Maintenance prédictive IA : sécuriser les décisions énergie

DSI, directeur de production : accepteriez-vous de reporter l’arrêt d’une turbine sur la seule recommandation d’une IA dont personne ne peut vérifier les données ?

La question engage davantage qu’un budget logiciel. Sur un site de production d’énergie, une mauvaise recommandation peut prolonger le fonctionnement d’un équipement dégradé ; une connexion mal maîtrisée peut, elle, introduire un risque dans les systèmes qui assurent sa conduite.

Il faut tenir les deux exigences. Ce guide traite donc d’un problème précis : anticiper une dégradation de palier de turbine à partir de données fiables, sans fragiliser les automatismes ni déléguer aveuglément la décision d’arrêt.

1. Une alerte utile doit pouvoir être discutée

Une hausse de vibration ne suffit pas à annoncer une panne. Selon la charge, la vitesse, la température ou une phase transitoire de fonctionnement, un même indicateur peut avoir des significations différentes.

Le contexte fait la différence. Avant de choisir un modèle de maintenance prédictive IA, le directeur des systèmes d’information, ou DSI, doit donc faire préciser la décision attendue : déclencher une mesure complémentaire, préparer une inspection ou proposer une fenêtre d’intervention.

Le responsable de la sécurité des systèmes d’information, ou RSSI, pose une autre condition : cette capacité d’analyse ne doit pas créer un chemin d’accès incontrôlé vers la conduite. Ces deux préoccupations se rejoignent lorsqu’une alerte devient traçable, explicable et utilisable par l’exploitation.

Le technicien doit pouvoir la contester. Il lui faut retrouver la mesure d’origine, son horodatage, l’état de fonctionnement de la turbine et les éléments qui ont motivé la recommandation, plutôt qu’un simple score rouge sur un écran.

La première livraison n’est donc pas un algorithme : c’est une règle de décision partagée. Qui examine l’alerte, avec quelles preuves, dans quel délai et avec quelle autorité sur l’équipement ?

2. Vérifier ce que les données permettent vraiment

Repartir du palier et de ses mesures

Le travail commence sur l’actif retenu. Pour un palier de turbine, l’analyse doit relier les mesures vibratoires pertinentes aux températures, à la lubrification et au régime de fonctionnement, en tenant compte des prescriptions du constructeur.

Tous les historiques ne conviennent pas. Une moyenne enregistrée à intervalles espacés peut montrer une dérive globale, mais masquer les signatures fréquentielles nécessaires à certains diagnostics ; il faut alors examiner la chaîne d’acquisition avant de parler d’intelligence artificielle.

Je propose de commencer par un diagnostic de fiabilité des données. Il confronte les signaux disponibles aux événements de maintenance industrielle, puis vérifie si les interventions et les changements de capteur permettent d’interpréter correctement l’historique.

Un remplacement doit laisser une trace. Sans cela, une rupture de tendance liée à l’instrumentation risque d’être interprétée comme une évolution mécanique, avec une recommandation inadaptée à la clé.

Tenir compte du fonctionnement réel du site

Les sites énergétiques africains n’ont pas tous les mêmes contraintes. Une centrale disposant d’une équipe d’instrumentation permanente et d’une liaison fiable n’organisera pas son analyse comme un site éloigné, dont les échanges de données sont intermittents.

Le service doit rester utile localement. Si la connectivité est irrégulière, je privilégierais une architecture capable de conserver les données sur place et de différer leur transfert, sans rendre la surveillance essentielle dépendante d’un accès distant.

La disponibilité des pièces compte également. Une alerte précoce n’aide réellement l’exploitation que si son traitement intègre le délai du composant concerné, les compétences mobilisables et les fenêtres d’indisponibilité acceptables pour le réseau.

3. Séparer l’analyse prédictive de la conduite

Une architecture lisible pour le RSSI

Le modèle ne doit pas devenir un nouvel organe de protection. Les protections existantes et les automatismes conservent leurs fonctions, indépendamment de la disponibilité du service d’analyse.

Cette séparation doit être démontrable. Les systèmes de technologie opérationnelle, dits OT, pilotent les équipements physiques ; leurs échanges avec les systèmes informatiques de gestion doivent être limités aux flux nécessaires et validés par les responsables concernés.

Une architecture envisageable consiste à extraire les mesures depuis un historien industriel vers une zone intermédiaire cloisonnée. L’analyse y accède à une copie, sans connexion directe de son environnement aux contrôleurs de la turbine.

Le détail dépend du site. Une passerelle unidirectionnelle peut être pertinente dans certains contextes, mais son choix doit tenir compte des protocoles, des besoins d’exploitation et des contraintes de maintenance, pas seulement d’un schéma de principe.

Encadrer les accès et les changements

Un flux annoncé « en lecture seule » ne suffit pas. Il faut vérifier les droits effectifs, les règles réseau et les possibilités d’administration de chaque composant traversé, y compris pendant le support technique.

Les accès distants méritent une attention particulière. Pour un prestataire intervenant sur l’analyse, l’autorisation devrait être nominative, limitée dans le temps, authentifiée de manière renforcée et journalisée selon la politique de sécurité du site.

Le modèle lui-même doit être versionné. Une nouvelle version, un changement de seuil ou une modification de préparation des données peut déplacer les alertes ; ces changements appellent une validation et une possibilité de retour arrière.

La supervision temps réel aide à rendre ces états visibles. Encore faut-il distinguer clairement une anomalie mécanique, une mesure absente et une indisponibilité du service analytique, car elles n’appellent pas la même réponse.

4. NIS2 : cadrer les obligations sans promettre une conformité automatique

