Selenium et Test Visuel : Le Guide Complet pour 2026
Selenium Visual Testing : « Approche consistant à utiliser le framework Selenium WebDriver pour capturer des images d'interfaces web et les comparer à des références visuelles, dans le but de détecter des régressions non intentionnelles dans l'apparence de l'application. »
Selenium est le framework de test automatisé le plus utilisé au monde. Avec plus de 22 000 recherches mensuelles rien que pour « selenium webdriver », il est clair que la communauté QA mondiale tourne encore largement autour de cet outil. Et pour cause : depuis 2004, Selenium a défini ce que signifie « automatiser un navigateur ».
Mais voilà le problème que personne ne veut vraiment entendre : Selenium n'a pas été conçu pour le test visuel. Il excelle dans le test fonctionnel — vérifier qu'un bouton fonctionne, qu'un formulaire envoie des données, qu'une page se charge correctement. Quand il s'agit de vérifier que cette page ressemble à ce qu'elle devrait, Selenium vous regarde avec l'air perplexe d'un robot à qui on demande de juger un concours de beauté.
Cet article n'est pas un tutoriel qui vous promet que Selenium peut tout faire. C'est un guide honnête qui explore ce qui est possible, ce qui est pénible, et ce qui mérite une meilleure solution.
Pourquoi le test visuel est devenu indispensable
Pendant longtemps, le test logiciel se résumait à une question binaire : « est-ce que ça marche ? ». Le bouton envoie-t-il le formulaire ? La page affiche-t-elle les bonnes données ? Le parcours utilisateur aboutit-il au paiement ?
Ces questions restent essentielles. Mais en 2026, elles ne suffisent plus.
Les utilisateurs modernes jugent une application en moins de 50 millisecondes — c'est le temps qu'il faut au cerveau humain pour former une première impression visuelle, selon une étude de l'université Carleton au Canada. Un bouton qui fonctionne mais qui est décalé de 20 pixels, un texte qui déborde de son conteneur, un thème sombre qui affiche du texte noir sur fond gris — tout cela « marche » au sens fonctionnel, mais détruit l'expérience utilisateur.
Le test visuel comble ce fossé. Il vérifie non pas ce que l'application fait, mais ce qu'elle montre. Et dans un monde où les interfaces changent à chaque sprint, détecter les régressions visuelles automatiquement n'est plus un luxe — c'est une nécessité.
Le problème ? Les outils de test fonctionnel comme Selenium n'ont jamais été pensés pour ça.
Ce que Selenium sait faire (et ce qu'il ne sait pas)
Selenium WebDriver est un outil extraordinaire pour ce qu'il a été conçu à faire : piloter un navigateur et interagir avec des éléments web. Il sait cliquer, taper, naviguer, attendre, et vérifier la présence ou le contenu d'éléments dans le DOM.
Ce que Selenium sait faire côté visuel se résume à exactement une chose : takeScreenshot(). Cette méthode capture l'état actuel du navigateur en tant qu'image PNG. C'est tout. Pas de comparaison, pas de différences, pas de seuils de tolérance, pas de masquage de zones dynamiques.
C'est un peu comme si on vous donnait un appareil photo et qu'on vous disait « voilà, vous êtes photographe professionnel ». L'outil de capture est là, mais tout le travail créatif — et technique — reste à faire.
Voici ce que Selenium ne sait pas faire nativement :
- Comparer deux captures d'écran
- Détecter les différences visuelles entre deux versions d'une page
- Gérer des images de référence (baselines)
- Filtrer le bruit visuel (anti-aliasing, animations, contenu dynamique)
- Générer des rapports visuels de différences
- Mettre à jour automatiquement les références quand un changement est intentionnel
Pour obtenir tout cela, il faut construire ou intégrer. Voyons les options.
Approche 1 : captures d'écran et comparaison externe
L'approche la plus basique — et la plus douloureuse — consiste à utiliser takeScreenshot() de Selenium pour capturer des images, puis à les comparer avec une bibliothèque de traitement d'images.
Le principe
Vous prenez une capture d'écran de votre page avec Selenium. Vous la stockez comme référence. La prochaine fois que vous exécutez le test, vous prenez une nouvelle capture et vous la comparez pixel par pixel avec la référence. Si les différences dépassent un certain seuil, le test échoue.
Les outils de comparaison courants
Plusieurs bibliothèques open source permettent la comparaison d'images : pixelmatch (JavaScript), Pillow ou scikit-image (Python), ImageMagick (ligne de commande). Chacune a ses forces, mais aucune n'est spécialement conçue pour le test d'interfaces web.
Ce que vous devez construire vous-même
En pratique, cette approche vous oblige à devenir l'architecte d'un mini-framework de test visuel. Vous devez gérer le stockage et le versioning des images de référence, la logique de comparaison avec des seuils configurables, le masquage des zones dynamiques (dates, publicités, contenu personnalisé), la gestion des différentes résolutions et tailles de viewport, les rapports exploitables qui montrent les différences, et le workflow de mise à jour des références quand un changement est voulu.
Les limites
C'est l'approche qui offre le plus de contrôle, mais aussi celle qui demande le plus d'investissement. Vous passez plus de temps à maintenir votre infrastructure de test visuel qu'à écrire de vrais tests. Et chaque mise à jour de navigateur, chaque changement de rendu de police peut générer des faux positifs qui noient les vraies régressions.
Imaginez un assistant qui, au lieu de vous aider à trouver les erreurs dans un document, passe son temps à souligner chaque virgule en vous demandant si elle est à la bonne place. Techniquement rigoureux, pratiquement insupportable.
Approche 2 : les plugins et bibliothèques tierces
Pour éviter de tout construire depuis zéro, la communauté a créé des bibliothèques qui ajoutent des capacités de test visuel par-dessus Selenium. Parmi les plus connues :
Ashot (Java)
Ashot est une bibliothèque Java qui étend les capacités de capture d'écran de Selenium. Elle permet la capture de pages entières (y compris le contenu hors écran via défilement), la comparaison d'images avec mise en évidence des différences, et le recadrage par élément spécifique.
C'est l'option la plus populaire dans l'écosystème Java/Selenium, mais elle reste un outil de bas niveau. Vous avez les briques, mais la maison est à construire.
needle (Python)
needle est un plugin pytest qui intègre Selenium avec la comparaison d'images. Il compare des captures d'écran de pages entières ou d'éléments spécifiques, utilise Pillow pour la comparaison, et s'intègre proprement avec pytest.
Le projet a connu des périodes d'inactivité, et la documentation peut être lacunaire. C'est un choix correct pour des besoins modestes, mais qui montre ses limites sur des projets de taille réelle.
BackstopJS
BackstopJS n'est pas exactement un plugin Selenium — c'est un outil autonome qui utilise Puppeteer ou Playwright en coulisses. Mais il mérite d'être mentionné car beaucoup d'équipes Selenium l'ajoutent en complément pour le test visuel.
BackstopJS propose une configuration déclarative en JSON, des captures multi-viewport, un rapport HTML interactif, et un workflow approve/reject pour les changements.
C'est probablement l'outil open source le plus abouti pour le test visuel. Mais il ne s'intègre pas directement avec vos tests Selenium existants — c'est un outil séparé avec son propre pipeline.
Les limites communes des plugins
Tous ces outils partagent des limitations fondamentales. Ils nécessitent des compétences de développement pour la mise en place et la maintenance. Ils dépendent de projets open source dont la pérennité n'est jamais garantie — un mainteneur qui change de job et c'est tout un écosystème qui ralentit. Ils ajoutent de la complexité à votre stack sans résoudre les problèmes structurels de la comparaison pixel par pixel. Et surtout, ils restent des outils de développeurs, inaccessibles au reste de l'équipe.
Approche 3 : intégration avec Applitools
La troisième voie est l'intégration avec un service SaaS dédié au test visuel. Applitools Eyes est le plus connu dans cette catégorie.
Le principe
Applitools fournit un SDK qui s'intègre directement avec Selenium. Vos tests Selenium existants sont augmentés d'appels à l'API Applitools qui envoient les captures d'écran vers leur cloud pour comparaison.
Ce qu'Applitools apporte
Applitools utilise une technologie de comparaison basée sur l'IA (leur « Visual AI ») qui est nettement plus intelligente que la comparaison pixel par pixel. Elle comprend la structure de la page, ignore les différences insignifiantes, et détecte les vraies régressions avec un taux de faux positifs remarquablement bas.
Le dashboard cloud permet à toute l'équipe (pas seulement les développeurs) de voir les résultats, approuver les changements, et suivre l'état des tests visuels.
Les limites
Le confort a un prix. Applitools est un service cloud payant dont les tarifs augmentent avec le volume de captures. Vos images d'interface quittent votre infrastructure pour être traitées sur leurs serveurs — un point sensible pour certaines organisations. Et vous restez dépendant d'un service tiers : si Applitools est en panne, vos tests visuels le sont aussi.
L'intégration SDK signifie aussi que vous devez toujours écrire et maintenir des tests Selenium. Vous avez simplifié la comparaison, mais pas la création des scénarios de capture. C'est mieux que de tout faire soi-même, certes — comme avoir un GPS au lieu d'une carte routière, le trajet est le même mais on s'y perd moins.
Le verdict : Selenium est pour le fonctionnel
Après avoir exploré les trois approches, une conclusion s'impose : Selenium est un outil de test fonctionnel, et essayer de lui greffer des capacités de test visuel, c'est comme monter un porte-vélos sur une moto — ça tient, mais ce n'est pas l'idée originale.
Chaque approche a ses mérites, mais aucune ne résout le problème fondamental : le test visuel et le test fonctionnel sont deux disciplines différentes qui méritent des outils différents.
Le test fonctionnel vérifie le comportement. Il pose la question « est-ce que ça fait ce que c'est censé faire ? ». Le DOM, les événements, les données — c'est le territoire de Selenium, et il y excelle.
Le test visuel vérifie l'apparence. Il pose la question « est-ce que ça ressemble à ce que c'est censé ressembler ? ». Les pixels, les layouts, les rendus — c'est un territoire que Selenium visite en touriste.
Continuez à utiliser Selenium pour vos tests fonctionnels. C'est l'outil qu'il faut. Mais pour le test visuel, envisagez sérieusement un outil conçu dès le départ pour cette mission.
L'alternative dédiée au test visuel
Delta-QA existe précisément parce que le test visuel ne devrait pas être un sous-produit bricolé de vos tests fonctionnels. C'est un outil dédié, pensé depuis la première ligne pour la détection de régressions visuelles.
Voici ce qui change avec une approche dédiée :
No-code, vraiment : vous n'avez pas besoin de Selenium, de WebDriver, ni de la moindre compétence en programmation. Vous pointez vers vos pages, Delta-QA fait le reste. Votre QA analyst, votre designer, votre product owner — tout le monde peut lancer et interpréter des tests visuels.
Comparaison intelligente : Delta-QA ne se contente pas de comparer des pixels. Il comprend les différences significatives et filtre le bruit technique (anti-aliasing, variations de rendu, contenu dynamique). Résultat : moins de faux positifs, plus de vraies régressions détectées.
Exécution locale : vos captures d'écran restent sur votre infrastructure. Pas de données envoyées vers un cloud tiers, pas de dépendance à un service externe, pas de facture qui enfle avec le volume.
Gratuit et sans limite artificielle : pas de tier « enterprise » pour débloquer les fonctionnalités essentielles, pas de compteur de captures qui vous force à rationalner vos tests.
Complémentaire à Selenium : Delta-QA ne remplace pas vos tests fonctionnels Selenium. Il les complète en couvrant la dimension visuelle que Selenium ne peut pas adresser nativement.
Le test visuel est trop important pour être traité comme un ajout de dernière minute. Vos utilisateurs voient l'interface avant d'interagir avec elle. Si cette interface est visuellement cassée, ils ne resteront pas assez longtemps pour découvrir que vos tests fonctionnels passent tous au vert.
Essayer Delta-QA Gratuitement →
FAQ
Selenium peut-il faire du test visuel nativement ?
Non. Selenium WebDriver permet de prendre des captures d'écran via takeScreenshot(), mais il ne propose aucune fonctionnalité native de comparaison d'images, de gestion de références visuelles, ou de détection de régressions. Tout doit être construit ou intégré avec des outils tiers.
Quelle est la meilleure bibliothèque pour le test visuel avec Selenium ?
Cela dépend de votre écosystème. En Java, Ashot est le choix le plus répandu. En Python, needle offre une intégration pytest. Pour une solution plus complète, BackstopJS (qui utilise Puppeteer/Playwright plutôt que Selenium) est souvent préféré. Aucune de ces solutions n'est aussi intégrée que ce que propose Playwright nativement.
Applitools vaut-il le coût pour le test visuel ?
La technologie Visual AI d'Applitools est impressionnante et réduit significativement les faux positifs. Pour les grandes entreprises avec des budgets confortables et des exigences élevées, c'est un choix solide. Pour les équipes plus petites ou soucieuses de la confidentialité des données, les coûts et la dépendance cloud peuvent être rédhibitoires. Des alternatives locales et gratuites comme Delta-QA existent.
Faut-il abandonner Selenium pour le test visuel ?
Non. Selenium reste excellent pour le test fonctionnel et devrait continuer à jouer ce rôle. L'idée n'est pas de remplacer Selenium, mais de le compléter avec un outil dédié au test visuel. Les deux disciplines sont complémentaires, et les meilleurs résultats viennent de l'utilisation du bon outil pour chaque besoin.
Le test visuel est-il vraiment nécessaire si on a des tests fonctionnels complets ?
Absolument. Les tests fonctionnels vérifient le comportement (le bouton fonctionne-t-il ?) mais pas l'apparence (le bouton est-il visible, bien positionné, de la bonne couleur ?). Selon le Web Almanac de HTTP Archive, les problèmes de mise en page représentent une part significative des bugs signalés par les utilisateurs — des bugs que les tests fonctionnels ne détectent jamais.
Comment Delta-QA se compare-t-il à l'approche Selenium + Applitools ?
Delta-QA est no-code (pas besoin de Selenium ni de SDK), local (pas de cloud tiers), et gratuit. L'approche Selenium + Applitools nécessite des compétences de développement, envoie les données vers le cloud Applitools, et implique un coût récurrent. Delta-QA est conçu pour les équipes qui veulent du test visuel accessible à tous, sans dépendance externe.
Prêt à séparer vos tests visuels de vos tests fonctionnels ?