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.
- 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 ».
- Ajouter une nouvelle autorisation (bouton « Add new » dans la version anglaise de l'aide).
- Saisir l'ID client du compte de service ou du client OAuth 2.0.
- Dans le champ des scopes OAuth, ajouter chaque scope dont l'application a besoin, en restant aussi étroit que possible.
- 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.
- 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 :
- 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).
- Un journal de chaque emprunt d'identité : quel compte, quel scope, quelle opération.
- La clé du compte de service dans un coffre, jamais dans le code ni sur un poste.
- 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 :
- https://knowledge.workspace.google.com/admin/apps/control-api-access-with-domain-wide-delegation?hl=en
- https://knowledge.workspace.google.com/admin/apps/control-api-access-with-domain-wide-delegation?hl=fr
- https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification
- https://developers.google.com/workspace/gmail/api/auth/scopes