Maintenance prédictive agente avec OpenVINO : un seul pipeline, cinq cas d’usage industriels.

Les pipelines, les équipements publics et autres actifs essentiels nécessitent une inspection constante afin d’éviter les pannes, les fuites et les incidents de sécurité. Une maintenance purement réactive ou basée sur un calendrier entraîne des déplacements répétés en camion, des signaux de défaut détectés trop tard, ainsi que des preuves dispersées lors d’une audit. L’IA agente offre une manière de surveiller en continu et d’intervenir plus tôt, ce qui permet de réduire le nombre de visites sur site, de diminuer le temps d’arrêt, d’améliorer la sécurité et de disposer d’un historique prêt pour une audit.

Cet article traite d’un projet du Google Summer of Code 2026 qui a repris le modèle de maintenance prédictive Intel Metro AI Suite, basé sur OpenVINO, et l’a étendu avec de nouveaux cas d’usage et des ensembles de données.

Le décalage entre une prédiction et une décision

Un modèle peut générer des milliers de prédictions, mais la personne qui les reçoit souhaite néanmoins trois réponses : ce qui s’est passé, pourquoi, et quoi examiner ensuite. Une étiquette accompagnée d’un score de confiance ne fournit pas ces informations. Un pipeline pratique doit conserver les preuves derrière chaque résultat, accepter différents types d’entrées, et permettre aux utilisateurs d’examiner les sorties sans comprendre le code sous-jacent.

Le projet visait précisément cela. Il associait l’inférence du modèle à un stockage structuré, coordonnait des agents d’intelligence artificielle, des questions en langage naturel et des tickets basés sur des preuves, tout cela au sein d’un seul flux de travail.

Comment le pipeline est mis en place

Le traitement commence par un modèle OpenVINO, dont les résultats sont enregistrés dans des fichiers JSONL ainsi qu’en base de données SQLite. Un flux de travail LangGraph coordonne ensuite trois agents : un pour la définition des politiques, un pour l’analyse et un pour les preuves. Les utilisateurs peuvent ensuite explorer les résultats via un chat ou soumettre une demande accompagnée des preuves correspondantes.

Quatre améliorations ont été apportées pour renforcer l’utilisabilité, l’explicabilité, l’extensibilité et le champ d’application. Il s’agit de correctifs distincts, mais tous s’inscrivent dans le même flux intégré du début à la fin.

Quatre contributions

Une case pour chaque type de question

Auparavant, l’utilisateur devait choisir entre le mode d’analyse, celui des preuves et le mode SQL avant de taper quoi que ce soit. Cela signifiait devoir connaître la répartition interne des fonctionnalités, ce qui est une exigence trop lourde pour un opérateur. La version remplacée détecte l’intention de l’utilisateur et envoie automatiquement la question au bon système backend, que ce soit depuis la ligne de commande ou l’interface web. Plus personne n’a besoin de sélectionner un mode.

Questions concernant les lectures brutes des capteurs

Le schéma SQLite configurable a été élargi afin de conserver les valeurs brutes des capteurs, le degré de fiabilité pour chaque modalité ainsi que les métadonnées relatives au cas d’usage. Cela permet de poser des questions telles que : quels échantillons présentaient un degré de fiabilité des capteurs plus élevé que celui des images ? La condition exprimée en langage naturel est transformée en une requête de base de données qui restitue les lectures, les étiquettes et les enregistrements sources correspondants. Ce même contexte est également transmis aux agents de politique et d’analyse. Ce qui importe, c’est la traçabilité, car les valeurs brutes et les métadonnées stockées relient chaque réponse aux enregistrements d’où elle provient.

Nouveaux modèles sans réconstruction

Le point d’entrée initial pour l’inférence gérait trop de tâches. Il a été divisé en éléments distincts : paramètres, routage, gestionnaires par modèle, étape d’exécution, enregistrement des résultats et visualisation. Un dispatcheur sélectionne désormais un gestionnaire compact et ciblé, tandis que des composants partagés s’occupent du comportement commun à chaque cas d’utilisation. Ajouter un nouveau type de données signifie désormais écrire un gestionnaire et une configuration, tout en réutilisant le reste du cycle de vie.

Cinq cas d’utilisation industriels sur une même plateforme

Les entrées, les cibles de prédiction et les preuves diffèrent selon les cinq cas, mais ils partagent la même infrastructure. Quatre types d’entrées sont pris en charge : des données tabulaires, des images, de l’audio accompagné de texte, et des données raster avec du texte.

Pipelines de pétrole et de gaz. Des données opérationnelles et matérielles sous forme tabulaire alimentent un MLP OpenVINO qui prédit simultanément deux éléments : l’état du pipeline et la perte d’épaisseur de sa paroi. Les données d’entrée comprennent des informations géométriques, le matériau utilisé, ainsi que des valeurs liées aux conditions d’exploitation et à la corrosion. Chaque enregistrement traité produit une classe d’état et une estimation de la perte d’épaisseur, lesquelles restent associées aux mesures originales. Ce lien permet aux outils ultérieurs d’interpréter les résultats en s’appuyant sur les données opérationnelles réelles, et le flux de travail inclut une analyse axée sur la corrosion.

Panneaux solaires. Un détecteur OpenVINO de type YOLO cherche les défauts dans des images d’électroluminescence à canal unique de cellules solaires et conserve les boîtes délimitantes en tant que preuves. Dans un échantillon, une boîte rouge marque une fissure réelle que le détecteur doit pouvoir identifier. Une évaluation menée sur l’ensemble des 19 150 images de test a donné un score F1 de 0,8277. La boîte prédite est enregistrée avec sa classe et son niveau de confiance, permettant ainsi à l’utilisateur de savoir où le défaut a été détecté.

