Moins connu que son jumeau le juste-à-temps, le jidoka est l’un des deux piliers fondamentaux du Toyota Production System.

La première idée fondamentale du Jidoka : « Construire la qualité dans le produit en détectant les anomalies dans le processus ». Le principe en est simple : il s’agit de ne jamais produire de pièces mauvaises et, de ce fait, mieux vaut arrêter la production plutôt que de produire des pièces insatisfaisantes. (extrait de « Jidoka, le deuxième pilier du Lean« . Working Paper n°2 de Michael Ballé, Projet Lean Entreprise)

Historiquement, le Jidoka a été inventé par Sakichi Toyota dans les années vingt et se traduisait par l’arrêt des métiers à tisser dès qu’un fil rompait. Il s’agissait d’éviter de découvrir au bout de plusieurs heures que la production de plusieurs centaines ou milliers de mètres de tissu était défectueuse et donc invendable. Ce système d’alerte a été généralisé et a permis de confier la surveillance de plusieurs machines à un seul opérateur. Lorsqu’un métier à tisser s’arrêtait, il émettait un signal d’alerte pour attirer l’attention et permettre ainsi immédiatement la prise en charge de la réparation et le redémarrage de la machine.

Le Lean management s’étant déployé dans des domaines industriels très variés, le Jidoka prend aujourd’hui de nouvelles formes. Le principe, lui, est resté le même : arrêter la production lorsqu’un défaut se produit.

Dans le monde industriel, l’une des façons de faire consiste à installer des systèmes que l’opérateur peut actionner pour arrêter la chaîne (une corde sur laquelle il peut tirer, une alarme qu’il peut déclencher, etc.) quand il voit un défaut. La production s’arrête, la panne est identifiée puis réparée, et la production reprend.

Dans le monde informatique, on rencontre le Jidoka de façon très explicite chez les agilistes qui pratiquent le TDD (Test Driven Development). De façon très fréquente, ils lancent le test sur tout le logiciel qu’ils sont en train de créer. Cela leur permet de savoir immédiatement si les nouvelles fonctionnalités qu’ils viennent de programmer ont été développées sans défaut, et de corriger tout de suite si tel n’est pas le cas, sans attendre que des jours et des semaines de programmation se soient accumulés, avec le risque de ne pas trouver l’origine du bug et de tout devoir recommencer.

Distinguer le normal de l’anormal

Pour mettre en place le Jidoka, il faut savoir distinguer un produit correct d’un produit défectueux. Cet apprentissage ne va pas de soi. En informatique, programmer une fonctionnalité demandée par un client et faire en sorte qu’elle fonctionne peut être considéré comme une réussite. Pourtant, si l’utilisation de cette fonctionnalité par le client prend un temps considérable, lui ne la considérera pas comme une réussite. On comprend ici la difficulté à déterminer si la pièce (ici, la fonctionnalité) est correcte ou pas.

Rendre les problèmes visibles

Lorsque les critères de normalité sont définis, il faut alors mettre en place les systèmes qui révéleront les anomalies au fur et à mesure qu’elles se présentent. En informatique, il peut s’agir d’une liste d’autocontrôle à remplir avant de se rendre dans un comité de validation pour obtenir le droit de lancer les développements. Il peut s’agir aussi d’un gabarit (l’adéquation entre la prise USB d’un ordinateur et la fiche d’une clé USB standard, par exemple) ou d’un détrompeur (ici, un système matériel qui empêchera l’utilisateur de se tromper de fiche sans avoir besoin d’être un spécialiste du câblage).

Protéger le client et résoudre les problèmes à la racine

Quand une situation ou une pièce anormale apparaît, la responsabilité de l’opérateur est de protéger le client, de réparer la pièce et de la réinjecter dans le circuit le plus rapidement possible. La particularité du Lean management c’est que l’on considère que le vrai travail commence à ce moment-là : après la phase de réaction, le moment est venu d’engager la phase de résolution de problème pour que cette anormalité ne se reproduise plus.

L’étape suivante consiste à aller au-delà de la question immédiate de l’utilisateur (« ça ne marche pas, comment faire ? »), et comprendre pourquoi elle est apparue, ouvre un univers d’améliorations possibles : selon le paradoxe américain, « le meilleur des services, c’est l’absence de service ».

A découvrir dans