Gouvernance Workspace et données

Dès l'instant où vous pointez Gemini vers les données de l'entreprise, la question intéressante n'est plus « qu'est-ce qu'il sait faire » mais « qu'a-t-il le droit de voir, et qui l'a décidé ». La gouvernance n'est pas une note de bas de page du déploiement de Gemini. Elle est le déploiement.

Cette leçon couvre les contrôles qui déterminent la portée de Gemini dans Google Workspace : où se situe réellement la frontière des données, en quoi comptes personnels et comptes Workspace diffèrent sur des points qui comptent pour la conformité, et ce qu'un admin active ou désactive. Nous suivrons une entreprise à travers un déploiement réaliste.

La frontière qui compte vraiment

Il existe une distinction qui explique presque toutes les décisions de gouvernance : un compte Google personnel versus un compte Workspace géré.

Quand un collaborateur utilise Gemini sur gemini.google.com connecté à un compte personnel @gmail.com, c'est un produit grand public régi par des conditions grand public. Par défaut, ces conversations peuvent être examinées par des humains et utilisées pour améliorer les modèles de Google. C'est acceptable pour une recette de cuisine. Ça ne l'est pas pour votre grille tarifaire non publiée.

Un compte géré est un utilisateur provisionné par l'admin Workspace de votre organisation (l'identité @votreentreprise.com). Ici, les règles s'inversent. Pour Gemini dans Workspace et pour l'app Gemini utilisée via un compte géré, Google indique que vos données ne sont pas utilisées pour entraîner ou améliorer des modèles en dehors de votre domaine, ne sont pas examinées par des humains à cette fin, et restent couvertes par vos protections de données Workspace existantes. Les prompts, les contenus générés et les fichiers que Gemini lit héritent du même traitement que le Doc ou l'e-mail lui-même.

Conséquence pratique : l'usage shadow sur des comptes personnels est votre vrai risque, pas l'outil officiel. Les gens collent du texte confidentiel dans un onglet Gemini personnel parce que c'est commode. La parade consiste à faire du compte géré le chemin de moindre résistance, et à bloquer ou décourager le personnel.

L'énoncé officiel de ces engagements se trouve dans **Comment Gemini pour Google Workspace protège vos données**.

Ce que Gemini peut voir (et la règle qui le contraint)

Gemini dans Workspace n'obtient pas de passe-partout. Il opère en tant qu'utilisateur connecté, avec exactement les permissions existantes de cet utilisateur. Cette seule règle dissipe la plupart des craintes du type « est-ce que ça peut fuiter ».

Quand quelqu'un demande dans Gmail à Gemini de « résumer le dernier fil de discussion de l'équipe finance », Gemini ne peut lire que ce que cette personne pouvait déjà ouvrir. Quand elle utilise le panneau latéral dans Docs ou Drive pour demander « qu'avons-nous décidé pour le lancement du T3 », Gemini ne récupère que les fichiers auxquels cet utilisateur a déjà accès. Il ne peut pas faire remonter un document qui ne lui a jamais été partagé.

C'est aussi là que la gouvernance devient inconfortable. **Gemini est un puissant outil de *découverte* sur des données que l'utilisateur peut techniquement consulter mais qu'il n'a jamais ouvertes**. Ce dossier sur-partagé de 2021 accessible à tout le domaine ? Aucun humain ne l'a jamais parcouru. Gemini le trouvera volontiers en deux secondes.

Donc le vrai travail préparatoire d'un déploiement Gemini n'est pas de configurer Gemini. C'est de corriger vos permissions Drive *avant* d'activer Gemini. L'outil ne crée pas l'exposition. Il révèle celle que vous aviez déjà.

Les contrôles réels de l'admin

La gouvernance Workspace se joue dans la console d'administration (admin.google.com), et Gemini s'administre comme tout autre service Google : via les unités organisationnelles (OU) et les groupes. Une OU est une portion de votre annuaire (par exemple « Juridique » ou « Stagiaires ») à laquelle vous appliquez une politique différente.

L'admin peut :

• Activer ou désactiver l'app Gemini par OU ou par groupe.
• Contrôler si Gemini dans les apps Workspace (le panneau latéral, « Aide-moi à écrire », les fonctions Meet) est disponible, et pour qui.
• Gouverner les extensions Gemini, qui permettent à l'app Gemini d'accéder aux données Workspace (Gmail, Drive, Docs), à Maps, Flights et plus. Chaque connexion est une surface explicite à autoriser ou restreindre.
• Gérer l'accès aux fonctionnalités alpha/bêta pour qu'un groupe pilote obtienne les nouveautés avant toute l'entreprise.

