Claude Code pour l'itération UI Flutter : un workflow pratique

Le problème : itérations UI rapides sans sombrer dans le chaos

Le travail UI rapide en Flutter commence souvent bien. Vous ajustez un layout, ajoutez un bouton, déplacez un champ, et l'écran s'améliore vite. Le problème survient après quelques passes, quand la vitesse se transforme en un tas de changements que personne ne veut relire.

Les équipes rencontrent généralement les mêmes échecs :

• L'arbre de widgets grossit sans plan, si bien qu'un changement « petit » force des modifications dans de nombreux fichiers.
• L'état est greffé sur le code UI, rendant les rebuilds imprévisibles et les bugs plus difficiles à tracer.
• La logique de navigation est dispersée (un push ici, un pop là) jusqu'à ce que les flux ne reflètent plus la façon dont les utilisateurs se déplacent réellement dans l'app.
• Les noms dérivent, des composants sont dupliqués, et personne n'est sûr du widget « réel ».
• Les diffs deviennent énormes, donc les reviewers survolent, des problèmes passent à travers, et des régressions apparaissent plus tard.

Une grande cause est l'approche « une grosse requête » : décrire la fonctionnalité entière, demander l'ensemble complet d'écrans et accepter une sortie massive. L'assistant tente d'aider, mais touche trop de parties du code à la fois. Cela rend les changements brouillons, difficiles à relire et risqués à fusionner.

Une boucle répétable corrige cela en imposant de la clarté et en limitant le rayon d'impact. Au lieu de « construire la fonctionnalité, » faites ceci de manière répétée : choisissez une user story, générez la plus petite tranche d'UI qui la prouve, ajoutez uniquement l'état nécessaire pour cette tranche, puis câblez la navigation pour une voie. Chaque passe reste assez petite pour être relue, et les erreurs sont faciles à annuler.

L'objectif ici est un workflow pratique pour transformer des user stories en écrans concrets, gestion d'état et flux de navigation sans perdre le contrôle. Bien fait, vous obtenez des pièces UI modulaires, des diffs plus petits et moins de surprises quand les exigences changent.

Transformer les user stories en spécification UI claire et exécutable

Les user stories sont écrites pour des humains, pas pour des arbres de widgets. Avant de générer quoi que ce soit, convertissez la story en une petite spec UI qui décrit le comportement visible. « Terminé » doit être testable : ce que l'utilisateur peut voir, toucher et confirmer, pas si le design « semble moderne ».

Une façon simple de garder le scope concret est de diviser la story en quatre catégories :

• Écrans : ce qui change, ce qui reste tel quel.
• Composants : quelles nouvelles pièces UI apparaissent et où elles résident.
• États : loading, success, error, empty, et ce que chacun affiche.
• Événements : taps, swipes, pull-to-refresh, retour, retries.

Si la story reste floue, répondez à ces questions en langage simple :

• Quels écrans changent, et lesquels restent les mêmes ?
• Quels nouveaux composants apparaissent, et où vont-ils ?
• Quels états existent, et que montre chacun ?
• Quels événements provoquent des changements d'état ?
• Quel est le contrôle d'acceptation que vous pouvez faire en 30 secondes après avoir lancé l'app ?

Ajoutez des contraintes tôt parce qu'elles guident chaque choix de layout : bases du thème (couleurs, espacements, typographie), responsivité (d'abord téléphone en portrait, puis tablettes), et minima d'accessibilité comme la taille des cibles tactiles, l'échelle du texte lisible et des labels significatifs pour les icônes.

Enfin, décidez ce qui est stable vs flexible pour éviter de churner la base de code. Les éléments stables sont ceux dont d'autres fonctionnalités dépendent, comme les noms de routes, les modèles de données et les APIs existantes. Les éléments flexibles sont sûrs à itérer, comme la structure du layout, la microcopie et la composition exacte des widgets.

Exemple : « En tant qu'utilisateur, je peux enregistrer un élément dans Favoris depuis l'écran de détail. » Une spec UI réalisable pourrait être :

• L'écran de détail affiche une icône de marque-page.
• Un tap bascule l'état sauvegardé.
• Pendant la sauvegarde, afficher un petit indicateur de progression.
• En cas d'échec, afficher une erreur inline avec une action Retry.
• La navigation reste la même (pas de nouvelles routes).

C'est suffisant pour construire, relire et itérer sans deviner.

Mettre en place la boucle d'itération pour que les diffs restent petits

Des diffs petits ne signifient pas travailler plus lentement. Ils rendent chaque changement facile à relire, facile à annuler et difficile à casser. La règle la plus simple : un écran ou une interaction par itération.

