LMAI® : logiciel maintenance assistée IA pour l’énergie

DSI, directeur de production : accepteriez-vous de maintenir une turbine en service si personne ne peut expliquer pourquoi son alarme revient depuis la dernière perturbation du poste électrique ?

La décision engage votre responsabilité. Derrière cette alarme peuvent se trouver un phénomène transitoire, une mesure défectueuse ou une dégradation réelle ; pourtant, l'exploitation doit choisir entre poursuivre, renforcer la surveillance et préparer un arrêt.

C’est précisément là que le logiciel maintenance assistée IA, ou LMAI®, prend son sens : rapprocher les informations utiles pour éclairer une décision technique, sans retirer aux équipes leur autorité sur l’installation.

LMAI® : comprendre avant de recommander

J’emploie ici LMAI® pour désigner le concept de logiciel de maintenance assistée par intelligence artificielle. Ce nom ne constitue pas une norme technique universelle et ne garantit, à lui seul, aucune capacité prédictive.

L’enjeu est concret. Sur un site de production d’énergie, ce type de système peut aider à relier les alarmes d’une turbine, ses conditions de fonctionnement, les interventions antérieures et les événements du poste HTB, c’est-à-dire haute tension B, par lequel transite l’électricité produite.

Sa fonction dépasse la consultation documentaire. Il doit aider à formuler des hypothèses explicites, à repérer les informations manquantes et à proposer les vérifications susceptibles de départager plusieurs explications.

Prenons une vibration inhabituelle après une variation de charge : le logiciel ne devrait pas conclure immédiatement à un défaut mécanique, mais examiner si le changement de régime explique le signal et si d’autres mesures corroborent cette lecture.

Une recommandation doit pouvoir être discutée. Le technicien a besoin de savoir quelle mesure vérifier ; le directeur doit comprendre ce qui justifie une surveillance renforcée plutôt qu’un arrêt immédiat.

Dans l’approche que je porte avec TENGENN LMAI®, l’intelligence artificielle est donc un appui au raisonnement de maintenance, pas une autorité autonome qui décide de la disponibilité d’une turbine.

Le vrai point de blocage : décider avec des informations séparées

L’alarme n’est pas toujours le problème principal. C’est souvent l’impossibilité de reconstituer rapidement ce qui l’a précédée, dans quelles conditions elle apparaît et ce qui a déjà été vérifié.

L’exploitation possède sa chronologie. La maintenance dispose des comptes rendus, tandis que les enregistrements électriques et les tendances de vibration peuvent être accessibles dans des outils distincts, avec des horodatages qui ne coïncident pas nécessairement.

Le raisonnement se fragmente alors. Une équipe cherche une cause mécanique ; une autre attribue l’événement au réseau, sans que les éléments disponibles permettent réellement de trancher.

Commencer par rendre les événements comparables

Avant toute analyse assistée, il faut vérifier l’identité des équipements, les unités de mesure, la synchronisation des horloges et la qualité des comptes rendus. Une proximité temporelle entre deux événements ne démontre pas leur lien causal.

Ce préalable n’a rien d’accessoire. Un décalage d’horloge peut inverser la séquence apparente et orienter toute l’investigation dans une mauvaise direction.

Pour certaines entreprises africaines de l’énergie, la connectivité entre le site et le siège constitue aussi un paramètre de conception. Si elle est intermittente, les informations nécessaires à la conduite et aux vérifications locales doivent rester accessibles sur place, selon une architecture adaptée.

Les situations diffèrent selon les réseaux, les contrats d’exploitation et les moyens disponibles. Le bon point de départ reste donc une décision précise à améliorer, plutôt qu’une collecte générale de données.

Pourquoi une GMAO seule ne suffit pas

La GMAO, gestion de maintenance assistée par ordinateur, reste un socle utile : elle structure les équipements, planifie les interventions et conserve l’historique des travaux.

Elle apporte de l’ordre. Mais enregistrer qu’un contrôle vibratoire a été effectué ne suffit pas à expliquer pourquoi une alarme réapparaît après certains changements de charge.

Une GMAO centrée sur les ordres de travail ne rapproche pas nécessairement les tendances de fonctionnement, les événements électriques et les observations des techniciens. Des produits proposent déjà certaines fonctions analytiques ; la distinction porte donc sur les capacités réelles, pas seulement sur l’étiquette commerciale.

Le LMAI® ajoute une couche d’analyse destinée à diagnostiquer, anticiper et aider à décider. Il peut rechercher des épisodes comparables, confronter une hypothèse à l’historique disponible et signaler qu’une conclusion manque de preuves.

L’anticipation reste conditionnelle. Repérer une dérive demande des mesures fiables et comparables, tandis qu’estimer une échéance de défaillance exige une validation autrement plus exigeante.

L’objectif n’est pas de remplacer systématiquement l’existant. La comparaison GMAO vs LMAI® permet surtout de distinguer l’organisation des interventions du soutien au raisonnement technique.

Un historique mal renseigné ne devient pas fiable parce qu’une IA le lit. Il faut d’abord améliorer la manière dont les observations sont produites et qualifiées.

Cas hypothétique : une turbine, une alarme, deux lectures

Considérons un cas entièrement hypothétique : un site de production électrique raccordé par un poste HTB constate des alarmes vibratoires intermittentes sur une turbine après certaines variations de puissance.

La turbine reste disponible. L’équipe hésite néanmoins à maintenir le régime demandé, car elle ne sait pas encore si les alarmes traduisent un comportement transitoire connu ou une évolution mécanique préoccupante.

Reconstituer avant d’interpréter

