Architecture Roadmap

Status: CURRENT / TARGET TRAJECTORY

Objet

Cette roadmap fixe la trajectoire architecturale de CMonChoix. Elle ne constitue pas un planning daté ni une liste de tickets. Elle indique l'ordre logique des transformations et les conditions à satisfaire avant de considérer une phase comme industrialisée.

La direction est gouvernée par la Constitution.

Principe directeur

WordPress présentation uniquement
            ↓
Platform indépendante dans src/
            ↓
Pipeline multi-marchands canonique
            ↓
Refresh incrémental + jobs bornés
            ↓
Projection-first
            ↓
SLO / capacité / recovery certifiés
            ↓
Multi-VPS lorsque les mesures le justifient

Chaque phase doit être livrée par petits lots vérifiables. Le legacy est retiré seulement après migration des consommateurs et certification du nouveau chemin.

Phase 0 — Foundation et gouvernance

Objectif

Disposer d'une architecture qui ne dépend pas de la mémoire des mainteneurs.

Attendus

• vision normative ;
• constitution ;
• invariants ;
• contrat de dépendances ;
• Definition of Done ;
• dette technique CURRENT ;
• ADR pour les décisions structurantes ;
• distinction CURRENT/TARGET/TRANSITIONAL/HISTORICAL.

État

Fondation établie. Elle reste à maintenir avec le code.

Phase 1 — Indépendance totale vis-à-vis de WordPress

Objectif

Faire de WordPress un pur CMS/SEO/adapter de présentation.

Travaux structurants

• migrer vers src/ toute logique métier encore dans plugins/ccx-feeds-industrial/ ;
• commencer par les zones mapping/classification/identity/quality/vertical/pipeline qui décident encore du résultat ;
• conserver des wrappers fins pendant la transition ;
• isoler $wpdb derrière des ports d'infrastructure ;
• empêcher toute nouvelle logique métier dans le plugin ;
• faire converger les workers vers une exécution Platform sans WordPress.

Condition de sortie

Une certification démontre qu'un scénario représentatif exécute ingestion -> normalisation -> classification -> identity -> quality -> projection sans WordPress chargé.

Phase 2 — Pipeline marchand canonique

Objectif

Ajouter un marchand sans ajouter un nouveau moteur métier.

Cible

Merchant source
   ↓
Merchant adapter / mapping source
   ↓
Canonical observation
   ↓
Common Platform pipeline

Conditions de sortie

• merchant_id et feed_run_id sont traçables ;
• les spécificités marchands sont confinées ;
• aucun if merchant opportuniste n'est dispersé dans les composants génériques ;
• retrait d'un marchand sans modification du Domain Core ;
• onboarding reproductible par fixtures et contract tests.

Phase 3 — Isolation des runs, batches et jobs

Objectif

Empêcher un gros feed ou un marchand en erreur de bloquer toute la plateforme.

Cible

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

Conditions de sortie

• traitements bornés ;
• reprise après crash ;
• idempotence ;
• retries explicites ;
• failed/dead-letter handling documenté ;
• limites de concurrence par marchand ;
• métriques queue/batch/run ;
• aucun gros traitement n'exige de conserver le feed entier en RAM.

Phase 4 — Refresh incrémental généralisé

Objectif

Mettre les offres à jour plusieurs fois par jour sans reconstruire tout le catalogue à chaque mutation.

Modèle

changement source
  ↓
offres impactées
  ↓
identités / produits impactés
  ↓
projections impactées
  ↓
invalidations cache ciblées

Conditions de sortie

• prix/stock ne déclenchent pas de calculs produit inutiles ;
• scope affecté explicite ;
• incrémental équivalent au full rebuild sur tests de certification ;
• suppressions et disparitions d'offres gérées ;
• full rebuild conservé comme recovery ;
• projection lag mesurable.

