Tauri, Electron ou Flutter : comment choisir pour une app centrée sur le Web ?

Read this article in English

Vous construisez une application dont une grande partie de la valeur vient du Web : éditeur HTML, dashboard, outil collaboratif, client de messagerie, navigateur métier ou interface qui affiche des sites tiers. Faut-il garder votre frontend et l’emballer avec Tauri, distribuer Chromium avec Electron, ou reconstruire l’interface avec Flutter ?

Il n’existe pas de vainqueur universel. Ces trois technologies ne placent pas la frontière au même endroit :

• Tauri conserve une interface web et utilise le moteur WebView de chaque système ;
• Electron conserve une interface web et distribue Chromium avec Node.js ;
• Flutter fournit son propre modèle d’interface en Dart et s’intègre au Web ou aux vues natives lorsqu’il en a besoin.

Le bon choix dépend moins d’une comparaison de popularité que de cinq contraintes : ce que vous possédez déjà, les plateformes réellement nécessaires, le degré d’uniformité du moteur web, la profondeur des intégrations natives et l’équipe qui assurera les mises à jour pendant plusieurs années.

Commencez par définir « centrée sur le Web »

Deux applications peuvent être dites « web-first » tout en nécessitant des architectures opposées.

La première possède une interface React ou Vue et appelle une API. Ici, le Web décrit surtout la technologie de l’interface. La seconde affiche plusieurs sites distants, dépend de cookies, de stockage web, de téléchargements ou de fonctions proches d’un navigateur. Ici, le moteur web fait partie du produit.

Avant de choisir, écrivez ce qui doit rester web :

• l’interface de votre propre application ;
• le contenu produit par les utilisateurs ;
• des documents HTML contrôlés par votre équipe ;
• des sites tiers non contrôlés ;
• des extensions de navigateur ou des API Chromium ;
• une version web accessible sans installation.

Une app dont seule l’interface est web peut changer de moteur avec peu de conséquences. Une app qui orchestre des sites tiers doit traiter le moteur, les profils, les permissions et les mises à jour comme des décisions produit.

La matrice de décision

Cette matrice n’attribue pas des points. Elle indique quelle question chaque option rend plus simple — et quelle dette elle déplace.

Critère	Tauri	Electron	Flutter
Code existant	Bon candidat si vous avez déjà un frontend HTML/CSS/JS compatible avec une sortie statique	Bon candidat si votre produit et votre équipe sont déjà en JavaScript/TypeScript et visent le desktop	Bon candidat si vous avez déjà du Dart/Flutter ou acceptez de reconstruire l’interface
Besoin mobile	Couvre desktop et mobile, avec des adaptations et plugins propres aux plateformes	Cible le desktop ; prévoir une autre stratégie pour Android et iOS	Couvre mobile, desktop et web avec un modèle d’interface partagé
Moteur web uniforme	Non : WebView2, Android WebView et WebKit évoluent avec les plateformes	Oui sur les cibles desktop prises en charge : l’app distribue sa version de Chromium	Ce n’est pas son objectif principal : Flutter rend son UI ; les contenus web intégrés passent par des vues ou plugins de plateforme
Intégration native	Commandes Rust et plugins Swift/Kotlin ; expertise supplémentaire dès que l’app dépasse les plugins existants	API desktop dans le processus principal Node.js, plus modules natifs si nécessaire	Platform channels, FFI et plugins ; code natif possible sur chaque cible
Équipe et maintenance	Web + Rust, puis Swift/Kotlin selon les besoins ; tester les différences de WebView	Web + Node.js ; suivre les versions Electron/Chromium et sécuriser la frontière main/renderer	Dart/Flutter, plus compétences natives pour les intégrations ; maintenir l’UI hors du DOM web

Ne lisez pas « bon candidat » comme « meilleur ». Une base de code réutilisable peut faire gagner des mois, mais elle ne doit pas devenir une excuse pour conserver une architecture incapable de porter la fonction centrale du produit.

Quand Tauri est cohérent

Tauri est particulièrement intéressant quand votre frontend web existant représente un actif important et que vous souhaitez atteindre desktop et mobile sans distribuer un navigateur complet avec l’application.

