Business Repairs¶

Status: TARGET

Rôle¶

Les Business Repairs désignent les Write Services destinés à corriger de manière contrôlée des données métier déjà présentes dans CMonChoix.

Ils interviennent après qu'un problème a été observé, expliqué, simulé et validé. Ils ne constituent pas un mécanisme normal du Pipeline et ne doivent jamais servir de raccourci pour contourner une règle métier mal placée.

Audit read-only
    ↓
Diagnostic
    ↓
Simulation / Virtual Patch
    ↓
Validation explicite
    ↓
Business Repair
    ↓
Nouvel audit de vérification

Cette page décrit une capacité cible et ses garde-fous. Elle ne prouve pas qu'un service générique nommé Business Repair ou une commande CLI correspondante soit actuellement actif dans le Runtime.

Pourquoi cette capacité existe¶

Certaines évolutions corrigent correctement le comportement futur mais laissent des données historiques dans un état devenu obsolète.

Un Business Repair peut alors être nécessaire pour réaligner un périmètre existant avec une règle désormais validée.

Exemples de situations légitimes :

une ancienne normalisation a produit une valeur incorrecte ;
une règle de verticale corrigée doit être appliquée à un historique ciblé ;
une projection dérivée doit être reconstruite après correction de sa source ;
une population identifiée par audit doit être réalignée sans rejouer tout le système ;
une incohérence métier connue doit être réparée avec une stratégie bornée et traçable.

Ce qu'un Business Repair n'est pas¶

Un Business Repair n'est pas :

un Audit ;
une Simulation ;
un Resolver ;
un Pipeline alternatif ;
une règle métier permanente ;
un script SQL ad hoc exécuté directement en production ;
une correction silencieuse déclenchée au chargement d'un bootstrap.

S'il faut exécuter régulièrement la même réparation, il faut rechercher la cause en amont dans le Pipeline, le Domain Core, un Vertical Module ou la couche de projection.

Entrées obligatoires¶

Avant toute écriture, l'opération doit identifier explicitement :

la population cible ;
la règle ou décision ayant autorisé la réparation ;
le run, feed, verticale, identifiant ou filtre utilisé ;
l'état attendu avant intervention ;
l'état attendu après intervention ;
les exclusions ;
la stratégie de reprise ;
la stratégie de rollback ou la justification de son absence.

Une population décrite comme « tous les produits concernés » sans critère reproductible n'est pas un périmètre acceptable.

Sortie attendue¶

Le résultat doit être structuré et réconciliable, par exemple :

examined
= changed
+ unchanged
+ skipped
+ failed

Le rapport doit exposer au minimum :

nombre de lignes examinées ;
nombre de lignes réellement modifiées ;
lignes déjà conformes ;
lignes ignorées et raisons ;
échecs et raisons ;
identifiant du run ou de l'opération ;
version du code ;
avertissements ;
durée ;
éléments nécessaires au rejeu ou à la vérification.

Séparation décision / écriture¶

Le Business Repair applique une décision déjà validée.

Il ne doit jamais :

décider qu'une identité est correcte ;
inventer une nouvelle règle de rapprochement ;
masquer un conflict ;
transformer un unknown ou un ambiguous en valeur certaine sans preuve ;
recalculer implicitement une politique métier différente de celle validée.

La règle doit vivre dans la couche qui en est propriétaire. Le Business Repair ne fait qu'appliquer cette règle sur un historique borné.

Périmètre minimal¶

Une réparation doit viser le plus petit périmètre permettant d'atteindre l'objectif.

Exemples de filtres acceptables :

une verticale ;
un feed ;
une famille produit ;
un run_id ;
une liste d'identifiants issue d'un audit ;
une plage ou un batch explicitement borné.

Une réparation globale doit être considérée comme une opération à haut risque et justifiée séparément.

Dry-run et simulation¶

Avant une mutation large, il faut disposer d'un dry-run ou d'une simulation équivalente lorsque cela est techniquement possible.

Le dry-run doit produire les mêmes décisions de ciblage que l'écriture réelle, mais sans effet persistant.

Il doit permettre de mesurer :

le nombre de lignes qui seraient modifiées ;
les raisons d'inclusion et d'exclusion ;
les cas ambigus ;
les erreurs prévisibles ;
l'impact sur les KPI concernés.

