Des agents à vous, dans Gemini Enterprise

Activer les API de l'agent, voir ses portées

source scripts/config.sh config/12-1-agents-dans-projet-exp.env
./scripts/deployer_shell.sh oauth {{K}}

== courriels
▶ gcloud services enable gmail.googleapis.com --project={{PROJET_AGENTS}}
  portées (A2A)           : https://www.googleapis.com/auth/gmail.readonly
  portées (Agent Runtime) : … + https://www.googleapis.com/auth/cloud-platform
Client OAuth (une fois, console, 2 min) : https://console.cloud.google.com/auth/clients?project={{PROJET_AGENTS}}

Les API et les portées viennent du bloc "oauth" de l'agent dans catalogue.json.

Le client OAuth

1. 🔎 Google Auth Platform → si besoin Commencer : nom de l'application, e-mail, audience Interne.
2. Clients → + Créer un client → Application Web → nom ge-{{K}}.
3. URI de redirection autorisés, ces deux-là exactement :

https://vertexaisearch.cloud.google.com/oauth-redirect
https://vertexaisearch.cloud.google.com/static/oauth/oauth.html

→ Créer → notez l'ID client (à mettre dans « Vos valeurs ») et le secret. Ne les mettez jamais dans le dépôt.

Déployer l'agent avec son autorisation

AGENTS_OAUTH="{{K}}={{AUTH}}" ./scripts/deployer_shell.sh cloudrun {{K}}
./scripts/deployer_shell.sh tester {{K}}   # 3 à 5 min après : « cliquez sur Autoriser » = normal

L'agent reçoit AUTH_ID={{AUTH}}. En A2A, le nom de l'autorisation dans l'app peut être différent ; sur Agent Runtime, il doit être identique.

La fiche, avec l'URL d'autorisation complète

AGENTS_OAUTH="{{K}}={{AUTH}}" CLIENT_ID={{CLIENT_ID}} ./scripts/deployer_shell.sh carte {{K}}

  3. Authentication (ne PAS cliquer Skip) :
      Nom de l'autorisation  : {{AUTH}}
      Authorization URL      : {{AUTH_URL}}
      Token URL              : https://oauth2.googleapis.com/token
      Scopes                 : {{SCOPES}}
      PKCE / HTTP Basic      : décochés

Le droit de l'app sur le service

Droit ① sur {{K}}-a2a-shell, comme pour tout agent A2A (onglet 2).

Ajouter l'agent avec l'autorisation

Console : Custom agent via A2A → la carte → Authentication : remplissez les champs de la fiche. Ne cliquez pas sur Skip.

Ou par script, avec les valeurs de l'app données devant les commandes (le fichier de config n'est pas touché) :

export PROJET_APP={{PROJET_APP}} NUM_APP={{NUM_APP}} GE_LOCATION={{GE_LOCATION}}
export GE_PROJECT={{PROJET_APP}} GE_APP={{APP_ID}}
./scripts/autorisation_oauth.sh create {{AUTH}} ~/Downloads/client_secret_XXX.json "{{SCOPES}}" "{{NOM}}"
AUTH_ID={{AUTH}} ./scripts/add_agent_to_ge.sh a2a carte-{{K}}.json "{{NOM}} (A2A)"   # + droit run.invoker
./scripts/personnaliser_agent.sh "{{NOM}} (A2A)" {{K}}                              # questions proposées, langue

Le test

Agent User pour vous → ouvrez l'agent → « {{EX}} » → encadré Authorize → fenêtre Google → Autoriser → la réponse, avec vos données. Ensuite, plus d'encadré : l'accès est gardé.

L'application OAuth Atlassian

1. developer.atlassian.com/console/myapps → Create → OAuth 2.0 integration.
2. Permissions : Jira API (read:jira-work, read:jira-user), Confluence API (search:confluence, read:confluence-content.summary).
3. Authorization → Callback URL : https://vertexaisearch.cloud.google.com/static/oauth/oauth.html.
4. Settings : Client ID et Secret. Distribution → Sharing : sinon, vous seul pouvez autoriser.

Déployer sur Agent Runtime avec les deux autorisations

AGENTS_OAUTH="workspace=acces-google,acces-atlassian" ./scripts/deployer_shell.sh runtime workspace
AGENTS_OAUTH="workspace=acces-google,acces-atlassian" CLIENT_ID={{CLIENT_ID}} ./scripts/deployer_shell.sh carte workspace

Dans l'app : deux autorisations

Custom agent via Agent Runtime → Authorizations → Add authorization deux fois. Les noms doivent être identiques à AGENTS_OAUTH.

Par script : AUTH_ID=acces-google,acces-atlassian ./scripts/add_agent_to_ge.sh adk <chemin> "Espace de travail". En A2A, le script refuse : « UNE seule autorisation par agent ».

Dans le chat

« Mes tickets Jira en cours ? » → un 2^e bouton Authorize (Atlassian) → Accept → la liste. « Prépare ma semaine avec réunions, e-mails et tickets » → les trois sources dans une seule réponse.

La fenêtre Google (sans risque)

Projet du client OAuth → 🔎 Google Auth Platform → Branding : nom (« Assistant Acme »), logo PNG 120×120, e-mail d'équipe. Puis Accès aux données → déclarer les portées : elles s'affichent en clair.

Le nom de l'autorisation

export PROJET_APP={{PROJET_APP}} NUM_APP={{NUM_APP}} GE_LOCATION={{GE_LOCATION}}
./scripts/autorisation_oauth.sh list                              # ID | nom affiché
./scripts/autorisation_oauth.sh renommer {{AUTH}} "{{NOM}}"

Si l'encadré montre encore l'ID après renommage, recréez l'autorisation avec un ID lisible, puis rattachez l'agent.

L'agent : nom, questions, texte de saisie, langue, icône

GE_PROJECT={{PROJET_APP}} GE_APP={{APP_ID}} GE_LOCATION={{GE_LOCATION}} \
  ./scripts/personnaliser_agent.sh "<nom actuel dans l'app>" {{K}} --icone icone.png

AVANT : {"displayName": "test gmail remote agent with auth"}
APRÈS : {"displayName": "{{NOM}} (A2A)", "starterPrompts": [{"text": "{{EX}}"}, …], "languageCode": "fr"}
Modifier cet agent dans l'app {{APP_ID}} (projet {{PROJET_APP}}) ? Tapez « oui » : oui
modifié : …  (retour arrière : ./scripts/personnaliser_agent.sh --annuler avant-<ID>.json)

Seuls ces champs changent (updateMask) : ni la carte, ni l'autorisation.