Price Comparator a commencé sa vie sur Firebase. Firestore pour les données, Firebase Auth pour l'authentification, Cloud Functions pour la logique serveur. L'écosystème Google — rapide à démarrer, documenté à l'infini, gratuit jusqu'à un certain seuil. Puis est venu le moment où j'ai décidé de tout migrer vers PocketBase. Voici pourquoi, et comment.
Pourquoi quitter Firebase ?
Le coût de la dépendance
Firebase est un service managé. C'est sa force : zéro infrastructure à gérer. C'est aussi sa contrainte : vous êtes lié aux prix, aux quotas et aux décisions produit de Google. Pour une app indie avec un volume modeste, Firebase reste gratuit — mais la perspective de monter en charge sans visibilité sur les coûts futurs génère une anxiété de fond difficile à ignorer.
La complexité de Firestore
Firestore est une base de données NoSQL documentaire. Puissante, mais déroutante pour des requêtes relationnelles simples. Price Comparator a un modèle de données classique : utilisateurs → magasins → produits → prix. Ce modèle relationnel s'exprime naturellement en SQL — pas en collections imbriquées avec des règles de sécurité complexes à maintenir.
La confidentialité des données
Les données de Price Comparator appartiennent à l'utilisateur. Les stocker sur les serveurs de Google — même chiffrées — implique une dépendance envers un tiers dont la politique de confidentialité peut évoluer. Héberger soi-même simplifie radicalement la politique RGPD : les données ne quittent pas mon infrastructure.
Pourquoi PocketBase ?
PocketBase est un backend open-source auto-hébergé, distribué en un seul binaire Go. Il embarque une base SQLite, une API REST automatique, un système d'authentification (email + OAuth2), des règles de sécurité par collection et une interface d'administration web. Zéro dépendance externe, zéro configuration Docker complexe.
« Un seul fichier binaire. Une base SQLite. Une interface admin. PocketBase est le backend que tout indie dev aurait voulu avoir depuis le début. »
Pour une app comme Price Comparator, c'est exactement l'outil qu'il faut. Le modèle relationnel s'exprime naturellement via les collections PocketBase (équivalentes aux tables SQL). Les règles de sécurité sont simples à écrire. Le SDK Dart officiel intègre nativement la gestion des tokens et le temps réel via SSE.
La migration technique
Schéma de données
La migration du schéma a été la partie la plus simple. Trois collections : users (géré par PocketBase nativement), stores (magasins, avec relation vers l'utilisateur propriétaire), items (produits), prices (prix, avec relations vers item et store). Les règles de sécurité : chaque collection n'est accessible qu'à l'utilisateur authentifié propriétaire de l'enregistrement.
Le script de migration
J'ai écrit un script Node.js qui lit les données depuis Firestore via le SDK Admin Firebase et les réécrit dans PocketBase via l'API REST. La difficulté principale : les IDs Firestore sont des chaînes arbitraires, ceux de PocketBase sont des identifiants de 15 caractères. Il a fallu maintenir une table de correspondance pour préserver les relations entre collections.
L'authentification Google OAuth2
PocketBase supporte OAuth2 nativement. Configurer Google comme fournisseur prend cinq minutes dans l'interface admin : Client ID, Client Secret, URL de redirection. Côté Flutter, le package url_launcher ouvre le flux OAuth dans le navigateur système, récupère le token de redirection et l'envoie à PocketBase. Même résultat qu'avec Firebase Auth — mais sans SDK Google supplémentaire.
Ce que j'ai gagné
Contrôle total. Les données de mes utilisateurs sont sur un serveur que je contrôle, en Europe, sans intermédiaire. La politique RGPD est simple : un seul responsable de traitement, une seule infrastructure à documenter.
Coût prévisible. Un VPS à 5 €/mois héberge PocketBase confortablement pour des milliers d'utilisateurs actifs. Aucune surprise de facturation liée à des lectures Firestore.
Modèle relationnel. Requêtes SQL sous le capot, relations explicites entre collections, filtres puissants côté API. Beaucoup plus naturel pour ce type de données.
Ce que j'ai perdu
Firebase offre des fonctionnalités qu'il faut reconstruire avec PocketBase : pas de CDN intégré, pas de Cloud Functions (remplacées par des hooks PocketBase ou un simple script serveur), pas d'analytics natif. Pour Price Comparator, aucune de ces fonctionnalités n'était critique. Pour une app plus complexe, il faudrait peser ces manques.
Faut-il migrer ?
PocketBase est le bon choix si votre modèle de données est relationnel, si vous voulez contrôler vos données, et si votre volume ne justifie pas une infrastructure distribuée. Firebase reste pertinent pour des projets qui ont besoin de temps réel à grande échelle, d'un CDN global ou d'intégrations profondes avec l'écosystème Google.
Pour un développeur solo avec une app de niche bien définie : PocketBase simplifie, réduit les coûts et rend la conformité RGPD beaucoup plus lisible. C'est le choix que j'aurais fait dès le premier jour si je l'avais connu.
