DreamFlow : du no-code à l’IA, le game changer est-il enfin là ?

En résumé
DreamFlow est un excellent accélérateur de démarrage pour une application Flutter mais il ne garantit pas une cohérence architecturale globale. Il ne remplace pas un développeur expérimenté sur un projet à forte exigence de maintenabilité et d’évolutivité. 

---

Il y a un an, nos experts mobile s’étaient lancé le défi de créer une application avec FlutterFlow, un éditeur d’applications Flutter no-code basé sur une interface visuelle et un système de drag & drop enrichi de pas mal de fonctionnalités. Cette année, bis repetita, il se sont attelés à vérifier la pertinence de DreamFlow, sa version perfusée à l’IA, dans le cadre d’un projet d’application “professionnelle”, à grande échelle, comme ceux que nous conduisons chez USERADGENTS. 

C’est quoi DreamFlow ?

DreamFlow a été créé par le même éditeur que FlutterFlow, c’est pourquoi on y retrouve naturellement de nombreux éléments familiers pour les utilisateurs de cet écosystème no-code où la création de l’interface passe avant tout par son aspect visuel, sans avoir besoin de mettre les mains dans le code (drag & drop de widgets, configuration du thème graphique de l’application, connexion à Firebase…). Le gros plus de DreamFlow, c’est qu’il dispose d’un agent intégré basé sur plusieurs LLM (Claude Sonnet, Claude Opus, GPT…) avec qui échanger en langage naturel pour façonner une application uniquement en mode conversationnel. On peut donc considérer la solution comme une sorte d’hybride, à mi-chemin entre une plateforme no-code ultra riche et un outil de génération de code intelligent, même si à date, beaucoup d’utilisateurs questionnent la pertinence d’avoir un second outil dédié à l’IA dans l’écosystème FlutterFlow, versus une intégration directe.

Pour notre part, nous avons décidé de voir ce que DreamFlow avait vraiment dans le ventre, en analysant ses capacités réelles et en nous posant plusieurs questions fondamentales : DreamFlow réussit-il son pari de simplifier à l'extrême la création d’applications Flutter, en allant encore plus loin que FlutterFlow, et produit-il un code d’application maintenable et exploitable par un expert du framework ?

Pour cela, nous avons mené un test grandeur nature reprenant deux écrans majeurs d’un projet en cours de production pour l’un de nos clients : un écran de recherche, où la logique fonctionnelle est clé, et une fiche “aliment” avec de nombreux composants. Nous avons choisi d’effectuer notre test avec Claude Opus, un LLM que nous avons l’habitude d’utiliser chez USERADGENTS pour ses performances en matière de génération de code. 

Nos principales observations sur DreamFlow 

Avant toute chose, il a fallu “prompter” afin de donner nos instructions à DreamFlow pour qu’il puisse se lancer. Description de l’architecture du projet, state management souhaité, maquettes d’écran, modèles de données, endpoints API, éléments de thème (couleurs et typographie)... Nous avons dû fournir tout un package d’informations très détaillées à l’IA car DreamFlow ne dispose pas d’un contexte méthodologique de travail concret et persistant. Il est donc nécessaire de passer par une phase de prompting un peu fastidieuse à chaque démarrage de projet.

UX - UI : la partie émergée de l’iceberg

Disons-le tout de suite, DreamFlow nous a permis de réaliser ces deux écrans avec une rapidité assez bluffante, bien qu’il ait fallu itérer un certain temps avec le LLM. Car si l’IA accélère indéniablement la production et que les premiers rendus étaient relativement proches des maquettes d’origine, nous avons constaté qu’une intervention humaine et experte était indispensable pour obtenir de la précision et une cohérence visuelle globale. Nous avons dû effectuer plusieurs ajustements à la main, notamment sur le thème (couleurs, styles, hiérarchie visuelle). Ce décalage entre génération initiale et résultat attendu s’est accentué à mesure que les écrans se sont complexifiés. 

Côté fonctionnel, le résultat est encore plus satisfaisant puisque l’implémentation de la fonction de recherche s’est faite presque sans interaction avec le modèle. L’outil applique logiquement et simplement les règles métiers qui ont été définies.

Le jugement est sans appel : nous avons réussi à créer la “coque” de notre application sans problème et surtout sans avoir besoin d’une expertise profonde en développement Flutter. 

Mais qu’en est-il si l’on regarde du côté des fondations de l’application ?

Un code qui respecte bien les principaux standards

