GitHub refond son stockage Git pour absorber 5 000 agents sur un seul dépôt
Le 5 novembre 2026, GitHub a détaillé « Project Rubicon », sa nouvelle architecture de stockage Git capable de 7 200 push par seconde sur un dépôt et de 5 000 agents simultanés, en s’appuyant sur un constat simple : seules les mises à jour de références exigent de la coordination. Les objets Git, immuables, partent dans Azure Blob Storage ; l’état mutable, minuscule, va dans un journal répliqué.
5 novembre 2026. Karthik Raman et Brian Celenza publient sur le blog GitHub les détails de la nouvelle architecture de stockage Git de la plateforme, présentée une semaine plus tôt à GitHub Universe. 7 200 push par seconde. C’est le débit atteint en test interne sur un seul dépôt. 5 000 agents. C’est le nombre d’agents concurrents travaillant simultanément sur ce même dépôt, pendant que les lectures restent à faible latence. Pourquoi c’est important : GitHub a reconstruit la couche la plus critique de sa plateforme — le stockage du code — pendant qu’elle tournait, pour encaisser un monde où des milliers d’agents poussent en continu sur les mêmes dépôts.
Le problème : l’agent change la forme d’un dépôt occupé
Le point de départ est une observation chiffrée. Aujourd’hui, les dépôts les plus actifs de GitHub reçoivent au plus quelques dizaines d’écritures par seconde, par à-coups. Avec l’arrivée des agents de code qui tournent en parallèle et 24 heures sur 24, ces à-coups deviendront un débit soutenu d’ici un an. Chaque push déclenche en plus une amplification de lecture : la CI s’exécute, les systèmes de déploiement tirent le commit, les autres agents le récupèrent pour contexte. GitHub dit déjà mesurer cette tendance sur les dépôts en tête de courbe — l’un d’eux a vu son trafic quotidien quadrupler entre mars et mai, puis poursuivre une trajectoire exponentielle.
Plutôt que de planifier « l’incrément suivant », l’équipe a fixé une cible de deux ordres de grandeur de plus en capacité. Pour un dépôt unique, cela impose d’accepter des milliers d’écritures par seconde, de répartir l’écriture sur plusieurs nœuds — l’indexation des packs et la vérification de connectivité des objets sont les étapes les plus coûteuses en CPU, et un seul nœud saturerait vite — et de minimiser la latence de commit, puisqu’un agent attend chaque push avant de passer à l’étape suivante.
L’idée maîtresse : seuls les références exigent un accord
Tout découle d’un constat sur la nature de Git. Les objets Git sont immuables et nommés par leur contenu : deux auteurs peuvent les stocker en même temps sans se concerter, car l’objet deadbeef… sera identique quel que soit l’ordre d’arrivée. La seule partie d’un push qui exige un accord est la mise à jour de référence — la branche ou le tag qui pointe vers le nouvel état — et cette mise à jour est minuscule en comparaison du reste.
L’architecture en tire deux principes, déjà posés dans le premier billet de la série : minimiser la coordination et découpler le stockage du calcul. La partie lourde (les packs) devient un problème de débit objet, parfaitement adapté à un service comme Azure Blob Storage ; la partie ordonnée (les références) devient un journal répliqué. Les composants historiquement soudés — stocker, servir, maintenir un dépôt — peuvent enfin évoluer indépendamment.
Pour le développeur, Git reste Git : mêmes commandes, mêmes protections. La refonte est invisible côté client, et c’est le but.
« Project Rubicon » : un plan de données entièrement neuf
Le projet porte un nom assumé : « Rubicon », clin d’œil au point de non-retour que l’industrie a franchi avec le développement agentique. Il a démarré en mai 2026, dans la foulée de la migration initiale vers Azure — qui a déjà déplacé 99,99999 % des dépôts et a scindé le quorum d’écriture au niveau de chaque référence.
Au-dessus, beaucoup de choses ne changent pas. Les requêtes des clients Git, de l’API et de l’interface web arrivent sur Spokes, qui garde son rôle de routage, d’équilibrage de charge, de placement et de garantie d’équité entre locataires — c’est lui qui porte l’échelle horizontale. En dessous, en revanche, le plan de données est neuf.
Spokes route chaque requête vers l’un des réplicas virtuels affectés au dépôt. Ces réplicas forment une flotte unique de calcul jetable : leur disque local n’est qu’un cache, reconstruisible à tout moment. Quand un réplica disparaît, les autres continuent de servir et un remplaçant remplit son cache au fil du trafic. Quand un dépôt devient actif, on ajoute des réplicas. Parallèlement, une flotte de nœuds de compaction travaille en arrière-plan, directement contre Blob Storage et Ref-CAS, pour fusionner les packs et supprimer les objets inaccessibles — jamais sur les réplicas, dont le CPU et la mémoire restent ainsi dédiés au service.
L’état durable vit à deux endroits : les objets Git (packs et données d’accélération de lecture) dans Azure Blob Storage ; les références et le manifeste des packs dans un journal répliqué nommé Ref-CAS, pour Reference Compare-and-Swap.
Deux chemins, une seule transaction ordonnée
Le parcours d’une écriture tient en une phrase : un réplica virtuel indexe le pack entrant et l’envoie vers Blob Storage, puis commet une unique transaction dans Ref-CAS qui liste le pack dans le manifeste et met à jour les références ; un nœud de compaction le fusionnera plus tard. Le parcours d’une lecture : le réplica compare sa version de référence avec Ref-CAS, tire les packs nécessaires depuis Blob Storage dans son cache, et sert depuis là.
La subtilité est dans ce qui va où. Blob Storage héberge presque tout le durable : les packs et index écrits par les push, la compaction et le garbage-collect ; les accélérateurs de lecture (index multi-packs, bitmaps de reachabilité) ; les enregistrements qui permettent à la compaction de reprendre ou d’auditer son travail ; les leases de répartition ; les réponses mises en cache des fetch répétés ; et les checkpoints de l’état des références — non autoritatifs. Tout ce qui s’écrit une fois sur une clé et ne bouge plus est un client idéal d’un stockage objet.
Les références, elles, sont l’exact inverse : chaudes et mutables. Un dépôt très actif voit sa référence de branche changer des milliers de fois par seconde — c’est précisément l’objet qu’un stockage objet immuable gère mal, et la raison d’être de Ref-CAS.
Ce que ça change pour un SRE
La leçon dépasse GitHub. Le motif « objets immuables adressés par le contenu + journal répliqué pour le minuscule état mutable » est une réponse générique à la saturation des systèmes à fort ratio lecture/écriture : on pousse l’état immuable vers le stockage le moins cher et le plus scalable, et on concentre la coordination sur la plus petite unité d’ordre possible. C’est le même geste que l’immutabilité a déjà rendu familier dans les pipelines de build, transposé au cœur de la forge.
Pour l’exploitant, le signal est concret : le développement agentique ne change pas seulement ce qu’on déploie, il change le profil de charge de l’outillage qui le sert. Un dépôt qui encaissait des à-coups va devoir encaisser un débit continu, et les architectures pensées pour l’humain — quelques dizaines d’écritures par seconde, en rafales — ne tiennent pas. La refonte de GitHub est un avant-goût de ce que la plupart des plateformes internes devront refaire.
Verdict
Si vous gérez une forge ou une plateforme de livraison, lisez « Rubicon » comme une feuille de route, pas comme une anecdote. La cible est claire : au moins deux ordres de grandeur de capacité supplémentaire, parce que les agents vont rendre continu ce qui était épisodique. Si votre forge est un GitLab ou un Gitea interne monolithique, mesurez dès maintenant votre ratio écriture/lecture et vos à-coups : c’est l’indicateur qui vous dira quand la même refonte deviendra nécessaire. Si vous consommez GitHub, vous n’avez rien à faire — la migration est invisible côté client — mais attendez-vous à ce que la notion de « dépôt occupé » change d’échelle, et dimensionnez vos webhooks et votre CI en conséquence. La leçon tient en une ligne : quand l’immuable domine, seule la référence mérite encore qu’on se coordonne.