Vision de la plateforme¶

Status: NORMATIVE / TARGET

Mission architecturale¶

CMonChoix est une plateforme indépendante capable d'ingérer les observations de nombreux marchands, de les normaliser, de résoudre l'identité des produits et variantes, d'évaluer leur qualité, de construire des projections rapides et de distribuer ces résultats à plusieurs interfaces.

La plateforme doit pouvoir évoluer de quelques marchands vers plusieurs dizaines puis plusieurs centaines sans changer ses principes fondamentaux.

La vérité métier doit rester indépendante :

des marchands ;
de WordPress ;
du frontend ;
de la base de données concrète ;
du cache ;
du moteur de recherche ;
du nombre de workers ;
de la topologie VPS.

North Star¶

La destination est simple :

Sources marchandes
      ↓
Source Adapters
      ↓
Ingestion / staging
      ↓
Normalisation canonique
      ↓
Classification / Vertical knowledge
      ↓
Identity resolution / variants
      ↓
Quality / business decisions
      ↓
Durable state
      ↓
Projections / search projections
      ↓
Read Services
      ↓
WordPress / API / exports / autres frontends

Le Runtime orchestre cette chaîne. Il ne crée pas la vérité métier.

WordPress¶

WordPress est exclusivement une couche CMS, SEO et présentation publique.

WordPress -> src/ : autorisé
src/ -> WordPress : interdit

La plateforme doit pouvoir continuer à importer, normaliser, classifier, résoudre, projeter, synchroniser et auditer si WordPress n'est pas installé.

Voir Frontière WordPress.

Un modèle multi-marchands, pas N moteurs marchands¶

Un marchand peut avoir :

une configuration ;
des credentials ;
une source ;
un adapter ;
un mapping de champs source ;
des capacités ou contraintes spécifiques.

Après cette frontière, les observations doivent converger vers le pipeline canonique commun.

La cible n'est pas :

acer-engine
samsung-engine
darty-engine
merchant-x-engine

La cible est :

Acer adapter -----\
Samsung adapter ---+--> Canonical Platform
Darty adapter -----/

Une exception marchande légitime doit être confinée et explicable. Elle ne doit pas contaminer les règles génériques.

Les données marchands sont des observations¶

Un titre, un EAN, une catégorie, un prix ou un attribut fourni par un marchand est une observation de source.

Une observation n'est pas automatiquement une décision canonique.

La plateforme conserve les preuves puis décide selon des contrats déterministes. Lorsque les preuves sont insuffisantes ou contradictoires, elle conserve explicitement l'incertitude.

Les états importants incluent notamment :

resolved ;
unknown ;
ambiguous ;
conflict.

Une seule vérité métier¶

Une décision importante possède un propriétaire autoritatif unique.

Une copie technique peut exister pour accélérer la lecture, le cache ou la recherche, mais elle reste reconstructible.

Le frontend, WordPress, Redis ou un index de recherche ne doivent pas devenir une deuxième autorité métier.

Projection-first pour le trafic public¶

La plateforme dépense le coût de calcul lorsque les données changent plutôt qu'à chaque consultation.

WRITE SIDE
observations -> décisions -> projections

READ SIDE
projection -> cache -> page

Une page publique ne doit pas refaire la classification, l'identité, la qualité ou un agrégat coûteux pour pouvoir s'afficher.

Cette stratégie permet de servir un trafic public important sans coupler les performances du site aux imports marchands.

Synchronisation incrémentale¶

La voie normale à grande échelle est le traitement ciblé des changements.

Un changement de prix ou de disponibilité doit principalement affecter l'offre concernée et les projections dépendantes.

Une nouvelle information produit peut déclencher les étapes métier nécessaires pour le produit impacté.

Un rebuild global reste disponible pour :

certification ;
recovery ;
réconciliation ;
correction d'un état dérivé.

Le rebuild complet n'est pas la réponse par défaut à chaque petite mutation.

Jobs et workers¶

Les traitements de volume doivent être divisibles en unités de travail bornées.

