Transformation & IA · ROI 2026
Votre slide dit « +30 % de vélocité depuis l’arrivée de l’IA ». Votre DAF demande ce que rapporte la facture. Ce ne sont pas du tout les mêmes questions.
Mesurer le ROI de l’IA n’est pas un problème de tableau de bord. C’est une question de méthode, d’honnêteté et de management.
Fin 2026, la question du ROI de l’IA est arrivée dans toutes les directions financières. Les licences d’assistants de code, les abonnements aux outils d’IA générative et la facture de tokens des agents ont grimpé plus vite que n’importe quelle autre ligne du budget IT. Le DAF pose donc une question parfaitement légitime : qu’est-ce que cet investissement nous rapporte, et comment le savons-nous ?
La réponse qui circule dans la plupart des entreprises tient sur une slide : la vélocité de l’équipe avant le déploiement de l’IA, la vélocité après, une flèche verte et un pourcentage. Ce chiffre remonte ensuite de comité en comité jusqu’au board. Problème : il ne répond pas à la question posée.
Stefan Wolpers, Professional Scrum Trainer et auteur du Scrum Anti-Patterns Guide, vient de le démontrer méthodiquement dans un article publié le 1er novembre 2026 sur Age of Product, « Measuring AI Impact: What Your Velocity Chart Cannot Tell the CFO ». Il s’appuie notamment sur la série publiée en septembre 2026 par James Shore, figure historique de l’agilité, sur la mesure de l’impact de l’IA. Leur conclusion commune est inconfortable pour beaucoup de managers : le retour sur investissement de l’IA ne se lit pas dans un burndown chart. Voici pourquoi, et comment produire une réponse que votre direction financière peut réellement signer.
Pourquoi la question du ROI de l’IA arrive maintenant sur la table
En 2025, l’adoption de l’IA en entreprise relevait encore largement de l’expérimentation. On distribuait des licences, on lançait des ateliers de prompt, on célébrait les premiers cas d’usage. Personne ne demandait de chiffres précis : l’important était de ne pas rater le train.
En 2026, le décor a changé. Les investissements dans l’IA sont devenus une ligne budgétaire significative, avec des coûts récurrents (licences, infrastructure, tokens, maintenance des intégrations, conformité) et des coûts cachés (formation des équipes, temps de vérification, gouvernance de l’IA). Les agents autonomes, qui consomment des tokens en continu, rendent la facture moins prévisible. Et la promesse d’un avantage concurrentiel ne suffit plus à justifier le budget total.
Début 2026, l’adoption de l’IA n’était déjà plus une option dans la plupart des entreprises. Leur maturité en matière de mesure, en revanche, est restée très faible : on sait combien coûte l’IA, beaucoup moins ce qu’elle rapporte. Les gains directs (temps gagné sur une tâche) sont mis en avant, les coûts de conformité et de relecture passent sous le radar.
Nous avons déjà expliqué pourquoi rationner l’IA pour réduire les coûts est une mauvaise réponse. Mais l’inverse est tout aussi dangereux : dépenser sans savoir ce qui crée de la valeur. Entre les deux, il y a une discipline à apprendre, celle de mesurer honnêtement.
Pourquoi la vélocité est le pire indicateur pour calculer le ROI de vos projets IA
La vélocité additionne des story points, c’est-à-dire des estimations faites par l’équipe avant que le travail commence. Leur valeur, rappelle Wolpers, a toujours été la conversation qu’elles provoquent, pas le nombre. Utiliser ce nombre pour mesurer la productivité était déjà discutable. L’utiliser pour mesurer l’impact de l’intelligence artificielle l’est encore plus, pour trois raisons.
1. Le « avant/après » attribue tout à l’IA
Les équipes changent rarement une seule chose à la fois. Les assistants de code arrivent le même trimestre qu’une réorganisation, un départ, une nouvelle cadence de sprint ou une release majeure. Comparer avant et après crédite l’IA de tous ces changements. Et le « avant » n’est pas forcément un point de référence calme : si le déploiement a suivi une période de rush, ou si les gens utilisaient déjà l’IA en douce avant les licences officielles, vous mesurez aussi ça. La question à poser devant chaque chiffre avant/après est simple : qu’est-ce qui a changé d’autre ce mois-là ?
2. L’IA change les estimations elles-mêmes
Si l’équipe pense que l’IA la rend plus rapide, ses estimations baissent, et un vrai gain peut disparaître de la courbe. À l’inverse, si la direction attend un « boost de vélocité IA », une équipe sous pression trouvera vite que le même travail mérite plus de points. C’est la loi de Goodhart : dès qu’une mesure devient un objectif, elle cesse d’être une bonne mesure. Wolpers en fait un exercice dans ses formations Scrum, « Cooking the Agile Books » : gonfler sa vélocité sans travailler plus. Tout le monde sait le faire. Avant et après le déploiement de l’IA, la vélocité n’est donc plus exprimée dans la même unité.
3. La vélocité ignore le travail de réparation
Les bugs, les tickets rouverts, les correctifs manuels, le support que personne n’avait planifié : tout ce travail n’apparaît jamais dans la vélocité. Or le rapport DORA 2025, qui a interrogé près de 5 000 professionnels de la tech, observait à la fois une relation positive entre adoption de l’IA et débit de livraison, et une instabilité des livraisons qui continue d’augmenter. Plus de travail livré et plus de travail de réparation peuvent apparaître dans les mêmes sprints. Une slide qui ne montre que le premier chiffre laisse le second à celui qui est d’astreinte le week-end.
Conseil pratique de Wolpers : comptez les éléments terminés à côté des points. Si les points par élément augmentent alors que le nombre d’éléments terminés par sprint reste stable, la vélocité monte mais le travail livré, lui, ne bouge pas.
Des gains plus rapides sur le code ne sont pas des gains pour l’organisation
James Shore donne un exemple que tout dirigeant devrait afficher dans son bureau : si l’IA double la vitesse de codage, mais que les développeurs passent la moitié de leur semaine sur autre chose (réunions, coordination, attente de décisions), leur gain global n’est pas de 2x mais de 1,33x. Un assistant de code accélère le code. Il ne fait rien pour la sprint review, la conversation avec les parties prenantes, ou la décision qui attend trois niveaux de hiérarchie plus haut.
C’est exactement ce que nous décrivions dans notre article sur la productivité des développeurs avec l’IA : l’automatisation d’une étape déplace les goulots d’étranglement ailleurs dans les processus. Si le vrai frein de votre organisation est la prise de décision, une IA qui produit du code deux fois plus vite fabrique surtout une file d’attente deux fois plus longue.
« La productivité du développement logiciel, c’est la valeur produite divisée par l’argent dépensé. Aller plus vite ne veut pas dire aller dans la bonne direction. »James Shore, cité par Stefan Wolpers (Age of Product, novembre 2026)
Voilà la formule de base du ROI de l’IA que votre DAF attend : de la valeur, pas de la vitesse. Un projet IA mesurable est un projet dont on peut relier l’usage à un résultat opérationnel ou business, pas à un volume de tickets.
Calculer le ROI de vos projets IA : partir du résultat, pas de l’outil
Les projets IA dont le ROI est le plus simple à démontrer sont ceux qui visent un résultat opérationnel déjà mesuré avant l’arrivée de l’IA : la détection de la fraude (montant de fraude évitée), la maintenance prédictive (pannes et arrêts évités), le traitement de dossiers (délai de traitement de bout en bout). Le résultat existe indépendamment de l’outil, on peut donc comparer. Avant de lancer un projet, commencez par identifier les goulots d’étranglement réels : c’est là que l’IA a une chance de produire un ROI significatif.
À l’inverse, les déploiements d’IA générative « pour tout le monde » sont les plus difficiles à évaluer : le gain est diffus, déclaratif, et rarement relié à un flux de travail précis. Pour calculer le ROI de ce type d’initiative IA, il faut redescendre au niveau du workflow : quelle tâche, faite par qui, combien de fois par semaine, avec quel temps de vérification.
Méfiez-vous aussi des benchmarks publiés par les éditeurs et cabinets : un ROI médian annoncé sur un échantillon de clients enthousiastes ne dit rien de votre contexte, de la qualité de vos données ni de la maturité de vos équipes. Dans les PME et ETI, où le budget total IA est plus serré, cette rigueur compte encore plus. Et n’oubliez pas la montée en compétences : la formation des équipes fait partie de l’investissement, au même titre que les licences.
Le chiffre qui devrait calmer tout le monde
Ce que les équipes ressentent et ce qu’elles mesurent n’a rien à voir.
En juillet 2025, l’organisme de recherche METR a publié une étude randomisée sur 16 développeurs open source expérimentés et 246 tâches, avec ou sans IA tirées au sort. Résultat : avec l’IA, ils ont mis 19 % plus de temps. Avant l’étude, ils s’attendaient à gagner 24 %. Après, ils pensaient encore avoir gagné 20 %.
METR reconnaît que ces résultats ont vieilli et que les outils de 2026 accélèrent probablement davantage. Mais quand l’organisme a interrogé 349 professionnels techniques début 2026, le gain de vitesse médian déclaré était de 3x, avec un avertissement des auteurs eux-mêmes : ces réponses ne sont pas forcément ancrées dans la réalité.
Un sondage de satisfaction mesure un ressenti. Il ne mesure pas un retour sur investissement.
Comment mesurer l’impact de l’IA : les trois niveaux de preuve
Tous les chiffres ne se valent pas. Wolpers propose une grille simple, applicable à chaque affirmation sur l’IA qui arrive sur votre bureau :
L’essai comparatif : le même type de tâche, réalisé avec et sans IA pendant les mêmes semaines, avec une estimation notée avant, et la condition tirée au sort après. C’est la preuve la plus solide qu’une équipe puisse produire seule. James Shore recommande justement d’alterner des tâches « avec IA » et « sans IA » sur la même période pour neutraliser les autres changements.
La comparaison avant/après : elle montre, au mieux, une corrélation.
Le sondage sur la vitesse ressentie : il dit comment les gens se sentent, ce qui est utile à savoir, mais il mesure une perception, pas une vitesse.
Attention à un biais que METR a lui-même rencontré dans son étude de suivi : entre 30 % et 50 % des développeurs ont évité certaines tâches qu’ils ne voulaient pas faire sans IA. Une fois qu’on s’appuie sur l’IA, travailler sans elle ressemble à une punition. Un essai a donc besoin du consentement des participants et d’une date de fin connue de tous.
Marre des slides IA à flèche verte ?
Chaque semaine, on décortique ce que l’IA change vraiment pour les managers, preuves à l’appui.
Le test du point mort : savoir si automatiser une tâche avec l’IA est rentable
Une bonne partie du travail confié à l’IA n’est pas du code : comptes rendus, rapports aux parties prenantes, notes de version, premières versions de user stories. Pour ces délégations, il existe un test beaucoup plus simple, cité par McKinsey dans son article d’octobre 2026 sur la courbe de valeur de l’IA et attribué à David Tepper, CEO d’Ascerta. Confier une tâche à l’IA a un sens économique quand sa probabilité de succès dépasse le rapport entre le temps de vérification et le temps qu’il faudrait pour faire la tâche soi-même.
Taux d’acceptation > temps de vérification ÷ temps de réalisation
La logique est implacable : avec l’IA, on paie toujours le temps de vérification, et quand le résultat échoue au contrôle, on refait la tâche à la main. La part des résultats acceptés doit donc dépasser ce ratio.
L’exemple (fictif) de Wolpers : un rapport mensuel prend 180 minutes à rédiger à la main et 60 minutes à vérifier ligne à ligne. La version IA n’est rentable que si plus d’un brouillon sur trois passe le contrôle. Si la vérification prend 150 minutes, parce que chaque affirmation exige de revenir aux données sources, il faut un taux d’acceptation supérieur à 83 %. Une équipe qui a dû réécrire deux de ses six derniers rapports a sa réponse.
Quatre ajustements évitent de se raconter des histoires :
Comptez le temps de vérification de tout le monde. Un Product Owner qui génère cinq descriptions de backlog en 15 minutes, puis trois développeurs qui passent chacun 20 minutes à démêler des phrases plausibles mais fausses : la vérification coûte 60 minutes, payées par des gens qui n’ont rien délégué. Tobi Lütke, CEO de Shopify, appelle ça des « slop grenades ». C’est un transfert de coût, pas un gain, et c’est la mécanique exacte du workslop.
Ajoutez le temps passé à écrire et ajuster les prompts, à chaque exécution.
Mesurez le temps de vérification au lieu de l’estimer de mémoire. Un souvenir est une estimation comme une autre.
Ne tranchez pas après trois essais. Les premières exécutions sont souvent plus lentes, le temps d’apprendre. Un verdict pris pendant ce creux peut s’inverser un mois plus tard.
La facture de tokens est une ligne à part. Pour un agent de code, elle peut être le gros chiffre. Pour un rapport, le temps humain pèse probablement plus lourd. Regardez votre propre facture avant d’affirmer quoi que ce soit.
Le piège du ROI parfait : quand plus personne ne vérifie
Le test du point mort a un angle mort. Imaginez un résumé hebdomadaire généré par IA qui passe le contrôle à chaque fois depuis deux mois, pendant que le temps de relecture est tombé de quinze minutes à une minute. Sur le papier, c’est votre meilleur cas d’usage : 100 % d’acceptation, vérification quasi nulle. En réalité, plus personne ne vérifie. Une tâche d’assistance est devenue une automatisation sans contrôle, sans que personne ne l’ait décidé.
Pour l’éviter, Wolpers propose un audit régulier des délégations à l’IA, une réunion de 45 à 60 minutes toutes les deux semaines ou chaque mois, qui fait pour le travail délégué ce que la rétrospective fait pour la façon de travailler de l’équipe. Quatre contrôles par workflow :
Dérive du résultat : le travail respecte-t-il toujours la définition de « terminé » ?
Adéquation du modèle : le niveau de modèle est-il toujours le bon, dans un sens comme dans l’autre ?
Réversibilité : pourriez-vous arrêter cette automatisation aujourd’hui, et qui le ferait ?
Glissement : combien de temps un humain passe-t-il réellement à relire ? Une approbation en quatre secondes est un échec.
Chaque workflow reçoit ensuite une décision : garder, modifier ou retirer. « On surveille » n’est pas une décision, c’est une décision repoussée qui se déguise. Et retirer une délégation qui ne paie plus est un succès : l’équipe a appris quelque chose. C’est aussi le meilleur moyen de garder la main sur la prolifération des agents IA en entreprise.
Mesurer l’approche, jamais les personnes
Tout export Jira contient le nom de chaque membre de l’équipe, et une IA à qui l’on demande pourquoi la vélocité a augmenté désignera volontiers un responsable. Dès qu’un bilan d’impact nomme, félicite ou classe des individus, la mesure d’une approche devient une évaluation de performance. Et les gens optimisent l’indicateur au lieu du travail.
James Shore est sans ambiguïté : ses indicateurs ne doivent jamais servir à évaluer la performance des équipes ou des individus. Sa règle tient sur un post-it :
« Mesurez l’approche, apprenez-en, puis arrêtez de mesurer. »James Shore, « Assessing AI Impact: Notes for Your CFO », 2026
La dernière partie est celle que tout le monde oublie. Un essai sur la vitesse s’arrête quand il a répondu à sa question. Installer un programme permanent de mesure de la productivité IA, c’est fabriquer de la surveillance et de la bureaucratie, deux choses dont votre culture n’a pas besoin.
Ce que votre DAF devrait recevoir à la place de la courbe de vélocité
Si la courbe de vélocité ne peut pas répondre, que donner à la direction financière ? Wolpers propose une page unique, que le CTO ou le manager de l’équipe peut signer :
Ce que l’équipe peut affirmer
Chaque affirmation avec sa source et son niveau de certitude. Par exemple : le nombre d’éléments terminés par sprint à côté des bugs et tickets rouverts, ou la décision prise sur un workflow délégué et l’audit qui la justifie.
Ce que l’équipe ne peut pas affirmer, et pourquoi
Par exemple : un pourcentage de productivité causé par l’IA, parce qu’une comparaison avant/après montre au mieux une corrélation. Préciser quelle preuve il faudrait pour pouvoir l’affirmer.
La décision par workflow délégué
Garder, modifier ou retirer, chaque ligne renvoyant à son entrée dans le journal de reclassification.
Trois indicateurs maximum, avec une date de fin
Pas un tableau de bord de quarante métriques. Trois mesures, chacune limitée dans le temps.
Cette page ne nomme personne et ne classe personne. Elle demande aussi un peu de courage, parce que « nous ne pouvons pas affirmer cela » n’est pas ce que promettait la slide de la plénière. Mais une page qui dit « on ne peut rien savoir » échoue autant qu’une page qui répète le pourcentage magique. La création de valeur se prouve, elle ne se proclame pas.
Par où commencer lundi matin : un essai sur un seul workflow
Pas besoin d’un grand projet IA de mesure. Pour votre propre travail, un carnet et quelques semaines suffisent :
Choisissez une tâche que vous faites déjà avec l’IA au moins une fois par semaine.
Écrivez votre règle de décision avant de commencer : je garde si, je change si, j’arrête si. Une fois les chiffres arrivés, chacun ressemble à une bonne raison de faire ce que vous vouliez déjà.
Prévenez la personne qui reçoit le résultat, pour qu’un livrable fait à la main soit compris comme un test.
Avant chaque exécution, notez votre estimation, puis tirez au sort avec ou sans IA (cinq papiers de chaque dans un mug, plus équilibré qu’une pièce sur dix essais).
Après chaque exécution, notez le temps total, vérification et reprise comprises, et si le résultat a passé votre contrôle.
Après huit à dix essais, comparez le ratio médian temps réel / estimation avec et sans IA, puis calculez votre point mort.
Appliquez votre règle, notez la décision, et arrêtez de mesurer.
Huit à dix essais ne convaincront pas un statisticien. Mais ils donnent une direction, et une direction suffit pour décider du sort d’un workflow. C’est infiniment plus honnête qu’une flèche verte, et c’est le genre de preuve qu’un DAF respecte.
Le ROI de l’IA n’est pas un chiffre qu’on trouve, c’est une discipline qu’on installe. Les organisations qui sauront dire « ça marche ici, pas là, et voici pourquoi » feront de l’IA un vrai levier. Les autres continueront de financer des slides.
Questions fréquentes sur le ROI de l’IA
Partez de la formule de base du retour sur investissement : valeur produite divisée par l’argent dépensé, et non vitesse de production. Pour un workflow délégué, utilisez le test du point mort : le taux d’acceptation des résultats doit dépasser le rapport entre le temps de vérification et le temps de réalisation à la main. Ajoutez les coûts complets (licences, tokens, infrastructure, maintenance, formation, temps de prompt et de relecture de toute l’équipe).La vélocité additionne des estimations faites avant le travail. Le déploiement de l’IA modifie ces estimations (à la baisse si l’équipe pense aller plus vite, à la hausse si la direction attend un gain), coïncide souvent avec d’autres changements, et ignore le travail de réparation comme les bugs et les tickets rouverts. Avant et après, la vélocité n’est plus mesurée dans la même unité.Peu d’indicateurs, limités dans le temps : nombre d’éléments réellement terminés à côté des bugs et tickets rouverts, taux d’acceptation et temps de vérification par workflow délégué, et indicateurs de résultat business ou client. Évitez les sondages de vitesse ressentie comme preuve : ils mesurent une perception.Le délai de retour dépend du cas d’usage, mais il faut éviter de juger trop tôt. Les premières exécutions sont souvent plus lentes, le temps d’apprendre à rédiger les prompts et à vérifier efficacement. Un essai de huit à dix exécutions sur quelques semaines donne déjà une direction exploitable pour un workflow donné.Non. Mesurez l’approche, pas les personnes. Dès qu’un bilan d’impact nomme ou classe des individus, il devient une évaluation de performance et les gens optimisent l’indicateur au lieu du travail. Seule observation utile : si le gain est concentré sur une seule personne, l’équipe ne peut pas revendiquer un effet collectif.Souvent parce que l’IA accélère une étape qui n’était pas le goulot d’étranglement, parce que le temps de vérification est reporté sur d’autres équipes, ou parce que la qualité des données et des résultats n’est jamais contrôlée. Un audit régulier des délégations permet de garder, modifier ou retirer chaque cas d’usage avant qu’il ne coûte plus qu’il ne rapporte.
L’IA sans le bullshit, chaque semaine
Une newsletter pour les managers qui veulent des preuves, pas des flèches vertes. Zéro hype, que du concret.