Migrer d'Airtable vers Softr Databases : pourquoi, comment, et ce qui peut coincer !

Pourquoi je me suis posé la question

Le 4 août 2026, Bending Spoons a annoncé le rachat d'Airtable pour 1,285 milliard de dollars en cash (valeur implicite d'environ 2,25 milliards). Le deal doit se clôturer d'ici la fin de l'année, sous réserve des autorisations réglementaires.

Deux jours plus tard, j'avais trois messages de clients dans ma boîte. Tous avec la même question : "On fait quoi de nos bases Airtable ?"

‍

Pour qui cet article est fait ?

Si vous dirigez une PME et que vous avez une ou plusieurs bases Airtable qui alimentent un portail client, un outil interne ou un CRM maison, vous êtes exactement la cible.

Si vous utilisez Airtable comme un tableur amélioré, sans app par-dessus, sans automatisation critique, vous pouvez lire la première partie et vous arrêter là. Rien ne presse.

Si vous avez 200 000 enregistrements, 40 automatisations et une équipe de 30 personnes qui vivent dans les Interfaces Airtable, cet article vous donnera le cadre, mais la migration elle-même sera un projet à part entière. Ne la faites pas un vendredi soir.

‍

Ce que le rachat change, concrètement ?

Je ne vais pas faire de procès d'intention. Le PDG de Bending Spoons, Luca Ferrari, parle d'accélérer l'innovation et d'investir dans Airtable sur le long terme. Howie Liu, le PDG d'Airtable, dit que ce partenariat lui donne les ressources dont il a besoin.

Ce que je peux faire, c'est regarder ce qui s'est passé sur les rachats précédents. Bending Spoons a racheté plus de 50 entreprises depuis 2013. Le schéma est documenté :

Evernote (janvier 2023) : 129 licenciements en février, 98 de plus en juillet. Le plan gratuit a été plafonné à 50 notes, un carnet, un appareil. D'après Forbes, des utilisateurs qui payaient environ 100 dollars par an se sont retrouvés à 249.

WeTransfer (juillet 2024) : trois quarts des effectifs supprimés en deux semaines. Le plan gratuit limité à 10 transferts par mois.

Komoot (mars 2025) : environ 80 % d'une équipe de 250 personnes remerciée. La synchronisation des itinéraires est passée en abonnement pour les nouveaux utilisateurs.

Meetup (2024) : le prix de l'abonnement organisateur a plus que doublé.

AOL, Eventbrite, Vimeo (2025-2026) : 78,6 millions de dollars de frais de réorganisation comptabilisés en 2025. Sur environ 1 830 salariés récupérés, seules quelques centaines devraient rester fin 2026.

Je ne dis pas qu'Airtable va suivre exactement cette trajectoire. Je dis que si vous êtes dirigeant et que votre outil de gestion repose sur Airtable, vous avez trois risques à modéliser :

1. Le rythme produit ralentit. Quand l'équipe d'ingénierie se réduit, la roadmap devient négociable. Les fonctionnalités promises n'arrivent pas.
2. Le support se dégrade. Vous perdez votre interlocuteur, et la connaissance de votre compte avec.
3. Le pricing est revu. Sur les rachats précédents, les utilisateurs existants n'ont pas systématiquement été protégés. Le plan gratuit est le premier touché.

Ma recommandation, que vous migriez ou pas : modélisez dès maintenant l'impact d'une hausse de 30 à 80 % de votre facture Airtable sur votre budget 2027. Si le chiffre vous fait mal, continuez à lire.

‍

Les trois options qui s'offrent à vous :

C'est le point que la plupart des gens ratent. Migrer n'est pas binaire.

