Données, migrations et argent

7.1 Le schéma, et comment le changer sans danger

Votre base de données a une structure : des tables, des colonnes, des relations. Une migration est un changement versionné de cette structure, un fichier qui ajoute une table, une colonne, un index. Le motif sûr, à copier : d'abord une étape en lecture seule qui vérifie l'état actuel sans rien écrire (les tables cibles existent-elles déjà, les choses dont je dépends existent-elles). Si l'étape de lecture vous surprend, arrêtez-vous avant d'écrire. Ensuite l'étape d'écriture, enveloppée pour s'appliquer entièrement ou se défaire entièrement, jamais à moitié.

Pour le CTO en vous

verrouillez la base par défaut. Activez la sécurité au niveau des lignes sur chaque table, et laissez uniquement le rôle côté serveur lire et écrire. Le frontend ne touche jamais directement la base ; tout passe par le backend. Une table dont la sécurité est désactivée est une porte que vous aviez oublié d'avoir laissée ouverte.

7.2 L'argent se stocke dans la plus petite unité

Ne stockez jamais de l'argent sous forme de décimal arrondi. Stockez-le dans la plus petite unité, en nombre entier de centimes. Les décimaux dérivent et s'arrondissent de façons qui créent ou perdent de l'argent en silence. Ce n'est pas du pédantisme, c'est la différence entre des comptes qui tombent juste et des comptes qui ne tombent pas juste.

7.3 L'idempotence : le même événement deux fois, un seul effet

Les tiers vous enverront deux fois le même événement : un webhook de paiement est rejoué, une requête se relance. Si « paiement reçu » s'exécute deux fois, vous ne devez pas créditer deux fois. La garde habituelle est une contrainte d'unicité, un identifiant unique sur l'événement, pour que la seconde arrivée soit ignorée en silence. Concevez pour le rejeu, parce que le rejeu arrivera.

7.4 Prouver un changement de données en masse

Quand vous changez des données à l'échelle, vous le prouvez par un invariant, pas par une relecture (Loi 6). Après une mise à jour en masse, vérifiez que les décomptes correspondent et qu'il ne reste rien de l'ancienne forme. Avant et après une grosse migration, prouvez que les lignes qui n'auraient pas dû bouger sont identiques octet pour octet. Et prouvez le résultat sur les vraies données sous forme de delta : ces nombres sont passés de X à Y, et rien n'a atterri là où il ne fallait pas. Un test vert dit « mon code s'est exécuté ». Un delta dit « le monde a changé comme je le voulais ».