Le socle technique d'un prototype se choisit en quelques heures et se paie pendant plusieurs années. Backend prêt à l'emploi ou développement maison, la question revient sur presque tous les projets d'application sur-mesure, et elle est rarement tranchée sur les bons critères.

Voici la grille que nous utilisons pour décider, avec les points qui coûtent cher quand on les découvre après la mise en production.

Un backend prêt à l'emploi, qu'est-ce que cela remplace au juste

Un BaaS (backend as a service) fournit d'emblée la plomberie que l'on redéveloppe sur chaque projet : une base de données, une gestion des comptes et des mots de passe, le stockage des fichiers, une interface de programmation générée automatiquement, la diffusion des changements en temps réel et une console d'administration. Concrètement, cela représente deux à quatre semaines de travail que vous ne payez pas au démarrage.

Le gain est réel : la valeur d'un prototype ne réside jamais dans sa page de connexion. Le piège est ailleurs. Ce socle choisi en une après-midi devient la fondation de l'application si le prototype convainc, et une fondation ne se change pas à mi-parcours sans douleur.

Trois familles de socles, trois profils de risque

Les options se rangent en trois familles, qui n'engagent pas du tout au même niveau.

  • Le service géré propriétaire (Firebase et son moteur Firestore). Très rapide à démarrer, mais le modèle de données, le langage de requête et les règles de sécurité sont spécifiques à la plateforme. Ce que vous écrivez n'est pas transposable ailleurs.
  • Le service géré bâti sur des briques ouvertes (Supabase, Appwrite). Vous obtenez le même confort, mais la base reste une base standard, en général PostgreSQL. Supabase publie d'ailleurs sa version auto-hébergeable sous licence Apache 2.0, ce qui laisse une porte de sortie technique.
  • Le socle léger auto-hébergé (PocketBase et équivalents). Un seul binaire, une base SQLite embarquée, aucun abonnement. Intéressant pour un prototype interne, à condition d'accepter le statut du projet : la version 0.40.1 a été publiée le 24 août 2026 et l'outil reste en série 0.x, donc sans promesse de stabilité de son interface de programmation d'une version à l'autre.

La quatrième voie, le développement maison sur un cadre applicatif classique, garde tout son sens dès que la logique métier est dense. Elle coûte plus cher les trois premières semaines et moins cher à partir du sixième mois.

Les quatre questions qui tranchent réellement

1. Où vivront les données, et sous quelle juridiction

C'est le critère qui élimine le plus d'options, et le plus souvent traité en dernier. Vérifiez qu'une région européenne est disponible et choisissez-la à la création du projet : chez la plupart des services gérés, changer de région ensuite n'est pas un réglage mais une migration complète. Une région européenne ne règle d'ailleurs pas à elle seule la question d'un éditeur soumis à une législation extraterritoriale. Si votre prototype manipule des données de santé, des données RH ou des données de clients publics, posez la question avant la première ligne de code.

2. Votre modèle de données est-il relationnel

Un catalogue de fiches peu liées s'accommode très bien d'une base orientée documents. Des devis reliés à des clients, eux-mêmes reliés à des contrats, des lignes de facturation et un historique de statuts, beaucoup moins. Si vous vous surprenez à dupliquer les mêmes informations dans plusieurs collections pour éviter des jointures, vous payez déjà la mauvaise famille de socle.

3. Qui exploitera l'application dans deux ans

Un socle auto-hébergé suppose quelqu'un pour appliquer les correctifs, surveiller la sauvegarde et gérer les certificats. Un service géré transfère cette charge à l'éditeur, contre un abonnement et une dépendance. Répondez avec un nom d'équipe, pas avec une intention.

4. Quelle est la porte de sortie

Demandez-vous comment vous récupéreriez vos données si l'éditeur triplait ses tarifs. Avec une base PostgreSQL standard, la réponse tient en un export et une restauration ailleurs. Avec un moteur propriétaire, l'export existe mais produit un format spécifique, et ce sont surtout les règles de sécurité et les fonctions serveur qu'il faut réécrire.

Ce que coûte le socle, chiffres en main

