Lean et IA : suivre le travail jusqu'à l'utilisateur

L’IA facilite la production d’un brouillon, d’une spécification, d’une pull request ou d’une réponse client. Cela n’est utile que si le travail est retenu lors de la décision suivante et atteint la personne qu’il devait aider. Une étape plus rapide peut alimenter une file d’attente plus longue.

Coder plus vite déplace le coût vers la vérification développe le diagnostic pour la livraison logicielle : files de review, CI, corrections et travail accepté.

Partir de la demande, pas de l’outil

Le Lean part de la valeur telle que le client la perçoit et de la succession de travaux nécessaires pour la lui fournir. Le Toyota Production System décrit deux principes utiles : le Just-in-Time, produire ce qui est nécessaire au moment où cela l’est, et le jidoka, détecter un problème et arrêter pour empêcher le travail défectueux de passer à l’étape suivante. Ces principes viennent de l’industrie. Les appliquer à un service assisté par l’IA est une analogie et un choix de conception, pas une preuve qu’une équipe logicielle reproduira les résultats de Toyota.

Pour une modification logicielle, la séquence peut aller du problème client à la décision produit, puis à l’implémentation, à la review, aux tests, à la release, à l’adoption et au support. Pour le service client, elle peut aller d’une demande à sa classification, à la collecte de preuves, à une proposition de réponse, à l’approbation, à l’envoi et à la résolution. Dans les deux cas, générer plus vite l’artefact intermédiaire est une amélioration locale. L’utilisateur vit la fin de la séquence.

Andrew Ng a décrit le travail produit, juridique et marketing comme des contraintes possibles une fois que l’ingénierie accélère. C’est l’observation d’un praticien, pas une loi mesurée des goulots d’étranglement. Elle invite utilement à regarder au-delà du code avant d’acheter davantage de capacité de développement.

Tracer le parcours d’une demande réelle

Choisissez un type de demande et suivez un petit échantillon de demandes terminées. Notez quand chacune entre et sort de chaque étape. Incluez le travail rejeté et les corrections, pas seulement les releases réussies. Utilisez la même définition et la même fenêtre d’observation avant et après la modification du workflow.

1. 01 · EntréeDécider de ce qui mérite d’être résolu.
2. 02 · CréationProduire l’artefact.
3. 03 · VérificationContrôler la justesse et la qualité.
4. 04 · LivraisonAtteindre l’utilisateur visé.
5. 05 · RésultatVérifier le résultat attendu.

N’additionnez pas ces lignes pour créer un score magique de productivité. Leur intérêt est diagnostique. Si le temps de création baisse tandis que celui de vérification augmente, la contrainte a peut-être changé de place. Si la livraison accélère sans que les résultats changent, ce parcours plus rapide transporte peut-être du travail dont les utilisateurs n’ont pas besoin.

L’unité compte. Un nombre de pull requests n’est pas un nombre de modifications utiles, de même qu’un nombre de réponses du support n’est pas un nombre de cas résolus. Choisissez un résultat et gardez son dénominateur visible : utilisateurs ciblés, demandes éligibles ou tâches acceptées.

Ajouter un signal d’arrêt là où les erreurs coûtent cher

Le jidoka est souvent réduit à « add more automated tests » (traduction : « ajouter davantage de tests automatisés »). La question plus exigeante est de savoir où le processus détecte un défaut, qui peut arrêter le flux et comment sa cause est supprimée avant que le même défaut revienne. Dans un workflow d’IA, une évaluation en échec, une affirmation sans preuve ou un reviewer incapable de comprendre une modification doivent être visibles avant la publication ou la release.

Cela n’exige pas le même examen pour chaque élément. Un travail réversible à faible risque peut suivre un parcours court. Une modification qui a un large rayon d’impact, concerne des données sensibles ou a un effet irréversible sur l’utilisateur exige un contrôle plus poussé. Définissez ces parcours avant que la file se remplisse et notez à quelle fréquence le parcours plus exigeant détecte un problème significatif. Une étape de review que personne n’a la capacité d’assurer ne fait que cacher le travail dans une nouvelle salle d’attente.

