For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/fr/articles/gemini-managed-agents-remote-mcp-production-guide.md.
Cet article explique pourquoi la mise à jour de Gemini Managed Agents est importante pour les équipes qui créent de véritables produits d’ag...
La mise à jour de juillet 2026 de Gemini Managed Agents par Google est bien plus qu’une simple amélioration de l’API. Elle rapproche les Managed Agents d’un véritable environnement d’exécution d’agents de niveau production.
Les ajouts importants sont l’exécution en arrière-plan, l’intégration de serveurs MCP distants, l’appel de fonctions personnalisées et l’actualisation des identifiants. Il ne s’agit pas de rendre le modèle plus fluide dans ses réponses. Il s’agit de savoir si un agent peut continuer à fonctionner en toute sécurité, se remettre de tâches de longue durée, appeler des outils avec les bonnes autorisations et laisser suffisamment de traces pour que les développeurs puissent examiner ce qui s’est passé.
La mise à jour de juillet 2026 de Google ne doit pas être interprétée comme un simple correctif d’API de routine. Elle indique que Gemini Managed Agents évolue vers une couche d’exécution plus complète pour les agents IA de production.
Les capacités clés sont l’exécution en arrière-plan, l’intégration de serveurs MCP distants, l’appel de fonctions personnalisées et l’actualisation des identifiants. Ces quatre éléments se situent tous au niveau de l’exécution. Ils résolvent des problèmes concrets liés à la durée des tâches, à l’accès aux outils, à l’authentification, à la reprise après incident et à l’auditabilité.
Avant cela, de nombreux produits d’agents IA reposaient sur une simple boucle de prompts. L’application assemblait le contexte, le modèle décidait de l’étape suivante, le programme appelait un outil, puis le résultat était réinjecté dans la fenêtre de contexte. Ce schéma fonctionne bien pour les démonstrations. Mais dès qu’un agent entre dans un véritable flux de travail métier, il se heurte rapidement à des problèmes plus complexes : gestion de l’état, identifiants, autorisations des outils, exécution de tâches longues, reprise après échec et journaux fiables.
Cette mise à jour de Gemini cible directement ces problèmes de production.
Les agents réellement utiles ont souvent besoin de plus que quelques secondes. Ils peuvent lire des documents, naviguer sur le web, exécuter des tests, générer du code, attendre une CI, préparer un rapport ou comparer des données entre plusieurs systèmes.
Faire tenir tout cela dans une seule requête HTTP synchrone est fragile. Ce n’est pas non plus une bonne expérience utilisateur. Un agent de production ne devrait pas ressembler à une requête de chat susceptible d’expirer. Il devrait davantage ressembler à un travail qui peut être lancé, surveillé, suspendu, annulé, relancé ou repris.
L’exécution en arrière-plan change le modèle produit. Une tâche d’agent peut désormais avoir un identifiant de tâche, un statut, des mises à jour de progression, la prise en charge de l’annulation, des motifs d’échec et un résultat final. Cela rend l’agent plus facile à intégrer dans de vraies applications, en particulier lorsque les utilisateurs doivent revenir plus tard pour voir ce qui s’est passé.
Cela change aussi la conception de l’interface. Une interface de chat se concentre sur un tour de conversation. Une interface d’agent se concentre sur l’état du travail. Les utilisateurs ont besoin de voir ce que l’agent est en train de lire, quels outils il a appelés, s’il est bloqué et si l’action suivante nécessite une approbation.
Pour les équipes qui développent avec NxCode ou des produits similaires de flux de travail IA, la réponse finale ne suffit pas. Le flux de travail doit aussi conserver des preuves d’exécution auditables : prompts, appels d’outils, sorties d’outils, erreurs, modifications de fichiers et artefacts finaux.
Le MCP est important parce qu’il réduit le chaos de l’intégration des outils. Par le passé, chaque modèle, IDE et système interne pouvait nécessiter son propre connecteur. Cela créait
des travaux d’intégration répétés et rendu la gestion des autorisations plus difficile.
Le Model Context Protocol offre une manière plus standardisée pour les agents d’accéder à des ressources et outils externes. Remote MCP transpose cette idée aux scénarios d’agents hébergés dans le cloud. Un agent géré peut se connecter à des documents distants, des systèmes de suivi des tickets, des plateformes d’observabilité, des services de données ou des outils internes sans dépendre d’un serveur d’outils local.
C’est là l’opportunité. La limite, c’est la sécurité.
Chaque serveur MCP constitue aussi une frontière d’autorisation. Les outils qu’il expose influencent le comportement du modèle. Le contenu qu’il renvoie peut contenir des injections de prompt. Ses autorisations peuvent être plus larges que ce que l’utilisateur avait l’intention d’accorder.
Pour cette raison, une configuration de production ne doit pas considérer Remote MCP comme un raccourci prêt à l’emploi. Les outils en lecture seule et ceux capables d’écrire doivent être séparés. Les actions destructrices doivent être restreintes. Chaque appel d’outil doit être journalisé. Les actions à haut risque doivent nécessiter une approbation humaine avant que l’agent puisse poursuivre.
MCP convient bien à un écosystème d’outils plus large, mais les appels de fonctions personnalisés restent la solution adaptée pour les actions internes au produit.
Par exemple : le calcul des prix, la vérification des droits liés à une offre, la création de brouillons, la création de pull requests, la consultation d’enregistrements internes ou des validations propres au métier. Ces fonctions doivent avoir des types clairs, des autorisations limitées et un comportement prévisible. L’autorisation finale doit toujours être appliquée dans le code applicatif plutôt que laissée au modèle.
Le renouvellement des identifiants peut sembler n’être qu’une petite fonctionnalité d’infrastructure, mais il fait en réalité partie de la frontière de confiance pour les agents de longue durée.
Les jetons à courte durée de vie sont plus sûrs, mais les tâches en arrière-plan ont besoin de continuité. Le schéma le plus sûr consiste à n’accorder que le périmètre minimal nécessaire à la tâche en cours, à éviter d’élargir ce périmètre lors du renouvellement, et à maintenir les actions sensibles derrière une approbation renforcée. Le modèle ne doit pas voir les secrets bruts, et les journaux ne doivent jamais divulguer de jetons.
Ne transférez pas toutes les fonctionnalités d’IA vers des Managed Agents d’un seul coup. Commencez par classer les workflows selon leur niveau de risque et leur caractère réversible.
Une première répartition utile est la suivante :
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
Le travail en lecture seule peut être davantage automatisé. Les actions d’écriture nécessitent des contrôles plus stricts. Pour chaque outil, définissez son périmètre d’autorisation, son responsable, le niveau de sensibilité des données, la règle d’approbation et l’exigence de journalisation.
Les workflows pilotes les plus adaptés sont les tâches qui exigent actuellement plusieurs étapes manuelles, mais qui peuvent encore être validées dans des environnements de staging ou de sandbox. De bons exemples incluent la collecte de recherches, les brouillons de correctifs de code, l’investigation de tickets de support, la génération de documentation et la réconciliation de données internes.
Un workflow plus sûr consiste à laisser d’abord l’agent produire des éléments de preuve et un plan. Ce n’est qu’après une revue humaine qu’il doit effectuer des actions irréversibles.
2026-07-08
Les Gemini Managed Agents sont des environnements d’exécution d’agents configurables dans l’API Gemini. Ils peuvent raisonner, exécuter du code, gérer des fichiers et utiliser des outils dans un environnement sandbox hébergé dans le cloud.
L’exécution en arrière-plan permet à des tâches de longue durée de continuer sans maintenir une connexion HTTP ouverte. Cela est utile pour des flux de travail tels que la recherche, la génération de code, les tests, la création de rapports et les vérifications de données entre plusieurs systèmes.
Remote MCP signifie qu’un agent géré peut se connecter à des serveurs distants du Model Context Protocol au lieu de s’appuyer uniquement sur des serveurs d’outils locaux. Cela facilite la connexion des agents à des systèmes externes, des API privées, de la documentation, des outils de suivi des tickets ou des services de données internes.
Remote MCP peut être utilisé en production uniquement avec une conception rigoureuse des autorisations. Les équipes doivent séparer les outils en lecture seule de ceux capables d’écrire, journaliser chaque appel d’outil, limiter les actions destructrices et ajouter une approbation humaine pour les opérations à haut risque.
L’appel de fonction personnalisé est préférable pour les actions métier propres au produit, telles que la validation des autorisations, le calcul des prix, la création de brouillons ou l’ouverture de pull requests. MCP convient mieux à des modèles d’intégration plus larges d’outils et de sources de données.
Les agents de longue durée peuvent avoir besoin de jetons d’accès qui expirent avant la fin de la tâche. L’actualisation des identifiants permet d’assurer la continuité, mais elle doit préserver le principe du moindre privilège et éviter d’exposer des secrets au modèle ou aux journaux.
Au minimum, les équipes doivent consigner les prompts, les appels d’outils, les sorties des outils, les erreurs, les modifications de fichiers, les décisions d’approbation et les artefacts finaux. Ces enregistrements facilitent l’audit, le débogage et l’amélioration du comportement des agents.
Protocole](https://modelcontextprotocol.io/docs/getting-started/intro) : la documentation officielle du MCP pour connecter des applications d’IA à des outils externes et à des sources de données.
Cet article explique pourquoi la mise à jour des agents gérés de Gemini est importante pour les équipes qui développent de véritables produits d’agents d’IA. Le changement clé est le passage de boucles de prompts courtes à un modèle d’exécution qui prend en charge les travaux de longue durée, les outils distants, les fonctions métier personnalisées et la continuité des identifiants.
La leçon de conception la plus importante est que les agents de production ont besoin de plus que des capacités du modèle. Ils ont besoin d’état, d’autorisations, de règles d’approbation, de journaux d’audit et de limites claires entre le travail en lecture seule et les actions irréversibles.
Pour les agents d’IA en production, la vraie question n’est pas seulement ce que le modèle peut faire, mais aussi si le système peut contrôler, observer et restaurer ce que fait l’agent.
Partez d’une phrase et obtenez un site complet en quelques minutes.
