Tout le monde compare les modèles. Lequel code le mieux, lequel rédige le mieux, lequel coûte le moins cher. Presque personne ne parle de l'endroit où ces modèles travaillent.

C'est pourtant là que ça se joue. Entre une IA qui impressionne en démo et une IA sur laquelle vous appuyez votre exploitation pendant un an, la différence ne vient pas du modèle. Elle vient du contexte métier qu'on lui donne, et de l'accès qu'elle a à des données d'entreprise de qualité.

Ce que l'IA sait faire, et ce qu'elle ne sait pas faire
Le modèle raisonne. Tout le reste, il faut le lui fournir.

Deux manières de nourrir une IA

Pour qu'une IA travaille sur votre business, il faut lui donner deux choses de nature très différente. La plupart des gens n'en donnent qu'une.

  • Du contexte métier, pour ce qui s'explique et qui bouge peu : vos outils, vos règles, votre façon de faire.
  • Une base de données structurée, pour ce qui se compte et qui bouge tout le temps : vos clients, vos ventes, vos échéances.

Le premier répond à « comment on travaille ici ». La seconde répond à « où en est-on aujourd'hui ». Aucun des deux ne remplace l'autre, et c'est justement là que la plupart des projets IA se plantent.

Contexte métier : le dossier qu'on donne à un stagiaire

La première couche, ce sont des fichiers de contexte en Markdown. Imaginez le dossier que vous prépareriez pour quelqu'un qui reprend votre poste.

Vous y mettez ce qu'un nouveau doit savoir avant de toucher à quoi que ce soit :

  • les outils que vous utilisez, et comment on s'y connecte (chez moi par API la plupart du temps) ;
  • vos sociétés, et qui gère quoi dans chacune ;
  • vos interlocuteurs : votre comptable, votre banque, vos prestataires ;
  • comment les outils se relient entre eux, votre Zendesk avec votre Stripe par exemple.

Ce sont des informations qui bougent peu et qui s'expliquent en prose. Du texte suffit très bien.

Base de données : tout ce qui est une liste

La seconde couche, ce sont vos données. Vos clients, vos ventes, vos baux, vos commandes. Tout ce qui change vite en contenu, mais presque jamais en forme.

Beaucoup de gens s'arrêtent avant, parce que la première couche est celle que les outils IA rendent facile. Un dossier de .md, deux ou trois skills, et on croit avoir fini. Sauf que si votre activité est un minimum répétitive, si vous vendez régulièrement des biens ou des services pris dans un catalogue, vous avez besoin de savoir ce que vous avez vendu, à qui, et quand.

Essayez de garder ça dans des fichiers texte. Vous n'y arriverez pas. Rien ne garantit que le fichier client de janvier ait la même structure que celui de juin. La qualité de la donnée n'est plus contrôlée par personne. Et le jour où vous voulez une statistique, une analyse ou une automatisation qui tienne, il faut relire tous les fichiers un par un et normaliser après coup ce qui aurait dû l'être avant.

Les deux couches : contexte en Markdown, données en base
Le texte explique le métier. La base retient les faits.

Trois exemples, dont deux que je fais tourner pour moi

  • Création de contenu. Le .md décrit le ton, la structure d'un bon script, ce que je ne dis jamais. La base contient les sujets, les angles, les statuts, les dates de publication.
  • Gestion immobilière. Le .md décrit comment on traite un impayé, un préavis, une réparation urgente. La base contient les biens, les baux, les locataires, les loyers reçus.
  • Commandes fournisseurs. Le .md explique comment on commande, ce qui se négocie, où sont les risques. La base contient les fournisseurs, les produits, les réceptions.

L'intérêt de ce couple, c'est qu'il dit très précisément à l'IA ce qu'elle doit savoir pour manipuler vos données, sans lui laisser trop de liberté. Elle sait quoi faire. Elle sait où le mettre.

Ce qui manque vraiment à un LLM

