GitHub : 220 millions de modifications de code par mois, le triple en un an

220 millions de pull requests fusionnées par mois : c’est le chiffre phare du rapport Octoverse 2026 de GitHub, présenté à la conférence GitHub Universe. Ce volume a triplé en moins d’un an. Reste une question que le chiffre ne règle pas : qui relit tout ce code, et qui en répond ?

Les chiffres annoncés à GitHub Universe

C’est Jay Parikh, vice-président exécutif de GitHub, qui a dévoilé le rapport annuel Octoverse. Le développeur Simon Willison, présent sur place, en rapporte les principaux chiffres. Il précise que GitHub lui a offert un billet d’entrée via son programme « GitHub Stars » : un détail utile à savoir pour situer le regard qu’il porte sur l’événement.

Voici ce qui est annoncé pour 2026 :

• les pull requests fusionnées ont triplé en moins d’un an, pour atteindre 220 millions par mois ;
• les commits ont plus que triplé, à 7,38 milliards par mois, l’essentiel de la hausse datant du second semestre ;
• le rythme de création de nouveaux dépôts a doublé, à 30,3 millions par mois.

Une pull request est une proposition de modification du code d’un projet. Quand elle est « fusionnée », elle est intégrée à la version de référence. Un commit est un enregistrement unitaire d’une modification.

Willison y voit « une représentation assez frappante » de l’impact de l’ingénierie agentique sur GitHub. Le terme désigne un travail de programmation confié, en partie, à des agents IA qui écrivent et proposent du code. Ce lien entre la hausse et les agents est donc l’interprétation qui accompagne les chiffres. Les passages que nous avons pu lire n’indiquent pas quelle part de ces pull requests vient réellement d’agents.

Un volume n’est pas une preuve de qualité

Le chiffre est spectaculaire. Mais que mesure-t-il exactement ? Le nombre de modifications intégrées, pas leur valeur. Trois fois plus de code fusionné peut signaler trois fois plus de fonctionnalités livrées. Cela peut aussi signaler beaucoup de petites modifications, du code généré en masse, ou des projets lancés puis abandonnés.

Plusieurs points restent sans réponse dans les sources :

• La part des agents. Aucun chiffre consulté ne sépare le code écrit par des humains de celui produit par des agents.
• La relecture. Une pull request fusionnée a été acceptée par quelqu’un ou par un processus automatique. Les sources ne disent pas combien de ces fusions ont été relues par un humain, ni avec quel soin.
• La qualité et la sécurité. Le rapport, tel que le décrit Willison, compte des volumes. Il ne dit rien des bogues, des failles ou de la dette technique introduits.
• Le point de vue de l’émetteur. Ces chiffres viennent de la plateforme elle-même, qui a intérêt à montrer que les agents transforment le développement. Cela ne les rend pas faux. Cela invite à les lire comme une annonce, pas comme un audit indépendant.

La méthodologie rappelle aussi que certains chiffres sont des estimations. Pour classer les pays, GitHub a utilisé un modèle de langage qui extrait le code pays des profils d’utilisateurs, afin de corriger l’effet des VPN. Pour classer les dépôts par secteur d’activité, un modèle d’embeddings multilingue a analysé nom, description, thèmes et fichier README. Rien d’anormal, mais ces catégories reposent sur des modèles d’IA, avec leurs marges d’erreur.

Chez Anthropic, l’entretien de code change de nature

Si le code devient abondant, qu’est-ce qui devient rare ? Un témoignage venu d’Anthropic donne une piste. The Decoder rapporte que Felix Rieseberg, responsable d’ingénierie chez Anthropic et à la tête du développement de Claude.ai et de Claude Code Desktop, a supprimé l’entretien de programmation classique.

Son argument : donner aujourd’hui un petit exercice de code à un candidat n’a plus de sens, car Claude les résout mieux que les candidats. Il compare un défi React à une interrogation sur l’assembleur. Selon lui, les bons scores aux tests ne prédisent plus qui deviendra un excellent développeur. Il observe même que des ingénieurs récents dépassent des collègues plus expérimentés : « Hunger beats tenure », la faim bat l’ancienneté.

Il cite un exemple interne. Deux ingénieurs d’Anthropic, alors relativement nouveaux, Anthony Morris et Alice Zhao, ont conçu l’interface graphique de Claude Code pendant un week-end. La première version publique est sortie environ huit jours plus tard. Rieseberg cherche désormais, dans les candidatures, de petits prototypes qui montrent du goût, de l’empathie et une pensée fondée sur des principes.

Il s’agit du récit d’un seul manager, dans une entreprise qui vend justement des agents de code. The Decoder nuance d’ailleurs le message. Le seuil d’entrée des postes juniors se déplace de l’application et du savoir-faire vers l’esprit d’entreprise, le sens du produit et le goût, des compétences que peu d’universités enseignent. Et les modèles que Rieseberg met en avant construisent des prototypes le week-end sans qu’on le leur demande, une disponibilité que tous les débutants ne peuvent pas offrir.

Ce que cela change pour un salarié ou un indépendant

Les deux sources ne parlent pas de la même chose, mais elles pointent dans la même direction. Quand produire du code coûte moins cher, la production cesse d’être le goulot d’étranglement. Le goulot devient la décision : que faut-il construire, ce code est-il correct, qui l’assume s’il casse en production ?

Pour un salarié ou un indépendant qui utilise des assistants de code, cela suggère quelques réflexes concrets :

• Relire vraiment. Un code généré qui « tourne » n’est pas un code compris. Si vous ne pouvez pas expliquer ce qu’il fait, vous ne pouvez pas en répondre devant un client ou un employeur.
• Tester avant de fusionner. Des tests automatiques et une relecture par un tiers restent les garde-fous les plus simples.
• Documenter la responsabilité. Dans une petite structure, savoir qui valide quoi évite que « c’est l’agent qui l’a écrit » serve de réponse.
• Cultiver le jugement produit. C’est ce que Rieseberg dit chercher chez les candidats : une idée claire, un prototype lisible, un souci de l’utilisateur.

Ce déplacement n’est pas neutre. La relecture demande du temps et de l’expérience, précisément ce que les profils juniors n’ont pas encore eu l’occasion d’accumuler. Si les agents écrivent le code facile, comment les débutants apprendront-ils à repérer le code douteux ?

Ce qu’il faudra observer

Les 220 millions de pull requests mensuelles disent que l’activité sur GitHub explose. Elles ne disent pas si le code qui en sort est meilleur, plus sûr ou mieux maintenu. Pour trancher, il faudrait des données que le rapport, tel que nous le lisons, ne fournit pas : la part de code écrite par des agents, le taux de relecture humaine, le nombre de correctifs et de failles après fusion.

La question à garder en tête est simple. Dans vos propres projets, quelle proportion du code que vous livrez a été relue ligne par ligne par un humain qui accepterait d’en répondre ?

Sources

• GitHub Octoverse 2026 (Simon Willison)
• With AI writing the code, entrepreneurial thinking is now what counts most for newcomers at Anthropic (The Decoder)