LMAI® : comprendre la maintenance IA dans le ferroviaire

Multiplier les interventions sur une rame ne garantit pas une meilleure disponibilité. Lorsque le même défaut revient après plusieurs passages en atelier, une maintenance très active peut même masquer une compréhension insuffisante de sa cause.

Tout paraît pourtant correctement suivi. Les ordres de travail sont clôturés, les contrôles renseignés et les pièces remplacées figurent dans l'historique ; malgré cela, l'exploitation retrouve un signalement déjà connu.

C'est cette récurrence mal comprise qui permet d'expliquer concrètement le LMAI®, ou logiciel de maintenance assistée par intelligence artificielle. Dans le ferroviaire, son intérêt n'est pas de produire davantage de comptes rendus, mais d'aider les équipes à relier ce qu'elles savent déjà pour mieux orienter leurs investigations.

Le LMAI® ne remplace pas le jugement ferroviaire

Le concept repose sur une distinction simple. Un logiciel peut conserver la mémoire des travaux sans être capable d'aider un technicien à comprendre pourquoi un défaut persiste malgré ces travaux.

La gestion de maintenance assistée par ordinateur, ou GMAO, structure les équipements, les échéances, les stocks et les interventions. Elle constitue un socle précieux pour retrouver le dossier d'un véhicule et préparer son entretien.

Le LMAI® ajoute une couche d'analyse. Il vise à rapprocher les observations d'atelier, les mesures disponibles et la documentation applicable afin de proposer des pistes de diagnostic, de repérer des récurrences et d'éclairer les arbitrages.

Cette assistance a une limite nette : elle ne constitue pas une autorisation de remise en service. Les décisions touchant à la sécurité restent soumises aux procédures, aux responsabilités et aux validations prévues par l'organisation ferroviaire et son cadre réglementaire.

Une recommandation doit donc être vérifiable. Elle devrait permettre de retrouver les éléments utilisés, de distinguer un fait d'une hypothèse et de comprendre pourquoi un contrôle complémentaire est suggéré.

Sans cela, l'outil ajoute une opinion. Il n'améliore pas nécessairement la décision.

Un défaut récurrent de porte, plusieurs récits incomplets

Prenons un cas strictement hypothétique : un exploitant ferroviaire constate des signalements intermittents de fermeture sur une porte de son matériel roulant. Le défaut provoque des vérifications répétées et, selon les règles applicables et les possibilités d'exploitation, peut conduire à une restriction ou à une immobilisation.

En atelier, le symptôme disparaît parfois. Un premier compte rendu mentionne un réglage, un autre décrit un contrôle de connexion, puis une intervention ultérieure conclut à un essai satisfaisant sans préciser les conditions de reproduction.

Chaque fiche peut être exacte. Leur lecture séparée ne permet pourtant pas de déterminer si les équipes traitent une seule défaillance persistante ou plusieurs événements différents.

Le directeur voit une disponibilité instable. Le technicien, lui, doit comprendre ce qui a réellement été vérifié avant son intervention, avec quelle méthode et sur quelle configuration du véhicule.

L'enjeu n'est pas d'accuser la saisie. Il consiste à reconstituer une histoire technique assez précise pour éviter de recommencer indéfiniment les mêmes recherches.

Dans cette situation, remplacer encore un composant sans mieux caractériser le symptôme peut consommer une pièce disponible sans lever l'incertitude. Une analyse utile commence donc par la qualité des rapprochements, non par la sophistication de l'algorithme.

De la fiche d'intervention à une hypothèse explicable

Un LMAI® ne transforme pas automatiquement un historique en vérité technique. Sa pertinence dépend de la structure des données, de leur qualité et des fonctions réellement mises en œuvre.

Reconnaître le même équipement

Il faut d'abord identifier sans ambiguïté le véhicule, la porte concernée et les composants suivis. Une désignation libre comme « porte côté quai » peut devenir difficile à exploiter lorsque plusieurs équipes utilisent des conventions différentes.

Le référentiel doit rester praticable. Une codification trop complexe risque de produire des erreurs que l'analyse automatisée prendra ensuite pour des faits.

Rapprocher sans confondre

L'intelligence artificielle peut aider à reconnaître des formulations voisines dans les rapports. Elle doit néanmoins préserver la différence entre un défaut de fermeture constaté, une information de fermeture absente et un événement impossible à reproduire.

Ces nuances orientent les contrôles. Les effacer sous une catégorie unique donnerait un historique plus propre en apparence, mais moins utile à l'atelier.

Une analyse peut alors rapprocher les événements d'un même organe, les actions effectuées et les résultats des essais. Elle peut aussi signaler qu'une donnée manque avant de proposer une interprétation.

Proposer une investigation, pas une certitude

Dans notre exemple, le système pourrait suggérer de comparer les conditions d'apparition et de vérifier la continuité d'un circuit selon la procédure applicable. Cette suggestion resterait une hypothèse à instruire, pas une cause démontrée.

Le résultat doit être sourcé. Le technicien doit pouvoir retrouver les interventions concernées et vérifier la pertinence de la documentation proposée pour la configuration du matériel.

C'est aussi la frontière avec la signalisation : un outil d'aide à la maintenance n'est pas, par nature, un système de sécurité autorisé à commander ou à valider une fonction ferroviaire. Aucun rapprochement statistique ne suffit à franchir cette frontière.

Pourquoi la GMAO seule atteint ses limites

La GMAO répond d'abord à une exigence d'organisation. Elle permet notamment de savoir quelle intervention était prévue, qui l'a exécutée et quelles ressources ont été engagées.

Certaines solutions possèdent déjà des fonctions analytiques avancées. Il serait donc trompeur d'opposer systématiquement une GMAO supposée passive à un LMAI® présenté comme intelligent par définition.