NIS2 désigne la deuxième directive européenne sur la sécurité des réseaux et des systèmes d’information. Elle prévoit, pour les entités concernées, des obligations de gestion des risques cyber, de gouvernance et de notification d’incidents, selon les règles applicables et leur transposition nationale.

Elle ne s’applique pas automatiquement à tout énergéticien africain. L’analyse doit porter sur l’entité, ses activités, ses implantations et le cadre juridique pertinent, avec l’appui des fonctions juridiques ou conformité.

Des exigences peuvent aussi arriver par contrat. Un groupe présent dans plusieurs pays ou un partenaire européen peut demander des garanties de sécurité à un exploitant ou à un fournisseur, sans que cela signifie que toute son activité relève directement de NIS2.

Un logiciel ne règle pas cette question. Pour le projet prédictif, le DSI et le RSSI doivent surtout pouvoir montrer comment sont maîtrisés les accès, les fournisseurs, les changements et la continuité du service.

La preuve doit être exploitable. Un dossier regroupant les flux autorisés, les responsabilités, les procédures de reprise et les résultats des tests sera plus utile qu’une mention « compatible NIS2 » dépourvue de périmètre vérifiable.

5. Cas hypothétique : une turbine et son poste HTB

Prenons un cas entièrement hypothétique. Un site de production d’électricité situé en Afrique de l’Ouest exploite une turbine raccordée au réseau par un poste à haute tension B, ou HTB, avec une équipe locale et un support spécialisé à distance.

Une vibration de palier dérive progressivement. L’équipe dispose de tendances, mais les variations de charge rendent leur interprétation délicate ; une intervention imposerait de coordonner l’indisponibilité du groupe avec l’exploitation du réseau.

Voici la méthode que j’appliquerais. Je ferais d’abord vérifier l’instrumentation, puis comparer les mesures dans des régimes de fonctionnement similaires, avant de rechercher une cohérence avec les températures et les observations de maintenance.

L’analyse resterait isolée de la conduite. Les mesures seraient copiées vers un environnement autorisé, sans permettre au modèle de modifier les consignes de turbine ou les réglages des protections du poste HTB.

Tester avant d’utiliser pour arbitrer

Le pilote fonctionnerait d’abord en observation. Ses alertes seraient confrontées aux contrôles de l’équipe, sans commander d’action et sans remplacer les règles existantes, afin d’identifier les fausses alertes et les situations insuffisamment couvertes.

Les critères seraient fixés avant l’essai. Ils porteraient notamment sur la disponibilité des données, la pertinence des alertes, leur délai utile et la charge de vérification imposée aux techniciens.

Aucun gain ne peut être annoncé ici. Sans historique qualifié ni validation sur ce site hypothétique, promettre une date de défaillance ou une réduction chiffrée des arrêts relèverait de la spéculation.

Une dérive confirmée pourrait justifier une inspection planifiée. À l’inverse, une mesure douteuse devrait conduire à contrôler l’acquisition, et non à transformer une incertitude instrumentale en diagnostic de palier.

6. De la GMAO à une décision mieux étayée

La gestion de maintenance assistée par ordinateur, ou GMAO, organise les interventions, conserve les comptes rendus et suit les ressources. Elle reste essentielle pour rattacher une alerte au travail réellement effectué sur la turbine.

Mais elle ne suffit généralement pas seule. Enregistrer une température et clôturer un ordre de travail ne permet pas nécessairement de rapprocher les régimes de charge, les signaux vibratoires et l’historique mécanique pour anticiper une dégradation.

Le LMAI® apporte une couche d’analyse destinée à aider au diagnostic, à l’anticipation et à la décision. La distinction GMAO vs LMAI® porte donc sur des fonctions complémentaires, pas sur l’abandon de la traçabilité des interventions.

Je porte TENGENN LMAI® dans cette perspective. Pour le cas étudié, je propose de cadrer son usage autour de la mise en relation des données et des observations, avec des recommandations soumises à validation humaine ; les fonctions et interfaces nécessaires doivent être vérifiées avant tout déploiement.

Mon point de départ reste le terrain. Avec environ sept années d’expérience dans différents environnements industriels, je considère qu’une recommandation vaut surtout par la capacité de l’équipe à en comprendre les raisons et les limites.

Je peux accompagner trois étapes liées : qualifier les données du palier, cadrer les flux avec le DSI et le RSSI, puis définir un pilote avec l’exploitation. L’objectif est de vérifier qu’une alerte aide réellement à préparer une intervention, sans déplacer le risque vers les automatismes.

Questions fréquentes

Faut-il disposer de plusieurs années de pannes enregistrées ?

Pas nécessairement pour détecter une anomalie. Un modèle peut apprendre certains comportements habituels sans disposer de nombreux défauts documentés, mais cela ne lui donne pas automatiquement la capacité d’identifier leur cause ou de prédire une durée de vie restante.

Peut-on conserver les données sur le site énergétique ?

Oui, si l’architecture retenue le permet. Il faut alors vérifier les ressources locales, les sauvegardes et les modalités de support, puis tester le comportement du dispositif lors d’une perte de liaison ou d’un redémarrage.

Qui décide après une alerte prédictive ?

La responsabilité doit rester explicitement attribuée. L’exploitation et la maintenance arbitrent selon les procédures du site, avec les expertises nécessaires ; le modèle apporte des éléments, tandis que le DSI et le RSSI encadrent la fiabilité et la sécurité du dispositif numérique.

Commencez par une turbine, une décision et des preuves vérifiables. Si vous préparez un projet de maintenance prédictive IA sur un site énergétique, contactez-moi directement via mon profil LinkedIn, Eries Emmanuel Dianou : nous pourrons examiner ensemble si vos données permettent d’anticiper une dégradation de palier sans ouvrir de risque supplémentaire pour la conduite.