« Pourquoi la pompe B7 s’est-elle arrêtée mardi dernier ? » Cette question devrait prendre quelques secondes à traiter, et non 11 jours d’e-mails entre trois équipes — voici ce que l’analyse compute-down des séries temporelles industrielles change à l’enquête.

« Pourquoi la pompe B7 s’est-elle arrêtée mardi dernier ? »

Voilà la question. Un opérateur la pose dans un couloir. Un directeur d’usine la pose après une réclamation client. Un ingénieur fiabilité la pose avant une revue de maintenance.

Elle paraît simple. Elle ne l’est pas.

Sur la plupart des sites industriels, cette seule phrase déclenche une chaîne de 11 jours d’e-mails et de messages Slack entre trois équipes avant que quiconque dispose d’une vraie réponse. Quand la réponse arrive, la production suivante a déjà démarré, le contexte est obsolète, et personne n’est certain que le correctif a bien traité la cause racine.

La boucle de 11 jours, étape par étape

Voici à quoi ressemble réellement cette enquête dans la plupart des usines :

La question est posée. Quelqu’un constate que la pompe B7 s’est arrêtée. Personne ne sait encore pourquoi.
L’équipe data est sollicitée. Les données brutes de séries temporelles vivent dans un historian que seule cette équipe sait interroger.
L’équipe data lance une requête, ou cinq. Chaque itération prend une journée, car la demande entre dans une file derrière d’autres demandes ponctuelles.
La maintenance est mise dans la boucle. Y a-t-il eu un ordre de travail ? Une intervention d’un technicien ? Ce journal se trouve dans un tout autre système.
La qualité est mise dans la boucle. L’arrêt correspond-il à un changement de lot ou de produit ? C’est sur papier, ou dans un troisième système.
Quelqu’un tente d’aligner les horodatages à la main. Sur trois systèmes, trois formats, trois responsables.
Une hypothèse se forme. Généralement partielle, parce que personne n’a eu la vision complète au même moment.
La réponse finit par arriver. Onze jours plus tard, en moyenne, d’après la difficulté que les équipes décrivent encore et encore.

Ce n’est pas un problème de personnes. C’est un problème d’architecture. Les données qui répondraient à la question en quelques secondes existent. Elles sont simplement éparpillées, cloisonnées, et verrouillées derrière la seule équipe qui sait les interroger.

Nous avons déjà écrit sur les raisons pour lesquelles 95 % des données industrielles brutes restent inexploitées parce que seule l’équipe data peut les interroger. La question de la pompe B7, c’est ce problème qui se joue en temps réel.

Pourquoi on ne peut pas simplement « donner ça à un LLM »

La solution qui semble évidente consiste à brancher un grand modèle de langage sur l’historian et à le laisser répondre aux questions en langage naturel. Cela ne fonctionne pas à l’échelle industrielle, et la raison est mathématique, pas une question d’ambition.

Une seule pompe à chaleur sur une seule semaine de données brutes de séries temporelles représente 5 à 30 fois plus que la plus grande fenêtre de contexte disponible sur le marché aujourd’hui. Une pompe, une semaine. Multipliez maintenant par une flotte entière.

Réinjecter des milliards de points bruts dans un LLM consomme des tokens, dépasse largement les fenêtres de contexte et ajoute une latence que l’enquête ne peut pas se permettre. Cela crée aussi un problème plus grave : l’échantillonnage. Quand l’historique complet n’entre pas dans le contexte, le modèle résume, et résumer des données brutes de séries temporelles revient à deviner ce qu’il faut laisser de côté.

Nous détaillons ce mode d’échec dans pourquoi réinjecter des données de séries temporelles dans un LLM échoue à l’échelle industrielle. En résumé : envoyer les données vers le modèle est la mauvaise direction.

Compute-down : envoyer le calcul vers les données

Spocky inverse le sens. Au lieu d’envoyer des milliards de points bruts dans une fenêtre de contexte, l’architecture compute-down envoie la requête là où les données se trouvent déjà, les interroge sur place et renvoie une réponse déterministe et explicable.

