Engineering manager : une parenthèse sur l'IA et le lean

C’est le sixième article de ma série sur ce que le rôle d’engineering manager m’a appris, et c’est aussi une parenthèse. Comme pour les épisodes précédents, ce qui suit n’est ni une méthode ni une vérité générale : c’est un retour d’expérience personnel sur ce que l’IA change, ou pas, dans la façon dont je conçois le travail d’une équipe d’ingénierie.

Les épisodes déjà publiés portaient sur le rôle et la posture d’engineering manager, le 1:1 et le suivi individuel, les objectifs et la vision et les métriques que je surveille. Vous pouvez retrouver tous les articles de la série sur la page du tag engineering-management.

J’ai appelé ce billet une parenthèse parce qu’il n’est pas un épisode de plus dans la progression de la série : c’est un arrêt, un détour, pour regarder un sujet qui traverse tous les autres.

Ce qui m’a poussé à écrire cette parenthèse, c’est une conviction simple : l’IA bouleverse nos manières de travailler, mais elle ne change en rien notre objectif principal. On cherche toujours la même chose : maximiser l’apport de valeur de nos contributions.

Aller plus vite n’est pas une fin en soi

Deux prompts et quinze minutes pour une feature ne font pas une feature à quinze minutes de valeur. Le premier réflexe quand on parle d’IA dans une équipe d’ingénierie, c’est pourtant la vitesse. « On va livrer plus vite. » C’est vrai, et c’est une vraie opportunité. Mais la vitesse n’est pas une fin en soi : elle ne crée de la valeur que lorsqu’elle s’applique à quelque chose qui en a déjà.

Il y a deux façons d’aller plus vite qui ne servent à rien :

• aller plus vite pour livrer des choses qui n’ont pas de valeur ;
• aller plus vite pour s’accumuler dans un goulot d’étranglement.

Dans les deux cas, la vitesse ne crée rien. Elle produit juste plus vite ce qu’on n’aurait pas dû produire, ou elle remplit un tuyau qui ne se vide pas. On l’avait vu dans l’article sur les métriques : la seule question qui compte, c’est de savoir si on livre, en valeur, ce qu’on avait prévu de livrer.

Et il y a la question du coût de maintenance. Une feature sans valeur ajoute au coût de maintenance de l’ensemble du code, qu’elle ait été écrite à la main ou générée en quinze minutes. Le fait qu’elle ait été produite vite ne change rien à ce qu’elle va coûter à maintenir pendant des années. L’IA abaisse le coût de production ; elle ne change pas le coût de possession.

J’avais déjà évoqué une version de cette idée dans l’article sur les objectifs et la vision, à propos des backlogs qui deviennent des cimetières d’intentions. L’IA rend la question plus urgente, pas moins.

Le lean et les 3M

Pour donner une forme à cette intuition, j’ai eu la chance de découvrir il y a quelques années certains concepts du lean manufacturing. Le lean, c’est cette discipline née chez Toyota¹ qui consiste à maximiser la valeur pour le client en éliminant tout ce qui ne la crée pas. J’y ai trouvé trois notions (les « 3M ») qui me servent aujourd’hui de grille de lecture pour l’usage que je fais de l’IA, et pour la façon dont je vois les équipes déléguer à des agents IA.

Les trois M sont le muda, le mura et le muri :

• le muda (無駄), c’est le gaspillage : tout ce qui consomme des ressources sans créer de valeur ;
• le mura (斑), c’est l’irrégularité : l’inconstance de la charge, les à-coups ;
• le muri (無理), c’est la surcharge : pousser une personne, une machine ou un système au-delà de ses limites.

Trois mots japonais, trois angles différents sur la même question : qu’est-ce qui, dans notre façon de travailler, nous éloigne de la valeur ?

Muda : l’IA qui rend le gaspillage moins cher

La première chose que l’IA change, c’est le prix du gaspillage.

Avant, produire du code avait un coût : un développeur, des heures, une attention. Ce coût était un frein naturel à la production de muda, imparfait mais réel. Avec l’IA, le coût marginal de production d’une feature, d’une fonctionnalité, d’un bout de code, tombe vers zéro. On peut produire du muda en quantité industrielle, presque gratuitement.

La chasse au muda devient donc plus importante qu’avant, pas moins. Le frein naturel a disparu : il ne reste que la discipline, et c’est elle qui empêche de remplir le codebase de ce qui n’aurait jamais dû y entrer.

Mais il y a un deuxième visage du muda avec l’IA, et il est vertueux. Le muda, dans le logiciel, c’est aussi tout ce toil, toutes ces tâches répétitives qui ne sont pas de la valeur mais qu’il faut bien faire : une migration mécanique, un refactoring répétitif, une mise à jour de dépendances, la génération d’un bout de code à partir d’une spécification claire. Là, déléguer à un agent ce qui est du vrai muda, c’est retirer du gaspillage sans en créer à la place. C’est l’usage de l’IA que je trouve le plus sain : pas produire plus, mais débarrasser l’équipe de ce qui n’apporte pas de valeur.

Mura : l’irrégularité que l’IA amplifie

Le deuxième M, c’est le mura : l’irrégularité de la charge, les à-coups.