La différence utile porte sur le travail effectivement réalisé. L'outil aide-t-il à relier les récidives, à formuler des investigations justifiées et à retrouver les preuves nécessaires, ou laisse-t-il toute cette reconstruction à la personne qui consulte les dossiers ?

C'est le sens de la comparaison GMAO vs LMAI®. L'une organise et enregistre ; l'approche LMAI® cherche à exploiter cette mémoire pour diagnostiquer, anticiper et décider, sans supprimer le socle de gestion.

Anticiper ne signifie pas forcément prédire une date de panne. Sur une flotte dont les mesures sont limitées, cela peut simplement consister à détecter une répétition inhabituelle et à préparer une investigation avant la prochaine immobilisation imprévue.

La prudence reste nécessaire. Des historiques peu nombreux ou des conditions d'utilisation différentes ne permettent pas de conclure qu'un défaut observé sur une rame apparaîtra sur toutes les autres.

Commencer par l'atelier, avec les contraintes du réseau

Pour un opérateur ferroviaire africain, le déploiement doit partir de ses conditions réelles. Un atelier central disposant d'une connexion stable et un dépôt distant dont les échanges sont intermittents ne peuvent pas dépendre exactement du même fonctionnement numérique.

Le terrain fixe les exigences. Si la connectivité est irrégulière, il faut examiner la saisie locale, la synchronisation et l'accès à la documentation autorisée avant de rendre un service distant indispensable.

La disponibilité des pièces influe également sur l'investigation. Lorsqu'un composant de remplacement doit être approvisionné avec un délai important, une recommandation insuffisamment étayée peut désorganiser la préparation des travaux.

Elle ne justifie jamais un raccourci de sécurité. L'objectif est de mieux préparer la décision, pas d'assouplir les critères de conformité sous la pression de l'exploitation.

La méthode que j'appliquerais

Je commencerais par reconstruire quelques épisodes du même défaut, depuis le signalement jusqu'aux essais et à la décision finale. Cette lecture permettrait d'identifier les informations manquantes et les divergences de vocabulaire qui empêchent les rapprochements.

Ensuite viendrait un périmètre pilote restreint. Une famille d'organes et un atelier suffisent pour vérifier si l'assistance retrouve les bons antécédents et produit des propositions compréhensibles par les mainteneurs.

L'évaluation porterait sur des éléments observables : pertinence des dossiers retrouvés, recommandations rejetées, qualité de la justification et réapparition du symptôme après intervention. Aucun gain de disponibilité ne devrait être attribué au logiciel sans comparaison adaptée au contexte d'exploitation.

La traçabilité doit couvrir aussi l'assistance. Il faut pouvoir distinguer la proposition du logiciel, l'analyse humaine, l'action exécutée et la validation prononcée selon les responsabilités prévues.

Ma démarche avec TENGENN LMAI®

Mes sept années d'expérience dans différents environnements industriels m'ont conduit à une conviction : un logiciel ne doit pas demander aux équipes de compenser les faiblesses du processus. Je ne présente pas cette expérience comme la preuve d'une mission ferroviaire particulière ; elle nourrit la méthode que je propose pour analyser un besoin avec ses responsables métier.

La priorité est de rendre le raisonnement partageable. Dans notre cas de porte récurrente, une personne qui reprend le dossier doit comprendre ce qui est établi, ce qui reste incertain et ce qui justifie le prochain contrôle.

Je porte la solution TENGENN LMAI® dans cette logique d'assistance à la maintenance intégrant l'IA. Son adéquation à un réseau ferroviaire doit être évaluée à partir des données disponibles, des interfaces nécessaires et des exigences de sécurité et de traçabilité, sans présumer qu'une fonction générique suffit.

Je propose d'abord un diagnostic ciblé du parcours de ce défaut récurrent. Je peux ensuite accompagner la structuration de l'historique et la définition d'un pilote d'aide au diagnostic, avec des critères d'acceptation convenus avec l'atelier et les responsables de maintenance.

L'automatisation vient après ces arbitrages. Si les données ne permettent pas une recommandation fiable, la réponse utile consiste à préciser ce qu'il faut observer, pas à fabriquer une certitude.

Questions fréquentes

Faut-il remplacer la GMAO pour utiliser un LMAI® ?

Pas nécessairement. Une approche LMAI® peut compléter la GMAO existante si l'accès aux données, la correspondance entre équipements et la traçabilité des échanges sont correctement définis.

Le choix dépend de l'existant. Une évaluation des interfaces doit précéder toute promesse d'intégration.

Peut-on commencer sans capteurs supplémentaires ?

Oui, pour certains usages. L'analyse de rapports et d'historiques peut déjà aider à retrouver des récurrences, sous réserve que les informations soient suffisamment précises et comparables.

Cela ne remplace pas une mesure absente. Si l'hypothèse exige une observation particulière, celle-ci doit être obtenue avec une méthode appropriée.

L'IA peut-elle valider la remise en service d'une rame ?

Une assistance générique ne le permet pas. La remise en service reste encadrée par les procédures applicables, les contrôles requis et les personnes habilitées ; une recommandation logicielle ne remplace aucune de ces obligations.

Le bénéfice recherché est ailleurs : mieux préparer le travail et rendre son raisonnement vérifiable. C'est ainsi que l'analyse peut soutenir la disponibilité sans brouiller les responsabilités de sécurité.

Vous retrouvez le même défaut dans plusieurs fiches sans parvenir à relier les interventions ? Contactez-moi directement sur mon profil LinkedIn, Eries Emmanuel Dianou, pour examiner comment cadrer un diagnostic de cette récurrence et déterminer si une assistance LMAI® serait pertinente pour votre atelier.