Passez suffisamment de temps sur Hacker News ou Reddit et vous finirez par tomber sur la même critique : Electron est lourd, Electron consomme trop de mémoire, et les applications de bureau sérieuses devraient être natives.
Cette critique contient une part de vérité. Les applications Electron ont généralement une empreinte de base plus importante, car elles embarquent Chromium et Node.js. Une application native soigneusement conçue peut consommer moins de mémoire, démarrer plus vite et s’intégrer plus profondément à son système d’exploitation.
Mais ce débat se concentre trop sur l’ordinateur et pas assez sur l’entreprise qui développe le logiciel.
Pour la plupart des utilisateurs, la technologie derrière une application compte à peine. Ce qui les intéresse, c’est de savoir si elle fonctionne, si elle est réactive, si les bugs sont corrigés et si des fonctionnalités utiles continuent d’apparaître. Pour un éditeur de logiciels, l’une des propriétés les plus importantes d’une pile technologique est donc quelque chose qui figure rarement dans les tableaux de performances : à quelle vitesse l’équipe peut-elle développer, livrer, apprendre et améliorer le produit ?
Pour de nombreuses applications de bureau modernes, Electron excelle dans ce domaine.
La ressource rare, c’est le temps des ingénieurs
Dans une vision idéalisée, une entreprise qui développe des applications de bureau natives dispose d’une excellente équipe macOS, d’une autre équipe chargée de l’application Windows, et peut-être d’une troisième pour Linux. Chaque application est soigneusement optimisée pour sa plateforme, et chaque ingénieur connaît en profondeur le système d’exploitation sur lequel il travaille.
La plupart des entreprises n’ont pas ce luxe.
Un produit de bureau peut mobiliser cinq ingénieurs. Ou seulement deux. Ces mêmes ingénieurs doivent développer des fonctionnalités, corriger les bugs, améliorer les performances, répondre aux clients, maintenir l’infrastructure, gérer les évolutions des systèmes d’exploitation et continuer à faire avancer le produit.
Le développement natif complique cette tâche, car macOS, Windows et Linux sont réellement des plateformes différentes. Elles ont des frameworks d’interface, des API, des systèmes de permissions, des comportements de cycle de vie, des programmes d’installation, des mécanismes de mise à jour, des systèmes de notifications, des modes de gestion des fenêtres et des API d’accessibilité différents, ainsi que des années de particularités propres à chaque plateforme.
Electron change la donne. Il combine Chromium, Node.js et des API de bureau dans un modèle d’application commun à macOS, Windows et Linux. Un même ingénieur TypeScript peut souvent développer une fonctionnalité de bout en bout, de l’interface à la logique applicative, et la livrer sur toutes les plateformes de bureau. Le code natif reste disponible lorsqu’il est réellement nécessaire, mais il devient l’exception plutôt que le socle du produit. Electron présente lui-même cet aspect comme l’un de ses principaux avantages : une seule base de code JavaScript pour les trois grandes plateformes de bureau.
L’effet de cette différence s’amplifie au fil des années. Si chaque fonctionnalité importante nécessite des implémentations distinctes pour Mac et Windows, l’entreprise paie sans cesse ce surcoût lié aux plateformes : pour chaque fonctionnalité, refonte, expérimentation, correction de bug, amélioration de l’accessibilité et optimisation des performances.
Avec Electron, une grande partie de ce travail n’est effectuée qu’une seule fois.
Electron privilégie la rapidité d’itération
Les produits deviennent rarement excellents parce que leur première implémentation était parfaite. Ils le deviennent par itérations successives.
Une équipe livre quelque chose. Les clients l’utilisent. L’équipe en tire des enseignements. Elle modifie la fonctionnalité. Davantage de personnes l’utilisent. Un autre problème apparaît. L’équipe l’améliore à nouveau.
Plus la boucle entre l’idée, l’implémentation, les retours et l’amélioration est courte, plus le produit progresse vite.
Electron est particulièrement efficace pour raccourcir cette boucle, car il repose sur des technologies que les éditeurs de logiciels utilisent déjà partout : JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js et npm.
Cela signifie que les entreprises peuvent mutualiser bien plus que le code source. Elles peuvent partager les ingénieurs, les composants d’interface, les outils, les bibliothèques, l’infrastructure, les méthodes de test et les connaissances internes entre leurs produits web et de bureau.
Un ingénieur frontend ne devient pas soudainement inutile parce que l’entreprise a besoin d’aide sur le client Windows. Un ingénieur spécialisé dans les applications de bureau peut contribuer à l’application web. Un ingénieur full-stack TypeScript peut passer d’un produit à l’autre au gré des priorités.
Pour une petite ou moyenne entreprise, cette souplesse peut valoir bien plus que l’économie de 100 Mo de RAM.
Regardez qui utilise réellement Electron
Electron est parfois présenté comme un raccourci pour les entreprises qui ne veulent pas investir dans une « véritable » application de bureau. Les produits développés avec lui rendent cet argument de plus en plus difficile à défendre.
Le projet Electron lui-même met en avant des produits comme Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom et Canva. Ce ne sont pas de simples utilitaires. Beaucoup comptent parmi les applications de productivité les plus sophistiquées et les plus utilisées au monde.
Visual Studio Code est un exemple particulièrement intéressant. Microsoft pourrait développer son éditeur de code phare avec pratiquement n’importe quelle technologie Windows de son choix, et pourtant VS Code utilise Electron sur Windows, macOS et Linux. Il intègre des terminaux, le débogage, des serveurs de langage, l’intégration de Git, le développement à distance, des notebooks, des extensions et des éditeurs hautement personnalisés.
La question intéressante n’est pas de savoir si Microsoft pourrait économiser de la mémoire en développant trois versions natives distinctes. Bien sûr que oui.
La vraie question est de savoir si VS Code aurait évolué aussi rapidement, serait resté aussi cohérent d’une plateforme à l’autre et aurait développé un écosystème aussi vaste si chaque fonctionnalité majeure avait nécessité plusieurs implémentations distinctes.
ChatGPT et Claude illustrent la différence d’approche
Le contraste entre ChatGPT et Claude est également instructif.
OpenAI a d’abord développé une application macOS native dédiée à ChatGPT. Anthropic, en revanche, a construit Claude Desktop avec Electron et disposait dès le départ d’un socle de bureau commun aux différentes plateformes.
Cette différence a pris davantage d’importance à mesure que les produits se sont enrichis. Claude Desktop pouvait continuer à intégrer des fonctionnalités telles que les intégrations MCP, les extensions et Claude Code dans la même application multiplateforme. Anthropic prend désormais en charge Claude Code directement dans son environnement de bureau, notamment avec plusieurs sessions locales et distantes.
OpenAI a ensuite orienté sa nouvelle stratégie de bureau multiplateforme vers Electron également, et Electron cite désormais ChatGPT et Claude parmi les applications Electron de premier plan.
Il serait excessif d’affirmer qu’Electron explique à lui seul la différence de rythme d’évolution des produits. La taille des équipes, les priorités, la stratégie produit et l’organisation interne comptent toutes. Mais l’avantage architectural est simple : un socle multiplateforme commun facilite la livraison de fonctionnalités sur différents systèmes d’exploitation sans avoir à maintenir des implémentations distinctes.
C’est précisément le type d’avantage qui prend de la valeur à mesure qu’un produit de bureau se développe.
Evernote a appris ce que coûte la maintenance de clients distincts
Evernote est l’un des exemples historiques les plus clairs de ce problème.
Pendant des années, Evernote a maintenu des applications différentes pour Mac, Windows, les appareils mobiles et le web. Au fil du temps, ces produits ont accumulé des différences de comportement et de rendu, des présupposés hérités du passé et des problèmes de synchronisation.
En 2020, Evernote a reconstruit ses applications Windows et Mac autour d’une base de code commune. L’entreprise a déclaré que ce nouveau socle rendrait les applications plus stables, permettrait de corriger les bugs plus rapidement, de livrer des fonctionnalités plus fréquemment et d’améliorer la synchronisation entre les plateformes.
Cette migration ne s’est pas faite sans heurts, et certains utilisateurs de longue date ont mal vécu la disparition initiale de fonctionnalités propres à chaque plateforme. Mais la raison pour laquelle Evernote a entrepris une réécriture aussi coûteuse est plus intéressante que les problèmes de migration eux-mêmes.
Dès qu’un produit comprend un éditeur riche, du stockage hors ligne, de la recherche, des pièces jointes, de la collaboration, des tâches, des calendriers et une synchronisation complexe, maintenir plusieurs implémentations indépendantes devient de plus en plus coûteux. Les bugs se manifestent différemment. Le rendu varie. La logique de synchronisation interagit avec des architectures locales différentes. Chaque modification importante du produit doit être répercutée dans plusieurs clients.
Une architecture commune ne fait pas disparaître les problèmes difficiles. Elle permet à l’entreprise d’en résoudre davantage une seule fois.
Linux est peut-être l’avantage le plus sous-estimé d’Electron
Linux renforce encore les arguments en faveur d’Electron.
Prendre correctement en charge Linux est difficile. Contrairement à macOS ou Windows, le « bureau Linux » n’est pas une plateforme unique étroitement contrôlée. Les développeurs doivent composer avec différentes distributions, différents formats de paquets, environnements de bureau, piles graphiques, bibliothèques système et protocoles d’affichage.
Pour de nombreux éditeurs de logiciels, la décision commerciale rationnelle serait tout simplement de ne pas prendre en charge Linux.
Electron change l’équation économique.
Comme Electron fournit un environnement d’exécution commun à macOS, Windows et Linux, ajouter la prise en charge de Linux peut être considérablement plus simple que maintenir une implémentation Linux native distincte. C’est l’une des raisons pour lesquelles les utilisateurs de Linux ont aujourd’hui accès à de nombreuses grandes applications de bureau qui, autrefois, n’auraient peut-être jamais bénéficié d’un client Linux officiel.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian et bien d’autres outils peuvent prendre en charge Linux sans maintenir une application GTK ou Qt entièrement distincte.
Electron prend aussi en charge une grande partie de la complexité propre à Linux pour le compte des développeurs d’applications. Le passage de X11 à Wayland en est un bon exemple. Les responsables de la maintenance d’Electron ont expliqué comment la transition de Chromium vers Wayland avait, de fait, entraîné les applications Electron dans son sillage, réduisant la quantité de travail sur la pile d’affichage que chaque équipe applicative devait accomplir séparément.
Sans des frameworks comme Electron, de nombreuses entreprises ne développeraient pas de clients Linux natifs. Elles se contenteraient de prendre en charge macOS et Windows, laissant aux utilisateurs de Linux un simple onglet de navigateur.
Electron a probablement fait davantage pour les logiciels commerciaux de bureau sous Linux qu’on ne le reconnaît.
Même Microsoft choisit de plus en plus les technologies web
Microsoft est peut-être le meilleur contre-exemple à l’idée selon laquelle les logiciels Windows sérieux devraient toujours utiliser des frameworks d’interface natifs pour Windows.
Microsoft contrôle Windows. L’entreprise contrôle Win32, .NET, WinUI, WebView2 et une grande partie de la plateforme sur laquelle les développeurs s’appuient. Si le développement Windows entièrement natif était toujours la réponse évidente, Microsoft serait idéalement placé pour l’utiliser partout.
Ce n’est pas ce qu’il fait.
Visual Studio Code utilise Electron. Teams reste construit autour de React, TypeScript et Chromium, même après le remplacement d’Electron par un hôte WebView2 plus optimisé. Le nouvel Outlook pour Windows repose lui aussi largement sur les technologies web, et Microsoft présente explicitement cette architecture comme un moyen d’accroître l’agilité, d’accélérer la livraison des fonctionnalités et de créer une expérience plus cohérente.
Le cas de Teams est particulièrement instructif. Microsoft voulait améliorer les performances et réduire la consommation de ressources ; il a donc modifié l’architecture. Mais il n’a pas réécrit l’interface sous la forme d’une application Windows native traditionnelle.
Il a conservé la pile web et optimisé le reste autour d’elle.
Cette distinction est importante. Microsoft a jugé que les avantages organisationnels de React, TypeScript et Chromium méritaient d’être préservés, tout en améliorant résolument les performances.
Il y a une autre leçon à en tirer. Microsoft lui-même a introduit de nombreuses générations de technologies pour les applications Windows au fil des années : Win32, WPF, UWP, WinUI et d’autres. Une entreprise qui choisit le « natif Windows » ne choisit pas nécessairement une plateforme intemporelle. Elle mise souvent sur une génération du framework privilégié par Microsoft.
Assez ironiquement, la plateforme web est devenue l’une des cibles de développement applicatif les plus stables qui soient.
Le recrutement fait partie de l’architecture
Le choix d’un framework détermine aussi les profils que vous pouvez recruter.
Les développeurs JavaScript et TypeScript constituent l’un des plus grands viviers de talents techniques du secteur. Une entreprise qui développe avec Electron peut recruter dans ce vivier plutôt que de devoir constituer des équipes distinctes de spécialistes expérimentés de macOS, Windows et Linux.
Les spécialistes du natif restent précieux. Les produits de bureau ambitieux ont toujours besoin d’ingénieurs qui connaissent les systèmes d’exploitation en profondeur. Mais Electron change le nombre de spécialistes dont vous avez besoin.
Au lieu d’exiger que la majeure partie de l’application soit développée par des experts de chaque plateforme, vous pouvez conserver une quantité relativement faible de code d’intégration native et laisser la majorité de l’équipe travailler sur le produit commun.
Cela compte encore davantage lorsqu’une entreprise dispose déjà d’une application web. Les composants React peuvent parfois être partagés. Les bibliothèques TypeScript peuvent être réutilisées. La logique produit peut passer du web au bureau et inversement. Les ingénieurs peuvent changer d’équipe sans devoir apprendre un écosystème entièrement différent.
Le recrutement devient également moins fragile. Si le seul ingénieur qui connaît en profondeur votre client Windows natif quitte l’entreprise, remplacer cette expertise peut être difficile. Avec Electron, une bien plus grande partie de la base de code utilise des technologies connues du reste de l’organisation.
Un framework ne détermine donc pas seulement la manière dont une interface est affichée. Il influence la structure même de l’organisation technique.
Natif ne signifie pas automatiquement meilleur logiciel
Les développeurs emploient souvent « natif » presque comme un synonyme de « rapide ».
Ce n’en est pas un.
Les API natives donnent aux développeurs la possibilité de créer une application très efficace. Que le produit final y parvienne réellement dépend de l’architecture, de l’équipe, du budget et de la quantité de travail d’optimisation que l’entreprise peut financer.
Une application native peut tout de même être lente, pleine de bugs, gourmande en mémoire, incohérente ou mal maintenue.
Surtout, répartir une équipe aux moyens limités entre plusieurs implémentations natives signifie que chaque implémentation bénéficie de moins d’heures de travail d’ingénierie.
Imaginez qu’une entreprise dispose de six ingénieurs pour son produit de bureau. Une option consiste à les répartir entre Mac et Windows, en laissant peut-être Linux de côté. Une autre consiste à affecter presque tous les six à une seule application Electron commune aux trois plateformes.
Quelle approche donne à l’entreprise la plus grande capacité technique pour améliorer le temps de démarrage, corriger les fuites de mémoire, peaufiner les interactions, améliorer l’accessibilité, réduire les plantages et répondre aux utilisateurs ?
Il n’est pas évident que les applications natives aboutissent au meilleur produit.
Cela crée un paradoxe intéressant : un framework qui consomme un peu plus de ressources machine peut permettre à une entreprise de développer un produit mieux optimisé, parce qu’il mobilise beaucoup moins de ressources d’ingénierie.
Electron vous offre une plateforme maîtrisée
Electron possède aussi un autre avantage facile à négliger : il embarque l’environnement d’exécution Chromium avec lequel l’application a été développée et testée.
Cela élimine une variable majeure du développement multiplateforme.
Les frameworks fondés sur les vues web des systèmes d’exploitation peuvent produire des applications plus petites, mais la contrepartie est qu’une même interface peut s’exécuter sur WebView2 sous Windows, WKWebView sous macOS et WebKitGTK sous Linux. Ces moteurs ont des capacités, des bugs, des calendriers de publication et des comportements de rendu différents.
Electron fait un autre compromis : embarquer l’environnement d’exécution et en faire une partie intégrante de l’application.
Oui, cela occupe de l’espace disque.
Mais cela donne aux développeurs une cible beaucoup plus cohérente sur trois systèmes d’exploitation très différents.
Cette cohérence a une immense valeur sur le plan de l’ingénierie.
Quand Electron ne suffit pas, vous pouvez toujours recourir au natif
Choisir Electron ne signifie pas renoncer aux fonctionnalités natives.
Les applications Electron peuvent utiliser des modules natifs et du code propre à chaque plateforme lorsque c’est nécessaire. Cela signifie que le choix architectural ne se résume pas vraiment à :
100 % natif ou 100 % JavaScript.
Pour de nombreux produits, un meilleur modèle est :
la majeure partie de l’application est partagée, avec une petite quantité de code natif là où le système d’exploitation l’exige réellement.
Le code natif devient une solution de recours plutôt que le socle de l’ensemble du produit.
Pour de nombreuses entreprises, c’est une bien meilleure manière d’allouer les efforts d’ingénierie.
Les utilisateurs s’intéressent aux produits, pas aux frameworks
Il existe un petit groupe d’utilisateurs techniquement avertis qui ouvrent le Moniteur d’activité, remarquent plusieurs processus Chromium et se plaignent immédiatement qu’une application utilise Electron.
La plupart des utilisateurs ne le font pas.
Peu leur importe que Slack utilise Electron. Peu leur importe que VS Code soit construit avec des technologies web. Ils ne savent pas quel framework Claude utilise. Ce qui les intéresse, c’est de savoir si le logiciel les aide à accomplir leur travail.
Si une application démarre suffisamment vite, se montre réactive, plante rarement et résout le problème de l’utilisateur, la technologie employée pour l’implémenter est largement invisible.
L’inverse est tout aussi vrai. Une application native ne devient pas automatiquement un bon produit parce qu’elle utilise Swift ou WinUI.
La concurrence entre logiciels se joue au niveau des produits, pas des frameworks.
Optimisez l’entreprise, pas seulement le binaire
Electron a de véritables coûts. Il occupe davantage d’espace disque. Son empreinte mémoire de base est généralement plus élevée que celle d’une petite application native. Pour certains produits, ces coûts font incontestablement d’Electron un mauvais choix.
Un minuscule utilitaire de barre de menus n’a probablement pas besoin de Chromium. Un pilote de périphérique certainement pas. Les jeux, les logiciels audio professionnels et les applications extrêmement sensibles à la latence ont d’autres exigences. Et si votre produit ne fonctionnera jamais que sur un seul système d’exploitation, le développement natif devient beaucoup plus facile à justifier.
Mais une très grande proportion des logiciels de bureau modernes n’entre pas dans ces catégories.
Il s’agit d’interfaces complexes connectées à des services cloud. Ces logiciels doivent fonctionner sur Windows et macOS, et les utilisateurs attendent de plus en plus une prise en charge de Linux. Ils doivent évoluer en permanence. Ils sont en concurrence avec des produits qui livrent des changements chaque semaine. Et ils sont généralement développés par une entreprise dont le nombre d’ingénieurs est limité.
Pour ces produits, la productivité des développeurs fait partie de la performance de l’application.
Electron permet à une entreprise de recruter dans un vivier de talents beaucoup plus vaste, de partager les ingénieurs entre le web et le bureau, de maintenir une application principale plutôt que plusieurs, de réutiliser l’écosystème JavaScript, de livrer les fonctionnalités de façon plus cohérente sur différents systèmes d’exploitation, de prendre en charge Linux à un coût qui serait souvent difficile à justifier autrement et de consacrer davantage de temps d’ingénierie à l’amélioration du produit plutôt qu’à la maintenance d’implémentations parallèles.
Le coût d’Electron se mesure facilement en mégaoctets.
Les coûts des autres approches sont plus difficiles à voir. Ils prennent la forme d’ingénieurs supplémentaires, d’implémentations dupliquées, de cycles de publication plus longs, de bugs propres à chaque plateforme, de difficultés de recrutement, de silos organisationnels, d’utilisateurs de Linux laissés de côté et de fonctionnalités qui mettent plusieurs mois de plus à parvenir à tout le monde.
Ces coûts n’apparaissent pas dans le Moniteur d’activité.
Mais pour l’entreprise qui développe le logiciel, ils peuvent être considérablement plus élevés.
L’objectif du développement logiciel n’est pas de produire le plus petit binaire.
Il est de créer le meilleur produit que votre organisation puisse livrer, maintenir et améliorer en continu.
Pour une catégorie étonnamment vaste d’applications de bureau, Electron reste l’un des moyens les plus efficaces d’y parvenir.