10-15. Déployer le serveur MCP et son agent « à la 3S » : GitHub Actions + Terraform

Le but : le même déploiement que 10-3 (Terraform) (serveurs MCP Sheets et Slides, agent A2A, Agent Registry, droits de Gemini Enterprise), mais lancé par le pipeline au merge sur main, avec l'identité agents-deployer-sa et un état Terraform dans un bucket GCS. Plus de terraform apply sur un poste.

Tout le modèle est expliqué une fois dans le projet 09 : 12-1-9 (ce qu'est la 3S et ce qu'on n'invente pas, le socle, WIF, GitHub, dépannage). Ce guide ne donne que ce qui change pour le projet 10.

Vérifié (15 octobre 2026, projet de test main-project-511608) : validate, fmt, et terraform plan réel du dossier stack-3s/deploy : 29 ressources (Sheets + Slides + agent Cloud Run), 27 (Sheets seul + agent Cloud Run + agent Agent Runtime). Pas encore exécuté : apply par le pipeline.

1. Les fichiers

Fichier	Rôle
`stack-3s/deploy/main.tf`	Backend GCS (préfixe `10-mcp-sheets`) + appel du module `../../terraform` (le Terraform du 10-3, sans copie)
`stack-3s/deploy/mcp.auto.tfvars`	Les valeurs de `config/10-mcp.env`, versionnées
`stack-3s/github/deploy-mcp.yml`	Le workflow : `validate` sur PR, `plan` + `apply` au merge

2. Le socle : celui du 09, une fois par projet

Le serveur MCP est dans le même projet que les agents : le socle du 09 sert aux deux. Ses rôles par défaut couvrent déjà le projet 10 (Agent Registry, Cloud Run, Cloud Build, et aiplatform.admin pour l'agent Agent Runtime). Si le socle n'existe pas encore : 12-1-9, partie 3. 3S : demandez le fournisseur WIF, le compte de déploiement et le bucket d'état.

3. Ce qui change par rapport à 10-3

10-3 (poste)	10-15 (pipeline)
`source scripts/config.sh config/10-mcp.env` (variables `TF_VAR_*`)	`stack-3s/deploy/mcp.auto.tfvars` (fichier versionné, mêmes valeurs)
`OAUTH_CLIENT_IDS=a,b`	`oauth_client_ids = ["a", "b"]`
`ALLOWED_DOMAINS=acme.example`	`allowed_domains = ["acme.example"]`
`NUM_APP=…`	`ge_project_number = "…"`
État dans `terraform/terraform.tfstate`	`gs://<projet>-tfstate/10-mcp-sheets/`

Le client OAuth (10-5, étape 1) se crée toujours à la main, dans la console : Google n'a pas d'API pour les clients OAuth « Application Web ». Son ID (pas son secret) va dans oauth_client_ids ; sans lui, Terraform s'arrête avant de créer le serveur (précondition). Le secret du client ne passe jamais par Git ni par le pipeline : il se colle dans l'app Gemini Enterprise.

4. Brancher et déployer

mkdir -p .github/workflows
cp 10-mcp-google-sheets-gemini-enterprise/stack-3s/github/deploy-mcp.yml .github/workflows/

Les 3 variables du dépôt (GCP_WIF_PROVIDER, GCP_DEPLOYER_SA, GCP_TFSTATE_BUCKET) sont les mêmes que pour le 09 ; si elles existent déjà, rien à faire. Puis :

git switch -c mcp/premier-deploiement
# modifier stack-3s/deploy/mcp.auto.tfvars : projet, numéro, ID du client OAuth, domaine
git commit -am "mcp : premier déploiement" && git push -u origin mcp/premier-deploiement

Pull request → verifier (fmt, validate) → relecture → merge → deployer (plan, apply, 5 à 8 min avec les deux images). Tests : 10-8.

Je veux	Dans `mcp.auto.tfvars`
Sheets seul	`produits_mcp = ["sheets"]` (10-14)
L'agent aussi sur Agent Runtime	`deploy_agent_runtime = true`
Donner l'accès à l'app	`ge_project_number = "<NUMÉRO du projet de l'app>"`

5. Déjà déployé avec 10-3 sur le poste ?

L'état local et l'état GCS sont distincts : le pipeline voudrait tout recréer (et échouerait sur les noms déjà pris). Déplacer l'état une fois, avant le premier merge :

cd 10-mcp-google-sheets-gemini-enterprise/terraform && terraform state pull > /tmp/etat-10.json
cd ../stack-3s/deploy && terraform init -backend-config=bucket=<PROJET>-tfstate
terraform state push /tmp/etat-10.json
# les ressources passent dans le module « mcp » (les sources « data. » se relisent seules)
terraform state list | grep -v '^data\.' | while read -r a; do terraform state mv "$a" "module.mcp.$a"; done
terraform plan    # attendu : « without changing any real infrastructure » (seules les sorties changent)

Vérifié sur une copie de l'état réel du projet 10 (36 objets dans l'état, Sheets + Slides + agent Cloud Run et Agent Runtime) : après ces commandes, plan n'annonce aucune création, modification ni suppression.

Plus simple sur un projet de test : terraform destroy en local, puis laisser le pipeline tout recréer.

6. Nettoyer

terraform destroy dans stack-3s/deploy (avec le compte du pipeline : 12-1-9, partie 6), puis retirer .github/workflows/deploy-mcp.yml. Le socle se supprime depuis le 09, en dernier.