💻 computer science

GitHub Copilot and Developer Productivity: An Observational Dose-Response Analysis

En utilisant 16 223 ingénieurs Microsoft sur 43 semaines et un plan à effets fixes par ingénieur pour contrôler les compétences et l'effort individuels, cette étude conclut que l'utilisation de GitHub Copilot est associée à une augmentation monotone de 40,5 % des taux d'achèvement des pull requests pour un temps de codage équivalent, indiquant un véritable gain d'efficacité plutôt qu'une corrélation avec des périodes de travail intrinsèquement plus denses.

Auteurs originaux : Alex Heilman, Alex Kyllo, Emerson Murphy-Hill

Publié 2026-06-02

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Alex Heilman, Alex Kyllo, Emerson Murphy-Hill

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez de déterminer si une nouvelle paire de chaussures de course haute technologie permet réellement aux gens de courir plus vite.

La méthode évidente pour tester cela est de comparer deux groupes : des personnes portant les chaussures et des personnes portant des baskets classiques. Mais voici le problème : peut-être que les personnes qui choisissent de porter les chaussures haute technologie sont déjà des athlètes professionnels, tandis que les porteurs de baskets sont des joggeurs occasionnels. Si les porteurs de chaussures courent plus vite, est-ce dû aux chaussures, ou simplement au fait qu'ils sont de meilleurs coureurs dès le départ ?

C'est exactement le casse-tête auquel les chercheurs de Microsoft ont été confrontés avec GitHub Copilot, un outil d'IA qui aide les ingénieurs logiciels à écrire du code. Ils voulaient savoir : L'utilisation de l'IA rend-elle réellement les ingénieurs plus productifs, ou les ingénieurs qui l'utilisent le plus sont-ils simplement des personnes naturellement plus productives ?

Plus grave encore, il y a un second niveau de confusion. Peut-être qu'un ingénieur utilise l'IA intensément pendant une semaine spécifique non pas parce que l'IA est magique, mais parce que cette semaine était une période de "rush" où il travaillait 80 heures par jour sur un projet énorme. Dans ce cas, il terminerait plus de travail (Pull Requests) simplement parce qu'il a travaillé plus longtemps, et non parce que l'IA l'a aidé à travailler plus vite.

La Solution : L'Expérience de "Comparaison de Soi-même"

Puisque les chercheurs ne pouvaient pas forcer aléatoirement certains ingénieurs à arrêter d'utiliser l'outil (cela serait contraire à l'éthique et perturberait leur travail), ils ont utilisé une astuce ingénieuse appelée analyse "intra-ingénieur" (Within-Engineer).

Voyez cela comme ceci : au lieu de comparer l'Ingénieur A (qui utilise l'IA) à l'Ingénieur B (qui ne l'utilise pas), ils ont comparé l'Ingénieur A à lui-même.

Ils ont observé le même ingénieur sur 43 semaines.

Semaine 1 : l'ingénieur utilisait à peine l'IA.
Semaine 2 : l'ingénieur utilisait l'IA intensivement.

En comparant l'ingénieur à lui-même, ils ont automatiquement annulé tout ce qui rend l'Ingénieur A différent de l'Ingénieur B (comme le talent naturel, le rôle de poste ou la culture d'équipe). Ils se demandaient : "Lorsque cette personne spécifique utilise l'IA davantage, accomplit-elle plus de travail par rapport aux moments où elle l'utilise moins ?"

Le Test d' "Efficacité" : Ont-ils travaillé plus dur ou plus intelligemment ?

Il restait encore une variable délicate : l'Effort.
Si un ingénieur utilise beaucoup l'IA, il se peut qu'il passe aussi simplement plus de temps devant son ordinateur à coder, par exemple 10 heures au lieu de 5. S'il termine plus de travail, c'est peut-être simplement parce qu'il a passé plus de temps à son bureau.

Pour corriger cela, les chercheurs ont utilisé un "filtre" statistique (un modèle appelé PPML) qui maintenait constant le temps passé à coder.

