Google Antigravity : migrer les jobs locaux avant le 5 octobre

Google Antigravity : ce qui change vraiment

Cette migration concerne l’agent Antigravity géré dans la Gemini API. Il ne s’agit pas d’une mise à jour de l’IDE Antigravity installé sur un ordinateur.

Les deux produits reposent sur les mêmes fondations d’exécution, d’où ce nom commun. Ici, le changement porte sur l’identifiant d’agent que votre application envoie à l’Interactions API de Google et, pour certaines intégrations, sur les appels d’outils intégrés qu’elle doit traiter. Mettre l’IDE à jour ne modifie pas ce contrat d’API.

Le nouvel agent est antigravity-preview-09-2026. Son modèle de raisonnement par défaut est Gemini 3.8 Flash, même si le guide de l’agent Antigravity explique comment sélectionner un autre modèle compatible via agent_config. Notre précédent décryptage des agents gérés Gemini détaille l’espace de travail hébergé, les jobs en arrière-plan et la boucle d’outils. Cette migration intervient un cran plus bas : elle détermine si ces jobs peuvent encore démarrer et si leurs appels d’outils peuvent toujours s’exécuter.

Dans sa note de version du 17 septembre, Google distingue deux parcours de migration :

• Un job exécuté dans une sandbox distante, qui ne lit que output_text ou model_output, change simplement la chaîne de l’agent.
• Un job qui utilise local_environment ou analyse les étapes function_call doit aussi mettre à jour son adaptateur d’outils.

Toute la décision tient à cette distinction. L’adaptateur est la petite couche de code qui reçoit le nom et les arguments d’un outil, les valide, lance l’action locale, puis renvoie le résultat.

Le contrat des outils locaux change à cinq endroits

L’ancien agent traitait surtout les opérations sur les fichiers comme de grandes lectures ou écritures. L’agent de septembre leur attribue des noms et des arguments plus précis. Il fait aussi passer les clés d’arguments du snake_case au PascalCase.

Cinq familles de fonctions liées aux fichiers et à la recherche ont changé. Deux outils intégrés de la liste restent identiques. Voilà pourquoi un gestionnaire générique construit autour de write_file peut échouer alors même que le nouvel identifiant d’agent est correct.

Le nouveau contrat d’édition est également plus précis. Au lieu de renvoyer un fichier entier pour une petite modification, l’agent indique une plage de lignes, le texte qu’il s’attend à y trouver et son remplacement. Votre adaptateur doit refuser l’appel si TargetContent ne correspond plus au fichier. Sans cette protection, un job différé peut écraser une modification humaine plus récente.

Quels jobs exigent une vraie migration ?

Un fondateur solo avec un job de rapport distant

Prenons un job nocturne qui demande à Antigravity de collecter des données dans la sandbox de Google, d’enregistrer un rapport et de renvoyer le texte final. Votre application lit output_text sans jamais examiner les étapes sous-jacentes.

C’est la migration légère. Remplacez antigravity-preview-05-2026 par antigravity-preview-09-2026, exécutez un rapport représentatif en parallèle de l’ancien job, comparez le livrable final, puis basculez la planification. Inutile de reconstruire un répartiteur d’outils locaux que vous n’utilisez pas.

Une équipe plateforme qui exécute les outils sur ses propres machines

Considérons maintenant un worker de dépôt dont les appels d’outils s’exécutent dans votre propre runner. Il lit des fichiers, recherche du code, modifie la configuration et renvoie les résultats à l’interaction.

Cette équipe prend en charge la migration la plus importante. Le répartiteur doit reconnaître les nouveaux noms, valider les arguments en PascalCase, faire respecter les règles sur les chemins et les commandes, appliquer les modifications par plage de lignes en toute sécurité et renvoyer le résultat au format attendu par l’interaction. L’enjeu est la continuité : revues de code, génération de rapports et jobs de maintenance continueront de fonctionner après la disparition du point d’accès de mai.

Une équipe observabilité qui consomme chaque étape

Certaines applications exécutent tout à distance, mais recopient tout de même les étapes function_call dans un journal d’audit, une interface de suivi, une file d’approbation ou un tableau de bord des coûts. Elles ne se contentent donc pas de la sortie finale.

Même si Google exécute l’action intégrée sur le système de fichiers, votre parseur peut encore supposer la présence de write_file, path et content. Mettez à jour sa liste d’autorisation et ses fixtures pour éviter que le tableau de bord classe une véritable modification comme inconnue, en perde les arguments ou l’envoie vers la mauvaise règle d’approbation.

Un responsable des opérations avec des déclencheurs sans surveillance

Les déclencheurs planifiés sont les plus risqués : personne ne regarde au moment où l’appel part. Un déclencheur associe un agent, un environnement, un prompt et une planification cron. Si l’interaction enregistrée pointe encore vers l’agent de mai, la planification peut sembler saine alors que son exécution échouera après l’arrêt.

Recensez l’identifiant de l’agent dans chaque définition de déclencheur, pas seulement dans l’appel SDK de l’application principale. Lancez ensuite en parallèle un job pour chaque profil d’outils distinct. Un job de reporting et un job de réparation de dépôt ne constituent pas le même test de migration sous prétexte qu’ils utilisent tous deux Antigravity.

