Thunkable Review 2026: Fast Prototypes, Frequent Crashes

Je vais vous expliquer exactement ce qui s’est passé, de l’observation de l’IA générer 1 000 lignes de code en trois minutes aux erreurs d’exécution avant même de pouvoir tester l’écran de connexion. Vous verrez ce que Thunkable fait brillamment, où il s’effondre complètement, et si cela vaut vraiment votre budget de jetons pour votre cas d’utilisation spécifique.

Qu’est-ce que Thunkable ?

Thunkable est une plateforme no-code de création d’applications mobiles qui utilise l’IA pour générer des applications iOS et Android natives à partir d’instructions textuelles.

Contrairement aux plateformes no-code traditionnelles qui reposent sur des blocs glisser-déposer, le générateur IA de Thunkable produit du code réel, complet avec fichiers JavaScript, structures de composants et styles.

Vous pouvez voir l’IA « réfléchir » à vos besoins, décomposant votre requête en structure d’application, style de design, fonctionnalités principales et modèles de données avant de rédiger le code. Cette transparence le distingue des générateurs IA en boîte noire qui masquent les détails techniques.

Quels problèmes résout-il ?

• Rapidité par rapport à un développement à partir de zéro : construire une application multi-écrans avec authentification, formulaires et gestion des données, ce qui prendrait des jours en développement traditionnel, se fait en quelques minutes
• Interface mobile professionnelle sans compétences en design : l’IA comprend les schémas de design mobile et génère des applications qui donnent une impression native, pas comme des sites web mobiles
• Flexibilité pour les utilisateurs techniques : contrairement aux outils purement no-code, vous avez accès au code React Native sous-jacent, permettant aux développeurs de personnaliser au-delà de ce que génère l’IA

Comment il se positionne : alors que des plateformes comme Bubble se concentrent sur les applications web avec éditeurs visuels et que Flutterflow cible les développeurs souhaitant du code Flutter, Thunkable fait le lien. Il est assez rapide pour que des fondateurs non techniques puissent prototyper tout en étant accessible en code pour les développeurs désirant garder le contrôle.

À qui s’adresse Thunkable ?

Thunkable convient particulièrement aux créateurs ayant une affinité pour la technologie qui souhaitent des prototypes d’applications mobiles rapides et n’ont pas peur de résoudre des problèmes ou de jeter un œil au code lorsque des problèmes surviennent. Il convient également à :

• Fondateurs de startups validant des idées mobile-first : si vous construisez une marketplace, un système de réservation ou un portail de services et avez besoin d’un prototype fonctionnel iOS/Android à présenter aux investisseurs ou aux premiers utilisateurs, Thunkable vous permet de passer de l’idée à une application testable en quelques heures.
• Développeurs Python explorant le développement mobile : vous maîtrisez la logique backend et les API, mais apprendre Swift ou Kotlin semble excessif pour un MVP. Thunkable génère du code React Native que vous pouvez lire et modifier, vous permettant de prototyper rapidement des interfaces mobiles tout en concentrant vos compétences backend sur les intégrations d’API.
• Propriétaires de petites entreprises créant des outils internes : vous pouvez décrire votre flux de travail en langage simple, obtenir un prototype fonctionnel et le déployer en tant qu’application web ou application mobile native sans engager une équipe de développement.

Pas idéal pour : les utilisateurs non techniques s’attendant à une expérience sans code et sans erreur. L’IA génère fréquemment du code bogué et corriger les erreurs d’exécution nécessite soit de dépenser des jetons dans des tentatives « Fix with AI », soit d’éditer vous-même le JavaScript.

Avantages et inconvénients de Thunkable

Essayez Thunkable gratuitement et regardez l’IA transformer votre concept d’application mobile en code fonctionnel en moins de 5 minutes. Pas de Swift, pas de Kotlin, juste vous et une zone de texte.

Fonctionnalités de Thunkable

• L’IA génère du code React Native à partir d’instructions
• Applications multi-écrans avec navigation inférieure
• Authentification utilisateur et gestion des rôles
• Générateurs de formulaires avec menus déroulants et validation
• Contrôle de version pour chaque itération de code
• Publication sur iOS, Android ou web
• Intégrations : Airtable, Firebase, Google Sheets, Xano
• Téléchargement de fichiers APK/AAB pour déploiement

