GitHub Octoverse 2026 : les agents lancent plus de 40 % des pull requests alors que l’activité s’envole

GitHub a publié son rapport Octoverse 2026 le 28 octobre, indiquant que les agents ont fourni la première ébauche de plus de 40 % des pull requests de septembre. Une pull request propose des modifications de code à examiner avant leur intégration dans un projet. Cette conclusion place la rédaction automatisée au cœur d’un flux de travail logiciel central, tout en laissant ouvertes les questions distinctes de productivité et de qualité.

GitHub Octoverse 2026 fait également état d’une activité record sur sa plateforme. Cela rend la distinction entre la production de modifications et la livraison de logiciels utiles plus déterminante. Un agent de codage IA, c’est-à-dire un logiciel qui exécute des tâches de développement à l’aide d’un modèle d’IA, peut générer un travail qui exige encore un jugement humain substantiel.

Pour les responsables de l’ingénierie, la tension centrale oppose l’augmentation de la production de code à la capacité de l’évaluer. Des recherches antérieures de METR ont montré pourquoi ces mesures méritent d’être traitées séparément. Parallèlement, la prise en charge par GitHub des agents d’Anthropic et d’OpenAI place des fournisseurs concurrents dans le même environnement de revue. La question pratique est de savoir quelle part du travail utile survit à l’ensemble du processus.

GitHub Octoverse 2026 constate une évolution dans la manière dont les changements commencent

Selon les conclusions d’Octoverse de GitHub, les développeurs ont effectué 17,9 milliards de pushes et fusionné 1,3 milliard de pull requests au cours de l’année couverte par le rapport. Un push envoie des modifications de code enregistrées vers GitHub. Le total de pushes a dépassé celui des deux années précédentes réunies.

La période couverte s’étend du 1er octobre 2025 au 30 septembre 2026. La plupart des chiffres incluent des projets publics et privés. GitHub a recalculé les années antérieures à l’aide de définitions comparables, une précision importante lorsqu’on compare ces chiffres à des rapports publiés précédemment.

La part lancée par des agents est passée de 17 % en mars à plus de 40 % en septembre. GitHub définit ces demandes par une première ébauche générée par un agent détectable.

Le chiffre d’adoption mesure la manière dont les modifications proposées commencent, plutôt que la quantité de logiciels finalisés qu’un agent crée de manière indépendante.

Cette distinction modifie le sens du titre. Un développeur peut définir la tâche, rejeter une approche initiale, réécrire des parties du résultat et prendre la décision finale d’approbation. Qualifier le travail qui en résulte d’entièrement autonome effacerait ces contributions.

Le dénominateur compte tout autant. Une part de pull requests ne peut pas être directement traduite en part de code, d’heures de travail ou de fonctionnalités produit. Les modifications proposées varient en taille, en difficulté et en importance.

Prenons une correction de documentation à côté d’une modification de l’autorisation de paiement. Les deux peuvent donner lieu à une pull request. Leurs exigences de revue et leurs conséquences diffèrent considérablement, même lorsque la plateforme enregistre chacune comme une seule proposition.

De même, un nombre croissant de modifications proposées peut refléter plusieurs évolutions. Les équipes peuvent tenter davantage de projets, diviser le travail en éléments plus petits ou générer des révisions supplémentaires. Ces possibilités exigent des interprétations différentes.

C’est pourquoi le rapport mérite l’attention sans pour autant porter toutes les conclusions associées au débat sur le codage par IA. Il documente une évolution substantielle du comportement de développement observable. Établir la valeur économique de ce comportement exige des éléments supplémentaires.

Pour les lecteurs qui suivent l’adoption des agents GitHub, le point de départ utile est donc une attribution précise. Il s’agit de mesures de la plateforme GitHub, avec les définitions et les limites de détection de l’entreprise. Elles ne constituent pas une estimation auditée de manière indépendante de la contribution de l’IA à l’ensemble du développement logiciel.

