Google Cloud ouvre Gemini Enterprise Agent Platform, mais le véritable enjeu est le contrôle

Google Cloud a rendu plusieurs capacités de Gemini Enterprise généralement disponibles le 29 juillet, seulement trois mois après avoir présenté son Agent Platform étendu. La mise à jour fait entrer la mémoire persistante, l’exécution sur sept jours, l’identité des agents, la gouvernance, l’évaluation et l’observabilité dans des usages de production plus larges. Le dilemme est clair : une autonomie accrue crée davantage de valeur, mais elle donne aussi aux logiciels plus de temps et d’autorité pour commettre des erreurs aux conséquences importantes.

Il ne s’agit pas simplement d’une nouvelle collection d’outils de création d’agents. Google cherche à fournir la couche opérationnelle entre un modèle d’IA et les systèmes d’entreprise qu’il peut modifier. Cette couche doit préserver le contexte, attribuer les autorisations, enregistrer les actions, appliquer les politiques et mesurer les résultats sur des flux de travail qui durent plusieurs jours.

Amazon et Microsoft visent le même point de contrôle avec Bedrock AgentCore et Microsoft Foundry. La compétition ne porte plus uniquement sur l’entreprise qui propose le modèle le plus performant. Elle concerne de plus en plus le cloud capable de rendre le travail autonome suffisamment maîtrisable pour que les équipes de sécurité, les développeurs et les responsables métier puissent l’approuver.

Google Cloud fait passer son aperçu d’agents à une plateforme de production

Cette mise à jour fait évoluer Gemini Enterprise Agent Platform d’un cadre ambitieux vers un système opérationnel que les entreprises peuvent déployer et gouverner.

Google a présenté la plateforme actuelle le 22 avril comme une évolution de Vertex AI. Son objectif affiché était de réunir l’accès aux modèles, le développement d’agents, le déploiement, la sécurité et l’optimisation dans un même environnement. L’entreprise a également indiqué que les futurs services Vertex AI et les mises à jour de feuille de route seraient proposés via Agent Platform, plutôt que sous forme de gamme de produits distincte.

Trois mois plus tard, Google a rendu sept capacités centrales généralement disponibles. Agent Memory Bank conserve un contexte structuré entre les sessions. Agent Runtime prend en charge des tâches asynchrones durant jusqu’à sept jours. Agent Identity attribue à chaque agent une identité dédiée pour le contrôle des accès et l’audit.

Agent Gateway, Agent Registry, Agent Evaluation et Agent Observability complètent cette couche de contrôle. Ensemble, ils gèrent les connexions aux outils, répertorient les agents déployés, mesurent les comportements et tracent l’exécution. Google décrit ces capacités dans sa mise à jour d’Agent Platform, qui présente la sortie sous l’angle du déploiement sécurisé des agents à grande échelle.

L’exécution sur sept jours est le changement le plus visible. Un chatbot classique répond au cours d’une session, puis attend une nouvelle demande. Un agent de longue durée peut gérer une séquence commerciale, surveiller les conditions de la chaîne d’approvisionnement ou coordonner un processus d’intégration sur plusieurs jours.

Cette persistance transforme le problème d’ingénierie. L’agent a besoin d’un état durable, d’une logique de reprise, de limites d’autorisation et d’un enregistrement de chaque action. Une erreur temporaire du modèle devient plus grave lorsque le même processus continue de fonctionner après la fermeture de l’application par l’utilisateur.

Memory Bank répond à une partie de ce défi en extrayant des faits sélectionnés dans des schémas structurés. Il peut conserver des préférences, l’historique d’un compte et des décisions antérieures sans contraindre l’agent à tout reconstruire à partir d’une transcription. Google affirme que cette conception permet une personnalisation à plus faible latence dans les tâches de longue durée.

La distinction entre mémoire stockée et historique brut des conversations est importante. Une transcription contient tout ce qui a été dit, y compris les détails non pertinents et les instructions obsolètes. La mémoire structurée sélectionne les informations censées rester utiles. Toutefois, ce processus de sélection crée également un nouveau point de défaillance, car le système peut enregistrer une inférence incorrecte.

