Ce que disent les études contrôlées sur l’IA et la productivité

Lors d’un essai randomisé en 2025, 16 développeurs expérimentés ont traité 246 tickets réels dans leurs propres dépôts open source, l’IA étant autorisée sur certains tickets et interdite sur d’autres. Quand l’IA était autorisée, ils ont mis 19 % de temps en plus. Avant l’étude, ils s’attendaient à travailler 24 % plus vite avec l’IA, et après coup ils pensaient encore qu’elle les avait accélérés de 20 %.¹

Cet écart entre productivité mesurée et productivité ressentie compte pour quiconque valide un budget de licences. Les dirigeants entendent des retours enthousiastes de leurs équipes et un flot d’affirmations de fournisseurs, et les preuves contrôlées sont moins nettes que les uns comme les autres. Cet article passe en revue quatre des études les plus connues, dit ce que chacune peut et ne peut pas démontrer, et propose une façon de décider où l’IA mérite un investissement dans vos propres processus.

Dans la frontière et hors de la frontière : l’expérience BCG

L’expérience de terrain la plus citée a porté sur 758 consultants en stratégie de Boston Consulting Group, soit environ 7 % des consultants de niveau contributeur individuel du cabinet. Ils ont été répartis au hasard entre : sans IA, GPT-4, ou GPT-4 avec une présentation de l’art du prompt.²

Sur 18 tâches de conseil réalistes, choisies pour se situer dans le champ de ce que le modèle sait faire, les consultants équipés d’IA ont terminé en moyenne 12,2 % de tâches en plus, 25,1 % plus vite, avec des résultats jugés plus de 40 % meilleurs en qualité que ceux du groupe témoin. Les consultants sous le seuil moyen de performance ont progressé de 43 % par rapport à leurs propres scores de départ ; ceux au-dessus, de 17 %.²

Les auteurs ont aussi conçu une tâche hors de la frontière, où la réponse plausible du modèle était fausse. Les consultants sans IA avaient la bonne réponse dans 84,5 % des cas. Les deux groupes avec IA ont obtenu 60 % et 70 %, soit une baisse moyenne de 19 points de pourcentage.² Les auteurs parlent de « frontière technologique en dents de scie » (« jagged technological frontier ») pour la limite entre ces deux régimes : des tâches de difficulté apparente comparable peuvent tomber d’un côté ou de l’autre, et rien à l’écran n’indique à l’utilisateur de quel côté il se trouve.²

Les limites comptent. Les tâches ont été construites par les chercheurs, le test hors frontière se résumait à une seule tâche, et les participants étaient des consultants travaillant sur des problèmes isolés. C’est une preuve sur un mécanisme, pas une prévision pour votre direction financière.

Pour un acheteur, le résultat hors frontière est la moitié la plus utile de l’article. Un outil qui produit des réponses fluides et assurées sera cru à proportion de sa fluidité, et l’expérience montre ce qui se passe quand cette confiance est mal placée. Un gain de 25,1 % en rapidité sur des tâches adaptées et une perte de 19 points de pourcentage de justesse sur une tâche inadaptée peuvent coexister dans la même équipe, le même jour, avec le même outil.²

Tâches rédactionnelles : plus rapides, meilleures et plus homogènes

Noy et Zhang ont confié à 444 professionnels diplômés de l’enseignement supérieur des tâches rédactionnelles propres à leur métier, comme des communiqués de presse et de courts rapports, dans une expérience en ligne préenregistrée, et ont exposé au hasard la moitié d’entre eux à ChatGPT. Dans la version document de travail, le temps nécessaire a baissé de 0,8 écart-type et la qualité a progressé de 0,4 écart-type.³

Le même article indique que l’outil a resserré l’écart entre les travailleurs, car les participants les moins performants en ont davantage profité, et qu’il s’est surtout substitué à l’effort plutôt que d’ajouter des compétences. Les travailleurs ont déplacé leur temps vers la génération d’idées et la relecture, et l’ont retiré du premier jet.³

Les réserves tiennent à la tâche et au cadre. Il s’agissait de devoirs rédactionnels courts et autonomes, réalisés en ligne par des participants rémunérés, et non de mois de rédaction dans une entreprise réglementée avec des circuits de validation. Des effets exprimés en écarts-types disent aussi peu de choses en argent tant que personne n’attache un coût à une heure et à un défaut.

Reste la question de qui capte le bénéfice. Si un outil rapproche les rédacteurs plus faibles du niveau des plus solides, un manager verra peut-être une production plus uniforme plutôt qu’un besoin d’effectifs réduit. Savoir si cela vaut son prix dépend de ce que coûte aujourd’hui un mauvais premier jet en temps de relecture, et aucun des deux articles ne répond à cette question pour votre organisation.

Développeurs expérimentés : plus lents, et persuadés d’être plus rapides