L’actualité reste importante dans ces termes. La rédaction est un point d’entrée significatif dans le travail d’ingénierie. Lorsque des agents y participent, les systèmes de revue deviennent le lieu où leurs propositions rencontrent les exigences des projets et la responsabilité humaine.

Cela place directement les mainteneurs, les responsables de l’ingénierie et les réviseurs de sécurité au cœur du sujet. Leurs décisions déterminent si l’activité supplémentaire devient un logiciel utile ou une collection plus vaste de propositions inachevées.

Davantage d’ébauches mettent la capacité de revue sous pression

Les équipes d’ingénierie tirent profit d’une rédaction plus rapide lorsqu’elles peuvent évaluer les modifications qui en résultent sans perdre le contrôle de la qualité ou des priorités.

Il s’agit d’un argument opérationnel, plutôt que d’une affirmation selon laquelle chaque équipe est déjà confrontée à une file de revue surchargée. La pression découle du flux de travail : produire une proposition et en assumer la responsabilité exigent des tâches différentes.

Un réviseur doit établir ce que la modification est censée accomplir. Il doit ensuite déterminer si sa mise en œuvre correspond à cette intention. Les tests automatisés peuvent étayer ce jugement, mais leur utilité dépend de ce qu’ils vérifient réellement.

Un test qui confirme une sortie attendue peut toujours négliger une hypothèse erronée sur le comportement des clients. Une modification peut satisfaire la tâche qui lui a été attribuée tout en entrant en conflit avec une autre partie du produit. Ce sont des raisons d’examiner les éléments probants autour d’une proposition.

Les conséquences vont également au-delà de l’exactitude lors de la soumission. Quelqu’un doit maintenir l’implémentation, expliquer ses décisions et répondre lorsque les exigences évoluent. Le code supplémentaire crée des obligations parallèlement à la valeur immédiate qu’il apporte.

Pour les responsables de l’ingénierie, cela soulève une question de capacité. Si la rédaction devient plus facile, comment une équipe doit-elle répartir son attention entre de nouvelles propositions, la maintenance existante et la fiabilité en production ? Augmenter les soumissions sans ajuster ces priorités risque de déplacer la contrainte vers l’aval.

Les chercheurs DORA de Google Cloud décrivent une tension connexe dans leur analyse des arbitrages du développement par IA. Ils indiquent que le temps gagné lors de la création se déplace souvent vers l’audit et la vérification. Leur interprétation considère l’IA comme un amplificateur des forces et faiblesses organisationnelles existantes.

Cette observation offre un cadre utile pour lire les chiffres de la plateforme. Une équipe disposant d’exigences claires et de contrôles fiables part d’une position différente de celle d’une équipe dont les responsabilités sont floues. Donner à ces deux équipes une rédaction plus rapide ne supprime pas ces différences.

La pression immédiate pèse sur les personnes qui approuvent les modifications et en assument les conséquences. Un mainteneur ne peut raisonnablement traiter la confiance d’un agent comme un substitut à des preuves. Un responsable de l’ingénierie ne peut pas déduire la valeur client d’un simple nombre croissant de soumissions.

Les équipes de sécurité font face à un problème d’allocation similaire. Une proposition peut nécessiter un examen approfondi parce qu’elle modifie des règles d’accès, traite des informations sensibles ou introduit un composant externe. Son origine ne détermine pas son risque.

Les équipes produit ont également un rôle à jouer. Une implémentation plus facile rend plus tentant le fait de poursuivre des demandes vaguement définies. Des critères d’acceptation clairs prennent davantage de valeur lorsque générer une implémentation plausible demande moins d’efforts.

Pour les développeurs individuels, l’implication est plus précise que le simple fait d’apprendre à rédiger des prompts. La compétence précieuse consiste à relier une modification demandée aux preuves qu’elle fonctionne et qu’elle a sa place dans le projet.

Cela comprend la préservation du raisonnement derrière les décisions. Les équipes qui tentent de créer une base de connaissances interrogeable font face à un défi connexe : conserver le contexte technique disponible lorsque l’auteur d’origine est absent.

