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.

X – Ça fait maintenant un ou deux ans que je lis régulièrement tes billets sur le Lean. J'ai l'impression que ça pourrait répondre à des questions que je me pose...

Moi – Je suis touché : ce n'est pas si souvent que j'ai un retour sur ces billets de blog plus ou moins réguliers.

X – Je me pose donc la question de m'y mettre. Comment faire ? Est-ce que tu aurais un tuyau ?

Moi – Si tu m'avais posé la question il y a quinze jours, je t'aurais répondu Le Goldmine : l'histoire romancée d'une transformation Lean dans une usine. Mais depuis la publication de Réussir ses décisions stratégiques, j'ai le sentiment que ce petit opus de Michael Ballé, Godefroy Beauvallet et Sandrine Olivencia serait une porte d'entrée plus adaptée.

X – C'est justement celui que j'ai lu sur ma kindle après avoir vu passer un billet sur ton blog.

Moi – Alors c'est génial, tu as déjà commencé. Maintenant il faut simplement avancer et tenir bon... Le sérieux et la ténacité sont des vertus cardinales quand on se lance dans le Lean.

X – Bien sûr je comprends tout ça, je me familiarise d'ailleurs tout doucement avec les concepts mais j'aurais besoin d'un truc plus terre à terre.

Moi – S'il te faut plus de terrain, je peux te suggérer de faire un peu de genchi genbutsu avec tes équipe. Le Gemba code en est une des formes possibles : on part d'un bug - chez nous une notice ou un warning détecté par les serveurs de production - et on explore en binôme les causes, puis on fait la correction qui s'impose avant de noter sur un A4 ce qu'on a appris au passage. Cela me prend une heure par semaine, à tour de rôle avec chaque développeur.

X – Et tu arrives à maintenir le rythme ?

Moi – Pas toujours, il y a effectivement des congés ou des déplacements qui contraignent mon agenda. Mais si je ne peux pas tenir la cadence alors je m'assure qu'un autre développeur prendra la relève. Sur les 25 dernières semaines, le Gemba code a eu lieu 24 fois. C'est Noël qui a fait déraillé cette routine la dernière fois...

X – Sauf que moi, je ne suis pas développeur : comment voudrais-tu que je comprenne ce que mes équipes font derrière leur écran ? Surtout qu'on s'appuie sur une brique externe, une véritable boîte noire sur laquelle nous n'avons pas la main. Bref on a un contexte technique moins évident que celui dont vous bénéficiez avec Opentime.

Moi – Et tu as essayé de contacter directement des senseïs ? Nous avons de la chance d'en avoir sur la région... Même plus besoin d'aller en chercher à Paris !

X – J'ai bien peur que ça fasse un sacré budget quand même. On n'est pas encore un grand groupe avec ses armées de consultants.

Moi – Mais au fait, vous êtes combien désormais ? La dernière fois qu'on avait papoté ensemble, vous veniez de passer pour la première fois la barre des 10 salariés.

X – C'est vrai qu'on a fait un bout de chemin depuis cette époque. On est désormais une vingtaine, c'est quand même une belle croissance.

Moi – Ah je comprends mieux : tu n'as pas encore besoin du Lean. C'est une piste que tu peux garder au chaud dans un coin de ta tête. Pour l'instant tu peux juste attendre d'avoir des vrais problèmes. Et si tu as envie de t'en sortir à ce moment-là, on pourra en reparler.

X – C'est bon j'ai fini ma tâche, est-ce qu'on peut la regarder ensemble pour la valider ?

Moi – Bien sûr...

Moi, confiant après 5 minutes à relire le code – C'est tout bon, on peut l'ajouter dans le dépôt source.

X – Je fais un merge avec la branche principale et après je pousse tout sur le serveur central. C'est bien ça ?

Moi – Exact, il suffit de bien suivre la petite procédure interne (checkout, rebase, merge, dcommit, push) qui t'explique chaque étape dans le wiki interne.

X – Je me souviens bien de ces procédures, je les ai d'ailleurs suivi pour installer le code source sur mon ordinateur au départ.

X, contrarié – Par contre là, ça ne marche pas : je n'ai rien fait de particulier et pourtant Git me dit que j'ai des commits d'avance ! Ce n'est quand même pas de ma faute si ça ne marche pas du premier coup...

