ITSkillsCenter
Intelligence Artificielle

Orchestrer plusieurs agents avec l’Agent Manager d’Antigravity

12 min de lecture

Un agent qui code pendant que vous lisez ses logs, c’est bien. Cinq agents qui avancent en parallèle sur cinq tâches, c’est un changement de métier. L’Agent Manager d’Antigravity est l’espace conçu pour ça : une tour de contrôle où vous lancez, surveillez et coordonnez plusieurs agents travaillant de façon asynchrone. Dans ce tutoriel, vous apprenez à y faire travailler deux agents en même temps sur l’application Suivi — l’un sur l’API, l’autre sur l’interface — sans jamais bloquer votre éditeur.

📘 Guide principal de la série : Google Antigravity : développer avec des agents IA autonomes.

🎯 Ce que vous allez apprendre

  • Ouvrir l’Agent Manager et comprendre sa logique de « mission control ».
  • Lancer plusieurs agents en parallèle sur des tâches distinctes.
  • Choisir le bon mode (Fast ou Planning) selon la complexité de chaque tâche.
  • Suivre l’avancement, lire les livrables et reprendre la main sans casser le travail en cours.

🛠️ Ce que vous allez construire

Nous reprenons l’application Suivi initialisée précédemment. Objectif du jour : faire avancer deux chantiers en même temps. Un premier agent ajoute à l’API les opérations de création et de liste des tâches ; un second prépare une page web minimale qui affiche ces tâches. À la fin, vous aurez constaté de vos yeux deux agents progressant côte à côte, chacun avec son propre fil et ses propres livrables.

Prérequis

Étape 1 — Ouvrir l’Agent Manager

Tout commence par changer de surface. Là où l’Editor View vous garde au plus près du code, l’Agent Manager prend de la hauteur : il est pensé pour piloter du travail, pas pour le taper. On y bascule avec le raccourci Cmd + E (ou via le bouton « Open Agent Manager »).

L’interface se lit comme un tableau de bord : à gauche, la liste des conversations et des agents actifs ; au centre, le fil de l’agent sélectionné ; à droite, un accès aux livrables. Si c’est votre première visite, l’espace est presque vide — c’est normal, nous allons le remplir. Retenez l’idée maîtresse : chaque agent vit dans sa propre conversation, et plusieurs conversations peuvent tourner en même temps.

Pour bien saisir l’intérêt de cette surface, il faut comprendre la différence entre travail synchrone et asynchrone. Dans un éditeur classique, le rythme est synchrone : vous tapez, vous attendez, vous relisez, ligne après ligne, et votre attention est captive. L’Agent Manager inverse ce rapport. Vous formulez une intention, l’agent part travailler seul, et votre attention se libère pour formuler la tâche suivante ou relire un livrable. Le goulot d’étranglement n’est plus la vitesse à laquelle vous tapez, mais la clarté avec laquelle vous décrivez ce que vous voulez et la rigueur avec laquelle vous vérifiez ce qui revient. C’est un déplacement subtil mais profond : on passe de l’écriture de code à la conduite de travail.

À ce stade, vous devez voir l’écran d’accueil de l’Agent Manager avec un champ de saisie de type « Ask anything ». C’est notre point de départ pour lancer le premier des deux agents.

Quand préférer le Manager à l’éditeur ?

La question revient vite : pourquoi ne pas tout faire dans l’éditeur, panneau d’agent ouvert ? Parce que les deux surfaces répondent à deux besoins différents. L’éditeur excelle pour une intervention unique et rapprochée : corriger une fonction précise, comprendre un fichier, faire une retouche que vous voulez voir s’appliquer sous vos yeux. Le Manager excelle dès qu’il y a pluralité — plusieurs tâches, plusieurs fichiers, plusieurs essais à mener en parallèle — ou dès que la tâche est assez longue pour que rester à la regarder serait du temps perdu. Une bonne heuristique : si vous vous apprêtez à lancer une tâche puis à attendre passivement, c’est un signal que la tâche appartient au Manager. Si vous voulez garder les mains sur le clavier pendant que ça se fait, restez dans l’éditeur.

Dans la vie réelle d’un projet comme Suivi, on alterne en permanence. On délègue au Manager la création d’une fonctionnalité entière, on revient dans l’éditeur affiner un détail de présentation, puis on relance un agent pour écrire les tests. Cette respiration entre les deux surfaces est ce qui rend l’outil fluide une fois la prise en main passée.

Étape 2 — Lancer le premier agent sur l’API

