Avec GitHub Copilot, l'IA a augmenté la productivité des développeurs de Microsoft, d'Accenture et d'un grand fabricant d'électronique, qui ont terminé 26 % de tâches en plus par semaine. C'est le résultat d'une étude randomisée publiée dans Management Science. Le gain profite d'abord aux profils juniors, et il bute sur un obstacle très concret, puisque quatre développeurs sur dix n'utilisent toujours pas l'outil au bout d'un an.
Des équipes de développement sous pression, et peu de mesures fiables
Depuis l'arrivée des assistants de code, les directions informatiques entendent deux discours opposés. Les éditeurs promettent des équipes plus rapides. Les développeurs expérimentés, eux, décrivent souvent un outil qui propose du code approximatif qu'il faut ensuite corriger.
Un directeur des systèmes d'information doit pourtant décider s'il paie une licence par développeur, et ce qu'il peut en attendre. Pour trancher, il lui faut des mesures prises dans le quotidien d'une équipe qui maintient un vrai logiciel, et non sur des exercices de démonstration.
C'est ce manque que comble le travail de Cui, Demirer, Jaffe, Musolff, Peng et Salz (4 867 développeurs selon leur document de travail), présenté par MIT Sloan. Ces chercheurs du MIT, de Princeton, de Microsoft et de Wharton ont suivi des développeurs dans leur travail réel, sur des mois, avec un groupe témoin.
Près de 5 000 développeurs suivis dans trois entreprises
L'étude repose sur trois expériences de terrain randomisées, c'est-à-dire que l'accès à l'outil a été attribué par tirage au sort. Elles portent sur près de 5 000 développeurs au total. Chez Microsoft, l'expérience a duré sept mois. Chez Accenture, elle a couru sur quatre mois. Le troisième terrain est un fabricant d'électronique classé au Fortune 100, resté anonyme, où le déploiement s'est fait par vagues sur deux mois.
L'outil testé est GitHub Copilot, un assistant de code qui suggère des lignes ou des fonctions entières pendant que le développeur écrit.
Le tirage au sort donne à ce résultat un poids que n'ont pas les enquêtes déclaratives. Les deux groupes travaillaient dans les mêmes entreprises, à la même période. L'écart mesuré entre eux peut donc être attribué à l'outil, et non à une différence de profil ou de motivation.
Les chercheurs comptent ce que les développeurs livrent chaque semaine, et non ce qu'ils disent gagner. Cela évite l'écueil classique de l'utilisateur enthousiaste qui surestime son propre gain.
L'IA améliore surtout la productivité des développeurs juniors
En moyenne sur les trois entreprises, le nombre de tâches terminées par semaine augmente de 26 % dans le groupe équipé de Copilot. Ce chiffre global masque une différence nette selon l'ancienneté, et c'est elle qui intéresse le plus un responsable d'équipe.
Chez les développeurs récemment embauchés ou juniors, le gain se situe entre 27 et 39 %. Chez les seniors, il tombe entre 8 et 13 %. L'outil aide donc beaucoup ceux qui connaissent mal le code de l'entreprise ou le langage utilisé, et beaucoup moins ceux qui le maîtrisent déjà.
Ce résultat rejoint exactement ce qui a été mesuré dans un tout autre métier. Dans les centres d'appels, les conseillers débutants avaient aussi tiré le plus de profit de l'assistant, comme nous l'avons détaillé à propos du même effet mesuré au service client. Dans les deux cas, l'IA transmet aux nouveaux venus une partie du savoir-faire que les anciens ont accumulé.
L'explication est assez intuitive quand on regarde le travail d'un développeur junior. Une bonne partie de sa semaine consiste à chercher comment faire une chose que ses collègues font sans y penser. L'assistant de code lui propose une piste immédiate, là où il aurait perdu une heure dans la documentation ou attendu la disponibilité d'un senior.
Quatre développeurs sur dix n'utilisent pas l'outil
L'autre enseignement de l'étude concerne l'adoption de l'outil d'IA. Au bout d'un an, environ 60 % des développeurs à qui Copilot avait été fourni l'utilisaient. Les 40 % restants ne s'en servaient pas, alors même que la licence était payée et l'accès ouvert.
Pour une direction informatique, ce chiffre change le calcul. Quatre licences sur dix peuvent rester sans effet quand personne n'accompagne le déploiement. Distribuer des licences ne suffit donc pas, il faut aussi que les équipes changent leur façon de travailler.
L'étude ne détaille pas les raisons de ce refus. En mission, nous voyons souvent les mêmes freins. Certains développeurs n'ont jamais eu de temps dédié pour apprendre l'outil, d'autres l'ont essayé une fois sur une tâche mal choisie et l'ont abandonné. Il arrive aussi que les règles internes sur la confidentialité du code restent floues, et que personne n'ose l'utiliser sur le vrai projet.
Ce que le chiffre de 26 % ne dit pas
La première limite est reconnue par les auteurs eux-mêmes. Ils mesurent le volume de travail livré, pas la qualité du code produit, à laquelle ils n'avaient pas accès. Plus de tâches terminées ne veut pas forcément dire moins de défauts, ni un code plus facile à maintenir dans deux ans.
Ce point compte particulièrement pour les juniors. Si un développeur débutant accepte une suggestion qu'il ne comprend pas entièrement, il livre plus vite mais peut introduire une erreur que personne ne verra avant la mise en production. La relecture du code par un pair reste donc indispensable, et elle pèse surtout sur les seniors.
La deuxième limite tient au contexte. Une autre étude, publiée par le laboratoire METR en 2025, a mesuré que seize développeurs très expérimentés, sur 246 tâches de leurs propres projets, étaient 19 % plus lents avec l'IA. Le détail qui frappe : avant l'expérience, ils pensaient gagner environ 24 % de temps, et après, ils estimaient encore avoir été 20 % plus rapides. L'échantillon est petit, mais l'écart entre ressenti et mesure est net. Le ressenti et la mesure divergent, ce qui plaide pour compter plutôt que sonder.
Le gain dépend donc de la personne, de la tâche et de sa connaissance du code. On retrouve là la logique mise en évidence par l'étude BCG sur les limites de l'IA, où l'outil aidait sur certaines tâches et dégradait le résultat sur d'autres.
Enfin, les trois terrains sont de très grandes entreprises, avec des équipes nombreuses, des processus de développement établis et des outils de suivi précis. Une équipe de cinq développeurs dans une PME n'a pas le même profil. L'ordre de grandeur reste utile, mais il ne se transpose pas tel quel.
Ce que ça change pour une PME ou une ETI
Prenons une ETI industrielle des Hauts-de-France qui emploie une équipe informatique interne de huit personnes. Elle maintient un logiciel de gestion de production développé il y a quinze ans. Deux développeurs seniors connaissent ce code par cœur, trois ont été recrutés dans les deux dernières années, et le reste de l'équipe gère les intégrations avec l'ERP.
D'après l'étude, c'est chez les trois recrutés récents que l'assistant de code en entreprise a le plus de chances de produire un effet mesurable. Il les aide à comprendre un code ancien, peu documenté, sans mobiliser en permanence les deux seniors. Ces derniers récupèrent du temps pour la conception et la relecture, là où leur expérience a le plus de valeur.
Encore faut-il que les juniors utilisent réellement l'outil, faute de quoi l'abonnement devient une ligne de dépense de plus. Pour une équipe de cette taille, nous recommandons de commencer par trois décisions simples.
- Fixer par écrit ce que l'assistant a le droit de voir, en particulier pour le code et les données sensibles.
- Former l'équipe sur ses propres projets, avec des exemples tirés de son code, plutôt que sur des exercices génériques.
- Suivre l'usage réel pendant trois mois, et interroger ceux qui ne s'en servent pas.
La formation est souvent le maillon qui manque. Notre formation aux assistants de code part des dépôts de l'entreprise et des tâches que l'équipe traite chaque semaine. Une partie de ce coût peut être prise en charge, et nous détaillons les dispositifs dans notre guide pour financer une formation à l'IA.
Pour un éditeur de logiciels, l'enjeu est encore plus direct, puisque le code est le produit vendu. La vitesse de livraison d'une équipe de développement pèse sur la feuille de route et sur la capacité à répondre aux demandes des clients. Nous accompagnons ce type d'entreprise sur l'IA pour les éditeurs de logiciels, de l'outillage des équipes jusqu'aux fonctions d'IA intégrées au produit.
Sur le terrain, nous arrivons au même point de vue. Sans règles claires, sans formation et sans suivi de l'usage, on paie la licence pour tout le monde et on obtient le gain pour la moitié de l'équipe.
Sources
- The Effects of Generative AI on High-Skilled Work, Management Science, 2025
- How generative AI affects highly skilled workers, MIT Sloan, 2024
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, juillet 2025