Choisissez une tranche précise avant de commencer. « Ajouter un état vide à l'écran Commandes » est une bonne tranche. « Refondre tout le flow Commandes » ne l'est pas. Visez un diff qu'un coéquipier peut comprendre en une minute.

Une structure de dossiers stable aide aussi à contenir les changements. Une organisation simple, feature-first, évite de disperser widgets et routes à travers l'app :

lib/
  features/
    orders/
      screens/
      widgets/
      state/
      routes.dart

Gardez les widgets petits et composés. Quand un widget a des entrées et sorties claires, vous pouvez changer le layout sans toucher la logique d'état, et modifier l'état sans réécrire l'UI. Privilégiez les widgets qui prennent des valeurs simples et des callbacks, pas de l'état global.

Une boucle qui reste relisible :

• Écrivez une spec UI de 3 à 6 lignes pour la tranche (ce qui apparaît, ce que font les taps, what loading/error looks like).
• Générez ou éditez uniquement les fichiers minimums nécessaires (souvent un écran et un ou deux widgets).
• Lancez l'écran, puis faites une passe de nettoyage (noms, espacements, suppression des props inutilisées).
• Commitez avec un message qui correspond à la tranche.

Fixez une règle stricte : chaque changement doit être facile à annuler ou isoler. Évitez les refactors non liés pendant que vous itérez sur un écran. Si vous remarquez des problèmes non liés, notez-les et corrigez-les dans un commit séparé.

Si votre outil supporte snapshots et rollback, utilisez chaque tranche comme point de snapshot. Certaines plateformes vibe-coding comme Koder.ai incluent des snapshots et rollback, ce qui peut rendre l'expérimentation plus sûre quand vous tentez un changement UI audacieux.

Une habitude qui garde les premières itérations calmes : privilégier l'ajout de nouveaux widgets plutôt que l'édition de widgets partagés. Les composants partagés sont là où de petits changements deviennent de gros diffs.

Étape par étape : générer un arbre de widgets depuis une user story

Le travail UI rapide reste sûr quand vous séparez la réflexion du tapotement. Commencez par obtenir un plan d'arbre de widgets clair avant de générer du code.

1. Demandez uniquement un aperçu d'arbre de widgets. Vous voulez des noms de widgets, la hiérarchie et ce que chaque partie affiche. Pas encore de code. C'est là que vous repérez des états manquants, des écrans vides et des choix de layout étranges, tant que tout est encore peu coûteux à changer.

2. Demandez une répartition des composants avec leurs responsabilités. Gardez chaque widget ciblé : un widget rend l'en-tête, un autre rend la liste, un autre gère l'UI vide/erreur. Si quelque chose nécessitera de l'état plus tard, notez-le maintenant mais n'implémentez pas encore.

3. Générez le scaffold de l'écran et des widgets stateless. Commencez par un fichier d'écran unique avec du contenu placeholder et des TODO clairs. Gardez les inputs explicites (params du constructeur) pour pouvoir injecter l'état réel plus tard sans réécrire l'arbre.

4. Faites une passe séparée pour le style et les détails de layout : espacements, typographie, theming et comportement responsive. Traitez le style comme un diff à part pour que les revues restent simples.

Un pattern de prompt qui fonctionne

Exposez les contraintes dès le départ pour que l'assistant n'invente pas d'UI que vous ne pouvez pas livrer :