Avant de paralléliser, lançons proprement un agent. On choisit d’abord l’espace de travail (workspace) : c’est le dossier sur lequel l’agent a le droit d’agir. Sélectionnez le dossier suivi. Puis choisissez le modèle dans le menu déroulant et le mode de conversation.

Le choix du mode est décisif. Fast exécute directement, idéal pour une tâche bien cadrée. Planning fait d’abord rédiger un plan structuré, recommandé dès que la tâche touche plusieurs fichiers ou demande des décisions. Ajouter deux endpoints à une API entre clairement dans la seconde catégorie : choisissez Planning.

Dans le projet suivi, ajoute deux routes a l'API Express :
- POST /tasks : cree une tache a partir d'un champ "titre" en JSON,
  lui attribue un identifiant et la stocke en memoire dans un tableau.
- GET /tasks : renvoie la liste des taches.
Garde l'endpoint /health intact. Propose un test rapide avec curl.

Validez. L’agent rédige son plan, puis attend votre approbation pour les actions sensibles. Pendant qu’il travaille, ne restez pas à le regarder : c’est précisément l’intérêt de l’Agent Manager. Nous allons lancer un second agent en parallèle.

Point d’étape — Le premier agent doit apparaître dans la liste de gauche avec un statut « en cours ». Tant qu’il travaille, son fil affiche les étapes franchies. Vous n’avez pas besoin d’attendre sa fin pour passer à la suite.

Étape 3 — Lancer un second agent en parallèle

Voici le geste qui change tout. Plutôt que d’enchaîner les tâches une à une, démarrez une nouvelle conversation dans l’Agent Manager (bouton « Start Conversation » ou le champ « Ask anything » de l’accueil). Vous obtenez un second agent, indépendant du premier, avec son propre fil.

Confiez-lui la partie interface, sur le même workspace suivi :

Cree un fichier public/index.html pour le projet suivi : une page
simple qui appelle GET /tasks en JavaScript et affiche les titres des
taches dans une liste. Ajoute un petit formulaire qui envoie POST /tasks.
Pas de framework, du HTML et du JavaScript natif suffisent.

Vous avez désormais deux agents actifs. Dans la liste de gauche, les deux conversations défilent indépendamment. C’est le cœur du modèle asynchrone : chacun avance à son rythme, et vous gardez une vue d’ensemble. Un détail pratique : comme les deux agents touchent le même projet, évitez de leur confier des modifications sur le même fichier au même moment — répartissez le travail par fichier (ici, l’un sur server.js, l’autre sur public/index.html) pour éviter les conflits.

Étape 4 — Suivre, approuver, et lire les livrables

Piloter, c’est surtout savoir où regarder. Cliquez d’une conversation à l’autre pour suivre chaque fil. Lorsqu’un agent réclame une validation — installer un paquet, écrire un fichier hors du périmètre attendu — une demande apparaît dans son fil ; approuvez en connaissance de cause. Les deux agents peuvent attendre votre feu vert à des moments différents, et c’est très bien ainsi.

Pour juger le résultat sans relire tout le code, ouvrez les livrables de chaque agent via le bouton dédié en haut à droite. Vous y trouvez la liste de tâches accomplies, le plan, et le récapitulatif final. L’agent « API » doit décrire ses deux nouvelles routes et la façon de les tester ; l’agent « interface » doit pointer vers public/index.html et expliquer comment l’ouvrir.

Lire un livrable n’est pas une formalité : c’est l’acte de validation lui-même. Un récapitulatif bien lu vous évite de relancer l’application pour rien, parce qu’il vous dit déjà ce qui a été testé et avec quel résultat. Prenez l’habitude de parcourir d’abord la liste de tâches accomplies pour vérifier que l’agent a bien fait ce que vous attendiez — ni moins, ni trop. Une dérive classique consiste à en faire plus que demandé : un agent qui « améliore » au passage un fichier que vous vouliez laisser intact. Le livrable est précisément l’endroit où repérer ce genre d’écart avant qu’il ne se propage.

Point d’étape — Lancez l’API avec node server.js, puis testez la création d’une tâche : curl -X POST http://localhost:3000/tasks -H "Content-Type: application/json" -d '{"titre":"Preparer la demo"}'. Un GET /tasks doit ensuite renvoyer cette tâche. Ouvrez enfin public/index.html dans un navigateur : la tâche doit s’afficher dans la liste.

Étape 5 — Reprendre la main proprement

Un bon pilote sait aussi arrêter. Si un agent part dans une mauvaise direction, vous pouvez interrompre sa conversation, lui envoyer un message correctif, ou reprendre le fichier à la main dans l’Editor View. Comme chaque agent est isolé dans sa conversation, stopper l’un n’affecte pas l’autre. C’est là que la séparation des deux surfaces prend tout son sens : vous orchestrez depuis le Manager, et vous plongez dans le code depuis l’éditeur quand une retouche fine s’impose.

