Un client demande ce que le centre sait de lui

Aux Arcades, le centre commercial qui sert de fil rouge à cette série, le programme de fidélité tourne depuis six ans. Des dizaines de milliers de porteurs de carte, un prestataire qui gère les points, une newsletter mensuelle, et chaque passage en caisse rattaché à un numéro d'adhérent.

Un matin, un client se présente à l'accueil. Il ne vient ni pour un échange ni pour un litige. Il veut savoir ce que le centre sait de lui : depuis quand, à qui ces informations sont transmises, ce qu'il en reste après six ans. Trois semaines plus tard, il écrit de nouveau. Cette fois, il demande à disparaître du fichier.

Deux demandes de quelques lignes. Pour y répondre, il faut ouvrir le fichier de fidélité, le progiciel de caisse, l'outil d'emailing, l'entrepôt d'analyse, les journaux d'accès, et appeler le prestataire.

Les articles 12 à 22 du RGPD énumèrent les droits des personnes. Lus par un juriste, c'est une liste. Lus par un ingénieur, c'est un cahier des charges : savoir où sont les données, savoir les extraire, savoir les supprimer partout.

Un droit s'écrit en une phrase dans le règlement. Il se paie en cartographie, en exports et en suppressions en cascade.

Ce billet explique ce que le texte prévoit et rapporte une décision publiée. Il ne dit à personne quoi faire dans sa situation. Pour la place du RGPD parmi les autres cadres, le billet sur ISO 27001, SOC 2, RGPD et NIS2 le situe en une section. Pour savoir qui, du centre ou de son prestataire, répond de ces demandes, c'est le billet sur le responsable de traitement, le sous-traitant et le DPO.

Huit droits et une horloge

L'article 12 ne crée aucun droit. Il pose les règles du jeu communes à tous les autres, et c'est probablement l'article le plus structurant du chapitre pour une équipe technique.

Il exige une information concise, transparente et formulée en termes clairs et simples. Il pose la gratuité de principe, avec une réserve pour les demandes manifestement infondées ou excessives, notamment répétitives. Il impose de répondre même quand on ne donne pas suite : l'article 12(4) prévoit d'indiquer les motifs de l'inaction, la possibilité de saisir une autorité de contrôle et celle d'un recours juridictionnel.

Et il déclenche l'horloge. L'article 12(3) fixe un délai d'un mois à compter de la réception de la demande. Ce délai peut être prolongé de deux mois compte tenu de la complexité et du nombre de demandes, à condition d'informer la personne de la prorogation et de ses motifs dans le mois initial.

Le compteur part de la réception de la demande, pas du jour où l'équipe technique s'en saisit. Une demande qui dort trois semaines dans une boîte de contact a déjà consommé les trois quarts du délai.

Voici la carte du chapitre. Chaque ligne ouvre une capacité différente, et aucune ne se déduit des autres.

Droit Article Ce qu'il ouvre
Information 13 et 14 Savoir qui traite quoi et pourquoi, sans avoir rien demandé
Accès 15 Obtenir confirmation, les informations sur le traitement, et une copie des données
Rectification 16 Corriger une donnée inexacte, compléter une donnée incomplète
Effacement 17 Faire supprimer, dans les cas que l'article énumère
Limitation 18 Geler l'usage des données sans les supprimer, le temps d'un arbitrage
Portabilité 20 Récupérer ses données dans un format lisible par machine, ou les faire transmettre
Opposition 21 S'opposer à un traitement, sans condition en matière de prospection
Décision automatisée 22 Ne pas subir une décision entièrement automatisée à effet significatif

Deux mécanismes gravitent autour de cette liste sans y figurer. L'article 7(3) permet de retirer son consentement à tout moment, aussi facilement qu'il a été donné, quand c'est la base légale retenue : le sujet est traité dans le billet sur les six bases légales et les sept principes. L'article 19, lui, n'est pas un droit mais une obligation : toute rectification, tout effacement et toute limitation doivent être communiqués à chaque destinataire des données, sauf impossibilité ou effort disproportionné.

Informer d'abord, donner accès ensuite

Aux Arcades, avant que quiconque ait demandé quoi que ce soit, un panneau à l'entrée annonce que l'établissement est sous vidéosurveillance et indique à qui s'adresser. Personne ne l'a réclamé. Il précède la collecte.