Tauri accepte les frontends qui produisent du HTML, du CSS et du JavaScript. Il agit comme un hôte de fichiers statiques et relie le frontend au code natif. La documentation Tauri décrit cette architecture frontend agnostique, ainsi que les bindings JavaScript/Rust et Swift/Kotlin pour les plugins dans sa présentation du framework.

Le compromis est le moteur. Tauri ne fournit pas le même moteur partout : WebView2 est utilisé sous Windows, Android System WebView sur Android, et WebKit sur les plateformes Apple et Linux selon la cible. La version dépend donc du runtime disponible sur l’appareil. Tauri documente précisément cette matrice de WebViews.

Tauri convient souvent si :

• votre interface web est déjà mature ;
• la taille distribuée et le recours au moteur système comptent ;
• vous avez réellement besoin de desktop et de mobile ;
• vous pouvez tester les différences entre moteurs ;
• votre équipe accepte d’écrire du Rust ou des plugins natifs pour les besoins avancés.

Il est moins naturel si votre produit dépend d’un comportement Chromium identique sur chaque desktop, d’un vaste écosystème d’extensions Chromium, ou d’API de navigateur que les WebViews système n’exposent pas uniformément.

Quand Electron est cohérent

Electron est souvent la voie la plus directe pour une application desktop web ambitieuse. Il intègre Chromium et Node.js dans le binaire et cible Windows, macOS et Linux. La présentation officielle d’Electron résume ce modèle.

Cette décision apporte un moteur de rendu connu avec la version d’Electron distribuée. Vous choisissez quand mettre à jour l’application et pouvez tester le produit contre cette version de Chromium avant diffusion. Cela simplifie les applications qui dépendent de fonctions web récentes ou d’un rendu très cohérent entre leurs cibles desktop.

En échange, votre équipe devient responsable du suivi du cycle Electron. Le projet prend en charge les trois dernières versions majeures stables et cadence ses versions de Chromium avec ses propres releases ; rester trop longtemps sur une branche ancienne réduit donc la fenêtre de correctifs reçus. La politique de support officielle détaille ce rythme.

L’architecture demande aussi une frontière explicite entre le processus principal, qui possède les capacités Node.js et système, et les renderers qui affichent l’interface. Le modèle multi-processus d’Electron explique pourquoi les API privilégiées ne doivent pas être exposées sans contrôle au contenu rendu.

Electron convient souvent si :

• le desktop est votre produit principal ;
• votre équipe maîtrise JavaScript/TypeScript et Node.js ;
• un moteur Chromium uniforme est une exigence, pas seulement un confort ;
• vous avez les moyens de maintenir un rythme de mises à jour régulier ;
• la stratégie mobile peut être séparée ou n’existe pas.

Le fait qu’Electron distribue Chromium ne garantit ni de bonnes performances ni une application sécurisée. L’architecture des fenêtres, l’isolation des contenus, les permissions, les mises à jour et la qualité du code restent votre responsabilité.

Quand Flutter est cohérent

Flutter part d’une autre hypothèse : l’interface n’est pas un DOM web conservé dans un shell. Elle est écrite en Dart avec le système de widgets Flutter, puis rendue par le moteur Flutter sur mobile et desktop. Le framework vise la réutilisation entre Android, iOS, le Web et les plateformes desktop, tout en permettant l’appel de code natif. L’aperçu architectural officiel décrit ces couches.

Cela peut être un excellent choix quand la valeur principale se trouve dans une interface applicative très maîtrisée, animée et cohérente, et que mobile compte autant que desktop. Une équipe déjà compétente en Flutter peut partager beaucoup de logique et d’UI sans faire du navigateur le centre de son architecture.

Mais si vous possédez une grande application Vue ou React, Flutter ne la réutilise pas comme interface native : il faut la réécrire en Dart ou maintenir deux surfaces. Et si le produit doit afficher des WebViews, Flutter doit les intégrer comme vues de plateforme ou via des plugins. La documentation officielle note que ces vues ont leurs propres compromis de composition, et que les platform views ne sont actuellement pas disponibles de la même façon sur toutes les cibles desktop. Voir la section dédiée aux contrôles natifs et les modes Android.

Flutter convient souvent si :

• vous démarrez l’interface de zéro ou avez déjà un socle Dart ;
• mobile est prioritaire et desktop/web doivent partager le même langage produit ;
• votre interface propre compte davantage que l’intégration profonde de contenus web tiers ;
• vous acceptez d’intégrer les WebViews et fonctions système comme capacités natives distinctes ;
• l’équipe veut investir durablement dans Flutter plutôt que préserver une stack DOM existante.

