Agents CLI : Microsoft mesure +24 % de PR, mais sous conditions

Pendant longtemps, le débat sur les agents de code s'est nourri de sondages déclaratifs et de démonstrations soignées. Une étude publiée le 1er juillet 2026 relève le niveau de preuve. Trois chercheurs de Microsoft, Emerson Murphy-Hill, Jenna Butler et Alexandra Savelieva, ont suivi le déploiement de Claude Code et de GitHub Copilot CLI auprès de dizaines de milliers d'ingénieurs de l'entreprise, entre le 5 janvier et le 29 avril 2026. Ils s'appuient sur la télémétrie réelle des développeurs, et non sur leurs impressions. ¹

Le résultat principal tient dans un chiffre. Les ingénieurs qui adoptent un agent CLI fusionnent environ 24 % de pull requests² de plus par jour qu'ils ne l'auraient fait sans l'outil. L'intervalle de confiance donné par les auteurs va de +14,5 % à +33,7 %, et le gain ne s'est pas dissipé sur les quatre mois observés. Pour une activité où les études rigoureuses concluent souvent à des effets modestes, ce signal mérite l'attention.

Le gain existe, mais il n'est pas automatique

L'étude est plus intéressante par ses conditions que par son chiffre d'affiche. Trois observations ressortent.

La diffusion passe par le collectif. Selon les auteurs, la première utilisation d'un agent se propage d'abord par les réseaux sociaux internes, quand un collègue montre l'outil à un autre. L'adoption ne se décrète donc pas uniquement par une note de direction.

La rétention suit l'activité de code, pas le profil. Un ingénieur est considéré comme retenu s'il enregistre de l'activité sur au moins 5 des 14 jours qui suivent sa première utilisation. Or cette rétention est fortement associée à la quantité de code que la personne produisait déjà avant d'adopter l'outil. Les développeurs qui codaient beaucoup adoptent et gardent l'outil à un taux plus élevé.

L'usage régulier compte davantage que l'usage occasionnel. D'après la synthèse de TechRepublic³, les ingénieurs qui se servaient de l'agent cinq jours par semaine ou plus voyaient un gain supérieur à 50 %, contre environ 15 % pour un usage de trois jours par semaine. Le bénéfice se construit dans la répétition, pas dans l'essai ponctuel.

Il faut ajouter un biais que les auteurs assument. Les personnes étudiées ont choisi d'utiliser l'outil. Cette sélection volontaire⁴ gonfle probablement l'effet mesuré par rapport à un déploiement imposé à toute une population.

Ce que la mesure ne dit pas

Les chercheurs sont explicites sur leur indicateur. Ils mesurent des pull requests fusionnées, c'est-à-dire un volume de production. Ils ne mesurent ni la qualité du code, ni sa sécurité, ni sa maintenabilité, ni l'impact client. Une équipe peut donc livrer davantage sans que la valeur livrée augmente d'autant.

Ce point relie l'étude Microsoft à un autre travail que nous avons déjà commenté. La plateforme DX, en suivant un échantillon d'entreprises sur plus d'un an, a trouvé un gain de débit de pull requests d'environ 10 % seulement, malgré une hausse d'usage de l'ordre de 65 %. Son explication tient au fait que le codage n'est pas le goulot d'étranglement : la planification, l'alignement et la revue restent des activités humaines peu touchées. Nous avions détaillé ce paradoxe dans notre article sur la livraison qui n'a pas bougé.

Comment concilier +24 % chez Microsoft et +10 % chez DX ? Les périmètres diffèrent, les populations aussi. Le tableau ci-dessous résume les deux lectures.

La différence n'a rien de contradictoire. La première regarde les personnes qui adoptent vraiment l'outil, la seconde regarde des organisations entières. Un dirigeant qui achète des licences se situe plus près du second cas que du premier.

Un poste de coût qui se pilote

L'étude rappelle enfin une réalité budgétaire. À l'échelle d'une grande organisation, la dépense en tokens peut atteindre plusieurs millions de dollars par an. Une PME reste loin de ces montants, mais le principe vaut à toute taille. Mal évaluer qui utilise l'outil, combien de temps et pour quel effet transforme une dépense récurrente en ligne comptable sans contrepartie claire.

Notre lecture

Pour une PME ou une ETI, cette étude déplace la bonne question. Le sujet n'est plus de savoir si un agent de code aide, car la mesure penche clairement vers l'affirmative chez ceux qui s'en servent. Le sujet devient de savoir comment obtenir cet effet chez soi.

Trois pistes concrètes en découlent. Ciblez d'abord les développeurs qui codent déjà beaucoup, car ce sont eux qui retiennent l'outil et en tirent le gain le plus fort. Appuyez-vous sur la démonstration entre pairs plutôt que sur une consigne descendante, puisque la diffusion sociale fait le travail. Fixez enfin un indicateur de valeur qui aille au-delà du volume de PR, sous peine de célébrer une production qu'aucune revue de qualité n'a validée.

Un agent CLI n'est pas un abonnement qui produit des résultats en restant sur l'étagère. Il rend ce que l'usage régulier lui donne. La vraie décision d'un dirigeant porte moins sur l'achat que sur l'accompagnement des équipes qui vont s'en servir chaque jour.

Sources

• Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI (Murphy-Hill, Butler, Savelieva, Microsoft, arXiv 2607.01418) : https://arxiv.org/abs/2607.01418
• Microsoft Study Finds AI Coding Agents Lift Pull Requests by 24 % (TechRepublic) : https://www.techrepublic.com/article/news-ai-coding-agents-microsoft-pull-requests/
• The AI efficiency plateau (DX, Engineering Enablement) : https://getdx.com/blog/the-ai-efficiency-plateau/