L’ingénierie agente et le cycle externe : où s’inscrivent Antigravity et la CLI Agents.

La prochaine étape du développement de l’IA dépend moins de modèles plus puissants et davantage de systèmes d’ingénierie plus robustes. Lors de Sequoia Ascent 2026, Andrej Karpathy a décrit le passage du codage intuitif vers l’ingénierie agente. Dans cette approche, les humains élaborent les spécifications, les boucles d’évaluation et les contraintes, tandis que les agents s’occupent de parties définies de l’implémentation.

Cette évolution est importante car l’IA ne remplace pas la discipline de l’ingénierie logicielle. Elle amplifie plutôt toute discipline déjà en place. La recherche DORA de Google ainsi que les directives relatives aux plateformes vont dans le même sens : les organisations disposant de fondations ingénierie solides tirent plus de bénéfices des workflows assistés par l’IA que celles dont les processus sont fragiles et la vérification insuffisante. L’adoption des outils de développement basés sur l’IA est généralisée, mais la confiance ne l’est pas. Le facteur limitant n’est plus le modèle lui-même, mais plutôt le système qui l’entoure : les spécifications, les évaluations, le pipeline de déploiement et la couche de gouvernance. L’ingénierie agente est la pratique consistant à construire ce système.

Que signifie l’ingénierie agente

En bref, il s’agit d’une méthode structurée de développement assisté par l’IA dans laquelle les humains assurent l’architecture, la qualité et la correction, tandis que des agents s’occupent de tâches d’implémentation définies dans des limites précises. Karpathy a identifié trois piliers.

Les spécifications en premier. Avant que l’agent n’écrive le moindre code, l’ingénieur définit l’objectif, les contraintes et les critères de succès dans une spécification lisible par machine. Un contrat structuré entre l’humain et l’agent remplace un prompt vague.

Évaluation avant confiance. Un seul essai réussi ne dit rien sur la fiabilité. Les agents doivent être testés à l’aide de jeux de données d’évaluation structurés, évalués grâce à des métriques et des méthodes utilisant un LLM en tant que juge, afin que leurs performances soient reproductibles avant toute mise en œuvre.

Barrages de sécurité et environnements isolés. Un agent doit être placé dans un environnement sécurisé doté de permissions explicites, d’éléments d’intégration et de mécanismes de contrôle des politiques, afin que son exécution ne puisse pas se dérouler sans surveillance. Seulement 12 % des projets pilotes d’agents IA au niveau entreprise parviennent à être mis en production aujourd’hui, et les modèles ne sont pas principalement responsables. Les lacunes infrastructurelles résident dans l’absence d’environnements isolés, de détection des secrets et de mécanismes de contrôle des politiques.

Où en sont les outils de codage actuels

Toute évaluation honnête commence par reconnaître les points forts des outils de codage IA actuels, et ils sont impressionnants.

Ils excellent dans les tâches nécessitant une action répétée : ils divisent une tâche en étapes, modifient plusieurs fichiers, exécutent des commandes dans le terminal local et se corrigent eux-mêmes en cas d’erreurs de compilateur. Ils ont largement dépassé le simple générateur de code et l’autocomplétion.

Cependant, la boucle interne n’en représente que la moitié. Les équipes d’entreprise ne se demandent plus si un agent peut écrire et modifier du code, car en 2026 presque tous les outils majeurs le permettent. La question plus difficile concerne la boucle externe : comment une organisation évalue, déploie, surveille et gère les agents une fois qu’ils quittent le terminal local d’un développeur. C’est là que la discussion change de nature. La différence structurelle se présente comme suit :

Rien dans tout cela ne discrédite les autres outils. En tant que moteurs d’exécution de la boucle interne, ils restent parmi les meilleurs disponibles. Mais la génération de code n’est que le point de départ, et les outils conçus pour le terminal local d’un développeur ne sont pas nativement adaptés à la gestion de l’ensemble du cycle de vie de la boucle externe. Pour réussir en 2026, il ne suffit pas de créer des agents performants ; il faut également disposer d’une infrastructure permettant de les évaluer, de les déployer et de les gérer en environnement de production.

Les agents CLI comme point d’entrée

La stratégie de Google repose sur une seule décision de conception. Agents CLI est conçu pour fonctionner en parallèle avec n’importe quel assistant de codage, et c’est là une force de son architecture plutôt qu’une faiblesse. Lors de l’installation, il ajoute sept compétences fondamentales basées sur le Agent Development Kit (ADK), couvrant la création de structures de base, l’évaluation, le scoring par des LLM en tant que juges, la configuration en temps de exécution, le déploiement via Cloud Run et l’observabilité grâce à Cloud Trace. Un utilisateur de Claude Code ou de Cursor peut exécuter agents-cli scaffold, agents-cli eval et agents-cli deploy avec à peu près la même facilité qu’un utilisateur d’Antigravity.