Moi, sarcastique – As-tu vérifié s'il n'y avait pas un petit lutin ou pire un farfadet sous ton clavier ? Peut-être qu'ils ont laissé des traces de leur passage ? Des miettes de pain peut-être ou des gouttes de lait ?

X – Ce n'est pas ce que je voulais dire...

Moi – Alors qu'est-ce que tu voulais dire ?

X, vexé – Que je ne sais pas ce que j'ai fait et que je comprends encore moins pourquoi ça ne marche pas... Mais que le code est bon.

Moi – Sauf qu'en l'état le code ne sert à rien : impossible de le fusionner dans le dépôt central.

X – Mais qu'est-ce que je peux faire alors ?

Moi – La première étape, c'est peut-être d'assumer que tu as fait une erreur et que tu es en train d'apprendre. Tu débutes chez nous, c'est normal. J'irai même jusqu'à dire que savoir trouver de l'aide fait parti de l'apprentissage.

X – Tu veux dire que je dois lire toute la documentation de Git pour comprendre comment résoudre ce problème ?

Moi – C'est une piste. Tu peux aussi repartir d'une installation complètement vierge. Tu peux également demander à un développeur senior de te montrer comment il s'en dépatouillerait. Tout dépend de ce que tu veux apprendre et à quelle vitesse surtout.

X – Mais qu'est-ce que je dois faire alors ?

Moi – Gagner en humilité et en expérience ! Et pour ça, ces trois chemins sont valables. Probablement même qu'il y en a d'autres...

X, impatient – Tu ne me diras donc pas lequel il faut que je prenne.

Moi – Je ne peux pas le faire pour toi : les adultes apprennent moins bien quand on leur montre trop précisément chaque étape. Ils ont déjà un tas de modèles mentaux à leur disposition, des modèles qui les ont aider devenir ce qu'ils sont, des modèles qui ont déjà fait preuve de leur efficacité. Si tu ne sais pas quel chemin prendre, l'expérience douloureuse d'un choix sera bien meilleure conseillère à terme : c'est peut-être le plus facile.

X – Parce que tu penses que ça peut être plus rude ?

Moi – Si tu feins de ne pas le savoir - peut-être qu'un de tes réflexes te suggère d'ailleurs très légitimement de "retourner la question pour ne pas être pris en défaut" -, alors il te faudra d'abord casser, affiner ou ajouter un modèle mental. C'est loin d'être si évident. Et là encore, personne ne peut le faire à ta place.

X — C’est sympa de me parler Lean de temps en temps. Et même de m’inviter à des conférences ou à des ateliers épisodiquement. Mais vraiment je n’en peux plus du vocabulaire japonais tout le temps.

Moi — Malheureusement on ne peut pas faire l'impasse : le Lean a été inventé et affiné au Japon, tout au long de son développement industriel, au sein d’une entreprise en particulier, Toyota.

X — N’empêche qu’à chaque conférence ou webinaire, je dois me farcir un nouveau mot sans traduction. J’ai eu droit à kaizen, puis andon, puis jidoka. Pour ceux que j’ai retenus… Je suis certain que j’en ai oublié en route. Ah si, le dernier en date était « Genchi Genbutsu ».

Moi — Sans oublier « Hoshin Kanri » ou « Nemawashi ».

X — Arrête, je suis déjà perdu : c’est dommage, je sens pourtant bien qu’il y a des trucs intéressants dans le Lean.

Moi — Je te propose de faire un pas de côté : est-ce que tu sais que presque tous les sodas en grand surface sont « kasher », en particulier aux Etats-Unis ?

X — Quel rapport ?

Moi — Je vais y venir… Nassim Nicholas Taleb appelle ça la tyrannie de la minorité : quand la majorité est indifférente à un sujet, une minorité exigeante peut imposer ses préférences assez facilement à toute une population. Et par ailleurs une minorité trop conciliante se fondera dans la masse, tandis qu’une majorité sensible bloquera toute évolution.

X — Et tu penses que le Lean est une de ces minorités ?

Moi — Pas qu’un peu : dans le monde de l’entreprise, la pensée dominante se transmet à coups d’injonction financière et de court-termisme froid, grâce à des cohortes de détenteurs d’un MBA.

X — Et la question du vocabulaire serait une forme d’intolérance ?

Moi — Complètement assumée.

X — Tu veux dire que vous bloquez l’accès au Lean avec des mots japonais de manière délibérée ?

