Brian Celenza, ingénieur logiciel principal chez GitHub, a écrit le 6 octobre sur le blog d'ingénierie officiel que l'entreprise reconstruit sa couche de stockage Git. La raison est énoncée sans détour: les agents IA ont poussé le trafic d'écriture jusqu'à la limite de l'ancienne architecture. Dans des tests internes, la nouvelle architecture multiplie le débit d'écriture par jusqu'à 35.
L'article donne une série de chiffres de croissance sur l'année écoulée:
| Indicateur | Donnée la plus récente | Évolution annuelle |
|---|---|---|
| Événements Git par mois | 473,3 milliards (août 2026) | environ 2,2x |
| Pushes par mois | 3,35 milliards | 4,9x |
| Commits par mois | 7,38 milliards (septembre 2026) | plus de 5x |
| Exécutions Actions par mois | 3,26 milliards (septembre 2026) | plus de 4x |
| PR fusionnées | valeur absolue non précisée | près de 4x |
Le dépôt individuel le plus sollicité a reçu environ 1 milliard de requêtes sur le seul mois d'août. L'article décrit ainsi l'habitude d'écriture des agents:
"An agent in a tight loop commits or checkpoints after nearly every action" (Un agent tournant en boucle serrée commit ou enregistre un checkpoint après presque chaque action.)
L'ancienne architecture bute sur l'écriture
Le système de stockage de dépôts actuel de GitHub s'appelle Spokes. Par défaut, chaque dépôt est conservé en copie complète sur les disques locaux de plusieurs serveurs de fichiers, soit 5 répliques au total. Lorsqu'un push met à jour une référence, le système utilise un protocole de validation en trois phases basé sur la majorité pour garantir que CI, l'interface web et les clients API voient un état cohérent du dépôt.
Dans cette conception, les répliques assurent deux rôles à la fois: prévenir la perte de données et répartir les requêtes de lecture. Le prix à payer est que chaque réplique doit participer à chaque écriture — ajouter des répliques permet d'absorber plus de lectures, mais ralentit l'écriture. À l'époque où les développeurs humains dominaient, les lectures dépassaient largement les écritures, et ce compromis ne posait pas de problème; depuis que les agents ont fait grimper la fréquence d'écriture, le nombre de répliques est devenu le goulot d'étranglement de l'écriture.
La nouvelle architecture se décompose en trois parties
La première consiste à réduire la coordination au minimum: seule la mise à jour des références nécessite encore un consensus entre les parties; le stockage d'objets, la validation et les scans de sécurité passent en traitement parallèle.
La deuxième partie sépare stockage et calcul. La persistance est confiée à Azure Blob Storage, et les requêtes de lecture sont traitées par un ensemble de processus worker légers. L'article précise:
"Separating the two lets us scale each one independently" (Séparer les deux permet de faire évoluer chacun indépendamment.)
La troisième partie isole la maintenance en arrière-plan: la compaction et le garbage collection s'exécutent désormais sur des processus worker dédiés, sans se disputer les ressources avec les requêtes en temps réel. Les mécanismes de contrôle comme la protection des branches, les revues obligatoires, les journaux d'audit et l'observabilité sont conservés.
Un calcul rapide du volume d'écriture
En calcul approximatif sur un mois de 30 jours, 7,38 milliards de commits équivalent à environ 2 850 par seconde; 3,35 milliards de pushes équivalent à environ 1 290 par seconde, contre environ 270 un an plus tôt. Si chaque push devait impliquer les 5 répliques, l'ancienne architecture aurait dû traiter environ 6 500 écritures de réplique par seconde (estimation, sans compter les tentatives répétées ni les tâches de maintenance).
La multiplication par 35 du débit correspond à une croissance annuelle des pushes de 4,9x, ce qui laisse, sur le papier, une marge de plusieurs années. À condition que la courbe de croissance du trafic des agents ne s'accentue pas davantage — ce que GitHub lui-même ne prétend pas prévoir.
Ce que l'article ne précise pas
L'article ne donne pas de calendrier sur le nombre de dépôts déjà migrés vers la nouvelle architecture ni sur la date du basculement complet; il ne précise pas non plus la taille du dépôt ni le niveau de concurrence utilisés pour le benchmark à 35x. Les impacts possibles pour les utilisateurs, comme un éventuel ajustement des limites de débit, ne sont pas non plus mentionnés.
GitHub a connu cette année plusieurs interruptions de service prolongées; l'article ne répond pas à ces incidents et ne dit pas si la nouvelle architecture permettrait d'éviter des situations similaires. Celenza annonce en conclusion que le prochain article de la série détaillera l'architecture future et le contexte de cette refonte.
Sources: blog d'ingénierie de GitHub, CocoLoop; les données officielles de GitHub ont permis de vérifier les critères de comptage mensuel des commits, pushes et exécutions Actions.