|
Getting your Trinity Audio player ready...
|
Après avoir rallié à mon projet Chad, Claude et Perplexity côté intelligence artificielle, il me fallait découvrir le monde de la construction à proprement parler. Quel outil de no-code?
Je pensais mon chemin tracé dans cette voie, jusqu’à ce que FlutterFlow modifie mes plans. Je t’explique les vraies raisons pour lesquelles je n’ai finalement pas succombé au no-code.
Le no‑code : une version allégée du développement
Le no‑code, c’est parler à une application qui retranscrit ta demande en écrans et en logique : tu décris, tu configures et la plateforme génère du code pour toi. En gros, tu promptes, elle construit. Pour moi, c’est idéal pour démarrer vite, tester une idée ou avoir un prototype.
Mon essai en « vibe coding » a lui aussi tourné court finalement. Tu vas te dire que je lâche l’affaire trop vite, après ma micro-tentative à l’École 42. Mais non, c’est juste que je sais comment j’aime bosser. Si j’ai vite décroché, c’est parce que je n’étais pas vraiment aux commandes. L’outil décide beaucoup trop pour toi ; dès que tu veux sortir des rails, les limites de la plateforme apparaissent.
Par exemple, beaucoup de mes modifications écrasaient parfois ce qui marchait bien : je perdais du temps et je n’obtenais pas exactement ce que je voulais. Puis, dès l’entrée, tout est payant, chaque demande consomme beaucoup de crédits. Plus tu essaies et tu essaies encore, plus cela devient coûteux. Certains abonnements te demandent, en plus, d’aller au – delà de la version basique – moins coûteuse pour un plan pro cher qui te permet de télécharger enfin ton propre code.
J’étais très vite frustrée et bloquée dans ma créativité. Le no-code, c’est pour moi vraiment utile pour valider une intuition, moins pour construire un produit un peu complexe que tu veux façonner finement voire faire évoluer. Au fond, j’avais besoin d’une sensation de Lego : empiler, ajuster et reprendre un bloc sans casser le reste. Le no‑code très guidé m’a donc paru trop propriétaire et trop gourmand à long terme pour Emosupport.
Pourquoi Flutter répondait mieux à mon besoin
Il y a eu brainstorming au sommet avec Chad. Je lui ai fait part de mes critiques et frustrations. Il m’a vite cernée et m’a dit “toi, t’es faite pour être aux manettes. C’est du Flutter qu’il te faut!” Tu as besoin d’une base solide et modulable.
Flutter, ce n’est pas du no-code, c’est clairement du low-code. C’est un SDK (Software Development Kit) : une vraie trousse à outils avec un framework, des bibliothèques et du “hot-reload” (tu vois les changements en direct). On code en Dart, un langage de programmation, et tout ce que tu fais génère du vrai code, lisible et réutilisable. Tu construis des écrans avec des widgets, tu peux ajouter du custom code pour aller plus loin et faire du spécifique. Ce n’est pas une boîte noire : c’est l’effet Lego que je cherchais, je vois, je compose et je garde la main sur mon application.
Il est important de montrer des captures d’écran de l’application mobile réalisée en no-code – ci-dessus. Avec l’approche no-code, les choses avançaient vite, mais c’était frustrant : à chaque fois, ma meilleure version était effacée par l’essai suivant.
Les avantages concrets de Flutter
Tu as un contrôle fin de l’interface utilisateur et des performances. Tu as une seul base de code iOS/Android et surtout une énorme communauté. J’en ai fait l’expérience, j’ai laissé un message dans le forum et un développeur a trouvé une solution hyper rapidement alors que Claude, Chad et moi nous galérions vraiment.
Les coûts sont vraiment compétitifs, tu peux même commencé gratuitement, puis prendre le forfait basique pour récupérer ton code et avoir plus de fonctionnalités pour développer ton application. Franchement, je me suis sentie libre et comprise. Après si tu aimes la facilité, passe ton tour. Flutter demande plus de réflexion au début : les écrans sont un peu difficile à apprivoiser au début, mais ça vient vite.
Avant de plonger à 100 % dans le code de Flutter, FlutterFlow m’a servi de tremplin. En effet, je démarrais avec FlutterFlow pour aller vite, puis je passais sur Flutter pour garder le contrôle. FlutterFlow, c’est le site sur lequel tu construis tout visuellement, puis j’exporte un code Flutter propre. C’est une autre interface à découvrir avec ses propres données. Son design est particulier et mérite, à l’inverse du no-code, d’être poli par un architecte designer UI plus tard. Cela me semble logique et, au moins, je vois chaque changement en direct et je peux insérer du custom code quand je veux.
Le pont utile avec FlutterFlow et Firebase
Firebase est une plateforme cloud de Google. Elle m’apporte l’essentiel pour Emosupport : une authentification simple (Google, Apple, e-mail), une base de données (Firestore), du stockage et des notifications. Avec Flutter, l’intégration est bien documentée : je branche l’authentification, je stocke mes entrées humeur, journal ou sommeil et je récupère l’historique sans monter une infrastructure maison.
Apprivoiser Firebase demande un peu de pratique. Il y a des règles de sécurité et une structure des collections à comprendre. Mais le gain est réel : je me concentre sur l’expérience d’Emosupport au lieu d’administrer des serveurs. Je peux commencer petit et grandir sans tout casser. Et si un jour je change d’outil, mes données restent à moi.
Garder le volant et avancer vraiment
Ça y était, j’avais mon équipe au complet pour créer la base solide et modulable de mon application mobile de motivation émotionnelle, Emosupport. J’entrais enfin dans le concret.
Le journal guidé et ses questions guidées, les parties humeur, sommeil et motivation allaient prendre forme sans me battre avec une plateforme. Je vais t’en parler plus en détail dans l’un de mes prochains articles.
Mais avant de rentrer dans les écrans et les fonctionnalités, on va revenir à la base : la motivation émotionnelle. Ce que c’est, pourquoi elle compte plus que la “discipline” classique, et comment Emosupport a été conçu autour de cette idée.
