Flutter est encore principalement associé aux applications mobiles iOS et Android. Son architecture lui permet pourtant d’aller bien au-delà de ces plateformes.

Sur un système Linux embarqué, il peut fonctionner sans Android, sans environnement de bureau complet et même sans serveur d’affichage traditionnel. Le framework devient alors une solution intéressante pour développer des interfaces graphiques modernes sur des équipements spécialisés.

Qt/QML conserve une avance importante dans ce domaine. Son écosystème, son outillage et ses solutions dédiées à la sûreté de fonctionnement sont le fruit de plusieurs décennies d’expérience.

Mais Flutter commence clairement à arriver sur son terrain.

1. Comment Flutter fonctionne-t-il sur un système embarqué ?

L’architecture de Flutter sépare plusieurs couches :

• le framework écrit en Dart ;
• le moteur de rendu Flutter ;
• l’embedder chargé de l’intégration avec la plateforme cible.

Sur Android, iOS, Windows, macOS ou Linux Desktop, cet embedder est fourni par le projet Flutter.

Pour une cible embarquée spécifique, il est possible d’utiliser un custom embedder basé sur l’API d’intégration du moteur. Celui-ci initialise le moteur Flutter et assure la liaison avec le système : affichage, entrées tactiles, clavier, cycle de vie, gestion des fenêtres et services natifs.

La documentation officielle de Flutter présente cette API comme le point d’entrée pour intégrer Flutter à une plateforme non prise en charge nativement.

Sur une distribution Linux construite avec Yocto ou Buildroot, le rendu peut ensuite suivre deux architectures principales.

Accès direct à l’affichage

L’embedder peut communiquer directement avec la pile graphique Linux en utilisant notamment :

• DRM/KMS pour contrôler l’affichage ;
• GBM pour gérer les buffers graphiques ;
• EGL et OpenGL ES pour créer le contexte de rendu accéléré par GPU.

Cette approche évite d’embarquer un environnement graphique complet. Elle convient particulièrement aux équipements dédiés qui n’exécutent qu’une seule interface plein écran.

Intégration avec Wayland

Flutter peut également fonctionner comme un client Wayland, avec un compositeur comme Weston.

Cette architecture est plus adaptée lorsque plusieurs applications, surfaces ou processus graphiques doivent partager le même affichage.

Dans les deux cas, le système peut rester relativement léger tout en conservant une interface fluide et accélérée par GPU. Le résultat dépend évidemment du SoC, de ses pilotes graphiques et de la qualité de l’embedder. L’embarqué reste de l’embarqué : tôt ou tard, un pilote décide de rappeler qui commande réellement la machine.

2. Les principaux projets Flutter Embedded

Plusieurs projets open source structurent aujourd’hui cet écosystème.

flutter-pi

flutter-pi est probablement le projet le plus accessible pour expérimenter Flutter sur Raspberry Pi.

Il permet d’exécuter une application Flutter sans X11 ni environnement de bureau, directement depuis une console Linux. Son intégration repose notamment sur DRM, GBM, EGL et les périphériques d’entrée Linux.

C’est une excellente porte d’entrée pour construire un prototype, une borne tactile ou un écran de contrôle à partir d’un Raspberry Pi.

Toyota ivi-homescreen

ivi-homescreen, développé par Toyota Connected, est un runtime Flutter destiné à Linux embarqué et basé sur Wayland.

Le projet est principalement orienté vers les systèmes d’infodivertissement automobile. Il fournit un environnement d’exécution capable de charger une application Flutter compilée avec son moteur et ses assets.

Toyota démontre ainsi que Flutter peut être utilisé au-delà du prototypage, dans des architectures automobiles où l’interface graphique constitue un produit à part entière.

Sony flutter-embedded-linux

Sony développe flutter-embedded-linux, un embedder optimisé pour les systèmes Linux embarqués.

Le projet cherche à limiter les dépendances par rapport à l’embedder Linux Desktop traditionnel et prend en charge plusieurs backends d’affichage, dont Wayland et DRM.

Sony fournit également le SDK flutter-elinux, qui adapte les commandes habituelles de Flutter pour créer, compiler et exécuter des applications destinées à ces plateformes.

meta-flutter

meta-flutter fournit les couches et recettes BitBake nécessaires à l’intégration du moteur Flutter, des embedders et des applications dans une image Yocto.

Ce projet facilite la reproductibilité du build et l’intégration de Flutter dans une chaîne de fabrication Linux embarquée. Un point essentiel dès que le prototype quitte le Raspberry Pi posé sur un bureau pour devenir un produit réellement maintenu.

3. Pour quels usages ?

Flutter Embedded peut être envisagé pour de nombreux équipements disposant d’un écran :

