Poka-yoke pour les connaissances : pourquoi votre AMDEC reste vide

Il y a des années, un ingénieur a refusé d’écrire ce qu’il savait dans l’AMDEC.

Il a dit pourquoi à voix haute, en pleine réunion. L’écrire réduirait sa propre valeur dans l’entreprise.

Sa réponse était plus honnête que le formulaire que je tenais.

L’incitation dont personne ne tient compte

Dans presque chaque usine, il y a une personne qu’on appelle quand une machine précise s’arrête. Ses connaissances ne figurent dans aucun document. Tout le monde le sait et personne n’y remédie.

L’entreprise le récompense de savoir ce que les autres ignorent. Puis elle lui demande de l’écrire. Elle lui demande de réduire la raison pour laquelle on l’appelle.

Eliyahu Goldratt a résumé le mécanisme en une phrase : dites-moi comment vous me mesurez et je vous dirai comment je me comporterai. Cet ingénieur est mesuré sur ce que lui seul sait résoudre. Il se comporte exactement comme il est mesuré.

La réponse habituelle est un rappel, un modèle ou une formation. Les trois supposent que le problème est l’attention. Ce n’est pas le cas.

Ce que Shingo a vraiment dit

Shigeo Shingo a tracé une ligne que la plupart des services qualité brouillent encore. Il a séparé l’erreur du défaut. Les gens font des erreurs. Une erreur ne devient un défaut que si rien ne l’arrête entre les deux.

Sa conclusion n’a pas été de demander aux gens d’être plus attentifs. L’attention n’est pas un contrôle. Il a conçu l’étape de sorte que la mauvaise action ne puisse pas aboutir : un montage qui n’accepte la pièce que dans un seul sens, un gabarit qui ne se ferme pas s’il manque une rondelle.

L’intérêt du poka-yoke est de supprimer la dépendance à l’attention humaine au moment précis où cette attention risque le plus de faiblir.

Appliquez la même idée à votre AMDEC. Si le document ne se remplit que lorsque quelqu’un s’en souvient, se sent généreux et dispose d’une heure, le système dépend de l’attention. Il n’y a aucun contrôle.

Pourquoi l’AMDEC sous Excel meurt deux fois

Une AMDEC dans un tableur échoue à deux endroits distincts, et le second explique pourquoi tant d’entre elles ont l’air bien fournies sans aider personne.

Elle échoue à la saisie. Y écrire est un acte à part, une fois le vrai travail terminé. Cela entre en concurrence avec la réclamation suivante. Personne ne lui impose d’échéance. Elle se remplit donc de façon inégale, surtout par ceux qui ont le moins à perdre.

Elle échoue à la restitution. Même les lignes rédigées sont difficiles à retrouver ensuite. L’ingénieur qui en a besoin six mois plus tard ne sait pas que le fichier existe, ne peut pas chercher dans ses douze versions sur SharePoint et ne sait pas laquelle était à jour. Les connaissances sont donc écrites en théorie et perdues en pratique.

Ce second échec explique pourquoi “nous documentons déjà tout” et “nous résolvons le même problème deux fois par an” sont vrais en même temps dans la même usine.

Ce que doit faire un garde-fou pour les connaissances

Si l’attention n’est pas le contrôle, quatre conditions doivent être réunies. Aucune ne concerne le logiciel.

La saisie doit être un sous-produit du travail. Les connaissances sont enregistrées parce que le cas a été clôturé, pas parce que quelqu’un l’a demandé après coup. S’il existe une étape séparée, il y aura des exceptions, et les exceptions deviennent la règle.

L’enregistrement doit porter sa source. Une cause sans le document, le lot ou la mesure qui la fonde n’est qu’une opinion mise en forme. L’ingénieur suivant doit pouvoir la vérifier, pas la croire sur parole.

La restitution doit se faire au moment du besoin. Pas sur demande, pas après une recherche. Quand un problème similaire est décrit, ce qui a déjà été appris doit arriver avec lui.

Celui qui écrit ne doit pas payer pour écrire. C’est cette condition qui décide si les trois autres fonctionneront un jour. Si partager ses connaissances fait perdre du statut, le système sera contourné, aussi bon soit-il.

Ce que cela produit

C’est ce que nous construisons chez Galileon. Pas un endroit pour stocker des documents, ni un formulaire de plus. Un système où chaque cas clôturé alimente le suivant.

Ce que cela produit pour l’ingénieur, mesuré sur notre propre échantillon pilote de 10 réclamations clients chez des industriels slovènes, de janvier à mars 2026 :

• L’étape des actions correctives passe de trois jours de réunions à une trentaine de secondes pour une première proposition, car les propositions viennent d’actions qui ont déjà fonctionné sur des causes confirmées.
• L’étape de description du problème produit environ trois fois plus de suggestions exploitables qu’un modèle vierge, car elle part de cas similaires au lieu d’une page blanche.
• Une traçabilité complète de la réclamation client jusqu’à l’action préventive, si bien que la question d’audit “montrez-moi comment vous en êtes arrivés là” a une réponse qui existe déjà.

Ce que l’ingénieur ne fait pas : remplir une base de connaissances. L’enregistrement est écrit parce que le cas a été clôturé.

Ce qui reste à l’ingénieur

Des agents collecteront les données comme les gens les collectent aujourd’hui, et il y en aura bien plus qu’actuellement. La dernière étape appartient toujours à une personne.

Le jugement qui ne se délègue pas, c’est la pensée analytique et critique, et il se joue dans quatre décisions :

• ce qui ne fait pas partie de ce problème
• ce qui est du bruit et ce qui est un signal
• où l’interprétation est fausse
• quelles données doivent être collectées à nouveau, sur un échantillon plus large

Plus il y a de données, plus il est précieux de décider lesquelles concernent vraiment le problème.

La limite qui mérite d’être tracée

Il existe une version de tout cela où chaque entreprise construit son propre outil. Le code ne coûte plus grand-chose, alors des choses qui auraient dû être refusées sont construites quand même, et le résultat est un produit aux nombreuses fonctions, sans attachement pour aucune d’elles.

La question à se poser avant que cela commence : quelle partie relève vraiment de votre métier, et laquelle vaut-il mieux laisser à des gens qui y travaillent tous les jours, disposent de bien plus de données et livreront quelque chose de mieux qu’un MVP interne ?

La réponse vous appartient. Elle mérite d’être donnée délibérément plutôt qu’au fil de l’eau.

En savoir plus sur galileon.si

• Deux ans pour décrire un seul défaut : ce que le rappel de Toyota enseigne sur la description du problème - ce qui se passe en amont, quand le problème n’est jamais assez bien décrit pour que l’analyse tienne.
• Comment fonctionne SolveR
• Sécurité des données

Références

• Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, Productivity Press, 1986. Page de l’éditeur
• Eliyahu M. Goldratt, sur la mesure et le comportement. Goldratt Consulting