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.

Moi — Est-ce qu'on peut regarder comment tu as corrigé ce ticket ?

X — Facile : dans la version mobile, en bas de la page, il manquait toujours l'historique d'un contact. Et maintenant c'est tout bon : regarde bien, cet historique est bien présent. C'était un problème dans l'API.

Moi — Et peut-on regarder le code qui correspond ?

X — Toujours aussi facile : avec le numéro de ticket, on va vite retrouver le numéro de commit.

X, tapant quelques commandes dans son terminal —Voici le diff avec la version juste avant le commit.

Moi, dubitatif — Et quand tu écoutes ce code, qu'est-ce qu'il te dit ?

X, gêné — Qu'il lui manque son test unitaire.

X — Pourtant on a fait une revue de code avec ma responsable.

Moi — Mais devant moi, tu as directement pointé le problème.

X — Je connais la règle : avec une correction de bug, toujours ajouter un test unitaire. Avec chaque évolution du code en fait, y compris avec une nouvelle fonctionnalité.

Moi — C'est donc que j'ai raté une étape dans la transmission, peut-être avec ta responsable.

X — Ou peut-être qu'on était pressé ce jour-là, je ne m'en souviens plus.

Moi — Reste que le jidoka est un des deux piliers du Lean.

X — Le jido-quoi ?

Moi — C'est le pilier qui préconise de construire la qualité dans le produit, en détectant les anomalies dans le processus.

X — Naïvement, je dirais que c'est précisément ce que nous avons fait en corrigeant le problème, non ? On n'avait pas forcément besoin d'un test test unitaire en plus...

Moi — Sauf qu'en refusant de faire le test unitaire correspondant, tu as bloqué deux choses : d'une part la démonstration que tu avais bien compris la racine du problème (et pas juste les symptômes), et d'autre part la vérification automatique si le problème devait se reproduire plus tard.

X — J'ai quand même une question : est-ce que tu savais qu'il y avait ce problème dans ce commit avant que nous commencions ce gemba ?

Moi — Bien sûr que non, je sais juste d'expérience qu'on finira par trouver un premier problème. Et qu'il mérite toujours qu'on y passe du temps. Les problèmes suivants finiront toujours par remonter un peu plus tard.

X — Alors ce jidoka, recouvre-t-il autre chose que les tests unitaires chez nous ?

Moi — Avec 206864 tests unitaires, c'est sur qu'on ne peut pas les rater : l'effet de masse joue à fond. Mais il y a aussi tous nos tests d'intégrité : est-ce que les fichiers qui doivent être dupliqués sont bien identiques ? est-ce que tous les fichiers de langue contiennent strictement les même chaînes de traduction ?

X — C'est donc pour ça qu'on m'avait demandé un petit script qui puisse identifier les fichiers qui n'ont pas été modifiés depuis 5 années !

Moi — Certainement : ça veut peut-être dire qu'ils sont devenus inutiles. Et dans ce cas, autant les supprimer : c'est toujours ça de surface en moins pour des attaques de cybersécurité.

X — Tu as d'autres exemples ? On ne m'a jamais parlé de ce type de tests dans mon cursus universitaire.

Moi — Voici une anecdote : un client nous appelle parce qu'un champ qu'il a activé sur les utilisateurs n'est pas accessible dans l'export Excel de ces même utilisateurs. On ajoute le champ en question dans l'export Excel, il est content. L'affaire aurait pu en rester là. Sauf qu'on se dit qu'il y a peut-être d'autres champs qui ne sont pas présents dans cet export. On ajoute donc un nouveau test d'intégrité et on découvre qu'il y avait bien 3 autres champs dans le même cas. Personne ne s'était jamais plaint jusqu'à présent. Et désormais si un développeur devait oublier d'ajouter un nouveau champ dans l'export, il recevrait un message d'échec via l'intégration continue. Le processus est devenu beaucoup plus robuste.

X — On se calme. On respire.

Moi — Ma réunion vient à peine de se terminer : est-ce que tu sens encore l'électricité dans l'air ?

X — Je peux surtout voir que ta respiration n'est pas aussi tranquille que d'habitude. Que ta décontraction n'est pas là. Et que ta chemise dépasse de ton jean.

