Flutter 3.47 : le framework largue pour de bon Material et Cupertino

En résumé : Avec Flutter 3.47, Material et Cupertino sortent officiellement du cœur du framework. Ces design systems, qui reproduisent les codes visuels d'Android et d'iOS, deviennent des packages indépendants à importer explicitement dans chaque projet. Un an après avoir anticipé ce changement, USERADGENTS a testé son impact sur les apps Flutter. Coût réel du sur-mesure, fiabilité de la génération de composants par IA, facilité de la migration pour les projets existants… La plupart des pronostics de 2025 se confirment, avec un bénéfice qui reste conditionné à la maturité du design system.

En 2025, Flutter annonçait son intention de sortir les design systems Material et Cupertino du cœur du framework et notre Lead Développeur Eddy Tokiniaina avait détaillé l’annonce dans cet article, en posant une série de pronostics sur ce que cela pourrait changer pour les projets d’apps Flutter existants ou futurs. Ce découplage implique de retirer Material (les composants qui imitent Android) et Cupertino (ceux qui imitent iOS) du SDK Flutter pour en faire deux packages indépendants, que chaque projet importe désormais explicitement comme n'importe quelle autre dépendance.

Depuis le 12 août 2026, c’est officiellement déployé avec la nouvelle version 3.47 de Flutter. Et parce qu’on tient nos promesses, voici venu le moment de confronter nos théories aux faits et de faire un test concret pour mesurer l’impact réel d’un tel changement pour les apps développées en Flutter.

Le découplage est-il toujours une bonne nouvelle ?

Sans le moindre doute, oui. Un an de recul a confirmé le sens de cette décision. En réalité, c’était même une nécessité. Car pour rappel, ce découplage n'est pas une lubie récente chez Google, c'est la réponse à une demande de la communauté Flutter qui remonte au lancement du framework en 2018 et qui a pris une forme concrète en 2022, avec une discussion GitHub réclamant explicitement la séparation des design systems du cœur du framework. Google, qui contrôlait jusque-là entièrement le contenu de ses librairies malgré la promesse open source de Flutter, a fini par changer son fusil d’épaule et accepté d’offrir l’indépendance aux éditeurs.

