Aller au contenu

Comparison

Status: CONTRACT

À quoi sert un Comparison Read Service ?

La famille Comparison regroupe les Read Services qui confrontent deux états comparables afin de mesurer précisément ce qui change entre eux.

Une comparaison peut porter par exemple sur :

  • deux versions d'une règle de résolution ;
  • deux projections ;
  • deux snapshots ;
  • deux stratégies de scoring ;
  • un état avant et après une évolution de code ;
  • une implémentation de référence et une implémentation candidate.

L'objectif n'est pas seulement de dire « différent » ou « identique », mais d'expliquer où, combien et pourquoi les résultats divergent.

État A
   ↓
Comparison Read Service
   ↑
État B
   ↓
Différences structurées + métriques + raisons

Pourquoi ce composant existe

Sans contrat commun, deux outils peuvent comparer des populations différentes, utiliser des règles de comptage incompatibles ou masquer des cas non comparables. Le résultat paraît alors précis mais ne permet pas une décision fiable.

Le Comparison Read Service impose donc quatre propriétés :

  1. les deux côtés sont clairement identifiés ;
  2. la population comparée est la même ou la différence de périmètre est explicitement comptée ;
  3. les écarts sont classés avec des raisons stables ;
  4. aucun état n'est modifié pendant la comparaison.

Position dans CMonChoix

Une comparaison intervient généralement après un audit ou une simulation :

Audit / état de référence
          ↓
Simulation / nouvel état calculé
          ↓
Comparison Read Service
          ↓
Écarts et KPI réconciliés
          ↓
Décision humaine ou validation

Elle peut aussi comparer directement deux projections persistées, deux runs ou deux sorties sérialisées.

Entrées

Une comparaison reproductible doit identifier au minimum :

  • la source A ;
  • la source B ;
  • le run, snapshot ou dataset de chaque côté ;
  • les filtres appliqués ;
  • la clé utilisée pour aligner les éléments ;
  • la version de la règle ou du composant comparé ;
  • les exclusions et cas non comparables.

La clé de rapprochement doit être stable. Un ordre de ligne SQL ou l'ordre d'arrivée des feeds ne doit jamais servir implicitement de clé de comparaison.

Sorties attendues

Le résultat doit être sérialisable et contenir au minimum :

  • la description des deux côtés comparés ;
  • le nombre total d'éléments considérés ;
  • le nombre d'éléments identiques ;
  • le nombre d'éléments différents ;
  • le nombre d'éléments présents uniquement d'un côté ;
  • le nombre de cas non comparables ;
  • les familles d'écarts ;
  • les reason codes ;
  • des échantillons représentatifs ;
  • les avertissements ;
  • un statut final.

Exemple de réconciliation :

total
= identical
+ different
+ only_in_a
+ only_in_b
+ not_comparable

La formule exacte dépend du service, mais aucune population ne doit disparaître silencieusement.

Types de différences

Une comparaison utile sépare les écarts au lieu de les fusionner dans un compteur global.

Exemples :

  • changement de status ;
  • candidat retenu différent ;
  • passage de unknown à resolved ;
  • apparition ou disparition d'un conflict ;
  • attribut modifié ;
  • projection absente ;
  • score différent ;
  • niveau de confiance différent ;
  • ordre de candidats différent ;
  • donnée présente d'un seul côté.

Les statuts unknown, ambiguous et conflict sont des résultats métier valides. Ils ne doivent pas être classés automatiquement comme erreurs techniques.

Lecture seule

Un Comparison Read Service ne doit jamais :

  • écrire en base ;
  • reconstruire implicitement une projection persistée ;
  • appeler un Write Service ;
  • modifier les données afin de rendre les deux côtés comparables ;
  • corriger automatiquement une différence ;
  • déclencher un worker, un cron ou une synchronisation.

Si une reconstruction est nécessaire, elle doit être exécutée séparément et explicitement avant la comparaison.

Comparer des populations réellement compatibles

Une comparaison n'est valide que si les deux côtés représentent le même périmètre logique.

Avant de conclure, vérifier notamment :

  • mêmes verticales ;
  • mêmes feeds ou marchands lorsque cela est requis ;
  • mêmes filtres ;
  • même population temporelle ;
  • mêmes règles d'éligibilité ;
  • mêmes unités de comptage ;
  • données de départ non contaminées par une mutation historique.

Comparer deux pourcentages calculés sur des dénominateurs différents peut donner une conclusion fausse même si chaque pourcentage est techniquement correct.

Relation avec Audit et Simulation

Un Audit décrit l'état observé.

Une Simulation calcule un état hypothétique sans écrire.

Une Comparison mesure les différences entre deux états ou deux résultats.

Ces responsabilités peuvent être enchaînées mais ne doivent pas être fusionnées :

Audit = qu'est-ce qui existe ?
Simulation = que se passerait-il ?
Comparison = qu'est-ce qui change entre A et B ?

Déterminisme

À entrées, filtres et version identiques, une comparaison doit produire le même résultat logique.

Pour cela :

  • utiliser des clés de rapprochement stables ;
  • trier explicitement les sorties ;
  • rendre les seuils explicites ;
  • ne pas dépendre d'un cache non identifié ;
  • versionner les règles de classification d'écarts.

Diagnostic

Lorsqu'une comparaison produit un résultat surprenant, vérifier dans cet ordre :

  1. les deux datasets représentent-ils réellement la même population ?
  2. les clés de rapprochement sont-elles identiques et stables ?
  3. des exclusions diffèrent-elles entre A et B ?
  4. l'une des projections est-elle plus ancienne que l'autre ?
  5. la règle ou la configuration diffère-t-elle en plus du code testé ?
  6. les cas unknown, ambiguous et conflict sont-ils comptés de la même façon ?
  7. une ancienne mutation a-t-elle contaminé l'un des états ?

Il faut corriger le protocole de comparaison avant de corriger le produit lorsqu'un problème provient du périmètre ou du dataset.

Tests attendus

Un Comparison Read Service important doit être couvert par :

  • tests de rapprochement des deux côtés ;
  • tests de réconciliation des compteurs ;
  • tests de déterminisme ;
  • tests sur éléments absents d'un côté ;
  • tests sur unknown, ambiguous et conflict ;
  • tests garantissant l'absence d'écriture ;
  • tests de stabilité des reason codes ;
  • un cas réel ou une fixture représentative.

Invariants

  1. Une comparaison est read-only.
  2. Les deux côtés et leurs périmètres sont identifiés explicitement.
  3. Les éléments sont rapprochés avec une clé stable.
  4. Tous les éléments sont comptés ou explicitement exclus.
  5. Les différences sont classées et explicables.
  6. Les statuts d'incertitude restent visibles.
  7. Une comparaison ne corrige jamais ce qu'elle observe.
  8. Une population incompatible rend la conclusion invalide.

Voir aussi