Architecture Roadmap¶

Status: CURRENT / TARGET TRAJECTORY

Objet¶

Cette roadmap fixe la trajectoire architecturale de CMonChoix. Elle ne constitue ni 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 est 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, dépendances, Definition of Done, dette technique CURRENT, ADR pour les décisions structurantes et distinction explicite entre CURRENT, TARGET, TRANSITIONAL et HISTORICAL.

État : fondation documentaire établie ; elle doit rester synchronisée 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 mapping, classification, identity, quality, verticales et pipeline ;
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 exécute un scénario représentatif 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.

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

Conditions de sortie : merchant_id et feed_run_id traçables, spécificités marchands confinées, absence de if merchant opportunistes dans le 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.

Conditions de sortie : traitements bornés, reprise après crash, idempotence, retries explicites, gestion des échecs, limites de concurrence par marchand, métriques run/batch/job et absence de chargement obligatoire du 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.

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

Conditions de sortie : scope affecté explicite, suppressions/disparitions gérées, projection lag mesurable, full rebuild conservé comme recovery et équivalence entre état incrémental et état canonique vérifiée par tests.

Des travaux de scoped refresh peuvent être développés et certifiés sur des branches dédiées, mais ils ne deviennent CURRENT sur la branche de référence qu'après intégration et revalidation de cette branche.

Phase 5 — Projection-first pour le Frontend¶

Objectif : découpler le coût du trafic public du coût des imports et décisions métier.

Conditions de sortie : pages publiques alimentées par read models/projections, aucune classification/identity/quality lourde à la requête, requêtes critiques bornées, cache avec invalidation explicite et projections reconstruisibles.

Phase 6 — Observabilité métier et SLO¶

Objectif : piloter la plateforme par des mesures.

Métriques prioritaires : feed age, durée et débit des syncs, offres ingérées/modifiées/rejetées, reason codes, identity unresolved/conflict, classification unknown/review, queue depth/lag, projection lag, latence frontend/read models, erreurs 5xx, DB latency, CPU/RAM/I/O workers.

Phase 7 — Capacity model du VPS¶

Objectif : connaître la capacité réelle avant d'ajouter de la complexité infrastructure.

À mesurer : offres totales, changements/jour, rows/sec ingestion/normalisation/persistence, products/sec identity/projection, jobs/min, DB writes/sec, CPU, RAM, IOPS, queue lag et projection lag.

Condition de sortie : une configuration VPS donnée est 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 reconstruisibles, Redis reconstruisible selon son rôle, procédure de reconstruction du VPS, rollback de déploiement et exercices 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.

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.

Le modèle doit préserver : produit canonique, offre liée au marchand et au marché, devise explicite, taxes/livraison explicites, disponibilité par marché et présentation/localisation séparées 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 sont introduits seulement 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, recovery/rollback pour les mutations risquées et documentation CURRENT synchronisée.