L’architecture de stockage Git de GitHub a été entièrement revue, et cette annonce, faite lors de GitHub Universe, vise à donner le coup d’accélérateur au développement piloté par des agents. Le défi principal, selon GitHub, n’est plus seulement la quantité de code, mais la fréquence des interactions : l’entreprise prévoit de voir les dépôts les plus actifs passer de quelques écritures par seconde à un débit soutenu de milliers d’opérations par seconde dans l’année à venir.

Cette transformation répond à une rupture technologique plus large. Les agents autonomes, capables de planifier, rédiger et tester du code, transforment la nature même d’un dépôt actif. Les chiffres parlent d’eux-mêmes : un dépôt particulièrement sollicité a vu son trafic journalier augmenter d’environ quatre fois entre mars et mai, et cette croissance suit une trajectoire exponentielle.

La stratégie technique s’est articulée autour de deux principes fondamentaux : minimiser la coordination et découpler le stockage du calcul. Les objets Git, étant immuables et nommés par leur contenu, permettent en soi une grande latitude ; deux contributeurs peuvent stocker des objets simultanément sans nécessiter de consensus. Le goulot d’étranglement réside dans la mise à jour des références, une opération beaucoup plus petite, mais qui nécessite une synchronisation.

Préparer l’échelle des agents

GitHub doit préparer son infrastructure à une échelle qui est au moins deux ordres de grandeur supérieure à ce qu’elle gère aujourd’hui. Cela exigeait de supporter des nœuds d’écriture multiples, car le processus d’indexation des paquets et la vérification de la connectivité des objets sont des opérations gourmandes en CPU qui, sur un seul nœud, deviennent rapidement limitantes. De plus, réduire la latence de l’opération push est vital, car un agent attend la confirmation pour passer à son étape suivante.

Pour atteindre cet objectif, GitHub a lancé « Projet Rubicon » en mai 2026. Cette nouvelle architecture s’appuie sur la migration massive de dépôts vers Azure, en limitant le quorum d’écriture aux références individuelles. Les répliques virtuelles, soutenues par Azure Blob Storage, ont été le premier pas pour rendre cette architecture opérationnelle. Pour les développeurs, la promesse est simple : Git reste Git. Ils continuent de faire push, fetch et de créer des branches sans changer leurs habitudes.

Le contexte de l’adoption des agents

Si GitHub met en place cette fondation solide, c’est que la pression exercée par l’automatisation est déjà palpable. Des analyses externes soulignent que le cycle de développement logiciel classique est en train de « s’effondrer », car l’intelligence artificielle prend en charge la majeure partie de l’implémentation et de la vérification du travail. D’ailleurs, selon le rapport Octoverse 2026, plus de 40 % des demandes de tirage (pull requests) sur la plateforme étaient initiées par des agents IA en septembre.

Cette montée en puissance des agents met en lumière la fragilité des systèmes existants ; GitHub a d’ailleurs connu des incidents de performance et une panne globale de près de huit heures récemment, causés par des défaillances critiques d’infrastructure. Pour absorber cette charge, l’entreprise a ajouté plus de quatre millions de cœurs et 160 pétaoctets de stockage cette année. La refonte de l’architecture Git est donc une réponse plus profonde, visant à garantir la performance même face à une activité soutenue et quasi perpétuelle. Il reste à voir comment cette capacité à absorber un tel flux de travail se traduira en outils accessibles, car la gestion de la linéarisation des changements entre références demeure un point technique complexe à maîtriser à l’échelle mondiale.

Sources

• Inside GitHub’s new Git storage architecture, GitHub, 5 novembre 2026
• Does the World Need a New GitHub?, Analytics India Magazine, 3 novembre 2026
• OpenAI built itself a new Git backend, too, The New Stack, 3 novembre 2026