Conflict Policy Contract¶
Le contrat Conflict Policy définit la manière dont les conflits d'identité doivent être détectés, évalués et traités au sein de CMonChoix Platform.
Il ne contient aucune règle spécifique à une verticale.
Il définit uniquement le cadre commun que toutes les verticales doivent respecter.
Sommaire¶
- Rôle
- Pourquoi un contrat de conflit ?
- Types de conflits
- Cycle d'évaluation
- Responsabilités
- Ce qui n'appartient pas au contrat
- Priorités
- Statuts
- Garde-fous
- Exemples
- État actuel
- Voir aussi
Rôle¶
Une Conflict Policy définit comment interpréter un conflit entre plusieurs candidats d'identité.
Elle ne décide pas du contenu métier.
Elle définit le processus.
Les Vertical Modules fournissent les règles propres à chaque famille produit.
Pourquoi un contrat ?¶
Toutes les verticales rencontrent des conflits.
Par exemple :
- Smartphone : Pro vs Pro Max ;
- Photo : objectif vs boîtier ;
- TV : OLED vs QLED ;
- Gaming : édition standard vs collector.
Le mécanisme général est identique.
Seules les règles métier changent.
Types de conflits¶
Une Policy peut distinguer plusieurs familles.
Conflit bloquant¶
Deux candidats incompatibles.
La résolution doit être interrompue.
Conflit faible¶
Les candidats sont proches mais nécessitent une vérification.
Bruit marchand¶
Le conflit provient principalement de la qualité des données du marchand.
Enrichissement compatible¶
Les deux candidats décrivent le même produit avec des niveaux de détail différents.
Faux conflit¶
Deux représentations différentes désignent exactement la même identité.
Cycle d'évaluation¶
```text id="4ojgvm" Candidates │ ▼ Conflict Detection │ ▼ Conflict Classification │ ▼ Policy Evaluation │ ▼ Resolution Status
---
# Responsabilités
Le contrat est responsable de :
* classifier les conflits ;
* définir leur gravité ;
* exposer les raisons de la décision ;
* fournir un statut stable.
Il n'est pas responsable de :
* résoudre l'identité ;
* modifier les données ;
* appliquer une règle Smartphone ;
* appliquer une règle Photo.
---
# Ce qui n'appartient pas au contrat
Les règles suivantes restent dans les Vertical Modules :
* stockage Smartphone ;
* couleur Smartphone ;
* monture Photo ;
* focale ;
* ouverture ;
* diagonale TV ;
* bundle Gaming.
Le contrat ne connaît jamais ces notions.
---
# Priorités
Les conflits doivent être évalués dans un ordre cohérent.
Exemple :
1. marque ;
2. famille produit ;
3. modèle ;
4. variante ;
5. attributs secondaires.
Une verticale peut enrichir cette hiérarchie sans modifier le mécanisme général.
---
# Statuts
Une Policy peut produire :
| Statut | Description |
| ------------------ | -------------------------- |
| resolved | Aucun conflit significatif |
| resolved_candidate | Résolution prudente |
| conflict_blocking | Conflit bloquant |
| invalid | Données incohérentes |
| unknown | Cas non classé |
---
# Garde-fous
Une Conflict Policy ne doit jamais :
* masquer un conflit de marque ;
* masquer un conflit de famille produit ;
* transformer une règle locale en règle globale ;
* contourner le Resolver ;
* créer une nouvelle identité.
---
# Exemple Smartphone
Deux candidats :
```text id="72te6h"
iPhone 16 Pro
iPhone 16 Pro Max
Résultat :
```text id="mtdr1q" Conflict Blocking
La décision provient de la policy Smartphone.
Le contrat ne connaît pas "Pro Max".
---
# Exemple Photo
Deux candidats :
```text id="0r86dz"
Canon EF-S 55-250 mm
Canon Zoom
Le contrat détecte un enrichissement compatible.
La décision finale appartient à la policy Photo.
État actuel¶
Les premières policies locales ont été validées sur Smartphone puis Photo.
L'objectif est maintenant de stabiliser un contrat commun capable d'accueillir les futures verticales sans modifier le Domain Core.