07. Les utilisateurs peuvent-ils ajouter un agent eux-mêmes, sans nous ?

Pour qui : admins Gemini Enterprise, sécurité, équipes métier et « builders » qui veulent connecter leurs agents. Question : un utilisateur peut-il connecter lui-même un agent à notre app, depuis l'interface web Gemini Enterprise, sans accès à la console GCP et sans notre aide ? Ou faut-il que l'équipe admin le fasse dans la console ?

1. Réponse courte

Ça dépend du type d'agent.

En une phrase : l'app web permet de construire et de composer des agents avec ce qui existe déjà. Faire entrer quelque chose de nouveau (un agent de code, un serveur MCP, une source) passe par la configuration de l'app, c'est-à-dire la console GCP ou l'API.

Google l'écrit ainsi : « les actions et outils disponibles pour un agent ou un workflow sont limités aux connecteurs, outils et autorisations mis en place par l'administrateur Gemini Enterprise. »

2. Les trois niveaux d'autonomie

 Niveau 1 : UTILISATEUR               Niveau 2 : BUILDER DÉLÉGUÉ             Niveau 3 : ADMIN GEMINI ENTERPRISE
 (app web uniquement)                 (rôle limité aux agents)               (console GCP du projet de l'app)
 ─────────────────────────            ─────────────────────────              ─────────────────────────────────
 • crée des agents sans code          • publie SES agents ADK / A2A          • tout : connecteurs, MCP, sécurité,
 • compose avec les agents et           (Agent Runtime, Cloud Run,             Model Armor, Agent Gateway, agents
   outils déjà publiés                  autre projet) dans l'app            • valide les partages
 • partage (avec ou sans validation)  • gère qui peut les utiliser          • contrôle tout le reste
 ✗ ne fait rien entrer de neuf        ✗ ne touche pas à la sécurité
 Rôle : Gemini Enterprise User        Rôle : Agent Admin (+ Viewer)          Rôle : Gemini Enterprise Admin

Rôles et permissions vérifiés dans IAM. Agent Admin contient discoveryengine.agents.create / update / delete / manage / setIamPolicy, et rien d'autre de significatif. C'est exactement « ajouter et partager des agents ».

3. Niveau 1 : ce que l'utilisateur fait seul, dans l'app web

3.1 Créer un agent sans code

1. Ouvrir l'app web Gemini Enterprise → Agents → Créer un agent (Workflow Builder).
2. Décrire l'agent en langage naturel (« un agent qui résume chaque lundi les tickets Jira de mon équipe ») : le concepteur propose les instructions et les étapes.
3. Ajouter des sources et outils : uniquement ceux déjà connectés par l'admin (Drive, Jira, serveurs MCP…).
4. Ajouter une étape « agent existant » : choisir un agent ADK ou A2A déjà publié dans l'app (ex. « Stock magasin (Supply) »). C'est ainsi qu'un utilisateur compose avec les agents de code, sans les connecter lui-même.
5. Tester → Publier → le partager (personnes ou groupes).

Limites à connaître :

• d'après la documentation Google, le sélecteur d'« agent existant » n'affiche pas les agents d'autres projets. Un agent cross-project doit donc d'abord être publié dans l'app (niveau 2 ou 3) ; il apparaît alors comme un agent de l'app (point à vérifier en recette) ;
• si l'agent réutilisé demande une connexion OAuth, l'utilisateur doit s'authentifier avant de lancer le workflow.

3.2 Les réglages admin qui ouvrent ou ferment ce niveau

Console → Gemini Enterprise → l'app → Configurations → fonctionnalités de l'app web :

Avec la validation activée, l'admin traite les demandes dans app → Agents → colonne Autorisations utilisateur → Examiner la demande de partage (Review share request).

4. Niveau 2 : le « builder délégué », la bonne réponse pour les équipes qui ont des agents de code

Le besoin : une équipe (ex. Supply) a son agent sur Agent Runtime, dans son projet, et veut le connecter à l'app sans ouvrir un ticket à chaque version.

La solution : lui donner le rôle Agent Admin sur le projet de l'app. Elle peut alors ajouter, modifier, retirer et partager des agents, sans pouvoir toucher à la sécurité de l'app.

4.1 Ce que l'admin fait une fois

Projet A (app) → 🔎 « IAM » → Accorder l'accès → groupe ge-builders-supply@acme.example → rôles :

• Agent Admin (roles/discoveryengine.agentAdmin) ;
• Gemini Enterprise Viewer (roles/discoveryengine.agentspaceViewer), pour ouvrir l'app en console.

Recommandé : une condition IAM de date d'expiration (accès revu chaque trimestre).

4.2 Ce que l'équipe builder fait ensuite, seule

1. Dans son projet B : déployer l'agent (tutoriel 03, méthode 1 ou 2) et donner au compte de Gemini Enterprise du projet A le droit cross-project (Discovery Engine Service Agent ou Cloud Run Invoker). Elle peut le faire : c'est son projet.
2. Dans le projet A : console → Gemini Enterprise → l'app → Agents → Ajouter un agent → Agent Runtime ou A2A (tutoriel 02, étape 6 ; A2A : tutoriel 03, M2.4). Ou en ligne de commande : ./scripts/add_agent_to_ge.sh adk|a2a ….
3. Onglet Autorisations utilisateur de l'agent → donner Agent User au groupe cible.

À valider en recette : que la page Agents de la console s'ouvre bien avec ces deux rôles seulement. Repli : l'équipe passe par l'API ou le script, qui n'ont besoin que d'Agent Admin.

4.3 Les garde-fous qui rendent la délégation acceptable

5. Niveau 3 : l'admin, ou la PR Terraform

Pour tout ce qui fait entrer du neuf autre qu'un agent (serveur MCP, source de données, Agent Gateway, Model Armor), et pour les équipes qui ne sont pas builders : l'admin Gemini Enterprise, dans la console du projet de l'app (tutoriels 02 et 03), ou une PR dans external_adk_agents (Terraform, README §4). La PR est le mode recommandé en production : relue, tracée, réversible.

6. Le circuit que nous recommandons pour Acme

Checklist avant d'accepter un agent (admin ou builder) :

• Hébergé en europe-* (app eu), sur Agent Runtime de préférence
• Model Armor dans l'agent (refuse de démarrer sans)
• Identité dédiée, droits minimum
• Les actions qui modifient demandent une confirmation humaine
• Description claire (c'est elle qui fait choisir l'agent)
• Partagé à un groupe précis, pas à toute l'entreprise
• Propriétaire et contact indiqués (label owner)

Voir qui ajoute quoi (Logs Explorer, projet de l'app) :

logName:"cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName="discoveryengine.googleapis.com"
protoPayload.methodName=~"(Create|Update|Delete)Agent"

Pour en faire une alerte e-mail : métrique basée sur les journaux + règle d'alerte, même modèle que l'alerte « Shadow AI » du projet 08 (75_shadow_ai.tf).

7. Questions fréquentes

Sources

• Workflow Builder (création d'agents sans code)
• Ajouter un agent existant dans un workflow
• Connecter des serveurs MCP dans Workflow Builder
• Gérer les fonctionnalités de l'app web
• Partager un agent
• Rôles IAM vérifiés avec gcloud iam roles describe (octobre 2026)