Il y a 1 an, lorsque nous avons regardé en profondeur le code produit par FlutterFlow, il n’était pas réellement à la hauteur des exigences de nos projets et nous avons été particulièrement refroidis par l’incapacité de reprendre le code nous-mêmes, à la main. Avec DreamFlow, la donne a changé. Globalement, le code généré montre une bonne compréhension de la plupart des bonnes pratiques en vigueur en matière de développement Flutter. Par exemple :

• Les entités utilisent ‘Equatable’, ce qui facilite la comparaison d’objets immuables. 
• La séparation entre ‘DTO’ et ‘Entity’ est clairement identifiée, avec des méthodes de conversion toEntity(). Ce découpage du code suit fidèlement les standards d’une architecture d’application Flutter “propre”.
• Certaines logiques métiers simples (les calculs par exemple) sont correctement placées dans le DTO, plutôt cohérent avec la transformation de données.
• Certaines extensions utiles, notamment sur String, sont bien localisées dans un dossier ‘Core/extensions’, respectant ainsi une organisation modulaire classique.

Ces éléments montrent que l’IA de DreamFlow permet de reproduire des patterns largement documentés dans l’écosystème Flutter, bien mieux que FlutterFlow seul. Lorsqu’il s’agit de structures connues et bien diffusées, la génération est pertinente et proche des pratiques professionnelles mais un écart persiste quand même avec ce que l’on peut attendre d’une application en production. En effet, en regardant plus en profondeur, nous avons pu identifier des violations importantes de l’architecture cible. C’est un problème actuellement récurrent avec l’IA : elle est capable de reproduire ces patterns car ils sont connus mais sans cohérence globale garantie.

Architecture et dépendances : ça se complique

Le principal problème observé concerne le non-respect de la Clean Architecture. D’une part, les use cases sont incomplets et une partie de la logique métier est appelée directement depuis la couche UI. D’autre part, la page instancie elle-même l’APIClient, la DataSource et le RepositoryImpl, sans passer par un use case. Résultat : trop de détails d’implémentation sur la couche présentation, un couplage fort avec la couche data, une séparation des responsabilités fragile et donc une testabilité très limitée. Un point finalement assez courant avec les outils d’IA mais problématique. Ils peuvent générer des bonnes briques isolées mais ne garantissent pas leur orchestration correcte à l’échelle du système.

Nous avons observé par ailleurs la présence de dépendances inutilisées dans le projet. Le package provider est déclaré dans le pubspec.yaml alors qu’il n’est pas utilisé, le projet fonctionnant en réalité avec BLoC. Ce type d’incohérence est révélateur d’une génération partiellement contextuelle. L’IA intègre tous les éléments standards d’un projet Flutter sans vérifier leur pertinence réelle dans l’architecture choisie.

Pas non plus de gestion du cycle de vie des dépendances au programme. Une nouvelle instance d’APIClient est créée à chaque ouverture de page, ce qui empêche toute mutualisation ou configuration centralisée. L’absence de singleton ou d’injection de dépendances structurées confirme que l’architecture n’est respectée qu’en surface.

Ces problèmes ne sont pas anecdotiques. Ils montrent que, même lorsque l’IA connaît les concepts de Clean Architecture, elle ne les applique pas de manière rigoureuse. L’outil peut reproduire la forme, mais pas toujours l’intention architecturale. Elle peut produire un code qui compile et fonctionne, mais qui est structurellement immature. Sans relecture et correction par un développeur expérimenté, ce type de base peut rapidement devenir difficile à faire évoluer.

Les limites du système de “rules” 

On pourrait penser que ces erreurs architecturales peuvent être évitées en configurant des règles (ou “rules”) dans DreamFlow. L’outil permet effectivement de générer un fichier de règles au format Markdown à partir du code produit, ce qui donne un contexte spécifique au LLM sur lequel il va pouvoir itérer. Cependant, dans la pratique, ce mécanisme ne corrige pas réellement les problèmes.

Le fichier généré décrit une Clean Architecture théorique sans analyser l’écart avec l’implémentation réelle. L’utilisateur se retrouve alors avec une documentation correcte… mais un code qui ne la respecte pas.

Pour obtenir une génération conforme, il faut souvent relancer l’IA après avoir soi-même corrigé ou reformulé les règles. Ce processus confirme que l’IA ne garantit pas la cohérence architecturale par elle-même. Elle nécessite un cadrage et des ajustements humains successifs.

