Delta-QA vs Percy : Test Visuel Structurel ou Screenshots dans le Cloud ?

Test visuel par capture d'écran (screenshot testing) : méthode de détection de régressions visuelles consistant à capturer une image complète d'une page ou d'un composant web, puis à la comparer pixel par pixel avec une image de référence — toute différence au-delà d'un seuil configurable étant signalée comme une régression potentielle.

Percy a longtemps été le nom qui venait en premier quand on parlait de test visuel automatisé. Racheté par BrowserStack en 2020, l'outil s'est installé comme la solution « évidente » pour les équipes qui veulent ajouter une couche de comparaison visuelle à leur pipeline de test. Et pendant longtemps, c'était effectivement la meilleure option disponible — par défaut plus que par excellence, mais la meilleure quand même.

Le paysage a changé. Et la question que chaque équipe devrait se poser aujourd'hui n'est plus « comment intégrer Percy dans nos tests ? » mais « est-ce que l'approche de Percy est toujours la plus pertinente pour notre besoin ? ».

Delta-QA propose une réponse radicalement différente au même problème. Pas de screenshots, pas de cloud, pas de SDK, pas de facture au screenshot. Une approche structurelle, locale, no-code et gratuite. Comparons les deux sans détour.

Percy : le test visuel comme extension de vos tests existants

Percy fonctionne selon un principe simple en apparence : à des points stratégiques de vos tests automatisés, vous déclenchez une capture d'écran. Cette capture est envoyée sur les serveurs de BrowserStack, où elle est comparée pixel par pixel avec une image de référence (la baseline). Les différences sont affichées dans un tableau de bord web où votre équipe peut approuver ou rejeter chaque changement.

L'idée est élégante. L'exécution l'est moins.

Pour utiliser Percy, vous devez d'abord avoir des tests automatisés — Cypress, Playwright, Selenium, Puppeteer, ou l'un des nombreux frameworks supportés. Vous installez ensuite le SDK Percy correspondant à votre framework. Vous modifiez vos tests pour ajouter des appels de capture aux endroits pertinents. Vous configurez un token d'authentification pour communiquer avec les serveurs Percy. Et vous priez pour que votre pipeline CI ait une connexion réseau suffisamment stable pour envoyer des screenshots haute résolution à chaque exécution.

Si vous êtes un développeur à l'aise avec les outils de test, tout cela est faisable en quelques heures. Si vous n'êtes pas développeur — et une proportion significative des personnes responsables de la qualité visuelle ne le sont pas — vous dépendez entièrement de quelqu'un d'autre pour mettre en place et maintenir votre outil de test visuel.

Delta-QA : le test visuel comme activité autonome

Delta-QA repose sur un postulat inverse : le test visuel ne devrait pas être un greffon sur vos tests fonctionnels. C'est une activité à part entière, avec ses propres besoins, ses propres utilisateurs, et ses propres contraintes.

Concrètement, vous fournissez à Delta-QA deux versions d'une page (deux URLs, deux environnements, ou deux moments dans le temps), et l'outil analyse les différences structurelles entre elles. Pas de captures d'écran envoyées dans le cloud. Pas de comparaison pixel. Delta-QA examine le DOM, les propriétés CSS calculées, et la hiérarchie des éléments pour identifier ce qui a changé.

Le résultat est un rapport clair des différences significatives : éléments ajoutés, supprimés, modifiés, déplacés, avec les propriétés CSS affectées. Pas d'interprétation floue, pas de « ce pixel a changé de couleur d'une nuance imperceptible ». Des faits structurels, vérifiables et explicables.

Et tout cela sans écrire une seule ligne de code. Si vous pouvez utiliser un navigateur web, vous pouvez utiliser Delta-QA. Cette phrase n'est pas un slogan marketing — c'est littéralement la réalité de l'interface.

Code vs no-code : pourquoi ça change tout

La différence la plus fondamentale entre Percy et Delta-QA n'est pas technique — elle est organisationnelle.

