Flutter en Production : Ce que nous avons appris après avoir lancé 3 applications multiplateformes
Flutter est notre choix par défaut pour les applications multiplateformes. Nous avons livré trois applications Flutter en production au cours de l'année écoulée — une application fintech, une plateforme edtech et un outil de service sur le terrain. Chacune nous a enseigné quelque chose de nouveau sur ce que Flutter fait bien et où il faut être prudent. Voici les vraies leçons, pas le discours marketing.
Gestion d'état : nous avons opté pour Riverpod
Après avoir essayé Provider, BLoC et Riverpod sur différents projets, nous avons standardisé Riverpod pour tout nouveau travail Flutter. La raison est simple : il gère l'injection de dépendances et la gestion d'état dans un seul modèle, il est sûr au moment de la compilation (pas d'erreurs d'exécution dues à des providers manquants), et il fonctionne de manière identique dans les tests.
BLoC est puissant mais trop cérémonieux pour la plupart des applications. Le modèle événement-état ajoute du code passe-partout qui ralentit le développement sans avantages proportionnels pour les applications CRUD typiques et pilotées par API. Nous réservons BLoC aux fonctionnalités stateful complexes comme l'édition collaborative en temps réel où le flux d'événements explicite est véritablement utile.
Notre architecture Riverpod suit un modèle à trois couches : les widgets UI dépendent des contrôleurs (StateNotifier ou AsyncNotifier), les contrôleurs dépendent des repositories, et les repositories dépendent des sources de données (clients API, stockage local). Chaque couche est indépendamment testable et le graphe de dépendances est explicite.
Performance : la règle des 90 %
Flutter vous donne 60 fps dès le départ pour 90 % des écrans. Les 10 % restants — listes de défilement longues, animations complexes superposées à des données en direct, et écrans avec de nombreuses images réseau simultanées — nécessitent une optimisation délibérée. Les optimisations les plus percutantes que nous avons trouvées :
Utilisez des constructeurs const partout où c'est possible. Cette seule pratique évite les reconstructions inutiles de widgets et est la victoire performance la plus facile dans Flutter. Nous l'appliquons via des règles lint. Utilisez ListView.builder au lieu de ListView pour toute liste de plus de 20 éléments — elle construit paresseusement uniquement les éléments visibles. Mettez en cache les images réseau avec cached_network_image et définissez des limites de mémoire appropriées. Pour les animations complexes, utilisez RepaintBoundary pour isoler les opérations de peinture coûteuses.
La superposition de performances de Flutter DevTools est votre meilleur allié. Nous l'exécutons sur chaque écran pendant le développement et signalons tout frame qui prend plus de 16ms. La plupart des saccades proviennent du layout thrashing (widgets profondément imbriqués qui déclenchent plusieurs passes de layout) ou des reconstructions inutiles (fournisseurs qui notifient les listeners trop largement).
Canaux de plateforme : passerelle vers le code natif
Chaque application Flutter finit par avoir besoin de code spécifique à la plateforme. Pour notre application fintech, c'était l'authentification biométrique et le stockage de l'enclave sécurisée. Pour notre application edtech, c'était la gestion des notifications push avec des payloads personnalisés. Pour notre application de service sur le terrain, c'était le suivi de localisation en arrière-plan.
Nous utilisons Pigeon pour les canaux de plateforme type-safe au lieu des MethodChannels bruts. Pigeon génère le code passe-partout pour les côtés Dart et natifs à partir d'une seule définition d'interface. Cela élimine la correspondance de noms de méthodes basée sur des chaînes de caractères qui cause des erreurs d'exécution et rend le code des canaux de plateforme véritablement maintenable.
Notre règle d'or : si un plugin existe avec un score pub.dev de 90%+ et une maintenance active, utilisez-le. Sinon, écrivez un thin wrapper de canal de plateforme qui délègue à l'API native. Ne combattez jamais la plateforme — épousez-la par des passerelles propres.
Stratégie de test qui fonctionne réellement
Les outils de test Flutter sont excellents mais sous-utilisés. Notre pyramide de test : 60% de tests unitaires (dépôts, contrôleurs, logique métier), 30% de tests de widgets (rendu des composants et interaction), 10% de tests d'intégration (flux utilisateur critiques de bout en bout). Ce ratio nous donne confiance dans la refactorisation sans la fragilité de trop nombreux tests d'intégration.
La fonctionnalité de test de fichiers golden est sous-estimée. Pour les écrans avec des layouts complexes, nous prenons un snapshot du widget rendu et le comparons à une image de référence. Cela détecte les régressions visuelles que les tests unitaires manquent. Nous exécutons les tests golden sur CI pour chaque demande de fusion.
Choisirions-nous à nouveau Flutter ?
Oui, avec des réserves. Flutter est le meilleur framework cross-platform disponible aujourd'hui pour les applications qui ont besoin à la fois d'iOS et d'Android avec une base de code partagée. Le langage Dart est productif et le système de widgets est véritablement bien conçu. Le hot reload rend l'itération rapide.
Mais ce n'est pas le bon choix pour tout. Les applications qui sont à 50%+ du code spécifique à la plateforme (RA avancée, pipelines caméra complexes, intégration OS approfondie) devraient être natives. Les applications qui sont principalement de l'affichage de contenu avec une interactivité minimale pourraient utiliser React Native ou même une PWA. Flutter excelle pour les applications interactives, basées sur les données avec des besoins d'intégration de plateforme modérés — ce qui décrit la plupart des produits de startup.