Resolution Status Audit¶

Vue d'ensemble¶

Le Resolution Status Audit est un Read Service dédié à l'analyse du résultat produit par le processus de résolution d'identité.

Son objectif est de comprendre dans quel état se trouve chaque résolution, indépendamment de la qualité finale des données ou de la projection générée.

Il permet notamment d'identifier les produits correctement résolus, ceux qui restent ambigus et ceux nécessitant une intervention.

Contrairement aux audits de comparaison, ce service ne cherche pas à comparer deux versions de la Platform.

Il observe exclusivement le résultat du processus de résolution.

Objectif¶

La construction d'une Canonical Product Identity peut aboutir à plusieurs situations.

Certaines résolutions sont immédiates.

D'autres restent ambiguës.

D'autres enfin nécessitent une règle métier complémentaire.

Le Resolution Status Audit permet de répondre à une question fondamentale :

Quel est l'état réel des résolutions produites par la Platform ?

Cette information est indispensable avant toute évolution du Resolver.

Position dans le cycle industriel¶

Le Resolution Status Audit intervient généralement après la construction des identités canoniques.

Resolver
      │
      ▼
Canonical Identity
      │
      ▼
Resolution Status Audit
      │
      ▼
Analyse
      │
      ▼
Décision

Il ne participe jamais à la résolution.

Il observe uniquement son résultat.

États de résolution¶

Chaque identité analysée appartient à un état de résolution.

Les états exacts peuvent évoluer avec la Platform, mais ils répondent généralement aux situations suivantes.

Résolution complète¶

Toutes les informations nécessaires sont disponibles.

L'identité canonique est construite sans ambiguïté.

Aucune intervention supplémentaire n'est nécessaire.

Résolution partielle¶

Une identité a pu être construite, mais certaines informations restent incomplètes.

Par exemple :

identifiant secondaire absent ;
attribut technique manquant ;
faible niveau de confiance.

La résolution est exploitable mais mérite d'être surveillée.

Résolution ambiguë¶

Plusieurs candidats restent compatibles.

Le Resolver n'a pas suffisamment d'informations pour trancher avec certitude.

Cette situation nécessite généralement :

une amélioration des heuristiques ;
une meilleure normalisation ;
ou une règle spécifique de verticale.

Résolution impossible¶

Les informations disponibles sont insuffisantes pour construire une identité fiable.

Le produit reste alors dans un état nécessitant une analyse complémentaire.

Informations analysées¶

Le Resolution Status Audit peut notamment examiner :

les identifiants utilisés ;
les candidats retenus ;
les candidats rejetés ;
le niveau de confiance ;
les conflits détectés ;
les règles ayant conduit à la décision finale.

Ces informations permettent de comprendre le comportement du Resolver.

Lecture seule¶

Comme tous les Read Services, cet audit est strictement read-only.

Il peut :

analyser les identités ;
produire des statistiques ;
classer les résolutions ;
générer un rapport.

Il ne doit jamais :

modifier une Canonical Identity ;
relancer une résolution ;
écrire dans la base de données ;
corriger automatiquement un conflit.

Utilisation pendant l'industrialisation¶

Lorsqu'une nouvelle verticale est développée, cet audit est exécuté à plusieurs reprises.

Une première exécution permet d'établir un état initial.

Les simulations sont ensuite réalisées.

Enfin, une nouvelle exécution mesure les progrès obtenus.

Cette approche permet de démontrer objectivement l'amélioration du processus de résolution.

Exemple¶

Lors de l'industrialisation d'une verticale, le rapport peut montrer que :

État	Nombre
Résolutions complètes	18 420
Résolutions partielles	612
Résolutions ambiguës	143
Résolutions impossibles	19

Cette répartition oriente immédiatement les investigations.

Les efforts peuvent être concentrés sur les situations réellement problématiques.

Bonnes pratiques¶

Le Resolution Status Audit doit :

utiliser des critères de classement stables ;
produire des résultats reproductibles ;
expliquer les causes des résolutions ambiguës ;
rester indépendant des verticales autant que possible ;
être exécuté avant toute modification importante du Resolver.

Évolution¶

À mesure que les heuristiques de résolution évolueront, cet audit continuera de servir de référence pour mesurer leur efficacité.

Il permettra notamment de suivre :

la diminution des ambiguïtés ;
l'amélioration du taux de résolution ;
l'évolution des niveaux de confiance ;
la stabilité du Domain Core.

Il constitue ainsi l'un des principaux outils de suivi du cœur fonctionnel de la Platform.