Flutter repose sur un moteur de rendu propriétaire qui redessine chaque pixel à l’écran au lieu de déléguer aux composants natifs du système. Ce choix architectural, qui explique la fluidité vantée du framework, génère aussi ses principales limitations techniques. Nous détaillons ici les inconvénients concrets que nous observons en production, au-delà des listes génériques habituelles.
Platform channels et dette de code natif en Dart, Swift et Kotlin
Le premier problème structurel de Flutter se manifeste dès qu’une application doit interagir en profondeur avec le système d’exploitation. Bluetooth avancé, localisation en arrière-plan, accès aux données de santé, gestion de périphériques propriétaires : toutes ces fonctionnalités passent par des platform channels écrits en Swift ou Kotlin.
Lire également : Qu'est-ce que l'accessibilité numérique englobe ?
L’équipe de developpement maintient alors simultanément trois bases de code : la couche Dart, le code natif iOS et le code natif Android. Le bénéfice du codebase unique, argument central du framework, se réduit considérablement dans ce scénario.
La situation empire quand un plugin communautaire ne couvre pas le cas d’usage exact. Le développeur doit alors forker le plugin, écrire du code natif spécifique, puis synchroniser les mises à jour du plugin parent avec ses propres modifications. Sur un projet de plus de douze mois, cette dette technique s’accumule et ralentit les cycles de livraison.
Lire également : Comment faire une gestion de base de données ?
Adoption retardée des nouveautés iOS et Android
Flutter dessine sa propre interface. Il n’utilise pas les composants UIKit d’Apple ni les vues Material natives d’Android. Conséquence directe : une nouvelle API ou convention visuelle de plateforme n’est pas disponible immédiatement.
Quand Apple introduit un nouveau style d’interaction ou que Google modifie un comportement système, il faut attendre une mise à jour du framework, d’un plugin tiers ou écrire un bridge natif. En développement natif pur, l’intégration est disponible dès la bêta du système d’exploitation.
Ce décalage pose un problème concret pour les applications qui doivent respecter les guidelines de la plateforme dès le jour du lancement d’une nouvelle version d’iOS ou d’Android. Les équipes qui publient des applications grand public sensibles à l’expérience utilisateur (banque, santé, mobilité) le constatent régulièrement.
Taille des applications Flutter : le poids du moteur embarqué
Le moteur graphique Skia (remplacé progressivement par Impeller) est embarqué dans chaque application Flutter. Cette architecture impose un plancher de taille que n’ont pas les applications natives simples.
Pour une application utilitaire minimaliste, la différence de poids entre une version native et une version Flutter est perceptible par l’utilisateur au moment du téléchargement. Sur des marchés où la bande passante mobile reste contrainte, ce surpoids n’est pas anodin.
- Le moteur de rendu intégré ajoute un volume incompressible au binaire final, même si l’application n’affiche que quelques écrans
- Les assets Dart compilés en code machine contribuent aussi à l’augmentation de la taille, car le tree shaking ne supprime pas l’intégralité du code inutilisé
- Les plugins natifs embarquent leurs propres dépendances, qui s’ajoutent au poids du moteur Flutter lui-même
Flutter Web et référencement naturel : une limite structurelle
Flutter Web n’est pas adapté aux sites dépendants du SEO. Le framework génère un rendu canvas ou un DOM non standard qui complique l’indexation par les moteurs de recherche.
Pour un tableau de bord interne ou une application web interactive, ce n’est pas un problème. Pour un site vitrine, un e-commerce ou un média éditorial, Flutter Web est un mauvais choix technique. Les technologies web classiques (HTML, CSS, JavaScript avec un framework comme React ou Next.js) restent nettement plus performantes sur ce terrain.
Nous observons que certaines équipes choisissent Flutter pour le mobile puis doivent développer une version web séparée avec une autre stack. Le coût total du projet augmente, et la promesse du code unique multi-plateforme perd de sa substance.
Écosystème Dart : recrutement et maturité des bibliothèques
Dart reste un langage de niche comparé à Kotlin, Swift ou JavaScript. Le bassin de developpeurs expérimentés est plus restreint, ce qui complique le recrutement et augmente les coûts salariaux sur certains marchés.
La communaute de plugins, bien qu’active, n’atteint pas la maturité de l’écosystème npm (React Native) ou des bibliothèques natives. Certains packages critiques dépendent d’un mainteneur unique. Quand ce mainteneur arrête de contribuer, l’équipe projet hérite de la maintenance.
- Les développeurs mobiles expérimentés doivent apprendre Dart en plus de leurs compétences existantes en Kotlin ou Swift
- Les bibliothèques tierces couvrent moins de cas d’usage spécifiques que celles disponibles en natif
- Un plugin abandonné peut bloquer une montée de version du SDK Flutter si ses dépendances deviennent incompatibles
Problèmes de build et toolchain
Les montées de version majeures de Flutter cassent régulièrement la compatibilité avec des plugins existants. La migration entre versions du SDK demande du temps de développement non fonctionnel que les plannings sous-estiment.
Sur des projets avec de nombreuses dépendances natives, la résolution de conflits Gradle (Android) ou CocoaPods (iOS) devient un irritant récurrent. Ces problèmes de build n’existent pas, ou sont moins fréquents, en développement natif pur.
Quand Flutter reste pertinent malgré ses limites
Ces inconvénients ne disqualifient pas Flutter dans tous les contextes. Le framework conserve un avantage réel pour les applications mobiles à interface riche qui n’exigent pas d’intégration système profonde : prototypage rapide, MVP, applications métier internes, outils de productivité.
Le hot reload accélère les itérations de manière significative. La qualité du rendu visuel, portée par les widgets personnalisables, permet de livrer des interfaces soignées avec une seule équipe de développement.
Le choix dépend du profil technique du projet, pas d’une préférence abstraite pour le cross-platform. Une application de santé connectée avec Bluetooth et capteurs propriétaires sera mieux servie par du natif. Un catalogue produit avec navigation fluide et animations élaborées tire pleinement parti de Flutter. Poser la question des contraintes d’intégration avant de choisir le framework reste la seule approche fiable.
