Lean, GenAI et Delivery Tech - Ce que le Lean peut apporter à l'adoption de la GenIA dans la tech

Ces deux dernières années, l'IA a fait une irruption brutale dans le monde de la tech avec un impact disruptif sur les processus de delivery. Et quand on fait du Lean, on ne peut s'empêcher d'y voir la mine d'apprentissages qui l'accompagne. Cela va faire près de 20 ans que je travaille dans la tech, et bientôt deux ans que j'observe l'IA se glisser dans nos vies professionnelles et je dois dire que je n'ai jamais observé de bouleversement aussi majeur que celui provoqué par l'irruption de la GenIA. Je le constate chaque jour sur le terrain et comme tout le monde, je me pose de nombreuses questions :

• Quelle valeur l'IA apporte vraiment aux métiers de la tech ?
• Quels sont les impacts sur les processus de delivery, au quotidien ? Sur nos organisations ?
• Comment le Lean peut-il accompagner ce changement ?

Pour essayer d'y répondre, j'ai commencé à massivement me documenter. Le sujet est tellement « disruptif » et mouvant qu'il existe des milliers de ressources, et certainement autant de façons de voir les choses. Cependant, tous ne se valent pas, et ne font pas preuve de la même rigueur. Avec ma sensibilité Lean, j'ai trouvé la démarche de Samuel Retiere, Technical Operations Principal chez Peaksys (la filiale tech de Cdiscount), particulièrement intéressante à éudier : une approche expérimentale, ancrée sur le terrain.