C’est intentionnel. Google ne concurrence pas au niveau de la génération de code. Il mise sur le fait que la valeur de l’ingénierie agente se déplace du frontend, où le code est écrit, vers le backend, où les agents sont exécutés, surveillés et gérés. Et quel que soit le frontend choisi par un développeur, les commandes CLI mènent au même endroit :

• agents-cli déploie des cibles Cloud Run, GKE ou Agent Engine, qui appartiennent toutes à GCP.
• agents-cli envoie des données de télémétrie à Cloud Trace et BigQuery, toujours via GCP.
• agents-cli enregistre les agents dans le Agent Registry, également sur GCP.
• La couche de gouvernance, avec Model Armor, Agent Identity et des mécanismes de contrôle, fonctionne également sur GCP.

La CLI constitue donc l’entrée, et GCP est la destination finale. Chaque assistant de codage qui l’adopte devient un client GCP pour le cycle de vie en production. C’est pourquoi l’affirmation « il fonctionne aussi avec Cursor » soutient cette stratégie plutôt que de la nuire : Google n’a pas besoin que quiconque change d’éditeur, seulement que la production soit exécutée sur GCP, et la CLI rend ce processus le plus simple possible pour chaque outil.

Trois couches concentriques

L’écosystème Google est organisé en trois couches imbriquées. Chacune ajoute des fonctionnalités, sans exiger l’abandon des outils existants.

La couche la plus intérieure est Agents CLI, compatible avec Cursor, Claude Code, Codex, Copilot, Antigravity ou tout autre outil prenant en charge l’injection de compétences. Il offre une méthode standard pour structurer un projet (agents-cli scaffold), une évaluation structurée réalisée par un juge basé sur un LLM (agents-cli eval), un déploiement sur Cloud Run ou GKE à l’aide d’une seule commande (agents-cli deploy) ainsi qu’une configuration automatique de l’observabilité via Cloud Trace (agents-cli observe). Il manque cependant une orchestration multi-agents, un mécanisme d’ingénierie de contexte persistant et des boucles de vérification intégrées. L’argument présenté aux utilisateurs est de conserver leur éditeur préféré, d’obtenir une méthode reproductible pour passer du prototype à la production, et d’accepter que le fonctionnement en production se fasse sur GCP.

La couche cloud est requise par tout outil utilisant Agents CLI, car c’est là que les agents s’exécutent réellement. Elle se compose de :

• Cloud Run, GKE et la plateforme d’agents pour un hébergement géré scalable
• Cloud Trace, permettant le suivi complet du chemin d’exécution avec des données telemétriques conformes à OTel
• BigQuery Agent Analytics, pour des tableaux de bord couvrant l’ensemble des agents déployés
• Agent Registry, un catalogue centralisé pour la gestion, la versionning et le partage des agents
• Model Armor, qui empêche les fuites de données et filtre le contenu dangereux
• Agent Identity, avec des identifiants cryptographiques liés à des identités humaines vérifiables ou à des principaux de service
• Le protocole Agent2Agent (A2A), permettant la communication entre les agents lors de la coordination d’une flotte

La raison en est que les assistants de codage autonomes dépendent généralement d’une infrastructure cloud externe pour le déploiement en production, l’observabilité et la gouvernance, et ne proposent pas un environnement d’exécution intégré pour les entreprises. Il s’agit d’un aspect structurel et non concurrentiel. Claude Code ne concurrence pas Cloud Run, car les deux opèrent à des niveaux différents.

Qu’ajoute Antigravity

Si tout le monde dispose de sous-agents et de fichiers contextuels, qu’est-ce qui distingue Antigravity ? La réponse ne réside pas dans une seule fonctionnalité : il s’agit d’une intégration verticale avec la couche de production.

Les sous-agents de Claude Code fonctionnent à l’intérieur du terminal : ils écrivent du code, exécutent des tests et génèrent des résultats. Le déploiement de ce code, sa surveillance en temps réel, la gestion d’une flotte d’agents ainsi que la coordination entre ces agents au sein de différents services incombent au utilisateur, car Claude Code ne connaît rien des instances Cloud Run, du pipeline d’observabilité ni des politiques de gouvernance en vigueur. Il s’agit d’un outil de développement. Les sous-agents d’Antigravity peuvent faire davantage :

• Déployer directement sur Cloud Run, GKE ou la plateforme d’agents via Agents CLI, car ce CLI est fourni par le fabricant et non un plugin tiers.
• Interroger les données de telemétrie Cloud Trace pendant le débogage, puisque Antigravity peut lire les données d’observabilité de GCP.
• Enregistrer les agents terminés dans le Agent Registry, car la publication fait partie intégrante du flux de travail.
• Coordonner avec les agents déployés via le protocole A2A, étant donné que la couche de communication fait partie du même écosystème.

