Transformation Digitale·
Automatisation des processus métier : méthode
Priorisez le process, pas l'outil : auditez, testez et automatisez pour supprimer la ressaisie, réduire les erreurs et gagner du temps.
12 min de lecture
Transformation Digitale10 min de lecture
Cahier des charges RGPD : minimisation et purge
Règles pratiques pour minimiser, archiver et purger les données selon le RGPD : finalités par champ, durées, logs et droits d'accès.
Julien Thomas
Co-fondateur & CEO, Ziema
- RGPD
- Sur-Mesure
- Transformation Digitale
Si je ne fixe pas les règles RGPD avant le développement, je paie souvent deux fois : une fois pour construire, une fois pour corriger.
En clair, ce cahier des charges doit répondre tout de suite à 7 points :
- quelles données je collecte
- pourquoi je les collecte
- combien de temps je les garde
- quand elles passent en archive
- quand elles sont supprimées ou anonymisées
- qui peut y accéder
- comment je prouve tout ça en cas de contrôle
Je retiens une règle simple : chaque champ doit avoir un but précis. Si je ne peux pas l’expliquer, je le retire. Même logique pour la conservation : une fiche prospect ne reste pas indéfiniment, une facture suit sa durée légale, un ticket support doit finir soit anonymisé, soit supprimé selon la règle fixée.
Voici le socle à inscrire noir sur blanc :
- un champ = une finalité
- chaque donnée a une durée
- l’archivage a un déclencheur clair
- la purge part sur des traitements automatiques
- les exceptions sont limitées, datées et tracées
- les logs prouvent l’action sans recopier les données
- les accès suivent une matrice par rôle
Je vise aussi la preuve. En pratique, une entreprise doit pouvoir montrer qui a fait quoi, quand, sur quelle donnée et avec quel résultat. Sans journal de suppression, sans règles d’accès, sans tests de recette, la conformité reste théorique.
Petit repère utile : selon plusieurs retours de projets, une large part des champs présents dans des outils métier n’est jamais exploitée. Moins de données stockées = moins de risque en cas de fuite, moins de tri manuel, moins de coûts de reprise. C’est souvent là que le gain se voit le plus vite.
| Point à cadrer | Ce que je définis |
|---|---|
| Collecte | Champs obligatoires, facultatifs, interdits |
| Finalité | Usage métier précis pour chaque donnée |
| Conservation | Durée active par catégorie |
| Archivage | Date de bascule, accès autorisés |
| Purge | Suppression ou anonymisation, avec déclencheur |
| Preuve | Logs, journal des suppressions, export CSV/JSON |
| Accès | Droits par rôle, actions sensibles limitées |
Mon but est simple : écrire des règles claires, testables et appliquées sans flou. La suite de l’article pose justement ce cadre, du champ de formulaire jusqu’au journal de purge.
Ne collecter que les données utiles : champs, finalités et règles de collecte
Rattacher chaque champ à une finalité métier précise
Avant de concevoir le modèle de données, commencez par définir à quoi sert chaque champ. L’idée est simple : un champ sans finalité métier claire n’a rien à faire là.
Pour chaque champ, notez la finalité associée. Si cette finalité reste floue, supprimez le champ. Ensuite, classez-le dans l’une de ces trois catégories :
- obligatoire
- facultatif
- interdit
C’est une règle de base, mais elle évite un problème très courant : ajouter des champs “au cas où”, puis se retrouver avec des données qui ne servent à rien.
Bloquer par défaut les données inutiles ou sensibles
Le cahier des charges doit indiquer, pour chaque champ, s’il est obligatoire, facultatif ou interdit. Et ce point ne doit pas rester théorique : les champs exclus doivent être bloqués à la fois dans l’interface et dans le modèle de données.
Par défaut, interdisez les données sensibles et limitez les champs libres au strict nécessaire. Sinon, ils finissent souvent par devenir des zones fourre-tout. On y retrouve vite des données hors périmètre, saisies sans cadre, parfois sans même que l’équipe s’en rende compte.
Cette règle ne concerne pas seulement les écrans de saisie. Elle doit aussi s’appliquer aux formulaires et aux workflows.
Appliquer la protection des données personnelles dès la conception aux formulaires, modèles de données et workflows
Un formulaire ne doit pas proposer de champ de commentaire libre si aucun processus ne le justifie. Même logique pour les accès : chaque étape ne doit voir que les données strictement nécessaires.
Autrement dit, ces limites doivent être écrites dans le cahier des charges. Elles ne doivent pas être laissées au choix du développeur au moment de l’implémentation. Chaque workflow doit donc n’accéder qu’aux seules données utiles pour l’étape concernée.
Une fois les champs bien cadrés, il faut fixer leur durée de conservation.
WEBINAIRE - Gestion des données : Identifier et supprimer les données obsolètes conformément au RGPD
Fixer les durées de conservation, les règles d'archivage et la purge automatique
Une fois les champs bien définis, le cahier des charges doit aussi poser leur cycle de vie. En clair : passage en base active, archivage intermédiaire, puis suppression ou anonymisation. Le point de départ, c'est simple : fixer ces durées pour chaque catégorie de données.
Construire une matrice de conservation par catégorie de données
Le cahier des charges doit contenir un tableau de référence. Son rôle est clair : indiquer, pour chaque catégorie de données, la durée de conservation active, la durée d'archivage et la méthode de purge. C'est ce tableau qui sert de repère à l'équipe projet.
| Catégorie de données | Finalité | Conservation active | Archivage intermédiaire | Méthode de purge |
|---|---|---|---|---|
| Compte utilisateur | Accès au service | Durée du contrat | 5 ans (Code civil) | Suppression définitive |
| Tickets support | Assistance client | Jusqu'à clôture du ticket | 3 ans | Anonymisation de la description |
| Factures | Comptabilité | 2 ans | 10 ans (Code de commerce) | Suppression définitive |
| Fiches prospects | Prospection commerciale | 3 ans depuis le dernier contact | Aucun | Suppression définitive |
Ce tableau ne doit pas rester théorique. Il doit servir de base aux règles techniques de l'application. Autrement dit, il faut convertir cette matrice en règles d'archivage et de purge que le système peut exécuter sans ambiguïté.
Écrire des règles d'archivage et de purge concrètes dans le cahier des charges
Le cahier des charges doit indiquer ce qui déclenche chaque bascule. Par exemple : « la fiche prospect passe en archivage intermédiaire 3 ans après le dernier contact enregistré » ou « les données d'un compte utilisateur sont supprimées à la fin du contrat ».
Pour chaque règle, il faut préciser :
- la date de référence : création, dernière activité ou fin de contrat ;
- le délai avant archivage ;
- les rôles autorisés à accéder aux archives ;
- la méthode de purge : suppression définitive ou anonymisation irréversible.
Si vous retenez l'anonymisation, il faut décrire la méthode choisie. Sinon, on reste dans le flou, et une anonymisation mal définie peut souvent être réversible en pratique. Sur ce point, mieux vaut être carré.
Ces transitions doivent être gérées par des traitements automatiques, sans action manuelle. Sur de gros volumes, compter sur des interventions humaines, c'est la porte ouverte aux oublis.
Prévoir les alertes et gérer les exceptions
Certaines données ne peuvent pas être purgées automatiquement sans contrôle préalable. Le cahier des charges doit donc prévoir des alertes paramétrables. Un cas classique : un e-mail envoyé au DPO ou au responsable métier avant la fin d'une période de conservation quand une validation humaine est nécessaire.
Il faut aussi prévoir les exceptions. Un litige en cours ou une obligation légale peuvent empêcher une purge immédiate. Dans ces situations, la purge automatique doit pouvoir être suspendue manuellement. Mais cette suspension ne doit jamais être laissée sans cadre. Elle doit être documentée, limitée dans le temps et traçable. Une exception sans date de fin, c'est simplement une conservation non conforme.
Une fois ces règles fixées, il faut encore pouvoir démontrer qu'elles ont bien été appliquées, avec des logs et un journal de suppression.
Prouver la conformité : logs, journal de suppression et contrôle des accès
Matrice des droits d'accès RGPD par rôle
Une fois les durées et les règles de purge fixées, il faut encore montrer qu’elles sont bien appliquées. En clair, il ne suffit pas de prévoir la suppression. Il faut aussi garder des traces qui permettent de la vérifier. Le cahier des charges doit donc intégrer ces mécanismes de preuve dès le départ.
Journaliser les actions sans copier les données personnelles
Un journal d’audit n’est pas une copie bis de la base de données. Son rôle est simple : enregistrer qui a fait quoi, quand et avec quel résultat, sans recopier les données personnelles visées.
Chaque entrée doit faire apparaître :
- l’identifiant technique ;
- la date et l’heure ;
- l’action ;
- l’objet concerné ;
- le résultat.
Autre point à cadrer : la durée de conservation de ces journaux. Si on ne la fixe pas, le remède peut devenir le problème. Des logs mal gérés finissent vite par ressembler à une nouvelle base de données personnelles.
Tenir un journal dédié aux suppressions
Les logs d’audit généraux ne suffisent pas pour la purge. Il faut un journal à part, pensé pour suivre les suppressions et les anonymisations.
Les purges automatiques et les suppressions manuelles doivent y être tracées séparément des journaux techniques généraux. Ce journal doit indiquer ce qui a été supprimé ou anonymisé, la date exacte de l’opération, l’identifiant de l’acteur ou de la règle qui a déclenché l’action, ainsi que la règle de conservation liée.
Si une purge a été suspendue, le journal doit aussi prévoir un champ « motif de report ». Ce champ sert à noter la raison du report, par exemple un litige en cours ou une obligation légale, y compris les suspensions de purge. Et, point très concret, ce journal doit pouvoir être exporté en CSV ou JSON.
Restreindre les accès par rôle et sécuriser les actions sensibles
La traçabilité ne règle pas tout. Il faut aussi limiter les accès noir sur blanc. Le cahier des charges doit préciser qui peut faire quoi sur chaque catégorie de données.
Certaines actions demandent une vigilance forte : export en masse, suppression groupée, restauration d’une archive. Ces opérations ne doivent jamais être ouvertes par défaut à tous les profils.
| Rôle | Consulter | Modifier | Exporter | Archiver | Purger / Supprimer |
|---|---|---|---|---|---|
| Utilisateur métier | Oui (périmètre limité) | Non | Non | Non | Non |
| Manager / DPO | Oui (tout) | Oui | Oui | Oui | Non |
| Administrateur | Oui (tout) | Oui (journalisé) | Oui (en masse, journalisé) | Oui | Oui (manuel) |
| Moteur automatique | - | - | - | Oui (auto) | Oui (auto) |
| Équipe technique | Oui (logs techniques uniquement) | Non | Non | Non | Non |
L’équipe technique, de son côté, ne doit accéder qu’aux métadonnées système. Jamais aux données personnelles elles-mêmes.
Valider le cahier des charges et le garder opérationnel dans le temps
Relecture avec le juridique, le DPO et les équipes métier avant le développement
Une fois les règles posées, le cahier des charges doit indiquer clairement qui valide quoi et comment ces règles seront vérifiées. Cette étape ne se fait pas dans son coin. Avant de lancer le développement, le juridique, le DPO et les équipes métier doivent relire ensemble les règles définies plus haut.
Cette relecture doit rester alignée avec le registre des traitements de l’entreprise. C’est aussi le bon moment pour revoir certaines demandes de départ. Si une fonctionnalité n’a pas de vraie raison d’être, mieux vaut la retirer avant le développement. C’est souvent là que l’on évite des coûts de reprise plus tard.
Prévoir des tests de recette pour la minimisation, la purge et les droits d'accès
Valider sur le papier ne suffit pas. Il faut aussi tester ces règles avant la mise en production. Le cahier des charges doit donc traduire les règles RGPD en critères de recette vérifiables.
Lors de la phase de recette, voici les points à exiger :
- Un champ non justifié est bloqué à la saisie et à l’enregistrement.
- Les données échues basculent ou sont supprimées à la date prévue.
- Les journaux ne contiennent que les métadonnées de preuve prévues.
- Chaque rôle respecte la matrice d’accès.
Le cahier des charges doit aussi prévoir une mise à jour simple des durées et des règles de purge. Sinon, au moindre changement, tout devient lourd à modifier.
Conclusion : les points non négociables à inscrire dans votre cahier des charges
Un bon cahier des charges RGPD tient sur quelques règles fermes : un champ = une finalité déclarée, une durée de conservation par type de donnée, un statut d’archivage explicite, une purge automatique, des logs de preuve, des accès restreints par rôle, des alertes avant échéance et des exceptions documentées.
FAQs
Par où commencer pour cadrer la minimisation des données ?
Commencez par faire l’inventaire de chaque donnée collectée, puis demandez-vous si elle sert vraiment à quelque chose dans vos processus métier. L’idée est simple : dès la phase de conception, ne prévoir que les champs strictement nécessaires.
Dans le cahier des charges, indiquez aussi les durées de conservation pour chaque type de donnée, les règles d’archivage automatique et les accès restreints. Ça évite de stocker, au fil du temps, des données personnelles qui n’ont plus lieu d’être.
Comment choisir entre suppression et anonymisation ?
Le choix dépend surtout de ce que vous voulez faire des données après leur fin d’usage.
La suppression efface les données de façon définitive. L’anonymisation, elle, retire tout lien possible avec une personne, de manière irréversible, tout en gardant une utilité pour l’analyse statistique ou l’historique.
En clair : si vous devez encore exploiter ces données pour suivre des tendances ou conserver une mémoire chiffrée, l’anonymisation peut convenir. Si vous n’avez plus aucun besoin d’analyse, mieux vaut opter pour la suppression.
Quels tests prévoir avant la mise en production ?
Avant la mise en production, validez sur les plans technique et juridique le respect des règles fixées dans le cahier des charges RGPD.
Vérifiez en particulier :
- la suppression automatique des données selon les durées prévues ;
- les rôles et accès appliqués selon le principe du moindre privilège ;
- le journal de preuve ;
- les mécanismes d’alerte.
Écrit par
Julien Thomas
Co-fondateur & CEO de Ziema
Je dirige Ziema, où nous concevons les logiciels métier que les éditeurs du marché ne font pas : applications métier, plateformes opérationnelles et SaaS verticaux. Au forfait, avec un périmètre et un délai engagés. Nos références : 24 Heures Le Mans, E.Leclerc, Théra-Connect.
Suivre sur LinkedInVotre première application métier en production en 30 jours.
On développe l'application métier calquée sur votre activité, celle qui vous fait gagner le plus de temps. Le code vous appartient.
- Le code livré sur votre infrastructure, à votre nom
- En production en 30 jours, du cadrage à la mise en ligne
- Prix ferme une fois le périmètre validé
Une question sur votre projet ?
Décrivez-le en deux lignes, on vous répond sous 24h.
