TL;DR : L'équipe DORA de Google Cloud vient de publier The ROI of AI-assisted Software Development. Je suis tombé dessus parce que deux personnes que je suis en débattaient sur LinkedIn — et en le lisant, j'ai eu une sensation étrange : ce rapport décrit, en vocabulaire de recherche, l'année que mon équipe vient de vivre. La J-Curve, la taxe de vérification, l'IA comme amplificateur et non comme solution miracle. Le diagnostic est juste. Les chiffres, eux, sont des chiffres d'éditeur — et le rapport l'admet lui-même. À lire pour le cadre de pensée, pas pour le "39 % de ROI".

En mars, j'ai écrit que le SDLC est mort, puis que coder n'a jamais été le métier. En mai, j'ai raconté comment l'IA est devenue un réflexe d'équipe — un retour de terrain, pas un manifeste. Trois articles écrits depuis l'intérieur d'une équipe, sans aucune donnée externe pour les appuyer. Juste ce que je voyais.

Et puis, cette semaine, le rapport DORA a commencé à tourner sur LinkedIn. Robert Schrader, Head of Software Engineering, en a publié une analyse posée. Jean-Rémy Revy, Head of Architecture chez Ippon Technologies, l'a relayée en disant qu'il allait "exactement dans le sens" de ce qu'il défendait depuis des mois. Deux praticiens, deux entreprises différentes, le même constat. J'ai cliqué. J'ai lu les 60 pages. Et j'ai retrouvé, posée noir sur blanc par une équipe de recherche, la quasi-totalité de ce que j'avais décrit à tâtons.

Avant d'aller plus loin, une mise au point honnête : ce rapport est publié par Google Cloud. L'équipe "delta" qui le co-signe est leur practice de conseil, et chaque chapitre se termine par un "contactez-nous". C'est, à la fois, de la vraie synthèse de recherche — DORA, c'est la lignée d'Accelerate et des quatre métriques clés, une marque qui a gagné sa crédibilité — et de la plaquette commerciale. On peut tenir les deux idées en même temps. C'est même indispensable pour lire ce document correctement.

"L'IA est un amplificateur" — la phrase que j'avais déjà écrite

La thèse centrale du rapport tient en une phrase : l'IA est un amplificateur. Elle amplifie les forces des organisations qui fonctionnent bien et les dysfonctionnements de celles qui galèrent. Le retour sur investissement ne vient pas de l'outil — il vient du système autour : la qualité de la plateforme interne, la clarté des workflows, l'alignement des équipes.

"L'IA ne réparera pas un système d'ingénierie cassé."

J'ai écrit presque mot pour mot la même chose dans l'article précédent : "mauvais contexte en entrée, mauvais débat en sortie". Un agent qui génère du code trois fois plus vite dans une équipe sans pipeline solide ne produit pas trois fois plus de valeur. Il produit trois fois plus de code, en attente devant une revue manuelle déjà engorgée. Le rapport le dit sans détour : le code est un passif, pas un actif. Générer plus de code sans garde-fous, ce n'est pas créer de la valeur, c'est accélérer l'accumulation de dette technique.

Ce point paraît évident une fois écrit. Il ne l'est pas dans la tête d'un comité qui vient d'acheter mille licences en espérant un miracle. Le rapport leur répond : le miracle n'est pas dans la licence.

La J-Curve a enfin un nom

Dans l'article précédent, j'ai décrit un creux : les premières semaines où mon équipe a adopté les agents, on a été moins productifs avant d'être plus productifs. Je n'avais pas de mot pour ça. Le rapport en a un : la J-Curve.

L'idée : quand une équipe adopte une technologie majeure, sa performance baisse temporairement avant de remonter — puis de dépasser le point de départ. La courbe dessine un J. DORA appelle ce creux "le coût de scolarité de la transformation". Trois choses le creusent :

  • La learning curve — le temps passé à apprendre les outils, à réadapter les workflows, à passer du prompt bricolé à un vrai travail de contexte et de spécification.
  • La taxe de vérification — le temps passé à relire du code généré dont on n'est pas sûr. Plus l'IA produit de code, plus la charge de revue grossit.
  • L'adaptation du pipeline — les tests, les approbations, tout l'aval qui doit encaisser un volume soudainement plus élevé.
