Historiens de données industrielles contre agents de requête en langage naturel : ce qui change sur le terrain

Un historien de données industrielles conserve la mémoire brute en séries temporelles de votre site, mais quelqu'un doit encore savoir comment l'interroger. Voici ce qui change quand un agent en langage naturel se place au-dessus de PI, AVEVA ou FactoryTalk au lieu de les remplacer.

« Nous avons les données. Nous n'arrivons simplement pas à obtenir une réponse assez vite. »

C'est la phrase que nous entendons des directeurs exploitation et maintenance qui utilisent déjà un historien mature. PI, AVEVA, FactoryTalk : les données brutes sont là, horodatées et compressées, sur plusieurs années.

Le problème n'est pas la collecte. C'est l'écart entre des données stockées dans l'historien et une personne qui obtient une réponse au moment où elle en a besoin.

Cet article s'adresse à la personne qui compare les outils d'historien, non pas parce qu'elle n'en a pas, mais parce qu'elle se demande si son historien suffit à lui seul, ou s'il faut quelque chose au-dessus.

Ce que fait réellement un historien de données

Un historien de données industrielles est une base de données spécialisée conçue pour collecter, stocker et gérer les données de séries temporelles issues des procédés industriels : température, pression, débit, position de vanne, alarmes, événements, tous horodatés pour disposer du contexte historique.

Selon AVEVA, son produit Historian combine « des techniques avancées de stockage et de compression des données avec une interface de requête standard du secteur » afin de donner aux équipes d'exploitation accès à l'historique des procédés, des alarmes et des événements pour le diagnostic et la prise de décision.

AspenTech décrit la catégorie de la même manière : un historien est « une archive numérique méticuleusement organisée » qui capture chaque fluctuation et chaque relevé, et sert de fondation au monitoring temps réel, au reporting de conformité et à l'analytique avancée.

Les historiens sont bons pour :

C'est sur ce dernier point que l'écart se creuse. L'interface de requête est conçue pour quelqu'un qui sait déjà quoi demander, et comment le demander dans le langage propre à l'historien.

SCADA, historien, et l'origine de la confusion

Les personnes qui cherchent sur ce sujet arrivent souvent sur la question connexe « quelle est la différence entre SCADA et historien ». En bref : le SCADA contrôle et affiche le procédé maintenant. L'historien archive ce que le SCADA a vu, pour que quelqu'un puisse y revenir plus tard.

Les deux répondent à « que s'est-il passé ». Aucun des deux, à lui seul, ne répond à « pourquoi cela s'est-il passé » ou « est-ce déjà arrivé, et qu'est-ce qui l'a résolu la dernière fois » sans qu'une personne extraie manuellement les tags, construise une courbe de tendance et croise un journal de maintenance distinct.

L'écart : les données brutes ont encore besoin d'une personne pour les traduire

Voici la difficulté que nous entendons le plus souvent chez les directeurs exploitation et maintenance qui exploitent des historiens à grande échelle : la performance de la flotte reste invisible jusqu'à ce qu'un locataire ou un client découvre le problème en premier. Si un locataire doit découvrir le problème, l'équipe a déjà échoué.

L'historien a enregistré les données. Personne ne les surveillait d'une manière qui fasse remonter l'anomalie à la personne capable d'agir.

Une difficulté liée : une seule question comme « pourquoi la pompe B7 s'est-elle arrêtée mardi dernier » se transforme en plusieurs jours d'e-mails et de messages Slack entre trois équipes avant que quiconque obtienne une réponse, alors même que l'historien contient chaque point de donnée nécessaire pour y répondre en quelques secondes. Nous avons écrit sur cette boucle d'enquête précise dans pourquoi l'enquête sur l'arrêt de votre pompe prend 11 jours.

L'historien n'est pas le goulot d'étranglement. Le goulot d'étranglement, c'est que quelqu'un doit encore connaître les noms de tags, construire la bonne requête et se rappeler quel journal de maintenance consulter.

Ce qu'apporte un agent de requête en langage naturel

Un agent de requête ne remplace pas l'historien. Il se place au-dessus, comme une couche de raisonnement qui lit les données brutes de séries temporelles comme le ferait un ingénieur expérimenté, et répond en langage courant.