Moi — Encore et toujours ce regard...

X — Et on n'arrête jamais d'apprendre : ce n'est pas si souvent que je te vois dans cet état.

Moi — Peut-être que je n'ai pas l'habitude des réunions, mais là je n'en pouvais plus : j'ai mis les pieds dans le plat, en créant un malaise bien profond. Un malaise qui s'est à peine dissipé quand l'ordre du jour initialement prévu a repris son cours.

X — Il me semble pourtant que tu étais au dernier Lean Tour à Lille, n'est-ce pas...

Moi, taquin — Je sais que tu sais que je l'ai organisé et même qu'on s'y est croisé.

X — Alors tu te souviens peut-être des leçons de Reynald Debaut-Henocque, il y avait 8.

Moi — Attends voir un peu... Mon préféré si tu n'as pas de problème, alors c'est qu'il y a un problème. Ah oui, et aussi mieux vaut tester quelque chose que ne rien faire.

X — À ce rythme, ça va nous prendre trois plombes...

Moi, hilare — Je me disais bien que je n'avais pas fini de digérer les conséquences des découvertes en neuro-pédagogie présentées par les équipes de Arc.

X, sérieux — Je t'offre donc une séance de rattrapage, il y avait aussi avoir des rêves, des objectifs et des vision, ne jamais être satisfait, connaître sa place, n'abandonnez jamais à mi-chemin et ne pénalisez jamais vos subordonnés.

Moi — Clairement j'en avais oublié plus que la moitié. Mais ça n'en fait toujours que 7.

X — J'espérais que tu te souviennes de la dernière, c'est celle qui m'intéresse aujourd'hui.

Moi — La race des senseïs est quand même pénible : avoir les réponses et ne pas les donner. Ou donner celles qui sont tout juste adjacentes...

X — J'avoue, j'ai regardé la vidéo il n'y a pas si longtemps pour écrire cette liste sur mon calpin : elle est quand même intéressante, dans la veine du Toyota Way.

Moi, soulagé — J'ai retrouvé : bad news first.

X, pompeux — Les mauvaises nouvelles d'abord.

Moi — Tu veux dire que j'aurais dû court-circuiter l'ordre du jour ? Et commencer la réunion par le point litigieux ?

X — Même pas. Le meilleur moment pour planter un arbre, c'était il y a 20 ans. Le deuxième meilleur, c'est tout de suite.

Moi, las — C'est reparti pour un tour.

X, taquin à son tour — Je sais que tu sais que je n'ai pas besoin d'en dire plus et que tu réfléchira tranquillement avant de faire mieux la prochaine fois, et même mieux que moi d'ailleurs : je n'ai pas choisi d'être indépendant pour rien.

Le jeudi 1^er février, j'ai eu le privilège de participer à la Journée de l'Écoconception Numérique, un événement organisé par Les Designers Éthiques.

Cette association, axée sur le numérique et le design, s'engage activement dans la promotion d'une approche éthique du design numérique. Elle met en avant le rôle essentiel du design dans la création de services numériques tout en soulignant les défis personnels (vie privée, attention, accessibilité) et collectifs (démocratie, environnement) posés par le numérique. L'objectif clair des Designers Éthiques est de contribuer à un numérique durable, responsable et propice à l'autonomie individuelle. Leur action se manifeste à travers la recherche, la formation et la création d'exemples concrets illustrant des choix responsables en design.

La journée comprend cinq conférences, une table ronde et six ateliers. J'aimerais partager avec vous l'expérience que j'ai vécue durant les conférences auxquelles j'ai assisté. Elles m'ont beaucoup marquées, offrant une diversité de perspectives grâce aux profils variés des intervenants.

"Apple, ils sont capables de comprendre le fonctionnement complexe de l'être humain mais ils sont incapables de nous fournir leur chaîne d'approvisionnement."

La première conférence, Pour une écologie décoloniale du numérique présentée par David Maenda Kithoko, met en lumière les conditions de travail précaires des travailleurs et travailleuses congolais.e.s dans l'industrie minière liée à nos outils numériques. Alertant sur la guerre en République Démocratique du Congo et l'esclavagisation de ces travailleur.euse.s, cette conférence nous met une claque : il est urgent de revoir nos modes de consommation numérique.

