Migrer de Gemini CLI vers Antigravity CLI : guide 2026
Plan de l'article
💡 En résumé (TL;DR)
- Google a annoncé la transition de l'expérience grand public Gemini CLI vers Antigravity CLI. L'accès Gemini Code Assist pour particuliers a pris fin le 18 juin 2026.
- Il faut distinguer l'usage grand public, l'API Gemini facturée séparément et les offres professionnelles ou d'entreprise : leurs calendriers et conditions peuvent différer.
- Une migration sûre ne consiste pas à remplacer un nom de paquet dans un script. Elle exige un inventaire des commandes, des règles d'autorisation, des extensions, des fichiers de contexte et des méthodes d'authentification.
- Ne copiez jamais aveuglément un dossier de configuration contenant des jetons. Recréez les identifiants dans la nouvelle CLI et testez les fonctions sur un dépôt jetable.
- Le verdict AngleFormation : conservez Gemini CLI uniquement lorsqu'un contrat ou une documentation Google applicable à votre compte le prévoit ; pour les usages individuels concernés, planifiez la bascule vers Antigravity CLI.
Gemini CLI a popularisé l'accès à un agent de codage directement depuis le terminal. Mais l'écosystème Google a évolué : en 2026, l'expérience destinée aux utilisateurs individuels bascule vers Antigravity CLI. Un ancien tutoriel d'installation Gemini CLI peut donc devenir trompeur s'il promet encore une authentification ou des quotas qui ne sont plus disponibles.
Ce guide explique comment conduire la transition sans perdre les habitudes de travail, sans exposer les secrets du poste et sans laisser une automatisation critique dépendre d'une commande obsolète.
Ce qui change réellement
Google a publié une annonce officielle sur la transition de Gemini CLI vers Antigravity CLI et une page de dépréciation pour Gemini Code Assist destiné aux particuliers. L'échéance annoncée pour cet accès individuel était le 18 juin 2026.
Cette évolution ne signifie pas que toutes les API Gemini ou tous les produits professionnels disparaissent. Avant toute action, identifiez le mode utilisé :
| Usage actuel | Question à vérifier | Action prudente |
|---|---|---|
| Connexion individuelle Google | l'accès Gemini Code Assist est-il encore autorisé ? | migrer vers Antigravity CLI |
| Clé Gemini API | le projet et la facturation sont-ils actifs ? | vérifier la documentation API et les coûts |
| Compte Google Cloud/entreprise | quelle édition et quelle date s'appliquent ? | suivre l'avis contractuel de l'organisation |
| Script CI/CD | la CLI est-elle appelée automatiquement ? | remplacer seulement après tests reproductibles |
| Extension ou serveur MCP | le protocole et les permissions sont-ils compatibles ? | valider chaque intégration séparément |
La documentation applicable au compte prime sur les captures d'écran d'un tutoriel ancien.
Étape 1 — Inventorier les usages de Gemini CLI
Ne désinstallez rien avant de savoir ce qui dépend de l'outil. Sur chaque poste ou runner, documentez :
- la méthode d'installation et la version ;
- le type d'authentification ;
- les fichiers de contexte du projet ;
- les paramètres globaux et locaux ;
- les extensions ou serveurs MCP ;
- les commandes autorisées automatiquement ;
- les scripts shell, tâches planifiées et pipelines qui appellent la CLI ;
- les dépôts où l'agent possède un accès en écriture ;
- les variables d'environnement utilisées.
Examinez les scripts sans afficher les valeurs secrètes :
command -v gemini || true
gemini --version || true
rg -n --hidden --glob '!node_modules' --glob '!.git' 'gemini' .
La dernière commande recherche les références dans le projet. Vérifiez chaque résultat : le mot peut aussi désigner une API ou un modèle, pas forcément la CLI.
Classer la criticité
Attribuez à chaque usage un niveau :
- faible : génération de brouillons dans un dépôt personnel ;
- moyen : revue de code ou tests sur une branche ;
- élevé : modification d'infrastructure, déploiement ou accès à des données sensibles.
Commencez par un usage fréquent, réversible et non critique.
Étape 2 — Sauvegarder la configuration sans copier les secrets
Une sauvegarde utile contient les paramètres nécessaires pour reconstruire l'environnement, mais pas des jetons en clair dans un dépôt Git.
Créez un inventaire séparé :
Projet : portail-client
CLI actuelle : Gemini CLI
Authentification : compte organisationnel
Fichiers de contexte : GEMINI.md à la racine
Outils autorisés : lecture, tests, formatage
Outils interdits : déploiement, suppression, accès production
MCP : dépôt Git interne, documentation
Propriétaire : équipe backend
Rollback : réinstallation version précédente + restauration config non secrète
Pour les credentials :
- identifiez leur emplacement sans en imprimer la valeur ;
- vérifiez s'ils ont été commis dans Git ;
- révoquez tout secret accidentellement exposé ;
- créez de nouveaux identifiants dans la cible ;
- stockez-les dans le gestionnaire de secrets de l'organisation.
Ne transférez pas un dossier de configuration entier si vous ne savez pas ce qu'il contient.
Étape 3 — Installer Antigravity CLI depuis la source officielle
Les noms de paquet, commandes et options peuvent évoluer rapidement. Utilisez la procédure publiée par Google au moment de l'installation et vérifiez l'origine du paquet avant d'exécuter une commande avec des droits élevés.
Principes de contrôle :
# Vérifier les outils présents avant la migration
node --version
npm --version
# Après installation selon la documentation Google
antigravity --version
antigravity --help
Si la commande officielle ou le nom du paquet diffère, ne forcez pas l'installation d'un paquet tiers au nom ressemblant. Les attaques par typosquatting ciblent précisément les outils populaires.
Une commande de type curl ... | bash donne immédiatement au script distant les droits de l'utilisateur. Préférez, lorsque Google le propose, un paquet signé, un gestionnaire avec origine vérifiable ou une archive dont l'intégrité peut être contrôlée.
Étape 4 — Recréer l'authentification et les autorisations
L'authentification confirme l'identité ; l'autorisation détermine ce que l'agent peut faire. Les deux doivent être revues.
Principe du moindre privilège
Pour un premier test :
- utilisez un dépôt de démonstration sans données client ;
- lancez la CLI avec un compte non administrateur ;
- limitez les répertoires accessibles ;
- demandez une confirmation avant toute commande ;
- interdisez les secrets de production ;
- n'autorisez pas
sudo, les commandes de suppression ou le déploiement ; - journalisez les actions et examinez les différences Git.
Une instruction dans un prompt n'est pas une barrière de sécurité. Les restrictions importantes doivent être appliquées par le système : permissions de fichiers, conteneur, identité cloud limitée, branche protégée et validation humaine.
Attention aux instructions non fiables
Un agent qui lit un dépôt, une page web, un ticket ou une documentation peut rencontrer des instructions malveillantes. C'est une forme de prompt injection. Ne donnez pas à l'agent la capacité de lire une source non fiable et d'exécuter ensuite une action sensible sans contrôle.
Étape 5 — Adapter le contexte du projet
Les fichiers de contexte servent à expliquer l'architecture, les commandes et les règles du dépôt. Ne supposez pas que chaque directive Gemini est comprise à l'identique par Antigravity.
Transformez le contexte en règles courtes et testables :
# Règles du projet
- Gestionnaire de paquets : pnpm.
- Exécuter `pnpm test` avant de proposer une modification.
- Ne jamais modifier les migrations de base déjà appliquées.
- Ne jamais lire ou afficher les fichiers `.env`.
- Ne pas déployer ; préparer uniquement un diff local.
- Demander une validation avant d'ajouter une dépendance.
Évitez les fichiers gigantesques qui mélangent historique, documentation et permissions. Placez les consignes stables dans le dépôt et gardez les secrets hors du contexte.
Étape 6 — Construire un protocole de comparaison
Testez l'ancienne et la nouvelle CLI sur les mêmes tâches, dans deux copies identiques du dépôt :
- expliquer un module sans le modifier ;
- corriger un test volontairement cassé ;
- ajouter une fonction simple avec tests ;
- refactoriser sans changer le comportement ;
- analyser une alerte de dépendance sans appliquer de mise à jour ;
- refuser une demande interdite par les règles du projet.
Mesurez :
| Critère | Mesure |
|---|---|
| Exactitude | tests réussis et comportement attendu |
| Portée du changement | fichiers modifiés inutilement |
| Sécurité | demandes de confirmation et respect des interdictions |
| Reproductibilité | même commande, résultat comparable |
| Coût et quotas | consommation observée sur le compte concerné |
| Temps humain | relecture et corrections nécessaires |
Ne validez pas une migration parce qu'une démonstration spectaculaire a réussi une fois. Elle doit réussir plusieurs scénarios et échouer proprement lorsque l'action n'est pas autorisée.
Étape 7 — Migrer les scripts et pipelines
Les appels non interactifs sont plus risqués, car une différence de code de sortie ou de format peut casser la chaîne.
Avant de modifier un pipeline :
- épinglez une version au lieu d'utiliser systématiquement
latest; - vérifiez les codes de sortie ;
- imposez un délai maximal ;
- capturez les journaux sans secrets ;
- limitez les droits du jeton CI ;
- créez une branche ou une pull request, jamais un déploiement direct ;
- prévoyez une étape d'approbation humaine.
Exemple de garde-fou shell générique :
set -euo pipefail
test -n "${CI_PROJECT_DIR:-}" || {
echo "Répertoire CI absent" >&2
exit 1
}
cd "$CI_PROJECT_DIR"
git status --porcelain
# Appel Antigravity à adapter à la documentation officielle.
# Le workflow doit produire une proposition, pas déployer.
pnpm test
git diff --check
Le commentaire volontaire remplace une commande hypothétique : copiez l'option réellement documentée par Google pour votre version.
Plan de bascule et retour arrière
Bascule progressive
- installer Antigravity sans supprimer Gemini ;
- tester un dépôt non critique ;
- recréer les extensions une par une ;
- migrer les usages interactifs ;
- migrer les automatisations après validation ;
- former les utilisateurs ;
- retirer les anciens secrets et paquets seulement à la fin.
Rollback
Documentez :
- la version précédente et sa source officielle ;
- la configuration non secrète sauvegardée ;
- la procédure de réauthentification ;
- les scripts qui doivent revenir à l'ancien binaire ;
- la durée pendant laquelle le retour arrière reste possible.
Un rollback n'est valide que s'il a été testé avant l'incident.
FAQ
Gemini CLI a-t-il complètement disparu ?
La transition officielle concerne l'expérience Gemini CLI destinée aux particuliers et l'accès Gemini Code Assist associé. Les API et offres professionnelles suivent leurs propres documentations. Vérifiez le type de compte avant de conclure qu'un usage précis est arrêté.
Puis-je conserver mes fichiers de contexte ?
Vous pouvez conserver leur contenu comme base, mais vérifiez la syntaxe, les noms de fichier et les règles réellement prises en charge par Antigravity. Profitez de la migration pour retirer les secrets et transformer les consignes vagues en règles testables.
Faut-il donner un accès administrateur à la CLI ?
Non dans la majorité des usages. Exécutez l'agent avec le minimum de privilèges et utilisez une élévation ponctuelle, visible et validée uniquement si une tâche le justifie.
Antigravity remplace-t-il Ansible, Terraform ou les tests ?
Non. Un agent peut aider à préparer ou expliquer une modification, mais l'infrastructure déclarative, les tests, les revues et les contrôles d'accès restent les mécanismes reproductibles de production.
Comment éviter qu'un agent modifie trop de fichiers ?
Travaillez sur une branche, limitez le répertoire accessible, demandez un plan avant l'écriture, imposez une confirmation, examinez git diff et exécutez les tests. Annulez la proposition si le périmètre dépasse la demande.
Conclusion
La transition de Gemini CLI vers Antigravity CLI doit être traitée comme une migration d'outil de développement, pas comme une simple mise à jour cosmétique. L'inventaire, la gestion des secrets, le test comparatif et le rollback sont plus importants que la vitesse d'installation.
Pour les PME, la règle est simple : l'agent peut accélérer l'analyse et la préparation d'un changement, mais les permissions système, les tests et l'approbation humaine doivent rester les sources de contrôle.