L’essai METR est le plus gênant. Ses développeurs étaient des contributeurs expérimentés de grands projets open source, avec en moyenne plus de 22 000 étoiles et plus de 1 million de lignes de code, qu’ils pratiquaient depuis des années. Les tickets duraient en moyenne environ deux heures. Les développeurs choisissaient leurs outils, le plus souvent Cursor Pro avec Claude 3.5 et 3.7 Sonnet.¹

Le résultat, encore une fois : 19 % de temps en plus quand l’IA était autorisée.¹ L’échantillon est petit, avec 16 personnes, les outils datent du début de 2025, et la page de METR indique désormais que les résultats sont dépassés et renvoie vers des données plus récentes publiées en février 2026 sur des outils de fin 2025.¹ Le constat durable est l’écart de perception. Des personnes qui ont subi le ralentissement déclaraient encore un gain de vitesse, si bien que les gains auto-déclarés d’un sondage interne forment une base fragile pour un dossier d’investissement.

Pourquoi des personnes compétentes seraient-elles plus lentes avec un outil performant ? L’étude ne prouve aucun mécanisme, et nous ne prétendrons pas le contraire. Une lecture plausible est que, sur du code qu’on connaît bien, le temps passé à rédiger une consigne, à lire la sortie et à la corriger peut dépasser le temps de taper la correction. Si c’est le cas, le même outil pourrait aider un nouvel arrivant sur la base de code et gêner un vétéran. L’étude n’était pas conçue pour le tester.

La vue du marché du travail : de faibles effets sur la paie et les heures

Humlum et Vestergaard ont rapproché de grandes enquêtes sur l’adoption des agents conversationnels au Danemark et des registres administratifs du marché du travail. Avec des estimations en doubles différences au niveau du salarié et de l’établissement, ils trouvent des effets nuls précis sur les revenus et sur les heures enregistrées, et écartent des effets supérieurs à 2 % deux ans après le lancement de ChatGPT.⁴

Deux lectures sont possibles. Le temps gagné peut ne pas apparaître dans la paie ou les heures parce qu’il est absorbé par d’autres tâches ou jamais capté par l’employeur. Ou bien l’adoption reste superficielle en pratique. Les données ne permettent pas de trancher, et l’étude ne mesure pas la production par heure au sein d’une entreprise.

Pour un dirigeant, c’est un frein utile aux prévisions les plus optimistes, et tout autant aux plus pessimistes. Un résultat nul dans les registres nationaux deux ans après ne démontre pas que les tâches individuelles n’accélèrent pas. Il montre que, dans ce pays et sur cette période, l’économie de temps n’a pas encore déplacé les salaires ou les heures d’une façon que les données puissent détecter.

Ce que ces résultats suggèrent pour un déploiement

Aucune étude ne tranche à elle seule, et ces quatre ne mesurent pas la même chose. Lues ensemble, elles vont pourtant dans le même sens. Quand la tâche relevait de la compétence du modèle et était bien définie, comme dans les tâches BCG et les exercices rédactionnels, les résultats étaient positifs. Quand le travail était profond, riche en contexte et déjà confié à des experts, comme dans l’essai METR, ils étaient négatifs. Quand la réponse du modèle avait l’air juste sans l’être, les gens lui ont fait trop vite confiance.

Cette lecture est la nôtre, et aucun de ces articles ne la formule. Elle suggère que l’unité d’analyse est la tâche et le processus qui l’entoure, avec une vérification humaine placée là où les erreurs sont probables. Les auteurs de l’étude BCG ont observé que certains consultants se répartissaient le travail avec l’IA tandis que d’autres travaillaient avec elle en continu, et que c’étaient deux schémas distincts d’usage réussi.² La façon d’organiser le travail influe sur le résultat, ce qu’un nombre de licences ne capture pas.

Une seconde conséquence concerne la manière de juger le succès. Le temps gagné déclaré est l’indicateur le moins cher à collecter et, d’après les données METR, l’un des moins fiables.¹ Compter les licences activées coûte encore moins et ne dit rien des résultats. Les indicateurs qui résistent à l’examen sont plus lents à réunir : le temps écoulé par élément terminé, les défauts détectés en aval et la part de la production de l’IA réécrite avant usage.

Que faire ensuite

Traitez le premier déploiement comme une expérience avec une hypothèse et une règle d’arrêt. Une séquence pratique suit. Notre benchmark sur le travail intellectuel offre un moyen de comparer votre propre répartition de tâches à des données de référence.

Si vous voulez une première estimation de vos processus candidats, le pré-audit gratuit est un court questionnaire qui en fournit une. Quel que soit votre outil, exigez un chiffre mesuré sur votre propre travail avant de généraliser un déploiement, car les preuves publiées indiquent que les gains sont réels à certains endroits, absents à d’autres, et difficiles à sentir de l’intérieur.