Migrer de Retool vers du code : garder la base, réécrire les outils

Quitter Retool est la migration la plus légère du no-code vers le code. Ce n’est pas une raison pour la faire sans y penser.

Retool construit des outils internes : des back-offices, des tableaux de bord, des écrans d’administration. Il ne stocke presque rien lui-même. Il se branche sur vos bases et vos API, exécute vos requêtes SQL sur son serveur et les affiche dans des composants.

D’où une situation rare : la logique est déjà, pour une bonne part, écrite en code. Les requêtes se relisent, les transformations en JavaScript aussi. Ce qui ne sort pas, ce sont les écrans, les droits et les workflows.

Ce guide dit quand partir, quand rester, ce qui se garde. Puis comment migrer outil par outil.

Ce qu’il faut retenir

• Un export Retool ne tourne que dans Retool. Aucun export en React n’existe.
• Votre base reste en place. Les requêtes SQL se réutilisent.
• Les droits se déplacent dans la base, parce que Retool filtrait souvent par requête.

Que peut-on récupérer d’une application Retool ?

Les requêtes, la structure et vos données, qui n’ont jamais quitté vos serveurs. La documentation de Retool décrit un export en JSON ou en archive Toolscript, avec requêtes, composants et modules. Elle précise qu’il ne contient ni les connexions ni les données. Le fichier ne s’exécute que dans Retool.

C’est le seul outil de la série où l’export vaut vraiment quelque chose pour la suite. Pas comme code à exécuter, mais comme inventaire exact : chaque requête, chaque transformation, chaque variable y figure en texte. Un développeur, ou un assistant de code, y lit l’application entière en une heure.

Quels signes disent qu’il est temps de quitter Retool ?

Le prix par utilisateur, l’hébergement et le cycle de développement. La grille de Retool affichée en octobre 2026 facture chaque créateur et chaque utilisateur interne, tous les mois. Sur l’offre Business, 150 utilisateurs internes représentent 2 100 € de licences par mois, avant les créateurs. Notre article sur le coût d’un outil métier sur mesure donne de quoi comparer avec une maintenance.

La facture suit l’effectif. L’offre Business coûte 46 € par créateur et 14 € par utilisateur interne et par mois, en facturation annuelle. Les utilisateurs externes, eux, sont facturés à l’unité au-delà de 50 par mois depuis le 13 septembre 2025.

L’auto-hébergement s’est refermé. Depuis février 2026, les nouveaux déploiements auto-hébergés passent par l’offre Enterprise. Le responsable produit de Retool l’a confirmé sur le forum, en promettant au moins six mois de préavis aux clients existants avant tout arrêt.

Le cycle de développement manque. Branches, revues et Git passent par le Source Control de Retool, réservé à l’offre Enterprise d’après sa grille. Sans lui, des tests et une revue de code avant mise en production restent difficiles.

Les volumes grossissent. Les bonnes pratiques de Retool pour ses applications mobiles situent un impact sévère sur la performance à partir de 5 000 lignes dans un tableau ou de 3 Mo de réponse.

L’outil devient un produit. Un portail client, une application pour des partenaires. Retool les accepte sur ses offres Business et Enterprise, puis facture les utilisateurs externes au-delà de 50 par mois.

Quand vaut-il mieux rester sur Retool ?

Quand vous avez beaucoup d’outils internes, peu d’utilisateurs par outil et une équipe qui en crée chaque mois. Le rapport Build vs Buy 2026 de Retool, une enquête auprès de 817 de ses propres clients, rapporte que 78 % prévoient de construire davantage d’outils internes. C’est le terrain de Retool. Il y est difficile à battre.

Trois situations où l’on vous conseille de rester :

• Les outils sont nombreux et petits. Dix back-offices de cinq utilisateurs chacun se construisent plus vite dans Retool qu’en code. Ce qui coûte, ce sont les outils larges, pas les outils nombreux.
• Personne ne maintiendra le code. Un outil codé sans équipe pour le faire évoluer vieillit plus mal que l’outil Retool qu’il remplace.
• Le problème est un seul outil. Sortez celui-là, gardez les autres. Retool n’oblige à rien de global.

