Chapitre 6.2 — Information, accès, rectification

⏱️ TL;DR — Trois droits « de base » qui vont ensemble. L’information (art. 13 quand tu collectes directement auprès de la personne, art. 14 quand tu obtiens les données autrement) : la personne doit savoir, dès le départ, qui traite quoi et pourquoi — on y consacre toute la Partie 8. L’accès (art. 15) : sur demande, la personne obtient la confirmation qu’on traite ses données, une copie, et un paquet d’informations sur le traitement. La rectification (art. 16) : elle peut faire corriger une donnée fausse ou compléter une donnée incomplète. Pour un dev, l’accès se code comme un endpoint d’export qui renvoie bien plus que des lignes de base : aussi le contexte du traitement.

🎯 Objectifs

• Distinguer l’information art. 13 (collecte directe) de l’art. 14 (collecte indirecte).
• Savoir exactement ce que doit contenir une réponse à une demande d’accès (art. 15).
• Concevoir un endpoint d’accès/export qui renvoie les données et leur contexte.
• Traiter une rectification (art. 16) et la répercuter proprement.

Information (art. 13-14) : le droit qui précède tous les autres

Avant même qu’une personne demande quoi que ce soit, elle a droit à l’information : on ne peut pas exercer des droits qu’on ignore. Deux articles, selon d’où viennent les données :

• Article 13 — collecte directe : tu recueilles les données auprès de la personne (un formulaire d’inscription, un compte créé). L’information est due au moment de la collecte.
• Article 14 — collecte indirecte : tu obtiens les données autrement que de la personne (un fichier transmis par une école, un partenaire, une source publique). L’information reste due, dans un délai raisonnable, et doit préciser en plus la source des données.

Le contenu de cette information (identité du responsable, finalités, bases légales, destinataires, durées, droits, transferts…) et la manière de le rédiger font l’objet de la Partie 8 — Transparence & information. Retiens ici l’essentiel : information = en amont et spontanée ; accès = à la demande. Les deux se répondent.

📚 Le texte — L’information figure aux articles 13 (données collectées directement auprès de la personne) et 14 (données non collectées auprès d’elle). Le détail du contenu et les mentions type sont traités en Partie 8.

Accès (art. 15) : bien plus qu’un « dump » de la base

C’est le droit le plus demandé, et le plus mal implémenté. Beaucoup d’équipes renvoient un export brut des lignes de leurs tables. Insuffisant. L’article 15 donne droit à trois choses :

1. La confirmation que des données de la personne sont (ou ne sont pas) traitées.
2. Une copie des données personnelles qui font l’objet du traitement.
3. Un ensemble d’informations sur le traitement, notamment : les finalités, les catégories de données concernées, les destinataires (ou catégories de destinataires), la durée de conservation (ou les critères qui la déterminent), l’existence des autres droits (rectification, effacement, limitation, opposition), le droit de réclamation auprès de la CNIL, la source des données quand elles n’ont pas été collectées auprès de la personne (lien avec l’art. 14), et l’existence éventuelle d’une décision automatisée (art. 22).

Autrement dit : une réponse d’accès, c’est les données + leur mode d’emploi. Un export qui ne renvoie que des valeurs sans dire à quoi elles servent ni à qui elles sont transmises ne satisfait pas l’article 15.

⚠️ Piège — Confondre accès (art. 15) et portabilité (art. 20). L’accès donne une copie lisible par un humain de toutes tes données, quel que soit le traitement, avec le contexte. La portabilité (chapitre 6.4) est plus étroite : un fichier machine des seules données que la personne a fournies, et seulement pour les traitements fondés sur le consentement ou le contrat. Ne réponds pas à une demande d’accès par un simple fichier de portabilité : il manquerait le contexte et une partie des données.

L’endpoint d’accès, côté code

Voici la forme d’une réponse d’accès conforme : les données et le contexte du traitement, dans une structure explicite.

