Chapitre 6.3 — Effacement & limitation

⏱️ TL;DR — L’effacement (art. 17), le « droit à l’oubli », permet à une personne de faire supprimer ses données dans plusieurs cas (données devenues inutiles, consentement retiré, opposition acceptée, traitement illicite…). Mais ce n’est pas un droit absolu : il cède devant une obligation légale de conservation, la liberté d’expression et d’information, l’exercice de droits en justice, ou l’archivage d’intérêt public. La limitation (art. 18), elle, est un entre-deux : on gèle le traitement — les données sont conservées mais on cesse de les utiliser — le temps de trancher une contestation. Côté code, tout se joue sur la distinction soft delete / hard delete et sur la cascade de suppression : effacer un compte doit effacer, ou anonymiser, tout ce qui pend.

🎯 Objectifs

• Lister les cas où l’effacement (art. 17) s’applique — et ses limites.
• Ne jamais promettre un droit à l’oubli absolu : savoir quand une obligation légale l’emporte.
• Comprendre la limitation (art. 18) comme un gel réversible du traitement.
• Implémenter soft delete, hard delete et la cascade proprement.

Effacement (art. 17) : le droit à l’oubli, et ses limites

L’article 17 donne le droit d’obtenir l’effacement de ses données, dans les meilleurs délais, dans un certain nombre de cas :

• les données ne sont plus nécessaires au regard des finalités (leur durée de vie utile est passée) ;
• la personne retire son consentement et il n’existe pas d’autre base légale pour continuer ;
• la personne s’oppose au traitement (art. 21) et il n’y a pas de motif légitime impérieux de le poursuivre ;
• les données ont été traitées de façon illicite ;
• l’effacement est requis pour respecter une obligation légale ;
• les données ont été collectées auprès d’un enfant dans le cadre d’un service en ligne.

Ce n’est pas un droit absolu

C’est le point que les équipes oublient, et qui fait dire « on ne peut pas juste tout supprimer » — à raison, parfois. L’article 17 prévoit lui-même que l’effacement ne s’applique pas quand le traitement reste nécessaire :

• pour respecter une obligation légale de conservation (par exemple les pièces comptables et de facturation, conservées un temps imposé par la loi) ;
• pour l’exercice du droit à la liberté d’expression et d’information ;
• pour la constatation, l’exercice ou la défense de droits en justice (un litige en cours) ;
• pour des motifs d’intérêt public (santé publique, archivage dans l’intérêt public, recherche).

Concrètement : un stagiaire peut demander l’effacement de son compte, mais tu conserves la facture de sa formation le temps imposé par le droit comptable et fiscal. Ce n’est pas un refus du droit — c’est une limite prévue par le texte. La bonne réponse est nuancée : « je supprime X et Y, je conserve Z au titre d’une obligation légale, pour telle durée, puis je le supprimerai aussi. »

⚠️ Piège — Promettre un « droit à l’oubli total et immédiat ». Faux sur les deux plans : il n’est ni total (les données sous obligation légale ou utiles à un litige restent) ni forcément immédiat (tu réponds dans le mois, et l’archivage légal a sa propre échéance). L’erreur inverse est tout aussi grave : refuser en bloc un effacement en brandissant une vague « conservation » sans base réelle. Pour chaque donnée : ai-je une obligation ou un motif précis de la garder ? Si non, elle part.

📚 Le texte — L’effacement est à l’article 17 : son alinéa 1 liste les cas d’application, son alinéa 3 les exceptions (obligation légale, liberté d’expression, intérêt public, droits en justice). La limitation est à l’article 18. Et l’article 19 impose de notifier aux destinataires l’effacement ou la limitation, sauf effort disproportionné.

Limitation (art. 18) : geler plutôt que supprimer

Parfois, la personne ne veut pas (ou ne peut pas) obtenir l’effacement, mais veut que tu arrêtes d’utiliser ses données pendant qu’on tranche une question. C’est la limitation : tu conserves les données, mais tu les gèles — plus de traitement actif, à part le simple stockage. Elle s’applique notamment quand :

• la personne conteste l’exactitude d’une donnée — on gèle le temps de vérifier ;
• le traitement est illicite mais la personne préfère la limitation à l’effacement ;
• tu n’as plus besoin des données mais la personne en a besoin pour un droit en justice ;
• la personne s’est opposée (art. 21) et on vérifie si tes motifs légitimes l’emportent.

Techniquement, la limitation est un drapeau : les enregistrements concernés sont marqués, et ton application doit refuser de les traiter (pas d’affichage actif, pas d’envoi, pas d’export) tant que le gel dure. C’est un soft delete particulier — les données existent, mais elles sont hors service.

Soft delete, hard delete et la cascade

Le cœur technique de l’effacement. Trois notions à ne pas confondre.

