GitHub repense le stockage Git : 5 000 agents dans un même dépôt, 7 200 pushs par seconde

Git a été créé pour les humains. Un développeur effectue un commit, pousse du code quelques fois par jour, entre parfois en conflit avec un collègue, et tout cela ne représente qu’une charge modeste pour le serveur. Les agents bouleversent ce modèle : ils écrivent du code en parallèle, fréquemment et sans pause. GitHub a fait état d’un test montrant jusqu’où la plateforme est prête à aller dans cette direction.

Ce qu’affirme GitHub

Selon le compte officiel, la nouvelle architecture de stockage Git a pris en charge, lors de tests internes, 5 000 agents travaillant simultanément dans un même dépôt. Ils effectuaient 7 200 pushs par seconde. Dans le même temps, le service continuait à traiter les requêtes de lecture avec une latence durablement faible. La publication elle-même ne fournit aucun détail, seulement un lien vers un article. Tout ce qui suit à propos de la conception du système doit donc être considéré comme un cadre de réflexion, et non comme une description de son architecture.

Quel problème cela résout

Imaginez un carrefour très fréquenté dont les feux sont conçus pour cinq voitures par minute. Tant que des humains conduisent, tout va bien. Lorsque 5 000 véhicules autonomes arrivent, un embouteillage se forme. Il en va de même pour un dépôt : chaque push met à jour des références et écrit des objets ; sous forte concurrence, les écritures commencent à gêner les lectures. Or tout le monde a besoin de lire : le clonage, la CI, les revues et les agents voisins qui récupèrent le code le plus récent.

Le chiffre essentiel n’est pas ici celui des 5 000 agents, mais l’association de deux conditions : un débit d’écriture élevé et une faible latence de lecture en même temps. Il est possible d’absorber des pics d’écriture en dégradant tout le reste. Ici, GitHub affirme que les performances de lecture ne se sont pas détériorées.

Pourquoi cela compte dès maintenant

Les workflows agentiques s’éloignent rapidement du modèle « un assistant aide une personne ». De plus en plus souvent, une seule personne lance des dizaines de tentatives parallèles pour résoudre une tâche, chacune vivant dans sa propre branche. Si l’infrastructure ne supporte pas cette charge, les équipes ne sont plus limitées par la qualité des modèles, mais par le stockage, les quotas et les files d’attente.

Pour les équipes produit et les fondateurs, c’est un signal : les plateformes de développement se réorganisent autour d’un nouvel utilisateur qui n’est pas humain. Les outils dans lesquels un agent est traité comme un client ordinaire soumis à des limites ordinaires deviendront bientôt des goulets d’étranglement.

Que faire concrètement

Premièrement, estimez combien de pushs par minute votre système agentique produit réellement. Pour la plupart des équipes, il s’agit de quelques unités ou dizaines, pas de milliers ; le record de GitHub ne vous concerne donc pas encore.

Deuxièmement, identifiez votre goulet d’étranglement actuel. Les causes fréquentes sont les conflits de fusion dans un même fichier, une CI lente déclenchée à chaque commit et les limites d’API. Le stockage est rarement le premier point de blocage.

Troisièmement, répartissez le travail des agents entre différentes branches et zones du code. Cinq mille agents modifiant le même fichier se noieront dans les conflits, quelle que soit la vitesse du serveur.

Quatrièmement, observez comment GitHub intégrera cette technologie à son produit, avec quels forfaits et quelles limites. Pour l’instant, il ne s’agit que d’une annonce concernant des essais internes.

Limites

Le test est interne et sa méthodologie n’a pas été publiée. Nous ne connaissons ni la taille du dépôt, ni la taille des pushs, ni la proportion de modifications conflictuelles, ni ce que signifie précisément une « faible latence » en millisecondes. Nous ignorons également quand et pour quels utilisateurs cette technologie sera disponible. La bonne réaction consiste donc à y voir un signal sur l’orientation du développement, sans intégrer ces chiffres à vos plans tant qu’aucune mesure indépendante n’est disponible.

La conclusion est simple. Avec les agents, Git passe d’un outil destiné aux humains à un système à forte charge. GitHub affirme s’y préparer. Les autres acteurs ont intérêt à réfléchir dès maintenant au comportement de leurs processus lorsque le nombre de pushs sera multiplié par cent.