La documentation ne peut pas approuver une modification. Elle peut aider un réviseur à comprendre les contraintes dont dépend l’approbation. À mesure que la rédaction s’accélère, ce contexte partagé mérite autant d’attention que les outils de génération eux-mêmes.

Copilot, Claude et Codex sont en concurrence dans le même flux de travail

Le contexte concurrentiel aide à expliquer pourquoi l’adoption des agents devient une question de flux de travail. Les développeurs peuvent rencontrer différents fournisseurs sans abandonner l’endroit où leurs équipes discutent et approuvent les modifications.

L’annonce de GitHub en février a présenté des agents de codage partenaires, dont Claude d’Anthropic et Codex d’OpenAI, en préversion publique. Elle décrivait l’attribution de travail depuis GitHub et la revue de pull requests préliminaires générées par ces agents.

Cette annonce établit l’orientation produit durant l’année couverte par le rapport. Elle ne doit pas être interprétée comme un inventaire complet de la disponibilité actuelle ou des conditions d’accès.

Pour GitHub, héberger des agents concurrents fait du flux de travail de revue un actif stratégique aux côtés de son propre assistant de codage.

La plateforme peut rester centrale même lorsqu’un développeur préfère un autre fournisseur pour une mission particulière. Le travail a toujours besoin d’une destination, d’un historique, d’une discussion et d’un processus d’approbation.

Pour Anthropic et OpenAI, apparaître dans cet environnement offre une autre voie vers le travail de développement. Leurs agents peuvent concourir pour des missions là où les équipes gèrent déjà les modifications logicielles.

Cette comparaison n’établit pas quel agent produit les meilleurs résultats. Un accord de distribution et une annonce produit ne peuvent pas répondre à cette question. Ils montrent comment les fournisseurs atteignent les utilisateurs, plutôt que la fiabilité avec laquelle ils résolvent des tâches comparables.

Cette distinction importe lors de l’interprétation de l’adoption des agents GitHub. Davantage de propositions lancées par des agents n’identifient pas automatiquement un fournisseur gagnant. L’adoption du flux de travail et la concurrence au sein de ce flux constituent des évolutions distinctes.

Un exemple concret apparaît dans l’annonce de février : les développeurs pouvaient attribuer une issue à un agent et recevoir une ébauche à examiner. Une issue consigne une tâche ou un problème demandé. Cela donne à la délégation un point de départ reconnaissable et un résultat révisable.

L’importance réside dans le transfert. Une demande devient une tentative d’implémentation, qui revient dans un système où les personnes peuvent inspecter les modifications et demander des révisions. L’agent participe à une structure de responsabilité existante.

Pour une équipe qui évalue des fournisseurs, cette structure devrait rendre la comparaison plus significative. La question pertinente est de savoir si un fournisseur accomplit le travail réel de l’équipe avec un effort de revue acceptable. Une démonstration soignée ne peut pas établir ce résultat.

Imaginons une comparaison d’agents sur une tâche de maintenance récurrente. Une évaluation utile examinerait si chaque proposition répond à la demande, respecte les conventions du projet et fournit une vérification crédible. Compter les fichiers générés répondrait à une autre question.

Il en va de même pour l’intégration d’un agent dans une équipe. L’accès à l’outil n’est que le début. Les autorisations, les limites des tâches et la responsabilité de l’approbation exigent toujours des décisions explicites.

Préserver un environnement de revue cohérent présente également un avantage pratique. Les équipes peuvent évaluer un nouveau fournisseur sans remplacer simultanément tous les processus environnants. Cela facilite la distinction entre les différences de fournisseurs et les changements de flux de travail.

L’histoire concurrentielle soutient donc la tension centrale. Les fournisseurs rendent la rédaction plus accessible au sein d’environnements d’ingénierie établis. La valeur de cet accès dépend de la capacité des équipes à transformer des propositions concurrentes en modifications acceptées et maintenables.

Des fusions plus rapides laissent ouvertes d’importantes questions de qualité