Pour un gros feed :

FeedRun
  ├── batch 0001
  ├── batch 0002
  ├── batch 0003
  └── ...

Les jobs critiques doivent être conçus pour être idempotents, retryables, observables et rejouables.

La panne d'un marchand ou d'un batch ne doit pas bloquer les autres marchands.

Freshness par type de donnée¶

Toutes les données n'ont pas besoin du même cycle.

La plateforme doit pouvoir mettre à jour plus fréquemment :

prix ;
stock ;
disponibilité ;
nouvelles offres.

Les opérations plus coûteuses — identité, classification complète, audits qualité massifs, full reconciliation — ne doivent être rejouées que lorsqu'elles sont nécessaires.

L'objectif est de permettre plusieurs mises à jour quotidiennes par marchand puis, pour certaines sources prioritaires, des refreshs plus fréquents, sans reconstruire inutilement tout le catalogue.

Observabilité métier¶

L'exploitation industrielle doit permettre de suivre au minimum :

âge du dernier feed réussi par marchand ;
durée de synchronisation ;
lignes et offres traitées ;
rejets et raisons ;
taux d'identité non résolue ;
classification unknown/review ;
profondeur et retard de jobs ;
projection lag ;
erreurs techniques ;
latence Frontend/read models ;
charge DB et ressources workers.

Les identifiants merchant_id, feed_run_id, batch_id, job_id et les identités produit/offre doivent permettre de corréler les traitements.

Persistance, cache et recherche¶

La persistance durable conserve l'état nécessaire à la reconstruction et à l'audit.

Redis peut servir de cache, coordination, lock, rate limit ou transport de jobs. Il ne doit pas être l'unique détenteur d'une donnée métier durable.

Un moteur de recherche est une projection spécialisée : son index doit pouvoir être reconstruit.

Single-node industrial-grade, distributed-ready¶

La plateforme doit rester simple à exploiter tant qu'un VPS unique satisfait les mesures de capacité.

Mais les composants doivent être séparables :

Étape 1
VPS unique
  web + workers + DB + cache + observabilité

Étape 2
web | workers | DB sur machines séparées

Étape 3
web horizontal + workers N + DB primaire/réplica + cache/search séparés

Passer d'une étape à l'autre ne doit pas demander une réécriture du Domain Core.

Kubernetes ou une orchestration plus complexe ne doit être introduit que lorsqu'un besoin mesuré le justifie.

Europe et marchés multiples¶

Le modèle doit pouvoir distinguer produit canonique, marchand, marché, pays de livraison, monnaie, taxes, disponibilité et présentation localisée.

La localisation WordPress ne doit pas devenir la définition du marché métier.

Une offre peut avoir des conditions différentes selon le pays ; ce contexte doit rester une donnée explicite de la Platform.

Résilience et reprise¶

Une plateforme industrielle doit prévoir :

backups hors du VPS ;
contrôles d'intégrité ;
restauration testée ;
rebuild des projections ;
reprise des jobs interrompus ;
procédures d'incident ;
rollback de déploiement ;
SLO/RPO/RTO progressivement explicités.

Un backup jamais restauré n'est pas considéré comme une preuve de capacité de reprise.

Comment migrer le legacy¶

Le legacy contient de la connaissance qu'il faut préserver, mais il ne définit pas la cible.

La méthode est :

observer CURRENT
  -> caractériser
  -> identifier la responsabilité
  -> définir le contrat cible
  -> extraire dans src/
  -> conserver un wrapper mince si nécessaire
  -> migrer les consommateurs
  -> certifier
  -> supprimer le chemin historique

Deux vérités métier permanentes ne sont pas acceptables.

Critère de réussite à long terme¶

CMonChoix doit pouvoir :

remplacer WordPress ;
changer de stockage, cache ou search engine ;
multiplier les workers ;
déplacer les services sur plusieurs machines ;
intégrer des centaines de marchands ;
rafraîchir les offres plusieurs fois par jour ;

sans réécrire son Domain Core et sans multiplier les implémentations métier concurrentes.