L’analyse qualitative de DORA portant sur les réponses de 1 110 ingénieurs de Google rapporte que l’IA peut déplacer le travail des développeurs vers l’audit et la vérification. Ces réponses décrivent un changement vécu ; elles n’établissent pas que chaque équipe connaîtra le même effet. Elles justifient de mesurer l’effort de review en plus de la vitesse de génération.

Préparer le repository avant d’ajouter de la capacité agentique

Dans une conférence FlowCon sur les standards Lean pour l’IA, Marek Kalnik de Theodo montre un agent qui produit des clés de traduction incohérentes à partir d’un repository qui mélangeait déjà conventions de nommage et langues. Il décrit des standards de travail partagés et des critères pour un projet que les agents peuvent utiliser de façon fiable. L’exemple désigne une source plausible de reprises ; il ne mesure pas le temps ou l’argent économisés grâce à ces standards.

Le modèle Agent Readiness de Factory vérifie l’état du repository : commandes de build, tests, instructions, observabilité et sécurité, entre autres. Dans la conférence d’Eno Reyes, l’ordre suggéré est de rendre une tâche vérifiable avant d’en assigner beaucoup en parallèle. Un test ciblé qui détecte la mauvaise clé de traduction est un équivalent logiciel du poka-yoke, ou prévention des erreurs. Un ingénieur qui connaît le repository doit choisir l’erreur qui compte et vérifier que le contrôle la détecte. Un fichier de configuration ou un score de préparation ne suffit pas à montrer que l’erreur a été évitée.

Je commencerais par un échec récurrent dans une tâche réelle, modifierais le contrôle ou l’instruction qui l’a laissé passer, puis répéterais un travail comparable avec le même modèle et les mêmes critères d’acceptation. Je noterais les nouvelles tentatives, les tokens utilisés et les corrections des reviewers, puis suivrais le travail accepté jusqu’à la release et au résultat utilisateur visé. La grille à cinq niveaux de Factory peut aider à localiser un manque, mais son score ne mesure ni la valeur client ni la productivité des agents dans une comparaison contrôlée.

Tester une erreur que le harnais n’a pas détectée

Une migration legacy fournit un test concret. Supposons qu’un agent cite une vraie ligne source, mais lise mal un opérateur ou manque un effet de bord dans une bibliothèque. Le contrôle de citation passe, alors que l’affirmation sur le comportement est fausse. Je garderais ce contrôle, demanderais à un reviewer distinct de suivre le chemin d’appel et exécuterais des cas de caractérisation sur l’application existante avant de la modifier. La première unité migrée devrait atteindre les étapes normales de review et de release avant que des agents en parallèle prennent en charge d’autres unités. Une cartographie fondée sur les seules sources est une piste d’investigation, pas une permission de migrer un comportement non observé.

Le contrôle a son propre coût. Suivez les faux blocages, les exécutions répétées de CI, les reprises manuelles, l’effort de review et la maintenance, en plus des modifications acceptées. Pour un format de fichier fragile, testez que le chemin d’édition réel préserve les octets et les fins de ligne, y compris une écriture par un autre outil. Une règle installée dans un repository ne prouve pas que l’agent en cours d’exécution l’a respectée. Le guide développe cette démarche comme une boucle de contre-mesures pour le harnais d’un repository, en traitant la sélection du contexte et le choix de méthode comme des décisions distinctes. C’est une proposition de protocole de test, pas un gain de migration mesuré.

Respecter le périmètre des preuves