Option 1 : garder Airtable en base, mettre Softr devant. Si vos utilisateurs finaux (clients, prestataires, équipe terrain) accèdent à vos données via des Interfaces Airtable ou des liens de partage, vous payez des sièges Airtable pour ça. Softr se connecte nativement à Airtable et vous permet de construire le portail par-dessus, avec logins, rôles et permissions. La base ne bouge pas. Vous réduisez votre dépendance à la couche interface d'Airtable, et souvent votre facture. C'est le chemin le moins risqué, et c'est celui que je fais depuis des années.

Option 2 : migrer les données vers Softr Databases. Vous copiez votre base dans la base de données native de Softr. Plus de limite d'API, plus de facture Airtable, un seul outil. C'est le cœur de cet article.

Option 3 : l'hybride. Vous migrez les tables qui alimentent vos apps, et vous gardez sur Airtable ce qui dépend d'automatisations ou d'intégrations que vous n'êtes pas prêt à refaire. Softr accepte plus de 100 sources de données dans la même app, donc rien ne vous oblige à tout basculer d'un coup.

Dans les trois cas, la première étape est la même : séparer la couche données de la couche interface dans votre tête et dans votre architecture. Une fois que c'est fait, le fournisseur de base de données devient interchangeable.

‍

Softr Databases, c'est quoi exactement ?

Pour ceux qui découvrent : Softr Databases est la base de données relationnelle native de Softr. Pensez à ça comme un Airtable intégré directement dans le constructeur d'app, sans passer par une API externe.

Ce que ça change par rapport à une source externe :

• Pas de limite d'API. Sur Airtable, l'import et la synchronisation dépendent du quota d'appels de votre plan. Sur Softr Databases, la donnée est dans la même infrastructure que l'app.
• Des performances stables quand le nombre d'enregistrements et de formules augmente.
• Des agents IA déclenchés sur la donnée : à la création d'un enregistrement, à la mise à jour d'un champ ou sur une condition personnalisée. Ce n'est pas disponible avec une source externe.
• Un pricing sans siège par utilisateur pour les utilisateurs de l'app.
• Hébergement AWS en région Europe, conforme RGPD. Pour une PME française, c'est un argument qui pèse face à des DAF ou des DPO.

Les limites structurelles, telles que documentées par Softr :

Le nombre d'enregistrements dépend de votre plan. La documentation indique 1 000 enregistrements par base sur le plan gratuit (5 000 au total), puis 5 000, 25 000 et 50 000 par table sur les plans Basic, Professional et Business. Vérifiez la page tarifs au moment de votre projet, ces chiffres bougent.

Les 24 types de champs disponibles : texte court, texte long, fichier, case à cocher, select (simple ou multiple), utilisateur, nombre, devise, pourcentage, date, email, URL, téléphone, note (étoiles), formule, rollup, lookup, enregistrement lié, date de création, date de modification, créé par, modifié par, autonumber, ID d'enregistrement.

Vous retrouvez donc l'essentiel de ce que vous utilisez sur Airtable. Ce qui manque, j'y reviens dans la partie sur les limites.

‍

Avant de migrer : trois étapes que personne ne veut faire

La migration copie vos données. Elle ne touche pas à votre base Airtable d'origine. C'est non destructif. Mais ça ne veut pas dire sans risque pour votre app, parce que l'app, elle, va changer de source.

1. Travaillez sur des copies

Dupliquez votre app Softr. Faites le premier test sur une copie de votre base Airtable, pas sur la base de production. Créez un point de restauration dans l'historique de version (App History) avant de toucher au moindre bloc. Si ça part en vrille, vous revenez en arrière en un clic.

2. Documentez vos champs calculés

Listez tous vos Lookups, Rollups, formules et liens entre tables. Le plus simple : créez une vue dédiée dans chaque table Airtable qui n'affiche que ces champs. Après l'import, vous les vérifiez un par un, Airtable d'un côté, Softr de l'autre.

Je fais ça dans un Google Sheet à trois colonnes : table, nom du champ, formule ou source. Ça prend une heure sur une base moyenne. Ça m'a déjà évité de découvrir un Rollup cassé trois semaines après la mise en production.