Un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → courant : tout activer pour une OU pilote de 200 personnes, laisser les 4 000 autres utilisateurs intacts, mesurer, puis étendre. Comme la politique s'applique au niveau de l'OU, c'est quelques clics, pas une migration.

Pour la gouvernance des données proprement dite, les interactions Gemini s'inscrivent dans les contrôles Workspace existants. Les régions de données peuvent fixer les données au repos dans une géographie donnée. La rétention et l'eDiscovery de Vault s'appliquent aux contenus Gemini concernés comme ils s'appliquent au courrier et à Drive. Les règles DLP (data loss prevention) et l'Access Transparency continuent de fonctionner. Vous ne greffez pas une nouvelle pile de conformité. Vous étendez celle que vous exploitez déjà.

Un déploiement concret : Northwind Logistics

Northwind compte 3 000 utilisateurs Workspace et une équipe juridique inquiète. Voici la séquence qui a effectivement fonctionné.

1. Colmater d'abord la fuite par comptes personnels. Avant toute annonce, l'admin a réduit l'incitation à l'usage shadow en rendant l'app Gemini gérée disponible et en communiquant une règle unique : les données de l'entreprise vont dans l'outil de l'entreprise, jamais dans un onglet Gemini personnel. (Workspace ne peut pas techniquement bloquer une connexion Gmail personnelle sur un appareil personnel : le levier est donc la politique interne plus une bonne expérience first-party.)

2. Auditer le partage Drive. À l'aide des rapports de sécurité de Drive, ils ont trouvé 40 000 fichiers partagés en « tous les membres de l'entreprise ». La plupart étaient inoffensifs. Environ 600 ne l'étaient pas (lettres de salaire, un dossier M&A). Ils les ont resserrés *avant* d'activer le panneau latéral Gemini, car Gemini les aurait sinon rendus trivialement trouvables.

3. Piloter sur une seule OU. Ils ont crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éé un groupe gemini-pilot de 150 personnes issues de plusieurs départements, activé l'app Gemini et les fonctions Workspace pour ce groupe, laissé actives les extensions Gmail et Drive, mais désactivé les extensions plus « tierces » pendant l'essai.

4. Surveiller les bons signaux. Vault capturait déjà les contenus pertinents pour l'eDiscovery. Ils ont vérifié que les interactions Gemini relevaient de leurs règles de rétention existantes et que rien ne sortait de leur région de données.

5. Construire un Gem gouverné. Plutôt que de laisser chacun improviser ses prompts, ils ont livré un Gem partagé (une configuration de Gemini enregistrée et paramétrée par instructions) pour l'équipe support : « Northwind Support Assistant », avec des instructions fixes sur le ton, l'escalade, et l'interdiction d'inventer une politique. Un Gem standardise le comportement, si bien que la gouvernance porte sur *un assistant configuré*, pas sur mille prompts ad hoc.

Cet ordre compte. Permissions d'abord, pilote ensuite, automatisation en troisième.

Quand l'automatisation entre en jeu : Apps Script et l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →

La phase suivante chez Northwind est allée au-delà du panneau latéral avec humain dans la boucle, vers l'automatisation, et cela change le tableau de la gouvernance.

Leur équipe ops voulait un job nocturne : lire un dossier Drive de rapports d'exceptions de livraison et produire un Doc de synthèse. Ils l'ont construit avec Apps Script, en appelant l'API Gemini. Le changement clé de gouvernance : un script ne s'exécute pas « en tant qu'utilisateur connecté » par-dessus l'épaule de quelqu'un. Il tourne sous l'identité et la clé que vous lui donnez, selon une planification, sans humain pour lire chaque sortie.

Cela implique trois nouvelles responsabilités. Identité : le script s'exécute en tant qu'utilisateur ou compte de service précis, donc son accès aux données est celui de ce compte. Restreignez-le au maximum. Gestion des clés : la clé d'API est un secret. Sa place est dans les Script Properties ou Secret Manager, jamais dans le code source. Revue des sorties : les résumés automatisés peuvent halluciner, donc un Doc généré qui oriente des décisions exige un point de contrôle humain.

import os
from google import genai

# Clé depuis l'environnement / le secret manager, jamais en dur.
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

def summarize_exceptions(report_text: str) -> str:
    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=(
            "Summarize these delivery exceptions for an ops manager. "
            "List only facts present in the text. Do not infer causes.\n\n"
            f"{report_text}"
        ),
    )
    return response.text

