L’intégration continue (CI) est devenue un nouveau goulot d’étranglement avec l’essor de l’utilisation des agents de programmation. Cette conclusion repose sur des expériences présentées par des équipes d’ingénierie d’Anthropic, de Linear et de Depot au cours du mois de septembre, et non sur l’annonce d’un outil unique. Le volume des tâches de CI chez Anthropic a été multiplié par 25 en six mois, tandis que ses ingénieurs livrent désormais, par trimestre, environ huit fois plus de code qu’ils n’en livraient entre 2021 et 2025. Chez Linear, le volume de la suite de tests a presque quadruplé depuis janvier, tandis que les agents écrivent désormais la plupart des tests.
Anthropic a réagi en utilisant l’analyse d’impact des tests pour exécuter uniquement les tests susceptibles d’être affectés par la modification, et Linear a presque entièrement repensé son pipeline. Ces mesures réduisent le temps d’attente, mais elles ne traitent qu’un niveau du problème : la vitesse de vérification du dépôt.
Pourquoi la vitesse de la CI ne suffit-elle plus ?
La CI a historiquement été conçue selon un mode de travail humain : le développeur ouvre un nombre limité de demandes de fusion chaque semaine, puis attend le résultat du pipeline tout en passant à une autre tâche. L’agent, lui, peut créer le code, les tests et les demandes de fusion en parallèle, ce qui augmente de manière exponentielle le nombre d’opérations de CI. L’article indique que Blacksmith, une entreprise qui vend des exécuteurs de CI, a observé une croissance hebdomadaire comprise entre 5 % et 10 % du nombre de tâches qu’elle exécute.
Le deuxième problème concerne le moment de la validation. L’agent écrit la modification, puis attend le résultat après la création de la demande de fusion. Lorsque le résultat arrive au bout de 20 minutes, il a peut-être perdu le contexte de la tâche, tandis que chaque problème implique un nouveau cycle d’attente.
Le dépôt n’est pas le système
Dans les applications autonomes, les tests du dépôt peuvent donner une image proche du comportement du système. Mais dans un environnement cloud natif, le dépôt représente un seul service au sein d’un ensemble pouvant comprendre des dizaines de services, tandis que le reste du système est souvent représenté par des interfaces simulées ou des données de test.
Une modification peut donc réussir les tests unitaires, passer la CI et fonctionner dans un environnement isolé, puis échouer à la première véritable requête qui franchit les frontières entre services. Il peut s’agir, par exemple, de modifier le nom d’un champ dont dépend un autre service, de réduire un délai d’attente et de provoquer une série de nouvelles tentatives, de modifier un schéma et de verrouiller une table dans l’environnement de test, ou encore de créer un point de terminaison qui se comporte différemment lorsqu’il est effectivement appelé par le service consommateur.
L’article cite les données de DevOps Research and Assessment (DORA), qui associent l’adoption accrue de l’intelligence artificielle à une augmentation de la fréquence de livraison des logiciels ainsi qu’à une hausse des perturbations dans la livraison. Autrement dit, produire du code plus rapidement ne garantit pas une meilleure validation.
Qu’est-ce qui change concrètement ?
La solution proposée n’est ni de supprimer la CI ni de ralentir les agents, mais de déplacer une partie de la validation plus tôt dans la boucle de travail de l’agent, afin que la modification soit testée contre le système réel et non contre le seul dépôt. Des outils comme Cursor utilisent des environnements cloud isolés ; plus de 30 % des demandes de fusion intégrées par Cursor proviennent d’agents qui fonctionnent de cette manière. D’autres outils, notamment GitHub Copilot cloud agent, Codex, Devin et Greptile, proposent différentes formes d’exécution du code dans des environnements temporaires.
Mais ces environnements contiennent généralement la branche, sa configuration et ce que le script d’initialisation peut installer, et non les autres services, la véritable liste des messages et une base de données ressemblant aux données de production. L’article estime donc que la boucle est fermée, mais qu’elle peut être fermée autour du mauvais élément.
Environnements partagés et validation contrôlée
L’article propose d’exécuter une version stable et partagée des services au sein d’un cluster Kubernetes, tout en créant des environnements de test légers qui ne déploient que le service modifié. Les requêtes marquées sont dirigées vers ce service, tandis que les autres flux se connectent aux versions stables partagées. Ainsi, un grand nombre d’agents peuvent partager l’environnement au lieu de cloner l’intégralité du système pour chaque agent ; l’article estime que le coût de l’environnement pourrait être proche de celui d’un seul conteneur et que son démarrage prendrait quelques secondes, mais la source ne fournit pas de mesures indépendantes confirmant ces estimations dans tous les environnements.
L’environnement seul ne suffit pas. Les équipes chargées de la plateforme ont besoin de procédures approuvées définissant les requêtes à envoyer, les journaux à collecter et les contrats à démontrer. Il convient également d’enregistrer les services touchés par le test et ses résultats, afin que le dossier puisse être lu par les outils de revue et les passerelles de fusion. L’auteur souligne que la gouvernance est nécessaire pour empêcher les agents d’exécuter des opérations dangereuses au sein d’un cluster partagé.
Du point de vue de certi.news, le véritable changement ne consiste pas simplement à accélérer la CI, mais à redéfinir ce que doit signifier la « réussite » de la validation. Les tests du dépôt restent importants, mais ils ne suffisent pas à eux seuls pour les systèmes distribués que les agents produisent plus rapidement. Les questions du coût, de l’isolation, de la sécurité des données et de la mesure de la précision de la validation restent ouvertes, et le document présente une thèse analytique plutôt qu’une norme éprouvée ou un produit particulier.