Prenons le problème par le manque. Un modèle de langage raisonne très bien et se plante sur quatre points, tous les quatre indispensables dès qu'on passe en exploitation.

Il n'a pas de mémoire fiable

Chaque conversation repart de zéro. Vous pouvez réexpliquer votre business tous les matins, il ne s'en souviendra pas mieux le lendemain.

Les outils ont bien ajouté une mémoire automatique, et c'est là que ça devient pervers. Elle retient des choses que vous ne vouliez pas garder. Elle grossit toute seule. Au bout de quelques semaines, plus personne ne la relit ni ne la valide, et on finit par la réinitialiser en bloc pour repartir propre.

Un fichier de contexte que vous écrivez, c'est l'inverse : chaque modification passe par vous. Une base aussi. L'agent y écrit, mais dans des champs que vous avez définis, et vous voyez ce qui a changé. La mémoire cesse d'être un dépôt qui gonfle dans un coin.

Il n'a pas de contrat

Laissez un modèle écrire une date, il vous sortira quatre formats dans la même session. Demandez-lui un statut, il inventera des variantes.

Un champ typé, un single-select avec ses options définies, c'est une contrainte, pas une suggestion. L'agent ne peut pas écrire « en cours de traitement » dans un champ qui n'accepte que trois valeurs. Cette rigidité qu'on trouve pénible quand on construit sa base devient votre meilleur garde-fou dès qu'une IA écrit dedans.

Il ne connaît pas vos liens

Il devine que Dupont est probablement le client du projet 42, par ressemblance de texte. Il devine, et vous n'avez aucun moyen de savoir quand il s'est trompé.

Une relation entre deux tables ne se devine pas : elle est posée dans la donnée. Ce client, ces projets, ces factures. L'agent ne reconstruit rien, il suit.

Personne ne voit ce qu'il a fait

Un agent agit, et par défaut ça disparaît. Airtable apporte les permissions, l'historique de révision, la possibilité d'un statut « à valider » et une interface où un humain tranche avant que ça parte.

Vous ne confieriez pas un dossier sensible à une nouvelle recrue sans jamais repasser derrière. Il n'y a aucune raison de le faire avec un agent.

Les quatre manques du LLM et ce qu'une base apporte
Colonne gauche : ce qui manque au modèle. Colonne droite : ce qu'une base structurée pose.

Airtable a fait le travail de son côté

Le raisonnement ci-dessus vaudrait pour n'importe quelle base propre, y compris une base SQL. Sauf qu'une base SQL, vos équipes ne l'ouvrent pas. Elles ne voient pas ce que l'agent vient d'écrire, et elles ne peuvent pas le corriger sans passer par un développeur.

C'est là qu'Airtable prend l'avantage : la même donnée reste manipulable par un humain, dans une vue ou une interface, sans intermédiaire. Le reste suit, parce qu'Airtable s'est rendu branchable et qu'il a pris à sa charge une partie du travail d'explication.

Trois portes d'entrée

Porte d'entrée Pour Contre
API REST Rien à installer, toujours à jour, c'est la voie de tout ce qui tourne en production. L'IA doit connaître l'API. Soit vous chargez la doc dans son contexte, soit elle invente des endpoints.
Serveur MCP Connexion en un clic, l'outil découvre seul ce qu'il sait faire, et Airtable le met à jour sans rien vous demander. Chaque outil disponible occupe de la place dans le contexte, en permanence, y compris ceux dont vous ne vous servez jamais.
CLI L'agent va chercher la commande au moment où il en a besoin. Le contexte reste léger, et tout se scripte et se rejoue. À installer et à maintenir. Airtable le marque explicitement comme expérimental.

Vous n'avez pas à choisir aujourd'hui, et c'est tout l'intérêt. Les trois tapent sur les mêmes données, avec les mêmes permissions. Vous changez de porte quand votre usage change, sans toucher à ce qu'il y a derrière.

