RGPD : exporter et effacer un compte, concrètement

RGPD Conformité Architecture Méthode
Publié le

La plupart des applications traitent la demande d’effacement à la main, six mois après avoir promis dans leurs mentions légales qu’elle se traite en un mois. Voici comment la tenir dans le code.

Effacer n’est pas la seule réponse

Le règlement prévoit un droit à l’effacement, et il prévoit aussi ses limites. Trois gestes existent, et confondre les trois est l’erreur qui fait perdre le plus de temps.

Effacer. La ligne disparaît. C’est la réponse par défaut pour tout ce qui ne concerne que la personne : ses préférences, ses sessions, ses fichiers déposés.

Pseudonymiser. La ligne reste, ce qui désigne la personne part. C’est la réponse quand la ligne appartient aussi à quelqu’un d’autre. Un message dans un fil de discussion : l’effacer troue la conversation des autres participants. Une idée retenue dans une boîte à suggestions, avec la réponse publique de l’équipe : l’effacer efface un engagement pris devant les autres membres.

Conserver. La ligne reste intacte, et ce choix doit être motivé. Une sanction, une facture, un journal d’accès : il existe une obligation légale ou un intérêt légitime qui prime sur la demande. La décision revient au responsable du traitement, pas au développeur.

Le tenir dans le code, pas dans un document

Le document qui décrit ces choix se périme au premier module ajouté. La seule version qui reste vraie est celle qui vit à côté du code et qui empêche de livrer sans elle.

Sur Beacon, chaque module déclare ce qu’il collecte, sous la forme d’un objet :

{
  cle:        'suggestions.idees',
  titre:      'Vos suggestions et vos soutiens',
  finalite:   'Recueillir les idées des membres et y répondre en public.',
  categories: ['contenu'],
  geste:      () => 'pseudonymiser',
  pourquoi:   'Une idée retenue appartient à la communauté, et la réponse ' +
              'publique de l’équipe est un engagement pris devant les autres.',
  lire:       async (db, sujet) => { /* ce qu'on détient */ },
  effacer:    async (db, sujet) => { /* le geste, et le nombre de lignes */ },
}

Le pourquoi est affiché à la personne, dans l’écran où elle demande l’effacement. Il n’est donc pas décoratif : il faut pouvoir l’assumer devant elle, ce qui change la façon de le rédiger.

Un module qui ne fournit pas cette déclaration ne passe pas la vérification de construction. Un module qui ne collecte rien doit le déclarer explicitement, avec sa justification, plutôt que de rester absent de la liste. La différence entre « ne collecte rien » et « a été oublié » est invisible sur une liste, et elle est exactement ce qu’un contrôle cherche.

L’export, du côté de la personne

Le droit d’accès se satisfait beaucoup mieux par un bouton que par une adresse de contact. La personne télécharge elle-même, depuis son profil, un fichier qui contient ce que le site détient sur elle.

Deux détails changent tout à l’usage :

Montrer le contenu avant de le produire. La liste des collectes, avec ce que chacune contient, s’affiche avant le téléchargement. Beaucoup de demandes s’arrêtent là, parce que la personne voulait surtout savoir.

Produire un format lisible. Un JSON de trois mille lignes satisfait le règlement et personne d’autre. Un tableau par collecte, avec des en-têtes en français, se lit.

La conservation, la partie qu’on oublie

Le droit à l’effacement occupe toute la discussion, et la durée de conservation est celle qui pose problème en contrôle. Garder des journaux d’accès pendant cinq ans sans raison est une infraction plus facile à constater qu’un effacement mal fait.

La réponse est un minuteur qui passe sur chaque règle et supprime ce qui est échu, avec deux précautions :

  • Un mode simulation qui dit ce qui partirait sans rien supprimer. Personne ne lance une purge en production sans l’avoir vue d’abord.
  • Un plafond par passage. Une purge qui trouve deux millions de lignes le premier jour ne doit pas les supprimer en une transaction.

Hors de votre base

Cette mécanique traite les données de votre base. Elle ne dit rien de ce que vous avez envoyé à un tiers : un service de paiement, un outil de mesure d’audience, un hébergeur de fichiers. Chacun a sa propre procédure, et votre responsabilité ne s’arrête pas à votre serveur.

Elle ne remplace pas non plus le registre des traitements ni l’analyse d’impact quand elle est requise. Elle rend le premier automatique, ce qui est déjà la partie qui se périme le plus vite.