Mon expérience pratique avec Thunkable

Voici mon récit complet de la création d’un portail de demandes de service avec Thunkable. Je voulais un système complet avec connexions utilisateur, tableau de bord et base de données fonctionnelle. Voici exactement comment cela s’est déroulé, chaque clic et chaque frustration inclus.

1. Premiers pas : inscription et premières impressions

Je suis arrivé sur la page d’accueil de Thunkable, et la première chose que j’ai vue était un appel à l’action massive et minimaliste : « Transformez votre idée en application ».

Au centre de l’écran se trouvait une grande zone de texte blanche. En dessous, quatre catégories suggérées pour vous aider à démarrer :

• Planification d’événements
• Gestion des inventaires
• Voyage
• Méditation

J’ai remarqué que si vous cliquez sur l’une d’elles, la zone de saisie se remplit automatiquement avec une description exemple.

Je ne voulais cependant pas d’un modèle ; je voulais voir si l’IA pouvait gérer une demande complexe et multi-niveaux.

Mais avant même de pouvoir taper un seul mot, je voulais créer un compte. J’ai cliqué sur le bouton « Sign up » en haut à droite.

Une fenêtre blanche épurée est apparue, proposant trois façons de s’inscrire :

• Continuer avec Google
• Continuer avec Apple
• S’inscrire par e-mail

J’ai saisi mon adresse e-mail et cliqué sur le bouton bleu « Sign up with email ». Thunkable n’utilise pas de mot de passe lors de cette phase initiale.

Ils utilisent à la place un système de « magic link ». J’ai dû quitter le site, ouvrir ma boîte mail dans un nouvel onglet et trouver le message de « The Thunkable Team ». J’ai cliqué sur « Confirm ». Enfin, j’ai été redirigé vers le tableau de bord Thunkable.

La première chose que j’ai remarquée une fois connecté, c’est l’interface incroyablement épurée. Il n’y avait ni pop-up « Welcome! Let’s take a tour », ni vidéos tutoriels, ni chatbot gênant qui vous salue.

Voici ce que j’en ai pensé :

L’inscription fut rapide, mais je ne suis pas fan des magic links car ils vous obligent à naviguer entre les onglets. En revanche, l’interface est magnifique. Elle n’est pas surchargée de mille boutons ou barres latérales ; il n’y a qu’une grande zone de saisie qui vous regarde, ce qui rend tout le processus très accessible pour quelqu’un qui ne sait pas par où commencer.

2. Ma première requête et les limites de caractères

Je suis retourné à l’écran principal de saisie pour entrer les détails de mon projet. Je voulais créer un « Portail de demande de service » pour les propriétaires.

Ce n’était pas une simple demande ; je voulais un flux de travail complet. J’ai passé quelques minutes à rédiger une requête très précise pour voir si l’IA suivrait mes instructions à la lettre.

J’ai également inclus une structure de données détaillée pour deux tables : une « Services Table » et une « Users Table ». J’ai même défini des rôles pour « Customer » et « Admin ».

Ce qui m’a surpris, c’est que la zone de saisie était très généreuse. J’ai collé ma requête détaillée, qui comptait près de 300 mots, et elle n’a pas été tronquée.

Je n’ai vu aucun compteur de caractères ni avertissement de « longueur maximale ». Elle a simplement accepté le texte et attendu que j’agisse. Une fois satisfait de ma requête, j’ai cliqué sur le bouton rouge « Generate App » en bas de la zone.

Mon avis sur le processus de saisie :

Cette étape était fluide. C’était très naturel, presque comme si j’écrivais un brief pour un freelance. J’ai adoré pouvoir être très précis sur les colonnes de données et les options du menu déroulant sans que l’outil ne se perde.

Comparé à d’autres constructeurs qui ne proposent qu’une petite zone d’une seule ligne, la large zone de saisie de Thunkable vous encourage vraiment à être détaillé. Vous avez l’impression de maîtriser la conception dès la première seconde.

