13. Les données : posséder le sens avant de posséder la table
Pourquoi ce chapitre existe
Les systèmes vivent plus longtemps que la plupart de leurs interfaces et de leurs équipes. Leur mémoire, elle, survit presque toujours : transactions, profils, droits, événements, journaux d'audit et agrégats analytiques. Une décision de données mal explicitée peut donc continuer à produire des effets des années après que son code d'origine a disparu.
Traiter la donnée comme un détail de persistance conduit à des corrections dangereuses : plusieurs écritures concurrentes, changements de sens silencieux, migrations opaques, exports impossibles à expliquer. Une donnée de qualité est un produit : elle a un propriétaire de sens, un cycle de vie, des contrats et des utilisateurs identifiables.
Les idées essentielles
- La propriété d'une donnée est d'abord la responsabilité de définir, préserver et faire évoluer son sens.
- Une source de vérité n'interdit pas les copies ; elle identifie l'autorité qui résout les contradictions.
- Les migrations sont des changements de comportement et de données, pas de simples scripts techniques.
- Le modèle de données doit rendre les états illégitimes difficiles à produire et les transitions importantes observables.
La donnée porte des décisions dans le temps
Une colonne nommée status est rarement auto-explicative. Est-elle l'état actuel, le dernier état reçu, une décision manuelle, un cache, une projection, un statut de facturation ou de livraison ? Qui peut la modifier ? Quels états sont possibles ? Une valeur absente signifie-t-elle « inconnu », « pas encore calculé » ou « non applicable » ? Tant que ces réponses restent implicites, la base devient le lieu où les interprétations divergent.
La propriété de donnée donne une réponse : une équipe ou une frontière est responsable du vocabulaire, des invariants et du chemin d'évolution. D'autres peuvent recevoir une vue, un événement ou une copie adaptée à leur besoin. Ils ne redéfinissent pas silencieusement la même notion dans leur propre stockage.
| Situation | Risque caché | Décision de conception |
|---|---|---|
| Deux systèmes écrivent le même solde | Écrasement, divergence, audit impossible | Désigner l'autorité ; échanger des intentions ou des événements |
| Une valeur est réinterprétée | Historique devenu ambigu | Ajouter un nouveau concept ; migrer explicitement le sens |
| Une copie alimente un écran | Fraîcheur inconnue | Déclarer source, délai acceptable et stratégie de rattrapage |
| Un export devient consommé | Schéma implicite devient contrat | Versionner, identifier les usages et annoncer les évolutions |
Source de vérité et projections
Une source de vérité est l'endroit qui tranche lorsqu'il existe plusieurs représentations. Elle n'est pas forcément la base la plus centrale ni la plus ancienne. Une projection de recherche peut copier le nom d'un produit ; elle n'a pas besoin de devenir propriétaire de la manière dont ce nom est corrigé. En revanche, elle doit savoir comment recevoir, ordonner et rejouer les mises à jour.
Cette distinction protège contre deux extrêmes : centraliser toutes les lectures sur une base unique, ce qui crée un goulot d'étranglement ; ou multiplier des copies sans contrat, ce qui crée des incohérences sans responsable. Les projections sont saines quand leur fraîcheur, leurs erreurs et leur réparation sont des propriétés assumées.
Concevoir les migrations comme des transitions contrôlées
Renommer un champ, séparer une entité ou modifier une unité de calcul affecte toujours des données anciennes et nouvelles. Le chemin robuste suit généralement quatre temps : ajouter une structure compatible ; rendre le code capable de lire les formes nécessaires ; migrer ou alimenter progressivement ; retirer l'ancienne forme après vérification. La stratégie précise dépend du volume, de la sensibilité et du temps de coexistence.
Le point délicat n'est pas le script initial. Il est la capacité à prouver que la migration a le bon sens. Définir avant l'exécution les comptes attendus, les contraintes de cohérence, les échantillons représentatifs et la gestion des exceptions évite de confondre « traitement terminé » et « données correctes ».
Elles ont souvent été produites sous des règles, des versions ou des erreurs qui n'existent plus. Les réécrire selon une logique nouvelle peut falsifier un audit, une facture ou une décision passée. Avant toute transformation, distinguer ce qui doit être corrigé, préservé, annoté ou simplement rendu lisible.
Anti-patterns
Considérer le schéma comme une vérité métier autonome
Une table normalisée ne dit pas à elle seule qui décide d'une valeur, quelle transition est valide ou quelle vue sert quel usage. Le schéma doit être relié aux règles et aux responsabilités qui lui donnent son sens ; sinon les prochaines migrations ne peuvent être évaluées qu'en lisant l'intégralité du code.
Corriger l'historique sans stratégie d'audit
Mettre à jour des lignes peut résoudre un symptôme tout en détruisant la capacité à expliquer ce qui s'est passé. Les domaines sensibles ont souvent besoin d'un événement correctif, d'une trace de migration, d'une date d'effet ou d'une conservation de la valeur d'origine.
Produire des événements après l'écriture sans garantie
Écrire dans une base puis publier un message dans une opération séparée peut laisser le système dans un état où la donnée existe sans que les consommateurs soient prévenus. Ce risque doit être traité par un mécanisme de livraison fiable, une réconciliation ou une conception qui accepte explicitement cette éventualité.
Bonnes pratiques
Documenter le contrat de donnée au plus près de la frontière
Pour les entités importantes, rendre visibles le propriétaire, le sens, les invariants, les accès autorisés, la rétention et les consommateurs. Il ne s'agit pas de décrire chaque colonne, mais de préserver les décisions nécessaires pour modifier sans réinterpréter l'historique.
Prévoir la réparation comme un parcours normal
Toute projection, migration ou intégration doit pouvoir être réconciliée. Cela suppose une manière de détecter les écarts, une source de vérité accessible et une opération de reprise qui soit testée sur un volume réaliste. La réparation n'est pas un aveu d'échec : c'est une propriété d'un système qui reconnaît les défaillances partielles.
Checklist — Une évolution de donnée est-elle maîtrisée ?
- Quel est le sens exact de la donnée, son propriétaire et la source qui tranche en cas de conflit ?
- Quels états, transitions et absences de valeur sont valides ?
- Qui lit, copie ou transforme la donnée, y compris hors du produit principal ?
- Comment les anciennes et nouvelles formes coexistent-elles pendant la migration ?
- Quelles preuves valident le contenu, les comptes et les exceptions après migration ?
- Comment rejouer, réconcilier ou auditer une erreur sans perdre l'historique utile ?
À retenir
La donnée est la mémoire décisionnelle du système. La rendre possédée, explicable et réconciliable protège autant la qualité actuelle que la capacité future de comprendre et de faire évoluer le produit.