L'essentiel : en juin 2026, Retool bascule vers un app builder uniquement IA sur une nouvelle architecture full-stack en React/TypeScript, couplé à un serveur MCP permettant de créer des applications Retool depuis n'importe quel agent de codage IA (Claude, Codex…). L'ambition est de profiter de la vitesse de l'IA générative sans perdre la gouvernance d'entreprise qui fait la différence de Retool face aux outils de « vibe coding » (Lovable, Replit, v0…).
1. Liste des nouveautés
La nouveauté majeure : un passage d'un moteur de rendu propriétaire et fermé à une stack React + TypeScript standard et inspectable.
Jusqu'ici, les abstractions propriétaires de Retool permettaient de construire vite, mais avaient trois limites : les modèles d'IA ne pouvaient pas travailler nativement dans le format Retool, les développeurs ne pouvaient pas apporter leurs propres outils et workflows, et les applications construites ailleurs (Replit, Lovable, v0, etc.) ne pouvaient pas tourner sur Retool ni hériter de sa gouvernance centralisée. Avec ce nouveau moteur, les applications Retool sont désormais écrites en React côté frontend et en TypeScript côté backend : l'agent IA génère du code standard, inspectable, réutilisable et améliorable par n'importe quelle équipe technique, sans rien enfermer dans un format propriétaire (source).
1.1 Repenser l'expérience comme un vrai éditeur IA
La fonctionnalité s'active depuis les paramètres de l'organisation, avec la possibilité de connecter son propre modèle (AWS Bedrock, Azure, OpenAI…) plutôt que de dépendre uniquement du modèle par défaut de Retool.
Le nouvel éditeur est pensé pour un usage prompt-first : on peut adresser un prompt à l'application entière, ou cliquer sur un élément précis de l'aperçu pour restreindre le prompt à ce composant (source).
1.2 Amélioration du chatbot dans l'application
Retool a également ouvert la porte à beaucoup plus de types d'entrées qu'auparavant : on peut désormais glisser-déposer des captures d'écran, des PDF, des fichiers de design (Figma…) ou des tableurs, et l'agent travaille directement à partir des mêmes références que celles déjà utilisées par l'équipe. Cela permet de reprendre le travail déjà réalisé ailleurs (maquettes, spécifications, jeux de données) et de le transmettre à Retool pour poursuivre la construction de l'application (source).
- Onglet Code : inspection et édition directe du React généré ; cliquer sur un élément de l'aperçu renvoie directement à la ligne de code correspondante.
- Onglet Data : alors que les applications générées par IA rendent souvent difficile de savoir ce qu'elles font réellement avec les données, Retool garde cette couche lisible par construction : chaque logique d'accès aux données est exposée comme une fonction que l'on peut ouvrir et comprendre. Pour les logiques conditionnelles plus complexes, un graphe de données visuel montre les relations entre les entrées et les sources de données, et comment les actions utilisateur se traduisent en opérations sur les données.
Import d'applications existantes : si j'ai une application React déjà commencée sur Lovable, Replit, v0 ou tout autre outil de vibe coding, ou même un projet React issu d'un dépôt local, je peux désormais l'importer directement pour la déployer sur Retool, sans réécriture. Lors de l'import, Retool fait correspondre automatiquement les connexions de données de l'application aux ressources déjà configurées et sécurisées par mon équipe. L'application hérite aussi des permissions Retool au niveau applicatif (RBAC), pour contrôler qui peut la consulter, l'utiliser ou l'administrer, avec les mêmes règles que partout ailleurs dans Retool (source).
Le gros point négatif est qu'il faudra convertir les applications créées avec l'architecture précédente.
Dans l'onglet Chat, un nouveau raccourci « Convert classic app » permet de convertir directement une application « classique » (créée avec l'ancien éditeur Retool, avant cette mise à jour) vers le nouvel éditeur React. Un agent importe le code source de l'app classique en lecture seule, élabore un plan de conversion en plusieurs phases, puis convertit les requêtes sur les ressources, le JavaScript et le reste du code en fonctions équivalentes dans le nouveau modèle. L'application classique d'origine n'est jamais modifiée pendant le processus ; pour les applications complexes, la conversion peut prendre jusqu'à une heure. Les applications classiques restent supportées pendant au moins deux ans après la disponibilité générale du nouvel éditeur : convertir n'est donc pas obligatoire (source).
1.3 MCP : piloter Retool depuis n'importe quel agent IA
L'essentiel : un serveur MCP en bêta publique permet de piloter Retool (apps, ressources, utilisateurs) directement depuis Claude, Cursor, Codex ou Kiro, avec les mêmes garde-fous de sécurité que l'interface web.
Gouvernance et sécurité : là où l'on construit ne devrait pas déterminer son niveau de sécurité. Retool étend son modèle de gouvernance aux agents de codage connectés : que l'on améliore une application existante ou que l'on parte de zéro via le MCP, les changements héritent automatiquement des standards de sécurité déjà approuvés par l'organisation (contrôle d'accès, audit trail, permissions sur les données), configurés une seule fois au niveau de la plateforme plutôt qu'application par application (source).
Au lieu d'ouvrir un navigateur, les administrateurs peuvent interagir directement avec Retool depuis leur environnement de codage IA pour :
- construire et modifier des applications, puis les déployer sur la plateforme Retool ;
- écrire des requêtes sur les ressources connectées pour alimenter des analyses de données ;
- inviter des utilisateurs en masse ou gérer les invitations en attente ;
- auditer les utilisateurs ayant accès à l'organisation ;
- inspecter la configuration de l'organisation et des environnements de ressources ;
- lister l'ensemble des ressources connectées et consulter leur configuration.
Documentation technique : MCP tools reference.
Peut-on désormais exporter le code React pour le déployer en dehors de Retool ?
En bref : le code est plus ouvert (React/TypeScript, synchronisable avec votre dépôt Git), mais l'exécution en production reste liée à la plateforme Retool (changelog).
Ces nouveautés introduisent deux limitations.
1.4 Tout passer par l'IA, est-ce vraiment un progrès ?
Je m'interroge sur la stratégie consistant à devoir (ou pouvoir uniquement) passer par l'IA pour faire des modifications. Là où l'ancien éditeur permettait de rendre un bouton visible ou invisible, ou de changer l'action qu'il déclenche, en deux secondes et d'un clic, tout devra désormais passer par un prompt en langage naturel ou directement en code, puis être testé pour s'assurer qu'il n'y a pas d'effet de bord ou d'incompréhension de la part de l'IA. Sur des modifications triviales et répétitives, ce détour me semble assez limitant, et potentiellement plus lent qu'un clic direct sur l'ancien éditeur.
1.5 La migration forcée des applications complexes
La seconde limite tient à l'obligation, à terme, de migrer les applications complexes construites sur l'éditeur classique vers ce nouvel éditeur IA. Retool a annoncé ne maintenir l'ancien éditeur que pendant les deux prochaines années. Passé ce délai, il ne sera vraisemblablement plus possible d'éditer une application autrement que via l'IA, ce qui pose la question du sort des applications critiques, complexes et déjà stabilisées, pour lesquelles une conversion (même assistée par IA) n'est jamais sans risque.
2. Pourquoi ce changement : la vraie bataille est la gouvernance
Avec l'IA, désormais, n'importe qui peut créer une application. On arrive vite à une situation où des opérationnels sans connaissance technique deviennent les développeurs de leurs propres outils. Le vrai enjeu n'est plus « peut-on créer une app facilement », mais « comment la gérer à l'échelle de l'entreprise ». Retool cherche à répondre à cet enjeu, et cette accélération amène de nouveaux enjeux.
2.1 Visibilité et mutualisation
Un des enjeux clés est de donner de la visibilité sur les applications déjà développées, afin d'éviter que deux personnes travaillent en parallèle sur le même sujet sans le savoir. Cela passe d'abord par un partage clair de la connaissance de ce qui existe ou est en cours de développement, afin que les nouveaux collaborateurs puissent retrouver rapidement les applications déjà en place plutôt que de repartir de zéro, ce qui suppose une documentation ou un référencement centralisé et accessible à tous. À plus long terme, l'objectif est aussi de mutualiser les développements : Retool permet à plusieurs personnes de travailler sur une même application tout en gérant des environnements distincts (test/production, ou par équipe), ce qui ouvre la voie à une collaboration structurée plutôt qu'à des développements isolés et redondants.
2.2 Hébergement et centralisation
Aujourd'hui, certaines applications tournent en local, d'autres sont hébergées un peu partout (Cloudflare, Vercel, AWS…), ce qui rend très difficile pour une entreprise d'avoir une vue d'ensemble centralisée sur tout ce qui existe. Cette dispersion complexifie plusieurs sujets essentiels :
- Le RGPD : un développeur peut choisir un hébergeur simplement parce que c'est ce que lui suggère une IA ou un tutoriel, sans connaître les contraintes de localisation des données (hébergement hors UE, transferts de données personnelles, etc.), exposant l'entreprise à des risques de conformité qu'elle ne maîtrise pas.
- La facturation : chaque service (hébergement, nom de domaine, base de données, API tierces…) génère sa propre facture, souvent sur une carte bancaire ou un compte différent, ce qui rend le suivi des coûts et leur rattachement à un projet précis très fastidieux.
- DNS et URLs : quand chaque application a son propre nom de domaine ou sous-domaine configuré chez un prestataire différent, personne dans l'entreprise ne sait précisément où pointe quoi, ni qui a les droits pour le modifier en cas de besoin (renouvellement, migration, incident).
À cela s'ajoutent d'autres risques : la sécurité et la gestion des accès (mots de passe et clés API dispersés entre plusieurs plateformes, sans vue centralisée sur qui a accès à quoi), la dépendance à une seule personne qui connaît l'architecture d'une application (si cette personne quitte l'entreprise, personne ne sait comment le service est hébergé ni comment le maintenir), et la dette technique liée à l'absence de standards communs, qui rend chaque nouvelle application plus coûteuse à reprendre ou à faire évoluer.
2.3 Sécurité et permissions
Un autre enjeu majeur est de centraliser la gestion des permissions. Il s'agit de savoir précisément qui a accès à quoi, en fonction de la sensibilité de l'application, de sa criticité et des données qu'elle manipule. Cela implique de gérer la connexion des outils entre eux tout en gardant le contrôle sur ces accès. Il faut par exemple éviter que n'importe qui puisse lire ou écrire sur le CRM, qui reste un outil central et critique pour l'entreprise, et dont une mauvaise manipulation peut avoir des conséquences importantes.
Cela passe aussi par la segmentation des environnements et des clés d'API par équipe ou par utilisateur. C'est un point vraiment clé pour limiter le rayon d'explosion en cas d'erreur ou de fuite : si chaque équipe ou chaque application dispose de ses propres accès isolés, un problème sur l'un d'entre eux n'expose pas l'ensemble du système, et il devient beaucoup plus facile d'identifier l'origine d'un incident et de le circonscrire rapidement.
3. Conclusion
Avec cette nouvelle stratégie, Retool vient se positionner en concurrent direct de Lovable for Enterprise sur le segment entreprise : là où les outils de vibe coding misent sur la vitesse de génération pure, Retool ajoute la couche de gouvernance (permissions, audit trail, connexions sécurisées aux ressources, RBAC) qui manquait jusqu'ici pour déployer ce type d'applications à l'échelle d'une organisation. Ce repositionnement n'est pas un simple ajustement produit : il traduit un changement de fond dans la façon dont les entreprises vont devoir gérer la prolifération d'applications internes créées par l'IA.
Je suis convaincu que toute entreprise qui n'adresse pas ce sujet dans les prochains mois va rencontrer des difficultés importantes : multiplication d'applications non répertoriées, dispersion des hébergements et des accès, dépendance à quelques personnes clés qui savent comment un outil a été construit, et exposition croissante à des risques de sécurité et de conformité (RGPD notamment) que l'entreprise ne maîtrise plus. Le vrai risque n'est pas que les équipes créent des applications avec l'IA — cela va continuer, avec ou sans cadre — mais qu'elles le fassent sans aucune gouvernance centralisée.
Le but est de centraliser les applications (visibilité, cycle de vie, hébergement), centraliser l'authentification et les permissions (qui a accès à quoi, avec quelles clés, sur quels environnements), et centraliser les skills ou briques réutilisables (connecteurs aux ressources, workflows, standards de développement) afin que chaque nouvelle application s'appuie sur un socle commun plutôt que de repartir de zéro, ainsi qu'une série de tests avant mise en production. C'est cette centralisation qui permet de conserver le gain de vitesse apporté par l'IA générative, sans en subir les effets de bord en matière de sécurité, de coûts et de dette technique.