• Appareils cibles (téléphone seulement, tablette aussi, orientation)
• Contraintes de design (Material 3, couleurs du thème existant, règles d'espacement)
• Attentes de navigation (comportement du back, deep links si besoin)
• Critères d'acceptation (ce qui doit être visible et cliquable)
• Limites de code existantes (fichiers/widgets qui doivent rester, conventions de nommage)

Exemple concret : la user story est « En tant qu'utilisateur, je peux consulter mes éléments sauvegardés et en supprimer un. » Demandez un arbre de widgets incluant une app bar, une liste avec des lignes d'item et un état vide. Puis demandez une répartition comme SavedItemsScreen, SavedItemTile, EmptySavedItems. Ce n'est qu'après que vous générez le scaffold stateless avec des données factices, puis que vous ajoutez le styling (séparateurs, padding et un bouton de suppression clair) dans une passe séparée.

Ajouter la gestion d'état sans alourdir le code UI

L'itération UI se casse quand chaque widget commence à prendre des décisions. Gardez l'arbre de widgets idiot : il doit lire l'état et rendre, pas contenir des règles métiers.

Commencez par nommer les états en langage simple. La plupart des features ont besoin de plus que « loading » et « done » :

• Loading (premier chargement ou refresh)
• Empty (pas de données)
• Error (requête échouée, permission refusée)
• Success (données prêtes)
• Partial input (formulaire commencé mais invalide)

Puis listez les événements qui peuvent changer l'état : taps, soumission de formulaire, pull-to-refresh, retour, retry et « l'utilisateur a édité un champ ». Faire cela en amont évite les suppositions plus tard.

Garder l'état séparé des widgets

Choisissez une approche d'état pour la feature et tenez-vous-y. L'objectif n'est pas « le meilleur pattern », mais des diffs cohérents.

Pour un écran petit, un contrôleur simple (ChangeNotifier ou ValueNotifier) suffit souvent. Placez la logique en un seul endroit :

• Entrées : événements provenant de l'UI (submit, refresh, edit)
• Sortie : un objet d'état unique que l'UI peut rendre
• Effets secondaires : appels API et demandes de navigation

Avant d'ajouter du code, écrivez les transitions d'état en anglais simple. Exemple pour un écran de login :

"Quand l'utilisateur appuie sur Se connecter : définir Loading. Si l'email est invalide : rester en Partial input et afficher un message inline. Si le mot de passe est incorrect : définir Error avec un message et activer Retry. Si succès : définir Success et naviguer vers Home."

Puis générez le code Dart minimal qui correspond à ces phrases. Les revues restent simples car vous pouvez comparer le diff aux règles.

Ajouter des règles testables pour les entrées invalides

Rendez la validation explicite. Décidez ce qui se passe quand les champs sont invalides :

• Bloquez-vous l'envoi ou autorisez-vous et affichez des erreurs ?
• Quels champs affichent des erreurs, et quand ?
• Le retour abandonne-t-il l'entrée partielle ou la conserve-t-il ?

Quand ces réponses sont écrites, votre UI reste propre et le code d'état reste petit.

Concevoir des flux de navigation qui suivent le comportement réel des utilisateurs

Une bonne navigation commence par une petite carte, pas un tas de routes. Pour chaque user story, notez quatre moments : où l'utilisateur entre, l'étape suivante la plus probable, comment il annule, et ce que signifie « retour » (retour à l'écran précédent ou retour à un état sûr).

Commencez par une carte de routes, puis verrouillez ce qui voyage entre écrans

Une simple carte de routes doit répondre aux questions qui causent généralement du retiming :

• Entrée : quel écran s'ouvre d'abord, et d'où (onglet, notification, deep link)
• Suite : le chemin avant après l'action primaire
• Annuler : où l'utilisateur atterrit s'il abandonne le flux
• Retour : si le back est autorisé, et ce qu'il doit préserver
• Repli : où aller si les données requises sont manquantes

Puis définissez les paramètres passés entre écrans. Soyez explicite : IDs (productId, orderId), filtres (plage de dates, statut) et données brouillon (formulaire partiellement rempli). Si vous sautez cette étape, vous allez finir par enfouir l'état dans des singletons globaux ou reconstruire des écrans pour "retrouver" le contexte.

Préparez les deep links et les patterns de "retourner un résultat"

Les deep links comptent même si vous ne les livrez pas le jour 1. Décidez ce qui arrive quand un utilisateur arrive au milieu d'un flux : pouvez-vous charger les données manquantes, ou devez-vous rediriger vers un écran d'entrée sûr ?

Décidez aussi quels écrans doivent renvoyer des résultats. Exemple : un écran "Select Address" renvoie un addressId, et l'écran de checkout se met à jour sans refresh complet. Gardez la forme du retour petite et typée pour que les changements restent faciles à relire.

Avant de coder, signalez les cas limites : changements non sauvegardés (afficher un dialogue de confirmation), authentification requise (mettre en pause et reprendre après connexion), et données manquantes ou supprimées (afficher une erreur et une issue de sortie claire).

Rendre les changements UI relisables et modulaires

Quand vous itérez vite, le vrai risque n'est pas l'UI « incorrecte ». C'est une UI non relisable. Si un coéquipier ne peut pas dire ce qui a changé, pourquoi ça a changé et ce qui est resté stable, chaque itération suivante ralentit.

Une règle utile : verrouillez d'abord les interfaces, puis laissez les internes bouger. Stabilisez les props publiques des widgets (inputs), petits modèles UI et arguments de route. Une fois nommés et typés, vous pouvez remodeler l'arbre de widgets sans casser le reste de l'app.

Préférez de petites coutures stables

Demandez un plan favorable aux diffs avant de générer du code. Vous voulez un plan qui dit quels fichiers changeront et lesquels resteront intacts. Cela concentre les revues et évite les refactors accidentels qui modifient le comportement.

Patterns qui maintiennent de petits diffs :

• Gardez les widgets publics minces : acceptez seulement les données et callbacks nécessaires, évitez d'aller piocher dans des singletons.
• Sortez les règles métiers des widgets tôt : mettez les décisions dans un controller ou view model, et faites l'UI rendre l'état.
• Quand une pièce UI ne change plus toutes les heures, extrayez-la en widget réutilisable avec une API claire et typée.
• Gardez les arguments de route explicites (un objet d'argument unique est souvent plus propre que plusieurs champs optionnels).
• Ajoutez un court changelog dans la description de votre PR : ce qui a changé, pourquoi, et quoi tester.

Un exemple concret apprécié par les reviewers

Supposons la story : « En tant qu'acheteur, je peux modifier mon adresse de livraison depuis le checkout. » Verrouillez d'abord les args de route : CheckoutArgs(cartId, shippingAddressId) reste stable. Puis itérez à l'intérieur de l'écran. Quand le layout est stable, découpez en AddressForm, AddressSummary et SaveBar.

Si la gestion d'état change (par exemple, la validation passe du widget à un CheckoutController), la revue reste lisible : les fichiers UI changent principalement pour le rendu, tandis que le controller montre la logique centralisée en un seul endroit.

Erreurs communes et pièges quand on itère avec un assistant IA

La façon la plus rapide de ralentir est de demander à l'assistant de tout changer en même temps. Si un commit touche layout, état et navigation, les reviewers ne sauront pas ce qui a cassé, et le rollback devient compliqué.

Une habitude plus sûre : une intention par itération : façonnez l'arbre de widgets, puis câblez l'état, puis connectez la navigation.

Erreurs qui créent du code désordonné

Un problème courant est de laisser le code généré inventer un nouveau pattern à chaque écran. Si une page utilise Provider, la suivante setState et la troisième un controller personnalisé, l'app devient rapidement incohérente. Choisissez un petit ensemble de patterns et faites-les respecter.

Autre erreur : mettre du travail asynchrone directement dans build(). Ça peut sembler correct pour une démo rapide, mais ça déclenche des appels répétés aux rebuilds, des clignotements et des bugs difficiles à tracer. Déplacez l'appel dans initState(), un view model ou un controller dédié, et gardez build() concentré sur le rendu.

Le nommage est un piège discret. Du code qui compile mais qui s'appelle Widget1, data2 ou temp rend les refactors futurs pénibles. Des noms clairs aident aussi l'assistant à produire des modifications de suivi meilleures car l'intention est évidente.

Garde-fous pour éviter le pire :

• Changez une seule chose à la fois : layout, état ou navigation
• Réutilisez le même pattern d'état sur la feature
• Pas d'appels réseau ou base de données dans build()
• Renommez les placeholders avant d'ajouter des fonctionnalités
• Préférez extraire des widgets plutôt qu'empiler encore plus de nesting

Le piège du nesting

Une correction visuelle classique est d'ajouter un Container, Padding, Align puis SizedBox jusqu'à ce que ça ressemble. Après quelques passes, l'arbre devient illisible.

Si un bouton est mal aligné, essayez d'abord d'enlever des wrappers, d'utiliser un seul widget parent de layout ou d'extraire un petit widget avec ses propres contraintes.

Exemple : un écran de checkout où le total change de taille lors du chargement. Un assistant pourrait entourer la ligne du prix de plus en plus de widgets pour la « stabiliser ». Une solution plus propre est de réserver l'espace avec un placeholder de chargement simple tout en gardant la structure de la ligne inchangée.

Checklist rapide avant de committer l'itération UI suivante

Avant de committer, faites une passe de deux minutes qui vérifie la valeur utilisateur et vous protège des régressions surprises. L'objectif n'est pas la perfection. C'est faire en sorte que cette itération soit facile à relire, tester et annuler.

Checklist prête pour commit

Relisez la user story une fois, puis vérifiez ces éléments contre l'app en cours d'exécution (ou au moins contre un test de widget simple) :

• L'arbre de widgets correspond à la story : éléments clés de l'acceptation visibles. Le texte, les boutons et les espaces sont intentionnels.
• Tous les états sont atteignables : loading, error et empty ne sont pas juste esquissés en code. Vous pouvez déclencher chacun (même via un flag debug temporaire) et ça reste acceptable.
• La navigation et le comportement du back ont du sens : le back retourne à l'écran attendu, les dialogues se ferment correctement et les deep links (si utilisés) atterrissent bien.
• Les diffs restent petits et maîtrisés : changements limités à un petit ensemble de fichiers avec une responsabilité claire. Pas de refactors non liés.
• Rollback propre : si vous revenez sur ce commit, les autres écrans buildent et tournent toujours. Supprimez les flags temporaires ou assets placeholders qui pourraient casser plus tard.

Un petit check réaliste : si vous avez ajouté un nouvel écran Détails de commande, vous devriez pouvoir (1) l'ouvrir depuis la liste, (2) voir un spinner de chargement, (3) simuler une erreur, (4) voir une commande vide, et (5) appuyer sur back pour revenir à la liste sans sauts bizarres.

Si votre workflow supporte snapshots et rollback, prenez un snapshot avant des changements UI plus importants. Certaines plateformes comme Koder.ai proposent cela, et ça aide à itérer plus vite sans risquer la branche principale.

Un exemple réaliste : de la user story aux écrans en trois itérations

User story : « En tant qu'acheteur, je peux parcourir des items, ouvrir une page de détails, sauvegarder un item en favoris puis voir mes favoris plus tard. » L'objectif est de passer des mots aux écrans en trois petites étapes relisables.

Itération 1 : concentrez-vous uniquement sur l'écran de liste. Créez un arbre de widgets suffisant pour rendre mais pas lié à de vraies données : un Scaffold avec un AppBar, une ListView de lignes factices et une UI claire pour loading et empty. Gardez l'état simple : loading (affiche un CircularProgressIndicator), empty (message court et éventuellement un bouton Réessayer) et ready (affiche la liste).

Itération 2 : ajoutez l'écran de détails et la navigation. Restez explicite : onTap pousse une route et passe un petit objet paramètre (par exemple : id de l'item, titre). Démarrez la page de détails en lecture seule avec un titre, une description factice et un bouton Favori. Le but est de respecter la story : liste -> détails -> retour, sans flux supplémentaires.

Itération 3 : introduisez la mise à jour de l'état des favoris et du feedback UI. Ajoutez une source de vérité unique pour les favoris (même en mémoire), et reliez-la aux deux écrans. Taper Favori met à jour l'icône immédiatement et affiche une confirmation (ex. SnackBar). Puis ajoutez un écran Favoris qui lit le même état et gère l'état vide.

Un diff relisible ressemble typiquement à :

• browse_list_screen.dart : arbre de widgets + UI loading/empty/ready
• item_details_screen.dart : layout UI et accepte des params de navigation
• favorites_store.dart : holder d'état minimal et méthodes de mise à jour
• app_routes.dart : routes et helpers de navigation typés
• favorites_screen.dart : lit l'état et affiche empty/list UI

Si un fichier devient « l'endroit où tout arrive », scindez-le avant d'aller plus loin. Des petits fichiers aux noms clairs accélèrent la prochaine itération.

Étapes suivantes : rendre la boucle répétable entre features

Si le workflow ne fonctionne que quand vous êtes « dans la zone », il cassera dès que vous changerez d'écran ou qu'un coéquipier touchera la feature. Faites de la boucle une habitude en l'écrivant et en posant des garde-fous sur la taille des changements.

Créez un template de prompt réutilisable

Utilisez un template d'équipe pour que chaque itération commence avec les mêmes entrées et produise le même type de sortie. Gardez-le court mais spécifique :

• User story + critères d'acceptation (ce que « done » signifie)
• Contraintes UI (design system, espacements, composants à réutiliser)
• Règles d'état (où vit l'état, local vs partagé)
• Règles de navigation (routes, deep links, comportement du back)
• Règles de sortie (fichiers à toucher, tests à mettre à jour, ce qu'il faut expliquer dans le diff)

Cela réduit les chances que l'assistant invente de nouveaux patterns en cours de feature.

Définissez ce que signifie « petit » pour que les diffs restent prévisibles

Choisissez une définition de petit facile à faire respecter en revue de code. Par exemple, limitez chaque itération à un nombre de fichiers et séparez refactors UI et changements de comportement.

Un ensemble simple de règles :

• Pas plus de 3 à 5 fichiers modifiés par itération
• Une nouvelle widget ou une nouvelle étape de navigation par itération
• Pas de nouvelle approche de gestion d'état introduite en cours de boucle
• Chaque changement doit compiler et s'exécuter avant la prochaine itération

Ajoutez des points de contrôle pour pouvoir annuler rapidement une mauvaise étape. Au minimum, taggez les commits ou gardez des checkpoints locaux avant des refactors majeurs. Si votre workflow supporte snapshots et rollback, utilisez-les agressivement.

Si vous voulez un workflow basé sur le chat qui peut générer et affiner des apps Flutter de bout en bout, Koder.ai inclut un mode de planification qui vous aide à revoir un plan et les fichiers attendus avant de les appliquer.