Imaginez que vous standardisiez votre CI sur l'un des trois outils open source de tests de régression visuelle que tout le monde présélectionne (BackstopJS, Argos, Lost Pixel), pour découvrir, une semaine après le début du chantier, que deux des trois ne sont pas ce qu'ils semblaient être vus de l'extérieur. Argos dispose d'un excellent code sur GitHub, mais son mainteneur affirme clairement que l'auto-hébergement n'est ni pris en charge ni documenté. Lost Pixel a été archivé le 22 avril 2026, lorsque l'équipe a rejoint Figma, sans fournir aucune voie de migration aux équipes qui l'utilisaient déjà.
Il ne reste donc qu'un seul des trois qui soit véritablement auto-hébergeable et maintenu aujourd'hui. C'est étrange à dire pour une catégorie qui offre autant de choix en apparence, mais c'est bien là qu'en est le paysage. Les outils que l'on traite comme trois équivalents sont, en pratique, une option auto-hébergée qui fonctionne, un outil solide qui vit sur les serveurs de quelqu'un d'autre, et un troisième que vous devriez quitter.
Voici un tour d'horizon axé sur l'auto-hébergement des outils de tests de régression visuelle auto-hébergés qui résistent à l'épreuve du réel : lequel correspond à quelle contrainte, et que faire si vous utilisez Lost Pixel en ce moment.
La version courte
- BackstopJS est l'option auto-hébergeable, maintenue, sous licence MIT et sans aucun coût. Puppeteer par défaut avec prise en charge de Playwright, comparaison au pixel près via Resemble.js et une interface de revue HTML (avec des réserves sur le rendu Docker que vous devrez anticiper).
- Argos est l'outil le plus solide côté flux de travail (revue de PR et comparaison de snapshots ARIA depuis fin 2025), mais c'est en pratique un SaaS géré. Le mainteneur ne fournit aucun support ni aucune documentation pour l'exécuter vous-même.
- Lost Pixel a été archivé en avril 2026. Ne l'adoptez pas pour de nouveaux projets, et si vous l'utilisez, planifiez votre migration dès maintenant.
Le verdict en une ligne : pour un pipeline CI entièrement auto-hébergé, BackstopJS est le choix pragmatique. Si vous voulez le meilleur flux de revue et pouvez accepter une dépendance SaaS, Argos est le meilleur outil.
(Ce que cet article ne couvre pas : les tests visuels basés sur Cypress, les flux de travail de composants propres à Storybook et des chiffres de benchmark issus de tests concrets. Cette comparaison repose sur des faits de première main, pas sur un banc d'essai que j'aurais exécuté moi-même.)
Le paysage des tests de régression visuelle auto-hébergés a changé
Deux événements précis survenus au cours de l'année écoulée ont remodelé cette présélection, et il est facile de passer à côté des deux si vous vous appuyez sur un article rédigé avant qu'ils ne se produisent.
Le premier : dans une discussion GitHub de septembre 2025, un mainteneur d'Argos a déclaré qu'Argos ne fournit aucun support ni aucune documentation pour son exécution en dehors du service géré. Le code est sous licence MIT et disponible librement, donc « vous pouvez l'auto-héberger » est techniquement vrai, mais il n'existe aucune voie prise en charge, une distinction qui compte énormément dès lors que c'est vous qui êtes d'astreinte.
Le second : le dépôt Lost Pixel a été archivé le 22 avril 2026, en lecture seule, lorsque l'équipe a annoncé qu'elle rejoignait Figma. Aucune consigne de migration n'a accompagné cet arrêt. Un outil qui était, il y a peu encore, une alternative gratuite et auto-hébergée légitime à Percy et Chromatic est désormais une dépendance sans mainteneur.
Les deux changements pointent dans la même direction. La raison pour laquelle les équipes en arrivent là, une tarification SaaS qui croît selon le nombre de navigateurs multiplié par les fenêtres d'affichage multipliées par les pages, ou une règle de conformité interdisant d'envoyer à un tiers des captures d'écran d'interfaces non publiées, n'a pas disparu. Ce qui a changé, c'est que le menu de l'auto-hébergement est plus court qu'il n'y paraît.
À retenir de cette section : un seul des trois outils que les gens présélectionnent est aujourd'hui véritablement auto-hébergeable et activement maintenu.
BackstopJS : l'option véritablement auto-hébergeable
L'installation se fait via npm install -g backstopjs (ou une installation locale dans le projet), et ce seul fait explique en grande partie pourquoi BackstopJS l'emporte sur l'axe de l'auto-hébergement : il n'y a aucun service à rétro-concevoir, aucun backend géré dont il dépendrait en secret. Il s'exécute comme un paquet npm ou un conteneur Docker sur une infrastructure qui vous appartient, sous licence MIT, sans aucun coût de licence. Le README indique que la version actuelle (6.3.x) prend en charge Node 20.
En interne, il pilote Puppeteer par défaut (Chrome sans interface) et prend aussi en charge Playwright sur chromium, firefox et webkit. La comparaison se fait au pixel près via Resemble.js, avec une valeur configurable misMatchThreshold qui détermine à partir de quel écart de pixels un test est considéré comme un échec. Les validations passent par un rapport HTML doté d'une interface dans le navigateur pour accepter les changements.
C'est au niveau des limites que se prend une décision stratégique. BackstopJS n'a pas de flux intégré de blocage de PR : il vous signalera qu'une différence existe, mais c'est à vous de la brancher sur une barrière du type « cette PR ne peut pas être fusionnée ». Sa configuration réside dans du JSON, un scénario à la fois, et à quelques centaines de cas de test, ce JSON devient à lui seul une surface de maintenance. Le développement est lent plutôt que rapide : le projet n'est pas archivé, le paquet en est actuellement à la version 6.3.25, et le dépôt affiche environ 7 200 étoiles GitHub et 516 tickets ouverts. Considérez donc BackstopJS comme mature et utilisable, non comme une plateforme de tests visuels en évolution rapide.
Le risque opérationnel le plus marqué concerne le rendu Docker. Deux tickets, des captures d'écran blanches ou tronquées dans Docker (#1156) et des résultats incohérents après la mise à niveau Docker v5.3.0 (#1303), sont ouverts depuis des années sans résolution. Or Docker est justement ce que vous voulez pour la CI, car il normalise le rendu d'une machine à l'autre. Ainsi, l'outil qui vous offre le plus de contrôle vous livre aussi une catégorie d'instabilité connue et non corrigée, précisément dans la configuration où vous l'utiliserez. C'est un risque planifiable, pas un obstacle rédhibitoire, mais il doit être posé sur la table avant que vous ne vous engagiez.
Astuce de pro, le piège des références multi-OS : si vos développeurs capturent les références sur macOS et que vos runners CI sont sous Linux, vos tests échoueront sur les seules différences d'anticrénelage des polices, avant même la moindre régression réelle. Comme l'a documentéun praticien, le rendu des polices diffère entre l'image Linux utilisée sur les services CI et une machine macOS locale, suffisamment pour faire échouer un test visuel à lui seul. La solution consiste à générer et comparer les références dans un seul environnement (exécutez BackstopJS en local dans la même image Docker que celle utilisée en CI), afin que les images de référence et de comparaison proviennent d'un rendu identique.
Argos : le meilleur flux de travail, mais un SaaS en pratique
Argos réussit l'expérience de revue là où BackstopJS échoue, et c'est toute la raison de sa présence dans cette liste malgré la réserve sur l'auto-hébergement. Il s'intègre à Playwright, Cypress, Storybook, WebdriverIO et Puppeteer, et se branche sur GitHub Actions, GitLab CI, Bitbucket et Azure DevOps. Le flux de revue de PR est un élément de produit à part entière, et il n'a cessé d'évoluer. De récentes entrées du changelog ajoutent des revues collaboratives avec des commentaires épinglés (juin 2026) et l'ignorance automatique des changements instables.
Son différenciateur technique le plus intéressant est la comparaison. En plus de la comparaison déterministe au pixel près, Argos a ajouté la comparaison de snapshots ARIA pour son SDK Playwright le 4 novembre 2025. La comparaison de snapshots ARIA compare l'arbre d'accessibilité (rôles, libellés et structure) en parallèle de la capture d'écran au pixel près, ce qui détecte une catégorie de régressions sémantiques et d'accessibilité qu'une simple comparaison de pixels peut manquer (un bouton qui semble identique mais qui a perdu son libellé accessible, par exemple). Pour les équipes engagées sur l'accessibilité, c'est une véritable capacité que les outils purement pixel n'offrent pas.
Vient ensuite la contrainte. Le code est sous MIT, mais le produit, c'est le service géré, et le mainteneur a été explicite : l'auto-hébergement n'est ni documenté ni pris en charge. Vous pouvez le déployer à partir des sources. Vous le faites simplement en sachant que tout changement en amont peut casser votre déploiement et que personne n'est tenu de vous aider. Il existe une incertitude connexe qu'il vaut mieux signaler qu'affirmer : des retours de la communauté suggèrent que l'intégration à GitLab Self-Managed exige un plan Enterprise (je considère cela comme un signal de la communauté, pas comme une spécification confirmée, alors vérifiez-le sur votre propre configuration avant d'en faire un facteur de décision).
Cela crée un vide inconfortable. Une équipe avec des exigences strictes de confidentialité (précisément celle qui est la plus motivée à s'auto-héberger) et qui veut aussi l'expérience de revue d'Argos n'a aucune bonne voie. Elle peut utiliser le service géré et accepter la dépendance à un tiers, ou s'auto-héberger sans support, ou choisir un autre outil. Il n'y a pas de quatrième porte propre, et il est plus honnête de le dire que de prétendre que la licence open source la referme.
À retenir de cette section : Argos est l'outil le plus solide. L'auto-héberger n'est pas pris en charge et reste fragile en exploitation.
Lost Pixel : archivé, et que faire si vous l'utilisez
La propre bannière du dépôt Lost Pixel résume toute l'histoire en une ligne : le dépôt a été archivé par son propriétaire le 22 avril 2026, et il est désormais en lecture seule. L'équipe a rejoint Figma, la dernière version était la v3.22.0 en novembre 2024, et aucune consigne de migration n'a été publiée.
Jusqu'à l'archivage, Lost Pixel était un choix raisonnable (rendu basé sur Docker, prise en charge de Playwright et Storybook ainsi que de Ladle et Histoire, et tests visuels aussi bien de pages entières qu'au niveau des composants). Rien de tout cela n'a changé techniquement le 22 avril. Ce qui a changé, c'est qu'il n'a plus de mainteneur, plus de correctifs de sécurité et plus de feuille de route, ce qui, pour une dépendance CI, est disqualifiant pour de nouveaux projets, quelle que soit la qualité d'exécution de la version actuelle.
Si vous l'utilisez aujourd'hui, la migration se divise selon l'usage que vous en faisiez. Si vous vous appuyiez sur ses tests au niveau des composants, en particulier les flux Storybook ou Ladle, votre remplacement le plus proche est le service géré Argos ou les tests de captures d'écran natifs de Playwright. BackstopJS peut capturer des sélecteurs ou des URL Storybook, mais il ne vous offre pas le même flux de composants intégré que Lost Pixel, si bien que vous devriez modéliser ces états de composants vous-même. Si vous l'utilisiez pour la régression visuelle de pages entières, BackstopJS en est le successeur auto-hébergé direct. Dans les deux cas, le changement n'est pas urgent au sens « vos builds vont casser demain », mais le compte à rebours est lancé : un outil de test non maintenu se dégrade discrètement à mesure que vos versions de navigateur, d'OS et de framework s'éloignent de celles pour lesquelles il a été compilé pour la dernière fois.
Comparaison en un coup d'œil
Voici les mêmes informations sous forme de tableau comparatif, afin que vous puissiez parcourir les axes qui comptent pour une décision CI avant de les rapporter à vos propres contraintes.
| Axe | BackstopJS | Argos | Lost Pixel |
|---|---|---|---|
| Licence | MIT | Code MIT, produit SaaS géré | MIT |
| Réalité de l'auto-hébergement | Entièrement auto-hébergeable par conception | Possible mais non pris en charge ni documenté | Était auto-hébergeable, désormais archivé |
| État de la maintenance | Maintenu, à évolution lente et mature | Actif (service géré) | Archivé le 22 avril 2026 |
| Approche de comparaison | Comparaison de pixels (Resemble.js) | Comparaison de pixels plus comparaison de snapshots ARIA | Comparaison de pixels (non maintenue) |
| Prise en charge des frameworks et moteurs | Puppeteer (par défaut), Playwright | Playwright, Cypress, Storybook, WebdriverIO, Puppeteer | Playwright, Storybook, Ladle, Histoire (au moment de l'archivage) |
| Flux de revue | Rapport HTML, validation manuelle, pas de barrière de PR | Revue de PR, commentaires collaboratifs, blocage de PR | Sans objet (archivé) |
| Coût | Gratuit | Tarification SaaS (basée sur les snapshots) | Gratuit mais non maintenu |
Comment choisir (cadre de décision)
Partez de votre contrainte la plus forte, pas d'une liste de fonctionnalités. La contrainte élimine pour vous la plus grande partie du menu.
- Entièrement auto-hébergé, budget nul, et vous pouvez accepter des tests limités aux pages entières avec revue manuelle : BackstopJS. C'est la seule option qui soit à la fois auto-hébergée, maintenue et gratuite, et les compromis (pas de barrière de PR, configuration en JSON, instabilité de Docker) sont des données connues que vous pouvez contourner par conception.
- Vous voulez la meilleure expérience de revue, le blocage de PR et la comparaison ARIA, et vous pouvez accepter une dépendance SaaS : le service géré Argos. C'est la voie vers les points forts d'Argos sans le risque de l'auto-hébergement non pris en charge. Si une règle de conformité interdit l'envoi de captures d'écran à un tiers, cette porte est fermée et vous revenez à BackstopJS.
- Petite suite de tests ou approche Playwright d'abord : envisagez de n'ajouter aucun outil dédié. Playwright intègre
toHaveScreenshot()nativement, et pour des suites d'environ moins de 100 tests, cela peut vous suffire. Un guide de praticien situe le point d'inflexion où un outil dédié commence à justifier son coût autour de cette échelle (considérez cela comme une observation du secteur, pas comme un chiffre officiel de Playwright). La charge de gestion des fichiers de référence dans git croît au-delà de ce point, et c'est là qu'un outil dédié se rentabilise. - Actuellement sur Lost Pixel : migrez maintenant, selon la répartition de la section précédente. Ne prenez pas « ça marche encore » comme une raison de rester.
Une réserve qui précède tous ces outils et leur survit : l' équipe Sparkbox, il y a des années, avait choisi une option hébergée précisément parce qu'amener les ingénieurs à réellement utiliser les tests était plus difficile que la mise en place. Un outil auto-hébergé doté d'une interface de revue plus faible peut l'emporter sur le coût et perdre sur l'adoption (si votre équipe ignore un rapport BackstopJS bruyant, son coût de licence nul ne vous aura rien apporté). Intégrez l'expérience de revue dans la décision, pas seulement le prix.
À retenir de cette section : c'est la contrainte qui choisit l'outil. Auto-hébergé-et-gratuit désigne BackstopJS, meilleur-flux-et-SaaS-acceptable désigne Argos, et petit-et-Playwright-d'abord peut ne désigner aucun outil.
Dimensionner le runner CI pour Chromium sans interface
Les trois outils pilotent Chromium sans interface, et c'est l'empreinte mémoire de Chromium (pas le CPU) qui détermine la taille de votre runner, car chaque worker de navigateur concurrent réclame ses propres quelques gigaoctets de RAM. Sous-dimensionnez la machine et vos tests visuels n'échouent pas proprement. Ils sont tués par le mécanisme OOM en cours d'exécution et remontent comme du bruit d'infrastructure instable, le pire type d'échec à déboguer.
À titre indicatif approximatif, dimensionné selon le parallélisme plutôt qu'en chiffres fermes (l'usage réel dépend de la complexité des pages et du nombre de workers exécutés en parallèle) :
- Petite équipe ou tests en série : environ 2 vCPU / 4 GB RAM gèrent un seul worker Chromium sans interface avec la surcharge du démon CI.
- Usage CI en équipe : environ 4 vCPU / 8 GB RAM prennent en charge à peu près 2 à 4 workers de navigateur en parallèle, ce qui correspond à la plupart des équipes.
- Débit élevé ou grandes suites : environ 8 vCPU / 16 GB RAM pour un parallélisme élevé, ou lorsque l'exécution de la régression visuelle partage un runner avec d'autres tâches CI.
Le stockage est le poste discret. Les artefacts de captures d'écran et les références historiques s'accumulent d'une exécution à l'autre, alors prévoyez cette croissance : réservez une marge de stockage généreuse si vous conservez les références en local, ou poussez les références et les artefacts vers un stockage objet pour que le disque du runner ne soit pas la contrainte.
Un VPS est l'hôte naturel pour un runner CI auto-hébergé qui fait cela, car vous voulez une RAM dédiée et prévisible pour les workers Chromium, et une machine de homelab n'a de sens que si le matériel est déjà là. Si vous montez aussi la pile CI environnante, les briques autour de l'outil de test visuel se déploient en un clic dans la marketplace Cloudzy : Gitea, GitLab, Jenkins et Forgejo pour la forge CI, et Docker pour la cohérence de rendu dont les outils ont besoin. L'outil de régression visuelle lui-même s'installe par-dessus via npm ou Docker, alors provisionnez un Linux VPS dimensionné à partir des fourchettes ci-dessus et exécutez-le là. Si vous mettez en place une CI basée sur Docker, les guides Cloudzy sur les alternatives auto-hébergées à GitLab et listant les conteneurs Docker couvrent la configuration adjacente.
Foire aux questions
Argos est-il auto-hébergeable ?
Techniquement oui (le code est sous licence MIT), mais le mainteneur a déclaré en septembre 2025 qu'Argos ne fournit aucun support ni aucune documentation pour son exécution en dehors du service géré. Considérez l'auto-hébergement comme non pris en charge et fragile en exploitation : il peut casser à tout changement en amont sans que le mainteneur soit tenu de vous aider. Pour la plupart des équipes, le service géré est la manière pratique de profiter des avantages d'Argos.
Qu'est-il arrivé à Lost Pixel ?
Lost Pixel a été archivé le 22 avril 2026, lorsque l'équipe a rejoint Figma et a arrêté le produit. Le dépôt est en lecture seule, la dernière version était la v3.22.0 en novembre 2024, et aucune consigne de migration n'a été fournie. Ne l'adoptez pas pour de nouveaux projets. Si vous l'utilisez, planifiez une migration vers BackstopJS (tests de pages entières) ou Argos et le mode natif de Playwright (tests de composants).
Qu'est-ce que la comparaison de snapshots ARIA ?
La comparaison de snapshots ARIA compare l'arbre d'accessibilité (rôles, libellés et structure) en parallèle de la capture d'écran au pixel près, ce qui détecte des régressions sémantiques et d'accessibilité qu'une simple comparaison de pixels peut manquer, comme un bouton visuellement identique qui a perdu son libellé accessible. Argos a ajouté cette fonctionnalité le 4 novembre 2025.
De combien de RAM Chromium sans interface a-t-il besoin en CI ?
Un seul worker en série s'exécute généralement dans environ 2 à 4 GB, et les workers concurrents font croître la RAM à peu près linéairement à partir de là. L'usage réel dépend de la complexité des pages et du nombre d'instances de navigateur exécutées en parallèle, alors considérez ces valeurs comme des repères plutôt que des chiffres fermes et laissez de la marge pour éviter que des exécutions de tests ne soient tuées par le mécanisme OOM.
BackstopJS prend-il en charge Playwright ?
Oui. Puppeteer est le moteur par défaut (Chrome sans interface), et BackstopJS prend aussi en charge Playwright sur chromium, firefox et webkit. Vous sélectionnez le moteur dans votre configuration.
