Youssef ELMIZEB · fondateur de tekfold.com · mis à jour le 26 octobre 2026
Antigravity n’est pas un éditeur de code auquel on aurait ajouté une fenêtre de chat : c’est un environnement conçu dès le départ pour que des agents exécutent des tâches — ouvrir un navigateur, taper dans un terminal, éditer des fichiers — pendant que tu supervises. La version 2.0 pousse la logique plus loin avec l’exécution d’agents en parallèle et la planification de tâches. Encore faut-il comprendre ce qui est réellement déléguable, et ce qui doit rester sous ta responsabilité.
Ce qui change par rapport à un assistant de code classique
Dans un assistant intégré, tu restes en boucle : tu poses une question, tu colles un extrait, tu acceptes le patch. Dans un environnement agentique, tu donnes un objectif ; l’agent construit un plan, consulte la documentation en ligne, exécute des commandes, lit la sortie d’erreur, corrige, puis te rend un résultat. Les outils exposés à l’agent — navigateur, terminal, éditeur, captures d’écran — sont la vraie différence : c’est ce qui lui permet de vérifier son propre travail au lieu de te demander à chaque étape.
| Type d’outil | Ce qu’il fait | Parallélisme | Revue humaine | Idéal pour |
|---|---|---|---|---|
| Assistant de code dans l’éditeur | Suggestion et patch à la demande | Aucun | À chaque modification | Écriture ligne par ligne, refactor ciblé |
| IDE agentique (type Antigravity) | Tâches de bout en bout avec outils | Plusieurs tâches simultanées | En fin de tâche, sur un diff | Fonctionnalités complètes, prototypes |
| Agent cloud autonome | Exécution sur branche distante, déclenchée par ticket | Élevé | À la revue de pull request | Maintenance, corrections répétitives |
| Automatisation visuelle (no-code) | Chaînes d’étapes prédéfinies | Limité au nombre de scénarios | À la conception | Processus stables, non liés au code |
Le bon choix dépend d’une seule question : ton besoin est-il ouvert (« construis une application qui fait ça ») ou figé (« exporte chaque vendredi ce rapport ») ? Pour le besoin figé, un agent autonome est du suréquipement ; pour le besoin ouvert, un assistant classique te fera perdre du temps en allers-retours.
Créer une application : le déroulé qui fonctionne
La réussite d’une tâche agentique se joue presque toujours sur la qualité du cadrage initial. Un prompt du type « fais-moi une application de gestion de tâches » produit un squelette générique que tu passeras plus de temps à corriger qu’à écrire. La séquence qui marche, en revanche, tient en quatre temps :
- Spécification courte et vérifiable : périmètre, utilisateurs, données manipulées, et surtout le critère de « c’est fini ».
- Plan demandé avant le code : tu valides l’architecture en quinze secondes plutôt qu’après vingt minutes de génération.
- Exécution par étapes, avec point de contrôle : base de données, puis interface, puis branche de calcul — jamais tout dans une seule trajectoire.
- Revue sur le diff et exécution réelle : tu lances l’application toi-même. Un agent qui déclare « c’est testé » sans avoir lancé le serveur ne l’a pas testé.
# Spécification à coller en tête de tâche (à adapter à ton projet)
Objectif : appli web de suivi de dépenses, monopage, sans compte.
Fini quand :
- l'ajout d'une dépense fonctionne sans rechargement
- le total mensuel se recalcule immédiatement
- les données survivent à un rafraîchissement (localStorage)
- `npm run build` passe sans erreur
Interdits : base de données distante, dépendance ajoutée
sans l'avoir justifiée dans un commentaire
À faire avant de coder : propose l'arborescence des fichiers
et attends ma validation.Cette structure est volontairement contraignante : un agent performant travaille mieux avec des frontières explicites qu’avec de la liberté. Et chaque condition de « fini » doit être vérifiable automatiquement : un build qui passe, une fonction qui répond — jamais « l’interface est agréable ».
Automatiser des tâches quotidiennes : utile, mais sous contrôle
La seconde promesse d’Antigravity concerne les tâches répétitives : trier des fichiers, nettoyer un dossier de téléchargements, organiser des onglets, produire un rapport périodique. Le gain existe réellement, à condition de respecter trois règles :
- Périmètre minimal : l’agent doit n’avoir le droit que sur un dossier de travail, jamais sur l’ensemble du disque. Un chemin mal interprété transforme un tri en suppression.
- Mode répétition d’abord : exécute la tâche une fois, relis le journal, puis seulement mets en planification. Lancer directement une tâche récurrente revient à automatiser une erreur.
- Journalisation et annulation : exige un rapport des actions (fichiers déplacés, renommés, supprimés) et garde une poubelle de sécurité pendant plusieurs semaines.
Point d’attention sur les tâches web (nettoyage d’onglets, remplissage de formulaires) : l’agent manipule des sessions connectées. Ferme les onglets sensibles avant, et n’autorise jamais une tâche planifiée à intervenir sur un profil contenant des comptes bancaires ou professionnels.
Exécuter plusieurs agents en parallèle : quand ça vaut le coup
L’exécution parallèle est la fonctionnalité la plus séduisante et la plus facile à mal utiliser. Elle paie réellement quand les tâches sont indépendantes et indépendamment vérifiables : trois modules séparés, une correction de bugs sans chevauchement, un prototype à partir de trois approches différentes pour comparer.
Elle devient contre-productive dans trois situations : les tâches partagent les mêmes fichiers (les diffs se marchent dessus), il n’existe pas de critère de validation par tâche (tu dois tout relire de toute façon), ou la consommation de tokens devient incontrôlable. Bon réflexe : limite-toi à deux ou trois tâches parallèles au début, avec un budget par tâche, et n’augmente le nombre qu’après avoir vérifié que ta revue reste tenable.
Si ton besoin est davantage « connecter des services » que « écrire du code », le générateur de workflow n8n reste plus adapté : tu obtiens une chaîne lisible et maintenable, sans dépendre de la qualité d’une trajectoire d’agent. Les autres ressources sont regroupées sur la page des outils gratuits.
Questions fréquentes
Faut-il savoir programmer pour utiliser Antigravity ?
Pour l’automatisation de tâches et les prototypes, non : la spécification en langage naturel suffit. Pour aller au-delà — comprendre le diff, corriger une régression, reprendre la main sur l’architecture — la lecture de code reste indispensable. Sans elle, tu ne peux pas valider le résultat.
Comment éviter que l’agent produise du code inexploitable ?
Impose des critères de finition vérifiables (build, tests, pas de dépendance injustifiée) et demande le plan avant l’exécution. Deuxièmement, limite la portée de chaque tâche : un agent qui touche à dix fichiers en même temps est beaucoup plus difficile à relire.
Que faire si la tâche part dans la mauvaise direction ?
Interromps plutôt que de corriger dans la foulée : annule, reformule la spécification avec la contrainte manquante, relance. Corriger une trajectoire erronée à moitié terminée produit presque toujours un mélange des deux approches.
Les agents en parallèle coûtent-ils beaucoup plus cher ?
Ils multiplient la consommation de tokens par le nombre de tâches actives, sans réduction automatique. Fixe un budget par tâche et un budget global : sans ces deux compteurs, tu découvres le coût au moment de la facture.
À retenir : un environnement agentique déplace ton travail de l’écriture vers la spécification, la planification et la revue. Décris précisément ce qui signifie « c’est fini », fais valider le plan avant le code, exécute deux tâches en parallèle au maximum tant que ta revue n’est pas rodée, et garde toujours une exécution manuelle avant toute mise en planification. Pour d’autres approches d’automatisation, le hub Tech & IA propose des alternatives complémentaires.