Une sortie intermédiaire existe : Appsmith, ToolJet ou Budibase, trois outils open source qu’on auto-héberge sans prix par utilisateur. Aucun n’importe une application Retool. Notre article sur le no-code open source détaille ce que ce choix implique.

Faut-il migrer la base en même temps que les outils ?

Presque jamais, puisqu’elle n’est pas dans Retool. Retool exécute vos requêtes sur ses serveurs, contre vos bases et vos API, qu’il appelle des ressources. L’export ne contient d’ailleurs aucune ressource. La nouvelle application se branche sur les mêmes. Trois composants font exception.

Le vrai chantier d’une migration Retool, ce sont les droits. La documentation de Retool recommande de filtrer les lignes par current_user dans chaque requête. Elle prévient que ce n’est pas un substitut aux contrôles d’accès de la base. Une requête qui oublie le filtre renvoie tout. Dans le code, ces filtres descendent dans la base, en règles par ligne. Ils ne dépendent plus de chaque écran.

Quitter Retool pour du code : que gagne-t-on, que perd-on ?

Vous gagnez un coût indépendant de l’effectif, un vrai cycle de développement et des droits portés par la base. Vous perdez la vitesse de construction. Dans Retool, un tableau branché sur une table se pose en dix minutes. Dans le code, il demande une page, une API et des tests.

Pour trancher outil par outil plutôt que d’un bloc, notre guide acheter ou construire son outil métier donne les critères.

Comment préparer la migration de Retool vers du code ?

En quatre étapes, avant toute ligne de code. Le process complet en compte dix. Retool sert vos équipes jusqu’à la bascule de chaque outil. Et la préparation est plus courte qu’ailleurs, parce que l’export vous donne un inventaire presque complet.

1. Exporter et inventorier chaque application

Exportez chaque application en JSON, chaque workflow aussi. Versionnez les fichiers. Listez pour chacune ses ressources, ses requêtes, ses transformations et ses groupes d’accès. Relevez le nombre d’utilisateurs actifs par outil : c’est ce qui fixe l’ordre de la migration.

2. Relire les requêtes

Chaque requête SQL se relit : celles qui servent, celles qui doublonnent, celles qui filtrent par current_user. Les bonnes passent côté serveur dans la nouvelle application, presque telles quelles. Les transformations en JavaScript deviennent des fonctions testées.

3. Descendre les droits dans la base

Écrivez la matrice : pour chaque groupe, ce qu’il voit et modifie, table par table. Puis traduisez-la en règles par ligne dans Postgres, ou en contrôles dans l’API. Après cette étape, un écran qui oublie un filtre ne peut plus rien montrer de trop.

4. Choisir la stack

Un outil interne se réécrit bien en Next.js ou en React, avec une bibliothèque de composants comme shadcn/ui, ou un cadre d’administration comme Refine. La connexion passe par votre annuaire, Google Workspace ou Microsoft Entra. Dans Retool, seule la connexion Google est ouverte à toutes les offres : Entra, comme tout SSO SAML ou OIDC, y demande l’offre Enterprise.

Comment reconstruire les outils Retool sans coupure ?

Outil par outil. Chaque application Retool est indépendante, ce qui découpe la migration tout seul : on en remplace une, les autres continuent. Les six étapes suivantes livrent chaque outil en production, puis réduisent la facture Retool au fil des bascules.

5. Reconstruire le premier outil

On commence par celui qui coûte le plus en licences ou qui pose le plus de problèmes. Il se branche sur les mêmes bases que l’outil Retool, qui reste ouvert en parallèle.

6. Migrer Retool Database et Storage

Si un outil s’appuie sur Retool Database, recopiez ses tables dans votre Postgres par l’URL de connexion, puis vérifiez les volumes table par table. Les fichiers de Retool Storage se rapatrient un par un. Leurs liens se réécrivent en base.

7. Réécrire les workflows

