Un jeu vidéo avec une équipe d'agents : Antigravity, Firebase et Voyager

Voyager est un arcade où le joueur pilote un vaisseau pour connecter les étoiles des constellations du zodiaque contre un minuteur décroissant, avec un classement partagé et un dernier salut de Zarg 966-Z à Zargaborg. Ce qui vaut la peine dans cette histoire, c'est comment elle a été construite : avec Antigravity, l'environnement de développement à agents autonomes de Google, et le tutoriel « Liftoff with Google Antigravity: Build a Video Game with AI » de Google Skills vous mène de bout en bout, de l'installation au jeu en ligne. Ce post suit ce parcours et ce qu'il enseigne sur le travail avec une équipe d'agents.

Un mission control, pas un chat avec du code

Antigravity est un environnement de développement propulsé par l'IA où les agents agissent comme des travailleurs autonomes. La différence avec le vibe coding tient à la structure : l'interface fonctionne comme un mission control, avec une configuration stratégique (définir comment se comportent les agents) et un guidage tactique de leurs actions sur le projet.

Deux commandes structurent chaque conversation. La première est Context, qui ajoute du matériau au prompt : Media pour des captures de style ou d'architecture, Mentions ou @ pour des documents, Actions ou / pour des tâches programmées et des objectifs, et Browser pour lui montrer le travail dans Chrome. Il y a une règle pratique : les ressources doivent être dans le dossier du projet pour pouvoir servir de contexte. La seconde est Model, avec les familles Gemini, Claude et GPT, et une recommandation concrète : des modèles de rang inférieur pour assurer la disponibilité.

L'intégration avec les produits externes a deux voies. Les plugins sont des bundles aux noms espacés qui regroupent skills, rules, serveurs MCP et hooks dans un seul paquet, et ils donnent à Antigravity de l'expérience sur des produits tiers ; le tutoriel installe celui de Firebase parce qu'il servira ensuite. Les serveurs MCP, de leur côté, sont, selon le site officiel, « an open-source standard for connecting AI apps to external systems », et les serveurs exposent des capacités pour que les agents se connectent à des choses.

De la première conversation sortent deux artefacts qui méritent l'attention. Les implementation plans sont le plan de comment l'agent compte réaliser la tâche, et l'utilisateur peut laisser des commentaires pour orienter son comportement : corriger un malentendu, ajuster le périmètre, freiner un changement prématuré. Les walkthroughs résument comment la tâche a été complétée, avec des captures ou même des enregistrements d'écran. Les deux existent pour que les agents communiquent avec les personnes et maintiennent l'alignement stratégique.

Les avertissements du premier contact font aussi partie de la méthode : les modèles sont non déterministes, chaque réponse est unique ; l'agent peut surcompliquer (le conseil du tutoriel est keep it simple) ; et une fois que l'app fonctionne, il vaut mieux refuser les requêtes restantes et appuyer sur Stop, parce que c'est là qu'il commence à brûler ce dont on a besoin plus tard.

Firebase : le backend sans quitter le flux

Voyager a besoin de trois services Firebase, la suite backend de Google : Firestore, la base de données structurée pour le classement ; l'authentification anonyme, pour associer des scores à un joueur sans lui demander de se connecter ; et Hosting, pour servir l'app à tout le monde. Dans la console, on crée le projet, on crée Firestore en mode standard avec ID et localisation par défaut, et vient la décision importante : test mode, pas default. Le test mode donne un accès facile pendant le développement et oblige à mettre à jour les règles en 30 jours. L'authentification anonyme s'active dans Security > Authentication > Native providers > Anonymous. Et l'enregistrement de l'app web génère le firebaseConfig avec sa clé API, que les agents référencent dans le code.

Le déploiement a deux chemins. Le flux agentic laisse Antigravity tout faire avec l'ID de projet : les seules commandes à exécuter sont mkdir, mv et firebase deploy, avec la permission de déployer en mode unsandboxed, et si l'app ne se déploie pas en cinq minutes il vaut passer au manuel. Le flux manuel est firebase init en sélectionnant Firestore et Hosting avec la barre d'espace, en choisissant le projet existant, en acceptant les noms par défaut et en répondant « non » à deux questions : application à page unique (Voyager a trois pages et les sous-dossiers causeraient des problèmes) et builds ou déploiements automatiques avec GitHub.

flowchart LR
    I[Firebase CLI : init avec Firestore et Hosting] --> D{75 % de tokens restants ?}
    D -->|Oui| G[Flux agentic : mkdir, mv, firebase deploy]
    D -->|Non| M[Flux manuel]
    G -->|Pas déployé en 5 minutes ?| M
    G --> L[Jeu en ligne avec Hosting]
    M --> L

Le init laisse un projet local avec des pièces concrètes : .firebase/ avec le cache, public/ avec index.html et 404.html, .firebaserc qui relie le dossier au projet, .gitignore, firebase.json comme carte maîtresse, firestore.indexes.json et firestore.rules, qui par défaut laisse la base ouverte le premier mois. Il y a un seuil opérationnel pour choisir le flux : s'il reste environ 75 % de tokens, flux agentic ; moins que cela, manuel.

L'équipe : SKILL.md, agents A, B et C

