par 
La question du blog : Pourquoi associe-t-on le « respect for people » au pilier du jidoka ?
La réponse de Yves
Comme je n’ai pas une très grande expérience avec le lean manufacturing et la pratique du jidoka sur le terrain, je vais faire un pas de côté en vous recommandant la lectures des excellents billets de mes collègues du Lean Institute sur le sujet. Ce pas de côté va porter sur le domaine, je vais parler de logiciel et aussi sur la question, puisque je vais me poser la question de la cause commune au jidoka et au principe fondamental du “respect for people”, à savoir la complexité. Sans surprise, nous allons retrouver un enseignement fondamental de la sociologie du comportement popularisé par le best-seller de Daniel Pink, la performance dans un monde complexe exige “purpose, mastery and autonomy”. On voit déjà apparaître un début de réponse à la question dans la juxtaposition de ces trois mots.
Le jidoka est à la fois un principe et un ensemble de pratiques développé au travers de l’histoire du lean manufacturing. Il s’agit d’une frontière entre l’automatisation, pour faciliter le travail de l’opérateur, et de la responsabilisation, pour ne rien perdre au sens du travail mais surtout parce que la très grande majorité des automatisations laisse des zones d’intervention, des incidents à gérer. Plus le domaine est complexe, plus il reste des actions à faire, plus l’opérateur doit collaborer avec l’automate. Le jidoka c’est à la fois la recherche de la motivation de l’opérateur, pour éviter qu’il soit “asservi à l’automate”, et surtout la recherche de l’efficacité car plus l’automatisation devient sophistiquée, plus le traitement des exceptions, des erreurs, des réglages exigent une forte compétence et une grande intelligence de situation. Le jidoka, c’est donc la collaboration entre l’automate et l’opérateur pour détecter, corriger et apprendre des défauts du processus de fabrication, dans une recherche d’amélioration continue de la qualité. L’essence lean du jidoka, c’est l’action au plus tôt, caractérisée par l’andon mais qui commence par l’obsession (et l’automatisation) de la recherche du défaut, et au plus profond, c’est-à-dire la recherche des causes racines de ces défauts. Reconnaissons tout de suite que cette frontière évolue et que dans certains domaines, l’automatisation (y compris de la détection et de la contre-réaction) est très poussée, tandis que dans d’autres domaines, le rôle clé de l’opérateur à travers l’andon (l’arrêt de la chaîne de production) est fondamental.
Si l’on s’intéresse au développement logiciel dans le monde moderne, en particulier dans le domaine des services numériques, il est marqué par une double exigence : celle de l’automatisation, tirée par les contraintes de lead time et celle de l’excellence des compétences, tirée par la complexité des domaines. On trouve deux expressions clés, celle de DevOps et de software craftsmanship, qui expriment cette complémentarité et tension. Les pratiques rassemblées autour de DevOps portent sur une approche produit organisée en cycles itératifs rapide, qui s’appuie sur l’automatisation du “build”, de l’intégration et des tests, du déploiement. Ici aussi l’automatisation est un domaine sans cesse croissant, et l’arrivée de l’IA génération dans l’assistance à la production de code est une parfaite illustration. Pour innover, il faut s’adapter; pour s’adapter il faut apprendre vite, pour apprendre vite il faut exécuter rapidement et sans erreur et donc automatiser (résumé en une phrase de mon dernier livre). L’impérative nécessité de ce chemin vers l’automatisation est établie, je vous renvoie au livre de référence “Accelerate”. En même temps, probablement à cause des dérives qui ont fait confondre aux grandes entreprises le développement agile avec des méthodes d’organisation du travail, le mouvement “software craftsmanship” a réaffirmé l’importance de la compétence logiciel, du beau geste technique, du compagnonnage dans la production de code. Il est difficile d’être innovant et agile avec des produits mal développés, un code mal structuré et difficile à partager. Le “beau code” est un avantage métier, à la fois en termes de potentiel d’innovation et de durabilité des produits. L’automatisation ne remplace pas la compétence, elle accélère la différentiation entre le talent et la médiocrité. Comme le remarque McKinsey, le gain de productivité des développeurs dans l’utilisation de l’IA générative est d’autant plus grand qu’ils sont expérimentés et compétents. l’IA ne remplace pas le craftsmanship, elle le multiplie.
Même si je n’ai pas prononcé le mot “jidoka” dans le paragraphe précédent, il s’agit bien d’automatisation avec une touche d’humanité, ou de la combinaison judicieuse entre automatisation et responsabilisation – (les deux traductions courantes de jidoka étant “automation with human touch” et “autonomation: hybrid between automation and autonomy”). Sans surprises, les spécialistes du lean transposent facilement le jidoka au domaine du logiciel. S’assurer de la qualité en détectant les défauts au plus tôt est un principe fondamental du “lean software development”. La pratique de l’Andon se transpose en permettant aux opérateurs de production (suivi de déploiement) de mobiliser l’ensemble de l’équipe (et d’arrêter le développement de nouveaux “features”) pour résoudre un problème constaté en production. La racine autonomation exprime superbement la tension créative entre automatisation et compétence humaine, entre DevOps et software craftsmanship. Dans le craftsmanship, on retrouve deux valeurs essentielles chez Toyota : nous avons besoin du cerveau de chacun pour résoudre les défis d’un monde complexe, et l’organisation du travail a pour premier objectif de devenir continûment (de plus en plus) excellent dans nos activités.
Ceci nous permet de revenir à la question posée et de comprendre l’importance du “respect for people”. Ce que Daniel Pink nous explique, en synthétisant 20 années de sociologie expérimentale, c’est que pour réussir des tâches complexes il faut développer le “mastery”, le plaisir de développer le “beau geste technique”, et l’autonomie de l’opérateur qui est devant la situation complexe. Il n’y a pas d’autonomie sans respect. Il est frappant quand on lit Daniel Pink sur la motivation intrinsèque de voir à quel point ces leçons sont intégrées dans la culture de Toyota depuis de nombreuses décennies. Il n’y a pas non plus de mastery (ou de craftsmanship, les deux mots sont très proches) sans respect. Les échecs les plus fréquents et flagrants des approches qualité pilotées par des cellules externes, qui souhaitent déployer “des bonnes pratiques / des bonnes méthodes / des bons outils” en top down, commencent par un manque de respect. Un manque de respect de l’individu et un manque de respect vis-à-vis de la complexité. Il n’y a pas de mastery sans humilité, une leçon qui date de plusieurs millénaires (bien avant le lean ou le développement logiciel). La recherche continue de la qualité du produit, en particulier dans le contexte d’une automatisation qui s’accroît, repose sur une culture d’apprentissage continu et d’excellence technique dont la fondation est le respect des femmes et des hommes de l’entreprise.
