Comment le streaming de données de technologies opérationnelles dans Databricks permet aux agents d'IA composites de raisonner, d'optimiser et de conseiller, au lieu de simplement surveiller.
09 h 14, milieu de poste. La remplisseuse s'arrête sur défaut. Le responsable de ligne dispose de quelques minutes, et non d'heures, avant que les équipements en aval ne soient plus alimentés. L'équipe sait déjà quoi faire sur le plan mécanique. Les questions qui prennent le plus de temps concernent la planification. Pouvons-nous encore atteindre l'objectif de production du poste ? Est-il plus économique d'accélérer la cadence par la suite ou de recourir à des heures supplémentaires ? Ce même défaut s'est-il déjà produit sur cette ligne, et comment l'équipe précédente s'en est-elle sortie ?
Les données pour répondre à ces trois questions existent déjà, dispersées dans les PLCs, SCADA, MES, ERP et LIMS.
ProdLine CoPilot est conçu pour ce court laps de temps. Il lit l'état en temps réel depuis la Databricks Data Intelligence Platform, oriente la question vers un spécialiste du domaine et exécute les calculs sous-jacents (rattrapage de planning, épuisement des stocks, risque qualité). Le plan proposé est testé par rapport à 1 000 scénarios de planification, équilibrant les compromis entre coûts, heures supplémentaires et niveau de service. Le responsable de ligne choisit. Le système rédige les documents (ordre de travail, blocage, note de planification) pour approbation.
Une ligne d'emballage PGC (produits de grande consommation) typique (embouteillage, mise en conserve, snacks, cosmétiques) compte 15 à 20 machines. Lorsqu'une remplisseuse ou une étiqueteuse s'arrête, les zones d'accumulation ne couvrent que quelques minutes avant que la ligne ne soit plus alimentée et que la production ne chute bien en dessous de la capacité nominale. Un OEE de classe mondiale se situe autour de 85 % ; de nombreuses usines sont plutôt proches de 70 à 75 %. À 500 caisses/heure sur un rythme de 24h/24 et 5j/7 avec une marge de 10 € par caisse, un point de OEE représente environ 300 000 € par an. Comblez un écart de 10 points sur une seule ligne et vous atteignez rapidement des millions ; à l'échelle d'une usine dotée d'une douzaine de lignes, l'addition grimpe vite.
Les données pour combler cet écart existent déjà :
Ces systèmes ne communiquent pas entre eux. Et les personnes qui ont besoin de réponses (responsables de ligne, chefs d'équipe, planificateurs) ne maîtrisent généralement pas le SQL.
Le schéma est classique : d'abord les rapports de fin de poste, puis la requête d'un analyste le lendemain matin, et enfin une réunion RCA 24 heures après les faits. Tout cela alors que la décision de rattrapage (vitesse, heures supplémentaires, CIP) a déjà dû être prise pendant le poste.
Diffuser l'OT en continu vers Databricks ne se limite pas à une simple mise à niveau de tableau de bord. Associer l'OT au MES, à l'ERP et au LIMS au sein d'un lakehouse gouverné unique permet aux agents de raisonner sur l'état en temps réel, d'optimiser sous des contraintes réelles et de faire des recommandations pendant le poste plutôt qu'après coup.
L'ancien modèle consistait à déployer une infrastructure complexe de type Kafka (brokers, partitions, groupes de consommateurs) uniquement pour déplacer les données de l'usine. Zerobus Ingest remplace cela. Il fonctionne en mode push et est serverless.
Tout système capable d'émettre des appels gRPC ou REST (passerelle PLC, connecteur d'historien, boîtier edge) insère des lignes dans les tables Delta de Unity Catalog.
Pas de brokers, pas de partitions ; vous évoluez en ouvrant simplement plus de connexions. Associez-le aux Lakeflow Spark Declarative Pipelines et à l'architecture médaillon standard Bronze, Silver, Gold pour la télémétrie, les signaux de qualité, les événements et les stocks.
Le MES, l'ERP et le LIMS arrivent à un rythme plus lent que l'OT à la sous-seconde (miroir, batch ou CDC), mais ils côtoient les tables OT sous un catalogue gouverné unique plutôt que dans un entrepôt de données distinct.
Une fois les données intégrées, ces mêmes tables alimentent SQL, Genie, AI Search, Model Serving et les agents, avec un lignage partagé sous Unity Catalog.
Les signaux prédictifs, le rattrapage de planning et les analyses en aval lisent tous à partir de ces tables gouvernées, de sorte que chaque nouvelle fonctionnalité écrit sur la copie existante au lieu de provisionner sa propre version.
Zerobus + Delta gère l'ingestion en quasi-temps réel avec une latence de l'ordre de quelques secondes, le tout gouverné sous Unity Catalog. Pour l'UI en direct de cette démo, le producteur écrit également directement dans Lakebase : un raccourci pour donner une impression de temps réel aujourd'hui, et non le modèle à long terme. La lecture à la milliseconde sur ces mêmes tables Delta est ce que gérera Lakehouse//RT, l'entrepôt de données en temps réel de Databricks sur le lakehouse.
De nombreuses usines gèrent les rapports d'un côté et les modèles de l'autre, de sorte que la ligne elle-même se retrouve avec plusieurs versions de la vérité selon les systèmes. Cette division paralyse les copilotes en cours de poste :
Le lakehouse sur Databricks élimine cette division sur chacun de ces trois points. Il n'y a qu'une seule copie des données (Delta ouvert sur le stockage cloud, et non une extraction distincte par charge de travail). La gouvernance s'applique directement à cette copie dans Unity Catalog, de sorte que les autorisations de l'analyste et celles de l'agent proviennent de la même source. De plus, le streaming, le SQL, l'IA et le serving s'exécutent tous sur une base unique, de sorte que le rapport du matin et l'écran en direct affichent exactement les mêmes chiffres.
Les spécialistes et les outils d'optimisation lisent les mêmes tables gouvernées que vos pipelines maintiennent. Il n'y a pas de base de données IA distincte.
L'orchestrateur est le point d'entrée. Il accepte une question en langage naturel, charge l'état actuel depuis Unity Catalog (machines, événements, planning, stocks, qualité, contraintes) et oriente l'intention vers le bon spécialiste.
Chaque appel lit le dernier état UC avant le démarrage du LLM. Le système recommande et rédige des documents (tickets, approbations, notes de poste). L'exécution reste du ressort du responsable de ligne, de la qualité et de la maintenance.
La mémoire conversationnelle à court terme réside dans Lakebase, et le corpus des incidents passés dans AI Search. Model Serving déploie les modèles et MLflow trace chaque appel.
Un agent générique simplifie à l'extrême ou perd le fil. L'analyse RCA des temps d'arrêt, la gestion des stocks et les calculs de planning nécessitent des données et des logiques mathématiques différentes. Un collectif de spécialistes permet de garder chaque prompt précis et chaque outil ciblé sur la question posée.
Par exemple, l'Analyste des temps d'arrêt ne gaspille pas de contexte sur les tables de stocks, et l'Optimiseur de planning n'extrait pas les lignes brutes de contrôle qualité comme le fait le Spécialiste qualité.
| Spécialiste | Rôle |
|---|---|
| Analyste des temps d'arrêt | Cause racine, cascade sur plusieurs machines, priorité de rattrapage ; événements + capteurs |
| Spécialiste qualité | SPC sur le remplissage, le couple de serrage, les étiquettes, le poids des caisses ; blocage/libération ; risque bayésien |
| Conseiller supply chain | Des dizaines d'intrants de ligne (ex. étiquettes, film, bouchons, adhésifs, produits chimiques de procédé) — taux de consommation, épuisement, urgence de réapprovisionnement |
| Coach OEE | Pertes de disponibilité / performance / qualité ; Pareto ; Genie pour les tendances |
| Optimiseur de planning | Plans de rattrapage MILP / stochastiques ; compromis : coût, risque de planning/service, débit |
| Prédicteur de maintenance | Anomalies (Z-score, IQR) ; signaux de type RUL ; compromis PM |
| Conseiller stratégique | Tendances sur plusieurs postes ; feuille de route d'amélioration ; cadrage capex/opex ; benchmarking |
| Briefing de poste | Comptes rendus de réunion d'avant-poste / de passation de consignes ; synthèse adaptée à Genie et optimisée pour le mobile |
Les spécialistes appellent un ensemble restreint et fixe d'outils. SQL Query et Genie Space effectuent des lectures gouvernées, de la même manière que le reste de l'organisation. Le Calculateur exécute les calculs de OEE, de rattrapage et d'épuisement en Python (NumPy et Pandas) sur la télémétrie issue de Databricks SQL. Un Détecteur d'anomalies exécute le Z-score et l'écart interquartile (IQR) sur des fenêtres glissantes directement sur ces tables. Plan & Constraints contient les limites de vitesse par ligne, les fenêtres de CIP, les règles de changement de format et la politique d'heures supplémentaires. Similar Cases récupère les incidents historiques depuis Databricks AI Search.
De nombreux copilotes industriels ne sont que de simples surcouches de LLM. ProdLine oriente vers de véritables solveurs (du type de ceux utilisés par les équipes de recherche opérationnelle) via le langage naturel.
| Optimiseur | Méthode | Problème résolu |
|---|---|---|
| Rattrapage de planning | MILP (OR-Tools SCIP) | Vitesse, OT, CIP — optimal selon le modèle défini, pas une vague heuristique |
| Planning stochastique | SAA + scénarios | Plan robuste face à la variabilité du OEE / des micro-arrêts |
| Prévision de production | Monte Carlo (ex. 1 000 trajectoires) | Intervalles de finalisation P10/P50/P90 basés sur l'historique |
| Risque qualité | CPT bayésienne | Score de risque + facteurs clés |
| Analyse des pertes de OEE | Pareto | Classement des pertes par ampleur / ROI |
| Planificateur multi-postes | Optimisation séquentielle | Vitesse, OT, CIP, PM sur plusieurs postes |
| Estimateur de RUL | Extrapolations de tendances | Compromis sur le calendrier de PM |
Rien ne s'exécute sans validation humaine. Le responsable de ligne gère la reprise, le service qualité gère le blocage et la libération, et la maintenance gère le bon de travail. L'objectif est de réduire la charge cognitive liée aux allers-retours entre les feuilles de calcul, les radios et les tableaux de bord, et non de remplacer le responsable de production.
Il doit répondre à trois questions en moins d'une minute : que se passe-t-il, quelles sont les options réalistes et quel est le coût de chaque option en termes de débit, d'heures supplémentaires, de qualité et de service.
Portes d'approbation (par conception) :
| Rôle | Approuve |
|---|---|
| Responsable de ligne | Reprise : vitesse, heures supplémentaires, calendrier |
| Qualité | Blocage/libération, écarts |
| Maintenance | Étendue des travaux et calendrier |
La démo actuelle couvre la boucle de raisonnement et de recommandation. La prochaine étape consiste à boucler la boucle avec des écritures retour (write-backs) dans le système, toutes conçues comme des brouillons plutôt que comme un contrôle automatique.
Le transfert vers la CMMS est un brouillon de bon de travail (panne diagnostiquée, étendue recommandée, temps cible, pièces requises) que le planificateur doit planifier. Pour la qualité, le QMS et le LIMS reçoivent une fiche d'écart pré-remplie (lot, machine, identifiants d'échantillons, gravité, décision recommandée) que le responsable qualité examine et valide. Le MES et le système de planification et d'ordonnancement avancés (APS) récupèrent un brouillon de mise à jour du calendrier avec des ajustements de vitesse, des heures supplémentaires, des changements de séquence et la justification de la reprise, réécrits pour l'exécution de l'équipe.
La traçabilité suit la même feuille de route : chaque recommandation stocke ses entrées, hypothèses, contraintes, approbateur et résultat de bout en bout, facilitant ainsi le passage de relais entre les équipes et l'amélioration continue.
La partie la plus difficile d'un déploiement multi-sites concerne les données, pas l'IA. Chaque usine possède ses propres machines, ses propres SOP et son propre schéma LIMS. Ce qui fait de la deuxième usine un ajout de valeur plutôt qu'un projet parallèle, c'est la couche de streaming sous-jacente : chaque usine s'appuie sur le même modèle Zerobus, la même architecture en médaillon (medallion layout) et la même gouvernance Unity Catalog, avec ses propres tables et son propre Genie Space sous un espace de noms dédié.
Les optimiseurs restent paramétrés. Une table line_constraints pilote les limites de vitesse, les limites d'heures supplémentaires, les fenêtres de CIP et les changements de série, de sorte que la modification des données modifie le comportement, sans qu'aucun redéploiement ne soit nécessaire.
Cette même base finance le cas d'usage suivant. L'énergie et la durabilité lisent la même télémétrie, la qualité des fournisseurs s'appuie sur la jointure LIMS, et la sécurité s'appuie sur le flux d'événements. Chaque nouveau projet repose sur l'infrastructure que le premier a déjà amortie, au lieu de devoir mettre en place une plateforme parallèle.
Clonez le dépôt de code et exécutez databricks bundle deploy dans votre propre espace de travail. Pour utiliser les données de votre propre usine, pointez le producteur vers votre historien de données plutôt que vers le simulateur ; Zerobus, l'architecture en médaillon, les outils d'agent et les brouillons validés par l'humain restent en place. Ouvrez prodline_copilot_film.html dans un navigateur pour une présentation animée de deux minutes avant de cloner.
Vous souhaitez créer votre propre assistant de surveillance de ligne et en savoir plus ? Contactez votre représentant commercial Databricks. Un spécialiste Databricks peut également vous aider à définir le périmètre d'intégration de l'OT, du MES, de l'ERP et du LIMS dans un lakehouse unique et gouverné.
Acronymes utilisés dans cet article, par ordre alphabétique.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.