Pourquoi l’IA échoue dans la livraison logicielle agile : exemples et solutions pour les Engineering Managers

De nombreux CTOs placent beaucoup d’espoir dans l’utilisation de l’IA dans la livraison logicielle agile : plus de vitesse, plus d’automatisation, plus de rendement. Cela est souvent vrai à court terme. Et pourtant, beaucoup d’équipes et de CTOs échouent à démontrer comment cette accélération locale se traduit en bénéfice pour le client et en valeur ajoutée pour l’entreprise.

Le problème, c’est que les entreprises, dans l’enthousiasme pour l’IA, optimisent les mauvaises choses : plus de tokens au lieu de plus de valeur pour le client, plus de code au lieu de plus de confiance, plus d’agents au lieu de meilleurs systèmes de livraison.

Cet article s’inscrit volontairement dans la continuité de nos deux autres articles :

• L’IA dans le développement logiciel agile : état de la recherche 2026 .
• Guide pour les CTO et les Engineering Managers sur le développement logiciel assisté par l’IA .

Ici, il s’agit du pont entre les deux : pourquoi l’IA échoue-t-elle dans la livraison logicielle agile dans la pratique ? Les exemples montreront concrètement ce que les managers peuvent faire et quelles solutions tiennent réellement la route.

Pourquoi l’IA optimise si souvent le mauvais objectif dans la livraison logicielle agile

Dès que l’IA est introduite comme levier de productivité, quelque chose de très prévisible se produit dans de nombreuses entreprises : ce qui est mesurable devient l’objectif. Cela se reflète dans la nouvelle tendance Tokenmaxxing. Pragmatic Engineer sur la tendance Tokenmaxxing

Par là, on entend que les entreprises ou les équipes considèrent implicitement ou explicitement une consommation élevée de tokens comme un signe de bonne utilisation de l’IA. C’est dangereux, tant sur le plan économique que sur le plan organisationnel. Car les tokens sont au mieux une mesure d’entrée, mais pas une mesure de valeur.

Le schéma est ancien. Autrefois, les “Lines of Code” étaient surévaluées comme métrique ; aujourd’hui, c’est la consommation de tokens ou les tableaux de bord d’utilisation de l’IA. Dans les deux cas, une variante de la loi de Goodhart s’applique : dès qu’une métrique devient un objectif, elle perd sa valeur en tant que métrique. Martin Fowler sur les Lines of Code comme problème de métrique, Wikipedia sur la loi de Goodhart

Pour l’IA dans la livraison logicielle agile, cela signifie ceci : qui maximise l’activité à court terme obtient souvent davantage d’activité IA. Mais pas automatiquement une meilleure livraison logicielle agile.

L’état de la recherche à ce sujet est décevant : au niveau individuel, on observe déjà des effets de productivité nets ; au niveau de l’équipe et de l’organisation, en revanche, beaucoup moins d’améliorations réellement solides. Nous avons résumé les détails ici : Sur l’état des études en 2026 sur l’IA dans le développement logiciel agile

Quatre exemples typiques de la manière dont l’IA échoue dans la livraison logicielle agile

Le premier échec est banal : les équipes produisent nettement plus de modifications, mais comprennent vraiment une part décroissante de celles-ci.

Pour les managers, cela paraît souvent positif au début :

• plus de pull requests
• des premières implémentations plus rapides
• plus d’histoires “terminées”

La contrepartie apparaît plus tard :

• les revues deviennent plus superficielles
• l’ownership se dilue
• l’analyse des incidents prend plus de temps
• les refactorings sont évités parce que plus personne n’est sûr de ce qui pourrait casser et où

Kent Beck décrit dans son article “Trust Factory” que des pratiques comme les tests, les revues, le refactoring et la livraison incrémentale construisent avant tout la confiance. C’est précisément cette confiance qui disparaît lorsque l’IA produit plus vite que l’équipe ne peut comprendre, vérifier et assumer la responsabilité de ce qu’elle produit. Kent Beck dans Trust Factory sur la confiance en ingénierie

Addy Osmani décrit un risque similaire sous le nom de Comprehension Debt : lorsque les équipes livrent toujours plus de code qu’elles ne parviennent plus à comprendre activement, la distance entre le système et la compréhension s’accroît à chaque changement. Addy Osmani sur la Comprehension Debt

Cela concorde aussi avec des constats plus généraux issus du terrain : selon une enquête Sonar résumée en 2026, la plupart des développeurs ne font pas entièrement confiance à la correction fonctionnelle du code généré par IA, et une part importante estime même que sa revue est plus coûteuse que celle de modifications écrites par des humains. Le problème n’est donc pas seulement la mauvaise qualité, mais aussi un surcroît d’effort de vérification et de compréhension. ITPro sur l’enquête Sonar concernant la dette de vérification