Valeur réalisée Temps Temps zéro Ligne de base La learning curve La taxe de vérification L'adaptation du pipeline Croissance exponentielle où en est votre équipe ? Un creux à financer, pas un échec à stopper.

Le piège, c'est le creux. Le rapport est très clair là-dessus : la plupart des initiatives IA n'échouent pas parce que la techno est mauvaise, mais parce que la direction prend le creux pour un échec et coupe le financement au pire moment. Jean-Rémy Revy résumait exactement ça sur LinkedIn : la J-Curve "matérialise le fait que l'investissement initial fait souvent perdre un peu en performance, puis finit par se rattraper". Si vous lancez l'IA dans votre organisation, vous signez pour ce creux. Autant le savoir, et le budgéter.

"Le creux n'est pas un signal d'échec. C'est le ticket d'entrée."

Au passage : la "taxe de vérification", c'est exactement ce que mon panel de sous-agents personas paie de façon délibérée. Plutôt que de laisser la charge de revue se diluer dans les vendredis après-midi, on la concentre dans un dispositif explicite. La taxe existe — DORA a raison — la question est de savoir si on la paie en pleine conscience ou si elle nous saigne en silence.

Le calcul de ROI, et le chiffre auquel je ne crois pas

Le cœur du rapport, c'est un modèle de calcul du ROI, avec un exemple chiffré. Une organisation de 500 personnes, 100 M$ de revenu produit. Investissement la première année : 8,4 M$. Valeur générée : 11,6 M$. ROI première année : 39 %. Retour sur investissement en huit mois. Et, cerise sur le gâteau, "les clients Google Cloud constatent en moyenne 727 % de ROI sur trois ans".

Voilà. Maintenant, pourquoi je ne crois pas à ce chiffre.

Sur les 11,6 M$ de valeur, 11 M$ viennent d'un seul levier : la "capacité de réinvestissement RH". En clair : on suppose que chaque développeur gagne 12,5 % de son temps (environ une heure par jour) et on valorise cette heure au coût salarial chargé. Tout le ROI tient à deux hypothèses empilées : (a) ce gain de temps de 12,5 % est réel, et (b) cette heure est effectivement reconvertie en valeur. À 100 %. Or une heure "gagnée" a une fâcheuse tendance à se faire avaler par les réunions, le changement de contexte… ou par la taxe de vérification elle-même. Si la conversion réelle est de 50 %, le ROI est divisé par deux.

Quant aux 727 % sur trois ans : ce sont des clients Google Cloud, qui sont restés trois ans chez Google Cloud, et qui ont accepté d'être mesurés. Biais de survie intégral. Les "78 % de dirigeants qui constatent un retour", les "88 % d'adopteurs de l'agentique aux retours positifs" : de l'auto-déclaration de cadres, pas des métriques de delivery.

Le plus honnête dans tout ça, c'est que le rapport le dit lui-même. Il qualifie ses propres chiffres d'"estimation à forte incertitude" destinée "à lancer une conversation", et cite la formule classique : "tous les modèles sont faux". Donc je le prends au mot. Ce qui est utile dans ce chapitre, ce n'est pas le 39 %. C'est la structure : la formule, les leviers de valeur, la liste des coûts qu'on oublie toujours — dont une ligne "coût de la J-Curve" que personne ne met jamais au budget. Le livrable, c'est la méthode. Le pourcentage, c'est de la décoration.

"Endossez le cadre de raisonnement. Refusez le chiffre précis."

Le vrai problème, c'est la mesure

C'est le point qu'a soulevé Robert Schrader sur LinkedIn, et il a raison de le mettre en avant. Le rapport vous donne des formules — mais une formule de ROI a besoin de deux choses : une baseline (l'"avant") et une cible (l'"après"), toutes deux fondées sur de vraies métriques de delivery.