GitHub indique que les demandes impliquant des agents en septembre ont atteint un taux de fusion à deux semaines de 90 %, contre environ 86 % pour les demandes sans implication d’agent détectée.

Une fusion enregistre l’acceptation dans un projet ; elle n’établit pas la fiabilité à long terme ni la valeur commerciale de la modification.

Cette limite s’applique également aux changements d’origine humaine. L’approbation peut être raisonnable au vu des éléments disponibles, tandis que les comportements ultérieurs révèlent une interaction négligée. La qualité logicielle se révèle avec le temps.

Une acceptation plus rapide peut refléter une amélioration. Elle peut aussi refléter des différences dans les tâches soumises, les pratiques de projet ou le niveau de contrôle requis. Une comparaison observationnelle ne peut pas automatiquement distinguer ces explications.

La sélection des tâches est particulièrement importante. Les équipes peuvent déléguer un travail dont elles savent déjà définir les spécifications et vérifier les résultats. Les missions plus ambiguës peuvent rester confiées aux développeurs. Comparer ces groupes sans tenir compte de leurs différences risque de surestimer le résultat.

La possibilité inverse mérite également d’être prise en compte. Un agent peut rendre réalisable une maintenance auparavant négligée, élargissant ainsi l’éventail du travail entrepris par une équipe. Une évaluation équitable doit tenir compte de cette production supplémentaire utile.

C’est là que les lectures simplistes échouent dans les deux sens. Une activité accrue ne suffit pas à démontrer que chaque équipe est devenue plus productive. L’absence d’une estimation universelle de la productivité ne suffit pas à prouver que cette activité n’a aucune valeur.

L’expérience de METR sur la productivité des développeurs illustre pourquoi la mesure est importante. Son étude randomisée du début de 2025 a impliqué 16 développeurs expérimentés réalisant 246 tâches dans des projets open source qu’ils connaissaient bien. L’autorisation d’utiliser l’IA a augmenté le temps de réalisation de 19 %.

Ces résultats décrivent une population, un contexte de tâches et une génération d’outils particuliers. Ils ne doivent pas être considérés comme une mesure directe des performances des agents à la fin de 2026.

La pertinence de l’étude ici est méthodologique. Constater que des développeurs utilisent un outil ne dit pas à quel point ils réalisent plus vite un travail équivalent. Cela exige une comparaison crédible.

Les recherches historiques doivent également être mises à jour lorsque les comportements évoluent. Un résultat peut rester valable dans son contexte initial tout en devenant moins informatif pour un flux de travail plus récent. Le traiter comme intemporel constituerait une autre erreur de mesure.

Les comparaisons de qualité exigent des limites tout aussi rigoureuses. Une modification proposée peut réussir les vérifications existantes tout en ajoutant une complexité que les futurs mainteneurs devront absorber. À l’inverse, une implémentation plus large peut supprimer une solution de contournement maladroite et réduire les efforts futurs.

Les évaluateurs ont donc besoin d’éléments liés à la tâche. Des vérifications pertinentes, un raisonnement compréhensible et une présentation claire du comportement modifié apportent davantage d’informations qu’une étiquette d’origine.

Pour les acheteurs en entreprise, cela crée un défi d’approvisionnement. Les tableaux de bord d’adoption sont faciles à résumer, tandis que les incidents évités et les charges de maintenance réduites prennent plus de temps à établir. Une évaluation convaincante doit reconnaître cette différence.

La conclusion appropriée est précise. Les chiffres d’acceptation de GitHub fournissent des informations sur la manière dont les changements progressent sur sa plateforme. Ils laissent place à des recherches supplémentaires sur les retouches, la fiabilité, l’effort des évaluateurs et la livraison utile.

Cet écart constitue un programme de mesure. Il n’exige pas de supposer que les agents sont universellement bénéfiques ou que leurs contributions ne sont que du bruit.

Mesurer la productivité des agents devient plus difficile à mesure que le travail évolue