C’est certainement l’un des points les plus rédhibitoires de ce type de solutions, qui ne génèrent pas de code à proprement dit mais le “projettent” à travers l’interface : le manque de confiance et un besoin constant de vérification basé sur l’expertise.

Dreamflow, une pertinence variable selon l’usage 

En réalité, il est difficile de se faire une idée arrêtée sur DreamFlow car sa pertinence dépend en grande partie de son périmètre d’utilisation. 

Pour qui ? Pour quoi ?

Pour créer une application rapide, tester une idée, faire un POC, sans enjeux de maintenance, d’évolution, de sécurité ou de performance, DreamFlow répond parfaitement à l’attente. Il faudra quand même un peu de travail et une bonne dose de tokens mais globalement, ce que DreamFlow produit fonctionne. Pour des profils non-techniques souhaitant “vibe coder” une application, c’est-à-dire expérimenter rapidement des écrans et voir le rendu immédiatement, sans configuration d’environnement de développement, DreamFlow est même parfaitement adapté car la prévisualisation en temps réel et l’approche WYSIWYG rendent la phase de création particulièrement fluide.

Dans sa forme actuelle, DreamFlow démontre clairement ce potentiel, mais il présente aussi de réelles limites. L’outil facilite la création d’une base d’application et accélère certaines tâches répétitives, mais il n’est pas encore conçu pour répondre pleinement aux exigences des développeurs expérimentés puisque ceux-ci doivent encore intervenir pour corriger l’architecture, affiner la logique métier ou garantir la maintenabilité du code. 

Alors est-ce qu’il pourrait trouver sa place dans un process de développement d’applications Flutter à l’échelle d’une agence, notamment sur des projets de grande envergure ? Non. En tout cas pas chez USERADGENTS. Le manque de maîtrise de la solution pour respecter les principes d’architecture est trop risqué pour produire une application de qualité et cela pourrait vite devenir critique dans le cadre d’un projet business réel. D’autant plus que notre cas d’usage était assez basique et laisse donc penser que le décalage sera encore plus important sur un cas complexe.

Quelles sont les alternatives ?

Chez USERADGENTS, nos développeurs préfèrent utiliser des outils de génération de code “professionnels”, pensés pour eux, comme Cursor ou Claude Code d’Anthropic (notre solution commune). 

Attention, cela ne veut pas dire que le code généré par Claude ne souffre pas des mêmes maux que celui généré par DreamFlow, ou par n’importe quelle IA d’ailleurs, mais son approche est radicalement différente et convient mieux à un public expert. DreamFlow génère des interfaces sans avoir besoin de se plonger dans le code, Claude Code génère en premier lieu du code pour façonner des interfaces. Là est toute la différence car Claude Code intègre en conséquence des outils supplémentaires pour les développeurs, notamment des systèmes de contrôle puissants qui réduisent l’intervention des experts  (rules efficientes car la prise en compte du contexte est réelle et durable, plug-ins spécialisés…)  et des services tiers à connecter grâce au protocole MCP (Atlassian, Figma…) pour mieux définir les besoins et booster la productivité.

Reconnaissons toutefois que Claude Code est bien plus complexe à prendre en main que DreamFlow mais cela semble logique. Ce dernier n’est pas un outil professionnel au regard de nos exigences en matière de qualité, d’évolutivité et de performance sur l’ensemble du cycle de vie d’une application.

En conclusion

DreamFlow permet de produire rapidement une base d’application fonctionnelle avec une architecture apparente propre et un code globalement exploitable. Sur des tâches structurantes, création de pages, requêtes API, wiring initial, le gain de temps est réel. L’outil facilite l’amorçage d’un projet et accélère la mise en place des premières briques. Cependant, dès que l’on entre dans des aspects plus fins, précision UI, respect strict de la Clean Architecture, gestion des dépendances ou organisation métier, l’intervention d’un développeur expérimenté devient indispensable. Sur certains ajustements, il est même plus rapide de corriger ou d’implémenter manuellement que de relancer la génération IA.

DreamFlow illustre ainsi une réalité plus large du développement assisté par IA, que nous avons éprouvée aussi chez USERADGENTS. Elle est devenue indispensable dans nos cycles de production grâce à son efficacité démontrée mais elle reste un outil. Un outil qui permet au développeur d’aller plus vite sans pour autant, se passer de son expertise.

Vous avez un projet d’application mobile ? Contactez nos experts techniques !