Et là, ça se complique. Obtenir des chiffres fiables est "particulièrement difficile dans les organisations hétérogènes", avec des paysages applicatifs fragmentés, des chaînes d'outillage disparates, et des sources de revenu autres qu'un produit logiciel ou de l'e-commerce. DORA prévient d'ailleurs que ces métriques doivent être appliquées en contexte, au niveau de l'application ou du service — comparer deux systèmes très différents ne veut rien dire.

Traduction : la moitié des entreprises qui voudront calculer leur ROI IA n'ont pas de baseline. Elles n'ont jamais mesuré leur lead time, leur fréquence de déploiement, leur taux d'échec de changement avant. Sans cet "avant", la J-Curve est invisible : on ne peut pas prouver une remontée qu'on n'a pas su mesurer descendre.

Jean-Rémy Revy l'a formulé d'une phrase que je garde : "Pas de ROI sans l'adoption d'un cadre de travail méthodologique adéquat et d'un outillage de contrôle aligné." C'est tout le sujet. Le rapport vend un calcul ; le calcul suppose une discipline de mesure que la plupart des organisations n'ont pas. Le ROI de l'IA est, d'abord, un problème d'instrumentation.

Les conclusions qui n'arrangent personne

Deux résultats du rapport ne flattent personne — et ce sont, justement, les plus crédibles.

Premier : l'IA aide beaucoup moins sur le code que vous maintenez vraiment. Les recherches citées (Stanford) donnent 35 à 40 % de gain de productivité sur des tâches simples, en greenfield. Sur du code legacy, complexe, brownfield ? 10 % ou moins. Pour quelqu'un comme moi, qui travaille sur du logiciel de santé régulé, vieux de plusieurs années, c'est le seul chiffre qui compte. Le "40 %" qui fait les titres décrit un terrain vierge. Le vrai métier, lui, se passe dans le code qui existe déjà — et là, le gain est honnête mais modeste.

Deuxième, et plus inconfortable encore : l'adoption de l'IA est associée à une hausse de l'instabilité du delivery. Dans la recherche DORA 2025, plus d'IA va de pair avec un taux d'échec de changement qui monte. L'exemple chiffré du rapport l'intègre : le taux passe de 5 % à 6 %, et ça coûte 344 000 $ de "taxe d'instabilité". Le delta paraît petit. Le fait, lui, ne l'est pas : un éditeur qui vend des outils d'IA admet noir sur blanc que sa techno, mal encadrée, dégrade la stabilité. C'est probablement la phrase la plus crédible du document — parce qu'elle survit au filtre de l'intérêt commercial. Quand un vendeur dit quelque chose contre son intérêt, on écoute.

Ne licenciez pas

Le rapport est ferme sur un point, et je veux le souligner parce que c'est le plus important : ne réduisez pas les effectifs. La productivité gagnée ne doit pas servir à licencier ; elle doit libérer de la capacité pour l'innovation.

Pour une fois, l'argument n'est pas moral, il est financier — et imparable. Le modèle de ROI du rapport repose presque entièrement sur la "capacité de réinvestissement RH". Si vous licenciez les gens, vous supprimez la plus grosse ligne de votre propre dossier de ROI. Vous détruisez la valeur que vous prétendiez créer. Et vous la détruisez précisément au creux de la J-Curve — c'est-à-dire en virant les gens qui paient la taxe de vérification et encaissent la learning curve, juste avant la remontée.

Le rapport reformule le ROI d'une façon que je trouve juste : ce n'est plus "combien de développeurs je peux remplacer", mais combien de créativité humaine latente on peut libérer en déchargeant les agents de la corvée systémique.

"On ne mesure pas l'IA au code qu'elle écrit, mais aux goulots d'étranglement qu'elle dégage."

Dans mon équipe, sur six mois, l'effectif n'a pas baissé. Il a augmenté — stagiaires et alternants compris. On livre plus, on dort mieux, et personne n'a été remplacé par une machine. Le rapport décrit, en langage de cabinet de conseil, exactement ce que j'ai vu se passer.

Ce qui reste aux humains

Comme dans chaque article de cette série, la partie honnête. Beaucoup de choses ne sont pas dans ce rapport — ou y sont, mais restent entre nos mains.

