Trois plateformes, trois terrains de jeu différents. Le choix se joue sur un seul critère de départ, et les deux suivants ne servent qu'à départager.

La question arrive presque toujours trop tôt. Tant que le périmètre du produit n’est pas écrit, comparer ces trois outils revient à comparer des listes de fonctionnalités, ce qui ne tranche rien. Une fois le périmètre connu, la décision prend dix minutes.

Le critère qui décide avant tous les autres

Votre produit vit-il dans un navigateur ou sur un téléphone ? Ce n’est pas une question de préférence, c’est une question d’usage réel.

Un outil manipulé assis devant un écran, avec des listes, des filtres, de la saisie longue et des exports, vit dans un navigateur. Un outil sorti de la poche sur un chantier, dans un couloir ou dans un camion, avec de la photo, de la position et des notifications, vit sur un téléphone.

Beaucoup de projets veulent les deux. À l’étape de la première version, vouloir les deux est la façon la plus sûre de rater les deux : le budget se divise et chaque version arrive à moitié aboutie. Il faut choisir, en sachant que le second support n’est pas condamné, il est reporté.

Bubble : quand la donnée est le sujet

Bubble est un constructeur d’applications web. Sa force est le modèle de données : des types reliés entre eux, des droits par rôle, des vues filtrées, des recherches croisées. C’est le terrain des outils métier internes, des places de marché et de tout ce qui manipule des listes.

Sa contrepartie est une courbe d’apprentissage réelle. L’interface expose beaucoup, et un produit construit sans discipline devient rapidement illisible pour quelqu’un d’autre que son auteur. Ce n’est pas un défaut de l’outil, c’est la conséquence de sa souplesse.

Le signal qui l’écarte : si votre usage principal suppose la caméra, la géolocalisation continue ou le fonctionnement hors connexion, vous vous battrez contre l’outil.

FlutterFlow : quand le téléphone est le sujet

FlutterFlow produit une application mobile qui s’installe depuis les magasins d’applications. Il donne accès à ce que le téléphone sait faire nativement, et c’est exactement ce qu’on lui demande.

Il suppose en contrepartie de composer avec les contraintes des magasins d’applications : un processus de publication, des règles de validation, et des délais qui ne dépendent pas de vous. Sur une première version, ce point est souvent découvert trop tard, et il pèse sur le calendrier.

Autre différence structurante : la logique métier y est moins centralisée que dans un constructeur web. Un produit dont le coeur est un ensemble de règles de gestion complexes s’y construit, mais plus laborieusement.

Adalo : quand la simplicité prime sur tout le reste

Adalo vise la mise en route rapide, avec une interface volontairement réduite. Sur un produit simple, une liste, des fiches, un formulaire, quelques écrans, il fait le travail plus vite que les deux autres.

Sa limite est sa qualité : ce qui est retiré de l’interface est aussi retiré des possibilités. Dès que le modèle de données se ramifie, dès que les droits se compliquent, dès que le volume de lignes grimpe, on atteint le bord de l’outil plus tôt qu’ailleurs.

Ce n’est un mauvais choix que si l’on se trompe sur la trajectoire. Pour un produit qui restera simple, c’est le chemin le plus court. Pour un produit qui doit grossir, c’est un détour.

Ce que les trois partagent, et leur plafond commun

Aucune de ces plateformes n’a de qualité intrinsèque : elles permettent de bien construire aussi facilement que de mal construire, simplement plus vite dans les deux cas. Ce qui distingue un produit qui tiendra d’un produit à refaire tient à trois choses, invisibles à l’écran.

  • Un modèle de données pensé avant la première page, parce que c’est le seul élément qu’on ne peut plus corriger sans tout reprendre.
  • Des droits gérés au niveau de la donnée et non de l’affichage : un bouton caché n’est pas une protection.
  • Une nomenclature tenue, pour que la personne qui reprendra le produit dans un an comprenne ce qu’elle regarde.

Elles partagent aussi un plafond, et il arrive au succès plutôt qu’au démarrage : les temps d’affichage sur les écrans qui manipulent beaucoup de lignes, une exigence de conformité que la plateforme ne permet pas de satisfaire, un coût indexé sur l’usage qui devient comparable à celui d’une équipe, ou une logique métier assez spécifique pour qu’on passe plus de temps à contourner l’outil qu’à s’en servir.

Et les générateurs assistés par IA ?

Ils produisent en quelques heures une interface crédible, ce qui est un vrai gain pour montrer une direction. Leur limite apparaît quand il faut faire évoluer ce qui a été généré : le modèle de données est souvent implicite et la logique dispersée, si bien que la reprise coûte plus que la construction n’a fait gagner. Nous détaillons ce que chacun sait faire dans Bolt ou Lovable.

Ce que coûte réellement une de ces plateformes

Nous ne publions pas de montants ici : les grilles évoluent trop souvent pour rester justes, et un tarif faux dans un comparatif décrédibilise le reste de la page. La mécanique, elle, est stable et suffit à décider.

Les trois facturent un abonnement par palier, et le palier dépend de l’usage plutôt que du nombre d’écrans construits. La conséquence est contre-intuitive : le produit le plus coûteux n’est pas le plus complexe, c’est celui qui est le plus utilisé. C’est une bonne nouvelle au démarrage, où le coût reste faible, et un point à surveiller au succès.

À cet abonnement s’ajoutent deux postes que presque personne ne budgète.

Le temps de conception, qui est ponctuel et représente l’essentiel du coût d’une première version. C’est du travail humain, il ne dépend d’aucune plateforme, et il ne baisse pas parce qu’on a choisi l’outil le plus simple.

Le temps de maintenance, qui est récurrent et systématiquement sous-estimé. Quelqu’un doit corriger ce qui casse, adapter le produit quand un service connecté change son interface, et traiter les demandes des utilisateurs. C’est ce poste qui décide de la rentabilité réelle, pas l’abonnement.

Un dernier coût n’apparaît sur aucune facture : la dépendance. Un produit qu’une seule personne sait faire évoluer coûte cher le jour où cette personne n’est plus disponible. C’est pour cette raison que nous vérifions dès le début que les données sont exportables dans un format lisible, et que nous documentons la logique métier en français, en dehors de l’outil.

Comment nous tranchons, en pratique

Dans cet ordre, et jamais avant d’avoir écrit le périmètre.

  • Le support d’usage réel, qui élimine déjà une des trois plateformes.
  • La complexité du modèle de données, qui départage les deux restantes dans presque tous les cas.
  • Qui maintiendra le produit après nous, qui tranche les rares situations où les deux premiers critères laissent le choix ouvert.

Le troisième est celui qu’on oublie et celui qui coûte le plus cher quand on l’oublie. Un produit qu’une seule personne sait faire évoluer est une dépendance, pas un actif. La démarche complète est décrite sur la page développement d’applications.