Rapport GitHub Octoverse 2026 : les agents IA lancent plus de 40 % des pull requests
Le rapport GitHub Octoverse 2026, présenté le 28 octobre 2026 lors de GitHub Universe, indique que les agents IA ont lancé plus de 40 % des pull requests de la plateforme en septembre 2026, contre 17 % en mars. Les pull requests fusionnées ont triplé en moins d'un an, à 220 millions par mois. Pour les éditeurs de logiciels, ces chiffres montrent où se déplace le travail : les agents rédigent une plus grande part du code, et la relecture, les contrôles de sécurité et les règles de fusion portent désormais une plus grande part de la charge.
Ce que GitHub a mesuré cette année
Le rapport mesure combien de travail supplémentaire passe désormais par GitHub. Jay Parikh, vice-président exécutif de GitHub, a présenté le rapport lors de GitHub Universe, et ses chiffres phares montrent la vitesse de la croissance. Les pull requests fusionnées ont triplé en moins d'un an, à 220 millions par mois. Les commits ont plus que triplé, à 7,38 milliards par mois, l'essentiel de la hausse intervenant au second semestre. Le rythme de création de dépôts a doublé, à 30,3 millions par mois.
La période étudiée va du 1er octobre 2025 au 30 septembre 2026. Les chiffres sur les agents reposent sur la détection par GitHub de l'activité des agents sur la plateforme. Pour certaines ventilations, GitHub a lui-même utilisé l'IA : un LLM a classé les profils d'utilisateurs par pays, et un modèle d'embeddings multilingue affiné a réparti les dépôts publics par secteur d'activité.
Quelle part du travail les agents IA lancent désormais
Plus de 40 % des pull requests sur GitHub ont commencé par un brouillon généré par un agent IA en septembre 2026, contre 17 % en mars. Les agents ont lancé 110 millions de pull requests rien qu'en septembre, soit environ six fois le volume de mars.
Le travail des agents est aussi plus étendu. GitHub constate que 87 % des pull requests lancées par un agent modifiaient plusieurs fichiers, contre 79 % des pull requests sans intervention détectée d'un agent. La part des pull requests impliquant un agent fusionnées en moins de deux semaines est passée de 83 % en février à 90 % en septembre, tandis que celle des autres restait autour de 86 %. GitHub précise que ces chiffres décrivent le délai de fusion, pas la qualité du code.
Comment les développeurs utilisent les fonctions d'agent de Copilot
Parmi les utilisateurs actifs mensuels de GitHub Copilot, 55 % utilisaient des fonctions agentiques, contre 35 % un an plus tôt. L'usage de l'agent cloud de Copilot, qui permet de confier une tâche à un agent qui la termine seul, a progressé de 230 % sur un an, et celui du chat d'agent de 85 %.
GitHub a aussi lancé Copilot Projects en préversion publique. L'outil permet de coordonner des agents sur plusieurs dépôts, de leur fournir du contexte issu de fichiers de conception, de conversations Slack et de comptes rendus de réunion, puis de relire leur production.
Comment GitHub gère la relecture du code écrit par les agents
Plus de code signifie plus de relecture, et les chiffres de GitHub montrent une croissance rapide des outils de relecture et de sécurité. L'usage de la revue de code assistée par IA et celui de GitHub Advanced Security ont chacun progressé de plus de 90 % sur un an. Les développeurs ont fusionné plus de 30 millions de pull requests Dependabot, environ le double du volume de 2025.
Plus de 264 000 développeurs avaient utilisé les pull requests empilées en septembre. La fonction découpe une modification importante en plusieurs pull requests plus petites, relues une à une, et elle est devenue disponible pour tous le 6 octobre. GitHub indique que les dépôts qui l'utilisaient ont vu le code fusionné augmenter de 9 % pendant la préversion, sans affirmer que la fonction en soit la seule cause.
« Pour une équipe dont les membres relisent le travail les uns des autres, c'est une vraie amélioration de notre façon de collaborer. » David Mostoller, ingénieur logiciel chez Comcast, à propos des pull requests empilées
Le 28 octobre, GitHub a ajouté Copilot code review Max en préversion publique : cette option exécute des agents de relecture indépendants sur des modèles de différents fournisseurs et combine leurs constats. La correction automatique agentique est devenue disponible pour tous le 15 octobre : Copilot propose des correctifs pour jusqu'à 25 alertes d'analyse de code dans une seule pull request et relance CodeQL pour les vérifier.
Ce que ce basculement signifie pour les responsables techniques
Pour une entreprise qui livre du logiciel, le goulot d'étranglement passe de l'écriture du code à sa vérification. Quand les agents lancent plus de 40 % des pull requests, la limite de la production devient le nombre de modifications que des personnes peuvent relire en toute confiance.
Les propres garde-fous de GitHub montrent comment il s'attend à ce que les entreprises gèrent cela. Les approbations de Copilot, désormais disponibles pour tous, peuvent compter parmi les approbations requises, mais elles sont désactivées par défaut, les administrateurs peuvent restreindre les chemins de fichiers que Copilot peut approuver, et une approbation est annulée si de nouveaux commits arrivent ensuite. Les équipes qui adoptent des agents auraient besoin de règles de relecture du même type avant que le volume n'arrive.
Questions et réponses
Quelle part des pull requests GitHub les agents IA lancent-ils ?
Plus de 40 % en septembre 2026, contre 17 % en mars, selon le rapport GitHub Octoverse 2026. Les agents ont lancé 110 millions de pull requests en septembre.
Combien de pull requests sont fusionnées sur GitHub chaque mois ?
Environ 220 millions par mois en 2026, le triple du niveau d'il y a moins d'un an, selon GitHub.
Qu'est-ce que Copilot code review Max ?
Une option de relecture en préversion publique depuis le 28 octobre, qui exécute des agents de relecture indépendants sur des modèles de différents fournisseurs et fusionne leurs constats en une seule relecture. Selon GitHub, elle prend plus de temps et consomme plus de crédits d'IA que les options Lite et Balanced.
Le regard de MOZGII
Comment nous le construirions
Quand les agents lancent une grande part des modifications, la ressource rare d'une équipe logicielle n'est plus la frappe. C'est la lecture attentive. Si nous organisions une équipe pour cela, nous commencerions par le circuit de relecture, pas par l'agent. Chaque pull request lancée par un agent porterait une courte note sur ce qu'elle a modifié et pourquoi, les tests exécutés et les fichiers touchés, pour qu'un relecteur parte d'un contexte plutôt que d'un diff brut.
Nous garderions des modifications petites, car une petite modification est plus facile à vérifier qu'une grosse, et nous enverrions par règle tout ce qui touche à la logique de connexion ou aux bibliothèques partagées à un relecteur senior. Les approbations par l'IA resteraient désactivées pour ces chemins. Un second modèle qui relit le premier peut repérer des erreurs, mais la décision de fusionner resterait à une personne.
Le système flancherait là où le volume dépasse l'attention. Si les relecteurs font face à beaucoup plus de pull requests chaque jour, ils se mettent à approuver par habitude, et les chiffres de vitesse paraissent bons pendant que la qualité baisse. C'est pourquoi nous ne suivrions pas le délai de fusion. L'indicateur que nous suivrions est la part des modifications d'agents fusionnées qui sont annulées ou corrigées dans les semaines suivantes. Ensuite, nous construirions un rapport hebdomadaire montrant aux relecteurs quels types de modifications d'agents ont demandé le plus de reprises, pour que l'équipe sache où regarder de plus près.
Sources
D’où viennent les faits de cet article.