Plan de migration¶

Vue d'ensemble¶

La migration de CMonChoix vers Platform V2 est réalisée progressivement.

L'objectif n'est pas de remplacer brutalement le plugin historique.

L'objectif est de construire une nouvelle Platform tout en garantissant la stabilité du site en production.

Chaque étape est validée avant de passer à la suivante.

La migration est volontairement incrémentale.

Principes¶

Le plan de migration respecte plusieurs principes.

aucune régression fonctionnelle ;
aucun changement massif ;
validation systématique ;
rollback possible ;
architecture cible prioritaire ;
suppression progressive du legacy.

Chaque étape produit une Platform plus propre que la précédente.

Vue globale¶

Documentation
        │
        ▼
Audit
        │
        ▼
Contracts
        │
        ▼
Domain Core
        │
        ▼
Read Services
        │
        ▼
Write Services
        │
        ▼
Modules
        │
        ▼
Pipeline
        │
        ▼
Runtime
        │
        ▼
WordPress Adapter
        │
        ▼
Suppression Legacy

Chaque étape prépare la suivante.

Phase 1 — Documentation¶

Objectif :

Construire une documentation suffisamment précise pour servir de référence pendant toute la migration.

Livrables :

Architecture
Contracts
Domain Core
Migration
ADR

Cette phase est pratiquement terminée.

Phase 2 — Audit¶

Objectif :

Comprendre parfaitement l'architecture historique.

Chaque dossier est analysé.

Chaque fichier est classifié.

Aucun composant n'est migré sans audit.

Cette étape permettra de distinguer :

la logique métier ;
les dépendances historiques ;
les patchs ;
les optimisations ;
les composants devenus inutiles.

Phase 3 — Contracts¶

Objectif :

Stabiliser les contrats de la Platform.

Les contrats définissent les interfaces entre les différents composants.

Ils doivent être finalisés avant toute migration importante.

Phase 4 — Domain Core¶

Le Domain Core devient la source unique de vérité.

Tous les concepts métier doivent progressivement y être centralisés.

Par exemple :

Canonical Identity ;
Resolver ;
Projection ;
Quality ;
Promotions ;
Helpers.

Aucun traitement métier ne doit contourner le Domain Core.

Phase 5 — Read Services¶

Les Read Services regroupent tous les traitements en lecture.

Ils permettent notamment :

les audits ;
les simulations ;
les previews ;
les comparaisons ;
les rapports.

Ils ne modifient jamais les données.

Phase 6 — Write Services¶

Les Write Services deviennent les seuls composants autorisés à modifier les données.

Ils remplacent progressivement les écritures dispersées dans l'ancien plugin.

Cette centralisation améliore :

la traçabilité ;
la sécurité ;
les possibilités de rollback.

Phase 7 — Modules¶

Chaque verticale devient un module indépendant.

Les anciens composants issus de :

includes/verticals
includes/application
runtime/vertical-normalizers

sont progressivement remplacés par :

platform/modules/<vertical>/

Chaque module respecte les mêmes contrats.

Phase 8 — Pipeline¶

Le Pipeline est progressivement simplifié.

Les règles génériques restent dans le Pipeline.

Les règles spécifiques sont déplacées vers les Modules.

Le Pipeline devient un orchestrateur de traitements plutôt qu'un ensemble de règles métier.

Phase 9 — Runtime¶

Le Runtime conserve uniquement les responsabilités d'orchestration.

Toute logique métier est déplacée ailleurs.

Le Runtime devient responsable de :

l'exécution ;
le scheduling ;
le monitoring ;
les états d'exécution.

Phase 10 — WordPress¶

WordPress devient uniquement une couche d'intégration.

Il expose :

le frontend ;
l'administration ;
les hooks ;
les commandes CLI ;
les points d'entrée HTTP.

Toute logique métier profonde appartient à la Platform.

Phase 11 — Suppression du legacy¶

La suppression intervient uniquement lorsque :

le composant est remplacé ;
les tests sont validés ;
les KPI sont identiques ;
le rollback est possible.

Aucun composant n'est supprimé simplement parce qu'il est ancien.

Critère de fin de migration¶

La migration sera considérée comme terminée lorsque :

Platform sera le seul moteur métier ;
WordPress ne sera plus qu'un adaptateur ;
les composants legacy auront disparu ;
les doublons auront été supprimés ;
chaque module respectera les Contracts ;
toute la documentation sera alignée avec l'architecture réelle.

Vision¶

Cette migration ne vise pas uniquement à moderniser le code.

Elle vise à construire une architecture capable d'évoluer pendant de nombreuses années sans recréer une nouvelle dette technique.

Chaque décision prise pendant cette migration doit être évaluée selon une seule question :

Cette décision rend-elle la Platform plus simple, plus cohérente et plus durable ?

Si la réponse est non, alors la décision doit être réévaluée.

Voir aussi¶

Présentation de la migration
Méthodologie
Classification des composants
Architecture
Domain Core
Pipeline
Runtime