Les gains de productivité apportés par les outils de code par IA sont réels. Ce qu'ils ne démontrent pas encore, c'est une amélioration proportionnelle de la qualité logicielle, du jugement produit ou de l'apprentissage organisationnel. Cet écart mérite d'être compris avant que la facture n'arrive.
À retenir :
- Le PDG d'Anthropic situe l'impact des outils de code par IA sur la productivité autour de 15 à 20 % — une estimation prudente venant de quelqu'un qui aurait toutes les raisons d'annoncer mieux. Les propres ingénieurs d'Anthropic, eux, ont déclaré un gain de 50 %. L'écart de 30 points entre ces deux chiffres est le point de départ d'une conversation plus honnête sur ce que ces outils font réellement.
- Un essai contrôlé randomisé a montré que des développeurs expérimentés travaillant sur des bases de code complexes auxquelles ils contribuaient depuis des années étaient mesurablement plus lents avec les outils d'IA — tout en restant convaincus d'aller plus vite.
- Goldman Sachs ne constate aucune relation significative entre l'adoption de l'IA et la productivité à l'échelle de l'économie, malgré de réels gains sur certains cas d'usage ciblés.
- Le risque ne vient pas des outils. Il vient de la pression concurrentielle, qui fait passer une adoption réfléchie pour une faiblesse — et une adoption négligente pour de l'audace.
- La friction du travail collectif — sessions de grooming, revues de code, le développeur qui dit "ces exigences se contredisent" — produisait autre chose que du logiciel. Les agents IA ne reproduisent pas ce sous-produit.
Que veut dire "vibe coding" — et pourquoi la définition compte-t-elle ?
La confusion commence avec le mot lui-même. En février 2025, Andrej Karpathy a forgé l'expression "vibe coding" dans un tweet — la description désinvolte d'un workflow de week-end où l'on s'en remet entièrement à l'IA, où l'on accepte tous les diffs sans les lire, et où l'on cesse de se soucier de comprendre le code. Il l'avait explicitement réservée aux projets jetables.
La suite est instructive. Karpathy a depuis indiqué qu'il préférait "agentic engineering" pour le travail sérieux — non parce qu'il aurait pris ses distances avec le code assisté par IA, mais parce qu'il estime que cette pratique mérite supervision, rigueur et savoir-faire. Dans une interview de mars 2026 sur le podcast No Priors, il a déclaré n'avoir pas tapé une ligne de code depuis décembre.
Dans le même temps, Gene Kim et Steve Yegge ont publié Vibe Coding: Building Production-Grade Software (2025), où ils définissent sous le même nom une pratique professionnelle rigoureuse, avec une préface de Dario Amodei. Ailleurs, le terme circule comme un péjoratif, comme un titre de fierté, comme une description de la démocratisation, ou encore comme un quasi-synonyme du développement assisté par IA en général.
Ce chaos définitionnel a son importance, car il permet à des pratiques très différentes de circuler sous la même étiquette. Une équipe qui utilise l'IA avec des revues disciplinées, une responsabilité claire et une vérification soigneuse peut, sur le papier, ressembler à une équipe qui accepte les sorties générées avec un examen minimal. Le terme est glissant ; les choix de gouvernance, eux, ne le sont pas.
Cet article n'est pas un plaidoyer contre le développement assisté par IA. C'est une question sur ce qui se passe lorsque la pression culturelle — adopter vite, adopter largement, annoncer une transformation — pousse les organisations à croire qu'elles font preuve de discernement alors qu'elles agissent à la légère.
Que disent les données sur la productivité du code par IA ?
Les estimations les plus crédibles sont plus modestes que les gros titres ne le laissent croire — et l'écart entre la perception et la réalité est frappant.
Dario Amodei, sur le Dwarkesh Podcast en février 2026, a livré sans doute l'estimation la plus honnête disponible de la part de quelqu'un directement concerné. Il chiffre l'impact des outils de code par IA sur la productivité autour de 15 à 20 % — une estimation délibérément prudente venant d'une personne qui aurait toutes les raisons d'annoncer mieux.
Une autre étude interne d'Anthropic, publiée fin 2025 et fondée sur l'enquête menée auprès de 132 ingénieurs maison, relève des gains de productivité auto-déclarés d'environ 50 %. Ce sont deux mesures différentes — l'une, une estimation large de productivité ; l'autre, des gains auto-déclarés par des ingénieurs d'une entreprise d'IA bénéficiant d'un accès anticipé privilégié aux outils — mais l'écart entre les deux mérite qu'on s'y attarde. Elles mesurent des choses différentes, et aucun des deux chiffres n'est précis. Un écart de 30 points entre deux estimations approximatives qui pointent dans des directions opposées en dit déjà long, surtout quand la plupart des décisions de réduction d'effectifs liées à l'IA reposent sur une productivité ressentie plutôt que sur une mesure indépendante.
L'essai contrôlé randomisé de METR — l'une des études indépendantes les plus rigoureuses menées à ce jour sur les outils de code par IA — s'est concentré précisément sur le contexte le plus pertinent pour les responsables d'ingénierie : des développeurs expérimentés travaillant sur des bases de code volumineuses, complexes et matures, auxquelles ils contribuaient depuis des années. Dans ce cadre, les développeurs utilisant des outils d'IA étaient 19 % plus lents que sans, alors qu'ils anticipaient au préalable une accélération de 24 %. Plus parlant encore : à l'issue de l'étude, ils estimaient que l'IA les avait rendus 20 % plus rapides — alors que les données objectives montraient l'inverse.
METR prend soin de souligner que ce résultat ne se généralise peut-être pas au-delà de ce contexte. Les outils d'IA peuvent se comporter différemment auprès de développeurs moins expérimentés, sur des bases de code méconnues ou sur des projets greenfield. Mais l'écart de perception — la déconnexion systématique entre la vitesse à laquelle les développeurs pensent travailler et celle à laquelle ils travaillent réellement — s'applique beaucoup plus largement. C'est cet écart, plus que le ralentissement lui-même, qui explique l'essentiel du débat actuel sur la productivité de l'IA.
Les économistes de Goldman Sachs, dans une analyse du T4 2025, n'ont trouvé "aucune relation significative entre la productivité et l'adoption de l'IA à l'échelle de l'économie". La même analyse identifie en revanche des gains de productivité d'environ 30 % sur des cas d'usage spécifiques et localisés — le code logiciel et le service client. La productivité par IA est une réalité par îlots. Ce n'est pas encore la transformation large que l'on annonce.
Ce que les données actuelles permettent de soutenir est plus étroit que le hype et que le contre-discours. Les outils de code par IA peuvent produire des gains significatifs dans certains contextes. Ils créent aussi un écart de perception récurrent, où l'accélération subjective dépasse l'amélioration mesurée. Ce que les données n'établissent pas encore, c'est qu'une production de code plus rapide se traduise de façon fiable par des gains proportionnels en qualité logicielle, en jugement produit ou en apprentissage d'équipe.
Le récit des plans sociaux résiste-t-il aux faits ?
Certaines des entreprises les plus bruyantes sur les coupes d'effectifs liées à la productivité de l'IA sont aussi celles où les preuves sont les plus minces.
Klarna en est l'exemple le plus instructif — rapporté en détail par Fortune. L'entreprise affirmait que son assistant IA assurait le travail de 700 agents de service client. Quelques mois plus tard, les clients se plaignaient de réponses génériques et de l'absence de support humain, et l'entreprise reprenait le recrutement de personnel humain. Le PDG Sebastian Siemiatkowski s'est exprimé sans détour sur ce qui s'était passé : "Le coût ayant malheureusement semblé être un facteur d'évaluation trop dominant… on finit avec une qualité moindre." Klarna ne prouve pas que les stratégies de remplacement par IA échouent toujours. C'est une illustration éclatante de ce qui passe à la trappe quand on confond volume traité et qualité livrée.
Klarna est le cas le mieux documenté — mais il n'est pas isolé. Tout au long de 2025 et 2026, plusieurs entreprises ont annoncé des réductions d'effectifs justifiées par l'IA, alors que des analystes et des initiés pointaient comme explication plus simple les sur-recrutements de la pandémie. Le marché a presque toujours récompensé le narratif IA, peu importe.
Une étude IBM auprès de 2 000 PDG a constaté qu'un seul projet d'IA sur quatre tient le retour sur investissement promis. Pourtant, près de deux tiers déclarent que le risque de prendre du retard les pousse à investir avant d'avoir une vision claire de la valeur.
Cette dernière statistique mérite qu'on s'y arrête. Le moteur principal de l'investissement dans l'IA n'est pas la preuve des retours — c'est l'angoisse de ce qui se passera si les concurrents avancent plus vite. Cette angoisse est compréhensible, et dans certains cas rationnelle. Mais elle crée les conditions d'une forme particulière d'aveuglement collectif : des organisations annoncent des transformations IA non pas parce que la transformation a eu lieu, mais parce que l'annoncer est devenu une nécessité concurrentielle. Le récit voyage plus vite que les résultats.
Et le temps que les résultats deviennent clairs, le récit a déjà façonné des décisions de recrutement, des attentes d'investisseurs et des engagements stratégiques difficiles à défaire.
Les outils sont réels. Le récit fait un travail que les outils, eux, ne font pas.
Pourquoi produire du code plus vite ne revient-il pas à faire un meilleur logiciel ?
C'est la question la plus importante — et elle dépasse le débat sur la productivité.
Ouvrez l'application Claude sur votre iPad. Elle fonctionne. C'est aussi, si vous l'utilisez régulièrement, un produit qui n'a manifestement pas été pensé en profondeur du point de vue de quelqu'un qui tient un iPad entre ses mains et veut que quelque chose lui semble juste.
Ce n'est pas, à la base, un problème de génération de code. C'est un problème de jugement : quelqu'un a dû décider de ce que l'application devait être, de la sensation qu'elle devait procurer à l'usage, et de ce qui ferait que vous l'ouvririez plutôt que d'aller dans le navigateur. Une meilleure génération de code peut accélérer la mise en œuvre, mais elle ne résout pas, à elle seule, cette couche de décision. La résoudre exige une attention soutenue à ce que d'autres êtres humains vivent réellement — et ce type d'attention est lent, incertain, et ne se vibe pas.
Quand la production devient rapide et bon marché, la pression économique pour réfléchir avant de construire diminue. On peut livrer en quelques jours quelque chose de plausible et itérer. L'effet cumulé, c'est que cette logique décourage activement l'investissement dans la véritable compréhension de l'utilisateur, celle qui rend un logiciel digne d'être utilisé. Pourquoi passer des semaines en recherche utilisateur quand on peut lancer et voir ce qui se passe ? Le problème, c'est que "voir ce qui se passe" ne produit un apprentissage utile que si l'on a déjà défini ce que l'on cherche et pourquoi. Sans cela, ce que vous lancez révèle moins que prévu, et corriger ce que vous trouvez coûte plus cher que prévu. Le temps que ce soit clair, les décisions sont déjà prises. C'est le même réflexe sous une autre forme : optimiser le visible et le rapide, reporter ce qui est lent et difficile à mesurer.
Cette tendance — optimiser la métrique excitante en négligeant le mécanisme qui la rend possible — n'est pas neuve. Quand un client se plaignit, dans les années 1920, des freins de sa voiture de course Type 35, Ettore Bugatti aurait répondu : "Je fais des voitures pour rouler, pas pour s'arrêter." La phrase a environ cent ans. La pensée qu'elle exprime est manifestement éternelle. Les voitures de Bugatti étaient belles, puissantes et notoirement sous-freinées. Elles allaient très vite, jusqu'à ne plus pouvoir.
En 2023, Gene Kim et Steven Spear ont publié Wiring the Winning Organization, une étude des organisations performantes qui nomme l'antidote : la slowification. Prendre le temps de planifier, de préparer et de bâtir une compréhension partagée avant d'exécuter n'est pas le contraire de la vitesse — c'est ce qui rend la vitesse soutenable. Les organisations qui investissaient dans une préparation délibérée surperformaient systématiquement celles qui considéraient chaque moment de délibération comme un coût à éliminer. Kim a ensuite cosigné Vibe Coding: Building Production-Grade Software — où il plaide précisément pour ce type de pratique rigoureuse et délibérée. Le principe qu'il identifiait en 2023 s'applique directement à la manière dont ce développement devrait être abordé.
Le plafond a été relevé sur la production. Celui de la compréhension n'a pas bougé.
Ce schéma n'est pas neuf. Chaque génération de meilleur outillage — langages plus expressifs, frameworks plus riches, infrastructure cloud — a rendu plus rapide et moins cher de construire des choses sans les comprendre. Le mouvement low-code promettait de démocratiser la création logicielle ; il a surtout livré des logiciels rapides à créer et frustrants à utiliser. Les outils de code par IA en sont la déclinaison la plus puissante à ce jour, pas l'invention.
L'écart entre ce que les organisations savent construire et ce qu'elles comprennent réellement s'est reproduit à chaque niveau d'abstraction. Il se reproduit aujourd'hui plus vite que jamais.
Que perd-on quand les agents IA remplacent les développeurs ?
Le jugement qui fait un bon logiciel n'a jamais été l'apanage des seuls product managers. Il était distribué — à travers l'équipe, par la friction du travail collectif.
Toute friction n'est pas précieuse. Une partie n'est que bureaucratie, latence, lourdeur évitable. Mais une autre partie est précisément l'endroit où se produit la compréhension collective — et la vague d'automatisation actuelle facilite la suppression simultanée des deux.
Ce n'est pas pure théorie. Dans les communautés d'ingénierie, en ce moment, quelque chose revient avec constance dans la manière dont les développeurs décrivent leur propre expérience : livrer plus vite, se sentir plus productif, et perdre discrètement prise sur ce que le système fait réellement et pourquoi. Les recherches citées plus haut le confirment au niveau macro. Les conversations aussi.
Quand un développeur s'opposait en session de grooming — "je ne peux pas construire ça parce que deux de ces exigences se contredisent directement" — l'organisation était forcée d'affronter quelque chose qu'elle avait réussi à éviter. Cet inconfort n'était pas un échec du processus de planification. C'était le processus de planification en train de fonctionner. L'exigence avait été rédigée d'une manière qui paraissait cohérente jusqu'à ce que quelqu'un essaie réellement de l'implémenter. La confusion du développeur était le miroir de l'organisation.
Quand une revue de code se déroulait entre un Engineer senior et un junior, les deux en ressortaient avec quelque chose qu'ils n'avaient pas auparavant. Le junior apprenait à penser une classe de problèmes. Le senior, lui, devait formuler quelque chose qu'il ne connaissait jusque-là que tacitement — et l'acte même de formuler l'aiguisait. La conversation était l'apprentissage. Le code en était le résidu.
Cette distinction compte plus qu'il n'y paraît. Michael Polanyi a passé une carrière à la préciser. "Nous savons plus que nous ne pouvons dire", écrivait-il dans The Tacit Dimension — et le corollaire est que ce que nous pouvons dire est toujours moindre que ce que nous savons réellement.
La compréhension construite par la pratique est différente, par nature, de l'information acquise par la lecture ou l'instruction. Vous ne pouvez pas lire pour savoir comment un système complexe défaille en charge, ou comment un type particulier d'utilisateur rencontre un type particulier de confusion. Il faut y avoir été — avoir tenu le modèle en main, l'avoir vu casser, et avoir reconstruit la compréhension révisée à partir de l'épave de la précédente.
C'est ce que la session de grooming et la revue de code produisaient, comme sous-produit de la friction, qu'on le nomme ou non.
Un agent IA ne produit pas ces sous-produits. Il avance sans broncher. La conformité de l'agent n'est pas la preuve que vos exigences étaient claires. C'est la preuve que l'agent ne se plaint pas.
Vous pouvez relire le code d'un agent IA. Vous ne pouvez pas avoir cette conversation avec lui. L'agent ne portera pas la revue plus loin sous forme de compréhension. Le développeur junior qui se serait formé à travers des années de tels échanges est de moins en moins recruté. Et l'organisation qui a remplacé ces échanges par du code généré a supprimé un mécanisme dont elle ignorait peut-être qu'elle dépendait — un mécanisme qui faisait tout autre chose que produire du logiciel.
La question qui mérite d'être posée
La métrique pertinente n'est pas seulement la vitesse à laquelle vous livrez. C'est de savoir si les gains de production s'accompagnent de gains en clarté, en jugement et en apprentissage.
Ce n'est pas un plaidoyer contre les outils d'IA. Bien utilisés — avec la supervision, le savoir-faire et le jugement que Karpathy, Kim et Yegge revendiquent tous — ces outils sont véritablement précieux. La question est de savoir si le moment présent crée les conditions de ce type d'usage. L'angoisse concurrentielle, la pression à livrer avant de réfléchir, le sentiment croissant que ralentir pour comprendre relève de la sous-performance : rien de tout cela n'est produit par les outils eux-mêmes. C'est l'air culturel qui les entoure aujourd'hui.
Les pilotes de course savent que les freins ne servent pas à ralentir. Ils servent à permettre l'engagement — à pouvoir attaquer plus fort dans les virages parce qu'on fait confiance à sa capacité de s'arrêter en cas de pépin. La friction que les équipes suppriment actuellement au nom de la vélocité, c'était souvent exactement cela : ni surcharge, ni inefficacité, mais le mécanisme qui rendait la vitesse possible en premier lieu. Le praticien rigoureux du développement assisté par IA le sait. L'organisation emportée par l'angoisse concurrentielle, souvent non.
Livrer plus de code n'a jamais été la même chose que faire un meilleur logiciel — et ne l'a jamais été. Le code a toujours été un artefact — le résidu visible de la compréhension qui l'a produit, pas la compréhension elle-même. Ce qui a changé, ce n'est pas la confusion entre artefact et compréhension. C'est la rapidité et le faible coût avec lesquels on peut désormais entretenir cette confusion à grande échelle.
La question qui mérite d'être posée — honnêtement, précisément, à propos de votre propre équipe — est de savoir laquelle de ces adoptions vous pratiquez réellement. Et cette question gagne généralement à être éclairée par un regard extérieur — quelqu'un qui a vu les deux et sait quoi chercher.
Ces questions n'ont pas de réponses toutes faites — et quiconque prétend le contraire ne se les pose probablement pas assez sérieusement. Chez DoiT, nous avons accompagné des centaines de responsables d'ingénierie et de technologie aux prises avec exactement cette tension — décidant quoi conserver, quoi changer, et ce qu'ils étaient sur le point de perdre sans s'en rendre compte. Nous avons constaté que les bonnes questions, posées avec les bonnes personnes, produisent généralement de meilleures réponses que n'importe quel framework. Si vous voyez quelque chose qui nous échappe, ou si vous avancez sur ces enjeux d'une manière qui fonctionne, nous serions ravis d'en discuter.
Foire aux questions
Quelles sont les différentes acceptions de "vibe coding" ? Le terme a aujourd'hui au moins trois sens distincts. Dans son sens originel — forgé par Andrej Karpathy en février 2025 — il décrivait un workflow décontracté, fondé sur l'abandon, adapté aux projets jetables. Gene Kim et Steve Yegge ont ensuite défini, sous le même nom, une pratique professionnelle sérieuse dans leur livre de 2025 Vibe Coding: Building Production-Grade Software, en mettant l'accent sur la rigueur, la supervision et le savoir-faire. Dans l'usage courant, il sert aussi de synonyme général au développement assisté par IA, ou à l'inverse de péjoratif désignant une adoption négligente de l'IA. Ce chaos définitionnel compte : quand un même terme désigne à la fois l'acceptation aveugle des sorties d'IA et une ingénierie agentique disciplinée, parler utilement de ce que telle ou telle équipe fait devient très difficile.
Les outils de code par IA peuvent-ils améliorer la productivité sans améliorer la qualité logicielle ? Oui. Les données suggèrent qu'ils le font déjà à grande échelle. Les outils d'IA peuvent augmenter de façon mesurable le volume de code produit et raccourcir les cycles de livraison sans améliorer le jugement qui détermine ce qui est construit, la clarté des exigences, ni la profondeur de la compréhension utilisateur derrière le produit. Goldman Sachs constate de réels gains de productivité dans le code logiciel comme cas d'usage spécifique. Ce que l'on n'observe pas — et que les preuves plus larges ne montrent pas encore — c'est que ces gains se traduisent par des améliorations proportionnelles en qualité logicielle ou en résultats produit.
Qu'a réellement trouvé l'étude METR sur le code par IA ? L'essai contrôlé randomisé de METR en 2025 a testé 16 développeurs expérimentés sur 246 tâches réelles, sur de grandes bases de code open source matures qu'ils connaissaient bien. Les développeurs utilisant des outils d'IA ont mis 19 % de temps en plus pour réaliser leurs tâches que sans, alors qu'ils anticipaient au préalable une accélération de 24 % et croyaient encore avoir été plus rapides après coup. METR souligne que ce résultat est spécifique à ce contexte et peut ne pas se généraliser à des développeurs moins expérimentés ou à des bases de code méconnues. L'écart de perception — croire systématiquement que l'IA aide alors que les données montrent l'inverse — est le résultat le plus largement applicable.
Pourquoi un tel écart entre la productivité IA auto-déclarée et celle mesurée ? Deux points de données illustrent cet écart sous des angles différents. Lors de son passage au podcast en février 2026, Dario Amodei a estimé l'impact des outils de code par IA sur la productivité autour de 15-20 %. Une autre étude interne d'Anthropic datant de fin 2025 a montré que les ingénieurs d'Anthropic eux-mêmes déclaraient un gain de productivité de 50 % — une mesure différente, mais l'écart entre les deux est instructif. L'étude de METR a relevé un schéma perceptuel similaire : les développeurs croyaient que l'IA les avait accélérés de 20 %, alors que la mesure objective indiquait un ralentissement de 19 %. L'analyse de METR sur cet écart pointe plusieurs facteurs : le code assisté par IA exige moins d'effort cognitif et donne une impression de rapidité même quand ce n'est pas le cas ; les développeurs peuvent confondre facilité et vitesse ; le temps passé à relire, corriger et nettoyer le code généré par IA n'est généralement pas comptabilisé dans les auto-déclarations.
Que s'est-il passé quand Klarna a remplacé ses agents de service client par de l'IA ? Klarna a remplacé environ 700 postes de service client par un assistant IA développé avec OpenAI, en affirmant que l'IA accomplissait un travail équivalent. Quelques mois plus tard, les clients se plaignaient de réponses génériques et de l'absence de support humain, les agents IA peinant face à des interactions complexes, nuancées et chargées d'émotion. Le PDG Sebastian Siemiatkowski a reconnu l'erreur sans détour : "Le coût ayant malheureusement semblé être un facteur d'évaluation trop dominant… on finit avec une qualité moindre." L'entreprise a repris le recrutement de personnel humain en service client en 2025. Le cas est instructif non seulement comme histoire d'échec, mais comme illustration de ce qui se perd quand la métrique devient le volume traité plutôt que la compréhension démontrée.
Qu'est-ce que la slowification, et pourquoi est-ce important pour les équipes logicielles ? La slowification est un concept tiré du livre de 2023 de Gene Kim et Steven Spear, Wiring the Winning Organization. Elle décrit l'investissement délibéré dans la planification, la préparation et la compréhension partagée avant l'exécution — ralentir afin d'aller plus vite et plus sûrement en aval. Leurs recherches sur des organisations performantes ont montré qu'il s'agissait d'un différenciateur constant : les équipes qui pratiquaient la slowification surperformaient systématiquement celles qui considéraient chaque moment de délibération comme un coût. Le principe s'applique directement au développement logiciel : la session de grooming, la recherche utilisateur soignée, la revue de code qui paraissait lente accomplissaient souvent exactement cela — produire le savoir partagé sur lequel repose une exécution confiante.
Les outils d'IA peuvent-ils augmenter la production tout en réduisant la compréhension ? Oui — et c'est sans doute une question plus importante que celle de savoir s'ils augmentent la productivité. Production et compréhension sont produites par des mécanismes différents. Le code est produit par l'exécution ; la compréhension, par la friction du travail collectif sur un problème — le développeur qui s'oppose à des exigences contradictoires, la revue de code où un ingénieur senior doit formuler quelque chose qu'il ne connaissait jusque-là que tacitement, la session de grooming où une équipe découvre que ce qui semblait être une spécification claire ne l'était pas. Les agents IA avancent sans générer ces sous-produits. Ils ne se plaignent pas, ne clarifient pas, ne portent pas la conversation plus loin sous forme d'apprentissage. Une organisation peut livrer davantage de logiciel tout en perdant prise, simultanément, sur ce que ses systèmes font, sur la raison pour laquelle ils ont été conçus ainsi, et sur ce dont ses utilisateurs ont réellement besoin. La production augmente. La compréhension qui devrait l'accompagner ne suit pas le rythme.
Goldman Sachs estime-t-il que l'IA n'a aucun impact sur la productivité ? Pas exactement. Les économistes de Goldman Sachs, dans la même analyse du T4 2025, ne trouvent aucune relation significative entre l'adoption de l'IA et la productivité à l'échelle de l'économie. Cette même analyse identifie en revanche des gains de productivité d'environ 30 % sur des cas d'usage spécifiques et localisés — le code logiciel et le service client étant les deux les plus cités. Le tableau est celui de gains réels dans certains contextes, qui ne se traduisent pas encore par une amélioration large de la productivité économique. Cette distinction compte pour la manière dont les organisations devraient penser leurs investissements IA : une adoption ciblée sur des contextes où les gains sont bien documentés est différente d'un traitement de l'IA comme multiplicateur de productivité à usage général.