IA : vos développeurs vont plus vite, le client attend toujours autant

Vos développeurs codent plus vite, le client attend toujours autant. La vitesse de l'IA s'arrête à la revue et aux tests. C'est un problème de système, pas d'outil.

J'ai retracé le parcours d’une demande, un jour, de bout en bout. L'équipe de développement l'avait traitée en quatre jours ouvrés. Le client, lui, avait attendu quarante-cinq jours. Pendant les quarante et un autres, la demande dormait dans des files d’attente : priorisation, revue, validation, derrière d'autres travaux. Les indicateurs de l'équipe de développement sont restés au vert du début à la fin.

Ce n'est plus une anecdote car c'est devenu la réalité de presque toutes les organisations qui ont déployé l'IA dans leurs équipes de développement. Le code n'a jamais été produit aussi vite. Le métier, lui, ne reçoit pas ses fonctionnalités plus vite. Et quelqu'un, en haut, commence à demander où est le ROI.

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

Des chiffres confirment ce que j’ai vu. L’étude de Faros AI, sur 22 000 développeurs, montre un temps de revue 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é.

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.

Les deux horloges

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

La première mesure la vitesse de votre équipe sur un élément, à l'intérieur de son propre processus. La seconde mesure l'attente du client, de la demande à la livraison. Aujourd’hui, les outils IA améliorent la première. Le client ne vit que la seconde.

Revenons à la demande que j’ai suivie. Quatre jours sur la première horloge. Quarante-cinq sur la seconde. Le tableau de bord des développeurs lisait la mauvaise. Voilà le piège, et il est mécanique : votre vélocité peut grimper pendant que le client attend plus longtemps. Vos indicateurs disent que vous gagnez alors que le client n'est pas d'accord. Or, c'est lui qui paye.

Le goulot remonte

Il y a une bonne nouvelle quand même. Le goulot de la revue est désormais attaqué au niveau de l'outil 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 pouvait pas absorber ce volume. Alors Codex 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 ce qu'ils ont fait. Ils n'ont pas acheté un outil de plus. En réalité, ils ont redessiné leur système de revue autour de la nouvelle vitesse. 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 les agents ont fini. Le jugement : quoi construire, ce qui a du sens, quel compromis accepter. C'était la vraie contrainte sous le processus de revue depuis le début. Les outils IA font la reconnaissance de patterns et la vérification. Elles ne prennent pas la décision.

Et c'est là que la plupart des analyses s'arrêtent, en concluant qu'il faut recruter des profils plus expérimentés. 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, c'est de passer de l'expérimentation à l'échelle. Le mot est juste, mais la cible n’est pas la bonne.

Ce qu'il faut industrialiser, ce ne sont ni les licences ni les POC. C'est le système de delivery lui-même. Et ce travail est concret, connu, et antérieur à l'IA :

Cartographier le flux complet, de la demande à la livraison, pas seulement l'étape de codage
Trouver les contraintes réelles, le plus souvent la revue, les tests ou une porte 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 là-dedans. C'est le travail qui a divisé par deux le délai de déploiement d'une équipe cloud, et réduit de 91 % les défauts d'une équipe de dev bancaire, revenue dans les délais en quelques mois. Les outils sont nouveaux, mais la façon de gérer le flux dans le système est toujours la même.

Il y a une nuance importante à noter aujourd’hui sur le marché. Les 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. Ils ne contredisent pas la règle, ils nous la confirment. Le gain vient effectivement du système repensé, et non pas de l'outil. La question qui reste ouverte, c'est celle de vos équipes internes, sur votre legacy, avec vos contraintes spécifiques.

Est-ce votre situation ?

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

Vos développeurs produisent plus de code, mais le métier ne reçoit pas ses fonctionnalités plus vite
Les pull requests s'empilent en attente de revue
Votre vélocité monte et votre lead time ne diminue pas
La direction a financé l'outillage IA, et quelqu'un 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. Écrire 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 de delivery atteigne le client. L'IA ne l'a pas cassé. Elle l’a juste mis suffisamment en tension pour que vous puissiez enfin le problème.