if __name__ == "__main__":
    with open("exceptions.txt") as f:
        print(summarize_exceptions(f.read()))

Notez le choix du modèle. Flash est le palier rapide et économique, adapté au résumé à haut volume ; Pro est le palier de raisonnement plus lourd que vous réservez aux analyses complexes. Le prompt est aussi un contrôle de gouvernance : « list only facts present in the text » réduit la fabricationfabricationUne hallucination, c'est lorsqu'un modèle d'IA produit une réponse fluide et assurée mais factuellement fausse, inventée, ou non étayée par ses données sources.Voir la définition complète →.

Il y a ici une autre distinction de compte, plus profonde. Les clés issues de Google AI Studio (aistudio.google.com) visent l'API Gemini Developer, parfaite pour le prototypage. Quand Northwind passera en production, ils migreront probablement vers Vertex AI (cloud.google.com/vertex-ai), où les mêmes modèles tournent sous Google Cloud IAM, contrôles VPC, audit logging et conditions de traitement des données entreprise. Pour une charge de travail qui touche aux données de l'entreprise, cette surface de gouvernance est la raison de passer d'AI Studio à Vertex.

Le grounding, et d'où vient la réponse

Une dernière question de gouvernance : quand Gemini répond, *sur quoi s'est-il appuyé pour répondre* ? Pour les données de l'entreprise, la réponse devrait être vos données, pas le web ouvert, sauf intention contraire.

Dans l'app Gemini et via le panneau latéral, le contenu Workspace est la source de grounding par conception (contrainte, là encore, par les permissions de l'utilisateur). Quand vous appelez l'API, le grounding est un choix que vous faites explicitement. Vous pouvez activer le grounding avec Google Search pour que les réponses citent des résultats web en direct, ce qui est excellent pour des faits d'actualité et catastrophique s'il vous faut des réponses limitées à la politique interne.

Le réflexe de gouvernance : pour un assistant interne, faites le grounding sur *votre* corpus (via votre propre retrieval, ou le grounding de Vertex AI sur vos données), et laissez le grounding Search désactivé sauf si un cas d'usage a réellement besoin du web public. Mélanger les deux sans réfléchir, c'est ainsi qu'un assistant « interne » se met à citer un blog quelconque comme s'il s'agissait de la politique de l'entreprise. Décidez la source de vérité par cas d'usage, et rendez-la explicite dans la configuration plutôt que d'espérer que le modèle choisisse correctement.

Vous pouvez consulter les options de grounding dans la documentation grounding de l'API Gemini.

Le modèle mental de la gouvernance

Rassemblez le tout en un modèle que vous pouvez garder en tête :

• Le type de compte fixe le contrat de traitement des données par défaut (personnel = conditions grand public ; géré = vos protections Workspace).
• Les permissions utilisateur fixent ce que tout Gemini interactif peut voir (il agit en tant qu'utilisateur, jamais au-dessus de lui).
• La politique admin par OU/groupe fixe qui obtient quelles fonctionnalités et extensions Gemini.
• Les contrôles Workspace existants (Vault, DLP, régions de données) s'étendent automatiquement à Gemini.
• L'automatisation (Apps Script, API, Vertex) vous fait sortir du « agit en tant qu'utilisateur » pour entrer dans l'identité explicite, les secrets et la revue des sorties.

Presque toutes les questions « est-ce que c'est sûr » se rattachent proprement à l'un de ces cinq points.

Points clés

• Corrigez les permissions Drive avant d'activer Gemini. L'outil révèle le sur-partage existant, il ne le crée pas. Auditez d'abord les fichiers « tous les membres de l'entreprise ».
• Rendez le compte géré plus facile que le compte personnel. Votre vrai risque de fuite, ce sont des collaborateurs qui collent des données confidentielles dans un onglet Gemini personnel régi par des conditions grand public.
• Gouvernez avec les OU et les groupes, et pilotez en petit. Activez Gemini pour une OU mixte, mesurez au regard de Vault et de vos paramètres de région de données, puis étendez.
• Traitez l'automatisation comme une classe de risque différente. Les jobs API et Apps Script tournent sous une identité que vous choisissez, avec des secrets à protéger et des sorties qu'un humain doit relire.
• Passez à Vertex AI pour la production. Les clés AI Studio servent au prototypage ; Vertex vous apporte IAM, journaux d'audit et conditions de données entreprise pour les charges de travail qui touchent aux données de l'entreprise.