Votre backend créé par IA doit-il quitter Firebase ?

Une application doit quitter Firebase lorsque son modèle de données, ses règles d'autorisation ou ses flux serveur deviennent plus difficiles à comprendre que le produit lui-même. Elle ne doit pas partir simplement parce que l'équipe a entendu dire que Postgres était plus sérieux. Une réécriture précipitée peut remplacer certaines contraintes par une panne, des comptes perdus et des mois de comportement partagé entre deux systèmes.

Pour la plupart des équipes qui ont dépassé les limites de Firestore, Supabase constitue une voie médiane pratique : données relationnelles, SQL, authentification gérée, stockage, fonctions et API générée dans un même service. Un service Postgres géré donne davantage de contrôle et impose moins de conventions aux équipes expérimentées, mais il leur laisse aussi la responsabilité d'assembler l'authentification, les API, le stockage des fichiers, les tâches en arrière-plan, l'observabilité et le déploiement. Rester sur Firebase peut encore être le bon choix lorsque le modèle documentaire convient et que l'équipe peut réparer ses règles et ses fonctions sans se battre contre la plateforme.

La destination dépend de la contrainte que vous ne pouvez plus payer

Choisissez la destination en nommant la contrainte qui consomme déjà du temps d'ingénierie. Si personne ne peut la formuler en une phrase, l'équipe n'est pas prête à migrer. Une plainte vague comme « Firebase ne passe pas à l'échelle » n'est pas un diagnostic. Firestore peut traiter de fortes charges ; la question utile consiste à savoir si ses modes d'accès et son modèle de cohérence conviennent encore à cette application.

Firebase reste adapté lorsque les clients lisent et écrivent surtout des documents indépendants, que le fonctionnement hors ligne compte, que les écouteurs temps réel sont centraux et que Security Rules peut exprimer les accès sans dupliquer l'état métier. L'intérêt d'une migration augmente lorsqu'une action doit modifier plusieurs enregistrements liés, que les rapports nécessitent des jointures entre collections, que l'intégrité référentielle doit résider dans la base ou que Cloud Functions est devenu le seul endroit où quelqu'un comprend encore les règles réelles.

Supabase convient aux équipes qui veulent la sémantique de Postgres sans construire chaque service périphérique. Il réduit le nombre de décisions pendant le déplacement, ce qui compte lorsqu'un outil d'IA a assemblé le code actuel et que personne n'en possède une carte fiable. Ses conventions imposent aussi des limites : Supabase Auth suit son propre cycle de vie, l'API de données générée dépend de la sécurité au niveau des lignes et les fonctions de la plateforme ne sont pas identiques à un serveur d'application généraliste.

Postgres géré convient lorsque l'équipe sait déjà quel framework web, fournisseur d'identité, système de tâches, service de stockage et ensemble de surveillance elle veut. La base de données reste portable, mais l'équipe doit concevoir et exploiter le backend. Cette liberté n'existe que si quelqu'un assume ces décisions.

Utilisez une grille simple avant de discuter des fournisseurs. Accordez un point à la destination favorisée par chaque affirmation :

Le score ne prend pas la décision. Il rend l'argument visible. Toute ligne que personne ne peut noter avec des preuves devient une tâche d'analyse à accomplir avant la migration.

L'effort de migration se cache dans le comportement, pas dans le nombre d'enregistrements

Un million de documents simples peut être plus facile à déplacer que dix mille documents dont le sens dépend de déclencheurs, d'horodatages clients, de compteurs dénormalisés et de Security Rules. Le nombre d'enregistrements influe sur la durée du transfert. Le couplage des comportements détermine l'ampleur du projet.

Commencez par cartographier chaque chemin capable de modifier un état persistant. Dans un code généré par IA, ne supposez pas que le client de base de données évident est le seul à écrire. Le navigateur peut écrire directement dans Firestore, les routes serveur peuvent utiliser Admin SDK, les fonctions planifiées peuvent réparer des compteurs, les webhooks peuvent modifier l'état d'un paiement et les scripts de déploiement peuvent créer des documents initiaux. Recherchez les initialisations de SDK, les noms de collections, les fonctions appelables, les accès aux espaces de stockage et les variables d'environnement. Comparez ensuite cette carte aux journaux de production et à la configuration cloud. Une recherche dans le code ne trouve pas les fonctions déployées qui ont disparu du dépôt.

