Points clés
- Electron rend du contenu web dans un shell desktop, ce qui signifie que votre application hérite de tous les bugs visuels du web — plus les spécificités desktop
- Les dimensions de fenêtre variables, les menus natifs, le support multi-écran et les différences de rendu entre OS créent des catégories de bugs visuels absentes du web classique
- Tester une app Electron comme un simple site web est une erreur : le contexte desktop change fondamentalement l'expérience visuelle
- Le test visuel automatisé est la seule approche viable pour couvrir la combinatoire OS × résolution × DPI × taille de fenêtre
Electron est défini par sa documentation officielle comme « un framework permettant de créer des applications desktop natives avec les technologies web (HTML, CSS, JavaScript), en combinant Chromium pour le rendu et Node.js pour l'accès aux fonctionnalités système, dans un runtime unique et multiplateforme » (Electron Documentation, electronjs.org).
Derrière cette définition élégante se cache une réalité que tout développeur Electron connaît : vous obtenez le meilleur du web (écosystème, productivité, composants UI riches) et le pire du web (inconsistances CSS, problèmes de rendu, performances variables). Le tout, agrémenté d'une couche supplémentaire de complexité liée à l'environnement desktop.
Si vous développez une application Electron — et il y a de fortes chances que vous en utilisiez plusieurs (VS Code, Slack, Discord, Figma, Notion, Obsidian) — cet article va vous montrer pourquoi le test visuel de votre application desktop mérite une attention spécifique, et pourquoi la traiter « comme du web » n'est pas suffisant mais reste le bon point de départ.
Electron hérite de tous les problèmes visuels du web
Le CSS est toujours du CSS
Votre application Electron utilise le même moteur de rendu que Chrome (Chromium, via le projet Electron qui embarque une version spécifique de Chromium). Cela signifie que tous les problèmes visuels du web s'appliquent : les régressions CSS après une mise à jour de dépendance, les débordements de texte, les problèmes de z-index, les images mal dimensionnées, les animations saccadées, les polices qui ne se chargent pas.
Si vous avez déjà fait du test visuel pour le web, vous connaissez ces problèmes. Et ils sont exactement aussi présents dans Electron.
Mais voilà le piège : beaucoup d'équipes qui développent des applications Electron ne viennent pas du web. Elles viennent du desktop natif (C++, C#, Java Swing) où les problèmes de rendu CSS n'existent pas. Elles découvrent ces problèmes pour la première fois, sans l'expérience ni les outils pour les gérer.
Les mises à jour de Chromium : le risque silencieux
Chaque mise à jour majeure d'Electron embarque une nouvelle version de Chromium. Et chaque nouvelle version de Chromium peut modifier subtilement le rendu. Une modification du sous-pixel antialiasing, un changement dans le calcul des arrondis, une évolution dans la gestion des fonts — ces changements sont rarement documentés comme breaking changes, mais ils peuvent provoquer des régressions visuelles mesurables.
L'équipe Electron publie une nouvelle version majeure environ toutes les huit semaines. Selon le blog officiel d'Electron, chaque release majeure intègre une version de Chromium, une version de Node.js, et une version de V8. Cela fait beaucoup de surfaces de changement potentiel.
Si vous ne faites pas de test visuel avant et après chaque mise à jour d'Electron, vous acceptez un risque silencieux de régression sur l'ensemble de votre interface.
Les spécificités desktop qui changent tout
La fenêtre redimensionnable : le responsive sous stéroïdes
Sur le web, le « responsive design » consiste à adapter le layout à quelques breakpoints prédéfinis (mobile, tablette, desktop). Ces problématiques de rendu multi-environnement sont au cœur du test visuel cross-browser. Les viewports possibles sont nombreux mais bornés par les tailles d'écrans existants.
Sur desktop, la fenêtre de votre application Electron peut prendre littéralement n'importe quelle taille, de 400 par 300 pixels à 3840 par 2160 pixels, en passant par toutes les dimensions intermédiaires. L'utilisateur peut redimensionner librement, et il le fait.
Cela crée un spectre continu de layouts possibles, pas un ensemble discret de breakpoints. Votre application doit être visuellement correcte à toute taille — et les tailles intermédiaires (celles entre vos breakpoints) sont souvent celles où les problèmes apparaissent.
Quelques scénarios typiques de bugs liés au redimensionnement :
Un sidebar qui se superpose au contenu principal quand la fenêtre est trop étroite pour afficher les deux mais trop large pour déclencher le mode « collapsed ».
Un tableau qui déborde de son conteneur et crée un scroll horizontal inattendu à certaines largeurs.
Des boutons d'action dans un header qui se chevauchent quand l'espace horizontal est insuffisant mais que le breakpoint mobile n'est pas encore atteint.
Un panneau flottant (inspecteur, terminal, palette de commandes) qui sort de la zone visible quand la fenêtre est trop petite.
Les menus natifs : l'interface que vous ne contrôlez pas
Les applications Electron peuvent utiliser les menus natifs de l'OS (barre de menu sur macOS, menu de fenêtre sur Windows et Linux). Ces menus sont rendus par le système d'exploitation, pas par votre code CSS. Leur apparence varie selon l'OS, la version de l'OS, et le thème système de l'utilisateur.
Visuellement, la zone de transition entre le menu natif et votre contenu web est une source fréquente de problèmes. Sur macOS, la barre de titre et le menu sont gérés par le système. Sur Windows, beaucoup d'applications Electron utilisent une barre de titre personnalisée (frameless window avec des boutons de contrôle recréés en CSS) pour un look plus moderne.
Cette barre de titre personnalisée est un composant critique visuellement. Les boutons de fermeture, réduction, et agrandissement doivent être au bon endroit, de la bonne taille, de la bonne couleur, et se comporter correctement au survol. Et tout cela varie entre les plateformes : sur macOS, les boutons sont à gauche et ronds ; sur Windows, ils sont à droite et carrés ; sur Linux, ça dépend du gestionnaire de fenêtres.
Si votre application utilise une barre de titre personnalisée, le test visuel doit la couvrir sur chaque OS cible. C'est un composant que les utilisateurs voient et utilisent constamment, et un bug visuel ici est immédiatement perceptible.
Le multi-écran et le DPI variable
L'environnement desktop moderne, c'est souvent un laptop avec un écran Retina (2x DPI) connecté à un moniteur externe en 1080p (1x DPI). L'utilisateur déplace votre application d'un écran à l'autre. Et quand l'application passe d'un écran 2x à un écran 1x, tout doit se re-rendre correctement.
Les problèmes visuels liés au DPI sont particulièrement sournois :
Les images bitmap (PNG, JPG) conçues pour un seul DPI apparaissent floues sur les écrans haute résolution ou pixelisées sur les écrans basse résolution. Les icônes et illustrations doivent être fournies en plusieurs résolutions ou en format vectoriel (SVG).
Les bordures de 1 pixel ne s'affichent pas de la même manière en 1x et 2x. Sur un écran 2x, une bordure de 1 pixel CSS fait 0.5 pixel physique, ce qui peut la rendre invisible ou inconsistante selon le moteur de rendu.
Les ombres portées, les dégradés, et les effets de flou changent subtilement de rendu entre les résolutions. Ce qui est un léger flou sur un écran 1x devient un flou prononcé sur un écran 2x, ou inversement.
Les textes subissent un antialiasing différent. La lisibilité d'une police fine peut être excellente en 2x et médiocre en 1x. Le choix typographique qui fonctionne sur votre écran de développement (probablement un MacBook Retina) peut être désastreux sur le moniteur externe de votre utilisateur.
La barre des tâches, le dock, et le system tray
Votre application interagit avec l'environnement desktop via l'icône de la barre des tâches (Windows/Linux), du dock (macOS), et du system tray. Ces icônes minuscules (16x16 à 48x48 pixels) doivent être impeccables. Badges de notification, overlays d'état, menus contextuels — ce sont des éléments visuels que vos utilisateurs voient en permanence, même quand votre application n'est pas au premier plan.
Les trois OS : trois rendus, trois problèmes
macOS : la référence exigeante
macOS est souvent la plateforme de développement principale. Les spécificités visuelles incluent les boutons de trafic lumineux (rouge, jaune, vert) à gauche, le rendu de police par Core Text (visuellement plus « gras » qu'au même poids sur Windows), et la gestion native du mode sombre qui doit s'harmoniser avec le thème de votre application.
Windows : la diversité de configurations
Windows offre la plus grande diversité de configurations. Les résolutions vont de 1366x768 (encore 20 % des écrans selon StatCounter en 2025) à 3840x2160. Les facteurs de mise à l'échelle (100 % à 200 %) ajoutent une complexité absente sur macOS.
Le rendu des polices par DirectWrite produit des résultats sensiblement différents de Core Text : polices plus fines, plus nettes, parfois moins lisibles à petite taille. Le mode « contraste élevé » pour l'accessibilité peut drastiquement modifier l'apparence de votre application si vos styles CSS ne le supportent pas.
Linux : le cas particulier
La fragmentation des environnements desktop (GNOME, KDE, XFCE) rend la normalisation difficile. Mais selon le Stack Overflow Developer Survey 2024, environ 27 % des développeurs utilisent Linux. Si votre application cible les développeurs, Linux mérite une couverture. Le minimum viable : Ubuntu avec GNOME.
Stratégie de test visuel pour Electron
Définir votre matrice de test
La première étape est de définir explicitement les combinaisons que vous allez tester. Au minimum, votre matrice devrait inclure :
Les OS cibles. macOS (dernière version et avant-dernière), Windows 10, Windows 11. Linux Ubuntu LTS si votre audience le justifie.
Les résolutions d'écran prioritaires. Pour chaque OS, les deux ou trois résolutions les plus utilisées par vos utilisateurs. Sur macOS : 1440x900 et 2560x1600 (Retina). Sur Windows : 1920x1080 et 1366x768. Adaptez selon vos données analytics réelles.
Les facteurs DPI. 1x et 2x au minimum. Sur Windows, ajoutez 1.5x (150 %) qui est un setting très courant.
Les tailles de fenêtre. Plein écran, demi-écran (split screen), et une taille réduite « minimale fonctionnelle ». Ces trois tailles couvrent les scénarios d'utilisation réels.
Automatiser la capture sur plusieurs OS
Le défi technique principal du test visuel Electron est de capturer des screenshots sur plusieurs OS. Vous avez plusieurs options.
L'approche CI multi-plateforme. GitHub Actions, GitLab CI et Azure Pipelines supportent les jobs sur macOS, Windows et Linux. Configurez un job de test visuel par OS qui lance votre application, navigue vers les écrans à tester, et capture des screenshots.
L'approche Playwright. Playwright supporte nativement l'automatisation d'Electron depuis la version 1.20 : lancement de l'app, interactions, captures de screenshots, le tout cross-platform.
L'approche Delta-QA. Pour les équipes qui ne veulent pas maintenir des scripts, Delta-QA offre une approche no-code pour capturer et comparer visuellement les écrans de votre application.
Les zones à surveiller en priorité
Dans une application Electron, certaines zones sont plus sujettes aux régressions visuelles que d'autres. Concentrez vos tests visuels sur ces zones :
La barre de titre et les contrôles de fenêtre. Si vous utilisez une barre de titre personnalisée (frameless window), testez-la sur chaque OS. Les boutons de fermeture/réduction/agrandissement, le drag area, le titre de l'application — tout doit être pixel-perfect et conforme aux conventions de la plateforme.
Les panneaux redimensionnables. Si votre application a des panneaux (sidebar, bottom panel, inspector) que l'utilisateur peut redimensionner, testez le rendu à différentes tailles de panneau. Les handles de redimensionnement, les tailles minimales et maximales, le contenu qui s'adapte — tout cela doit être visuellement correct.
Les menus contextuels. Les menus contextuels natifs ont un rendu différent sur chaque OS. Les menus contextuels personnalisés (en CSS) doivent être testés en termes de positionnement (ne pas déborder de la fenêtre), de lisibilité, et de cohérence avec le thème de l'application.
Les modales et dialogues. Les boîtes de dialogue système (ouvrir un fichier, enregistrer, imprimer) sont natives et ne nécessitent pas de test visuel de votre part. Mais les modales personnalisées de votre application doivent être testées, en particulier leur centrage, leur overlay, et leur comportement quand la fenêtre est petite.
Les états de chargement et les transitions. Le démarrage d'une application Electron peut prendre quelques secondes. Ce que l'utilisateur voit pendant ce temps (splash screen, écran de chargement, fenêtre vide) fait partie de l'expérience et mérite un test visuel.
Les erreurs les plus fréquentes
Ne tester que sur un seul OS
C'est l'erreur la plus courante et la plus coûteuse. Si votre équipe développe sur macOS et teste sur macOS, les bugs visuels spécifiques à Windows et Linux arrivent en production sans filtre. Et Windows représente généralement la majorité de votre base d'utilisateurs Electron (selon les données de Electron Fiddle et de nombreuses applications Electron populaires, Windows représente souvent 60 à 70 % des installations).
Ignorer les facteurs de DPI
Tester uniquement en 1x quand une proportion significative de vos utilisateurs sont en 2x (ou inversement) est une recette pour les surprises. Les problèmes de DPI sont subtils — textes légèrement flous, bordures disparues, icônes pixelisées — mais ils donnent une impression de manque de finition qui érode la confiance.
Traiter Electron comme un navigateur web
Votre application Electron n'est pas un onglet de navigateur. C'est une application desktop que l'utilisateur a installée, qui a son propre espace dans la barre des tâches, et qui est jugée selon les standards des applications natives. Les utilisateurs tolèrent un site web avec un layout un peu cassé. Ils ne tolèrent pas une application desktop installée avec des problèmes visuels évidents.
Négliger les tailles de fenêtre intermédiaires
Si vous ne testez qu'en plein écran, vous manquez tous les bugs qui apparaissent quand l'utilisateur utilise votre application en demi-écran (split screen avec une autre application). C'est un usage extrêmement courant sur desktop, surtout pour les outils de productivité.
FAQ
Electron utilise Chromium, donc les tests web classiques suffisent, non ?
Non. Electron utilise Chromium pour le rendu, c'est vrai. Mais l'environnement est fondamentalement différent : fenêtre redimensionnable à l'infini, pas de barre d'adresse, menus natifs OS, intégration avec la barre des tâches, support multi-écran, DPI variable. Vos tests web classiques couvrent le rendu Chromium dans un navigateur. Ils ne couvrent pas les spécificités de l'environnement desktop Electron. Les deux niveaux sont nécessaires.
Comment gérer les différences de rendu de police entre macOS et Windows ?
Le rendu de police diffère structurellement entre Core Text (macOS) et DirectWrite (Windows). La seule façon fiable de gérer ces différences est de maintenir des baselines visuelles séparées par OS. Ne comparez pas un screenshot macOS avec un screenshot Windows — ils seront toujours différents, et ces différences sont normales. Comparez macOS avec macOS, Windows avec Windows.
Faut-il tester chaque mise à jour de version Electron ?
Oui, et c'est non négociable. Chaque mise à jour majeure d'Electron embarque une nouvelle version de Chromium qui peut modifier le rendu. La bonne pratique est de lancer votre suite de tests visuels complète avant et après la mise à jour, de comparer les résultats, et de valider les différences. Certaines différences seront des améliorations du moteur de rendu (que vous pouvez accepter en mettant à jour les baselines), d'autres seront des régressions (que vous devez corriger ou reporter).
Comment tester le mode contraste élevé de Windows ?
Le mode contraste élevé (High Contrast Mode) de Windows est un paramètre d'accessibilité qui remplace les couleurs de votre application par un schéma de couleurs à fort contraste. Vous pouvez l'activer programmatiquement dans votre environnement de test CI (via les réglages système ou des outils d'automatisation). Capturez des screenshots dans ce mode et maintenez une baseline dédiée. C'est particulièrement important si votre application cible des environnements professionnels où les politiques d'accessibilité sont strictes.
Mon application Electron cible uniquement macOS. Le test multi-OS est-il quand même nécessaire ?
Si votre application ne supporte véritablement qu'un seul OS, le test multi-OS n'est évidemment pas nécessaire. Mais vérifiez cette hypothèse : beaucoup d'applications « macOS only » découvrent qu'une partie de leurs utilisateurs exécutent l'application sur Windows via des installations non officielles ou des demandes entreprise. Si vous envisagez un support Windows futur, investir dans le test multi-OS dès maintenant facilitera considérablement la transition.
Quelle est la fréquence idéale de test visuel pour une application Electron ?
À chaque commit qui touche l'interface, et à chaque mise à jour de version Electron ou de dépendance UI. En pratique, intégrez le test visuel dans votre pipeline CI/CD pour qu'il s'exécute automatiquement à chaque pull request. Le coût d'un faux positif occasionnel est infiniment inférieur au coût d'une régression visuelle livrée à des milliers d'utilisateurs desktop.
Pour aller plus loin
- Test visuel pour Progressive Web Apps (PWA) : testez-les comme des apps, pas comme des sites
- Test Visuel dans GitLab CI/CD : Comment Exploiter les Artifacts et Environments pour une Détection Parfaite des Régressions
Electron vous donne le pouvoir de créer des applications desktop avec les technologies du web. C'est un superpouvoir. Mais ce superpouvoir vient avec une responsabilité : les bugs visuels du web vous suivent sur le desktop, et ils sont rejoints par une cohorte de problèmes spécifiques à l'environnement natif.
La bonne nouvelle, c'est que si vous savez déjà tester visuellement du web, vous avez 80 % des compétences nécessaires. Les 20 % restants — la matrice multi-OS, les facteurs DPI, les fenêtres redimensionnables, les menus natifs — sont une extension naturelle de votre démarche existante.
Electron hérite de tous les problèmes du web. Testez-le comme du web, puis allez plus loin.