Google Antigravity : Test de l'IDE IA et agent Google

Si vous cherchez un avis Google Antigravity, le bon réflexe n’est pas de le comparer à Cursor sur une seule suggestion de code. Antigravity vise un autre moment : celui où vous voulez confier à un agent IA une tâche entière, avec lecture du repo, modifications, terminal, navigateur, preuves et validation humaine. L’angle IA Technologie est simple : décider vite si Google Antigravity mérite un essai, quel plan viser et dans quels cas Cursor, Claude Code ou Copilot restent plus rationnels.

Antigravity 2.0 a déplacé le sujet. Google ne présente plus seulement un IDE dopé à Gemini, mais une application desktop autonome pour lancer, surveiller et orchestrer des agents. L’IDE existe toujours. Le CLI aussi. Le coeur de la décision, lui, se trouve dans le cycle complet : planifier une tâche, agir sur les fichiers, exécuter des commandes, ouvrir Chrome, produire un artifact et laisser l’humain reprendre le contrôle avant que le patch devienne dangereux.

Essayer Google Antigravity gratuitement →

Pourquoi utiliser Google Antigravity comme assistant de code ?

Google Antigravity vaut surtout le coup si vous utilisez déjà l’IA comme un collaborateur de développement, pas comme un générateur de snippets. Une demande du type “ajoute une validation sur ce formulaire, lance le serveur local, vérifie le parcours dans Chrome et montre le diff” correspond mieux à Antigravity qu’une demande de complétion d’une ligne.

La documentation officielle décrit Antigravity 2.0 comme un centre de commande pour agents capables d’exécuter des commandes système, lire et écrire des fichiers, faire des recherches web, utiliser MCP, gérer des subagents, interagir avec Chrome et créer des artifacts. En français simple, cela veut dire que l’agent peut suivre un workflow de développeur : comprendre le problème, proposer un plan, modifier le repo, vérifier le résultat et laisser une trace relisible.

Le meilleur cas d’usage est un ticket court mais complet. Exemple : corriger un bug d’affichage sur une app Next.js, demander à l’agent de créer une branche ou un worktree, limiter les fichiers autorisés, lancer le test concerné, puis produire une capture navigateur. Ce n’est pas spectaculaire sur une démo vide. C’est utile sur un repo réel, là où une erreur de contexte coûte vite une heure.

La limite est nette : Antigravity ne remplace pas la revue. Plus l’agent peut agir dans le terminal, le navigateur et les fichiers, plus il faut lui donner un périmètre précis. Une demande vague comme “améliore mon app” va consommer du quota, toucher trop de fichiers et produire un résultat difficile à relire. Le bon test ressemble à un ticket technique, avec symptôme, fichiers probables, contrainte, commande de test et preuve attendue.

Décision courte : installez Antigravity si vous avez au moins une tâche multi-fichiers à déléguer cette semaine. Si votre besoin reste l’autocomplétion quotidienne dans l’IDE, commencez plutôt par Cursor ou GitHub Copilot.

Quel est le prix et le quota de Google Antigravity ?

Le prix de Google Antigravity ne se lit pas comme un SaaS classique avec un nombre fixe de générations par mois. La page officielle des plans indique que tous les comptes reçoivent une baseline avec modèles Gemini, Tab completions illimitées et accès aux fonctions produit comme Scheduled Tasks et CLI. Elle précise aussi que les limites dépendent du plan Google AI, de la capacité disponible et de la quantité de travail réalisée par l’agent.

Ce détail change la décision d’achat. Une correction simple peut coûter peu de quota. Une tâche confuse qui ouvre le navigateur, lit beaucoup de fichiers, lance plusieurs commandes et itère sur trois erreurs peut coûter beaucoup plus. Le bon seuil n’est donc pas “combien de messages par jour”, mais “combien de vraies tâches agentiques par semaine”.