Classez chaque écriture selon la garantie dont elle a besoin. La modification d'un profil tolère généralement une mise à jour directe. La confirmation d'une commande peut exiger une transaction, de l'idempotence, un événement immuable et une règle de nouvelle tentative. Un compteur maintenu par un déclencheur Firestore peut devenir un agrégat SQL, un déclencheur de base de données ou une projection asynchrone. Ces trois conceptions échouent différemment. Copier le déclencheur ligne par ligne dans une nouvelle fonction conserve un ancien contournement alors que la nouvelle base a supprimé la contrainte d'origine.

Estimez le travail dans quatre catégories : transformation des données, bascule des identités, remplacement des flux et intégration client. La transformation comprend l'aplatissement des documents imbriqués, la promotion des valeurs répétées en tables, le choix des types et la résolution des références orphelines. La bascule des identités couvre les hachages de mots de passe, les fournisseurs liés, les sessions, les modèles de courriel, les URL de redirection et la récupération des comptes. Le remplacement des flux englobe les fonctions, files d'attente, tâches planifiées, webhooks et événements de stockage. L'intégration client couvre les changements de requêtes, les états de chargement, les hypothèses de fonctionnement hors ligne, la gestion des erreurs et les contrôles d'autorisation.

Un fichier d'inventaire permet de relire cette estimation. Il peut s'agir d'un simple JSON conservé avec le code de migration :

{
  "source": "firestore",
  "collections": {
    "orders": {
      "writers": ["web-checkout", "payment-webhook"],
      "readers": ["account-page", "support-console"],
      "rules": ["owner-read", "support-read"],
      "side_effects": ["send-receipt", "increment-customer-total"]
    }
  }
}

Cet artefact évite un échec familier : l'équipe migre les écrans visibles, déclare la base terminée, puis découvre qu'un ancien webhook continue d'écrire uniquement dans Firestore. Ajoutez chaque auteur d'écriture avant de fixer des dates. Si une collection possède un auteur inconnu ou un champ inexpliqué, l'analyse n'est pas terminée.

Une exportation Firestore est une source, pas un schéma Postgres

L'exportation gérée de Cloud Firestore produit des fichiers journaux LevelDB et des métadonnées dans Cloud Storage. La documentation Firebase la décrit comme une exportation importable dans une autre base Firestore ou chargeable dans BigQuery sous certaines conditions. Il ne s'agit pas d'une sauvegarde relationnelle que pg_restore peut lire, ni d'un instantané exact pris au démarrage de l'opération. Considérez-la comme la matière première d'une transformation contrôlée.

La migration exige une correspondance explicite entre les chemins de documents et les tables. Un document tel que customers/{customerId}/orders/{orderId} contient une relation dans son chemin. Dans Postgres, cette relation appartient généralement à une clé étrangère orders.customer_id. Les tableaux d'étiquettes primitives peuvent rester des tableaux. Les tableaux d'objets qui évoluent indépendamment deviennent en général des lignes enfants. Les champs de type map peuvent devenir des colonnes typées lorsque le produit les interroge, ou du jsonb lorsque leur forme est vraiment ouverte. Mettre tous les documents en jsonb facilite le premier import tout en conservant les faiblesses de l'ancien modèle.

Firestore autorise l'absence de champs et la variation de type entre documents. Postgres demande un type et permet au schéma de le faire respecter. Étudiez la source avant de finaliser les tables : comptez les champs absents, recensez les types observés, recherchez les identifiants naturels en double et repérez les références à des documents supprimés. Décidez du traitement de chaque anomalie. Une conversion silencieuse, comme transformer un horodatage invalide en valeur nulle, permet à l'import de réussir tout en déplaçant un défaut latent en production.

Pour Supabase, les outils communautaires de migration Firebase peuvent convertir des collections Firestore en JSON et importer les données transformées, mais ils ne comprennent pas les relations voulues par l'application. Pour Postgres géré, un extracteur et un chargeur sur mesure sont souvent plus clairs. Dans les deux cas, rendez la transformation déterministe : le même enregistrement source doit toujours produire la même ligne et le même identifiant. Conservez une colonne d'identifiant source jusqu'à la fin du rapprochement.