3. Observation de la construction par l’IA : la phase de « réflexion »

Dès que j’ai cliqué sur generate, l’écran est devenu sombre et un message d’état est apparu : « Analyzing your request ».

C’était la partie la plus intéressante de toute l’expérience. Au lieu d’un simple spinner de chargement, Thunkable m’a montré un journal en direct du « processus de réflexion » de l’IA.

J’ai regardé l’IA décomposer ma requête en quatre catégories distinctes :

• Structure de l’application : il a opté pour une mise en page à « Navigation inférieure » avec trois écrans principaux : Accueil, Nouvelle demande et Profil.
• Style de design : il a retranscrit ma demande d’une « couleur principale bleue » et d’une esthétique « professionnelle ». Il a également noté « interface propre et moderne » comme objectif.
• Fonctionnalités principales : il a énuméré les composants qu’il comptait construire, notamment le système de connexion/inscription, le formulaire de demande de service et le tableau de bord avec filtrage par statut.
• Structure des données : il a confirmé la création de deux tables : users et service_requests. Il a même listé les colonnes créées, comme id, service_type et status.

Après l’analyse, l’écran est passé à un éditeur de code complet. J’ai regardé l’IA taper littéralement du code React Native.

Je pouvais voir les fichiers se créer dans la barre latérale gauche. Des fichiers comme App.js, theme.js et HomeScreen.js apparaissaient un à un. Je voyais la logique se rédiger : des fonctions pour handleSubmit, fetchRequests et toggleStatus.

Le processus complet, du clic sur « Generate » à l’application « terminée », a pris presque exactement trois minutes. Une petite notification est apparue en bas : « Your app has been generated ! », et un bouton bleu « Preview » est apparu.

Voici ce que j’en ai pensé :

Voir le « processus de réflexion » de l’IA était incroyable. Cela m’a permis de vérifier si elle comprenait vraiment ma demande avant même de commencer à écrire le code.

C’est un peu étrange d’être dans un outil « no-code » et de regarder 1 000 lignes de JavaScript, mais c’est vraiment génial si vous voulez comprendre comment votre application fonctionne en interne. Cela enlève tout le mystère de la « boîte noire » de l’IA.

4. Premier aperçu : examen de l’application générée

Lorsque la génération a été terminée, j’ai cliqué sur le bouton « Preview ». Un émulateur de téléphone mobile est apparu sur la droite de l’écran.

Ma première impression a été que l’application avait un rendu très épuré et « natif ». Elle ne ressemblait pas à un site web mobile ; elle avait l’air d’une véritable application que l’on trouve sur l’App Store.

Voici un aperçu de ce que j’ai vu :

• Le tableau de bord : le premier écran affichait la liste des « Service Requests ». Il comportait un bel en-tête et une barre de bascule en haut avec quatre onglets : All, Pending, In Progress et Completed.
• Le schéma de couleurs : il suivait parfaitement mes instructions. Les boutons étaient d’un bleu profond professionnel, et l’arrière-plan d’un gris doux faisait ressortir les cartes blanches.
• La navigation : en bas de l’écran, un menu clair proposait trois icônes : « Requests », « New Request » et « Profile ».
• Le rendu : cela penchait clairement vers un style « professionnel ». Les polices étaient nettes, les espacements entre les éléments étaient uniformes, et il utilisait des schémas d’interface mobile standard, très familiers.

Cependant, le tableau de bord était vide. Il n’avait pas généré de « données factices » pour me montrer à quoi ressemblerait une demande dans la liste, ce qui rendait un peu difficile l’évaluation du rendu final sans ajouter manuellement des données.

Mon ressenti au premier regard : le design correspondait exactement à ma demande, professionnel et bleu. Il n’a pas cherché à être trop « original », ce que j’ai apprécié pour un portail de service. J’ai été impressionné par la gestion des onglets et de la navigation ; c’était très fluide.

Ma seule petite critique est que j’aurais aimé qu’il génère quelques demandes de service factices pour que l’écran ne soit pas si vide au démarrage. Cela aurait renforcé l’effet « wahou ».