Pour un test ponctuel, le quota de base suffit. Choisissez une tâche courte, gardez Strict Mode ou des permissions prudentes, puis regardez si l’agent produit un plan, un diff et une preuve utiles. Pour un développeur solo qui lance deux ou trois tâches agentiques par semaine, Google AI Pro devient le premier plan à considérer, car Google indique un quota plus généreux et rafraîchi toutes les cinq heures jusqu’à la limite hebdomadaire.

Ultra vise un autre profil. La documentation Antigravity indique le quota le plus généreux, l’accès aux modèles tiers et une préversion /teamwork-preview réservée à Ultra dans la page sur les subagents. Ce n’est pas le bon achat pour une curiosité du week-end. C’est à regarder si Antigravity devient un poste de production quotidien, si plusieurs agents travaillent en parallèle ou si l’accès aux modèles tiers change réellement votre workflow.

Les AI Credit Overages méritent aussi une ligne dans votre calcul. Google indique que les utilisateurs Pro ou Ultra peuvent utiliser des crédits IA achetés pour dépasser le quota de base, avec un réglage “Never” ou “Always”. En pratique, laissez l’overage sur une option prudente au début. Un agent mal cadré peut faire monter la consommation sans améliorer le résultat.

Voir les plans Antigravity →

Simulateur de forfait pour Google Antigravity

Ce module ne calcule pas un coût exact, car Google ne publie pas un nombre fixe de requêtes universel pour Antigravity. Il sert à classer votre usage selon quatre critères qui changent vraiment la décision : volume de tâches agentiques, surface préférée, sensibilité du repo et besoin de navigateur ou MCP.

Gardez la logique simple. Moins de quatre tâches par semaine : commencez avec le quota de base. Entre quatre et quinze tâches par semaine : Pro devient cohérent si les limites vous freinent. Au-delà, ou si plusieurs agents doivent travailler sur des workflows longs, Ultra mérite une comparaison. Si le sujet est conformité, IAM, réseau privé ou résidence des données, ne bricolez pas avec un compte personnel : regardez Enterprise.

Fonctionnalités : Agents autonomes, MCP et Artifacts

Antigravity se distingue quand la tâche doit être vérifiée, pas seulement écrite. Le Browser Subagent peut ouvrir un Chrome local, lire une page, agir sur une interface, capturer des screenshots et produire des vidéos webm. Pour un développeur front, c’est un vrai différenciateur : l’agent peut corriger un bouton, lancer la page, cliquer dans le formulaire et laisser une preuve visuelle.

Les artifacts changent aussi la relation avec l’agent. Google les décrit comme des éléments créés pour communiquer le travail et le raisonnement : markdown riche, diff, diagramme, image, capture, enregistrement navigateur ou plan d’implémentation. L’impact utilisateur est concret : vous ne surveillez pas chaque étape en direct, vous relisez un plan ou une preuve au bon moment.

Un exemple de workflow utile : demandez à Antigravity de modifier une page de pricing, de créer un implementation plan, de limiter le périmètre à deux composants, de lancer le build, puis de vérifier le rendu mobile dans Chrome. Si l’artifact montre une capture correcte et un diff court, la relecture devient rapide. Si l’agent propose de toucher quinze fichiers, vous coupez avant que la tâche s’élargisse.

Les worktrees ajoutent une protection pratique. Dans Antigravity 2.0, les projets peuvent utiliser des Git worktrees pour faire travailler des agents dans des dossiers isolés en arrière-plan. Cela réduit le risque de mélanger une expérience agentique avec votre branche locale. Ce n’est pas une excuse pour ignorer Git. C’est une meilleure base pour déléguer proprement.

Le CLI complète l’ensemble pour les développeurs terminal-first. La documentation le présente comme une interface légère qui partage le même moteur agentique, les mêmes réglages principaux et la possibilité d’exporter une conversation vers Antigravity 2.0. Si vous travaillez en SSH ou sur un serveur distant, ce détail pèse plus qu’une jolie interface.

Phrase de décision : utilisez Antigravity pour les tâches qu’un développeur junior devrait documenter avant merge. Pour renommer une variable ou compléter un import, un IDE IA plus direct reste plus rentable.

