CMonChoix Platform

DOCUMENTATION OFFICIELLE

Une Platform catalogue indépendante, multi-marchands et industrialisable

Le point d’entrée pour comprendre l’architecture cible, distinguer le CURRENT du TARGET et exploiter CMonChoix sans perdre la direction du projet.

NORMATIVE Constitution et frontières CURRENT État runtime dans les pages Operations TARGET Platform indépendante sous src/

North Star

Règle fondamentale

WordPress → src/ : autorisé.
src/ → WordPress : interdit pour fournir une responsabilité métier.

CMonChoix est une plateforme d’ingestion, normalisation, classification, identité produit, qualité, catalogue, projections et synchronisation multi-marchands.

WordPress est uniquement une couche CMS, SEO et présentation publique. Le moteur catalogue doit pouvoir fonctionner sans WordPress.

La cible est de pouvoir passer de quelques marchands à plusieurs dizaines puis plusieurs centaines, avec des traitements bornés et rejouables, des refreshs incrémentaux et un Frontend alimenté par des projections rapides.

À lire avant toute modification importante

Constitution Les règles qui doivent rester vraies même si le code, WordPress ou l’infrastructure changent. Vision cible North Star multi-marchands, projection-first, incrémental et distributed-ready. Frontière WordPress Ce qui appartient à la Platform et ce qui peut réellement rester dans WordPress. Invariants Garde-fous métier, dépendances, jobs, projections, isolation et recovery. Roadmap d’architecture WordPress independence → multi-marchands → incrémental → SLO → multi-VPS. Migration plugin → Platform Comment sortir progressivement le métier de ccx-feeds-industrial vers src/.

Architecture en une vue

Sources marchandes
      ↓
Adapters source
      ↓
Ingestion / normalisation
      ↓
Domain + connaissances verticales
      ↓
Identity / quality / décisions métier
      ↓
Persistance durable
      ↓
Projections / Read Services
      ↓
WordPress adapter
      ↓
Pages / SEO / CMS

Le Runtime orchestre cette chaîne ; il ne crée pas de nouvelle vérité métier.

Multi-marchands

La cible n’est pas un moteur différent pour chaque marchand.

Acer --------\
Samsung ------+--> adapters source --> pipeline canonique commun
Darty --------/
Merchant N ---/

Chaque marchand peut avoir sa configuration et son mapping source. Après cette frontière, les observations convergent vers les mêmes contrats Platform.

Une panne ou un feed volumineux d’un marchand ne doit pas bloquer les autres.

Performance et fraîcheur

La stratégie est de calculer lorsque les données changent, pas à chaque visite :

mutation
  ↓
scope impacté
  ↓
projection refresh
  ↓
cache / search invalidation

request utilisateur
  ↓
projection / read model
  ↓
rendu

Prix, stock et disponibilité peuvent être rafraîchis fréquemment et de manière ciblée. Les calculs plus coûteux — identité, classification complète, audits qualité, full reconciliation — sont rejoués uniquement lorsque nécessaire.

Le full rebuild reste disponible pour convergence, certification et disaster recovery.

Exploitation CURRENT

Les nombres de services, marchands actifs, tables, derniers commits certifiés et états de santé changent avec le Runtime. Ils ne sont donc pas figés sur cette page d’accueil.

Pour connaître l’état réellement observé :

État Runtime actuel Topologie et comportement réellement observés sur la révision documentée. Synchronisation marchands Runs, batches, isolation, refresh incrémental, retries et scheduling. Performance & capacité Débit, CPU, RAM, DB, projection lag et certification de capacité VPS. Déploiement Procédures CURRENT de livraison et de validation. Sauvegarde & restauration Backups, restore checks et reprise. Certification Ce qui doit être prouvé par tests, code et Runtime — pas seulement documenté.

Statuts documentaires

• NORMATIVE / CONTRACT : règle durable ;
• CURRENT : comportement réellement actif ou observé ;
• TARGET : destination recherchée ;
• TRANSITIONAL : compatibilité temporaire ;
• HISTORICAL : contexte conservé ;
• DEPRECATED : ne doit plus guider de nouveau développement.

Un état CURRENT qui contredit la cible ne redéfinit pas l’architecture : il devient une dette ou une migration à fermer.

Principe de transmission

Un nouveau mainteneur doit pouvoir comprendre CMonChoix sans connaître son historique oral.

Avant une modification sensible, il doit pouvoir répondre à quatre questions :

1. Qui possède cette responsabilité ?
2. Quelle est la source de vérité ?
3. Cette capacité doit-elle fonctionner sans WordPress ?
4. Comment prouver le résultat et récupérer après un échec ?

Si ces réponses sont floues, le chantier doit commencer par l’architecture ou l’audit, pas par un patch local.