Classer, conserver, exporter : gouvernance des données dans Google Workspace

Un domaine Google Workspace ne casse pas par manque d'outils : il casse parce que les informations sensibles sont éparpillées dans Drive et Gmail, personne ne sait quel fichier est confidentiel et quel fichier est en libre-service, et quand arrive la demande légale de conserver ou de restituer les données, c'est seulement à ce moment-là qu'on commence à chercher. La gouvernance des données est la pile qui évite ce moment : elle classe le contenu, l'empêche de sortir par la mauvaise porte, retient ce qu'une affaire nécessite et permet de l'exporter quand il le faut. Le cours « Google Workspace Data Governance » de Google Skills parcourt les quatre couches avec des exercices sur un domaine de test, et ce post les suit dans l'ordre.

flowchart LR
    C[Classer<br/>étiquettes Drive et Gmail] --> P[Prévenir<br/>règles DLP]
    P --> R[Conserver<br/>Vault : rétention, matters, holds]
    R --> E[Exporter<br/>Takeout, Data Export, stockage local]

Classer : les étiquettes de Drive et Gmail

Les étiquettes de classification sont des étiquettes de métadonnées pour les fichiers Drive et les messages Gmail, et il en existe deux types. Les standard organisent : projet, année, région. Elles apparaissent dans les barres latérales. Les badged (avec badge) ressortent : elles affichent un badge coloré à côté du nom du fichier pour marquer les niveaux de confidentialité, comme un sceau visible avant d'ouvrir quoi que ce soit.

Le périmètre a des bords qu'il vaut mieux connaître avant de concevoir une politique. Les étiquettes ne s'appliquent qu'aux fichiers Drive propriété de l'organisation et aux messages Gmail rédigés par des utilisateurs de l'organisation. Elles ne s'appliquent pas aux dossiers, aux raccourcis, aux espaces partagés, aux fichiers d'une autre organisation, aux messages envoyés par des externes, ni aux messages déjà envoyés ou reçus. Un message déjà parti ne s'étiquette pas : s'il a besoin d'une étiquette et qu'il a été écrit depuis un client qui n'est pas Gmail, il ne peut en recevoir une qu'à travers une règle DLP.

Les limites sont concrètes : 150 étiquettes par organisation, jusqu'à 5 étiquettes appliquées par utilisateur par fichier Drive et jusqu'à 20 étiquettes par fichier au total, en comptant celles que les utilisateurs appliquent plus celles que les règles appliquent. Dans Gmail, le plafond est de 20 étiquettes au total et, quand des règles les appliquent, seules les 20 de plus haut rang entrent. Les étiquettes se créent en état brouillon, le type de champ ne peut pas changer après publication, et chaque édition impose une republication.

Il y a un détail qui échappe à presque toute politique d'étiquetage : dans Drive, les permissions du fichier commandent toujours. Qui n'a que la permission de lecture peut voir les étiquettes, même s'il a la permission de les appliquer. La classification n'est pas un canal séparé des permissions ; elle coexiste avec elles, et un fichier largement partagé emporte son étiquette partout.

Prévenir : les règles DLP avec détecteurs personnalisés

Les règles de prévention de perte de données (DLP) se créent dans Security > Access and data control > Data protection. L'exercice « Customer data » montre la partie la plus intéressante de cette couche : un détecteur personnalisé. Plutôt que de se fier uniquement aux types de données fournis par Google, on écrit sa propre expression régulière, testée avant de l'enregistrer, qui détecte les clients à haut profil de cette organisation — dans l'exemple Acme Corp, Beta Industries et Gamma Group.

Ce détecteur personnalisé ne travaille pas seul : la règle le combine avec des types de données prédéfinis de portée globale (nom de personne, numéro de carte de crédit, date de naissance et adresse e-mail), chacun avec un seuil de probabilité « très élevé » et une correspondance minimale. La règle couvre tout le domaine et les applications Drive et Chat.

Les actions se configurent par application, et c'est là que vit la différence entre avertir et contenir. Dans Chat, avertir l'utilisateur avec un message personnalisé qui route vers une personne précise. Dans Drive, bloquer le partage externe. Dans l'Alert Center, alerter avec une sévérité élevée et un destinataire désigné. La même règle, trois réponses différentes selon l'endroit où la correspondance a été détectée.

flowchart TD
    A[Créer des règles DLP avec contenu sensible] --> B[Scan continu des fichiers]
    B --> C{Violation de la règle ?}
    C -->|Oui| D[Actions : avertir, bloquer, alerter]
    C -->|Non| N[Rien à consigner]
    D --> F[Alert Center avec sévérité]

Il existe une variante qui ajoute du contexte à la décision : DLP avec Context-Aware Access. On crée d'abord un niveau d'accès dont la condition exige, par exemple, un appareil approuvé par l'administrateur, et ensuite une règle sur les fichiers Drive qui sélectionne ce niveau et applique l'action « désactiver le téléchargement, l'impression et la copie ». Autrement dit : la correspondance de contenu et l'état de l'appareil décident ensemble. Cette combinaison nécessite les éditions Frontline, Enterprise ou Education Standard et Plus, ou Enterprise Essentials Plus, et l'application des politiques de contexte exige Endpoint Verification actif sur les administrateurs et les utilisateurs.

Ce que DLP ne voit pas

