Remaining Audit¶
Vue d'ensemble¶
Le Remaining Audit est un Read Service dont la mission est d'identifier les anomalies qui subsistent après une phase d'industrialisation.
Contrairement aux audits précédents, son objectif n'est pas de comprendre le fonctionnement global de la Platform, mais d'établir une liste précise des cas qui empêchent une verticale d'être considérée comme validée.
Il intervient généralement en fin de cycle, lorsque les principales règles métier ont déjà été mises en place.
Le Remaining Audit permet de distinguer les problèmes réellement bloquants des écarts résiduels acceptables.
Pourquoi un Remaining Audit ?¶
Lorsqu'une nouvelle verticale est développée, les premiers audits mettent généralement en évidence un grand nombre d'écarts.
Au fil des corrections :
- certaines différences disparaissent ;
- certaines sont volontairement conservées ;
- d'autres apparaissent comme des cas très particuliers.
À ce stade, une question devient centrale :
Que reste-t-il réellement à traiter ?
Le Remaining Audit répond précisément à cette question.
Position dans le cycle industriel¶
Le Remaining Audit intervient après plusieurs cycles d'amélioration.
Audits
│
▼
Simulations
│
▼
Micro-correctifs
│
▼
Remaining Audit
│
▼
Validation finale
Il constitue généralement l'une des dernières étapes avant la rédaction du rapport de validation.
Objectifs¶
Le Remaining Audit poursuit plusieurs objectifs.
Il permet notamment de :
- recenser les cas encore problématiques ;
- mesurer leur impact réel ;
- déterminer leur origine ;
- identifier les corrections encore nécessaires ;
- justifier les écarts volontairement conservés.
Son rôle est d'aider à prendre une décision d'architecture.
Catégorisation des cas restants¶
Toutes les différences restantes n'ont pas la même importance.
Le Remaining Audit distingue généralement plusieurs catégories.
Cas bloquants¶
Ces situations empêchent la validation de la verticale.
Par exemple :
- erreur de résolution importante ;
- projection incorrecte ;
- conflit majeur d'identité.
Ces cas doivent être corrigés avant toute validation.
Cas mineurs¶
Ces anomalies existent mais leur impact reste limité.
Il peut s'agir par exemple :
- d'une information secondaire absente ;
- d'une normalisation incomplète ;
- d'un enrichissement perfectible.
Ces cas peuvent parfois être reportés.
Cas connus¶
Certaines différences sont parfaitement identifiées.
Leur comportement est documenté.
Leur correction est volontairement reportée afin de privilégier des évolutions plus importantes.
Le Remaining Audit permet de conserver leur trace.
Cas hors périmètre¶
Tous les écarts ne relèvent pas nécessairement de la Platform.
Certains peuvent provenir :
- d'informations erronées dans un feed marchand ;
- d'un identifiant absent ;
- d'une ambiguïté impossible à résoudre automatiquement.
Ces situations doivent être documentées mais ne justifient pas toujours une évolution du Domain Core.
Lecture seule¶
Comme tous les Read Services, le Remaining Audit est strictement read-only.
Il peut :
- analyser les données ;
- produire des statistiques ;
- classer les anomalies ;
- générer un rapport.
Il ne doit jamais :
- corriger un produit ;
- modifier une projection ;
- relancer une résolution ;
- écrire dans une table.
Priorisation¶
L'un des principaux intérêts du Remaining Audit est d'aider à prioriser les développements.
Toutes les anomalies n'ont pas vocation à être corrigées immédiatement.
L'audit permet notamment d'identifier :
- les corrections ayant le plus fort impact ;
- les cas suffisamment rares pour être différés ;
- les limites acceptées de la Platform ;
- les évolutions nécessitant une réflexion plus approfondie.
Cette priorisation évite de consacrer du temps à des cas marginaux.
Exemple¶
Après plusieurs semaines d'industrialisation d'une verticale, le rapport peut présenter une synthèse de ce type :
| Catégorie | Nombre |
|---|---|
| Cas bloquants | 4 |
| Cas mineurs | 37 |
| Cas connus | 52 |
| Hors périmètre | 18 |
Une telle répartition permet de décider objectivement si la verticale est prête à être validée.
Bonnes pratiques¶
Le Remaining Audit doit être exécuté avant chaque validation importante.
Les cas recensés doivent :
- être reproductibles ;
- être documentés ;
- être classés ;
- être accompagnés d'une justification.
Lorsqu'un cas est volontairement conservé, la raison de ce choix doit être explicitement indiquée.
Évolution¶
À mesure que la Platform gagnera en maturité, le nombre de cas recensés par le Remaining Audit devrait progressivement diminuer.
Le service restera néanmoins indispensable pour :
- mesurer les progrès réalisés ;
- documenter les limites connues ;
- préparer les futures évolutions ;
- garantir une validation fondée sur des faits.
Il constitue ainsi l'un des derniers garde-fous avant la validation officielle d'une verticale.