Consommer les données d’autres applications

Chaque application IronFlock reçoit un backend de données privé et isolé : ses propres tables, ses propres flux en direct, son propre realm. C’est l’isolation qui rend les applications sûres à installer — mais à elle seule, elle ferait aussi de chaque application un silo. Les données qu’une application collectrice recueille sur une machine ont une valeur qui dépasse largement cette seule application : elles sont la matière première des tableaux de bord, des analyses, des modèles de machine learning et des rapports.

L’accès aux données inter-applications transforme les applications installées en briques de construction. Une application peut déclarer qu’elle souhaite lire les données d’une autre application du même projet — ses flux d’événements en direct et son historique enregistré. L’utilisateur propriétaire du projet décide de l’autoriser ou non, application par application, avec un interrupteur qu’il peut basculer à tout moment. La plateforme applique le reste : l’accès est strictement en lecture seule, limité aux tables que l’application fournisseuse partage réellement, et ne franchit jamais les frontières d’un projet.

Ce que cela rend possible

• Des analyses prêtes à l’emploi au-dessus des collecteurs. Installez un collecteur de données sur vos machines, puis installez une application de tableau de bord OEE qui consomme les mesures du collecteur — sans projet d’intégration, sans export de données, sans code de liaison.
• Du machine learning sans plomberie. Une application de maintenance prédictive peut s’entraîner sur des mois d’historique de vibrations et de températures déjà collecté par une autre application, et évaluer les lectures en direct au fil de leur arrivée.
• Des applications spécialisées plutôt que des monolithes. Séparez la collecte, la transformation, la visualisation et le reporting en applications distinctes qui font chacune une chose bien — et combinez-les par projet comme des briques de Lego.
• Un écosystème, pas des silos. Publiez une application dont toute la valeur réside dans ce qu’elle fait des données des autres applications. La fiche App Store montre aux utilisateurs quelles données une application partage et quelles données elle demande.

Fonctionnement

Trois parties sont impliquées, et chacune garde le contrôle de ce qui lui appartient :

1. L’application fournisseuse (« App B ») définit ses tables et ses transformations dans son data-template.yml, comme toute application. Tout est partageable par défaut ; des tables individuelles peuvent être marquées private.
2. L’application consommatrice (« App A ») déclare dans son data-template.yml de quelles applications elle souhaite lire les données, et pourquoi.
3. L’utilisateur installe les deux applications dans un projet et approuve l’accès — au moment de l’installation, ou plus tard via un interrupteur par application dans les paramètres d’applications du projet. Pas d’approbation, pas d’accès : la déclaration seule n’accorde rien.

Les données ne quittent jamais le projet. Le développeur de l’application fournisseuse n’a toujours pas accès aux données de l’utilisateur — l’autorisation s’établit entre des applications installées au sein d’un même projet, sous le contrôle du propriétaire du projet.

Une base de données de projet standardisée, de nombreux backends isolés

En interne, chaque projet IronFlock provisionne la même base de données de séries temporelles standardisée. À l’intérieur, chaque application installée possède un espace backend privé et séparé : ses tables vivent dans leur propre schéma de base de données, invisibles pour toute autre application tant que l’utilisateur n’accorde pas d’accès en lecture. Cette conception — une base de données par projet — est ce qui fait fonctionner l’ensemble du modèle :

• Reproductible d’un projet à l’autre. Le backend de données d’une application est provisionné à l’identique dans chaque projet où elle est installée — mêmes tables, mêmes types, même comportement de requête, que le projet s’exécute dans le cloud managé ou sur une appliance sur site. Développez une fois pour ce backend ; il se comporte de la même façon partout.
• Un point central de collecte et d’inspection. Les propriétaires de projet voient les données de toutes leurs applications en un seul endroit — une seule base de données à inspecter, interroger et posséder, au lieu d’un éparpillement de stockages par application.
• Isolation par défaut, partage sur autorisation. L’isolation par schéma garde l’espace de chaque application privé. Une autorisation inter-applications ouvre une fenêtre en lecture seule sur le schéma d’une autre application — au sein de la même base de données, si bien que rien n’est copié, exporté ni synchronisé. Les données n’ont qu’un seul foyer ; c’est l’accès qui change.

