« Il suffit de brancher un LLM sur l’historian » ne résiste pas aux données d’un parc réel. Une pompe à chaleur et une semaine de relevés peuvent déjà dépasser de 5 à 30 fois la plus grande fenêtre de contexte.

« Il suffit de brancher un LLM sur l’historian » ne résiste pas aux données d’un parc réel

Chaque trimestre, un responsable data et analytique industrielle entend le même argument : connectez votre historian à un LLM, posez-lui des questions en langage naturel, et obtenez de la maintenance prédictive.

Puis quelqu’un essaie sur un seul équipement. Pas un parc. Une pompe à chaleur. Une semaine de données de séries temporelles brutes.

Pour ce seul équipement et cette seule semaine, le volume des relevés est 5 à 30 fois supérieur à la plus grande fenêtre de contexte disponible aujourd’hui. Multipliez cela par un parc de centaines de pompes, de compresseurs ou de pompes à chaleur fonctionnant en continu, et le calcul cesse d’être théorique. C’est un mur.

C’est la partie que les démonstrations génériques de maintenance prédictive par IA passent sous silence. Elles montrent un graphique propre et la réponse d’un chatbot. Elles ne montrent pas ce qui arrive lorsque vous tentez de réinjecter des milliards de points bruts dans un modèle conçu pour lire des documents, pas pour raisonner sur l’historique opérationnel d’un parc.

Où l’approche naïve échoue, étape par étape

Le mode d’échec est le même dans toutes les équipes qui tentent de greffer un LLM générique sur des séries temporelles industrielles. Il prend la forme d’une boucle qui ne se referme jamais :

Quelqu’un pose une vraie question opérationnelle, par exemple : « Pourquoi la pompe B7 s’est-elle arrêtée mardi dernier ? »
L’équipe data essaie de tout transmettre au modèle. Tags de capteurs bruts, mois d’historique, journaux de maintenance, tout est envoyé en une fois dans la fenêtre de contexte.
La fenêtre de contexte déborde. Pas un peu. De 5 à 30 fois, pour un seul équipement sur une seule semaine.
L’équipe sous-échantillonne ou tronque les données pour les faire tenir. C’est là que la précision se dégrade discrètement, car les motifs importants, une dérive lente ou une signature de panne rare, se trouvent souvent précisément dans les données supprimées.
La latence et le coût des tokens augmentent. Chaque réingestion de données brutes dans le modèle consomme des tokens pour des données dont le modèle n’a pas besoin pour bien raisonner ; il a besoin du résultat du raisonnement effectué sur ces données.
La réponse arrive tard, ou n’arrive pas. La question initiale, « Pourquoi la pompe B7 s’est-elle arrêtée ? », devient le genre de chaîne d’e-mails de 11 jours entre trois équipes qu’une plateforme data était censée éliminer.

La cause profonde n’est pas l’intelligence du modèle. C’est l’architecture. Envoyer des milliards de points bruts au modèle au lieu d’envoyer les questions du modèle vers les données est une approche inversée à l’échelle industrielle.

Compute-down : envoyer le calcul vers les données, pas les données vers le modèle

Les agents de Spocky ne réinjectent pas les séries temporelles brutes dans une fenêtre de contexte. Ils envoient le calcul là où les données se trouvent déjà et ne rapportent que ce dont la question de l’opérateur a réellement besoin.

Cette seule décision de conception permet de garder des réponses déterministes et explicables, plutôt qu’une supposition présentée comme une réponse. Un modèle qui doit échantillonner, tronquer ou résumer des milliards de points avant de répondre ne raisonne pas sur l’historique de votre parc ; il raisonne sur la fraction qui a pu tenir.

Le compute-down change ce qui devient possible :

La consommation de tokens et la latence baissent jusqu’à 90 %, car l’agent ne déplace pas les données brutes dans les deux sens pour raisonner dessus.
L’historique opérationnel complet reste dans le périmètre, au lieu de la seule tranche ayant survécu au sous-échantillonnage.
Les réponses arrivent en quelques secondes, pas après un traitement par lots ou un contournement de la fenêtre de contexte.

C’est aussi pour cela que l’industrie revient sans cesse sur les raisons pour lesquelles réinjecter des séries temporelles dans un LLM échoue à l’échelle industrielle : il s’agit d’un schéma récurrent, pas d’une erreur d’ingénierie isolée. Ce schéma se répète parce que le calcul sous-jacent, nombre d’équipements × nombre de capteurs × fréquence d’échantillonnage × profondeur d’historique, dépasse toujours la croissance des fenêtres de contexte.

Pourquoi le problème s’aggrave avec la taille du parc

Un pilote sur un seul équipement peut survivre à une réingestion brutale, moyennant un certain coût. Un parc ne le peut pas.

Les difficultés se cumulent :

95 % des données industrielles brutes restent inexploitées, car seule l’équipe data sait les interroger. Chaque question opérationnelle passe par le même goulot d’étranglement.
Les ordres de travail, les données machines, les constats qualité et le savoir-faire des techniciens vivent dans des systèmes distincts. Personne ne peut donc suivre un même fil, d’un ordre de travail jusqu’à une réparation, sans rapprochement manuel.
Les problèmes à l’échelle du parc restent invisibles jusqu’à ce qu’un client ou un occupant les découvre en premier.

