Développer des interfaces Airtable sur mesure avec le SDK (en code agentique)

Depuis fin 2025, je consacre une part croissante de mon activité au développement agentique. Le paysage a un peu changé : un peu moins de No-Code « pur », davantage de développement assisté par IA, et beaucoup de tests pour cerner les nouvelles contraintes et les nouvelles limites de ces outils.

Dans ce mouvement, de nombreuses plateformes proposent désormais une approche mixte, à mi-chemin entre le No-Code et le code sur mesure (le « vibe coding »). Airtable ne fait pas exception avec ses Custom Extensions : elles permettent de construire des interfaces qui vont bien au-delà des éléments natifs de l’Interface Designer, avec une liberté quasi totale.

Dans cet article, je partage un retour d’expérience sur ces extensions sur mesure : les deux méthodes pour les construire, comment démarrer avec le SDK, et surtout quelques détails pratiques tirés de mes premières mises en œuvre, qui ne sautent pas aux yeux à la lecture du tutoriel et qui font gagner du temps.

Deux méthodes : l’agent Omni ou le SDK

Pour créer une extension custom, Airtable propose deux voies.

Option 1 : Passer par Omni (l’agent IA d’Airtable)

Omni génère le code de l’extension à partir d’une description en langage naturel. C’est très efficace pour tester et pour réaliser des interfaces simples en une ou deux itérations.

La limite arrive vite : dès qu’on veut itérer davantage, l’agent doit réécrire le code complet à chaque passe. C’est lent, le version control devient difficile, et l’approche montre ses limites pour les besoins un peu complexes.

Option 2 : Développer en code « traditionnel » avec le SDK

La seconde voie consiste à développer en code classique, c’est-à-dire, en 2026, en code agentique avec Claude Code, Codex ou un autre outil. Pour cette approche, il est nécessaire de s’appuyer sur le SDK Airtable (les Interface Extensions). On retrouve alors un vrai projet local, versionnable, avec toute la souplesse du développement web (React).

Démarrer avec le SDK

Le tutoriel officiel décrit les étapes dans l’ordre. En résumé :

1. Installer la CLI

npm install -g @airtable/blocks-cli

2. Enregistrer une clé API avec le bon scope (block:manage) :

block set-api-key

3. Déclarer une extension dans le builder hub. On récupère ici l’identifiant de l’extension (blkXXXXX).

4. Initialiser le repo local à partir d’un template :

block init NONE/blkXXXXX \
  --template=https://github.com/Airtable/interface-extensions-hello-world \
  test-extension-hello-world

À partir de là, le squelette du projet est en place et on peut commencer à développer.

Les détails appris à l’usage

C’est ici que se trouve l’essentiel du retour d’expérience : quelques points qui ne sont pas évidents au premier abord et qui peuvent faire perdre du temps.

Le mode dev passe par une interface Airtable, pas par un npm run dev

Il n’y a pas d’équivalent à npm run dev pour faire tourner l’extension isolément dans le navigateur. À la place, block run lance un serveur de développement (sur localhost), mais pour voir l’extension en cours de développement, il faut :

1. Créer une interface dans Airtable, de type Custom ;
2. Y choisir l’extension enregistrée sur le builder hub ;
3. Activer le mode dev, qui va alors charger votre extension via un embed du serveur localhost.

Autrement dit, le rendu se fait toujours à l’intérieur d’Airtable, dans le contexte réel d’une interface, et non dans une fenêtre de navigateur autonome.

Pas de skill officiel pour les agents de code

Il n’existe pas de skill officiel Airtable dédié au développement avec le SDK. Le block init fournit bien un jeu de Cursor rules et de Windsurf rules, mais pour les autres outils (Claude Code par exemple), le plus simple est de recréer un fichier AGENTS.md ou CLAUDE.md en reprenant le contenu du fichier de règles Cursor.

L’extension ne voit que la donnée que vous lui exposez

Une interface custom peut être branchée sur une ou plusieurs tables. Pour chaque table, on choisit les champs visibles (comme pour les interfaces natives), et on peut appliquer des filtres à la source ainsi que des filtres dropdown natifs en haut de page.

L’extension n’a accès qu’à cette donnée : uniquement les tables déclarées, les champs cochés et la donnée laissée par les filtres source ou dropdown. Deux conséquences pratiques :

• Penser à exposer toutes les données nécessaires (tables et champs) à l’interface, sinon le code ne pourra tout simplement pas y accéder.
• Filtrer la donnée dès que possible : toute la donnée exposée est chargée côté interface, donc plus le périmètre est restreint, plus les temps de chargement sont fluides.

Anticiper les champs manquants avec une bannière (plutôt qu’une erreur obscure)

Conséquence directe du point précédent : si un champ attendu par le code est masqué ou supprimé dans la configuration de l’interface, on se retrouve facilement avec une erreur peu lisible. Une astuce que je recommande d’ajouter directement dans le AGENTS.md / CLAUDE.md du projet :

Système « champs non disponibles » : déclarer le schéma attendu (tables +
fields avec id et label lisible), le résoudre au démarrage via
`base.getTableByIdIfExists` et `table.getFieldIfExists` (qui renvoie `null`
si le field est masqué dans la page de l'interface ou supprimé), puis afficher
une bannière listant les tables/champs manquants par table pour que le builder
les rende visibles ; le reste du code doit rester null-safe (aucun accès à un
field non résolu).

On obtient ainsi une bannière claire indiquant les problèmes de données à corriger, plutôt qu’un plantage difficile à diagnostiquer pour la personne qui configure l’interface.

Custom properties : utiles pour le réutilisable, superflues pour le cas unique

Le SDK propose un système de custom properties, très utile pour des extensions réutilisables sur plusieurs bases (par exemple une nouvelle dataviz ou un type de graphique générique).

En revanche, pour une interface dédiée à un seul cas d’usage, ce mécanisme alourdit inutilement le développement initial. Dans ce cas, je privilégie de simples constantes dans le code.

Aller plus loin : donner le contexte de la base à l’agent

Dernier conseil : quand on développe en code agentique, il est très utile de laisser l’agent récupérer directement le contexte de la base (les identifiants de champs, les types, etc.) via le MCP ou la CLI Airtable. L’agent travaille alors avec les vrais field ID plutôt qu’à l’aveugle.

En résumé

Les Custom Extensions d’Airtable comblent un vrai manque : aller au-delà des composants natifs sans quitter l’écosystème Airtable. Deux approches coexistent :

• Omni pour prototyper vite et couvrir les cas simples ;
• le SDK dès qu’on a besoin d’itérer, de versionner et de gérer des besoins plus complexes, d’autant plus pertinent à l’ère du code agentique.

Le SDK demande quelques ajustements de méthode (mode dev via une interface Airtable, gestion fine de la donnée exposée, garde-fous sur les champs manquants), mais une fois ces réflexes acquis, c’est une base solide pour livrer des interfaces vraiment sur mesure.

---

Vous avez un projet Airtable : structuration d’une base, automatisations, ou une interface custom à développer avec le SDK ? C’est exactement le type de chantier que j’accompagne. Parlons-en.

Discuter de votre projet Airtable ↗