Google commercialise donc l’exécution et la mémoire comme une paire. L’exécution maintient la tâche active, tandis que Memory Bank conserve le contexte disponible. Aucune de ces fonctionnalités ne rend à elle seule un agent fiable, mais elles permettent ensemble aux développeurs de tenter des flux de travail qui dépassent une requête unique.

La mise à jour étend également le champ de la plateforme au-delà des agents intégralement construits avec des modèles Google. Lors du lancement, Google a indiqué que Model Garden donnait accès à plus de 200 modèles propriétaires, tiers et ouverts. Ce choix suggère que l’entreprise veut contrôler le déploiement et la gouvernance même lorsque les clients choisissent le modèle d’un autre fournisseur.

Cette stratégie rend Agent Platform plus important qu’un canal de distribution pour Gemini. Google le positionne comme une infrastructure destinée à des flottes d’agents hétérogènes. La plateforme réussira si les organisations considèrent ses services d’identité, de registre, de passerelle et de supervision comme des contrôles communs à travers ces flottes.

Pourquoi Google Cloud mise sur le contrôle des agents

Les acheteurs d’entreprise sont de moins en moins limités par la disponibilité des modèles, et de plus en plus par le risque opérationnel entourant les actions des agents.

Un agent prototype peut fonctionner avec un jeu de données restreint et quelques outils. Les agents en production rencontrent des dossiers clients, des applications internes, des identifiants, des chaînes d’approbation et des exigences de conformité. Chaque connexion ajoutée accroît à la fois l’utilité de l’agent et son rayon d’impact potentiel.

Google Cloud répond avec un modèle d’identité conçu spécifiquement pour les agents. Agent Identity est un type natif de gestion des identités et des accès, et non un simple compte de service réutilisé. Google indique qu’il lie l’accès à l’environnement d’exécution, applique des autorisations de moindre privilège, gère le cycle de vie de l’identité et produit des enregistrements d’audit non répudiables.

Le moindre privilège consiste à n’accorder que les accès nécessaires à une tâche définie. Le principe est connu, mais les agents compliquent sa mise en œuvre. Leurs plans peuvent changer pendant l’exécution et ils peuvent appeler plusieurs outils pour atteindre un objectif général.

Les comptes de service traditionnels restent souvent actifs après qu’une application a changé ou disparu. Les autorisations peuvent s’accumuler à mesure que les équipes ajoutent des intégrations. Best Buy a décrit les comptes orphelins, l’absence de responsabilité clairement définie et l’extension des autorisations comme des problèmes récurrents dans l’annonce de Google.

Une identité d’agent dédiée crée une unité de responsabilité plus claire. Les administrateurs peuvent demander quel agent a agi, à quoi il a accédé, qui en est responsable et quel environnement d’exécution a autorisé l’action. Cette visibilité devient essentielle lorsqu’un agent prend des décisions sans qu’une personne approuve chaque étape.

Agent Gateway se situe à la frontière suivante. Il centralise les interactions entre les agents, les modèles et les outils. Les administrateurs peuvent appliquer des conditions d’identité et des règles en langage naturel, tandis que Model Armor inspecte le trafic à la recherche d’injections de prompt, d’empoisonnement d’outils et de fuites de données.

L’injection de prompt survient lorsqu’un contenu hostile ou non fiable manipule les instructions d’un agent. L’empoisonnement d’outils implique une description ou une réponse d’outil compromise qui modifie le comportement de l’agent. Ces deux attaques deviennent plus lourdes de conséquences lorsque l’agent peut accéder à des fichiers, envoyer des messages, mettre à jour des dossiers ou modifier des logiciels.

Agent Registry répond à un problème différent : la prolifération organisationnelle. Il fournit un catalogue des agents, serveurs et connexions à l’échelle d’une entreprise. Les équipes peuvent découvrir les composants existants, tandis que les administrateurs peuvent identifier les responsables et surveiller les déploiements.

