Discord prévoit de remplacer Electron par un client natif en Rust

Discord prépare une évolution importante de l’architecture de ses applications de bureau et mobiles. Selon le compte rendu d’Inven Global du 4 novembre  (en anglais), le cofondateur et directeur technique Stanislav Vishnevskiy a présenté un projet de reconstruction du client autour de Rust, en remplacement d’Electron sur ordinateur et de React Native sur mobile. L’interface de bureau utilise GPUI  (en anglais), un framework d’interface native en Rust, plutôt que Tauri ou une autre enveloppe autour d’une interface web.

L’intérêt dépasse le cas de Discord. Electron permet aux équipes web de livrer des logiciels de bureau avec HTML, CSS et JavaScript. Le choix de Discord illustre les compromis entre interfaces web, partage de code et consommation de ressources d’un client natif.

Qu’a-t-on réellement annoncé ?

Vishnevskiy présente Rust comme une technologie déjà utilisée par Discord depuis 2018 dans son infrastructure, ses systèmes vocaux et certaines parties du client actuel. Le projet étend ce socle partagé à une plus grande partie de l’application.

D’après les articles qui rapportent sa déclaration, le projet prévoit de :

• Remplacer Electron comme framework principal de l’interface de bureau.
• Utiliser GPUI pour une interface de bureau native, plutôt qu’héberger une interface web avec Tauri.
• Abandonner React Native sur mobile tout en conservant des interfaces mobiles natives.
• Partager davantage de logique applicative en Rust entre ordinateur et mobile.

Une capture d’une première version Windows nommée “Discord Phoenix” montrait environ 290 Mo de mémoire utilisée. C’est l’observation d’un prototype dans des conditions particulières, pas une comparaison indépendante validée avec le client de production. Les articles des 4 et 5 novembre ne donnaient ni date de sortie publique ni accès à un test public : il s’agit d’un projet en développement, pas d’une annonce de disponibilité.

Electron devient-il un mauvais choix ?

Non. Electron reste utile pour réutiliser les compétences web, partager du code d’interface avec un site, distribuer une application sur plusieurs systèmes de bureau et bénéficier d’un moteur de rendu Chromium éprouvé. Ces avantages peuvent justifier ses coûts dans de nombreuses applications.

En contrepartie, le moteur de navigateur embarqué peut augmenter la mémoire utilisée, la taille d’installation et le temps de démarrage. Une interface native peut éviter une partie de ces coûts, mais demande d’autres pratiques pour le rendu, l’accessibilité, l’intégration au système et le développement. Le choix dépend des objectifs de performance, des compétences de l’équipe et du mode de distribution. Les conseils de performance d’Electron  (traduction imparfaite ; consultez l’original anglais  pour les exemples de code) insistent sur le profilage des véritables points de ralentissement avant de modifier le code.

La décision de Discord ne prouve ni que Rust est toujours plus rapide ni qu’une application Electron consomme forcément trop de mémoire. La charge de travail et l’implémentation comptent toujours. Attendez des mesures sur une version publiquement testable avant de traiter une capture de prototype comme un résultat de référence.

Trois enseignements pour les équipes d’applications fondées sur le Web

Mesurer le parcours utilisateur, pas seulement la mémoire au repos. Comparez le démarrage, la réactivité, l’activité processeur en arrière-plan, la mémoire sous une charge réaliste et le comportement sur les appareils moins puissants. Incluez les tâches réellement effectuées, pas seulement une fenêtre vide.

Séparer la logique métier partagée de l’interface. Même si l’application reste sous Electron, une frontière claire entre le rendu et la gestion des données, du réseau et de l’état peut faciliter une migration future. Un diagramme des modules aide à repérer ce qui dépend vraiment du navigateur. L’éditeur Mermaid de Web2Generators peut servir à cet exercice. Notre guide des diagrammes d’API montre comment représenter les échanges et les chemins d’erreur entre composants.

Revoir l’accessibilité et le rendu après un changement de moteur. Une implémentation native n’hérite pas automatiquement de la sémantique HTML, du comportement au clavier ou des réglages de contraste CSS de l’application web. Pour les versions qui continuent d’utiliser un rendu de navigateur, Color Studio aide à vérifier les couleurs et les contrastes. Notre guide d’un système de couleurs accessible explique comment examiner le texte et les états d’interface. Ces vérifications restent à refaire dans le nouveau moteur.

Et le site web de Discord ?

Les propos du directeur technique concernent l’architecture des clients. Ils ne constituent pas une annonce d’arrêt de la version web de Discord. Ils ne signifient pas non plus que les standards du navigateur, CSS ou JavaScript perdent leur intérêt en général. De nombreux produits continueront à bénéficier d’interfaces web, tandis que d’autres pourront réserver une technologie native à certains clients sensibles aux performances.

La question utile est de savoir si l’architecture d’un produit correspond encore à ses usages et à ses objectifs de performance. L’inspection des requêtes réseau aide aussi à distinguer les coûts de rendu des appels d’API lents dans une application web existante.

Sources

• Déclaration du 4 novembre de Stanislav Vishnevskiy sur X  (en anglais ; déclaration primaire liée par les articles, dont l’accès direct était indisponible pendant la vérification).
• Inven Global, 4 novembre 2026 : reconstruction des applications Discord de bureau et mobiles en Rust  (en anglais).
• tbreak, 5 novembre 2026 : Discord confirme le projet Rust pour remplacer son application Electron  (en anglais).