Voici la méthode que j’appliquerais : sélectionner quelques épisodes documentés, aligner leurs chronologies et comparer les vibrations avec la vitesse, la charge et les événements électriques pertinents.

Les périodes normales comptent aussi. Comparer uniquement des alarmes entre elles ferait perdre le contexte nécessaire pour comprendre ce qui distingue réellement un épisode anormal.

L’analyse assistée pourrait révéler que le signal apparaît principalement pendant certaines transitions de charge. Ce serait une piste de vérification, pas la preuve que le poste HTB ou le réseau en est la cause.

Un contrôle ciblé suivrait. Selon les éléments recueillis, l’équipe pourrait vérifier la chaîne de mesure ou approfondir l’examen mécanique, en respectant les prescriptions du constructeur et les règles de sécurité du site.

Préparer une décision défendable

Le résultat attendu serait une note courte : faits établis, hypothèses encore ouvertes, vérification prioritaire et conditions nécessitant une escalade vers les responsables habilités.

Aucun seuil ne serait improvisé. Les limites de fonctionnement et les critères d’arrêt doivent venir des référentiels applicables à l’équipement, non d’une réponse générée par le logiciel.

Si une intervention exige une pièce dont l’approvisionnement est long, cette contrainte peut orienter sa préparation. Elle ne justifie jamais de poursuivre l’exploitation au-delà des limites autorisées.

Cybersécurité : connecter l’analyse sans ouvrir la conduite

Un assistant de maintenance n’a pas à disposer des mêmes droits qu’un système de commande. L’accès aux données doit être conçu pour éviter qu’une fonction d’analyse devienne un chemin vers les équipements critiques.

La séparation est essentielle. Pour ce cas, je privilégierais l’étude d’un accès en lecture aux données nécessaires, via des interfaces contrôlées, sans capacité de modifier les consignes de la turbine ou les protections du poste.

Cela ne règle pas tout. Il faut également examiner les comptes utilisateurs, la traçabilité des accès, les mises à jour et les échanges éventuels avec un service distant.

Ce que NIS2 implique réellement

NIS2 est la directive européenne relative à un niveau élevé commun de cybersécurité, qui couvre notamment certaines entités de l’énergie selon son champ d’application et les textes nationaux de transposition.

Elle n’est pas automatiquement applicable à tout site africain. L’analyse dépend de l’entité concernée, de ses activités et de ses implantations ; des exigences contractuelles peuvent aussi découler de relations avec des acteurs européens, sans équivaloir à un assujettissement direct.

Installer un logiciel ne rend pas conforme. La gestion des risques, la continuité d’activité et le traitement des incidents relèvent d’une organisation plus large, à examiner avec les responsables cybersécurité et juridiques.

La supervision temps réel peut alimenter l’analyse, mais ses données doivent franchir des interfaces maîtrisées. Si l’assistant devient indisponible, la conduite sûre du site doit rester possible.

Mon approche : un périmètre restreint, des preuves vérifiables

Mes sept années d’expérience dans différents environnements industriels nourrissent une conviction : la valeur d’un outil se mesure à la qualité de la décision qu’il aide à prendre, pas au nombre de données qu’il affiche.

Je commencerais modestement. Une famille d’alarmes sur une turbine offre un périmètre plus instructif qu’un déploiement immédiat sur tout le site, surtout lorsque les historiques restent hétérogènes.

Je propose d’abord un diagnostic du cheminement de l’information, depuis l’apparition de l’alarme jusqu’à la décision de maintenance. Ce travail permet d’identifier les vérifications manquantes et les responsabilités à clarifier avant de choisir une architecture logicielle.

Vient ensuite l’analyse des données disponibles. Je peux accompagner la construction d’un pilote avec notre solution TENGENN LMAI®, en définissant avec vos équipes les fonctions à intégrer, les droits d’accès et les critères d’acceptation.

Le test doit rester contradictoire. Sur des épisodes historiques réservés à l’évaluation, les équipes doivent pouvoir relever une hypothèse infondée, une alerte inutile ou une recommandation impossible à appliquer.

Je regarderais notamment si les faits sont mieux reconstitués et si les propositions sont suffisamment étayées pour guider une vérification. Une réponse convaincante à la lecture, mais techniquement fausse, constitue un échec.

La technologie doit s’adapter à cette exigence. Elle ne doit pas obliger les équipes à contourner leurs procédures pour faire fonctionner une démonstration.

Questions fréquentes

Le LMAI® remplace-t-il les spécialistes de la turbine ?

Non. Il peut rapprocher des informations et suggérer des pistes, mais l’interprétation technique, les prescriptions du constructeur et la validation des responsables habilités restent déterminantes.

Faut-il installer davantage de capteurs ?

Pas nécessairement. L’examen des données existantes peut montrer qu’un meilleur horodatage ou des comptes rendus plus précis sont prioritaires ; un nouveau capteur se justifie lorsqu’il répond à une incertitude identifiée.

Peut-on travailler sans transmettre les données hors du site ?

Cette contrainte doit être étudiée dès la conception. Un traitement local ou une architecture hybride peuvent être envisagés selon les fonctions recherchées, les ressources disponibles et les exigences de sécurité, sans supposer que toutes les configurations sont équivalentes.

Le concept LMAI® devient utile lorsqu’il aide à passer d’une alarme isolée à une décision argumentée. Ni la quantité de capteurs ni la fluidité d’une réponse ne remplacent cette exigence.

Vous devez décider du maintien en service d’une turbine sans parvenir à relier ses alarmes aux événements du poste HTB ? Contactez-moi directement sur mon profil LinkedIn, Eries Emmanuel Dianou : je vous propose d’examiner les informations disponibles pour définir un premier périmètre d’analyse adapté à votre site.