Méthodologie de migration¶

Vue d'ensemble¶

La migration de la Platform suit une méthodologie stricte dont l'objectif est de préserver la valeur du projet sans reproduire les défauts de l'architecture historique.

Cette méthodologie s'applique à tous les composants provenant du plugin historique ccx-feeds-industrial.

Aucune exception ne doit être faite.

Philosophie¶

Le plugin historique représente plusieurs années de développement.

Il contient :

une forte valeur métier ;
de nombreuses optimisations ;
des règles de classification éprouvées ;
des correctifs spécifiques ;
des centaines de décisions techniques.

En revanche, il contient également :

des patchs accumulés ;
des dépendances devenues inutiles ;
des composants obsolètes ;
des doublons ;
des compromis liés aux anciennes contraintes du projet.

La migration consiste à séparer la valeur métier de la dette technique.

Principe fondamental¶

La Platform V2 ne migre jamais un composant parce qu'il existe.

Elle migre uniquement un composant parce qu'il est encore pertinent.

Chaque composant doit démontrer sa valeur avant d'être intégré.

Les six étapes de la migration¶

Chaque composant suit exactement le même processus.

Audit
    │
    ▼
Compréhension
    │
    ▼
Classification
    │
    ▼
Migration ou Réécriture
    │
    ▼
Validation
    │
    ▼
Activation

Aucune étape ne peut être ignorée.

Étape 1 — Audit¶

Avant toute modification, le composant est analysé.

L'audit doit permettre de répondre notamment aux questions suivantes :

quelle est sa responsabilité ;
est-il encore utilisé ;
qui l'appelle ;
quelles sont ses dépendances ;
contient-il des patchs historiques ;
dépend-il d'autres composants qui vont disparaître ;
son comportement est-il documenté.

L'objectif n'est pas encore de modifier le composant.

L'objectif est de le comprendre.

Étape 2 — Compréhension¶

Un composant ne peut être migré que si son fonctionnement est parfaitement compris.

Cela implique notamment :

comprendre sa logique métier ;
identifier les cas particuliers ;
comprendre les raisons des patchs existants ;
distinguer les règles métier des contraintes techniques.

Cette étape est essentielle.

Migrer un composant mal compris conduit généralement à recréer les mêmes problèmes.

Étape 3 — Classification¶

Une fois le composant compris, il reçoit une classification.

Cette classification détermine son avenir dans la Platform.

Les classifications sont définies dans le document Classification des composants.

Étape 4 — Migration ou réécriture¶

La migration n'est jamais automatique.

Deux approches sont possibles.

Migration¶

Le composant est suffisamment propre pour être adapté à la nouvelle Platform.

Sa logique est conservée.

Son intégration est adaptée à la nouvelle architecture.

Réécriture¶

Lorsque le composant est trop fortement lié à l'ancienne architecture, seule la logique métier est conservée.

Le code est entièrement réécrit.

Cette approche est souvent préférable lorsqu'un composant a accumulé de nombreux patchs successifs.

Étape 5 — Validation¶

Tout composant migré doit être validé.

Selon sa nature, cette validation peut comprendre :

analyse statique ;
validation PHP ;
tests unitaires ;
smoke tests ;
comparaison avec le comportement historique ;
audits ;
vérification des KPI ;
validation des performances.

La migration n'est considérée comme terminée qu'après validation.

Étape 6 — Activation¶

Un composant validé n'est pas immédiatement utilisé par le Runtime.

Son activation suit toujours la progression suivante.

draft
    │
    ▼
readonly
    │
    ▼
active

Cette progression garantit une transition progressive et limite les risques de régression.

Les patchs historiques¶

La présence d'un patch dans l'ancien plugin ne justifie jamais sa migration.

Chaque patch doit être réévalué.

Trois situations peuvent se présenter.

Le patch reste nécessaire¶

Le besoin existe toujours.

Le comportement est alors réintégré proprement dans la nouvelle Platform.

Le patch devient inutile¶

La nouvelle architecture résout naturellement le problème.

Le patch disparaît.

Le patch est spécifique à l'ancienne architecture¶

Le comportement est remplacé par une solution plus générique.

Les règles absolues¶

La migration respecte systématiquement les principes suivants.

Aucun copier-coller massif¶

Les anciens dossiers ne sont jamais déplacés intégralement.

Aucun legacy inutile¶

Tout composant legacy a vocation à disparaître.

La Platform reste la référence¶

L'ancienne architecture ne doit jamais imposer son organisation à la nouvelle Platform.

La simplicité prime¶

Lorsque deux solutions produisent le même résultat, la plus simple est privilégiée.

La stabilité prime sur la vitesse¶

La migration doit préserver le fonctionnement du site.

Une migration plus lente mais plus sûre est toujours préférable à une migration rapide générant des régressions.

Objectif final¶

À la fin de la migration, chaque composant présent dans la Platform devra répondre à une seule question :

"Si ce composant devait être développé aujourd'hui, avec l'architecture actuelle, l'écririons-nous de cette manière ?"

Si la réponse est non, alors ce composant devra être adapté ou réécrit.

Ce principe garantit que la Platform évolue continuellement vers une architecture plus simple, plus cohérente et plus durable.