La Limitation de Conservation Est la Nouvelle Ligne de Front de la Répression en 2026 pour l'Analytics

La question coûteuse du RGPD était autrefois avez-vous une base légale pour collecter ceci. En 2026, elle est devenue pourquoi est-ce encore dans votre base de données. Deux actions répressives ont fait passer la conservation d'une note de bas de page documentaire à la ligne de front, et les systèmes d'analytics se trouvent en plein dans le rayon d'impact.

Deux décisions qui ont déplacé la cible

Le 13 janvier 2026, la CNIL a infligé 27 millions d'euros à Free Mobile et 15 millions à Free. La plupart des articles se sont concentrés sur la violation de 2024 qui a exposé 24 millions de contrats d'abonnés, mais la décision citait aussi directement l'article 5(1)(e) — la limitation de conservation. Free Mobile avait conservé des données sur 2,8 millions de contrats résiliés depuis plus de dix ans sans justification. Les données n'ont pas été collectées illicitement. Elles ont été conservées illicitement.

Un mois plus tard, l'EDPB a publié les résultats de son action coordonnée de contrôle de 2025. Trente-deux autorités de protection des données ont audité 764 responsables de traitement sur leurs pratiques d'effacement et ont trouvé deux défaillances systémiques : l'absence de classification interne des données et l'absence de suppression automatisée dans les systèmes informatiques eux-mêmes. Une politique de conservation documentée que rien n'applique techniquement a été traitée comme une circonstance aggravante, et non atténuante.

Le signal est sans ambiguïté. Les régulateurs présument désormais que la collecte a eu lieu ; ils auditent la suppression.

Pourquoi l'analytics est l'endroit évident où regarder

La limitation de conservation au titre de l'article 5(1)(e) prévoit que les données personnelles ne doivent pas être conservées sous une forme identifiable plus longtemps que la finalité ne l'exige. La plupart des stacks d'analytics y manquent silencieusement.

Une table d'événements typique stocke une ligne par interaction liée à un identifiant stable — un ID de cookie, un ID d'appareil, un e-mail haché — avec un horodatage et sans expiration. Le schéma est conçu pour tout garder indéfiniment, afin que « on voudra peut-être l'interroger plus tard » reste possible. C'est précisément la conservation au cas où que la CNIL a sanctionnée.

Le problème s'aggrave parce que c'est l'identifiant qui rend une ligne personnelle. Tant que user_id = a91f... peut être relié à une personne sur des mois d'événements, chacune de ces lignes entre dans le champ d'application, chacune est soumise aux demandes d'accès et d'effacement, et chacune est une responsabilité en cas de violation. La conservation n'est pas un coût de stockage. C'est une exposition mesurée en temps.

Minimiser à l'écriture l'emporte sur supprimer à la lecture

La solution durable n'est pas un meilleur cron job qui élague les anciennes lignes. C'est un modèle de données où la forme identifiable ne persiste jamais en premier lieu.

Le modèle d'identité de Monoid est construit autour de cela. Un visiteur est représenté uniquement par un hash quotidien :

SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

L'IP et le User-Agent bruts n'existent que dans la mémoire du Worker, le temps de calculer ce hash ; D1 stocke le hash, jamais les valeurs brutes. Comme la date est une entrée, le hash du même visiteur change à chaque minuit. Il n'y a aucun identifiant stable d'un jour à l'autre à conserver, donc le profil inter-sessions que vise la limitation de conservation ne peut pas s'accumuler — non par politique, mais par construction.

C'est de la minimisation des données à l'écriture. Vous ne supprimez pas le lien plus tard parce que vous ne l'avez jamais écrit. Une demande d'effacement devient triviale quand il n'y a aucune clé durable contre laquelle effacer.

Une conservation que vous pouvez réellement prouver

La limitation de conservation a tout de même besoin d'une borne externe, et une borne défendable est courte et appliquée, pas longue et aspirationnelle. Monoid conserve les données de pages vues pendant 730 jours au maximum. Deux ans sont un plafond délibéré pour l'analyse des tendances, et la purge est une opération réelle sur la table, pas une ligne dans un PDF de politique. Le constat de l'EDPB était que les politiques sans application sont la faille que les enquêtes exploitent ; une conservation qui s'exécute réellement la referme.

La combinaison compte plus que chacune des moitiés. Des hash qui tournent chaque jour signifient que les données sont déjà de forme agrégée avant même que la conservation ne s'applique. La purge à 730 jours signifie que même ce signal agrégé a une fin nette et démontrable.

Comment juger tout analytics dont vous dépendez

Quel que soit l'analytics qui se trouve derrière votre site, trois vérifications correspondent directement à ce que les régulateurs ont audité :

• Trouvez chaque champ qui relie un enregistrement à une personne dans le temps. Un ID utilisateur stable, une valeur de cookie persistante, une IP brute, un fingerprint. Chacun transforme un journal d'événements en un profil conservé — demandez donc si l'analytics que vous utilisez en stocke ne serait-ce qu'un seul.
• Demandez quand la conservation est appliquée — à l'ingestion ou lors d'une revue trimestrielle. La minimisation qui se produit au moment où les données sont écrites l'emporte sur un job de suppression que quelqu'un doit se souvenir de lancer. La réponse la plus solide est un modèle où la forme identifiable n'a jamais été stockée en premier lieu.
• Demandez si la suppression est démontrable. Si un fournisseur ne peut pas pointer une borne de conservation stricte qui s'exécute réellement, il a une politique, pas un contrôle — et le contrôle de l'EDPB vient de vous dire lequel des deux est sanctionné.

Les données les moins coûteuses à défendre lors d'un audit sont celles que vous n'avez jamais conservées sous forme identifiable. La limitation de conservation n'est plus une clause à paraphraser dans une politique de confidentialité ; c'est ce que la prochaine enquête mesurera, et l'architecture qui y répond est celle qui n'a jamais eu de profil à supprimer.

Sources

• RGPD Article 5 — Principes relatifs au traitement des données à caractère personnel (limitation de la conservation)
• Règlement (UE) 2016/679 (RGPD), texte officiel sur EUR-Lex
• EDPB — Action coordonnée de contrôle 2025 sur la mise en œuvre du droit à l'effacement
• Google Analytics 4 — Conservation des données