Jeux de données gouvernés
Chaque jeu de données reçoit sa fiche — qui en est responsable, qui peut le lire, quelle fraîcheur il doit avoir, combien de temps on le garde — et le système applique la fiche, pas un PDF de politique.
Imaginez une bibliothèque où chaque livre a sa fiche : qui en prend soin, qui a le droit de l'emprunter, et quand il retourne sur l'étagère. Un jeu de données gouverné, c'est cette fiche pour vos données — et les portes la vérifient vraiment. Un agent IA qui n'est pas sur la fiche ne peut tout simplement pas ouvrir le tiroir.
Le problème, en mots simples
Vous êtes sur le point de brancher un agent IA sur la base de données clients, et quelqu'un pose la question raisonnable : « attends — est-ce qu'il peut voir les salaires ? Les vieux dossiers qu'on devait supprimer ? La table avec les notes de cartes de crédit ? » Personne n'en est certain. Les règles d'accès vivent dans un document de politique vieux de deux ans, les permissions réelles de la base ont été copiées de la personne embauchée avant vous, et les deux ont dérivé en silence. Alors le projet stagne — ou pire, il ne stagne pas, et l'agent lit quelque chose qu'il n'aurait jamais dû voir.
Ce que nous mettons en place
Nous attachons les règles aux données elles-mêmes. Chaque jeu de données déclare, en code : qui en est propriétaire, son niveau de sensibilité (interne, confidentiel ou réglementé), quels rôles peuvent le lire, quelle fraîcheur il doit garder, et combien de temps il est conservé avant suppression. Un catalogue de données (Unity Catalog, Polaris, Lake Formation ou DataHub — un fichier central pour vos données qui garde aussi les portes) applique ces règles au moment même où une personne ou un outil lance une requête. Le retrieval de l'IA passe par les mêmes portes : un agent hérite exactement des permissions de la personne pour qui il travaille, rien de plus.
Comment ça fonctionne, étape par étape
- Donner un propriétaire à chaque jeu
Une personne ou une équipe nommée, pas « l'équipe de données ». Quand quelque chose cloche avec cette table, c'est elle qui reçoit le message.
- Étiqueter sa sensibilité
Interne, confidentiel ou réglementé. L'étiquette décide de la prudence exigée de chaque lecteur en aval.
- Déclarer qui peut le lire
L'accès est accordé à des rôles (des fonctions), pas à des individus — un changement de poste ne devient pas une fouille archéologique de permissions.
- Fixer fraîcheur et rétention
À partir de quand une donnée est trop vieille, et quand les vieux dossiers doivent être supprimés. Les deux sont écrits et vérifiables.
- Laisser le catalogue appliquer les règles
Chaque requête — d'une personne, d'un tableau de bord ou d'un agent IA — passe par le catalogue, qui applique les règles à l'instant même. Pas de porte de côté.
- Tenir la liste des dépendants
Les consommateurs en aval sont enregistrés : modifier ou retirer un jeu de données commence par savoir qui sera touché.
Ce qui change pour vous
Avant : répondre à « qui peut voir ces données ? » demande un fil de clavardage, trois suppositions et un haussement d'épaules nerveux. Après : c'est une requête au catalogue, répondue en secondes, et la réponse est appliquée — pas seulement souhaitée. Accueillir un nouvel agent ou un nouvel analyste devient une attribution de rôle, au lieu de copier les permissions du dernier arrivé en croisant les doigts. Ce qu'il ne fera pas : décider des règles à votre place. Qui devrait voir quoi reste une décision humaine — le système s'assure seulement que la décision, une fois prise, est réellement suivie.