Percy est un outil de développeur. Il vit dans le code, il s'installe via npm ou pip, il se configure dans des fichiers de configuration, et il s'exécute dans des pipelines CI/CD. C'est parfaitement logique quand vos testeurs sont des développeurs. C'est un mur quand ils ne le sont pas.

Pensez à votre équipe. Qui se soucie de la qualité visuelle de votre produit ? Les développeurs, certes. Mais aussi les designers qui ont créé les maquettes. Les product owners qui ont validé les parcours utilisateur. Les QA managers qui définissent les critères d'acceptation. Les responsables marketing qui gèrent les pages de contenu. Aucune de ces personnes ne devrait avoir besoin d'écrire du code pour vérifier que le site a l'air correct.

Percy les exclut structurellement du processus de test visuel. Ils peuvent consulter les résultats dans le tableau de bord — approuver ou rejeter les changements — mais ils ne peuvent pas configurer de nouveaux tests, ajouter de nouvelles pages à surveiller, ou ajuster les paramètres de détection. Ils sont des consommateurs passifs d'un outil conçu pour d'autres.

Delta-QA les inclut. Toute personne de l'équipe peut lancer une comparaison visuelle, ajouter des pages à surveiller, configurer des seuils de sensibilité, et interpréter les résultats. Le test visuel devient une responsabilité partagée au lieu d'une tâche technique déléguée.

La facture au screenshot : un modèle qui punit la rigueur

Le modèle économique de Percy mérite une attention particulière, parce qu'il crée un incitatif pervers.

Percy facture au nombre de screenshots par mois. Les plans commencent avec un quota de screenshots inclus, et chaque screenshot supplémentaire au-delà du quota est facturé. Plus vous testez, plus vous payez. Plus vous êtes rigoureux dans votre couverture visuelle, plus la facture augmente.

Réfléchissez un instant à ce que cela signifie en pratique. Vous avez un site e-commerce avec 500 pages produit. Vous voulez vérifier visuellement chaque page après chaque déploiement. C'est 500 screenshots par déploiement. Si vous déployez quotidiennement, c'est 15 000 screenshots par mois. Si vous testez sur trois résolutions (desktop, tablette, mobile), c'est 45 000 screenshots par mois. Le plan qui couvre ce volume ne sera pas celui à 400 dollars.

Ce modèle crée une tension malsaine entre la couverture de test et le budget. Les équipes finissent par limiter les pages testées, réduire la fréquence des tests, ou tester sur moins de résolutions — non pas parce que c'est la bonne décision technique, mais parce que le budget l'impose. Le modèle économique de l'outil dégrade activement la qualité des tests.

Delta-QA ne facture rien. Pas par screenshot, pas par page, pas par mois. Vous testez autant de pages que vous voulez, aussi souvent que vous voulez, sur autant de résolutions que vous voulez. La rigueur de votre couverture de test est limitée par votre ambition, pas par votre portefeuille.

Cloud vs local : la souveraineté de vos données

Chaque screenshot envoyé à Percy transite par les serveurs de BrowserStack et y est stocké. Pour la plupart des sites publics, ce n'est pas un problème. Mais les sites publics ne sont qu'une fraction de ce que les équipes testent.

Qu'en est-il de votre backoffice d'administration ? De votre tableau de bord interne avec les données clients ? De votre environnement de staging avec les données de production anonymisées (ou pas toujours parfaitement anonymisées) ? De votre portail médical, de votre interface bancaire, de votre système de gestion RH ?

Envoyer des screenshots de ces pages sur les serveurs d'un tiers, même un tiers de confiance certifié SOC 2, pose des questions que certaines organisations ne peuvent pas ignorer. Les réglementations sectorielles (RGPD, HDS, PCI-DSS), les politiques de sécurité internes, et le bon sens en matière de protection des données imposent des limites à ce qui peut transiter par des serveurs externes.

Delta-QA élimine la question. L'outil s'exécute localement. Vos pages sont analysées localement. Les résultats restent locaux. Aucune donnée ne quitte votre environnement. Ce n'est pas une fonctionnalité premium ou une option de déploiement enterprise — c'est l'architecture de base de l'outil.

