Isolée, une information est rarement dangereuse ou utile. Son contexte décide : pourquoi a-t-elle été collectée, qui la comprend, qui peut y accéder, avec quelles autres informations elle est combinée, combien de temps elle reste disponible et quelle action elle déclenche.
Le même numéro de téléphone peut servir à livrer une commande, relancer un prospect, authentifier un compte ou enrichir un profil. Ces usages n’ont ni la même finalité, ni les mêmes attentes, ni nécessairement la même base juridique.
Ce cadre rend les différences visibles et exécutables. Il doit permettre de répondre rapidement à une question simple : « Montrez-moi d’où vient cette donnée, pourquoi nous la détenons, où elle circule et comment nous la corrigeons ou la supprimons. »
1. Chiffres clés : la donnée est devenue un risque d’exploitation quotidien
La CNIL a reçu 20 150 plaintes en 2025, un record et une hausse de 10 % par rapport à 2024. Environ 1 900 concernaient directement des violations de données. Ces chiffres couvrent des situations variées, du travail aux réseaux sociaux ; ils montrent que les attentes des personnes se traduisent en sollicitations concrètes.
La même année, 6 167 violations de données ont été notifiées à la CNIL. Un incident déclaré sur deux relevait d’un piratage. L’autorité souligne également des violations de plus en plus massives et une implication fréquente des prestataires. La cartographie doit donc dépasser les systèmes internes.
En 2025, la CNIL a mené 323 contrôles et rendu 259 décisions correctrices, dont 83 sanctions. Le montant cumulé des amendes atteignait 486 839 500 euros, fortement influencé par deux décisions importantes. Le nombre brut d’euros ne doit pas servir à prédire une sanction individuelle ; les 143 mises en demeure et 31 rappels aux obligations montrent une gamme de réponses plus large.
La cybersécurité représentait un tiers des contrôles et près de 30 % des sanctions. Pour 2026, la CNIL annonce consacrer 50 % de ses contrôles et actions répressives à la sécurité des données. La qualité et la conformité ne peuvent donc pas être gérées séparément de l’accès, des sauvegardes et des prestataires.
Du côté des usages, Eurostat estime que 39,85 % des entreprises de l’Union européenne d’au moins dix personnes réalisaient des analyses de données en 2025, en interne ou avec un prestataire. L’augmentation des traitements, de l’IA et du partage accroît mécaniquement le besoin de provenance et de règles réutilisables.
2. Le grand livre des traitements et des données
Le registre RGPD des activités de traitement reste une pièce centrale. Mais une gouvernance opérationnelle le relie à un grand livre plus large.
Chaque entrée décrit :
| Champ | Question à trancher |
|---|---|
| Finalité | quel résultat légitime poursuit-on ? |
| Personnes | qui est concerné, y compris indirectement ? |
| Données | quelles catégories sont nécessaires ? |
| Source | personne, partenaire, appareil, inférence ? |
| Base juridique | sur quel fondement repose le traitement ? |
| Propriétaire | qui décide du sens et du risque ? |
| Systèmes | où sont stockage, copies, caches et sauvegardes ? |
| Destinataires | quelles équipes et quels tiers reçoivent ? |
| Localisation | dans quels pays stockage et accès ont-ils lieu ? |
| Durée | quel événement déclenche archivage et suppression ? |
| Droits | comment une demande est-elle propagée ? |
| Qualité | quels seuils rendent la donnée utilisable ? |
| Sécurité | classification, accès, chiffrement, journalisation ? |
| Preuve | quels documents et contrôles le démontrent ? |
Cette fiche n’est pas remplie une fois pour toutes. Elle possèd'un propriétaire, une date de revue et des liens vers les systèmes. Une modification de finalité, de fournisseur ou de durée déclenche une mise à jour.
Le registre juridique et le catalogue technique se synchronisent. Le premier explique pourquoi. Le second montre où et comment. Aucun des deux ne suffit seul.
3. Le voyage d’un enregistrement client
Suivons l’adresse e-mail d’une personne, depuis un formulaire jusqu’à sa suppression.
3.1. Concevoir la collecte
L’équipe définit la finalité avant le champ. Si l’e-mail sert à envoyer un devis, la date de naissance semble probablement inutile. La minimisation évite de collecter « au cas où ».
L’information fournie à la personne décrit les finalités, le responsable, la base, les destinataires, la durée, les droits et les contacts. Elle doit correspondre au fonctionnement réel, y compris aux outils publicitaires et prestataires.
Le formulaire distingue ce qui est nécessaire au service de ce qui relève d’un choix. Le consentement, lorsqu’il est utilisé, doit être spécifique, éclairé, univoque et retirable. Il ne constitue pas la base universelle de tous les traitements.
3.2. Valider à l’entrée
Le système vérifie format, domaine, doublon et provenance. Il conserve l’horodatage et la version du formulaire. Toute valeur invalide est corrigée avec prudence ou signalée ; en inventer une automatiquement peut dégrader la qualité et les droits.
La qualité commence ici. Une faute dans l’e-mail empêche l’exercice d’un service et peut envoyer une information à un tiers. Une validation technique protège donc aussi la personne.
3.3. Enregistrer la finalité et la preuve
L’adresse n’est pas copiée seule. Elle reste liée au contexte : demande de devis, compte client, abonnement ou relation contractuelle. Si plusieurs finalités existent, elles sont représentées séparément.
La preuve ne consiste pas nécessairement à stocker une capture complète. On conserve les éléments proportionnés : version du texte, source, date, choix et identifiant. Les journaux possèdent eux-mêmes une durée de conservation.
3.4. Autoriser les accès
Le CRM applique des rôles. Le commercial voit les prospects de son périmètre. Le support accède aux clients qu’il traite. Les exports massifs sont limités et journalisés.
L’habilitation est revue lors d’une arrivée, d’un changement de poste et d’un départ. Un compte inactif n’est pas une archive ; c’est une porte potentielle.
Les environnements de test utilisent des données synthétiques ou correctement pseudonymisées lorsque possible. Copier la base de production sur un ordinateur développeur crée une nouvelle finalité et un nouveau risque.
3.5. Partager avec un prestataire
Avant transmission, l’entreprise qualifie le rôle : sous-traitant, responsable conjoint ou destinataire indépendant selon le cas. Le contrat précise instructions, confidentialité, sécurité, sous-traitants ultérieurs, assistance aux droits, violations, sort des données et audit.
La localisation réelle inclut support, sauvegardes et télémétrie. Une région d’hébergement dans l’UE ne prouve pas qu’aucun accès extérieur n’existe.
La liste des prestataires est reliée au grand livre. Lorsqu’un contrat s’arrête, la suppression est demandée et attestée ; les copies dans les outils intégrés ne sont pas oubliées.
3.6. Transformer et déduire
L’entreprise peut calculer une propension d’achat ou segmenter le client. Cette nouvelle donnée est une inférence avec sa propre définition, sa date, sa méthode et sa durée. Elle n’est pas « vraie » au même titre qu’une commande observée.
Le profilage est analysé selon son impact. Une utilisation publicitaire, un risque de fraude ou une décision produisant des effets importants n’impliquent pas les mêmes contrôles. Les personnes doivent pouvoir exercer leurs droits selon le cadre applicable.
Les modèles utilisent des versions et jeux d’évaluation. Une correction de la donnée source doit pouvoir se propager ou déclencher un recalcul.
3.7. Corriger
Une personne signale une adresse erronée. Le système principal est corrigé, puis l’information est propagée aux systèmes consommateurs. L’ancienne valeur peut rester dans un journal ou une sauvegarde pour une durée justifiée, avec des restrictions.
Le graphe de provenance identifie les copies. Sans lui, l’équipe répond « corrigé » alors que la campagne, le data warehouse et l’outil support conservent l’erreur.
3.8. Conserver selon un événement
Une durée fixe n’est pas toujours suffisante. On peut conserver pendant la relation contractuelle, puis pendant une période liée aux obligations ou litiges. Le déclencheur est défini : dernière interaction qualifiée, fin de contrat, clôture de dossier.
Les données dormantes sont archivées avec moins d’accès. La conservation ne doit pas être prolongée simplement parce que le stockage coûte peu.
Les sauvegardes suivent un cycle distinct. Elles ne servent pas à l’exploitation courante, sont protégées et expirent. Une demande de suppression peut être appliquée lors d’une restauration afin d’éviter la réapparition.
3.9. Supprimer ou anonymiser
La suppression couvre base principale, outils satellites, index de recherche, embeddings, exports et files. Le système produit une preuve d’exécution et remonte les échecs.
L’anonymisation doit empêcher raisonnablement la réidentification. Retirer le nom n’est généralement qu’une pseudonymisation si l’historique, la localisation ou un identifiant permettent de retrouver la personne.
Une donnée réellement anonyme peut sortir du champ du RGPD. Cette qualification exige une analyse du contexte et des moyens raisonnablement susceptibles d’être utilisés.
4. Qualité : définir « suffisamment bon » par décision
La gouvernance ne cherche pas la perfection. Elle définit des seuils proportionnés.
Une donnée peut être complète mais fausse, exacte mais trop ancienne, cohérente mais non autorisée. Les dimensions principales sont exactitude, complétude, unicité, cohérence, validité, fraîcheur et traçabilité.
Pour chaque produit de données, on écrit : règle, seuil, mesure, fréquence, propriétaire et réaction. Exemple : 100 % des virements ont un bénéficiaire vérifié ; moins de 0,5 % des fiches client actives ont une devise absente ; la table de stock arrive en moins de vingt minutes.
Les contrôles se placent à plusieurs niveaux.
Préventifs. Champ obligatoire, référentiel, format, choix limité, validation métier.
Détectifs. Réconciliation, doublon, dérive, distribution, fraîcheur, échantillonnage.
Correctifs. Quarantaine, retour au producteur, reprise, recalcul, notification aux consommateurs.
La correction doit remonter à la cause. Un analyste qui répare chaque mois le même fichier masque un défaut de processus.
5. Traçabilité : quatre lignées à ne pas confondre
Le volet technique montre les tables, champs et transformations. La question devient « d’où vient ce chiffre ? ».
La lignée métier montre définitions, propriétaire et décision. Elle répond « que signifie-t-il ? ».
La lignée juridique relie finalité, base, catégories, destinataires et durée. Elle répond « pourquoi pouvons-nous le traiter ? ».
La lignée opérationnelle conserve versions, accès, incidents et actions. Elle répond « qui a fait quoi et quand ? ».
Une gouvernance mature relie ces quatre vues par des identifiants communs. Le DPO n’a pas besoin de lire tout le SQL ; l’ingénieur n’a pas besoin d’interpréter seul la base juridique. Chacun peut naviguer jusqu’à la preuve pertinente.
Le journal d’accès est protégé contre l’altération et limité. Il n’enregistre pas inutilement le contenu sensible. Les accès administrateurs et exports reçoivent une attention spécifique.
6. RGPD : traduire les principes en contrôles
Licéité, loyauté, transparence. La finalité et la base sont documentées, l’information est accessible et le fonctionnement ne surprend pas la personne.
Limitation des finalités. Un nouvel usage passe par une analyse de compatibilité ou une nouvelle base. Le data lake n’accorde pas un droit général de réutilisation.
Minimisation. Le schéma, les formulaires et les exports excluent les champs inutiles. Les jeux de développement sont réduits.
Exactitude. Les sources de vérité, corrections et indicateurs de qualité sont définis.
Limitation de conservation. Chaque catégorie possèd'un déclencheur et une procédure automatique, avec traitement des exceptions.
Intégrité et confidentialité. Classification, moindre privilège, chiffrement, sauvegarde, test, surveillance et gestion d’incident s’appliquent.
Responsabilité. L’organisation conserve les décisions, analyses, contrats, tests et preuves d’exécution.
Une analyse d’impact relative à la protection des données est réalisée lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés. Elle commence assez tôt pour influencer l’architecture.
7. Data Act : ce qui change dans la stratégie de données
Le règlement européen sur les données, ou Data Act, s’applique depuis le 12 septembre 2025. Il complète le Data Governance Act applicable depuis septembre 2023.
Le texte concerne notamment l’accès aux données générées par des produits connectés, certaines obligations de partage, les clauses contractuelles déloyales et le changement entre services de traitement de données. Pour une entreprise industrielle, les données de machines ne doivent plus être considérées automatiquement comme inaccessibles parce qu’elles résident chez le fabricant.
La Commission explique que les utilisateurs de produits connectés peuvent accéder, utiliser et partager les données brutes qu’ils co-génèrent, dans les conditions du règlement. Les contrats et l’architecture d’IoT doivent donc identifier ce qui est exportable, dans quel format et à quelle fréquence.
Pour le cloud et l’edge, le Data Act impose des mesures facilitant le changement. La Commission mentionne des interfaces ouvertes et, au minimum, des exports dans un format couramment utilisé et lisible par machine pour certains services. Elle précise que les frais de changement, y compris certains frais de sortie, doivent disparaître à partir du 12 janvier 2027, après une période transitoire.
La gouvernance doit intégrer ces droits et obligations sans les confondre avec le RGPD. Une donnée industrielle peut contenir des données personnelles. Le droit d’accès contractuel à la donnée ne supprime pas les exigences de protection des personnes.
8. Sécurité : gouverner les grandes bases et les prestataires
La CNIL souligne que les violations impliquent souvent des prestataires. L’entreprise cartographie donc la chaîne : collecte, API, ETL, entrepôt, sauvegarde, BI, IA, support et export.
Chaque maillon applique le moindre privilège. Les comptes de service ont une finalité, des droits limités et des secrets rotatifs. Les accès temporaires expirent. Les exports massifs déclenchent une alerte.
Les grandes bases sont segmentées. Une compromission d’un outil marketing ne doit pas ouvrir le référentiel complet. Les données sensibles sont séparées et chiffrées, avec gestion des clés distincte.
La réponse aux violations prévoit détection, qualification, confinement, conservation des preuves, évaluation du risque, notifications et communication. Le délai réglementaire applicable ne doit pas être découvert le jour de l’incident.
Un exercice annuel simule la fuite d’un sous-traitant. L’équipe vérifie la liste des personnes affectées, les données concernées, les contacts et la capacité à révoquer les accès. Le contrat devient alors testable.
9. Modèle d’organisation : fédérer sans diluer
Le Chief Data Officer ou responsable data fixe le cadre, les standards et la plateforme. Le DPO conseille et contrôle l’application du RGPD selon son rôle. Le RSSI porte la politique de sécurité. Les propriétaires de domaine décident des définitions et usages. Les data stewards maintiennent qualité et métadonnées. Les équipes techniques implémentent.
Un conseil de gouvernance arbitre les sujets transversaux : définition du client, partage sensible, nouvelle finalité, exception de conservation, fournisseur critique. Il ne valide pas chaque colonne.
Le modèle fédéré donne aux domaines des responsabilités sous des standards communs. La finance possède la marge. Le commerce possèdu lead qualifié. La plateforme fournit catalogue, lignée, contrôle d’accès et qualité.
Les décisions sont datées. Une exception a un propriétaire, une justification, des mesures compensatoires et une échéance. Sans date de fin, elle devient la norme silencieuse.
10. Tableau de bord de gouvernance
Le tableau de bord suit des résultats, pas seulement des documents produits.
- pourcentage de traitements et produits avec propriétaire ;
- systèmes reliés au registre et au catalogue ;
- données sans classification ou durée ;
- règles de qualité respectées par criticité ;
- incidents et délai de détection/correction ;
- demandes de droits traitées et erreurs de propagation ;
- comptes inactifs, accès privilégiés et exports massifs ;
- prestataires sans revue récente ;
- suppressions exécutées, en échec ou en attente ;
- tests de restauration et de réversibilité réussis.
Une couverture de 100 % peut être trompeuse si les fiches sont obsolètes. On mesure la fraîcheur et l’existence d’une preuve.
11. Cas pratique : réconcilier CRM, marketing et facturation
Une entreprise possède 180 000 contacts dans son CRM, 240 000 dans sa plateforme e-mail et 95 000 comptes dans la facturation. Personne ne sait combien de clients actifs ont consenti aux communications.
Le projet commence par les identifiants et finalités, pas par une fusion totale. Le compte contractuel devient la référence pour le statut client. Le CRM conserve la relation commerciale. La plateforme e-mail reçoit uniquement l’identifiant pseudonyme, l’adresse nécessaire, le segment autorisé et le statut de communication.
La réconciliation révèle 31 000 doublons probables, 18 000 adresses sans provenance exploitable et 7 000 anciens clients toujours dans des campagnes. Les chiffres sont propres à ce cas fictif, mais le traitement illustre la méthode.
L’équipe ne supprime pas automatiquement tous les enregistrements. Elle classe : données contractuelles à conserver, marketing à suspendre, doublons à fusionner avec journal, dossiers à examiner. Une pipeline quotidienne propage retraits et corrections. Une alerte détecte tout contact envoyé sans statut compatible.
Le bénéfice ne se limite pas au risque. Les taux de délivrabilité et les cohortes deviennent plus fiables. La conformité améliore ici le pilotage.
12. Feuille de route en cent vingt jours
Jours 1 à 30 : visibilité. Recenser dix traitements et produits critiques, leurs propriétaires, systèmes, prestataires et durées. Cartographier un parcours de donnée complet.
Jours 31 à 60 : contrôles. Définir classification, accès, règles de qualité, demandes de droits, conservation et incidents. Corriger les écarts les plus exposés.
Jours 61 à 90 : automatisation. Relier registre et catalogue, instrumenter la lignée, propager les corrections, automatiser les suppressions et suivre les échecs.
Jours 91 à 120 : preuve. Tester une restauration, une demande de droit, une violation chez un prestataire et un export de sortie. Présenter le tableau de bord au conseil.
La priorité se fonde sur les personnes affectées, la sensibilité, le volume, l’autonomie et la dépendance. Gouverner « toutes les données » en même temps conduit souvent à documenter sans corriger.
13. Questions fréquentes
13.1. Gouvernance data et RGPD sont-ils la même chose ?
Non. Le RGPD encadre les données personnelles. La gouvernance couvre aussi données financières, industrielles, produits et référentiels, avec qualité, définitions, accès et valeur. Les deux doivent être reliés.
13.2. Faut-il un outil de catalogue ?
Il aide lorsque les sources et équipes se multiplient. Commencez par les objets critiques et les responsabilités. Un catalogue vide de définitions ou non relié aux pipelines devient un annuaire obsolète.
13.3. Qui est responsable de la qualité ?
Le propriétaire métier définit le niveau nécessaire. Le producteur corrige la cause. L’équipe data mesure et alerte. Les consommateurs signalent les écarts. La responsabilité est distribuée, mais elle ne doit pas être anonyme.
13.4. Pseudonymiser suffit-il pour sortir du RGPD ?
Non. Si une réidentification reste possible à l’aide d’informations séparées, les données demeurent personnelles. La pseudonymisation est une mesure de sécurité utile, pas une anonymisation automatique.
13.5. Comment savoir quoi supprimer ?
Relier chaque catégorie à une finalité, une obligation et un déclencheur. Définir les exceptions, sauvegardes et preuves. Une durée unique pour toute la base est rarement adaptée.
14. Ce qu’une personne peut vérifier quand finalité, base et durée deviennent exécutables
Un registre documentaire devient gouvernance lorsqu’il correspond aux systèmes. Pour un traitement échantillonné, l’équipe doit relier finalité, base juridique, catégories, collecte, transformations, destinataires, accès, conservation, suppression et exercice des droits.
La vérification prend un cas concret. Elle suit une personne depuis le formulaire jusqu’au CRM, au warehouse, aux exports et aux sauvegardes, puis déclenche une correction et observe sa propagation. Les copies légitimes, délais techniques et exceptions sont expliqués ; les dépôts oubliés rejoignent un plan de suppression.
Une clôture solide exige que le propriétaire métier confirme le besoin, que le DPO ou conseil compétent valide le raisonnement applicable, que l’ingénierie fournisse les preuves d’accès et d’effacement, que le data steward réconcilie les définitions et que les écarts résiduels possèdent un risque, un responsable et une échéance ; sans cette traversée complète, la même donnée peut sembler conforme dans le registre, fausse dans le reporting et encore disponible dans un export que personne n’avait recensé.
La durée est ensuite traduite en règle surveillée. Un tableau mensuel affiche volumes arrivés à échéance, suppressions réussies, erreurs, exceptions et âge maximal. La conformité devient ainsi observable sans prétendre qu’un indicateur remplace l’analyse juridique.
15. Ce que Logiks recommande
Suivez d’abord un enregistrement réel de bout en bout. Reliez le registre juridique au catalogue technique, puis donnez à chaque produit un propriétaire, une durée, des règles de qualité et une preuve d’accès. Automatisez la correction et la suppression comme des processus de production. Une gouvernance efficace rend la bonne pratique plus facile que le contournement.
16. Sources principales
- CNIL, Rapport annuel 2025, publié le 18 mai 2026 : https://cnil.fr/fr/rapport-annuel-2025
- CNIL, Sanctions et mesures correctrices : bilan 2025 : https://cnil.fr/fr/bilan-sanctions-2025
- CNIL, Guide de la sécurité des données personnelles : https://www.cnil.fr/fr/securite-des-donnees
- EUR-Lex, règlement (UE) 2016/679, RGPD : https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Commission européenne, Data Act explained : https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained
- Commission européenne, application du Data Act depuis le 12 septembre 2025 : https://digital-strategy.ec.europa.eu/en/news/eu-data-act-gives-users-control-over-data-connected-devices
- Eurostat, analyse de données dans les entreprises en 2025 : https://ec.europa.eu/eurostat/statistics-explained/SEPDF/cache/33473.pdf
