L'IA a accéléré le code, mais pas le delivery

Avec l'IA, les développeurs produisent du code bien plus vite. Mais leurs clients attendent toujours : le système de delivery de bout en bout n'a pas été repensé autour de cette nouvelle vitesse.

J’accompagnais des développeurs pour réduire les délais de mise en production de nouvelles fonctionnalités d’un logiciel métier. C’est alors que j'ai suivi une demande, un jour, de bout en bout. Les développeurs l'avaient implémentée en quatre jours ouvrés. Mais au bout du compte, le client, lui, avait attendu quarante-cinq jours. Pendant les quarante et un autres jours, pour différents métiers (sécurité, cloud, réseau, test, etc.), la demande était dans des files d’attente : priorisation, revue, validation, derrière d'autres travaux. Bien entendu, lors des quatre jours qu’ils ont passé à coder, concernent leur délai interne, tout semblait normal pour les développeurs.

Cette situation n'est plus une anecdote. C'est devenu la réalité de beaucoup d’organisations qui ont déployé l'IA dans leurs équipes de développement. En effet, produire du code n'a jamais été aussi rapide. En revanche, le métier n’en bénéficie pas plus rapidement qu’auparavant. Et quelqu'un, haut placé dans la hiérarchie, exige maintenant le ROI de ces investissements dans l’IA.

J’améliore des systèmes de delivery pour la tech depuis plus de quinze ans maintenant. J’ai travaillé en banque, industrie, énergie, secteur public ; tout cela, bien avant le premier prompt. Ce que l'IA expose aujourd'hui, je l’observais déjà il y a une décennie. La seule différence maintenant, c'est qu'elle a rendu le problème impossible à ignorer.

Des chiffres publics confirment ce que j’ai vu. L’étude de Faros AI, sur 22 000 développeurs, montre un temps de revue (après développement) médian en hausse de 441 %, et 31 % de pull requests en plus qui fusionnent sans aucune revue. Le rapport DORA 2025 le pose sans détour : l'adoption de l'IA augmente la production, et en même temps l'instabilité. Sa conclusion tient en une phrase : réussir avec l'IA est un problème de système, pas un problème d'outil. L'IA a parfaitement tenu sa promesse ici : elle a accéléré l'écriture du code, or c’est la seule étape qui était déjà rapide. Le goulot d’étranglement s'est juste déplacé ailleurs dans les processus de travail.

Jusque-là, tout le monde est d'accord. Ce constat traîne partout depuis un an. Du coup la question intéressante n'est plus le diagnostic, mais plutôt ce que vous en faites maintenant.

Les deux horloges

Il existe deux horloges, et la plupart des équipes de développement n'en regardent qu'une.

La première mesure le temps consacré par une équipe pour produire un élément, selon son principal processus de travail. La seconde mesure l'attente du client, depuis la date de sa demande initiale jusqu’à sa mise en production effective. La première mesure un délai interne d’une équipe parmi d’autres, la seconde le délai réel pour le client. Aujourd’hui, concernant les développeurs, les outils IA améliorent la première. Or le client, lui, ne vit que la seconde : le délai de production de bout en bout.

Revenons à cette demande que j’ai suivie : elle a mis quatre jours sur la première horloge, et quarante-cinq selon celle du client. Les développeurs lisaient la leur, mais seule celle du client importe réellement. Le piège est mécanique : la vélocité des développeurs peut grimper pendant que le client attend plus longtemps.

Le goulot remonte