Un simple drapeau --dry-run n'est pas une preuve suffisante : des tests doivent vérifier qu'aucune écriture n'a lieu.

Idempotence et reprise¶

Une réparation rejouée avec les mêmes paramètres ne doit pas dupliquer les effets ni dégrader les données déjà conformes.

Le service doit distinguer :

changed : modification réellement appliquée ;
unchanged : état déjà conforme ;
skipped : volontairement ignoré ;
failed : traitement impossible ou erreur technique.

En cas d'interruption, la reprise doit être possible à partir d'un run, batch, offset ou autre identifiant stable sans recommencer aveuglément toute l'opération.

Rollback¶

Avant l'écriture, déterminer comment revenir à l'état précédent.

Selon l'opération, cela peut reposer sur :

une sauvegarde vérifiée ;
une table ou un snapshot de référence ;
une reconstruction déterministe ;
un journal avant/après ;
une opération inverse explicitement testée.

Si aucun rollback simple n'existe, ce risque doit être écrit dans le plan d'intervention avant exécution.

Relation avec les projections¶

Une projection est une donnée dérivée. Si la vérité source est corrigée, la bonne action peut être une reconstruction de projection plutôt qu'une modification directe de chaque ligne dérivée.

Le futur mainteneur doit donc déterminer d'abord quelle couche possède la vérité avant de choisir la réparation.

Modifier directement une projection alors que sa source reste fausse ne résout pas le problème : la prochaine reconstruction réintroduira l'écart.

Relation avec le Domain Core et les Vertical Modules¶

Le Domain Core porte les règles génériques.

Les Vertical Modules portent les règles propres à une famille de produits.

Un Business Repair ne doit pas déplacer une règle verticale dans le Core sous prétexte qu'elle facilite une correction ponctuelle.

Inversement, une règle réellement générique ne doit pas être dupliquée dans plusieurs réparations verticales.

Procédure d'intervention sûre¶

Pour une réparation sensible :

exécuter ou relire l'Audit ayant identifié le problème ;
confirmer le périmètre exact ;
vérifier la couche propriétaire de la vérité ;
exécuter la Simulation ou le Virtual Patch ;
vérifier les compteurs et les cas unknown, ambiguous et conflict ;
préparer sauvegarde, reprise et rollback ;
appliquer sur un périmètre réduit ;
comparer avant/après ;
élargir seulement si le comportement est conforme ;
relancer l'Audit de validation.

Erreurs fréquentes¶

Corriger la projection au lieu de la source¶

La donnée semble correcte immédiatement, puis redevient incorrecte au prochain rebuild.

Mélanger audit et écriture¶

Une commande censée diagnostiquer modifie également les données. La baseline devient alors impossible à reproduire.

Élargir trop tôt le périmètre¶

Un correctif valide sur quelques cas est appliqué globalement sans mesurer les sous-populations atypiques.

Écraser l'incertitude¶

Un repair transforme des cas unknown, ambiguous ou conflict en valeurs arbitraires afin d'améliorer un KPI. C'est une violation du contrat métier.

Confondre capacité cible et Runtime courant¶

La présence de cette page ne signifie pas qu'une commande ou une classe générique de Business Repair existe actuellement. Toujours vérifier le code et l'aide CLI avant toute exécution.

Tests attendus¶

Un Business Repair important doit être couvert au minimum par :

test du ciblage ;
test de non-écriture en dry-run ;
test d'idempotence ;
test de reprise ;
test de réconciliation des compteurs ;
test des exclusions ;
test de conservation des états unknown, ambiguous et conflict ;
test de rollback ou de reconstruction lorsque cette capacité est annoncée ;
test garantissant que la règle métier reste dans sa couche propriétaire.

Invariants¶

Un Business Repair écrit explicitement et jamais implicitement.
Il applique une décision déjà validée.
Son périmètre est borné et reproductible.
Les écritures sont mesurables et traçables.
Le rejeu est idempotent ou son absence d'idempotence est explicitement interdite.
Les états d'incertitude ne sont jamais masqués pour améliorer un KPI.
La source de vérité est corrigée avant les données dérivées lorsque cela s'applique.
Une réparation récurrente signale probablement une règle mal placée en amont.
La présence de la documentation ne prouve pas l'existence d'un entrypoint Runtime actif.