Le scoped canonical refresh introduit sur la branche actuelle est une étape de cette direction, pas la fin de l'industrialisation globale.

Phase 5 — Projection-first pour le Frontend

Objectif

Découpler complètement le coût du trafic public du coût des imports et décisions métier.

Conditions de sortie

• pages publiques lisent des read models/projections ;
• aucune classification/identity/quality lourde à la requête ;
• requêtes critiques bornées ;
• cache explicite avec stratégie d'invalidation ;
• projection reconstructible ;
• WordPress reste remplaçable.

Phase 6 — Observabilité métier et SLO

Objectif

Piloter la plateforme par des mesures plutôt que par le ressenti.

Métriques prioritaires

• feed age par marchand ;
• durée et débit de synchronisation ;
• offres ingérées/modifiées/rejetées ;
• reason codes ;
• identity unresolved/conflict ;
• classification unknown/review ;
• queue depth/lag ;
• projection lag ;
• latence read models/Frontend ;
• erreurs 5xx ;
• DB latency ;
• CPU/RAM/I/O des workers.

Conditions de sortie

• dashboards utiles ;
• alertes sur symptômes importants ;
• objectifs de disponibilité, fraîcheur, latence et reprise documentés ;
• run/batch/job corrélables de bout en bout.

Phase 7 — Capacity model du VPS

Objectif

Connaître la capacité réelle avant d'ajouter de la complexité infrastructure.

À mesurer

offers total
offers changed/day
rows/sec ingestion
rows/sec normalization
rows/sec persistence
products/sec identity
products/sec projection
jobs/min
DB writes/sec
CPU / RAM / IOPS
queue lag
projection lag

Condition de sortie

Une configuration VPS donnée peut être associée à une capacité observée, une fréquence de refresh et une marge de sécurité.

Phase 8 — Disaster Recovery certifié

Objectif

Pouvoir perdre un composant sans perdre la plateforme.

Conditions de sortie

• backups hors VPS ;
• restauration testée ;
• RPO/RTO explicités ;
• projections/search rebuildables ;
• Redis reconstructible selon son rôle ;
• procédure de reconstruction du VPS ;
• rollback de déploiement documenté ;
• tests de restore périodiques.

Phase 9 — Séparation physique progressive

Déclencheur

Uniquement lorsque la capacité mesurée du VPS unique devient insuffisante ou qu'un besoin de disponibilité le justifie.

Trajectoire possible

A. VPS unique
   web + workers + DB + cache + monitoring

B. web | workers | DB séparés

C. web x N
   workers x N
   DB primary + replica
   Redis/search séparés
   monitoring séparé

Le déplacement physique d'un worker ne doit pas modifier le métier.

Phase 10 — Multi-market Europe

Objectif

Supporter plusieurs marchés sans coupler le métier à un site WordPress par pays.

Modèle à préserver

• produit canonique global lorsque pertinent ;
• offre liée au marchand et au marché ;
• devise explicite ;
• taxes et livraison explicites ;
• disponibilité par marché ;
• présentation/localisation séparée du moteur métier.

Ce qui n'est pas une étape obligatoire

Kubernetes, microservices nombreux, event sourcing généralisé ou séparation de chaque module sur un serveur ne sont pas des objectifs en soi.

Ils ne doivent être introduits que lorsqu'une contrainte mesurée et un bénéfice opérationnel clair le justifient.

Règles de passage entre phases

Une phase n'est pas terminée parce qu'un nouveau fichier existe. Il faut au minimum :

• contrat documenté ;
• tests/guards adaptés ;
• comportement Runtime validé lorsque concerné ;
• observabilité ;
• migration des consommateurs ;
• absence de deuxième vérité active ;
• procédure de recovery/rollback pour les mutations risquées ;
• documentation CURRENT synchronisée.

Références

• Vision
• Invariants
• Frontière WordPress
• Migration
• Performance
• Synchronisation marchands
• Certification
• Dette technique