Régression visuelle : modification non intentionnelle de l'apparence d'une interface utilisateur (mise en page, couleurs, typographie, espacement, alignement) introduite par un changement de code, une mise à jour de dépendance, ou une modification de configuration, et détectable uniquement par comparaison visuelle entre deux états de l'interface.
Voici une vérité que beaucoup d'équipes utilisant Cypress préfèrent ignorer : votre suite de tests Cypress, aussi complète soit-elle, est structurellement aveugle à une catégorie entière de bugs. Les régressions visuelles passent à travers vos assertions comme de l'eau à travers une passoire, non pas parce que vos tests sont mal écrits, mais parce que Cypress n'a tout simplement pas été conçu pour les détecter.
Ce n'est pas une critique de Cypress. C'est un constat. Et la différence entre un constat et une critique, c'est que le constat appelle une solution, pas un débat.
Tous nos comparatifs, sur des critères vérifiables : Alternatives et comparatifs.
Votre suite Cypress confirme que tout marche, pas que tout s'affiche bien. Complétez-la avec Delta-QA : vos parcours enregistrés sans code, un compte gratuit et sans carte bancaire. Essayer Delta-QA gratuitement →
Cypress : excellent dans ce qu'il fait, absent là où ça compte visuellement
Cypress a révolutionné le test front-end quand il est arrivé sur le marché. L'exécution dans le navigateur, le rechargement automatique, le time-travel debugging, l'API intuitive (tout cela a rendu le test end-to-end accessible à des équipes qui considéraient Selenium comme un instrument de torture médiévale). Et dans le domaine du test fonctionnel, Cypress reste un outil remarquable.
Mais posez-vous cette question : quand avez-vous, pour la dernière fois, écrit un test Cypress qui vérifie que votre page d'accueil a l'air correcte ? Pas qu'un bouton existe. Pas qu'un texte est présent. Qu'elle a l'air correcte : que les espacements sont bons, que les couleurs sont cohérentes, que la mise en page n'a pas bougé d'un pixel.
La réponse, pour l'immense majorité des équipes, est « jamais ». Et ce n'est pas par négligence. C'est parce que Cypress ne compare pas d'images. Sa propre documentation le dit au 10/2026 : la commande cy.screenshot() capture une image, mais ne la compare pas ; le test visuel passe par des plugins ou des services tiers.
L'angle mort de Cypress : pas de comparaison visuelle native
Quand vous écrivez cy.get('.button').should('be.visible'), vous vérifiez que l'élément existe dans le DOM et n'est pas caché par du CSS. Vous ne vérifiez pas qu'il a la bonne couleur. Vous ne vérifiez pas qu'il est au bon endroit. Vous ne vérifiez pas que son texte est lisible. Vous ne vérifiez pas qu'il ne chevauche pas un autre élément.
Un bouton peut être « visible » au sens de Cypress (présent dans le DOM, display différent de none, opacity supérieure à 0) et être complètement inutilisable visuellement. Texte blanc sur fond blanc. Taille de 2 pixels par 2 pixels. Positionné à 3000 pixels à droite de l'écran. Cypress vous dira que tout va bien. Votre utilisateur vous dira autre chose.
C'est un angle mort fondamental, pas une limitation mineure. Une part importante des problèmes remontés par les utilisateurs touche l'affichage : un bouton illisible, un formulaire décalé, un bloc qui déborde. Et Cypress, dans sa configuration native, n'en détecte aucun.
Les plugins visuels de Cypress : une solution partielle et fragile
Face à ce manque, l'écosystème Cypress a produit des plugins de test visuel. Les plus connus s'appuient sur des services tiers (Percy, Applitools, Happo) pour capturer des screenshots et les comparer, ou sur cypress-image-snapshot pour une comparaison locale. Si vous cherchez le détail de chaque option, notre guide complet pour ajouter le test visuel à Cypress passe en revue ces approches et leurs limites réelles. C'est une voie qui fonctionne, mais avec des contraintes significatives.
La dépendance à un service tiers. Chaque plugin visuel pour Cypress repose sur une plateforme externe. Vos screenshots sont envoyés sur les serveurs d'un prestataire, comparés là-bas, et les résultats vous reviennent. Ça ajoute de la latence à votre pipeline CI, une dépendance réseau, et un coût de licence pour le service tiers, en plus du coût de Cypress Cloud si vous l'utilisez.
La complexité de configuration. Ajouter un plugin visuel à Cypress nécessite d'installer un package npm, de configurer l'authentification avec le service tiers, de modifier vos tests existants pour ajouter des appels de capture, de gérer les tokens d'API, et de former votre équipe à la plateforme externe. Ce n'est pas insurmontable, mais ce n'est pas non plus l'expérience « ça marche en 5 minutes » que promettent les pages marketing.
La maintenance double. Vous vous retrouvez à maintenir deux systèmes : vos tests Cypress et la configuration du plugin visuel. Quand Cypress se met à jour, le plugin peut casser. Quand le service tiers change son API, vos tests peuvent échouer. Quand votre équipe change, il faut former les nouveaux sur deux outils au lieu d'un.
La couverture limitée. Un plugin visuel intégré à Cypress capture des screenshots pendant l'exécution de vos tests fonctionnels. Ce qui signifie que la couverture visuelle dépend de la couverture fonctionnelle. Si vous n'avez pas de test Cypress pour la page « Conditions Générales de Vente », vous n'avez pas de test visuel pour cette page non plus. Votre couverture visuelle est plafonnée par votre couverture fonctionnelle, et les deux n'ont aucune raison de coïncider.
Delta-QA : le test visuel comme discipline autonome
Delta-QA part d'une philosophie différente. Le test visuel n'est pas une fonctionnalité greffée sur un outil de test fonctionnel. C'est une discipline à part entière, avec ses propres exigences, ses propres workflows, et ses propres utilisateurs.
L'indépendance vis-à-vis des tests fonctionnels. Delta-QA enregistre vos parcours en naviguant. Vous n'avez pas besoin d'un test fonctionnel comme véhicule pour capturer une page. Votre couverture visuelle ne dépend pas de votre couverture fonctionnelle : vous pouvez vérifier des dizaines de pages sans écrire un seul test.
L'accessibilité pour les non-développeurs. Qui sont les personnes les plus compétentes pour juger de la qualité visuelle d'une interface ? Les designers. Les QA manuels. Les product owners. Et ces personnes, dans la majorité des organisations, ne savent pas écrire du JavaScript. Avec Cypress + plugin visuel, elles dépendent d'un développeur pour configurer, lancer, et interpréter les tests. Avec Delta-QA, elles sont autonomes. C'est une différence qui change la dynamique d'une équipe.
La gestion native des références. Delta-QA intègre un workflow complet : rapport qui compare la page comme le ferait l'œil humain et nomme chaque élément changé, jugement de chaque différence (voulue ou bug), historique des modifications. Ce workflow est pensé pour des équipes pluridisciplinaires, pas pour un développeur solo qui push et merge dans la même matinée.
Le navigateur. Delta-QA rejoue vos parcours dans un vrai navigateur, Chromium aujourd'hui ; Firefox et WebKit sont prévus. Côté Cypress, Chrome, Edge et Firefox sont pris en charge, WebKit reste expérimental.
Le problème structurel des plugins : la loi de la couverture couplée
Reprenons ce point, parce qu'il mérite d'être développé. Quand votre test visuel est couplé à votre test fonctionnel (comme c'est le cas avec les plugins visuels de Cypress), votre couverture visuelle hérite de toutes les limitations de votre couverture fonctionnelle.
Vous avez un test Cypress pour le tunnel d'achat ? La couverture visuelle du tunnel d'achat est assurée. Vous n'avez pas de test Cypress pour la page FAQ ? Pas de couverture visuelle de la page FAQ. Votre test Cypress pour la page profil couvre le cas « utilisateur connecté avec abonnement premium » ? Vous avez une couverture visuelle pour ce cas, mais pas pour « utilisateur connecté sans abonnement » ou « utilisateur dont l'abonnement a expiré ».
La couverture fonctionnelle et la couverture visuelle ont des logiques différentes. En fonctionnel, vous testez des parcours : des séquences d'actions et de vérifications. En visuel, vous testez des états : des snapshots de pages dans des conditions données. Un parcours fonctionnel de 10 étapes peut n'avoir besoin que de 2 vérifications visuelles (page d'entrée et page de confirmation). Inversement, une page simple sans logique fonctionnelle complexe (une page « À propos ») peut nécessiter une vérification visuelle sur 5 résolutions et 3 navigateurs.
Coupler les deux, c'est forcer une discipline à adopter la couverture de l'autre. C'est comme dire que vous n'inspecterez visuellement une pièce d'usine que quand un ouvrier y entre pour utiliser une machine. Les jours où personne ne travaille dans cette pièce, les fuites d'eau passent inaperçues.
Cypress fait ça mieux : le test fonctionnel
Reconnaissons les forces de Cypress, parce qu'elles sont réelles et significatives.
L'expérience développeur. Cypress a été conçu par des développeurs pour des développeurs. L'interface de débogage avec time-travel, la rapidité d'exécution, l'API chaînée fluide (c'est un plaisir à utiliser). Delta-QA ne prétend pas offrir cette expérience parce que ce n'est pas son terrain de jeu.
La vérification de logique métier. Un tunnel de paiement qui calcule les taxes, les frais de port, et les codes promo correctement : c'est Cypress qui vérifie ça. Pas Delta-QA. La logique métier est invisible visuellement jusqu'à ce qu'elle produise un résultat affiché, et même là, vérifier que « le montant affiché est correct » nécessite de connaître le montant attendu, ce que seul un test fonctionnel peut calculer.
L'interception réseau. Cypress peut intercepter les requêtes HTTP, simuler des réponses serveur, tester des cas d'erreur. C'est un outil de test d'intégration front-end puissant qui va bien au-delà de la simple vérification d'interface.
Un écosystème Cloud qui s'étoffe. Au 10/2026, Cypress Cloud propose Test Replay pour rejouer un échec, UI Coverage, Cypress Accessibility, des résumés d'échecs générés par IA, et la commande cy.prompt() transforme des étapes écrites en langage naturel en commandes Cypress. Rien de cela ne compare l'apparence d'une page à une référence, mais l'outil progresse vite.
La vitesse d'exécution. L'architecture de Cypress, qui exécute les tests dans le même processus que l'application, offre une vitesse d'exécution remarquable pour les tests fonctionnels. Pas de latence réseau entre le test et l'application, pas de protocole WebDriver intermédiaire.
Votre suite Cypress valide la logique, pas l'apparence. Comblez ce manque avec Delta-QA : test visuel no-code, compte gratuit et sans carte bancaire. Essayer Delta-QA gratuitement →
Delta-QA fait ça mieux : le test visuel
La couverture rapide. Couvrir visuellement vos pages principales prend le temps de les parcourir dans Delta-QA. Obtenir la même couverture via un plugin Cypress nécessiterait d'écrire un test pour chaque page, de gérer les baselines et de stabiliser les captures. Des jours de travail d'un côté, quelques heures de navigation de l'autre.
Le workflow d'approbation. Quand Delta-QA détecte un changement, votre designer peut le juger directement dans l'interface. Pas besoin de passer par un développeur, pas besoin de comprendre le rapport Cypress. Le rapport parle le langage des personnes qui jugent la qualité visuelle : quel élément a changé, et comment.
La réduction des faux positifs. Les plugins visuels pour Cypress héritent souvent des limitations de la comparaison pixel-à-pixel brute. Un anti-aliasing de police différent entre deux exécutions ? Faux positif. Un caret de curseur qui apparaît dans un champ de texte ? Faux positif. Delta-QA compare les éléments de la page plutôt que ses pixels : une variation de rendu qui ne change ni la couleur, ni la taille, ni la position d'un élément n'est pas signalée.
L'historique visuel. Delta-QA conserve l'historique des références et des changements jugés. Vous pouvez retracer l'évolution d'une page au fil des versions. Avec un plugin Cypress local, vos baselines sont des fichiers dans Git (versionnés, mais sans interface pour visualiser leur évolution).
Le scénario typique : quand le plugin Cypress ne suffit plus
Imaginons un scénario courant. Votre équipe utilise Cypress depuis deux ans. Vous avez 300 tests fonctionnels. Votre couverture est bonne. Puis un jour, un refactoring CSS touche votre design system. La variable --color-primary change. Les tests Cypress passent tous, aucun d'entre eux ne vérifie les couleurs. En production, 30 pages ont un bouton d'action dont le contraste est devenu insuffisant pour être lisible. Le support reçoit 15 tickets en deux heures. Le correctif est déployé en urgence.
Après cet incident, votre lead technique décide d'ajouter un plugin visuel à Cypress. L'installation prend une demi-journée. La configuration de baselines pour 50 pages critiques prend une journée. Les premiers runs génèrent 47 faux positifs. Le tri des faux positifs prend une journée. Deux semaines plus tard, un développeur met à jour Cypress et le plugin n'est plus compatible. La suite visuelle est désactivée « temporairement ». Trois mois plus tard, elle est toujours désactivée.
Ce scénario n'est pas inventé : c'est le récit composite de dizaines de conversations avec des équipes QA. Le problème fondamental n'est pas le plugin. C'est que le test visuel greffé sur un outil de test fonctionnel n'est jamais prioritaire. C'est toujours « le truc en plus » qu'on fait quand on a le temps : c'est-à-dire jamais.
Delta-QA évite ce piège parce que le test visuel est la raison d'être de l'outil, pas un ajout optionnel. Il n'y a pas de suite fonctionnelle qui prend la priorité. Il n'y a pas de configuration plus urgente à maintenir. Le test visuel est la priorité, et l'outil est construit autour de cette priorité.
La combinaison gagnante : Cypress + Delta-QA
La position que nous défendons n'est pas « abandonnez Cypress pour Delta-QA ». Ce serait absurde. Cypress est un excellent outil de test fonctionnel. Delta-QA est conçu pour la non-régression d'interface. La combinaison des deux donne une couverture QA que ni l'un ni l'autre ne peut offrir seul.
Cypress vérifie que votre application fonctionne. Les parcours utilisateur, la logique métier, les intégrations API, les cas d'erreur. C'est la couche fonctionnelle de votre assurance qualité.
Delta-QA vérifie que votre application a l'air correcte. Les couleurs, la typographie, les espacements, la mise en page. C'est la couche visuelle de votre assurance qualité.
Chaque couche a son rythme. Les tests Cypress tournent dans votre pipeline CI/CD ; les scénarios Delta-QA se rejouent à chaque version. Chacune regarde une dimension différente de la qualité, avec des outils optimisés pour cette dimension.
C'est comme avoir à la fois un système d'alarme et des caméras de surveillance. L'alarme détecte les intrusions (fonctionnel : quelqu'un est entré qui n'aurait pas dû). Les caméras montrent ce qui se passe (visuel : est-ce que tout a l'air normal). Les deux ensemble sont plus efficaces que chacun séparément.
L'argument du « on a déjà Cypress, ça suffit »
C'est l'objection la plus fréquente. « On a déjà investi dans Cypress, on ne va pas ajouter un autre outil. » C'est un argument compréhensible mais fallacieux. Vous avez déjà un marteau, mais ça ne fait pas de chaque problème un clou.
Si votre application a une interface utilisateur (et si vous lisez cet article, c'est probablement le cas), une partie significative de la valeur perçue par vos utilisateurs vient de l'apparence de cette interface. Pas de la logique métier sous-jacente, aussi brillante soit-elle. Un utilisateur ne voit pas votre architecture microservices. Il voit un bouton bleu, un formulaire aligné, une typographie cohérente.
Ne pas tester cette dimension, c'est parier que personne ne cassera jamais le CSS de votre application. C'est un pari que vous allez perdre. La question n'est pas si, mais quand. Et quand ça arrivera, le coût sera proportionnel au temps que la régression passe en production : un temps que l'on réduit en la détectant avant le déploiement.
Combien de temps pour ajouter Delta-QA à un setup Cypress existant
Si vous utilisez déjà Cypress et que vous voulez ajouter Delta-QA, voici ce que ça implique concrètement.
Delta-QA fonctionne indépendamment de Cypress. Vous n'avez pas besoin de modifier vos tests Cypress existants. Vous n'avez pas besoin d'installer un plugin. Vous n'avez pas besoin de toucher à votre configuration Cypress. Les deux outils coexistent sans conflit parce qu'ils ne partagent rien.
La mise en place de Delta-QA consiste à ouvrir votre site et à parcourir les scénarios à couvrir. Le premier passage établit les références. C'est tout : la couverture visuelle est active, indépendamment de vos tests Cypress.
Pour aller plus loin dans la CI, Delta-QA a désormais un SDK, Vision. Il couvre aujourd'hui Playwright, en TypeScript et JavaScript ; la prise en charge de Cypress est prévue ensuite. Avec Playwright, une ligne par page à vérifier suffit : une différence non jugée fait échouer le test, et le journal de la CI donne le lien du rapport.
FAQ
Cypress va-t-il ajouter du test visuel natif un jour ?
C'est une question récurrente dans la communauté Cypress. Au 10/2026, la documentation indique que Cypress ne compare pas lui-même les images et renvoie vers des plugins. Cypress Cloud s'enrichit (Test Replay, UI Coverage, Accessibility, fonctions d'IA comme cy.prompt()), mais sans comparaison visuelle à une référence. Et même si Cypress l'ajoutait, elle resterait couplée à l'exécution des tests fonctionnels : ce qui conserverait le problème de couverture couplée décrit plus haut.
Les plugins visuels de Cypress ne sont-ils pas suffisants ? Pour un usage basique, ils peuvent dépanner. Mais ils ajoutent une dépendance à un service tiers (avec son propre coût de licence), ils couplent la couverture visuelle à la couverture fonctionnelle, et leur maintenance est une charge supplémentaire. Si vous avez 10 pages et un développeur disponible pour maintenir le plugin, ça peut fonctionner. Si vous avez 100 pages et une équipe QA mixte, les limitations deviennent bloquantes.
Delta-QA peut-il détecter des bugs que Cypress ne détecte pas ? Oui, par définition. Cypress vérifie des assertions programmatiques : « cet élément contient ce texte », « cette URL est correcte », « cette requête a retourné un 200 ». Delta-QA vérifie l'apparence visuelle : « cette page a l'air identique à la version de référence ». Les bugs visuels (régressions CSS, problèmes de responsive, conflits de z-index, polices manquantes) sont invisibles aux assertions Cypress mais détectés par Delta-QA.
Est-ce que Delta-QA ralentit le pipeline CI/CD ? Vos scénarios Delta-QA enregistrés sans code ne passent pas par votre pipeline Cypress : ils ne le ralentissent pas. Pour une intégration dans la CI, le SDK Vision couvre aujourd'hui Playwright ; Cypress est prévu ensuite.
Faut-il choisir entre Cypress Cloud et Delta-QA ? Non. Les deux servent des objectifs différents. Cypress Cloud optimise vos tests fonctionnels Cypress : parallélisation, rejeu des échecs, détection de tests flaky, couverture d'interface et accessibilité. Delta-QA couvre la comparaison visuelle à une référence, que Cypress Cloud n'adresse pas. Les deux sont des investissements complémentaires.
Mon équipe QA n'est pas technique. Peuvent-ils utiliser Delta-QA sans aide développeur ? C'est précisément le cas d'usage pour lequel Delta-QA a été conçu. L'interface no-code permet à un testeur QA, un designer, ou un product owner de configurer, lancer, et interpréter les tests visuels sans aucune compétence en développement. C'est l'un des différenciateurs fondamentaux par rapport à un plugin Cypress, qui nécessite de modifier du code JavaScript pour ajouter des points de capture visuelle.
Peut-on utiliser Delta-QA avec un autre framework que Cypress ? Oui. Les scénarios Delta-QA sont indépendants de tout framework de test : que vous utilisiez Cypress, Playwright, Selenium, TestCafe, ou aucun framework, ils fonctionnent de la même manière. Et pour les équipes Playwright, le SDK Vision, permet d'ajouter une vérification Delta-QA dans un test existant.
Conclusion : ne laissez pas Cypress porter un fardeau qui n'est pas le sien
Cypress est un outil remarquable pour ce qu'il fait. Mais lui demander de couvrir le test visuel (via des plugins, des hacks, ou des assertions CSS bricolées), c'est lui imposer une mission pour laquelle il n'a pas été conçu. C'est comme équiper un sprinter d'un sac à dos de 20 kilos et s'étonner qu'il soit moins rapide.
Libérez Cypress. Laissez-le faire ce qu'il fait le mieux : tester que votre application fonctionne. Et confiez le test visuel à un outil conçu pour ça.
Prêt à couvrir l'angle mort visuel de votre suite de tests ? Lancez votre première comparaison avec Delta-QA, avec un compte gratuit et sans carte bancaire. Essayer Delta-QA gratuitement →