Un registre n’empêche pas automatiquement les agents redondants ou dangereux. Sa contribution immédiate est la visibilité. Une organisation ne peut pas appliquer des contrôles cohérents à des logiciels dont ses équipes centrales ignorent l’existence.

Le calendrier de Google reflète l’écart croissant entre les projets pilotes et les systèmes de production gouvernés. De nombreuses équipes peuvent assembler un agent utile avec un modèle, un prompt et plusieurs API. Elles sont moins nombreuses à disposer de systèmes communs pour l’identité, la mémoire, l’évaluation et l’investigation des incidents.

Cet écart met les fournisseurs cloud sous pression, car les clients préfèrent des contrôles opérationnels intégrés à leur infrastructure existante. Les politiques d’identité, systèmes de journalisation, contrôles réseau et services de données résident déjà dans l’environnement cloud. Une plateforme d’agents devient plus attrayante lorsqu’elle peut réutiliser ces fondations.

La même dynamique met sous pression les frameworks d’agents indépendants. Les frameworks ouverts peuvent donner aux développeurs portabilité et flexibilité, mais les équipes d’entreprise ont toujours besoin d’un environnement d’exécution et d’un plan de gouvernance. Google prend en charge les standards ouverts et son Agent Development Kit, mais la couche opérationnelle gérée encourage un usage plus poussé de son cloud.

L’enjeu stratégique est donc plus vaste que la consommation de modèles. La plateforme gagnante peut devenir l’endroit par défaut où les entreprises enregistrent leurs agents, accordent des autorisations, inspectent des traces et évaluent les performances. Une fois que ces contrôles entourent une charge de travail, la déplacer devient plus complexe.

Le mécanisme reliant mémoire, identité et évaluation

Le pari central de Google est que les agents autonomes deviennent gérables lorsque l’exécution, l’autorité, le contexte et la mesure partagent un même plan de contrôle.

Agent Runtime fournit l’environnement d’exécution. Memory Bank maintient le contexte sélectionné. Agent Identity détermine qui le système considère comme l’acteur. Agent Gateway régit l’accès aux modèles et aux outils, tandis que Registry enregistre ce qui a été déployé.

Evaluation et Observability ferment la boucle. Observability enregistre ce que l’agent a fait, y compris les traces de raisonnement, l’utilisation des outils, la latence et le comportement d’exécution. Evaluation détermine si le résultat répondait à une norme attendue.

Google réunit les deux fonctions dans un même moteur. Les développeurs peuvent utiliser la même logique de mesure pendant la construction et après le déploiement. L’entreprise indique que les options d’évaluation incluent des métriques prédéfinies, des fonctions Python personnalisées, des juges basés sur des modèles et des rubriques adaptatives développées avec Google DeepMind.

Cette continuité compte, car les benchmarks hors ligne échouent souvent à représenter les conditions réelles. Un jeu de données de test ne peut anticiper chaque demande client, chaque évolution de réponse d’outil ou chaque état d’autorisation. L’évaluation en ligne peut identifier une dégradation des performances et une dérive comportementale après la sortie.

La dérive comportementale signifie que les résultats d’un agent changent avec le temps, même si son objectif déclaré reste constant. Une mise à jour du modèle, un prompt révisé, une nouvelle source de données ou un outil modifié peuvent provoquer ce changement. La surveillance continue aide les équipes à déterminer quand la modification a commencé.

Cependant, l’évaluation n’élimine pas le jugement subjectif. Un juge basé sur un modèle peut hériter des biais ou des faiblesses du modèle chargé de l’évaluation. Une métrique personnalisée peut optimiser un indicateur indirect facile à mesurer tout en négligeant le résultat métier qui compte.

Les équipes de production ont toujours besoin de critères de réussite explicites. Un agent de support client peut être évalué sur la qualité de résolution, le respect des politiques, la précision des escalades et l’effort demandé au client. Se concentrer uniquement sur la vitesse de réponse pourrait récompenser des réponses assurées mais incorrectes.