Un test minimal du contrat de modification de fichier

Le premier test le plus sûr ne demande aucun identifiant de production. Envoyez à votre adaptateur une fixture enregistrée qui reprend la forme d’un appel, modifiez un fichier jetable et vérifiez que seule la ligne visée a changé.

J’ai exécuté le code suivant avec Node, en reprenant le nom replace_file_content publié par Google et ses champs en PascalCase. Il s’agit d’un test local de l’adaptateur, pas d’un appel réel à la Gemini API.

import assert from "node:assert/strict";
import { mkdtempSync, readFileSync, writeFileSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";

function applyReplaceFileContent(call) {
  assert.equal(call.name, "replace_file_content");

  const {
    TargetFile,
    StartLine,
    EndLine,
    TargetContent,
    ReplacementContent,
  } = call.arguments;

  const lines = readFileSync(TargetFile, "utf8").split("\n");
  const current = lines.slice(StartLine - 1, EndLine).join("\n");
  assert.equal(current, TargetContent, "line window no longer matches");

  lines.splice(
    StartLine - 1,
    EndLine - StartLine + 1,
    ...ReplacementContent.split("\n"),
  );
  writeFileSync(TargetFile, lines.join("\n"));
}

const dir = mkdtempSync(join(tmpdir(), "antigravity-adapter-"));
const file = join(dir, "scheduled-job.env");
writeFileSync(file, "owner=ops\nstatus=old\nmode=scheduled\n");

applyReplaceFileContent({
  name: "replace_file_content",
  arguments: {
    TargetFile: file,
    StartLine: 2,
    EndLine: 2,
    TargetContent: "status=old",
    ReplacementContent: "status=ready",
  },
});

assert.equal(
  readFileSync(file, "utf8"),
  "owner=ops\nstatus=ready\nmode=scheduled\n",
);
console.log("PASS: line 2 changed from status=old to status=ready");

Le test a réussi. Plus important encore, il s’interrompt au lieu de modifier un contenu obsolète dès que l’on change la valeur TargetContent de la fixture.

Le calcul économique oppose le coût de migration aux jobs manqués

Google n’a pas annoncé de nouveau tarif par token avec cette migration d’agent. Le poste budgétaire qui évolue est le temps consacré à l’ingénierie et aux opérations.

Utilisez deux formules simples :

Pour un job distant qui ne consomme que la sortie, le travail d’ingénierie peut se limiter au changement de la chaîne de l’agent et à une exécution en parallèle. Pour une intégration avec des outils locaux, prévoyez les cinq familles de fonctions modifiées, les fixtures du parseur, les tests de sécurité et une exécution complète pour chaque profil de workflow distinct.

N’en déduisez pas une estimation horaire universelle et artificielle. Un générateur de rapports ciblé et un agent de développement local ne couvrent ni les mêmes outils, ni la même logique d’approbation, ni le même coût d’échec. Appliquez aux formules votre coût d’ingénierie complet et la valeur métier de chaque exécution. La finance disposera alors d’une vraie base de décision, pas d’une liste de fonctionnalités du fournisseur.

Ce qu’il faut dire sans détour

Le test local ci-dessus prouve que la fixture et l’adaptateur sont cohérents. Il ne garantit pas ce qu’un agent réel produira pour chaque prompt. Cette exécution ne disposait pas d’identifiants pour la Gemini API ; je n’ai donc pas prétendu lancer l’agent hébergé. Votre dernier contrôle doit reposer sur un appel de l’agent de septembre capturé dans un environnement jetable.

Cet événement n’impose pas non plus le même travail à tous les utilisateurs d’Antigravity :

• Agissez cette semaine si un job de production référence antigravity-preview-05-2026, utilise local_environment, analyse des étapes function_call ou s’exécute sans surveillance selon une planification.
• Suivez le parcours léger si le job tourne dans une sandbox distante et ne consomme que output_text ou model_output. Changez l’identifiant et lancez-le en parallèle.
• Partez directement du nouvel identifiant si vous évaluez encore l’API et n’avez aucun job fondé sur l’agent de mai en production.
• Ignorez cette migration si vous utilisez uniquement l’IDE Antigravity sans appeler l’agent géré via la Gemini API.

Ce qu’il faut faire lundi

Confiez l’inventaire à une personne. Recherchez l’identifiant de l’agent de mai et les anciens noms d’outils dans la configuration déployée, les définitions de déclencheurs, les variables d’environnement, les tableaux de bord et les fixtures. Répartissez les résultats entre les jobs limités à la sortie et ceux qui nécessitent un adaptateur avant de modifier le code.

Migrez ensuite un job représentatif de chaque liste. Gardez l’ancienne planification en pause, mais disponible le temps d’inspecter l’exécution de septembre, migrez les jobs restants par famille de workflows et créez une alerte sur les appels d’outils inconnus jusqu’au 5 octobre. Le livrable du lundi n’est pas une présentation. C’est un inventaire avec des responsables, une exécution en parallèle réussie et une date pour chaque job restant.

Pour recevoir d’autres analyses claires sur les changements capables de perturber des workflows réels, inscrivez-vous à la newsletter.