Une semaine de données de séries temporelles brutes provenant d’une seule pompe à chaleur représente un volume 5 à 30 fois supérieur à la plus grande fenêtre de contexte de LLM disponible sur le marché. Voici ce que cela implique pour toute équipe qui tente de greffer une IA conversationnelle sur un parc, et ce que fait une architecture compute-down à la place.

« Il suffit de brancher le LLM sur l’historian »

C’est l’argument que beaucoup d’équipes entendent. On raccorde l’historian, on envoie les tags bruts dans un grand modèle de langage, on pose ses questions en anglais courant, et c’est réglé.

Cela ne résiste pas au contact d’un parc réel.

Un responsable data et analytique industrielle avec qui nous avons échangé le résume ainsi : « Nous avons essayé d’alimenter le modèle avec une semaine de données d’une seule machine. Cela n’a même pas franchi l’étape d’ingestion. »

Ce n’est pas un défaut d’outillage. C’est une question de mathématiques.

Les chiffres derrière l’échec

Prenons une pompe à chaleur. Télémétrie industrielle standard : températures, pressions, débits, états du compresseur, codes de défaut, échantillonnés toutes les quelques secondes sur des dizaines de tags.

Une semaine de ces données, tokenisée sous forme de texte, atteint environ 5 à 30 fois la plus grande fenêtre de contexte disponible aujourd’hui sur le marché.

Pas un parc. Pas un site. Une machine. Une semaine.

Passons maintenant à l’échelle dont une exploitation industrielle a réellement besoin :

Un parc de 400 pompes à chaleur, et non une seule.
Une année d’historique, et non une semaine, parce que la plupart des comparaisons utiles (cet hiver contre l’hiver dernier, avant la rénovation contre après) l’exigent.
Plusieurs types de capteurs par équipement, et non une poignée de tags.

Multipliez ce dépassement par la taille du parc, par la profondeur d’historique, par le nombre de tags, et l’écart entre « les données brutes en entrée » et « la fenêtre de contexte disponible » cesse d’être une erreur d’arrondi. C’est la différence entre une démonstration et quelque chose qui tourne en production.

Pourquoi le contournement ne fonctionne pas davantage

Le correctif habituel consiste à rogner sur les données avant qu’elles n’atteignent le modèle :

Sous-échantillonner. Ne garder qu’un point sur cent. Le modèle ne voit alors plus le bref transitoire qui a réellement provoqué l’arrêt.
Résumer d’abord avec des statistiques. Fournir au modèle une moyenne, un maximum, un écart type. Il raisonne alors sur une description des données, et non sur les données.
Tronquer la fenêtre temporelle. Lui donner trois jours au lieu de trois mois. Il ne voit alors plus le motif saisonnier qui explique l’anomalie.
Échantillonner un sous-ensemble d’équipements. Analyser 40 pompes à chaleur au lieu de 400. La comparaison à l’échelle du parc, celle dont la question avait besoin, disparaît.

Chacune de ces options réduit le nombre de tokens. Chacune jette aussi exactement la résolution dont un opérateur a besoin pour faire confiance à la réponse. C’est le compromis que personne ne veut faire quand la question est « pourquoi la pompe B7 s’est-elle arrêtée mardi dernier », et que la réponse honnête exige d’examiner chaque seconde de données brutes autour de l’événement, et non une moyenne lissée de la semaine.

C’est aussi là qu’apparaît la manœuvre proscrite dans beaucoup d’outils du marché : transformer discrètement une question déterministe en question probabiliste, parce que le modèle raisonne sur un échantillon au lieu du signal complet. Spocky ne fait pas cela. Les réponses restent déterministes et explicables, recoupées avec l’historique réel, et non avec une estimation compressée de celui-ci.

Compute-down : envoyer le calcul vers la donnée

L’architecture de Spocky inverse la chaîne. Au lieu d’expédier des milliards de points bruts dans une fenêtre de contexte, elle envoie la logique de requête là où la donnée se trouve déjà.

L’agent ne demande pas à un LLM de garder en mémoire une semaine de signal brut. Il demande à un moteur de séries temporelles, construit au fil de 15 ans de R&D avec une bibliothèque de plus de 1 300 fonctions analytiques, de calculer la réponse sur l’historique complet, puis transmet le résultat, et non le flux brut, à la couche de raisonnement.

C’est la différence entre :

Ingest-up : données brutes, tokenisation, troncature ou sous-échantillonnage, le modèle raisonne sur un fragment.
Compute-down : question, le calcul s’exécute sur l’historique brut complet à la source, le modèle raisonne sur la réponse réelle.

Effet pratique : la latence et la consommation de tokens baissent jusqu’à 90 %, parce que le modèle ne porte plus le poids du signal entier, seulement le résultat de son interrogation. Une question qui déclenchait auparavant une chaîne d’emails de 11 jours entre trois équipes obtient une réponse déterministe et explicable en quelques secondes, recoupée automatiquement avec les journaux de maintenance. Cette boucle fait l’objet de son propre décryptage dans pourquoi l’enquête sur l’arrêt de votre pompe prend 11 jours.

Ce que cela donne sur un parc réel

