1. Construire avant de définir le modèle de données
L'erreur la plus courante : commencer dans FlutterFlow avant de modéliser les données dans Supabase. Vous construisez 8 écrans, puis réalisez que votre structure de données ne supporte pas les fonctionnalités dont vous avez besoin. Chaque écran doit être reconstruit.
La solution : passez le premier jour dans l'éditeur de tables Supabase, pas dans FlutterFlow. Définissez chaque table, chaque colonne, chaque relation de clé étrangère. Posez la question : "Puis-je requêter toutes les données dont j'ai besoin pour chaque écran depuis ce schéma ?" Si oui, commencez à construire. Si non, corrigez d'abord le schéma.
La modélisation des données prend 2 à 4 heures. Reconstruire des écrans sur un mauvais schéma prend des jours. C'est l'investissement le plus rentable du début de projet — et pourtant c'est celui qui est le plus souvent sauté par les équipes qui ont hâte de voir les premiers écrans.
2. Ignorer la Row-Level Security
Construire une app multi-utilisateurs sans Row-Level Security (RLS) signifie que chaque utilisateur peut potentiellement accéder aux données de tous les autres — une grave défaillance de sécurité et de conformité.
La solution : activez RLS sur chaque table Supabase dès le premier jour. Rédigez les politiques : - Table users : `using (auth.uid() = id)` - Table items : `using (auth.uid() = user_id)` ou `using (org_id IN (SELECT org_id FROM memberships WHERE user_id = auth.uid()))`
Testez en créant deux utilisateurs de test et en vérifiant que l'utilisateur A ne peut pas voir les données de l'utilisateur B. Ce test prend 10 minutes et doit être fait avant tout autre test.
En France, une violation de données personnelles due à une absence de RLS peut entraîner des sanctions RGPD significatives de la part de la CNIL. Pour les apps B2B notamment, une fuite de données inter-clients peut détruire la confiance et exposer l'entreprise à des recours.
3. Traiter le preview FlutterFlow comme un test
Le preview dans le navigateur de FlutterFlow est pratique mais ne représente pas le comportement réel sur appareil. Nous avons vu des apps qui fonctionnent parfaitement en preview mais crashent sur iOS, ont des gestes cassés sur Android, ou s'affichent incorrectement sur les petits écrans.
La solution : testez sur des appareils physiques hebdomadairement tout au long du développement, pas seulement avant le lancement. Utilisez le "Test Mode" de FlutterFlow pour obtenir un QR code qui installe l'app sur votre appareil. Testez sur au moins un iPhone et un appareil Android, avec différentes tailles d'écran.
Les appareils prioritaires pour le marché français : iPhone 15/14 (les plus répandus), iPhone SE 3ème génération (petit écran), Samsung Galaxy A54/A55 (très populaires dans la gamme moyenne). Un bug qui n'apparaît que sur un écran de 6,1 pouces touchera la majorité de vos utilisateurs français.
4. Tout construire avant de tester avec des utilisateurs
Les fondateurs construisent souvent une application complète — 15 écrans, 8 fonctionnalités — avant de la montrer à un seul vrai utilisateur. Puis ils découvrent que les utilisateurs veulent quelque chose de différent et doivent redesigner la moitié de l'app.
La solution : construisez le workflow principal (3 à 4 écrans) en semaine 2 et présentez-le à 5 vrais utilisateurs. Qu'essaient-ils de faire qui n'existe pas ? Que trouvent-ils déroutant ? Qu'ignorent-ils complètement ? Ces retours façonnent les semaines 3 à 6 et évitent beaucoup de refonte.
Pour recruter des testeurs en France, des communautés comme Tech.rocks, les groupes Slack d'entrepreneurs et les incubateurs régionaux (Station F, Euratechnologies, Minalogic, etc.) sont d'excellentes ressources. Même 3 entretiens utilisateurs de 30 minutes peuvent révéler des problèmes fondamentaux qu'aucun montant de développement supplémentaire ne résoudra.
5. Ignorer les guidelines App Store pendant le développement
Un rejet App Store après 8 semaines de développement est décourageant et coûteux. Les raisons de rejet les plus courantes :
- Pas de politique de confidentialité liée dans l'app et la fiche App Store - Option "Sign in with Apple" manquante quand l'app propose Google ou Facebook Login (Apple l'exige) - App qui est essentiellement un wrapper de site web sans fonctionnalité native - Flux de suppression de données manquant (obligatoire depuis 2024) - Paiements pour des biens numériques effectués en dehors du système d'achats in-app d'Apple
La solution : examinez les App Store Review Guidelines d'Apple au début du projet. Construisez la politique de confidentialité conforme au RGPD, le flux de suppression de compte, et Sign in with Apple dès le premier jour. Pour le marché européen, les mentions légales françaises et les CGU doivent également être accessibles depuis l'app.
6. Ne pas planifier le comportement hors ligne
Les utilisateurs mobiles perdent la connectivité — dans le métro, dans les bâtiments, en voyage. Une app qui affiche un écran vide hors ligne perd la confiance.
FlutterFlow avec Supabase ne supporte pas le mode hors ligne first nativement. La solution : implémentez une dégradation gracieuse. Mettez en cache le dernier fetch de données réussi dans SharedPreferences. Affichez une bannière "Vous êtes hors ligne — affichage des données en cache". Désactivez les actions d'écriture avec un message clair. Les utilisateurs comprennent les limitations hors ligne — ils ne comprennent pas une app complètement vide.
En France, où l'usage du métro parisien et d'autres transports souterrains est massif, le comportement hors ligne est particulièrement important pour les apps B2B utilisées en déplacement. Un commercial qui ne peut pas consulter les fiches clients dans le métro entre deux rendez-vous aura une expérience utilisateur dégradée qui impactera l'adoption de l'outil.
7. Sous-estimer la maintenance post-lancement
Les apps no-code ne sont pas sans maintenance. FlutterFlow publie des mises à jour qui cassent parfois les fonctionnalités existantes. Supabase fait évoluer ses APIs. Apple impose des mises à jour de compatibilité avec les nouvelles versions iOS.
Budgétez 15 à 20 % du coût de développement par an pour la maintenance. Cela couvre : les upgrades de version FlutterFlow, les mises à jour de dépendances, les corrections de compatibilité iOS/Android, et les inévitables demandes "on peut ajouter cette petite fonctionnalité" des utilisateurs.
Les contrats avec les clients doivent inclure une clause de maintenance claire. Les projets sans cette clause deviennent des litiges au premier update iOS qui casse une fonctionnalité. En France, soyez particulièrement attentif aux implications légales : un logiciel livré sans maintenance peut engager la responsabilité de l'agence si des failles de sécurité apparaissent après la livraison. Une convention de maintenance minimale protège les deux parties.