• Soft delete : on marque l’enregistrement comme supprimé (deletedAt, status = "deleted") mais il reste en base. Utile pour un délai de rétractation, une réversibilité courte, ou justement une limitation. Attention : un soft delete n’est pas un effacement RGPD tant que la donnée reste lisible et utilisable — c’est au mieux une étape.
• Hard delete : on supprime réellement la donnée (DELETE, purge). C’est ce qu’exige l’article 17 pour les données qui n’ont aucun motif de conservation.
• Cascade : effacer une personne, c’est effacer tout ce qui s’y rattache — pas seulement la ligne users. Sinon des données personnelles survivent dans les tables liées.

// Effacement (art. 17) en DEUX temps : soft delete immédiat, puis hard delete en cascade.
 
// 1) Soft delete : on gèle l'accès tout de suite (l'utilisateur ne voit plus rien).
await db.users.update({
  where: { id },
  data: { status: "deleted", deletedAt: new Date() },
})
 
// 2) Purge en CASCADE de tout ce qui rattache la personne — sinon des restes traînent.
async function purgerCompte(id: string) {
  await db.quizResults.deleteMany({ where: { userId: id } })   // activité
  await db.messages.deleteMany({ where: { authorId: id } })    // support, chat
  await db.consents.deleteMany({ where: { userId: id } })      // journaux de consentement
  await db.searchIndex.remove({ userId: id })                  // ⚠️ l'index aussi
  await db.backupsQueue.scheduleErase({ userId: id })          // ⚠️ et les sauvegardes
 
  // Ce qui est sous OBLIGATION LÉGALE n'est pas supprimé : il est ANONYMISÉ ou ISOLÉ.
  await db.invoices.update({
    where: { userId: id },
    data: { userId: null, buyerName: "SUPPRIMÉ" }, // on garde la pièce comptable, pas la personne
  })
 
  await db.users.delete({ where: { id } })                     // la ligne principale en dernier
}

Trois pièges concrets dans cette cascade : l’index de recherche (souvent oublié, il ré-expose les données), les sauvegardes (elles contiennent une copie — on documente une politique de purge par rotation) et les logs (une IP ou un e-mail dans les journaux est une donnée personnelle, chapitre 1.1). Effacer « le compte » sans traiter ces trois-là laisse la personne dans le système.

💡 Réflexe — Modélise l’effacement dès la conception du schéma. Pose sur chaque table la question : « quand je supprime cette personne, cette ligne doit-elle partir, être anonymisée (obligation légale), ou est-elle déjà agrégée donc hors sujet ? ». Une clé étrangère onDelete: Cascade ou une fonction purgerCompte() centralisée vaut mille suppressions manuelles oubliées. Le droit à l’oubli se code, il ne s’improvise pas au moment de la demande.

🧭 Sur FormaCampus — Un stagiaire adulte, pour qui FormaCampus est responsable, demande la suppression de son compte. On supprime : profil, scores de quiz, messages de support, journaux de consentement, entrées d’index. On conserve, isolé et pseudonymisé, ce que la loi impose de garder — la facture de la formation — pour la durée légale de conservation comptable, avant purge finale. On notifie les sous-traitants concernés (hébergeur, e-mailing) de procéder à l’effacement de leur côté (art. 19 et obligations du contrat de sous-traitance, art. 28). Sur le périmètre scolaire, où FormaCampus est sous-traitant, la demande d’effacement est transmise à l’école responsable, que FormaCampus assiste techniquement.

🔒 Côté personne concernée — Ce que la personne redoute, c’est le « compte fantôme » : croire avoir tout supprimé et retrouver ses données des mois plus tard dans un e-mail marketing ou une fuite. Une suppression honnête lui explique ce qui part tout de suite, ce qui est conservé (et pourquoi — la facture, pas le fichier de prospection), et quand le reste sera purgé. Cette transparence vaut mieux qu’un « c’est supprimé » vague et faux.

✏️ Exercices

Exercice 1 — Tout supprimer, vraiment ? Un ancien stagiaire demande l’effacement total de ses données. Il a suivi une formation payante il y a huit mois. Que supprimes-tu, que gardes-tu, et pourquoi ?

Exercice 2 — Effacement ou limitation ? Un stagiaire conteste l’exactitude de la note d’un module et demande qu’on arrête de l’utiliser le temps de vérifier — sans vouloir supprimer son compte. Quel droit, et que fais-tu techniquement ?

Exercice 3 — La cascade oubliée. Un dev implémente la suppression : DELETE FROM users WHERE id = ?. Le ticket est fermé. Où sont les fuites ?

🧠 Quiz de révision

Chapitre suivant : Portabilité & opposition — récupérer ses données dans un format machine pour les emporter ailleurs, et dire non à un traitement — en premier lieu à la prospection.