L’architecture intégrée devient plus utile lorsqu’une évaluation peut déclencher une action opérationnelle. Une baisse de score pourrait réduire les autorisations d’un agent, orienter le travail vers un humain ou arrêter un flux de travail. L’annonce de Google décrit des capacités de supervision, mais les clients doivent encore concevoir des politiques d’intervention appropriées.

AT&T fournit un exemple concret de mémoire. L’entreprise indique que ses agents commerciaux utilisent Memory Bank pour synthétiser des faits issus d’interactions antérieures avec les clients, afin de permettre la reprise des conversations après une interruption. Elle travaille également à assurer une continuité entre les canaux application, voix et web.

Ce cas illustre à la fois le bénéfice et le risque. Le contexte mémorisé peut éviter aux clients de répéter des informations. Une mémoire incorrecte ou trop étendue peut également se propager d’un canal à l’autre et influencer les décisions ultérieures.

Commerzbank présente l’aspect gouvernance. La banque indique évaluer Agent Registry et Agent Gateway pour la découvrabilité, l’application des politiques, la gestion des accès, l’observabilité et l’audit. Son intérêt montre pourquoi une couche centralisée séduit les organisations réglementées.

WellSky indique utiliser un registre centralisé pour cataloguer, versionner et gérer les agents tout au long de leur cycle de vie. L’entreprise relie ce catalogue aux politiques de conformité et à l’approbation pour la production. Cela se rapproche davantage de la gestion des actifs logiciels que d’une fonctionnalité d’IA destinée au grand public.

CodeMender étend le même mécanisme à la sécurité logicielle. Google le décrit comme un agent géré qui détecte, vérifie et propose des correctifs pour les vulnérabilités du code. Le raisonnement principal s’exécute dans le cloud, tandis que la compilation, les tests et les simulations d’exploitation s’exécutent dans des environnements sandbox gérés par les clients ou des machines virtuelles isolées.

La conception de CodeMender conserve un point d’approbation humaine. Les développeurs reçoivent les modifications proposées sous forme de diffs locaux, et l’agent ne les valide pas directement dans les dépôts de production. Google indique également que le code client n’est pas utilisé pour entraîner ses modèles fondamentaux.

Cette limite est instructive. CodeMender automatise l’analyse et la création de correctifs, mais ne supprime pas la responsabilité des développeurs. L’étape de revue humaine limite l’autonomie précisément là où une modification incorrecte pourrait créer une nouvelle vulnérabilité ou perturber la production.

Les agents à forte intensité de connaissances ont besoin de limites similaires. Les équipes peuvent utiliser une base de connaissances consultable pour organiser les preuves internes, mais la récupération d’informations ne donne pas à elle seule à un agent l’autorisation d’agir. Le contexte, les autorisations et la vérification restent des décisions de conception distinctes.

AWS et Microsoft construisent la même couche de contrôle

L’ensemble des fonctionnalités de Google se distingue par son intégration, et non par une catégorie incontestée, car ses principaux rivaux dans le cloud proposent désormais une infrastructure d’agents comparable.

Amazon Bedrock AgentCore sépare la logique de l’agent de son infrastructure gérée. Son Runtime fournit l’isolation, la montée en charge, les sessions, les contrôles d’authentification et les mécanismes d’observabilité. Les développeurs gardent le contrôle de la boucle d’orchestration et peuvent connecter Memory, Gateway, Identity et d’autres services.

Le runtime AgentCore peut héberger du code écrit avec différents frameworks. Cette approche séduit les équipes qui veulent une infrastructure gérée sans adopter un unique framework d’agents. Elle rend également la réponse concurrentielle d’Amazon directement comparable à la plateforme de Google.

AWS propose un service spécialisé d’identité et d’identifiants pour les charges de travail automatisées. Selon sa documentation sur l’identité, AgentCore Identity prend en charge l’authentification, l’autorisation, les identifiants tiers et les pistes d’audit. Ses identités de charge de travail suivent des modèles d’identité établis tout en ajoutant des attributs spécifiques aux agents.

Microsoft Foundry Agent Service combine également l’exécution, l’orchestration, l’identité, la sécurité et l’observabilité. Son runtime géré peut isoler les sessions, tandis que Microsoft Entra fournit l’identité et le contrôle d’accès basé sur les rôles. Application Insights prend en charge les traces et la surveillance en production.

