# Cinq ans de logs à conserver : le coût pour une collectivité

> Une obligation réglementaire de conservation des journaux sur cinq ans change complètement le dimensionnement d'une base et d'un cache pour un site public. Checklist commentée avant de s'engager.

- Auteur : WordPress Développement
- Publié le : 2021-08-23
- Mis à jour le : 2021-08-23
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/cinq-ans-logs-cout-collectivite/

## L’essentiel

- Les logs applicatifs ne doivent jamais vivre dans les mêmes tables que le contenu
- La rotation et l'archivage à froid limitent la croissance de la base active
- Le cache ne doit jamais dépendre d'une table qui grossit indéfiniment

Combien pèsent cinq années de journaux d'accès et d'événements applicatifs sur un site public à trafic modéré mais constant ? Avant de répondre par un chiffre, il faut d'abord répondre à une question d'architecture : où ces journaux doivent-ils vivre pour ne jamais ralentir le site qu'ils sont censés surveiller. C'est la question posée lors du dimensionnement d'un site pour une collectivité soumise à une obligation réglementaire de conservation de cinq ans sur certains journaux d'activité.

Cette checklist reprend, poste par poste, les décisions prises pour que cette contrainte de conservation n'impacte jamais les temps de réponse perçus par les visiteurs du site public.

## 1. Ne jamais stocker les logs dans les tables de contenu WordPress

Le premier réflexe erroné consiste à utiliser une table personnalisée liée au même schéma que `wp_posts` ou `wp_postmeta`, sur la même base que le contenu éditorial. Sur cinq ans, une table de journaux accumule plusieurs millions de lignes, ce qui dégrade les performances de toute requête touchant à la même base, y compris via un cache de requêtes partagé au niveau du moteur MySQL. La table de journaux a été isolée sur un schéma séparé, avec ses propres index, pour qu'une opération de maintenance dessus (optimisation, archivage) n'impacte jamais les tables actives du site.

## 2. Dimensionner le volume réel avant de choisir un moteur de stockage

Une estimation a été faite en amont : sur la base du trafic mesuré (environ 4 000 visites par jour) et du niveau de détail exigé par l'obligation réglementaire (adresse IP tronquée, date, action, ressource consultée), le volume annuel estimé s'élève à environ 8 Go, soit environ 40 Go cumulés sur cinq ans avant toute compression. Ce chiffre a orienté le choix vers une table InnoDB compressée plutôt qu'un stockage non compressé, avec un gain mesuré d'environ 60 % sur l'espace occupé.

> L'essentiel à retenir : Les logs applicatifs ne doivent jamais vivre dans les mêmes tables que le contenu ; La rotation et l'archivage à froid limitent la croissance de la base active ; Le cache ne doit jamais dépendre d'une table qui grossit indéfiniment

## 3. Partitionner par période pour limiter le coût des requêtes de purge

Même avec une conservation de cinq ans, certaines catégories de journaux moins sensibles peuvent être purgées plus tôt selon des règles internes à la collectivité. Une table non partitionnée rend cette purge coûteuse (un `DELETE` massif verrouille la table pendant sa durée d'exécution). La table a été partitionnée par année via `PARTITION BY RANGE` sur la colonne de date, ce qui permet de supprimer une partition entière (une année) en une opération quasi instantanée, plutôt qu'un `DELETE` ligne par ligne :

```
ALTER TABLE journaux_acces
PARTITION BY RANGE (YEAR(date_evenement)) (
    PARTITION p2021 VALUES LESS THAN (2022),
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION pmax VALUES LESS THAN MAXVALUE
);
```

## 4. Isoler le cache objet des tables de journaux

Le cache d'objets persistant (Redis dans ce cas) ne doit jamais être sollicité pour des lectures ou écritures liées aux journaux : ces données sont écrites en continu et lues rarement (uniquement en cas de contrôle ou d'audit), ce qui en ferait un très mauvais candidat au cache, capable au contraire de pousser hors du cache des données réellement utiles au rendu des pages publiques. Les écritures de journaux passent directement en base, sans transiter par la couche de cache objet.

## 5. Archiver à froid après une période active

Après validation avec le service juridique de la collectivité, il a été convenu que seule la dernière année de journaux devait rester consultable rapidement depuis l'interface d'administration ; les quatre années précédentes, toujours conservées pour respecter l'obligation légale, sont exportées mensuellement vers un stockage à froid (fichiers compressés horodatés, hors de la base active), consultables uniquement via un script d'extraction en cas de besoin d'audit.

1. Export mensuel automatisé via une tâche planifiée WP-Cron déportée vers un vrai cron système, plus fiable sur un job récurrent de cette nature.
2. Vérification d'intégrité de l'export (somme de contrôle) avant purge de la partition correspondante en base active.
3. Documentation de la procédure de restauration, testée une fois par an pour garantir qu'elle fonctionne réellement le jour où un audit la réclame.

> Une obligation de conservation n'impose pas de tout garder au même endroit, au même niveau de disponibilité, pendant cinq ans.

## En résumé

Dimensionner un site pour une obligation de conservation de journaux sur cinq ans exige de séparer clairement les données actives des données à archiver, de partitionner par période plutôt que de tout stocker dans une table monolithique, et de tenir le cache objet à l'écart de données qui n'ont rien à y gagner. Cette checklist, appliquée dès la conception, a permis d'éviter que la contrainte réglementaire ne devienne, cinq ans plus tard, un problème de performance sur le site public lui-même.