Sécurité et gestion des permissions par l’agent IA

Antigravity a un vrai sujet de sécurité, parce que l’agent peut lire des fichiers, écrire dans un repo, lancer des commandes, ouvrir des URLs et utiliser des serveurs MCP. Google répond avec un moteur de permissions lisible : chaque action peut tomber dans Deny, Ask ou Allow, avec une priorité stricte Deny > Ask > Allow.

Ce mécanisme est plus important qu’il n’en a l’air. Vous pouvez autoriser npm run test, demander confirmation pour toute commande inconnue, refuser l’accès à un dossier .ssh, limiter les URLs, ou encadrer les outils MCP. Pour un repo client, le bon réglage initial consiste à laisser les commandes sensibles en Ask, refuser les dossiers privés et n’autoriser que les domaines nécessaires.

Strict Mode durcit encore le cadre. La documentation indique que le terminal passe en Request Review, que l’exécution JavaScript navigateur demande une validation, que l’artifact review demande confirmation, que l’agent respecte .gitignore et que l’accès hors workspace est désactivé. En clair : vous perdez un peu de fluidité, mais vous réduisez le risque d’un agent trop libre sur un projet sensible.

Le navigateur a son propre modèle. Antigravity utilise un profil Chrome isolé, séparé de votre profil principal, avec cookies et sessions distincts. C’est utile pour éviter qu’un agent tombe sur vos sessions personnelles. Ce n’est pas une garantie absolue : si vous tapez des identifiants dans le profil agentique, ces cookies persistent dans ce profil. Traitez-le comme un environnement de travail séparé.

Le sandbox terminal est annoncé en preview sur macOS et Linux. Les permissions de fichiers et d’URLs alimentent alors les règles d’accès du conteneur. L’idée est bonne : limiter ce que les commandes peuvent lire, écrire et contacter. La prudence reste nécessaire, car une preview n’a pas la même maturité qu’une politique de sécurité d’entreprise auditée.

Décision courte : pour un repo personnel, commencez avec permissions par défaut et validation des commandes. Pour un repo client ou interne, activez Strict Mode avant le premier vrai test. Pour une organisation avec données sensibles, regardez la voie Google Cloud.

Google Antigravity vs Cursor AI : Quelle alternative ?

Le match Antigravity vs Cursor se tranche par le geste principal. Cursor reste plus naturel si vous vivez dans l’IDE : Tab, Agent, règles projet, diff visuel, commandes et corrections proches du code. Antigravity prend l’avantage quand la tâche dépasse l’IDE et réclame un hub d’agents, des worktrees, Chrome, des artifacts et des permissions plus visibles.

Prenez Cursor pour une journée classique de développement : écrire un composant, accepter des complétions, demander une petite refactorisation, corriger un test, relire un diff. Sa force est la continuité dans l’IDE. La fiche Cursor reste la comparaison la plus utile si votre décision porte sur l’environnement de code quotidien.

Prenez Antigravity pour une tâche qui ressemble à un mini-projet. Exemple : “analyse ce bug, propose un plan, modifie les fichiers nécessaires, lance les tests, vérifie dans Chrome, puis laisse un artifact avec capture et diff”. Ce workflow donne à Antigravity un terrain plus large que Cursor, surtout si vous voulez suivre plusieurs agents ou conversations.

Claude Code entre dans la comparaison si vous préférez le terminal et le raisonnement long. GitHub Copilot reste logique si votre équipe ne veut pas changer d’IDE ou travaille déjà avec une gouvernance GitHub. Windsurf mérite une comparaison si vous cherchez surtout une alternative IDE agentique. Lovable est plus adapté si vous partez de zéro et voulez créer une app web par conversation.

La limite d’Antigravity face à Cursor tient à la maturité perçue de l’édition quotidienne. Un hub agentique peut sembler lourd si vous voulez simplement finir un composant React. À l’inverse, Cursor peut sembler trop centré sur l’IDE si vous voulez piloter plusieurs agents, un navigateur et des artifacts.