Attention quand même à une idée reçue : le MCP n'est pas une version allégée de l'API. Les deux surfaces ne se recouvrent pas.

  • Ce que le MCP fait et pas l'API REST : créer des interfaces et des pages d'interface, créer et modifier des automatisations, revenir en arrière sur une action.
  • Ce que l'API REST fait et pas le MCP : les webhooks, l'envoi de pièces jointes, et tout l'administratif d'entreprise (journaux d'audit, gestion des utilisateurs, partages, espaces de travail).
  • Le CLI, lui, expose exactement le MCP. Il interroge le même serveur, donc il a strictement les mêmes capacités, ni plus ni moins.

Deux limites à connaître côté MCP : une automatisation créée par l'IA arrive en brouillon et c'est vous qui l'activez, et une page d'interface se crée mais ne se modifie pas encore.

Le vocabulaire spécifique à Airtable est déjà fourni

Airtable publie aussi des skills prêts à l'emploi, dans son dépôt public github.com/Airtable/skills. Huit à ce jour, et le dépôt bouge vite.

Deux d'entre eux forment le socle :

  • airtable-overview explique le modèle de données : ce qu'est une base, une table, un champ, un enregistrement, une vue, une automatisation, une interface. Il vaut quelle que soit la porte d'entrée que vous utilisez.
  • airtable-filters apprend à l'IA à construire une requête qui tienne : quel opérateur pour quel type de champ, comment viser une option de single-select, comment écrire une plage de dates. Il est écrit pour les outils du serveur MCP, donc il vaut aussi pour le CLI. En API REST pure, il ne vous servira pas.

Les six autres vont plus loin : comment se comporter dans une base, et des schémas métier tout faits pour le commercial, le marketing et le produit. J'y consacre un article à part.

Le résultat compte plus que le détail : vous n'avez plus à expliquer à une IA ce qu'est un champ lié ou une formule. C'est livré. Vous ne décrivez que ce qui est propre à votre base et à votre métier.

Ce qui va survivre à tout ça

Un dernier point, et c'est le plus important pour moi. Tout ce que vous installez aujourd'hui côté IA va bouger, et pas qu'un peu :

  • le protocole, MCP aujourd'hui, autre chose demain ;
  • le client que vous avez choisi, Claude Code, Codex ou ce qui sortira l'an prochain ;
  • les bonnes pratiques du moment, qui changent tous les trimestres ;
  • votre découpage en skills et en commandes.

Dans dix-huit mois, une partie sera obsolète et le reste aura un nom qu'on ne connaît pas encore.

Deux choses vont rester. Vos fichiers de contexte, parce qu'ils décrivent comment vous travaillez et pas avec quel outil. Le jour où vous changez de modèle ou de protocole, ils se rechargent tels quels.

Et vos données, si elles sont correctement structurées. Une table clients avec des champs typés et des relations propres a la même valeur quel que soit l'agent qu'on branche dessus. Elle en a même sans agent du tout.

Mettez donc votre énergie dans ces deux couches, et considérez tout le reste comme du câblage temporaire. Choisir Airtable ici, ce n'est pas parier sur l'outil IA à la mode. C'est ranger vos données dans un format qui survivra aux outils.

Ce qui bouge et ce qui reste
Le câblage change tous les six mois. Le métier et les données, non.

En résumé

Une IA n'a pas besoin qu'on la rende plus intelligente. Elle a besoin d'un endroit sérieux où travailler : du texte pour le contexte stable, une base pour tout ce qui vit. Airtable lui apporte les quatre choses qui lui manquent : la mémoire, le contrat, le sens des liens, et le contrôle.

On ne demande pas à l'IA d'être fiable. On lui donne un endroit où elle ne peut pas faire n'importe quoi.

Est-ce que ça vous intéresse que je détaille comment je gère ça de mon côté, concrètement ? Dites-le moi en commentaire et j'en fais un article dédié.