Validation de la verticale Photo¶

Status: CURRENT / GUIDE DE VALIDATION

Cette page est le point d’entrée de transmission pour valider une évolution de la verticale Photo.

Elle ne remplace ni les tests, ni les audits, ni un éventuel rapport de certification versionné au plus près du code. Elle explique surtout comment établir une preuve de validation fiable sans confondre documentation, état Runtime et historique de certification.

Pourquoi cette page existe¶

Une verticale peut être techniquement présente dans le dépôt sans que cela suffise à prouver :

qu’elle est chargée dans le Runtime courant ;
qu’elle est activée sur un flux donné ;
que ses métriques actuelles correspondent à un ancien rapport ;
qu’une campagne historique reste représentative des données présentes.

La validation doit donc toujours être rattachée à une révision, un corpus et des commandes reproductibles.

Ce qu’il faut valider¶

Une évolution Photo doit vérifier au minimum :

la stabilité de la détection de famille produit ;
la normalisation des attributs structurants ;
la conservation des statuts resolved, unknown, ambiguous et conflict ;
l’absence de faux rapprochement entre boîtier, objectif, kit et accessoire ;
le déterminisme des décisions ;
l’absence d’écriture implicite pendant les audits ;
l’impact sur les projections ;
l’absence de régression sur les autres verticales ;
la séparation entre Identity Resolution, Quality et Media Quality.

Séquence de validation recommandée¶

Baseline identifiée
        ↓
Audit read-only
        ↓
Classification des écarts
        ↓
Simulation de la règle candidate
        ↓
Comparaison avant / après
        ↓
Revue des statuts et reason codes
        ↓
Tests automatisés
        ↓
Décision explicite
        ↓
Écriture ou activation éventuelle
        ↓
Vérification post-opération

Un rapport n’autorise pas à lui seul une mutation. Toute écriture reste portée par un Write Service, un pipeline ou une action Runtime explicitement prévue pour cela.

Baseline obligatoire¶

Avant toute comparaison, enregistrer au minimum :

commit Git ou version déployée ;
environnement ;
source ou feed concerné ;
taille du corpus ;
identifiants permettant de rejouer l’échantillon ;
configuration utile ;
version des règles ;
commande et arguments utilisés.

Sans baseline comparable, un delta avant/après n’est pas une preuve fiable.

Métriques minimales¶

Le rapport de validation doit distinguer au minimum :

volume analysé ;
couverture ;
resolved ;
unknown ;
ambiguous ;
conflict ;
répartition des reason codes ;
régressions sur des cas auparavant stables ;
nouveaux faux positifs détectés ;
delta de projection ;
delta éventuel de qualité média.

Un taux de résolution plus élevé n’est pas automatiquement une amélioration. Une baisse artificielle des unknown, ambiguous ou conflict peut révéler une règle devenue trop agressive.

Cas Photo à examiner explicitement¶

La revue manuelle doit inclure des exemples représentatifs tels que :

boîtier seul ;
objectif seul ;
kit boîtier + objectif ;
même modèle avec montures différentes ;
références constructeur abrégées ;
focales proches ;
accessoires ressemblant à des produits principaux ;
titres partiels ;
contradictions entre titre, attributs et référence ;
médias incohérents avec l’identité projetée.

Validation Media Quality¶

Media Quality reste audit-first.

La validation doit distinguer :

identité correcte
≠
projection complète
≠
score de qualité élevé
≠
image principale cohérente

Une image suspecte ne doit pas être supprimée ou remplacée automatiquement faute de candidat fiable. L’absence de preuve suffisante reste un résultat valide et doit apparaître dans le rapport.

Où chercher le rapport technique¶

Des rapports de validation ou certifications historiques peuvent exister dans le dépôt, notamment au plus près du plugin ou du code concerné.

Ne pas figer un ancien chemin comme source CURRENT.

Pour retrouver un rapport dans la révision déployée :

find plugins src docs -type f \
  \( -iname '*photo*validation*' -o -iname '*photo*report*' -o -iname '*photo*certif*' \) \
  -print

Puis vérifier :

le statut du document ;
sa date ou son commit ;
le corpus utilisé ;
les commandes exécutées ;
si les fichiers et entrypoints cités existent encore.

Un rapport historique reste une preuve historique, pas un état Runtime actuel.

Décision finale¶

La conclusion doit être explicite :

acceptée : les preuves sont suffisantes et les régressions maîtrisées ;
acceptée avec réserves : limites documentées et non bloquantes ;
rejetée : régression, faux positifs ou invariant cassé ;
inconclusive : corpus, baseline ou preuves insuffisants.

inconclusive est préférable à une validation artificielle.

Erreurs fréquentes¶

Réutiliser un ancien KPI sans rejouer l’audit¶

Un chiffre historique n’est pas automatiquement valable sur le corpus courant.

Confondre présence du module et activation Runtime¶

La présence d’un fichier ou d’une documentation ne prouve pas qu’il est exécuté dans le contexte observé.

Valider uniquement les cas résolus¶

Les unknown, ambiguous et conflict sont essentiels pour mesurer le conservatisme de la verticale.

Corriger directement une projection¶

La projection est dérivée. Si elle est fausse, diagnostiquer d’abord identité, attributs, règles Photo et Builder avant toute mutation.

Checklist de transmission¶

Avant de déclarer une évolution Photo prête :

[ ] révision et environnement enregistrés ;
[ ] corpus rejouable ;
[ ] audit read-only exécuté ;
[ ] simulation comparée à la baseline ;
[ ] quatre statuts contrôlés ;
[ ] reason codes examinés ;
[ ] cas conflictuels revus ;
[ ] tests automatisés passés ;
[ ] delta de projection mesuré ;
[ ] Media Quality séparé de l’identité ;
[ ] aucune écriture implicite pendant l’audit ;
[ ] décision finale documentée.