Airtable et Postgres : le chemin conçu dès le jour un

Voici la thèse, réfutable : les limites publiées de l'API Airtable ne sont pas des contraintes à subir, ce sont des spécifications d'architecture. Lues correctement, elles décrivent le système à construire : une couche opérationnelle où le métier travaille — Airtable — et une couche de scale où vivent le volume et les applications — Postgres, chez nous via Supabase. Le pipeline entre les deux n'est pas une sortie de secours qu'on improvise sous pression. C'est un composant qu'on conçoit dès le premier jour, au même titre que le schéma de données.

Cette architecture hybride repose sur un partage des rôles net. Airtable excelle là où il a été conçu pour exceller : interfaces éditables par le métier, vues, automatisations, extensions — l'équipe reste autonome dans son outil, en temps réel. Postgres excelle ailleurs : SQL arbitraire, volumétrie, isolation par tenant, accès concurrents depuis des applications web. « Every Supabase project gets a full Postgres database », écrit Supabase : pas une abstraction, le moteur complet.

La suite documente ce contrat d'API, les quatre patterns du pipeline, et la preuve en production.

Voici ce que publient les pages officielles d'Airtable au 12 août 2026 :

La ligne la plus importante n'est pas dans ce tableau : c'est une phrase de la documentation des rate limits. « If you anticipate a higher read volume, we recommend using a caching proxy. » L'éditeur désigne lui-même la couche de lecture externe comme le pattern prévu. Utiliser Airtable comme backend d'applications Next.js à fort trafic, c'est précisément construire ce proxy — et le construire en Postgres plutôt qu'en cache éphémère, pour gagner les jointures, les agrégations et la sécurité niveau ligne.

C'est le raisonnement au cœur de notre façon de construire : lire les limites publiées d'une plateforme comme des specs, et concevoir avec elles, pas contre elles.

1. Réplication programmée. La documentation PostgreSQL décrit la réplication logique en modèle publish/subscribe : snapshot initial, puis flux incrémental fondé sur une identité de réplication. Airtable n'expose pas de log de transactions ; l'équivalent s'obtient avec une tâche planifiée qui lit les changements et les upserte dans Postgres. Deux orchestrateurs remplissent ce rôle : pg_cron côté Supabase, ou des scheduled tasks Trigger.dev avec déduplication.

2. Source de vérité par domaine. Le sens du flux est un choix par table, pas une religion. Les contacts appartiennent à Airtable et se répliquent vers Postgres ; les événements applicatifs naissent dans Postgres et remontent en agrégats. Supabase publie d'ailleurs un foreign data wrapper Airtable — les tables s'interrogent en SQL, en lecture seule et sans pushdown de filtres : idéal pour explorer, un argument de plus pour la réplication programmée en production.

3. IDs stables. Le record ID Airtable (« rec… ») est immuable — il « cannot be altered in any way ». Stocké comme clé externe dans Postgres, il rend chaque upsert idempotent. Dans l'autre sens, l'API d'écriture supporte l'upsert natif :

{
  "performUpsert": { "fieldsToMergeOn": ["external_id"] },
  "records": [{ "fields": { "external_id": "crm-4812", "statut": "actif" } }]
}

Zéro correspondance crée, une seule met à jour, plusieurs font échouer la requête. L'idempotence est câblée dans les deux sens.

4. Conventions de schéma transportables. Pagination par 100, types de champs, champs calculés exclus du merge : tout impose un mapping explicite entre les deux couches. Ce mapping est un livrable en soi — nous avons expliqué pourquoi dans le schéma est le livrable. Chez nous, il est stocké comme configuration dans Airtable même : le métier voit et gouverne ce qui se synchronise.

L'objection classique : « et la latence ? ». Elle suppose que tout doit être temps réel. Or le métier travaille déjà en temps réel, dans Airtable. Seule la couche de lecture est concernée, et sa fraîcheur se règle domaine par domaine.

Trois mécanismes documentés se combinent. Les webhooks Airtable envoient un ping minimal ; le contenu se récupère par un appel séparé, en livraison at-least-once avec jusqu'à 13 tentatives sur environ un jour — et un refresh à automatiser : un webhook expire après 7 jours sans rafraîchissement. La réplication programmée fixe le rythme de fond : horaire pour un référentiel, quotidien pour l'historique. Côté application, l'ISR de Next.js pilote la revalidation : revalidate = 60 pour du contenu chaud, revalidatePath à la demande quand le pipeline vient d'écrire ; en cas d'échec, la dernière version générée reste servie.

Pour situer : le CDC classique capture les changements depuis le log de transactions, dans l'ordre, en at-least-once. Webhooks et réplication programmée en tiennent lieu ici, avec la même exigence d'écritures idempotentes : les doublons de livraison sont normaux.

Ce que ça coûte de ne rien faire — Une application branchée en direct sur l'API partage les 5 req/s de la base avec toutes les automatisations existantes ; chaque pic de trafic se paie en statuts 429 et 30 secondes d'attente. Sur le plan Team, le quota de 100 000 appels par mois se consomme en lectures redondantes, puis tout le trafic est ralenti à 2 req/s jusqu'au 1er du mois. Et quand la base approche 50 000 records, la couche de scale se construit dans l'urgence — au pire moment.

Nous opérons ce modèle. Huit applications de production Next.js + Supabase + Vercel — SaaS, portails, dashboards — sont alimentées par ce type de pipeline, sur plus de trente projets livrés (données internes Ownward, 2026).

Le pipeline est un moteur de synchronisation piloté par mapping : du Python orchestré sur Trigger.dev, configuration stockée dans Airtable. Il relie six CRM/ERP — HubSpot, Oscar, Dynamics 365, Hyperplanning, YPAREO en SOAP, et Airtable — vers un référentiel unique. Une nouvelle source, c'est un nouveau mapping, pas du nouveau code ; et zéro re-saisie manuelle. Le choix de l'orchestrateur suit les cinq critères détaillés dans quand industrialiser une automatisation.

Et Airtable dans tout ça ? Il reste la couche où le métier est chez lui. En un an, nous y avons construit dix-sept extensions custom avec le SDK officiel (JavaScript/React standard), dont un CRM complet avec téléphonie, emails templatés et cartes interactives. Adoption immédiate, précisément parce que l'équipe n'a jamais quitté son outil (données internes Ownward, 2026).

Notre grille de départ : elle se discute domaine par domaine, mais elle évite la décision par défaut — tout dans une seule couche.

Colonne de droite, toujours la même exigence : clé stable (rec-ID ou clé externe), écriture par upsert, reprise sans doublon.

Cette architecture a un coût fixe : un pipeline est du logiciel, avec son monitoring, ses reprises sur erreur et sa maintenance. En dessous d'une certaine échelle — une base, pas d'application externe, des lectures faibles — Airtable seul suffit, et c'est très bien ainsi. La coexistence introduit aussi une latence de réplication assumée : les cas exigeant une cohérence forte en lecture se traitent domaine par domaine, parfois en lisant la source directement. Enfin, deux couches signifient deux modèles à garder alignés ; sans mapping explicite et versionné, la dérive de schéma est une question de mois. Ce n'est pas un argument contre le pattern — c'est son prix, et il se budgète.