Un bon schéma cible fait respecter les affirmations déjà portées par l'application. Cet extrait attribue durablement chaque commande et empêche les livraisons répétées d'un webhook de créer des doublons :

create table customers (
  id uuid primary key,
  firebase_uid text unique,
  email text not null
);

create table orders (
  id uuid primary key,
  customer_id uuid not null references customers(id),
  provider_event_id text not null unique,
  status text not null check (status in ('pending', 'paid', 'cancelled')),
  created_at timestamptz not null
);

Après le chargement, rapprochez des faits plutôt que de vous fier à un code de sortie sans erreur. Comparez les comptes par catégorie métier, les sommes monétaires dans la plus petite unité, les dates minimales et maximales, le nombre de propriétaires distincts et un échantillon de correspondances entre source et cible. Conservez ces requêtes dans le contrôle de versions. Une migration impossible à répéter et vérifier reste une improvisation ponctuelle, pas un processus de mise en production.

L'authentification se déplace séparément des données métier

Les comptes utilisateur ne sont pas des lignes ordinaires, car un compte valide comprend des identifiants, des identités chez les fournisseurs, un état de vérification, des sessions, un mécanisme de récupération et des références depuis les données métier. Migrer une collection users ne migre pas Firebase Authentication, même si les deux emploient le même UID.

Firebase CLI prend en charge auth:export, et Firebase expose les paramètres de hachage nécessaires aux imports compatibles. Le guide Supabase de migration de Firebase Auth emploie un outil en deux parties : il exporte les utilisateurs Firebase en JSON et les importe dans la table cible auth.users. Le guide demande aussi de conserver les paramètres SCRYPT de Firebase, dont la clé de signature, le séparateur de sel, le nombre de tours et le coût mémoire. Ce détail fait la différence entre laisser les utilisateurs se connecter normalement avec leur mot de passe et obliger tout le monde à lancer une récupération.

Ne supposez pas que toutes les identités sont transférables sans difficulté. Inventoriez les comptes par mot de passe, par lien envoyé par courriel, par téléphone, les comptes anonymes et chaque fournisseur OAuth. Vérifiez si une personne possède plusieurs fournisseurs liés sous un seul UID. Contrôlez si la cible conserve les identifiants du fournisseur et comment elle traite les adresses en double. Les claims personnalisés ont besoin d'un emplacement explicite, par exemple des tables d'autorisation ou des claims signés. Les sessions ne passent normalement pas entre deux systèmes d'authentification distincts ; prévoyez donc l'expiration des jetons, la réauthentification et un message clair pour l'utilisateur.

Trois modèles de bascule sont défendables. Une réinitialisation forcée est la plus simple, mais elle génère du support et doit relever d'une décision produit. Un import groupé des hachages conserve la vérification des mots de passe si la cible prend en charge l'algorithme et les paramètres de la source. Une migration progressive valide l'ancien identifiant lors de la première connexion, crée ou met à jour l'identité cible, puis cesse de consulter l'ancien service pour cette personne. Cette dernière solution réduit l'impact du premier jour, mais prolonge la période pendant laquelle deux systèmes peuvent accorder l'accès.

Quel que soit le modèle, créez une correspondance immuable des identités avant de déplacer les lignes métier :

firebase_uid                         postgres_user_id
n7Yx...                              2d99150e-3b33-4afb-9c5b-7cbd20b91a4d

Ne reliez jamais les enregistrements par adresse électronique pendant la migration. Les gens changent d'adresse, les fournisseurs ne la normalisent pas toujours de la même façon et des doublons apparaissent souvent après des années d'imports. Utilisez l'UID source comme identité de migration, puis associez l'identifiant cible. Testez les utilisateurs désactivés, non vérifiés, supprimés mais encore associés à des données, ceux qui dépendent seulement d'un fournisseur et la récupération de compte. La connexion nominale par mot de passe prouve très peu de choses.

L'autorisation doit être réécrite, pas traduite