Le deuxième échec est encore plus coûteux pour les dirigeants : l’IA réduit le coût de la production, mais pas automatiquement le coût de l’erreur.

Lorsque les équipes ont mal découpé les exigences, les ont insuffisamment validées ou se sont contentées de s’aligner en interne, l’IA ne fait qu’accélérer le mauvais travail. Kelsey Hightower le formule très directement dans son post LinkedIn : “Productivity doesn’t matter if you’re working on the wrong thing.” Post LinkedIn de Kelsey Hightower sur la fausse productivité

C’est exactement dans cette direction qu’Andrew Ng avance aussi dans une conversation très citée en 2025 : l’IA a fortement accéléré le coding, mais cela déplace le véritable goulot d’étranglement. Le principal problème n’est plus l’exécution, mais la question produit :

Que devons-nous construire, au juste, et à quelle vitesse apprenons-nous à partir des retours réels des utilisateurs ?

Source : Entretien de Business Insider avec Andrew Ng sur le goulot d’étranglement du Product Management

C’est la raison pour laquelle l’IA dans une livraison logicielle agile ne peut réussir qu’avec une véritable proximité client. Si le chemin du prompt au code devient plus rapide, mais que le chemin du code au feedback client reste lent, seuls le volume de production et le volume de changements augmentent.

La recherche sur le travail produit agile montre aussi exactement ce schéma à un autre niveau : dans une étude de cas industrielle sur les Agile Epics, des chercheurs décrivent que des exigences mal définies entraînent du churn, des retards, des problèmes de qualité et des coûts inutiles. L’IA ne peut pas résoudre magiquement de tels goulots d’étranglement. Elle peut tout au plus les matérialiser plus vite. Étude ArXiv sur les Agile Epics et la qualité des exigences

C’est pourquoi le contrepoids décisif à une utilisation aveugle de l’IA n’est pas moins d’IA, mais une meilleure livraison agile. Ceux qui cherchent les leviers transversaux pour cela les trouvent ici : Guide sur l’avenir du développement logiciel agile assisté par l’IA

De nombreuses visions d’avenir de l’IA dans la livraison logicielle agile paraissent attrayantes, parce qu’elles rendent la responsabilité élégamment invisible : un agent analyse les retours des utilisateurs, le suivant rédige les exigences, le suivant implémente, le suivant teste et le suivant déploie.

Techniquement, une partie de cela est faisable. Sur le plan organisationnel, cela devient vite flou.

Surtout dans le développement logiciel agentique, il faut donc poser plus fermement l’ancienne question managériale : qui décide ? Qui vérifie ? Qui assume les conséquences ? IBM formule le problème de fond dans un aperçu éclairant sur l’AI decision-making : la responsabilité reste humaine, surtout lorsque des systèmes préparent ou accélèrent des décisions. IBM sur la responsabilité dans l’AI decision-making

L’AI Agile Manifesto met lui aussi ici le bon contrepoint : plus d’intelligence machine sans jugement humain n’est pas un progrès, mais une mauvaise voie. AI Agile Manifesto dans sa version originale

C’est précisément pourquoi il ne suffit pas de parler uniquement des capacités des outils. Dès lors que des agents interprètent des exigences, effectuent des changements ou déclenchent même des actions proches de la production, la responsabilité doit devenir organisationnellement plus claire et plus visible.

Le quatrième échec n’apparaît souvent qu’avec retard : certaines développeuses ou certaines équipes semblent extrêmement productives, tandis que l’organisation dans son ensemble devient plus lente.

Cela se produit lorsque chacun optimise localement avec l’IA, mais que presque personne ne renforce le système dans son ensemble :

• Les principes d’architecture sont appliqués de manière incohérente
• les mêmes problèmes sont résolus plusieurs fois en parallèle
• les systèmes de revue et de test sont contournés
• les pipelines de livraison deviennent un point de congestion
• La charge d’incidents et le travail de reprise augmentent

Birgitta Böckeler explique dans son entretien avec InfoQ sur le Harness Engineering pourquoi une autonomie plus élevée implique toujours aussi des risques plus élevés et doit être limitée par des mécanismes de feedforward et de feedback appropriés. Podcast InfoQ avec Birgitta Böckeler sur le Harness Engineering