Transmission d’énergie. Un modèle YOLOv8s-cls affiné classe les images de lignes de transmission en trois catégories de circuits. Il gère à la fois des images synthétiques et des photos issues d’inspections sur site, ce qui permet de vérifier si un même classificateur peut traiter à la fois des vues de circuits générées et des photographies prises sur le terrain. Sur 348 images de test, il a identifié correctement 334 d’entre elles, soit une précision de 0,9598. Les deux types d’images subissent un prétraitement et des calculs identiques.

Entretien de l’environnement opérationnel. Dans ce cas, une piste audio est associée à une sous-titre. Ces deux éléments sont prétraités séparément, classés par deux branches MLP d’OpenVINO puis combinés grâce à une fusion en phase tardive. Un échantillon concernant des machines tournantes était accompagné du sous-titre décrivant un outil électrique qui vibre pendant son fonctionnement. Une frame vidéo fournit du contexte au lecteur humain, mais l’entrée du modèle est l’audio de la piste ainsi que le texte. Les branches restent inspectables individuellement jusqu’à ce que leurs scores soient fusionnés.

Traitement de l’eau. Une zone raster de Sentinel-2 à 15 canaux est associée à une description textuelle relative à l’environnement, par exemple celle décrivant un comté en Arizona avec des données d’évapotranspiration, de précipitations, de profondeur des eaux souterraines et de profondeur des eaux de surface. Les caractéristiques statistiques issues du raster ainsi que les caractéristiques TF-IDF provenant du texte sont traitées par des branches OpenVINO distinctes avant une fusion finale, ce qui permet de préserver la fiabilité de chaque branche. Une vue préliminaire au format JPEG est générée afin que les utilisateurs puissent examiner l’échantillon, mais le modèle lui-même utilise le tableau NumPy multicanal original. Cette vue préliminaire peut également être jointe à une demande, fournissant ainsi des preuves visibles pour une prédiction multimodale.

Fonctionnement sur du matériel Intel

Chaque modèle a été déployé au format OpenVINO IR, et le point d’entrée configurable gère les images, les vecteurs de capteurs tabulaires, les caractéristiques audio ainsi que des entrées multimodales en paire. Le code a été validé sur une GPU Intel, et l’inference via le pipeline a également été confirmée sur une NPU Intel, y compris la génération des fichiers de sortie JSONL et SQLite.

Tester plus que la précision

La validation a dépassé le simple critère de précision du modèle. Chaque flux de travail a été testé, depuis le chargement du modèle et la génération d’une sortie structurée en passant par les agents, les interfaces, les preuves, les tickets jusqu’à l’exécution sur du matériel Intel. Les vérifications ont couvert à la fois les interfaces entre composants et les sorties des différents modèles.

Ce que montrent les démonstrations

Deux vues illustrent le fonctionnement du système. La première concerne l’orchestration backend : elle commence par les résultats des inférences dans la couche de données partagées. L’agent de politique les filtre en fonction de la politique configurée, tandis que l’agent d’analyse résume leur signification opérationnelle. Ensuite, l’agent de preuves regroupe chaque résultat avec ses données sources et métadonnées pour former un enregistrement traçable. Ensemble, ils transforment les sorties du modèle stockées en analyses structurées et en preuves prêtes à être examinées.

La seconde vue correspond au chat unifié : les utilisateurs consultent les résumés d’analyse, examinent les preuves et filtrent les résultats, ainsi que des données de maintenance structurées. Après investigation, ils peuvent créer une demande de maintenance pour un suivi ultérieur. Cela montre l’ensemble du processus, allant de l’examen des résultats à la soumission d’une demande.

Leçons tirées de la conception

Équilibrer la réutilisation et le comportement spécifique à chaque modalité était le problème de conception central. Les cinq cas partagent des composants de configuration, d’exécution, de stockage et d’agent, tandis que de petits traitements assurent le prétraitement et le posttraitement nécessaires à chaque type de données. La duplication est réduite sans avoir à faire passer des entrées très différentes par une logique identique.

Les résultats s’opposent également au stockage d’une simple étiquette. Lorsque des valeurs brutes de capteurs, des boîtes délimitantes, des niveaux de confiance par branche, des métadonnées et des aperçus sources accompagnent la prédiction, chaque résultat reste lié à des preuves que les humains et les agents peuvent examiner.

Pour les cas multimodaux, la fusion tardive permet de garder trace individuellement des branches audio, texte et raster. Le poids égal actuel est simple et reproductible, bien que des poids appris ou calibrés dynamiquement puissent mieux refléter le degré de fiabilité de chaque modalité.

La couche d’agents ne remplace pas les modèles prédictifs. Elle organise les résultats stockés, récupère les preuves nécessaires et dirige une question vers l’analyse ou l’opération de base de données appropriée. La validation concerne les ensembles de données évalués ainsi que le matériel Intel, et les déploiements réels nécessiteraient encore des tests, un suivi et une calibration spécifiques au site.

De prototype à plan détaillé

Ce qui a commencé comme un pipeline conçu pour un seul cas d’usage est devenu plus modulaire, multimodal et orienté utilisateur. OpenVINO fournit la couche d’inférence commune, tandis que le stockage structuré associé à des agents coordonnés transforme les résultats du modèle en informations que l’utilisateur peut examiner et exploiter. La même chaîne, allant des données industrielles, en passant par l’inférence et les preuves, jusqu’à l’exploration en langage naturel et la création de tickets, est désormais réutilisée dans plusieurs domaines de maintenance.