Données à migrer depuis Airtable

Exporter vos données depuis l’interface Airtable

Avant tout développement, Airtable permet d’exporter chaque table en CSV depuis l’interface. C’est la première étape pour auditer vos données ou les transmettre à un prestataire.

Comment exporter une table en CSV

Dans une vue grille, cliquez sur le menu en haut à droite de la table, puis sur Download CSV. L’export inclut toutes les lignes de la vue active avec les colonnes visibles.

Points d’attention avec l’export CSV :

• Les vues filtrées n’exportent que les lignes visibles : si votre vue applique un filtre, les enregistrements masqués ne sont pas inclus. Exportez depuis une vue sans filtre pour récupérer l’intégralité des données.
• Les linked records apparaissent comme du texte : la relation entre tables n’est pas conservée dans le CSV, seul le nom de l’enregistrement lié est affiché.
• Les pièces jointes ne sont pas incluses : le CSV contient uniquement les noms de fichiers, pas les fichiers eux-mêmes.
• Les formules sont exportées avec leur résultat calculé : la logique n’est pas exportée, seulement la valeur au moment de l’export.

Ce que l’export CSV ne couvre pas

Pour une migration complète, l’export CSV seul ne suffit pas. Il faut passer par l’API REST Airtable pour récupérer les pièces jointes, les IDs des linked records et le schéma des tables.

---

Structure des bases et tables

L’API REST Airtable expose le schéma de chaque base via l’endpoint GET /meta/bases/{baseId}/tables. Cet endpoint retourne les noms de colonnes, les types de champs et la configuration des vues. SmartBooster analyse ce schéma pour construire le modèle de données cible avant d’extraire les enregistrements.

Enregistrements (records)

Les enregistrements sont extraits via GET /bases/{baseId}/tables/{tableId}/records. Airtable limite à 5 requêtes par seconde par base et retourne 100 enregistrements par page maximum. Pour des bases volumineuses, la migration est paginée via le paramètre offset.

Types de champs et correspondances SQL

Type Airtable	Correspondance cible
singleLineText, email, url, phoneNumber	VARCHAR
multilineText, richText	TEXT
number, currency, percent, rating	DECIMAL ou INT
date, dateTime	DATE ou DATETIME
checkbox	BOOLEAN
singleSelect	ENUM ou table de référence
multipleSelects	Table de jointure
autonumber	PK AUTO_INCREMENT
formula, rollup, lookup	Recréé en logique applicative
linkedRecord	Clé étrangère ou table de jointure
attachment	Migré vers stockage fichiers

Liens entre tables (linked records)

Les linkedRecord fields sont la particularité centrale du modèle de données Airtable. Ils permettent de relier des enregistrements de tables différentes, comme un CRM relie des contacts à des entreprises.

Lors de la migration, chaque relation est analysée :

• Relation one-to-many : une clé étrangère est ajoutée dans la table enfant
• Relation many-to-many : une table de jointure intermédiaire est créée

Les identifiants Airtable (recXXXXXXXXXXXXXX) sont remappés vers les IDs auto-incrémentés du nouveau schéma en deux passes : d’abord les enregistrements sans dépendances, ensuite les relations.

Si vous exportez manuellement : un export CSV ne conserve pas ces relations. Il faut réimporter les données table par table en recréant les liens manuellement dans le nouveau logiciel, ce qui est faisable sur de petits volumes mais très fastidieux au-delà de quelques centaines de lignes avec des relations croisées.

Pièces jointes (attachments)

Les pièces jointes ne sont pas stockées dans Airtable mais accessibles via des URLs signées temporaires retournées par l’API. SmartBooster télécharge chaque fichier pendant la migration et le ré-héberge sur le stockage cible.

Points d’attention :

• Les URLs signées ont une durée de validité limitée : la migration des pièces jointes doit être réalisée dans la foulée de l’extraction des enregistrements
• La taille maximale par cellule est de 5 Go dans Airtable
• Les noms de fichiers et types MIME sont conservés

Si vous exportez manuellement : les pièces jointes ne sont pas incluses dans le CSV. Il faut les télécharger une par une depuis l’interface ou écrire un script utilisant l’API, ce qui peut représenter un volume de travail significatif sur des bases avec beaucoup de fichiers joints.

Formules, rollups et lookups

Ces champs sont calculés côté Airtable et ne représentent pas des données stockées : ils ne sont pas exportables directement. Leur logique est analysée avant la migration et recréée dans le nouveau logiciel :

• Formule : recréée en méthode de modèle ou calcul en base de données
• Rollup (agrégat sur une relation) : recréé via une requête SQL d’agrégation
• Lookup (valeur d’un enregistrement lié) : recréé via une jointure SQL

C’est l’étape qui demande le plus d’analyse et d’échanges avec votre équipe : certaines formules complexes nécessitent une décision métier sur leur recréation.

---

Ce qui nécessite une décision avant la migration

Certains éléments ne peuvent pas être migrés automatiquement :

• Les automations Airtable : déclencheurs et actions sont recréés en logique applicative (jobs planifiés, webhooks, événements métier)
• Les interfaces Airtable (Interface Designer) : remplacées par les écrans sur mesure du nouveau logiciel
• Les formulaires Airtable : remplacés par les formulaires du nouveau logiciel
• Les intégrations natives (Slack, Google Drive, Salesforce) : rebranching sur les nouvelles APIs du logiciel cible

Ce qui peut rester dans Airtable

La migration n’est pas forcément totale. Certaines bases ou usages peuvent coexister temporairement ou durablement avec le nouveau logiciel :

• Les bases non liées au périmètre du projet
• Les workflows d’équipes qui utilisent Airtable de façon autonome
• Les formulaires publics si Airtable Interface Designer reste pertinent pour ce cas

SmartBooster peut aussi développer un connecteur API pour synchroniser Airtable avec le nouveau logiciel, au lieu de le remplacer complètement.

---

Ce qu’un prestataire sérieux doit faire

Si vous faites appel à un prestataire pour cette migration, voici les questions à poser pour évaluer sa rigueur avant de démarrer :

• Analyse du schéma avant l’extraction : le prestataire doit cartographier les bases, les tables et les relations avant d’écrire le moindre script de migration.
• Environnement de recette dédié : la migration doit être testée sur un environnement isolé, jamais directement en production.
• Gestion des linked records : le remapping des IDs Airtable vers les IDs cibles doit être explicitement prévu, pas improvisé.
• Stratégie pour les pièces jointes : le prestataire doit anticiper le re-hébergement des fichiers avant que les URLs signées Airtable n’expirent.
• Plan de rollback : en cas d’anomalie détectée après la bascule, que se passe-t-il ? Vos données Airtable doivent rester accessibles pendant une période de vérification.

Chez SmartBooster, ces points font partie du cadrage initial de chaque projet de migration.

Authentification à l’API Airtable

Pour extraire les données via l’API, Airtable recommande les Personal Access Tokens (PAT) depuis 2023. Les anciennes clés API (API Keys) sont dépréciées et ne doivent plus être utilisées pour de nouveaux projets.

Un PAT se crée depuis les paramètres de votre compte Airtable, avec des scopes granulaires (lecture seule suffit pour une migration) et une restriction possible aux bases concernées. Consultez le guide de création des identifiants API Airtable pour la procédure complète.

Références techniques

• API REST Airtable : authentification
• API REST Airtable : lister les enregistrements
• API REST Airtable : schéma d’une base
• Types de champs Airtable
• Champ pièces jointes Airtable