Que ce ne soit pas un risque théorique, plusieurs cas rendus publics le montrent. Selon des rapports, Amazon a durci en 2026 ses garde-fous internes après de graves séries d’incidents, dans lesquels des systèmes agentiques ou proches de l’IA ont également été cités comme facteur contributif. La leçon qui en a été tirée était éloquente : davantage de changements documentés, davantage de validations, davantage de « controlled friction » dans les systèmes critiques. Autrement dit : toute accélération locale n’améliore pas forcément le système global. Parfois, elle ne fait que rendre ses faiblesses plus visibles plus vite. Rapport de Business Insider sur les garde-fous IA renforcés d’Amazon

Une deuxième forme différente de la même entropie apparaît avec le « Vibe Coding » assisté par l’IA. Axios a rapporté en 2026, citant des chercheurs en sécurité, l’existence de centaines de milliers d’artefacts accessibles publiquement, dont des milliers contenant des données d’entreprise sensibles. Ici, ce n’est pas principalement un seul prompt qui échoue, mais l’ensemble du système composé de standards, d’accès, de valeurs par défaut, de compréhension de la sécurité et de gouvernance. Rapport d’Axios sur le Vibe Coding et les artefacts accessibles publiquement

En bref : plus l’IA est autonome, plus le cadre organisationnel et technique dans lequel elle opère est important.

Pourquoi la productivité à court terme et le tokenmaxxing sont la mauvaise stratégie en matière d’IA

Certains dirigeants réagissent au nouveau levier de l’IA par une conclusion simple : alors, il faut simplement imposer aussi vite que possible et autant que possible l’utilisation de l’IA.

C’est exactement la mauvaise réaction managériale.

Pourquoi ?

Parce que « short term productivity » dans ce contexte signifie généralement seulement ce qui suit :

• plus de code généré
• plus de sessions d’IA
• plus de consommation de tokens
• davantage de tâches résolues en local

Mais tout cela ne dit encore presque rien sur les questions qui sont réellement décisives pour l’IA dans la delivery logicielle agile :

• Le bon problème a-t-il été résolu ?
• L’équipe comprend-elle le changement ?
• Le changement peut-il être déployé en toute sécurité ?
• Le système est-il meilleur ou plus fragile après le changement ?
• L’organisation apprend-elle plus vite ou seulement de manière plus fébrile ?

C’est précisément pour cela que le tokenmaxxing est un si bon signal d’alerte. Il montre ce qui se passe lorsque les entreprises traitent l’usage de l’IA comme une fin en soi. Les collaborateurs maximisent alors exactement ce qui est récompensé de manière visible, même si cela accroît les coûts, l’entropie et la navigation à l’aveugle. Pragmatic Engineer sur la tendance du tokenmaxxing

Jez Humble a décrit clairement ce problème de management bien avant la vague actuelle d’IA : lorsque les managers se concentrent directement sur la productivité, les améliorations à long terme ne sont souvent précisément pas réalisées. Pour l’IA dans la livraison logicielle agile, cela est encore accentué. Jez Humble sur l’accent mis sur la productivité et l’absence d’améliorations à long terme

Ce qui fonctionne à la place : quatre solutions robustes pour l’IA dans la livraison logicielle agile

1. Maintenir explicitement la responsabilité chez l’humain

L’IA peut accélérer, proposer et soulager. Mais elle ne doit pas devenir une excuse pour que la responsabilité des décisions et de la qualité se dilue.

En pratique, cela signifie :

• des responsables clairement identifiés pour l’architecture, la sécurité et les décisions pertinentes pour le produit
• aucune métrique de succès qui récompense simplement l’activité de l’IA
• des règles explicites de revue et de validation pour les modifications générées par l’IA

2. Construire un environnement d’ingénierie plutôt que de simples outils d’IA

Beaucoup d’équipes investissent d’abord dans les modèles et seulement ensuite dans les conditions dans lesquelles ces modèles peuvent fonctionner en sécurité. Il faut exactement inverser cela.

Un environnement robuste pour l’IA dans la delivery logicielle agile comprend par exemple :

• de bonnes spécifications
• de petits lots de travail vérifiables
• des tests automatisés
• l’analyse statique
• des sandbox contrôlées
• des contextes d’architecture clairs
• un retour rapide depuis la CI, la delivery et la production

Si cette idée vous intéresse, OpenSpec et le GitHub Spec Kit sont aussi des références utiles sur le travail guidé par les spécifications avec l’IA : OpenSpec pour le développement de produits guidé par les spécifications, GitHub Spec Kit pour le développement spec-driven

3. Rendre le feedback client plus rapide que la production de code

L’IA n’est un levier de delivery durable que si les cycles d’apprentissage s’accélèrent aussi. Sinon, on produit simplement plus vite, mais à côté de la réalité.

Concrètement, cela signifie :