La stabilité des résultats : pixels capricieux vs structure fiable

Quiconque a utilisé un outil de test visuel basé sur les screenshots sait que les faux positifs sont le fléau de l'approche. Percy a fait des progrès significatifs avec des algorithmes de comparaison intelligents, des seuils de sensibilité configurables, et des zones d'exclusion. Mais le problème fondamental demeure : comparer des pixels est intrinsèquement instable.

Le rendu d'une police varie d'un système d'exploitation à l'autre. L'anti-aliasing diffère selon la carte graphique. Les animations capturées à des moments légèrement différents produisent des images différentes. Les contenus dynamiques (dates, compteurs, publicités) changent entre les captures. Les images chargées depuis un CDN peuvent arriver dans un ordre différent. Un scroll-bar qui apparaît ou disparaît décale tous les éléments de quelques pixels.

Chacun de ces cas génère un « diff » dans Percy qui n'est pas un bug réel. Et chaque faux positif consomme du temps : quelqu'un doit regarder le diff, décider que ce n'est pas un vrai problème, et l'approuver. Multipliez par des centaines de screenshots et des dizaines de déploiements, et vous obtenez des heures de travail gaspillées à trier des faux positifs. Il y a des choses plus passionnantes dans la vie — à peu près toutes, en fait.

L'approche structurelle de Delta-QA est immunisée contre ces problèmes. Le rendu de la police peut varier — la structure CSS reste identique. L'anti-aliasing peut différer — les propriétés CSS calculées ne changent pas. Le contenu textuel peut se mettre à jour — la hiérarchie DOM et les styles restent stables. Le taux de faux positifs de l'approche structurelle est une fraction de celui de l'approche screenshot.

L'intégration CI/CD : deux approches, même destination

Percy s'intègre dans les pipelines CI/CD via son SDK. C'est une intégration mature qui fonctionne bien avec les grands systèmes CI (GitHub Actions, GitLab CI, Jenkins, CircleCI). Mais elle ajoute une dépendance réseau : si les serveurs Percy sont lents ou indisponibles, votre pipeline est impacté.

Delta-QA s'intègre également dans les pipelines CI/CD, mais sans SDK ni dépendance externe. L'outil s'exécute localement sur votre runner CI. Pas de latence réseau, pas de timeout si un service tiers est down. Votre pipeline ne dépend que de votre propre infrastructure.

Quand Percy reste le bon choix

Percy est un bon outil dans certains contextes spécifiques.

Vous voulez le test visuel comme complément de vos tests fonctionnels existants. Si vous avez déjà une suite de tests Cypress ou Playwright robuste, ajouter Percy à cette suite est la voie de moindre résistance. Vous ajoutez des captures aux moments clés de vos tests, et votre couverture visuelle est immédiatement opérationnelle.

Vous avez besoin de test cross-browser visuel. Percy peut capturer des screenshots sur différentes combinaisons navigateur/résolution via l'infrastructure BrowserStack. Si vérifier le rendu visuel sur Chrome, Firefox, Safari et Edge simultanément est une exigence, Percy offre cette capacité.

Votre équipe est composée exclusivement de développeurs. Si les seules personnes qui feront du test visuel sont des développeurs à l'aise avec les SDKs et les pipelines CI/CD, la barrière d'entrée de Percy est négligeable.

Quand Delta-QA est la meilleure option

Le test visuel est un besoin en soi, pas une extension de vos tests fonctionnels. Si vous voulez du test visuel indépendamment de vos tests automatisés — ou si vous n'avez tout simplement pas de tests automatisés — Delta-QA est autonome.

Des non-développeurs doivent participer au test visuel. QA, designers, product owners, marketing — si ces profils doivent pouvoir lancer et interpréter des tests visuels sans passer par un développeur, Delta-QA est le seul choix réaliste.

Le budget est limité ou vous refusez la facturation au volume. Si vous ne voulez pas que votre couverture de test soit dictée par votre budget screenshots, la gratuité de Delta-QA élimine cette contrainte.

