X – J'ai été assez surpris par ta présence parmi les auditeurs de la dernière masterclass de l'Institut Lean France. Vu le nombre de posts que tu publies, je pensais plutôt te croiser dans un évènement où tu serais locuteur...

Moi – C'est peut-être flatteur mais je crois surtout que c'est se méprendre sur le rôle de l'apprentissage.

X – Tu veux dire que tu découvres encore des choses précieuses quand tu écoutes d'autres praticiens Lean parler de leurs expériences ?

Moi – Et pas qu'un peu ! J'ai même un souvenir très précis lors de la session que tu évoques : quelle est la première étape quand on découvre un problème ?

X – C'est vrai que ça m'avait marqué aussi : au lieu de corriger le problème au plus vite, la réponse au sein de Toyota était de trouver un leader pour ce problème.

Moi – On est quand même loin du réflexe classique, celui qui consisterai à corriger la situation au plus vite.

X – C'est dans ces cas-là que je revois mon ancien directeur débarquer dans le bureau et exiger une solution sur le champ : j'imagine qu'il se plait encore dans cette posture du pompier-qui-peut-décider-et-faire-faire.

Moi – Et pour moi c'est une mise en lumière d'une pratique qui était devenue régulière chez nous : mettre un post-it avec son nom, une date et quelques mots décrivant un problème sous le panneau du kaizen d'un salarié. On lui notifie donc que ce problème rentre potentiellement dans son périmètre et qu'il peut revenir à la source au moment opportun.

X – Je comprends encore moins : comment as-tu été surpris par un énoncé si tu le mets déjà en pratique dans ta boîte ?

Moi – Parce que justement je n'avais pas encore fais ce saut conceptuel : avec un slogan comme "trouver un problème, chercher le leader", il devient plus facile de systématiser cette approche dans tous les types de problème qu'on peut rencontrer.

X – As-tu eu d'autres moments similaires lors de cette session ?

Moi – Oui : le "rangement vertical". Parce que si on peut entasser des objets sur une étagère, ils tomberont s'ils ne sont pas accrochés au panneau vertical, indiquant au passage qu'ils ne sont pas à leur place !

X – On est quand même loin de tes bureaux : je n'imagine pas qu'on puisse y trouver un seul de ces panneaux verticaux avec crochets, attaches et autres trous de fixation.

Moi – N'empêche que cette image m'aura marqué, même sans avoir trouvé - jusqu'à présent - comment elle peut s'appliquer à des lignes de code.

X – Dois-je comprendre que tu y cogites encore ? Il y a pourtant un gouffre entre des objets physiques soumis à la gravité et des mots interprétés par un compilateur.

Moi, songeur – C'est marrant que tu parles de gravité : je n'avais pas pris le problème sous cet angle. Que serait au code serait ce que la gravité est aux objets physiques ?

X – Attention, ça peut vite tourner à la question philosophique.

Moi – Sauf que je fais ça en continue : là où certains pensent que "Le Lean n’est ni plus ni moins qu’une démarche d’analyse de la valeur appliquée à grande échelle", sous-entendu que n'importe qui peut la faire et qu'il suffirait de le vouloir, je tente plutôt de comprendre comment de petites bribes de TPS peuvent s'appliquer à mon domaine. Par exemple, dans le développement logiciel : où est le gemba ? qui sont les opérateurs sur la chaîne ? Je te propose deux cadres différents : les opérateurs peuvent être tes développeurs (des humains) ou tes lignes de code (une abstraction).

X – Dans ce premier cas, c'est facile : le gemba c'est le bureau avec le clavier et l'écran. Mais j'anticipe que tu considères aussi les serveurs comme un gemba.

Moi – Bingo ! Et là il y a un monde complet qui s'ouvre. Par exemple le fameux cercle de craie que Taiichi Ohno imposait à ses assistants pour apprendre à regarder : peux-tu passer une heure à regarder un serveur et tenter d'y voir quelque chose ?

X – Tu voudrais me faire rentrer dans la matrice ?

Moi – Bien sûr que non, mais on peut créer des lunettes bien particulières pour comprendre le système de l'intérieur : Simon Wardley explore ces lunettes avec son concept de moldable software. On a ainsi pris de vraies claques en explorant les load dans des boucles : quand tu sais qu'un load fait un appel à la base de données et qu'on découvre un de ces appels dans 5 boucles imbriquées, je te laisse imaginer les dégâts en terme de performance. Et je te laisse divaguer sur ceux qu'apporteront le vibe coding.