Dans le lean, c’est la cause racine : une charge irrégulière oblige à dimensionner l’aval pour les pics, ce qui est de la surcapacité, et quand le pic ne passe pas, c’est du stock qui attend. L’irrégularité fabrique donc les deux autres M : elle pousse à surcharger (muri), et elle génère du gaspillage (muda).

L’IA, elle, produit par rafales. Zéro code un jour, dix pull requests le lendemain, au gré des prompts et de l’élan du moment. Or le reste de la chaîne, lui, ne varie pas : la revue, la validation, les tests, le déploiement, la donnée, les décisions produit ont une capacité fixe. Résultat : du code qui s’accumule, du travail en cours qui ne finit pas.

La réponse du lean, c’est le lissage : au lieu de produire par à-coups, produire à un rythme régulier que l’aval peut absorber. Concrètement, cela veut dire ne pas lancer dix pull requests le même jour, borner ce qu’on envoie en revue, ne pas accélérer plus vite que le goulot. Si le goulot, c’est la revue, produire deux fois plus n’a aucun intérêt : ça fait juste deux fois plus de PR à relire. L’IA ne déplace pas le goulot ; elle le fait juste apparaître plus vite. Et quand on a un goulot, la bonne question n’est pas « comment produire plus vite », mais « comment faire passer le goulot plus vite », ou comment ne pas lui envoyer ce qui n’a pas de valeur.

Muri : l’IA qui surcharge

Le troisième M, c’est le muri : la surcharge.

Une ligne qui me sert beaucoup : un agent IA n’est fiable que jusqu’à un certain point. Au-delà, il produit du plausible, pas du correct. Demander à un agent de faire une tâche au-delà de sa fiabilité, c’est créer du muri, et le muri se paie toujours : en défauts, en corrections, en relecture.

Il y a aussi la surcharge humaine. Quand l’IA produit plus vite, quelqu’un doit valider plus vite. Si l’équipe ne grandit pas et que les garde-fous restent les mêmes, alors l’IA ne fait que déplacer la charge : on passe moins de temps à écrire, et plus de temps à relire ce qu’un agent a produit. Le temps gagné en production est simplement racheté en validation. Ce n’est pas une critique de l’IA, c’est une loi du mura et du muri : on ne supprime pas une contrainte en la poussant un peu plus loin, on la déplace.

Une grille pour déléguer aux agents

Le bon usage, c’est de connaître la limite de fiabilité de l’outil et de cadrer la délégation en dessous de cette limite : en découpant la tâche, en donnant un contexte clair, en gardant la décision et le jugement là où ils doivent rester. Si je devais résumer tout ça en un livrable, ce serait une grille de trois questions à se poser avant de déléguer quelque chose à un agent IA. Chaque question correspond à un M, et chaque M à un piège :

Un exemple pour rendre la grille concrète : une migration technique que l’équipe traîne depuis des mois. Est-ce que ça a de la valeur ? Oui, on retire une dette et on débloque du travail derrière. Le goulot est-il en aval ? Si la revue est déjà saturée, générer la migration ne fera qu’ajouter des pull requests à relire : on attaque d’abord le goulot, ou on découpe pour que ça passe sans tout bloquer. L’agent est-il fiable pour ça ? Une migration mécanique, bien cadrée, oui : c’est exactement dans ses limites. On délègue donc, avec un périmètre borné et une relecture ciblée. Le même exercice sur une feature sans valeur aboutirait à la conclusion inverse : on ne la ferait simplement pas, même si elle ne coûte que quinze minutes.

Trois questions, trois angles sur la même obsession : la valeur. Ce n’est pas une check-list magique, c’est un réflexe. Et comme pour les autres outils de la série, je l’utilise comme un instrument de calibrage : elle ne dit pas quoi faire, elle dit où regarder avant de décider.

Ce que ça change pour le manager

Tout ça a une conséquence directe sur ma façon de concevoir le travail d’équipe. Si la production n’est plus le goulot, le rôle du manager change : il ne s’agit plus d’aider l’équipe à produire plus, mais de faire en sorte que ce qui est produit serve. Concrètement :

• refuser ou faire questionner les sujets sans valeur, même s’ils ne coûtent que deux prompts : un muda refusé est le plus efficace des muda éliminés ;
• surveiller les goulots d’abord, la production ensuite : si la revue ou la validation est saturée, accélérer la production n’est pas un progrès ;
• faire des limites de fiabilité des agents un sujet d’équipe, pas une affaire individuelle : savoir ce qu’on peut déléguer sans que la relecture devienne le nouveau goulot, et comment le cadrer ;
• réorienter la capacité que l’IA libère vers de la valeur, et pas vers plus de production : c’est là que l’IA devient un levier de réduction de muda plutôt qu’une usine à muda.

Pour conclure

C’était la parenthèse. Je la referme ici, avec l’idée qui la résume : l’IA change nos manières de travailler, pas notre objectif. Elle rend le gaspillage moins cher, elle amplifie les goulots, elle déplace la surcharge, et dans les trois cas, la réponse n’est pas dans l’outil, elle est dans une discipline que le lean nomme depuis longtemps.

Comme toujours, vous pouvez retrouver l’ensemble de la série via le tag engineering-management.