Deux ans pour décrire un seul défaut : ce que le rappel de Toyota enseigne sur la description du problème
Toyota a mis deux ans à cerner un défaut logiciel, puis des semaines à le corriger. Leçons du rappel pour bien décrire le problème avec la méthode 8D.
En août 2026, Toyota a rappelé 508 354 Camry Hybrid aux États-Unis. Le défaut avait été signalé deux ans plus tôt.
Le dossier de rappel déposé auprès du régulateur américain raconte toute l’histoire, étape par étape. Lisez-le lentement.
Juillet 2024 : premières remontées terrain. Le combiné d’instruments reste noir au démarrage. Les essais sur le terrain ne parviennent pas à le reproduire.
Octobre 2025 : les soupçons se portent sur le logiciel. Toyota et son fournisseur construisent un équipement de diagnostic dédié.
Fin 2025 : première reproduction sur un banc d’essai. Avril 2026 : des essais de cycles marche-arrêt ne parviennent pas à le déclencher. Juillet 2026 : un essai sur véhicule complet provoque enfin la défaillance.
Deux ans avant de pouvoir faire apparaître le défaut à volonté. Puis quelques semaines jusqu’à la correction - une mise à jour logicielle du combiné d’instruments.
Pourquoi nous le savons
Nous connaissons cette histoire uniquement parce que la loi américaine l’exige. Selon le 49 CFR 573.6, un constructeur doit remettre avec chaque rappel une chronologie écrite de son enquête.
L’UE n’a pas de document équivalent. Safety Gate publie l’alerte et le risque, pas le chemin vers la cause. Cette année, il recense 278 alertes concernant des véhicules à moteur, dont 8 citent le logiciel - mais aucune ne contient de chronologie d’enquête.
Venant d’Europe, où nous avons un formulaire pour tout, je trouve cela toujours surprenant.
Pour un ingénieur qualité, cette chronologie écrite est un cadeau. Elle montre où sont réellement passés les deux ans.
Ils n’ont pas analysé pendant deux ans
Voici la partie inconfortable. Pendant la majeure partie de ces deux ans, personne n’analysait la cause racine. Ils essayaient de répondre à une question plus élémentaire : où le défaut apparaît-il, et où n’apparaît-il jamais ?
Regardez maintenant un cas de figure que je connais de ma propre pratique.
Dans un 8D, la description du problème est l’étape D2. Trop souvent, elle est rédigée en trois lignes. L’analyse des causes racines n’a alors rien à quoi se raccrocher. Chaque réunion produit une nouvelle hypothèse, et aucune n’est confirmée.
Ce n’est pas de l’analyse. C’est de la supposition posée sur une description qui ne tient pas.
Un problème bien posé
Charles Kettering a dirigé la recherche de General Motors pendant 27 ans. On lui attribue la phrase : “Un problème bien posé est à moitié résolu.” Kepner et Tregoe en ont fait une méthode : pour chaque dimension du problème, noter où il EST et où il N’EST PAS.
Une description complète, c’est un 5W2H rempli jusqu’au bout - chaque ligne avec deux réponses :
Quoi : ce qui ne va pas, en une phrase, sans explication, sans coupable. Où : où il apparaît et où il n’apparaît jamais - sur quelle machine oui, sur laquelle non ; dans quelle équipe oui, dans laquelle non. Quand : quand il a commencé - et ce qui a changé à ce moment-là. Qui : qui est concerné - et qui ne l’est pas. Pourquoi : pourquoi il semble se produire - le soupçon, bien séparé des faits. Comment : comment il se manifeste - et comment il ne se manifeste pas. Combien : pièces, pourcentage, réclamations.
L’écart entre les deux colonnes est le seul endroit où la cause racine peut se trouver.
Et un test honnête vous dit que la description est terminée : vous pouvez reproduire le défaut à volonté. Une fois ce test passé, la correction de Toyota a pris quelques semaines. Il a fallu deux ans pour le passer.
Sept ans de ma propre expérience
J’ai passé plus de dix ans dans la qualité en production. Un problème m’a suivi pendant sept d’entre eux. Nous le résolvions encore et encore sans jamais le décrire jusqu’au bout.
Quand nous avons enfin pris le temps d’écrire la description complète, autre chose est apparu. Ce n’était pas un seul problème. Il y en avait plusieurs, qui se chevauchaient, chacun avec sa propre cause.
Au cours des trois mois suivants, nous avons trouvé les causes et défini des actions pour chacune d’elles séparément.
Une de mes leçons : si vous n’arrivez pas à décrire un problème jusqu’au bout, vous êtes probablement en train de résoudre plusieurs problèmes à la fois.
Tous les problèmes ne méritent pas un 8D
Une réserve. Tout ce qui précède s’applique au 8D - la méthode des réclamations clients et des problèmes difficiles. Faire passer un rebut interne ou un petit écart par un 8D complet fait perdre une semaine de temps d’ingénierie. C’est à cela que servent les méthodes plus légères : 4-Step pour les écarts internes, PDCA pour l’amélioration continue, Just-Do-It pour le trivial. Dans SolveR, 8D, 4-Step, PDCA fonctionnent sur la même base de connaissances, si bien que choisir la méthode plus légère ne signifie jamais perdre la trace.
La bonne méthode raccourcit le chemin. La mauvaise l’allonge.
Où cela mène
Je suis convaincu que la quantité de données autour de chaque problème va croître de plusieurs ordres de grandeur. Des agents IA la collecteront comme le font les gens aujourd’hui - chaque étape notée, des règles explicites. Le bruit croîtra plus vite que le signal.
Filtrer deviendra alors le travail principal : ce qui appartient au problème, ce qui est du bruit, quelle interprétation est fausse, quelles données doivent être collectées à nouveau sur un échantillon plus large. La dernière étape restera toujours humaine.
La cause racine n’est pas trouvée par celui qui analyse le plus vite. Elle est trouvée par celui qui sait faire apparaître le défaut à volonté.
En savoir plus sur galileon.si
Références
- NHTSA, Part 573 Safety Recall Report 26V511, 2026-08-06. 508 354 unités, chronologie de l’enquête, remède logiciel.
- 49 CFR § 573.6 - l’exigence américaine d’une chronologie écrite de l’enquête.
- EU Safety Gate, motor-vehicle alerts - consulté le 2026-08-17. 278 alertes en 2026, 8 citant le logiciel, aucune chronologie publiée.
- Charles F. Kettering, attribué - “A problem well stated is a problem half solved”.
- Kepner, Tregoe, The Rational Manager, 1965 - la spécification du problème EST / N’EST PAS.