Si tu as 30 secondes. « Ne pas dupliquer les données » est une règle qui se casse en production : les caches sont légitimes, et tu finis par les livrer quand même. La règle qui tient vraiment est plus fine — toute valeur stockée qui ressemble à une duplication est soit Live, soit Snapshot, soit Cache, et chaque catégorie impose une implémentation distincte. Sauter la classification, c'est livrer le genre de bug que je viens de trouver multiplié par 560 lignes : une colonne qui se périme en silence parce que personne n'a décidé si elle devait suivre sa source ou non. Utile si tu as des tables backend que tu as cessé de croire.

Une colonne que personne ne mettait à jour

Le samedi 18 avril 2026, en milieu de matinée. Je relis le tableau de bord avec Hélène, qui tient les comptes de l'école depuis dix-neuf ans. Son cahier est ouvert, le mien c'est l'écran. Elle pointe sur une ligne — une élève de céramique, troisième année, un cas parfaitement banal — et fronce les sourcils. Rembrandt dit qu'elle nous doit encore 1 159 €. L'échéancier d'Hélène dit 2 262 €. On recoupe sur le papier. Onze mensualités à 205,65 €. Hélène a raison.

La colonne que mon tableau de bord lit, c'est contacts.montant_total. Elle a été remplie à l'import en mars depuis une somme unique à un instant unique, et rien dans le code ne la met à jour. Trois semaines plus tard, une mensualité s'ajoute — Hélène l'a saisie à la main dans la nouvelle table echeances — et la colonne ne bouge pas. Le tableau de bord lit ce qu'on lui a donné en mars, qui était juste en mars.

L'audit qui suit donne 72 contacts divergents et environ 18 000 € de non-dette fantôme. « Et combien d'autres comme ça » — Hélène demande, plus calme que moi, parce que c'est exactement ce qu'elle attend d'un logiciel qui décide tout seul.

Le bug n'est ni dans la SUM, ni dans le script de migration, ni dans le cron. Le bug, c'est que personne n'a jamais tranché ce que contacts.montant_total était censé être — un snapshot d'un moment, un cache d'une somme, ou une valeur qui doit toujours refléter l'échéancier courant. La colonne a été insérée parce qu'on en avait besoin à ce moment-là. Le mécanisme qui l'aurait gardée vraie maintenant n'a jamais été écrit, parce que la question n'a pas été posée.

C'est l'article sur la question.

Pourquoi « ne pas dupliquer » ne marche pas

La règle naïve « ne pas dupliquer les données » interdit aussi les caches qu'on veut garder — vues matérialisées, compteurs synchronisés. La règle qui tient : toute valeur stockée qui ressemble à une duplication est Live, Snapshot ou Cache, classée avant d'être créée. Une duplication sans catégorie est un bug en attente.

Les trois catégories

Live

La valeur doit toujours refléter l'état courant du système. Aucune raison métier de la figer à un moment précis.

Implémentation : ne pas la stocker. Lecture directe via une vue SQL (v_*) ou une requête sur les tables sources.

Dans Rembrandt : v_reste_du_contact.montant_prevu_total — la somme dynamique des échéances d'un contact.

L'anti-pattern, c'est stocker une copie « pour éviter la jointure ». La divergence est garantie sans rafraîchisseur, et le rafraîchisseur n'est jamais écrit.

Snapshot

La valeur doit rester figée au moment d'un événement métier. La modifier rétroactivement est une faute fonctionnelle.

Implémentation : la stocker, ne jamais la recalculer. Protection en écriture après création — une CHECK constraint, un trigger qui interdit l'UPDATE, ou une simple discipline documentée.

Dans Rembrandt : inscriptions.tarif_applique — le tarif à la date d'inscription, qui ne bouge pas si le cours est réévalué après.

L'anti-pattern, c'est « recalculer rétroactivement par souci de cohérence ». Cela vole l'historique. Si une réévaluation tarifaire doit s'appliquer, elle s'applique par un nouvel événement — avoir plus nouvelle facture — pas par modification du snapshot existant.