La conférence suivante, Perception de l'obsolescence et design de paramètres écologiques , animée par Thomas Thibault et Léa Mosesso nous pousse à la réflexion : peut-on continuer d'utiliser un smartphone obsolète ? Comment les marques qui développent des smartphones peuvent-elles intégrer des paramètres liés à l'écologie dans leur interfaces pour nous permettre de limiter notre consommation d'outil numérique ? Questions auxquelles ces deux conférencier.ère.s tentent de répondre, grâce d'abord à une enquête auprès de 18 personnes qui veulent faire durer leur matériel numérique, puis à une analyse poussée pour montrer que modifier les interfaces pour changer nos habitudes, c'est possible.

Gérer la dette technique lors de la reprise d’un projet informatique : comment réduire son impact ? , par Anaïs Altun et Sandrine Ricardo de l'entreprise PathTech, apporte des enseignements pratiques sur la gestion de l'impact environnemental du code informatique, soulignant l'importance de traiter cette question progressivement pour améliorer l'expérience professionnelle.

"Faire le ménage une fois par mois dans sa maison prendra des heures et peut être démotivant, alors que le faire un petit peu chaque jour, c'est plus facile."

Conférence d'autant plus intéressante que le sujet de la dette technique touche directement plusieurs corps de métier au sein de la même entreprise. Anaïs et Sandrine réussissent alors l'impossible : donner l'impression aux designer.euse.s comme moi qu'ils et elles peuvent avoir un impact sur le code.

Avant la pause déjeuner, c'est le débat mouvant. Plusieurs personne montent sur scène, sur laquelle sont projetés une question, "d'accord" d'un côté et "pas d'accord" de l'autre. Tous le monde a participé avec enthousiasme et cela a permis de savoir comment les personnes qui s'étaient déplacées jusqu'à la conférence voyaient l'écoconception. Encore une fois, on a le sentiment d'être réellement inclus dans le débat, je ne me sens ni délaissée, ni spectatrice. C'est stimulant !

Durant la table ronde Faut-il mesurer l'écoconception ? Et comment ? , Benoît Petit, Thibault Dugast, Yannick Tremblais et Louise Aubet soulignent l'importance de comprendre pourquoi mesurer et se concentrer sur la réduction d'impact plutôt que sur une évaluation constante.

"On mesure, mais la vérité c'est qu'il faut réduire dans tous les cas : la question c'est 'à quoi on renonce pour limiter notre impact ?'"

Simon Vandaele et Nathalie Suze présentent Écoconception de sites web publics accessibles : cas pratiques . Il et elle passent en revu des sites institutionnels écoconçu et partagent avec nous leurs manières de créer des sites écologiques et accessibles pour réduire son impact environnemental, limiter la quantité de ressources informatiques, limiter l'arrivée d'une obsolescence et communiquer facilement avec le plus grand nombre.

Enfin, Pascal Courtois, Sven Grothe, Florian Guillanton et Arnaud Lévy font un retour d'expérience de site écoconçu. Plus que le produit en lui même, ces 4 conférenciers parlent de l'engagement politique et social que peut être l'écoconception. Plein d'espoir, ils contribuent tous à leur façon à l'amélioration du paysage numérique.

Pour conclure cette journée de conférence, ce sont Aurélie Baton, Anne Faubry et Mellie La Roque qui prennent la parole. Elles font un état des lieu de la façon dont on perçoit l'écoconception aujourd'hui et l'évolution de l'association des Designers Éthiques. Elles nous expliquent également comment nous allons pouvoir imaginer le futur, et comment les designers peuvent influencer leur entreprise à écoconcevoir de plus en plus souvent leur produit.

Quelle journée inspirante ! Cela me donne vraiment envie d'écoconcevoir plus, de m'engager de façon plus drastique pour un avenir numérique propre et beau.

---

Ressources

• Guide d'écoconception par les Designers Éthiques
• Fresque des Designers Éthiques
• Journée de l'écoconception Numérique