Microsoft dispose d’un avantage supplémentaire de distribution grâce à Microsoft 365 et Copilot. Une organisation qui utilise déjà Entra, Teams, SharePoint et Microsoft 365 peut considérer Foundry comme une extension de son environnement de travail existant. Google peut avancer un argument parallèle via Google Workspace et ses produits de données cloud.

Microsoft permet également aux clients d’enregistrer certains agents hébergés en externe à des fins d’observabilité et d’évaluation. Ses contrôles pour agents externes utilisent des traces OpenTelemetry, ce qui permet à Foundry de surveiller un agent sans héberger ni invoquer son runtime. Plusieurs capacités associées restent en préversion, notamment l’évaluation humaine et les analyses red team pour les agents externes.

Les trois plateformes reflètent donc différentes versions de la même thèse. Les agents d’entreprise nécessitent une exécution gérée, un contexte persistant, une identité, une gouvernance des outils et une surveillance. Les fournisseurs cloud veulent que ces services deviennent la base standard sous-jacente à chaque agent.

L’avantage de Google réside dans la cohérence de sa pile désormais disponible. Runtime, Memory Bank, Identity, Gateway, Registry, Evaluation et Observability partagent une même famille de produits. Gemini Enterprise peut également distribuer des agents aux employés par le biais d’une application contrôlée.

Son défi consiste à prouver qu’une pile unifiée produit de meilleurs résultats opérationnels. Des noms de fonctionnalités similaires ne démontrent pas une fiabilité supérieure. Les clients jugeront la qualité de l’intégration, la précision des politiques, la réponse aux incidents, la disponibilité régionale, la prise en charge des frameworks et l’effort requis pour exploiter chaque système.

La portabilité demeure un autre sujet ouvert. Google indique qu’Agent Platform prend en charge les modèles tiers et les normes ouvertes. Pourtant, un agent conçu autour de son type d’identité, de ses schémas de mémoire, de son registre, de son moteur d’évaluation et de ses politiques de passerelle pourrait devenir coûteux à déplacer.

AWS et Microsoft créent des dépendances comparables. Leurs services gérés réduisent le travail d’ingénierie en faisant des choix spécifiques à la plateforme pour le client. Ce compromis est courant dans le cloud computing, mais les agents autonomes augmentent les enjeux, car les données de gouvernance et l’historique comportemental se retrouvent également liés au fournisseur.

Les entreprises devraient donc distinguer la portabilité des modèles de la portabilité opérationnelle. Changer le modèle derrière un agent peut nécessiter une modification de configuration. Déplacer son historique d’identité, sa mémoire persistante, ses dossiers d’évaluation, ses politiques de passerelle et ses pistes d’audit constitue une migration plus importante.

La concurrence ne se jouera pas sur la liste de fonctionnalités la plus longue. Elle dépendra de la capacité d’une plateforme à réduire le travail nécessaire pour réussir l’examen de sécurité et maintenir un comportement fiable en production. Ces résultats exigent des preuves allant au-delà des annonces de lancement.

Le risque non résolu est de savoir si la gouvernance peut suivre le rythme

Les contrôles des agents réduisent les risques connus, mais des runtimes plus longs et un accès plus large aux outils créent des modes de défaillance que les tableaux de bord ne peuvent pas résoudre automatiquement.

Un agent fonctionnant pendant sept jours a davantage d’occasions de rencontrer des données obsolètes, des instructions contradictoires, des identifiants expirés et un comportement inattendu des outils. Il peut également amplifier une erreur initiale par ses décisions ultérieures. La durée du runtime est donc à la fois une capacité et un multiplicateur de risques.

La mémoire persistante crée une autre tension. La personnalisation s’améliore lorsqu’un agent se souvient des préférences et des décisions passées. La gouvernance devient plus difficile lorsque les équipes doivent décider ce que le système doit extraire, combien de temps il doit conserver ces informations et comment les utilisateurs peuvent les corriger.