5. Quand les erreurs ont commencé : la boucle de dépannage

La phase de lune de miel s’est terminée dès que j’ai essayé d’interagir réellement avec l’application. J’ai cliqué sur l’onglet « New Request » pour voir mon formulaire, et au lieu du formulaire, une boîte violette est apparue sur l’émulateur. Il était écrit :

Runtime Error: Your app encountered an error while running. Cannot read properties of null (reading ‘id’) at Line 433, Column 50. Error location: the ‘HomeScreen’ screen.

Je n’avais même pas encore touché au code que l’application plantait déjà. Cependant, Thunkable semble s’y attendre.

À l’intérieur de la boîte d’erreur, un grand bouton indiquait « Fix with AI ». J’ai cliqué dessus, et l’IA est repassée en mode « réflexion ». Elle a passé environ 45 secondes à « réanalyser » le code, puis a actualisé l’aperçu.

La première panne avait disparu, et j’ai finalement pu voir le formulaire « New Service Request ». Il était exactement comme je l’avais décrit :

• Un menu déroulant pour le « Service Type » avec Plumbing, Electrical, etc.
• Une grande zone de texte pour la description.
• Un sélecteur de date pour la date préférée.
• Un menu déroulant « Urgency Level ».

Mais ensuite, j’ai essayé de cliquer sur l’icône « Profile » pour voir mes informations utilisateur, et une deuxième erreur est apparue :
Runtime Error: Cannot read properties of null (reading ‘name’) at Line 949, Column 42.

Ce que j’en ai pensé :

Cette partie était frustrante. L’IA est un excellent designer, mais c’est une codeuse bugguée. Elle semblait avoir du mal avec la logique d’« authentication ». Elle cherchait à récupérer le nom ou l’ID d’un utilisateur avant même que je sois connecté ou que j’aie créé un compte, ce qui faisait planter toute l’application.

Le bouton « Fix with AI » est puissant, mais devoir l’utiliser trois fois juste pour voir trois écrans différents était un peu décevant. J’avais l’impression que l’application n’était pas encore tout à fait « prête pour la production ».

6. Crédits et limites de jetons : le coût de la construction

Alors que j’appuyais sur ce bouton « Fix with AI », j’ai commencé à me demander combien cela me coûtait. J’ai cliqué sur les paramètres de mon compte et trouvé une section « Tokens ».

Sur le « Free Plan », j’ai vu que j’avais reçu 1,2 k jetons. Chaque fois que l’IA génère une nouvelle application ou tente de corriger un morceau de code, cela puise dans cette limite.

J’ai remarqué qu’après ma génération initiale et mes deux « fixes », mon nombre de jetons avait diminué d’environ 250.

Cela signifie que si vous avez une application complexe nécessitant beaucoup de dépannage, vous pourriez facilement épuiser vos jetons gratuits en une seule après-midi.

Mon avis sur les limites de crédits :

C’est un système équitable, mais cela ajoute un peu de stress au processus de construction. À chaque fois que je cliquais sur « Fix with AI », j’avais l’impression de dépenser de l’argent. Ce serait mieux si les corrections par l’IA ne comptaient pas dans votre limite, surtout lorsque les erreurs sont causées par le code généré par l’IA elle-même.

7. Personnalisation du design : no-code vs. high-code

Je voulais voir si je pouvais modifier le design sans utiliser l’IA. J’ai cliqué sur l’onglet « Edit », m’attendant à un éditeur glisser-déposer comme sur la plateforme Thunkable standard. En fait, on m’a juste fourni le code.

• Modifier les couleurs : j’ai dû ouvrir un fichier nommé theme.js et changer des codes hexadécimaux comme #0000FF par d’autres valeurs.
• Déplacer des boutons : j’ai dû ajuster les paramètres « Flexbox » dans le code de type CSS.
• Ajouter des composants : si je voulais ajouter un nouveau bouton, je devais le taper manuellement dans le code.

Il n’existe pas (encore) de « Design Panel » avec curseurs ou sélecteurs de couleurs pour ces builds IA. Soit vous utilisez l’IA pour apporter des modifications, soit vous écrivez le code vous-même.

