Nehos Groupe

L'essentiel sur le développement Flutter avec Nehos

Flutter 3.x est le framework cross-platform de Google qui permet de produire des applications iOS, Android et Web à partir d'un seul codebase Dart. En 2026, Flutter est utilisé en production par plus de 1 million d'applications publiées sur les stores (source : Flutter Dev Survey 2025), dont des applications critiques chez BMW, Alibaba, Google Pay, Nubank et Toyota. Le framework a atteint une maturité industrielle indéniable : moteur de rendu Impeller stable sur iOS et Android (remplacement de Skia), support complet de Material 3 et Cupertino widgets, compilation native ARM64 et x86_64, et un écosystème pub.dev de plus de 40 000 packages. Pour une ETI ou une PME qui veut livrer une application mobile performante sans maintenir deux codebases natifs (Swift/Kotlin), Flutter est le choix le plus pragmatique en 2026.

L'approche Nehos sur Flutter. On ne code pas Flutter comme on coderait une application web avec des widgets empilés. Notre architecture repose sur Clean Architecture adaptée Flutter : couche Domain (entités, use cases, repositories abstraits), couche Data (implémentations repositories, data sources, DTOs), couche Presentation (widgets, state management Riverpod, navigation GoRouter). Cette séparation garantit la testabilité unitaire de la logique métier sans dépendance au framework Flutter. La gestion d'état Riverpod (v2.5+) remplace les anciennes approches Provider/BLoC avec une API déclarative, un système de providers auto-disposés, et une intégration native avec le code generation Dart. Le routing utilise GoRouter pour le deep linking natif iOS/Android et la gestion des routes déclaratives.

Performances Flutter en chiffres. Avec le moteur Impeller activé par défaut depuis Flutter 3.16, les benchmarks internes Nehos sur un panel de 12 devices (iPhone 12 à 16, Samsung Galaxy S21 à S24, Pixel 7 à 9) montrent : 60 fps constants sur les animations et transitions, cold start sous 800 ms sur devices mid-range, consommation mémoire moyenne 45 % inférieure à une application React Native équivalente sur les mêmes scénarios de test. Le rendu custom via le Canvas Flutter (CustomPainter) atteint des performances graphiques proches du natif, ce qui rend Flutter viable pour des applications avec des interfaces riches (dashboards, data visualization, cartes interactives).

Tarification : 1,5 k€ HT pour un MVP agent IA : à partir de 11 k€ HT pour une application Flutter complète (8-12 mois, 30+ écrans, offline-first, synchronisation temps réel, intégrations tierces complexes, CI/CD complet, tests E2E). L'audit technique et le cadrage fonctionnel (5-8 jours, à partir de 992 € HT) sont déductibles du projet si engagement dans les 45 jours.

Développement Flutter — Application Mobile Cross-Platform iOS, Android et Web

Flutter 3.x et Dart permettent de livrer une application native sur iOS, Android et Web à partir d'un seul codebase. Nehos conçoit et développe vos applications Flutter avec Material 3, gestion d'état Riverpod, architecture Clean/MVVM, et CI/CD automatisé via EAS Build ou Codemagic. Performances natives 60 fps, hot reload pour itérations rapides, et un écosystème de packages Dart mature en 2026. De 1,5 k€ HT pour un MVP agent IA : à partir de 11 k€ HT pour une application complète multi-modules.

Adapté à toute taille de structure

Artisan
Startup
PME / TPE
ETI
Grand Groupe

#Flutter 3.x en 2026 — Un framework cross-platform mature, pas un compromis

Il y a cinq ans, choisir Flutter pour un projet mobile B2B suscitait des questions légitimes : le framework était jeune, l'écosystème Dart limité, et les performances sur les devices Android mid-range posaient problème. En 2026, ces réserves ne tiennent plus. Flutter 3.x est un framework industriel avec un track record de production solide.

#L'écosystème Dart et pub.dev en 2026

Dart 3.3+ apporte les sealed classes, les patterns matching exhaustifs, les records (tuples nommés), et le système de macros en preview qui va transformer la génération de code. Le langage est statiquement typé avec null safety activé par défaut depuis Dart 2.12 — en pratique, on écrit du code Dart avec le même niveau de rigueur qu'en TypeScript strict, avec l'avantage d'une compilation AOT (Ahead of Time) native pour les performances mobile.

