Migrer de Softr vers du code : commencer par la base, pas par le portail

Pour migrer de Softr vers du code, commencez presque toujours par sortir vos données d'Airtable ou de Google Sheets vers une vraie base PostgreSQL, puis reconstruisez le portail et les automatisations autour de cette base, en recréant les utilisateurs sans leurs mots de passe, qui ne s'exportent pas. Si l'outil reste interne, utilisé par une petite équipe et que sa logique tient au même endroit, restez sur Softr et simplifiez plutôt que de migrer.

Chez Noxcod, on maintient une plateforme métier construite sur Softr, Airtable et Make, et on a reconstruit en code notre propre application, Tala, qui tournait sur Bubble. Ces deux expériences nous ont convaincus d'une chose sur les projets Softr. Le portail lui-même pose rarement problème. Ce qui coûte, c'est la logique éclatée entre trois outils, parce que comprendre un bug oblige à lire les trois.

Pourquoi quitter Softr alors que le portail fonctionne ?

On quitte Softr quand chaque correction demande d'ouvrir trois outils, presque jamais parce que les écrans déçoivent. Sur la plateforme métier qu'on maintient, Softr gère l'affichage et les droits d'accès, Airtable porte les données et les formules, Make fait tout le reste : envoi de documents, appels à un prestataire de signature électronique, traitement de formulaires externes. Chaque outil fait bien son travail. La règle métier, elle, n'habite nulle part en entier.

