Audits¶
Vue d'ensemble¶
Les audits constituent la principale famille de Read Services de la Platform.
Ils permettent d'analyser le comportement réel des traitements sans jamais modifier les données.
Dans CMonChoix, un audit n'est pas un simple outil de diagnostic ponctuel. Il fait partie intégrante du processus de développement et accompagne chaque évolution importante de la Platform.
Avant toute modification du Domain Core, d'un Vertical Module ou du Pipeline, un ou plusieurs audits sont réalisés afin de comprendre précisément l'origine du problème.
Philosophie¶
Un audit répond toujours à une question précise.
Par exemple :
- Pourquoi deux offres n'ont-elles pas été regroupées ?
- Pourquoi plusieurs identités canoniques existent-elles pour un même produit ?
- Pourquoi un score de confiance est-il faible ?
- Pourquoi une projection est-elle incomplète ?
- Pourquoi une verticale présente-t-elle davantage de conflits qu'une autre ?
Un audit ne cherche jamais à corriger ces situations.
Son rôle consiste exclusivement à les expliquer.
Une démarche scientifique¶
Les audits suivent toujours la même méthode.
Observation
│
▼
Mesure
│
▼
Analyse
│
▼
Compréhension
│
▼
Documentation
Une correction n'intervient qu'après cette phase d'analyse.
Cette approche évite les modifications réalisées par intuition ou par essais successifs.
Lecture seule¶
Tous les audits sont strictement read-only.
Ils peuvent :
- lire les données ;
- produire des statistiques ;
- comparer des résultats ;
- calculer des indicateurs ;
- générer des rapports.
Ils ne doivent jamais :
- modifier une table ;
- mettre à jour une projection ;
- corriger une identité ;
- exécuter un Write Service.
Cette règle est absolue.
Types d'audits¶
La Platform utilise plusieurs catégories d'audits.
Audit de comparaison¶
Ce type d'audit compare deux états différents de la Platform.
Il peut notamment comparer :
- Legacy contre Platform ;
- avant et après un correctif ;
- deux versions d'un algorithme ;
- deux stratégies de résolution.
L'objectif est de mesurer précisément les écarts.
Audit de résolution¶
Ces audits permettent de comprendre comment une identité canonique a été construite.
Ils analysent notamment :
- les candidats retenus ;
- les candidats rejetés ;
- les conflits détectés ;
- les identifiants utilisés ;
- les règles appliquées.
Ils sont particulièrement utiles lors de l'évolution du Resolver.
Audit de qualité¶
Les audits de qualité mesurent la qualité des informations produites par la Platform.
Ils peuvent mettre en évidence :
- des données incomplètes ;
- des incohérences ;
- des identifiants manquants ;
- des projections partielles.
Ils s'appuient principalement sur les indicateurs du module Quality.
Audit de validation¶
Ces audits interviennent généralement à la fin d'un cycle de développement.
Ils vérifient notamment :
- que les objectifs sont atteints ;
- que les KPI sont conformes ;
- qu'aucune régression n'est apparue ;
- que les hypothèses formulées sont validées.
Ils servent de base au rapport de validation.
Résultats attendus¶
Un audit doit produire un résultat exploitable.
Il doit permettre de répondre clairement à la question qui a motivé son exécution.
Un bon audit ne se contente pas d'afficher des données.
Il explique ce qui se passe.
Il met en évidence les anomalies.
Il permet de prendre une décision.
Qualités d'un bon audit¶
Un audit efficace possède plusieurs caractéristiques.
Il est :
- reproductible ;
- déterministe ;
- documenté ;
- rapide à exécuter ;
- facile à interpréter.
Les résultats doivent être identiques lorsque les données d'entrée sont identiques.
Intégration dans le cycle industriel¶
Dans CMonChoix, les audits interviennent tout au long du cycle d'industrialisation.
Analyse initiale
│
▼
Audits
│
▼
Simulation
│
▼
Validation
│
▼
Micro-correctif éventuel
│
▼
Nouvelle validation
Cette approche permet de limiter fortement les régressions.
Exemples dans la Platform¶
Les audits sont largement utilisés lors de l'industrialisation d'une nouvelle verticale.
Parmi les plus courants :
- comparaison Legacy / Platform ;
- analyse des conflits d'identité ;
- audit des familles restantes ;
- audit des candidats ;
- audit des différences ;
- audit des projections ;
- audit des KPI.
Ces outils permettent d'expliquer précisément les écarts observés avant toute modification du code.
Évolution¶
Au fil des évolutions de la Platform, de nouveaux audits pourront être ajoutés.
Ils devront toutefois respecter plusieurs principes :
- répondre à une problématique clairement identifiée ;
- rester strictement read-only ;
- produire des résultats reproductibles ;
- être documentés ;
- pouvoir être réutilisés dans plusieurs contextes.
L'objectif n'est pas de multiplier les outils, mais de construire une bibliothèque cohérente d'analyses réutilisables.