Diagnostic de pannes par IA pour ponts roulants

Imaginons une nuit d'hiver : dans la salle de garde d'un pont roulant d'une aciérie, l'assistant IA émet une alerte — « L'usure des garnitures de friction du frein du levage principal a atteint la limite de mise au rebut, remplacement immédiat recommandé » — et cite une « norme » qui stipulerait que l'épaisseur résiduelle des garnitures ne doit pas être inférieure à 40 % de l'épaisseur d'origine. L'opérateur suit la consigne, arrête la machine et démonte le frein dans la nuit. Constat : l'épaisseur des garnitures est encore de 62 %, très loin du seuil de mise au rebut. La ligne de production est restée à l'arrêt six heures pour rien.

Le premier réflexe de l'opérateur est de suspecter un capteur défectueux. Il consulte les courbes historiques de vibration et de température : tout est normal. Il vérifie ensuite la « norme » citée : en parcourant les spécifications de conception et les normes de surveillance de sécurité applicables, il ne trouve aucune trace de la clause invoquée par l'IA — celle-ci a cité une disposition inexistante, tout en lui donnant une apparence crédible avec un numéro de norme, des chiffres et même un « domaine d'application » bien présentés. Le plus problématique : l'IA s'exprime avec une telle assurance et une structure si complète qu'un opérateur de maintenance ordinaire a du mal à détecter la supercherie sur le moment.

La cause profonde ne se situe ni dans les capteurs, ni dans la base de données, mais dans le fonctionnement même du grand modèle : il génère le texte mot par mot selon des probabilités, en privilégiant une expression fluide qui « sonne juste » plutôt qu'une vérification factuelle qui « est juste ». Lorsque ses données d'entraînement ne contiennent pas une norme donnée, il ne dit pas « je ne sais pas » : il « comble » la clause manquante avec le schéma linguistique le plus probable. C'est précisément ce qui rend la situation si dangereuse dans un contexte industriel — une IA qui fait semblant de savoir est plus redoutable qu'une IA qui admet son ignorance.

Une alerte crédible mais entièrement inventée : de la fausse alarme à la mauvaise décision

Le scénario ci-dessus n'est pas un cas isolé, mais une projection typique des hallucinations des grands modèles dans un contexte industriel. Le danger ne réside pas tant dans la « mauvaise réponse » que dans le fait qu'elle soit « convaincante ». Le cerveau humain a une tendance profondément enracinée : plus une réponse cite des chiffres précis, des numéros de normes et des termes techniques, plus elle est acceptée comme une conclusion fiable. Or, les grands modèles excellent précisément dans l'accumulation de ces signaux d'« autorité » dans leurs sorties, même lorsque le contenu est purement inventé.

De ce point de vue, les dommages causés par les hallucinations suivent une chaîne d'amplification à trois niveaux.

Premier niveau, la fausse alarme : le modèle génère une conclusion erronée à l'apparence professionnelle — une valeur limite standard inventée, ou une attribution de panne erronée.

Deuxième niveau, le mauvais diagnostic : le personnel sur site, convaincu par le caractère « crédible » de la conclusion, saute l'étape de vérification et utilise directement la sortie du modèle comme base de jugement.

Troisième niveau, la mauvaise décision : sur la base de ce diagnostic erroné, l'opérateur procède à l'arrêt, au démontage, au remplacement de pièces — gaspillant des heures de travail et du temps d'arrêt, et risquant même de laisser passer un véritable danger et de provoquer un accident.

Kelude, lors de ses études de terrain, observe systématiquement la même corrélation : le niveau de confiance des opérateurs envers l'IA est proportionnel au nombre de « chiffres précis » dans ses sorties. C'est précisément ce qu'il faut surveiller — car les hallucinations se manifestent le plus facilement à deux endroits : les « chiffres précis » et les « clauses de normes ».

Pourquoi l'IA ose-t-elle inventer avec autant d'assurance : l'absence de contraintes factuelles dans un mécanisme de génération probabiliste

Pour comprendre pourquoi les hallucinations sont si difficiles à « prévenir », il faut d'abord comprendre le mécanisme de génération des grands modèles. Il s'agit essentiellement d'un modèle probabiliste : étant donné le contexte précédent, il calcule le mot suivant le plus probable, puis génère le texte mot par mot. Ce mécanisme excelle naturellement à produire un texte fluide, cohérent et conforme aux habitudes linguistiques, mais aucune étape ne vérifie si « cette phrase est vraie dans la réalité ».

En d'autres termes, le grand modèle recherche la « plausibilité linguistique », pas la « vérité factuelle ». Lorsqu'on lui demande une clause de norme absente de ses données d'entraînement, il ne répond pas « introuvable » : il assemble, selon les schémas linguistiques appris, un « numéro de norme + terme technique + une valeur limite qui semble raisonnable ». Plus le contenu assemblé est spécialisé et précis, plus il est difficile à démasquer.

