Lost Pixel vs Delta-QA : par quoi remplacer Lost Pixel après son arrêt ?

Lost Pixel vs Delta-QA : par quoi remplacer Lost Pixel après son arrêt ?

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 parlait directement aux développeurs front-end qui vivent dans l'univers des composants.

Mise à jour (10/2026). Le 22 avril 2026, les fondateurs de Lost Pixel ont annoncé l'arrêt du produit : l'équipe rejoint Figma. Le dépôt GitHub est archivé, et la dernière version publiée sur npm (3.22.0) date de novembre 2024. Le code reste disponible sous licence MIT, mais il n'évoluera plus. Ce comparatif garde sa description de l'outil, utile si vous l'utilisez encore, et vous aide à choisir la suite.

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 vers quoi migrer : un autre outil centré sur les composants, ou une approche qui teste vos pages réelles comme Delta-QA. 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.

Tous nos comparatifs, sur des critères vérifiables : Alternatives et comparatifs.

Détecter les régressions visuelles sans toucher à npm ni à un fichier de config. Delta-QA s'utilise en no-code, avec un compte gratuit et sans carte bancaire. Essayer Delta-QA gratuitement →

Lost Pixel : le spécialiste des composants

Lost Pixel est un outil open source de test de régression visuelle, désormais archivé. 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) ajoutait un workflow de review et d'approbation des baselines ; avec l'arrêt annoncé, ne comptez plus sur elle pour un nouveau projet.

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.

Les développeurs n'en sont pas exclus pour autant : ceux qui écrivent leurs tests en Playwright disposent désormais du SDK Vision, une ligne par page à vérifier, dans le même espace que les scénarios enregistrés sans code.

L'approche no-code

Avec Delta-QA, vous créez un compte gratuit. Vous entrez l'URL de votre site. Vous naviguez normalement, comme un utilisateur le ferait. Chaque étape du parcours devient un point de contrôle. Lors de l'exécution suivante, Delta-QA rejoue le parcours dans un vrai navigateur, compare chaque page à sa référence 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.

La comparaison comme l'œil humain au lieu des pixels

Là où Lost Pixel compare des images pixel par pixel, Delta-QA compare la page comme le ferait l'œil humain et restitue en clair l'élément qui a changé. 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.

Cette approche limite aussi les faux positifs. Une variation d'anti-aliasing ou de sous-pixel ne change ni la couleur, ni la taille, ni la position d'un élément : elle n'a pas de raison d'être signalée. Ce qui reste à juger, ce sont les changements qui touchent réellement la page.

L'option On-Premise

Pour les organisations qui l'exigent, Delta-QA propose une offre On-Premise installée en Docker sur votre infrastructure : aucune donnée ne quitte votre réseau, pas de screenshots envoyés sur un serveur distant.

Le SaaS reste l'entrée la plus rapide : compte gratuit, sans carte bancaire. L'offre On-Premise s'évalue, elle, par un POC gratuit d'un mois.

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.

L'open source pour Storybook, c'est puissant mais ça se configure. Delta-QA détecte vos régressions visuelles sans une ligne de configuration : compte gratuit, no-code et sans carte bancaire. Essayer Delta-QA gratuitement →

Ce que Lost Pixel faisait bien

Ses forces expliquent pourquoi des équipes l'ont adopté, et ce qu'il faudra retrouver ailleurs.

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 et la version self-hosted était gratuite. La plateforme cloud était payante, à des tarifs accessibles ; elle est concernée par l'arrêt annoncé.

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.

L'open source. Le code reste lisible et réutilisable sous licence MIT. Mais un dépôt archivé ne reçoit plus de correctifs : à chaque mise à jour de Storybook, de Playwright ou de Node.js, c'est à vous d'assurer la compatibilité.

Ce que Delta-QA apporte en plus

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.

La qualité des résultats. Chaque différence est rattachée à un élément de la page et décrite en clair. Vous savez quoi a changé : 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. Avec l'installation On-Premise, aucune donnée ne quitte votre réseau : aucun service cloud tiers, aucun transfert externe. 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 la création du compte au premier parcours enregistré, comptez quelques minutes avec Delta-QA. Avec Lost Pixel, il fallait installer le package, écrire la configuration, avoir un Storybook fonctionnel, configurer le CI : 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.

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 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, et donc dans un outil qui ne teste que les stories. 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 : par quoi remplacer Lost Pixel

Si votre besoin est centré sur Storybook, cherchez un outil de composants maintenu : Chromatic, édité par l'équipe de Storybook, en est l'exemple le plus direct (voir notre comparatif Chromatic et Delta-QA et nos pistes pour un test visuel Storybook sans Chromatic). Lost Pixel reste exécutable tel quel, mais sans correctifs.

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 et des parcours, pas seulement des composants isolés. Si vous voulez des résultats lisibles, rattachés aux éléments de la page. Si la souveraineté des données est un critère, avec l'offre On-Premise. Si vous voulez être opérationnel en minutes, pas en heures.

Combinez les deux niveaux si vous voulez une couverture complète : un outil de composants dans le pipeline CI pour surveiller les briques de base, et Delta-QA pour tester les pages complètes, impliquer les profils non techniques, et vérifier l'intégration visuelle avant chaque release.

Prêt à tester vos pages réelles sans rien configurer ? Lancez votre première comparaison avec Delta-QA, avec un compte gratuit et sans carte bancaire. Essayer Delta-QA gratuitement →

Questions fréquentes

Lost Pixel est-il encore maintenu ?

Non. Le 22 avril 2026, ses fondateurs ont annoncé l'arrêt du produit et leur arrivée chez Figma. Le dépôt GitHub est archivé et la dernière version npm (3.22.0) date de novembre 2024. Le code reste utilisable sous licence MIT, mais sans correctifs ni évolutions : prévoyez une migration.

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.

Delta-QA détecte-t-il les mêmes problèmes que la comparaison pixel de Lost Pixel ?

Delta-QA détecte les changements visibles des éléments : couleurs, tailles, marges, polices, positions, bordures, en vous donnant le détail de chaque changement. En revanche, les changements internes à une image modifiée ou un contenu textuel différent sont détectés différemment par les deux approches.

Faut-il Storybook pour utiliser Lost Pixel ?

Non, Lost Pixel pouvait aussi tester des pages web complètes en mode « page shots ». Mais son intégration Storybook était sa principale proposition de valeur. Pour le test de pages, d'autres outils maintenus, dont Delta-QA, prennent le relais.

Quel outil est le plus rapide à mettre en place ?

Delta-QA. Création du compte, ouverture de votre site, navigation : votre premier parcours est enregistré en quelques minutes. Lost Pixel nécessitait npm, un fichier de configuration, un Storybook (ou un mode page) opérationnel, et idéalement un pipeline CI configuré : une à deux heures pour un développeur expérimenté.

Comment passer de Lost Pixel à Delta-QA ?

Les baselines de Lost Pixel sont des images propres à sa logique pixel : elles ne se transfèrent pas. Vous enregistrez vos parcours principaux dans Delta-QA, qui crée ses propres références au premier passage. Pour les tests Playwright de vos développeurs, le SDK Vision ajoute une vérification Delta-QA en une ligne par page.