Deux épisodes réels montrent à quoi ça ressemble au quotidien. Des utilisateurs cliquaient deux fois sur le bouton de signature, et chaque clic créait une demande de signature chez le prestataire. Pour corriger, on a injecté un script JavaScript anti double-clic dans les pages Softr (le code personnalisé est réservé au plan Pro et au-dessus d'après la documentation Softr), puis il a fallu nettoyer à la main les doublons déjà créés. Deuxième épisode, on a constaté que la configuration fine d'un champ de formulaire, par exemple les types de fichiers autorisés, ne se lit pas par l'API. Il faut ouvrir l'éditeur, et l'ouvrir modifie la date de mise à jour de l'application. Diagnostiquer sans rien toucher devient presque impossible.

Aucun de ces problèmes n'est grave seul. Leur somme l'est. Quand un client signale qu'un dossier n'a pas avancé, la cause peut être un filtre de visibilité dans Softr, une formule Airtable qui renvoie une chaîne vide ou un scénario Make qui a échoué en silence la veille. Il faut alors remonter l'historique de chaque outil, et aucun d'eux ne dit « voici la règle ». Dans un dépôt de code, cette règle tient dans un fichier versionné, que l'on peut tester, relire, et confier à un agent de code IA comme Claude Code.

Ce client reste sur Softr à ce jour. Nous citons ces épisodes parce que ce sont exactement les signes qui font poser la question de la migration.

Que peut-on récupérer d'un portail Softr ?

Vous récupérez toutes vos données et la liste de vos utilisateurs, mais ni le code du portail, ni les mots de passe, ni les règles de droits sous une forme réutilisable. Le détail dépend de l'endroit où vivent vos données.

Si votre portail lit Airtable ou Google Sheets, vos données ne sont pas chez Softr. Softr indique dans sa page sur le choix d'une source de données qu'il ne stocke ni ne synchronise vos données, avec un cache de 24 heures pour la vitesse. Votre base Airtable reste donc la vôtre, accessible par son API ou par export CSV, et elle survivra au portail. Si vous utilisez Softr Databases, la base intégrée de Softr, les données sont hébergées chez Softr et sortent par la Softr Database API ou par un export CSV depuis un bloc tableau.

Les utilisateurs se téléchargent en CSV depuis le menu Users du studio, comme le décrit la documentation des utilisateurs. Les mots de passe, eux, ne suivent pas, et c'est normal. Un cofondateur de Softr l'a confirmé en 2023 sur le forum officiel : ils sont hachés à sens unique et aucun export n'est possible. Le code personnalisé que vous avez injecté vous appartient, copiez-le. Les pages, les blocs, les groupes d'utilisateurs et les filtres conditionnels sont configurés dans le studio, on les inventorie (captures d'écran, liste des règles) avant de les réécrire.

Cet inventaire, on le fait avant d'annoncer un délai. C'est d'ailleurs la première partie d'un audit de votre application et de ce que l'IA peut y reprendre : lister ce qui sort tel quel, ce qui se traduit et ce qui se réécrit.

Faut-il migrer la base, le portail, ou les deux ?

Migrez la base d'abord dans la plupart des cas, parce que Softr sait afficher une base Supabase et que votre portail peut donc continuer à servir vos utilisateurs pendant que les données changent de maison. Les sources de données de Softr incluent Supabase (disponible à partir du plan Pro, appelé Professional dans la documentation) et les bases SQL comme PostgreSQL (réservées aux plans Business et Enterprise).

Cet ordre vaut surtout quand Airtable plafonne. Au 14 octobre 2026, la page tarifs d'Airtable affiche 50 000 enregistrements par base sur le plan Team à 20 $ par utilisateur et par mois en facturation annuelle, et 125 000 sur le plan Business à 45 $. Son API est limitée à 5 requêtes par seconde et par base, et les requêtes de votre portail passent par elle, malgré le cache de Softr. Softr lui-même estime, dans son comparatif des sources de données, qu'une app branchée sur Airtable tient bien entre 200 et 300 utilisateurs simultanés. Sortir la base en premier lève ce plafond, et surtout vous oblige à transformer les formules, lookups et rollups en règles explicites. C'est là que se trouve le vrai travail. Ensuite, on rebranche les scénarios Make un par un sur la nouvelle base, puis on reconstruit le portail en Next.js sur des données déjà propres. Le jour de la bascule du portail, il ne reste à déplacer que les utilisateurs et le domaine. Si vous hésitez sur le backend, notre guide Supabase et notre comparatif Xano ou Supabase comme backend détaillent les deux options.

Le portail d'abord se justifie quand la douleur est l'interface (image de marque, parcours, usage mobile) et que la base est petite et propre. Une application Next.js peut lire Airtable par son API, mais vous gardez la limite de débit et la logique éclatée. Nous ne le recommandons qu'en étape transitoire. Tout migrer d'un coup convient aux petites applications, avec peu de tables et une logique surtout portée par Make. C'est aussi l'ordre suivi pour Tala, pour une autre raison : front et back étaient à refaire ensemble. La nouvelle application a été construite pendant que l'ancienne servait les clients, puis tout a basculé en une nuit, après une répétition générale.

Que deviennent les utilisateurs et leur connexion ?

Vos utilisateurs gardent leur compte mais pas leur mot de passe : on les recrée à partir de leur e-mail dans le nouveau système, et ils se reconnectent par lien magique, par code envoyé par e-mail, ou en choisissant un nouveau mot de passe.

Pour rapprocher les comptes, on s'appuie sur un fait simple : Softr utilise l'e-mail comme identifiant unique de chaque utilisateur, d'après sa page sur la synchronisation des utilisateurs. C'est la clé qui relie le CSV du menu Users à votre table Airtable et au futur compte. Les groupes d'utilisateurs de Softr reposent souvent sur un champ Airtable (« Rôle », « Client rattaché »). Ils deviennent des rôles et des règles d'accès, écrites dans la base ou dans le code et testables.

Sur Tala, on a recréé chaque utilisateur dans le nouveau service de connexion avec son e-mail déjà marqué vérifié, sans qu'aucun e-mail ne parte pendant la nuit. Et la recette s'est faite avec un vrai compte client migré, pas avec un compte administrateur qui voit tout : c'est ce compte qui a révélé, juste après la bascule, que les clients ne voyaient pas leurs agents à cause d'un rattachement d'organisation erroné, corrigé avant leur arrivée.

Sur un portail Softr, le même piège prend une autre forme. Un filtre « l'utilisateur connecté correspond au champ Client » était implicite dans le studio ; s'il est mal réécrit, un client voit tout, ou ne voit rien. Autre comportement implicite, précisé sur la même page de documentation : en synchronisation standard, supprimer un utilisateur dans la source ne le supprime pas dans Softr, qui le réinscrit dans la source à la synchronisation suivante. Dans votre nouveau système, écrivez noir sur blanc ce qui se passe quand quelqu'un part. Enfin, les liens magiques générés par Softr qui traînent dans des scénarios exportés doivent être révoqués le jour de la bascule.

Que faire des scénarios Make ou Zapier pendant la migration ?

Gardez-les branchés pendant la transition, puis rapatriez dans le code chaque scénario qui porte une règle métier, et ne laissez dans Make ou Zapier que ce qui relie deux services externes sans décision au milieu. Un scénario qui calcule un statut, décide d'envoyer un document ou crée une demande de signature fait partie de votre produit. Il doit vivre avec lui.

On commence par une fiche par scénario : ce qui le déclenche, les tables qu'il lit et modifie, les services externes qu'il appelle, les clés qu'il utilise. Une clé saisie en dur dans un module, pour un appel HTTP par exemple, reste dans l'export du scénario. Lors d'une migration, on renouvelle donc chaque clé présente dans un export le jour de la bascule, parce que des copies de ces fichiers circulent forcément quelque part.

Reprenons le double-clic sur la signature. Dans Softr, la parade qu'on a trouvée était un script dans la page, côté navigateur. Dans une application en code, la protection se place sur le serveur : avant d'appeler le prestataire de signature, il vérifie qu'aucune demande n'existe déjà pour ce document, et refuse la seconde. Un test automatisé simule les deux clics et échoue si un doublon apparaît. La correction ne dépend plus d'un script que quelqu'un pourrait supprimer en modifiant une page.

Traduire les formules Airtable et les scénarios Make en code était la partie la plus longue d'une migration il y a deux ans. Aujourd'hui, un agent de code lit l'export du scénario et les formules, propose une traduction, et on la valide avec la personne qui connaît le métier. Dominique explique dans sa vidéo sur le no-code face à l'IA pourquoi le code va désormais plus vite que le no-code sur ce type de travail. La validation humaine, elle, ne se délègue pas : c'est elle qui découvre qu'une formule gérait un cas particulier que personne n'avait documenté.

Quand vaut-il mieux rester sur Softr ?

Restez sur Softr si l'outil est interne, modifié par l'équipe qui s'en sert, et si sa logique tient dans Softr et une seule base. Dans ce cas, une migration vers du code vous ferait payer un développement pour un problème que vous n'avez pas.

Au 14 octobre 2026, la page tarifs de Softr affiche le plan Basic à 19 $ par mois en facturation annuelle (25 $ au mois), le plan Pro à 99 $ par mois en annuel (119 $ au mois) avec 10 utilisateurs d'équipe et 50 utilisateurs clients, et le plan Business à 329 $ par mois en annuel (395 $ au mois) avec 30 utilisateurs d'équipe et 100 clients. Softr Databases y est annoncé jusqu'à 500 000 enregistrements sur le plan Pro. Pour un outil interne, c'est peu face au coût d'un développement sur mesure.

Avant de partir, il existe une option honnête qui réduit trois outils à un. Softr propose d'importer une base Airtable dans Softr Databases en un clic, sans modifier la base d'origine, avec les enregistrements liés, les pièces jointes et la plupart des formules. Ses workflows intégrés peuvent reprendre une partie des scénarios Make. Notre recommandation est nette : si votre portail est interne, sert quelques dizaines de personnes et que personne n'a eu besoin d'injecter un script pour corriger un bug, ne migrez pas vers du code. Rapatriez Airtable dans Softr Databases, sortez de Make ce que Softr sait faire, et gardez votre budget.

Le calcul s'inverse quand le portail sert vos clients. Les utilisateurs clients se paient au-delà du quota du plan, la logique devient critique pour votre chiffre d'affaires, et vous avez besoin de tests, d'environnements séparés et d'un historique lisible de chaque changement. Si vous hésitez encore entre deux outils no-code, notre comparatif Bubble vs Softr pose les différences, mais changer d'outil no-code ne règle pas la question des trois outils.

Combien de temps prend une migration de Softr vers du code ?

Comptez quelques semaines pour un portail simple sur une base propre, davantage quand la logique est répartie entre des formules Airtable et de nombreux scénarios Make. La durée dépend surtout du temps nécessaire pour relire les règles et les réécrire, beaucoup moins du nombre d'écrans.

Les écrans se reconstruisent vite avec un agent de code IA. Le délai varie surtout selon ces facteurs :

• le nombre de rôles et de règles de visibilité à réécrire et à tester ;
• la forme des données : formules, lookups, rollups, pièces jointes, champs mal typés ;
• le nombre de scénarios Make et de services externes (signature, formulaires, paiement) ;
• la méthode de connexion actuelle et le nombre d'utilisateurs à prévenir ;
• le niveau de continuité exigé, d'une coupure annoncée à une bascule de nuit sans interruption.

Pour la bascule elle-même, on applique ce que nous a appris notre migration de Bubble vers du code. Le script de migration est rejouable. Il a un mode qui valide sans rien écrire, une option pour ne traiter que quelques comptes, et une table de correspondance entre l'identifiant Airtable de chaque enregistrement et son nouvel identifiant, pour pouvoir le relancer sans créer de doublons. On fait une répétition générale l'après-midi sur un export complet, puis l'export final le soir et la bascule dans la nuit. Un second script compte et contrôle ce qui est arrivé de l'autre côté. Puis la recette se fait avec un vrai compte client.

La dernière leçon vient de la migration de notre propre site de Webflow vers Astro. Après la bascule, la source de vérité change de camp. Si quelqu'un modifie encore Airtable le lendemain, ou relance le script depuis un ancien export, il écrase ce qui a été fait depuis. Passez Airtable en lecture seule et verrouillez le script. Pour estimer votre cas, l'inventaire décrit plus haut suffit à donner une fourchette, et notre page sur la migration de Softr vers du code sur mesure détaille la méthode.

Questions fréquentes

Peut-on exporter une application Softr en code ?

Non, à notre connaissance : nous n'avons trouvé dans la documentation de Softr aucune fonction qui exporte le code du portail. Ce qui sort, ce sont les données (par API ou CSV), la liste des utilisateurs en CSV et le code personnalisé que vous avez vous-même injecté. Les écrans se reconstruisent. Notre article sur les outils no-code qui exportent leur code fait le point outil par outil.

Mes utilisateurs devront-ils recréer leur mot de passe en quittant Softr ?

Oui, s'ils se connectaient par mot de passe. Softr ne peut pas les exporter, ils sont hachés à sens unique. Le plus simple est de recréer chaque compte à partir de son e-mail, déjà marqué vérifié, puis d'envoyer un seul message au bon moment avec un lien de connexion. Ceux qui utilisaient un lien magique ou un code par e-mail ne voient presque aucune différence.

Peut-on garder Airtable avec une application en code ?

Oui, une application Next.js peut lire et écrire dans Airtable par son API. C'est utile en transition. À long terme, vous gardez la limite de 5 requêtes par seconde et par base, les plafonds d'enregistrements de votre plan et des règles cachées dans des formules. Nous le conseillons comme étape, rarement comme destination pour un portail client.

Quelle alternative à Softr pour un portail client ?

Pour un portail client qui grandit, la combinaison qu'on recommande le plus souvent est Next.js pour l'interface et Supabase ou PostgreSQL pour les données, les comptes et les droits d'accès. Si votre portail reste interne et simple, la meilleure alternative est parfois de rester sur Softr en regroupant vos données dans Softr Databases pour supprimer un outil.

Faut-il arrêter Softr le jour de la migration ?

Non. Gardez l'abonnement quelques semaines après la bascule, portail dépublié ou réservé aux administrateurs, le temps de comparer des cas réels avec la nouvelle application. Airtable passe en lecture seule pour que personne n'y saisisse plus rien. Vous résiliez une fois la recette terminée et les derniers écarts expliqués.