Aller au contenu

ADR : Architecture back-office — source de données unique, fronts spécialisés multiples

Contexte

Sujet ouvert par Alban au meeting 2026-04-30, en lien avec sa réflexion sur le MCP : à terme, faut-il intégrer toutes les UIs métier (CRM, gestion projets, outil d'analyse...) dans une plateforme back-office unique gérée par la tech, ou garder des plateformes spécialisées par métier ?

Ce débat reboucle avec la conclusion d'une réunion antérieure : "il y a une seule source de vérité, plusieurs fronts différents".

Options envisagées

Option A : Plateforme back-office unique (fusion des UIs)

  • Description : tout ramener sur un seul back-office maintenu par la tech, avec MCP par rôle pour adresser la spécialisation métier.
  • Avantages : moins de duplication, cohérence visuelle, maintenance centralisée.
  • Inconvénients : nécessite une généralisation prématurée (cf Vincent : "souvent généraliser, ça crée du bloat"), ralentit la vélocité produit, perd la finesse UX par persona, complexifie la collaboration.
  • Coût estimé : élevé court terme, gain potentiel long terme.

Option B : Source de données unique + multiples fronts spécialisés

  • Description : EF (DB de prod) reste la source de vérité unique. Chaque métier a son front spécialisé (CRM par Alban, outil d'analyse par Romain, back-office EF par tech, etc.). Les fronts consomment l'API EF.
  • Avantages : vélocité produit maintenue, UX par persona, équipes indépendantes, cohérence garantie au niveau des données. MCP utilisable comme tiroir transverse pour les besoins d'exploration.
  • Inconvénients : plus de fronts à maintenir, cohérence visuelle à porter au niveau design system.
  • Coût estimé : continuité.

Option C : Statu quo (multiples fronts ET multiples DBs)

  • Description : continuer avec Bubble + outil d'analyse + CRM ayant chacun leur source.
  • Avantages : aucune migration.
  • Inconvénients : duplication des données, contradictions entre plateformes, dette croissante. Déjà la cause de la refonte EF en cours.
  • Coût estimé : élevé long terme. Inacceptable.

Décision

Option retenue : B — Source unique (EF) + fronts spécialisés

Justification (synthèse Vincent + Denis + Romain) :

  • "Le front, il est là pour servir la personne qui l'utilise" → spécialisation = bonne chose.
  • "Avoir un front unifié, c'est surtout un gain UX, pas critique." → on accepte la pluralité de fronts.
  • "Éviter de dupliquer la donnée et faire en sorte que tout ait un sens d'un point de vue back-office, c'est beaucoup plus critique." → on impose une source unique.
  • L'orientation équipes indépendantes par squad dépend de cette modularité front.

Conséquences

Positives attendues

  • Pas de méga-projet front interconnecté avec peur de toucher quoi que ce soit.
  • Possibilité d'itérer vite sur des UIs spécialisées (Alban sur CRM, Romain sur outil d'analyse, etc.).
  • À mesure qu'un sujet mûrit (validation produit, criticité acceptée), il bascule vers la team tech avec process complet — pas de lock-in du build perpétuel par les product builders.
  • MCP positionné comme tiroir transverse, pas comme plateforme remplaçante.

Négatives acceptées

  • Plusieurs codebases front à maintenir.
  • Cohérence visuelle à imposer au niveau design system / composants partagés (à structurer).
  • Duplication potentielle de logique d'affichage (à mitiger via API + composants partagés).

Reversibilité

  • Coût d'annulation : moyen. On peut toujours fusionner plus tard. La source unique est l'invariant non-négociable.

Plan d'implémentation

Métriques de succès

  • Aucune nouvelle source de vérité créée hors EF
  • Tous les nouveaux fronts internes consomment l'API EF (pas la DB en direct)
  • Capacité à recruter des devs en autonomie sur un périmètre back-office sans qu'ils aient besoin de comprendre toute la stack

Sources

Révisions

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