3. Documentez tout ce qui vit autour de la base

C'est le point que Softr met en avant dans sa propre communication sur le rachat, et c'est le plus important : exportez toutes vos bases en CSV et stockez-les hors Airtable. Puis inventoriez vos automatisations Airtable, vos scénarios Make ou Zapier, vos formulaires, vos appels API. Tout ce qui écrit ou lit dans votre base.

Softr Databases ne migre pas les automatisations. Il migre les données. Si vous avez 15 automatisations Airtable qui envoient des mails et créent des enregistrements liés, vous devez les recréer. Je détaille ça dans les limites.

‍

L'import, étape par étape

1. Dans Softr Studio, cliquez sur Databases dans la barre latérale gauche.
2. Cliquez sur Create new database.
3. Dans la boîte de dialogue, choisissez Import data.
4. Sélectionnez Airtable comme source.
5. Choisissez votre compte Airtable connecté, ou ajoutez une nouvelle connexion.
6. Cherchez et sélectionnez la base à importer. L'import porte sur la base entière, pas sur une table isolée.
7. Cliquez sur Start import et attendez la fin.

Un point à ne pas sous-estimer : Softr passe par l'API d'Airtable pour lire vos enregistrements. La vitesse et la fiabilité de l'import dépendent donc du quota d'API de votre plan Airtable. Sur un plan gratuit avec une grosse base, attendez-vous à un import lent, voire à devoir relancer. Sur un plan Team ou Business, c'est fluide. Sur une base de 8 000 enregistrements avec pièces jointes, j'ai compté une vingtaine de minutes.

Vérification immédiate après l'import

Avant de toucher à votre app, ouvrez chaque table importée et vérifiez :

• le nombre d'enregistrements par table (comparez avec Airtable) ;
• l'intégrité des enregistrements liés (les relations pointent vers les bonnes tables) ;
• la présence des pièces jointes ;
• les résultats des champs Formule, Lookup et Rollup.

‍

Ce qui passe tout seul, ce qui demande une relecture

Transféré automatiquement

• Les enregistrements et tous les champs texte, nombre, date, select, case à cocher.
• Les champs système : date de création, date de dernière modification, autonumber.
• Les enregistrements liés, avec les relations préservées.
• Les pièces jointes et fichiers, copiés dans Softr (donc plus dépendants des URL Airtable qui expirent).
• Les formules, dans une syntaxe compatible Airtable.

À vérifier ou à recréer

• Créé par / Modifié par : ce sont des champs calculés côté Airtable. Softr tente de conserver les valeurs, mais vérifiez champ par champ. Le type équivalent existe dans Softr.
• Texte long enrichi : le formatage est importé en Markdown. Contrôlez l'affichage dans vos blocs, surtout les listes et les liens.
• Formules complexes : les fonctions liées au système interne d'Airtable (RECORD_ID, infos de session, etc.) n'ont pas toujours d'équivalent direct. Consultez le glossaire des formules Softr et réécrivez ce qui ne résout pas.
• Lookups et Rollups : supportés, mais vérifiez qu'ils résolvent bien contre la bonne table liée. Un Rollup qui pointe sur la mauvaise table affiche zéro sans erreur.

‍

Rebrancher votre app, bloc par bloc

C'est ici que les migrations ratent. Pas à l'import, mais au rebranchement.

D'abord, le point de restauration

Avant de changer la source d'un seul bloc, créez un point de restauration dans App History. Si trois blocs plus tard vous réalisez que vous avez cassé les filtres, vous restaurez l'app entière en une étape.

Ensuite, un bloc à la fois

1. Sélectionnez un bloc connecté à Airtable.
2. Ouvrez l'onglet Sources dans les paramètres du bloc.
3. Dans le menu Account, remplacez Airtable par Softr Databases.
4. Sélectionnez la base importée et la table correspondante.
5. Vérifiez le mapping des champs. Comme les noms de champs sont conservés, le remapping est en général automatique.
6. Passez en revue tous les paramètres qui font référence à un champ précis.