Une équipe de détection de deux personnes qui supervise plus de 400 pompes à chaleur ne passe pas ses journées à lire des tableaux de bord. Elle est alertée dès qu’un motif d’anomalie apparaît, au lieu de le laisser enfoui dans des données brutes que personne n’a le temps d’interroger.

Cela ne fonctionne que parce que l’interrogation ne passe pas chaque fois par une fenêtre de contexte. Le calcul a lieu à la source, en continu, et l’agent fait remonter ce qui compte. Une visibilité du parc construite ainsi permet à l’équipe de détecter les problèmes avant qu’un client ait à les signaler, et non après.

C’est la même architecture qui permet à un opérateur de poser une question en anglais courant et d’obtenir une réponse sans attendre l’équipe data. Cela compte, parce que dans la plupart des organisations industrielles, 95 % des données brutes restent inexploitées simplement parce que seule l’équipe data sait comment les interroger. Un moteur compute-down associé à une couche en langage naturel supprime ce goulot d’étranglement sans ajouter d’exigence de formation, un thème traité plus en détail dans les programmes de maintenance prédictive IoT et la couche analytique manquante.

Où cela se place à côté de votre historian

Rien de tout cela ne remplace un historian, un lakehouse ou une infrastructure IIoT existante. Cela se place au-dessus.

L’historian stocke le signal brut. Le moteur de Spocky l’interroge au moment de la requête, à la profondeur qu’exige la question, sans nouveau projet de modélisation de données pour chaque nouvelle question. C’est une posture différente de celle des tableaux de bord, qui ne répondent qu’aux questions anticipées lors de leur construction. Voyez comment cela se traduit concrètement dans historiens de données industrielles contre agents de requête en langage naturel.

Les indicateurs, côte à côte

Une pompe à chaleur, une semaine de télémétrie brute : 5 à 30 fois la plus grande fenêtre de contexte de LLM disponible.
Architecture compute-down : jusqu’à 90 % de réduction de la latence et de la consommation de tokens par rapport à l’envoi des données brutes dans le modèle.
Une équipe de deux personnes, plus de 400 pompes à chaleur, une visibilité complète du parc.
Les enquêtes de type arrêt de pompe : d’une chaîne d’emails de 11 jours entre trois équipes à une réponse déterministe en quelques secondes.

Ce ne sont pas des abstractions tirées d’un manuel de statistiques. C’est ce qui arrive quand la question d’architecture (où s’exécute le calcul) est tranchée avant la question de l’IA.

Parlez à notre équipe

Si votre équipe a déjà heurté le mur de la fenêtre de contexte en tentant de greffer un LLM sur un historian, nous avons vu exactement ce mode d’échec. Parlez à notre équipe pour voir comment le compute-down fonctionne sur votre propre parc, ou lisez d’autres retours clients pour le voir en production.

FAQ

Quels sont de véritables exemples d’analyse de séries temporelles industrielles, et pas seulement des exemples statistiques ?

Un exemple concret : une pompe à chaleur qui génère une semaine de télémétrie brute (température, pression, débit, codes de défaut) produit un jeu de données 5 à 30 fois plus volumineux que la plus grande fenêtre de contexte de LLM disponible aujourd’hui. Portez cela à un parc de centaines d’équipements et à une année d’historique, et l’écart entre le volume de données brutes et ce qu’un modèle peut contenir croît d’autant. C’est l’exemple pratique, au niveau de l’architecture, que les contenus purement inspirés des manuels de statistiques sur les séries temporelles laissent généralement de côté.

Pourquoi ne peut-on pas simplement réinjecter des données de séries temporelles brutes dans un LLM pour l’analytique industrielle ?

Les fenêtres de contexte ne sont pas conçues pour contenir le volume que produit la télémétrie industrielle. Un équipement, une semaine, dépasse déjà de 5 à 30 fois la plus grande fenêtre de contexte du marché. Les contournements comme le sous-échantillonnage, le résumé statistique ou la troncature de la fenêtre temporelle écartent tous exactement la résolution nécessaire pour répondre à une question opérationnelle précise, par exemple pourquoi une pompe s’est arrêtée à un instant donné.

Qu’est-ce que l’architecture compute-down dans l’analytique industrielle ?

Le compute-down envoie la logique de requête là où les données brutes se trouvent déjà, calcule la réponse sur l’historique complet à la source, et ne transmet que le résultat à la couche de raisonnement. Cela évite d’expédier des milliards de points bruts dans une fenêtre de contexte, réduisant la latence et la consommation de tokens jusqu’à 90 % tout en gardant des réponses déterministes et explicables plutôt qu’échantillonnées ou approximatives.

Cela remplace-t-il notre historian ou notre plateforme IIoT existants ?

Non. Cela ajoute une couche d’intelligence orientée opérateur au-dessus de l’historian, du lakehouse ou de l’infrastructure IIoT déjà en place. Les données brutes restent où elles sont ; le moteur compute-down les interroge au moment de la requête au lieu d’exiger un nouveau projet data pour chaque nouvelle question.

Pourquoi réinjecter des données de séries temporelles dans un LLM échoue à l’échelle industrielle