Deux études de terrain montrent pourquoi une métrique de production exige un contrôle en aval. Dans le déploiement d’agents CLI chez Microsoft début 2026, les utilisateurs ayant adopté ces agents ont mergé environ 24 % de pull requests de plus sur la fenêtre d’observation de quatre mois. Une étude dans une entreprise très engagée dans l’IA a trouvé un débit de PR mergées par personne égal à 2,09 fois son niveau avant l’obligation d’usage, tandis que la charge des reviewers doublait à peu près. Les deux comptent des PR mergées. Aucune ne mesure la valeur client, et la seconde ne peut pas isoler l’IA comme seule cause du changement.

Une étude de cas ICSE-SEIP de six semaines chez Globo offre un contre-exemple utile à l’idée que la review doit absorber tout gain. Les tâches que l’équipe avait marquées comme utilisant la GenAI avaient un temps de cycle de développement Jira moyen inférieur de 23 % à la valeur historique de l’entreprise. La participation était volontaire, l’équipe étiquetait elle-même les tâches et la comparaison n’était pas randomisée. L’article n’établit pas si l’IA a causé la différence, si la composition des tâches était équivalente, ni si la qualité des releases et les résultats utilisateurs se sont améliorés. Il établit qu’une file plus longue en aval est une hypothèse à tester, pas un résultat à présumer.

Ces études sont pertinentes parce qu’elles montrent que les capacités de création et d’acceptation peuvent croître à des rythmes différents. Elles ne disent pas à une autre organisation quel sera son propre gain. L’avertissement d’un product manager de Doctolib exprime le même point comme témoignage de praticien : davantage de demandes d’IA pourraient aussi signifier davantage de bugs. Cet avertissement invite à vérifier les défauts ; il n’affirme pas que les bugs y ont effectivement doublé.

Ce que mesurent réellement les cas d’entreprise

Qonto : du code migré

Qonto fournit un exemple concret de Lean appliqué à une tâche d’ingénierie assistée par l’IA. En janvier 2025, une petite équipe a lancé un kaizen pour migrer une application Ember vers React. Son retour d’ingénierie décrit une CLI qui exécute une conversion par IA, un codemod déterministe, une seconde passe d’IA et une review humaine. Un ingénieur, avec une aide limitée, a migré 8 632 lignes lors d’une évaluation de deux semaines commencée le 10 février. Les quelque 50 lignes par jour-ingénieur sans l’outil avancées par Qonto étaient une estimation, pas un groupe témoin observé. Le pic rapporté de 20 fois la production manuelle est donc une comparaison avec cette estimation, et l’unité est le code migré. Le récit ne donne pas le coût complet de review, le taux de défauts après intégration ni le délai avant que les clients bénéficient de la migration.

Le kaizen compte davantage que le multiplicateur affiché. Qonto a d’abord essayé un chatbot web, puis a intégré la conversion au workflow de développement, avant de reconsidérer la CLI parce que les ingénieurs préféraient une extension d’IDE. Sa conférence antérieure sur la qualité aborde le travail réussi du premier coup et la limitation du travail en cours. Cette conférence de 2023 précède l’expérience de migration ; elle établit un vocabulaire Lean préexistant, pas l’effet de l’IA. Dans une déclaration de vision de 2026, le président de Qonto invoque jidoka et kaizen pour l’IA dans les workflows financiers. Une orientation annoncée n’est pas un résultat produit mesuré.

Theodo : des fonctionnalités livrées

Theodo rapporte une autre unité. Son récit ComPaRe EMA indique que quinze fonctionnalités ont atteint la production en trois semaines pour l’AP-HP. Les deux mois de comparaison correspondent au délai de livraison estimé par l’équipe sans agents. Le cas décrit un humain qui vérifie la stratégie technique, les tests et le code, et arrête l’agent pour améliorer les instructions ou les contrôles quand il échoue. Ce sont des choix de contrôle observables ; l’article ne publie pas l’adoption ultérieure ni une série comparable de défauts. Dans une conférence distincte, Fabrice Bernhard décrit une équipe confrontée à des pull requests d’environ 4 000 lignes sur 53 fichiers. L’équipe a mesuré le délai de merge et essayé des modèles de code réutilisables pour concentrer la review. La conférence rapporte une baisse du délai de merge, sans série publiée ni résultat utilisateur. Ne fusionnez pas ces deux récits en un seul projet mesuré.