Les paramètres qui sautent souvent

Après un changement de source, contrôlez systématiquement :

• les filtres conditionnels et les filtres d'enregistrements ;
• la configuration de la recherche et des filtres inline ;
• les couleurs des tags et labels, si elles proviennent d'un champ ;
• les boutons d'action, dont les références de champs peuvent se réinitialiser.

Le protocole de test

Prévisualisez chaque bloc après son rebranchement. Vérifiez que la donnée s'affiche, puis testez une création et une modification d'enregistrement. Seulement après, passez au bloc suivant. Si vous rebranchez dix blocs d'un coup et que quelque chose casse, vous ne saurez pas lequel. Un à la fois, c'est plus long, mais c'est traçable.

‍

Utilisateurs, groupes et permissions

C'est la partie que je vois le plus souvent oubliée, parce qu'elle ne se voit pas tant que personne ne se connecte.

La table de synchronisation des utilisateurs

Si vos utilisateurs d'app sont synchronisés depuis une table Airtable, repointez la synchronisation vers la table correspondante dans Softr Databases. Pendant la manipulation, désactivez l'option Send user notification email. Sinon, tous vos utilisateurs existants reçoivent un mail d'invitation comme s'ils étaient nouveaux. Je l'ai vu arriver. Ce n'est pas une conversation agréable avec un client.

Avec Softr Databases comme source, la synchronisation devient bidirectionnelle : une modification dans l'app remonte dans la table, et inversement. Une conséquence pratique : ne modifiez plus les emails directement dans la table source, vous risquez de désynchroniser les comptes.

Les groupes d'utilisateurs

Si vos groupes reposent sur une logique conditionnelle (par exemple : "Rôle = Admin" dans la table users), remappez les conditions vers les nouveaux champs. Les groupes peuvent ne pas se synchroniser complètement avant la publication. Publiez l'app avant de juger que ça ne marche pas.

Les restrictions globales de données

Elles ne se transfèrent pas. Elles sont liées à une table précise dans une source précise. Vous devez les recréer de zéro contre les tables Softr Databases. Si votre app a des restrictions du type "un client ne voit que ses propres commandes", c'est un point critique. Sans cette étape, un client peut voir les commandes des autres.

La vérification finale

Connectez-vous en tant qu'utilisateur de chaque groupe. Un admin, un client, un prestataire. Vérifiez que chacun voit exactement ce qu'il doit voir, et rien de ce qui lui est interdit. Tant que ce test n'est pas passé, la migration n'est pas terminée.

‍

Ce que Softr Databases ne remplace pas (encore)

Je vous ai dit que je serais honnête sur les limites. Les voici.

Les automatisations Airtable. Elles ne migrent pas. Softr a ses propres workflows et ses agents IA sur la base, mais vous devez reconstruire chaque automatisation. Comptez ça dans votre estimation de charge. Sur une base avec 15 automatisations, c'est une journée de travail minimum.

Les Interfaces Airtable. Si votre équipe interne travaille dans des Interfaces Airtable, elles disparaissent avec la base. L'idée est de les remplacer par des blocs Softr, mais ce n'est pas un copier-coller. C'est une reconstruction.

Les vues Airtable. Vos vues filtrées, groupées, vos calendriers, vos galeries ne sont pas importées. Dans Softr, l'équivalent se fait au niveau des blocs de l'app.

Certains blocs Softr. Au moment où j'écris, les blocs Kanban et Inbox ne supportent pas encore Softr Databases. Les blocs List, Grid et Table fonctionnent. Si votre app repose sur un Kanban, vérifiez l'état du support avant de migrer.

Les intégrations tierces. Zapier est disponible. Make et n8n sont annoncés mais pas encore là. Si vos scénarios Make lisent ou écrivent dans Airtable, vous passez par l'API REST de Softr Databases dans l'intervalle, ou vous gardez ces tables sur Airtable (option hybride).

