Airtable est une plateforme applicative nativement IA où il suffit de décrire un besoin en langage courant pour obtenir tables, interfaces, automatisations et agents IA fonctionnant sur les données réelles de l'équipe, avec gouvernance administrateur et conformité d'entreprise.
Vous avez utilisé cet outil ? Notez-le
Vous avez utilisé cet outil ? Notez-le
Airtable est une plateforme qui combine une base de données relationnelle accessible à des utilisateurs métier et une couche d'intelligence artificielle désormais placée au centre du produit. Le message d'accueil du site résume l'intention : « AI transformed individual work. Airtable transforms teamwork. » — l'IA a transformé le travail individuel, Airtable veut transformer le travail collectif. L'entreprise se décrit elle-même comme « the system of record for companies building what's next », c'est-à-dire le référentiel de données des organisations qui construisent ce qui vient ensuite. Cette formulation n'est pas anodine : elle revendique le statut de source de vérité, pas celui d'outil satellite branché à côté d'un ERP ou d'un CRM.
Le 24 juin 2025, une lettre publique du dirigeant de l'entreprise a qualifié la refonte native IA de « refounding moment », un moment de refondation. Le vocabulaire est fort et mérite d'être pris au sérieux dans une évaluation d'achat, parce qu'il décrit une réorganisation du produit et non un ajout cosmétique. Beaucoup d'éditeurs ont greffé un panneau de chat sur une interface existante en 2024 et 2025 ; Airtable revendique explicitement l'inverse, à savoir que l'IA constitue la ligne principale du produit et non une couche complémentaire. Concrètement, cela signifie que la génération d'applications, les agents et l'automatisation ne sont pas des modules optionnels vendus séparément mais des primitives de la plateforme.
Sous cette couche, le socle reste ce qui a fait la réputation d'Airtable : une base de données relationnelle qu'un utilisateur métier peut manipuler sans écrire de SQL. On travaille dans des bases, chaque base contient des tables, chaque table contient des champs typés — texte, nombre, date, sélection, pièce jointe, formule, et surtout champs de liaison qui rattachent un enregistrement d'une table à un ou plusieurs enregistrements d'une autre table. C'est cette capacité de liaison entre tables qui sépare Airtable d'un tableur : dans un tableur, la relation entre deux feuilles est une formule fragile qu'un tri malencontreux peut casser ; dans Airtable, la relation est une propriété structurelle de la donnée.
Cette double nature explique le positionnement commercial. Une équipe qui a dépassé les limites d'une feuille de calcul partagée mais qui ne veut pas — ou ne peut pas — mobiliser une équipe d'ingénierie pour déployer PostgreSQL, une couche d'API et une interface d'administration trouve dans Airtable un compromis. Elle obtient la structure d'une base relationnelle, des interfaces présentables à des utilisateurs finaux, des automatisations, une API REST, une gouvernance des accès, et depuis la refonte IA la possibilité de décrire une application en langage naturel plutôt que de la construire champ par champ.
Il faut néanmoins garder en tête un élément de contexte structurel : le 4 août 2026, Bending Spoons a annoncé un accord définitif en vue d'acquérir Airtable pour une valeur d'entreprise de 1,285 milliard de dollars. L'opération n'est pas conclue à ce jour. Elle reste soumise aux approbations réglementaires et aux conditions de clôture usuelles, la clôture étant attendue plus tard dans l'année, et les deux entreprises continuent d'opérer indépendamment jusque-là. Le produit, la marque et le domaine sont inchangés, mais ce point mérite d'entrer dans l'analyse de toute décision d'achat pluriannuelle.
Omni est l'interface conversationnelle de construction. On décrit en langage courant ce dont on a besoin — un suivi de campagnes marketing, un pipeline de recrutement, un inventaire d'équipements — et Omni génère une application complète : les tables, les champs, les interfaces destinées aux utilisateurs et les automatisations qui les relient. Le point déterminant est que la sortie n'est pas un artefact opaque. Ce qu'Omni produit reste entièrement éditable avec les outils visuels habituels : on ouvre la table générée, on renomme un champ, on change un type, on ajoute une vue, exactement comme si on l'avait construite manuellement. Cela évite l'écueil classique des générateurs qui produisent un résultat impressionnant mais impossible à faire évoluer.
Le second point déterminant est commercial : construire des applications et des agents avec Omni est gratuit et ne consomme pas de crédits IA. C'est une décision de tarification qui compte, parce qu'elle sépare l'acte de conception — itératif, exploratoire, coûteux en essais — de l'acte d'exécution, qui lui est facturé en crédits. On peut donc reconstruire une application dix fois pour trouver la bonne structure sans surveiller un compteur.
Les agents constituent la couche d'exécution. Ils analysent les données, produisent du contenu et mènent des recherches automatiquement et à l'échelle. La forme la plus intégrée est le Field Agent, un agent qui travaille à l'intérieur de chaque enregistrement : au lieu de traiter un lot de données dans un script externe, la logique s'exécute ligne par ligne, au niveau du champ, là où la donnée vit.
Les autres formes couvrent des tâches identifiables. L'analyse documentaire examine des contrats ou des factures et signale les points d'alerte. La recherche web enrichit des prospects, analyse des concurrents et résume l'actualité d'un secteur. La traduction et la génération d'images complètent l'ensemble. Un aspect opérationnel important : ces agents peuvent être configurés pour se déclencher automatiquement à chaque ajout ou mise à jour de données. Ce n'est donc pas un assistant qu'on sollicite manuellement, c'est un traitement qui s'attache au cycle de vie de l'enregistrement.
Les automatisations reposent sur un modèle déclencheur-action sans code : un événement se produit, une suite d'actions s'exécute. Pour les cas qui dépassent ce que l'éditeur visuel exprime, la logique est extensible en JavaScript, ce qui offre une porte de sortie propre sans imposer d'écrire du code pour les cas simples. Des connexions natives existent vers Slack, Google Workspace et des outils comparables, ce qui permet de faire sortir l'information de la base plutôt que d'obliger chacun à venir la consulter.
L'Interface Designer sert à construire et partager des interfaces personnalisées sans code, et surtout à décider qui voit quoi. C'est une distinction structurante par rapport à un tableur partagé : un commercial peut consulter sa propre liste d'opportunités sans accéder à la table de rémunération, un prestataire externe peut renseigner un formulaire sans voir la base complète. Airtable précise que certaines fonctionnalités, en particulier autour des permissions, sont réservées à certains niveaux tarifaires — un point à vérifier au moment de l'évaluation plutôt qu'après le déploiement.
Le volet gouvernance a été construit pour des acheteurs qui doivent répondre à une direction de la sécurité. Les administrateurs pilotent l'usage de l'IA et activent l'IA au niveau de l'espace de travail, contrôlent les données auxquelles les agents accèdent, et l'ensemble de l'activité est gouverné et auditable. Les niveaux entreprise ajoutent un panneau d'administration, des journaux d'audit, une gestion des clés de chiffrement de niveau entreprise et des dispositifs de prévention de la fuite de données.
HyperDB adresse le problème du volume. Ce composant synchronise et met à l'échelle des jeux de données comptant plus de 100 millions d'enregistrements. Il faut cependant le situer correctement : il s'agit d'une capacité de niveau entreprise, pas d'un correctif applicable aux limites d'enregistrements des offres inférieures.
Avant, une équipe marketing suit ses campagnes dans une feuille de calcul partagée : une ligne par campagne, des colonnes pour le budget, les dates, le responsable, et une colonne « assets » contenant des liens vers un stockage externe. Les briefs vivent dans un traitement de texte, les validations dans une chaîne d'e-mails, et personne ne sait avec certitude quelle version d'un visuel est la version approuvée.
Après, la campagne devient un enregistrement lié à des tables distinctes : une table de contenus, une table de canaux, une table de parties prenantes. Chaque contenu porte son statut de validation, ses pièces jointes et son lien vers la campagne parente. Une interface dédiée présente au directeur marketing le portefeuille de campagnes sans lui donner accès aux détails d'exécution, tandis qu'une autre interface donne au rédacteur uniquement la file des contenus qui lui sont assignés. Une automatisation notifie Slack quand un contenu passe en attente de validation. Un agent de traduction produit les variantes linguistiques d'un texte validé au moment où son statut change.
Avant, les candidatures arrivent par e-mail et par un formulaire, les CV s'accumulent dans un dossier partagé, et l'évaluation se fait dans un document par poste. Retrouver les candidats évalués six mois plus tôt pour un poste comparable relève de l'archéologie.
Après, chaque candidature est un enregistrement lié à un poste, lui-même lié à un service et à un responsable du recrutement. Les entretiens forment une table séparée liée aux candidatures, ce qui permet à un candidat d'avoir plusieurs entretiens sans dupliquer son enregistrement. Un agent d'analyse documentaire lit le CV joint et en extrait les éléments structurés qui alimentent des champs dédiés. Les évaluateurs saisissent leurs retours via une interface qui ne leur montre que les candidats qu'ils doivent voir, sans exposer les prétentions salariales ni les évaluations de leurs collègues.
Avant, un commercial reçoit une liste de sociétés avec un nom et une adresse web. Il ouvre chaque site, cherche l'effectif, le secteur, l'actualité récente, et recopie manuellement le résultat. L'opération prend plusieurs minutes par ligne et la qualité dépend de la fatigue de l'opérateur.
Après, l'ajout d'un prospect déclenche un agent de recherche web qui rassemble le contexte public disponible et le consigne dans des champs structurés, avec un résumé rédigé. Le commercial arrive sur une fiche déjà documentée et concentre son temps sur la qualification réelle plutôt que sur la collecte. L'important est que le résultat atterrisse dans des champs de la base et non dans une conversation de chat éphémère : il devient filtrable, triable, exploitable dans une vue et disponible via l'API.
Avant, un service juridique ou financier reçoit des documents, quelqu'un les lit, note les échéances dans un agenda et signale les clauses inhabituelles dans un e-mail. Le suivi dépend de la mémoire d'une personne.
Après, le document est joint à un enregistrement, un agent d'analyse documentaire le parcourt à la recherche de points d'alerte, et le résultat alimente des champs de statut et de risque. Une automatisation crée une tâche de revue quand un signal est détecté et notifie le canal Slack concerné. La différence n'est pas que la machine remplace le juriste — la revue humaine reste nécessaire — mais que le tri initial cesse de constituer un goulot d'étranglement.
Avant, les informations produit sont éclatées entre un tableur de références, un dossier d'images, un document de spécifications techniques et les connaissances non écrites de deux personnes. Chaque lancement provoque une chasse à l'information.
Après, le produit est un enregistrement central lié aux fournisseurs, aux composants, aux marchés de distribution et aux ressources visuelles. Les champs de recherche et d'agrégation remontent automatiquement les informations des tables liées : le coût total d'un produit se calcule à partir des composants liés plutôt que d'être saisi à la main. Une interface donne à l'équipe commerciale une fiche produit consultable, une autre donne à l'équipe achats la vue fournisseurs. Une automatisation avertit quand une fiche est incomplète à l'approche d'une date de lancement.
Avant, les demandes internes arrivent par messagerie instantanée, par e-mail et parfois oralement. Rien n'est tracé, les priorités sont arbitrées par le volume sonore, et personne ne peut répondre à la question « combien de demandes avons-nous traitées ce trimestre ».
Après, un formulaire alimente une table de demandes ; une interface donne au demandeur la visibilité sur l'état de sa demande sans lui ouvrir la base ; une autre donne à l'équipe destinataire une file de travail priorisée. Les automatisations gèrent les accusés de réception et les relances. Le bénéfice mesurable est la traçabilité : la charge devient une donnée plutôt qu'une impression.
Modéliser avant de générer. Même si Omni produit une structure en quelques secondes, il est payant de poser sur papier les entités du domaine et leurs relations avant de lancer la génération. La description fournie à Omni sera plus précise, et la revue du résultat sera plus rapide parce qu'on saura ce qu'on cherche.
Traiter les limites d'enregistrements comme une contrainte de conception, pas comme un détail. Les quotas s'appliquent par base : 1 000 enregistrements sur l'offre gratuite, 50 000 sur Team, 125 000 sur Business. Une base qui accumule des données transactionnelles — journaux d'événements, lignes de commande, historiques — atteindra ces seuils bien plus vite qu'une base qui stocke des entités métier. Il vaut mieux décider dès la conception ce qui vit dans Airtable et ce qui reste dans un système en amont.
Surveiller la consommation de crédits dès le premier jour. Chaque action consomme un nombre variable de crédits selon les données d'entrée, le modèle sélectionné et les données de sortie. Un agent déclenché à chaque mise à jour d'enregistrement sur une table active a un profil de coût très différent d'un agent déclenché manuellement. Mesurer sur un échantillon avant de généraliser évite les surprises en fin de mois.
Comprendre que les crédits sont mutualisés. L'allocation mensuelle par utilisateur payant est mise en commun à l'échelle de l'espace de travail sur Free et Team, et à l'échelle de l'organisation sur Business et Enterprise Scale, plutôt que réservée par personne. Une équipe qui lance un traitement massif peut donc épuiser l'allocation partagée par d'autres équipes. Une convention interne sur les traitements de volume et une surveillance de la consommation valent mieux qu'un arbitrage a posteriori.
Utiliser la gratuité d'Omni pour itérer. Puisque la construction d'applications et d'agents avec Omni ne consomme pas de crédits, il n'y a aucune raison de se contenter de la première structure générée. Reformuler la demande, comparer plusieurs structures et retenir la plus lisible est une démarche sans coût direct.
Restreindre le périmètre de données des agents. Les administrateurs contrôlent ce à quoi les agents accèdent. Le réflexe par défaut devrait être de donner l'accès minimal nécessaire à la tâche, non par méfiance mais parce qu'un périmètre restreint produit des résultats plus pertinents et des factures plus prévisibles.
Gérer le coût par siège de manière explicite. La facturation est par utilisateur : chaque collaborateur ayant besoin d'un accès en modification augmente le coût, et les discussions dans la communauté font régulièrement état de factures inattendues après l'attribution désinvolte de droits d'édition. Une revue périodique des accès en modification, avec conversion en accès lecture ou en accès via interface pour ceux qui n'éditent pas réellement, est une hygiène de base.
Prévoir la revue humaine comme une étape du processus. Les applications générées par Omni nécessitent toujours une relecture humaine, et les sorties des agents également. Formaliser cette étape — un champ de statut « à valider », une vue dédiée, un responsable désigné — la rend systématique plutôt que dépendante de la vigilance individuelle.
Les équipes opérationnelles qui ont dépassé le tableur. C'est le public historique et il reste central. Quand une feuille partagée compte plusieurs onglets reliés par des formules de recherche fragiles, que plusieurs personnes saisissent en même temps et qu'un tri malencontreux désaligne des colonnes, le passage à une structure relationnelle résout un problème réel et immédiat.
Les équipes marketing et contenu. La combinaison de pièces jointes, de statuts de validation, de calendriers et d'interfaces destinées à des parties prenantes non techniques correspond directement aux besoins d'une production éditoriale ou d'un plan de campagne. Les agents de traduction et de génération d'images s'insèrent naturellement dans ces flux.
Les équipes commerciales et revenue operations. L'enrichissement automatique de prospects, la structuration d'un pipeline et le partage sélectif d'informations avec la direction commerciale répondent à un besoin classique. Airtable ne remplace pas un CRM d'entreprise établi, mais il couvre les processus périphériques que le CRM traite mal.
Les ressources humaines et le recrutement. Le recrutement est intrinsèquement relationnel — candidats, postes, entretiens, évaluateurs — et souffre particulièrement du stockage en documents séparés. La possibilité de restreindre ce que chaque évaluateur voit répond à une exigence de confidentialité réelle.
Les équipes produit et opérations. Le suivi de fournisseurs, de composants, de références et de ressources associées bénéficie directement des champs de liaison et d'agrégation, qui suppriment les recopies manuelles et les incohérences qui en découlent.
Les constructeurs d'outils internes sans profil technique. Le profil du responsable opérationnel qui doit livrer un outil utilisable par vingt personnes sans passer par une file d'attente d'ingénierie correspond exactement à ce qu'Omni et l'Interface Designer visent.
Les organisations soumises à des exigences de conformité. Les certifications SOC 2 Type 2, ISO/IEC 27001:2022, ISO/IEC 27701:2019, HIPAA et TX-RAMP Level 2, l'option de stockage des données dans l'Union européenne et la possibilité pour les clients entreprise de stocker les données au repos avec leurs propres clés répondent à des exigences fréquentes des directions sécurité.
Les entreprises avec de très grands volumes de données de référence. HyperDB, en synchronisant et mettant à l'échelle des jeux de données de plus de 100 millions d'enregistrements, adresse un cas que les quotas des offres inférieures ne peuvent pas couvrir. Ce public est par construction celui des niveaux entreprise.
Le navigateur est l'environnement principal, sans installation. C'est là que se trouve l'expérience complète : construction de bases, Interface Designer, configuration des automatisations et des agents, administration. Pour la majorité des utilisateurs, la question du client à installer ne se pose donc pas.
Airtable propose par ailleurs des applications de bureau et mobiles. En revanche, les notes des magasins d'applications, les tailles des paquets et les versions minimales de système d'exploitation n'ont pas pu être confirmées de manière indépendante (à vérifier). Il est donc recommandé de consulter directement les fiches officielles des magasins avant tout déploiement qui dépendrait de contraintes de parc — par exemple un parc mobile administré avec une version de système figée.
L'API web suit une sémantique REST, encode les objets en JSON et utilise des codes de statut HTTP standard. Ce choix la rend prévisible pour toute équipe ayant déjà intégré une API moderne : les conventions sont celles attendues, sans protocole propriétaire à apprendre. Les quotas d'appels dépendent de l'offre : 1 000 appels par espace de travail et par mois sur l'offre gratuite, 100 000 sur Team, et un volume illimité sur Business. Cette progression est déterminante pour tout projet d'intégration : une synchronisation bidirectionnelle avec un système externe consomme des appels beaucoup plus vite qu'un export ponctuel, et le quota de l'offre gratuite ne permet qu'un usage exploratoire.
L'offre Free comprend 1 000 enregistrements par base, 1 Go de pièces jointes par base, 2 semaines d'historique des révisions et des instantanés, et 1 000 appels d'API par espace de travail et par mois. Ce périmètre convient à l'évaluation, à un projet personnel ou à un prototype. Les deux semaines d'historique constituent la limite la plus sous-estimée : une erreur détectée après un mois n'est plus récupérable par cette voie.
L'offre Team est à 20 dollars par utilisateur et par mois en facturation annuelle. Elle porte les quotas à 50 000 enregistrements par base, 20 Go de pièces jointes, 1 an d'historique des révisions et 100 000 appels d'API par espace de travail et par mois. C'est le point d'entrée réaliste pour une équipe qui fait tourner un processus en production, notamment grâce à l'année d'historique qui change la nature du filet de sécurité.
L'offre Business est à 45 dollars par utilisateur et par mois en facturation annuelle, avec 125 000 enregistrements par base, 100 Go de pièces jointes, 1 an d'historique des révisions et un nombre d'appels d'API illimité. La levée du plafond d'API est souvent le facteur décisif : dès qu'une intégration synchronise en continu avec un autre système, un quota mensuel devient une contrainte d'architecture.
L'offre Enterprise Scale relève d'une tarification sur mesure établie selon les besoins et l'échelle de l'organisation. C'est à ce niveau que se situent le panneau d'administration, les journaux d'audit, la gestion des clés de chiffrement de niveau entreprise, la prévention de la fuite de données, HyperDB, le choix des modèles activés et le stockage des données au repos avec des clés détenues par le client.
Les crédits IA suivent une logique distincte. Chaque offre attribue une allocation mensuelle par utilisateur payant, mise en commun à l'échelle de l'espace de travail sur Free et Team, et à l'échelle de l'organisation sur Business et Enterprise Scale, plutôt que réservée individuellement. Chaque action consomme un nombre variable de crédits selon les données d'entrée, le modèle sélectionné et les données de sortie — un point qui rend l'estimation a priori difficile et la mesure empirique nécessaire.
Des packs complémentaires sont disponibles pour les clients en libre-service : 10 000 crédits pour 20 dollars par mois, 100 000 crédits pour 200 dollars par mois, 400 000 crédits pour 800 dollars par mois. À noter enfin, et c'est un élément qui influence sensiblement le coût total : la construction d'applications et d'agents avec Omni est gratuite et ne consomme pas de crédits.
Notion est plus fort comme espace de travail documentaire et de gestion des connaissances. Ses bases de données existent mais servent d'abord à organiser des pages ; quand le besoin porte sur des relations strictes entre entités, des agrégations fiables et une API à fort volume, Airtable reste plus adapté. Le choix se joue souvent sur la question : construit-on un référentiel de données ou une base documentaire ?
Smartsheet se rapproche davantage de la gestion de projet et de portefeuille traditionnelle. Son modèle mental descend du planning et du diagramme de Gantt plutôt que de la base relationnelle. Pour une direction de projet qui raisonne en jalons, dépendances et charge, c'est un terrain plus naturel ; pour un référentiel de données métier, c'est un détour.
Monday.com est d'abord une plateforme de gestion du travail et ensuite une base de données. L'ergonomie est orientée vers le suivi d'activité d'équipe et la visualisation de l'avancement. Le compromis est symétrique de celui d'Airtable : l'adoption par des équipes non techniques est souvent plus rapide, la rigueur du modèle de données plus faible.
Google Sheets associé à Apps Script constitue l'option la moins chère. Elle permet d'aller loin en automatisation grâce au script, mais elle ne fournit ni structure relationnelle ni partage permissionné digne de ce nom : donner accès à une feuille, c'est généralement donner accès à tout ce qu'elle contient. C'est une alternative crédible pour un usage interne à faible enjeu, beaucoup moins quand des tiers doivent accéder à une partie seulement des données.
Baserow et NocoDB sont des options open source auto-hébergeables. Elles deviennent pertinentes quand la localisation des données ou la maîtrise du coût pèse plus lourd que la couche IA : on héberge soi-même, on ne paie pas par siège, et on contrôle entièrement l'infrastructure. La contrepartie est qu'il faut assumer l'exploitation, les sauvegardes et les mises à jour, et qu'on renonce aux agents et à Omni.
Retool vise la construction d'outils internes par-dessus des bases de données existantes. C'est le bon choix quand la donnée vit déjà dans PostgreSQL ou dans un entrepôt et qu'il ne s'agit que de bâtir l'interface. La différence essentielle est qu'il faut écrire du code, ce qui exclut le profil d'utilisateur métier autonome auquel Airtable s'adresse.
La facturation par siège fait croître le coût avec l'effectif, pas avec l'usage. Chaque collaborateur ayant besoin d'un accès en modification s'ajoute à la facture, indépendamment de son intensité d'utilisation. Les discussions dans la communauté font régulièrement remonter des factures inattendues à la suite d'attributions de droits d'édition accordées sans réflexion. Pour une décision d'achat, cela signifie que la projection de coût doit se faire sur la trajectoire d'effectif de l'équipe concernée, et qu'une politique explicite sur qui obtient un accès en modification doit être définie avant le déploiement plutôt qu'après la première facture.
Les limites d'enregistrements s'appliquent par base et se manifestent plus tôt qu'attendu. Mille enregistrements sur l'offre gratuite et cinquante mille sur Team se remplissent rapidement dès que la base accueille des données transactionnelles plutôt que des entités de référence. Le caractère « par base » du quota a une conséquence de conception : découper en plusieurs bases repousse la limite mais fragmente les relations, puisque les liaisons fonctionnent au sein d'une base. Et HyperDB, qui traite le problème du volume, est une capacité de niveau entreprise et non un correctif disponible sur les offres inférieures.
La consommation de crédits IA est variable et facile à sous-estimer. Le nombre de crédits dépend des données d'entrée, du modèle choisi et des données de sortie, ce qui rend toute estimation théorique fragile. La mutualisation aggrave le risque : l'allocation étant partagée à l'échelle de l'espace de travail ou de l'organisation, l'automatisation d'une seule équipe peut épuiser l'enveloppe commune et interrompre les traitements d'autres équipes. Pour un acheteur, la question à poser n'est pas « combien coûte une action » mais « qui peut déclencher des traitements de volume et sous quel contrôle ».
La courbe d'apprentissage est réelle. Le principal obstacle pour un utilisateur venant du tableur n'est pas l'interface, c'est la pensée relationnelle : comprendre pourquoi une information doit vivre dans une table séparée reliée plutôt que dans une colonne supplémentaire, et maîtriser les liaisons, les champs de recherche et les agrégations. Une organisation qui néglige cette marche produit des bases qui reproduisent un tableur avec plus d'étapes, et qui n'apportent aucun des bénéfices structurels attendus. Il faut budgéter de la formation, pas seulement des licences.
Certaines capacités dépendent du niveau tarifaire, en particulier autour des permissions. C'est le point le plus susceptible de créer un écart entre la démonstration et la réalité du déploiement. Une évaluation menée sur un niveau supérieur à celui qui sera acheté peut valider un modèle de partage qui ne sera pas reproductible ensuite. La vérification doit porter précisément sur les scénarios de permissions envisagés, testés au niveau tarifaire réellement prévu.
Le changement d'actionnariat introduit une incertitude à moyen terme. Le 4 août 2026, Bending Spoons a annoncé un accord définitif en vue d'acquérir Airtable pour une valeur d'entreprise de 1,285 milliard de dollars. L'opération n'est pas conclue : elle reste soumise aux approbations réglementaires et aux conditions de clôture usuelles, la clôture est attendue plus tard dans l'année, et les deux entreprises continuent d'opérer indépendamment jusqu'à cette date. Le produit, la marque et le domaine restent inchangés. Pour un achat ponctuel ou un engagement court, l'impact est nul. Pour un engagement pluriannuel, il est raisonnable d'intégrer au raisonnement que l'autorité sur la tarification et la feuille de route pourra évoluer après la clôture, et de négocier les clauses contractuelles en conséquence.
Les applications générées par Omni exigent toujours une relecture humaine. La génération produit une structure de départ cohérente, pas une application validée. Les types de champs, le sens des liaisons, les conditions de déclenchement des automatisations et le périmètre des interfaces doivent être vérifiés avant toute mise en production. Traiter la sortie d'Omni comme un brouillon avancé plutôt que comme un livrable évite le scénario où une erreur de modélisation est découverte après la saisie de plusieurs milliers d'enregistrements.
C'est une base de données relationnelle exposée à travers une interface que des utilisateurs métier peuvent manipuler. La différence essentielle par rapport à un tableur tient aux champs typés et aux liaisons entre tables : un enregistrement d'une table peut être rattaché structurellement à des enregistrements d'une autre table, et cette relation est une propriété des données plutôt qu'une formule de recherche. Les champs de recherche et d'agrégation permettent ensuite d'afficher et de calculer des valeurs provenant des enregistrements liés sans les recopier. La comparaison au tableur reste néanmoins utile pour comprendre l'ergonomie, qui reste celle d'une grille manipulable directement.
Omni est un générateur conversationnel : on décrit en langage courant ce dont on a besoin et il produit une application complète comprenant les tables, les interfaces et les automatisations. La différence avec un assistant de chat tient à la nature de la sortie — Omni ne renvoie pas du texte à recopier, il crée des objets réels dans l'espace de travail. Ces objets restent entièrement éditables avec les outils visuels habituels, ce qui permet de reprendre la main sur n'importe quel élément généré. Enfin, construire des applications et des agents avec Omni est gratuit et ne consomme pas de crédits IA, ce qui autorise l'itération sans surveillance du budget.
Chaque offre payante attribue une allocation mensuelle de crédits par utilisateur payant, mise en commun à l'échelle de l'espace de travail sur Free et Team et à l'échelle de l'organisation sur Business et Enterprise Scale, plutôt que réservée individuellement. Chaque action consomme un nombre variable de crédits selon les données d'entrée, le modèle sélectionné et les données de sortie, ce qui rend l'estimation théorique peu fiable. La bonne pratique consiste à mesurer la consommation sur un échantillon avant de généraliser, et à être particulièrement attentif aux agents configurés pour se déclencher à chaque ajout ou mise à jour de données. Des packs complémentaires existent pour les clients en libre-service : 10 000 crédits à 20 dollars par mois, 100 000 crédits à 200 dollars par mois et 400 000 crédits à 800 dollars par mois.
Non. La position officielle est explicite : les fournisseurs de modèles ne conservent jamais vos données et vos données ne sont jamais utilisées pour l'entraînement de modèles. Sur les offres entreprise, les clients décident en outre quels modèles sont activés, parmi des fournisseurs incluant OpenAI, Anthropic, Meta et d'autres. Les administrateurs contrôlent également les données auxquelles les agents accèdent et activent l'IA au niveau de l'espace de travail, l'ensemble de l'activité étant gouverné et auditable. Pour une direction sécurité, ce sont ces trois leviers combinés — non-rétention, choix des modèles, contrôle du périmètre de données — qui constituent la réponse.
Les certifications annoncées sont SOC 2 Type 2, ISO/IEC 27001:2022, ISO/IEC 27701:2019, HIPAA et TX-RAMP Level 2. Il existe une option de stockage des données dans l'Union européenne, et les clients entreprise peuvent stocker les données au repos avec des clés dont ils sont propriétaires. Les résidents de l'Espace économique européen, du Royaume-Uni et de la Suisse disposent de droits d'accès, de portabilité, de rectification, d'effacement, de limitation, de retrait du consentement et d'opposition ; les résidents des États américains concernés disposent de droits d'accès, de suppression, de correction et de recours. La politique de confidentialité a été mise à jour pour la dernière fois le 15 juillet 2026.
Les limites s'appliquent par base : 1 000 enregistrements sur l'offre gratuite, 50 000 sur Team, 125 000 sur Business. Le caractère « par base » est déterminant, car il signifie que le contournement consiste à répartir les données sur plusieurs bases — au prix de la perte des liaisons, qui fonctionnent à l'intérieur d'une base. Pour les organisations dont le volume dépasse largement ces seuils, HyperDB synchronise et met à l'échelle des jeux de données de plus de 100 millions d'enregistrements, mais il s'agit d'une capacité de niveau entreprise et non d'un correctif applicable aux offres inférieures. En pratique, il faut décider dès la conception quelles données vivent dans Airtable et lesquelles restent dans un système en amont.
L'offre gratuite convient à l'évaluation mais ses 1 000 enregistrements par base et ses 2 semaines d'historique des révisions la rendent inadaptée à un processus critique. L'offre Team, à 20 dollars par utilisateur et par mois en facturation annuelle, apporte 50 000 enregistrements par base, 20 Go de pièces jointes, un an d'historique et 100 000 appels d'API mensuels par espace de travail : c'est le point d'entrée réaliste pour la production. L'offre Business, à 45 dollars par utilisateur et par mois en facturation annuelle, devient nécessaire quand le volume dépasse 50 000 enregistrements par base, quand 100 Go de pièces jointes sont requis, ou surtout quand une intégration continue rend le plafond d'appels d'API contraignant. Il faut également vérifier au niveau tarifaire réellement envisagé les fonctionnalités de permissions, car certaines sont réservées à certains niveaux.
L'API web suit une sémantique REST, encode les objets en JSON et utilise des codes de statut HTTP standard, ce qui la rend prévisible pour une équipe ayant déjà intégré une API moderne. La contrainte principale n'est pas technique mais quantitative : les quotas d'appels sont de 1 000 par espace de travail et par mois sur l'offre gratuite, 100 000 sur Team, et illimités sur Business. Une synchronisation bidirectionnelle continue avec un système externe consomme des appels beaucoup plus vite qu'un export périodique, ce qui pousse souvent les projets d'intégration sérieux vers Business. Il est donc pertinent de dimensionner le volume d'appels attendu avant de choisir l'offre plutôt que de découvrir la contrainte en production.
Pas dans l'immédiat. Le 4 août 2026, Bending Spoons a annoncé un accord définitif en vue d'acquérir Airtable pour une valeur d'entreprise de 1,285 milliard de dollars, mais l'opération n'est pas conclue : elle reste soumise aux approbations réglementaires et aux conditions de clôture usuelles, la clôture est attendue plus tard dans l'année, et les deux entreprises continuent d'opérer indépendamment jusque-là. Le produit, la marque et le domaine sont inchangés. Pour un usage courant ou un engagement de courte durée, il n'y a rien à ajuster. Pour un engagement pluriannuel en revanche, il est prudent d'intégrer au raisonnement que l'autorité sur la tarification et la feuille de route pourra évoluer après la clôture, et de traiter ce point lors de la négociation contractuelle.
Oui, systématiquement. Les applications générées par Omni nécessitent toujours une revue humaine : il faut vérifier que chaque table représente bien une entité unique, que les liaisons pointent dans le bon sens, que les types de champs sont adaptés, et que les conditions de déclenchement des automatisations ne créent pas de boucle. Pour les agents, la vérification porte sur la qualité de sortie mesurée sur un échantillon représentatif avant l'activation du déclenchement automatique à chaque ajout ou mise à jour de données. La méthode la plus fiable consiste à formaliser cette relecture dans le processus lui-même — un champ de statut « à valider », une vue dédiée et un responsable identifié — de sorte qu'elle ne dépende pas de la vigilance individuelle. Cette discipline coûte peu au démarrage et évite les corrections lourdes une fois les données accumulées.
Comment utiliser Airtable
La première étape consiste à décrire l'objectif métier à Omni plutôt qu'à ouvrir une table vide. Formuler « je veux suivre les demandes de congés avec une validation par le responsable et une visibilité pour les RH » produit une structure de départ contenant des tables, des interfaces et des automatisations cohérentes entre elles. Cette approche est préférable au démarrage à blanc parce qu'elle force à énoncer le processus avant de dessiner le schéma, et parce que la construction avec Omni ne consomme pas de crédits.
La deuxième étape est la revue du modèle de données généré. C'est le moment où le jugement humain est indispensable. Il faut vérifier que chaque table représente une entité et une seule, que les liens entre tables pointent dans le bon sens, et que rien n'a été aplati en une seule table large qui reproduirait un tableur. Une question simple sert de test : est-ce qu'un même élément peut apparaître plusieurs fois ? Si oui, il mérite sa propre table et un champ de liaison.
La troisième étape porte sur les types de champs. Un champ de sélection vaut mieux qu'un champ texte libre pour un statut, parce qu'il rend le filtrage fiable et empêche les variantes orthographiques. Les champs de recherche et d'agrégation méritent une attention particulière : ils permettent d'afficher et de calculer des valeurs provenant d'enregistrements liés sans les dupliquer, ce qui est le principal gain structurel par rapport à un tableur.
La quatrième étape est la construction des vues. Une même table peut être présentée sous plusieurs angles — grille filtrée, calendrier, tableau de suivi par statut — et chaque vue sert un usage. Il est utile de nommer les vues d'après leur usage réel plutôt que d'après leur forme, parce que ce nommage devient une documentation implicite du processus.
La cinquième étape concerne les interfaces. C'est ici que se décide qui voit quoi. Il faut construire une interface par public plutôt qu'une interface universelle : le dirigeant qui veut un état de synthèse et l'opérateur qui saisit des données n'ont pas les mêmes besoins ni les mêmes droits. Les fonctionnalités liées aux permissions dépendant du niveau tarifaire, cette étape doit être testée avec un compte représentatif du niveau qui sera réellement acheté.
La sixième étape est l'automatisation. Il est prudent de commencer par les notifications, qui sont réversibles et à faible risque, avant de passer aux automatisations qui écrivent dans la base. Chaque automatisation doit être testée sur des données de test, avec une attention aux boucles : une automatisation qui modifie un enregistrement peut déclencher une autre automatisation qui écoute cette modification.
La septième étape introduit les agents. On commence par un cas restreint et vérifiable — l'enrichissement d'un champ, la traduction d'un texte court — plutôt que par une chaîne complète. On observe la qualité de sortie sur un échantillon avant d'activer le déclenchement automatique à chaque ajout ou mise à jour, car c'est ce déclenchement qui transforme un coût ponctuel en coût récurrent.
La huitième étape est la gouvernance. Avant d'ouvrir l'espace de travail à un public large, il faut activer l'IA au niveau approprié, définir les données auxquelles les agents accèdent, et vérifier que la piste d'audit répond aux exigences internes. Sur les niveaux entreprise, c'est également le moment de configurer le panneau d'administration, les journaux d'audit et la prévention de la fuite de données.