C'est précisément la raison pour laquelle des normes comme l'ISO 24621:2022 « Diagnostic de pannes par IA pour les grues » insistent particulièrement sur la « traçabilité » des conclusions de diagnostic : une conclusion de diagnostic valide doit pouvoir être retracée jusqu'aux données de capteurs et à la base de jugement concrètes, et non pas être une simple assertion invérifiable. La sortie par défaut des grands modèles manque précisément de cette « chaîne de traçabilité », ce qui explique pourquoi leur intégration directe dans les décisions d'alerte pose problème.

Les ingénieurs de Kelude résument ce phénomène par l'expression « hallucination de fluidité » : plus la sortie est fluide, plus elle masque facilement l'absence de faits. Le contexte industriel exige exactement l'inverse — mieux vaut un « incertain, à vérifier » qu'un paragraphe de conclusions erronées présenté avec aplomb.

Les trois formes d'hallucination industrielle les plus courantes : normes, procédures et données inventées

Dans le contexte concret de la maintenance des grues, les hallucinations se manifestent principalement sous trois formes, chacune avec un cheminement de dommages distinct.

Première forme : l'invention de clauses de normes. C'est la plus dangereuse. L'IA peut citer un numéro de norme inexistant, ou associer une norme réelle à une valeur limite erronée. Si l'opérateur de maintenance s'appuie sur cette base pour arrêter ou autoriser la remise en service, c'est une « norme » fictive qui prend la décision à la place de la norme réelle.

Deuxième forme : l'invention de procédures de réparation. Les séquences de maintenance générées par les grands modèles semblent souvent « complètes », mais peuvent omettre des étapes de sécurité obligatoires telles que la coupure d'alimentation, la dépressurisation ou l'isolation énergétique. Toute erreur dans l'ordre ou l'exhaustivité des étapes menace directement la sécurité physique des intervenants.

Troisième forme : l'invention de données de mesure. L'IA peut fournir une amplitude de vibration ou une lecture de température jamais collectée par un capteur, et en déduire une « dégradation du roulement » ou une « usure de l'engrenage ». De telles données fictives font reposer l'évaluation de l'état sur du sable, privant ainsi toute décision de remplacement de son fondement.

Le tableau ci-dessous met en regard les dommages et les points de contrôle clés pour ces trois formes d'hallucination :

De la correction ponctuelle à la prévention systémique : un cadre de fiabilité pour l'IA industrielle

Les hallucinations étant inhérentes au mécanisme de génération, il est illusoire de vouloir « rendre le modèle infaillible ». L'approche industrielle pertinente consiste à déplacer la ligne de défense d'une « correction a posteriori » vers une « prévention systémique », afin que l'IA n'ait jamais l'occasion de transmettre une hallucination jusqu'à l'étape décisionnelle.

Première exigence : ancrer toute conclusion générée par l'IA à une source factuelle vérifiable. Toute clause de norme, limite ou donnée de mesure citée dans une alarme doit pouvoir être retracée dans la base documentaire normative et les enregistrements des capteurs. Toute information introuvable est systématiquement exclue du processus de traitement. Cette exigence rejoint l'esprit de la norme GB/T 28264 — Système de surveillance et de gestion de la sécurité pour appareils de levage, qui souligne que les paramètres de surveillance de sécurité doivent s'appuyer sur des enregistrements réels — les conclusions de l'IA ne sauraient exister indépendamment des données de surveillance authentiques.

Deuxième exigence : définir clairement la limite de capacité de l'IA. Celle-ci peut alerter, synthétiser, rechercher, mais ne remplace en aucun cas l'humain pour les décisions d'arrêt, d'autorisation ou de remplacement de pièces. Toute requête dépassant ce périmètre doit être explicitement refusée ou redirigée vers un opérateur humain, plutôt que de faire l'objet d'une réponse hasardeuse.

Troisième exigence : l'examen manuel et la traçabilité par enregistrement. Kelude Industries Lourdes applique ce principe dans sa pratique terrain : toute sortie de l'IA influençant le diagnostic de l'état d'un équipement doit être validée par un opérateur humain, avec conservation conjointe de la sortie brute de l'IA, des références citées et de la conclusion de l'examen. Ainsi, même si une hallucination franchit les deux premières barrières, elle peut être interceptée lors de l'examen manuel et retracée lors d'un audit ultérieur.

La recommandation de Kelude Industries Lourdes est claire : plutôt que de viser une IA « jamais en erreur », il convient de partir du principe qu'elle « peut se tromper à tout moment » et de consolider les trois verrous que sont l'examen manuel, la traçabilité et la limite de capacité. Les hallucinations ne peuvent être éradiquées, mais elles peuvent être tenues à l'écart des décisions.

📖 Lectures connexes : Grands modèles linguistiques dans la maintenance des grues : cas concrets et limite de capacité | Gestion de la santé des équipements (PHM) : maintenance prédictive des ponts roulants par mégadonnées et ML — pratique d'ingénierie

Questions fréquentes