C'est le modèle utilisé par Spocky. Spocky ne réinjecte pas l'historique brut d'un historien dans un LLM : à l'échelle industrielle, cela consomme des tokens et dépasse rapidement les fenêtres de contexte, un point que nous détaillons dans pourquoi la réinjection des données de séries temporelles dans un LLM échoue à l'échelle industrielle. À la place, l'architecture compute-down de Spocky envoie le calcul vers les données, là où elles se trouvent déjà, et renvoie une réponse déterministe et explicable.

Concrètement, au-dessus d'un historien existant, cela ressemble à ceci :

L'agent ne devine pas. Il raisonne sur les données brutes de séries temporelles déjà présentes dans l'historien et montre son raisonnement.

Pourquoi cela compte particulièrement pour les directeurs exploitation et maintenance

Trois difficultés reviennent sans cesse chez les responsables d'exploitation qui gèrent des flottes distribuées au-dessus d'un historien :

La visibilité sur la flotte. Attendre qu'un locataire signale un problème signifie que l'équipe a déjà perdu. Une couche de requête et d'alerte qui surveille la flotte et signale les anomalies dès leur apparition, au lieu de les laisser enfouies dans les données brutes, comble cet écart.

Les déplacements réactifs. Envoyer un technicien avant de savoir si une visite est même nécessaire érode la marge de chaque contrat de service. Quand la télémétrie, l'historique, les manuels et les interventions passées sont interrogeables en un seul endroit, davantage de problèmes se résolvent à distance, et les visites restantes se font avec la bonne pièce en main.

Aucune preuve qu'une intervention a fonctionné. Comparer les performances entre sites et flottes, ou confirmer qu'un correctif a réellement tenu, implique en général de courir après des tableaux de bord après coup. Un agent de requête qui croise automatiquement les données d'intervention remplace cette course manuelle par une réponse directe.

Rien de tout cela n'exige de changer d'historien. Cela exige une couche qui rende les données de l'historien utilisables par les personnes qui décident, et pas seulement par l'équipe data qui sait les interroger.

Ce qui ne change pas

Votre historien reste votre système de référence. PI reste PI. AVEVA reste AVEVA. La compression, la piste d'audit, le reporting de conformité : cette infrastructure ne disparaît pas, et elle ne doit pas disparaître.

Ce qui change, c'est qui peut en obtenir une réponse, et à quelle vitesse. Au lieu que l'équipe data traite chaque demande ponctuelle, les opérateurs et les ingénieurs demandent directement. Au lieu qu'une personne agisse seule sur un changement à l'échelle de la flotte, l'agent fait remonter le constat et une personne valide toujours avant toute action.

Lecture connexe sur la façon dont ce schéma apparaît dans les programmes de maintenance prédictive : les programmes de maintenance prédictive IoT échouent sans cette couche manquante.

FAQ

Que fait un historien de données ?

Un historien de données collecte, stocke et gère les données de séries temporelles issues des procédés industriels : température, pression, débit, alarmes et événements, horodatés pour être récupérés et analysés plus tard. C'est la couche d'archivage du système de contrôle d'un site, distincte du SCADA, qui assure le contrôle et l'affichage en temps réel.

Quelle est la différence entre le SCADA et un historien ?

Le SCADA surveille et contrôle le procédé en temps réel. L'historien archive ce que le SCADA a enregistré pour que quelqu'un puisse y revenir plus tard, construire des courbes de tendance ou enquêter sur un événement après coup.

Ajouter un agent de requête signifie-t-il remplacer notre historien ?

Non. Un agent de requête en langage naturel comme Spocky se place au-dessus de votre historien existant (PI, AVEVA, FactoryTalk ou un autre) comme couche de raisonnement. Il lit les données brutes de séries temporelles qui y sont déjà stockées et répond aux questions en langage courant, en les croisant avec les journaux de maintenance et d'autres éléments de contexte opérationnel.

Les opérateurs peuvent-ils interroger l'historien directement sans l'équipe data ?

Avec une couche en langage naturel, oui. Les opérateurs et les ingénieurs posent leurs questions en anglais courant et obtiennent une réponse déterministe et explicable, sans avoir à connaître les structures de tags ni la syntaxe de requête. Cela libère l'équipe data de son rôle de goulot d'étranglement pour chaque demande ponctuelle.

L'agent agit-il automatiquement sur la flotte ?

Non. Spocky fait remonter les constats et prend en charge les actions, mais une personne valide avant que quoi que ce soit ne se produise sur la flotte. La décision humaine reste dans la boucle pour toute action ayant des conséquences.