Lire le rapport en sceptique. Personne ne le fera à votre place. Un document publié par un fournisseur, avec un calculateur fourni par le même fournisseur, se lit une main sur le portefeuille. Pas avec mépris — DORA mérite une lecture sérieuse — mais avec discernement.

Construire et tenir la baseline. L'outillage de mesure, le cadre méthodologique dont parle Revy : ça ne s'achète pas, ça se construit. C'est un travail d'ingénierie, lent, peu glamour, et c'est le préalable à tout calcul de ROI sérieux.

Reconvertir le temps gagné. L'heure libérée ne se transforme pas toute seule en valeur. Quelqu'un doit décider, délibérément, qu'elle ira dans les tests, dans le métier, dans l'innovation — et pas dans une réunion de plus. Le 11 M$ du modèle n'existe que si cette décision est prise, et tenue.

Tenir l'architecture et décider quoi construire. Aucun agent n'a la lecture stratégique d'un produit. Le cadre que l'IA amplifie, c'est nous qui l'écrivons.

Que faire lundi matin

Si vous dirigez une équipe et que vous voulez tirer quelque chose de concret de ce rapport, voici l'ordre que je conseillerais :

  1. Mesurez votre baseline DORA maintenant. Lead time, fréquence de déploiement, taux d'échec de changement, temps de restauration. Avant d'ajouter la moindre IA. Sans l'"avant", vous ne prouverez jamais l'"après".
  2. Mettez la J-Curve au budget. Une ligne explicite "coût de transformation", avec une durée annoncée. Et faites pré-valider à la direction l'engagement de ne pas couper le financement pendant le creux.
  3. Suivez les indicateurs avancés, pas le ROI. La fréquence d'expérimentation et les métriques de delivery vous diront en semaine 3 si vous êtes sur la courbe. Le ROI, c'est une histoire à huit mois — trop tard pour corriger le tir.
  4. Auditez votre couche de contexte. Votre plateforme interne est-elle un vrai produit ? Vos données sont-elles accessibles à l'IA ? Si la réponse est non, c'est là qu'est la dépense — pas dans plus de licences.
  5. Faites tourner le calculateur avec VOS chiffres. En trois scénarios : conservateur, réaliste, optimiste. Le livrable, c'est la fourchette et la discipline de l'exercice. Pas le pourcentage que vous montrerez en COPIL.

Conclusion

Il y a six mois, j'ai écrit un retour de terrain et je l'ai terminé par : "si vous pensiez que je faisais de la théorie — non." Aujourd'hui, une équipe de recherche externe, sans le moindre intérêt à me flatter et qui n'a évidemment jamais lu mon blog, publie le même diagnostic. Ce n'est pas une revanche. C'est une convergence — et une convergence vaut plus qu'une revanche, parce qu'elle vient d'ailleurs.

Le diagnostic du rapport est solide : l'IA est un amplificateur, la J-Curve est réelle, les fondations passent avant l'outil, et le code reste un passif. L'arithmétique, elle, est une amorce de conversation — pas une promesse. Lisez le rapport pour le cadre. Faites tourner le calculateur pour la discipline d'y mettre vos propres chiffres. Et oubliez le 39 %.

Une dernière question, la seule qui compte vraiment : sur quelle partie de la courbe est votre équipe, en ce moment ? Si vous ne savez pas répondre, ce n'est pas grave — ça veut juste dire que vous n'avez pas de baseline. Commencez par là. Le reste suivra.

Lire la suite de la série : Le SDLC est mort — pourquoi le processus a toujours été du gaspillage. Coder n'a jamais été le métier — ce que devient l'ingénieur quand la syntaxe disparaît. L'IA est devenue un réflexe d'équipe — à quoi ressemble une équipe IA-native un mardi. Six mois d'agents — le point d'étape où je note cette courbe en J face aux données, et corrige un pari. Le backlog n'a jamais été le métier — ce que l'amplificateur fait au rôle produit. La doctrine se capitalise. Les modèles, non. — où vivent réellement les fondations que ce rapport exige. Les tests passent. Il ne se passe rien. — le défaut sans symptôme, et ce qui l'attrape à la place de la lecture.

Sources