Les sous-agents de Claude Code sont des outils de développement performants, tandis que ceux d’Antigravity sont des outils de développement conscients de l’environnement de production, car ils partagent un même ensemble de technologies fournies par le même éditeur. Quatre fonctionnalités sont avancées comme étant inégalées par d’autres outils actuellement :

1. Continuité multi-surface : un contexte d’agent couvre l’IDE de bureau, la ligne de commande, le SDK pour une utilisation programmée ainsi que l’API gérée. Un flux de travail peut commencer dans l’IDE, se poursuivre dans la terminal et être déclenché depuis CI/CD. Claude Code est principalement utilisé dans la terminal, tandis que Cursor se concentre sur l’IDE.
2. Intégration de la CLI avec les agents propriétaires : les fonctions scaffold, eval, deploy et observe ont été conçues en collaboration avec Antigravity, de sorte que l’agent connaît nativement la CLI et peut enchaîner des commandes tout au long du cycle de vie sans avoir recours à des techniques d’ingénierie de prompts.

Contexte conscient du GCP. Les agents peuvent intégrer des données Cloud Trace, des entrées du Agent Registry ainsi que des métadonnées de déploiement dans leur contexte de travail, permettant ainsi à un agent chargé de résoudre un problème en production de lire des données de télémétrie, d’examiner la configuration de l’agent déployé et de proposer des correctifs au cours d’une seule session.

Découvrabilité d’entreprise. De nombreux agents personnalisés restent isolés derrière des URL d’endpoint privés, accessibles uniquement par leurs créateurs et nécessitant des identifiants partagés manuellement. Un pipeline de publication natif résout ce problème : en indiquant à la CLI d’enregistrer un agent auprès de Gemini Enterprise, l’instruction agents-cli publish est exécutée, et l’agent apparaît alors comme un outil sécurisé et découvrable au sein de l’application Gemini Enterprise dans toute l’organisation. L’IAM natif gère les accès, permettant aux équipes de l’utiliser sans devoir mettre en place leur propre infrastructure.

Comparaison des écosystèmes

Afin de rendre cette comparaison concrète, le tableau suivant indique où les outils sont équivalents et où ils diffèrent.

Dans la première moitié de cette comparaison, les trois écosystèmes convergent sur le plan architectural, offrant une bonne génération de code, une orchestration parallèle des sous-agents ainsi que des environnements cloud gérés pour les tâches à long terme. Dans la seconde moitié, c’est là que Google prétend apporter une valeur d’entreprise supplémentaire. Les plateformes concurrentes transfèrent le code, les données et les identifiants vers des environnements de exécution propriétaires de tiers, tandis que Google permet à une organisation d’exécuter, d’identifier, d’authentifier, de gérer et de surveiller les agents au sein de son propre périmètre Google Cloud grâce à Agent Runtime, Agent Identity, Model Armor et Agent Registry. Cette séparation se reflète en production : des données de telemétrie natives de GCP, un outil d’implémentation unifié pour quatre niveaux d’accès, ainsi que des mécanismes de gouvernance préinstallés pour les modèles.

En somme, les capacités locales de boucle interne se rapprochent progressivement, tandis que c’est au niveau de la couche d’infrastructure que l’intégration verticale crée un écart.

Comment décider

Le cadre de décision pour les dirigeants et les ingénieurs est simple. Une équipe dont l’objectif principal est d’accélérer la boucle interne devrait conserver ses outils actuels. Claude Code, Cursor et Copilot sont excellents et s’améliorent constamment chaque mois. On peut ajouter Agents CLI pour ses fonctionnalités liées au cycle de vie, avec un déploiement sur GCP une fois que l’équipe est prête.

Une organisation qui passe d’un codage assisté par l’IA à des workflows gérés par des agents a des besoins différents. La gestion de flotte, la qualité assurée par des évaluations, la gouvernance dans les secteurs réglementés ainsi que la coordination entre plusieurs agents exigent une architecture différente, et Google fait partie des rares fournisseurs offrant un ensemble intégré de manière verticale, allant des agents de codage à l’évaluation, au déploiement, à l’observabilité et à la gouvernance.

Le cas ne dépend pas de la supériorité des modèles, puisque ceux-ci convergent. Il dépend plutôt de l’intégration des infrastructures : la distance entre l’écriture de code pour des agents et le fonctionnement de flottes d’agents gérés en production. Google a réduit cette distance plus que quiconque, quel que soit l’éditeur utilisé par une équipe.