Il y a une bonne nouvelle quand même. Le goulot de la revue (dont parlait entre autres l(étude Faros) est désormais attaqué au niveau de l'outillage IA, et par ceux-là mêmes qui ont créé cette vitesse dont nous parlons.

Prenons le cas d’OpenAI. La quasi-totalité de leurs ingénieurs utilise désormais Codex, contre à peine plus de la moitié quelques mois plus tôt. Et depuis qu'ils l'ont adopté, ils fusionnent 70 % de pull requests de plus chaque semaine. La revue humaine ne pouvant pas absorber ce volume, c’est Codex qui relit lui-même presque chaque PR avant qu'une personne ne la voie. Anthropic a placé un système de revue multi-agents devant le flux. D'autres éditeurs construisent le leur, découpant le travail entre agents de coordination, d'implémentation et de vérification.

Regardons de près ce qu'ils ont fait, car ils n'ont pas acheté un outil en plus. En réalité, ils ont redessiné leur système de revue autour de la nouvelle vitesse (celle de l’écriture de code). Le créateur de l'outil a fait face à sa propre contrainte en premier, et il a eu la discipline de la traiter comme un problème de système.

Maintenant, voyons ce qui reste quand des agents IA ont fini une revue. C’est encore le jugement : quoi construire, ce qui a du sens, quel compromis accepter. C'était la vraie contrainte du processus de revue depuis le début. Car en réalité, les outils IA font la reconnaissance de patterns et la vérification. Elles ne décident pas vraiment quelles fonctionnalités livrer, ni quels compromis accepter.

Et c'est là que la plupart des analyses s'arrêtent, en concluant qu'il faut recruter des profils plus expérimentés. Pour moi, c'est une erreur de diagnostic. Le jugement n'est pas une compétence à acheter sur le marché. C'est votre nouveau goulot. Et celui-là ne se recrute pas, il faut le piloter. On conçoit le système autour de lui : on l'alloue, on le protège, on le concentre là où il compte. C'est exactement le travail que le Lean fait depuis soixante-dix ans. La contrainte a changé de place, mais la méthode pour la traiter, elle, est toujours la même.

Industrialiser, mais quoi ?

Le mot d'ordre de 2026 pour l’IA dans les directions informatiques, c'est de passer de l'expérimentation à l'échelle. C’est juste, mais la cible n’est pas la bonne.

Au-delà des POC ou de la gestion des licences, il faut plutôt industrialiser le système de delivery lui-même. Ce travail est concret, déjà connu car bien antérieur à l'IA :

Cartographier le flux complet, de la demande à la livraison, et donc pas uniquement l'étape de production du code
Trouver les contraintes réelles ; aujourd’hui c’est souvent la revue, les tests ou une étape de validation
Limiter les encours, pour que les files d’attente cessent de grossir
Rendre chaque attente visible, pour que l'équipe voie où on perd du temps
Tirer le flux de travail à travers le système au lieu d'en pousser toujours plus à l'entrée sans visibilité

Il n’y a rien d'exotique dans cette approche. C'est celle qui a permis de diviser par deux le délai de déploiement d'une équipe cloud, et réduit de 91 % les défauts d'une équipe de développement de logiciels bancaires, revenue dans les délais en quelques mois. Il y a sans cesse de nouveaux outils pour les développeurs, mais la façon de gérer le flux dans le système de delivery est toujours la même.

Notons une nuance importante sur le marché aujourd’hui. Les grands intégrateurs annoncent des délais divisés par trois ou quatre grâce à l'IA. En regardant le périmètre de plus près, on remarque que ce sont des projets qu'ils maîtrisent de bout en bout, avec une chaîne de production reconstruite autour de l'outil IA. Ils confirment l’approche à suivre. Les gains viennent effectivement du système repensé, et non pas de l’introduction d’un outil. La question qui reste ouverte, c'est celle de vos équipes internes, qui travaillent sur votre « legacy », avec des contraintes techniques et métiers spécifiques.

Est-ce votre situation ?

Lisez ces cinq phrases, et comptez celles qui sont vraies chez vous :

Vos développeurs produisent du code plus vite, mais le métier ne reçoit pas ses fonctionnalités plus vite
Les pull requests s'empilent en attente de revue
La vélocité des équipes monte, mais votre délai de livraison de bout en bout ne diminue pas
La direction a financé l'outillage IA, et demande maintenant le ROI
Personne ne sait pointer l'étape précise où l’on perd du temps

Si trois de ces affirmations sont vraies, alors vos outils IA ne sont pas le problème. C’est le système autour qui n’est pas bon.

L'IA a fait son travail. Produire du code n'a jamais été aussi rapide. Le prochain gain ne viendra pas d'une licence de plus ni d'un agent de plus. Il viendra d'un système de delivery redessiné pour que la nouvelle vitesse des développeurs atteigne le client. L'IA n’a fait que mettre votre processus de delivery suffisamment en tension pour que vous puissiez enfin voir le problème.