• systèmes d’infodivertissement automobile ;
• tableaux de bord et panneaux de contrôle industriels ;
• bornes tactiles et terminaux spécialisés ;
• systèmes domotiques ;
• équipements médicaux non critiques ou interfaces séparées des fonctions critiques ;
• électroménager et objets connectés ;
• interfaces de diagnostic, de supervision ou de maintenance.

Le choix reste fortement dépendant du niveau de criticité du produit, de la durée de maintenance attendue et des contraintes de certification.

Flutter peut parfaitement afficher une interface sur un équipement médical ou industriel. Cela ne signifie pas pour autant que le framework, l’embedder ou l’ensemble du système dispose des certifications nécessaires à une fonction critique. Cette distinction, peu spectaculaire mais assez utile lorsqu’on souhaite éviter les réunions avec des juristes, doit être intégrée dès la conception.

4. Quels avantages par rapport à une solution traditionnelle ?

Flutter apporte plusieurs caractéristiques intéressantes pour une équipe produit.

Une interface cohérente entre plusieurs plateformes

Le moteur de rendu de Flutter contrôle directement l’affichage des composants. Une même base d’interface peut donc être partagée entre une application mobile, un écran embarqué et éventuellement une application desktop.

Cela permet aussi de mutualiser un Design System, certains composants et une partie de la logique de présentation.

Un développement rapide

En mode debug, le Hot Reload reste disponible lorsque l’embedder expose correctement le service de développement Flutter.

Les équipes conservent ainsi une boucle de travail proche de celle utilisée sur mobile : modification du code, injection dans l’application en cours d’exécution et validation immédiate sur la cible.

Une compilation AOT pour la production

En release, le code Dart est compilé en avance de phase pour l’architecture cible. L’application n’a donc pas besoin d’interpréter le code métier au démarrage.

Cette approche est adaptée aux équipements où les performances et la prédictibilité du lancement sont importantes.

Un écosystème connu des équipes mobiles

Pour une entreprise qui utilise déjà Flutter sur mobile, l’embarqué permet de capitaliser sur les mêmes compétences, le même langage et une partie du même outillage.

Le gain potentiel ne vient pas uniquement du partage de code. Il vient aussi de la réduction du nombre de technologies à maîtriser et de la capacité à faire travailler les mêmes équipes sur plusieurs surfaces numériques.

5. Flutter ne remplace pas encore Qt/QML

Qt bénéficie d’une maturité considérable dans l’industrie et propose une chaîne complète dédiée aux systèmes embarqués.

Boot to Qt fournit par exemple une pile Linux basée sur Yocto, des outils de déploiement et une intégration étroite avec Qt Creator.

Qt dispose également de composants spécialisés comme Qt Safe Renderer, conçu pour isoler et afficher des informations critiques dans des systèmes soumis à des exigences de sûreté de fonctionnement.

Flutter ne propose pas aujourd’hui un équivalent direct à cet ensemble. Son support embarqué dépend encore largement de projets communautaires ou industriels externes au SDK principal.

Il faut également vérifier, pour chaque cible :

• la disponibilité d’un moteur compatible avec l’architecture du processeur ;
• la stabilité des pilotes GPU ;
• la prise en charge des entrées et périphériques spécifiques ;
• la compatibilité des plugins Flutter ;
• la stratégie de mise à jour et de maintenance à long terme ;
• les contraintes de démarrage, de mémoire et de stockage ;
• les éventuelles exigences de certification.

Le choix entre Flutter et Qt/QML ne peut donc pas être résumé à une comparaison de performances ou à une préférence de langage.

Il s’agit d’un choix d’architecture produit.

Conclusion

Flutter n’est plus limité au mobile. Grâce à son moteur portable, à l’API Custom Embedder et aux travaux menés par des acteurs comme Toyota, Sony et la communauté open source, il peut désormais cibler efficacement plusieurs catégories de systèmes Linux embarqués.

Qt/QML reste la référence la plus mature pour les environnements industriels exigeants, particulièrement lorsque les certifications, le support fournisseur et la maintenance sur plusieurs décennies sont déterminants.

Mais pour des interfaces modernes, non critiques, connectées à un produit mobile ou conçues par une équipe qui maîtrise déjà Flutter, l’option mérite clairement d’être étudiée.

Flutter ne domine pas encore le marché de l’embarqué.

Il vient toutefois d’y poser un pied. Et connaissant l’industrie logicielle, quelqu’un finira inévitablement par essayer d’y faire tenir toute la jambe.

Vous souhaitez concevoir une interface Flutter embarquée, valider sa faisabilité sur votre matériel ou définir une architecture Linux adaptée à votre produit ? N’hésitez pas à nous contacter et parlons-en ensemble. 😊