Gemini Enterprise Agent Platform : Google Cloud unifie ses outils d’IA agentique

Adieu Vertex AI, bonjour Gemini Enterprise Agent Platform 

Depuis, Google Cloud entend y intégrer des fonctions de conceptions d’agents IA.

Gemini Enterprise Agent Platform marque l’unification des capacités de conception, de déploiement, de gouvernance et d’évaluation des agents IA.

De prime abord, c’est à nouveau une opération de rebranding à large échelle. Tous les services ont été renommés en conséquence.

Ce renommage renvoie en réalité à la tentative de Google Cloud d’imposer la vision derrière Gemini Enterprise.

Gemini Enterprise était présenté comme le « portail vers les agents IA » d’une entreprise. Or, au lancement, la solution n’était qu’une réunion des produits alors rassemblés sous les marques Agentspace et Gemini Advanced.

Désormais, Gemini Enterprise Agent Platform est la fusion de Vertex AI, de Gemini Enterprise. C’est aussi le moyen de prendre en charge des solutions verticalisées, sous l’appellation Gemini Enterprise Apps. Les clients pourront créer les leurs, tandis que GCP en a présenté une première dédiée à l’expérience client, démo à l’appui.

« Gemini Enterprise est en quelque sorte le centre de commandes destiné aux administrateurs IT et à ceux qui gèrent les agents IA en arrière-plan. Cela permet de tout regrouper au même endroit », déclare Brian Delahunty, vice-président ingénierie, Cloud AI chez Google Cloud, lors d'un point presse.

Les Apps seront les environnements « où les métiers et les experts travaillent main dans la main avec l’IA ». Elles doivent être connecté à Google Workspace, aux back-ends, aux SI, etc.

Revenons à la plateforme elle-même. Pour les développeurs et les citizens developers, il s’agit de rassembler des capacités auparavant réparties à différents endroits du portefeuille Google Cloud.

Ainsi, les deux briques de conception d’agents IA rejoignent Gemini Enterprise Agent Platform. D’un côté, les développeurs peuvent utiliser l’Agent Development Kit (ADK), en sus d’accéder à CrewAI, LangChain, LangGraph, LLamaIndex ou encore AG2. De l’autre, les citizen developers ont accès à l’Agent Studio, une interface low-code/no-code, jusqu’alors nommée Vertex AI Studio.  

ADK semble plus populaire chez les clients de GCP.

« Nous voyons actuellement 6 000 milliards de tokens par mois passé par ADK », affirme Brian Delahunty. « De plus, nous avons fait des progrès notables ces derniers mois ».

Parmi ces avancées, ADK intègre un « moteur orienté graphe qui offre essentiellement un curseur permettant de passer d’un raisonnement basé sur des modèles, plus dynamiques, à un fonctionnement déterministe, plus strict », poursuit-il. Une capacité annoncée en décembre dernier. Salesforce, de son côté, a présenté Agent Script, un langage de spécification pour faire peu ou prou la même chose.

Le jardin de modèles d’IA reste d’actualité. À cela s’ajoute une liste d’outils et de protocoles pour déployer des systèmes RAG, de recherche profonde, MCP, A2A, AP2, etc.

Pour le déploiement, Agent Runtime, Sessions, Sandbox et Agent Memory Bank entrent en disponibilité générale.

Agent Runtime, ex-Agent Engine, regroupe un ensemble de services de déploiement incluant des fonctions de sécurité et d’infrastructure as code.

En matière de sécurité, ce runtime est désormais conforme à la loi américaine sur les données de santé HIPAA, qui prend en charge les clés de chiffrement gérées par les clients (CMEK) et peut s’intégrer à un VPC.

Et le septième jour, l’agent IA termina sa tâche

Il permet surtout d’exécuter des flux agentiques pendant 7 jours d’affilée. Pour les tâches de courte durée, le runtime s’enclenche sous la seconde. « Nous avons refondu la couche d’exécution pour qu’elle soit très performante. Les clients ne paient que pour la mémoire et les ressources de calcul consommées ».

