Quelle base de données pour son MVP : tableur, Airtable ou Supabase ?

Introduction

Vous avez un parcours utilisateur en tête, peut-être même une maquette. Reste une question qui paraît technique mais qui engage la suite : où vont être stockées vos données ? Liste de clients, commandes, réservations, profils : tout produit, même minuscule, a besoin d'un endroit fiable pour les ranger, les retrouver et les protéger.

Pour une première version, trois familles de solutions reviennent sans cesse : le simple tableur, une base « tableur amélioré » comme Airtable, et une vraie base de données comme Supabase (qui repose sur Postgres). Ce guide compare ces trois voies sur des critères de fondateur, pas d'ingénieur : le temps pour démarrer, les limites à connaître, la sécurité et le coût du changement plus tard.

Ce que la base de données change pour votre MVP

Pour tester une idée, la meilleure base de données est celle que vous pouvez mettre en place en une demi-journée et abandonner sans regret. Mais trois besoins reviennent dès que de vrais utilisateurs arrivent :

• Des comptes séparés : chaque personne ne doit voir que ses propres données.
• Des volumes qui grossissent : quelques dizaines de lignes au départ, plus ensuite si le test fonctionne.
• Des échanges avec le reste de l'outil : votre application lit et écrit dans la base, et cela suppose une connexion programmée, avec ses propres limites.

Posez ces trois questions avant de choisir : *qui doit voir quoi ? combien de lignes dans six mois ? qui écrit dans la base, des humains ou des programmes ?* Les réponses orientent presque tout.

Option 1 : le tableur

Un tableur partagé est la solution la plus rapide : vous le connaissez déjà, il ne demande aucun apprentissage, et beaucoup de projets de test commencent ainsi, avec des formulaires qui alimentent une feuille.

Il convient tant que l'application n'est pas encore une application : vous recueillez des demandes, vous les triez à la main, vous répondez par e-mail. Il atteint ses limites dès que vous avez besoin de droits d'accès par utilisateur, de relations entre plusieurs tables (un client, ses commandes, leurs lignes) ou de saisies que des programmes doivent effectuer sans erreur. À ce stade, vous bricolez des contournements : mieux vaut passer à l'étape suivante.

Option 2 : Airtable, le tableur qui se comporte comme une base

Airtable ressemble à un tableur mais gère des tables reliées entre elles, des formulaires, des vues filtrées et des automatisations. C'est un bon choix quand votre équipe, pas vos utilisateurs, travaille dans la base : suivi de candidatures, catalogue, planning interne. Votre outil no-code lit ensuite ces données.

Deux limites officielles méritent d'être connues avant de s'engager :

• Le nombre d'enregistrements par base dépend de l'offre. D'après la page officielle des offres, il est de 1 000 enregistrements par base en offre gratuite, 50 000 en offre Team et 125 000 en offre Business en libre-service. Une limite par table existe aussi, mais elle est comprise dans celle de la base.
• Le débit de l'API : la documentation indique 5 requêtes par seconde et par base. Au-delà, le service répond par une erreur 429 et demande d'attendre 30 secondes avant de réessayer.

Ce que cela veut dire concrètement : un petit test avec quelques dizaines d'utilisateurs reste très au large. En revanche, une application dont chaque page appelle la base à chaque affichage peut atteindre le plafond de débit bien avant le plafond de lignes. Si vous prévoyez des pics de trafic (un lancement, une campagne), simulez-les avant.

Autre point de vigilance, qui relève de notre analyse : Airtable sert avant tout à des équipes qui travaillent dans la base. Si le besoin « chacun voit uniquement ses données » est central, la séparation entre utilisateurs devra être construite côté application ; regardez alors l'option suivante.

Option 3 : Supabase, une vraie base avec des comptes intégrés

Supabase fournit une base Postgres, un système de connexion et une API prête à l'emploi. C'est le choix naturel quand vos utilisateurs se connectent et manipulent leurs propres données : espace client, application de réservation, outil d'équipe.

Sur le plan des coûts, la page des tarifs indique pour l'offre gratuite 500 Mo de base de données par projet et 2 projets actifs, avec une mise en pause des projets gratuits après une semaine d'inactivité. L'offre Pro démarre à 25 dollars par mois et inclut 8 Go de disque par projet. Pour un test, la pause est le point à surveiller : un projet gratuit mis en pause peut rendre votre application indisponible, ce qui est gênant le jour où un prospect clique sur votre lien. Vérifiez dans la documentation comment le réactiver.

