1.5 KiB
title, area, horizon, tags, flag, src
| title | area | horizon | tags | flag | src |
|---|---|---|---|---|---|
| <code>AuditLog</code> n'a aucune purge | backend | v1 | manager-service | warn | RGPD · lot J | v1-plan.md lot F · STATUS.md §1sexies |
VisitEvent purge à 13 mois, VisitorQuestion à 90 jours, AuditLog à jamais. C'est un sujet RGPD et rien d'autre : la table porte UserId, et les valeurs avant-après d'une modification de User contiennent e-mail, prénom et nom. Ce n'est pas un sujet de volume — l'inondation par WeatherSyncService est coupée depuis le 12/08, la table croît désormais au seul rythme des éditions humaines. Donc à traiter au lot J, pas au lot F. Recommandation : 12 mois, uniforme, via un AuditLogPurgeService calqué sur VisitEventPurgeService — 12 et non 13, le 13 mois des stats existe pour comparer une saison à la précédente et le recopier ici serait du mimétisme. ⚠️ Reprendre le même verrou : purge inerte tant qu'Audit:RetentionDays n'est pas défini, le pg_dump quotidien n'étant toujours pas en place — supprimer des lignes d'audit sans restauration fine est la pire combinaison. Écarté : garder les Delete plus longtemps que les Create/Update, ça double les règles pour un cas qu'une sauvegarde couvre déjà.