Identité canonique¶

L’identité canonique est la référence produit de confiance utilisée par CMonChoix pour reconnaître un même produit malgré les différences de titres, d’identifiants ou de présentation entre marchands.

Statut¶

Concept normatif d’architecture.

Pourquoi cette notion est essentielle¶

Deux marchands peuvent décrire exactement le même produit de manière différente.

Exemple :

Marchand A : Samsung Galaxy S26 256GB Black
Marchand B : Galaxy S26 Noir 256 Go - Samsung

Le site ne doit pas créer deux produits uniquement parce que les textes sont différents.

À l’inverse, il ne doit pas fusionner deux produits différents simplement parce qu’ils partagent un nom proche ou un identifiant incomplet.

L’identité canonique sert donc à répondre à une question centrale :

« De quel produit réel parle-t-on ? »

Ce qu’est une identité canonique¶

Une identité canonique est la représentation métier autoritative d’un produit après résolution de son identité.

Elle doit rester indépendante :

du marchand ;
du feed utilisé ;
de l’identifiant interne du marchand ;
d’un EAN ou GTIN pris isolément ;
d’un titre commercial ;
de WordPress ;
du frontend ;
du format de stockage d’une projection.

Les informations marchandes sont des preuves. Elles peuvent contribuer à la décision, mais elles ne deviennent pas automatiquement la vérité canonique.

Comment l’identité est déterminée¶

Le processus logique est le suivant :

Observations marchandes
        ↓
Preuves + identifiants
        ↓
Candidats possibles
        ↓
Resolver + Conflict Policy
        ↓
Résultat de résolution
        ↓
resolved / unknown / ambiguous / conflict

Resolver¶

Le Resolver est le composant chargé de départager les candidats possibles en fonction des preuves disponibles.

Conflict Policy¶

La Conflict Policy définit les situations dans lesquelles des preuves incompatibles doivent empêcher une résolution forcée.

Les quatre états à connaître¶

État	Signification
`resolved`	Les preuves sont suffisantes pour choisir une identité canonique.
`unknown`	Les informations disponibles sont insuffisantes.
`ambiguous`	Plusieurs identités restent plausibles.
`conflict`	Des preuves se contredisent explicitement.

Seul resolved doit permettre d’attacher une identité canonique avec suffisamment de confiance.

Les autres états sont des résultats légitimes. Ils ne doivent pas être transformés silencieusement en succès.

Exemple concret de mauvais comportement¶

Imaginons qu’un produit possède :

un titre ressemblant fortement à un Galaxy S26 ;
mais un identifiant ou une capacité incompatible avec ce modèle.

Le mauvais réflexe serait de dire :

« Le titre ressemble assez, on va quand même le classer comme Galaxy S26. »

La bonne architecture doit au contraire conserver le conflit, l’exposer et empêcher la création d’une certitude artificielle.

Que contient une identité canonique ?¶

Elle contient uniquement des informations métier stables.

Selon la famille de produits, cela peut inclure :

marque ;
famille produit ;
série ;
modèle ;
génération ;
type de produit canonique ;
référence normalisée stable.

Les détails exacts dépendent des contrats du domaine et de la verticale concernée.

Les informations spécifiques à un marchand n’y ont pas leur place.

Différence entre identité et variante¶

Une variante est une version commerciale ou technique d’un même produit canonique.

Exemples :

couleur ;
stockage ;
mémoire ;
configuration réseau ;
finition ;
taille.

Une variante ne doit pas créer automatiquement une nouvelle identité canonique.

Exemple smartphone¶

Identité canonique
- marque : Apple
- famille : iPhone
- modèle : iPhone 16 Pro

Variante
- stockage : 256 Go
- couleur : Titane noir

Ici, la couleur et le stockage décrivent une variante du produit, pas nécessairement une nouvelle identité produit indépendante.

Exemple télévision¶

Identité canonique
- marque : Samsung
- famille : Neo QLED
- modèle : QN90D

Variante
- taille : 65 pouces

La frontière exacte entre identité et variante dépend toujours des règles validées de la verticale concernée.

Que produit un résultat de résolution ?¶

Un résultat sérieux devrait exposer, selon le contrat :

le statut ;
l’identité retenue si resolved ;
le niveau de confiance ;
les codes de raison ;
les preuves utilisées ;
les conflits détectés ;
la version du Resolver et des règles ;
des métadonnées d’audit.

Pourquoi autant d’informations ? Parce qu’une personne qui reprend le projet doit pouvoir comprendre pourquoi une identité a été retenue.

Relation avec les projections¶

Une projection est une représentation destinée à un usage précis : affichage frontend, SEO, comparaison, recherche, export ou audit.

