Le développement mobile a longtemps suivi une règle simple : soit rapide, soit avec le code source. Les plateformes no-code classiques apportaient la vitesse mais enfermaient le projet dans un moteur propriétaire. Développer en React Native donnait le contrôle, au prix d’une équipe et de mois de travail. Draftbit tente de réunir les deux mondes : un éditeur visuel qui, à la sortie, livre du vrai code React Native plutôt qu’une boîte noire.
Cela ressemble au compromis parfait, mais le diable est dans les détails. Nous avons démonté Draftbit : ce qu’il sait faire, où il trébuche, combien il coûte, comment il se compare à FlutterFlow et Adalo, et à qui il s’adresse vraiment.
Qu’est-ce que Draftbit
Draftbit est une plateforme cloud pour construire des applications mobiles. Elle fonctionne entièrement dans le navigateur, et le résultat est un projet React Native sur le framework Expo. L’idée centrale est simple : vous assemblez l’interface à la souris sur un canevas infini, vous connectez des données, et la plateforme génère du vrai code que vous pouvez télécharger, exécuter en local et modifier à la main.
C’est exactement ce qui distingue Draftbit des créateurs no-code « boîte noire », où l’application n’existe qu’à l’intérieur du service. Pas de vendor lock-in dur : si la plateforme ne vous plaît plus demain, le projet continue de vivre dans une toolchain React Native standard et peut se développer sans Draftbit.
Ces dernières années, le produit a nettement basculé vers l’IA. L’éditeur repose désormais sur des agents (sur la base de modèles de code populaires), et une partie du travail se décrit en mots au lieu de s’assembler à la main. Draftbit ne se positionne plus seulement comme un créateur, mais comme un environnement hybride entre le no-code et le développement complet.
Avantages et inconvénients
Soyons honnêtes dès le départ : les inconvénients ne manquent pas non plus.
Avantages :
- À la sortie, du vrai code React Native/Expo, sans vendor lock-in.
- Éditeur visuel sur canevas infini, compréhensible par un non-développeur.
- Des agents IA transforment une description textuelle en écran fonctionnel.
- Intégration prête avec Supabase et toute API REST/GraphQL.
- Aperçu en direct dans le navigateur, sur l’appareil et dans les simulateurs iOS/Android.
- Publication sur le web, l’App Store et Google Play depuis un seul endroit.
- Export vers GitHub et en zip, plus prise en charge de composants de code personnalisés.
- Navigation claire : stacks, onglets et menus drawer se configurent visuellement.
Inconvénients :
- Les tarifs se mesurent en crédits : une génération intensive par agent vide vite le quota.
- L’export complet du code et la publication en boutique ne sont que dans les offres payantes.
- L’éditeur vise le bureau : depuis une tablette ou un téléphone, la mise en page est pénible.
- La liste des intégrations prêtes est plus étroite que le monde des modules natifs.
- La plateforme cible le marché anglophone : aucun support ni ressource en français.
- Les animations complexes, les gestes inhabituels et la logique native lourde exigent toujours du code manuel.
- Le modèle de crédits rend les dépenses moins prévisibles qu’un abonnement fixe.
À quoi ressemble le travail : éditeur et composants
La base de Draftbit est un éditeur visuel. Les écrans sont listés à gauche, le canevas au centre, les propriétés de l’élément sélectionné à droite. Les composants se glissent à la souris : blocs de texte, boutons, images, listes, formulaires, cartes, onglets, barres de navigation. Chaque élément offre espacements, typographie, états (normal, enfoncé, désactivé) et adaptabilité aux différentes tailles d’écran.
Les composants se décrivent comme dans le monde React Native : ce sont les mêmes vues et styles, simplement assemblés via un panneau. Mieux : vous pouvez écrire vos propres composants en JavaScript et brancher des bibliothèques externes quand les standards ne suffisent pas. C’est la différence clé avec les créateurs « fermés » : Draftbit ne craint pas que vous regardiez sous le capot.
La navigation est une couche à part. Les stacks, onglets et menus drawer sont pris en charge, avec transitions et passage de paramètres entre écrans. La navigation est précisément l’endroit où les créateurs visuels s’effondrent d’ordinaire — ici, elle s’assemble de façon prévisible et s’exporte tout aussi prévisible en code.
Il y a aussi la collaboration : dans les offres d’équipe, plusieurs personnes peuvent modifier un projet en même temps, avec rôles et permissions séparés. Pour les agences et les équipes produit, c’est essentiel : fini l’envoi de fichiers et l’attente de son tour.
Agents IA : de la description à l’écran
Le nouveau cœur du produit, ce sont les agents. Vous écrivez en langage courant ce dont vous avez besoin (« ajoute un écran de profil avec avatar, nom et bouton de déconnexion »), et l’agent modifie le projet. Les changements apparaissent immédiatement dans l’éditeur visuel et dans le code, et le résultat se vérifie dans l’aperçu en direct.
C’est un modèle hybride intéressant :
- Le designer modifie les écrans à la souris et veille à la cohérence visuelle.
- Le développeur lit le code, branche des bibliothèques externes et affine la logique.
- L’agent prend en charge la routine : écrans brouillons, formulaires, composants typiques.
Mais ce sont justement les agents qui coûtent de l’argent. Ils consomment des crédits, et l’accès est limité sur l’offre gratuite. Un projet peut tourner dans plusieurs sandboxes cloud isolées en même temps — davantage dans les offres supérieures — et plusieurs agents peuvent travailler en parallèle. Cela accélère le travail, mais demande de la prudence : plus d’agents en marche, plus vite le quota mensuel disparaît.
Données et backend
Draftbit n’impose pas de backend précis, mais par défaut il vous pousse vers Supabase. C’est pratique : base de données, authentification et API apparaissent presque sans configuration, et un projet de départ obtient un backend fonctionnel immédiatement.
Au-delà, la plateforme se connecte à n’importe quel endpoint REST et GraphQL et récupère des données depuis des tables et des services externes. Dans les offres supérieures, des serveurs MCP personnalisés sont disponibles — un mécanisme qui permet à l’agent de travailler directement avec vos sources de données. Cela semble abstrait, mais en pratique l’agent peut non seulement maquetter des écrans, mais aussi récupérer le schéma de données de votre service.
Pour un MVP typique, c’est plus que suffisant : liste de produits, profils utilisateurs, commandes, chats, un fil — tout se construit sur des intégrations standard. Et s’il faut une source de données unique, on la branche via une simple requête REST sans complications.
Code et absence de vendor lock-in
L’argument principal de Draftbit est l’export du code source. À partir d’une certaine offre, un projet s’exporte en archive ou se pousse vers GitHub. Ce sont les vrais fichiers React Native, qui compilent via Expo et s’ouvrent dans n’importe quel éditeur de code.
Ce que cela apporte en pratique :
- Le projet se transmet à une équipe de développement sans perte.
- On peut ajouter un module natif absent du créateur.
- On peut quitter la plateforme sans réécrire l’application de zéro.
- Le code se versionne dans git comme n’importe quel projet.
- On peut brancher ses propres modèles et clés API.
Pour une entreprise, cela réduit le risque : même si la plateforme change ses tarifs ou ferme, l’application vous reste. C’est pourquoi Draftbit est souvent choisi comme premier pas « sûr » vers le mobile — un pas dont on peut ressortir.
Publication sur le web, l’App Store et Google Play
Draftbit peut publier une application de plusieurs façons. La plus simple est la version web sur un sous-domaine draftbit.dev, disponible même sur l’offre gratuite. Viennent ensuite les builds iOS et Android et la publication dans les boutiques.
Sur l’offre Pro, on promet une aide à la soumission App Store — cela épargne beaucoup de nerfs, car les règles d’Apple et de Google sont une aventure en soi. Les domaines personnalisés et la suppression du branding Draftbit sont dans les offres payantes : pour un produit client, c’est le minimum, car le logo d’un créateur tiers sur l’écran de l’appli fait peu professionnel.
Rappelez-vous les exigences des boutiques : les comptes développeur (Apple Developer, Google Play Console) restent à votre charge, et aucun créateur ne les paiera pour vous.
Tarifs
Le modèle de facturation repose sur les crédits. Une offre vous donne un stock mensuel de crédits, dépensés en travail, surtout par les agents IA. Assembler à la main coûte peu de crédits ; la génération intensive en coûte beaucoup.
Offres approximatives au moment de la publication (vérifiez la page officielle des tarifs — les limites et les grilles ont changé plusieurs fois) :
- Free — 0 $ : jusqu’à ~10 000 crédits par mois, quelques projets, éditeur visuel, publication web sur draftbit.dev, accès limité aux agents.
- Standard — environ 20 $/mois : plus de crédits, projets et intégrations illimités, export complet du code, publication iOS/Android/web, domaines personnalisés, sans branding.
- Pro — environ 40 $/mois : encore plus de crédits, plusieurs agents en parallèle, serveurs MCP personnalisés, export GitHub, simulateurs, aide App Store, support prioritaire.
- Team — environ 200 $/mois : ~250 000 crédits, 10 sièges éditeur, collaboration en direct, sessions de formation.
- Enterprise — sur devis : SSO/SAML, déploiement privé ou auto-hébergé, SLA, infrastructure dédiée.
La facturation annuelle offre généralement une remise d’environ 20 %. Les sources citent des chiffres différents — fiez-vous à la page officielle : la grille de Draftbit a changé plusieurs fois, et les limites de crédits dépendent de la politique en cours.
Tests et scénarios concrets
Nous avons parcouru plusieurs scénarios typiques pour voir où Draftbit est fort et où il ne l’est pas.
MVP pour une startup. Écran d’onboarding, auth via Supabase, liste de produits depuis une API REST, fiche produit, panier. L’essentiel s’assemble visuellement en quelques heures, le reste est terminé par l’agent. Pour publier en boutique, il faut au moins l’offre Standard. Verdict : scénario excellent, c’est pour cela que la plateforme a été créée.
Outil interne. Une appli pour salariés : liste de tâches, formulaires, annuaire, notifications push. Draftbit y brille : pas besoin d’un design parfait, ce qui compte c’est la vitesse et un backend fonctionnel. Peu de crédits consommés, car tout est standard.
Marketplace. Plus difficile : il faut des paiements, des rôles, de la modération, une intégration de prestataire de paiement. Une partie de la logique devra s’écrire en code ou passer par des services tiers. Draftbit s’en sort, mais cesse d’être un « créateur pour débutant ».
Un jeu ou du travail matériel. Verdict honnête ici : ce n’est pas pour cet outil. Graphismes lourds, caméra en temps réel, appareils Bluetooth, animation complexe : c’est le territoire du développement natif, et un créateur visuel ne fait que gêner.
Draftbit face à la concurrence
Comparons avec les principales alternatives.
Draftbit vs FlutterFlow. FlutterFlow génère du code Flutter, Draftbit du React Native. Si votre équipe connaît Flutter et Dart, FlutterFlow est plus logique. Si c’est JavaScript et React Native, prenez Draftbit. En maturité d’écosystème, FlutterFlow semble plus dense ; en flexibilité du code, Draftbit est plus proche du développement « réel ».
Draftbit vs Adalo. Adalo est plus accessible aux débutants et plus simple dans le scénario de base, mais enferme bien plus dans son environnement : l’export et le contrôle du code sont limités. Draftbit est plus dur au départ, mais livre le code source.
Draftbit vs Bubble. Bubble, c’est pour le web, Draftbit pour le mobile. Pour un marketplace ou un SaaS dans le navigateur, prenez Bubble ; pour une appli en boutique, Draftbit.
Draftbit vs développement natif. Une équipe native offre un contrôle et des performances maximaux, au prix du temps et du budget. Draftbit gagne là où le time-to-market compte et où le produit teste encore une hypothèse.
Sécurité et travail d’équipe
Une question fréquente dans les formulaires d’achat : où sont stockées les données ? Le code du projet vit dans le cloud Draftbit, mais les offres d’équipe proposent des options privées et auto-hébergées, ainsi que SSO et SAML. Pour le segment entreprise, c’est obligatoire, et la plateforme le couvre.
Sur les offres gratuite et inférieures, la séparation des rôles est modeste, et la collaboration en direct n’apparaît qu’avec Team. Si plus d’une ou deux personnes travaillent sur le projet, mieux vaut viser directement les offres d’équipe — sinon il faudra se coordonner « chacun son tour ».
Limites de performance et pièges
Une application Draftbit est du React Native classique, donc en vitesse elle ne le cède pas à une appli faite main sur le même stack. Le rendu natif est préservé et l’interface reste réactive. Les problèmes commencent là où le produit bute sur une logique complexe pour laquelle le créateur n’a tout simplement pas de bloc prêt.
Pièges à connaître d’avance :
- Les crédits se consomment de façon imprévisible. Un travail intensif des agents peut brûler le quota mensuel en quelques jours, sans que ce soit évident au départ.
- Certaines fonctions sont payantes. Export du code, simulateurs, intégration GitHub : tout est hors de l’offre Free.
- L’écosystème de templates est plus modeste que celui des grands créateurs web : ne comptez pas sur une solution clé en main.
- Mises à jour de la plateforme. Draftbit a changé plusieurs fois offres et limites ; révisez le budget chaque année.
À qui s’adresse Draftbit
Draftbit n’est pas un remplacement du développement natif ni un créateur jouet. C’est un outil pour des situations précises :
- Fondateurs et product managers qui ont besoin d’un MVP dans l’App Store en quelques semaines, pas en mois.
- Équipes avec un développeur React Native qui veulent accélérer la routine de mise en page.
- Agences qui construisent des applis clients à partir d’un modèle.
- Outils internes : applis pour salariés, équipes terrain, comptabilité.
- Designers qui veulent transformer une maquette en appli fonctionnelle sans équipe.
Il ne convient pas si l’appli exige une logique native lourde (jeux, matériel, graphismes complexes) ou si le budget n’inclut simplement pas d’abonnement.
Questions fréquentes
Faut-il savoir programmer ? Non. Le scénario de base s’assemble visuellement. Mais plus le produit est complexe, plus les connaissances en JavaScript et React Native sont utiles.
Que se passe-t-il si j’arrête de payer ? Vous pouvez exporter le code et poursuivre le développement vous-même. L’appli ne cesse pas de fonctionner.
Puis-je utiliser mon propre backend ? Oui, via REST ou GraphQL. Supabase n’est qu’un backend par défaut pratique, pas une obligation.
Draftbit publie-t-il l’appli à ma place ? La plateforme aide pour les builds et la soumission, mais les comptes développeur chez Apple et Google sont ouverts et payés par l’utilisateur.
Combien de crédits me faut-il ? Cela dépend de l’usage des agents. L’assemblage manuel est bon marché, la génération par mots coûte cher.
Verdict
Draftbit est l’un des rares outils no-code/low-code qui ne cherche pas à vous enfermer dans sa sandbox. Du vrai code React Native, un export GitHub, le support d’agents IA et un chemin clair vers l’App Store : une combinaison solide pour lancer vite un produit mobile.
On le paie en crédits et en abonnement : l’offre gratuite convient pour essayer, apprendre et publier sur le web, tandis qu’un vrai produit nécessite au moins Standard. Le modèle de crédits est le principal défaut : les dépenses sont plus difficiles à prévoir qu’avec un abonnement fixe, surtout si l’équipe sollicite intensément les agents.
Si vous voulez le contrôle du code et de la vitesse, Draftbit mérite un test court : l’offre gratuite permet d’évaluer l’éditeur avant de payer. Si vous voulez des performances maximales et des fonctions natives, une équipe de développement classique reste imbattable.
Avez-vous déjà essayé de construire une appli mobile de façon visuelle ? Partagez votre expérience : qu’est-ce qui l’a emporté, la vitesse du créateur ou la liberté du code ?