La Question : "Si l'Ingénieur A passe exactement 8 heures à coder, termine-t-il plus de code lorsqu'il utilise l'IA intensément par rapport aux semaines où il ne l'utilise pas du tout ?"

Le Résultat : Oui. Même lorsque le temps passé à coder était exactement le même, les ingénieurs qui utilisaient intensément l'IA complétaient environ 40 % de projets de code (Pull Requests) en plus que lors des semaines où ils ne l'utilisaient pas du tout.

La Batterie de "Falsification" : Écarter les excuses

Les chercheurs savaient que les sceptiques trouveraient d'autres raisons pour expliquer ce résultat. Ils ont donc mené sept tests différents de "détecteur de mensonges" pour voir si les résultats n'étaient pas un coup de chance.

Le Test de l' "IA Générique" : Peut-être que les ingénieurs qui utilisent beaucoup l'IA sont simplement très "doués en technologie" et utilisent d'autres outils d'IA (comme dans Word ou Excel) ce qui leur donne l'impression d'être productifs ?
- Test : Ils ont vérifié si l'utilisation de l'IA dans des applications non liées au code (comme PowerPoint) prédisait une production de code plus élevée.
- Résultat : Non. Utiliser l'IA dans Word n'a pas aidé à écrire du code. C'était spécifiquement l'IA de codage qui comptait.
Le Test de la "Hype d'Équipe" : Peut-être que toute l'équipe était dans une semaine de "hype", de sorte que tout le monde utilisait l'IA et que tout le monde écrivait plus de code ?
- Test : Ils ont vérifié si l'utilisation de l'IA par un ingénieur prédisait la production de code de ses coéquipiers.
- Résultat : Non. Si c'était juste de la hype d'équipe, votre utilisation de l'IA devrait prédire la production de votre voisin. Ce n'était pas le cas.
Le Test du "Changement de Tâche" : Peut-être que lors des semaines à forte utilisation d'IA, les ingénieurs ont simplement arrêté de réviser le code des autres pour se concentrer entièrement sur l'écriture de leur propre code ?
- Test : Ils ont vérifié si écrire plus de code signifiait réviser moins de code.
- Résultat : Non. Les ingénieurs écrivaient plus de code ET révisaient plus de code lorsqu'ils utilisaient l'IA. Ils n'ont pas simplement échangé une tâche contre une autre ; ils faisaient plus de tout.
Le Test du "Découpage" : Peut-être que les ingénieurs découpaient simplement de gros projets en petites pièces faciles pour faire paraître les chiffres plus élevés ?
- Test : Ils ont examiné la taille des projets de code.
- Résultat : Non. Le plus grand gain se trouvait en réalité dans les projets les plus grands et les plus complexes (7 fichiers ou plus), et non dans les plus petits.
Le Test du "Travail Facile" : Peut-être faisaient-ils simplement de la paperasse facile (comme mettre à jour des fichiers texte) au lieu de codage difficile ?
- Test : Ils ont séparé les fichiers de configuration "faciles" des fichiers de code "difficiles".
- Résultat : Non. Le gain de productivité était en fait plus fort pour les fichiers de code difficiles.
Le Test de la "Temporalité" : Peut-être que l'utilisation de l'IA en Semaine 1 était simplement le signe que l'ingénieur était dans une "humeur productive" qui durait jusqu'en Semaine 2 ?
- Test : Ils ont vérifié si l'utilisation de l'IA la semaine précédente prédisait la production de la semaine actuelle.
- Résultat : Non. Le gain ne se produisait que dans la même semaine exacte où l'IA était utilisée.

La Conclusion

L'étude conclut que GitHub Copilot rend réellement les ingénieurs plus efficaces.

Lorsqu'un ingénieur utilise l'outil de manière plus intensive, il accomplit environ 40 % de travail en plus dans le même laps de temps. Il ne s'agit pas seulement du fait que les personnes productives utilisent l'outil ; l'outil lui-même semble agir comme un multiplicateur de force, aidant les ingénieurs à accomplir plus de choses sans avoir besoin de travailler plus d'heures.

