Régression visuelle : changement non intentionnel de l'apparence d'une interface utilisateur — mise en page, couleurs, typographie, espacement, alignement — introduit par une modification de code, une mise à jour de dépendance ou un changement de configuration, et détectable uniquement par comparaison automatisée entre deux états de l'interface.
Lost Pixel a su se tailler une place intéressante dans l'écosystème du test visuel. Open source, spécialisé dans les composants Storybook et Ladle, intégrable dans les pipelines CI — c'est un outil qui parle directement aux développeurs front-end qui vivent dans l'univers des composants.
Mais voici la question que personne ne pose assez tôt dans l'évaluation : est-ce que votre besoin, c'est de tester des composants isolés dans Storybook, ou c'est de vérifier que votre site fonctionne visuellement en conditions réelles ?
La réponse à cette question détermine si vous avez besoin de Lost Pixel, de Delta-QA, ou potentiellement des deux. Et cette réponse dépend moins de la technologie que de la composition de votre équipe et de la nature de vos problèmes de qualité visuelle.
Lost Pixel : le spécialiste des composants
Lost Pixel est un outil open source de test de régression visuelle. Son terrain de prédilection : Storybook, Ladle, Histoire (les environnements de développement de composants UI) et les pages web statiques. L'outil capture des screenshots de vos composants ou pages et les compare entre les exécutions pour détecter les changements visuels.
L'intégration Storybook comme point fort
Si vous développez avec Storybook — et en 2026, une majorité d'équipes front-end React, Vue ou Angular le font — Lost Pixel se branche directement sur votre catalogue de stories. Chaque story devient automatiquement un test visuel. Pas besoin de lister manuellement les pages à tester ou d'écrire des scénarios de navigation : votre catalogue Storybook est votre suite de tests visuels.
C'est une proposition de valeur claire et immédiatement compréhensible pour un développeur front-end. Vous maintenez déjà vos stories pour la documentation et le développement de composants. Lost Pixel les transforme en tests de régression visuelle sans effort supplémentaire.
L'outil supporte aussi Ladle (l'alternative légère à Storybook) et Histoire (pour Vue), ce qui couvre l'essentiel de l'écosystème de développement de composants. Et au-delà des composants, Lost Pixel peut tester des pages web complètes en mode « page shots ».
Un outil pensé par et pour les développeurs
Lost Pixel s'installe via npm, se configure dans un fichier de configuration TypeScript ou JavaScript, et s'exécute en ligne de commande. L'intégration CI est documentée pour GitHub Actions, et la plateforme Lost Pixel (en version cloud) ajoute un workflow de review et d'approbation des baselines.
La courbe d'apprentissage est raisonnable pour un développeur. Si vous connaissez npm, les fichiers de configuration, et les GitHub Actions, vous pouvez être opérationnel en moins d'une heure. C'est plus simple qu'un Applitools ou un Percy — Lost Pixel ne vous noie pas sous les options et les intégrations.
Mais cette simplicité pour les développeurs est une barrière pour tout le monde. Si vous n'êtes pas développeur, installer un package npm, écrire un fichier de configuration, et configurer une GitHub Action est aussi accessible que de piloter un sous-marin sans formation.
La comparaison pixel-à-pixel
Lost Pixel compare des screenshots — des images capturées de vos composants ou pages. C'est l'approche la plus intuitive et la plus répandue dans le test visuel. Vous voyez littéralement ce qui a changé, superposé sur une image.
Cette approche a un mérite indéniable : elle est visuelle. Le rapport vous montre les différences de manière graphique. Vous n'avez pas besoin de comprendre le CSS pour voir qu'un bouton a bougé ou qu'une couleur a changé.
Mais elle a aussi une faiblesse structurelle : la sensibilité au bruit de rendu. Les variations d'anti-aliasing entre deux rendus, les différences de polices entre l'environnement local et le CI, les animations non synchronisées — tout cela génère des faux positifs. Lost Pixel offre un seuil de tolérance configurable, mais calibrer ce seuil correctement est un art délicat : trop sensible et vous croulez sous les faux positifs, trop tolérant et les vraies régressions passent inaperçues.
Delta-QA : le test visuel pour toute l'équipe
Delta-QA part d'un constat simple : le test visuel ne devrait pas être réservé aux développeurs. Les personnes les plus qualifiées pour juger de la qualité visuelle d'une interface — designers, QA fonctionnels, product owners — sont souvent exclues du processus parce que les outils existants exigent des compétences techniques.
L'approche no-code
Avec Delta-QA, vous installez une application desktop. Vous entrez l'URL de votre site. Vous naviguez normalement — comme un utilisateur le ferait. L'outil capture l'état structurel de chaque page visitée et crée des baselines. Lors de l'exécution suivante, il compare le nouvel état avec les baselines et vous montre ce qui a changé.
Pas de npm. Pas de fichier de configuration. Pas de ligne de commande. Pas de GitHub Actions. Si vous savez utiliser un navigateur web, vous savez utiliser Delta-QA.
Cette accessibilité n'est pas un compromis sur la puissance de l'outil — c'est un choix de conception qui élargit considérablement le périmètre des personnes capables de contribuer à la qualité visuelle. Un designer peut vérifier que ses spécifications sont respectées. Un QA fonctionnel peut intégrer le test visuel dans sa routine de validation. Un product owner peut s'assurer qu'un déploiement n'a rien cassé visuellement avant de donner le feu vert.
L'analyse structurelle au lieu des pixels
Là où Lost Pixel compare des images pixel par pixel, Delta-QA analyse les propriétés CSS calculées des éléments de la page. C'est une différence fondamentale qui change la nature des résultats.
Quand Delta-QA signale un changement, il ne vous montre pas un rectangle coloré sur une image. Il vous dit exactement ce qui s'est passé : « la font-size du titre est passée de 24px à 20px », « la couleur de fond du header a changé de #FFFFFF à #F8FAFC », « le padding du bouton a diminué de 16px à 12px ».
Ces informations sont directement actionnables. Vous savez quoi corriger, dans quelle règle CSS chercher, et comment vérifier que la correction est effective. Avec une comparaison d'images, vous savez que quelque chose a changé visuellement — trouver quoi exactement nécessite une investigation manuelle.
L'analyse structurelle élimine aussi les faux positifs par construction. Puisque Delta-QA ne regarde pas les pixels mais les propriétés CSS, les variations de rendu — anti-aliasing, polices, animations — ne génèrent pas de bruit. Ce qui est signalé est un vrai changement dans la structure CSS de votre page.
Le on-premise par défaut
Delta-QA fonctionne entièrement en local. Aucune donnée ne quitte votre machine. Pas de compte à créer, pas de service cloud à utiliser, pas de screenshots envoyés sur un serveur distant.
La version Desktop est gratuite et sans limite de snapshots. Tout est inclus, tout est local.
Le débat central : composants isolés vs pages réelles
Le choix entre Lost Pixel et Delta-QA cache un débat plus profond sur ce que signifie réellement « tester visuellement » une application.
L'approche composants : nécessaire mais insuffisante
Lost Pixel, via son intégration Storybook, teste des composants isolés. Chaque composant est rendu individuellement, dans un environnement contrôlé, avec des props définies. C'est excellent pour détecter les régressions au niveau du composant : un bouton dont le border-radius a changé, un champ de texte dont le placeholder a disparu, un badge dont la couleur est devenue incohérente.
Mais les bugs visuels les plus impactants ne se produisent pas au niveau du composant isolé. Ils se produisent quand les composants s'assemblent dans une page réelle. Un composant de navigation qui pousse le contenu de 50 pixels vers le bas. Un footer qui chevauche le contenu principal sur mobile. Une grille de cartes qui se casse quand un texte est plus long que prévu. Un modal qui ne centre plus correctement quand la fenêtre est redimensionnée.
Ces problèmes d'intégration visuelle sont invisibles dans Storybook, parce que Storybook ne montre pas l'intégration — il montre les briques individuelles. C'est comme tester chaque rouage d'une montre séparément et conclure que la montre fonctionne. Les rouages peuvent être parfaits individuellement et ne pas s'emboîter correctement une fois assemblés.
L'approche pages : la réalité de l'utilisateur
Delta-QA teste des pages réelles, dans un navigateur réel, avec le HTML, le CSS, le JavaScript, et les interactions réelles de votre application. Quand Delta-QA vous dit que votre page est visuellement correcte, c'est parce qu'elle l'est dans les conditions où vos utilisateurs la verront.
Ce n'est pas une abstraction, pas un environnement isolé, pas un rendu partiel. C'est votre page, dans son ensemble, avec toutes les interactions entre composants, tous les styles hérités, toutes les surcharges CSS, tous les effets de cascade.
Cette approche capture les bugs d'intégration visuelle que les tests de composants isolés manquent structurellement. Elle capture aussi les problèmes liés aux données réelles — un nom de 40 caractères qui déborde d'un champ, un prix à 5 chiffres qui casse un layout, une image manquante qui effondre une mise en page.
Lost Pixel fait ça mieux
La transparence exige de reconnaître les forces de Lost Pixel.
L'intégration Storybook native. Si vous maintenez un catalogue Storybook, Lost Pixel le transforme en suite de tests visuels sans effort. Chaque story devient un test. C'est une proposition de valeur exceptionnelle pour les équipes centrées sur les composants.
L'automatisation CI/CD. Lost Pixel s'intègre naturellement dans un pipeline GitHub Actions. Les tests visuels se déclenchent automatiquement à chaque pull request, sans intervention humaine. La couverture est continue et systématique.
Le coût. Lost Pixel est open source. La version self-hosted est gratuite. La plateforme cloud est payante, mais les tarifs sont accessibles. Pour une équipe de développeurs qui veut du test visuel sans budget conséquent, c'est un argument fort.
La granularité composant. Tester chaque composant individuellement permet de localiser les régressions au niveau le plus fin. Quand un composant change, vous savez immédiatement lequel, sans avoir à chercher dans une page complète. C'est un workflow efficace pour les développeurs qui travaillent composant par composant.
La communauté open source. Lost Pixel bénéficie d'une communauté active, d'un développement transparent, et de la possibilité de contribuer des améliorations. C'est un avantage culturel et pratique pour les équipes qui valorisent l'open source.
Delta-QA fait ça mieux
L'accessibilité totale. Aucun prérequis technique. Pas de npm, pas de CLI, pas de fichier de configuration, pas de GitHub Actions. Si vous savez naviguer sur un site, vous savez utiliser Delta-QA. C'est la différence entre un outil pour développeurs et un produit pour toute l'équipe.
La qualité des résultats. L'analyse structurelle produit des résultats précis, détaillés et sans faux positifs de rendu. Vous savez exactement quoi a changé et pourquoi — pas seulement « quelque chose a changé visuellement dans ce rectangle ».
La couverture d'intégration. Delta-QA teste des pages complètes, pas des composants isolés. Il capture les bugs d'intégration visuelle que les tests de composants manquent par conception — les problèmes de layout, les conflits de styles, les effets de données réelles sur la mise en page.
La souveraineté des données. Tout se passe en local. Aucune donnée ne quitte votre machine. Aucun compte à créer, aucun service cloud nécessaire. Pour les entreprises soumises au RGPD ou à des politiques de sécurité strictes, c'est un avantage structurel.
Le temps de mise en route. De l'installation au premier test visuel, comptez deux à trois minutes avec Delta-QA. Avec Lost Pixel, il faut installer le package, écrire la configuration, avoir un Storybook fonctionnel, configurer le CI — comptez plutôt une à deux heures pour un développeur expérimenté.
L'implication de toute l'équipe. Le test visuel sans code avec Delta-QA est une activité collaborative. Designers, QA, product owners et développeurs peuvent tous participer, lire les résultats, et approuver ou rejeter les changements. Avec Lost Pixel, le test visuel reste dans le domaine des développeurs.
Le cas typique : pourquoi les composants seuls ne suffisent pas
Prenons un scénario que toute équipe front-end a vécu. Vous avez un design system avec un composant Card utilisé partout sur votre site. Chaque Card a un titre, une image, une description, et un bouton. Dans Storybook, le composant est parfait — testé visuellement, toutes les variantes couvertes.
Un jour, un développeur modifie le CSS global du site. Il change la variable globale du line-height pour améliorer la lisibilité. Les tests Lost Pixel sur les composants Storybook passent — le line-height global n'affecte pas les stories isolées qui ont leur propre contexte. En production, la page catalogue qui affiche 12 Cards en grille est complètement cassée : le texte plus haut pousse les boutons, les Cards n'ont plus la même hauteur, la grille est visuellement incohérente.
Ce bug est invisible dans Storybook. Il est invisible dans Lost Pixel. Il est visible dans Delta-QA, parce que Delta-QA teste la page réelle avec le CSS global appliqué.
Ce n'est pas un cas extrême ou artificiel. C'est le quotidien du développement front-end : les composants vivent dans un écosystème, et leur comportement visuel dépend de cet écosystème. Tester les composants isolément est nécessaire, mais c'est une condition nécessaire, pas suffisante.
Le verdict : qui devrait choisir quoi
Choisissez Lost Pixel si vous êtes une équipe de développement front-end qui travaille avec Storybook ou Ladle. Si votre priorité est de détecter les régressions au niveau des composants individuels. Si vous avez un pipeline GitHub Actions et vous voulez des tests visuels automatisés à chaque pull request. Si votre équipe est exclusivement technique et à l'aise avec les outils en ligne de commande.
Choisissez Delta-QA si votre équipe inclut des profils non techniques qui doivent participer au test visuel. Si vous avez besoin de tester des pages complètes, pas seulement des composants isolés. Si vous voulez des résultats précis et actionnables sans faux positifs de rendu. Si la souveraineté des données est un critère. Si vous voulez être opérationnel en minutes, pas en heures.
Choisissez les deux si vous voulez une couverture complète. Lost Pixel dans le pipeline CI pour surveiller les régressions de composants à chaque pull request. Delta-QA sur les postes de l'équipe pour tester les pages complètes, impliquer les profils non techniques, et vérifier l'intégration visuelle avant chaque release. C'est la stratégie de test visuel la plus robuste : les composants ET les pages, les développeurs ET toute l'équipe.
Questions fréquentes
Lost Pixel est open source et gratuit — pourquoi choisir Delta-QA ?
Lost Pixel est gratuit en licence, mais il exige un investissement en temps et en compétences techniques : installation npm, configuration TypeScript, pipeline CI/CD, Storybook fonctionnel. Delta-QA est gratuit (version Desktop) ET accessible sans aucun prérequis technique. Le vrai coût d'un outil, ce n'est pas sa licence — c'est le temps que votre équipe met pour être productive avec.
Delta-QA peut-il tester des composants Storybook comme Lost Pixel ?
Delta-QA teste des pages web complètes, pas des composants isolés dans Storybook. Si vous accédez à votre Storybook via un navigateur, vous pouvez techniquement tester vos stories avec Delta-QA, mais ce n'est pas son usage principal. La force de Delta-QA est de tester l'intégration réelle de vos composants dans des pages complètes — exactement ce que Lost Pixel ne couvre pas.
La comparaison structurelle de Delta-QA détecte-t-elle les mêmes problèmes que la comparaison pixel de Lost Pixel ?
L'analyse structurelle de Delta-QA détecte tous les changements de propriétés CSS — couleurs, tailles, marges, polices, positions, bordures. Elle va même plus loin en vous donnant le détail exact de chaque changement. En revanche, les changements purement visuels non liés au CSS (une image modifiée, un contenu textuel différent) sont détectés différemment par les deux approches. Les outils sont complémentaires.
Faut-il Storybook pour utiliser Lost Pixel ?
Non, Lost Pixel peut aussi tester des pages web complètes en mode « page shots ». Mais son intégration Storybook est sa principale proposition de valeur. Sans Storybook, vous perdez l'avantage de la couverture automatique des composants — et à ce point, d'autres outils (dont Delta-QA) offrent une meilleure expérience pour le test de pages.
Quel outil est le plus rapide à mettre en place ?
Delta-QA, sans discussion. Installation de l'application, ouverture de votre site, navigation — vous testez en moins de trois minutes. Lost Pixel nécessite npm, un fichier de configuration, un Storybook (ou un mode page) opérationnel, et idéalement un pipeline CI configuré. Pour un développeur expérimenté, comptez une à deux heures. Pour un profil non technique, Lost Pixel n'est tout simplement pas une option.
Les deux outils peuvent-ils fonctionner ensemble ?
Oui, et c'est une stratégie recommandée. Lost Pixel surveille les régressions de composants dans le pipeline CI à chaque pull request — c'est votre filet de sécurité automatisé au niveau des briques de base. Delta-QA teste les pages complètes sur le poste de l'équipe — c'est votre vérification d'intégration visuelle. Les deux niveaux de test se complètent et couvrent des angles morts différents.