La productivité IA, mesurée

Le ressenti contre la mesure

En 2025, l'institut METR a mené une expérience rare : mesurer rigoureusement des développeurs expérimentés sur de vrais dépôts open source, avec et sans assistance IA. Résultat contre-intuitif : avec l'IA, ils étaient environ 19 % plus lents — alors qu'eux-mêmes estimaient avoir été plus rapides. L'écart entre productivité ressentie et productivité mesurée est le vrai enseignement de l'étude.

Cela ne signifie pas que l'IA ne sert à rien. Cela signifie que le gain n'est ni automatique, ni universel — et qu'il faut le mesurer plutôt que le supposer.

Ce que METR a vraiment mesuré

Le protocole mérite d'être connu, parce qu'il explique la force du résultat. METR a recruté des développeurs expérimentés, mainteneurs de dépôts open source qu'ils connaissaient intimement — pas des débutants sur du code inconnu. Chaque tâche (de vraies issues de leurs propres projets) était assignée aléatoirement avec ou sans assistance IA, outillage de début 2025. On mesure le temps réel de complétion, et on demande aussi aux développeurs d'estimer leur gain.

Résultat : ils s'estimaient environ 20 % plus rapides avec l'IA… et étaient environ 19 % plus lents. Près de quarante points d'écart entre la perception et la mesure. C'est ce protocole — randomisé, sur du vrai travail — qui rend le chiffre difficile à balayer d'un revers de main.

Les limites, honnêtement : l'échantillon est petit, le contexte particulier (experts sur LEUR code, où l'IA a le moins à apporter), et les outils évoluent vite. L'étude ne dit pas « l'IA ralentit tout le monde » — elle dit que le gain ne va pas de soi, même pour des profils qu'on imaginerait les mieux placés.

D'où vient l'écart entre ressenti et réalité

Pourquoi des professionnels aguerris se trompent-ils à ce point sur leur propre vitesse ? Trois mécanismes bien identifiés :

• Le temps invisible : écrire le prompt, attendre, lire la proposition, la corriger — chaque boucle paraît courte, mais leur somme ne s'enregistre pas comme du « travail ». Taper son propre code, si.
• Le coût de vérification : une suggestion plausible doit être relue avec plus d'attention que son propre code, justement parce qu'on ne sait pas où elle peut se tromper. Cette vigilance fatigue et ralentit — silencieusement.
• Le plaisir de la délégation : déléguer procure une sensation d'efficacité, indépendamment du résultat. C'est agréable, donc ça paraît rapide. Le chronomètre n'a pas d'états d'âme.

La leçon n'est pas « méfiez-vous de l'IA » mais « méfiez-vous du déclaratif » : toute décision d'équipement fondée sur « on se sent plus productifs » repose sur la métrique la moins fiable qui existe.

Où l'IA aide vraiment

• Le code répétitif : boilerplate, tests, migrations, documentation — fort volume, faible ambiguïté.
• La découverte : comprendre une base de code inconnue, explorer une API, comparer des approches.
• Les langages et domaines moins maîtrisés : l'IA aide davantage le développeur hors de sa zone d'expertise que dans son cœur de métier.

Et où elle fait perdre du temps

• Sur du code complexe et spécifique, relire et corriger des suggestions plausibles mais fausses coûte plus que d'écrire soi-même.
• Sans contexte du projet (conventions, architecture, historique), l'IA propose du code générique qui crée de la dette.
• L'effet « ça avance » masque le temps réel passé à itérer sur des prompts.

Le levier n'est pas l'outil. C'est le contexte qu'on lui donne.

Les conditions d'un vrai gain

Les équipes qui gagnent réellement en productivité ont trois points communs : elles donnent à l'IA le contexte du projet (conventions, architecture, mémoire des décisions), elles mesurent l'impact au lieu de le déclarer, et elles gardent une revue humainesystématique. C'est une question de méthode et de direction technique — pas d'abonnement à un outil. C'est d'ailleurs l'un des premiers chantiers d'un CTO externe : transformer un usage individuel et dispersé de l'IA en pratique d'équipe outillée et mesurée.

Comment mesurer chez vous

Inutile de reproduire le protocole de METR pour objectiver l'effet de l'IA dans votre équipe. Trois mesures simples, tenues sur quelques semaines, suffisent à sortir du déclaratif :

• Le temps de cycle par type de tâche : durée entre prise en charge et mise en production, ventilée entre tâches répétitives et tâches métier complexes — c'est là que l'écart se voit.
• Le taux de retouche : proportion de code assisté par IA repris en revue ou corrigé après coup. Un gain de vitesse annulé par les retours n'est pas un gain.
• La comparaison avant/après à périmètre constant : sur une même catégorie de tickets, pas sur des sprints différents — sinon on mesure la météo du projet, pas l'outil.

Ce dispositif tient dans un tableau de bord d'équipe et évite les deux écueils symétriques : l'enthousiasme déclaratif (« on va deux fois plus vite ») et le rejet de principe. Entre les deux, il y a vos chiffres.

Ce que ça change pour votre équipe

Si le gain dépend du contexte et de la méthode, alors la question d'organisation devient plus importante que la question d'outillage. Trois conséquences pratiques :

Le métier se déplace vers la revue et le cadrage. Plus l'IA produit de code, plus la valeur se concentre sur ceux qui savent juger ce code : architecture, cas limites, sécurité. Le jugement technique devient le facteur limitant — pas la vitesse de frappe. C'est aussi pourquoi la séniorité compte davantage, pas moins, à l'ère de l'IA.

Le contexte projet devient un actif. Conventions écrites, architecture documentée, mémoire des décisions : tout ce qui aide un nouveau développeur aide aussi l'IA — et démultiplie son rendement. Les équipes qui investissent dans cette « ingénierie de contexte » creusent l'écart.

La formation ne s'improvise pas. Savoir découper une tâche pour l'IA, détecter une suggestion plausible mais fausse, décider quand reprendre la main : ce sont des compétences qui s'apprennent. Les laisser se développer « naturellement » produit exactement la situation que METR a mesurée.