Les agents de code ne changent pas seulement l'éditeur. Ils changent le volume qu'un hébergeur de code doit absorber. Un agent qui ouvre des branches, propose des modifications et relance un changement en échec peut produire de l'activité bien plus vite qu'une équipe qui tape. GitHub reconstruit le stockage sous Git pour que cette croissance ne casse pas le flux que les développeurs connaissent déjà.
Pour une équipe logicielle britannique, le titre est facile à laisser passer. L'architecture de stockage semble être le problème de GitHub. Elle devient celui de l'équipe quand les envois ralentissent, quand l'intégration continue attend derrière une vague de commits automatiques, ou quand les demandes d'un agent arrivent plus vite qu'on ne peut les relire. Un stockage plus rapide ne relit pas le code.
L'échelle décrite par The Register
The Register a rapporté le 9 octobre 2026 que GitHub réécrit son stockage pour faire face à ce qu'il appelle une demande agentique, et que les essais internes de GitHub ont montré jusqu'à 35 fois plus de performance en écriture avec le nouveau système. Le même article chiffre le trafic. Entre septembre 2025 et août 2026, les événements GitHub sont passés de 218,2 milliards par mois à 473,3 milliards. Le média rapporte aussi 7,38 milliards de commits en septembre 2026, cinq fois le chiffre de septembre 2025.
Ces nombres décrivent la plateforme GitHub, pas un dépôt d'entreprise typique. Ils expliquent quand même la refonte. Plus les agents créent des branches, soumettent des changements et lancent des flux de développement automatisés, plus l'hébergeur doit servir de lectures et d'écritures en même temps. Le récit de la réécriture du stockage et celui de la reconstruction de l'infrastructure disent la même chose : l'ancien dessin est remplacé parce que l'activité à l'échelle des agents l'a mis à nu.
Ce qui change dans le dessin
The Register décrit l'ancien stockage de GitHub comme appuyé sur plusieurs répliques de dépôt et un quorum pour confirmer chaque écriture. Dans le nouveau dessin, les écritures vont dans Azure Blob Storage, qui gère la réplication, tandis que les lectures sont servies à part. La maintenance, comme le compactage et le ramassage des déchets, passe en tâche de fond. Le but est de retirer ces goulots du chemin d'un envoi ordinaire, sans demander aux développeurs d'apprendre un autre usage de GitHub.
Cette séparation compte. Le trafic d'écriture des agents et le trafic de lecture des humains partageaient un dessin fait pour un autre mélange. Déplacer la réplication vers le stockage d'objets, et la maintenance hors du chemin critique, est une réponse d'infrastructure à un problème de charge. Cela ne change pas ce qu'un commit signifie, et cela ne décide pas si un changement peut être fusionné. Les équipes doivent prendre le chiffre de performance comme un résultat d'essai de GitHub, et continuer à surveiller leurs propres pipelines. Un facteur 35 dans un essai interne ne promet pas que chaque monodépôt semblera 35 fois plus rapide un mardi après-midi.
Ce que les équipes logicielles doivent encore faire
Un stockage plus rapide aide les grandes équipes et les pipelines d'intégration continue chargés à absorber plus d'activité. C'est une partie du travail avec des agents de code. Le reste ne change pas, et il devient plus important quand les changements arrivent en volume.
- Une personne relit encore ce qu'un agent propose, surtout sur le code qui touche l'argent, les données personnelles ou le contrôle d'accès.
- Les tests automatisés doivent faire échouer la construction quand le changement est faux, parce que personne ne peut lire chaque ligne d'une semaine chargée.
- Les agents ont besoin de leurs propres droits. Un jeton qui peut pousser vers chaque dépôt est un incident qui attend une mauvaise instruction.
- Les mises en production restent délibérées. Produire un changement vite n'est pas une raison de le déployer vite.
Les équipes britanniques connaissent déjà ce schéma avec des contributeurs humains très actifs. Les agents le compriment. Un dépôt qui acceptait dix demandes par jour peut en voir bien plus une fois qu'un agent est pointé vers le backlog. Règles de revue, contrôles obligatoires et protection de branche sont ce qui empêche ce volume de devenir du code de production non relu. Node.js 26 est un autre changement d'exécution la même année, et il rappelle que les mises à niveau de plateforme et d'outils arrivent ensemble. Aucun des deux ne remplace un essai en préproduction.
La demande dépasse l'éditeur
La leçon plus large est que l'adoption de l'IA n'est pas seulement un choix d'outil de code. Elle change la demande sur le contrôle de source, les systèmes de build, les environnements de test et la capacité cloud. Un agent qui lance une suite à chaque branche dépense de l'argent et du temps de file même quand la couche de stockage va bien. Les responsables d'ingénierie devraient demander si leur plateforme de développement tient plus de concurrence tout en restant fiable, et si la facture cloud et le tour de revue tiennent aussi. Les dépenses d'infrastructure IA racontent la même histoire un niveau plus bas : le modèle est la partie visible, et les systèmes dessous doivent grandir avec lui.
La sécurité est dans cette liste. Un agent avec un jeton GitHub est une identité. Des droits excessifs, un secret laissé dans un dépôt, ou un flux qui déploie depuis une branche non relue sont des échecs connus. Ils deviennent moins chers à déclencher quand l'agent peut ouvrir la demande lui-même. Le contrôle d'accès fait partie de la plateforme de développement, pas d'un durcissement plus tard.
Prévoir la plateforme avec l'outil de code
La reconstruction de GitHub montre que les hébergeurs de code traitent le trafic des agents comme la nouvelle normale. Les équipes britanniques peuvent laisser le travail de performance à GitHub, et garder la revue, les tests et les droits. Le développement logiciel qui inclut des agents a encore besoin d'un pipeline de confiance. L'hébergement cloud doit avoir la place pour les builds supplémentaires que ces agents lanceront.
Web Works Rise est une équipe menée depuis le Royaume-Uni, à Birmingham, avec un hub en Tunisie qui ajoute de la capacité de livraison. La pile des projets clients comprend Next.js, React et TypeScript, avec les contrôles qui empêchent un changement de sauter la revue. Si un agent doit rejoindre ce pipeline, parlez à l'équipe de l'endroit où il peut committer, de ce qui doit passer avant fusion, et de qui répond du résultat.