Moi — « Bloquer » est un peu excessif. C’est surtout un moyen de préserver l’essentiel : les spécificités du Lean. Tiens par exemple, le « Karakuri » : au départ c’est une petite poupée qui bouge toute seule, grâce à la gravité et à des systèmes ingénieux. C’est désormais un axe majeur des efforts de Toyota sur le chemin de sa propre décarbonation : chaque année il y a des compétitions internes avec des voyages au Japon pour les meilleurs. Les connotations d’un mot comme « marionnette » ou « poupée » rendent le concept difficilement abordable en France sans le détour par le mot japonais.

X — Mais pourquoi tout le temps et partout ?

Moi — Tu oublies le fameux « Just-in-Time », inventé par les japonais eux-même parce que ça « sonnait » bien. Puis détourné en pas-de-stock-chez-moi par des consultants, oubliant l’intérêt du stock tampon et négligeant les pertes de compétence.

X — Je sens que je ne vais pas réussir à te faire changer d’avis.

Moi — Tu bosses dans le développement logiciel, est-ce que tu te fais autant de tracas avec les « commits », « mock objects » et autres « pull requests » ?

X — Tu triches : c’est le vocabulaire d’une très large majorité de développeurs à travers le monde.

Moi — N’empêche que si tu veux devenir développeur, tu dois apprendre ces mots-concepts.

X — Tu veux dire qu’il faut accepter de redevenir débutant pour faire du Lean ?

Moi — Cela ne m’étais jamais apparu aussi clairement, mais maintenant que tu le dis, oui ! Trois fois oui même. C'est même l'intérêt principal que j'y trouve.

X — Tu continues à utiliser des feuilles de papier au mur !? Je pensais pourtant que dans une boîte de logiciels qui promeut la dématérialisation des procédures RH - entre autres - il y avait mieux à faire.

Moi — Je te rassure : ici chacun fait autant de télétravail qu’il le souhaite. On peut dématérialiser autant que nous le souhaitons. Nous avons ainsi deux formes de Gemba que nous faisons régulièrement en ligne et en binôme, le « Gemba code » et le « Gemba kaizen ».

X — Mais alors pourquoi ne pas mettre en ligne ces feuilles ?

Moi — Parce que ces feuilles-là sont d’abord pour moi, quand je prends un temps du recul et de réflexion avec moi-même.

X — Décidément je ne comprends pas : si tu es le seul à les utiliser, ça pourrait tout simplement être un fichier Excel sur ton ordinateur personnel. Même pas besoin de cette couche de complexité qu’on appelle Zoom, Miro, Teams et peut-être bientôt Metaverse.

Moi — Petit hic : prendre du recul derrière un écran est littéralement impossible. Tu seras toujours à 60 cm des pixels lumineux. Je préfère largement pouvoir embrasser tout le mur d’un seul regard et m’avancer au besoin pour explorer une feuille en particulier. Je vais même jusqu’à écrire à la main les résultats que je collecte dans nos différents outils numériques.

X — Dois-je comprendre que tu aimes bien perdre ton temps à utiliser tes petits feutres vert et rouge ?

Moi — Et même le Tippex ! Dans le cas présent, c’est moi qui met les points sur les courbes et qui en efface certain avec du correcteur blanc : l’effet Ikea joue aussi sa part.

X — Un peu comme un tennisman qui joue contre le mur alors : la trajectoire de la balle ne dépend que de son coup initial.

Moi — Effectivement, je n’avais pas pensé à cette métaphore : je m’y retrouve en tout cas. En fait le mur et ces feuilles sont mon espace matériel de Hansei : ce moment d’auto-réflexion pour tenter de comprendre ce qui s’est passé, l’accepter et trouver des ressources pour l’améliorer.

X — C’est marrant que tu aies besoin d’une zone bien physique pour réfléchir : j’aurais cru que tu pouvais faire ça devant ton écran. Un informaticien est plutôt équipé pour ça n’est-ce pas ?

Moi — Et bien non, mes meilleurs moments devant un écran sont plutôt quand je code en pleine concentration. On appelle ça être dans la « zone » mais c’est plutôt que le code coule de source, les doigts tapent plus vite que la pensée, le monde extérieur n’existe pas. L’auto-réflexion, c’est au contraire une bonne tranche de réelle qu’il faut examiner, évaluer et digérer. Ce serait trop facile de l’évacuer en refermant l’ordinateur.