Ce sont les agents qui ouvrent les pull requests

Le 28 octobre, GitHub a publié Octoverse, son rapport annuel sur l’activité de la plateforme, et une ligne se détache : en septembre 2026, plus de 40 pour cent des pull requests sur GitHub sont parties d’un premier jet rédigé par un agent, contre 17 pour cent en mars. Cela représentait 110 millions de pull requests pour le seul mois de septembre. Le même jour, lors de sa conférence Universe, GitHub a lancé Copilot Projects en préversion publique et mis Agentic Workflows en disponibilité générale.

Une semaine plus tard, Meta a racheté Conductor, une start-up conçue pour faire travailler plusieurs agents de code à la fois. Ensemble, ces nouvelles vont dans le même sens : écrire du code n’est plus la partie rare de la fabrication d’un logiciel. Le spécifier, le relire, le tester et en répondre, si.

Ce que GitHub a compté

Ce sont les propres chiffres de GitHub, mesurés sur sa propre plateforme, et il faut les lire comme tels. Octoverse considère qu’une pull request a été lancée par un agent lorsque son premier jet provient d’un agent de code que GitHub peut détecter, et le rapport qualifie ce signal de « plancher, puisque toute utilisation d’agents n’est peut-être pas détectée ». Il couvre les dépôts publics et privés, et les chiffres des années précédentes ont été recalculés sur la même base.

Le rapport indique aussi que les pull requests d’agents sont désormais fusionnées au moins aussi souvent que les autres. En février, 83 pour cent des pull requests impliquant un agent ont été fusionnées en deux semaines, contre environ 86 pour cent de celles sans agent détecté ; en septembre, la part des agents avait atteint 90 pour cent. Elles sont aussi plus larges : environ 87 pour cent modifient plus d’un fichier, contre 79 pour cent des autres. Selon notre lecture, une fusion montre qu’un relecteur a accepté une modification, pas que la modification était juste.

Plus d’agents par personne

Les produits lancés par GitHub le même jour partent du principe que cette part va continuer de croître. Copilot Projects donne au travail qui s’étend sur plusieurs dépôts un seul endroit pour son contexte, ses agents et ses résultats. Vous décrivez un objectif, Copilot fait tourner des agents en parallèle, « fait le point avec vous quand il a besoin de vous » et rapporte des résultats, comme des pull requests à relire. Agentic Workflows permet à une équipe de décrire en Markdown des tâches comme le tri des tickets ou l’analyse d’un build échoué, et de les faire exécuter par un agent de code dans GitHub Actions, avec des autorisations en lecture seule par défaut et une tâche distincte qui analyse les modifications proposées avant leur application.

Le billet de GitHub sur Universe décrit la répartition du travail en une phrase : « Les développeurs fixent la direction, prennent les décisions et restent responsables de ce qui est livré. » Un analyste cité par InfoWorld a précisé ce que cela signifie en pratique. « Dix sessions d’agents en parallèle, par exemple, pourraient générer dix pull requests à relire », a déclaré Amit Kumar Jena, qui dirige le développement IA du cabinet de conseil Kanerika.

Soixante-dix pour cent, ce n’est pas fini

Un nouveau test, mené hors de GitHub, montre pourquoi cette relecture ne peut pas être sautée. Le 26 octobre, des chercheurs d’Alibaba et de plusieurs universités ont publié Co-Design Bench : 273 tâches tirées de 26'314 sessions de code réelles d’utilisateurs, chacune vérifiée par rapport à des critères d’acceptation cachés rédigés par des experts, 2'331 au total. Le meilleur des dix modèles, testés dans la même configuration d’agent, a rempli en moyenne 69,9 pour cent des critères par tâche, mais n’a entièrement satisfait que 26,4 pour cent des tâches. The Decoder, qui a rendu compte de l’étude le 8 novembre, a écrit que les agents de code « ont encore besoin d’un nettoyage humain sur près de trois tâches sur quatre ».