Siemens : des décisions et une culture de la qualité

Une étude de praticiens sur cinq ans chez Siemens Electronics Works Amberg examine une autre question : comment les décisions d’IA s’inscrivent dans une culture Lean de la qualité. Van Giffen et ses coauteurs identifient des tensions entre analyse humaine et analyse par IA, raisonnement transparent et opaque, processus guidés par les spécifications et par les données. L’étude propose des moyens de gérer ces tensions. Elle ne quantifie pas de gain de vitesse ou de qualité dû à l’IA. Pour les équipes logicielles, la leçon pratique est de préserver la capacité du responsable du processus à inspecter une recommandation et à décider ce qui s’arrête lorsqu’elle est fausse. C’est une application au logiciel, pas un résultat mesuré chez Siemens.

RootCoach : le raisonnement et l’autonomie

Le sens inverse, l’IA au service d’une pratique Lean existante, est visible au Lean Enterprise Institute. Art Smalley décrit RootCoach, un outil qui critique le raisonnement sur les causes racines. Son affirmation selon laquelle il dépasse 90 % du coaching qu’il a vu est un jugement personnel, sans comparaison en aveugle publiée. Matthew Savas nomme le risque : des retours d’IA fréquents peuvent transformer l’outil en autorité et remplacer le dialogue par lequel un manager développe les capacités de résolution de problèmes d’une personne. Une évaluation utile mesurerait la qualité du raisonnement et l’autonomie ultérieure de la personne, pas le nombre de documents A3 générés.

Open source : des contrôles inspectables

Les projets open source rendent certaines de ces idées inspectables. Andon consigne les défauts récurrents des agents et propose des hooks comme contre-mesures ; son propre README indique qu’un contrôle de fin peut accepter une entrée de vérification rédigée par l’agent alors qu’elle est fausse. RaiSE et AI-Kaizen décrivent des workflows Lean ou PDCA. Leurs repositories montrent des contrôles proposés, pas des améliorations des résultats clients mesurées indépendamment.

Mener une amélioration bornée

Avant d’ajouter de l’IA à une étape, notez le type de demande, le résultat utilisateur visé et les points d’attente actuels. Puis modifiez une étape et comparez des demandes équivalentes sur des fenêtres équivalentes. Gardez ensemble quatre observations : délai jusqu’au résultat accepté, temps d’attente, taux de correction ou d’échec et effort humain sur tout le parcours. Les métriques de livraison de DORA aident pour la partie release ; elles ne remplacent pas un résultat produit ou service.

Pour un workflow logiciel concret, mon guide Du code au merge suit les contrôles locaux, les reviews par IA, les corrections et la décision humaine de merge. Son dernier chapitre applique cette amélioration bornée à une PR récente, en séparant attente, effort humain, reprises et coût.

Si un nouvel outil réduit le temps de rédaction mais augmente l’effort de review ou de support, ajustez le travail admis dans la file, la méthode de vérification ou la frontière de la tâche. Si le résultat de bout en bout s’améliore sans dégrader la qualité ni la santé de l’équipe, étendez prudemment la démarche au type de demande suivant. Il s’agit d’apprendre du système que vous faites réellement fonctionner, pas d’importer un pourcentage de productivité depuis l’étude de quelqu’un d’autre.

Pour les équipes logicielles, le chapitre du guide sur les métriques d’équipe développe la mesure. Mon analyse de la productivité de l’IA examine plus en détail les dénominateurs des études de terrain. Le rôle de cet article est plus restreint : garder la demande utilisateur en vue quand le milieu du workflow devient très rapide.