Collaboration spaces Module

Vaks PM · Guide d'intégration · Microsoft Teams · Slack · Google Chat · Juillet 2026

Ce que fait le provisioning des espaces de collaboration — et ce qu'il ne fait pas

• Cela se déclenche à l'activation du projet. Un projet standard entrant dans l'état actif provisionne un espace chez chaque fournisseur activé. Il n'y a pas de drapeau d'opt-in par projet — l'interrupteur de chaque fournisseur gouverne tous les projets standard.
• Cela maintient la composition en phase au fil des arrivées et des départs sur le projet, de façon additive par défaut. Retirer des personnes de l'espace quand elles quittent le projet est un réglage que vous activez.
• Le cycle de vie à la clôture dépend du fournisseur. Microsoft Teams archive son équipe quand le projet se termine (jamais de suppression) ; Slack, Google Chat et le Drive partagé ne s'archivent pas automatiquement (voir Supprimer / détacher).

Comment marche « Collaboration spaces »

Deux voies indépendantes mènent au même endroit. Sortante : Vaks crée lui-même l'espace via le fournisseur configuré (Teams, Slack, Google Chat). Entrante : un outil qui gère son propre espace (un canal Slack déjà possédé par votre équipe, une équipe Teams provisionnée hors Vaks, un espace Google monté par un autre système) déclare le lien en retour. Les deux voies convergent vers le même enregistrement et le même panneau sur le projet.