// Réponse à une demande d'ACCÈS (art. 15) : données + informations sur le traitement.
type ReponseAcces = {
  personneConcernee: { id: string; identiteVerifiee: true }
  genereLe: string // horodatage ISO 8601 de la génération
 
  // 1) Les DONNÉES elles-mêmes (copie), regroupées par domaine.
  donnees: {
    compte: { email: string; nom: string; creeLe: string }
    profil: { etablissement?: string; organisme?: string; role: string }
    activite: Array<{ moduleId: string; scoreQuiz: number; termineLe: string }>
    // ... toute autre donnée personnelle réellement traitée
  }
 
  // 2) Le CONTEXTE du traitement, exigé par l'art. 15 (le « mode d'emploi »).
  traitements: Array<{
    finalite: string                 // ex. "Suivi pédagogique du stagiaire"
    baseLegale: string               // ex. "Exécution du contrat de formation"
    categoriesDestinataires: string[] // ex. ["hébergeur UE", "prestataire e-mailing"]
    dureeConservation: string        // ex. "3 ans après la dernière formation"
    source?: string                  // requis si collecte indirecte (art. 14)
    decisionAutomatisee: boolean     // existence d'un traitement au sens de l'art. 22
  }>
 
  // 3) Le rappel des DROITS et de la voie de réclamation.
  vosDroits: {
    rectification: true
    effacement: true
    limitation: true
    opposition: true
    reclamationCnil: "https://www.cnil.fr"
  }
}

Un endpoint qui renvoie cette structure — pas un simple SELECT * — répond vraiment à l’article 15. Génère-le à la demande, ne le stocke pas, et trace l’envoi dans ton registre des demandes.

💡 Réflexe — Construis ta réponse d’accès à partir de ton registre des traitements (art. 30, Partie 11), pas à la main. Si chaque table de ta base est déjà reliée à une finalité, une base légale, des destinataires et une durée, l’endpoint d’accès n’a plus qu’à assembler ces métadonnées avec les valeurs. L’accès conforme est un sous-produit d’un registre bien tenu.

Rectification (art. 16) : corriger et compléter

Le plus simple des trois — et pourtant souvent oublié dans le code. La personne peut demander de :

• corriger une donnée inexacte (un nom mal orthographié, une date de naissance erronée, un établissement de rattachement obsolète) ;
• compléter une donnée incomplète au regard de la finalité (par une déclaration complémentaire).

La rectification touche à la qualité des données — c’est le pendant, côté personne, du principe d’exactitude de l’article 5 (chapitre 1.4). Une donnée fausse peut avoir des conséquences réelles : un bulletin attribué au mauvais élève, une attestation de formation à un nom erroné.

Deux réflexes de dev :

• Répercuter la correction partout où la donnée est copiée (caches, index de recherche, exports déjà générés, systèmes tiers). Corriger dans la table users mais laisser une copie erronée dans l’index de recherche, c’est ne pas avoir rectifié.
• Notifier les tiers : si les données ont été communiquées à des destinataires, ceux-ci doivent être informés de la rectification, sauf effort disproportionné (c’est le droit de notification de l’article 19).

🧭 Sur FormaCampus — Un formateur signale que le nom d’un stagiaire est mal orthographié sur son attestation Qualiopi. La rectification (art. 16) impose de corriger la fiche et de régénérer les documents qui en dépendent, puis de propager la correction à l’index de recherche et aux exports. Côté accès (art. 15), quand un stagiaire demande « tout ce que vous avez sur moi », FormaCampus renvoie non seulement ses scores et son profil, mais aussi pour quoi ces données sont traitées, combien de temps elles sont conservées, et à quels sous-traitants (hébergeur, e-mailing) elles sont transmises — le contexte, pas juste les valeurs.

🔒 Côté personne concernée — Demander l’accès, c’est souvent le premier réflexe de quelqu’un qui s’inquiète : « qu’est-ce qu’ils savent de moi, au juste ? ». Une réponse lisible, qui explique en clair les finalités et les destinataires, désamorce l’inquiétude et renforce la confiance. À l’inverse, un export illisible de colonnes techniques donne l’impression qu’on cache quelque chose — et pousse souvent la personne vers une réclamation CNIL.

✏️ Exercices

Exercice 1 — L’export suffit-il ? Pour répondre à une demande d’accès, un dev renvoie un dump JSON de la ligne users et de la table quiz_results. Est-ce conforme à l’article 15 ?

Exercice 2 — Art. 13 ou 14 ? (a) Un stagiaire remplit lui-même le formulaire d’inscription à une formation. (b) Une école transmet à FormaCampus un fichier CSV de ses élèves. Quel article d’information s’applique, et qu’a-t-il de spécial dans le second cas ?

Exercice 3 — Rectifier vraiment. Un stagiaire fait corriger sa date de naissance. Le dev met à jour la table users et referme le ticket. Que manque-t-il ?

🧠 Quiz de révision

Chapitre suivant : Effacement & limitation — le fameux « droit à l’oubli », ce qu’il permet, ce qu’il ne permet pas, et comment « geler » un traitement sans tout supprimer.