Feuille de route des verticales¶
La feuille de route des Vertical Modules décrit la méthode d'industrialisation commune à toutes les familles de produits.
Elle ne constitue pas un calendrier contractuel. Elle définit les critères permettant de faire passer une verticale de l'exploration à une intégration certifiée dans la Platform.
Sommaire¶
- Objectif
- États de maturité
- Méthode d'industrialisation
- Critères de passage
- Verticales de référence
- Verticales candidates
- Règles d'architecture
- Risques à éviter
- Indicateurs attendus
- Voir aussi
Objectif¶
L'architecture de CMonChoix permet d'ajouter progressivement de nouvelles familles de produits sans modifier les invariants du Domain Core.
Chaque verticale apporte uniquement :
- ses attributs métier ;
- ses règles locales de normalisation ;
- ses heuristiques de résolution ;
- ses classifications de conflits ;
- ses stratégies de scoring ;
- ses règles de qualité spécialisées.
Le Domain Core, les Contracts, les Read Services, les Write Services et le Runtime restent génériques.
États de maturité¶
Une verticale doit exposer un état de maturité explicite.
| État | Signification |
|---|---|
| discovery | Périmètre métier en cours d'exploration |
| audit | Règles candidates évaluées en lecture seule |
| simulation | Résultats projetés sans écriture métier |
| validation | KPI et invariants en cours de certification |
| certified | Verticale validée pour intégration contrôlée |
| production | Verticale active dans le runtime certifié |
| suspended | Verticale désactivée à la suite d'une régression ou d'un incident |
Un changement d'état doit être justifié par des preuves reproductibles.
Méthode d'industrialisation¶
Discovery
↓
Périmètre et identifiants
↓
Vertical Module
↓
Read Services
↓
Audits déterministes
↓
Simulations
↓
Validation KPI
↓
Certification
↓
Intégration contrôlée
La mise en production n'est jamais la première étape.
1. Discovery¶
La phase de découverte définit :
- les familles produit couvertes ;
- les identifiants fiables ;
- les variantes significatives ;
- les conflits bloquants ;
- les données sources disponibles ;
- les cas inconnus et ambigus.
2. Module local¶
Le Vertical Module contient uniquement la connaissance propre au domaine.
Il ne doit pas :
- modifier le Domain Core ;
- écrire directement dans les projections ;
- contourner le Resolver ;
- intégrer une règle spécifique à un marchand ;
- appeler le Frontend.
3. Audit¶
Les premières règles sont exécutées en lecture seule.
Les audits doivent mesurer au minimum :
- volume analysé ;
- taux de couverture ;
- taux
resolved; - taux
unknown; - taux
ambiguous; - taux
conflict; - répartition par code de raison ;
- écarts par source ou marchand.
4. Simulation¶
La simulation produit le résultat attendu sans mutation métier implicite.
Elle doit permettre de comparer :
- l'état courant ;
- l'état candidat ;
- les lignes ajoutées, modifiées ou supprimées ;
- les régressions potentielles ;
- les changements de statut ;
- les impacts sur la projection et la qualité.
5. Validation¶
Une verticale n'est certifiée que si :
- ses résultats sont déterministes ;
- les invariants sont respectés ;
- les conflits forts ne sont jamais masqués ;
- les inconnus ne sont pas forcés ;
- les règles sont indépendantes des marchands ;
- les métriques sont stables sur plusieurs exécutions ;
- un rollback est possible ;
- les tests couvrent les cas limites.
Critères de passage¶
Le passage d'un état au suivant exige un rapport de validation.
Audit → Simulation¶
Conditions minimales :
- taxonomie métier stabilisée ;
- règles candidates versionnées ;
- codes de raison définis ;
- échantillon représentatif disponible ;
- résultats d'audit reproductibles.
Simulation → Validation¶
Conditions minimales :
- aucun write implicite ;
- delta complet et explicable ;
- absence de régression bloquante connue ;
- comportement stable par source ;
- cas
unknown,ambiguousetconflictconservés.
Validation → Certified¶
Conditions minimales :
- KPI acceptés ;
- tests automatisés ;
- documentation à jour ;
- commandes CLI documentées ;
- observabilité disponible ;
- plan de rollback validé.
Certified → Production¶
Conditions minimales :
- activation explicite ;
- fenêtre de déploiement contrôlée ;
- surveillance des métriques ;
- capacité de suspension immédiate ;
- absence de mutation Media Quality non approuvée.
Verticales de référence¶
Les verticales Smartphone et Photo servent de références architecturales.
| Verticale | Rôle architectural |
|---|---|
| Smartphone | Première validation complète de l'approche Identifier First et de la résolution de variantes |
| Photo | Confirmation de la séparation entre règles génériques et signatures métier spécialisées |
Leur statut opérationnel exact doit être vérifié dans les rapports runtime et de certification. Cette page ne remplace pas l'état observé en production.
Verticales candidates¶
Les familles suivantes constituent des candidats d'industrialisation, sans ordre contractuel :
| Verticale | Exemples de périmètre | Risques métier principaux |
|---|---|---|
| TV | téléviseurs, technologies d'affichage, diagonales, résolutions | confusion taille/modèle, OLED/QLED, millésimes |
| Gaming | consoles, jeux, accessoires, bundles, éditions | plateforme, édition, région, bundle |
| Printer | imprimantes, consommables, technologies, formats | modèle compatible, cartouche, mono/couleur |
| Mobility | vélos électriques, trottinettes, mobilité urbaine | autonomie, puissance, homologation, variante |
| Toys | jeux, jouets, licences, âges | licence, édition, tranche d'âge, lot |
| Wellness | santé connectée et bien-être | classification, variantes, contraintes réglementaires |
Une verticale candidate ne devient pas automatiquement prioritaire. La priorité dépend notamment :
- du volume de données ;
- de la qualité des identifiants ;
- de la valeur produit ;
- du coût d'audit ;
- du risque de faux rapprochement ;
- de la capacité à construire un corpus de validation.
Règles d'architecture¶
Dépendances¶
La dépendance autorisée reste :
Domain Core / Contracts
↑
Vertical Module
↑
Pipeline et Runtime
Le Domain Core ne dépend jamais d'une verticale.
Extraction vers le Core¶
Une règle locale ne peut être extraite vers le Domain Core que si :
- elle est prouvée sur plusieurs verticales ;
- sa sémantique est réellement générique ;
- elle ne contient aucune notion métier locale ;
- elle possède un contrat stable ;
- sa migration ne crée pas de dépendance circulaire.
Écriture¶
Les Vertical Modules ne doivent pas écrire directement dans les tables de projection.
Les mutations passent par les Write Services certifiés.
Qualité média¶
Media Quality reste audit-first :
- analyse en lecture seule par défaut ;
- preuves et codes de raison obligatoires ;
- aucune suppression ou substitution implicite ;
- mutation uniquement via une commande ou un Write Service explicite ;
- métriques avant et après toute action corrective.
Risques à éviter¶
Une industrialisation doit être suspendue si elle introduit :
- une logique spécifique à un marchand dans la verticale ;
- une résolution forcée des cas inconnus ;
- la disparition de conflits réels ;
- des résultats non déterministes ;
- une mutation directe depuis un audit ;
- une règle transversale non contractualisée ;
- une dépendance entre verticales ;
- une régression silencieuse de projection.
Indicateurs attendus¶
Chaque verticale doit publier des métriques comparables.
| Indicateur | Finalité |
|---|---|
| coverage_rate | Mesurer la part réellement analysable |
| resolved_rate | Mesurer les identités résolues avec preuve suffisante |
| unknown_rate | Préserver les cas insuffisamment documentés |
| ambiguous_rate | Mesurer les candidats non départageables |
| conflict_rate | Mesurer les incompatibilités réelles |
| regression_count | Détecter les changements non souhaités |
| deterministic_replay | Vérifier qu'une même entrée produit le même résultat |
| projection_delta | Quantifier l'impact sur les projections |
| quality_delta | Quantifier l'impact sur les scores et contrôles qualité |
Les seuils d'acceptation appartiennent au rapport de certification de chaque verticale.
Vision¶
La Platform doit pouvoir accueillir de nouvelles verticales sans fragiliser son cœur.
Le Domain Core évolue lentement. Les Vertical Modules évoluent au rythme des métiers, sous contrôle des Contracts, des audits et de la certification.