Ce que j’en ai pensé :

C’était une grosse surprise. Je m’attendais à ce que l’IA génère une application « à base de blocs » que je pourrais modifier visuellement.

En me fournissant du code brut, Thunkable indique en gros que cet outil s’adresse aux développeurs qui souhaitent un coup de pouce, pas aux débutants complets qui ne veulent jamais voir une ligne de code. Cela rend l’outil très puissant, mais aussi plus difficile d’accès pour les non-techniciens.

8. Configuration des données et du backend : où sont mes données ?

J’ai décidé de regarder comment les données étaient gérées. En examinant le code, j’ai trouvé cette ligne en haut :

const storageStrategy = ‘all-local’;

Et plus loin, j’ai vu que l’application utilisait quelque chose nommé useQuery et useMutation issu de ‘platform-hooks’ :

const { useQuery, useMutation } = require(‘platform-hooks’);

C’était déroutant au début. Les demandes de service étaient stockées via ces hooks, mais je ne savais pas où allaient réellement les données. Restaient-elles sur le téléphone ? Allaient-elles dans une base de données cloud ?

Voici ce que j’ai découvert :

La stratégie ‘all-local’ signifie que les données sont stockées localement sur l’appareil, mais pas de façon permanente dans une véritable base de données. C’est essentiellement une configuration avancée de localStorage qui donne l’impression d’utiliser une base de données (avec requêtes et mutations), mais qui ne fait en réalité que gérer des données dans le navigateur ou le stockage temporaire du téléphone.

Le bon : le code est déjà structuré pour fonctionner avec une base de données. Le schéma useQuery et useMutation est exactement ce qu’on utiliserait avec un backend réel.

Le mauvais : il n’est réellement connecté ni à Airtable, ni à Firebase, ni à Google Sheets, ni à aucune base de données cloud. Si un propriétaire soumet une demande, un plombier ou un administrateur n’a aucun moyen de la voir, car elle n’est enregistrée que sur l’appareil du propriétaire. Les données disparaissent si vous videz l’application ou changez d’appareil.

Ce qui s’est passé lorsque j’ai demandé « How do I connect a database ? »

Je n’étais pas sûr de savoir comment connecter une vraie base de données, alors j’ai tapé cette question dans la boîte de chat où j’avais saisi ma requête initiale. J’espérais que l’IA m’expliquerait le processus ou proposerait de configurer une intégration.

Au lieu de cela, quelque chose d’étrange s’est produit. Les journaux de « réflexion » de l’IA (que je pouvais voir pendant le traitement) étaient intéressants :

« La bonne réponse serait d’expliquer que : 1. La stratégie actuelle est ‘local’ (pas de base de données) 2. Pour utiliser une base de données, ils doivent passer à la stratégie ‘all-local’ (qui utilise platform-hooks avec useQuery/useMutation) 3. La stratégie ‘all-supabase’ (base de données cloud avec authentification) sera disponible dans une future version. Cependant, je suis instruit de NE RETOURNER QUE du code, rien d’autre. »

L’IA était programmée pour ne sortir que du code, pas des explications. Au lieu de répondre à ma question, elle a interprété ma requête comme une modification de l’application. Elle a passé 13,6 secondes en « réflexion », puis a régénéré le code.

Mais voici le problème : le code qu’elle m’a renvoyé était presque identique à ce que j’avais déjà. Elle a juste réorganisé une partie de la structure interne (création d’un ServiceRequestContext pour partager les données entre écrans), tout en conservant la même stratégie de stockage ‘all-local’.

Elle ne m’a pas basculé vers une base de données cloud. Elle n’a pas proposé de connexion à Airtable. Elle a simplement… fourni une version légèrement refactorisée de la même configuration de stockage local.

Mon avis sur le backend :

Le générateur IA fonctionne par défaut avec une approche local-first, ce qui convient pour des démos mais pas pour des applications multi-utilisateurs en production. Ce qui me frustre, c’est que :