Phrase de décision : gardez Cursor si l’IDE reste votre cockpit. Testez Antigravity si vous voulez que l’agent prenne une tâche complète, produise des preuves et reste sous permissions explicites.

Conclusion : Notre avis final sur Google Antigravity

Je recommanderais Google Antigravity en priorité aux développeurs qui savent écrire un ticket clair et relire un diff. Le profil idéal n’est pas forcément le meilleur expert IA. C’est quelqu’un qui connaît son repo, sait ce qu’un test doit prouver et peut arrêter l’agent quand le plan part trop large.

Pour un développeur solo, Antigravity peut réduire les allers-retours sur les bugs où il faut lire, modifier, lancer et vérifier. Le seuil d’achat raisonnable commence quand vous lancez plusieurs tâches agentiques par semaine et que le quota de base devient une friction réelle. Avant ce seuil, testez sans payer et comparez le temps de relecture au temps que vous auriez passé à coder.

Pour une startup, le bon usage est la délégation cadrée : bugs isolés, QA navigateur, documentation technique, refactorings courts, recherche dans le codebase, tests de non-régression. Les scheduled tasks peuvent devenir utiles si vous voulez demander à un agent de revenir sur un projet à heure fixe, mais il faut éviter de planifier des changements non surveillés sur une branche critique.

Pour une entreprise, la voie personnelle est rarement suffisante. La documentation Enterprise explique une intégration avec Gemini Enterprise Agent Platform, projet Google Cloud, IAM, facturation, endpoints global/eu/us, VPC Service Controls et request/response logging selon la configuration. C’est plus lourd. C’est aussi le niveau de sérieux attendu quand le code, les logs ou les contraintes de résidence des données entrent dans la décision.

Je le recommanderais moins à un profil non technique qui veut “créer une app sans coder” sans développeur pour relire. Antigravity peut aider, mais il parle le langage du repo, des commandes, des permissions, des worktrees et des artifacts. Si le besoin est un premier MVP visuel, Lovable ou Base44 seront souvent plus accessibles.

Phrase de décision : Antigravity est un bon achat si vous avez déjà un repo, des tâches concrètes et une discipline de review. Sans ce cadre, il accélère autant les bonnes idées que les mauvais changements.

Guide pour bien tester Google Antigravity

Le premier test doit être court. Choisissez un bug réel ou une amélioration visible : un formulaire qui valide mal, une page qui casse sur mobile, un test qui échoue, une route API qui renvoie le mauvais statut. Évitez les refontes globales. Elles consomment du quota et compliquent la relecture.

La consigne doit ressembler à un ticket. Donnez le symptôme, le résultat attendu, les fichiers probables, les commandes autorisées et la preuve demandée. Exemple : “Corrige le bug de validation email sur la page signup. Ne modifie pas le design global. Lance le test concerné. Ouvre la page en local avec le Browser Subagent et fournis une capture ou un artifact avant le verdict.”

Demandez un implementation plan avant l’exécution. La documentation sur les artifacts explique que l’agent peut produire un plan destiné à être relu avant les changements. C’est le moment de couper le scope. Si le plan touche un dossier entier pour corriger un champ, refusez ou commentez l’artifact.

Réglez les permissions avant de lancer. Pour une première session, autorisez les commandes nécessaires comme npm run test ou npm run build, gardez le reste en Ask, limitez les URLs à localhost et aux docs utiles, puis bloquez les chemins sensibles. C’est moins fluide. C’est plus propre.

Mesurez le résultat avec une question simple : est-ce que l’agent m’a rendu un diff plus facile à relire que si j’avais fait la tâche moi-même ? Si la réponse est oui sur deux ou trois tickets, Pro devient défendable. Si l’agent produit des plans trop larges, gardez le quota de base et améliorez vos consignes avant de payer.

Essayer Google Antigravity sur un vrai ticket →