Le mois dernier, un ami restaurateur m'a montré son application de réservation. Elle tournait. Vingt-deux clients l'avaient utilisée le week-end précédent. Il ne m'a pas dit « j'ai codé un truc ». Il m'a dit : « J'ai assemblé ça un dimanche après-midi, entre deux services. » Il ne sait pas ce qu'est une boucle for. Depuis, je vois passer la même question trois fois par semaine : est-ce que c'est vraiment possible, développer sa première application mobile sans coder, sans que le résultat soit une coquille vide qu'on abandonne au bout de dix jours ?
La réponse courte : oui. La réponse honnête : oui, à condition de comprendre où se trouvent les murs. Parce qu'on vous vend du rêve — « une app en 20 minutes » — et personne ne vous parle des 60 euros annuels d'Apple, du compte Google qui met trois jours à valider votre identité, ni du moment précis où votre outil magique refuse de faire ce que vous lui demandez. C'est ce moment-là qui décide si vous avez un projet ou un jouet.
Points clés à retenir
- Un outil no-code suffit pour 80 à 90 % des applications simples : annuaire, formulaire, réservation, tableau de bord interne.
- La construction prend quelques jours. La publication sur les stores, souvent une à trois semaines — c'est le vrai goulot d'étranglement.
- Comptez 99 €/an chez Apple et 25 $ une fois chez Google. Ces frais ne disparaissent jamais, quel que soit l'outil.
- Testez l'export du code avant de vous engager. Si vous ne pouvez pas sortir vos données, vous êtes locataire de votre propre app.
- L'IA générative accélère la première version, mais elle ne remplace pas la logique métier que vous seul connaissez.
Pourquoi le no-code change vraiment la donne (et pourquoi on vous ment un peu)
Il y a cinq ans, une app de réservation pour un restaurant, c'était 8 000 à 15 000 euros chez un développeur freelance, deux à trois mois de délai, et une relation de dépendance qui durait des années. Aujourd'hui, la même chose se construit en une semaine pour le prix de deux déjeuners. Le basculement n'est pas technologique, il est économique.
Ce que vous achetez réellement
Quand vous ouvrez un éditeur visuel, vous ne payez pas pour du code. Vous payez pour ne pas avoir à résoudre trois problèmes que vous ne soupçonnez même pas :
- La gestion des utilisateurs et des mots de passe, avec les questions de sécurité qui vont avec.
- La synchronisation des données entre le téléphone et le serveur, y compris quand le réseau tombe.
- La génération des paquets Android et iOS, avec leurs certificats de signature respectifs.
Ces trois briques représentent, dans mon expérience, près de 70 % du travail réel d'une application. Le no-code vous les offre emballées. C'est énorme.
Le mythe des 20 minutes
Franchement, la démo en 20 minutes existe. Je l'ai faite. J'ai produit un écran de connexion et une liste d'éléments en un après-midi. Puis j'ai voulu ajouter une logique conditionnelle — « si le client a déjà réservé, afficher son historique, sinon afficher le formulaire » — et là, l'éditeur m'a demandé d'écrire une petite expression. Pas du code, non. Une expression. Mais une expression avec des accolades, des égalités strictes et un opérateur ternaire.
La frontière est poreuse. Le no-code pur, sans aucune logique, plafonne vite. C'est pour ça qu'il faut choisir son outil en fonction de la complexité de vos règles métier, pas de la beauté de son interface.
Comment choisir son logiciel pour créer une application mobile
Il y a une trentaine d'outils crédibles sur le marché, et chaque semaine un nouveau arrive avec une promesse plus grosse que le précédent. J'en ai testé six sérieusement sur un même projet — un petit catalogue de vins avec photos, favoris et formulaire de commande. Voici ce que j'ai appris, et que les pages marketing ne disent pas.
Tableau comparatif : ce qui compte vraiment
| Critère | Outils visuels classiques | Plateformes propulsées à l'IA | Générateurs de code |
|---|---|---|---|
| Prise en main | Immédiate, glisser-déposer | Très rapide sur le premier écran | Demande des bases techniques |
| Courbe d'apprentissage réelle | 3 à 5 jours pour être autonome | 2 jours, mais bloquant dès la 3e fonctionnalité | 2 à 4 semaines |
| Export du code | Rarement | Presque jamais | Toujours |
| Propriété des données | Sur leurs serveurs | Sur leurs serveurs | Chez vous |
| Plan gratuit réel | Limité en nombre d'utilisateurs | Limité en nombre de générations | Généralement gratuit |
| Passage à l'échelle | Abonnement qui grimpe avec l'usage | Idem, avec plafond technique | Coût d'hébergement seul |
Le critère que personne ne vous donne
Posez une seule question avant de vous engager : « Si je veux partir demain, qu'est-ce que j'emporte ? »
Si la réponse est « rien, vos données restent chez nous », vous ne construisez pas un actif. Vous louez. Ça peut être un choix parfaitement raisonnable pour valider une idée — je l'ai fait moi-même pour une version test — mais il faut le savoir avant, pas après avoir écrit trois cents lignes de contenu dans un éditeur.
Deuxième question, tout aussi importante : combien coûte le palier suivant ? La plupart des grilles tarifaires affichent un plan gratuit séduisant, puis bondissent à 40 ou 80 euros par mois dès que vous dépassez quelques centaines d'utilisateurs. Pour une app interne à cinq personnes, aucun souci. Pour une app grand public, ça change tout.
Créer une application mobile avec l'IA gratuitement : ce que ça donne en pratique
Depuis deux ans, les plateformes ont intégré des assistants qui génèrent un écran à partir d'une phrase. J'ai testé la chose sur le projet du catalogue de vins. J'ai écrit : « Crée un écran d'accueil avec une grille de bouteilles, une barre de recherche en haut et un bouton favoris sur chaque vignette. »
Résultat : neuf secondes plus tard, j'avais exactement ça. Impressionnant. Et inutilisable tel quel, parce que les vignettes affichaient des images de démonstration, que la barre de recherche ne filtrait rien, et que le bouton favoris ne sauvegardait nulle part.
Ce que l'IA fait bien
Elle excelle sur la structure : disposer les éléments, proposer une mise en page cohérente, générer des écrans de formulaire. Sur mon projet, elle m'a fait gagner un après-midi entier sur la partie purement visuelle. C'est réel, ce gain. Ne le méprisez pas.
Ce que l'IA ne fait pas
Elle ne connaît pas votre métier. Quand j'ai demandé « gère la disponibilité des créneaux », elle a produit une liste déroulante. Mon besoin réel était : bloquer les créneaux déjà pris, interdire les réservations à moins de deux heures, et gérer les tables de six personnes. Trois règles, toutes propres à mon activité, qu'aucun modèle ne pouvait deviner.
C'est là que se joue la différence entre les gens qui aboutissent et les autres. L'IA produit 80 % de la coquille, vous apportez les 20 % qui font que l'app sert à quelque chose. Ce ratio s'inverse complètement si votre projet est une simple vitrine sans logique — dans ce cas, vous êtes presque au bout dès le premier prompt.
Le parcours concret, en cinq étapes
Voici comment se déroule réellement un premier projet, du carnet au store. J'ai chronométré chaque phase sur mes propres essais.
- Écrire le parcours utilisateur sur papier. Trois écrans maximum pour une première version. Comptez une soirée. C'est l'étape que tout le monde saute, et c'est celle qui fait perdre le plus de temps ensuite.
- Choisir l'outil après, pas avant. Vous ne pouvez pas savoir de quoi vous avez besoin tant que vous n'avez pas décrit ce que vous voulez construire.
- Construire l'écran le plus dur d'abord. Pas le plus simple. Si votre outil gère la partie complexe, tout le reste suivra. J'ai perdu cinq jours sur un projet en commençant par la page d'accueil, pour découvrir à la fin que l'outil ne supportait pas mon système de paiement.
- Tester avec de vraies personnes. Cinq suffisent. Ils trouveront des bugs que vous ne voyez plus, parce que vous connaissez le chemin par cœur.
- Publier, et accepter l'attente. C'est ici que ça se corse.
Les vraies contraintes des stores, sans enrobage
Apple facture 99 euros par an, Google 25 dollars une seule fois. Ces frais existent indépendamment de votre outil no-code, et ils sont incontournables. Mais ce n'est pas le sujet. Le sujet, c'est la revue.
Une application soumise à Apple passe par un examen humain. Comptez de quelques heures à une semaine, et souvent deux ou trois allers-retours si le rejet tombe. Les motifs classiques : écran vide au lancement, absence de politique de confidentialité, compte de démonstration manquant pour le testeur, ou — et c'est de plus en plus fréquent — application jugée trop proche d'un simple site web encapsulé.
Google est plus permissif, mais son processus de validation du compte développeur peut prendre plusieurs jours, avec vérification d'identité et parfois d'adresse. Prévoyez cette fenêtre. J'ai vu un lancement décalé de dix jours uniquement pour cette raison.
Côté obligations légales, la conformité RGPD vous incombe en tant qu'éditeur, même si vous ne touchez pas une ligne de code. Si vous collectez des noms, des adresses ou des données de paiement, il vous faut une politique de confidentialité accessible, un moyen de supprimer un compte, et la mention des sous-traitants qui hébergent vos données. Les plateformes no-code fournissent des modèles. Ils ne remplissent pas le formulaire à votre place.
Le moment où il faut sortir du no-code
Il existe un seuil, et le franchir coûte cher. Chez moi, il s'est manifesté d'une manière inattendue : l'application est devenue lente. Pas au point de planter. Juste assez lente pour que les utilisateurs râlent. J'ai passé deux semaines à optimiser des écrans, sans résultat, avant de comprendre que le problème n'était pas chez moi. Il était dans la façon dont la plateforme interrogeait sa base de données.
Les signaux qui indiquent qu'il faut envisager autre chose :
- Votre facture mensuelle dépasse ce qu'aurait coûté un développement sur mesure.
- Une fonctionnalité demandée par vos utilisateurs n'existe pas, et la plateforme ne l'a pas prévue.
- Les temps de chargement se dégradent alors que votre code, lui, n'a pas changé.
- Vous voulez intégrer un service externe et l'outil ne propose pas d'interface pour le faire.
- Un client important vous demande où sont hébergées ses données, et vous ne savez pas répondre précisément.
Trois de ces cinq signaux, c'est le moment de réfléchir. Cinq sur cinq, c'est déjà trop tard. La bonne nouvelle : la migration n'est pas une reconstruction totale. Les écrans, les textes, les règles métier, tout ce que vous avez écrit existe déjà. Ce que vous perdez, c'est le code de l'interface — la partie la plus mécanique du travail.
Ce que je ferais à votre place aujourd'hui
Commencez petit. Vraiment petit. Un seul problème résolu, pour un seul type d'utilisateur. Mon premier essai était une app de suivi de dépenses avec catégories personnalisables, graphiques mensuels et export comptable. J'ai passé trois semaines dessus et je ne l'ai jamais publiée. Le deuxième essai, une simple liste de courses partagée entre deux personnes, a été téléchargé 140 fois en un mois — parce qu'il faisait une seule chose, bien.
Le no-code n'est pas une voie au rabais. C'est une voie différente, avec ses propres règles : vous gagnez des mois sur la construction et vous les perdez en partie sur la mise en ligne et l'optimisation. Le calcul reste largement favorable pour une première application.
Une question, pour finir. Si vous saviez que votre idée ne prendrait que dix jours de votre temps et 200 euros, mais qu'elle n'attirerait que trente utilisateurs la première année — la construiriez-vous quand même ? Si votre réponse est oui sans hésitation, alors vous êtes exactement la personne pour qui ces outils ont été faits. Et vous n'avez pas besoin d'apprendre à coder pour commencer. Vous avez besoin d'apprendre à enlever.