Pas de pipeline d’ingestion. Pas de nouvel entrepôt de données. Aucune replateformisation de l’historian.

C’est toute la différence entre :

Ingest-up : déplacer les données vers le modèle, atteindre les limites de contexte, obtenir un résumé approximatif.
Compute-down : déplacer la question vers les données, exécuter le calcul là où elles vivent, obtenir une réponse exacte.

Pour la pompe B7, cela signifie que Spocky peut recouper l’arrêt avec les journaux de maintenance, les interventions précédentes et l’historique d’exploitation automatiquement, dans la même requête, sans qu’un humain aligne manuellement trois tableurs.

Le résultat : demandez à Spocky pourquoi la pompe B7 s’est arrêtée, et obtenez une réponse déterministe et explicable en 7 secondes, recoupée automatiquement avec les journaux de maintenance. Pas un résumé. Pas une supposition plausible. Une réponse construite sur l’historique brut complet, calculée au moment de la requête.

Ce qui change pour l’équipe data

Le responsable data/analytics ne disparaît pas du tableau. Son rôle change.

Aujourd’hui, l’équipe data est le goulot d’étranglement : chaque question opérationnelle passe par elle, parce qu’elle est la seule à savoir interroger l’historian. Ce n’est pas un bon usage d’une équipe qualifiée, et ce n’est pas soutenable à mesure que le nombre de questions augmente.

Avec une analytique en langage naturel et compute-down, les opérateurs posent leurs questions directement. Pas de SQL. Pas de ticket de demande de tableau de bord. Pas d’attente dans une file derrière cinq autres demandes. L’équipe data passe du rôle de goulot d’étranglement des requêtes à celui de garante du système : valider la logique, affiner les agents et s’assurer que les réponses restent justes à mesure que de nouveaux équipements, capteurs et cas limites s’ajoutent.

C’est un meilleur compromis. C’est aussi le schéma que nous observons avec les historians industriels lorsque des agents de requête en langage naturel viennent s’y superposer — l’historian ne disparaît pas, il devient plus utile.

Pourquoi la réponse doit être déterministe, et non probabiliste

Dès qu’on utilise l’IA pour quoi que ce soit, la tentation est d’accepter un peu de flou en échange de rapidité. Dans les opérations industrielles, ce compromis ne tient pas.

Une réponse à « pourquoi la pompe B7 s’est-elle arrêtée » sert à justifier une décision de maintenance, une demande de garantie ou une revue de sécurité. Elle doit être explicable, et elle doit être reproductible. Si vous posez deux fois la même question, vous devez obtenir deux fois la même réponse, avec le même calcul montré.

C’est pourquoi les agents de Spocky sont conçus pour être déterministes et explicables, point final, et non échantillonnés ou approximatifs. Les plus de 1 300 fonctions analytiques développées au fil de quinze ans de R&D sur les séries temporelles existent pour calculer des réponses exactes sur l’historique brut, pas pour générer des résumés plausibles d’un échantillon.

Un humain valide toujours avant qu’une action soit menée sur la flotte. Spocky répond à l’enquête et fait remonter la recommandation ; la décision d’agir reste entre les mains de l’opérateur ou de l’ingénieur.

D’une enquête à la boucle d’exploitation

La question de la pompe B7 n’a pas à rester un cas isolé. Dès qu’un agent sait l’instruire, la même logique d’enquête se prolonge :

Explorer : poser la question, obtenir la réponse déterministe.
Automatiser : transformer la version récurrente de cette question en rapport permanent ou en alerte.
Agir : soutenir une action supervisée, avec une personne qui valide toujours.
Documenter : consigner ce qui s’est passé pour que la prochaine enquête démarre avec plus d’éléments, pas moins.
Prédire : accumuler assez d’historique de motifs validés pour signaler le prochain arrêt de type B7 avant qu’il ne survienne.