1. L’IA ne m’a pas demandé d’emblée où je souhaitais stocker les données (Airtable ? Firebase ? Google Sheets ?).
2. L’IA ne pouvait pas expliquer ses choix lorsque je l’ai demandé directement. Elle est programmée pour ne générer que du code, pas pour discuter des décisions d’architecture.
3. Le code semble prêt pour une base de données (avec useQuery et useMutation), mais ce n’est en réalité qu’un wrapper sophistiqué autour de localStorage.

Selon la documentation de Thunkable, je pourrais en théorie passer storageStrategy de ‘all-local’ à quelque chose comme ‘all-supabase’ (qui utiliserait une véritable base de données cloud avec authentification), mais les journaux de réflexion de l’IA suggèrent que cette fonctionnalité est « coming in a future release », ce qui signifie que le générateur IA n’a pas encore accès aux stratégies de base de données cloud.

La vraie question : est-ce une limitation de l’IA ou aurais-je simplement dû être plus précis dans ma requête ? Si j’avais dit « Build a service portal that stores requests in Airtable » dès le départ, l’IA l’aurait-elle pris en charge ? Je suppose que la réponse est peut-être oui, mais l’IA aurait dû me demander quelle base de données je souhaitais utiliser au lieu de se rabattre sur le stockage local sans explication.

9. Intégrations disponibles : relier les points

Même si l’IA ne les a pas configurées pour moi, j’ai consulté la plateforme pour voir quelles intégrations étaient disponibles si je voulais les ajouter manuellement.

J’ai constaté que je pouvais potentiellement connecter l’application à :

• Airtable : pour une base de données cloud plus puissante avec une interface de type tableur. Idéal pour gérer les demandes de service de façon accessible aux développeurs et aux administrateurs non techniques.
• Firebase : pour une authentification utilisateur réelle et la synchronisation des données entre appareils. Cela résoudrait immédiatement le problème des données confinées à un seul téléphone.
• Google Sheets : pour un suivi simple des données, accessible aux utilisateurs non techniques. Imaginez un gestionnaire immobilier ouvrant un Google Sheet pour voir toutes les demandes de service entrantes—sans codage nécessaire.
• Xano : pour un backend évolutif sans gestion de serveurs. Idéal pour les applications devant grandir sans que vous ayez à vous soucier de l’infrastructure.
• Backendless : pour des bases de données visuelles et des fonctionnalités de gestion des utilisateurs. Une autre option de backend no-code.
• Cloudinary : pour gérer les images. Pensez à des photos d’une canalisation cassée que les propriétaires pourraient télécharger avec leur demande de service.
• Webflow : pour la synchronisation avec un CMS de site web. Si vous avez un site de gestion immobilière construit avec Webflow, vous pourriez théoriquement synchroniser les demandes de service entre votre site et votre application.
• RevenueCat : pour les achats intégrés et les abonnements, si vous souhaitez monétiser l’application.

Les outils sont donc bien présents. La question est : pourquoi l’IA ne les a-t-elle pas utilisés ?

C’est là que ça devient intéressant. J’ai repris le journal de réflexion de l’IA lorsque j’ai demandé « How do I connect a database ? »

« Pour utiliser une base de données, il faut passer à la stratégie ‘all-local’ (qui utilise platform-hooks avec useQuery/useMutation). La stratégie ‘all-supabase’ (base de données cloud avec authentification) sera disponible dans une future version. »

1. Les intégrations existent, mais le générateur IA y a un accès limité. Thunkable prend clairement en charge Airtable, Firebase, Google Sheets et plus, mais le générateur IA semble restreint à quelques « storage strategies » prédéfinies comme ‘all-local’ (stockage sur l’appareil) et ‘all-supabase’ (base de données cloud, bientôt disponible).
2. L’IA n’a pas d’interface conversationnelle pour la configuration. Je ne pouvais pas simplement taper « Connect this to my Airtable » et laisser l’IA faire le travail. J’aurais dû configurer manuellement l’intégration en suivant la documentation de Thunkable.
3. L’IA est optimisée pour la rapidité, pas la personnalisation. Elle a choisi par défaut l’option la plus rapide et la plus simple (stockage local) au lieu de poser des questions complémentaires comme « Où souhaitez-vous stocker vos données ? » ou « Cette application aura-t-elle plusieurs utilisateurs ? »

