Supprimer des données personnelles est une obligation légale. Ne pas supprimer des indicateurs de performance est une nécessité opérationnelle. Ces deux impératifs semblent contradictoires — ils ne le sont pas, à condition d'avoir anticipé la chose bien avant que la première donnée ne soit effacée. C'est précisément là que la plupart des organisations se font prendre.
Le droit à l'effacement : ce que le RGPD impose réellement
Le RGPD encadre la suppression des données personnelles à travers deux mécanismes distincts :
- Le droit à l'effacement (article 17), dit "droit à l'oubli" : une personne concernée peut demander la suppression de ses données lorsque celles-ci ne sont plus nécessaires à la finalité pour laquelle elles ont été collectées, lorsqu'elle retire son consentement, ou lorsque le traitement est illicite.
- Le principe de limitation de la conservation (article 5.1.e) : les données ne doivent pas être conservées plus longtemps que nécessaire à leur finalité. Passé ce délai, leur suppression ou anonymisation est obligatoire — sans qu'une demande individuelle soit nécessaire.
Ces deux obligations s'appliquent aux données personnelles, c'est-à-dire à toute information permettant d'identifier directement ou indirectement une personne physique. Elles ne s'appliquent pas à des données véritablement anonymisées — et c'est précisément cette distinction qui ouvre la voie à la préservation des KPI.
Le piège de la suppression brutale
Une suppression menée sans préparation détruit bien plus que des données personnelles. Elle emporte avec elle l'histoire opérationnelle d'un projet : combien d'usagers ont utilisé le service en 2022 ? Quelle était la fréquentation moyenne du portail captif un mardi de janvier ? Quel était le taux de conversion du formulaire de demande d'aide sociale avant la refonte de l'interface ?
Ces chiffres ne sont plus des données personnelles — ils ne permettent pas d'identifier qui que ce soit. Mais si personne n'a pris soin de les extraire et de les stocker séparément avant que les enregistrements sources ne soient supprimés, ils disparaissent avec eux.
Les conséquences sont souvent sous-estimées :
- Impossibilité de justifier les résultats d'un projet auprès d'élus, de financeurs ou d'autorités de contrôle sur la base de données historiques.
- Perte de la baseline nécessaire pour mesurer l'impact d'une évolution ou d'un investissement futur.
- Incapacité à détecter des tendances longues (saisonnalité, croissance, dégradation) qui ne se voient que sur plusieurs années de recul.
- Fragilisation des rapports d'activité : les bilans annuels construits sur des données supprimées deviennent impossibles à reproduire ou à vérifier.
Données personnelles vs données agrégées : la distinction clé
La CNIL et le Comité européen de la protection des données (CEPD) posent une distinction nette : une donnée est anonymisée — et donc hors du champ du RGPD — lorsqu'il est raisonnablement impossible de ré-identifier la personne concernée, même en croisant cette donnée avec d'autres sources.
Une statistique agrégée bien construite satisfait ce critère :
- « 1 247 connexions au portail Wi-Fi public en janvier 2023 » → donnée agrégée, non personnelle.
- « L'utilisateur ID 4521 s'est connecté 47 fois en janvier 2023 » → donnée personnelle, soumise au RGPD.
- « Fréquentation moyenne : 40 connexions par jour en semaine, 18 le week-end » → agrégat, non personnel.
- « M. Dupont s'est connecté tous les jours à 8h12 depuis l'arrêt de bus Gambetta » → donnée personnelle (identification + comportement + localisation).
Le seuil d'anonymisation réelle dépend du contexte. Pour des populations larges (milliers d'usagers), des agrégats simples suffisent généralement. Pour des populations petites (quelques dizaines de personnes dans un service interne), un agrégat « sur 12 personnes, 8 ont utilisé le service » peut permettre une ré-identification dans certains contextes — et nécessite davantage de prudence, voire l'application de techniques de differential privacy.
Mettre en place les mécanismes d'agrégation : pourquoi c'est long
C'est ici que réside le vrai enjeu de gestion de projet. Construire un pipeline d'agrégation robuste n'est pas une tâche qu'on réalise en quelques heures la veille d'une purge programmée. Voici pourquoi.
Définir les bons indicateurs demande de la réflexion
Quels KPI sont réellement utiles dans deux, cinq ou dix ans ? Cette question exige un travail de concertation avec les métiers, les élus et les financeurs. Des indicateurs mal choisis au moment de l'agrégation seront inutilisables ou trompeurs plus tard. Des indicateurs oubliés seront définitivement perdus.
Il faut notamment anticiper :
- Les granularités temporelles utiles (journalier, hebdomadaire, mensuel, annuel)
- Les dimensions de segmentation pertinentes (par type d'usager, par zone géographique, par canal d'accès) — tout en vérifiant que ces segmentations ne permettent pas une ré-identification
- Les indicateurs de qualité de service (taux de disponibilité, temps de réponse moyen, taux d'erreur) distincts des indicateurs d'usage
- Les métriques réglementaires imposées par des financeurs ou des contrats (taux de couverture, nombre de bénéficiaires uniques…)
Développer et tester le pipeline d'agrégation
Le pipeline d'agrégation est le processus automatisé qui, à intervalles réguliers, calcule les statistiques à partir des données brutes et les stocke dans une table ou un entrepôt dédié, avant que les données sources ne soient supprimées. Ce développement implique :
- La conception du modèle de données agrégées (structure des tables de statistiques, nomenclatures stables dans le temps)
- L'écriture et le test des requêtes d'agrégation (avec vérification de cohérence entre les chiffres agrégés et les données sources, tant que les deux coexistent)
- La mise en place des jobs automatisés et leur supervision (alertes en cas d'échec, journalisation des exécutions)
- La validation métier des premiers résultats produits (les chiffres sont-ils cohérents avec ce qu'on observe dans les outils de reporting existants ?)
Faire tourner le pipeline en parallèle avant la suppression
Une fois le pipeline développé, il doit tourner en parallèle des données sources pendant une période suffisante — typiquement plusieurs semaines ou plusieurs mois — avant que la suppression ne soit déclenchée. Cela permet :
- De valider que les agrégats produits sont cohérents et complets
- De détecter les cas limites ou les anomalies dans les données sources qui pourraient fausser les statistiques
- D'ajuster les indicateurs si les métiers réalisent que certains KPI manquent ou que certains ne sont pas pertinents
- De constituer un historique rétroactif en recalculant les agrégats sur les périodes passées
Ce n'est qu'à l'issue de cette phase de validation que la suppression des données personnelles sources peut être déclenchée en confiance.
Planifier la suppression comme un projet à part entière
La suppression de données dans le respect du RGPD n'est pas une opération de maintenance. C'est un projet qui doit être planifié, budgété et piloté avec la même rigueur qu'un développement fonctionnel. Les étapes clés :
- Cartographier les données à supprimer : dans quelles tables, quels systèmes, quels fichiers ? Les données personnelles sont rarement centralisées dans un seul endroit — elles se trouvent souvent dans des logs, des sauvegardes, des exports CSV, des e-mails archivés, des bases de données de test.
- Définir le calendrier en tenant compte des durées légales de conservation, des procédures contentieuses en cours (des données en lien avec un litige ne peuvent pas être supprimées avant la fin de la procédure), et des cycles de reporting.
- Valider les agrégats avant suppression : procéder à une recette formelle des statistiques produites, co-signée par les responsables métiers.
- Documenter la suppression dans le registre des traitements : date d'exécution, périmètre, responsable de l'opération, confirmation de destruction des copies (sauvegardes incluses).
- Notifier les sous-traitants : si des prestataires hébergent ou traitent les données, ils doivent être instruits de procéder à la suppression de leur côté et fournir une confirmation.
Ce qu'on ne peut pas récupérer après coup
Une erreur fréquente est de croire qu'on pourra toujours "récupérer les stats plus tard". Une fois les données supprimées, c'est définitif. Il n'existe pas de marche arrière. Les quelques situations qui semblent offrir une issue de secours ont toutes leurs limites :
- Les sauvegardes : si elles existent encore, les restaurer pour extraire des statistiques constitue un nouveau traitement de données personnelles, qui doit lui-même être licite, proportionné et documenté — et qui repart du problème initial.
- Les outils de web analytics (Matomo, Google Analytics) : ils conservent souvent des agrégats par défaut, mais uniquement pour les indicateurs qu'ils sont configurés pour suivre. Ils ne remplacent pas un pipeline d'agrégation métier.
- Les exports ponctuels faits "à la main" par des équipes : souvent incomplets, non reproductibles, rarement documentés, et parfois eux-mêmes devenus non conformes s'ils ont été conservés dans des dossiers partagés sans contrôle d'accès.
La règle est simple : tout KPI qu'on voudra consulter après la suppression doit avoir été calculé et stocké avant la suppression. Pas pendant. Pas après. Avant.
En résumé : une séquence, pas une improvisation
La bonne pratique se résume à une séquence irréversible et non négociable :
- Identifier les KPI à préserver — en concertation avec les métiers, avant tout développement
- Concevoir et développer le pipeline d'agrégation — avec validation du modèle de données
- Faire tourner le pipeline en parallèle pendant la période de données encore disponibles
- Valider les agrégats produits — recette formelle, co-signée
- Déclencher la suppression — sur toutes les copies, y compris sauvegardes et systèmes tiers
- Documenter l'opération dans le registre des traitements
Ce séquencement prend du temps — plusieurs mois dans les projets complexes. C'est précisément pourquoi il doit être anticipé dès la conception du système, et non découvert au moment où la CNIL frappe à la porte ou où un délai légal de conservation expire.
Les organisations qui gèrent bien cette tension entre obligation d'effacement et nécessité de mémoire opérationnelle sont celles qui ont traité la question non pas comme un problème juridique, mais comme un enjeu d'architecture de données. Le RGPD ne leur interdit pas de savoir ce qui s'est passé — il leur interdit de le savoir au niveau de l'individu.
