On nous chante en continu la rengaine de la fin des développeurs.
L’IA va coder, l’IA va tester, l’IA va même bientôt choisir la couleur du logo. Si votre métier, c’est de transformer un ticket Jira en lignes de code, OK vous êtes une espèce en voie de disparition.
Mais si on regarde de plus près, ce qu’il se passe dans le logiciel en ce moment ressemble à ce qui s’est passé chez Toyota dans les années 60.
L’IA n’est pas en train de tuer le code. Elle est en train d’en faire une activité Lean.
1. Jidoka : l’IA est votre “Andon”
Dans le Lean, le Jidoka, c’est l’automatisation au service de l’humain. On ne laisse pas la machine tourner seule dans son coin.
C’est exactement le flow avec Claude Code. Il s’occupe de la syntaxe, des tests unitaires et du code dont on a visualisé l’architecture. Claude c’est la presse hydraulique. Beaucoup plus efficace que 3 personnes motivées avec leurs marteaux.
Mais comme sur une ligne de production Toyota, l’intelligence n’est pas dans le bras articulé. Elle est dans l’humain qui opère le flux.
Le développeur n’écrit plus de code. Il orchestre des agents qui, eux, font le boulot à moindre valeur ajouté. Son job ? Cadrer la tâche et tirer sur le cordon Andon quand l’IA hallucine ou quand le code devient un plat de spaghettis.
2. Le “Gemba” ou la mort des intermédiaires
Le plus gros gâchis (Muda) dans le logiciel, c’est le cloisonnement.
- Le client parle au Product Manager.
- Le PM/PO écrit une spec.
- Le développeur lit la spec (ou pas).
- Le développeur code un truc qui ressemble vaguement ce dont le client a besoin pour résoudre son problème.
C’est l’antithèse du Gemba — le principe qui dit que l’ingénieur doit aller voir la réalité du terrain.
Avec l’IA, la barrière technique s’effondre. Puisque coder devient “facile”, le développeur n’a plus d’excuse pour rester planqué derrière son écran. Son nouveau terrain de jeu, c’est l’utilisateur.
Les rôles de “Product Engineer” et “Software Engineer” se réorganisent autour d’un rôle proche du Shusa.
3. Le Shusa : le développeur devient Chef de Produit
Chez Toyota, le Shusa (Chief Engineer) n’est pas juste un expert technique ; il est responsable de la réussite commerciale du véhicule. Il possède une vision transversale. Il connaît la mécanique, mais il connaît aussi le marketing, les coûts et ce que le conducteur veut ressentir au volant.
Ainsi, chaque développeur tend vers ce modèle de “mini-CEO” de sa fonctionnalité, plutôt que d’être un simple artisan de la ligne de code.
C’est le portrait-robot du développeur “Ketchup et Couteau Suisse” dont je vous parlais récemment.
Puisque l’IA permet de coder en 1 jour ce qui prenait 3 jours, le dev peut passer les 2 jours restants à discuter avec les clients, améliorer le produit, réfléchir à l’architecture, la sécurité et la fiabilité.
L’IA absorbe la compétence purement technique. Alors la seule façon de se différencier, c’est le discernement. Être capable de dire : “Ce n’est pas parce que l’IA peut coder cette fonctionnalité qu’on doit le faire.”
Au final c’est se recentrer sur son vrai taf : concevoir des logiciels fiables et performants pour un marché. C’est le positionnement d’un ingénieur-produit.
4. Zéro Stock : sobriété du code
Dans le Lean, le stock, c’est le mal. Un pneu qui attend d’être monté sur une voiture, c’est de l’argent qui dort.
En logiciel, on retrouve les mêmes notions avec la complexité technique qui est une forme de “stock de charge cognitive”. Et tous ces tickets JIRA forment aussi à leur façon un “stock de fonctionnalités” qui attend d’être livré.
L’IA facilite le Juste-à-Temps. Au lieu de construire des usines à gaz prévoyant tous les cas d’usage possibles pour les 10 prochaines années (ce qu’on appelle pudiquement de “l’over-engineering”), on génère uniquement l’itération dont on a besoin, maintenant.
Le développeur devient un minimaliste. Puisque l’IA accélère la ré-écriture, utilisons-là pour faire le plus simple possible. Des types, des fonctions.
On passe d’une culture du volume à une culture de l’impact.
Alors, on fait quoi ?
Le risque du développeur n’est pas que l’IA écrive son code. Mais plutôt de ne pas savoir quoi lui faire écrire : produit, architecture.
Le 10x développeur n’est pas celui qui code le plus vite (les LLM ont déjà gagné), mais celui qui comprend le mieux le problème à résoudre pour concevoir un bon produit pour son marché.
Passez au Lean. Arrêtez de polir votre code, commencez à polir votre produit.
Références :
- AI Is Replacing Engineering Tasks, Not Jobs (Matt Watson) : Lien vers l’article sur Substack