Une fois les fichiers du Hello World initial effacés, le tutoriel assemble la partie la plus intéressante du build. Un fichier d'orchestration SKILL.md, lisible par n'importe quel agent qui travaille sur le projet, définit comment ils travaillent ensemble. L'Agent A construit le moteur du jeu dans game.js. L'Agent B construit le classement dans leaderboard.js : son plan n'inclut pas de vérification, suivant l'instruction du SKILL.md de la laisser à l'Agent C, et il réutilise en plus les fichiers créés par l'Agent A, si bien que son code s'appuie sur le travail d'autrui. L'Agent C teste et répare.

L'Agent C est le point le plus difficile du build. En langage de fusée, Max Q est la fenêtre de pression maximale, et le tutoriel l'utilise pour nommer cette étape. Il a besoin du serveur MCP chrome-devtools-mcp pour avoir des mains numériques : ouvrir le jeu, interagir et lire les erreurs de la console web. Son prompt définit le rôle « Quality Assurance Tester and Engineer » et une boucle de débogage en sept étapes : lancer avec firebase emulators:start sans npx, l'ouvrir avec DevTools MCP, démarrer le jeu, échouer en laissant le minuteur s'épuiser sur la première constellation, redémarrer, sauter les douze niveaux avec Shift+D, et confirmer le SVG et le message de Zarg 966-Z avant d'utiliser le classement sans ensemencer la base avec d'autres tests.

flowchart TD
    S[SKILL.md d'orchestration] --> A[Agent A : moteur du jeu<br/>game.js]
    S --> B[Agent B : classement<br/>leaderboard.js sur les fichiers de A]
    S --> C[Agent C : QA avec DevTools MCP<br/>boucle de sept étapes]
    A --> C
    B --> C
    C --> F[Correction humaine minimale<br/>et déploiement sur le site live]

La supervision humaine apparaît dans les détails. Le flux sûr par défaut demande la permission avant de faire des changements : il faut autoriser le débogage à distance pour que le sous-agent ouvre Chrome et teste ce qui a été construit, corriger le plan quand il suppose quelque chose de faux (un CLI Firebase authentifié, par exemple), et exiger firebase emulators:start sans npx. Quand l'Agent C est resté bloqué dans une boucle logique, essayant d'exécuter un script au lieu d'appuyer sur le bouton Try Again, une seule instruction humaine l'en a sorti ; ensuite il a réparé une faute de frappe HTML qui cassait le classement et a poussé le jeu sur le site live. Même l'erreur npm de l'environnement s'est résolue avec un « fix it ».

Les six mots et la limite de leur usage

Le prompt engineering du tutoriel s'appuie sur six mots-clés : who, what, when, where, why et how, appliqués à l'expérience utilisateur et à l'expérience développeur. Avec eux, l'idée de l'app se consolide en un outline portable. Vient ensuite le prompt chaining, qui repose sur une idée simple : « given enough context, AI writes great instructions for AI », c'est-à-dire, avec assez de contexte, l'IA écrit de bonnes instructions pour l'IA. Le tutoriel a enchaîné les prompts dans l'app web Gemini pour générer le SKILL.md et les prompts des agents.

La contrepartie de la méthode est une expérience. L'action /grill-me aligne l'agent avec une instruction minimale, au lieu d'un prompt soigné. Le jeu qui en est sorti fonctionnait, mais n'avait pas d'originalité : des éléments de deux classiques combinés, des défis faciles à esquiver, et jusqu'un classement Firebase que personne n'avait demandé. La conclusion est directe : l'IA excelle dans l'implémentation, le how du projet, et ne remplace pas la maîtrise du why. La recommandation pratique du tutoriel est d'utiliser les six mots pour clarifier la vision avant de recourir à /grill-me.

Tokens : d'où vient le carburant

Les tokens sont l'information sur laquelle travaille l'IA : l'input est tokenisé en nombres, le modèle opère sur ces nombres et produit de nouveaux tokens qui deviennent la sortie, comme des blocs de code. Ce sont aussi la métrique de consommation, avec des limites vérifiables dans Settings > Models. Dans le flux de travail, ils se traduisent en décisions concrètes : le seuil de 75 % pour choisir entre déploiement agentic et manuel, et Stop une fois que l'app fonctionne.

Ce que ce parcours rend clair, c'est la répartition des pièces. La personne met le why : ce qu'est Voyager, comment on gagne, ce qui n'est pas acceptable. Les agents mettent le how : HTML, CSS, JavaScript et l'intégration avec Firebase. Le SKILL.md est le contrat entre les deux côtés, et la correction humaine, même d'une instruction, reste ce qui évite au build de tourner en boucle dans une boucle logique. Le fait que le tutoriel remplace les labs par un « joue comme le développeur » renforce l'idée : la vérification finale est de le jouer, pas de le lire.

Reste ce qui n'a pas été testé. Le quiz du tutoriel ne s'est pas ouvert et le badge n'a pas été réclamé. Les prérequis système et la disponibilité d'Antigravity sont datés « at the time of publication » et sujets à changement : le tutoriel tourne en local. Et les prompts complets des agents A et B n'apparaissent pas dans le texte téléchargé ; seulement ceux de l'Agent C et le guide « How to build Voyager » comme ressource.

*Source : « Liftoff with Google Antigravity: Build a Video Game with AI », de Google Skills.*