---
title: "RGPD"
weight: 100
description: "Consentement, droit à l'effacement, rétention des données et accès aux archives."
---

# RGPD

difuzio est conçu pour faciliter la conformité : traçabilité du consentement,
droit à l'effacement, rétention bornée, et localisation maîtrisée des données.

## Consentement

Chaque abonné porte la trace de son consentement :

- `consent_source` : l'origine du consentement (`web_form`, `email_confirm`,
  `admin_import`, `api`) ;
- `consent_evidence` : un texte libre décrivant la preuve (formulaire, date,
  référence d'import, etc.) ;
- `consent_at` : la date du consentement ;
- `consent_text_ver` : la version du texte de consentement que la personne a
  accepté, recopiée depuis le réglage `consent_text_ver` de la liste au moment de
  l'inscription. Elle n'est renseignée que pour les canaux qui la composent :
  formulaire web (`web_form`, y compris après approbation d'un modérateur) et
  confirmation par courriel (`email_confirm`). Un import ou un ajout forcé la
  laisse vide : la personne n'a jamais vu ce texte, sa preuve est
  `consent_evidence`. Modifier le réglage de la liste ne réécrit jamais les
  membres déjà inscrits, qui gardent la version qu'ils ont réellement acceptée.

Le double opt-in (politique d'abonnement `confirm`) produit un consentement
`email_confirm` horodaté, sans intervention. Pour les ajouts par import ou par
API, une preuve de consentement est exigée : une demande sans preuve est rejetée
(`422` côté API). Cela évite d'inscrire des personnes sans base légale.

## Droit à l'effacement

    CREDENTIALS_DIRECTORY=/etc/difuzio/secrets difuzio erase --config /etc/difuzio/config.yaml \
        --email personne@example.org --confirm

Le drapeau `--confirm` est obligatoire (opération irréversible), et `--config`
également : le corps des messages est stocké hors de la base
(`storage.blob_dir`), et seul le fichier de configuration en donne le chemin. La
commande refuse de s'exécuter avec `--dsn` seul plutôt que de vider les lignes en
laissant les corps sur disque.

La commande efface les données personnelles table par table :

- suppression dure des abonnements (`members`), des rebonds (`bounces`), des
  demandes d'abonnement en attente, des tokens, des compteurs de débit, et du
  compte utilisateur le cas échéant ;
- purge du brut des messages postés par la personne : la ligne `messages` est
  pseudonymisée et l'objet correspondant est délié sur disque. Les chemins sont
  relevés dans la transaction et les fichiers supprimés après validation ; si un
  fichier ne peut pas être supprimé, la commande remonte une erreur au lieu
  d'annoncer un effacement complet ;
- l'`audit_log` est conservé (obligation légale, Art. 17(3)) mais le label est
  remplacé par un hash et l'adresse IP est mise à NULL : la traçabilité des
  actions subsiste sans réidentifier la personne.

La commande affiche un rapport du nombre de lignes traitées par table :

    erased personne@example.org: members=3 messages=12 (raw objects unlinked=12)
    bounces=1 pending=0 tokens=2 rate=0 users=1 (audit_log 5 hashed)

Un échec partiel est remonté, jamais silencieux : si une étape échoue, l'erreur
est journalisée et signalée.

## Rétention

difuzio borne la conservation des données techniques :

- copies sortantes terminales : purgées au-delà de `worker.outq_retention_days`
  (3 jours par défaut) ;
- jobs entrants : `worker.inbound_retention_days` (au moins 7 jours, pour couvrir
  la déduplication LMTP face à la file MTA amont) ;
- tokens expirés ou consommés : purgés périodiquement ;
- éléments de modération et demandes d'abonnement : expirés au-delà de leur
  fenêtre ;
- clés d'idempotence (`idempotency_keys`) : purgées au-delà de 24 h ;
- file de livraison des webhooks (`webhook_deliveries`) : effacée en cascade à la
  suppression du webhook.

Les tables techniques `send_events` (marqueur d'envoi terminé) et `digest_state`
(filigrane de digest par liste) ne portent pas de PII directe (identifiants
internes). L'effacement RGPD d'une personne (`erase`) reste exhaustif.

Côté journaux applicatifs, aligner la rétention (journald / logrotate) sur 90
jours, ces journaux pouvant contenir des adresses email (voir
[Exploitation](/difuzio/admin/exploitation)).

## Localisation et sous-traitants

Toutes les données applicatives résident dans la base que vous opérez (MariaDB,
ou le fichier SQLite de la variante "light"). Les
flux sortants de données personnelles sont : la remise du courrier au relais
submission (votre MTA) puis aux destinataires, et, si vous en configurez, les
webhooks (chaque événement signé est `POST`é vers l'URL que vous enregistrez -- à
documenter dans votre registre de traitement). difuzio n'envoie aucune donnée à un
service tiers de lui-même.

## Accès aux données

- l'accès aux archives d'une liste est borné par `archive-access`
  (`public` / `members` / `owners`) ;
- la visibilité de la liste des abonnés est bornée par les rôles (voir
  [Utilisateurs et rôles](/difuzio/admin/utilisateurs-roles)).