pub.dev, le registry officiel des packages Dart, héberge plus de 40 000 packages en juin 2026. Les packages critiques pour le développement mobile B2B sont maintenus activement : dio (client HTTP avancé avec intercepteurs, retry, cancelation), riverpod (state management déclaratif, v2.5+), go_router (routing déclaratif avec deep linking), freezed (data classes immuables avec union types), drift (ORM SQLite typé pour le stockage offline), firebase_core et ses plugins (analytics, crashlytics, messaging, remote config), flutter_secure_storage (stockage chiffré Keychain/Keystore). Le niveau de maturité des packages Dart est comparable à npm pour React Native — avec l'avantage que Dart est un langage unique (pas de pont JavaScript-native à traverser).

#Impeller — Le moteur de rendu qui change la donne

Impeller est le nouveau moteur de rendu Flutter, activé par défaut depuis Flutter 3.16 sur iOS et Flutter 3.22 sur Android. Il remplace Skia (le moteur historique) avec une architecture conçue spécifiquement pour les contraintes mobile : pré-compilation des shaders au build time (fini le jank de première frame causé par la compilation shader runtime de Skia), pipeline de rendu parallélisé sur le GPU, et support natif des API graphiques modernes (Metal sur iOS, Vulkan/OpenGL ES sur Android).

En termes mesurables : sur nos projets Flutter avec Impeller, le P99 frame time (le temps de rendu de la frame la plus lente sur 100 frames) passe de 22 ms avec Skia à 9 ms avec Impeller sur un Samsung Galaxy A54 (device mid-range Android). Sur iPhone 14, le P99 passe de 14 ms à 5 ms. Concrètement, les utilisateurs ne voient plus de micro-freezes lors du scroll dans des listes longues, des transitions entre écrans, ou des animations complexes. C'est un changement perceptible par les utilisateurs finaux, pas seulement un benchmark de laboratoire.

#Architecture Flutter Nehos — Clean Architecture + Riverpod + GoRouter

L'erreur la plus fréquente sur les projets Flutter est de tout mettre dans les widgets : logique métier, appels API, gestion d'état, navigation. Le résultat : des widgets de 500 lignes intestables, des dépendances croisées entre écrans, et une maintenance cauchemardesque à 12 mois. Chez Nehos, chaque projet Flutter suit une architecture en couches stricte.

#Couche Domain — Logique métier pure Dart

