Aller au contenu
Selected work
02 Livrée · bascule DNS planifiée

Migration Base44 → Supabase

Refonte d'une plateforme multi-agences EU, sans downtime

Client
BPSI France — aménagement d'espaces (Paris · Berlin · Madrid · Milan)
Rôle
Migration & build
Période
2026
02 CASE STUDY Migration Base44 → Supabase nyami.fr / work

Visuel de marque — screenshot produit à remplacer.

Stack

Vite + React Supabase (Postgres + RLS) Edge Functions Cloudflare Pages Resend

Lien

bpsifrance.com ↗

Site cible bpsifrance.com — bascule DNS progressive, ancien site en filet.

Contexte

BPSI France opère l’aménagement d’espaces sur plusieurs agences européennes. Leur plateforme (site vitrine + recrutement + études de cas + espace connecté) tournait sur Base44, un backend propriétaire : dépendance forte, peu de contrôle sur les données, coûts et lock-in croissants.

Objectif : reprendre le contrôle total de la stack — données, auth, emails, déploiement — sans jamais couper le site en production ni perdre une boîte mail.

Défi technique

  • 113 références Base44 disséminées dans le code applicatif à éliminer entièrement.
  • Reconstituer le modèle de données (postes, études de cas, profils) sur Postgres avec des politiques d’accès (RLS) propres.
  • Migrer sans downtime : l’ancien site devait rester servi pendant toute la transition.
  • Piège email : le domaine porte des boîtes mail actives (Titan) — une mauvaise manipulation DNS les aurait supprimées.

Solution

  • Modèle de données reconstruit : 7 tables Postgres + Row Level Security, données réelles réimportées (postes ouverts, études de cas, profils).
  • 8 Edge Functions Supabase pour l’API, le sitemap, les assets et l’envoi d’emails.
  • Formulaire de devis branché sur Resend (email transactionnel).
  • Front Vite + React déployable en statique sur Cloudflare Pages.
  • Bascule DNS progressive (records A/CNAME modifiés chirurgicalement, MX/SPF/TXT intouchés) → aucun email perdu, ancien site en filet de sécurité, downtime nul.

Résultat

  • 113 références Base44 → 0. Sortie complète du backend propriétaire.
  • Migration livrée en 8 commits propres, staging vérifié bout-à-bout.
  • Emails d’entreprise préservés (découverte du risque Titan documentée, aucune mailbox touchée).
  • Un handoff de déploiement écrit : commandes, plan de rollback instantané, checklist.

Learnings & trade-offs

  • Le vrai risque d’une migration n’est pas le code, c’est le DNS et l’email. L’essentiel du soin est passé dans une bascule réversible plutôt que dans le refactor.
  • Documenter chaque étape irréversible avant de l’exécuter — et savoir s’arrêter devant une case à cocher dangereuse.