Cohérence de la base de données¶

Status: CONTRACT

Rôle¶

La cohérence Database décrit les propriétés qui permettent de relire, comparer et reconstruire un état sans créer de contradiction entre les différentes couches de CMonChoix Platform.

La base de données ne décide pas de la vérité métier. Elle conserve des états produits par le Pipeline, le Domain Core, les Vertical Modules, les projections et les composants techniques.

Une incohérence Database peut donc être :

structurelle ;
temporelle ;
liée à une projection ;
liée à un run incomplet ;
liée à un ancien comportement destructif ;
ou simplement le reflet fidèle d'un résultat métier unknown, ambiguous ou conflict.

Le dernier cas est important : un résultat incertain n'est pas automatiquement une incohérence.

Position dans l'architecture¶

Sources marchandes
      ↓
Stage / normalisation / enrichissement
      ↓
Domain Core + Vertical Modules
      ↓
Canonical Identity / décisions
      ↓
Projection Builder
      ↓
Write Service
      ↓
Persistance
      ↓
Read Services / Frontend / Runtime adapters

La cohérence se vérifie donc entre plusieurs niveaux, pas uniquement à l'intérieur d'une table.

Types de cohérence¶

Cohérence structurelle¶

Les lignes respectent le schéma et les contraintes attendues : types, clés, relations, valeurs interprétables, absence de doublons interdits.

Une table structurellement valide peut malgré tout être métierement incorrecte.

Cohérence métier¶

Les données persistées reflètent correctement une décision métier produite par les composants autorisés.

Le stockage ne tranche jamais lui-même entre plusieurs candidats.

Les statuts canoniques doivent rester visibles :

resolved : décision suffisamment établie selon le contrat ;
unknown : preuves insuffisantes ;
ambiguous : plusieurs interprétations restent plausibles ;
conflict : des preuves incompatibles empêchent une résolution propre.

Une opération de maintenance qui transforme silencieusement ces états en resolved fabrique une nouvelle vérité et viole la frontière Database.

Cohérence de projection¶

Une projection doit être compatible avec l'état amont dont elle est dérivée.

Les anomalies typiques sont :

lignes manquantes ;
lignes dupliquées ;
attributs projetés obsolètes ;
projection partiellement reconstruite ;
génération avec une version de règle différente de celle attendue ;
ordre de rebuild incomplet entre familles dépendantes.

Une projection incohérente se reconstruit via les Builders et Write Services appropriés. Elle ne se « répare » pas par modification SQL manuelle ligne par ligne.

Cohérence temporelle¶

Les éléments comparés doivent représenter un état temporel compatible : même run, snapshot ou génération logique lorsqu'une telle cohérence est requise.

Éviter notamment de mélanger :

une projection ancienne avec des tables amont fraîchement recalculées ;
un run terminé avec un run partiel ;
une baseline contaminée par un ancien comportement destructif avec une nouvelle politique audit-first.

Cohérence technique¶

Les tables et états techniques doivent rester cohérents avec leur rôle : exécution, schéma, locks, caches, historiques, états de queue ou de synchronisation.

Un état technique incohérent peut bloquer un traitement sans rendre les données métier elles-mêmes incorrectes.

Comment diagnostiquer une incohérence¶

Commencer par observer, sans écrire.

Identifier la population exacte : table, verticale, feed, run, projection, identifiants.
Déterminer la famille de données : source, intermédiaire, métier, projection ou technique.
Vérifier si l'écart observé est un vrai défaut ou un statut métier explicite.
Comparer les versions, runs, timestamps et filtres réellement utilisés.
Vérifier la chaîne qui a produit la donnée avant d'envisager une correction.
Exécuter un Read Service ou un audit adapté lorsque disponible.
Si une modification est nécessaire, la simuler ou la borner avant d'appeler un Write Service.
Relancer l'audit après écriture pour confirmer l'effet réel.

Ce qu'une requête SQL prouve — et ne prouve pas¶

Une requête SQL peut prouver par exemple :

qu'une ligne existe ;
qu'une valeur a une certaine forme ;
qu'un compteur vaut N ;
que deux tables divergent ;
qu'un timestamp ou un run diffère.

Elle ne prouve pas à elle seule :

qu'une Canonical Identity est correcte ;
qu'un conflict devrait être résolu ;
qu'une projection doit être modifiée manuellement ;
qu'une règle de verticale appartient au Domain Core ;
qu'une donnée plus récente est nécessairement meilleure.

La base expose des faits persistés ; leur interprétation appartient aux couches métier et applicatives appropriées.

Reconstruction¶

Pour une projection reconstruisible, la démarche sûre est :

observer l'état amont
→ vérifier le périmètre
→ simuler si nécessaire
→ reconstruire via le service explicite
→ contrôler les compteurs
→ réauditer

Pour la famille Product Models documentée actuellement, l'ordre canonique est :

Product Models
→ Variants
→ Specifications
→ Gallery

La disponibilité concrète des services et commandes doit être vérifiée dans le code et le Runtime avant exécution.

Données historiques contaminées¶

Lorsqu'une ancienne implémentation a déjà modifié de façon destructive une projection, cette projection n'est plus une baseline fiable.

C'est notamment vrai pour d'anciens comportements Media Quality ayant pu altérer image_norm.

Dans ce cas :

identifier la source amont saine ;
reconstruire la projection ;
refaire l'audit sur cet état régénéré ;
seulement ensuite comparer l'ancienne et la nouvelle politique.

Corrections autorisées¶

Une incohérence ne justifie pas automatiquement une écriture.

Selon sa cause, la correction peut appartenir :

au Pipeline ;
au Domain Core ;
à un Vertical Module ;
à un Projection Builder ;
à un Write Service ;
à l'infrastructure ou au Runtime pour un état purement technique.

La bonne correction est celle qui traite la cause au bon niveau.

Erreurs fréquentes¶

Corriger directement la projection¶

Cela masque souvent la cause et casse la reconstruction déterministe.

Forcer `resolved`¶

Un unknown, ambiguous ou conflict peut être le bon résultat. Le supprimer pour améliorer un KPI crée un faux succès.

Comparer des populations incompatibles¶

Deux taux identiques ou différents n'ont aucun sens si les dénominateurs, runs ou filtres divergent.

Relancer aveuglément un writer¶

Une seconde exécution peut amplifier un problème si la cause est une mauvaise entrée ou une mauvaise règle. Diagnostiquer avant de rejouer.

Confondre technique et métier¶

Un lock, un cache ou un état de queue défectueux ne se corrige pas dans la Canonical Identity.

Tests attendus¶

Les mécanismes de cohérence importants doivent couvrir :

la réconciliation des compteurs ;
le déterminisme ;
les cas resolved, unknown, ambiguous, conflict ;
les runs incomplets ;
les lignes manquantes ou dupliquées ;
les reconstructions idempotentes ;
l'absence de mutation dans les audits ;
les différences de version ou de snapshot.

Invariants¶

Une donnée persistée n'est pas vraie parce qu'elle existe.
Les statuts d'incertitude métier restent explicites.
Une projection reflète son état amont et reste reconstruisible.
Les comparaisons portent sur des populations compatibles.
Les audits restent read-only.
Une correction traite la cause dans la bonne couche.
Une baseline historiquement altérée est régénérée avant validation.
Toute écriture significative est suivie d'une vérification indépendante.