Les schémas structurés apportent de la discipline, mais leur conception est un choix de politique. Un agent commercial peut avoir besoin des intérêts d’un compte en matière de produits sans conserver de données personnelles sensibles. Un agent interne peut avoir besoin des décisions d’un projet sans traiter chaque commentaire spéculatif comme un fait établi.

Agent Identity peut montrer quel acteur logiciel a effectué une action. Cela n’explique pas nécessairement pourquoi l’action s’est produite. Une enquête complète peut nécessiter les instructions de l’agent, la version du modèle, le contexte récupéré, les réponses des outils, l’état de la mémoire, les décisions de politique et les résultats d’évaluation.

L’observabilité peut recueillir une grande partie de ces éléments. Tout consigner introduit toutefois des préoccupations liées à la confidentialité et au stockage. Des traces de raisonnement détaillées peuvent contenir des informations client, des documents confidentiels ou des résultats sensibles d’outils.

Les équipes doivent décider quelles traces peuvent être conservées sans risque et qui peut les consulter. Elles ont également besoin de périodes de conservation et de politiques de masquage conformes à leurs obligations légales. La centralisation aide à appliquer ces choix, mais ne les rend pas simples pour autant.

Les règles de passerelle en langage naturel méritent un examen similaire. Elles facilitent l’expression des politiques, mais les contrôles de sécurité doivent se comporter de manière prévisible dans des conditions adverses. Les organisations devraient vérifier si des demandes équivalentes reçoivent des décisions cohérentes et si les conflits de politiques échouent de manière sûre.

Google indique que Model Armor aide à se défendre contre l’injection de prompts, l’empoisonnement d’outils et les fuites de données. Ces protections doivent être considérées comme des contrôles au sein d’un système multicouche, et non comme la preuve qu’un agent est sûr. Aucun filtre ne peut anticiper chaque instruction malveillante ou intégration compromise.

Les déclarations de clients dans l’annonce de Google sont encourageantes, mais limitées. Elles décrivent des déploiements et évaluations sélectionnés plutôt que des mesures indépendantes et comparatives. La mise à jour ne fournit ni taux d’erreur à l’échelle de la plateforme, ni taux d’incidents de sécurité, ni réduction chiffrée de l’effort opérationnel.

Cette absence est compréhensible pour un produit récemment disponible. Elle signifie également que les acheteurs devraient éviter de traiter la disponibilité générale comme une preuve de performances matures pour toutes les charges de travail. La validation la plus solide viendra d’une utilisation soutenue en production sous des contrôles mesurables.

La revue humaine demeure nécessaire pour les actions à fort impact. CodeMender illustre ce principe en exigeant que les développeurs approuvent les correctifs. Les transferts financiers, les fermetures de comptes, les changements en production et les communications juridiquement significatives méritent des limites tout aussi explicites.

Le niveau approprié d’autonomie dépend de la réversibilité. Un agent peut bénéficier de plus de liberté lorsqu’une action est facile à examiner et à annuler. Les décisions irréversibles ou visibles de l’extérieur exigent des autorisations plus restreintes, une évaluation renforcée et une escalade fiable.

Les entreprises ont également besoin d’une responsabilité en dehors de l’équipe plateforme. Les équipes de sécurité peuvent définir les règles d’accès, tandis que les responsables métier définissent les résultats acceptables. Les équipes juridiques et de confidentialité déterminent quelles informations peuvent entrer dans la mémoire ou les journaux.

Sans responsabilité partagée, Agent Registry risque de devenir un catalogue de systèmes que personne ne gouverne activement. Les tableaux de bord d’évaluation peuvent produire des scores sans processus de réponse. Les dossiers d’identité peuvent établir l’attribution après un incident sans empêcher l’incident.

Google a réuni les composants nécessaires à un plan de contrôle crédible. La question restante est de savoir si les organisations peuvent transformer ces composants en pratiques opérationnelles applicables. La technologie peut exposer une décision, mais la responsabilité reste humaine.

Ce qu’il faut surveiller après l’expansion de Gemini Enterprise