Le règlement fonctionne de la même façon. Les articles 13 et 14 imposent une information délivrée d'office. L'article 15, lui, répond à une sollicitation. Confondre les deux conduit à une erreur classique : croire qu'on est en règle parce qu'on sait répondre aux demandes, alors que l'information spontanée n'a jamais été faite.

La différence entre 13 et 14 tient à l'origine des données, et elle change tout pour un système qui agrège des sources.

Article 13 Article 14
Origine des données Collectées auprès de la personne Obtenues d'une autre source
Moment de l'information Au moment de la collecte Dans un délai raisonnable et au plus tard un mois après l'obtention, ou dès la première communication avec la personne, ou dès la première divulgation à un autre destinataire
Mention spécifique Caractère obligatoire ou non de la fourniture des données Catégories de données concernées et source dont elles proviennent
Limite prévue par le texte Ne s'applique pas si la personne dispose déjà des informations, article 13(4) Exceptions de l'article 14(5), dont le cas où l'information exigerait des efforts disproportionnés

L'article 15 se lit en trois étages. D'abord la confirmation que des données sont traitées, ou l'affirmation qu'il n'y en a pas. Ensuite une liste d'informations : finalités, catégories de données, destinataires, durée de conservation envisagée ou critères qui la déterminent, existence des autres droits, droit d'introduire une réclamation, source des données quand elles ne viennent pas de la personne, et existence d'une décision automatisée avec des informations utiles sur la logique sous-jacente. Enfin, l'article 15(3) ajoute la copie des données elles-mêmes.

C'est cette copie qui pose le vrai problème technique, parce qu'un dossier réel n'est jamais mono-personne. Un ticket de réclamation aux Arcades contient le nom du vigile qui a constaté les faits, l'appréciation écrite d'un salarié, parfois les coordonnées d'un autre client présent ce jour-là.

L'article 15(4) précise que le droit d'obtenir une copie ne doit pas porter atteinte aux droits et libertés d'autrui. Répondre en exportant le dossier brut est donc une manière de créer un second problème en réglant le premier.

La sur-communication est un manquement, pas un excès de zèle. Extraire un dossier tel quel, c'est divulguer les données des tiers qui y figurent.

Rectifier, effacer, limiter

Le client des Arcades a déménagé : sa nouvelle adresse relève de l'article 16, qui couvre aussi la complétion d'une donnée incomplète par une déclaration complémentaire. Celui qui veut sortir du fichier relève de l'article 17. Mais la comptabilité du centre, elle, conserve les pièces justificatives pendant des années parce qu'une autre loi l'exige.

Tout l'article 17 tient dans cette tension. L'article 17(1) énumère les motifs qui ouvrent l'effacement : les données ne sont plus nécessaires au regard des finalités, le consentement est retiré et aucune autre base ne subsiste, la personne s'oppose dans les conditions de l'article 21, le traitement est illicite, une obligation légale impose la suppression, ou les données ont été collectées dans le cadre d'une offre de services en ligne au sens de l'article 8(1), celui qui vise le consentement des enfants.

L'article 17(3) énumère ce qui y fait obstacle, et ces exceptions sont celles qu'on rencontre le plus souvent en entreprise : l'exercice du droit à la liberté d'expression et d'information, le respect d'une obligation légale ou l'exécution d'une mission d'intérêt public, des motifs de santé publique, l'archivage et la recherche dans les conditions de l'article 89(1), et la constatation, l'exercice ou la défense d'un droit en justice.

L'article 17(2) ajoute une charge que beaucoup découvrent tard : quand les données ont été rendues publiques, des mesures raisonnables doivent être prises pour informer les autres responsables qui les traitent.

