SMF·BUBBLE
Un prompt peut-il remplacer Bubble ?
Applications no-code — visual web app builder
Bordereau de suivi des pièces
Verdict
Le geste honnête n’est jamais de cloner Bubble lui-même — c’est de reconstruire la seule application spécifique que tu fais tourner dessus, en code brut. C’est un vrai projet de plusieurs jours : des écrans CRUD, deux ou trois workflows, et l’hébergement. Ce que tu abandonnes, c’est l’éditeur visuel, ce qui veut dire que chaque futur changement passe désormais par du code, pas par du glisser-déposer.
Pièce A — Le prompt
Reçu le30.07.2026Avant d’écrire quoi que ce soit, cerne la forme réelle de l’application : les 3 à 5 écrans centraux, les types de données et leurs champs, et le ou les deux workflows qui comptent le plus. Construis ensuite exactement cette application en code — pas un constructeur d’applications généraliste, pas un clone de Bubble. Une forme typique : des pages rendues côté serveur adossées à une vraie base de données, des écrans CRUD (liste avec recherche/filtre, vue détail, formulaires de création/édition avec validation) pour chaque type de donnée, et chaque « workflow » de l’application d’origine réécrit comme une simple fonction — une soumission de formulaire qui met à jour une ligne, envoie un email, et redirige ; tout ce qui était planifié devient une tâche cron dans le même processus. Ajoute une authentification seulement si des personnes autres que le propriétaire vont se connecter ; pour un outil mono-utilisateur, saute l’authentification entièrement et garde-le privé. Stocke les données dans une vraie base avec un export planifié pour que rien ne reste jamais coincé.
Ne construis pas d’éditeur visuel, de système de plugins, ni rien d’autre en forme de plateforme — le livrable est une application qui fonctionne et se déploie sur un petit serveur, pas un outil pour construire d’autres applications. Précise clairement dans le README que chaque futur changement passe désormais par du code : c’est exactement le compromis que représente cette démarche.L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 l’éditeur visuel pour faire des changements sans toucher au code
- B.2 la place de marché de plugins de Bubble
- B.3 l’hébergement et la montée en charge intégrés
- B.4 la possibilité pour un non-développeur de maintenir l’app ensuite
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : no-code platform/ecosystem
Les gens continuent de payer parce que les futurs changements restent visuels — pas besoin de développeur. Dès que tu possèdes le code à la place, chaque changement devient une pull request, pas une modification en glisser-déposer.
Questions
Puis-je récupérer mon application et mes données Bubble existantes ?
Les données, oui — Bubble peut exporter ta base de données en CSV, et ça correspond au nouveau schéma. L’application elle-même ne se transfère pas : les workflows visuels de Bubble doivent être relus et réécrits en code à la main, un par un.
Ça marche sur mon téléphone ?
En tant que page web responsive, oui, de la même façon que la version Bubble. Il n’y a pas d’application native dans un cas comme dans l’autre, donc rien ne change de ce côté.
Combien ça coûte à faire tourner ?
Un petit VPS et une base de données, typiquement cinq à dix dollars par mois — souvent moins qu’un forfait Bubble chargé en workflows, puisque tu ne paies que ton propre serveur.
Quelle est la chose qui ne survit pas à la reconstruction ?
Les changements visuels, sans code. Chaque futur ajustement — un nouveau champ, un nouvel écran, un workflow modifié — passe désormais par le code et un déploiement, pas par une modification en glisser-déposer dans un onglet de navigateur.
Outils proches
Récépissé