La confidentialité des données est non négociable. Si vos pages contiennent des données sensibles ou si vos politiques de sécurité interdisent l'envoi de screenshots sur des serveurs tiers, l'approche locale de Delta-QA est la seule option conforme.

Vous en avez assez des faux positifs. Si vous avez déjà expérimenté le test visuel par screenshots et que le tri des faux positifs vous a fait abandonner, l'approche structurelle de Delta-QA vous réconciliera avec le test visuel.

Le verdict sans filtre

Percy est un outil mature, bien intégré dans l'écosystème BrowserStack, et efficace pour les équipes de développeurs qui veulent ajouter une couche visuelle à leurs tests automatisés. C'est un bon outil pour son cas d'usage spécifique.

Mais ce cas d'usage est plus étroit que ce que le marketing de Percy suggère. La majorité des équipes n'ont pas besoin d'un SDK, d'un service cloud, et d'une facturation au screenshot pour détecter les régressions visuelles. Elles ont besoin d'un outil simple, rapide, accessible à tous, et qui ne punit pas la rigueur de test avec une facture croissante.

Delta-QA est cet outil. Pas parce qu'il est plus sophistiqué que Percy — il ne l'est pas, et il ne prétend pas l'être. Mais parce qu'il résout le problème du test visuel avec moins de friction, moins de coût, et plus d'accessibilité. Et dans le monde réel, l'outil qui se fait adopter est toujours plus utile que l'outil qui impressionne.

FAQ

Percy est-il gratuit ?

Percy propose un plan gratuit limité à un certain nombre de screenshots par mois (le seuil a varié au fil du temps). Au-delà, les plans payants commencent à plusieurs centaines de dollars par mois et escaladent selon le volume de screenshots. Pour un usage professionnel sérieux avec une couverture de test significative, le plan gratuit est insuffisant. Delta-QA est gratuit sans limitation de volume.

Peut-on utiliser Percy sans écrire de code ?

Non. Percy nécessite l'intégration d'un SDK dans un framework de test automatisé. Même les solutions d'intégration les plus simples (Percy CLI avec des URLs) nécessitent l'utilisation d'un terminal et de commandes en ligne. Delta-QA est entièrement no-code — l'interface web suffit pour configurer et exécuter des tests visuels.

L'approche structurelle détecte-t-elle les mêmes bugs que les screenshots ?

Elle détecte la grande majorité des régressions visuelles — celles causées par des changements de CSS, de structure HTML, ou de mise en page. Elle ne détecte pas les problèmes de rendu graphique pur (corruption d'image, problème de webfont, bug de rendu spécifique à un navigateur) qui nécessitent une comparaison visuelle pixel. Pour la plupart des équipes, les régressions structurelles représentent plus de 90% des bugs visuels rencontrés en pratique.

Percy gère-t-il les pages avec authentification ?

Oui, mais uniquement dans le cadre de vos tests automatisés. Votre script de test doit gérer l'authentification (login, cookies, tokens), et ensuite Percy capture les screenshots des pages authentifiées. Avec Delta-QA, l'accès aux pages authentifiées est direct puisque l'outil s'exécute dans votre environnement local où vous avez déjà accès à vos applications.

Combien de temps gagne-t-on en éliminant les faux positifs ?

Les équipes utilisant des outils de test visuel basés sur les screenshots rapportent régulièrement que le tri des faux positifs représente entre 30% et 60% du temps consacré au test visuel. Sur une semaine type avec 20 déploiements et des centaines de screenshots, ce sont plusieurs heures de travail humain consacrées à approuver des différences qui ne sont pas des bugs. L'approche structurelle de Delta-QA réduit drastiquement ce ratio.

Percy et Delta-QA peuvent-ils coexister ?

Absolument. Vous pouvez utiliser Percy dans vos tests automatisés pour la comparaison pixel de composants critiques, et Delta-QA en parallèle pour la couverture quotidienne de l'ensemble de vos pages. Les deux outils sont indépendants et ne se marchent pas sur les pieds. C'est même une combinaison judicieuse si vous voulez le meilleur des deux approches.