ADK a été adapté à cette capacité d’exécution à long terme. Il intègre des fonctions pour gérer des checkpoints, des sauvegardes d’état à un moment T et reprendre un flux de travail plus tard. « Si un agent s’exécute pendant plusieurs jours et qu’il a besoin de s’arrêter pour diverses raisons (demander l’approbation d’un humain, attendre le résultat d’un autre agent IA, etc.), il doit pouvoir reprendre sa tâche là où il l’avait arrêté », explique Brian Delahunty.

En outre, les clients peuvent utiliser des conteneurs customisés pour y inclure des outils spécifiques ou des conditions d’exécution.

Sandbox est, comme son nom l’indique, un environnement isolé pour exécuter des agents IA ou des flux de travail agentiques sans compromettre les systèmes en place. « Sandbox permet par exemple aux agents IA d’accéder à des interfaces visuelles et des ordinateurs », illustre Brian Delahunty. C’est la grande mode et cela pourrait être l’un des moyens les plus sûrs pour exécuter du code généré par une IA.

Deux niveaux de mémoire

Agent Platform Sessions, ex-Agent Builder Sessions, doit maintenir l’historique de conversation et des échanges avec les usagers pendant une seule conversation. Ce mécanisme est plus indiqué pour une boucle d’échange simple avec un service client, par exemple.

Memory Bank n’est autre que le moyen de conserver les états des agents IA sur le long terme. La fonctionnalité permet d’extraire les informations clés et de les conserver, de consolider des données, de « générer » – c’est-à-dire d’ajouter des éléments de contexte de manière synchrone et asynchrone, avec des données structurées ou non structurées. La gestion de l’expiration et des rôles pour ces éléments en mémoire sont gérés depuis cette brique.

« Memory Bank remplace le stockage temporaire des données de session par mémoire persistante à long terme », précise Brian Delahunty. « De plus, pour permettre l’interaction avec vos systèmes existants, nous introduisons des identifiants de session personnalisés afin que vous puissiez relier votre environnement à vos sessions et à vos logiciels existants ».

La majorité des plateformes agentiques, dont celles d’AWS et de Microsoft proposent une capacité similaire.

Sécurité, gouvernance : quelques trous dans la raquette à combler

Concernant la gouvernance, Google Cloud a encore du pain sur la planche. La bonne nouvelle, c’est qu’Agent Identity entre en disponibilité générale.

« Désormais, chaque agent de votre flotte dispose d’un identifiant unique et traçable, associé à ses propres identifiants IAM », affirme Michael Gerstenhaber, Vice-président produit Cloud AI chez Google Cloud.

« Cela vous permet d’appliquer le principe du moindre privilège ». 

En clair, cela permet de segmenter l’accès aux données par un agent IA.

Contrairement à d’autres acteurs du marché, Google Cloud a pris le parti de considérer deux cas de figure principaux. Un premier durant lequel un agent s’exécute de manière autonome, un autre où il agit pour le compte d’un métier.

« En ce sens, il faudrait plutôt évoquer trois identités », ajoute le responsable. « D’abord, nous identifions l’agent par des moyens cryptographiques, les permissions partagées à travers l’identifiant d’un utilisateur, et il faut ensuite compter l’identité de l’agent qui agit au nom de l’utilisateur ».

GCP utilise plus spécifiquement SPIFFE (à prononcer spi-fi, pour Secure Protection Identity Framework for Everyone), présenté par Red Hat comme « un moyen de structurer les identités et de les vérifier par le biais du chiffrement pour déterminer leur fiabilité ». Une approche également retenue par Solo.io, un spécialiste du Service Mesh.

La mauvaise nouvelle, c’est que les services associés doivent encore sortir de leur phase de préversion. Par exemple, les politiques IAM spécifiques à la gouvernance des agents IA ne sont disponibles que sur invitation.

