Écrit par Simon 
WeWeb est le plus facile des outils no-code à quitter. C’est aussi celui qu’on quitte le plus souvent pour de mauvaises raisons.
Facile, parce que WeWeb ne fait qu’une chose : l’interface. Vos données, vos règles d’accès et vos utilisateurs vivent presque toujours dans un autre outil, Supabase, Xano ou Airtable. Changer de front-end ne touche pas à ce socle.
Mauvaises raisons, parce que l’export de code de WeWeb laisse croire qu’on peut partir avec son application. On part avec un build. L’éditeur le dit lui-même. C’est le premier fait à connaître avant de chiffrer quoi que ce soit.
Ce guide pose les signes qui justifient une migration, ceux qui disent de rester, la question du back-end outil par outil, puis le process complet, de l’inventaire à la passation.
Ce qu’il faut retenir
- L’export WeWeb est une application Vue.js compilée, « structurée par une machine, pour une machine » selon sa documentation : un filet, pas un point de départ.
- Le back-end décide du chantier. Supabase reste en place, Airtable part en premier.
- On migre une couche à la fois, jamais l’interface et la base le même week-end.
Que récupère-t-on vraiment quand on exporte une application WeWeb ?
Un build de production, pas un code source qu’on reprend. En 2026, la page produit de WeWeb décrit une application Vue.js autonome, avec ses pages, ses workflows et ses styles, réunis dans un seul livrable. Sa documentation précise que ce code est structuré par une machine, pour une machine. On ne peut pas, dit-elle, construire dans WeWeb puis maintenir le résultat soi-même.
Concrètement, l’export vous donne :
- une application qui tourne, hébergeable sur n’importe quel serveur statique ;
- des fichiers bruts sans composant Vue : le framework n’existe que compilé, dans le build ;
- aucun retour possible : l’import d’un export dans WeWeb n’existe pas.
Trois choses restent derrière. Les plugins qui passent par les services de WeWeb cessent de fonctionner une fois l’application auto-hébergée : la documentation cite Airtable, Notion, Stripe, OpenAI, les connecteurs SQL et WeWeb Auth. Les fichiers déposés sur le CDN de WeWeb ne suivent pas. Et WeWeb ne fournit aucune supervision pour une application hébergée ailleurs.
L’export est réservé à l’offre Essential et au-dessus, à 20 $ par mois sur la grille tarifaire d’avril 2026.
Il a donc une vraie utilité, mais pas celle qu’on lui prête. Exporter régulièrement, c’est assurer la continuité si l’éditeur change ses prix ou ferme un service. Ce n’est pas commencer une migration. Un développeur qui reprend ce build pour le faire évoluer passe plus de temps à le déchiffrer qu’à réécrire l’écran.
Quels signes disent qu’il est temps de quitter WeWeb ?
Ceux qui touchent à la maintenance et au produit, rarement au prix. Une offre Essential coûte 20 $ par mois en 2026. Même après la hausse tarifaire du 12 février 2026, la licence pèse peu face au salaire d’un développeur. Les raisons solides sont ailleurs.
La logique a déménagé dans l’interface. Des dizaines de workflows de page, des formules imbriquées, des variables globales que trois écrans modifient. Dans un éditeur visuel, rien de tout ça ne se teste automatiquement ni ne se relit en revue de code. Au-delà d’un certain volume, chaque changement devient un pari.
Des développeurs arrivent dans l’équipe. Ils travaillent avec des branches, des tests et une intégration continue. WeWeb s’en rapproche, avec ses composants codés en Vue 3 et son serveur MCP piloté par Claude Code ou Codex depuis juin 2026. Mais un développeur qui passe sa journée dans du code finit par vouloir que l’application entière y soit.
Des pages dynamiques doivent être indexées. Le pré-rendu ajouté le 26 août 2026 ne couvre que les pages publiques statiques, selon le journal des versions de WeWeb. Une fiche produit ou un annuaire généré depuis la base reste une application monopage, que tous les robots ne savent pas lire.
Il faut une application mobile native. WeWeb produit des applications web progressives. La documentation ne décrit aucune publication native sur les stores.
L’hébergement des données doit être choisi. L’ancien plugin WeWeb Auth stocke et traite ses données aux États-Unis, sur Amazon Cognito, d’après la documentation d’export. Pour un client qui impose l’Europe, c’est un point de contrat. Le back-end natif lancé en avril 2026, lui, laisse choisir l’Europe : ce signal ne vaut que pour l’ancien plugin.
Quand vaut-il mieux rester sur WeWeb ?
Quand votre architecture est déjà découplée et que personne ne maintiendra le code. Depuis juin 2026, WeWeb se pilote par un serveur MCP depuis Claude Code, Codex ou Gemini. Il accepte aussi des composants Vue écrits à la main. Le plafond de l’outil a monté. Avant de partir, vérifiez que vous l’avez vraiment touché.
Trois situations où l’on vous conseille de rester :
- Vos données sont dans Supabase ou derrière votre API. Le socle vous appartient déjà. Ce qui vous lie à WeWeb, c’est l’interface. Et une interface se réécrit en dernier, quand elle bloque vraiment.
- Personne ne fera évoluer le code. Une application codée sans équipe pour la maintenir devient, en deux ans, plus fragile que l’outil qu’elle remplace. Le sujet est traité en détail dans no-code ou vibe code : qui maintiendra vos outils ?
- Un seul écran résiste. Un composant codé en Vue, intégré dans WeWeb, règle souvent le problème qui motivait la migration. Il coûte quelques jours, pas une refonte.
Rester n’empêche pas de se protéger. Un export régulier, versionné dans un dépôt à vous, couvre le risque de verrouillage fournisseur pour le prix de l’offre Essential.
Faut-il migrer le back-end en même temps que le front ?
Presque jamais en même temps. Souvent, pas du tout. WeWeb se branche sur Supabase, Xano, une API REST ou GraphQL, Airtable et, depuis le 8 avril 2026, sur son propre back-end bâti sur Postgres, d’après l’annonce de lancement. Le sort de chacun est différent.
| Back-end actuel | Ce qu’on en fait | Pourquoi |
|---|---|---|
| Supabase | On le garde | C’est du Postgres, avec ses règles d’accès par ligne. Les empreintes de mots de passe se transfèrent avec la base. Seule l’interface change. |
| Xano | On le garde le temps de la migration du front, puis on décide | Le nouveau front appelle les mêmes points d’API. La sortie de Xano est un second chantier, à ouvrir s’il coince. |
| API maison | On la garde | Le contrat existe déjà. C’est le cas le plus simple. |
| Airtable | On le migre d’abord | Le plugin Airtable de WeWeb passe par ses services et ne survit pas à l’export. L’API d’Airtable plafonne à 5 requêtes par seconde et par base. |
| Back-end WeWeb | On le migre, avec précaution | Il tourne sur Postgres et WeWeb exporte son serveur. Mais en octobre 2026, le guide d’auto-hébergement ne décrit ni l’export des données ni l’hébergement de l’authentification. |
La règle qui s’en dégage : on ne change qu’une couche à la fois. Si le back-end est sain, on réécrit l’interface dessus. S’il coince, on le migre d’abord sous l’interface WeWeb existante, qui continue de servir pendant le chantier. Le cas Airtable est détaillé sur notre page Airtable vers Supabase.
Quitter WeWeb pour du code : que gagne-t-on, que perd-on ?
Vous gagnez la maîtrise, vous payez chaque évolution. Trois plafonds de WeWeb disparaissent avec un code à vous : le pré-rendu, ajouté en août 2026 mais limité aux pages publiques statiques, les composants codés qui ne vivent que dans l’éditeur, l’export qu’on ne maintient pas. En échange, ajouter un champ ne prend plus deux minutes.
| Ce que vous gagnez | Ce que vous payez | |
|---|---|---|
| Évolution | Tests automatisés, revue de code, historique de chaque changement | Chaque modification passe par un développeur et un déploiement |
| Produit | Rendu côté serveur, pages dynamiques indexables, mobile natif possible | Aucun composant prêt à l’emploi : chaque bloc se construit |
| Coût | Plus de licence par développeur, hébergement au choix | Une maintenance à budgéter tous les mois, en jours |
| Dépendance | Le code, le dépôt et l’hébergement sont à vous | Vous dépendez de l’équipe qui connaît le code |
| Équipe | Un recrutement standard : des développeurs Vue ou React | Plus personne côté métier ne modifie un écran seul |
La ligne qui compte est la dernière. Dans WeWeb, un chef de projet sans formation technique ajoute un filtre à un tableau. Dans une application codée, il ouvre un ticket. Pour comparer les deux sur cinq ans, notre article sur le coût d’un outil métier sur mesure détaille les postes qu’on oublie.
Comment préparer la migration de WeWeb vers du code ?
En quatre étapes, avant d’écrire la première ligne. Le process complet en compte dix, sans coupure de service : WeWeb continue de servir ce qui n’est pas encore réécrit. C’est pendant la préparation que se jouent la plupart des dépassements de budget.
1. Faire l’inventaire de l’application
Listez chaque page, chaque workflow global et de page, chaque variable, chaque formule, chaque plugin et chaque appel au back-end. Relevez surtout ce qui sert : les écrans qu’on ouvre, les actions qu’on déclenche. Une migration est le bon moment pour supprimer les trois pages que personne n’a ouvertes depuis six mois.
Faites un dernier export complet et versionnez-le. Il ne servira pas de base de code. Il servira de référence de comportement et de solution de repli.
2. Décider du sort du back-end
Appliquez le tableau plus haut. Si le back-end part, il part avant l’interface. L’application WeWeb est alors rebranchée sur la nouvelle base pendant la transition.
3. Figer le contrat entre le front et le back
Écrivez la liste des appels que l’interface fait au back-end : tables lues, points d’API, paramètres, réponses, droits attendus pour chaque rôle. Le nouveau front doit respecter ce contrat à l’identique. Il sert aussi à tester l’un sans l’autre.
4. Choisir la stack
WeWeb génère du Vue 3. Vue ou Nuxt est le chemin le plus court, puisque la logique d’écrans se transpose presque telle quelle. React ou Next.js se défend si votre équipe le pratique déjà. Prenez un framework qui fait du rendu côté serveur si des pages doivent être indexées. Et un hébergement dont vous choisissez la région.
Comment reconstruire une application WeWeb sans coupure ?
Par modules, derrière un proxy, avec WeWeb en repli jusqu’au dernier jour. L’export de WeWeb, auto-hébergeable, sert de solution de secours si l’éditeur devient indisponible pendant le chantier. Les six étapes suivantes livrent l’application en production morceau par morceau. Aucune ne demande d’arrêter le service. Chacune se vérifie avant la suivante.
5. Reconstruire module par module
La nouvelle application vit sur le même domaine que l’ancienne. Un proxy envoie certaines routes vers le code, les autres vers WeWeb. On commence par le module qui justifie la migration, pas par la page de connexion. Chaque module passe en production avant que le suivant commence.
6. Migrer l’authentification et les utilisateurs
Avec Supabase Auth, rien ne bouge : le nouveau front se connecte au même projet, vos utilisateurs ne voient rien. Si vous changez aussi de projet, la documentation de Supabase confirme que les empreintes de mots de passe suivent la base.
Avec l’ancien WeWeb Auth, adossé à Cognito, la documentation ne prévoit aucune sortie des comptes : la liste des utilisateurs ne se synchronise même pas avec un back-end. Avec l’authentification du back-end natif, l’export n’est pas documenté en octobre 2026 : testez-le avant de chiffrer. Dans les deux cas, deux options : une réinitialisation annoncée par e-mail, ou une connexion par lien magique la première fois. Prévenez vos utilisateurs une semaine avant.
7. Rapatrier les fichiers
Les fichiers stockés sur le CDN de WeWeb ne suivent pas l’export. Téléchargez-les, déposez-les dans un stockage à vous. Puis réécrivez les URL enregistrées en base. Un script, une passe, une vérification par échantillon.
8. Recetter la parité
Pour chaque rôle, écrivez les scénarios qui comptent : créer un dossier, valider une demande, exporter un rapport. Jouez-les dans les deux applications avec les mêmes données. Comparez les résultats. Ces scénarios deviennent ensuite des tests automatisés, ce que WeWeb ne vous offrait pas.
9. Basculer
Le proxy envoie la dernière route vers le code. Posez une supervision d’erreurs dès le premier jour : WeWeb n’en fournissait pas pour l’auto-hébergement. Votre application n’en aura pas d’office. Gardez l’abonnement WeWeb actif un mois, en lecture seule, pour revenir en arrière.
10. Passer la main
Une documentation, un environnement de test, un déploiement automatisé. Et surtout une personne chez vous qui sait livrer une modification. Résiliez les sièges WeWeb après la période de repli. Une application qu’on ne peut pas reprendre sans son prestataire est une migration ratée.
Combien de temps prend une migration de WeWeb ?
Moins que pour Bubble ou Softr, quand le back-end reste. On n’a trouvé aucun chiffre publié pour une sortie de WeWeb. Ceux qui circulent portent sur Bubble, où tout se réécrit : on ne les transpose pas. Ce qu’on sait mesurer, c’est ce qui fait varier la durée.
Elle dépend du nombre d’écrans et de workflows, pas du nombre d’utilisateurs. Elle double quand le back-end part aussi, parce qu’on enchaîne alors deux migrations au lieu d’une. Et elle dérive presque toujours à la même étape : l’inventaire bâclé, qui laisse découvrir en recette un workflow que personne n’avait listé.
Chez Bienfait, on chiffre en jours, écran par écran, après l’inventaire et jamais avant. Un devis donné sur une capture d’écran de l’éditeur rate les workflows, qui sont la moitié du travail. Pour un premier ordre de grandeur, notre simulateur de coût de migration chiffre votre application poste par poste, barème affiché.
En bref
WeWeb se quitte plus facilement que les autres. Mais l’export ne vous fait pas gagner une ligne de code.
Ce qui décide du chantier, c’est le back-end : Supabase reste, Airtable part, le back-end natif de WeWeb demande des précautions. Ensuite, on réécrit une couche à la fois, module par module, avec WeWeb en repli jusqu’au dernier jour.
Chez Bienfait, on commence par l’inventaire et par la question du back-end. Et on vous dit franchement quand un composant codé dans WeWeb suffit.
Et si votre application tourne sur Bubble, où l’interface et la base ne font qu’un, la question change de nature : c’est l’objet de notre guide pour migrer de Bubble vers du code.
Les sources
- WeWeb, Hosting and code export, documentation. Consulté le 2026-10-12. Page
- WeWeb, Code export, page produit. Consulté le 2026-10-12. Page
- WeWeb, WeWeb Pricing, April 2026 Update. Consulté le 2026-10-12. Grille
- WeWeb, WeWeb pricing, 12 February 2026, journal des versions. Consulté le 2026-10-12. Annonce
- WeWeb, WeWeb is now full-stack, journal des versions, 8 avril 2026. Consulté le 2026-10-12. Annonce
- WeWeb, AWS full-stack self-hosting, documentation. Consulté le 2026-10-12. Guide
- WeWeb, journal des versions du 26 août 2026 (pré-rendu des pages statiques). Consulté le 2026-10-12. Entrée
- WeWeb, journal des versions du 25 juin 2026 (serveur MCP). Consulté le 2026-10-12. Entrée
- WeWeb, WeWeb Auth, documentation du plugin. Consulté le 2026-10-12. Page
- WeWeb, Component anatomy, documentation développeur (Vue 3). Consulté le 2026-10-12. Page
- Supabase, Migrating auth users between projects. Consulté le 2026-10-12. Guide
- Airtable, Rate limits, documentation de l’API. Consulté le 2026-10-12. Page
- Google Search Central, Understand JavaScript SEO basics, mis à jour le 4 mars 2026. Consulté le 2026-10-12. Page
Questions fréquentes
Peut-on exporter le code d'une application WeWeb ?
Oui, à partir de l'offre Essential, à 20 $ par mois selon la grille d'avril 2026. L'export est une application Vue.js compilée, prête à héberger. La documentation de WeWeb précise qu'elle n'est pas faite pour être maintenue à la main : c'est un filet de sécurité, pas la base d'une réécriture.
Faut-il migrer le back-end en même temps que le front ?
Rarement. Si vos données sont dans Supabase ou dans une API à vous, on garde le back-end et on ne réécrit que l'interface. On le migre d'abord quand c'est lui qui coince : Airtable et ses 5 requêtes par seconde et par base, ou le back-end natif de WeWeb, dont l'export des données n'est pas documenté en octobre 2026.
Que deviennent les mots de passe en quittant WeWeb ?
Cela dépend de l'authentification d'origine. Avec Supabase Auth, rien ne bouge : le nouveau front se connecte au même projet. Avec l'ancien plugin WeWeb Auth, adossé à Amazon Cognito, la documentation ne prévoit aucune sortie des comptes : il faut prévoir une réinitialisation ou un lien magique.
Vers quel framework migrer une application WeWeb ?
WeWeb génère du Vue 3. Vue ou Nuxt est donc le chemin le plus court pour une équipe qui garde la même logique d'écrans. React ou Next se justifie si votre équipe le pratique déjà. Choisissez un rendu côté serveur si des pages dynamiques doivent être indexées.
Combien de temps dure une migration de WeWeb vers du code ?
Quand le back-end reste en place, c'est le plus court des trajets du no-code vers le code : seule l'interface est réécrite, module par module. La durée dépend du nombre d'écrans et de workflows, pas du nombre d'utilisateurs. Elle double quand le back-end doit partir aussi.
Peut-on revenir dans WeWeb après avoir exporté ?
Non. La documentation de WeWeb répond explicitement que l'import d'un export n'est pas disponible. Toute modification faite dans le code exporté reste dans le code exporté. Chaque nouvel export repart de l'éditeur. C'est une raison de plus pour ne pas retoucher l'export à la main.