Le défi de la mesure va au-delà du choix du bon tableau de bord. L’utilisation d’agents peut modifier les tâches que les développeurs tentent de réaliser et la manière dont ils répartissent leur attention.

Dans sa mise à jour sur les recherches de productivité de février 2026, METR a indiqué que son expérience ultérieure fournissait une estimation peu fiable des effets actuels de l’IA sur la productivité. Le recrutement, la sélection des tâches et l’utilisation simultanée d’agents compliquaient l’interprétation.

Les chercheurs estimaient que les développeurs tiraient probablement davantage de bénéfices que ne le suggéraient leurs estimations antérieures. Ils ont également souligné que leurs données apportaient des preuves limitées concernant l’ampleur de cette amélioration.

Une évaluation fiable doit prendre en compte les changements dans le travail lui-même, parallèlement aux changements dans les outils qui l’exécutent.

C’est important, car une comparaison sur des tâches fixes répond à une question circonscrite. Elle peut estimer comment l’assistance affecte une mission particulière. Elle ne peut pas pleinement saisir ce qui se passe lorsque l’assistance modifie les missions que les personnes choisissent.

Supposons qu’un développeur ait auparavant reporté une migration fastidieuse parce qu’elle exigeait trop d’effort concentré. Un agent pourrait rendre ce travail réalisable pendant une semaine déjà chargée. Le bénéfice comprend l’achèvement de quelque chose qui serait resté non fait.

Examinons maintenant le cas inverse. Une rédaction plus facile peut encourager une équipe à implémenter une fonctionnalité avant d’avoir établi que les utilisateurs en ont besoin. L’implémentation peut être techniquement réussie tout en consommant une attention qui aurait été mieux employée ailleurs.

Ces exemples sont des possibilités analytiques, et non des résultats rapportés par le jeu de données Octoverse. Ils expliquent pourquoi une livraison utile doit être reliée à l’intention et aux résultats.

Le travail en parallèle introduit une autre complication. Un développeur peut examiner une proposition pendant qu’un agent travaille sur une tâche distincte. Mesurer le temps d’exécution écoulé de l’agent comme du temps de travail humain représenterait mal cette organisation.

Pourtant, ignorer la supervision fausserait également le résultat. La préparation des tâches, les interruptions, les approches rejetées et l’examen final doivent faire partie de l’évaluation du flux de travail. La frontière comptable influence la conclusion.

Pour les organisations, cela plaide en faveur de plusieurs formes de preuves complémentaires. Des évaluations de tâches comparables peuvent examiner l’effort nécessaire à leur réalisation. Les données opérationnelles peuvent montrer l’acceptation et les retouches. Les résultats produit peuvent établir si les changements livrés ont aidé les utilisateurs.

Aucune mesure unique ne saisit tout. C’est une raison d’indiquer ce que représente une mesure, plutôt que de ramener des résultats différents à un score universel de productivité.

Une équipe peut améliorer sa vitesse de livraison tout en rencontrant des difficultés de maintenance. Une autre peut réduire les efforts répétitifs sans accroître la fréquence des livraisons, car les approbations restent limitées ailleurs. Toutes deux méritent des descriptions correspondant à leur expérience réelle.

La même rigueur s’applique à la comparaison des équipes. Un service mature assorti d’exigences strictes de fiabilité diffère d’un nouveau projet expérimental. Leurs nombres de soumissions ne doivent pas devenir un classement de l’efficacité des développeurs.

GitHub Octoverse 2026 est utile comme preuve d’un environnement de développement en évolution. Ses implications plus larges deviennent plus claires lorsque l’activité de la plateforme est considérée parallèlement aux études au niveau des tâches et aux résultats organisationnels.

Pour les développeurs, la question pratique est de savoir si leur travail devient plus facile à réaliser et à maintenir. Pour les managers, il s’agit de savoir si ces gains se maintiennent à l’échelle de l’équipe. Aucune de ces questions ne disparaît lorsque la rédaction devient courante.

Surveiller l’effort d’évaluation, la fiabilité et les résultats de tâches comparables