Cette capacité de gestion d’identité va de pair avec l’Agent Registry, encore en préversion publique. Celui-ci permet aux agents de se connecter aux ressources cloud, aux API, aux serveurs MCP et aux autres agents de « manière sécurisée ».

« Cela permet aux développeurs de créer plus rapidement des applications à l’aide de connecteurs validés, tandis que le service informatique bénéficie d’une visibilité totale sur ces connecteurs et sur leur utilisation », assure Michael Gerstenhaber.

En préversion privée cette fois, Google Cloud prépare Agent Gateway, une passerelle entre Agent Identity, Agent Registry, les modèles, la couche d’observabilité, les agents, les outils, le garde-fou Model Armor, et les API. Elle est à la fois responsable de la délégation d’autorisations (en s’appuyant sur l’ID SPIFFE spécifique à un agent), de router le trafic de manière sécurisée (via mTLS, DPoP), et de collecter la télémétrie. Agent Gateway peut donc être configuré en egress ou en ingress. Bref, un service qui semble tout simplement s’appuyer sur le proxy Envoy, une technologie désormais éprouvée. MuleSoft s’appuie également sur cette librairie pour propulser sa propre passerelle IA, Flex Gateway.

Par ailleurs, GCP mettra en place Agent Anomaly Detection, un service propulsé par des modèles statistiques et des LLM as a Judge pour repérer des comportements ou des activités inhabituelles.

 Enfin, le fournisseur annonce des fonctions d’évaluation, de simulation et d’observabilité. Agent Observability reprend les conventions sémantiques d’OpenTelemetry consacrées à l’IA générative. Le service propose pour l’instant deux vues. La première est consacrée aux métriques les plus courantes afin de superviser, en autres, les échecs, les volumes de trafic et la consommation de tokens. La deuxième permet de creuser dans les traces de raisonnement et d’appels d’outils des agents IA.

« Vous voulez savoir ce que font vos agents et, surtout, quel raisonnement ils ont suivi pour en arriver aux résultats, afin de pouvoir leur dire : “ne faites pas ça”, ou “ce n’était pas la bonne façon d’aborder le problème” », résume Michael Gerstenhaber.

Créer une boucle d’optimisation des instructions

Comme le laisse à penser le responsable, la suite logique est d’associer cette capacité à une brique d’optimisation.

Agent Optimizer doit permettre d’automatiquement repérer les erreurs d’exécution et de recommander des ajustements des system prompts afin d’améliorer les performances des agents IA. « Vous devriez pouvoir affiner vos instructions de manière programmatique en fonction des signaux d’erreur afin de créer une bibliothèque de qualité continue », promet le dirigeant.

En matière d’évaluation et de simulation, GCP adapte petit à petit des capacités existantes pour mettre à l’épreuve des agents IA avant leur mise en production. Il s’agit à la fois de créer des tests et de noter les agents IA sur des tâches ainsi que de générer des données synthétiques pour ce faire. Un passage obligé « pour passer des prototypes à la production », estime Michael Gerstenhaber.

Avec cette Gemini Enterprise Agent Platform (un nom bien trop long pour son propre bien), Google Cloud laisse à penser qu’il souhaite imposer une grande partie de la pile technologique agentique à ses clients. « Il y a de la valeur ajoutée à proposer une stack unifiée, depuis les TPU, les modèles, en passant par le kit de développement, les agents et l’application elle-même », vante Brian Delahunty. « Mais nous ne voulons pas imposer nos outils et nos services », assure-t-il.

« Vous pouvez créer vos agents dans LangGraph ou avec le SDK d’AWS, puis les exécuter sur Agent Engine [désormais appelé Agent Runtime, N.D.L.R], cela fonctionnera très bien. Vous pouvez connecter vos agents IA et vos serveurs MCP à notre registre. Notre objectif est de proposer une plateforme ouverte », dit-il en répétant le discours de Thomas Kurian, directeur général de Google Cloud. « Nous voulons devenir ce moteur d’orchestration pour les agents au sein d’une entreprise, même si vous n’utilisez qu’une partie de notre plateforme ».