Loi 25 : journal d'audit immuable et cycle de vie des données
Quand une plateforme traite des données d'élèves mineurs, deux questions finissent toujours par se poser : qui a fait quoi, et quand? Et combien de temps garde-t-on ces données? J'ai implémenté les deux réponses exigées par la Loi 25 : un journal d'audit immuable et un cycle de vie complet des données.
Le contexte
La plateforme SaaS sur laquelle je travaille corrige des textes d'élèves à l'aide de l'IA, pour des écoles du Québec (c'est aussi celle de la console d'administration). Les données qu'elle traite sont donc des renseignements personnels de mineurs.
Au Québec, la Loi 25 a modernisé l'encadrement de ces renseignements. Elle impose notamment une évaluation des facteurs relatifs à la vie privée (EFVP) pour tout projet de système d'information qui en traite, et la destruction ou l'anonymisation des renseignements une fois leur finalité atteinte. L'EFVP de la plateforme a fixé des exigences claires : tracer les actions sensibles et maîtriser la durée de vie des données.
Le problème
Ces exigences se traduisent en besoins très concrets :
- rendre des comptes : pouvoir dire, pour chaque action sensible, qui l'a faite, quand et sur quelle donnée, avec un historique auquel personne ne peut toucher;
- ne rien garder plus longtemps que nécessaire, sans perdre la possibilité de revenir en arrière tant que les données sont seulement archivées.
Deux besoins en tension : d'un côté, ne jamais effacer l'historique; de l'autre, savoir effacer les données pour de bon.
La solution
Un journal d'audit immuable
Les actions sensibles sont consignées dans un journal d'audit : qui, quoi, quand, sur quelle ressource. Ce journal fonctionne en ajout seul : l'API n'expose aucune opération pour modifier ou supprimer une entrée. Une fois écrite, une trace reste telle quelle.
L'immuabilité est ici une décision de conception : aucune route, aucun service ne permet de réécrire l'histoire.
Un cycle de vie complet des données
Les données suivent un cycle explicite, organisé par période :
| Opération | Ce qu'elle fait |
|---|---|
| Archivage | Sort les données d'une période de l'usage courant, sans les détruire |
| Restauration | Ramène une période archivée si nécessaire |
| Purge | Supprime définitivement les données qui n'ont plus à être conservées |
| Réinitialisation | Remet un espace à zéro pour repartir sur une nouvelle période |
Cette séparation rend les choses claires : archiver est sans risque, puisqu'on peut restaurer; purger est définitif, et c'est voulu.
Les résultats
- Les fonctionnalités exigées par l'EFVP sont en place : traçabilité des actions sensibles et maîtrise de la durée de conservation.
- Un historique fiable : en cas de question ou d'incident, on peut retracer qui a fait quoi, et quand.
- Une durée de vie des données maîtrisée, de l'archivage à la purge, par des opérations prévues pour ça plutôt que par des manipulations manuelles.
Ce que j'en retiens
- La conformité est une fonctionnalité comme une autre, avec ses utilisateurs, ses cas limites et ses tests. Traitée comme une case à cocher, elle devient de la dette.
- L'immuabilité se décide à la conception : le plus sûr moyen qu'une trace ne soit jamais modifiée, c'est de ne jamais écrire le code qui le permettrait.
- Penser la suppression dès le départ. Purger proprement des données est bien plus simple quand le modèle de données a été pensé pour.