Pourquoi Airtable s'installe partout
Airtable réussit pour une raison précise : il donne à une équipe métier le pouvoir de modéliser ses propres données. Tables liées, champs typés, vues filtrées par utilisateur, automatisations simples. En une après-midi, un référentiel existe, il est partagé, et il est déjà plus fiable que les six fichiers de tableur qu'il remplace.
Cette autonomie a une valeur réelle. Sur des données qui changent souvent, faire passer chaque modification de structure par un développeur est un gaspillage. Airtable supprime ce goulot, et c'est pour cela qu'il se diffuse sans que personne ne l'ait décidé.
Les quatre murs
Le volume. Chaque abonnement fixe une limite de lignes par base. Elle paraît lointaine, puis elle arrive, et il n'existe pas de solution propre à l'intérieur de l'outil : on découpe en plusieurs bases, on perd les liaisons, on recopie à la main.
Les droits. Un collaborateur voit une base ou ne la voit pas. Restreindre l'accès aux seules lignes qui le concernent n'est pas possible. Dès que le référentiel contient des données de plusieurs clients, de plusieurs agences ou de plusieurs salariés, c'est bloquant.
La cohérence. Rien n'empêche une suppression accidentelle, un doublon ou une valeur incohérente. Il n'y a pas de contrainte d'intégrité, pas de transaction. Sur un référentiel de contacts, c'est un désagrément. Sur un référentiel de commandes, c'est un incident.
Le débit. L'interface de programmation limite le nombre d'appels par seconde. Une application qui interroge Airtable à chaque affichage de page épuise le quota immédiatement, et il n'y a pas d'option pour l'augmenter au-delà d'un certain point.
Ce que PostgreSQL apporte, et ce qu'il retire
PostgreSQL lève les quatre murs d'un coup : volume, droits jusqu'au niveau de la ligne, contraintes d'intégrité et transactions, débit dimensionné par votre infrastructure. Le coût ne dépend plus du nombre d'utilisateurs, et l'hébergement peut être souverain.
Ce qu'il retire est tout aussi net : l'autonomie. Une base PostgreSQL sans interface n'est utilisable par personne dans une équipe métier. C'est le vrai coût de la bascule, et il est souvent sous-estimé dans les comparaisons.
Le compromis qui marche
La bonne réponse est rarement binaire. Le schéma qui fonctionne le mieux consiste à faire de PostgreSQL la source de vérité et à garder une interface de saisie confortable au-dessus : un back-office sur mesure, ou un outil d'administration comme Directus qui offre une ergonomie proche du tableur sur une vraie base.
Les équipes gardent leur confort, le produit gagne une fondation solide, et la question du plafond ne se repose plus. Le moment de faire cette bascule est celui où le référentiel cesse d'être un outil d'équipe pour devenir une dépendance de votre exploitation. Ce basculement de statut arrive presque toujours sans que personne ne l'ait décidé, ce qui explique qu'il soit constaté trop tard.
