Tout le monde nous a dit d’utiliser Electron. Écrire une fois, tourner partout. Aller vite. Nous avons fait l’inverse — SwiftUI chez Apple, Jetpack Compose sur Android, C++/WinRT sous Windows, Metal et Vulkan à l’état brut là où il fallait des pixels à l’heure. Voici ce que nous avons appris en construisant quatre clients natifs pour un seul produit.
La voie facile contre la bonne voie
Quand vous dites que vous construisez une application de bureau à distance de zéro en 2024, la première question est toujours : « Pourquoi ne pas simplement utiliser Electron ? »
C’est une question légitime. Electron fait tourner certaines des apps les plus réussies de la planète — VS Code, Slack, Discord, l’enveloppe de bureau de Figma. Il permet d’écrire une fois et de déployer partout. Vos développeurs web deviennent développeurs de bureau du jour au lendemain. L’avantage en délai de mise sur le marché est réel.
Nous avons regardé les chiffres, pesé les compromis, et choisi la voie la plus difficile possible : entièrement natif sur chaque plateforme. SwiftUI sur iOS et macOS. Jetpack Compose sur Android. C++/WinRT sous Windows. Metal pour le rendu chez Apple. Vulkan partout ailleurs. Un serveur Go sur mesure au cœur.
Pas parce que nous aimons souffrir, même si certains jours on en a l’impression. Mais parce que, pour ce genre d’app, le natif n’est pas un luxe. C’est une exigence.
La taxe Electron est bien réelle
Commençons par ce qu’est réellement Electron : une fenêtre de navigateur Chromium qui fait semblant d’être une app de bureau. Ce n’est pas une critique — c’est de l’architecture. Et pour de nombreuses applications, c’est tout à fait acceptable.
Mais pour un bureau à distance ? Vous diffusez des pixels depuis un autre ordinateur et vous les affichez en temps réel tout en capturant chaque événement de saisie pour le renvoyer. La latence n’est pas un luxe. C’est tout le produit.
Voici ce que nous avons mesuré en prototypant les deux approches :
- Mémoire — Client natif en régime établi : ~45 MB. Prototype Electron : ~380 MB. Un écart de 8,4× au repos, avant même que l’une ou l’autre app commence à décoder une seule image.
- Démarrage à froid — L’app macOS native démarre à froid en moins de 200 ms. Le prototype Electron a pris de 2 à 3 secondes. Pour un outil que vous lancez vingt fois par jour, cela s’accumule en vraie friction.
- Batterie — Sur un Mac sur batterie, la version Electron tirait environ 3× la puissance pendant une connexion au repos. Chromium ne dort pas à bas prix.
Les 380 MB ne viennent pas d’un Electron boursouflé. C’est Chromium qui fait son travail — V8, un processus GPU, des processus utilitaires, un moteur de navigateur entier. C’est de l’ingénierie impressionnante. C’est simplement de l’ingénierie conçue pour un autre problème.
Les images comptent plus que les fonctionnalités
Le bureau à distance est l’une des rares catégories d’apps où chaque image compte. Perdez une image et l’utilisateur le sent. Ajoutez 16 ms de latence de saisie et un designer ne peut plus tracer des courbes fluides. Ajoutez 32 ms et un joueur ne peut plus jouer.
Avec le rendu natif, nous parlons directement au GPU. Sur les plateformes Apple, VideoToolbox nous donne un accès direct au décodage vidéo matériel. Nous prenons une image H.265 sur le réseau, la décodons par le matériel et l’affichons — sans que l’image ne touche jamais la mémoire principale. La chaîne du décodage à l’affichage tourne en moins de 4 ms sur un Mac récent.
Dans Electron, cette même image passe par le compositeur de Chromium, par le pont IPC, est peinte par Skia, puis recomposée par le système. Chaque saut ajoute de la latence. Chaque saut ajoute de la gigue. Et la gigue — une cadence d’images irrégulière — est ce qui fait que le bureau à distance paraît bancal, même quand les FPS moyens semblent corrects.
Nous n’avons pas choisi le natif par purisme. Nous l’avons choisi parce que la physique de notre problème l’exigeait — environ 8 ms de traitement sur le réseau local (le reste correspond à la cadence de rafraîchissement 60 Hz propre à votre écran), cela ne laisse aucune place à un navigateur au milieu.
Registre des capacités : natif contre web
Le débat Electron contre natif reste souvent coincé dans les impressions. Nous avons donc noté les sept capacités du système dont Remio dépend à chaque seconde de chaque session et demandé, simplement : comment chacune se comporte-t-elle sous chaque environnement d’exécution ?
| Capacité | Natif | Web / Electron |
|---|---|---|
| Décodage matériel 60 fps | ● VideoToolbox / D3D11VA direct | ○ Via WebCodecs, gigue |
| Audio USB à faible latence | ● CoreAudio / WASAPI | — En bac à sable, 40 ms+ |
| Surveillance de la saisie clavier | ● CGEvent / SendInput | — Bloquée hors du focus |
| Accès GPU Metal / D3D11 | ● Textures sans copie | ○ WebGPU, sauts de copie |
| Système de fichiers local | ● Complet, cadré par le système | ○ Sélecteur seul, invites |
| Multifenêtre, multi-écran | ● Fenêtrage natif du système | ○ Cales BrowserWindow |
| Persistance en arrière-plan | ● LaunchAgent / service | — Suspendue quand masquée |
Chaque ligne est une fonctionnalité que nous livrons aujourd’hui. Chaque — dans la colonne web est un contournement qu’il nous faudrait inventer, documenter et pour lequel il faudrait s’excuser. Passer au natif, c’est traiter ces capacités comme des primitives plutôt que comme des polyfills.
La citoyenneté de plateforme
Voici une chose dont parlent rarement les adeptes de l’écrire-une-fois-tourner-partout : les utilisateurs le voient.
Ils le voient quand une app ne respecte pas les transitions du mode sombre du système. Quand la physique du défilement semble légèrement fausse. Quand l’app n’apparaît pas dans Spotlight ou ne gère pas correctement la gestion des fenêtres de macOS. Quand le menu contextuel ressemble à une page web au lieu d’un menu natif.
Ce ne sont pas des détails accessoires. C’est la différence entre une app que l’on tolère et une app que l’on adore. Sur iOS, c’est particulièrement critique — la validation de l’App Store rejettera les apps qui ne semblent pas natives, et à raison.
Avec SwiftUI, nous obtenons tout cela gratuitement. Dynamic Type, accessibilité VoiceOver, retours haptiques du système, multitâche sur iPad, raccourcis clavier sur Mac. Nous ne réimplémentons pas les fonctions de la plateforme. Nous les utilisons.
Le coût est réel aussi
Soyons honnêtes sur l’inconvénient : passer au natif est coûteux. Pas en dollars — en temps et en complexité.
Nous maintenons quatre bases de code d’interface. Notre couche réseau et codec est partagée (Go pour la signalisation, C++ pour le protocole de streaming), mais chaque pixel que vous voyez à l’écran est du code propre à une plateforme. Une fonctionnalité qui prend un jour avec Electron nous prend de trois à cinq jours, parce que nous la construisons quatre fois, réglée pour chaque plateforme.
Il nous est arrivé de passer des semaines avec une animation qui fonctionnait à merveille sur iOS, était cassée sur Android et saccadait sous Windows. La matrice de débogage est brutale.
Mais voici ce que nous avons appris : la voie la plus difficile et la bonne voie sont souvent la même. Nos utilisateurs ne connaissent ni ne se soucient de notre architecture. Ils savent que Remio est rapide, que Remio est juste, et qu’il ne dévore pas leur batterie au petit-déjeuner.
Le referions-nous
Sans hésiter.
L’approche native nous a donné des performances qu’Electron ne peut fondamentalement pas égaler pour ce cas d’usage. Elle nous a donné des apps qui semblent à leur place sur chaque plateforme. Elle nous a donné une empreinte mémoire inférieure à 45 MB au lieu de 380 MB. Elle nous a donné environ 8 ms de traitement sur le réseau local (le reste correspond à la cadence de rafraîchissement 60 Hz propre à votre écran), là où un concurrent enveloppé dans un navigateur dépasse 60 ms.
Surtout, elle nous a donné un avantage technique difficile à franchir. Construire du natif sur quatre plateformes est assez dur pour que la plupart des concurrents ne le fassent pas. Cette difficulté est notre avantage.
La catégorie du bureau à distance a été dominée par des apps web enveloppées dans Electron et des apps natives héritées, pas réellement mises à jour depuis des années. Il y a de la place pour quelque chose à la fois moderne et natif — quelque chose construit de zéro en pensant au matériel d’aujourd’hui.
C’est Remio. Construit à la dure, parce que certaines choses valent la peine d’être bien faites.