Ce que j’en ai pensé :

Le potentiel est clairement là, et c’est plus robuste que je ne le pensais au départ. Ma frustration ne porte pas sur les capacités de Thunkable. La plateforme dispose manifestement de ces intégrations. Ma frustration vient du fait que le générateur IA n’a pas proposé ces options de manière proactive lors de la phase de saisie.

J’aurais aimé que l’IA me demande quelque chose comme :

« Je vois que vous construisez un portail de service. Où souhaitez-vous stocker les demandes de service ?

• Stockage local (rapide, fonctionnel hors ligne, mais les données restent sur un seul appareil)
• Airtable (base de données cloud avec interface de type tableur)
• Firebase (base de données en temps réel avec authentification utilisateur)
• Google Sheets (suivi des données simple et partageable)

Cette question unique m’aurait évité de développer ce qui semble être une application multi-utilisateurs mais fonctionne comme un prototype mono-utilisateur. »

10. Contrôle de version : le filet de sécurité ultime

Une fonctionnalité qui m’a vraiment impressionné est l’outil « Version History ». En cliquant sur une petite icône d’horloge dans la barre d’outils supérieure, une barre latérale s’est ouverte et a listé chaque version de l’application créée par l’IA.

Je pouvais voir une chronologie :

1. Portail de demande de service avec authentification utilisateur (celui qui plantait)
2. « Fix null reference error » (la première correction)
3. Connect database to application

Je pouvais cliquer sur n’importe quelle version pour voir le code ou même « Restore » l’application à ce moment précis.

C’était incroyablement utile lorsqu’une tentative de « Fix with AI » empirait l’application ou introduisait un nouveau plantage.

Mon avis sur le contrôle de version :

C’est le meilleur contrôle de version que j’aie vu dans un outil no-code ou IA. Il apporte un vrai sentiment de sécurité. Vous n’avez pas peur d’expérimenter ou de laisser l’IA tenter une correction risquée, car vous savez que vous pouvez revenir en arrière en un clic. Cela rend le processus parfois chaotique de développement IA beaucoup plus professionnel et maîtrisé.

11. Publication et déploiement : mise en ligne

Une fois que j’ai estimé que l’application était suffisamment aboutie, j’ai examiné les options « Publish ». En haut à droite, il y a un gros bouton « Publish ».

En cliquant, un menu s’est ouvert avec trois choix principaux :

• Publish iOS : lance le processus d’envoi de votre application sur l’App Store. Cela nécessite un compte Apple Developer.
• Publish Android : génère un fichier APK ou AAB pour le Google Play Store.
• Publish Web App : c’était le plus intéressant. Cela vous donne une URL pour que les gens puissent utiliser votre application dans un navigateur mobile sans télécharger quoi que ce soit.

Il y avait également un bouton « Download » qui permettait de demander une copie locale des fichiers de build Android ou iOS. C’est énorme, car cela signifie que vous n’êtes pas « verrouillé » à la plateforme Thunkable indéfiniment. Vous possédez réellement le résultat.

Mon avis sur la publication :

Le flux de publication est très direct. Ils ne cachent pas l’option « web app » derrière une immense barrière payante, ce que j’ai apprécié. Le fait de pouvoir obtenir les fichiers de build bruts pour Android et iOS donne l’impression d’un outil professionnel plutôt que d’un simple gadget pour hobbyistes. C’est une conclusion très fluide au processus de création.

Résumé final de l’expérience

Après quelques heures passées avec l’outil, j’avais un prototype fonctionnel d’un portail de demandes de service. Il comportait un écran de connexion, un formulaire de demande opérationnel et un tableau de bord filtrant les tâches par statut.

Mon évaluation finale :

Le générateur IA de Thunkable est un point de départ puissant pour quiconque souhaite créer une application mobile rapidement. Il est fantastique pour visualiser une idée et construire la structure de l’UI en minutes plutôt qu’en jours.