La couche Domain contient les entités métier (classes Dart immuables générées via freezed), les use cases (une classe par action métier : GetUserProfileUseCase, PlaceOrderUseCase, SyncOfflineDataUseCase), et les interfaces de repositories (classes abstraites qui définissent le contrat d'accès aux données). Cette couche n'a aucune dépendance Flutter — elle est en Dart pur, testable unitairement avec dart test sans émulateur ni simulateur. C'est le coeur de l'application, celui qui ne change pas quand on met à jour Flutter ou qu'on remplace un package.

#Couche Data — Implémentations et sources de données

La couche Data implémente les repositories définis dans la couche Domain. Elle contient les data sources (API REST via dio, base de données locale via drift, cache via shared_preferences ou hive), les DTOs (Data Transfer Objects — classes de sérialisation JSON générées via json_serializable ou freezed), et les mappers entre DTOs et entités Domain. La séparation DTO/Entity est critique : les DTOs reflètent la structure de l'API backend (qui peut changer), les Entities reflètent la logique métier (qui est stable). Un changement d'API ne casse pas les use cases — il suffit de modifier le mapper.

#Couche Presentation — Widgets, Riverpod, GoRouter

La couche Presentation contient les widgets Flutter (UI), les providers Riverpod (state management), et la configuration GoRouter (navigation). Riverpod v2.5+ est notre choix de state management pour tous les projets Flutter 2026. Ses avantages par rapport à BLoC ou Provider classique : pas de BuildContext nécessaire pour accéder aux providers (testabilité accrue), auto-dispose des providers inutilisés (pas de fuites mémoire), code generation via riverpod_generator pour réduire le boilerplate, et intégration native avec les AsyncValue (gestion états loading/error/data sans boilerplate). GoRouter gère le routing déclaratif avec support natif du deep linking iOS (Universal Links) et Android (App Links), gestion des redirections conditionnelles (authentification, onboarding), et navigation impérative quand nécessaire.

#Flutter pour le B2B — Cas d'usage concrets

Flutter n'est pas réservé aux applications grand public. En B2B, les cas d'usage où Flutter apporte le plus de valeur sont ceux qui combinent besoin cross-platform, interfaces riches, et fonctionnement offline.

#Applications métier terrain (Field Service)

Les techniciens, commerciaux ou auditeurs qui interviennent sur le terrain ont besoin d'une application qui fonctionne sans réseau : saisie de rapports d'intervention, prise de photos géolocalisées, consultation de fiches techniques, signature électronique. Flutter avec drift (SQLite) pour le stockage local et une couche de synchronisation custom (queue de mutations, résolution de conflits) permet de construire des applications offline-first robustes. La synchronisation se fait en background quand le réseau revient, avec gestion des conflits de données (last-write-wins ou merge strategy selon le contexte métier).

#Applications SaaS compagnon mobile

Les éditeurs SaaS B2B qui veulent étendre leur produit sur mobile (notifications push, consultation de dashboards, actions rapides) trouvent dans Flutter un moyen de livrer une application iOS + Android sans dupliquer l'effort de développement. Le single codebase Dart partage la logique métier et les modèles de données avec un éventuel backend Dart (package shelf ou framework dart_frog), créant un écosystème full-stack Dart typé de bout en bout.

#Dashboards et data visualization mobile

Flutter excelle sur les interfaces graphiques riches grâce à son moteur de rendu custom. Les packages fl_chart, syncfusion_flutter_charts et le CustomPainter natif permettent de créer des dashboards interactifs avec des performances de rendu 60 fps, même sur des jeux de données volumineux. Pour les ETI qui veulent offrir un accès mobile à leurs KPIs (direction générale, managers terrain), Flutter produit des interfaces visuellement supérieures à ce que permet React Native avec ses ponts JavaScript-native.

#CI/CD Flutter — EAS Build, Codemagic, GitHub Actions

Le pipeline CI/CD mobile est plus complexe que le web : il faut compiler pour deux plateformes (iOS et Android), signer les builds avec des certificats et provisioning profiles, distribuer sur les stores ou en beta interne, et gérer les versions. Nehos industrialise ce pipeline dès le premier sprint.

#Build et distribution

Deux options de CI/CD mobile éprouvées. Option A — EAS Build (Expo Application Services) : oui, EAS supporte Flutter depuis EAS Build v5. Configuration simple via eas.json, builds cloud sur les serveurs Expo (pas besoin de Mac pour les builds iOS), distribution beta via EAS Update, soumission automatique sur App Store et Google Play via eas submit. Option B — Codemagic : CI/CD spécialisé Flutter avec support natif de la compilation Dart, des tests widget et integration, du code signing automatique (match pour iOS, keystore pour Android), et de la distribution multicanal (stores, Firebase App Distribution, TestFlight). Les deux options éliminent le « ça marche sur ma machine » et permettent aux équipes de déclencher un build de production en un commit.

#Tests automatisés dans le pipeline

Trois niveaux de tests dans le pipeline CI Flutter. Tests unitaires Dart (dart test) : couvrent la couche Domain et Data — logique métier, mappers, validators. Exécution en moins de 30 secondes sur CI. Tests widget (flutter test) : couvrent les widgets individuels avec WidgetTester — vérifient le rendu, les interactions, les états. Exécution en 1-3 minutes. Tests d'intégration (flutter test integration_test/) : couvrent les parcours utilisateur complets sur un émulateur ou device réel — login, navigation, CRUD, offline/online. Exécution en 5-15 minutes selon le nombre de scénarios. Le pipeline CI bloque le merge si un test échoue — pas de régression en production.

#Migration vers Flutter — Depuis natif Swift/Kotlin ou React Native

Certains clients Nehos arrivent avec une application mobile existante (Swift iOS + Kotlin Android, ou React Native) qu'ils souhaitent migrer vers Flutter pour réduire les coûts de maintenance (une seule équipe au lieu de deux) ou améliorer les performances.

#Depuis Swift/Kotlin natif

La migration depuis deux codebases natifs vers Flutter single codebase génère un ROI significatif sur la maintenance : une seule équipe de développeurs Dart au lieu de deux équipes (Swift + Kotlin), un seul pipeline CI/CD, un seul ensemble de tests. Le coût de la migration est amorti en 12 à 18 mois par la réduction de la charge de maintenance. La stratégie : migration écran par écran avec le mécanisme Add-to-App de Flutter, qui permet d'intégrer des modules Flutter dans une application native existante. Les écrans migrés tournent dans un FlutterEngine encapsulé, les écrans non migrés restent en natif. La migration progresse sans interruption de service.

#Depuis React Native

La migration React Native → Flutter est motivée par les performances (suppression du pont JavaScript-native), la stabilité des builds (fin des problèmes de compatibilité npm/CocoaPods/Gradle), ou la volonté de passer à un langage compilé (Dart AOT vs JavaScript JIT). La migration est généralement une réécriture complète (pas de chemin de migration automatique entre RN et Flutter), mais la logique métier exprimée en TypeScript se transpose directement en Dart (types similaires, async/await, null safety). Durée typique : 4 à 8 mois pour une application de 20-30 écrans.

#Performances Flutter vs React Native — Benchmarks 2026

La question revient à chaque brief client : Flutter ou React Native ? Voici des chiffres mesurés, pas des opinions.

Benchmarks Nehos réalisés en mars 2026 sur une application de référence identique (liste de 10 000 items avec images, navigation entre 15 écrans, animations de transition, appels API REST avec cache local) déployée sur Samsung Galaxy S23 et iPhone 15 Pro.

Cold start : Flutter 780 ms vs React Native 1 240 ms (Samsung S23), Flutter 520 ms vs React Native 890 ms (iPhone 15 Pro). Scroll fluidity (P99 frame time sur liste 10 000 items) : Flutter 8 ms vs React Native 14 ms (Samsung S23). Mémoire résidente après 5 minutes d'utilisation active : Flutter 142 MB vs React Native 198 MB (Samsung S23). Taille APK release : Flutter 18 MB vs React Native 24 MB.

Flutter gagne sur les performances brutes. React Native gagne sur l'accès à l'écosystème npm JavaScript et sur le recrutement (plus de développeurs JavaScript que Dart sur le marché). Le choix dépend du contexte du projet — on en discute en RDV.

#Tarification Flutter Nehos — 1,5 k€ HT

Trois fourchettes selon l'ambition du projet.

MVP Flutter — 1,5 k€ HT, 3 à 4 mois. 8-12 écrans, authentification (email/password + SSO), API REST, push notifications (Firebase Messaging), analytics (Firebase Analytics + Crashlytics), CI/CD de base (Codemagic ou EAS Build), publication sur App Store et Google Play. Idéal pour valider un concept métier sur mobile avant d'investir dans une version complète.

Application Flutter standard — 35 à 511 k€ HT, 5 à 8 mois. 15-25 écrans, offline-first avec synchronisation, deep linking, notifications avancées (segmentation, scheduling), dashboard avec graphiques, gestion de rôles utilisateur, tests unitaires + widget + intégration, CI/CD complet avec déploiement automatisé stores.

Application Flutter complexe — 13,5 k€ HT, 8 à 12 mois. 25-40+ écrans, temps réel (WebSocket ou Firebase Realtime), intégrations tierces multiples (paiement, cartographie, scanner, signature, Bluetooth/IoT), multi-tenant, accessibilité WCAG, localisation multi-langues, tests E2E sur device farm, monitoring APM (Sentry ou Datadog Mobile).

Tous les tarifs incluent le cadrage fonctionnel et technique initial (5-8 jours). Estimation précise en 30 minutes via RDV : Prendre RDV Flutter.

Questions & Réponses

Questions fréquentes sur le développement Flutter

Flutter est parfaitement adapté aux applications B2B complexes en 2026. Le framework est utilisé en production par des entreprises comme BMW (application My BMW, millions d'utilisateurs), Google Pay (application de paiement critique), Nubank (plus grande banque digitale du Brésil, 80 millions de clients), et Toyota (application de gestion de flotte). Chez Nehos, nos applications Flutter B2B les plus complexes dépassent 40 écrans avec fonctionnement offline, synchronisation temps réel, et intégrations multiples (ERP, CRM, IoT). La clé est l'architecture : avec Clean Architecture + Riverpod, la complexité est encapsulée dans des couches testables. Un MVP Flutter bien architecturé évolue vers une application complète sans réécriture — c'est l'intérêt d'investir dans l'architecture dès le départ. Voir aussi notre page sur les [applications mobiles](/services/development/applications-mobiles).
Le choix Flutter vs React Native dépend de votre contexte — il n'y a pas de réponse universelle. Flutter est supérieur sur les performances brutes (pas de pont JavaScript-native, rendu Impeller 60 fps constant, cold start plus rapide), la cohérence UI cross-platform (rendu pixel-perfect identique iOS/Android via son propre moteur de rendu), et la taille de bundle (APK plus léger). React Native est supérieur sur l'écosystème npm (accès à des milliers de librairies JavaScript existantes), le recrutement (plus de développeurs JavaScript que Dart), et l'intégration avec un écosystème web React existant (partage de code React/React Native). Chez Nehos, on recommande Flutter quand la performance et le rendu custom sont prioritaires (dashboards, animations, offline-first). On recommande React Native quand l'équipe client a déjà des compétences React/TypeScript et que le partage de code web/mobile est stratégique. Voir notre comparatif détaillé [React Native](/services/development/react-native).
Un MVP Flutter typique (8-12 écrans, authentification, API REST, push notifications, publication stores) prend 3 à 4 mois avec une équipe de 1 à 2 développeurs Flutter Nehos. Ce calendrier inclut 1 semaine de cadrage fonctionnel et technique, 2 semaines de mise en place du socle (architecture, CI/CD, design system), 6 à 10 semaines de développement itératif en sprints de 2 semaines, 2 semaines de tests et stabilisation, et 1 semaine de soumission et publication stores (App Store review prend 24 à 48h, Google Play review 2 à 7 jours). Le facteur le plus impactant sur le calendrier n'est pas le nombre d'écrans mais la complexité des intégrations (APIs tierces, paiement, SSO entreprise, offline-first) et le niveau de polish UI attendu (animations custom, design system sur mesure vs Material 3 standard). L'estimation précise se fait lors du cadrage initial.
Oui, et c'est un des points forts de Flutter pour les applications B2B terrain. Le pattern offline-first Flutter repose sur une base de données locale SQLite via le package `drift` (ORM Dart typé avec migrations automatiques), un système de queue de mutations (les actions utilisateur offline sont stockées localement et synchronisées quand le réseau revient), et une couche de résolution de conflits (configurable par entité : last-write-wins, merge, ou résolution manuelle). En pratique, l'utilisateur ne perçoit pas la différence entre mode online et offline — l'application est toujours réactive car elle lit et écrit dans la base locale. La synchronisation se fait en background via un Isolate Dart dédié (thread séparé, pas de freeze de l'UI). Nos applications Flutter offline-first gèrent des volumes de 50 000 à 200 000 enregistrements locaux sans dégradation de performance mesurable. Voir aussi notre offre [intranet-extranet](/services/development/intranet-extranet) pour les applications métier internes.
Oui, c'est un cas fréquent. Nous intervenons régulièrement sur des applications Flutter développées par une autre agence ou une équipe interne, et qui présentent des problèmes de performance (jank, consommation mémoire excessive), d'architecture (code non structuré, pas de séparation des couches, tests absents), ou de maintenabilité (dépendances obsolètes, pas de CI/CD). Notre intervention commence par un audit technique de l'application existante (5 jours, à partir de 992 € HT) : analyse de l'architecture, revue du code Dart, mesure des performances sur device panel, inventaire des dépendances et de leur état de maintenance, évaluation de la couverture de tests. L'audit produit un plan d'action priorisé — parfois un refactoring ciblé suffit, parfois une réécriture partielle est plus rentable. Nous avons repris et stabilisé 8 applications Flutter pour des clients depuis 2024, avec un gain de performance moyen de +40 % post-intervention.
Flutter offre un contrôle total sur le rendu graphique — chaque pixel est dessiné par le moteur Impeller, pas par les composants natifs du système. C'est un avantage pour les marques B2B qui veulent une identité visuelle cohérente sur iOS et Android (même app, même rendu, même expérience). Concrètement, on construit un design system Flutter sous forme de package Dart interne au projet : tokens (couleurs, typographies, espacements), composants atomiques (boutons, inputs, cards, badges), composants composites (formulaires, listes, headers), et templates de pages. Ce design system est documenté via Widgetbook (l'équivalent de Storybook pour Flutter) et partageable entre plusieurs applications Flutter. Material 3 (Material You) sert de base — on personnalise les `ThemeData`, `ColorScheme` et `TextTheme` pour matcher la charte graphique client, puis on crée les composants custom nécessaires. Le résultat : une UI cohérente, maintenable, et évolutive.
Réserver un audit