ADR : V1 contrats branchée sur Bubble, switch vers EF ultérieur¶

Contexte¶

Romain travaille sur la V1 contrats dans l'outil d'analyse. La structure de données nécessaire (project owner, société, garanties, cautions, représentants légaux) doit, à terme, venir de la DB de prod EF (source de vérité unique actée). Mais l'EF n'est pas encore disponible (refacto en cours côté tech).

Question d'arbitrage : faut-il livrer une V1 sur Bubble (seule source dispo) ou attendre la disponibilité de l'EF ?

Options envisagées¶

Option A : V1 sur Bubble, switch ultérieur vers EF¶

Description : Brancher la génération sur Bubble en V1, isoler la fonction de récupération via un service intermédiaire (getDataFromBricks-style), basculer plus tard.
Avantages : déblocage immédiat, vraie itération produit avec Cédric et le comité, on apprend en réel.
Inconvénients : un peu de "dette" assumée, à migrer un jour.
Coût estimé : faible — la migration future = changer 1 fonction si le pattern intermédiaire est respecté.

Option B : Attendre l'EF¶

Description : Pas de V1 contrats avant disponibilité EF.
Avantages : pas de dette de migration.
Inconvénients : bloque le produit pendant ~plusieurs semaines/mois. Pas tenable opérationnellement.
Coût estimé : élevé en opportunité (les contrats sont attendus en prod).

Décision¶

Option retenue : A — V1 sur Bubble, switch ultérieur

Justification : Vincent confirme que le switch source de vérité est un changement technique très faible si on respecte le pattern d'isolation. Romain et Vincent alignés. Pas de raison d'attendre.

Conséquences¶

Positives attendues¶

Déblocage de la V1 contrats à court terme.
Pattern getDataFromBricks (proposé par Alban) appliqué ici devient un standard interne pour tous les modules qui consomment des données externes (cf aussi CRM, gestion projets).
Les data ne sont pas stockées côté outil d'analyse : elles sont gettées à la demande, le template est rempli, le PDF est généré, rien n'est persisté. Évite la dette de synchronisation.
L'état "signé / non signé" n'est jamais stocké côté Bricks : on requête USign à la demande.

Négatives acceptées¶

Migration future à prévoir (Bubble → EF), même si peu coûteuse techniquement.
Au moment de la migration EF, il faudra consolider les données qui ont vécu côté outil d'analyse (caution, données saisies à la signature) avec celles côté Bubble. → Documenter le périmètre exact pour cette consolidation.

Reversibilité¶

Coût d'annulation : bas. Le pattern d'isolation rend la migration triviale.

Plan d'implémentation¶

[x] Décision prise au meeting 2026-04-30
[ ] Romain : poursuivre la V1 dans l'outil d'analyse, structurer un service intermédiaire pour la récupération des données
[ ] Documenter dans concepts/contrats.md le périmètre exact de la dépendance Bubble vs EF
[ ] Au moment où l'EF expose les endpoints nécessaires : transformer la fonction get pour pointer EF
[ ] À la migration : consolider les data (caution, etc.) entre les deux systèmes

Métriques de succès¶

V1 contrats opérationnelle pour les premiers projets (Cédric peut générer un contrat post-comité)
Switch source de données réalisé sans rupture côté Cédric ni côté PDP
Aucune duplication de donnée stockée côté Bricks pour ce scope

Sources¶

Révisions¶

2026-04-30 : créée et acceptée (status: accepted)