Cependant, ce n’est pas une « baguette magique ». Vous allez rencontrer des erreurs, devoir dépenser des jetons pour les corriger, et il se peut que vous deviez regarder du code si vous voulez connecter une véritable base de données.

Comparé à d’autres outils, Thunkable donne l’impression d’un environnement de développement professionnel. Il vous montre le code et vous fournit les outils pour le corriger. Si vous êtes un créateur « tech-leaning » souhaitant un avantage considérable sur votre prochain projet, c’est une technologie très impressionnante.

Si vous recherchez une application parfaite en un clic sans le moindre effort, vous pourriez trouver les erreurs d’exécution un peu écrasantes. Dans l’ensemble, c’est une avancée majeure pour le monde du no-code.

Tarifs et plans de Thunkable

Thunkable propose quatre niveaux de tarification basés sur les limites de jetons IA, la confidentialité des projets et les capacités de publication.

Tous les plans incluent le générateur de code IA. La différence réside dans ce que vous pouvez construire et où vous pouvez déployer.

Coûts cachés à connaître

Vous aurez besoin d’un compte Apple Developer (99 $/an) et d’un compte Google Play (25 $ en une seule fois) pour publier des applications. Thunkable ne le mentionne pas en amont, mais vous ne pouvez pas diffuser sur les stores sans eux.

Les jetons IA expirent chaque mois sur les plans payants (ils sont rechargés au moment de la facturation). Si vous êtes sur le plan Accelerator et utilisez 3 000 de vos 20 000 jetons, vous retrouverez 20 000 jetons le mois suivant. Les jetons non utilisés ne sont pas reportés.

Important : si votre abonnement expire, les applications publiées deviennent inaccessibles aux utilisateurs finaux. Ce n’est pas comme WordPress, où votre site reste en ligne après l’arrêt de l’abonnement. Vos applications passent hors ligne jusqu’à ce que vous renouveliez.

Ma recommandation

Commencez par le plan Accelerator (19 $/mois) si vous êtes sérieux dans la construction. Les 2 000 jetons du plan Gratuit s’épuisent trop rapidement lors du débogage, et vous avez besoin d’au moins un projet privé pour toute utilisation professionnelle.

Vous pouvez construire l’application dans Thunkable, puis la connecter manuellement à votre backend Django en utilisant le code React Native généré. Il vous suffit de modifier les points de terminaison de l’API dans les fichiers de code.

Alternative à Thunkable

La génération de code par IA de Thunkable en fait un outil de prototypage rapide, mais si votre objectif est une UI mobile pixel-perfect avec un contrôle total du code, FlutterFlow offre une alternative intéressante.

Choisissez Thunkable si vous êtes : un fondateur non technique qui souhaite valider une idée d’application mobile. Vous êtes à l’aise avec quelques bugs occasionnels et recherchez la voie la plus rapide de l’idée à un prototype fonctionnel.

Choisissez FlutterFlow si vous êtes : un développeur explorant le développement mobile et souhaitant un code lisible et exportable. Vous maîtrisez les concepts de programmation et désirez un contrôle granulaire sur l’UI, les animations et la logique backend.

Verdict final sur Thunkable

Le générateur IA de Thunkable livre exactement ce qu’il promet : des applications mobiles fonctionnelles en quelques minutes à partir d’instructions en anglais simple.

Voir l’IA décomposer vos exigences et générer du code React Native est vraiment impressionnant, et le système de contrôle de version vous permet d’expérimenter sans crainte.

Mais voici la réalité : vous passerez plus de temps à corriger les bugs générés par l’IA qu’à développer de nouvelles fonctionnalités. Les erreurs d’exécution surviennent en permanence, consommant votre budget de jetons lors de tentatives « Fix with AI » qui introduisent souvent de nouveaux problèmes.

Mais si vous vous attendez à des applications peaufinées et prêtes pour la production sans toucher au code, vous serez déçu.

Thunkable

4.3

0 user reviews

26,48 $ /mo

Prix de départ

Rating based on expert review

• Convivialité
  0.0
• Assistance
  0.0
• Caractéristiques
  0.0
• Fiabilité
  0.0
• Tarif
  0.0