Déclarer la dépendance

L’application consommatrice annonce les applications qu’elle lit dans son .ironflock/data-template.yml :

consumes:
  - app: machine-monitor
    reason: "Calcule l'OEE à partir des flux d'états machine et de compteurs du moniteur"
 
data:
  tables:
    - tablename: oee_results
      columns:
        # ... les propres tables de votre application, comme d'habitude

Le champ app est le nom technique de l’application fournisseuse (affiché sur sa page App Store). La reason est présentée à l’utilisateur dans la boîte de dialogue de consentement — écrivez-la pour un humain qui décide s’il peut faire confiance à votre application.

Lire les données

À l’exécution, le SDK se connecte au backend de données de l’application fournisseuse et vous donne la même API de lecture que celle que vous utilisez déjà pour vos propres tables :

from ironflock import IronFlock
 
flock = IronFlock()
 
# Connect to the providing app's data backend (requires the user's grant)
monitor = await flock.connect_to_app("machine-monitor")
 
# Discover what it shares
print(monitor.tables)      # shared tables with their columns
print(monitor.transforms)  # shared transforms (views)
 
# Query history
rows = await monitor.get_history("machinestate", {"limit": 1000})
 
# Down-sampled series for charts and models
series = await monitor.get_series_history("measurements", {
    "metrics": ["temperature"],
    "method": "AVG",
    "timeRange": ["2026-07-01T00:00:00Z", "2026-07-04T00:00:00Z"],
})
 
# Subscribe to live rows as they are collected
async def on_row(row):
    print("live reading:", row)
 
await monitor.subscribe_to_table("measurements", on_row)

import { IronFlock } from "ironflock";
 
const flock = new IronFlock();
await flock.start();
 
// Connect to the providing app's data backend (requires the user's grant)
const monitor = await flock.connectToApp("machine-monitor");
 
// Discover what it shares
console.log(monitor.tables);      // shared tables with their columns
console.log(monitor.transforms); // shared transforms (views)
 
// Query history
const rows = await monitor.getHistory("machinestate", { limit: 1000 });
 
// Down-sampled series for charts and models
const series = await monitor.getSeriesHistory("measurements", {
  metrics: ["temperature"],
  method: "AVG",
  timeRange: ["2026-07-01T00:00:00Z", "2026-07-04T00:00:00Z"],
});
 
// Subscribe to live rows as they are collected
await monitor.subscribeToTable("measurements", (row) => {
  console.log("live reading:", row);
});

Si l’utilisateur n’a pas accordé l’accès (ou le révoque plus tard), connectToApp échoue avec une erreur claire et typée — votre application doit traiter la source de données comme optionnelle et continuer de fonctionner en se dégradant proprement.

Consommer toutes les données du projet (joker)

Certaines applications sont des ateliers de données polyvalents — un runtime Node-RED, un notebook, un outil de reporting — dont toute la valeur réside dans le fait de laisser l’utilisateur travailler avec n’importe quelles données présentes dans le projet. Une telle application ne peut pas nommer les fournisseurs à l’avance ; elle ne sait pas quels collecteurs ou applications d’analyse l’utilisateur installera. Pour celles-ci, déclarez un joker : un accès en lecture aux données de chaque application du projet.

consumes:
  - app: "*"          # the quotes are REQUIRED — a bare * is a YAML alias
    reason: "Vous permet de créer des flux sur les données en direct et historiques de chaque application de ce projet"

Le joker "*" accorde un accès en lecture à toutes les applications du projet — y compris celles que l’utilisateur installe plus tard, sans nouveau consentement. Tout le reste du modèle est inchangé : l’accès reste en lecture seule, les tables et transformations privées ne sont toujours jamais partagées, et les applications de plateforme sont hors périmètre. L’utilisateur approuve le joker avec un unique interrupteur tout-ou-rien (au lieu d’une liste par application), et peut le révoquer à tout moment.

