Claude 5.5 dans Google Antigravity : vérifier son accès et préparer la migration

La documentation d’Antigravity consultée le 4 octobre 2026 référence Claude Sonnet et Opus 5.5 en mode thinking. L’accès dépend de l’abonnement. Google annonce aussi le retrait de trois anciens modèles le 2 novembre.

Un accès réservé à certains abonnements

Le catalogue officiel réserve Claude 5.5 à Google AI Ultra et à Google AI Pro hors essai. Il exclut Free et Google AI Plus ainsi qu’Enterprise.

Cette information décrit le catalogue consulté. La page ne donne pas la date initiale d’ajout de ces modèles. Elle ne justifie donc pas de présenter le 4 octobre comme leur date de lancement dans Antigravity.

Trois modèles doivent quitter le catalogue

Google prévoit de retirer Sonnet 4.6 thinking et Opus 4.6 thinking ainsi que GPT-OSS-120b le 2 novembre 2026. Préparez le remplacement des modèles que vous utilisez.

Un changement en cours de tâche prend effet au tour suivant

Le modèle choisi se conserve entre les messages. Un changement pendant l’exécution s’applique aux tours suivants. Le tour en cours conserve le modèle précédent.

Comparer le travail produit avant de migrer

Commencez par relever les tâches qui dépendent de l’ancien modèle. Conservez quelques exemples de résultats attendus. Faites exécuter ces mêmes tâches avec le remplaçant envisagé. Examinez les modifications produites et les erreurs qui demandent une intervention.

Une disponibilité dans le catalogue ne mesure pas à elle seule la qualité pour votre projet. Vérifiez aussi l’accès effectif avec le compte utilisé par l’équipe. Prévoyez un retour à une version de travail connue lorsque vous comparez des modifications de code.

Une migration de modèle demande une comparaison reproductible

Notre analyse porte sur les dépendances d’un projet à son assistant de développement. Les consignes habituelles peuvent contenir des attentes adaptées à l’ancien modèle. Un changement de modèle peut donc demander une révision du protocole de travail. La présence du remplaçant dans le catalogue ne garantit pas qu’il reproduira les mêmes choix de code ou les mêmes explications. Il faut conserver une base de comparaison.

Séparer la modification proposée et son acceptation

Pour un exercice sur une correction de bug, le développeur peut enregistrer l’état de départ et le comportement attendu. Il examine ensuite les fichiers modifiés et les tests réellement exécutés. Une réponse qui affirme avoir corrigé le problème doit être confrontée au résultat observable. Si le modèle a changé pendant la session, cette information fait partie du compte rendu de l’essai. Elle permet de comprendre quelle étape a produit chaque modification.

Planifier la transition avant l’échéance annoncée

Le retrait d’un modèle oblige d’abord à retrouver les projets qui le sélectionnent. Il peut s’agir d’un choix visible dans l’interface ou d’une procédure conservée dans l’équipe. Le responsable vérifie ensuite l’accès au remplaçant avec le bon abonnement. Il choisit un lot de tâches et documente les écarts. Une transition peut être progressive sans confondre le travail en cours et les nouveaux essais.

Un résultat reproductible conserve les instructions et les fichiers de départ. Il décrit aussi les vérifications qui ont conduit à accepter le correctif. Cette démarche évite de s’appuyer seulement sur l’impression d’une meilleure réponse. Elle rend le choix du modèle discutable entre développeurs et facilite un retour à un état connu lorsque le nouvel essai ne répond pas au besoin.

Sources et prolongement

Sources : catalogue officiel d’Antigravity consulté le 4 octobre 2026 et journal des versions. L’échéance de retrait reste une date annoncée par Google.

Pour comprendre le modèle avant de changer d’environnement, consultez Claude Sonnet 5.5 et ses usages professionnels.

Les formations de David LACOUR aident les équipes à comparer les assistants et à organiser leur utilisation sur des tâches concrètes. Échangez sur votre projet de formation.