Un dirigeant de PME peut, dans la même semaine, croiser deux chiffres qui ne semblent pas venir de la même planète. Un support d'éditeur annonce un retour sur investissement de 2 800 % sur un déploiement d'IA. Une étude universitaire, parue quelques mois plus tôt, mesure un gain de 14 % sur une tâche bien définie. Une troisième, plus gênante, observe que des développeurs chevronnés travaillent plus lentement avec l'assistant qu'ils croient pourtant utile. La question n'est pas de savoir qui ment, mais de comprendre ce que chaque chiffre mesure vraiment, puis de repérer celui qui s'applique à votre entreprise.
Trois études, trois mondes
En juillet 2025, le laboratoire METR a mené un essai contrôlé randomisé, la méthode de référence des essais cliniques. Seize développeurs open source expérimentés ont traité 246 tâches réelles, tirées de dépôts qu'ils connaissaient déjà, chaque tâche étant assignée au hasard avec ou sans IA. Avec l'accès aux outils d'IA, ils ont mis 19 % de temps en plus pour finir1. L'étude précise ses limites: contributeurs aguerris, code mûr, outils du début 2025. Elle ne dit rien des débutants ni des projets neufs.
Deux ans plus tôt, un travail publié par le NBER pointait dans l'autre sens. Erik Brynjolfsson, Danielle Li et Lindsey Raymond ont suivi 5 179 agents de support client d'une grande entreprise, sur près de trois millions de conversations. L'accès à un assistant a relevé la productivité de 14 % en moyenne. Le détail compte plus que la moyenne: les gains se concentrent sur les agents les moins expérimentés et frôlent zéro pour les meilleurs2.
Enfin, le rapport MIT NANDA « The GenAI Divide », paru en août 2025, a analysé 300 déploiements et conclu que 95 % des projets pilotes n'avaient produit aucun effet mesurable sur le compte de résultat. Les auteurs relèvent un biais d'allocation: les budgets vont surtout au marketing et aux ventes, alors que le rendement observé est meilleur dans les opérations et la finance3.
Pourquoi l'écart est aussi large
Trois différences suffisent à expliquer un rapport de un à deux cents entre ces chiffres.
La première tient à qui mesure. Un essai randomisé compare deux groupes tirés au sort et chronomètre le résultat. Un chiffre de vendeur repose le plus souvent sur du déclaratif, sur un cas unique et sur une méthode que personne ne peut rejouer. Le gain de 2 800 % cité plus haut provient d'un billet de prestataire qui ne publie ni protocole ni périmètre4. Ce n'est pas inutilisable, à condition de le lire comme un argument commercial et non comme une mesure.
La deuxième porte sur le périmètre. Le NBER chronomètre une tâche répétitive et cadrée, le support par chat, où l'IA excelle. METR mesure un travail de développement complexe sur du code existant, où la relecture et la correction annulent le temps gagné à écrire. Deux réalités différentes donnent deux chiffres différents, sans qu'aucun ne soit faux.
La troisième concerne la population. Le même outil aide beaucoup un débutant et presque pas un expert, comme le montre l'écart interne à l'étude du NBER. Une moyenne d'entreprise cache donc des situations opposées selon les équipes.
Quand le ressenti dépasse la mesure
Le résultat le plus utile de l'étude METR ne porte pas sur le temps, mais sur la perception. Avant l'expérience, les développeurs pensaient gagner 24 % de temps. Après l'avoir vécue, en ayant en réalité perdu du temps, ils estimaient encore avoir été 20 % plus productifs1. L'écart entre le ressenti et la mesure atteint près de quarante points.
Ce biais se retrouve dans un ERP. Un commercial qui rédige un devis avec un assistant a le sentiment d'aller vite, parce que la première version sort en quelques secondes. Le temps passé ensuite à vérifier les remises, à corriger une référence produit ou à reprendre une clause reste invisible dans ce ressenti. La fluidité immédiate se confond avec la productivité, alors que le cycle complet, du besoin client à la commande validée, raconte parfois une autre histoire.
Mesurer chez vous plutôt que croire
Aucun chiffre externe ne remplace une mesure locale, parce que votre gain dépend de vos processus, de vos données et de vos équipes. Un protocole simple suffit à sortir du débat des moyennes.
| Étape | Ce qu'on fait | Piège à éviter |
|---|---|---|
| Choisir un processus | Un seul, fréquent et mesurable (devis, facture fournisseur, réponse support) | Vouloir tout instrumenter d'un coup |
| Établir la ligne de base | Chronométrer le cycle complet sans IA sur plusieurs semaines | Se fier au souvenir des équipes |
| Comparer proprement | Deux groupes, ou avant/après sur la même équipe | Changer l'outil et l'organisation en même temps |
| Compter le retravail | Inclure corrections, allers-retours et rejets en aval | S'arrêter au premier jet produit |
| Tenir la durée | Observer sur six à douze semaines | Conclure sur les trois premiers jours d'enthousiasme |
Cette approche vaut aussi pour décider où investir. Le rapport MIT NANDA suggère de regarder du côté des opérations et de la finance, souvent délaissées au profit du marketing. Dans un ERP, cela désigne des tâches précises: rapprochement bancaire, relance client, contrôle de facture fournisseur, où le volume répétitif offre une base de mesure claire et un gain qui se vérifie ligne à ligne.
Le contexte français va dans ce sens. La part des TPE-PME ayant lancé un projet d'IA a fortement progressé, mais une bonne moitié s'appuie sur des outils gratuits et non pilotés, comme nous l'avons détaillé dans notre article sur l'adoption de l'IA. Sans mesure, un projet reste au stade de l'impression, et l'impression se trompe de quarante points.
Notre lecture
Nous ne retenons aucun des trois chiffres comme vérité générale, et c'est le message. Le 14 % du NBER, le moins 19 % de METR et le 95 % du MIT décrivent des situations réelles mais différentes, dont aucune n'est la vôtre par défaut. Un chiffre de vendeur qui ne publie pas sa méthode se traite comme une promesse à vérifier, pas comme un résultat.
Pour une PME ou une ETI qui déploie l'IA dans son ERP, la conduite pratique tient en peu de mots. Choisir un processus, mesurer son cycle complet avant l'outil, recommencer après, et compter le retravail que le ressenti oublie. Le gain existe souvent, surtout sur les tâches répétitives et pour les profils les moins expérimentés. Il est rarement spectaculaire, il ne se voit pas à l'œil nu, et il ne ressemble jamais tout à fait au chiffre du prospectus.
Sources
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity : https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- NBER, Generative AI at Work (Brynjolfsson, Li, Raymond) : https://www.nber.org/papers/w31161
- MIT NANDA, The GenAI Divide: State of AI in Business 2025 : https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
- Focus AI, ROI de la formation IA en PME (exemple de chiffre commercial) : https://www.focus-ai.fr/blog/roi-formation-ia-pme-resultats-200-entreprises
Footnotes
-
METR, essai contrôlé randomisé de juillet 2025, seize développeurs open source expérimentés, 246 tâches. Temps de réalisation supérieur de 19 % avec les outils d'IA, alors que les participants s'attendaient à un gain de 24 % et estimaient a posteriori un gain de 20 %. ↩ ↩2
-
Erik Brynjolfsson, Danielle Li, Lindsey Raymond, « Generative AI at Work », NBER working paper 31161. 5 179 agents de support client, environ trois millions de conversations, gain moyen de 14 % concentré sur les agents les moins expérimentés. ↩
-
MIT NANDA, « The GenAI Divide: State of AI in Business 2025 » (août 2025). Analyse de 300 déploiements: 95 % des pilotes sans effet mesurable sur le compte de résultat, budgets biaisés vers le marketing et les ventes. ↩
-
Cas de retour sur investissement de 2 800 % avancé par un billet de prestataire, sans protocole ni périmètre publié: exemple d'un chiffre commercial non reproductible, cité ici à titre d'illustration. ↩