Les usines oublient ce qu'elles ont déjà résolu
L'analyse des causes racines par l'IA en production ne rapporte que si le cas clôturé reste retrouvable. Voici ce qui en décide.
Ce que l’analyse des causes racines par l’IA change vraiment en production
L’analyse des causes racines par l’IA en production, c’est l’utilisation d’un modèle pour aider un ingénieur à passer d’un défaut à sa cause, et pour garder tout le cas dans un seul dossier. Elle ne choisit pas la cause. Elle raccourcit les deux parties les plus lentes du travail, la description du problème et la recherche de ce qui a déjà été essayé, et elle décide si le cas terminé pourra resservir.
Cette dernière partie est celle sur laquelle personne ne fonde son achat. C’est aussi la seule dont la valeur se cumule.
Une flotte apprend. Une usine classe.
Il y a deux semaines, la conduite autonome supervisée a été autorisée sur les routes slovènes. C’était le sixième marché de l’Union européenne à l’autoriser.
Ce système n’en est pas arrivé là en changeant de nom, ni parce qu’un modèle était plus malin que le précédent. Il y est arrivé parce que la flotte fait remonter ses données. Chaque kilomètre parcouru devient quelque chose que la version suivante peut lire.
Placez-vous maintenant dans une usine et regardez le même défaut être résolu pour la troisième fois.
L’ingénierie n’est pas moins bonne. Les gens ne sont pas moins bons. La différence, c’est ce que chaque côté a le droit de garder.
Un système de conduite écrit son expérience sous une forme que la version suivante peut utiliser. La qualité écrit son expérience dans un rapport. Le rapport est classé, signé et archivé. L’ingénieur suivant qui se heurte au même mur ne sait généralement pas qu’il existe, ou ne le trouve pas. L’apprentissage s’arrête avec la personne qui a fait le travail.
Le rapport a été conçu pour être signé
Ouvrez n’importe quelles archives 8D, le constat est le même. Les rapports sont complets. Ils sont aussi illisibles en tant que données.
L’énoncé du problème est en prose. Les preuves sont dans une pièce jointe. L’action tient en une phrase. Le nom du fichier est un numéro et une date. Rien de tout cela ne répond à la question qu’un nouvel ingénieur pose réellement, qui n’est jamais “montrez-moi le rapport 2024-118” mais toujours “est-ce qu’il s’est déjà passé quelque chose de ce genre sur cette machine”.
Ce n’est pas un manque de discipline. Le formulaire 8D a été conçu pour prouver à un client qu’un problème a été traité. Il n’a jamais été conçu pour être lu par le cas suivant.
Voici le même travail vu deux fois.
| Un rapport classé | Un dossier de cas réutilisable | |
|---|---|---|
| Écrit pour | le client et la signature | l’ingénieur suivant |
| Énoncé du problème | de la prose, souvent moins de trois lignes | structuré, avec ce que le problème est et ce qu’il n’est pas |
| Preuves | des pièces jointes à côté du fichier | rattachées à la cause qu’elles retiennent ou écartent |
| Retrouvé par | numéro de rapport et date | symptôme, pièce, machine, étape du processus |
| Vérification | un champ date, souvent vide | une boucle fermée, efficace ou non |
| Valeur après clôture | la preuve que c’est traité | une donnée d’entrée pour le cas suivant |
Le tableau résume tout l’argument. Les deux décrivent les mêmes heures de travail, par les mêmes personnes. L’un des deux peut resservir.
Ce que nous avons mesuré
Entre janvier et mars 2026, nous avons traité dix réclamations clients de cette façon avec des industriels slovènes, mesurées chez huit d’entre eux. Sur cet échantillon, tout ce qui a été produit pendant la résolution est resté rattaché au cas et consultable ensuite : la définition du problème, les causes écartées, les preuves et la vérification.
Source : échantillon pilote, 10 réclamations, industriels slovènes, janvier à mars 2026, mesuré chez 8 industriels.
C’est un petit échantillon et nous le disons. Il suffit à montrer le mécanisme, pas à promettre un chiffre à une usine que nous n’avons jamais vue.
L’ordinateur portable
Avant tout cela, je me suis retrouvé devant un ordinateur portable qui contenait plus de 20 ans de travail d’un ingénieur. Il partait une semaine plus tard.
Chaque problème résolu et chaque essai raté se trouvaient dans des fichiers que lui seul savait lire. Des noms de dossiers qui avaient un sens pour lui. Des tableurs sans ligne d’en-tête. Des photos avec les noms de fichier de l’appareil.
Personne d’autre dans ce bâtiment n’aurait pu les ouvrir et savoir quoi faire ensuite. L’entreprise n’avait pas encore perdu ces connaissances. Elle ne les avait jamais eues.
Un outil qui mène une usine plus vite à la cause et laisse derrière lui le même tas de fichiers a déplacé le problème sans le résoudre.
Ce qu’il faut vérifier lundi
Ressortez le dernier cas que vous avez clôturé. Puis faites trois vérifications, dans cet ordre.
Un. Demandez à quelqu’un qui n’y a pas travaillé de le retrouver, en partant du symptôme et de rien d’autre. Donnez-lui cinq minutes.
Deux. Lisez la D2, la description du problème. Si elle fait moins de trois lignes, le cas a été clôturé sur une supposition qui s’est trouvée juste.
Trois. Trouvez la date de vérification. Si le champ est vide et que le rapport est clôturé, la boucle n’a jamais été fermée.
Si le cas échoue aux trois, la prochaine apparition de ce défaut coûtera autant que la première. C’est tout le coût d’une trace qu’on ne peut pas lire.
En savoir plus sur galileon.si
Références
- Slovenia clears Tesla’s FSD driver assistance, publié le 7 September 2026. AOL, reprise de Reuters
- Tesla FSD (Supervised) approved in Slovenia, its sixth EU market, 7 September 2026. We Talk Tesla