Aller au contenu

ADR : Migration progressive des accès direct-DB vers API entre services

Contexte

Aujourd'hui, les services internes d'Alban (CRM, gestion des projets, génération docs) tapent directement sur le replica DB de prod plutôt que de passer par l'API EF. C'était optimal en phase initiale (vélocité, simplicité). Aujourd'hui ça pose deux problèmes :

  1. La team tech refacto fréquemment le schéma DB (cleanup en cours du modèle qui traîne depuis le début de Bricks). Chaque refacto casse les services d'Alban → backlog de rattrapage côté Alban.
  2. Plus la sécurité côté variables DB exposées dans plusieurs codebases.

Sujet ouvert par Denis : il est temps d'aller vers une relation via API entre services.

Options envisagées

Option A : Tout migrer immédiatement

  • Avantages : sortie nette du direct-DB.
  • Inconvénients : très lourd, l'API EF n'expose pas encore tout, bloque Alban en mode "j'attends que la tech expose les endpoints".

Option B : Migration progressive, ownership query à Alban

  • Description : Alban dev en direct DB sur le replica (autonomie). Au moment de passer en prod, il transforme sa query en endpoint API, fait une PR sur le repo tech. Il garde l'ownership de la query (il connaît son besoin), la tech expose le contrat.
  • Avantages : autonomie côté Alban préservée, dette se résorbe progressivement, doc auto via les endpoints, downtime zéro lors des prochains refactos schéma (la tech met à jour la query interne, l'API ne change pas).
  • Inconvénients : période transitoire un peu hybride.

Option C : Statu quo

  • Inconvénients : dette croissante, casses régulières, sécurité.

Décision

Option retenue : B — Migration progressive avec ownership query côté Alban

Justification : permet de garder la vélocité d'Alban tout en sécurisant la stabilité face aux refactos schéma. Denis est OK pour exposer les endpoints au fur et à mesure ("on prend ta query, on la met dans notre service, on fait un endpoint, c'est fait").

Cas particulier : les extracts one-shot (CSV pour Cédric, scripts ponctuels) peuvent rester en direct DB.

Conséquences

Positives attendues

  • Plus de casse à chaque refacto schéma : la tech met à jour la query interne sans toucher l'API.
  • Documentation automatique des besoins data des services tiers (les endpoints listent ce qui est consommé).
  • Variables DB centralisées côté tech pour la sécurité.
  • Pattern réutilisable : tout futur service interne consomme l'API, pas la DB.

Négatives acceptées

  • Période transitoire où coexistent direct-DB (dev) et API (prod).
  • Dépendance d'Alban à la disponibilité de Denis/Vincent pour merger les endpoints.
  • Performance : à priori pas d'incidence majeure (Alban reste sur des requêtes ciblées, pas de bombardement). À monitorer.

Reversibilité

  • Coût d'annulation : bas. On peut toujours réautoriser direct-DB.

Plan d'implémentation

  • [x] Décision prise au meeting 2026-04-30
  • [ ] Alban : lister toutes les queries de ses services (bricks.service.ts & équivalents) — base de référence pour la migration
  • [ ] Alban + Denis : prioriser quelles queries deviennent endpoints en premier (commencer par celles qui ont déjà cassé / vont casser)
  • [ ] Alban : pour chaque nouvelle query qui va en prod, faire une PR sur le repo tech qui ajoute un endpoint exposant cette query
  • [ ] Denis : exposer les variables DB centralisées, retirer les variables des codebases externes une fois migration acquise
  • [ ] Tous : ne pas faire ça tout de suite à grande échelle — saisir les opportunités de refacto naturelles

Métriques de succès

  • Aucune casse de service Alban lors des prochains refactos schéma DB côté tech
  • Toutes les queries customer-facing exposées via API à l'échéance d'un trimestre
  • Réduction du nombre de codebases ayant les credentials DB en clair

Sources

Révisions

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