Les agents codent plus vite. Quid de l'intégration?
Épisode 1 sur 3 : comprendre ce qui ralentit la livraison
Un agent propose une correction. Un autre ajoute des tests. Un troisième adapte un appel d’API. Le code arrive vite, mais quelqu’un doit encore vérifier que ces changements fonctionnent ensemble et peuvent être livrés.
Deux observations donnent une idée des volumes en jeu. Dans son rapport Octoverse 2025, GitHub rapporte une moyenne de 43,2 millions de pull requests fusionnées par mois, soit 23 % de plus sur un an. La plateforme accueille aussi davantage de développeurs. Ces chiffres montrent une hausse de l’activité, sans isoler la part liée à l’IA.
Chez Anthropic, l’échelle est différente : l’entreprise indique être passée d’environ 2 500 à plus de 30 000 changements intégrés par jour entre mai et septembre 2026. Son retour d’expérience sur Scion, publié en octobre 2026, décrit comment elle a repensé sa gestion de versions pour absorber ce volume.
Ce cas interne ne représente pas le quotidien de toutes les équipes, mais il m'a poussé à m'interroger sur les limites de nos outils: que se passe-t-il lorsque les propositions de code arrivent plus vite que l’équipe ne peut les traiter ?
La gestion de versions n'a pas attendu Git
Le source control, ou gestion de versions, permet de suivre les modifications des fichiers, de retrouver leurs versions précédentes et de combiner les contributions. Il existait bien avant Git : cet historique d’Eric Sink (en anglais) présente notamment SCCS, RCS, CVS et Subversion, ainsi que l’évolution des modèles de collaboration.
Créé en 2005 par Linus Torvalds, Git a été conçu pour permettre aux développeurs de travailler de manière distribuée. Chaque dépôt local peut contenir l’historique complet, et de nombreuses opérations se font sans connexion au serveur.
Ce modèle permet de travailler à plusieurs, de préparer des changements séparément, puis de les rapprocher. Les agents utilisent ces mêmes possibilités. En revanche, leur multiplication peut rendre certains coûts plus visibles : préparer un environnement, relire une proposition ou réconcilier deux modifications prend toujours du temps.
Quatre points de friction
Les propositions attendent leur tour
Des agents proposent vingt corrections dans la matinée. Les relecteurs et la chaîne d’intégration continue, ou CI, ne peuvent en traiter que quelques-unes. Les propositions restantes attendent.
La revue et les tests donnent le rythme de l’intégration.
Le nombre de modifications produites augmente, mais pas nécessairement le nombre de modifications livrées. Pour comprendre ce décalage, il faut regarder le temps passé à attendre une revue ou un résultat de test, en plus du temps de rédaction du code.
Les changements se croisent
Un agent ajoute un paramètre à une API pendant qu’un autre réorganise cette même API. Leurs propositions peuvent fonctionner séparément et devenir incompatibles une fois réunies.
Certains conflits apparaissent pendant la fusion des fichiers. D’autres concernent le comportement du programme et passent inaperçus à cette étape. Une fusion sans conflit textuel ne dispense donc pas de tester le résultat commun.
Des tests réussis séparément ne suffisent pas à valider l’ensemble.
La préparation des environnements prend du temps
Dix agents éphémères clonent chacun un monorepo, un dépôt regroupant plusieurs projets ou services. Chacun ne doit pourtant corriger que quelques lignes dans un seul service.
Le téléchargement et la préparation des fichiers peuvent alors coûter plus cher que la correction. Réduire les fichiers récupérés est une piste, à condition de garder les dépendances nécessaires à la compilation et aux tests. Un démarrage rapide perd de son intérêt si le premier build doit ensuite télécharger tout ce qui manque.
Il faut retrouver ce qui a été validé
Après plusieurs corrections automatiques d’un algorithme de tri, le relecteur doit retrouver le comportement attendu et vérifier que les tests correspondent à la dernière version proposée.
Suivre l’identité d’une correction aide à comprendre son parcours. Pour décider de l’intégrer, il faut aussi savoir quelle version exacte a été testée. Une nouvelle révision ou un rebase peut modifier le code sur lequel portait la validation précédente.
Une validation doit rester associée à la version exacte qui a été testée.
Comme avant l’IA, produire du code plus vite ne garantit pas de livrer plus vite si la chaîne de développement n’évolue pas en conséquence.
Trois familles de réponses
L’expression « alternatives à Git » rassemble des outils qui ne traitent pas tous le même problème.
| Question | Approches à examiner |
|---|---|
| Comment réorganiser et suivre les changements ? | Jujutsu, client Sapling |
| Comment servir efficacement un très grand dépôt ? | Mononoke, EdenFS, Scion |
| Comment réduire le coût de Git sans changer son modèle ? | Scalar, partial clone, sparse checkout |
Ces approches peuvent se compléter. Un outil qui facilite les rebases ne réduit pas forcément le temps de téléchargement du dépôt. Une copie de travail virtuelle peut accélérer la préparation des fichiers, mais elle ne vérifie pas que deux changements d’API sont compatibles.
Les projets contenant beaucoup de textures, de modèles 3D ou de fichiers audio ajoutent une autre contrainte : certains fichiers se fusionnent difficilement. Des outils comme Perforce P4 et Unity Version Control proposent des workflows adaptés à ces ressources. Nous les retrouverons dans le troisième épisode.
Commencer par une mesure utile
Quand les agents produisent davantage de code, la revue, les tests et l’intégration peuvent devenir les étapes les plus lentes. La première étape consiste donc à identifier celle qui freine réellement l’équipe. Les outils deviennent plus faciles à comparer une fois cette question posée.
Dans le deuxième épisode, consacré à Jujutsu et Sapling, nous examinerons comment retravailler des propositions sans perdre leur fil. Le troisième épisode portera sur le coût des grands dépôts et des environnements.
Top comments (0)