ADR : Stratégie de bascule EF — Big Bang on/off, pas d'hybride¶

Contexte¶

La nouvelle plateforme EF doit remplacer l'ancien EF Bubble. La stratégie de bascule était restée ouverte au meeting 25/05 : trois pistes en présence — Big Bang on/off, synchro réactive (data ancien EF → reflétée sur le nouveau, retour en arrière possible), et split pré-financement / post-financement comme dérisquage.

Au kick-off du 16/06, le sujet est retranché collectivement pour pouvoir lancer la phase de parallélisation et confier l'ownership de la migration.

Options envisagées¶

Option A : Big Bang on/off (retenue)¶

Une bascule unique de l'ancien vers le nouvel EF, sans coexistence des deux versions.
Avantage : pas de double maintenance, pas de synchro bidirectionnelle à fiabiliser.
Inconvénient : pas de fallback automatique ; nécessite une fenêtre de maintenance et un scénario de repli en cas d'échec.

Option B : Synchro réactive (hybride)¶

Les données modifiées sur l'ancien EF se reflètent immédiatement sur le nouveau, permettant un retour en arrière.
Inconvénient rédhibitoire : l'hybride avec Bubble a déjà été expérimenté (CRM + commissions) et s'est révélé être « un sac de nœuds » — synchros API Bubble non systématiques, limites techniques de Bubble non pensé pour ça. Trop complexe à maintenir.

Option C : Split pré / post-financement¶

Basculer le post-financement d'abord (dossiers figés, plus proche de l'API), garder le pré-financement sur l'ancien EF.
Non retenue comme stratégie de bascule : la parallélisation du dev couvre déjà pré-fi, post-fi et users en tracks séparés, et l'équipe préfère une bascule unique propre plutôt que de maintenir deux systèmes en parallèle côté run.

Décision¶

Option A — Big Bang on/off, pas d'hybride entre ancienne et nouvelle version.

Justification : la double maintenance et la synchro hybride avec Bubble sont jugées trop coûteuses et trop risquées au vu de l'expérience passée. On assume une bascule nette.

Conséquences¶

Acceptées¶

Fenêtre de maintenance probable lors de la bascule.
Scénario de fallback à définir (« qu'est-ce qui se passe si ça merde à telle étape ? ») — point ouvert à cadrer dans le plan de migration.
Sprint de debug post-release à prévoir (façon migration passée), ressource dédiée envisagée.

Ownership¶

Kevin (product builder externe, expert EF Bubble) prend l'ownership de la migration : audit de l'existant Bubble, schéma, plan / rétroplanning de migration, grande partie de la conversion data. Conditionné à l'obtention du schéma de données côté back (même imparfait).

Réversibilité¶

Faible une fois la bascule faite (pas de retour automatique) — d'où l'importance du scénario de fallback et des tests sur vraies données en amont (début août).

Points liés à cadrer dans le plan de migration¶

Persistance des IDs pour ne pas perdre l'historique (cas de la messagerie : correspondance ID Bubble ↔ ID CRM).
Création SPV / Lemonway / Project Owner Bricks, encore sur l'ancien EF, sans plan B aujourd'hui.

Sources¶

Révisions¶

2026-06-16 : créée et acceptée (status: accepted). Clôt la question de release ouverte au 25/05.