Delta-QA vs Chromatic : Composants Isolés ou Pages Complètes ?
Test visuel de composants (component visual testing) : méthode de vérification automatisée consistant à rendre des composants d'interface utilisateur de manière isolée — hors du contexte de la page complète — et à comparer leur apparence avec un état de référence validé, afin de détecter les régressions visuelles au niveau du design system avant qu'elles ne se propagent aux pages en production.
Il y a une question que les équipes front-end évitent soigneusement de se poser : « nos composants sont testés visuellement dans Storybook, mais est-ce que nos pages en production sont testées aussi ? ». La réponse, dans une majorité de cas, est non. Et cette lacune coûte cher, parce que les bugs visuels qui atteignent vos utilisateurs ne vivent pas dans Storybook — ils vivent dans les pages réelles, avec les données réelles, les interactions réelles, et les combinaisons de composants réelles.
Chromatic est un excellent outil pour tester des composants isolés. Delta-QA est conçu pour tester des pages complètes. Ce ne sont pas des concurrents au sens strict — ce sont des outils qui regardent le même problème depuis des altitudes différentes. Mais si vous devez en choisir un seul, ou si vous voulez comprendre ce que chacun apporte, ce comparatif va droit au but.
Chromatic : le gardien du design system
Chromatic, créé par les mainteneurs de Storybook, est l'extension naturelle de l'écosystème Storybook pour le test visuel. Le concept est brillant dans sa logique : vous avez déjà défini vos composants dans Storybook avec leurs différents états (stories). Chromatic capture un screenshot de chaque story à chaque commit, compare avec la baseline, et signale les changements.
C'est un workflow parfaitement intégré pour les équipes qui travaillent avec des design systems. Votre designer définit un bouton avec quatre variantes (primary, secondary, disabled, loading). Votre développeur implémente ces variantes et crée les stories correspondantes. Chromatic vérifie à chaque changement de code que les quatre variantes n'ont pas visuellement régressé. Si le border-radius du bouton change accidentellement, Chromatic le détecte avant que quiconque ne fasse une revue de code.
L'outil offre également une fonctionnalité de revue d'UI (UI Review) qui permet aux designers et aux développeurs de valider visuellement les changements avant le merge. C'est essentiellement une code review visuelle, et c'est réellement utile pour maintenir la cohérence d'un design system.
L'angle mort de Chromatic : le monde réel
Voici le problème que Chromatic ne résout pas — non pas par défaut de qualité, mais par choix architectural : les composants isolés ne se comportent pas comme les pages assemblées.
Un bouton testé isolément dans Storybook est rendu dans un environnement contrôlé : un viewport fixe, pas de voisins, pas de contexte CSS hérité, pas de données dynamiques, pas d'interactions avec d'autres composants. C'est précisément ce qui rend le test fiable au niveau du composant. Mais c'est aussi ce qui le rend aveugle aux problèmes d'assemblage.
Qu'est-ce qui casse visuellement en production ? Rarement un composant isolé. Ce qui casse, c'est la combinaison. Un composant de header qui chevauche un composant de navigation parce qu'un z-index a changé. Une grille de produits qui se désaligne parce qu'un composant carte a reçu un margin supplémentaire. Un formulaire qui déborde de son conteneur parce qu'un label est plus long que prévu dans une autre langue. Un footer qui remonte sur le contenu principal parce qu'une section intermédiaire a perdu sa hauteur minimale.
Ces bugs sont invisibles dans Storybook. Chaque composant, pris isolément, est visuellement correct. C'est leur assemblage qui pose problème. Et Chromatic, par conception, ne teste pas l'assemblage — il teste les briques, pas l'édifice.
Delta-QA teste l'édifice. L'outil compare des pages complètes, telles qu'elles sont rendues dans un navigateur réel, avec tous leurs composants assemblés, leurs styles hérités, leurs interactions, et leurs données. C'est le test de la réalité, pas le test du plan de l'architecte.
Le fossé entre Storybook et la production
Il y a un décalage structurel entre ce que Storybook montre et ce que la production affiche, et ce décalage est rarement discuté.
Les données. Dans Storybook, vos composants reçoivent des données mock — soigneusement choisies pour être représentatives et tenir dans la maquette. En production, ils reçoivent des données réelles — un nom de produit de 150 caractères qui n'avait pas été prévu, une image au ratio improbable, un prix avec un nombre de décimales variable, une liste de catégories qui remplit trois lignes au lieu d'une. Ces données réelles créent des situations visuelles que Storybook ne reproduit jamais.
Les styles hérités. Dans Storybook, chaque composant est rendu dans un sandbox CSS relativement propre. En production, les composants héritent des styles globaux, des resets CSS, des thèmes, des overrides contextuels, et parfois des styles tiers (widgets analytics, chatbots, bandeau cookies). Un composant peut être parfait dans Storybook et visuellement cassé en production à cause d'un conflit de styles qu'aucune story ne reproduit.
Les états dynamiques. Storybook teste des états prédéfinis — ceux que le développeur a jugé bon de documenter. En production, les composants passent par des états intermédiaires, des états d'erreur non prévus, des combinaisons d'états que personne n'a pensé à tester. Le formulaire avec une validation en cours, le bouton dans un conteneur flex qui se redimensionne, la carte produit avec une promotion qui ajoute un badge — chaque combinaison est un test visuel que Storybook ne couvre pas.
Delta-QA teste ce que vos utilisateurs voient réellement. Pas ce que Storybook promet qu'ils verront.
No-code vs Storybook : la question de l'audience
Chromatic s'adresse aux développeurs front-end qui travaillent avec Storybook. C'est une audience légitime et importante. Mais c'est une audience restreinte.
Pour utiliser Chromatic, vous devez avoir un projet Storybook configuré. Vous devez savoir écrire des stories. Vous devez comprendre le concept de baseline et de snapshot visuel. Vous devez être à l'aise avec un workflow basé sur les pull requests et l'intégration continue. En résumé : vous devez être développeur front-end.
Votre QA manager qui veut vérifier une page avant le release ? Il ne peut pas utiliser Chromatic directement. Votre product owner qui remarque un problème visuel en recette ? Il ne peut pas lancer un test. Votre designer qui veut comparer la maquette avec le résultat en production ? Il n'a pas accès au workflow Chromatic sans passer par un développeur.
Delta-QA ouvre le test visuel à toute l'équipe. Pas de Storybook requis. Pas de code. Pas de pipeline CI/CD à comprendre. Vous donnez deux URLs, vous lancez la comparaison, vous lisez le rapport. Le designer compare sa maquette avec la production. Le QA compare le staging avec la production. Le product owner compare la version actuelle avec la version précédente. Chacun est autonome.
Ce n'est pas de l'anti-intellectualisme technologique. C'est de la reconnaissance que la qualité visuelle concerne tout le monde, et que les outils devraient refléter cette réalité.
Composants vs pages : deux niveaux de test complémentaires
Plutôt que d'opposer Chromatic et Delta-QA, il est plus juste de les positionner comme deux niveaux d'une stratégie de test visuel complète.
Niveau composant (Chromatic) : vérifier que chaque brique du design system est visuellement conforme à ses spécifications. C'est le test unitaire du visuel. Il détecte les régressions au niveau le plus granulaire, au plus tôt dans le cycle de développement (avant même le merge).
Niveau page (Delta-QA) : vérifier que les pages assemblées, avec les données réelles et les styles en cascade, sont visuellement correctes. C'est le test d'intégration du visuel. Il détecte les problèmes d'assemblage, les conflits de styles, et les régressions qui n'existent que dans le contexte de la page complète.
Une équipe qui fait les deux a une couverture visuelle remarquable. Les régressions de composants sont détectées tôt par Chromatic. Les régressions de pages sont détectées par Delta-QA. Le filet de sécurité est double.
Mais si vous ne pouvez en choisir qu'un — par contrainte de budget, de temps, ou de ressources — la question devient : quel niveau de test protège le mieux vos utilisateurs ? Et la réponse, sans ambiguïté, est le niveau page. Parce que vos utilisateurs ne voient pas des composants. Ils voient des pages.
Le modèle économique : snapshots vs liberté
Chromatic facture au nombre de snapshots par mois. Un snapshot = une story, un navigateur, une résolution. Avec 200 composants à 3 stories chacun sur 2 navigateurs, c'est 1 200 snapshots par build. Vingt builds par jour (une équipe active), c'est 720 000 par mois.
Le plan gratuit offre 5 000 snapshots mensuels — suffisant pour un petit projet, épuisé en quelques jours sur un design system de taille moyenne. Les plans payants escaladent avec le volume. Et cela crée la même tension que chez Percy : la couverture de test est inversement proportionnelle au budget. Les équipes finissent par limiter les stories testées ou la fréquence des builds pour rester dans leur quota. Un outil de qualité qui vous incite à réduire votre couverture de test — avouez que le paradoxe est savoureux.
Delta-QA est gratuit. Pas de quota de snapshots, pas de plafond de pages, pas de limitation de fréquence. Vous testez autant de pages que nécessaire, aussi souvent que nécessaire. La qualité de votre couverture visuelle ne dépend que de votre volonté de bien faire, pas de votre capacité à payer.
Ce que Chromatic fait que Delta-QA ne fait pas
La transparence impose de reconnaître les forces uniques de Chromatic.
La revue d'UI collaborative. Le workflow de Chromatic permet aux développeurs et aux designers de valider visuellement les changements de composants dans le cadre d'une pull request. C'est un processus de revue intégré qui n'a pas d'équivalent exact dans Delta-QA.
Le test de tous les états d'un composant. Si votre bouton a 12 variantes (taille, couleur, état, thème), Chromatic les teste toutes systématiquement. Tester ces 12 variantes au niveau de la page nécessiterait de trouver 12 pages différentes où elles apparaissent — ce qui n'est pas toujours possible.
L'intégration native avec Storybook. Chromatic est fait par les créateurs de Storybook. L'intégration est aussi profonde que possible : détection automatique des nouvelles stories, configuration minimale, workflow fluide. C'est un avantage réel si Storybook est le centre de votre workflow de développement UI.
La documentation visuelle vivante. Chromatic maintient un historique visuel de chaque composant à travers le temps. C'est une bibliothèque de design vivante qui montre l'évolution de chaque composant — une fonctionnalité précieuse pour les design systems.
Ce que Delta-QA apporte que Chromatic ne couvre pas
Le test de la réalité. Les pages en production, avec les vraies données, les vrais styles hérités, les vraies interactions entre composants. Pas l'idéalisation propre de Storybook, mais le monde tel qu'il est.
L'accessibilité universelle. Tout membre de l'équipe peut lancer un test visuel. Pas besoin d'être développeur, pas besoin de connaître Storybook, pas besoin d'accéder au pipeline CI. La démocratisation du test visuel.
L'indépendance technologique. Delta-QA fonctionne quel que soit votre stack front-end. React, Vue, Angular, Svelte, WordPress, Shopify, site statique, application legacy en jQuery — peu importe. Si ça s'affiche dans un navigateur, Delta-QA le teste. Chromatic nécessite Storybook, qui nécessite un framework JavaScript moderne.
La souveraineté des données. Exécution locale, aucune donnée envoyée sur des serveurs tiers. Pour les applications internes, les données sensibles, et les organisations soumises à des réglementations strictes.
Le coût zéro. Pas de calcul de snapshots, pas de plan à choisir, pas de carte bancaire à renseigner. Gratuit dans le sens le plus littéral du terme.
Le scénario idéal : les deux ensemble
Si votre équipe utilise déjà Storybook et a le budget pour Chromatic, la combinaison des deux outils est la stratégie la plus robuste.
Chromatic surveille vos composants au niveau du design system. Chaque changement de style, chaque variation, chaque état est vérifié visuellement. Les régressions sont détectées au moment du développement, avant que le code n'atteigne la branche principale.
Delta-QA surveille vos pages en production (ou en staging). Les problèmes d'assemblage, les conflits de styles, les bugs qui n'apparaissent que dans le contexte réel sont détectés avant que les utilisateurs ne les voient.
Ensemble, c'est une double couverture qui ne laisse pratiquement rien passer. Et puisque Delta-QA est gratuit, le coût total de cette stratégie est le coût de Chromatic seul.
Le scénario pragmatique : un seul outil
Si vous devez choisir un seul outil — parce que le budget est limité, parce que l'équipe est petite, ou parce que vous voulez commencer simple — la question se résume à ceci : qu'est-ce qui protège le mieux vos utilisateurs ?
Vos utilisateurs ne voient pas vos composants Storybook. Ils voient vos pages. Ils interagissent avec vos pages. Ils forment leur opinion sur votre produit en regardant vos pages. Un composant parfait dans Storybook mais cassé dans la page assemblée est un composant cassé du point de vue de l'utilisateur.
Delta-QA teste ce que vos utilisateurs voient. C'est aussi simple que ça.
FAQ
Chromatic fonctionne-t-il sans Storybook ?
Non. Chromatic est conçu spécifiquement pour Storybook et dépend des stories pour définir ce qui doit être testé visuellement. Si votre projet n'utilise pas Storybook, Chromatic n'est pas utilisable. Delta-QA fonctionne indépendamment de tout framework ou outil de développement — il teste des pages web, quel que soit le stack qui les produit.
Est-ce que tester les composants dans Storybook suffit pour garantir la qualité visuelle ?
Non. Les composants testés en isolation ne reproduisent pas les conditions réelles d'une page assemblée : héritage de styles, données dynamiques, interactions entre composants, styles tiers. Chromatic vérifie que vos briques sont correctes. Delta-QA vérifie que l'assemblage est correct. Les deux niveaux sont nécessaires pour une couverture complète.
Chromatic détecte-t-il les problèmes responsive ?
Oui, dans la limite de ce que Storybook montre. Vous pouvez configurer vos stories pour différentes tailles de viewport, et Chromatic les testera. Mais les problèmes responsive spécifiques à une page assemblée (un élément qui déborde quand combiné avec d'autres, un layout qui casse avec des données réelles longues) ne seront pas détectés. Delta-QA peut comparer des pages à différentes résolutions dans leur contexte réel.
Le plan gratuit de Chromatic est-il suffisant pour un petit projet ?
Le plan gratuit de Chromatic offre 5 000 snapshots par mois, ce qui couvre un petit design system avec des builds occasionnels. Dès que le nombre de composants ou la fréquence de builds augmente, le quota est rapidement atteint. Un projet avec 100 composants, 3 stories par composant, et 2 builds quotidiens consomme environ 18 000 snapshots par mois. Delta-QA n'a aucune limitation de volume.
Peut-on utiliser Delta-QA pour tester des composants isolés ?
Delta-QA est optimisé pour les pages complètes, pas pour les composants isolés. Si vous avez un environnement où vos composants sont rendus individuellement sur des URLs accessibles (comme un Storybook déployé), vous pouvez techniquement utiliser Delta-QA pour les comparer. Mais ce n'est pas son cas d'usage principal. Pour le test de composants isolés, Chromatic reste l'outil de référence.
Comment Delta-QA gère-t-il les design systems si ce n'est pas au niveau du composant ?
Delta-QA vérifie la cohérence visuelle de votre design system au niveau où elle compte le plus : dans les pages qui l'utilisent. Si un changement dans votre design system casse la mise en page d'une dizaine de pages, Delta-QA le détecte directement. C'est un test end-to-end du design system, complémentaire au test unitaire de Chromatic.
Chromatic et Delta-QA ne sont pas des adversaires — ils sont les deux faces d'une même médaille. L'un protège vos composants, l'autre protège vos pages. Si vous pouvez avoir les deux, prenez les deux. Si vous devez choisir, choisissez celui qui protège ce que vos utilisateurs voient réellement.