Aller au contenu
Cercle IA Tech · Intégration Un site du réseau Cercle IA Tech

Guide

Délégation au niveau du domaine Google Workspace et IA

Donner à une IA l'accès aux données de tous les utilisateurs Google Workspace : la délégation au niveau du domaine, la procédure, les précautions.

Mis à jour le

La délégation au niveau du domaine permet à un administrateur Google Workspace d'autoriser une application à accéder aux données de tous les utilisateurs de l'organisation, sans demander le consentement de chacun. Concrètement, un compte de service peut alors agir au nom de n'importe quel utilisateur, par exemple pour qu'une IA lise les boîtes Gmail ou les fichiers Drive de toute l'équipe. C'est le pouvoir le plus large que l'on puisse donner à une intégration Google : il se donne avec des scopes étroits, se revoit régulièrement, et se retire dès qu'il ne sert plus.

La page d'aide de Google s'intitule « Contrôler l'accès à l'API à l'aide de la délégation au niveau du domaine ». Voici son contenu utile, lu le 15/11/2026.

Quand en a-t-on besoin ?

Situation Délégation nécessaire ?
Un salarié connecte sa propre boîte à un assistant Non : il donne son consentement lui-même
Une IA trie la boîte partagée d'un service Souvent, si l'application doit agir sans personne connectée
Une IA indexe les Drive de toute l'équipe Oui, ou un consentement de chaque personne
Un outil de migration ou une automatisation interne Ce sont les exemples cités par Google

Certains scopes n'existent qu'avec cette délégation : Google précise que les opérations de gmail.settings.sharing sont réservées à l'administration et accessibles seulement aux clients Google Workspace qui utilisent un compte de service avec délégation au niveau du domaine.

Pour l'accès individuel, côté utilisateur, voir NL-Q Drive.

La procédure

Il faut être connecté en super-administrateur.

  1. Dans la console d'administration : « Sécurité » > « Contrôle des accès et des données » > « Commandes des API » > « Gérer la délégation au niveau du domaine ».
  2. Ajouter une nouvelle autorisation (bouton « Add new » dans la version anglaise de l'aide).
  3. Saisir l'ID client du compte de service ou du client OAuth 2.0.
  4. Dans le champ des scopes OAuth, ajouter chaque scope dont l'application a besoin, en restant aussi étroit que possible.
  5. Valider l'autorisation (« Authorize »). En cas d'échec, Google cite deux causes : l'ID client n'est pas enregistré chez Google, ou des scopes sont en double ou non pris en charge.
  6. Vérifier dans le détail que chaque scope apparaît bien.

Les changements peuvent prendre jusqu'à 24 heures, mais s'appliquent en général plus vite. Si l'approbation à plusieurs est activée dans votre organisation, un autre super-administrateur doit approuver.

Les précautions données par Google

  • Portée totale. Google l'écrit : l'application a accès aux données de tous vos utilisateurs. D'où la consigne de scopes étroits.
  • Revue des scopes. Vérifier régulièrement les scopes de l'application et retirer ceux qui ne sont pas nécessaires ou plus utilisés.
  • Revue des comptes de service. Les passer en revue régulièrement et supprimer ceux qui ne servent plus.
  • Effet d'une suppression. Les applications qui dépendent de l'autorisation cessent de fonctionner immédiatement : prévenez avant de retirer.

Choisir les scopes pour une IA

Partez de ce que fait l'IA, pas de ce qui est plus simple à configurer. Pour Gmail, par exemple :

L'IA doit… Scope
Classer d'après l'expéditeur et l'objet gmail.metadata
Lire pour résumer gmail.readonly
Préparer des brouillons gmail.compose

Évitez https://mail.google.com/, l'accès complet, que Google réserve aux applications qui doivent supprimer définitivement des messages. Le détail des scopes Gmail est sur la page Gmail API : scopes restreints.

Une remarque sur la vérification : selon Google, l'installation à l'échelle du domaine par un administrateur dispense de la vérification de la marque, mais pas de la vérification de l'application si elle utilise des scopes sensibles ou restreints. Une application réglée en « Internal », utilisée seulement dans votre organisation, en est en revanche exemptée.

Les garde-fous à ajouter vous-même

La délégation ne limite pas les utilisateurs concernés : elle vaut pour toute l'organisation. Les limites doivent donc être dans votre code :

  1. Une liste d'utilisateurs autorisés. Le compte de service n'emprunte l'identité que des comptes prévus (la boîte partagée, l'équipe pilote).
  2. Un journal de chaque emprunt d'identité : quel compte, quel scope, quelle opération.
  3. La clé du compte de service dans un coffre, jamais dans le code ni sur un poste.
  4. Une date de revue inscrite au calendrier, pour appliquer la consigne de revue de Google.

Chez Microsoft, l'équivalent est une permission d'application, que l'on peut restreindre à certaines boîtes par RBAC dans Exchange Online : voir Microsoft Graph et les mails Outlook.

Questions fréquentes

Qui peut accorder la délégation au niveau du domaine ?

Seul un super-administrateur de Google Workspace. Si l'approbation à plusieurs est activée, l'autorisation doit aussi être approuvée par un autre super-administrateur.

Combien de temps faut-il pour que la délégation prenne effet ?

Google indique que les changements peuvent prendre jusqu'à 24 heures, mais qu'ils s'appliquent en général plus vite.

Sources

Pages consultées pour écrire cet article :

  1. https://knowledge.workspace.google.com/admin/apps/control-api-access-with-domain-wide-delegation?hl=en
  2. https://knowledge.workspace.google.com/admin/apps/control-api-access-with-domain-wide-delegation?hl=fr
  3. https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification
  4. https://developers.google.com/workspace/gmail/api/auth/scopes

À lire aussi