PocketBase

Ce qu'est réellement PocketBase

La plupart des backends relèvent de l'assemblage : une base de données quelque part, un service d'authentification à côté, un stockage d'objets pour les envois, une petite interface d'administration qu'on compte toujours écrire, et la colle entre tout cela. PocketBase ramène l'ensemble à un processus et un fichier sur le disque. Vous téléchargez un exécutable pour votre plateforme, vous le lancez, vous ouvrez l'interface dans le navigateur, vous définissez vos collections, et votre application a une API : pas d'orchestration de conteneurs, pas de base gérée, pas de fournisseur d'authentification séparé, et rien à configurer avant que la première requête fonctionne.

Le compromis est visible et assumé. Comme la base est embarquée plutôt qu'accessible par le réseau, tout le backend est un processus tenant un fichier SQLite, ce qui explique à la fois pourquoi il est si simple à exploiter et pourquoi la montée en charge horizontale devient une autre conversation qu'ailleurs. Pour l'étape où se trouvent la plupart des lecteurs de cette page — une application sans utilisateurs, ou avec quelques centaines — ce compromis penche nettement de votre côté, et il y reste bien plus longtemps qu'on ne l'imagine.

• Une base embarquée avec abonnements en temps réel. SQLite à l'intérieur du binaire, plus une API d'abonnement pour que les clients reçoivent les changements au moment où ils surviennent au lieu de les réclamer. Une interface qui se met à jour toute seule devient la valeur par défaut, et non un projet.
• Utilisateurs et fichiers, intégrés. L'authentification et la gestion des utilisateurs sont fournies, la gestion des fichiers aussi. Les deux fonctions qui, dès le premier jour, poussent d'ordinaire à souscrire un service tiers sont donc déjà là.
• Une interface d'administration et une API de style REST. Une interface web pour définir les collections, éditer les enregistrements et inspecter les données, au-dessus d'une API HTTP que les SDK officiels enveloppent. Le SDK JavaScript couvre les navigateurs, Node.js et React Native ; un SDK Dart existe pour Flutter et le bureau.
• Un seul exécutable portable. Les binaires précompilés utilisent un pilote SQLite écrit en Go pur et se construisent avec CGO désactivé : ils se compilent donc de façon croisée vers une liste publiée de cibles Linux, macOS, Windows, FreeBSD, OpenBSD et NetBSD. Déployer, c'est copier un fichier et le lancer.

Deux façons de le faire tourner, et le choix compte plus tard

La première est l'application autonome. Téléchargez la version pour votre plateforme, décompressez, lancez la commande serve, c'est tout. Les exécutables précompilés embarquent aussi une machine virtuelle JavaScript, ce qui permet d'ajouter des hooks et des points d'entrée personnalisés en JavaScript sans toucher à Go ni recompiler quoi que ce soit. C'est la voie qui met un prototype devant quelqu'un cet après-midi, et y rester est parfaitement raisonnable.

La seconde est la bibliothèque Go. Vous importez PocketBase dans un programme à vous, vous enregistrez des routes et de la logique métier sur ses événements de cycle de vie, puis vous compilez le résultat — votre code et le backend entier — en un unique exécutable lié statiquement. L'exemple minimal du README fait une quinzaine de lignes. La raison de le savoir dès le premier jour, c'est qu'il s'agit de la sortie de secours : l'application autonome ne devient pas un mur lorsque votre logique dépasse ce qui se configure, parce que le même projet est aussi le framework en dessous. Les prérequis sont modestes, actuellement Go 1.27 ou plus récent pour compiler.

Où cela s'insère dans la pile de croissance d'un fondateur

PocketBase est un outil pour construire, pas pour croître : sa contribution à la croissance est donc indirecte, et il vaut mieux la nommer honnêtement. Il supprime les semaines qui séparent une idée d'une chose dans laquelle un inconnu peut se connecter. Cela compte, parce que presque rien de ce qu'on peut apprendre sur la demande n'est accessible avant ce point. Ce qu'il ne fait pas, c'est amener qui que ce soit vers ce que vous avez construit.

• Pour une première version qui fonctionne. Authentification, stockage et base de données en un seul téléchargement, c'est le chemin honnête le plus court d'un prototype vers quelque chose devant quoi poser une vraie page de connexion. Si vous faites le front avec des outils d'IA, quelle est la meilleure façon de promouvoir une application faite en vibe coding prend le relais là où la construction s'arrête.
• Pour les outils internes que vous ne voulez pas payer. Une liste d'attente, un calendrier éditorial, un suivi de prospection, un CRM léger pour vos cinquante premières conversations. Les collections et l'interface d'administration en couvrent une part étonnante sans devenir un produit à entretenir.
• À côté de la couche de croissance, pas à sa place. Rien ici n'écrit votre positionnement, ne publie quoi que ce soit ni ne répond à un client. Une fois le produit existant, le travail change entièrement de forme — comment obtenir mes 100 premiers utilisateurs est le problème suivant, et c'est le plus dur.
• Savoir ce que vous adoptez. La licence est MIT et le README autorise explicitement l'usage commercial, y compris la vente d'un service bâti dessus. C'est aussi un projet d'avant la 1.0, avec des ruptures attendues, et le dépôt limite temporairement les pull requests aux contributeurs déjà en place à cause d'une vague de soumissions automatisées de faible qualité : prévoyez d'ouvrir des tickets plutôt que des correctifs.

Ce que nous avons appris en exploitant SQLite en production

Nous ne sommes pas neutres ici, et c'est justement la partie utile : AgentCeres fait tourner SQLite en production aussi, ce qui suit relève donc d'une décision que nous avons prise et non d'une critique extérieure. Ce qu'un backend en un seul fichier change surtout, c'est que l'endroit où vit ce fichier devient toute votre architecture. Le nôtre reposait sur un volume monté, et la panne que nous rencontrions sans cesse était que tout ce qu'un conteneur avait écrit sans que personne ne l'ait poussé vers un stockage durable ne survivait tout simplement pas au déploiement suivant. Cela ne s'annonçait jamais comme une erreur non plus : cela se présentait comme une application ayant silencieusement oublié quelque chose, ce qui est la pire manière dont une perte de données puisse arriver.

La deuxième surprise fut que la ressource rare était le volume lui-même, et non l'espace disque dessus. Notre hébergeur plafonne le nombre de volumes par projet, et nous avons touché ce plafond bien avant toute limite de capacité, ce qui a fini par imposer une refonte : les conteneurs sont devenus jetables et l'état durable a migré vers une base de données et un stockage d'objets qui leur survivent. Si vous faites tourner un PocketBase pour un produit, cela ne vous atteindra jamais. Si vous vous surprenez à en vouloir un par client, comptez les volumes avant de concevoir autour.

La troisième est propre à SQLite et nous a coûté un après-midi sincèrement déroutant. Le typage de SQLite est souple : nous stockions des horodatages sous forme d'entiers dans certaines colonnes et de texte dans d'autres, et les comparaisons entre ces deux formes ne renvoient aucune erreur — juste les mauvaises lignes, en silence, dans une requête qui se lit comme correcte. PocketBase gère son propre schéma, vous en êtes donc largement protégé jusqu'au moment où vous écrivez vos propres requêtes ou vos propres extensions Go contre le même fichier ; à partir de là, le problème devient le vôtre. Choisissez une fois pour toutes votre format de stockage et vérifiez le type de la colonne avant de faire confiance à une comparaison.