Elle dérive de la vérité métier déjà résolue.

Une projection ne doit jamais :

créer une nouvelle identité ;
réparer silencieusement une identité ;
cacher un état unknown, ambiguous ou conflict sans politique explicite ;
devenir la source autoritative de l’identité.

Elle doit rester reconstruisible à partir des sources amont certifiées.

Relation avec les Vertical Modules¶

Les Vertical Modules apportent les règles spécifiques nécessaires pour interpréter les preuves.

Exemples :

Smartphone : modèle, stockage, génération ;
Photo : monture, focale, type d’objectif ;
TV : série, taille, technologie.

Une verticale peut aider le Resolver, mais elle ne doit pas :

modifier directement l’identité canonique ;
contourner le Resolver ;
forcer une résolution malgré un conflit bloquant ;
créer une seconde source de vérité produit.

Relation avec Media Quality¶

Media Quality vérifie la cohérence des images et autres médias avec les données produit déjà résolues.

Ce n’est pas une source d’identité.

Une image incohérente peut révéler un problème de données, mais elle ne doit pas, à elle seule, autoriser une modification de l’identité canonique.

Media Quality doit donc :

consommer l’identité et les variantes autoritatives ;
produire des preuves et raisons d’audit ;
rester non destructif par défaut ;
ne jamais réécrire directement l’identité ;
faire passer toute correction approuvée par une frontière d’écriture explicite.

Ce dont l’identité canonique n’est pas responsable¶

Elle ne possède pas :

les prix ;
les promotions ;
le stock ;
les offres marchandes ;
le rendu frontend ;
les décisions Media Quality ;
l’orchestration du Pipeline ;
les écritures en base.

Cette séparation est importante : reconnaître un produit et connaître son prix sont deux responsabilités différentes.

Règles interdites¶

Il est interdit de :

recalculer l’identité dans le frontend ;
contourner le Resolver ;
transformer unknown, ambiguous ou conflict en resolved par défaut ;
créer plusieurs identités autoritatives pour le même produit sans décision explicite de séparation ;
intégrer des champs marchands spécifiques dans l’identité canonique ;
placer des règles verticales dans le cœur générique ;
modifier l’identité directement depuis une verticale ;
modifier l’identité depuis Media Quality ou un Read Service ;
considérer une projection comme source de vérité d’identité.

Ce qu’il faut surveiller¶

La résolution d’identité devrait exposer des métriques telles que :

observations traitées ;
candidats générés ;
resolved ;
unknown ;
ambiguous ;
conflict ;
doublons détectés ;
version du Resolver ;
version des règles ;
nombre d’écritures ;
écritures ignorées ;
erreurs.

Des codes de raison stables permettent ensuite de comparer deux versions du moteur et de détecter une régression.

Comment diagnostiquer un mauvais regroupement produit¶

Si deux offres semblent mal regroupées ou séparées à tort :

ne pas corriger directement la projection ou le frontend ;
récupérer les observations marchandes concernées ;
vérifier les identifiants et preuves normalisées ;
observer les candidats générés ;
regarder le statut retourné par le Resolver ;
examiner les codes de raison et éventuels conflits ;
identifier si le problème vient de la normalisation, de la verticale, du Resolver ou d’une donnée source ;
simuler la correction ;
seulement après validation, appliquer une écriture via la frontière prévue ;
reconstruire ou vérifier les projections si nécessaire.

Cette méthode évite de corriger uniquement le symptôme visible.

Ce que les tests doivent protéger¶

Les tests doivent notamment couvrir :

résolution déterministe ;
maintien explicite des états non résolus ;
conservation des conflits ;
prévention des doublons ;
règles de variantes ;
reconstruction des projections ;
isolation des verticales ;
absence de mutation des Read Services ;
absence de mutation d’identité par Media Quality ;
propriété explicite des écritures par Write Service ;
compatibilité pendant les migrations.

Pour la personne qui reprend le projet¶

Si vous ne retenez que trois choses :

un titre marchand n’est pas une identité produit ;
une incertitude doit rester une incertitude tant qu’elle n’est pas résolue par des preuves ;
le frontend et les projections consomment l’identité, ils ne doivent pas la fabriquer.

Avant toute correction manuelle de regroupement produit, remonter jusqu’au processus de résolution plutôt que modifier la dernière couche visible.

Documents associés¶

Évolution future¶

Le modèle d’identité canonique peut évoluer tant que la stabilité, le déterminisme, la traçabilité et les frontières architecturales restent préservés.

Toute nouvelle capacité métier doit consommer cette identité commune plutôt que créer son propre système parallèle.