Airtable ou PostgreSQL et application web : le tableau comparatif
Airtable est un tableur relationnel en ligne, très accessible. Une application sur mesure repose sur une vraie base de données (PostgreSQL chez YMHB Web) et des écrans conçus pour chaque usage. Les écarts portent moins sur l'interface que sur ce qui se passe en dessous.
| Critère | Airtable | Application sur mesure (PostgreSQL) |
|---|---|---|
| Volume par base | Plafond d'enregistrements selon l'offre (1 000 en Free, 50 000 en Team, 125 000 en Business) | Pas de plafond contractuel, dimensionnement selon le serveur |
| Facturation | Par collaborateur propriétaire, créateur ou éditeur (commentateurs aussi sur l'offre Team) ; lecture seule non facturée | Pas de coût par utilisateur, hébergement et maintenance |
| Droits d'accès | Par espace, base ou interface ; filtrage « utilisateur connecté » configuré page par page | Règles par rôle et par ligne, appliquées dans la base elle-même |
| Intégrité des données | Champs typés, liens entre tables, peu de contraintes | Clés étrangères, contraintes d'unicité, transactions |
| Logique métier | Formules, automatisations, scripts | Code versionné et testé automatiquement |
| API | 5 requêtes par seconde et par base, plus un quota mensuel sur les offres Free et Team | Conçue pour vos volumes |
| Mise en route | Immédiate | Cadrage, maquettes, construction |
Les volumes : quand la base approche du plafond
Chaque offre Airtable fixe un nombre maximal d'enregistrements par base, ainsi qu'un volume de stockage pour les pièces jointes. Une base qui suit des interventions, des commandes ou des mesures quotidiennes l'atteint plus vite qu'on ne l'imagine : quarante interventions par jour, chacune avec cinq lignes de pièces, produisent 240 enregistrements par jour (40 fiches et 200 lignes), soit 60 000 sur 250 jours ouvrés, au-delà du plafond de l'offre Team.
Les contournements habituels ont tous un coût : archiver les anciennes années dans une autre base (et perdre l'historique dans les recherches), changer d'offre, ou découper l'activité en plusieurs bases synchronisées. Dans une base PostgreSQL, des centaines de milliers de lignes restent un volume ordinaire, et l'historique complet reste interrogeable.
Les droits d'accès : qui voit quoi ?
C'est souvent la vraie raison de migrer. Dans Airtable, les droits se donnent par espace de travail, par base ou par interface. Les interfaces permettent de restreindre l'affichage aux enregistrements où l'utilisateur connecté figure dans un champ, mais la documentation précise que ce filtrage se configure page par page : une autre page ou une autre interface ne l'hérite pas.
Pour un portail où chaque client ne doit voir que ses dossiers, ou un réseau d'agences où chaque responsable ne voit que ses équipes, ce modèle devient fragile : une page oubliée suffit à exposer des données. Dans une application sur mesure, la règle « un client ne voit que ses lignes » est écrite une fois, dans la base, et s'applique à tous les écrans et à l'API. C'est le principe de la sécurité au niveau des lignes de PostgreSQL. La page portail client et extranet montre l'usage typique.
La logique métier : formules contre code testé
Airtable gère bien les calculs simples : un total, une date d'échéance, un statut déduit. Les difficultés commencent avec les règles qui engagent plusieurs tables à la fois. Exemple : valider une commande doit décrémenter le stock, réserver un créneau de livraison et bloquer le client s'il dépasse son encours. Dans Airtable, cela devient une chaîne d'automatisations ; si l'une échoue au milieu, la base reste dans un état incohérent.
Une base relationnelle exécute ces opérations dans une transaction : tout passe, ou rien ne passe. Et le code qui porte la règle est versionné et testé à chaque mise à jour, ce qu'une automatisation modifiée dans une interface ne permet pas.
Le coût : quand la facturation par éditeur pèse
Airtable facture les collaborateurs qui peuvent modifier les données, et sur l'offre Team ceux qui peuvent seulement commenter. Tant que trois personnes saisissent et que les autres consultent, le coût reste contenu. Il grimpe dès que les techniciens, les commerciaux ou les chefs d'équipe doivent mettre à jour un enregistrement depuis le terrain : chacun devient un collaborateur facturé. Une application sur mesure ne facture pas par utilisateur, ce qui change le calcul pour les organisations où beaucoup de personnes saisissent un peu.
Dans quels cas garder Airtable, dans quels cas migrer ?
Gardez Airtable si la base est de taille modeste, si les personnes qui la modifient sont peu nombreuses et proches, si une erreur de saisie n'a pas de conséquence grave et si personne d'extérieur n'y accède.
Migrez si au moins deux de ces situations se présentent :
- la base approche du plafond d'enregistrements de votre offre ;
- des clients, partenaires ou franchisés doivent accéder à une partie seulement des données ;
- des règles métier impliquent plusieurs tables et ne doivent jamais échouer à moitié ;
- le nombre de collaborateurs facturés augmente chaque trimestre ;
- d'autres logiciels interrogent la base plus vite que l'API ne le permet.
Comment se passe une migration d'Airtable vers PostgreSQL ?
Une migration réussie ne se contente pas de copier les tables. Elle suit quatre étapes.
- Inventaire : tables, champs, liens, formules, automatisations, interfaces et personnes qui utilisent chacune.
- Modélisation : on profite de la migration pour corriger le modèle (champs texte qui contiennent des listes, doublons, tables fourre-tout).
- Reprise vérifiée : les données sont importées, contrôlées champ par champ, puis synchronisées pendant la transition. C'est la méthode appliquée lors du passage de MongoDB à Supabase pour Cap Vert : aucune donnée supprimée, bascule quand le client donne son accord.
- Bascule : les équipes passent sur la nouvelle application, Airtable reste en lecture seule le temps de vérifier.
La position de YMHB Web
YMHB Web construit des applications web sur PostgreSQL, souvent avec Supabase. Si votre base Airtable fonctionne et reste loin de ses limites, nous vous conseillerons de la garder. Quand elle devient un risque, nous construisons une application web sur mesure qui reprend vos données et vos habitudes, en commençant par les écrans les plus utilisés. Le cas d'une base Access ou FileMaker est traité sur la page migrer Access ou FileMaker vers le web.
Questions fréquentes
- Combien d'enregistrements peut contenir une base Airtable ?
- Le nombre d'enregistrements d'une base Airtable est plafonné selon l'offre souscrite : 1 000 enregistrements par base en offre Free, 50 000 en offre Team et 125 000 en offre Business, d'après la documentation d'Airtable. Les offres négociées avec le service commercial suivent d'autres conditions. Ces plafonds sont à vérifier sur la page officielle, car ils peuvent évoluer.
- Airtable convient-il pour un portail client ?
- Airtable permet d'afficher à chaque utilisateur connecté les seuls enregistrements où il figure, via les interfaces. Mais ce filtrage se configure page par page, ce qui rend un portail client fragile dès qu'il compte plusieurs écrans. Pour un portail où chaque client ne doit voir que ses données, une application sur mesure qui applique la règle dans la base est plus sûre.
- Quelle est la limite de l'API Airtable ?
- L'API Airtable est limitée à 5 requêtes par seconde et par base, quelle que soit l'offre. Les offres Free et Team ajoutent un quota mensuel d'appels. Pour des synchronisations fréquentes avec un ERP, un site e-commerce ou une application mobile, cette limite oblige à regrouper ou espacer les échanges, et peut justifier une base de données dédiée.
- Peut-on migrer d'Airtable vers PostgreSQL sans perdre de données ?
- Oui, à condition de procéder par étapes : inventaire des tables et des automatisations, nouveau modèle de données, import contrôlé champ par champ, puis synchronisation pendant la transition. Airtable reste consultable en lecture seule jusqu'à la validation. Les pièces jointes et l'historique demandent une attention particulière, car ils se transfèrent différemment des champs simples.
- Une application sur mesure coûte-t-elle plus cher qu'Airtable ?
- Une application sur mesure coûte plus cher à construire qu'un abonnement Airtable. En revanche, elle ne facture pas chaque collaborateur qui modifie des données et n'impose pas de plafond d'enregistrements par base. Le calcul devient favorable quand beaucoup de personnes saisissent, que les volumes grossissent ou que des erreurs de données ont un coût réel pour l'activité.