• des releases plus petites
• davantage d’expérimentations avec de véritables boucles de feedback clients
• une analyse plus systématique des données d’utilisation des fonctionnalités
• une analyse plus rapide des signaux de support et des utilisateurs

Se contenter d’augmenter la vitesse de codage, sans augmenter la vitesse et la qualité du feedback, ne construit pas une organisation AI-native, mais seulement une « Feature Factory » plus rapide, comme le décrit John Cutler. Voir : 12 signs you’re working in a feature factory

4. Prendre au sérieux les rétrospectives et les boucles d’apprentissage

Lorsque l’IA échoue dans la delivery logicielle agile, les causes sont souvent systémiques. Dans ce cas, il sert à peu de chose d’optimiser seulement des prompts ou des outils isolés.

Les équipes ont besoin de routines leur permettant de rendre visibles les schémas récurrents et de les résoudre systématiquement :

• Où perdons-nous la compréhension ?
• Où s’accumule le goulot d’étranglement des revues ?
• Où l’IA crée-t-elle plus de travail de reprise que de bénéfices ?
• Où optimisons-nous la vitesse locale au détriment du système global ?

C’est précisément pour cela que les rétrospectives restent pertinentes. Pas comme un rituel hérité du passé Scrum, mais comme un mécanisme d’apprentissage organisationnel dans un environnement à fréquence de changement plus élevée.

Conclusion : l’IA dans la delivery logicielle agile échoue rarement par manque d’IA

La véritable ironie est la suivante : de nombreuses organisations échouent avec l’IA non pas parce qu’elles sont trop prudentes, mais parce qu’elles pilotent à trop court terme.

Elles confondent productivité à court terme et création de valeur durable ainsi qu’amélioration du système de delivery. Elles confondent consommation de tokens et création de valeur. Elles confondent génération autonome de code et maturité organisationnelle.

La meilleure question directrice n’est donc pas : “Comment amener nos équipes à utiliser encore plus l’IA ?”

Mais plutôt :

• Dans quelles conditions l’IA améliore-t-elle vraiment notre delivery ?
• Où l’IA crée-t-elle actuellement de nouveaux goulots d’étranglement dans la chaîne de valeur ?
• Où l’IA met-elle au jour des lacunes systémiques que nous devons corriger ?
• Quelles capacités organisationnelles devons-nous renforcer pour que l’accélération ne se transforme pas en entropie ?

Si vous voulez d’abord des preuves factuelles et sobres, lisez la suite ici : état des études sur l’IA dans le développement logiciel agile .

Si vous cherchez directement des leviers de management, allez plus loin ici : Guide pour les CTO et les Engineering Managers sur l’IA dans le développement logiciel agile .

FAQ sur l’IA dans la livraison logicielle agile

Pourquoi l’IA donne-t-elle plus de output à mon équipe, mais pas une meilleure delivery ?

Parce que plus de output ne signifie pas automatiquement une meilleure delivery. Si les revues, les tests et le feedback ne suivent pas, c’est surtout la complexité qui augmente.

Que signifie le tokenmaxxing dans le développement logiciel assisté par l’IA ?

Le tokenmaxxing consiste à faire de l’usage de l’IA ou de la consommation de tokens un objectif. Cela mesure l’activité, pas la valeur.

Que devraient faire les Engineering Managers au lieu de simplement pousser la productivité IA ?

Ils devraient renforcer la responsabilité, les tests, les revues et les boucles de feedback. C’est seulement cela qui rend l’IA utile à long terme.

Les équipes très assistées par l’IA ont-elles encore besoin de rituels agiles ?

Oui, mais avec un autre focus. Moins de suivi de statut, plus de feedback, d’apprentissage et d’amélioration continue.

Comment puis-je mesurer, en tant qu’Engineering Manager, si l’IA apporte vraiment quelque chose dans le développement logiciel ?

Mesurez le Lead Time, l’effort de revue, le taux d’erreurs et la valeur pour le client. Le simple volume de production ne suffit pas.

Pourquoi mon équipe devient-elle plus rapide avec l’IA, mais les résultats ne s’améliorent-ils pas ?

Parce que plus de code ne produit pas automatiquement de meilleurs résultats. Sans revues soignées, tests et retours, seule l’entropie augmente.

Quels KPI devrais-je vraiment suivre pour l’IA dans le développement logiciel ?

Suivez le temps de cycle, le taux de défauts, le rework, la sécurité des déploiements et le délai jusqu’au retour client. Les tokens seuls en disent trop peu.

Comment puis-je empêcher que du code généré par l’IA ralentisse mon équipe plus tard ?

Gardez les changements petits, testez-les soigneusement et exigez une revue claire. L’IA peut apporter de la rapidité, mais pas remplacer la compréhension.