Sommaire6
Une application, ce sont des écrans, et derrière eux un back-end : les comptes, la base de données, les fichiers, les règles qui disent qui a le droit de voir quoi. Pour une PME, trois options reviennent : Supabase, Firebase, ou un serveur que l’on gère soi-même. Aucune n’est meilleure dans l’absolu. Chacune engage des choses différentes sur la forme des données, les coûts, la dépendance à un fournisseur et le travail d’exploitation. Nous utilisons Supabase sur les applications que nous avons construites, et nous le disons d’entrée : ce comparatif essaie d’être juste avec les trois.
En bref
Supabase : une base Postgres complète, relationnelle, avec comptes, temps réel et fonctions serveur autour ; auto-hébergeable, mais alors sans les sauvegardes gérées.
Firebase : une base de documents NoSQL de Google, avec synchronisation en temps réel et mode hors ligne prévus pour le mobile et le web.
Serveur à soi : la maîtrise complète et le choix du lieu des données, en échange de toute l’exploitation.
Le bon choix dépend de la forme de vos données, du besoin de hors ligne et de qui fera tourner le tout dans trois ans.
Ce que fait un back-end
Définition
Back-end
La partie de l’application que l’utilisateur ne voit pas : elle garde les données, vérifie les identités, applique les règles d’accès, stocke les fichiers et exécute les traitements qui ne doivent pas dépendre du téléphone.
Les plateformes comme Supabase et Firebase fournissent ces briques prêtes à l’emploi, ce qui raccourcit le développement. Un serveur à soi oblige à les assembler, mais laisse tout choisir.
Supabase : une base Postgres et les services autour
D’après sa documentation, chaque projet Supabase reçoit une base Postgres complète, pas une abstraction. Autour d’elle, Supabase ajoute les comptes, le temps réel, le stockage de fichiers, des fonctions serveur et des règles d’accès ligne à ligne.
Ce qui plaît : des données relationnelles (un client a des commandes, une commande a des lignes) qu’on interroge en SQL, et une base qui reste du Postgres standard, lisible par les outils habituels. C’est ce qui rend la sortie moins douloureuse si l’on change d’avis.
Ce qu’il faut savoir : l’offre Free se met en pause après une semaine d’inactivité et n’inclut pas de sauvegarde automatique, et l’offre Pro démarre à 25 $US par mois, selon la page tarifs de Supabase. Supabase peut aussi s’héberger soi-même, avec Docker, mais sa documentation d’auto-hébergement prévient : la version auto-hébergée est soutenue par la communauté, et elle n’a ni les sauvegardes gérées ni la restauration à un instant donné de la plateforme.
Sur le terrain
Ce qui tourne sur Supabase chez nous
Challenge Us, une application de défis de groupe que nous avons développée, s’appuie sur Supabase pour le temps réel entre participants et pour les fonctions serveur qui calculent le jour de chaque saisie dans le fuseau de chacun. Supabase figure aussi dans la pile technique de Palmora Property, à côté d’un CRM auto-hébergé.
Firebase : une base de documents pensée pour le mobile
Firebase est la plateforme de Google pour les applications. Sa base principale, Cloud Firestore, est décrite par sa documentation comme une base NoSQL orientée documents, qui garde les données synchronisées entre les appareils par des écouteurs en temps réel et prévoit un mode hors ligne pour le mobile et le web.
Ce qui plaît : le hors ligne et la synchronisation sont intégrés, ce qui compte pour une application utilisée sur le terrain où le réseau manque. La même plateforme regroupe aussi l’analyse d’audience, l’envoi de notifications et l’hébergement.
Ce qu’il faut savoir : une base de documents se conçoit autour des écrans qui la lisent, pas autour des relations entre les données ; les requêtes croisées y sont moins naturelles qu’en SQL. Et la facturation suit l’usage, lecture par lecture :
de données stockées sans frais dans Cloud Firestore, sur l’offre Spark
lectures de documents par jour sans frais, au-delà facturées sur l’offre Blaze
écritures de documents par jour sans frais
Une application dont chaque écran relit beaucoup de documents peut voir sa facture suivre son succès plus vite que prévu : la façon de structurer les données compte autant que le nombre d’utilisateurs.
Un serveur à soi : la maîtrise, et tout le reste
Troisième voie : une base Postgres et une application serveur que vous hébergez, sur une machine louée en Europe par exemple. Vous choisissez où vivent les données, quels logiciels tournent, et vous ne dépendez d’aucune grille tarifaire de plateforme.
En échange, tout ce que la plateforme faisait vous revient. La liste que Supabase donne à ceux qui l’hébergent eux-mêmes vaut pour n’importe quel serveur : provisionner et entretenir la machine, la sécuriser et la tenir à jour, maintenir la base, assurer la disponibilité, les sauvegardes, la reprise après sinistre et la surveillance.
C’est un choix raisonnable quand l’entreprise a déjà ce socle, ou une raison forte de l’avoir (données sensibles, exigences de localisation). Nous en parlons dans notre article sur les outils à auto-héberger en premier, et la question des sauvegardes mérite à elle seule l’article sur ce qui casse vraiment.
Comment trancher
Une plateforme (Supabase ou Firebase)
Vous voulez des utilisateurs vite, sans équipe d’exploitation
Les briques standard (comptes, fichiers, temps réel) couvrent votre besoin
Vous acceptez une grille tarifaire qui suit l’usage
Un serveur à soi
Vous avez déjà un socle d’hébergement et quelqu’un pour l’exploiter
Le lieu des données ou leur sensibilité l’exige
Vous voulez maîtriser chaque logiciel de la chaîne
Entre Supabase et Firebase, la forme des données décide souvent : des relations nombreuses entre clients, commandes et documents penchent vers Postgres ; une application très mobile, qui doit fonctionner hors ligne et synchroniser des documents simples, penche vers Firestore. Dans tous les cas, posez quatre questions avant de choisir :
- Quelle forme ont vos données ?
Des tableaux reliés entre eux, ou des documents indépendants lus écran par écran ?
- Le hors ligne est-il nécessaire ?
Si oui, où, et combien de temps ?
- Où les données doivent-elles vivre ?
Une exigence de localisation ou de sensibilité peut trancher seule.
- Qui exploitera le back-end dans trois ans ?
C’est la question qui pèse le plus sur le budget de maintenance.
Le back-end est l’une des décisions qui font varier le prix de développement et le coût mensuel d’une application. Notre développement d’applications le fixe dès le cadrage, en chiffrant son coût d’exploitation pour votre usage.
Questions fréquentes
Supabase est-il une alternative à Firebase ?
Pour beaucoup d’applications, oui : les deux fournissent comptes, base de données, fichiers, temps réel et fonctions serveur. La différence de fond est la base : Postgres relationnel chez Supabase, documents NoSQL chez Firebase. Le choix se fait sur la forme de vos données et le besoin de hors ligne, plus que sur une liste de fonctions.
Peut-on changer de back-end après le lancement ?
C’est possible, mais rarement simple : il faut migrer les données, les comptes des utilisateurs et réécrire la partie de l’application qui parle au back-end. Une base Postgres standard se transfère avec les outils habituels de Postgres ; une base de documents demande de repenser la structure. Mieux vaut choisir en connaissant ses données que compter sur une migration plus tard.
Supabase ou Firebase, lequel coûte le moins cher ?
Cela dépend de l’usage, pas d’une grille. Firebase facture surtout au nombre de lectures et d’écritures, donc la façon dont l’application relit ses données pèse lourd. Supabase facture un abonnement mensuel, puis le calcul et le stockage au-delà de ce qu’il inclut. Chiffrez les deux sur votre usage prévu, pas sur la page d’accueil de leur grille tarifaire.
Un serveur à soi est-il plus sûr qu’une plateforme ?
Pas automatiquement. Il vous laisse choisir où vivent les données et qui y accède, mais la sécurité dépend alors entièrement de vous : mises à jour, configuration, sauvegardes testées, surveillance. Une plateforme bien configurée vaut mieux qu’un serveur mal tenu. Le serveur à soi se justifie quand vous avez déjà le socle et les personnes pour l’exploiter.
Sources
- Documentation Supabase, présentation de la base de données (nouvel onglet)supabase.com
- La page tarifs de Supabase (nouvel onglet)supabase.com
- Documentation Supabase, auto-hébergement (nouvel onglet)supabase.com
- Documentation Firebase, Cloud Firestore (nouvel onglet)firebase.google.com
Documentation Supabase, présentation de la base de données
Lire sur supabase.com(nouvel onglet)Jim · fondateur de Brain Plus AI
À lire aussi en applications web et mobiles
Guide pratique6 min
Maintenance d'application : le budget après le lancement
Une application en service a trois postes de dépense : son exploitation, les mises à jour imposées par Apple, Google et les bibliothèques, et ses évolutions. Les deux premiers ne sont pas optionnels, et chacun se chiffre ligne par ligne.
Choisir et chiffrer7 min Le guide du sujet
Combien coûte une application : ce qui fait varier le prix
Une fourchette de prix ne dit rien de votre projet : ce qui fait varier le devis d'une application, ce sont quelques décisions précises, plus un coût d'exploitation mensuel à chiffrer à part. Voici lesquelles.
Comprendre6 min
Application terrain : ce qu'elle change pour vos équipes
Techniciens, livreurs, commerciaux en tournée, équipes de chantier : une application interne leur évite le papier, les photos perdues dans une messagerie et la ressaisie du soir. Voici ce qu'elle change, et ce qu'il faut pour qu'elle serve.