Git fonctionne très bien pour des développeurs humains. Mais lorsque des agents IA créent en continu des lectures, écritures, checkpoints, tests et merges, le profil de charge change. GitHub et GitLab commencent désormais à adapter leur infrastructure à cette nouvelle réalité.
Pourquoi les agents changent la charge sur Git
Un développeur humain ne produit généralement pas un commit après chaque petite étape. Un agent peut au contraire lire quelques fichiers, modifier du code, créer un checkpoint, lancer des tests puis recommencer quelques secondes plus tard.
GitHub explique que ce développement à l’échelle des agents augmente fortement les écritures concurrentes, les lectures automatisées et les merges. En septembre 2026, GitHub indique avoir traité 7,38 milliards de commits, plus de cinq fois le volume observé un an auparavant. Le nombre mensuel d’événements Git serait passé d’environ 218 à 473 milliards entre septembre 2025 et août 2026.
Les écritures sont plus difficiles à distribuer que les lectures
Servir un fichier ou un clone peut être accéléré avec du cache et des réplicas. Une écriture doit être enregistrée durablement puis devenir visible de façon cohérente pour les autres agents, la CI et les développeurs.
Ce sont notamment ces écritures concurrentes qui deviennent difficiles à absorber lorsque de nombreux agents travaillent simultanément.
Les merges convergent vers le même endroit
Une centaine d’agents peut produire une centaine de branches indépendantes. Mais lorsqu’elles doivent rejoindre main, les opérations convergent vers la même référence.
GitHub indique que le nombre de merges de pull requests a presque quadruplé en un an. Les merge queues et les stratégies de validation prennent donc davantage d’importance.
Chaque modification déclenche une cascade
Un push peut déclencher des tests, builds, analyses de sécurité, indexations, notifications et parfois de nouveaux agents. GitHub indique que GitHub Actions a exécuté 3,26 milliards de jobs en septembre 2026.
Avec des agents qui effectuent de petites modifications fréquentes, la capacité à sélectionner précisément les validations nécessaires devient essentielle pour éviter de multiplier inutilement les coûts de CI.
GitLab arrive au même constat par un autre chemin
GitLab travaille également sur une nouvelle génération de gestion du code source conçue pour les agents. Son constat porte notamment sur le coût des clones : un agent éphémère n’a pas toujours besoin de récupérer l’intégralité d’un dépôt simplement pour consulter quelques fichiers ou modifier quelques lignes.
GitLab expérimente donc davantage d’opérations côté serveur afin que les agents puissent demander précisément les données nécessaires sans reconstruire tout le contexte localement.
Le changement de fond
Git reste le modèle de versionnement. C’est la manière dont les agents interagissent avec Git qui commence à évoluer.
Moins de clones, plus d’interfaces spécialisées
Pour un humain, disposer d’une copie complète et distribuée du dépôt reste extrêmement puissant. Pour un agent chargé d’une tâche courte, une interface ciblée peut réduire le trafic réseau, le temps de démarrage et le contexte chargé.
On pourrait progressivement passer de agent → Git directement à agent → service SCM / API → Git.
L’identité et la traçabilité deviennent centrales
Un changement peut désormais être produit à la demande d’un utilisateur, par un agent, un sous-agent ou un workflow CI, avec un modèle et des permissions spécifiques.
La question ne sera donc plus seulement « qui a fait ce commit ? », mais aussi : quel agent, quelle tâche, quel modèle, quelles permissions et quelle demande initiale ?
Ce que cela change pour les équipes
- Branches plus éphémères : création et nettoyage doivent rester rapides.
- Merge queues : elles deviennent importantes lorsque de nombreux changements convergent vers la branche principale.
- CI plus sélective : relancer toute la suite après chaque micro-modification peut devenir très coûteux.
- Traçabilité renforcée : l’identité technique d’un workflow ne suffit plus toujours à expliquer l’origine d’un changement.
Ce que cela suggère pour TechAtelier
Le signal intéressant dépasse Git : des outils conçus pour une activité humaine commencent à être adaptés à une activité machine beaucoup plus rapide et parallèle.
Le même phénomène peut concerner les pipelines CI/CD, les API, les systèmes d’alertes, la supervision, les quotas, les politiques de sécurité et les journaux d’audit.
Une architecture parfaitement adaptée à quelques utilisateurs humains peut se comporter très différemment lorsque des agents réalisent automatiquement des centaines d’opérations.
Ce qu’il faut retenir
Git n’est pas devenu obsolète. Le profil d’utilisation change.
GitHub reconstruit une partie de son infrastructure Git pour absorber cette nouvelle charge, tandis que GitLab développe un backend SCM davantage orienté requêtes serveur et traçabilité des agents.
Lorsque plusieurs plateformes majeures commencent à modifier leur architecture autour du même phénomène, ce n’est plus seulement une fonctionnalité IA supplémentaire : le développement logiciel lui-même commence à changer d’échelle.
Sources
- GitHub — Building Git infrastructure for agent-scale development
- GitLab — Next-generation source code management for agents
Publié le 7 octobre 2026. Les chiffres et fonctionnalités correspondent aux informations publiées par GitHub et GitLab à cette date.