Delta-QA vs Cypress : Pourquoi le Test Visuel Manque à Votre Suite Cypress
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.
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 propose aucune fonctionnalité native de test visuel. Zéro. Rien dans la boîte.
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. Les bugs visuels représentent une proportion significative des problèmes signalés en production — jusqu'à 70% selon les études Forrester sur l'expérience utilisateur numérique. 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. C'est une approche 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. L'entropie logicielle est un adversaire patient — une IA de jeu de Go qui ne fait jamais d'erreur et qui exploite chaque complexité que vous ajoutez à votre système.
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 scanne vos pages directement. Vous n'avez pas besoin d'un test fonctionnel comme véhicule pour capturer un screenshot. Votre couverture visuelle ne dépend pas de votre couverture fonctionnelle. Vous pouvez tester visuellement 200 pages sans écrire un seul test fonctionnel, et c'est exactement ce que font les équipes qui veulent une couverture visuelle rapide et exhaustive.
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 baselines. Delta-QA intègre un workflow complet de gestion des baselines : comparaison visuelle côte à côte, approbation ou rejet des changements, historique des modifications, alertes sur les régressions. 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 cross-browser intégré. Delta-QA teste nativement sur plusieurs navigateurs sans configuration supplémentaire. Avec Cypress, le cross-browser est une source de friction permanente : la compatibilité Safari/WebKit est un sujet récurrent dans la communauté, et chaque navigateur nécessite sa propre configuration de test.
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
Soyons clairs sur 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.
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.
Delta-QA fait ça mieux : le test visuel
La couverture exhaustive. Couvrir visuellement l'intégralité d'une application de 100 pages × 4 résolutions × 3 navigateurs prend quelques minutes de configuration 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 manuellement, et de résoudre les incompatibilités cross-browser du plugin. Un projet d'une semaine contre une configuration d'une heure. Le calcul est vite fait.
Le workflow d'approbation. Quand Delta-QA détecte un changement visuel, votre designer peut le valider directement dans l'interface. Pas besoin de passer par un développeur, pas besoin de comprendre le rapport Cypress, pas besoin de savoir ce qu'est une baseline ou un diff. L'outil parle le langage des personnes qui jugent la qualité visuelle : des images côte à côte, un overlay de différences, un bouton approuver/rejeter.
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. Une animation qui n'est pas au même frame ? Faux positif. Delta-QA gère ces situations avec des zones d'exclusion, une tolérance intelligente, et une normalisation des rendus qui réduisent drastiquement les faux positifs sans masquer les vraies régressions.
L'historique visuel. Delta-QA maintient un historique des baselines et des changements visuels au fil du temps. Vous pouvez retracer l'évolution visuelle d'une page sur plusieurs semaines ou mois. Avec un plugin Cypress, vos baselines sont des fichiers dans Git — techniquement 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 un excellent outil de test visuel. 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 correct. Les couleurs, la typographie, les espacements, la mise en page, la cohérence cross-browser. C'est la couche visuelle de votre assurance qualité.
Les deux couches tournent dans votre pipeline CI/CD. Les deux génèrent des alertes quand quelque chose casse. Les deux peuvent bloquer un déploiement si un problème est détecté. Mais chacune regarde une dimension différente de la qualité, et chacune le fait 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 Delta-QA réduit à zéro 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 à configurer vos URLs, vos résolutions cibles, et vos navigateurs. Puis à lancer une première capture pour établir vos baselines. C'est tout. La couverture visuelle est active, et elle est indépendante de vos tests Cypress.
Dans votre pipeline CI/CD, vous ajoutez une étape Delta-QA qui tourne en parallèle de vos tests Cypress. Les deux étapes sont indépendantes, les deux peuvent bloquer le déploiement, les deux génèrent leurs propres rapports. Pas de conflit, pas de dépendance, pas de configuration croisée.
FAQ
Cypress va-t-il ajouter du test visuel natif un jour ? C'est une question récurrente dans la communauté Cypress. À ce jour, l'équipe Cypress n'a pas annoncé de fonctionnalité native de test visuel. Le modèle économique de Cypress Cloud est centré sur le test fonctionnel — parallélisation, analytics, flake detection. L'ajout d'un test visuel natif nécessiterait une infrastructure de stockage et de comparaison d'images que Cypress n'a pas aujourd'hui. Et même si Cypress ajoutait cette fonctionnalité, elle resterait couplée à l'exécution des tests fonctionnels — ce qui conserverait le problème de couverture couplée que nous avons décrit.
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 ? Delta-QA tourne en parallèle de vos tests Cypress. La durée totale de votre pipeline ne change pas si les deux étapes s'exécutent simultanément. La capture et la comparaison de screenshots sont des opérations optimisées. En pratique, l'ajout de Delta-QA à un pipeline CI/CD n'impacte pas significativement le temps de livraison.
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, analytics, détection de tests flaky. Delta-QA couvre la dimension visuelle que Cypress Cloud n'adresse pas. Les deux sont des investissements complémentaires, pas concurrents. Le budget est le seul facteur de tension, et il se résout en comparant le coût de Delta-QA au coût des bugs visuels en production.
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. Delta-QA est indépendant de tout framework de test fonctionnel. Que vous utilisiez Cypress, Playwright, Selenium, TestCafe, ou aucun framework du tout, Delta-QA fonctionne de la même manière. C'est un outil autonome qui n'a besoin que d'une URL pour commencer à tester.
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.