Cependant, les chercheurs précisent avec prudence : cette étude mesure l'efficacité (faire plus en une heure). Elle ne mesure pas le temps total économisé. Si l'IA vous aide à terminer une tâche en 30 minutes au lieu d'une heure, votre "efficacité" augmente, mais vous pourriez aussi simplement décider de finir votre journée plus tôt. L'étude prouve que la vitesse augmente, mais elle ne nous dit pas exactement comment les ingénieurs passent ce temps supplémentaire.

Résumé technique : GitHub Copilot et la productivité des développeurs

Énoncé du problème
L'article traite de la difficulté de mesurer l'impact causal des assistants de codage basés sur des modèles de langage étendu (LLM), spécifiquement GitHub Copilot (GHCP), sur la productivité des développeurs. Bien que la littérature existante comprenne des expériences contrôlées et des quasi-expérimentations, il est difficile d'étendre ces conclusions à la productivité en « régime permanent » d'un outil omniprésent. Les auteurs identifient deux couches principales de facteurs de confusion qui obscurcissent l'inférence causale dans les données observationnelles :

Sélection entre ingénieurs : Les ingénieurs qui utilisent GHCP plus fréquemment peuvent différer systématiquement de ceux qui l'utilisent moins (par exemple, en termes de compétences, de rôle, d'équipe ou de réceptivité aux nouveaux outils).
Confusion intra-ingénieur, variable dans le temps : Même pour un seul ingénieur, les semaines de forte utilisation de GHCP peuvent coïncider avec des semaines « chargées » (par exemple, des périodes de rush, des lancements de fonctionnalités majeures) où la production élevée est dictée par l'effort plutôt que par la contribution marginale de l'outil.

Les comparaisons transversales standard confondent ces différences avec l'effet de l'outil, tandis que les tests A/B randomisés sont jugés irréalisables en raison des implications éthiques et pratiques liées au retrait d'un outil établi pour un sous-ensemble d'ingénieurs.

Méthodologie
L'étude utilise 43 semaines de données observationnelles provenant de 16 223 ingénieurs logiciels au sein de l'organisation Cloud+AI de Microsoft. Les auteurs emploient une analyse dose-réponse intra-ingénieur utilisant un modèle de Pseudo-Maximum de Vraisemblance de Poisson (PPML) avec des effets fixes à deux voies.

Stratégie d'identification :
- Effets fixes par ingénieur ( $\alpha_i$ ) : Ceux-ci absorbent toutes les différences invariantes dans le temps entre les ingénieurs (compétences, rôle, équipe, style de codage), comparant ainsi chaque ingénieur à lui-même plutôt qu'à ses pairs.
- Effets fixes par semaine ( $\delta_t$ ) : Ceux-ci absorbent les chocs à l'échelle de la population (échéances, vacances, réorganisations).
- Contrôles d'effort : Le modèle inclut le temps de codage actif et le temps de navigation comme covariables. Cela définit l'estimand non pas comme un « effet total » (qui inclurait les gains de temps), mais comme un effet d'efficacité : le changement de production de PR par unité d'effort de développement mesuré. Cette approche est conservatrice ; si GHCP fait gagner du temps, ce canal est absorbé par les contrôles, ce qui signifie que le coefficient estimé représente une limite inférieure de l'impact total sur la productivité.
Opérationnalisation du traitement : L'utilisation de GHCP est mesurée par la « profondeur d'interaction » (total des suggestions, des invites et des acceptations par semaine), classée en quatre niveaux : Zéro, Faible, Modérée et Élevée.
Variable de résultat : Le nombre de Pull Requests (PR) terminées attribuées à la semaine de création, avec une fenêtre de complétion de 28 jours.

Résultats clés
L'analyse révèle une relation monotone et positive entre l'intensité de l'utilisation de GHCP et la production de PR, en maintenant constants le temps de codage et le temps de navigation :

