Remaining Audit¶

Status: CURRENT

À quoi sert cet audit ?¶

Le Remaining Audit est un Read Service de fin de cycle. Il recense et classe ce qui reste réellement à traiter après plusieurs phases d'audit, de simulation et de correction.

Il répond à une question simple :

Qu'est-ce qui empêche encore de considérer le périmètre comme suffisamment maîtrisé ?

Audits initiaux
    ↓
Simulations / corrections validées
    ↓
Nouvel état observé
    ↓
Remaining Audit
    ↓
Cas restants + gravité + justification
    ↓
Rapport de validation

Pourquoi il existe¶

Après plusieurs itérations, les anomalies restantes ne sont pas toutes équivalentes.

Certaines peuvent être bloquantes. D'autres sont des limites connues, des cas rares, des données insuffisantes ou des écarts volontairement acceptés.

Sans Remaining Audit, le risque est double :

continuer à modifier la Platform alors que le résiduel est acceptable ;
déclarer une verticale validée alors que des cas importants restent cachés.

Entrées¶

L'audit doit identifier :

le run, snapshot ou dataset observé ;
la verticale et les feeds concernés ;
les audits et corrections déjà réalisés ;
la version du code ;
les critères de validation ;
les exclusions ;
les familles d'écarts déjà connues.

Le périmètre doit correspondre au périmètre que l'on souhaite réellement valider.

Sorties attendues¶

Chaque cas ou famille restante doit être associé à :

une catégorie ;
un volume ;
un impact ;
une raison ;
des exemples ;
un statut de résolution si pertinent ;
une décision : corriger, accepter, différer ou déclarer hors périmètre ;
une justification explicite.

Les compteurs doivent être réconciliables avec la population analysée.

Catégories recommandées¶

Bloquant¶

Le problème empêche la validation du périmètre.

Exemples :

mauvaise identité canonique sur une population significative ;
conflit masqué ;
projection incorrecte pour un champ essentiel ;
règle entraînant des faux positifs graves.

Mineur¶

L'écart existe mais n'empêche pas le fonctionnement attendu du périmètre.

Il doit rester mesuré et documenté.

Connu et accepté¶

Le comportement est compris, mesuré et volontairement conservé.

L'acceptation doit avoir une justification, pas seulement un commentaire « à voir plus tard ».

Différé¶

Une correction est souhaitable mais n'est pas requise pour la validation actuelle.

Hors périmètre¶

Le cas ne relève pas de l'évolution évaluée ou ne peut pas être résolu avec les données disponibles.

Inconclusif¶

Les preuves disponibles ne permettent pas encore de conclure correctement.

unknown, ambiguous et conflict restent des statuts métier. Ils ne doivent pas être automatiquement assimilés à « bloquant » : leur acceptabilité dépend du contexte et du contrat métier.

Lecture seule¶

Le Remaining Audit peut :

lire les résultats et projections ;
compter et classifier ;
relier des cas à des familles connues ;
générer un rapport.

Il ne doit jamais :

corriger une identité ;
modifier une projection ;
relancer implicitement le Resolver ;
appeler un Write Service ;
changer une classification persistée ;
lancer une synchronisation.

Comment l'utiliser sans fausser la validation¶

Le Remaining Audit ne doit pas devenir un mécanisme permettant de déplacer les problèmes dans des catégories plus favorables.

Avant d'accepter un résiduel, vérifier :

sa population exacte ;
son impact métier ;
la cause réelle ;
la possibilité d'une régression cachée ;
l'existence d'un garde-fou ;
la justification de l'acceptation ou du report.

Un taux global amélioré ne suffit pas si une sous-population importante s'est dégradée.

Ce qu'il ne faut pas en déduire¶

Un faible nombre de cas restants ne prouve pas automatiquement que la verticale est validée.

Quatre conflits graves peuvent être plus importants que plusieurs centaines d'attributs secondaires manquants.

Inversement, la présence de cas unknown ou ambiguous n'est pas nécessairement un échec : le Domain Core doit parfois refuser de forcer une décision insuffisamment étayée.

Relation avec le rapport de validation¶

Le Remaining Audit fournit une partie des preuves du rapport final.

Le rapport de validation doit reprendre :

les catégories restantes ;
leurs volumes ;
les cas bloquants ;
les réserves ;
les limites ;
les décisions de report ou d'acceptation.

Le rapport, et non l'audit seul, porte la décision finale VALIDÉ, VALIDÉ AVEC RÉSERVES, REFUSÉ ou INCONCLUSIF.

Reproductibilité¶

Le même dataset, les mêmes critères et la même version doivent produire le même classement logique.

Toute évolution des seuils ou catégories doit être documentée afin de ne pas comparer deux Remaining Audits avec des règles différentes sans le signaler.

Tests attendus¶

Les tests doivent couvrir :

réconciliation des catégories ;
absence d'écriture ;
stabilité des reason codes ;
cas bloquants, mineurs et hors périmètre ;
conservation explicite de unknown, ambiguous et conflict ;
déterminisme du classement.

Invariants¶

Le Remaining Audit est read-only.
Le périmètre et les critères de validation sont explicites.
Tous les cas restants sont comptés ou explicitement exclus.
La gravité est distincte du statut de résolution.
Une acceptation ou un report possède une justification.
L'audit ne prend pas à lui seul la décision finale de validation.
Aucun cas n'est masqué pour améliorer artificiellement un KPI.