Les ordres de grandeur ci-dessous ont été relevés le 2 septembre 2026 et servent à cadrer une discussion, pas à établir un devis.

  • Service géré par abonnement : chez Supabase, l'offre Pro se situe autour de 25 dollars par mois et par organisation, l'offre Team autour de 599 dollars, avec facturation supplémentaire au-delà des volumes inclus.
  • Service géré au compteur : Firebase conserve un palier gratuit, de l'ordre de 50 000 lectures, 20 000 écritures et 20 000 suppressions Firestore par jour pour 1 Gio stocké, puis facture chaque opération au-delà. Le budget d'un prototype y est presque nul, celui d'une application mal indexée peut s'envoler sans prévisibilité.
  • Socle auto-hébergé : aucune licence, mais un serveur, une sauvegarde testée et du temps d'exploitation. Comptez ce temps, il est rarement gratuit.

Retenez la différence de nature : l'abonnement est prévisible, le compteur ne l'est pas.

La réversibilité se décide au premier jour

Quelle que soit la famille retenue, trois précautions rendent le changement possible plus tard sans réécriture générale.

  1. Isolez les appels au socle derrière une fine couche d'accès plutôt que de les disséminer dans toute l'interface. Le jour où vous changez de fournisseur, vous remplacez un dossier, pas une application.
  2. Gardez la logique métier hors des règles de la plateforme. Les règles de sécurité propriétaires sont pratiques et parfaitement non portables : limitez-les au contrôle d'accès, jamais aux calculs qui font votre métier.
  3. Exportez dès le prototype. Un export automatique hebdomadaire, testé une fois, vous dit si la porte de sortie existe vraiment. Une porte de sortie jamais empruntée n'est qu'une hypothèse.

Cinq erreurs fréquentes

  • Choisir le socle avant d'avoir décrit le modèle de données. Une heure de schéma évite un mois de contournements.
  • Ouvrir le compte au nom du prestataire ou d'un salarié. Le projet, le domaine et la facturation appartiennent à l'entreprise, dès le prototype.
  • Confondre palier gratuit et absence de coût. Le palier gratuit est un lieu d'essai, pas un environnement de production pour des données dont vous répondez.
  • Peupler le prototype avec des données clients réelles. Un jeu de test représentatif suffit, et évite d'exposer des données personnelles dans un environnement moins protégé.
  • Reporter la question de la sauvegarde à la mise en production. Un prototype qui a déjà convaincu les utilisateurs part en production plus vite que prévu, souvent tel quel.

Pour une PME qui prototype une application métier destinée à durer, nous partons dans la majorité des cas sur un socle bâti autour de PostgreSQL, en service géré pendant la phase de prototype, avec la possibilité d'internaliser ensuite. La rapidité d'un service géré sert l'exploration, le caractère standard de la base protège l'exploitation. Vous pouvez voir comment nous menons cette phase sur notre page prototypes rapides.

Questions fréquentes

Peut-on garder un BaaS en production, ou faut-il forcément migrer ensuite ?

On peut très bien rester dessus des années. La migration ne s'impose que si le coût au compteur devient imprévisible, si une contrainte de localisation des données apparaît ou si la logique métier déborde de ce que la plateforme sait exprimer.

Un socle auto-hébergé comme PocketBase convient-il à une application interne ?

Oui pour un outil interne à faible concurrence, avec une équipe capable d'assurer les mises à jour et la sauvegarde. Tenez compte du fait que le projet est encore en série 0.x et que son interface de programmation peut évoluer entre deux versions.

Combien de temps un BaaS fait-il vraiment gagner sur un prototype ?

De l'ordre de deux à quatre semaines sur la plomberie initiale : comptes, droits, stockage de fichiers, interface d'administration. Ce gain porte sur le démarrage, pas sur la logique métier, qui reste à écrire dans tous les cas.

Comment vérifier qu'un service géré héberge bien les données en Europe ?

Regardez la région sélectionnée sur le projet lui-même, pas la page commerciale, puis demandez l'accord de traitement des données et la liste des sous-traitants. Choisissez la région à la création : la changer ensuite relève d'une migration.

Faut-il choisir le même socle pour le prototype et pour la version définitive ?

Ce n'est pas obligatoire, mais changer de socle coûte plusieurs semaines. Si le prototype a des chances sérieuses d'aller en production, autant retenir dès le départ un socle que vous accepteriez de garder.

Vous hésitez sur le socle technique de votre futur prototype, ou vous voulez un avis sur celui qui est déjà en place ? Parlons de votre projet, nous vous dirons franchement ce qui tient et ce qui risque de vous bloquer.