Désormais, pour chaque projet d’app Flutter, le choix est de mise. Soit de suivre les grosses tendances des plateformes en restant en 100 % Material, en 100 % Cupertino, ou en mixant les deux (comme c'était déjà possible avant). Soit de tout reconstruire de zéro, pour une identité de marque totalement affranchie des guidelines d'Apple et de Google.

Globalement, la communauté des développeurs a plutôt bien reçu la nouveauté. Le découplage permet de ne pas subir les cycles de mises à jour de Flutter, il implique une meilleure séparation architecturale et les correctifs UI peuvent se faire plus rapidement. De toute façon, rares sont les apps à choisir Flutter comme framework pour ses design systems Material ou Cupertino. La séparation a donc semblé pour la majorité logique. Excepté pour les adeptes de Material de la première heure qui trouvent que la personnalisation avec le design system de Google est beaucoup plus facile et que la création de composants sans lui peut très vite devenir pénible, surtout quand il s’agit de créer des composants complexes comme un formulaire. 

Et ce n’est pas tout à fait faux.

Faire du sur-mesure : la liberté a un prix ?

Si sur le papier l’idée de recréer toute son interface de 0 est séduisante, surtout pour les designers qui peuvent explorer des pistes créatives beaucoup plus larges, pour les développeurs, c’est une autre affaire. Une affaire de complexité. Recréer un composant sans Material ni Cupertino oblige à redescendre très bas dans l'implémentation, bien plus bas que ce à quoi la plupart des développeurs Flutter sont habitués.

Le tableau ci-dessous résume ce qu'il faut recoder soi-même, brique par brique.

Besoin	Material	Cupertino	Sur-mesure (sans design system)
Application	MaterialApp	CupertinoApp	WidgetApp
Structure de page	Scaffold	CupertinoPageScaffold	À construire (wireframe à appliquer sur chaque écran)
Champ de formulaire	TextFormField	–	À construire (FormField + EditableText)
Bouton, carte, liste	Prêts à l'emploi	Partiellement couverts	À construire
Checkbox, switch, slider	Prêts à l'emploi	Prêts à l'emploi	À construire (gestion des gestes et de l'animation)
Dialog, snackbar, drawer	Prêts à l'emploi	Partiellement couverts	À construire (route, overlay, animations)

Et dès qu’il y a de l’animation en jeu, c’est encore pire. Il faut recréer le mouvement (bon ça, ça va encore) mais surtout garantir qu'il reste fluide et cohérent, quelle que soit la taille ou la résolution de l'écran. C'est là que la plupart des projets sur-mesure peuvent perdre du temps.

Repartir de zéro, sans Material ni Cupertino, semble donc surtout pertinent pour les grandes marques : celles qui ont déjà une identité riche cohérente, bien documentée dans un design system exhaustif (celui de l’Etat ou bien d’IBM sont des références en la matière par exemple) et qui bien sûr ont un budget suffisant pour assumer les coûts de design, de développement et de maintenance des nouveaux composants.

L'IA pour générer les composants : un twist suffisant ?

Évidemment, en 2026, l'IA est une solution sérieuse pour pallier la complexité de développement et d’intégration des composants sur-mesure. Nous l’avons testé, ça a marché. Mais attention, à une condition non négociable : cette génération ne fonctionne bien que si le design system fourni au modèle est propre, complet, avec toutes les descriptions nécessaires, sans zone grise ni éléments cachés sous le tapis. Sans cadre précis, le modèle peut inventer des composants qui n'existent pas et c'est toute l'identité de marque qui trinque.

Nous sommes ici sur un cas concret de design-to-code, qui maximise les expertises, facilite la collaboration avec le designer mais ne fait pas forcément gagner du temps au développeur si le design system n’est pas totalement exhaustif. Si l'IA offre un support précieux, la variété des formats d'écrans et des terminaux à adresser oblige à rester vigilant sur l'optimisation des interfaces dans les différents contextes (on dénombre pas moins de 6 poses possibles rien qu’avec le nouvel iPhone Duo d’Apple). Même si cette multiplicité est intrinsèque à la philosophie même du développement sur Flutter. Le support des écrans pliables et double-écrans est d’ailleurs stable dans Flutter depuis 2022, via l'API MediaQuery Display Features, qui distingue les postures d'un appareil (à plat, replié, avec charnière) et prend en charge tous les modèles Fold de Google et Samsung pour l’instant. 

Et comment on migre, en clair ?

Pas de panique pour les projets existants : la migration vers material_ui et cupertino_ui est douce. Une seule commande met à jour automatiquement les imports du projet, sans rien casser côté fonctionnel. Elle bascule simplement l'usage du package interne vers son équivalent externe. Et rien n'oblige à se précipiter : l'ancien et le nouveau système cohabitent le temps de s’adapter, exactement comme lors de la précédente grande transition, de Material 2 vers Material 3, qui avait duré deux ans.

En conclusion : un choix qui dépend des ambitions

Pour la majorité des clients, ceux qui souhaitent continuer avec Material, Cupertino ou tout autre design system tiers, ce découplage est largement transparent : une migration automatisée, une période de transition confortable, et c'est tout. La question des coûts ne se pose que pour ceux qui veulent du sur-mesure (coûts de design, de développement, de maintenance et désormais, de tokens d'IA) Tout dépend, in fine, du niveau de maturité du design system du client.

Avant de se quitter, voici un an après nos pronostics, comment ils se vérifient concrètement, critère par critère.

Critère	Ce qu'on annonçait en 2025	Verdict avec Flutter 3.47
Structure du framework	Chaque design system devient un package indépendant	✅ Confirmé tel quel
Simplicité de démarrage	Légèrement plus complexe : choisir, développer et/ou importer les design systems nécessaires	✅ Confirmé, mais l'ampleur dépend entièrement de la maturité du design system du client
Poids de l'application	Poids réduit, seules les dépendances nécessaires compilées	❌ Infirmé : le tree-shaking de Flutter faisait déjà ce travail, le gain est marginal en pratique
Cohérence du développement	Risque de divergence ou de versioning asynchrone entre packages	❌ Infirmé : l'équipe Flutter maintient toujours Material et Cupertino en parallèle
Flexibilité / extensibilité	Possibilité d'intégrer des design systems multiplateformes (Samsung One UI, Fluent…) ou sur-mesure	✅ Confirmé  la promesse la mieux tenue du découplage
Mise à jour et maintenance	Chaque design system évolue à son propre rythme, le core devient plus stable	✅ Confirmé
Vitesse de compilation	Potentiellement plus rapide, la compilation ne concernant que les dépendances choisies	🕐 Plausible, mais aucun chiffre de benchmark disponible à ce stade
Adoption par les développeurs débutants	Moins intuitive, configuration de son propre design system requise	🕐 Vrai sur le papier  à confirmer par le retour de la communauté dans les prochains mois
Interopérabilité multiplateforme	Plus neutre et ouverte, chaque marque peut avoir son propre design	✅ Confirmé, c'est la direction assumée par Flutter

Besoin d'accompagnement pour migrer votre application vers Flutter 3.47, ou pour trancher entre Material/Cupertino et un design system sur-mesure ? Parlez-en à nos experts Flutter.

---

Ce qu'il faut retenir

• Flutter 3.47 sort Material et Cupertino du cœur du framework : ce sont désormais deux packages pub.dev autonomes, material_ui et cupertino_ui.
• Ce découplage répond à une demande de la communauté Flutter datant de 2022 : une décision structurante, pas un simple nettoyage de code.
• Les éditeurs ont désormais un vrai choix : 100 % Material, 100 % Cupertino, un mix des deux, ou un design system entièrement sur-mesure.
• Le sur-mesure convient aux marques dotées d'un design system mature et d'un budget conséquent (design, dev, maintenance, tokens d'IA), beaucoup moins pour les autres.
• Toutefois, l'IA peut aider à générer une base de composants à condition d’avoir un design system propre.
• Le test reste obligatoire sur toutes les configurations d'écran, y compris pliables, un enjeu renforcé par l'arrivée de l'iPhone Duo.
• La migration vers les nouveaux packages est automatisée et progressive : aucune urgence à tout basculer d'un coup.

Questions fréquentes sur le découplage Material et Cupertino dans Flutter

Qu'est-ce que le découplage de Material et Cupertino dans Flutter ? Depuis Flutter 3.47, Material et Cupertino ne font plus partie du SDK principal : ce sont deux packages indépendants, material_ui et cupertino_ui, publiés sur pub.dev et importés explicitement par le projet.

Pourquoi Flutter a-t-il découplé Material et Cupertino du framework ? Pour répondre à une demande de la communauté qui remonte au lancement de Flutter en 2018 et s'est concrétisée en 2022 via une discussion GitHub, accélérée par la menace d'un fork du framework. L'objectif : des mises à jour Flutter plus simples, une innovation UI plus rapide, et la possibilité pour chaque marque de créer son propre design system.

Faut-il migrer immédiatement vers material_ui et cupertino_ui ? Non. Flutter maintient une période de coexistence entre l'ancien et le nouveau système d'import, comparable à la transition Material 2 → Material 3, qui avait duré deux ans. Une commande automatisée gère la migration quand vous êtes prêt.

Faut-il un design system abouti pour générer des composants Flutter de A à Z, sans Cupertino ni Material, avec l'IA ? Oui. Sans design system documenté et exhaustif, un modèle d'IA peut inventer des composants qui n'existent pas dans votre charte, ce qui dilue l'identité de marque. Avec un design system propre et exhaustif, en revanche, l'IA génère une base de composants fonctionnelle en quelques minutes, à condition de toujours tester le résultat.

Flutter gère-t-il les écrans pliables comme l'iPhone Duo ? Oui. Le support des écrans pliables et double-écrans est stable dans Flutter depuis 2022, via l'API MediaQuery Display Features mais il ne prend pour l’instant en charge que les téléphones de Samsung et Google. Le simulateur de l’iPhone Duo n’est disponible qu’en beta. Il existe toutefois des packages alternatifs créés par des développeurs et disponibles sur pub.dev. Cela reste un point de vigilance supplémentaire pour tout composant généré par IA, qui doit être testé sur toutes les postures d'écran, pas seulement sur un affichage classique.

Faut-il choisir le sur-mesure ou garder Material et Cupertino ? Cela dépend de la maturité du design system du client. Avec un design system riche et une volonté d'indépendance visuelle vis-à-vis d'Apple et de Google, le sur-mesure se justifie. Sans design system mûr, conserver Material et Cupertino via les packages externes reste le choix le plus fiable et le plus économique.