Chapitre 4.2 — Le consentement

⏱️ TL;DR — Quand le consentement est la bonne base, il doit être libre, spécifique, éclairé et univoque, exprimé par un acte positif clair — donc jamais de case pré-cochée (arrêt Planet49, CJUE C-673/17). Il doit être aussi facile à retirer qu’à donner. Et parce que le RGPD fonctionne à la preuve (accountability), tu dois journaliser chaque consentement : qui, quand, pour quoi, sur quelle version des mentions. Le consentement s’impose vraiment dans trois cas : prospection, cookies non essentiels, et données sensibles (où il doit être explicite).

🎯 Objectifs

• Recueillir un consentement valable au regard des 4 qualités.
• Bannir les cases pré-cochées et les consentements « forcés ».
• Rendre le retrait aussi simple que le recueil, et en tirer les conséquences.
• Prouver le consentement : horodatage, finalité, version des mentions.
• Savoir quand le consentement s’impose vraiment (et quand il est explicite).

Les 4 qualités d’un consentement valable

Un consentement ne « vaut » que s’il réunit quatre qualités cumulatives. Il en manque une → le consentement est invalide, et le traitement qui s’appuie dessus est illicite.

L’acte positif clair est le cœur du « univoque » : cocher soi-même une case décochée, cliquer un bouton explicite, envoyer un formulaire dédié. Ce qui ne compte pas : une case déjà cochée, un consentement « par défaut », le simple fait de continuer à utiliser le site.

📚 Le texte — L’arrêt Planet49 (CJUE, affaire C-673/17) a tranché : une case pré-cochée ne constitue pas un consentement valable, car il n’y a pas d’acte positif de l’utilisateur. C’est la référence à citer dès qu’on te propose une case déjà cochée « pour simplifier ».

Le retrait : aussi facile que le recueil

Le consentement se retire à tout moment, et le retrait doit être aussi simple que le fait de l’avoir donné. Si tu recueilles en un clic, tu dois pouvoir retirer en un clic — pas via un e-mail au support, un formulaire papier ou un parcours à cinq écrans. Le retrait ne vaut que pour l’avenir : il n’efface pas la licéité de ce qui a été traité avant.

Conséquence d’architecture : puisqu’un consentement peut disparaître à tout instant, aucun traitement indispensable au service ne doit en dépendre. Si ton produit cesse de fonctionner quand la personne retire son consentement, c’est le signe que tu avais choisi la mauvaise base (relis le chapitre 4.1).

💡 Réflexe — Code le retrait en même temps que le recueil, pas « plus tard ». Un bouton « Se désabonner » ou « Gérer mes préférences » accessible en un geste, et un traitement qui s’arrête réellement derrière. Un consentement qu’on ne peut pas retirer proprement n’est pas un consentement.

Prouver le consentement (accountability)

Recueillir ne suffit pas : il faut pouvoir démontrer que la personne a consenti, quand, pour quelle finalité et sur quelle version des mentions d’information. Sans cette trace, face à la CNIL, c’est comme si le consentement n’existait pas. Concrètement, tu tiens un registre de consentement — une table ou un journal append-only.

// Ce qu'un enregistrement de consentement doit pouvoir prouver
type EnregistrementConsentement = {
  personneId: string          // identifiant de la personne concernee
  finalite: string            // ex. "newsletter_marketing" - une finalite precise
  accorde: boolean            // true = donne, false = retire
  horodatage: string          // date et heure ISO 8601 de l'action
  versionMentions: string     // version des mentions d'information affichees
  preuveTexte: string         // libelle exact de la case au moment du clic
  canal: string               // ex. "formulaire_inscription", "double_opt_in_email"
}

Le même journal enregistre le retrait (une ligne avec accorde: false), ce qui permet de reconstituer l’historique complet des choix d’une personne. En JSON, une trace ressemble à ceci :

{
  "personneId": "usr_8c2f",
  "finalite": "newsletter_marketing",
  "accorde": true,
  "horodatage": "2026-03-14T09:41:07Z",
  "versionMentions": "mentions-v3-2026-01",
  "preuveTexte": "Je souhaite recevoir la newsletter de FormaCampus",
  "canal": "double_opt_in_email"
}

⚠️ Piège — Se contenter d’un booléen optin = true dans la table users. Ce champ ne prouve rien : ni la date, ni la finalité, ni le libellé exact accepté, ni la version des mentions. Le jour d’un contrôle ou d’une plainte, tu ne peux rien démontrer. La preuve, c’est un journal daté et versionné, pas une case dans le profil.

Quand le consentement s’impose vraiment

Le consentement n’est pas le défaut (chapitre 4.1), mais il est incontournable dans quelques situations où la personne doit garder la main :

• Prospection commerciale vers des prospects (e-mails marketing) : le principe est le consentement préalable. La prospection B2B peut relever de l’intérêt légitime sous conditions (chapitre 4.4), mais le B2C marketing repose sur le consentement.
• Cookies et traceurs non essentiels (mesure d’audience non exemptée, publicité, réseaux sociaux) : consentement requis, avec « refuser aussi simple qu’accepter ». Ce sujet relève de la directive ePrivacy et de la recommandation CNIL 2020 — on lui consacre la Partie 7.
• Données sensibles (art. 9 : santé, opinions, biométrie…) : quand la base retenue est le consentement, il doit être explicite — un acte renforcé et sans ambiguïté, spécifique à ces données. On développe en Partie 5.

🧭 Sur FormaCampus — Pour sa newsletter, FormaCampus met une case décochée « Je souhaite recevoir la newsletter », séparée de l’inscription (qui, elle, repose sur le contrat). Chaque opt-in part dans le journal de consentement avec horodatage et version des mentions, et le lien « Se désabonner » de chaque e-mail écrit une ligne de retrait. Pour les cookies de mesure d’audience non exemptés, un bandeau avec « Tout refuser » aussi visible que « Tout accepter ». Résultat : le jour où une académie demande des preuves, FormaCampus les sort en une requête.

🔒 Côté personne concernée — Un bon consentement se reconnaît de l’autre côté de l’écran : la personne comprend ce qu’elle accepte, coche elle-même, et retrouve un moyen évident de changer d’avis. Un consentement arraché par une case pré-cochée ou un dark pattern se retourne contre l’entreprise : plaintes, mauvaise réputation, sanctions.

✏️ Exercices

Exercice 1 — Repère les vices. Un formulaire propose : une case pré-cochée « J’accepte de recevoir des offres de nos partenaires », obligatoire pour valider l’inscription, et un désabonnement possible uniquement par courrier postal. Cite les qualités enfreintes.

Exercice 2 — Conçois la preuve. Ton chef veut « juste un champ newsletter = oui/non dans la table clients ». Explique pourquoi c’est insuffisant et propose le minimum à journaliser.

Exercice 3 — La bonne base ? Pour envoyer aux stagiaires inscrits un e-mail « votre attestation de fin de formation est disponible », faut-il leur consentement marketing ?

🧠 Quiz de révision

Chapitre suivant : Contrat & obligation légale — les deux bases les plus fréquentes en EdTech, et l’art de distinguer « nécessaire au contrat » de « pratique pour l’entreprise ».