Antigravity sait aussi capitaliser sur ce travail : les agents peuvent enregistrer du contexte et des extraits utiles dans une base de connaissances afin d’améliorer leurs tâches futures. Concrètement, plus vous travaillez sur Suivi, plus les agents disposent de repères sur vos conventions. Nous exploiterons ce mécanisme volontairement et de façon contrôlée dans les tutoriels sur les instructions persistantes et les compétences.

Garder ses conversations lisibles

Quand trois ou quatre agents tournent, la liste de gauche peut vite devenir confuse. Deux réflexes aident. D’abord, formulez chaque tâche de manière auto-descriptive : une première ligne claire (« Ajouter les routes /tasks à l’API ») sert d’étiquette mentale à la conversation. Ensuite, fermez ou archivez les conversations terminées une fois leur livrable validé, pour ne garder à l’écran que le travail vivant. Cette hygiène paraît anecdotique au début ; elle devient indispensable dès que l’on mène plusieurs chantiers de front sur un même projet, car c’est elle qui vous permet de toujours savoir, d’un coup d’œil, qui fait quoi et où en est chacun.

🐞 Pièges fréquents

Symptôme Cause probable Correctif
Deux agents modifient le même fichier et se marchent dessus Tâches mal réparties Découper par fichier ou par dossier ; un agent par zone du projet
Un agent semble « figé » Il attend une validation Ouvrir son fil : une demande d’approbation bloque souvent l’avancement
Le front affiche une liste vide L’API n’est pas lancée, ou mauvais port/URL Vérifier que node server.js tourne et que l’URL appelée correspond au port réel
Erreur CORS dans la console du navigateur Front et API sur des origines différentes Servir la page depuis le serveur Express, ou demander à l’agent d’activer CORS sur l’API

✅ Récapitulatif

Vous savez maintenant ouvrir l’Agent Manager, y lancer plusieurs agents et les faire avancer en parallèle sur des chantiers distincts du même projet. Vous avez vu comment choisir entre Fast et Planning, comment suivre et approuver chaque fil indépendamment, et comment reprendre la main sans tout casser. Surtout, vous avez intégré la bonne division du travail : répartir par fichier pour éviter les collisions. C’est la compétence qui transforme l’agent isolé en véritable équipe pilotable.

🧾 Aide-mémoire

Action Comment
Basculer vers l’Agent Manager Cmd + E ou bouton « Open Agent Manager »
Lancer un nouvel agent « Start Conversation » / champ « Ask anything »
Choisir le périmètre d’action Sélection du workspace (dossier) au démarrage
Tâche multi-fichiers Mode Planning
Tâche simple et cadrée Mode Fast
Éviter les conflits Un agent par fichier / par zone

💪 À vous de jouer

Lancez un troisième agent dont la seule mission est d’écrire un fichier README.md décrivant l’API et la page web produites par les deux autres. Observez comment il lit le projet existant pour se documenter.

Voir une piste de solution

Consigne : « Rédige un README.md pour le projet suivi : décris les routes /health, /tasks (GET et POST) et explique comment lancer le serveur et ouvrir la page public/index.html. Ne modifie aucun fichier de code. » L’agent doit parcourir server.js et public/index.html pour rédiger une documentation fidèle, puis vous présenter le fichier en livrable.

À lire aussi

Ressources officielles

FAQ

Combien d’agents puis-je lancer en même temps ?
Plusieurs conversations peuvent tourner en parallèle ; en pratique, la limite utile vient surtout de votre capacité à relire les livrables et des quotas du modèle, pas d’un plafond technique strict. Commencez par deux ou trois.

Les agents partagent-ils un état entre eux ?
Chaque conversation est indépendante. Ce qu’ils partagent, c’est le système de fichiers du projet : d’où l’importance de répartir le travail par fichier. La base de connaissances, elle, accumule du contexte réutilisable d’une session à l’autre.

Faut-il rester devant l’écran pendant qu’ils travaillent ?
Non, c’est tout l’intérêt du mode asynchrone. Vous pouvez lancer une tâche, partir vérifier autre chose, et revenir lire le récapitulatif. En mode supervisé, l’agent vous attendra simplement aux points qui demandent une validation.

Partager
Service ITSkillsCenter

Application mobile Android et iOS

Création d'application mobile Android et iOS. À partir de 350 000 FCFA.

Démarrer mon projet
Publicité