Cache

La valeur est dérivable depuis d'autres données mais coûteuse à calculer à chaque lecture. Tu acceptes de la stocker pour la performance, à condition de déclarer un rafraîchisseur explicite dans le même commit que la colonne.

Implémentation : stocker plus déclarer le mécanisme. Trois mécanismes admis : GENERATED ALWAYS AS (...) pour une dérivation intra-ligne, un trigger SQL nommé trg_* sur les tables qui alimentent la valeur, ou une vue matérialisée mv_* avec REFRESH planifié ou post-bulk.

Aucun cache ne survit sans son rafraîchisseur nommé. Si tu ne peux pas garantir le rafraîchissement, tu retombes sur Live.

Dans Rembrandt : cours.places_prises — cache rafraîchi par trigger sur inscriptions.

La décision à trois questions

Devant chaque nouveau champ qui ressemble à une duplication, trois questions dans l'ordre :

1. La valeur doit-elle évoluer avec les données amont ? Si non — c'est un événement passé figé → Snapshot. Stocker, documenter « snapshot à la création ».
2. Le calcul à la volée est-il acceptable côté performance ? Si oui → Live. Ne pas stocker. Créer une vue v_*.
3. Sinon, c'est un Cache : trigger trg_*, GENERATED ALWAYS AS, ou vue matérialisée mv_* — déclaré dans le même commit que la colonne. Si aucun des trois n'est tenable, repasser à Live et accepter le coût.

Ce que j'ai trouvé dans mon propre schéma

J'ai lancé l'audit une semaine après l'incident Hélène. Quatorze divergences, six catégories. L'archétype, c'est contacts.montant_total — un Live déguisé traité en Snapshot, par négligence. Le fix n'est pas « recalculer périodiquement » — ça rétablit la divergence à la prochaine échéance créée. Le fix, c'est de supprimer la colonne et de router les lectures vers v_reste_du_contact. Migration de catégorie, pas patch. Le problème n'est pas le stockage. C'est que le stockage a été décidé sans déclarer le contrat qui l'aurait gardé vrai.

Une petite discipline de nommage

Toute colonne Cache porte un commentaire SQL au moment de la migration :

COMMENT ON COLUMN cours.places_prises IS 'CACHE: refreshed by trg_inscriptions_sync_places';

Sans ce commentaire, le prochain lecteur du schéma ne peut pas distinguer un Cache géré d'un Live qui a divergé en silence. Quand une revue de migration fait remonter une colonne sans catégorie, on s'arrête, on classe, ou on retire.

Ce que tu peux copier dans ton projet

Deux éléments concrets applicables dès demain :

1. Lance un audit de catégorisation sur les colonnes que tu as cessé de croire. Prends les cinq les plus suspectes au feeling, classe chacune en Live, Snapshot ou Cache. Toute colonne que tu n'arrives pas à placer est un bug déjà livré.
2. Refuse le patch qui rétablit le bug. Quand un Live déguisé en Snapshot diverge, le fix n'est pas « recalculer ponctuellement ». Cela repousse le prochain incident d'exactement un événement amont. Le fix, c'est la migration de catégorie — supprimer la colonne, router les lectures via la vue.

La règle se lit en une ligne : toute valeur stockée qui ressemble à une duplication est Live, Snapshot ou Cache, avec un contrat déclaré dans le même commit.

Coda

Hélène a refermé son cahier à la fin de cette matinée. Elle n'a pas dit « je vous l'avais dit » — ce n'est pas son style ; elle a dit « vous voyez bien que ça ne suffit pas ». C'est le genre de victoire qu'on ne mesure pas, qu'on suppose seulement.

Code compagnon : rembrandt-samples/live-snapshot-cache/ — la checklist de décision à 3 questions et les quatre patterns SQL (vue Live, protection Snapshot, trigger Cache, migration de catégorie), licence MIT.