Chaque workflow devient une tâche planifiée, un point d’API ou une file de tâches. Les blocs de code JavaScript et Python, que Retool documente pour ses workflows, se reprennent presque tels quels. Ajoutez des journaux et une alerte en cas d’échec.

8. Recetter la parité, droits compris

Jouez les scénarios de chaque groupe dans les deux outils, sur les mêmes données. Puis testez l’inverse : connectez-vous avec un compte restreint et vérifiez qu’il ne reçoit aucune ligne qui ne le concerne pas.

9. Basculer et réduire la facture

Retirez l’outil de Retool et ses utilisateurs avec lui. Retool facture les utilisateurs actifs sur la période, d’après sa documentation de facturation : chaque bascule réduit la note le mois suivant.

10. Passer la main

Une documentation, un environnement de test, un déploiement automatisé et une personne chez vous qui sait livrer. Puis on passe à l’outil suivant, ou on décide que les autres restent dans Retool.

Combien de temps prend une migration de Retool ?

Moins que pour les autres outils, puisque la base reste et que les requêtes se réutilisent. On n’a trouvé aucun retour d’expérience indépendant chiffré. Les fourchettes qui circulent viennent d’agences qui vendent la prestation. On ne les reprend pas comme des faits.

Ce qui fait varier la durée : le nombre d’écrans, de groupes d’accès et de workflows par outil. Elle dérive presque toujours au même endroit : un droit appliqué par un filtre de requête dans Retool, oublié dans la matrice. Il réapparaît en recette sous la forme d’une donnée visible par la mauvaise personne.

Chez Bienfait, on commence par l’export de toutes les applications et par la matrice des droits. Les deux réunis disent presque tout de ce qu’il faut construire. Pour un premier ordre de grandeur, notre simulateur de coût de migration chiffre votre application poste par poste, barème affiché.

En bref

Retool se quitte en gardant sa base. Mais pas en gardant ses droits tels quels.

Les requêtes se réutilisent, les données restent, les utilisateurs sont vos collaborateurs, pas des comptes à migrer. Ce qui se reconstruit, ce sont les écrans et les règles d’accès, outil par outil, avec Retool en repli pour les autres.

Chez Bienfait, on vous dit franchement quels outils méritent de sortir. Et lesquels coûtent moins cher à laisser dans Retool.

Et si votre outil est un front WeWeb sur Supabase plutôt qu’un back-office Retool, le chemin se ressemble beaucoup : c’est l’objet de notre guide pour migrer de WeWeb vers du code.

Les sources

• Retool, Import and export apps, documentation. Consulté le 2026-10-12. Page
• Retool, Source Control, documentation. Consulté le 2026-10-12. Page
• Retool, Pricing, grille affichée en euros. Consultée le 2026-10-12. Grille
• Retool, Billing and usage, documentation (types d’utilisateurs, utilisateurs externes au 13 septembre 2025). Consulté le 2026-10-12. Page
• Forum Retool, Self-hosted docs now state Enterprise only, réponse du responsable produit, 25 février 2026. Consulté le 2026-10-12. Discussion
• Forum Retool, Can I export app produced in Retool to HTML or ReactJS, 31 août 2022. Consulté le 2026-10-12. Discussion
• Retool, documentation de Retool Database, pages Retool Database et External access, consultées le 2026-10-12.
• Retool, Workflows: import and export, documentation. Consulté le 2026-10-12. Page
• Retool, Retool Storage, documentation. Consulté le 2026-10-12. Page
• Retool, documentation des droits, pages Permissions et current_user, consultées le 2026-10-12.
• Retool, documentation mobile, seuils de performance. Consulté le 2026-10-12. Page
• Retool, Build vs Buy Report 2026, enquête auprès de 817 clients et créateurs Retool, fin 2025, contenu d’éditeur, 17 février 2026. Consulté le 2026-10-12. Communiqué
• Dépôts GitHub d’Appsmith (Apache-2.0), de ToolJet (AGPL-3.0) et de Budibase (GPL v3), consultés le 2026-10-12.

Questions fréquentes

Écrit par

Simon

Co-fondateur

in