Les fournisseurs ne se valent pas sur tout : l'archivage à la clôture ne s'applique aujourd'hui qu'à Microsoft Teams (les canaux Slack et espaces Google Chat sont créés mais pas archivés automatiquement à la clôture d'un projet) ; la visibilité public/privé est un concept Teams et Slack que Google Chat n'a pas. Un espace déclaré depuis l'extérieur n'est jamais touché par ces règles de cycle de vie — seuls les espaces provisionnés par Vaks le sont.

Prérequis

Microsoft Teams est celui des trois qui demande le plus côté identité — le tableau ci-dessous lui est spécifique. Slack et Google Chat sont plus légers (aucune dépendance Entra/SSO) et ont chacun leur propre courte liste de prérequis dans leur section de mise en place plus bas.

Étape 1 — L'inscription d'application Entra

Créez une nouvelle inscription d'application dans Centre d'administration Microsoft Entra → Identité → Applications → Inscriptions d'applications → Nouvelle inscription, mono-tenant, sans URI de redirection. Elle s'authentifie en son nom propre avec le flux client credentials — aucun utilisateur n'est impliqué.

Sous Autorisations d'API → Ajouter une autorisation → Microsoft Graph → Autorisations d'application, ajoutez :

Team.Create
TeamMember.ReadWrite.All
Channel.Create
TeamSettings.ReadWrite.All

En option, ajoutez User.Read.All pour aider à résoudre les identités. Puis pressez Accorder le consentement administrateur et vérifiez que la colonne d'état affiche Accordé pour chacune — les permissions d'application ne font rien tant qu'elles ne sont pas consenties.

Récupérez le Directory (tenant) ID et l'Application (client) ID depuis la Vue d'ensemble, et créez un secret client sous Certificats & secrets, en copiant sa valeur aussitôt.

Étape 2 — Dans Vaks PM

Ouvrez Admin → Intégrations → Espaces de collaboration, choisissez Ajouter un fournisseur → Microsoft Teams, et configurez-le :

Étape 3 — Tester, puis provisionner

Pressez Tester sur la carte du fournisseur pour confirmer que les identifiants sont acceptés par Graph.

À partir de là, le provisioning est automatique : activez un projet standard et son équipe est créée. Le panneau Espaces de collaboration de chaque projet dispose aussi de boutons manuels — Provisionner maintenant, Re-synchroniser, Archiver — et affiche les dernières entrées du journal de provisioning avec le décompte des membres ajoutés et ignorés.

Étape 4 — Documents SharePoint pour les agents et les membres (optionnel)

Chaque équipe provisionnée a un site SharePoint derrière elle. Cette extension permet aux agents IA travaillant sur le projet — et aux membres du projet qui ont accès à l'équipe — de lire ces documents comme contexte en direct : rien n'est copié, et c'est en lecture seule. Les membres les consultent sous l'onglet SharePoint de l'espace documents du projet ; les agents y accèdent via leur contexte de travail.

Elle nécessite une permission Graph supplémentaire sur l'app, dans l'un de deux modèles :

• Read-all (plus simple) : ajoutez Sites.Read.All à l'app de provisioning. Un seul consentement ; Vaks PM restreint les lectures aux drives des équipes provisionnées.
• Selected-sites (plus serré) : l'app de provisioning détient Sites.FullControl.All et accorde à une seconde app lectrice minimale un accès Sites.Selected au site de chaque équipe au fur et à mesure du provisioning. Les lectures des agents passent par l'app lectrice, qui ne peut voir que les sites qui lui ont été accordés.

Activez-la ensuite à deux endroits — à l'échelle de l'org sous Intégrations → Collaboration spaces (dans la carte SharePoint : Enable SharePoint context, plus le modèle d'identité et, pour le modèle selected, l'ID client et le secret de l'app lectrice), et par projet (SharePoint document context, qui exige aussi que le projet ait les agents activés).

Étape 1 — L'app Slack

Slack n'a aucun prérequis d'identité — il lui faut un bot token et rien d'autre. Allez sur api.slack.com/apps → Create New App → From scratch, nommez-la (ex. Vaks PM) et choisissez le workspace où elle doit vivre.

Sous OAuth & Permissions → Scopes → Bot Token Scopes, ajoutez :

channels:manage
groups:write
users:read.email

channels:manage crée et gère les canaux publics, groups:write fait de même pour les canaux privés, et users:read.email sert à résoudre l'email d'un membre du projet vers un compte Slack pour l'inviter. Ajoutez celui des deux premiers qui correspond à la visibilité de canal que vous comptez utiliser — les deux si vous n'êtes pas encore sûr.

Remontez à OAuth Tokens et cliquez sur Install to Workspace (un admin du workspace doit approuver si vous n'en êtes pas un). Copiez le Bot User OAuth Token — il commence par xoxb-.

Étape 2 — Dans Vaks PM

Ouvrez Admin → Intégrations → Collaboration spaces, choisissez Ajouter un fournisseur → Slack, et configurez-le :

Cliquez sur Tester pour confirmer que le token est accepté, puis activez un projet standard pour voir son canal créé — ou, pour un projet déjà actif, utilisez l'outil Provisionner maintenant directement sur la carte Slack (collez l'id du projet) plutôt que de faire un aller-retour de statut.

Étape 1 — Google Cloud & Workspace

Google Chat est le plus lourd des trois à mettre en place, car l'API Chat n'a pas de mode app-only : créer un espace et y ajouter des membres exige toujours un utilisateur Workspace réel, donc un compte de service doit l'impersonner via une délégation domain-wide. Attendez-vous à impliquer un admin Google Cloud et un admin Workspace.

1. Activer l'API. Dans un projet Google Cloud (créez-en un si besoin), allez sur APIs & Services → Library, cherchez Google Chat API, et activez-la.
2. Configurer l'app Chat — ne pas sauter cette étape. Activer l'API ne suffit pas : ouvrez l'onglet Configuration de la Google Chat API (console.cloud.google.com/apis/api/chat.googleapis.com/hangouts-chat) et renseignez un nom d'app, une URL d'avatar (n'importe quelle image https) et une description. Vaks ne faisant que des appels REST (jamais de bot interactif), laissez les fonctionnalités interactives désactivées (sinon Google réclame une URL de connexion inutile). Rendez l'app visible pour votre domaine. Sans cette configuration, tout appel Chat renvoie « PERMISSION_DENIED — the resource doesn't exist », même avec une délégation parfaite — c'est le piège le plus courant.
3. Créer un compte de service. IAM & Admin → Service Accounts → Create Service Account. Notez son email (…@….iam.gserviceaccount.com). Deux modes d'authentification ensuite : clé de compte de service (téléchargez une clé JSON via Keys → Add Key → JSON) ou Workload Identity, sans clé (rien à télécharger — voir la section dédiée juste après, recommandée si votre organisation bloque la création de clés de compte de service).
4. Activer la délégation domain-wide. Toujours sur la page du compte de service, cochez Enable Google Workspace Domain-wide Delegation et notez le Client ID (un long nombre, pas l'email).
5. Autoriser les scopes, dans la console admin Workspace. Dans admin.google.com (un super admin Workspace est requis ici) → Security → API controls → Domain-wide delegation → Add new : collez le Client ID numérique, et ces scopes :

   https://www.googleapis.com/auth/chat.spaces,https://www.googleapis.com/auth/chat.memberships

6. Choisir un utilisateur à impersonner. N'importe quelle boîte Workspace réelle et licenciée convient — c'est l'identité que le compte de service emprunte pour agir comme un humain. Un compte d'exploitation/automatisation est un choix courant ; il ne peut simplement pas être le compte de service lui-même.

Sans clé — Workload Identity Federation (commun à toutes les intégrations Google)

Beaucoup d'organisations orientées sécurité appliquent la règle d'organisation Google iam.disableServiceAccountKeyCreation, qui interdit de télécharger une clé de compte de service. Dans ce cas, la méthode par clé ci-dessus est un mur. Vaks PM propose alors un second mode d'authentification, Workload Identity Federation (WIF), qui n'a besoin d'aucune clé téléchargée — c'est le chemin qu'un client Google sérieux acceptera.

Le principe : Vaks signe un jeton OIDC avec sa propre clé (dont Google ne connaît que la partie publique, collée dans la config du pool), Google l'échange contre un jeton fédéré, puis signe l'assertion de délégation domain-wide côté serveur. La clé détenue par Vaks ne donne aucun accès en soi : l'accès est gouverné par la config WIF et un droit IAM, tous deux révocables par vous à tout moment.

Ce cloisonnement est délibéré : chaque intégration a sa propre clé, donc vous pouvez la régénérer ou la révoquer sans casser les autres. Si vous n'utilisez qu'une seule intégration en WIF, vous n'avez évidemment qu'un seul provider à créer.

Une fois par organisation

1. Cibler le projet (l'ID, en texte — pas le numéro) :

   gcloud config set project PROJECT_ID

2. Créer le pool d'identités — une seule fois, réutilisé par toutes les intégrations :

   gcloud iam workload-identity-pools create vaks --location=global --display-name="Vaks PM"

Une fois par intégration

Répétez ce bloc pour chaque ligne du tableau ci-dessus que vous activez. Toutes les commandes de cette page utilisent les mêmes marqueurs à remplacer :

1. Compte de service sans clé. Le compte de service de l'étape 1 convient — ne créez simplement aucune clé JSON. La délégation domain-wide (Client ID + scopes en admin Workspace) reste celle de l'intégration concernée.
2. Générer la clé de signature dans Vaks. Dans la carte de l'intégration, basculez Authentification sur Workload Identity (sans clé), puis Générer la clé de signature. Vaks affiche l'issuer, le kid et un JWKS public — la clé privée reste chiffrée en base, jamais exposée.

   Créez le fichier dans Cloud Shell. Entre les deux EOF, collez le contenu exact du champ « JWKS public » de la carte — le bloc {"keys":[ … ]} complet, tel quel, sans rien modifier. Ce n'est pas un contenu à inventer ni à recopier d'un exemple : c'est votre clé publique, celle qui porte le kid affiché sur la carte. (Les guillemets autour du premier EOF empêchent le shell d'interpréter le contenu.)

   cat > jwks-PROVIDER_NAME.json <<'EOF'
   [[ COLLEZ ICI LE JWKS PUBLIC AFFICHÉ SUR LA CARTE ]]
   EOF

   Le JWKS ne contient que de la clé publique — il n'y a rien de secret à protéger dans ce fichier. Le kid qu'il porte doit être celui affiché sur la carte : c'est lui qui permettra plus tard de vérifier que Google détient la bonne version.

   Alternative si vous préférez un éditeur : cloudshell edit jwks-PROVIDER_NAME.json. Vérifiez au besoin que le fichier est du JSON valide avec python3 -m json.tool jwks-PROVIDER_NAME.json.

3. Créer le provider OIDC (JWKS collé, drapeau --jwk-json-path — pas --jwks-json-file dans les gcloud récents) :

   gcloud iam workload-identity-pools providers create-oidc PROVIDER_NAME \
     --location=global --workload-identity-pool=vaks \
     --issuer-uri="<ISSUER>" --jwk-json-path=jwks-PROVIDER_NAME.json \
     --attribute-mapping="google.subject=assertion.sub"

4. Autoriser le pool à impersonner le compte de service. Cette liaison se fait au niveau du pool, pas du provider : elle identifie le compte de service par son sujet, sans distinguer par quel provider le jeton est arrivé. Donc si vous réutilisez le même compte de service pour plusieurs intégrations, un seul binding suffit — il n'y a rien à rejouer. À ne refaire que si l'intégration utilise un compte de service différent.

   gcloud iam service-accounts add-iam-policy-binding SA_EMAIL \
     --role=roles/iam.serviceAccountTokenCreator \
     --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/vaks/subject/SA_EMAIL"

   Note : SA_EMAIL apparaît à deux endroits — le compte de service ciblé (juste après add-iam-policy-binding) et le subject/ du membre. Remplacez les deux par la même adresse.

5. Renseigner l'audience dans la carte : le nom de ressource complet du provider que vous venez de créer — il se termine par PROVIDER_NAME, pas par le nom du pool.

   //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/vaks/providers/PROVIDER_NAME

gcloud iam workload-identity-pools providers update-oidc PROVIDER_NAME \
  --location=global --workload-identity-pool=vaks \
  --jwk-json-path=jwks-PROVIDER_NAME.json

gcloud iam workload-identity-pools providers describe PROVIDER_NAME \
  --location=global --workload-identity-pool=vaks --format="value(oidc.jwksJson)"

https://www.googleapis.com/auth/chat.spaces,https://www.googleapis.com/auth/chat.memberships,https://www.googleapis.com/auth/drive

Étape 2 — Dans Vaks PM

Ouvrez Admin → Intégrations → Collaboration spaces, choisissez Ajouter un fournisseur → Google Chat, et configurez-le. Choisissez d'abord le mode d'Authentification : Clé de compte de service (le champ clé privée apparaît) ou Workload Identity (sans clé) (le champ audience et le panneau de génération de clé apparaissent à la place) :

Cliquez sur Tester — ça échange l'assertion du compte de service contre un jeton et fait un petit appel Chat API en lecture seule, confirmant que toute la chaîne de délégation fonctionne avant que quoi que ce soit ne soit créé. Puis activez un projet standard pour voir son espace apparaître.

Supprimer un espace, ou détacher un lien

Deux actions vivent sur chaque tuile de la section Collaboration spaces d'un projet, et il ne faut pas les confondre :

https://www.googleapis.com/auth/chat.spaces,https://www.googleapis.com/auth/chat.memberships,https://www.googleapis.com/auth/chat.delete

Étape 1 — Google Cloud & Workspace

Le provisioning Google Drive crée un Drive partagé par projet — l'équivalent Google du site SharePoint qui accompagne une équipe Teams. Comme pour Google Chat, un compte de service seul ne suffit pas : créer un Drive partagé exige un utilisateur Workspace réel, donc l'impersonation par délégation domain-wide est obligatoire, quel que soit le mode d'authentification.

1. Activer l'API. Dans votre projet Google Cloud, APIs & Services → Library → Google Drive API → activer.
2. Créer un compte de service. IAM & Admin → Service Accounts. Notez son email (…@….iam.gserviceaccount.com). Deux modes d'authentification ensuite : clé de compte de service (Keys → Add Key → JSON) ou Workload Identity, sans clé.
3. Activer la délégation domain-wide. Sur la page du compte de service, cochez Enable Google Workspace Domain-wide Delegation et notez le Client ID (le long nombre, pas l'email).
4. Autoriser le scope, en console admin Workspace. admin.google.com → Sécurité → Contrôle des API → Délégation au niveau du domaine → Ajouter : collez le Client ID numérique, et ce scope :

   https://www.googleapis.com/auth/drive

   Ce scope couvre la création du Drive et la gestion de ses membres. Il englobe la lecture : un compte de service dédié uniquement à la lecture des documents n'a besoin, lui, que de drive.readonly.
5. Choisir un utilisateur à impersonner. Une boîte Workspace réelle et licenciée, qui a le droit de créer des Drive partagés. Un compte d'exploitation convient bien.

Mode sans clé (Workload Identity) pour cette intégration

Le principe et le pool sont communs à toutes les intégrations Google — voir Sans clé — Workload Identity Federation pour la création du pool (à ne faire qu'une fois). Ce qui suit est le bloc propre au provisioning Drive : il lui faut son propre provider, car son issuer diffère de celui de Google Chat.

1. Dans la carte Google Drive (Étape 2 ci-dessous), passez Authentification sur Workload Identity (sans clé) puis Générer la clé de signature. L'issuer affiché se termine par /federation/gdrive-provisioning ; copiez le JWKS dans jwks-gdrive-prov.json.
2. Créez le provider dédié, dans le pool vaks déjà existant :

   gcloud iam workload-identity-pools providers create-oidc vaks-gdrive-prov \
     --location=global --workload-identity-pool=vaks \
     --issuer-uri="https://VOTRE-TENANT/federation/gdrive-provisioning" \
     --jwk-json-path=jwks-gdrive-prov.json \
     --attribute-mapping="google.subject=assertion.sub"

3. Le droit d'impersonation est porté par le pool : si le compte de service est déjà lié (par exemple pour Google Chat), il n'y a rien à refaire. Sinon, rejouez le add-iam-policy-binding de la section commune.
4. Collez cette audience dans le champ Audience du pool WIF de la carte :

   //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/vaks/providers/vaks-gdrive-prov

Étape 2 — Dans Vaks PM

Ouvrez Admin → Intégrations → Collaboration spaces, puis Ajouter un fournisseur → Google Drive. Choisissez d'abord le mode d'Authentification : le formulaire s'adapte (clé privée, ou audience du pool + panneau de génération de clé).

Cliquez sur Tester — l'assertion est échangée contre un jeton et un petit appel Drive en lecture est effectué, ce qui valide toute la chaîne de délégation avant que quoi que ce soit ne soit créé. Activez ensuite un projet standard pour voir son Drive apparaître. Re-provisionner un projet déjà pourvu ne recrée rien : ça re-synchronise seulement les membres.

Synchronisation de la composition

La composition est maintenue à jour de trois façons : quand les membres ou managers du projet changent, quand la composition d'une équipe affectée change, et par un job de filet de sécurité qui réconcilie périodiquement chaque projet actif provisionné. La synchronisation est additive seulement, sauf si Retirer à la sortie du projet est activé, et elle ne retire jamais le propriétaire. Seuls les membres actifs ayant une identité Entra sont ajoutés ; tous les autres sont ignorés et comptés dans le journal.

Espaces déclarés depuis l'extérieur

Tout ce qui précède fait que Vaks crée l'espace (Microsoft Teams). L'autre sens existe aussi : un outil externe qui crée lui-même l'espace — un canal Slack, un espace Google, ou une équipe Teams gérée hors de Vaks — vient déclarer le lien en retour, pour qu'il s'affiche sur le projet. Aucune licence de provisioning Teams n'est requise pour cette voie.

Elle s'appuie sur une clé d'organisation restreinte au seul périmètre collab:link — volontairement étroit : cette clé ne peut rien lire ni modifier d'autre sur le projet. Créez-la depuis Admin → Intégrations → Collaboration spaces : ajoutez le fournisseur Declared spaces API, qui frappe une clé scopée collab:link (le secret n'est affiché qu'une fois).

{provider} est une étiquette libre (slack, google, teams…). Le corps du PUT :

{
  "url": "https://…",         // requis, https obligatoire, ≤ 2048 car.
  "externalId": "C0123ABCD",  // optionnel — l'id de l'espace côté outil
  "name": "Projet Acme"       // optionnel — libellé affiché
}

Dépannage

Le provisioning est délibérément silencieux — il ne casse jamais une mise à jour de projet — c'est donc le panneau Espaces de collaboration du projet et son journal qu'il faut regarder. Les messages serveur reviennent en français quelle que soit la langue de l'interface, reproduits mot pour mot ci-dessous.

À lire aussi : sources de documents, le guide complet de SharePoint et Google Drive comme contexte de lecture · SCIM et OIDC, prérequis du lien d'identité Entra · connecteur IA pour les agents qui lisent le contexte SharePoint · toutes les intégrations.