Cypress vs Selenium en 2026 : le comparatif honnête (et ce que les deux oublient)
En bref
Le test automatisé d'interface web consiste à exécuter des scénarios de vérification sur une application web de manière programmatique, en simulant les actions d'un utilisateur pour valider que l'application fonctionne conformément aux attentes. Cypress et Selenium sont les deux frameworks dominants dans ce domaine — mais ils ont chacun une lacune majeure que personne ne veut voir.
Le débat Cypress vs Selenium est un classique qui revient chaque année, comme la question « tabs vs spaces » ou « monolithe vs microservices ». Les articles de comparaison ne manquent pas. Mais la plupart se contentent de lister les différences techniques sans prendre position, et surtout, sans aborder l'éléphant dans la pièce : ni Cypress ni Selenium ne savent véritablement tester ce que vos utilisateurs voient.
Cet article est un comparatif opiné. Vous y trouverez une analyse franche des forces et faiblesses de chaque outil, des recommandations claires selon votre contexte, et une réflexion sur ce qui manque fondamentalement aux deux.
Selenium : le vétéran qui refuse de mourir
Selenium est né en 2004 chez ThoughtWorks, ce qui lui donne plus de 20 ans d'existence. Dans le monde du logiciel, c'est un âge canonique. Beaucoup l'ont enterré — et beaucoup ont eu tort.
Selenium WebDriver, la version moderne du framework, est aujourd'hui la base du standard W3C WebDriver. Ce n'est pas rien : les navigateurs Chrome, Firefox, Safari et Edge implémentent nativement le protocole que Selenium a contribué à définir. C'est un cas rare dans l'industrie où un outil open source finit par façonner le standard du web lui-même.
Le projet Selenium est maintenu activement. La version 4, sortie en 2021, a apporté le support natif du protocole Chrome DevTools (CDP), une architecture modernisée, et une meilleure gestion du grid distribué. En 2026, Selenium reste le framework de test le plus déployé dans le monde, avec une présence dominante dans les grandes entreprises.
Cypress : le moderne qui a conquis les développeurs
Cypress est arrivé sur la scène en 2017 avec une proposition radicalement différente : oubliez le WebDriver, exécutons les tests directement dans le navigateur.
Cette architecture « in-browser » n'est pas un détail technique — c'est ce qui explique la quasi-totalité des différences entre Cypress et Selenium. Comme Cypress s'exécute dans le même boucle d'événements que l'application testée, il a un accès natif au DOM, aux requêtes réseau, aux timers, et à l'état de l'application. C'est pour cela qu'il est plus rapide, plus stable, et plus facile à débugger.
En moins de 10 ans, Cypress a conquis la communauté JavaScript. Selon la survey State of JS 2024, Cypress reste l'outil de test end-to-end le plus utilisé dans l'écosystème JavaScript, devant Playwright (qui monte rapidement). Son expérience développeur — le test runner interactif, le time-travel debugging, la documentation exemplaire — a fixé un nouveau standard pour ce que devrait être un outil de test.
Les forces réelles de Selenium en 2026
La couverture multi-langages. Selenium supporte officiellement Java, Python, C#, Ruby, JavaScript, et Kotlin. Pour une organisation qui a des équipes en Java et en Python, c'est un avantage décisif. Vous ne forcez pas vos équipes à apprendre un nouveau langage pour écrire des tests.
La couverture multi-navigateurs. Selenium fonctionne nativement sur Chrome, Firefox, Safari, Edge, et même IE (pour les organisations qui en ont encore besoin). Cette couverture n'est pas approximative — elle repose sur le standard W3C WebDriver, ce qui garantit un comportement cohérent.
L'écosystème et la maturité. Plus de 20 ans d'existence signifient un écosystème massif : des milliers d'articles, de tutoriels, de réponses Stack Overflow, et de bibliothèques tierces. Trouver un développeur qui connaît Selenium est trivial. Trouver un développeur qui connaît Cypress est plus facile qu'il y a 5 ans, mais Selenium a encore l'avantage du volume.
Selenium Grid. Pour les tests distribués à grande échelle, Selenium Grid permet d'exécuter des tests en parallèle sur des dizaines ou centaines de machines. C'est une solution éprouvée pour les pipelines CI/CD enterprise qui doivent exécuter des milliers de tests en un temps raisonnable.
La flexibilité architecturale. Selenium ne vous impose aucune opinion sur la structure de vos tests, votre framework d'assertions, ou votre stratégie de reporting. Cette liberté est un avantage pour les équipes matures qui ont des besoins spécifiques — et un inconvénient pour les équipes qui ont besoin de guardrails.
Les forces réelles de Cypress en 2026
La vitesse d'exécution. Cypress est significativement plus rapide que Selenium pour les suites de tests de taille moyenne. L'architecture in-browser élimine la latence du protocole WebDriver. Les commandes Cypress sont exécutées de manière synchrone dans le navigateur, sans les allers-retours réseau qui ralentissent Selenium.
La stabilité des tests. Les tests « flaky » sont le cauchemar de tout ingénieur QA. Cypress réduit drastiquement ce problème grâce à son système d'attente automatique : chaque commande attend que l'élément soit visible, interactif, et stable avant d'agir. Pas besoin de saupoudrer des sleeps arbitraires dans vos tests.
L'expérience développeur. Le test runner de Cypress est un outil à part. Vous voyez vos tests s'exécuter en temps réel, vous pouvez voyager dans le temps pour voir l'état du DOM à chaque étape, et les messages d'erreur sont clairs et actionables. Pour un développeur, écrire des tests avec Cypress est presque agréable. C'est rare.
Le network stubbing natif. Cypress peut intercepter et modifier les requêtes réseau directement depuis le navigateur. C'est extrêmement puissant pour tester des scénarios edge-case (API lente, erreur 500, réponse vide) sans avoir à configurer un mock server externe.
La documentation. La documentation de Cypress est, sans exagération, parmi les meilleures de l'industrie open source. Chaque concept est expliqué clairement, avec des exemples fonctionnels et des guides de migration. C'est un avantage compétitif souvent sous-estimé.
Les faiblesses que les advocates de chaque camp minimisent
Les faiblesses de Selenium qu'on ne veut pas voir
La complexité de mise en place. Configurer un environnement Selenium fonctionnel — WebDriver, browser drivers, grid, reporting — reste fastidieux. En 2026, c'est encore un investissement significatif, même avec Docker et les outils de containerisation.
La fragilité des tests. Les tests Selenium sont notoirement fragiles. Un changement mineur dans le DOM (un attribut qui change, un élément qui se charge une milliseconde plus tard) peut casser une suite de tests entière. Les équipes passent un temps considérable à maintenir des tests plutôt qu'à en écrire de nouveaux.
La lenteur relative. Le protocole WebDriver introduit une latence incompressible. Pour une suite de 1 000 tests, cette latence cumulée est significative. Selenium Grid atténue le problème par la parallélisation, mais ajoute de la complexité infrastructure.
Les faiblesses de Cypress qu'on ne veut pas voir
Le JavaScript obligatoire. Cypress ne supporte que JavaScript (et TypeScript). Si vos équipes de test sont en Java ou en Python, migrer vers Cypress signifie un changement de langage complet. Ce n'est pas un détail.
Les limitations multi-onglets et multi-domaines. Cypress a historiquement des limitations pour les scénarios impliquant plusieurs onglets ou plusieurs domaines. Des améliorations ont été apportées (cy.origin), mais certains scénarios complexes restent plus naturels avec Selenium.
La dépendance à un éditeur commercial. Cypress est open source, mais la société Cypress.io (maintenant partie de l'écosystème Cloud) propose des services payants (Cypress Cloud) pour le dashboard, la parallélisation, et l'analytics. Le modèle open-core crée une dépendance que certaines organisations préfèrent éviter.
La couverture navigateurs limitée. Cypress supporte Chrome, Edge, Firefox, et les navigateurs Chromium-based. Safari n'est pas supporté nativement. Pour les organisations qui doivent tester sur Safari (e-commerce B2C, par exemple), c'est une limitation réelle.
Le grand oublié : le test visuel
Voici le point que la plupart des comparatifs Cypress vs Selenium n'abordent pas, et que nous considérons comme le plus important.
Cypress et Selenium sont des outils de test fonctionnel. Ils vérifient que votre application se comporte correctement : un clic sur ce bouton mène à cette page, ce formulaire affiche ce message d'erreur, cette API retourne ces données. Ils répondent à la question : « Est-ce que ça marche ? »
Mais ils ne répondent pas à la question : « Est-ce que ça ressemble à ce que ça devrait ? »
Un test Cypress qui vérifie que le bouton « Ajouter au panier » est présent et cliquable ne vous dira jamais que ce bouton est passé de vert à gris parce qu'un fichier CSS a été mal mergé. Un test Selenium qui valide le flux de paiement ne détectera pas que le formulaire de carte bancaire se superpose au récapitulatif de commande sur mobile.
Ces bugs visuels sont invisibles aux tests fonctionnels. Et ils sont les premiers que vos utilisateurs remarquent.
Les plugins de test visuel : une réponse insuffisante
Oui, Cypress a des plugins de test visuel. Oui, Selenium peut être combiné avec des bibliothèques de comparaison d'images. Mais soyons honnêtes sur les limitations :
La maintenance est lourde. Ces plugins sont des add-ons, pas des fonctionnalités natives. Ils ajoutent de la complexité à votre suite de tests, nécessitent une configuration spécifique, et introduisent des dépendances supplémentaires à maintenir.
Le workflow est technique. Pour utiliser un plugin de test visuel dans Cypress ou Selenium, vous devez écrire du code. Cela exclut les designers, les product owners, et les QA non-techniques — exactement les personnes qui sont les mieux placées pour juger si une interface « ressemble à ce qu'elle devrait ».
La gestion des baselines est primitive. Les plugins de test visuel pour Cypress et Selenium stockent généralement les baselines dans le repo Git, sans workflow d'approbation, sans historique visuel exploitable, et sans dashboard dédié.
Les faux positifs sont endémiques. Sans gestion fine des seuils de tolérance, des zones d'exclusion, et du rendu anti-aliasing, les plugins de test visuel génèrent un volume de faux positifs qui décourage rapidement les équipes.
La solution : un outil dédié
Notre position est claire : pour le test visuel, utilisez un outil dédié. Pas un plugin, pas un add-on, pas un hack. Un outil dont c'est la raison d'être.
Un outil de test visuel dédié offre ce que les plugins ne peuvent pas offrir : une interface de revue visuelle conçue pour la comparaison d'images, une gestion des baselines avec workflow d'approbation, des seuils de tolérance intelligents qui réduisent les faux positifs, et une accessibilité pour les profils non-techniques.
C'est exactement ce que fait Delta-QA : du test visuel, et rien d'autre. Pas de scripts à écrire, pas de framework à configurer, pas de dépendances à maintenir. Vous comparez visuellement vos pages, vous détectez les régressions, et vous approuvez les changements intentionnels. C'est tout.
Notre position : choisissez selon votre besoin, pas selon la hype
Le débat Cypress vs Selenium est un faux dilemme pour beaucoup d'équipes, parce qu'il pose la mauvaise question. La vraie question n'est pas « quel est le meilleur outil ? » — c'est « quel est le meilleur outil pour mon contexte ? »
Choisissez Selenium si votre organisation utilise plusieurs langages de programmation, si vous avez besoin d'une couverture Safari native, si vous avez déjà un investissement significatif dans l'écosystème Selenium, ou si vous avez besoin du Selenium Grid pour des tests distribués à grande échelle.
Choisissez Cypress si votre stack est JavaScript/TypeScript, si l'expérience développeur est une priorité, si vous avez besoin de tests rapides et stables, et si vos scénarios ne nécessitent pas de multi-onglets ou multi-domaines complexes.
Et dans les deux cas, ajoutez un outil de test visuel dédié. Ni Cypress ni Selenium ne couvrent cet angle, et c'est un angle que vos utilisateurs remarquent en premier.
FAQ
Playwright n'a-t-il pas rendu ce débat obsolète ?
Playwright est effectivement un concurrent sérieux qui mérite sa place dans la discussion. Développé par Microsoft, il combine certaines forces de Selenium (multi-navigateurs, multi-langages) et de Cypress (architecture moderne, auto-wait). Cependant, en 2026, Cypress et Selenium dominent encore en termes de base installée et d'écosystème. Playwright monte rapidement, mais il n'a pas encore rendu les deux autres obsolètes — il a ajouté une troisième option.
Peut-on utiliser Cypress et Selenium ensemble dans le même projet ?
Techniquement oui, mais c'est rarement une bonne idée. Maintenir deux frameworks de test signifie deux configurations, deux ensembles de bonnes pratiques, et deux courbes d'apprentissage. Si vous migrez de Selenium vers Cypress, faites-le progressivement par module plutôt que de maintenir les deux indéfiniment.
Cypress vs Selenium : lequel est le plus rapide en 2026 ?
Pour les suites de tests de taille moyenne (quelques centaines de tests), Cypress est généralement plus rapide grâce à son architecture in-browser. Pour les très grandes suites (milliers de tests), Selenium Grid avec parallélisation massive peut être compétitif. La réponse dépend de votre volume et de votre infrastructure.
Le test visuel peut-il remplacer les tests fonctionnels Cypress ou Selenium ?
Non. Le test visuel et le test fonctionnel couvrent des angles différents. Le test fonctionnel vérifie le comportement (est-ce que ça marche ?), le test visuel vérifie l'apparence (est-ce que ça ressemble à ce que ça devrait ?). Un bouton peut être visuellement correct mais ne pas fonctionner au clic, et inversement. Les deux sont nécessaires pour une couverture complète.
Quel est le coût réel de la migration de Selenium vers Cypress ?
Le coût dépend de la taille de votre suite de tests existante, du langage utilisé (si vous êtes en Java, la migration implique un changement de langage), et de la complexité de vos scénarios. Pour une suite de 500 tests Selenium en JavaScript, comptez 2 à 4 mois pour une équipe de 2-3 personnes. Le coût principal n'est pas la réécriture des tests — c'est l'adaptation des patterns et des pratiques.
Pourquoi Delta-QA plutôt qu'un plugin de test visuel pour Cypress ?
Un plugin de test visuel dans Cypress vous contraint au workflow technique de Cypress : vous devez écrire du code, exécuter les tests dans le pipeline, et gérer les baselines dans Git. Delta-QA est un outil autonome accessible à toute l'équipe — designers, PMs, QA non-techniques — avec une interface dédiée à la comparaison visuelle, des workflows d'approbation, et une gestion fine des seuils de tolérance. Pour le test fonctionnel, utilisez Cypress ou Selenium. Pour le test visuel, utilisez un outil conçu pour cela.
Conclusion : le bon outil au bon endroit
Cypress et Selenium sont deux excellents outils de test fonctionnel. Le choix entre les deux dépend de votre stack, de votre équipe, et de vos contraintes — pas d'un classement abstrait.
Mais quel que soit votre choix, vous aurez un angle mort : le test visuel. Ni Cypress ni Selenium n'ont été conçus pour détecter les régressions visuelles, et les plugins qui tentent de combler ce manque restent des solutions de compromis.
Pour le test visuel, vous méritez un outil dédié. Un outil qui fait une seule chose, et qui la fait bien.