Agrandir la fenêtre de contexte du LLM ne résout rien de tout cela. La solution consiste à changer l’endroit où le calcul s’exécute. C’est la différence entre un chatbot greffé sur un historian et un historian de données industrielles associé à un agent de requête en langage naturel conçu pour l’échelle des données de capteurs continues.

La maintenance prédictive est la destination, pas le point de départ

Il faut être direct sur un point que le discours sur la maintenance prédictive par IA passe généralement sous silence : la prédiction est la dernière étape d’une boucle, pas la première.

Avant qu’un motif soit assez fiable pour servir à prédire, il faut le trouver, le valider et vérifier qu’il se confirme sur des cas répétés. Les équipes qui passent directement à « prédire la panne » sans d’abord explorer les données, confirmer le motif et valider les interventions réellement efficaces s’enlisent souvent avant même d’obtenir un modèle opérationnel. Cela explique en grande partie pourquoi les pilotes de maintenance prédictive s’arrêtent avant d’atteindre la prédiction.

Dans la pratique, l’ordre est le suivant :

Explorer : étudier l’historique brut pour trouver et confirmer un motif réel.
Automatiser : transformer le motif validé en rapport ou en alerte récurrente.
Agir, avec validation humaine : mener des actions supervisées sur le parc, sans jamais agir automatiquement sans décision humaine.
Documenter : consigner ce qui s’est passé et la solution appliquée.
Prédire : seulement lorsque les étapes précédentes ont produit assez de cas validés pour prédire avec confiance.

L’architecture compute-down rend d’abord possible l’étape 1 à l’échelle d’un parc. Si chaque exploration de l’historique brut fait déborder une fenêtre de contexte, les équipes ne vont jamais assez loin pour valider un motif qui mérite une prédiction. C’est aussi pourquoi la différence entre maintenance prédictive et maintenance préventive compte davantage que ne le laisse penser le vocabulaire : l’une repose sur des interventions planifiées sans preuve, l’autre exige des éléments probants.

Ce qu’il faut vérifier avant d’évaluer un outil de « maintenance prédictive par IA »

Pour un responsable data et analytique industrielle qui assiste à des démonstrations fournisseurs, quelques questions directes permettent de dépasser rapidement le discours marketing :

Où le calcul s’exécute-t-il : dans la fenêtre de contexte du modèle ou au niveau des données ? Si la réponse implique d’envoyer des séries temporelles brutes dans un prompt, demandez ce qui se passe au-delà d’un équipement et d’une semaine.
Que devient la fidélité lorsque le volume de données augmente ? Sous-échantillonner pour tenir dans une fenêtre de contexte signifie que le modèle raisonne sur une vue partielle, pas sur une vérité terrain déterministe.
Une décision humaine intervient-elle avant qu’une action touche le parc ? L’action supervisée, et non l’action autonome, doit être la réponse par défaut.
L’outil peut-il répondre à une question que personne n’avait anticipée ? Les tableaux de bord et les modèles préentraînés répondent aux questions pour lesquelles ils ont été conçus. Les agents travaillant sur les données brutes répondent à celles qui sont posées à 2 heures du matin après un arrêt.

Ces questions ne sont pas abstraites. Ce sont les mêmes qui distinguent un système de maintenance prédictive capable de découvrir pourquoi un événement s’est produit d’un système qui vous dit seulement ce qui s’est passé.

FAQ

L’IA remplacera-t-elle les équipes de maintenance ?

Non. Spocky repose sur le principe inverse : l’IA étend ce qu’un opérateur ou un technicien peut prendre en charge, davantage d’équipements, davantage d’investigations et des réponses plus rapides, sans supprimer la personne qui valide toute action menée sur le parc. Les agents font remonter des réponses et soutiennent l’action supervisée ; ils n’agissent pas seuls.

ChatGPT est-il une IA prédictive ou une IA générative ?

ChatGPT et les LLM généralistes similaires sont des IA génératives, conçues pour produire du texte à partir de motifs présents dans leurs données d’entraînement. La maintenance prédictive industrielle exige une autre architecture : une architecture qui raisonne de façon déterministe sur l’historique brut des séries temporelles à l’échelle d’un parc, et non une architecture qui génère une réponse plausible à partir d’un échantillon de données.

Pourquoi ne puis-je pas simplement envoyer les données de mon historian à un LLM pour faire de la maintenance prédictive ?

À cause du volume. Une semaine de données de séries temporelles brutes pour une seule pompe à chaleur représente 5 à 30 fois la plus grande fenêtre de contexte du marché. Réinjecter des milliards de points dans un modèle consomme des tokens, ajoute de la latence et impose un sous-échantillonnage qui peut masquer précisément le motif recherché. L’architecture compute-down évite ce problème en envoyant le calcul vers les données plutôt que les données vers le modèle.

Quels sont de vrais exemples de maintenance prédictive bien mise en œuvre ?

L’approche qui fonctionne commence par l’exploration d’un historique brut non échantillonné afin de valider un véritable motif de panne. Elle passe ensuite aux alertes automatisées, à l’action supervisée avec validation humaine, à la documentation, puis seulement à la prédiction. Passer directement à un modèle prédictif sans motifs validés est une raison fréquente de l’enlisement des pilotes.

Maintenance prédictive par IA : pourquoi envoyer des séries temporelles brutes à un LLM ne fonctionne pas