Créer un agent IA complet sans coder : notre test du nouvel outil de Google
Et s’il était possible de développer un agent IA entièrement automatisé, grâce… à un agent IA ? C’est l’idée très méta de Google, qui vient de dévoiler agents-cli. Une interface complète en no-code qui permet de développer de A à Z son agent en utilisant la stack Google Cloud. Le projet, disponible en open source, gère l’ensemble du workflow d’un agent : de sa création à son évaluation en passant par le monitoring. Nous avons déployé un agent from scratch en utilisant la plateforme. Retour d’expérience.
Une interface CLI, deux usages possibles
Agents-cli prend la forme d’un assistant en ligne de commande capable de guider la création d’un agent IA étape par étape. L’utilisateur part d’un projet vierge, décrit le type d’agent qu’il souhaite construire, puis l’outil génère la structure nécessaire. Fichiers de configuration, logique de l’agent, dépendances, instructions système, outils connectés et premiers scénarios d’évaluation : chaque brique est développée par l’agent lui-même. La plateforme s’appuie principalement sur l’Agent Development Kit (ADK), le framework de Google pour concevoir des agents. Dans les faits, l’agent créé est un agent ADK. Il peut recevoir une instruction, appeler des outils, interroger des API, enchaîner plusieurs étapes de raisonnement et, si nécessaire, être intégré dans une architecture multi-agents. Agents-cli peut ensuite créer des benchmarks, lancer des tests, comparer plusieurs versions, préparer l’infrastructure, puis déployer l’agent sur Google Cloud.
A ce stade, les principales limites tiennent à l’absence de prise en charge de la voix et de la vidéo en temps réel, au déploiement encore centré sur l’écosystème Google Cloud, ainsi qu’à une compatibilité limitée avec les langages de script autres que Python. Il ne sera pas possible, par exemple, de créer un agent de service client vocal. C’est dommage, d’autant que xAI arrive avec un outil tout-en-un optimisé spécifiquement sur cette tâche (test à venir sur le JDN).
Agents-cli peut s’utiliser de deux manières : soit en utilisant l’outil depuis le terminal, en lançant soi-même les différentes commandes, soit en utilisant un agent de code (Codex, Claude Code, OpenCode, Antigravity…). Dans ce cas, l’utilisateur formule simplement son cas d’usage en langage naturel, et c’est l’agent de code qui exécute les commandes agents-cli à sa place, corrige les erreurs, relance les tests et ajuste le projet jusqu’à obtenir un agent fonctionnel. Nous vous conseillons cette dernière approche, beaucoup plus naturelle et simple d’usage.
Le test du JDN
Pour ce test, nous allons créer un agent de service public, accessible sur le site d’une mairie pour répondre aux besoins des usagers. Nous avons créé un site pour la ville fictive de Brigon-les-Bains avec plusieurs contenus froids. Le but est de développer un agent capable non seulement de répondre à partir des données du site, mais aussi de guider l’usager dans une démarche complète. L’agent doit pouvoir, par exemple, autoriser la prise de rendez-vous en ligne, le signalement de problème sur la voirie, etc. Tous les problèmes qu’une mairie traite au quotidien.
Pour ce test, nous utiliserons assez naturellement Antigravity, l’agent de code de Google, couplé à agents-cli. Nous commençons par installer l’outil de Google avec la commande :
npx skills add google/agents-cli
L’outil ajoute en réalité sept skills spécialisés : scaffold pour créer la structure du projet, adk-code pour développer la logique de l’agent, eval pour tester et comparer ses réponses, deploy pour préparer le déploiement, observability pour configurer le monitoring, publish pour le rendre disponible dans l’écosystème Google, et workflow pour orchestrer l’ensemble du cycle de développement. Il est possible de ne sélectionner que ce que vous souhaitez utiliser.
Nous lançons ensuite Antigravity dans le dossier contenant le site de notre mairie fictive. Nous allons lui donner un seul prompt, long et descriptif, pour lui indiquer les capacités attendues de l’agent. Celui-ci devrait ensuite se débrouiller seul en utilisant les skills agents-cli pour interroger, configurer et mettre en place les briques ADK.
Prompt envoyé à Antigravity :
Tu es un agent de code senior. Ta mission est de créer, avec agents-cli et l’Agent Development Kit de Google, un agent IA de service public pour le site fictif de la mairie de Brigon-les-Bains. Objectif général : développer un agent conversationnel intégré directement au site de la mairie. L’agent doit répondre aux questions des habitants à partir des contenus déjà présents sur le site, mais aussi permettre d’accompagner l’usager dans les principales démarches municipales, sans se limiter à un simple chatbot RAG. Analyse d’abord le projet existant dans ce dossier : structure du site, pages disponibles, contenus froids, technologies utilisées, scripts, dépendances et contraintes de build. Ne supprime rien d’existant sans raison. Ajoute uniquement les fichiers et composants nécessaires. L’agent doit remplir les fonctions suivantes : 1. Répondre aux questions des habitants à partir des contenus du site * Indexer les pages et documents du site de la mairie. * Utiliser ces contenus comme base documentaire pour répondre aux questions. * Citer ou mentionner la source utilisée quand c’est pertinent : page, rubrique ou document. * Refuser d’inventer une information absente du site. * Reformuler clairement les réponses administratives dans un langage simple. 2. Orienter l’usager vers la bonne démarche L’agent doit être capable d’identifier automatiquement le type de demande : * état civil ; * inscription scolaire ou périscolaire ; * prise de rendez-vous avec un service municipal ; * réservation de salle ou d’équipement public ; * signalement de problème de voirie ; * stationnement ; * propreté ; * urbanisme ; * vie associative ; * demande d’information générale. 3. Guider l’usager dans une démarche complète Pour chaque démarche, l’agent doit poser les questions nécessaires, collecter les informations manquantes, vérifier que la demande est complète, puis produire une synthèse structurée. Exemples : * Pour une prise de rendez-vous : service concerné, motif, nom, coordonnées, créneau souhaité, pièces à apporter. * Pour une réservation de salle : date, horaire, nombre de personnes, type d’événement, salle souhaitée, besoins particuliers. * Pour une inscription scolaire : enfant concerné, niveau, adresse, responsables légaux, pièces justificatives. * Pour une demande d’état civil : type d’acte demandé, identité concernée, lien avec la personne, mode de retrait souhaité. * Pour un signalement de voirie : adresse précise, type de problème, niveau d’urgence, description, présence d’un danger immédiat, photo éventuelle si le site le permet. 4. Permettre le signalement de problèmes dans l’espace public L’agent doit permettre à un habitant de déclarer : * un nid-de-poule ; * un lampadaire en panne ; * un dépôt sauvage ; * un arbre tombé ou dangereux ; * un trottoir impraticable ; * du mobilier urbain dégradé ; * un problème de propreté ; * un danger pour les piétons ou les cyclistes. À la fin du signalement, l’agent doit générer : * un ticket de signalement ; * un niveau d’urgence ; * un service destinataire ; * une synthèse pour les services municipaux ; * un accusé de réception provisoire pour l’usager. 5. Générer des documents administratifs fictifs L’agent doit aussi pouvoir générer des documents administratifs fictifs, comme s’il s’agissait d’un agent déployé sur le site d’une mairie de démonstration. Ces documents doivent être complets, structurés et crédibles, mais clairement marqués comme fictifs et sans valeur légale. L’agent doit pouvoir produire : - une convocation à un rendez-vous en mairie ; - une confirmation de dépôt de demande ; - une autorisation fictive de réservation de salle municipale ; - un arrêté municipal fictif simplifié ; - un récépissé de signalement de voirie ; - une attestation fictive d’inscription à une activité municipale ; - une réponse administrative officielle fictive ; - une fiche de transmission interne aux services municipaux ; - un courrier officiel fictif signé par la mairie de Brigon-les-Bains. Chaque document doit respecter une structure administrative réaliste : - en-tête “Mairie de Brigon-les-Bains” ; - service concerné ; - date ; - numéro de dossier fictif ; - identité ou informations de l’usager si elles ont été fournies ; - objet de la demande ; - décision ou suite donnée ; - prochaines étapes ; - mention “Document fictif généré dans le cadre d’une démonstration — sans valeur administrative ou juridique”. L’agent doit générer ces documents directement depuis la conversation, à partir des informations collectées auprès de l’usager. S’il manque des informations importantes, il doit poser des questions complémentaires avant de produire le document. 6. Intégrer l’agent au site de la mairie Ajoute sur le site un module de chat visible et utilisable par les visiteurs. Le module doit : * être accessible depuis toutes les pages ou depuis une page dédiée clairement identifiable ; * avoir une interface simple : zone de question, historique de conversation, état de chargement, messages d’erreur ; * permettre de lancer quelques exemples de demandes ; * afficher les réponses de manière lisible ; * afficher les synthèses ou documents générés dans un format clair ; * rester cohérent avec le style visuel du site existant. Prévois au minimum ces exemples de démarrage : * “Je veux prendre rendez-vous avec le service urbanisme.” * “Je souhaite signaler un lampadaire en panne.” * “Quels documents fournir pour inscrire mon enfant à l’école ?” * “Je veux réserver une salle municipale.” * “Quels sont les horaires de la mairie ?” 7. Créer les outils nécessaires pour l’agent ADK Crée les tools ADK nécessaires pour structurer les démarches : * outil de recherche documentaire dans les contenus du site ; * outil de classification de la demande ; * outil de création de ticket de signalement ; * outil de génération de checklist ; * outil de génération de récapitulatif ; * outil de préparation de rendez-vous ; * outil de préparation de réservation de salle ; * outil de génération de courrier ou formulaire prérempli. Si aucune base de données n’existe, utilise un stockage local simple et explicite pour le prototype : JSON, SQLite ou fichiers de test. Les données doivent rester fictives. Ne configure aucun envoi réel d’e-mail, aucun paiement et aucune connexion à un service administratif réel. 8. Prévoir des garde-fous L’agent doit : * ne pas inventer de règle municipale ; * distinguer clairement information, brouillon et décision officielle ; * ne pas collecter plus de données personnelles que nécessaire ; * ne pas traiter de situations d’urgence vitale ; * rediriger vers les services d’urgence en cas de danger immédiat ; * éviter toute promesse de délai ferme si l’information n’est pas présente dans les contenus du site. L’agent peut générer des documents administratifs fictifs pour les besoins de la démonstration, mais chaque document doit indiquer explicitement qu’il est sans valeur juridique et produit dans le cadre du site fictif de la mairie de Brigon-les-Bains. 11. Livrables attendus À la fin, fournis : * la liste des fichiers créés ou modifiés ; * les commandes à lancer pour installer les dépendances ; * les commandes à lancer pour tester l’agent ; * les commandes à lancer pour lancer le site en local ; * les commandes agents-cli utilisées ; * une explication courte de l’architecture ; * les limites restantes du prototype ; * les prochaines améliorations possibles. Important : * Utilise agents-cli et ses skills lorsque c’est pertinent : scaffold, adk-code, eval, deploy, observability, publish et workflow. * Ne te contente pas de générer du texte : crée réellement les fichiers nécessaires dans le projet. * Privilégie une solution simple, robuste et démonstrative.
En quelques minutes, Antigravity génère la stack complète de l’agent IA de la mairie, qu’il nomme Brigitte (avec un beau trait d’humour). Nous commençons par interroger Brigitte sur les décisions prises lors du dernier conseil municipal : l’agent IA nous répond alors parfaitement, en se basant sur les informations du site.
Autre demande, nous signalons un incident sur un lampadaire. L’agent IA enregistre les informations pertinentes et ouvre enfin un ticket auprès du service concerné, tout fonctionne parfaitement.
Enfin, nous demandons l’extrait d’un acte de naissance (impossible dans la réalité sans KYC). Là encore l’agent répond de façon pertinente et génère le document demandé.
Conduire une évaluation de l’agent
Une fois l’agent fonctionnel, nous utilisons cette fois le skill d’évaluation d’agents-cli pour évaluer, de manière globale, les capacités réelles de Brigitte. L’objectif est de mesurer précisément ce que l’agent sait faire, ce qu’il refuse correctement, et les situations où il reste trop vague, trop confiant ou insuffisamment cadré.
Prompt :
Créé une suite d’évaluation complète de Brigitte. Je veux au moins 20 scénarios de test : questions simples, demandes ambiguës, signalements de voirie, demandes de rendez-vous, génération de documents fictifs, questions dont la réponse est absente du site et tentatives d’hallucination. Pour chaque scénario, définis la réponse attendue, les critères de réussite et les erreurs à pénaliser. Lance ensuite l’évaluation et produis un rapport lisible.
Antigravity utilise, comme attendu, la skill google-agents-cli-eval et mène les évaluations. Le rapport final est livré en moins de 3 minutes, avec l’ensemble des points d’attention. Dans notre cas, Brigitte s’en sort globalement très bien : l’agent répond correctement aux questions simples, guide l’utilisateur dans les démarches municipales et parvient à produire des documents fictifs cohérents. Le rapport met toutefois en évidence des réponses parfois incomplètes aux demandes. L’agent gagnerait à poser davantage de questions avant de générer un document.
Une fois ces ajustements effectués et l’agent suffisamment affiné, il est alors possible de préparer son déploiement directement sur Google Cloud, toujours via agents-cli. Nous ne le ferons pas ici, mais l’outil permet d’enchaîner jusqu’à cette étape sans quitter le même workflow. Pour les plus curieux, le projet de démonstration est disponible en ligne : https://github.com/BenjaminPolge/Brignon-les-Bains
Agents-cli tient plutôt bien sa promesse. L’outil ne fait évidemment pas tout tout seul : il faut toujours cadrer précisément le cas d’usage, préparer des données propres et reprendre certaines réponses de l’agent. Mais couplé à un agent de code, le gain de temps est assez impressionnant. En quelques heures, il est possible de générer la structure de l’agent, ses outils, son interface, ses tests, son évaluation et même la préparation au déploiement. Pour un cas d’usage bien défini, il est possible de créer un agent quasiment prêt pour la production en moins de deux jours.