Pour créer une petite application web locale avec Google Antigravity IDE, commencez par rattacher un dossier au projet, puis faites avancer le code par étapes et testez-le dans le navigateur. Le tutoriel pratique d’InfoWorld suit un projet Astro enrichi avec HTMX et SQLite ; Google précise que les plans et autres éléments de revue ne sont pas générés à chaque tâche.

Choisir la bonne surface Antigravity

Pour ce tutoriel, choisissez Antigravity IDE : c’est l’environnement destiné au développement avec un éditeur, un terminal et des outils de gestion d’agents. Google distingue l’IDE de l’application Antigravity autonome, conçue comme un centre de gestion des agents, et d’Antigravity CLI, qui permet des interactions avec un agent depuis le terminal. La documentation de Google Codelabs distingue également le SDK de ces interfaces. La présentation officielle des produits et de la configuration précise les caractéristiques de chaque surface.

Pour l’exercice de prise en main de Google, les systèmes indiqués sont macOS, Windows et certaines distributions Linux ; Chrome et un compte Gmail personnel font aussi partie des prérequis de cet exercice.

Relier le projet aux fichiers locaux

Mikey No Code montre en anglais la configuration d’un projet, la revue d’un plan, des modifications ciblées et des essais dans le navigateur, avec une application distincte en Node.js.

Créez un projet dans l’IDE et associez-lui un dossier local avant de demander à l’agent de travailler sur les fichiers. Google décrit le projet comme le périmètre auquel peuvent être rattachés un ou plusieurs dossiers, ainsi que des outils, des autorisations et des réglages propres au projet. Dans son tutoriel débutant, Mikey No Code insiste aussi sur cette étape : l’agent ne peut pas accéder aux fichiers du projet tant qu’un dossier local n’est pas relié.

La vidéo de Mikey No Code montre un autre exemple, une application de tâches en Node.js : elle complète les étapes de configuration et de revue, mais ne présente pas le projet de guitares d’InfoWorld.

Construire une application locale, étape par étape

Le parcours ci-dessous reprend le projet d’inventaire de guitares décrit par InfoWorld. Il illustre un exemple de développement avec Antigravity IDE, pas une configuration imposée à tous les projets.

  1. Créer le projet Astro. Dans le terminal, la commande utilisée est npm create astro@latest vintage-guitar-vault. Elle génère le projet Vintage Guitar Vault.
  2. Commencer par une page et des données simples. Dans src/pages/index.astro, l’auteur du tutoriel InfoWorld part d’une liste de guitares codée directement dans la page. Son exemple utilise le bloc de frontmatter Astro délimité par --- ; un commentaire précisant les champs souhaités pour les guitares donne une liste d’exemple plus ciblée qu’une demande non détaillée.
  3. Ajouter les requêtes HTMX. L’exemple fait évoluer la liste statique vers une requête HTMX pour récupérer l’historique d’entretien d’une guitare, à partir de /api/maintenance/${guitar.id}. Les suggestions de code intégrées ont aidé sur la syntaxe, mais le travail entre plusieurs fichiers a demandé l’intervention de l’Agent Manager.
  4. Déplacer les données dans une base locale. Le projet utilise SQLite avec better-sqlite3. L’auteur rapporte avoir demandé à l’Agent Manager d’ajouter HTMX, de corriger l’interpolation Astro et de déplacer les fiches de guitares vers la base de données.
  5. Ajouter l’initialisation et la route d’entretien. Le projet reçoit ensuite un script de données initiales et la route /api/maintenance/[id], qui répond à la requête déclenchée pour une guitare.

Ces étapes, ainsi que la construction du projet, sont rapportées par l’auteur du tutoriel pratique d’InfoWorld sur Antigravity IDE.

Lancer l’application et examiner le résultat

Dans le projet InfoWorld, npm run dev lance le serveur de développement ; l’application est consultée à l’adresse localhost:4321. Ouvrez-la dans le navigateur et testez l’action d’entretien pour vérifier le parcours entre la fiche de guitare et sa route dédiée.

InfoWorld rapporte que son auteur a rencontré une erreur node-gyp sous Windows, corrigée après approbation, puis une TypeError lors du test de la fonction d’entretien. L’auteur indique que des essais dans le navigateur intégré et un travail supplémentaire avec l’agent ont permis de résoudre ces problèmes dans cet exemple.

Google décrit /plan comme une commande permettant de demander un plan d’implémentation. Des plans, listes de tâches, diffs, captures d’écran et comptes rendus peuvent aussi servir à examiner le travail de l’agent. Mais ces éléments ne sont pas systématiques, et l’agent peut parfois poursuivre sans bouton visible « Proceed ». Examinez donc les changements proposés quand ils sont accessibles, puis vérifiez le comportement de l’application en la lançant réellement.