Le quota d'enregistrements. Selon votre plan Softr, la limite par table peut être plus basse que ce dont vous disposez sur Airtable. Une base Airtable Business à 100 000 enregistrements ne rentre pas sur un plan Softr Professional. Vérifiez avant de lancer l'import.

Le format des exports. Vous perdez l'habitude Airtable de l'export CSV en deux clics depuis n'importe quelle vue. L'export existe, mais le réflexe n'est pas le même.

‍

Ma checklist de migration

À imprimer ou à copier dans votre outil de gestion de projet.

Avant

• Export CSV de toutes les bases, stocké hors Airtable
• Inventaire des automatisations Airtable, scénarios Make/Zapier, formulaires, appels API
• Liste des champs calculés (Lookup, Rollup, formules) par table
• Vérification du quota d'enregistrements du plan Softr cible
• Duplication de l'app Softr
• Point de restauration App History

Import

• Import de la base via Databases > Create new database > Import data > Airtable
• Comparaison du nombre d'enregistrements par table
• Vérification des enregistrements liés
• Vérification des pièces jointes
• Vérification des formules, Lookups, Rollups
• Contrôle des champs Créé par / Modifié par
• Contrôle du rendu Markdown des textes longs

Rebranchement

• Nouveau point de restauration
• Changement de source bloc par bloc, avec test après chaque bloc
• Filtres conditionnels et filtres d'enregistrements
• Recherche et filtres inline
• Couleurs de tags
• Boutons d'action

Utilisateurs

• Repointage de la table de synchronisation utilisateurs, notifications désactivées
• Remapping des groupes d'utilisateurs
• Recréation des restrictions globales de données
• Publication de l'app
• Test de connexion pour chaque groupe d'utilisateurs

Après

• Reconstruction des automatisations
• Rebranchement des intégrations externes (API REST ou Zapier)
• Période de double fonctionnement de deux semaines avant de couper Airtable

‍

Mon verdict

Migrer vers Softr Databases a du sens si :

• Vos bases Airtable servent avant tout à alimenter une app Softr (portail client, outil interne, CRM maison).
• Vous payez des sièges Airtable pour des utilisateurs qui ne font que consulter ou saisir de la donnée.
• Vous butez sur les limites d'API d'Airtable, ou vous avez des lenteurs sur des bases avec beaucoup de formules.
• Vous avez moins de 10 automatisations et vous êtes prêt à les reconstruire.
• L'hébergement en Europe est un critère pour vos clients ou votre DPO.
• Vous voulez réduire le risque fournisseur avant que le pricing d'Airtable ne bouge.

Migrer n'a pas de sens si :

• Votre équipe travaille au quotidien dans les Interfaces et les vues Airtable, sans app par-dessus.
• Vous avez des dizaines d'automatisations Airtable et des scénarios Make critiques que vous ne pouvez pas refaire maintenant.
• Votre app dépend d'un bloc Kanban ou Inbox.
• Votre volume dépasse le quota du plan Softr que vous êtes prêt à payer.
• Vous n'avez pas le temps de faire la vérification bloc par bloc et le test par groupe d'utilisateurs. Une migration faite à moitié est pire que pas de migration.

‍

Dans le doute, commencez par l'option 1 : gardez Airtable en base, construisez ou déplacez votre interface sur Softr. Vous séparez les couches, vous réduisez la dépendance, et vous pourrez basculer la base plus tard, quand vous aurez de la visibilité sur ce que Bending Spoons fait vraiment d'Airtable.

La prochaine étape si vous voulez tester : dupliquez une petite base Airtable, importez-la dans une base Softr Databases vide, et comparez vos champs calculés. Une heure suffit pour savoir si votre cas passe ou pas.

Softr propose aussi une consultation de migration gratuite pour passer en revue votre configuration. Et si vous voulez qu'on regarde votre cas ensemble, vous savez où me trouver.