Les prochains éléments utiles devront relier la participation des agents à ce qui se produit après l’apparition d’une proposition. Au cours des prochains mois, les lecteurs devraient rechercher les évolutions qui clarifient la relation entre la rédaction et la livraison.

Les preuves de suivi les plus solides relieront le travail produit par des agents à l’effort d’évaluation, aux résultats en production et à des comparaisons de tâches crédibles.

Le premier signal est une meilleure présentation de l’effort d’évaluation. Les fournisseurs de plateformes et les équipes d’ingénierie devraient montrer quelle attention humaine exigent les propositions d’agents acceptées. Le temps d’attente seul ne peut pas l’établir.

Une demande peut attendre dans une file sans consommer beaucoup d’effort de la part des évaluateurs. Une autre peut progresser rapidement tout en exigeant une discussion intensive. Distinguer ces situations rendrait les statistiques d’acceptation plus informatives.

La preuve d’une baisse de l’effort d’évaluation sur des travaux comparables renforcerait l’argument selon lequel les agents améliorent l’ensemble du flux de travail. Une hausse de cet effort suggérerait qu’une partie des gains de rédaction se déplace vers la supervision.

Les lecteurs devraient également examiner comment les équipes comptabilisent le travail rejeté. Un tableau de bord centré uniquement sur les fusions réussies peut omettre l’effort consacré à l’évaluation de propositions qui ne sont jamais acceptées. Ces tentatives font également partie de l’évaluation.

Le deuxième signal est la fiabilité après acceptation. Recherchez des évaluations qui suivent les changements au-delà de la fusion et examinent s’ils nécessitent des corrections, des annulations ou une réponse aux incidents.

Une annulation supprime ou défait un changement antérieur. Sa signification dépend du contexte, car les décisions produit peuvent évoluer pour des raisons sans rapport avec la qualité du code. Un rapport utile doit fournir suffisamment de détails pour distinguer ces explications.

Une fiabilité stable parallèlement à une livraison plus rapide renforcerait l’argument en faveur de gains nets. Davantage de réparations ultérieures le nuancerait. La comparaison pertinente devrait tenir compte du risque de la tâche et de la maturité du projet.

C’est particulièrement important pour les acheteurs évaluant un déploiement dans l’ensemble d’une organisation. Un projet pilote réussi sur un travail de maintenance circonscrit n’établit pas automatiquement la préparation à des systèmes sensibles. L’extension doit produire des preuves concernant ce nouveau périmètre.

Le troisième signal est une recherche actualisée comparant un travail équivalent avec des outils actuels. Les études devraient expliquer comment elles traitent la sélection des tâches, les agents simultanés et l’effort humain entourant la génération.

Une amélioration cohérente dans des évaluations crédibles renforcerait l’argument de la productivité. Des résultats mitigés suggéreraient que les bénéfices dépendent de la mission, du développeur ou de l’organisation. Dans les deux cas, ce serait plus utile qu’une affirmation universelle.

Les chercheurs devraient également rendre les limites visibles. Un résultat au niveau d’une tâche, un résultat de livraison d’équipe et un résultat de satisfaction des développeurs peuvent tous être valides. Ils décrivent différentes dimensions de l’expérience.

Pour les lecteurs qui évaluent GitHub Octoverse 2026, gardez les distinctions centrales visibles à mesure que de nouvelles annonces arrivent. Demandez quel travail les agents commencent, qui l’évalue et ce qui se passe après l’approbation. Suivez si les organisations publient des preuves concernant l’effort d’évaluation et la fiabilité parallèlement à l’adoption. Lorsque vous comparez des outils, recherchez des résultats issus de tâches ressemblant aux vôtres, avec la supervision incluse dans le calcul. Préservez le contexte des changements importants afin que les futurs évaluateurs puissent en comprendre l’objectif. Le rapport rend difficile d’ignorer la participation des agents ; votre prochaine décision devrait dépendre du travail que cette participation aide à accomplir. Quelles preuves montreraient que votre équipe livre des logiciels plus utiles avec moins d’effort total ?