La prochaine étape sera mesurée par l’adoption réelle, des résultats de gouvernance vérifiés et les réponses concurrentielles, plutôt que par de nouvelles démonstrations d’agents.

Le premier signal sera la preuve de production pour les workflows de sept jours. Les clients devraient documenter les taux d’achèvement, la fréquence des interventions, le comportement de récupération et le nombre de défaillances qui se cumulent sur plusieurs étapes. Des performances fiables sur de longues durées renforceraient l’affirmation de Google selon laquelle Agent Runtime va au-delà des courtes sessions de chat.

De faibles taux d’achèvement indiqueraient l’inverse. Ils suggéreraient que l’exécution persistante progresse plus vite que la fiabilité de la planification. La mesure importante n’est pas de savoir si un agent reste actif pendant sept jours, mais s’il accomplit un travail utile dans des limites définies.

Le deuxième signal sera la manière dont Agent Identity et Gateway se comportent lors des audits et des incidents. Les entreprises ont besoin de preuves que les autorisations restent limitées, que les cycles de vie des identifiants se terminent correctement et que les enquêteurs peuvent reconstituer les actions conséquentes. Des examens réussis dans la finance, la santé et les télécommunications soutiendraient l’argument de gouvernance de Google.

Les équipes de sécurité devraient également examiner les événements évités, et pas seulement les déploiements réussis. Des informations utiles incluraient les tentatives d’injection bloquées, les appels d’outils refusés, les conflits de politiques et le temps nécessaire pour identifier un agent défaillant. Des rapports agrégés pourraient aider les acheteurs à comparer les contrôles sans exposer les détails des clients.

Le troisième signal viendra de la réponse d’AWS et de Microsoft. Tous deux proposent déjà des services d’exécution, d’identité, de mémoire, de passerelle et d’observabilité. Leurs prochaines versions montreront si Google a pris une avance significative ou s’il s’est simplement aligné sur une nouvelle référence du cloud.

La portabilité des frameworks et de la télémétrie sera particulièrement importante. La prise en charge par Microsoft de traces d’agents hébergées en externe offre une première approche. AWS met l’accent sur la flexibilité des frameworks au sein de son environnement d’exécution managé. Google doit démontrer que son expérience unifiée n’oblige pas les clients à renoncer à un choix concret.

Les acheteurs devraient tester chaque plateforme avec le même workflow représentatif. Ce test devrait inclure une tâche de longue durée, une modification d’autorisation, une instruction injectée, un outil défaillant, une correction de mémoire et une régression d’évaluation. Les listes de fonctionnalités ne peuvent pas révéler comment l’ensemble du système se comporte sous pression.

Les développeurs devraient également se demander si la plateforme rend les défaillances compréhensibles. Une trace n’est utile que lorsqu’elle relie un résultat à l’instruction, au contexte, à l’outil, à la politique et au modèle responsables. Davantage de télémétrie peut accroître la confusion si le système n’organise pas ces relations.

Les travailleurs du savoir ont une préoccupation connexe. Les agents persistants agiront de plus en plus sur des notes, des documents, des réunions et des décisions passées. Un workflow d’IA personnel peut aider à organiser ce contexte, mais l’action en entreprise exige des autorisations explicites et une revue.

Google Cloud a désormais rendu généralement disponibles ses principaux contrôles pour agents. Il s’agit d’une transition produit importante, et non d’une preuve que le travail autonome en entreprise est résolu. Le véritable test de la plateforme commencera lorsque les agents fonctionneront pendant plusieurs jours, franchiront les frontières entre systèmes et rencontreront des conditions que leurs concepteurs n’avaient pas prévues.

Posez une question concrète avant d’étendre l’autorité d’un agent : votre équipe peut-elle reconstituer, arrêter et inverser en toute sécurité son action plausible la plus dommageable ? Si la réponse est incertaine, utilisez d’abord les nouveaux contrôles pour restreindre le workflow. La disponibilité générale rend un déploiement plus large possible. Les preuves, la responsabilité et des limites rigoureuses doivent le rendre responsable.