Agents gérés Gemini API : les contrôles à poser avant la production

La mise à jour apporte de nouveaux points de gouvernance, mais elle ne dispense ni de tests ni d’autorisation. Google a annoncé le 28 juillet 2026 que antigravity-preview-05-2026 adopte Gemini 3.6 Flash par défaut. Les autres nouveautés mises en avant sont les hooks d’environnement, la sélection du modèle, les contrôles de budget, les déclencheurs planifiés et l’accès gratuit.

Google décrit une interaction gérée capable de coordonner le raisonnement, l’exécution de code, l’installation de paquets, le traitement de fichiers et la récupération d’informations sur le Web dans un bac à sable cloud isolé. Ce périmètre fonctionnel est confirmé. Il n’autorise pas automatiquement les données sensibles, les identifiants externes ou les actions ayant des conséquences importantes.

CreatikLab recommande donc de commencer par une mission limitée, réversible et vérifiable. Le modèle doit être évalué sur des cas connus. Les hooks doivent traduire une politique écrite. La planification doit avoir un propriétaire. Les effets financiers, juridiques ou destinés aux clients doivent rester soumis à une validation explicite.

Google indique que le nouvel agent par défaut s’applique sans modification du code lors de l’interaction suivante. Une intégration peut ainsi continuer à répondre tout en produisant des choix d’outils ou des résultats différents. Cette transition mérite une campagne de régression, même si l’appel API reste inchangé.

Gemini 3.6 Flash est présenté comme équilibré pour le raisonnement, le code et l’utilisation d’outils. Google maintient Gemini 3.5 Flash pour les workflows agentiques généraux de la génération précédente et décrit Gemini 3.5 Flash-Lite comme le choix de plus faible coût et latence dans la famille 3.5. agent_config.model permet une sélection explicite.

Ces indications orientent un test comparatif, mais elles ne prédisent pas le résultat d’un métier particulier. Il faut rejouer les mêmes entrées, mesurer les erreurs, observer les outils sollicités et compter les corrections humaines. Une configuration peut être fixée lorsque la reproductibilité est nécessaire.

• Prévoir des cas ordinaires, des cas limites et des demandes interdites.
• Conserver les échecs dans le jeu de régression.
• Examiner les actions intermédiaires et les fichiers produits.
• Relancer l’évaluation après toute modification du modèle, des instructions, des hooks, des outils ou des paquets.

Google annonce des déclencheurs planifiés pour les agents gérés. Pour une équipe, la question centrale est moins la fréquence que le droit d’exécuter une tâche sans lancement manuel. Une première planification devrait se limiter à la production d’un brouillon, d’un inventaire ou d’un rapport soumis à revue.

Avant d’automatiser, décrivez le scénario à rebours. Quel résultat doit arriver au réviseur ? Quelle entrée est autorisée ? Comment reconnaître une sortie absente, ancienne ou mal formée ? Qui peut suspendre le flux ? Ces réponses relèvent de la conception opérationnelle de l’organisation.

Les contrôles de budget annoncés par Google constituent un point de pilotage distinct. Ils ne doivent pas être présentés comme une garantie du coût global. Testez la configuration actuelle sur des cas représentatifs et conservez un suivi de l’usage en dehors des fichiers que l’agent peut modifier.

1. Exécuter d’abord le processus manuellement.
2. Définir des critères de revue avant le premier test.
3. Programmer ensuite un résultat sans action externe.
4. Prévoir un propriétaire pour les sorties invalides ou manquantes.
5. N’ouvrir des droits supplémentaires qu’après une évaluation stable.

Les hooks d’environnement fournissent les points de contrôle les plus directs de cette version. Google explique que des scripts personnalisés peuvent intervenir avant ou après un appel d’outil dans le bac à sable. La configuration repose sur .agents/hooks.json et sur des événements associés aux phases précédant ou suivant l’exécution.

L’exemple de Google montre qu’un gestionnaire préalable peut refuser une opération. L’appel est alors ignoré et le motif peut rejoindre le contexte du modèle. Un gestionnaire postérieur peut vérifier ou mettre en forme un résultat. Des gestionnaires HTTP peuvent également communiquer avec un endpoint externe.

Un hook ne remplace toutefois pas la politique qu’il doit appliquer. Il faut établir une liste courte d’outils admis, identifier les actions exigeant une validation et décider quelles traces conserver. Une règle conçue pour une mission ne doit pas être réutilisée sans examen dans un contexte différent.

• Observer les appels tentés avant d’élargir les permissions.
• Autoriser uniquement les opérations nécessaires à la mission.
• Refuser par défaut les actions inconnues ou destructrices.
• Vérifier après exécution la présence du résultat attendu.
• Conserver les traces importantes hors de l’espace modifiable par l’agent.
• Tester les retards, indisponibilités et réponses invalides des gestionnaires.

Une réponse finale bien écrite ne prouve pas que le chemin d’exécution était acceptable. La cartographie doit couvrir les instructions, les outils, le code, les paquets, les fichiers, les contenus Web récupérés et les connexions externes. Elle doit aussi montrer ce qui peut sortir du bac à sable.

1. Recenser les entrées autorisées et leurs propriétaires.
2. Classer les outils en lecture, écriture réversible, écriture irréversible et communication externe.
3. Définir les paquets admis et la méthode de revue des changements.
4. Limiter les chemins de fichiers accessibles et les destinations d’export.
5. Identifier chaque API, identifiant ou processus externe.
6. Attribuer la revue, l’interruption, la récupération et l’escalade.