Magnitude : Les ingénieurs terminent 40,5 % de PR en plus lors de leurs semaines de forte utilisation de GHCP par rapport à leurs semaines d'utilisation nulle.
Gradient : L'effet est monotone mais présente des rendements décroissants à haute intensité :
- Usage faible : +21,0 %
- Usage modéré : +39,4 %
- Usage élevé : +40,5 %
Contrôles : Le temps de codage et le temps de navigation sont positivement associés à la production de PR, confirmant la capacité du modèle à capturer la productivité basée sur l'effort.

Robustesse et falsification
Pour répondre à l'hypothèse non testable d'indépendance conditionnelle (selon laquelle des facteurs non observés ne pilotent pas simultanément l'usage de GHCP et la production de PR), les auteurs mènent une batterie de sept tests de falsification :

Traitement placebo (IA non-codage) : L'utilisation de l'usage de M365 Copilot (non lié au codage) comme traitement produit un gradient plat, excluant l'idée que des « semaines d'engagement avec l'IA » génériques seraient le moteur du résultat.
Résultat placebo (PR des coéquipiers) : L'usage de GHCP par un ingénieur ne prédit pas la production de PR de ses coéquipiers, excluant les chocs au niveau de l'équipe.
Changement de mix de tâches (Rédaction vs Revue) : Les PR rédigées ainsi que les revues de PR augmentent avec l'usage de GHCP, contredisant l'hypothèse selon laquelle les ingénieurs se contenteraient de déplacer le temps de la revue vers la rédaction.
Tests de temporalité : Les variables d'usage de GHCP décalées (lagged) ou en avance (leading) ne montrent aucun pouvoir prédictif, indiquant que l'association est contemporaine et n'est pas pilotée par des états non observés persistants.
Décomposition de la taille des PR : La dose-réponse est la plus forte pour les grandes PR (7+ fichiers), contredisant l'hypothèse du « découpage » (selon laquelle les ingénieurs décomposeraient le travail en petites PR triviales).
Décomposition par type de PR : Le gradient est plus marqué pour les « autres » PR (excluant les fichiers de configuration/documentation) que pour les PR de type config/doc uniquement, excluant un glissement vers des types de tâches plus faciles.
Opérationnalisation alternative : L'utilisation de la « largeur » (jours par semaine avec usage) au lieu de la « profondeur » (depth) produit un gradient monotone similaire (+54 % pour la largeur élevée), confirmant que le résultat n'est pas un artefact du partitionnement en catégories.

Signification et affirmations
L'article affirme fournir une estimation observationnelle rigoureuse de l'effet d'efficacité de GitHub Copilot. En s'appuyant sur la variation intra-ingénieur et une batterie de tests de falsification robuste, les auteurs réduisent l'espace des explications alternatives plausibles. Ils concluent que l'augmentation de 40,5 % du débit de PR observée est cohérente avec un véritable effet de productivité plutôt qu'avec un biais de confusion mécanique ou une réallocation des tâches.

Les auteurs présentent explicitement leurs conclusions comme un effet d'efficacité (plus de production par heure) plutôt qu'un effet total, reconnaissant que si GHCP réduit le temps nécessaire pour accomplir les tâches, le gain de productivité total serait encore plus élevé. Ils maintiennent une position modeste, notant que bien que leur conception réduise considérablement l'ensemble des facteurs de confusion plausibles, une affirmation causale définitive nécessiterait une expérience randomisée, qu'ils considèrent comme irréalisable pour cette question de recherche spécifique. L'étude démontre que les données de panel intra-ingénieur avec effets fixes et tests de falsification peuvent fournir des preuves crédibles de l'impact de la productivité des outils d'IA omniprésents dans des contextes réels.

La Solution : L'Expérience de "Comparaison de Soi-même"

Le Test d' "Efficacité" : Ont-ils travaillé plus dur ou plus intelligemment ?

La Batterie de "Falsification" : Écarter les excuses

La Conclusion

Résumé technique : GitHub Copilot et la productivité des développeurs

Articles similaires