Flutter ne devient pas un mauvais choix dès qu’une WebView apparaît. Le signal d’alerte arrive lorsque la majorité du produit est un navigateur spécialisé : l’UI Flutter risque alors d’entourer une collection de vues natives dont les contraintes dominent malgré tout.

L’exemple CommunityGlows

CommunityGlows avait déjà une interface Vue et une extension Chrome/Firefox. Le produit devait ensuite fournir un workspace desktop multi-panneaux et une application Android, avec des profils associés à des sessions de réseaux sociaux.

Tauri a préservé le socle Vue et permis d’ajouter une orchestration native en Rust et Kotlin. Mais ce choix n’a pas supprimé le travail de plateforme : le desktop utilise des espaces de données WebView par couple profil/réseau, tandis qu’Android possède un mode natif multi-profile et un fallback plus limité. L’extension, elle, ouvre des onglets et conserve le modèle de session du navigateur.

Electron aurait offert un moteur Chromium plus uniforme pour le cockpit desktop, mais pas une architecture mobile commune. Flutter aurait offert une forte base mobile, mais demandé une nouvelle interface Dart tout en conservant le besoin de WebViews natives pour les réseaux.

Ce cas ne prouve pas que Tauri est supérieur. Il montre comment la valeur du code existant et l’obligation mobile peuvent peser davantage que l’uniformité du moteur desktop. Nous détaillons cette décision dans Pourquoi CommunityGlows utilise Tauri plutôt qu’un fork de Chromium.

Un fork Chromium est une quatrième décision

Un fork de Chromium n’est pas « Electron avec plus de contrôle ». Electron fournit un framework applicatif et suit Chromium pour vous. Forker Chromium signifie maintenir votre propre dérivé du navigateur : code source, chaîne de build, intégration amont, tests, correctifs et distribution.

Les instructions officielles de compilation de Chromium donnent une idée de la surface technique. Ses principes fondamentaux insistent sur les mises à jour, les tests, la sandbox et la défense en profondeur : des responsabilités continues pour tout éditeur qui distribue un navigateur.

Ce choix peut devenir rationnel si le navigateur lui-même est le produit et si des modifications profondes de profils, d’onglets, de politiques ou du moteur sont indispensables. Il est disproportionné si vous cherchez seulement une fenêtre desktop pour votre application web.

Une méthode de décision en six questions

Avant le prototype, répondez dans cet ordre :

1. Quelles plateformes génèrent réellement de la valeur dans les deux prochaines années ? Évitez de payer maintenant pour une cible hypothétique.
2. Quelle part du code existant mérite d’être conservée ? Mesurez l’UI, les tests, l’accessibilité et les compétences, pas seulement le nombre de lignes.
3. Le moteur web est-il un détail d’implémentation ou une dépendance produit ? Listez les API, sites tiers et extensions réellement indispensables.
4. Quelle variation entre moteurs pouvez-vous accepter ? Testez les parcours critiques sous WebView2, WebKit et Android WebView si Tauri reste candidat.
5. Qui possède la couche native et les mises à jour ? Nommez les compétences et le temps réservés, au lieu d’inscrire « plugin » dans une case.
6. Quel risque devez-vous prouver par un prototype ? Choisissez le parcours le plus difficile : multi-WebView, téléchargement, partage mobile, authentification, accessibilité ou mise à jour.

Le prototype utile n’est pas trois applications « Hello World ». Il doit exercer la fonction qui pourrait invalider votre choix.

Le choix le plus durable est celui dont vous acceptez la maintenance

Choisissez Tauri si préserver un frontend web, couvrir desktop et mobile, et accepter les moteurs système forme un compromis cohérent. Choisissez Electron si le desktop et l’uniformité Chromium justifient un runtime embarqué et son rythme de mises à jour. Choisissez Flutter si vous voulez construire une interface multiplateforme en Dart et que le Web intégré reste une capacité, pas le centre incontrôlé du produit.

Puis documentez ce que vous n’avez pas choisi. Une bonne décision d’architecture n’affirme pas qu’une technologie est meilleure partout. Elle explique quelles contraintes elle satisfait, quelles responsabilités elle crée et quel signal déclenchera sa réévaluation.