Google qualifie le bac à sable d’isolé. Cette description ne constitue pas une certification universelle. Chaque organisation doit déterminer les données acceptables, la manière de fournir les identifiants et les informations qui peuvent apparaître dans les journaux ou les fichiers générés.

La carte doit enfin matérialiser les changements de niveau d’autorisation. Préparer un rapport dans un espace contrôlé et modifier une plateforme active sont deux opérations différentes. La seconde exige une décision propre, même si la première a réussi.

Un pilote doit permettre de refuser le lancement lorsque les résultats sont insuffisants. Commencez par un critère d’acceptation rédigé avant l’exécution. Une équipe pourrait, par exemple, demander l’analyse d’une copie approuvée de documents techniques et comparer le rapport avec sa procédure manuelle.

La mesure doit couvrir tout le workflow. Un texte convaincant ne suffit pas si des outils non autorisés ont été sollicités ou si une interruption laisse des fichiers ambigus. Les cas d’échec doivent être conservés pour vérifier les versions suivantes.

• Réussite selon le test d’acceptation établi à l’avance.
• Appels d’outils tentés, admis et refusés par catégorie.
• Erreurs factuelles, structurelles et violations des règles métier.
• Corrections, validations et actions de récupération humaines.
• Temps entre une entrée valide et un résultat prêt à revoir.
• Usage observé sur l’ensemble du workflow.
• État des fichiers et des systèmes après une interruption.
• Utilité opérationnelle constatée sans garantie de rendement.

Ventilez les observations par modèle, version d’instruction, politique de hooks et configuration d’outils. Une moyenne favorable peut masquer un défaut rare mais critique. Le lancement doit dépendre du risque résiduel le plus important, pas uniquement du résultat moyen.

L’annonce de Google ne décrit pas de connexion native entre Managed Agents et Google Ads. Elle n’accorde pas non plus de permissions sur un compte publicitaire. Une intégration éventuelle demanderait une authentification distincte, un périmètre limité et des règles d’approbation.

Pour un premier essai, une équipe peut fournir un export approuvé. Le mandat pourrait porter sur la cohérence des noms, les champs manquants, le regroupement d’anomalies ou la préparation de questions pour un spécialiste. Ce sont des propositions d’architecture CreatikLab, pas des fonctions promises par Google.

Les outils capables de modifier les enchères, budgets, ciblages ou créations actives doivent rester hors de portée de ce test. Le rapport doit également être confronté aux objectifs de campagne, à la qualité des conversions, aux marges et aux contraintes de marque.

Pour découvrir l’accompagnement humain de CreatikLab en publicité, consultez la page du service Google Ads. Ce lien ne présente pas ce service comme une fonctionnalité des agents gérés.

1. Choisir une mission unique avec un résultat objectivement vérifiable.
2. Cartographier les données, outils, paquets, fichiers et connexions.
3. Comparer les modèles et fixer la configuration validée si nécessaire.
4. Observer les hooks avant d’activer les refus automatiques.
5. Maintenir les opérations destructrices hors de portée.
6. Tester les contrôles de budget sans promettre un coût total.
7. Planifier d’abord des workflows qui produisent uniquement des propositions.
8. Conserver les traces d’audit hors de l’espace éditable par l’agent.
9. Simuler les interruptions, sorties invalides et dépendances indisponibles.
10. Imposer une validation humaine pour les effets importants.
11. Vérifier les conditions actuelles du projet avant le lancement.
12. Rejouer l’évaluation après chaque évolution du workflow.

Préparez une fiche d’une page avec la mission, les outils actuels, les données admises, la fréquence envisagée, le test d’acceptation et les actions interdites. Ouvrez ensuite MarketingPro, adressez cette fiche à Lia et demandez une revue cadrée du workflow Gemini ou du cas publicitaire. Précisez la décision à prendre et les risques que vous souhaitez examiner.

Quelles nouveautés Google a-t-il annoncées ?

Google indique que antigravity-preview-05-2026 utilise désormais Gemini 3.6 Flash par défaut. L’annonce présente aussi les hooks d’environnement, le choix explicite du modèle, des contrôles de budget, des déclencheurs planifiés et un accès gratuit.

Faut-il modifier le code pour adopter le nouveau modèle par défaut ?

Google précise que l’agent nommé passe à Gemini 3.6 Flash lors de l’interaction suivante sans modification du code. Une équipe peut également sélectionner un modèle compatible avec agent_config.model.

Quel est le rôle des hooks d’environnement ?

Ils permettent d’exécuter des gestionnaires personnalisés avant ou après les appels d’outils dans le bac à sable. Google cite notamment le blocage, la validation et l’audit.

Les contrôles de budget garantissent-ils le coût total ?

Aucune garantie de ce type ne doit être déduite. Google annonce des contrôles de budget, mais le workflow complet doit être testé et surveillé selon la configuration actuelle du projet.

Que signifie l’accès gratuit pour une équipe ?

Cela confirme l’ajout d’un accès au niveau gratuit. Cette information ne suffit pas, à elle seule, pour prévoir l’économie d’une charge de production ou garantir qu’un usage donné restera gratuit.

Les agents gérés intègrent-ils nativement Google Ads ?

L’annonce ne décrit pas d’intégration native. Toute connexion à un compte publicitaire nécessiterait une authentification, des permissions et des contrôles distincts. Un export approuvé offre un premier périmètre plus prudent.