C’est la boucle d’exploitation. C’est la même boucle qui permet à une équipe de détection de deux personnes de superviser plus de 400 pompes à chaleur et de détecter les problèmes avant le client, et le même schéma derrière une réduction de 75 % des visites sur site pour un déploiement d’actifs connectés — moins d’interventions, parce que le diagnostic a lieu avant l’envoi du technicien, et non après.

Si votre équipe mène des pilotes de maintenance prédictive et peine à dépasser l’exploration, l’ordre compte : validez d’abord le motif. Nous traitons ce sujet dans pourquoi les programmes de maintenance prédictive IoT échouent sans analytique en langage naturel.

Récapitulatif des indicateurs

11 jours → 7 secondes : l’enquête sur la pompe B7, avant et après.
5 à 30 fois : l’écart entre les données hebdomadaires de séries temporelles d’une seule pompe à chaleur et la plus grande fenêtre de contexte LLM — la raison de l’échec des approches ingest-up.
Plus de 400 pompes à chaleur : supervisées par une équipe de détection de deux personnes grâce à une visibilité sur toute la flotte.
75 % de visites sur site en moins : dans un déploiement d’actifs connectés utilisant le diagnostic à distance avant l’envoi d’un technicien.
Plus de 1 300 fonctions analytiques : développées au fil de quinze ans de R&D sur les séries temporelles, disponibles au moment de la requête.
3 semaines : délai typique pour déployer un agent de production personnalisé.

Et maintenant ?

La chaîne de 11 jours n’est ni un problème de formation ni un manque d’outils dans une équipe donnée. C’est ce qui arrive quand les données brutes, les ordres de travail et la connaissance tacite vivent dans des systèmes différents et qu’une seule équipe peut interroger l’un d’entre eux.

L’analytique conversationnelle compute-down comble cet écart en répondant à la question là où les données se trouvent déjà, en quelques secondes, avec une trace déterministe que chacun peut vérifier.

Parlez à notre équipe, ou lisez d’autres témoignages clients, pour voir ce que cela donne sur votre flotte.

FAQ

Pourquoi enquêter sur un seul arrêt de pompe prend-il autant de temps aujourd’hui ?

Parce que les éléments de preuve vivent dans trois systèmes distincts : les données machine brutes dans un historian, les ordres de travail dans un système de maintenance, et les constats qualité sur papier. Répondre à « pourquoi la pompe B7 s’est-elle arrêtée » implique d’aligner manuellement les horodatages sur les trois, ce qui passe par des chaînes d’e-mails et de messages Slack entre équipes et prend généralement environ 11 jours.

Pourquoi ne peut-on pas simplement charger toutes les données de capteurs dans un LLM pour répondre à ces questions ?

Les fenêtres de contexte ne peuvent pas les contenir. Les données brutes de séries temporelles d’une seule pompe à chaleur sur une seule semaine représentent 5 à 30 fois plus que la plus grande fenêtre de contexte LLM du marché. Réinjecter des milliards de points consomme des tokens, ajoute de la latence et force le modèle à résumer au lieu de calculer sur l’historique complet.

Une réponse compute-down est-elle une estimation probabiliste ou un calcul exact ?

Elle est déterministe et explicable. Spocky envoie le calcul vers les données au lieu d’envoyer les données dans un modèle : la même question posée deux fois renvoie la même réponse avec le même calcul sous-jacent, et non un résumé échantillonné ou approximatif.

Cela remplace-t-il l’équipe data ?

Non. Cela lui retire le rôle de goulot d’étranglement des requêtes pour chaque question opérationnelle. Les opérateurs accèdent aux données brutes en libre-service et en langage naturel, tandis que l’équipe data se consacre à la gouvernance et à l’affinage des agents aux côtés des Forward Deployed Engineers.

Le système agit-il automatiquement sur les équipements ?

Non. Spocky prend en charge l’enquête, le reporting récurrent, les alertes et l’action supervisée, mais une personne valide toujours avant qu’une action soit menée sur la flotte.

Pourquoi l’enquête sur l’arrêt de votre pompe prend 11 jours — et comment la réduire à quelques secondes