Comment voir quels outils d'IA ont accès à votre Google Workspace

Vous pouvez voir tous les outils d'IA disposant d'un accès OAuth à votre Google Workspace depuis la console d'administration, sous Sécurité → Contrôle des accès et des données → Contrôles des API → Contrôle d'accès aux applications. Elle liste toutes les applications tierces autorisées dans votre domaine — y compris les assistants d'IA, les extensions de navigateur et les robots de prise de notes de réunion — ainsi que les données Google que chacune s'est vu accorder.

Ce guide détaille ce chemin, ce que la console montre réellement, où elle atteint ses limites, et comment garder cette liste à jour une fois que vous l'avez.

Où trouver l'accès des applications tierces dans la console d'administration Google ?

1. Connectez-vous à admin.google.com en tant que super-administrateur ou administrateur disposant du privilège Services.
2. Accédez à Menu → Sécurité → Contrôle des accès et des données → Contrôles des API.
3. Cliquez sur Gérer l'accès aux applications (également appelé Contrôle d'accès aux applications dans certaines versions de la console).

Vous arrivez sur une liste répartie en Applications configurées (applications pour lesquelles votre organisation a explicitement défini un niveau d'accès) et Applications utilisées (toutes les applications actuellement utilisées, que vous les ayez configurées ou non). Pour chaque application, vous pouvez voir :

• Le nom de l'application, son éditeur et son identifiant client OAuth.
• Si elle porte le badge de vérification d'applications de Google.
• Les périmètres (scopes) de services Google individuels qu'elle demande — Drive, Gmail, Calendar, Admin Directory, etc. — développables par application.
• Le nombre d'utilisateurs de votre domaine l'ayant autorisée.
• Le niveau d'accès que vous pouvez définir : Approuvée, Limitée, Données Google spécifiques, ou Bloquée.

Vous pouvez également exporter la liste complète au format CSV, et appliquer différents niveaux d'accès à différentes unités organisationnelles plutôt qu'à l'ensemble du domaine en une seule fois.

Comment savoir lesquelles de ces applications sont des outils d'IA ?

La console de Google n'étiquette rien comme « IA » — elle liste toutes les applications connectées via OAuth de la même manière, qu'il s'agisse d'un module complémentaire de tableur ou d'un assistant basé sur un grand modèle de langage. En pratique, les outils d'IA apparaissent sous des formes variées : un éditeur d'IA directement (OpenAI, Anthropic, Perplexity), un robot de prise de notes de réunion (Otter.ai, Fireflies, Fathom), un assistant de rédaction (Grammarly, Jasper), ou un module complémentaire plus discret (« GPT for Sheets and Docs », « AI Email Writer ») dont le nom de l'éditeur ne donne aucun indice sur sa fonction. Les repérer relève d'un exercice manuel de reconnaissance de motifs : parcourez les noms des applications et de leurs éditeurs, et vérifiez les périmètres demandés — une application demandant drive.readonly ou gmail.readonly associée à un nom que vous ne reconnaissez pas mérite un examen plus approfondi, quelle que soit sa catégorie.

Comment vérifier quels outils d'IA une personne précise a autorisés ?

La vue à l'échelle du domaine ci-dessus vous indique qu'une application a des utilisateurs ; elle ne vous dit pas *qui*, ni *quand* il l'a autorisée. Pour cela :

1. Accédez à Menu → Annuaire → Utilisateurs et ouvrez le compte de la personne concernée.
2. Ouvrez son onglet Sécurité.
3. Faites défiler jusqu'à Applications connectées.

Cette section liste toutes les applications tierces que cet utilisateur en particulier a autorisées, le niveau d'accès (les périmètres qu'elle peut utiliser), et la date d'autorisation. Un administrateur disposant du privilège de gestion de la sécurité des utilisateurs peut révoquer directement l'un de ces accès depuis cette page. C'est le seul endroit où la console indique *quand* une application a été autorisée — mais cela implique de vérifier une personne à la fois, sans export en masse ni possibilité de filtrer sur les seuls « outils d'IA ».

Quelles sont les véritables limites de cette démarche manuelle ?

L'écran de contrôle d'accès aux applications à l'échelle du domaine agrège les décomptes mais omet le détail par utilisateur ; l'écran des applications connectées par utilisateur possède ce détail mais pas de vue d'ensemble. Ni l'un ni l'autre ne vous indique :

• Si l'accès est toujours utilisé, ou s'il a été accordé une fois puis oublié.
• Ce que l'application a réellement fait avec les données auxquelles elle peut accéder — la console montre ce qu'elle *peut* atteindre, pas ce qu'elle *a* atteint.
• Comment la situation a évolué dans le temps, puisqu'il n'existe aucun historique des autorisations accordées ou des périmètres élargis.
• Lesquelles des applications listées sont des outils d'IA, à moins que vous ne reconnaissiez vous-même chaque nom d'éditeur.

Pour un Workspace comptant une poignée d'applications connectées, parcourir les deux écrans à la main reste réaliste. Au-delà de quelques dizaines d'applications et de quelques centaines d'utilisateurs, maintenir la liste à jour cesse d'être une tâche ponctuelle et devient une tâche récurrente — la même information, revérifiée, indéfiniment. Et les deux écrans exigent un rôle d'administrateur disposant du bon privilège (Services pour la vue à l'échelle du domaine, gestion de la sécurité des utilisateurs pour la vue par utilisateur) — un Workspace comptant plusieurs administrateurs a quand même besoin d'une personne qui vérifie régulièrement les deux, et non d'une tâche qui échoit naturellement à celui qui s'en aperçoit.

Que ne peut pas révéler la vue manuelle, et comment 8200.dev y répond-il ?

La démarche manuelle répond à la question « qu'est-ce qui peut atteindre les données ? ». Elle ne répond pas à « qui l'a utilisé, quand, et est-ce encore nécessaire ? » — les questions qui déterminent réellement si une application doit conserver son accès. Agent Guard de 8200.dev recense chaque agent d'IA et chaque application connectée via OAuth sur l'ensemble de vos sources connectées dans une vue unique et continuellement mise à jour, évalue le risque de chacun, et explique le constat en langage clair plutôt que sous forme de chaîne de périmètre technique. La découverte se fait en lecture seule : la connexion à Google Workspace utilise un périmètre de métadonnées Drive en lecture seule, et l'inventaire plus approfondi des applications OAuth présenté ci-dessus devient disponible une fois qu'une organisation active l'audit des applications OAuth, ce qui réautorise l'accès avec les périmètres Admin SDK supplémentaires en lecture seule requis par Google pour cette vue spécifique — rien ici ne modifie l'accès de sa propre initiative ; toute action reste une recommandation tant que l'organisation n'a pas choisi d'agir.

Consultez la liste complète des connecteurs pour voir comment cela s'étend au-delà de Google Workspace à Microsoft 365, Slack, GitHub, et aux éditeurs d'IA eux-mêmes.