Interface Designer, extension custom ou app externe : trois économies

Toute base Airtable bien modélisée pose vite la même question : quelle interface donner à ceux qui s'en servent ? Trois réponses existent, qui se distinguent moins par leur rendu que par leur économie.

Notre thèse : choisir entre Airtable Interface Designer, extension custom et application externe est un arbitrage coût/audience/complexité — pas une préférence esthétique. Chaque option gagne dans son cas d'usage ; aucune ne gagne partout.

La suite déplie chaque colonne, puis les rassemble dans un arbre de décision. Tous les tarifs ont été constatés le 12 août 2026 sur les pages officielles.

Interface Designer est disponible sur tous les plans Airtable. On y assemble des vues métier sans écrire de code — du front-end no-code au sens strict : une équipe autonome livre une interface en quelques heures (timeline et partage hors base restent payants).

L'économie se joue ailleurs : Airtable se facture au siège. La lecture seule est gratuite ; toute permission d'édition est un siège facturé.

Une interface « incluse » pour 25 opérationnels qui saisissent, c'est donc 500 à 1 125 $/mois de sièges — la mécanique détaillée dans le calcul du siège.

Vers l'extérieur, deux mécanismes. Les interfaces se partagent avec des collaborateurs « interface-only », sans accès à la base sous-jacente (jusqu'à 5 000 par interface) ; le partage public d'une page se fait en lecture seule, sur workspace payant. Et les Portals, add-on par packs de sièges : dès 120 $/mois les 15 sièges sur Team, un portail par base.

Interface Designer gagne quand l'audience est interne, déjà équipée en sièges, et que le besoin est une vue métier livrée vite : le coût marginal du front est alors nul.

Les extensions — des composants qui ajoutent visuels ou fonctionnalités à une base — existent sur tous les plans payants. Le Blocks SDK, public sur GitHub sous licence propre à Airtable, permet d'en construire sur mesure : composants fonctionnels et hooks React, Node.js 22+, un CLI dédié.

block release                # publication privée aux collaborateurs de la base
block add-remote             # déclarer une base cible supplémentaire (beta)
block release --remote prod  # déployer sur plusieurs bases

L'économie : une extension releasée en privé est accessible aux collaborateurs de la base, sans review ni licence logicielle additionnelle. Son coût, c'est le développement — et lui seul. Son audience est bornée aux sièges déjà payés : rien de plus sur la facture de licences, mais pas d'audience élargie non plus.

C'est le bon outil quand l'audience est déjà l'équipe. Nous avons construit 17 extensions custom en production en un an, dont un CRM complet — téléphonie Aircall, emails templatés, SMS et WhatsApp, cartes interactives — directement dans la base (données internes Ownward, 2026). Adoption immédiate, pour une raison simple : personne n'a quitté son outil de travail.

Deux points documentés : le déploiement multi-bases passe par les « remotes » du CLI, encore en beta ; et les extensions supposent de rester sur plan payant.

L'API web d'Airtable est conçue pour intégrer les données « avec n'importe quel système externe » : REST, JSON, personal access tokens ou OAuth avec scopes. Une application externe parle à la base avec un seul token ; ses utilisateurs finaux ne sont pas des collaborateurs Airtable et ne coûtent aucun siège.

L'économie s'inverse : le coût devient fixe, découplé de l'audience — que l'application serve 50 ou 5 000 utilisateurs. Ordre de grandeur, constaté le 12 août 2026 :

Le vrai poste est le développement d'une application complète : auth, droits, déploiement, maintenance.

Une contrainte d'architecture s'ajoute. L'API est limitée à 5 requêtes/seconde par base et 50 par token, avec des quotas mensuels par plan — 100 000 appels sur Team, illimités sur Business. Au-delà de quelques utilisateurs simultanés, le pattern à retenir est la réplique : l'application lit un référentiel synchronisé, pas la base en direct. Nos 8 applications de production Next.js/Supabase/Vercel — portails, dashboards, SaaS multi-tenant — s'appuient ainsi sur un moteur de synchronisation reliant six CRM/ERP à un référentiel unique (données internes Ownward, 2026). Cette discipline fait partie de notre façon de construire.

L'application externe gagne quand l'audience dépasse les murs de la base : clients, partenaires, multi-tenant, visibilité par domaine. En dessous, elle est surdimensionnée.

Ce que ça coûte de ne rien faire — Servir 30 externes via des sièges Editor sur Team, c'est 600 $/mois, 7 200 $/an, là où des Portals à 120 $/mois les 15 sièges ou une app externe à infra fixe (~45 $/mois hors développement) répondent autrement. À l'inverse, développer une application pour 5 internes déjà équipés en sièges, c'est payer développement puis maintenance pour un front qu'Interface Designer livrait en quelques heures.

Cinq questions tranchent la plupart des cas — en gardant en tête que le coût réel d'un abonnement SaaS dépasse la licence.

Si deux lignes divergent, l'audience l'emporte : c'est elle qui fait basculer le modèle économique, pas le confort de l'écran.

Les tarifs, quotas et limites cités sont ceux constatés le 12 août 2026 ; Airtable indique pouvoir faire évoluer ses rate limits, y compris par plan. La frontière exacte des sièges facturés varie selon le plan — formulation sûre : lecture seule gratuite, édition facturée. L'arbre de décision ignore la gouvernance, la conformité et les compétences internes, qui peuvent renverser un arbitrage purement économique. Nos chiffres de production décrivent notre contexte, pas une moyenne du marché. Enfin, les options ne s'excluent pas : beaucoup de déploiements en combinent deux — des interfaces pour l'équipe, une app externe pour les clients.