Firestore Security Rules et la sécurité au niveau des lignes de Postgres répondent à des questions proches avec des modèles d'exécution différents. Une traduction mécanique est dangereuse. Les règles Firestore évaluent une requête par rapport aux chemins de documents et aux données proposées. Les politiques Postgres filtrent les lignes lors des opérations SQL, tandis que les rôles et les droits déterminent les objets accessibles. Un code serveur muni d'identifiants privilégiés peut contourner l'un ou l'autre système ; la frontière de confiance compte donc autant que la syntaxe des politiques.

Commencez par rédiger une matrice d'accès dans le langage du produit. Pour chaque ressource, indiquez qui peut la sélectionner, l'insérer, la modifier et la supprimer, ainsi que les champs ou transitions d'état autorisés. « Les utilisateurs peuvent modifier leur profil » reste incomplet si la ligne contient aussi un champ is_admin. « Les propriétaires peuvent modifier leurs commandes » est faux si les clients peuvent passer status de pending à paid.

Une politique Supabase permettant de sélectionner ses propres commandes pourrait ressembler à ceci :

alter table orders enable row level security;

create policy "customers read own orders"
on orders for select
to authenticated
using (customer_id = auth.uid());

Cette politique ne fonctionne que si orders.customer_id contient le même UUID que celui renvoyé par auth.uid(). Si la ligne importée contient un UID Firebase textuel alors que le nouveau jeton contient un UUID Supabase, la politique ne renvoie aucune ligne. Si un développeur désactive la sécurité au niveau des lignes pour réparer l'écran, elle peut toutes les renvoyer. La correspondance des identités et la conception du schéma appartiennent donc à l'examen de l'autorisation.

Postgres géré n'offre pas auth.uid() à moins que l'application ne crée un contexte de session équivalent ou ne filtre toujours par du code serveur de confiance. De nombreuses équipes choisissent la seconde approche : les clients appellent une API, l'API vérifie l'identité et SQL reçoit l'identifiant authentifié en paramètre. Ce modèle se lit plus facilement dans un seul code, mais chaque point d'accès doit appliquer l'autorisation. Un accès direct à la base depuis le navigateur exige une conception des rôles et des tests de politique plus stricts.

Testez les refus, pas seulement les réussites. Pour chaque rôle, tentez de lire la ligne d'un autre client, de changer une colonne de propriété, de modifier un état protégé, d'insérer l'identifiant d'un autre propriétaire et d'invoquer l'opération par chaque route publique. Exécutez ces tests avec les mêmes identifiants publics et les mêmes claims que le client. Une requête de console d'administration ne prouve rien sur l'isolation des clients.

Les flux personnalisés déterminent si Supabase suffit

Supabase suffit généralement lorsque le comportement peut résider dans des contraintes SQL, des fonctions de base de données, des fonctions edge, des tâches planifiées, des webhooks et un nombre modeste de travaux en arrière-plan. Postgres géré devient plus clair lorsque le produit exige des workers longs, des environnements spécialisés, des files complexes, un réseau privé ou un contrôle de déploiement qui résisterait au modèle de fonctions d'une plateforme.

Recensez les Cloud Functions actuelles par type de déclencheur, pas par nom de fichier. Les fonctions HTTP sont des API. Les fonctions appelables lient le client au protocole d'invocation Firebase. Les déclencheurs Firestore réagissent aux changements de données. Les hooks d'authentification réagissent aux événements d'identité. Les déclencheurs de stockage traitent des fichiers. Les fonctions planifiées assurent la maintenance. Chaque catégorie a besoin d'une cible au comportement de livraison et de nouvelle tentative équivalent.

Accordez une attention particulière à la livraison au moins une fois. Un webhook de paiement, un événement de stockage ou un message de file peut arriver deux fois, même si cela reste rare. Le nouveau gestionnaire doit réclamer l'identifiant d'événement dans la même transaction que la modification d'état. La contrainte d'unicité du schéma précédent transforme la seconde livraison en doublon détectable. Un drapeau en mémoire ou une ligne de journal ne fournit pas cette garantie entre plusieurs instances.