Le cours est franc sur les limites de cette couche, et cette franchise vaut plus que la liste des fonctionnalités. Une politique DLP peut prendre jusqu'à 24 heures pour prendre effet. Les règles ne capturent pas toutes les données sensibles : faux positifs et négatifs coexistent. DLP convertit les fichiers Drive dans un format scannable et ne scanne que le premier Mo des fichiers convertis de plus de 1 Mo ; les fichiers de plus de 50 Mo ne se convertissent pas et certains de plus de 10 Mo peuvent échouer à convertir. Les titres et les étiquettes sont toujours scannés. Et chaque règle génère jusqu'à 50 alertes par jour, avec un décalage entre l'événement et son journalisation.

Le flux, de plus, est continu et en deux temps : d'abord les règles définissant le contenu sensible à protéger sont créées (s'appliquant à My Drive et aux Shared Drives), puis le système scanne les fichiers à la recherche de violations ; quand un fichier viole une règle, ses actions s'appliquent et une alerte part. DLP est pris en charge dans Drive, Gmail, Chat, Meet, Sheets, Docs, Slides et Forms.

Conserver : Google Vault, les matters et les holds

Google Vault est l'outil de gouvernance de l'information et d'eDiscovery : conserver, placer en hold, chercher et exporter des données. Ça commence par une règle qui surprend beaucoup de monde : les règles de rétention se créent avant de pouvoir préserver des données. Ce n'est que quand une règle de rétention existe qu'on peut préserver des informations, et une règle de rétention peut planifier la purge quand le délai expire. Les données sous conservation légale ne sont pas purgées.

L'exercice définit une règle personnalisée pour l'unité organisationnelle Executive de Gmail de 1825 jours (cinq ans) et une règle Gmail par défaut de 365 jours (un an), toutes deux purgeant uniquement les messages supprimés définitivement. La règle personnalisée prime sur la par défaut dans son OU. Et l'avertissement est sérieux : une règle mal configurée peut purger des données de façon immédiate et irréversible. La recommandation est de la tester avec un petit groupe, et de ne pas la combiner avec le réglage d'auto-suppression des mails et chats de Gmail.

Les holds (conservation légale) n'expirent jamais. Tant qu'un compte a des données en hold, l'administrateur ne peut pas le supprimer ni transférer ses données, et les données ne sont purgées que si un utilisateur de Vault retire le hold, si le custodian est retiré, ou si l'utilisateur perd sa licence Vault. Un matter est le contenant de tout ce qui se rapporte à une affaire : requêtes enregistrées, comptes en préservation, comptes avec accès, ensembles d'export et piste d'audit. L'exercice crée le matter « Project X » avec un hold Gmail pour deux comptes précis, avec possibilité d'affiner par dates ou termes de recherche.

Dans le matter, on cherche et on exporte. La recherche permet un comptage des résultats avant l'export, et les exports ne sont disponibles que 15 jours : il faut les télécharger à temps. L'audit se fait avec l'investigation tool sur les événements de Vault, et enregistre qui a édité des règles de rétention ou téléchargé des exports, avec possibilité d'exporter ces journaux vers un Sheet.

Exporter : trois voies et leurs sauvegardes

Quand les données doivent sortir de l'organisation, il y a trois voies, destinataires distincts.

Google Takeout est pour les utilisateurs individuels : l'utilisateur télécharge une copie de ses données de services intégrés, une fois ou planifiée tous les deux mois pendant un an. L'administrateur contrôle par unité organisationnelle quels services peuvent être exportés, et les mineurs de moins de 18 ans avec des comptes Education restent restreints même si le service est activé.

L'outil Data Export exporte les données de l'organisation vers une archive Google Cloud Storage à des fins légales, de conformité ou administratives, et ses sauvegardes temporaires sont la partie notable : il exige la 2-Step Verification pour l'administrateur, notifie par e-mail tous les superadministrateurs au démarrage, ne remet pas l'archive avant 48 heures (période de sécurité), prend généralement 72 heures et peut aller jusqu'à 14 jours. Si l'administrateur qui l'a lancé perd le rôle de superadministrateur pendant le processus, l'export est annulé automatiquement. Les états de l'export sont Failed, Errors, Complete et In progress.

Le stockage local exporte les données de Workspace vers un bucket Google Cloud Storage à vous, et l'emplacement du bucket détermine l'emplacement des données : c'est la souveraineté des données. Il n'inclut que les données des utilisateurs ayant la licence du complément Assured Controls (option payante pour Enterprise Plus), et les régions de données couvrent les données au repos, sauvegardes incluses, et le traitement aux États-Unis ou en Europe.

Ce que la pile résout et ce qu'elle ne garantit toujours pas

Les quatre couches se tiennent entre elles. Sans classification, la règle DLP ne sait pas quoi prioriser. Sans règles DLP, l'étiquette est un sceau qui avertit mais ne retient pas. Sans rétention, une affaire juridique ne trouve pas de données. Sans voies d'export, la rétention devient une archive que personne ne peut restituer. Et la classification par IA, prise en charge par Gemini Enterprise, Gemini Education Premium et AI Security, analyse le contenu du fichier pour le classer automatiquement, avec des étiquettes par défaut appliquées selon l'emplacement ou le type de fichier.

Ce que la pile ne garantit pas mérite d'être dit sans détour : la détection reste probabiliste. Le cours lui-même avertit que DLP ne capture pas toutes les données sensibles, avec faux positifs et négatifs, scan partiel des gros fichiers et plafond d'alertes par jour. Un fichier mal étiqueté, une règle mal testée ou une rétention mal configurée sont de vraies erreurs avec de vraies conséquences, et aucune des quatre couches ne les élimine par elles-mêmes. Ce qu'elles font, c'est placer le travail là où il faut : décider des politiques dans la console, au lieu de courir après chaque fichier partagé à la main.

*Source : « Google Workspace Data Governance », de Google Skills.*