Migrer d'Airtable vers Supabase.
Une base Airtable qui rame, des droits d'accès qu'on ne sait plus démontrer, une facture au siège. Supabase, c'est du Postgres : vos données sortent du tableur et deviennent une vraie base, que vous pouvez emporter.
Les données passent. Les automatisations et les interfaces se reconstruisent.
Ce qu’une migration Airtable vers Supabase change vraiment
Airtable range vos données dans des tables qui ressemblent à un tableur. Supabase les range dans Postgres, une base relationnelle que tout le monde sait lire, sauvegarder et déplacer.
Ce qui change au quotidien tient en trois points. Les liens deviennent des clés que la base fait respecter. Les droits s’écrivent dans la base au lieu de se régler dans l’interface. Et la facture suit les ressources consommées, plus le nombre de personnes qui ouvrent une table.
Ce qui ne change pas : vos données. Elles passent, avec leurs liens et leurs fichiers.
Ce qui ne passe pas, c’est tout ce qui a été construit autour. Automatisations, interfaces, vues filtrées : rien de cela n’existe dans Postgres. C’est la partie sous-estimée de la plupart des plans de migration.
Pourquoi on ne copie pas la base telle quelle
L’export CSV d’Airtable donne les noms des enregistrements liés, pas leurs identifiants. Deux clients qui portent le même nom deviennent un seul lien ambigu. Pour migrer proprement, on passe par l’API, qui rend les identifiants. On en profite pour trancher une question qu’Airtable ne pose jamais : ce lien est-il un un-à-plusieurs, ou un plusieurs-à-plusieurs ?
C’est là que la migration devient une occasion. Les bases qui ont grandi vite portent presque toujours des tables en double et des liens qui n’en sont pas. Les recopier à l’identique dans Postgres, c’est payer pour déménager le désordre.
Quand rester sur Airtable
Pas toujours. Une base de quelques milliers de lignes, qu’une équipe ouvre tous les jours et corrige à la main, n’a rien à faire sur Supabase. La grille d’Airtable est un vrai produit. Supabase n’a pas d’équivalent pour des non-développeurs.
On vous le dit, quitte à déconseiller la migration. Souvent, on migre deux tables et le reste ne bouge pas : celles qui ramaient, ou celles que l’extérieur doit pouvoir interroger.
Et ensuite ?
Une migration réussie se juge six mois plus tard, à la question suivante : qui sait modifier la base, sans nous ? C’est pour ça que le schéma est documenté, que les changements sont versionnés, que vos équipes ont les accès le jour de la bascule.
Chez Bienfait, on commence par regarder la base existante, ses automatisations et ceux qui s’en servent. Vous repartez avec un plan, même si vous ne nous le confiez pas.
Quand la question se pose vraiment.
Les vues mettent des secondes à s'ouvrir
Quelques dizaines de milliers de lignes, des champs de recherche et de cumul en cascade : chaque filtre recalcule tout. Postgres fait ces jointures en un instant, parce qu'il a été fait pour ça.
Vous avez atteint la limite d'enregistrements
Chaque forfait Airtable plafonne le nombre de lignes par base. Découper en plusieurs bases synchronisées marche un temps, puis devient le sujet à lui seul.
Un client ou un auditeur demande qui accède à quoi
Dans Airtable, les droits se règlent par base et par interface. Dans Supabase, ils s'écrivent ligne par ligne, dans la base, avec des tests.
Vos outils appellent l'API et butent sur ses limites
L'API d'Airtable accepte quelques requêtes par seconde et par base. Dès que Make, un portail et un tableau de bord s'en servent en même temps, des scénarios échouent sans bruit.
La facture grimpe avec le nombre de personnes
Airtable se paie au siège. Sur Supabase, la facture suit les ressources consommées (hébergement, stockage, trafic), pas le nombre de personnes qui consultent la base.
Ce qui passe, et ce qu'on reconstruit.
Les cas où on vous dit de rester.
Quelques milliers de lignes, une équipe qui s'y retrouve
Rien ne force à partir. Airtable porte très bien ce volume. Une migration a un coût qu'il faut pouvoir justifier.
Ce sont vos équipes qui saisissent et corrigent les données à la main
La grille d'Airtable est son vrai atout. Supabase a un éditeur de tables, mais c'est un outil de développeur : si personne n'écrit l'interface qui le remplace, la migration vous reprend plus qu'elle ne vous donne.
Le problème est un modèle de données mal pensé
Des tables en double, des liens dans tous les sens. Migrer tel quel ne le répare pas, ça le copie. On commence alors par le corriger, parfois sans changer d'outil.
Par étapes, sans grand soir.
Cartographier la base
On liste les tables, les liens, les champs calculés, les automatisations et qui s'en sert vraiment. Une partie ne sert plus à personne : on ne migre pas ce qu'on peut supprimer.
Dessiner le schéma cible
On décide des clés, des relations et des contraintes avant de déplacer une ligne. C'est là qu'on corrige les erreurs de modèle accumulées, pas après.
Migrer en parallèle
Les données sont copiées via l'API, fichiers compris, pendant qu'Airtable continue de vivre. Chaque passage rejoue les différences : on peut le refaire autant de fois que nécessaire.
Reconstruire ce qui ne migre pas
Automatisations et interfaces sont refaites sur Supabase, testées avec vos équipes sur des données réelles pendant que l'ancien système tourne encore.
Basculer, puis couper
On fige Airtable, on passe la dernière différence, on bascule. L'ancienne base reste en lecture seule le temps de vous laisser vérifier.
On regarde votre base ensemble.
30 minutes pour dire s'il faut migrer, quoi, et vers quoi. Sans engagement.
Sans réserver de créneau : être rappelé dans la journée nous écrire
Vos questions, nos réponses.
Combien de temps dure une migration Airtable vers Supabase ?
Elle dépend du nombre de tables, de champs calculés et d'automatisations, bien plus que du nombre de lignes. Copier les données est la partie rapide. On le chiffre après avoir regardé la base, pas avant.
Est-ce qu'on perd quelque chose en route ?
Les données, non : lignes, liens et fichiers passent. Les automatisations, les interfaces et les vues ne se migrent pas, elles se reconstruisent. On vous les liste avant de commencer.
Peut-on migrer sans arrêter l'activité ?
Oui. La copie se fait pendant qu'Airtable reste utilisé, puis rejoue les différences jusqu'à la bascule. L'arrêt se limite en général à la fenêtre de bascule, qu'on place hors des heures de saisie.
Qui modifie les données ensuite, si ce n'est plus Airtable ?
C'est la question à poser avant de commencer. Soit une interface bâtie sur Supabase, par exemple avec WeWeb, soit une application sur mesure. Le plan de migration prévoit l'écran de saisie, pas seulement la base.
Et si Supabase ne nous convient plus plus tard ?
La base est du Postgres standard : un export se restaure chez n'importe quel hébergeur. Supabase s'installe aussi sur vos propres serveurs. Vous n'êtes pas enfermé, ce qu'on ne peut pas dire d'Airtable.
Où sont hébergées les données ?
Dans la région choisie à la création du projet, européenne chez nous. Si elles doivent rester en France, on installe Supabase sur un serveur français.
Une migration Airtable en tête ?
On en parle 30 minutes, sans engagement, et on vous dit franchement s'il faut migrer.
Sans réserver de créneau : être rappelé dans la journée nous écrire