La gouvernance d'agents est le vrai produit de Next '26
Memory Bank, Sessions, Identity, Registry, Gateway, Anomaly Detection, Security Dashboard : Google industrialise ce que personne n'avait pris au sérieux. Pourquoi votre roadmap agentique doit s'aligner sur cette pile avant Q3 2026.
À Next '26, Google n'a pas lancé un agent. Il a lancé l'infrastructure pour les gouverner.
C'est cette phrase que la plupart des comptes-rendus de Las Vegas n'ont pas écrite. Les analyses se sont concentrées sur les nouveaux modèles Gemini, les fonctionnalités ADK, les intégrations MCP. Elles ont manqué l'essentiel : la couche la plus dense en annonces de la Gemini Enterprise Agent Platform n'est pas « Build ». Ce n'est pas « Scale ». C'est « Govern ».
Sept nouvelles capacités annoncées en deux jours, toutes orientées vers une seule obsession : reprendre le contrôle sur des agents qui, laissés à eux-mêmes, deviendraient rapidement le nouveau shadow IT de l'entreprise. Un chiffre pour contextualiser : selon les données partagées dans une session CTO de Next '26, les organisations qui ont déployé plus de 10 agents IA en production sans framework de gouvernance centralisé ont enregistré en moyenne 3,2 incidents de conformité non détectés dans leurs 6 premiers mois. Ce n'est pas un risque théorique. C'est une réalité déjà documentée chez les early adopters.
Le signal discret que presque tout le monde a raté
La Gemini Enterprise Agent Platform s'articule autour de quatre couches : Build, Scale, Govern, Optimize. À première vue, l'ordre semble logique : on construit d'abord, on gère ensuite. Mais si vous regardez la densité des annonces par couche à Next '26, quelque chose frappe immédiatement.
La couche Govern concentre huit composants détaillés : Agent Gateway, Agent Identity, Agent Registry, Agent Anomaly Detection, Model Armor, Agent Policy, Agent Security et Agent Compliance. Build en a quatre. Scale, quatre également. Ce déséquilibre n'est pas un accident de présentation.
C'est un signal stratégique. Google ne dit pas « voici comment déployer des agents ». Il dit « voici comment ne pas perdre le contrôle de ce que vous avez déjà déployé ».
Le spectre du Shadow Agent
Pour comprendre pourquoi Google investit autant dans la gouvernance, il faut se souvenir d'un moment similaire : l'avènement du shadow IT au milieu des années 2000. Des départements entiers adoptaient Dropbox, Slack ou des outils SaaS sans impliquer la DSI. Les données s'échappaient. La gouvernance était impossible. Le rattrapage a pris des années.
Les agents IA reproduisent exactement ce scénario, mais à une vitesse et une échelle sans comparaison. Les slides de Next '26 le montrent clairement : d'un côté, l'« Agent sprawl » une collaboration non gouvernée entre agents qui conduit à un accès illimité aux données. De l'autre, le « Tool/MCP sprawl » des intégrations non sécurisées aux systèmes d'entreprise via des protocoles ouverts.
La différence avec le shadow IT : les agents agissent de manière autonome. Ils ne font pas que stocker des fichiers dans le mauvais endroit. Ils exécutent du code, accèdent à des API, modifient des données, orchestrent d'autres agents. Sans identité, sans registre, sans passerelle de contrôle, la piste d'audit devient inexistante.
La question que tout CISO devrait poser aujourd'hui : « Combien d'agents tournent actuellement dans mon organisation, et qui est responsable de chacun d'eux ? » Dans les organisations que j'accompagne, la réponse honnête quand on creuse est rarement satisfaisante. Le plus souvent, la liste des agents en production est incomplète, les propriétaires sont flous, et les accès accordés lors des POC n'ont jamais été revus.
Les sept briques d'une gouvernance agentique industrielle
Ce qui distingue les annonces de Next '26 de la communication marketing habituelle, c'est le niveau de concrétude technique. Chacune des sept capacités suivantes répond à une faille spécifique que Google a clairement identifiée dans les déploiements agentiques en production.
1. Agent Memory Bank La mémoire devient une surface d'audit (#6)
La Memory Bank stocke les mémoires long terme issues des conversations, avec des Memory Profiles à faible latence. Elle intègre une base vectorielle prête à l'emploi, une génération mémorielle asynchrone, et la possibilité de définir des TTL et une compaction automatique.
L'angle souvent évoqué : personnalisation, continuité des interactions. L'angle qu'on sous-estime : toute mémoire persistante est une surface auditable. Savoir ce qu'un agent « se rappelle » de chaque utilisateur, c'est la fondation d'une conformité RGPD agentique. Les DPO qui n'ont pas encore intégré la mémoire d'agent dans leur cartographie des traitements de données personnelles sont en retard sur le risque réglementaire.
2. Agent Sessions La traçabilité n'est plus optionnelle (#7)
Les Sessions permettent le stockage de l'historique conversationnel avec des Custom Session IDs liés directement au CRM ou à la base de données interne de l'entreprise. TTL paramétrable jusqu'à 365 jours. Approvisionnement automatique pour les agents déployés via Agent Engine.
La conséquence opérationnelle est directe : chaque interaction d'un agent avec un utilisateur devient traçable de bout en bout, liée à une identité métier, rejoignable dans n'importe quel outil d'audit. C'est le passage d'un agent « stateless » à un agent qui laisse une trace vérifiable. Pour toute organisation soumise à des exigences d'audit (secteur financier, santé, retail à grande échelle), cette capacité cesse d'être optionnelle dès le premier déploiement en production.
3. Agent Identity La fin du « qui a fait quoi ? » (#8)
Chaque agent reçoit un identifiant cryptographique unique, associé à une piste d'audit complète de ses actions. Concrètement, l'identité est représentée sous la forme d'un principal standardisé (principal://agents.global.org-[id]...) qui peut être référencé dans les politiques IAM existantes.
C'est la pièce maîtresse du dispositif. Sans identité unique et vérifiable, toutes les autres couches de gouvernance restent théoriques. L'Agent Identity répond à la question fondamentale que pose chaque audit de sécurité : « Quel agent, avec quelles permissions, a effectué cette action, à quelle heure, sur quelles données ? »
Un parallèle utile : quand les entreprises ont commencé à déployer des comptes de service applicatifs, la DSI a rapidement réalisé que ces comptes sans visage étaient devenus le vecteur de choix pour les mouvements latéraux lors d'incidents. Les agents sans identité reproduisent exactement ce risque, à une échelle bien supérieure.
4. Agent Registry L'App Store de la gouvernance agentique (#9)
Le Registry est une bibliothèque centrale d'agents et d'outils approuvés, indexée et gouvernée. Il centralise les agents (internes, Google-made, marketplace), les serveurs MCP et les endpoints en un seul point de contrôle. Les Auth Providers permettent de définir les mécanismes d'authentification (API Key, OAuth 2-legged ou 3-legged) pour chaque cible.
L'enjeu stratégique : sans registre, chaque équipe construit ses propres agents avec ses propres outils, ses propres credentials, ses propres politiques. Avec le Registry, l'entreprise dispose d'un catalogue contrôlé où chaque agent est approuvé, versioné et attribuable à un responsable métier. C'est la différence entre une bibliothèque de composants logiciels gouvernée et un dossier partagé où chacun dépose ce qu'il veut.
5. Agent Gateway Le point de contrôle unifié (#10)
L'Agent Gateway est le point d'entrée unique pour tous les flux entre agents et systèmes externes. Il embarque Model Armor, la couche de protection contre l'injection de prompts et les fuites de données. Toute requête sortante passe par ce point névralgique, où les politiques de sécurité sont appliquées de manière systématique.
Pour un CISO, la Gateway répond à la question la plus urgente : « Comment empêcher un agent de devenir le vecteur d'une exfiltration de données ou d'une attaque par injection ? » La réponse n'est pas dans le prompt. Elle est dans l'infrastructure. Un prompt-guardrail peut être contourné par une entrée malveillante. Un firewall d'infrastructure ne le peut pas.
6. Agent Anomaly Detection Quand l'IA surveille l'IA (#11)
L'Anomaly Detection fonctionne en temps réel, combinant des modèles statistiques et un LLM-as-judge pour détecter les comportements suspects. Ce double registre est fondamental : les modèles statistiques capturent les déviations quantitatives (volume de requêtes, patterns d'accès inhabituels), pendant que le LLM-as-judge évalue la sémantique des actions.
Le cas d'usage critique : un agent compromis ou manipulé via une injection de prompt se comporte différemment de sa baseline. L'Anomaly Detection le détecte avant que le dommage ne soit irréversible. Dans les organisations que j'accompagne qui opèrent des agents avec accès aux données financières ou client, ce type de détection comportementale est le seul moyen d'attraper les compromissions qui contournent les contrôles d'accès statiques.
7. Agent Security Dashboard La visibilité comme prérequis (#12)
Le Security Dashboard intègre Security Command Center pour la détection automatique de vulnérabilités sur trois plans : les agents eux-mêmes, les modèles sous-jacents et les OS d'exécution. C'est une vue consolidée qui permet d'identifier les failles avant que des acteurs malveillants ne les exploitent.
L'intérêt de l'intégration avec Security Command Center ne doit pas être sous-estimé : les organisations qui utilisent déjà GCP pour leur posture de sécurité n'ont pas besoin de déployer un outil tiers. La gouvernance agentique s'intègre dans leur workflow existant. C'est un argument commercial fort pour les clients GCP mais aussi un signal d'architecture clair pour ceux qui envisagent une stratégie multi-cloud : la gouvernance agentique va devenir un critère de plateforme, pas un add-on.
Gouverner par l'infrastructure, pas par les prompts
L'une des formules les plus marquantes de Next '26 provient d'une session technique adressée aux architectes et CTO : « Govern through Infrastructure, Not with Prompts ».
Cette phrase résume une prise de position fondamentale. Depuis deux ans, la majorité des équipes qui déploient des agents IA tentent de les « contrôler » par des instructions dans le système de prompt. « Tu ne dois jamais accéder à ces données. » « Tu dois toujours vérifier avec un humain avant d'agir. » Ces guardrails textuels sont fragiles : ils peuvent être contournés par injection, dégradés par un changement de modèle, ou simplement ignorés dans des scénarios edge case.
La gouvernance par infrastructure, c'est autre chose : des politiques qui s'appliquent indépendamment du comportement du modèle, des contrôles d'accès qui ne peuvent pas être « expliqués » à un agent pour les contourner, des alertes qui ne dépendent pas de la bonne volonté du LLM. C'est la différence entre croire qu'un employé ne volera pas et lui retirer l'accès aux zones qui ne concernent pas son périmètre.
Google articule cette gouvernance autour de trois axes :
Visibility (Visibilité) : quels agents tournent dans mon domaine ? Qui en est responsable ? À quelles données ont-ils accès ?
Control (Contrôle) : comment restreindre un agent aux seules informations autorisées pour son utilisateur ? Comment arrêter un agent compromis en temps réel ?
Security (Sécurité) : comment réduire le risque d'actions malveillantes ? Comment détecter une activité anormale ? Comment assurer la conformité réglementaire ?
Ce que cela change concrètement pour votre roadmap
Si votre organisation prévoit de déployer des agents en production avant Q3 2026, ces annonces ont des implications directes sur la façon dont vous devriez planifier la prochaine phase.
Pour les CTO et architectes
Revoyez votre architecture agentique à la lumière de la pile Govern. Si vous avez conçu des agents avec des guardrails purement prompt-based, identifiez dès maintenant les contrôles que vous devrez migrer vers de l'infrastructure. La question « comment cet agent s'authentifie-t-il auprès des services qu'il appelle ? » doit avoir une réponse claire avant tout passage en production.
L'Agent Registry doit être votre premier chantier. Avant d'étendre le nombre d'agents déployés, assurez-vous d'avoir un catalogue contrôlé. Chaque agent doit être versioné, attribué à une équipe, et doté d'un cycle de vie défini. Sans cela, vous construisez sur du sable.
Pour les CDO
La Memory Bank et les Sessions changent fondamentalement votre relation aux données clients dans un contexte agentique. Les politiques RGPD qui s'appliquent à vos CRM et bases de données doivent maintenant couvrir les mémoires persistantes des agents. Définissez les TTL, les politiques de purge, et les droits d'accès à ces mémoires avant le déploiement.
La question du consentement prend une nouvelle dimension : un utilisateur qui interagit avec un agent accepte-t-il implicitement que ses préférences, ses habitudes et ses demandes soient mémorisées et utilisées pour personnaliser de futures interactions ? La réponse légale n'est pas encore tranchée dans la plupart des juridictions européennes. Anticipez.
Pour les CISO
L'Agent Gateway et l'Anomaly Detection constituent votre priorité absolue. Sans passerelle de contrôle centralisée, chaque agent est une surface d'attaque potentielle. Le risque d'injection de prompt systémique où un acteur malveillant manipule un agent via ses données d'entrée pour lui faire exécuter des actions non autorisées est aujourd'hui sous-estimé par la grande majorité des organisations.
Intégrez l'Anomaly Detection dans votre stratégie SIEM dès maintenant. Les agents qui accèdent à des données financières, de santé ou personnelles doivent être surveillés avec le même niveau de rigueur que vos accès administrateurs privilégiés. Et posez-vous cette question dès aujourd'hui : si demain un régulateur vous demande de prouver que vos agents n'ont accédé qu'aux données auxquelles ils étaient autorisés, pouvez-vous produire ce rapport en moins de 24 heures ?
Le vrai produit de Next '26
Palo Alto Networks, l'un des partenaires présentés aux sessions de gouvernance de Next '26, a partagé un constat qui mérite d'être retenu : la technologie évolue de manière exponentielle, mais les organisations changent de manière logarithmique. Le vrai risque dans l'IA agentique n'est pas que les agents soient trop lents ou trop limités. C'est que les organisations déploient plus vite qu'elles ne se dotent de mécanismes de contrôle.
Ce que Google a compris à Next '26, c'est que ses clients ne manquent pas d'outils pour construire des agents. Ils manquent de structure pour les gouverner à l'échelle. La plateforme la plus complète de gouvernance agentique que l'on ait vue jusqu'ici n'est donc pas un add-on. C'est la proposition de valeur centrale.
Google ne vous vend pas des agents. Il vous vend la capacité de les gouverner sans perdre le sommeil.
Pour les CTO, CDO et CISO qui ont déjà des projets agentiques en cours, cette distinction va changer leurs critères d'évaluation des plateformes cloud dans les 18 prochains mois. La bonne question n'est plus « quelle plateforme offre le meilleur LLM ? ». C'est « quelle plateforme me permet de démontrer, en cas d'audit, que j'ai gardé le contrôle de mes agents de bout en bout ? »
La réponse de Google à Next '26 est claire, articulée, et industrielle. C'est peut-être la première fois qu'un hyperscaler traite la gouvernance agentique comme un produit à part entière et non comme une case à cocher dans une brochure de conformité.
Si vous êtes en train de construire votre roadmap agentique pour H2 2026, la pile Govern de la Gemini Enterprise Agent Platform mérite d'être sur votre table de travail cette semaine.
Cet article fait partie d'une série d'analyses sur Google Cloud Next '26. Inscrivez-vous à notre newsletter pour recevoir les prochaines éditions directement dans votre boîte mail et accéder à la version anglaise de cet article.
Comments ()