L’étude a ses limites. Chaque tâche est une demande unique et figée, si bien que les agents ne pouvaient ni poser de questions ni être corrigés en cours de route, la notation est faite par des juges IA qui peuvent se tromper, et plusieurs auteurs viennent d’Alibaba, dont le modèle Qwen figurait parmi ceux testés. Reste que l’écart qu’elle mesure, entre la plupart des exigences et toutes les exigences, est exactement celui qu’un relecteur est là pour combler.

Ce que font aujourd’hui les bonnes équipes

Rien de tout cela ne demande tant de nouveaux outils qu’une vieille discipline, appliquée plus strictement. Commencez par la spécification : quand un agent rédige la modification, la tâche écrite est la véritable source, et Jena a averti que « des tâches mal définies pourraient entraîner des exécutions répétées, des reprises et une consommation accrue de crédits d’IA ». Écrivez ce que signifie « terminé » avant que l’agent ne commence, comme Co-Design Bench fixe d’abord ses critères d’acceptation.

Gardez des modifications assez petites pour être lues. GitHub indique que les pull requests empilées, qui découpent un travail lié en modifications plus petites relues l’une après l’autre, avaient été utilisées par plus de 264'000 développeurs en septembre, deux mois après le lancement de leur préversion. Faites des tests le point de passage obligé : une modification ne devrait pas arriver jusqu’à une personne avant de les avoir passés, et les tests eux-mêmes méritent la relecture la plus attentive, car un agent qui peut modifier ses propres tests peut faire passer n’importe quoi.

Enfin, nommez la personne. Chaque modification livrée a besoin de quelqu’un qui l’a approuvée et peut l’expliquer, et ce quelqu’un ne peut pas être l’agent. Le conseil de Jena aux DSI va dans le même sens : « exiger une approbation humaine avant que les pull requests générées par des agents ne soient fusionnées ».

Les outils peuvent s’éteindre

L’opération Conductor ajoute une leçon plus discrète. TechCrunch a rapporté le 4 novembre que Meta avait racheté la start-up, fondée en 2024, dont les équipes d’agents sont « conçues pour aider les ingénieurs logiciels à travailler de concert sur des parties distinctes et cloisonnées d’un projet », avec des agents de laboratoires comme Anthropic et OpenAI. Meta a confirmé le rachat, sans en donner les conditions.

L’avis de Conductor fixe lui-même le calendrier. Les nouvelles inscriptions ont cessé le 4 novembre, ses espaces de travail cloud passent en lecture seule le 13 novembre, et le 20 novembre l’entreprise commence à supprimer les données des utilisateurs dans le cloud : les clients ont donc seize jours pour exporter ce qu’ils y conservent. L’application de bureau continue de fonctionner pour l’instant et commencera à être progressivement arrêtée début 2027. Conductor affirme n’avoir jamais vendu les données des utilisateurs ni entraîné de modèles avec elles, et propose un export ainsi qu’un transfert vers l’application locale.

Rien ici ne suggère une mauvaise foi. Cela montre à quel point la couche qui fait tourner les agents est encore récente et instable : un service qui détient les espaces de travail et les conversations de vos agents peut être racheté et fermé en quelques semaines. Gardez ce qui compte dans des endroits que vous contrôlez : le code et son historique dans votre propre dépôt, les spécifications et les décisions consignées à côté, et des tests que tout agent doit passer, quel que soit le fournisseur.

Où nous en sommes

Werk, notre plateforme d’applications, est disponible et repose sur cette répartition du travail. L’IA écrit l’essentiel du code sur un framework que nous avons construit et auquel nous faisons confiance, des personnes décident de ce qu’il faut construire, conçoivent ce que l’on ressent à l’usage et relisent chaque version, et chaque version est testée. Le code vous appartient, et la plateforme continue de grandir en dessous. La prochaine étape vers laquelle nous travaillons, ce sont des agents qui livrent seuls des modifications et des correctifs de routine, testés et relus avant leur mise en production, ce qui ne fonctionne que si la spécification, les tests et la relecture sont déjà en place.