Le point de sécurité qu'il ne faut pas manquer

La sécurité d'une application Supabase repose sur les règles d'accès ligne par ligne, appelées Row Level Security (RLS). La documentation officielle les décrit comme des règles d'autorisation précises qui s'exécutent dans la base elle-même, et recommande de les activer sur chaque table d'un schéma exposé. Une fois activées, aucune donnée n'est accessible par l'API avec une clé publique tant qu'aucune règle n'a été créée.

Pour un non-technique, retenez ceci : une table sans règle d'accès bien pensée est soit inaccessible, soit trop ouverte. Quand une application générée par l'IA fonctionne « du premier coup », vérifiez que ces règles existent. Nous détaillons ce contrôle, et cinq autres, dans notre guide pour sécuriser une application créée avec l'IA.

Comparer les trois options en un coup d'œil

Comment choisir : trois règles simples

1. Vos utilisateurs ne se connectent pas encore ? Un tableur ou Airtable suffit. Gardez votre énergie pour parler à vos premiers clients, pas pour configurer une base. 2. Votre équipe saisit, l'application affiche ? Airtable est confortable, tant que le trafic reste modéré. 3. Chacun doit voir ses propres données ? Partez directement sur Supabase, pour ne pas migrer à chaud avec de vrais utilisateurs.

Le principe sous-jacent : la base de données est l'élément le plus coûteux à changer après le lancement. Les écrans se refont en quelques jours ; des données déjà collectées, reliées et utilisées demandent une migration soignée. Mieux vaut donc choisir un cran au-dessus de votre besoin immédiat que d'attendre le premier incident.

Préparer un changement de base sans douleur

Même avec le bon choix, vous changerez peut-être de base si le test réussit. Trois habitudes rendent ce passage moins douloureux :

• Nommez clairement vos tables et vos colonnes dès le départ, sans abréviations personnelles.
• Une information, un endroit : évitez de recopier la même donnée dans plusieurs tables.
• Exportez régulièrement vos données dans un fichier, pour pouvoir repartir de zéro en cas d'erreur de manipulation.

Pour replacer ce choix dans l'ensemble de votre stack, consultez le comparatif no-code, low-code et code assisté par l'IA et le guide sur le mode de connexion de vos utilisateurs, qui s'appuie sur la même base.

Checklist avant d'ouvrir l'accès à vos premiers utilisateurs

• Vous savez répondre à : qui doit voir quoi, combien de lignes dans six mois, qui écrit dans la base.
• Si vous utilisez Airtable : vous avez estimé le nombre d'appels par page et vérifié qu'il reste sous 5 requêtes par seconde et par base.
• Si vous utilisez Supabase : chaque table a ses règles d'accès, testées avec deux comptes différents.
• Votre offre (gratuite ou payante) ne mettra pas l'application en pause le jour du lancement.
• Vous avez fait un export complet de vos données.

Questions fréquentes

Peut-on lancer un MVP uniquement avec un tableur ?

Oui, tant que le produit consiste surtout à recueillir et traiter des demandes à la main. Dès que des comptes utilisateurs, des droits d'accès ou des automatisations fiables entrent en jeu, une vraie base devient préférable.

Airtable ou Supabase pour une application avec des comptes clients ?

Supabase est plus adapté quand chaque utilisateur doit voir uniquement ses propres données, grâce à ses règles d'accès ligne par ligne. Airtable convient mieux à des données gérées par votre équipe.

Quelle est la limite d'Airtable à connaître en premier ?

Le débit de l'API : 5 requêtes par seconde et par base, selon la documentation officielle. Le plafond de lignes, qui dépend de l'offre, vient ensuite.

Mon assistant IA peut-il choisir et configurer la base à ma place ?

Il peut proposer une structure et écrire le code de connexion, mais il ne vérifiera pas toujours les règles d'accès ni les limites de votre offre. Demandez-lui explicitement ces points, puis testez avec deux comptes.

Sources

• Airtable, « Rate limits » : https://airtable.com/developers/web/api/rate-limits
• Airtable, « Airtable plans » : https://support.airtable.com/docs/airtable-plans
• Supabase, « Row Level Security » : https://supabase.com/docs/guides/database/postgres/row-level-security
• Supabase, « Pricing » : https://supabase.com/pricing