Comme une application consommatrice à joker ne connaît pas les noms des fournisseurs à l’avance, elle les découvre à l’exécution :

from ironflock import IronFlock
 
flock = IronFlock()
 
# Discover every app whose data you may read (name + shared-table catalog)
providers = await flock.list_consumable_apps()
for p in providers:
    print(p["app"], p["stages"])   # e.g. "energy-monitor", {"prod": {"tables": [...]}}
 
# Open one by name (works because you hold the wildcard grant)
energy = await flock.connect_to_app("energy-monitor")
rows = await energy.get_history("meterdata", {"limit": 1000})
 
# ...or open them all at once
all_apps = await flock.connect_to_all_apps()
for app in all_apps:
    await app.subscribe_to_table(app.tables[0]["tablename"], on_row)

import { IronFlock } from "ironflock";
 
const flock = new IronFlock();
await flock.start();
 
// Discover every app whose data you may read (name + shared-table catalog)
const providers = await flock.listConsumableApps();
for (const p of providers) {
  console.log(p.app, p.stages);   // e.g. "energy-monitor", { prod: { tables: [...] } }
}
 
// Open one by name (works because you hold the wildcard grant)
const energy = await flock.connectToApp("energy-monitor");
const rows = await energy.getHistory("meterdata", { limit: 1000 });
 
// ...or open them all at once
const all = await flock.connectToAllApps();
for (const app of all) {
  await app.subscribeToTable(app.tables[0].tablename, onRow);
}

listConsumableApps() est la primitive — un seul appel, n’ouvre aucune connexion, renvoie le catalogue non privé de chaque fournisseur pour que vous puissiez afficher un sélecteur. connectToAllApps() est le raccourci pratique qui les ouvre toutes d’un coup. Les applications nouvellement installées apparaissent automatiquement au prochain appel à listConsumableApps(). Si l’utilisateur n’a pas accordé le joker, les deux échouent avec une erreur typée NO_GRANT.

En lecture seule par construction

L’autorisation est appliquée par la couche de messagerie de la plateforme, pas par convention. Une application consommatrice peut :

Partager les données de votre application — et en garder certaines

Si vous construisez une application qui collecte des données précieuses, c’est en les partageant que votre application devient une fondation sur laquelle d’autres construisent. Vous n’êtes pas obligé de tout partager : marquez les tables ou transformations internes private et elles disparaissent entièrement du catalogue partagé — ni listées, ni interrogeables, ni diffusées.

data:
  tables:
    - tablename: measurements        # partagée (par défaut)
      columns: [ ... ]
    - tablename: calibration_state   # interne — jamais visible pour les autres applications
      private: true
      columns: [ ... ]
  transforms:
    - tablename: hourly_aggregates   # les vues partagées fonctionnent comme les tables partagées
      sql: "SELECT ..."

L’utilisateur garde le contrôle

• Au moment de l’installation, l’utilisateur voit exactement de quelles applications installées la nouvelle application souhaite lire les données, et pourquoi — et peut refuser chacune d’elles. Un refus ne bloque jamais l’installation ; l’application ne reçoit simplement pas les données.
• Chaque accès accordé apparaît comme un interrupteur dans les paramètres d’applications du projet, où il peut être révoqué (ou accordé plus tard, par exemple après l’installation de l’application fournisseuse) à tout moment.
• Les autorisations sont propres à chaque projet. Installer la même paire d’applications dans un autre projet repart de zéro.

Une composition typique

Le modèle qui rend tout cela concret — la collecte, l’analyse et la visualisation comme applications séparées et composables — est décrit de bout en bout dans Extraction de données de l’usine : des collecteurs de protocoles extraient les données des machines, et des tableaux de bord OEE, des modèles de maintenance prédictive ou des analyses énergétiques les consomment, chacun installé et autorisé indépendamment.