flowchart TD dem["Demande d'effacement
reçue et horodatée"] motif{"Un motif de
l'article 17(1)
est-il rempli ?"} exc{"Une exception de
l'article 17(3)
couvre-t-elle les données ?"} refus["Réponse motivée
et voies de recours
article 12(4)"] part["Effacement partiel
et conservation restreinte
au périmètre couvert"] eff["Effacement en cascade
et information des destinataires
article 19"] dem --> motif motif -- "Non" --> refus motif -- "Oui" --> exc exc -- "Oui, sur une partie" --> part exc -- "Non" --> eff classDef question fill:#a0413e,stroke:#5f5e5a,color:#f5f2ec classDef action fill:#b5651d,stroke:#5f5e5a,color:#f5f2ec classDef neutre fill:#ede9e1,stroke:#b5651d,color:#1a1a1a class motif,exc question class eff,part action class dem,refus neutre

Entre les deux se glisse l'article 18, le plus ignoré du chapitre et pourtant le plus utile en pratique. La limitation gèle le traitement sans détruire : les données sont conservées, mais ne peuvent plus être utilisées, sauf consentement de la personne, défense d'un droit en justice, protection des droits d'un tiers ou motif important d'intérêt public. Elle sert précisément aux périodes d'arbitrage, par exemple pendant qu'on vérifie l'exactitude contestée d'une donnée.

Attention à ce que « effacer » veut dire côté données. Remplacer un nom par un identifiant technique ne fait pas sortir l'enregistrement du champ du règlement, comme le rappelle le billet sur la donnée personnelle, l'anonymisation et la pseudonymisation. Une agrégation réellement anonyme, elle, peut survivre à l'effacement, parce qu'elle n'est plus une donnée personnelle.

L'effacement n'est pas un bouton. C'est un arbitrage entre des motifs et des exceptions, suivi d'une propagation dans tous les systèmes qui détiennent une copie.

La portabilité et ses deux conditions

Un client des Arcades veut récupérer son historique d'achats pour l'importer dans son application de suivi de budget. Ce n'est ni de l'accès, ni de l'effacement : il ne veut pas lire, il veut emporter et réutiliser.

L'article 20 a un périmètre nettement plus borné que les autres droits du chapitre. Il suppose deux conditions cumulatives : le traitement doit reposer sur le consentement ou sur un contrat, et il doit être effectué à l'aide de procédés automatisés. Un traitement fondé sur l'intérêt légitime ou sur une obligation légale reste hors de son champ, même s'il porte exactement sur les mêmes données.

Le texte parle des données « fournies » par la personne. Ce mot trace la ligne : ce que le client a saisi et ce qu'il a généré par son usage du service entrent dans le périmètre, tandis qu'un score calculé par le responsable relève de sa propre production. La distinction est simple à énoncer et pénible à implémenter, parce que les deux vivent dans la même table.

Le format attendu est structuré, couramment utilisé et lisible par machine. L'article 20(2) ajoute la transmission directe d'un responsable à un autre lorsqu'elle est techniquement possible, sans imposer pour autant de rendre les systèmes compatibles entre eux.

{
  "format_version": "1.0",
  "genere_le": "2026-03-14T09:12:00Z",
  "personne": {
    "identifiant_adherent": "ARC-84213",
    "email": "client@example.org"
  },
  "donnees_fournies": {
    "compte": { "cree_le": "2021-06-02", "langue": "fr" },
    "achats": [
      { "date": "2024-11-03", "montant_eur": 42.9, "enseigne": "niveau-1-b12" }
    ]
  },
  "donnees_produites_par_le_responsable": {
    "segment_marketing": "actif",
    "score_appetence": 0.72
  }
}

Séparer les deux blocs dans l'export coûte une heure de conception et évite une discussion sans fin plus tard. L'article 20(4) rappelle par ailleurs que la portabilité ne doit pas porter atteinte aux droits d'autrui, ce qui vise par exemple un carnet de contacts rempli de tiers.

La portabilité ressemble à une demande d'accès avec un fichier joint, mais son périmètre est plus étroit et son format contraint. Reste à tracer la frontière entre ce que la personne a fourni et ce que le système a calculé.

S'opposer, et refuser la décision automatique

Un porteur de carte annonce à l'accueil qu'il ne veut plus recevoir les prospectus du centre. Personne ne lui demande pourquoi, et la question n'a pas lieu d'être posée.

Le règlement distingue en effet deux oppositions très différentes sous un même article. L'article 21(1) ouvre une opposition motivée par des raisons tenant à la situation particulière de la personne, contre les traitements fondés sur l'intérêt public ou l'intérêt légitime. Le responsable peut la refuser, mais seulement en démontrant des motifs légitimes et impérieux qui prévalent sur les intérêts, droits et libertés de la personne, ou la nécessité de défendre un droit en justice. C'est une mise en balance, et elle se documente.

L'article 21(2) fonctionne autrement. En matière de prospection, l'opposition s'exerce à tout moment, sans motif, et l'article 21(3) prévoit que les données ne sont plus traitées à cette fin. Aucune balance, aucune discussion. L'article 21(4) impose en outre de porter ce droit à la connaissance de la personne au plus tard lors de la première communication, de manière claire et séparée de toute autre information.

L'article 22 clôt le chapitre sur un terrain devenu très concret avec les modèles automatisés. Il pose le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé, y compris le profilage, produisant des effets juridiques ou affectant la personne de manière significative de façon analogue.

Trois cas y échappent : la nécessité pour la conclusion ou l'exécution d'un contrat, une autorisation par le droit de l'Union ou d'un État membre, et le consentement explicite. Dans le premier et le troisième, l'article 22(3) impose des mesures appropriées, au minimum le droit d'obtenir une intervention humaine, d'exprimer son point de vue et de contester la décision. L'article 22(4) encadre plus strictement encore les décisions reposant sur des catégories particulières de données.

Le mot qui décide de tout est « exclusivement ». Les lignes directrices WP251rev.01 sur la décision automatisée, adoptées par le G29 et reprises par le Comité européen de la protection des données, attendent une intervention humaine effective, exercée par une personne qui a l'autorité et la compétence pour modifier la décision. Une validation de façade ne fait donc pas sortir le traitement du champ de l'article 22.

Une opposition à la prospection ne se discute pas. Et sur une décision automatisée, une intervention humaine de façade reste une décision automatisée.

Ce que ça exige du système d'information

Revenons au directeur des Arcades. Sa première difficulté n'est pas juridique : il ne sait pas dire combien de fichiers contiennent le nom d'un adhérent. Tant que cette question reste sans réponse, aucun droit n'est réellement exerçable.

Le point de départ est donc le registre des traitements de l'article 30, décrit dans le billet sur la répartition des rôles. On ne répond pas à une demande d'accès en interrogeant une base : on y répond en parcourant une liste de traitements, chacun avec son système, son responsable opérationnel et sa clé de rapprochement.

Cette clé est le second point dur. Retrouver une personne dans quinze systèmes suppose un identifiant stable, ou à défaut une règle de rapprochement assumée. Sans elle, la recherche se transforme en correspondance approximative sur des noms, avec le risque de rater un enregistrement, et le risque symétrique d'en attribuer un qui appartient à quelqu'un d'autre.

Vient ensuite la vérification de l'identité du demandeur. L'article 12(6) permet de demander des informations supplémentaires en cas de doute raisonnable sur l'identité de la personne. Le texte parle bien d'un doute, ce qui n'érige pas la pièce d'identité en préalable systématique : exiger un justificatif pour toute demande revient à créer une collecte nouvelle pour honorer un droit.

Droit Ce qu'il faut savoir faire techniquement Le point dur
Accès, art. 15 Retrouver toutes les occurrences dans tous les traitements et produire une copie lisible Les copies latérales : entrepôt analytique, exports CSV, tickets de support
Rectification, art. 16 Corriger à la source et propager vers les systèmes aval Les données recopiées par un flux qui ne repasse jamais
Effacement, art. 17 Supprimer en cascade, y compris chez les sous-traitants Les sauvegardes et les archives conçues pour être immuables
Limitation, art. 18 Marquer un enregistrement comme gelé et bloquer son usage Peu de progiciels prévoient cet état, c'est un attribut à ajouter
Portabilité, art. 20 Exporter dans un format structuré et lisible par machine Séparer les données fournies de celles produites par le système
Opposition, art. 21 Consulter une liste d'opposition avant chaque campagne L'outil de routage tiers qui détient sa propre copie du fichier
Décision automatisée, art. 22 Tracer la décision, ses entrées, et prévoir un point de reprise humain Un modèle dont la sortie ne s'explique pas

Le cas des sauvegardes mérite d'être posé sans faux-semblant. Rouvrir une sauvegarde pour en extraire un enregistrement est techniquement absurde et souvent impossible sur un support conçu pour ne pas être réécrit. L'approche la plus courante consiste à borner la durée de rétention des sauvegardes et à documenter ce choix, puis à rejouer la suppression si une restauration remet les données en circulation. Les journaux techniques posent une question voisine, avec cette nuance qu'ils servent aussi à démontrer la sécurité du traitement.

Reste la chaîne des prestataires. Aux Arcades, le fichier de fidélité vit chez le prestataire qui gère les cartes, et il est exporté chaque nuit vers l'outil d'emailing. L'article 28(3)(e) prévoit que le contrat de sous-traitance organise l'assistance du sous-traitant pour donner suite aux demandes d'exercice des droits. En clair, la capacité à répondre se négocie au moment de la signature, pas le jour où la demande arrive.

sequenceDiagram autonumber participant P as Personne concernée participant G as Guichet des demandes participant D as DPO participant SI as Systèmes internes participant ST as Sous-traitants P->>G: Demande de copie de ses données G->>G: Horodatage et ouverture du dossier G->>D: Qualification du droit invoqué D-->>P: Question complémentaire en cas de doute raisonnable D->>SI: Recherche par identifiant dans chaque traitement du registre D->>ST: Sollicitation au titre du contrat de sous-traitance SI-->>D: Extraits par système ST-->>D: Extraits hébergés chez le prestataire D->>D: Consolidation et retrait des données de tiers D-->>P: Réponse et copie sous un mois Note over G,ST: Prorogation de deux mois possible, motivée et notifiée dans le premier mois
Une organisation qui découvre sa cartographie le jour où une demande arrive a déjà perdu la moitié du délai. Le mois de l'article 12(3) se joue avant la demande, pas après.

Clearview AI, ou le prix du silence

On associe volontiers les sanctions RGPD aux fuites de données. Il n'y en a eu aucune ici, et c'est ce qui rend l'affaire instructive pour ce billet.

Clearview AI est une société américaine qui a constitué une base de reconnaissance faciale en aspirant des photographies et des vidéos accessibles publiquement sur Internet, y compris sur les réseaux sociaux, à hauteur de plusieurs milliards d'images. Les personnes concernées n'ont jamais été en contact avec elle : c'est exactement la configuration de l'article 14, celle où les données ne viennent pas de la personne.

Après une mise en demeure restée sans suite satisfaisante, la CNIL a prononcé une amende de 20 millions d'euros (délibération de la formation restreinte n° SAN-2022-019 du 17 octobre 2022), assortie d'une injonction de cesser la collecte et de procéder à l'effacement, sous astreinte. L'astreinte a ensuite été liquidée le 17 avril 2023, pour 5,2 millions d'euros supplémentaires.

Trois manquements ont été retenus. Un traitement dépourvu de base légale au sens de l'article 6. Un défaut de coopération avec l'autorité de contrôle au sens de l'article 31. Et, au milieu, le non-respect des droits des personnes : l'exercice du droit d'accès était restreint de façon abusive, notamment par une limitation aux données des douze derniers mois et à deux demandes par an, tandis que les réponses aux demandes d'accès et d'effacement étaient tardives, incomplètes ou absentes.

Aucun système n'a été piraté dans cette affaire. Aucune donnée n'a fuité du fait d'un attaquant. Le manquement porte sur le fait de ne pas avoir répondu, ou d'avoir répondu à sa propre mesure.

Les droits des personnes ne sont pas un supplément décoratif à la sécurité. Leur non-respect se sanctionne pour lui-même, sans qu'aucune violation de données ne soit nécessaire.

Il y a une leçon d'ingénierie derrière la leçon juridique. Limiter l'accès aux douze derniers mois, plafonner le nombre de demandes, répondre partiellement : ce sont les contournements que produit un système incapable de retrouver et d'extraire proprement. La contrainte technique finit par se voir dans la réponse envoyée.

Points clés

  • L'article 12 commande tout le chapitre : information claire, gratuité de principe, réponse dans un délai d'un mois à compter de la réception, prorogation possible de deux mois motivée et notifiée, et obligation de motiver un refus.
  • L'information des articles 13 et 14 se délivre d'office, sans demande. L'accès de l'article 15 y ajoute une copie, avec la limite de l'article 15(4) sur les données de tiers.
  • L'effacement de l'article 17 est un arbitrage entre les motifs de l'alinéa 1 et les exceptions de l'alinéa 3, notamment l'obligation légale de conservation et la défense d'un droit en justice. L'article 18 offre le gel comme sortie intermédiaire.
  • La portabilité de l'article 20 ne couvre que le consentement et le contrat, en traitement automatisé, sur les données fournies par la personne. L'opposition en prospection, elle, est inconditionnelle.
  • Répondre suppose une cartographie issue du registre de l'article 30, une clé de rapprochement, un export propre, une suppression en cascade et l'assistance contractuelle des sous-traitants. Le cas Clearview AI montre que le silence se sanctionne sans fuite de données.

Dans la série

Palier 3 : Tenir la galerie. Domaine : Protection des données.

Pour aller plus loin