GitHub a annoncé le 6 octobre 2026, dans un article de son blog d'ingénierie officiel, qu'il reconstruit l'infrastructure Git qui porte l'hébergement de code mondial — pour une raison directe : l'auteur du code a changé. En un an, les commits, pushes et fusions produits par les agents et les développeurs sur GitHub ont été multipliés, et l'architecture de stockage pensée pour un rythme humain a heurté en premier le goulot des écritures.
Les chiffres d'abord : les pushes atteignent 3,35 milliards par mois
Le changement d'échelle rapporté par GitHub est abrupt. En août 2026, les événements Git de la plateforme ont atteint 473,3 milliards, plus du double de l'année précédente ; en septembre 2026, les commits ont atteint 7,38 milliards, plus de cinq fois le niveau d'un an plus tôt. Les pushes sont passés de 0,69 à 3,35 milliards par mois, soit 4,9 fois plus ; les fusions de pull requests ont presque quadruplé ; et GitHub Actions a tourné 3,26 milliards de fois en septembre, là aussi plus de quatre fois plus.
La façon de travailler des agents amplifie chaque écriture. Des milliers d'agents travaillant en parallèle sur des branches distinctes d'un même dépôt produisent un débit d'écriture continu qui converge vers un point unique, le tronc : les fusions se disputent une même référence, et le développement centré sur le tronc, les trains de versions et les files de fusion canalisent tout le travail vers une référence unique qui doit absorber chaque fusion. Chaque push se démultiplie en outre en milliers de lectures, la CI et l'analyse de code clonant ou récupérant la même extrémité de branche des milliers de fois par minute.
Lire s'étend facilement, écrire non : le couplage de l'ancienne architecture
La couche de stockage actuelle de GitHub, Spokes, conserve une copie complète de chaque dépôt sur les disques locaux de plusieurs serveurs de fichiers — cinq par défaut — et utilise un protocole de commit en trois phases avec quorum pour que le web, l'API et la CI voient un état cohérent lors d'une mise à jour de référence. Ce duo sert aujourd'hui un milliard de dépôts.
Le problème : la durabilité et la mise à l'échelle sont le même mécanisme. Les copies sur disque sont à la fois la source de vérité et la source de capacité de lecture. Ajouter de la capacité de lecture signifie ajouter une réplique durable de plus, et chaque réplique participe à chaque écriture : un push n'est donc pas plus rapide que sa réplique la plus lente. Ajouter des répliques pour absorber les lectures ralentit les écritures, perdre une réplique réduit la capacité de lecture, et perdre le quorum arrête complètement les écritures. Pour la plupart des dépôts, ce compromis tient ; aux niveaux d'activité les plus élevés, il devient un plafond.
La direction de la reconstruction : séparer durabilité et échelle
La nouvelle architecture sépare la durabilité de la mise à l'échelle, en tenant trois lignes : les flux de travail ne changent pas — branches, revues, fusions et historique fonctionnent sur la nouvelle infrastructure exactement comme les équipes les connaissent, sans modifier les habitudes ; la fiabilité passe en premier, chaque compromis étant mesuré à cette aune ; et le contrôle reste humain — protections de branche, revues obligatoires, journaux d'audit et visibilité des dépôts sont préservés, de sorte que, quelle que soit la charge prise par les agents, le code reste relu et approuvé par ses propriétaires. Côté ingénierie, l'accent est mis sur la coordination minimale : un dépôt recevant de nombreux pushes doit accepter et publier les mises à jour rapidement, sans attendre un accord global à chaque étape. Toute la reconstruction se fait pendant que la plateforme continue de tourner — il n'existe aucune fenêtre de maintenance où le code du monde s'arrêterait.
La portée dépasse une seule entreprise. Quand la production des agents se compte en milliards de commits, le goulot se déplace de la capacité des modèles vers l'infrastructure : dépôts, revues et CI, construits pour un rythme humain, doivent être reconstruits pour un rythme machine. Ce site a déjà présenté l'évaluation ReviewBench de GitHub, qui éprouve le code écrit par des agents sur 219 pull requests réelles — la question y est de savoir si ce code est fiable. Cette reconstruction répond à l'autre moitié : la plateforme elle-même peut-elle suivre la vitesse à laquelle les agents écrivent ? Pour les équipes qui s'appuient fortement sur les agents de code, le débit d'écriture, les files de fusion et les capacités d'audit des plateformes de code vaudront, ces deux prochaines années, d'être surveillés d'aussi près que les modèles.