Ne placez pas tous les flux dans un déclencheur de base simplement parce que Postgres peut les exécuter. Les déclencheurs conviennent aux invariants locaux et aux petits changements dérivés qui doivent partager une transaction. Ils conviennent mal aux appels d'API tierces, aux envois de courriel et au traitement lent de médias. Ces actions ont besoin d'une tâche durable et d'un worker qui réessaie de façon idempotente. La base doit valider le changement métier et mettre l'intention en file dans la même transaction.

La recommandation populaire qui consiste à tout réécrire en SQL séduit parce qu'elle supprime du code applicatif. Elle devient mauvaise lorsqu'elle cache les flux dans des fonctions que le reste de l'équipe ne sait ni déployer, ni suivre, ni tester. Placez les règles de cohérence près des données. Placez l'orchestration dans un service doté de journaux, de délais, de nouvelles tentatives et d'un responsable. Supabase peut héberger une petite version de ce service ; une conception avec Postgres géré suppose que l'équipe le choisira et l'exploitera ailleurs.

La charge d'exploitation est le travail qui reste après le lancement

La différence opérationnelle n'oppose pas « géré » à « non géré ». Firebase, Supabase et Postgres géré prennent tous en charge l'infrastructure à un certain niveau. La comparaison utile demande quelles pannes restent à votre charge et si l'équipe peut les détecter et les réparer.

Firebase élimine la majeure partie de l'administration de la base, mais l'équipe conserve la responsabilité de Security Rules, des index, des quotas, des déploiements de fonctions, des surprises de coût, des choix de région et de la récupération applicative. Supabase gère Postgres et regroupe plusieurs services backend, mais l'équipe reste responsable des migrations de schéma, des politiques par ligne, des connexions, des performances des requêtes, de la compatibilité des extensions et de l'interaction entre les composants. Un fournisseur Postgres géré prend en charge le processus de la base, les sauvegardes et une partie de la maintenance, tandis que l'équipe possède la couche API et chaque service d'accompagnement qu'elle a choisi.

Demandez qui effectuera cinq tâches récurrentes : appliquer un changement de schéma sans casser les anciens clients, restaurer des données à un point connu, réagir à la fuite d'un identifiant serveur, diagnostiquer une requête lente entre plusieurs services et renouveler un secret d'authentification. Si la réponse est un fondateur qui n'a jamais vu la configuration de déploiement, Postgres géré accompagné d'une pile de services sur mesure est un premier déplacement trop ambitieux. Si une équipe backend expérimentée exploite déjà ces contrôles, les conventions d'une plateforme peuvent gêner plus qu'aider.

Les comparaisons de coût nécessitent la même charge et les mêmes hypothèses de panne. Firestore facture les opérations et le stockage selon son modèle. Les offres Postgres regroupent souvent le calcul, puis limitent les connexions, la mémoire, le stockage ou le débit. Une requête qui lit un agrégat relationnel ne se compare pas à un client qui récupère des centaines de documents, et une instance Postgres dimensionnée pour la pointe ne se compare pas au coût à vide d'un service sans serveur. Rejouez des requêtes proches de la production sur une cible de test et mesurez la latence, les lignes touchées, les connexions utilisées et le travail de réglage. N'extrapolez pas à partir d'une démonstration vide.

La portabilité comporte elle aussi plusieurs couches. Les tables SQL passent plus facilement d'un fournisseur Postgres à un autre que les données Firestore vers un schéma relationnel. Supabase Auth, les métadonnées de stockage, les API générées, les politiques et les fonctions edge créent encore du travail de migration. Ce coût est acceptable lorsque ces services économisent aujourd'hui plus de travail qu'ils ne risquent d'en demander demain. Qualifier un backend de « sans dépendance » masque les dépendances applicatives qui comptent.

Une bascule sûre garde une seule autorité pour chaque écriture

La migration la plus sûre sépare la copie des données du changement d'autorité. Pendant la copie, Firestore reste la source officielle. Pendant la bascule, chaque entité métier doit avoir un seul auteur d'écriture faisant autorité. Écrire dans deux systèmes pendant des semaines sans rapprochement crée deux versions plausibles de la vérité et rend le retour plus difficile.

Utilisez cette séquence comme point de départ :