Cette série de 10 articles publiés sur Medium décrit la démarche que Peaksys a lancée pour évaluer l'apport de l'IA dans les développements, en testant la solution Cursor IA. Cet IDE augmenté par l'IA permet d'expliciter des règles métier à partir du code, de générer du code, mais aussi de passer en mode agent pour faire des propositions (par exemple : détecter le besoin d'une clé SSH et proposer de la générer).

Karakuri kaizen

Dès le début des tests, l'organisation constate que l'IA permet à des développeurs de créer des applications « from scratch » sur une technologie qu'ils ne connaissent pas. Le gain paraît significatif pour fabriquer des outils utiles au quotidien. Par exemple : une extension Chrome de suivi de la consommation de tokens, qu'un développeur réalise en une après-midi là où plusieurs semaines auraient été nécessaires sans IA. Ce qui est marquant ici, c'est la facilité avec laquelle les développeurs créent des applications, sur des terrains qui leur sont inconnus. Côté qualité, Peaksys a pris soin de faire valider la qualité du code par des développeurs expérimentés dans ces technologies : celle-ci a été jugée satisfaisante.

Cursor semble donc être un compagnon particulièrement intéressant pour donner vie rapidement aux idées des développeurs. L'un d'eux affirme avoir créé 4 applications internes en 2 semaines pour accélérer la production. On pense ici aux exemples connus du Lean Manufacturing où l'on peut voir des outils créés pour faciliter la vie des employés : un dispositif pour attraper exactement 3 vis dans une boîte ou un détrompeur lumineux pour éviter de piocher une pièce dans le mauvais bac…

Dans la tech, il n'est pas rare de se dire « si seulement j'avais un outil pour faire ça ! ». Dans certains cas, l'IA pourra désormais y répondre : elle semble être un facilitateur du Karakuri Kaizen, cette pratique par laquelle les équipes conçoivent elles-mêmes des outils « maison » pour assister une étape. Il existe cependant une différence essentielle. Le Karakuri traditionnel, c'est du low-tech ingénieux (utilisant la gravité, des ressorts, des aimants, etc.), né d'un problème vu sur le terrain, une fois le flux compris… et pas avant. L'IA propose l'inverse : du high-tech instantané. Maîtriser le flux et ses gaspillages devient alors indispensable pour que chaque outil reste au service de l'humain et que son apport soit validé par la mesure (PDCA - i.e. Plan-Do-Check-Act). Sans quoi, on risque surtout de faire proliférer des outils que personne n'utilise vraiment, et donc du gaspillage. À cette condition, ces dispositifs pourraient être redoutablement efficaces pour attaquer le M**uri (i.e. la surcharge, la pénibilité vécue par les développeurs).

Les limites de la GenAI

Lorsque les développeurs de Peaksys ont commencé à travailler sur du code fonctionnel, des limites sont rapidement apparues. Samuel décrit deux exemples :

• Cursor a proposé un refactoring pour traiter un sujet de « Clean Code ». Ce faisant, il a modifié une règle métier et introduit un bug fonctionnel.
• En voulant ajouter une nouvelle règle métier, Cursor a cassé un test. Pour le réparer, il a changé la règle métier — ce qui n'était pas vraiment l'attendu.

Et il y en a eu d'autres : des écarts quand on lui demande d'expliquer des règles métier à partir du code, des ajouts de features non désirées, des oublis de logs, etc. Cependant, ces articles datent d’un an, ce qui est une éternité quand on parle d’IA. Depuis, les progrès des IA ont été vertigineux. Comme le précise Soufiane Keli dans l’entretien qu’il nous à accordé : “depuis Septembre 25 et GPT [...] La tech est arrivée au bon niveau de maturité pour produire du code de qualité”.

À ce stade, on mesure à quel point il va être important d'apprendre à maîtriser ces nouveaux outils. La GenAI est un assistant et, à ce titre, elle a besoin de supervision. Le risque, ici, c'est de créer une usine cachée (hidden factory) : une reprise humaine routinière et normalisée qui, si elle devient une étape « normale » du flux, finit par masquer le gaspillage. On ne le voit plus comme un défaut, on le voit comme du travail. C'est souvent le signal le plus dangereux, parce qu'il ne déclenche plus de PDCA et donc plus d’apprentissage.

D'où l'importance de se poser les bonnes questions : comment ces écarts sont-ils vus par les équipes ? Comment sont-ils partagés ? Qu'en apprenons-nous ? Il s'agit ici d'accompagner l'apprentissage pour trouver le bon geste à standardiser, plutôt que de multiplier les contrôles humains. C'est là qu'un principe Lean éclaire toute la situation : le Jidoka. Son idée première, c'est de s'arrêter au défaut et de signaler l'anomalie… de tirer l'Andon *(*i.e. un cable qui permet d’arrêter la chaîne pour reporter instantanément un problème). Or nos deux exemples montrent exactement l'inverse : l'IA ne s'arrête pas, dans un cas elle maquille ainsi le défaut en ré-écrivant la règle métier pour faire passer le test. Autrement dit, l'outil est aujourd'hui « anti-Jidoka » par défaut, et c'est l'humain qui joue le rôle de l'Andon. Le vrai enjeu devient alors un peu plus clair : comment outiller l'arrêt au défaut (tests, garde-fous, revues) pour que l'anomalie remonte immédiatement, au lieu d'être dissimulée par l'usine cachée ? C'est tout l'esprit du Lean : protéger l'étape suivante, c'est-à-dire le client. C'est l'IA qui est notre assistant, pas l'inverse.

L’IA comme révélateur d’écart caché

Le développement logiciel, ce n'est pas qu'écrire des lignes de code. Si l'IA accélère significativement son aspect mécanique, cela ne suffira pas à livrer plus vite au client : les étapes amont (le Discovery) et aval (les Ops) risquent de ne pas suivre la cadence. Pour éviter cela, l'expérimentation a exploré comment l'IA pouvait aider les parties Design et Architecture.

En voulant creuser le sujet, Samuel décrit une expérience visant à comparer l'analyse des architectures implémentées dans le code par l'IA (Bounded Contexts) avec la description du métier par les experts (Business Domains dans un contexte de Domaine Driven Design). Il parvient alors à identifier des écarts significatifs et instructifs, qui matérialisent la dette fonctionnelle du périmètre analysé. Il détecte par exemple un écart de vocabulaire important entre le métier et le code. Une source de surcharge cognitive pour les développeurs. Une piste prometteuse à creuser.

Ce qui est intéressant ici, c'est qu'on déplace l'IA du « faire » vers le « voir ». Et voir, c'est le commencement de toute démarche d'amélioration. Dans cet exemple, l'IA révèle les écarts entre la pensée des métiers et l'exécution, en regardant le code. Elle pourrait donc donner une autre dimension au Gemba, en offrant un management visuel étendu au code : elle agrandit le terrain observable et permet d'abaisser le niveau de l'eau pour révéler des rochers restés invisibles jusqu'ici. En cela, l'IA peut devenir une véritable mine d'apprentissage. L'exemple du vocabulaire donné par Samuel l'illustre parfaitement : il met en avant un Muri cognitif bien caché, qui génère un gaspillage à chaque échange. Le genre de gaspillage qui ralentit insidieusement tout le flux de connaissance, sans jamais déclencher de PDCA, parce que personne ne le voit.

Attention cependant à ne pas céder à la tentation de déléguer toute la responsabilité de la mise en œuvre du Domaine Driven Design à l'IA. La valeur de l'Event Storming, ce sont les conversations entre experts du métier et développeurs. Cette connaissance est précieuse : la court-circuiter, ce serait perdre l'apprentissage collectif et priver les développeurs de la capacité à demander les bonnes choses à l'IA (on y reviendra). Car c'est là que se joue la nuance : l'IA n'est pas là pour concevoir l'architecture à notre place, mais pour nous aider à mieux la voir. Elle ne remplace pas le regard des équipes, elle l'augmente, en rendant visibles des écarts restés jusque-là dans l'angle mort. Et une équipe qui voit mieux, c'est une équipe qui décide et apprend mieux, ensemble.

Besoin de s’adapter… vite

Aujourd'hui, l'IA nous interpelle beaucoup. Mais un constat met tout le monde d'accord : un IDE augmenté par l'IA sera indispensable à toute entreprise tech qui ne veut pas se faire dépasser. La question n'est plus de savoir s'il faut y aller, mais quand, et comment.

Ce constat en ouvre un autre : les IDE augmentés par l'IA, comme les modèles eux-mêmes, évoluent plus vite que la capacité de n'importe quelle organisation à les tester. Il faudra donc, très probablement, changer d'IDE et de modèle plus souvent qu'on ne le voudrait pour continuer à profiter des meilleures performances. Si l'organisation apprenante, et la vitesse d'apprentissage, étaient déjà un véritable avantage compétitif, l'IA ne fait qu'amplifier le phénomène.

Dans de nombreuses entreprises, la direction a une envie légitime de maîtriser les processus et les outils. Mais la rapidité des changements va demander une tout autre capacité d'adaptation et d'expérimentation : des expériences à faible coût et réversibles, pour apprendre vite tout en maîtrisant les coûts et les gains. Le PDCA pourrait être un parfait moteur de cette vitesse d'apprentissage. Dans le Lean, la performance à long terme ne vient pas de la qualité d'une décision, mais de la fréquence à laquelle on boucle sur le Plan-Do-Check-Act. Autrement dit : quand le rythme du changement externe dépasse le rythme d'apprentissage interne, l'organisation décroche**. Et le management Lean construit autour du** PDCA a montré maintes fois sa capacité à accélérer l’apprentissage interne.

C'est là que les directions vont devoir travailler le « Respect for People » du Toyota Way. Pour que l'organisation apprenne assez vite, elle devra déléguer une part de son contrôle à la standardisation par les équipes. Moins de contrôle, et plus de standard. Non pas un standard imposé d'en haut, mais celui que les équipes construisent à partir des problèmes rencontrés sur le terrain. Comme le rappelle Régis Médina, le standard est le phare qui nous guide dans le chaos : précieux, justement, quand l'environnement change plus vite qu'on ne peut le maîtriser. Cela suppose d'impliquer toute la ligne managériale, de multiplier les Gemba pour voir, comprendre et agir vite sur les problèmes, et d'en faire une routine quotidienne, entretenue chaque jour, par la hiérarchie.

La nécessité de standardiser

Lors de l'expérimentation, Samuel a mené des Gemba pour comprendre comment ces agents IA étaient réellement utilisés sur le terrain. Il a découvert des usages très différents : de l'analyste qui fait analyser son code pour en expliquer le comportement mais sans jamais lui faire écrire une ligne, au « vibe coder » qui pilote l'agent sans développer lui-même, en passant par le « Lucky Luke du code » qui tape son code assisté par l'IA, et le « native AI agent » qui exploite toutes les fonctionnalités des agents. Ce dernier est tour à tour pilote et copilote : il s'appuie sur l'IA pour écrire son code, et lui en fait parfois générer l'intégralité.

Les usages sont donc très variés avec, au fond, une proportion assez faible de « native AI agent » : à peine un tiers du panel observé quelques semaines après le début de l’expérimentation. Cela met en lumière tout l'intérêt de définir, et de faire évoluer, une standardisation sur le sujet : pour exploiter l'IA pleinement, et ne laisser personne sur la touche. Le Yokoten, cette pratique du Lean qui vise à diffuser les apprentissages dans toute l'organisation, devient alors indispensable. Attention toutefois : diffuser, ce n'est pas uniformiser. Le Yokoten partage un apprentissage pour que chaque équipe se l'approprie et l'adapte à son contexte, pas pour le calquer à l'identique. C'est justement ce qui le distingue de l'envie qu'auraient certaines entreprises de tout aligner d'un coup, comme le réflexe d'une standardisation mal comprise. On retrouve ici, encore, l'intérêt du Gemba : c'est le terrain qui guidera les apprentissages, dans cette séquence vertueuse. Expérimenter, observer, puis construire le standard, pour chaque cas spécifique. Tout l'inverse de l'approche top-down, qui impose un standard théorique avant la moindre observation.

Ce que la GenIA va changer dans nos équipes

Aujourd'hui, il est difficile de douter que l'IA accélère les développements. On est en revanche en droit de s'interroger sur l'impact que cette rapidité va avoir sur la structure même de nos équipes de développement.

Le constat de Samuel, partagé par de nombreuses autres sources, est que l'IA va devenir un allié de poids pour tester un nouveau business case en contexte d'incertitude, quand l'objectif est d'aller vite en production pour éprouver l'appétence des utilisateurs. Les binômes Développeur / Produit accompagnés d'une IA peuvent être redoutablement efficaces pour explorer une hypothèse. La véritable valeur de l'IA, ici, n'est donc pas dans le coût de « production de code », mais dans la réduction du délai entre une hypothèse et son test sur le terrain. En somme : réduire le lead time et augmenter le rythme d'apprentissage. Le Build-Measure-Learn du Lean Startup, cette pratique d'apprentissage rapide héritée du PDCA, qui vise à tester le plus souvent possible, devient alors un atout indiscutable. Dans ce cas métier, l'IA ne sert plus la productivité brute, mais le flux d'apprentissage.

Pour mener ces évolutions avec l'IA, il faudra apprendre sans cesse à dialoguer avec elle. Les développeurs devront donc apprendre à communiquer efficacement à l'IA le problème à résoudre, pour qu'elle se charge de la besogne d'écrire le code. Samuel décrit une façon de s'y prendre très intéressante. Il n'utilise pas le formalisme classique « En tant que… je veux… afin de… », bien connu de nos développeurs. À la place, il demande à l'IA de décrire le comportement actuel, puis il décrit le comportement attendu en précisant bien l'écart avec le point de départ. Cette pratique est particulièrement intéressante car elle repose sur la matérialisation de l'écart. L'IA fonctionne mieux quand on lui parle en termes d'écart à combler qu'en termes de fonctionnalité. C'est d'ailleurs la base même du PDCA, et la définition d'un problème en Lean. Tout cela impose de nombreux changements : au-delà de l'outil, c'est maintenant la manière de comprendre et d'exprimer les problèmes qu'il faut challenger. Et c'est finalement la capacité d'apprentissage rapide de l'organisation qui sera la plus mise à l'épreuve.

Le développeur comme expert métier

La question de savoir si l'IA remplacera les développeurs occupe nos esprits depuis cette irruption brutale de la GenAI et des Agents de développement. L'expérimentation menée par Peaksys ne va pas dans ce sens, mais elle ouvre une perspective de changement aussi intéressante que structurante.

L'IA va accélérer les tâches répétitives, comme les tests ou la génération de code prêt à revoir. Mais le niveau de qualité ne semble pas encore suffisant pour partir en production sur des systèmes complexes. Les revues semblent donc encore indispensables, même si des progrès très significatifs ont été faits entre les articles de Samuel et aujourd’hui, notamment avec les agents et leur feedback loop.

Un point nous intéresse tout particulièrement. L'expérimentation a clairement montré que travailler avec l'IA exige de maîtriser, plus que jamais, les gestes du développement. Le lien de causalité entre la qualité du code produit par le binôme ingénieur / agent et la compétence de l'ingénieur a été nettement établi. Car l'IA peut vite prendre de mauvaises directions. Il faut donc de la rigueur et de la standardisation pour maîtriser son usage, et repérer les cas où elle ne serait, au fond, que du gaspillage. Ce sera d'autant plus vrai quand les tokens atteindront leur véritable prix, c'est-à-dire un prix qui compense les pertes et génère du bénéfice pour les entreprises proposant des modèles. Les profils à risque sont donc ceux qui exécutent sans “penser” leur travail. Et c'est précisément une promesse du Lean : engager chaque collaborateur à “penser” son travail chaque jour, dans chaque geste. Cela en implique un autre : le besoin de maîtrise du métier, qui, dans ce mode de fonctionnement avec l'IA, sera encore plus fort. Chaque développeur devra devenir un expert métier, à tel point que Samuel se pose légitimement la question : un développeur du e-commerce pourra-t-il demain travailler dans la banque ?

D'autres évolutions peuvent toucher l'organisation des équipes. Là où nous avions des équipes réunissant toutes les compétences techniques nécessaires pour répondre à des problèmes business, on aura probablement demain des équipes d'ingénieurs plus proches des problématiques business, capables de développer tout le nécessaire quelle que soit la technologie. Attention à ne pas mal lire ce mouvement : il ne s'agit pas de profils moins compétents, mais de moins de spécialités techniques cloisonnées pour une expertise métier plus profonde. Ce qui pourrait demander moins de personnes pour traiter un sujet donné, mais des équipes globalement plus grandes afin de limiter le périmètre et les dépendances. Ces équipes se recomposeraient chaque jour, au daily, pour former de petites « subject teams » chargées de traiter un sujet précis dans son entièreté. Comme des feature teams sur des cycles très courts. Le daily tel que nous le connaissons n'aurait donc plus vraiment de sens.

Les articles font aussi apparaître d’autres impacts structurants. Le backlog, par exemple, répertorierait les changements côté utilisateur, et non plus les changements de produit. Les tickets ne seraient plus détaillés pour servir de documentation et celle qui serait nécessaire aux audits et à la traçabilité serait générée par l'IA à partir du code. Le code deviendrait la source de référence pour tout le monde. Mais comment, alors, détecter les écarts entre ce qui devrait être mis en place et ce qui l'est vraiment ? Cette faculté si puissante qu'on abordait plus haut ! Le paradoxe est là : l'outil qui nous aidait à voir l'écart peut, mal employé, devenir celui qui le masque à nouveau. Si le code devient la seule source de vérité et que c'est l'IA qui le documente, l'écart entre l'intention métier et l'exécution redevient invisible et on rendrait aveugle le système censé nous le faire voir. On touche ici au risque principal de l'IA : vouloir lui déléguer trop, trop vite, jusqu'à lui déléguer l'apprentissage lui-même, la laisser apprendre toujours plus, au détriment de l'apprentissage des personnes.

Conclusion

En introduction, je me posais trois questions :

• Quelle valeur l'IA apporte vraiment aux métiers de la tech ?
• Quels sont les impacts sur les processus de delivery, au quotidien ? Sur nos organisations ?
• Comment le Lean peut-il accompagner ce changement ?

Une chose est sûre : une erreur serait d'utiliser l'IA pour faire seulement plus vite, et un peu mieux, ce que nous faisons déjà. Ce serait optimiser le moyen sans questionner la finalité et risquer de faire plus vite les mauvaises choses. Il faut repenser le travail lui-même : moins de rétrospectives classiques, plus de boucles courtes, d’arrêts au défaut, de standards Lean, de feedbacks ciblés émergeant du terrain et tirés par la ligne managériale.

Côté organisations, le mouvement est déjà engagé : les directions qui commandent et contrôlent ne suivent plus le rythme, et l'IA ne fera qu'accentuer l'écart. C'est là que le Lean peut devenir un atout majeur par sa rigueur sur la mesure, le Gemba, le focus sur le spécifique et la maîtrise des gestes par le standard. Il pourrait bien être le “super-pouvoir” de demain : celui qui aide à penser le travail chaque jour et à remonter à la finalité avant d'optimiser le moyen. Sur la qualité, les articles sont sans ambiguïté : l'IA n'élève pas le niveau, elle l'amplifie. Elle rend donc le Jidoka encore plus critique, car l'IA amplifie les écarts, les bons comme les mauvais.

Reste la question à laquelle chacun devra rester attentif, ligne managériale comprise : l'IA aide-t-elle l'humain, ou l'humain se rend-il esclave de l'IA, en la surveillant en permanence ? Ce serait l'exact inverse de l'autonomation, qui vise à développer les compétences des personnes, pas celles des IA. C'est d'ailleurs le glissement que l'on sent parfois dans les articles : beaucoup sur l'apprentissage de l'IA, un peu moins sur celui des personnes. Et la performance mesurée en est presque absente : quid du lead time des fonctionnalités ? De leur coût ? Du flux dans son ensemble ? Autant de questions qui montrent que, loin d'être balayé par l'IA, le Lean a encore de beaux jours devant lui.