1. Gelez les changements de schéma et recensez chaque lecteur, auteur, fonction, règle, index et secret.
2. Construisez le schéma cible, la correspondance d'identités, les tests d'autorisation et l'import déterministe dans un environnement isolé.
3. Répétez une migration complète depuis une nouvelle exportation, notez sa durée et rapprochez les faits métier.
4. Copiez les dernières données, capturez les changements survenus après le début de la copie, puis suspendez les écritures source pour appliquer le dernier delta.
5. Basculez d'abord les auteurs serveur, puis les clients, surveillez les deux systèmes et gardez une voie de retour testée jusqu'à ce que les écritures dans la cible rendent ce retour dangereux.

Un plan avec peu d'interruption peut employer la capture des changements ou une double écriture temporaire, mais il lui faut une règle de conflit et un registre de rapprochement. Consignez l'identifiant de l'opération source, la transaction cible, l'entité, le résultat et l'état de la nouvelle tentative. Décidez à l'avance si la source ou la cible gagne lorsque les deux changent. Si personne ne sait expliquer comment réparer l'échec de la seconde écriture, la double écriture n'est pas maîtrisée.

Préservez la compatibilité à la frontière de l'API quand c'est possible. Si les clients appellent déjà une API applicative, changez son implémentation de stockage sans modifier le contrat. Si les clients parlent directement à Firestore, introduisez une couche de dépôt ou une nouvelle API avant de déplacer chaque écran. Cette séparation semble plus lente la première semaine, mais évite des modifications répétées pendant le reste de la mise en production.

Définissez le retour arrière comme une procédure testée avec une échéance. Avant les premières écritures dans la cible, il peut suffire de repointer les clients et de jeter la cible. Dès que des enregistrements propres à la cible existent, le retour exige une transformation inverse ou un gel des écritures. Nommez l'événement exact qui ferme la fenêtre de retour facile. Une sauvegarde aide, mais elle ne constitue pas un plan de retour tant que l'équipe ne l'a pas restaurée et n'en a pas mesuré la durée.

Le code peut nécessiter une réparation avant le déplacement du backend

Une migration amplifie tout ce que l'application actuelle n'a pas explicité. Les projets générés mélangent souvent des identifiants navigateur et serveur, dupliquent les appels de base entre composants, font confiance aux identifiants de propriétaire fournis par le client et cachent des règles métier dans les gestionnaires de l'interface. Déplacer ces appels vers Supabase ou Postgres sans modifier les frontières transfère les défauts.

Ne lancez la migration qu'après avoir répondu à quatre questions sur le code. Quels modules ont le droit d'accéder à la base ? Où l'identité côté serveur devient-elle un identifiant utilisateur fiable ? Quel service possède chaque transition d'état ? Quel environnement peut lire les secrets privilégiés ? Si les réponses changent selon l'écran, établissez d'abord une petite frontière d'accès aux données. Elle n'a pas besoin d'être élégante. Elle doit rendre toutes les écritures visibles et testables.

La gestion des secrets mérite son propre contrôle. La configuration web de Firebase sert à identifier un projet et sa protection dépend de Security Rules et de la configuration du service, tandis que les identifiants Admin SDK accordent un accès privilégié. Supabase possède des identifiants clients publics conçus pour fonctionner avec les politiques par ligne et des identifiants serveur privilégiés qui contournent les restrictions normales. Les chaînes de connexion d'un Postgres géré appartiennent normalement au serveur, jamais au navigateur. Les remplacements automatisés confondent souvent ces catégories parce qu'elles ressemblent toutes à des variables d'environnement.

FixMyMess peut auditer une application d'IA héritée, réparer son authentification et sa logique, renforcer sa sécurité, refactoriser son code et préparer son déploiement avant ou pendant le déplacement. Le résultat utile n'est pas un changement de fournisseur, mais un système dont un humain peut expliquer la propriété des données, les chemins privilégiés et la procédure de mise en production.

Ne migrez pas un code qui ne peut pas réussir un audit élémentaire des chemins d'écriture. Stabilisez l'identité et les invariants métier, choisissez la plus petite destination qui les prend en charge et répétez l'opération jusqu'à ce que le rapprochement devienne routinier. Firebase, Supabase et Postgres géré peuvent tous faire tourner un produit sain. Aucun ne peut fournir le modèle manquant du comportement attendu du produit.