DOM Comparison vs Visual Comparison : Deux Approches, Deux Angles Morts

DOM comparison vs visual comparison : opposition entre deux méthodes de détection de changements d'interface — la première analyse les modifications de l'arbre HTML (Document Object Model), la seconde compare des captures d'écran pixel par pixel — chacune présentant des angles morts que l'autre ne couvre pas.

Voici un scénario que vous avez probablement déjà vécu : votre équipe déploie une mise à jour. Les tests unitaires passent. Les tests d'intégration passent. Les tests end-to-end passent. Et pourtant, un utilisateur signale que le bouton de paiement a disparu sous le footer sur mobile.

Comment est-ce possible ? Parce que vos tests vérifient que le DOM contient le bon bouton avec le bon texte et le bon lien — mais personne ne vérifie que ce bouton est effectivement visible à l'écran, à la bonne position, avec la bonne taille.

C'est exactement le problème que pose le choix entre comparaison DOM et comparaison visuelle. Ces deux approches sont souvent présentées comme des alternatives. En réalité, ce sont deux facettes complémentaires d'un même problème — et utiliser l'une sans l'autre, c'est accepter un angle mort dans votre stratégie de test.

Cet article détaille ce que chaque approche détecte, ce qu'elle rate, et pourquoi la comparaison structurelle — celle qui lit le DOM ET vérifie les propriétés CSS calculées — est aujourd'hui la réponse la plus complète au problème de la régression visuelle.

Ce que fait réellement la comparaison DOM

La comparaison DOM consiste à prendre un snapshot de l'arbre HTML d'une page à un instant T, puis à le comparer avec un snapshot pris à un instant T+1. Si un nœud a été ajouté, supprimé ou modifié, le diff le signale.

C'est une approche puissante pour détecter les changements structurels. Un paragraphe supprimé par erreur, un attribut href modifié, une classe CSS ajoutée ou retirée — la comparaison DOM voit tout ce qui touche à la structure du document.

Les outils qui utilisent cette approche sont nombreux. Les snapshot tests de Jest en sont l'exemple le plus répandu. Vous sérialisez le rendu d'un composant React ou Vue, vous le stockez dans un fichier, et à chaque exécution, Jest compare le résultat actuel avec le snapshot enregistré.

Le problème, c'est que la comparaison DOM ne voit que le HTML. Elle ne voit pas le résultat visuel.

Ce que la comparaison DOM ne détecte pas

Prenons un exemple concret. Vous avez un bouton avec la classe .btn-primary. Dans votre fichier CSS, cette classe définit un background-color: #2563EB (bleu). Un développeur modifie le fichier CSS et change cette couleur en #DC2626 (rouge). Le HTML n'a pas bougé. Le DOM est identique. Le snapshot Jest passe au vert.

Mais votre bouton est passé du bleu au rouge en production.

Ce n'est pas un cas théorique. Voici les situations concrètes où la comparaison DOM est aveugle.

Les changements CSS externes. Toute modification dans une feuille de style, un fichier de thème, une variable CSS custom, un token de design system — rien de tout ça n'apparaît dans le DOM. Le HTML reste identique, seul le rendu change. Et le rendu, c'est ce que vos utilisateurs voient.

Les problèmes de fonts. Une police Google Fonts qui ne se charge plus, un fallback système qui s'active, un poids de font qui change — le DOM contient toujours la même balise <p> avec le même texte. Mais visuellement, tout le rythme typographique de votre page est cassé.

Les problèmes de z-index et de superposition. Deux éléments qui se chevauchent à cause d'un conflit de z-index, un modal qui apparaît sous le contenu au lieu d'au-dessus, un tooltip qui déborde de son conteneur — le DOM contient tous les éléments correctement. C'est leur empilement visuel qui est faux.

Les problèmes de responsive. Un conteneur flex qui ne wrape plus correctement, un élément qui déborde de son parent, une media query qui ne s'applique plus — le DOM est le même. C'est le layout qui a changé.

Les problèmes de spacing et d'alignement. Une marge qui passe de 16px à 0px, un padding qui disparaît, un gap entre éléments qui change — rien de visible dans le DOM si ces propriétés sont définies en CSS.

La comparaison DOM est, par conception, aveugle à tout ce qui est défini en dehors du HTML. Et dans une application web moderne, la majorité du rendu visuel est définie en CSS — pas en HTML.

Ce que fait réellement la comparaison visuelle

La comparaison visuelle prend le problème par l'autre bout. Au lieu de comparer du code, elle compare des images. Vous capturez un screenshot de votre page à un instant T (la baseline), puis un screenshot à un instant T+1, et un algorithme compare les deux images pixel par pixel — ou avec des méthodes perceptuelles plus sophistiquées comme pHash ou SSIM — une distinction essentielle que nous explorons dans notre article pixel par pixel vs perceptuelle.

L'avantage est évident : la comparaison visuelle voit ce que l'utilisateur voit. Si un bouton change de couleur, elle le détecte. Si un texte déborde de son conteneur, elle le détecte. Si un élément disparaît sous un autre, elle le détecte.

C'est l'approche utilisée par des outils comme Percy, Applitools, Chromatic et BackstopJS. Elle a démocratisé la notion de test de régression visuelle et a permis à des milliers d'équipes de détecter des bugs que leurs tests fonctionnels ne voyaient pas.

Mais elle a aussi ses propres angles morts. Et ils sont considérables.

Ce que la comparaison visuelle ne détecte pas

Les changements invisibles mais sémantiquement importants. Un lien dont le href passe de /checkout à /cart ne produit aucun changement visuel — le texte et le style du lien sont identiques. Mais l'utilisateur qui clique n'arrive plus au bon endroit. La comparaison visuelle ne voit rien.

Les changements d'accessibilité. Un aria-label supprimé, un role modifié, un alt manquant sur une image — rien de visible dans un screenshot. Mais pour les utilisateurs de lecteurs d'écran, votre page est devenue inutilisable.

Les changements de contenu dynamique. Un prix qui passe de 29€ à 290€, un compteur qui affiche un mauvais nombre, un nom d'utilisateur qui ne se charge plus — si le layout reste identique, la comparaison pixel-par-pixel peut ne pas le signaler comme une régression, surtout avec des seuils de tolérance élevés.

Les faux positifs massifs. C'est le problème numéro un de la comparaison visuelle pure. Un curseur qui clignote, une animation qui n'est pas au même frame, un contenu dynamique (date, heure, publicité), un rendu de font légèrement différent entre deux exécutions — tout cela génère des diffs visuels qui ne sont pas des régressions. Selon une étude de Google sur la fiabilité des tests (2016), les tests instables — ou "flaky tests" — représentent 1,5% de l'ensemble des exécutions de tests chez Google, et les variations de rendu sont l'une des premières causes de flakiness dans les tests visuels.

L'absence d'explication. Quand une comparaison visuelle vous montre un diff, elle vous dit "quelque chose a changé ici" en surlignant une zone. Mais elle ne vous dit pas quoi. Est-ce la couleur ? La taille ? La position ? Le contenu ? Vous devez enquêter vous-même. Sur une page complexe avec des dizaines de changements, le triage devient un travail à plein temps.

Le vrai problème : deux méthodes, deux angles morts symétriques

Si vous avez suivi jusqu'ici, vous voyez le paradoxe.

La comparaison DOM détecte les changements HTML mais rate les changements visuels. La comparaison visuelle détecte les changements visuels mais rate les changements sémantiques. Les deux approches sont aveugles exactement là où l'autre est forte.

Ce paradoxe n'est pas une coïncidence. Il reflète la dualité fondamentale d'une page web : le code (DOM + CSS) produit un rendu visuel, mais la relation entre les deux n'est pas bijective. Un même DOM peut produire des rendus très différents selon le CSS appliqué. Et un même rendu visuel peut être produit par des DOM très différents.

C'est pourquoi choisir entre comparaison DOM et comparaison visuelle est un faux dilemme. La question n'est pas "laquelle est meilleure" — la question est "comment couvrir les deux dimensions".

Certaines équipes essaient de résoudre ce problème en combinant les deux outils : Jest pour les snapshots DOM, et Percy ou BackstopJS pour les screenshots. C'est mieux que rien, mais c'est aussi deux pipelines à maintenir, deux ensembles de baselines à gérer, deux sources de faux positifs à trier, et aucune corrélation entre les résultats. Quand Jest dit "le DOM a changé" et Percy dit "le visuel a changé", personne ne vous dit si ces deux changements sont liés.

La comparaison structurelle : lire le DOM ET vérifier le CSS calculé

Il existe une troisième approche qui ne se contente ni du DOM seul, ni des pixels seuls. C'est la comparaison structurelle — et c'est l'approche que Delta-QA a choisie.

Le principe est le suivant : au lieu de comparer un arbre HTML statique ou une image plate, Delta-QA lit chaque élément du DOM et récupère ses propriétés CSS calculées — c'est-à-dire les styles réellement appliqués par le navigateur après résolution de toutes les cascades, héritages, media queries et variables CSS.

Concrètement, pour chaque élément de votre page, Delta-QA connaît sa position exacte, ses dimensions réelles, sa couleur effective, sa typographie appliquée, ses marges et paddings résolus, son z-index calculé, son opacité, sa visibilité. Pas les styles déclarés dans le CSS source — les styles tels que le navigateur les a calculés et appliqués.

Cette approche résout les deux angles morts simultanément.

Elle détecte les changements CSS. Si une variable CSS change et affecte la couleur d'un bouton, Delta-QA le voit — parce qu'il compare les propriétés CSS calculées, pas le HTML source. Le background-color du bouton est passé de rgb(37, 99, 235) à rgb(220, 38, 38). Le rapport le dit explicitement.

Elle détecte les changements DOM. Si un élément est ajouté, supprimé ou déplacé dans l'arbre HTML, Delta-QA le voit — parce qu'il parcourt le DOM élément par élément.

Elle ne génère pas de faux positifs liés au rendu. Pas de comparaison pixel-par-pixel, donc pas de diff causé par un curseur qui clignote, une animation à un frame différent, ou un léger anti-aliasing de font. Si la propriété CSS calculée est identique, il n'y a pas de diff.

Elle explique ce qui a changé. Au lieu de surligner une zone en rouge sur un screenshot, Delta-QA vous dit : "Le padding-top de cet élément est passé de 16px à 8px" ou "Le font-weight de ce titre est passé de 700 à 400". Vous savez exactement quoi a changé, sur quel élément, et de quelle valeur.

L'algorithme en 5 passes

Delta-QA ne se contente pas d'un diff naïf entre deux arbres DOM. Son algorithme structurel en 5 passes procède méthodiquement pour garantir la précision des résultats.

La première passe identifie les éléments correspondants entre les deux versions de la page en utilisant une combinaison de sélecteurs CSS, de position dans l'arbre, et de contenu textuel. La deuxième passe compare les propriétés CSS calculées de chaque paire d'éléments correspondants. La troisième passe détecte les éléments ajoutés et supprimés. La quatrième passe analyse les relations spatiales — un élément qui a bougé par rapport à ses voisins. La cinquième passe agrège les résultats et élimine le bruit — les micro-variations de rendu qui ne constituent pas des régressions significatives.

Le résultat est un rapport qui vous donne la liste exacte des changements, classés par sévérité, avec pour chacun l'élément concerné, la propriété modifiée, la valeur avant et la valeur après.

Quand la comparaison DOM suffit

Soyons honnêtes : la comparaison DOM a sa place. Si votre objectif est de vérifier que la structure de vos composants n'a pas changé entre deux commits — et uniquement la structure — les snapshot tests de Jest font correctement le travail. Ils sont rapides, gratuits, intégrés dans l'écosystème JavaScript, et ne nécessitent aucune infrastructure supplémentaire.

C'est un filet de sécurité léger pour les développeurs front-end qui veulent être alertés quand un rendu de composant change. Tant que vous êtes conscient que ce filet ne couvre que le HTML — pas le CSS, pas le layout, pas le rendu final — c'est un outil légitime dans votre boîte à outils.

Le problème commence quand vous traitez les snapshot tests DOM comme un substitut au test visuel. Ce n'en est pas un. C'est un test de structure, pas un test d'apparence.

Quand la comparaison visuelle suffit

La comparaison visuelle par screenshots a aussi sa place. Pour des pages très statiques avec peu de contenu dynamique, elle fonctionne bien. Pour des vérifications rapides avant un déploiement — "est-ce que la homepage a l'air correcte" — un screenshot comparé à une baseline est un bon indicateur rapide.

Elle est aussi utile pour détecter des régressions de rendering spécifiques à certains navigateurs. Un bug WebKit qui affecte le rendu d'un gradient CSS ne sera pas détecté par une comparaison DOM ou structurelle — il faut voir l'image rendue par le navigateur.

Mais si vous travaillez sur une application avec du contenu dynamique, des animations, des états interactifs, ou simplement un CSS qui évolue régulièrement, les faux positifs de la comparaison pixel-par-pixel vont rapidement devenir un problème opérationnel. D'après les retours terrain de la communauté de test visuel, les équipes passent en moyenne entre 30 et 60 minutes par jour à trier des faux positifs sur des outils de comparaison par screenshots.

Pourquoi la comparaison structurelle est la bonne réponse en 2026

Le web a évolué. Les applications modernes sont construites avec des design systems, des variables CSS, des frameworks de composants, du responsive complexe, des thèmes dynamiques. Le CSS n'est plus un fichier statique qu'on écrit une fois — c'est un système de règles dynamiques qui interagissent entre elles.

Dans ce contexte, comparer le DOM sans regarder le CSS, c'est comme vérifier le plan d'un bâtiment sans regarder si les murs sont à la bonne place. Et comparer des screenshots sans comprendre la structure, c'est comme regarder la photo d'un bâtiment sans pouvoir dire si c'est le toit ou la fondation qui a bougé.

La comparaison structurelle — telle que Delta-QA la pratique — est la seule approche qui comprend à la fois la structure et le rendu. Elle sait que le bouton existe (DOM), elle sait qu'il est bleu (CSS calculé), elle sait qu'il fait 200px de large (dimensions calculées), et elle sait qu'il est positionné à 340px du haut de la page (position calculée).

Si l'une de ces propriétés change, elle le détecte. Si aucune ne change, elle ne génère pas de faux positif. C'est aussi simple que ça.

Et parce que Delta-QA fonctionne sans code et sans cloud, vous n'avez pas besoin d'être développeur pour bénéficier de cette précision. Vous installez l'application, vous naviguez sur votre site, et l'outil fait le reste. En local. Sans envoyer vos données nulle part.

FAQ

Quelle est la différence fondamentale entre comparaison DOM et comparaison visuelle ?

La comparaison DOM analyse les modifications de l'arbre HTML — les balises, attributs et textes qui composent la structure d'une page. La comparaison visuelle compare des captures d'écran pixel par pixel pour détecter tout changement visible à l'écran. La première rate les changements CSS, la seconde rate les changements sémantiques non visibles.

Le DOM peut-il changer sans que le visuel change ?

Oui, fréquemment. Un attribut data-* modifié, une classe CSS ajoutée qui n'a pas de style associé, un commentaire HTML ajouté, une restructuration du DOM qui produit le même rendu — tous ces cas modifient le DOM sans changer l'apparence de la page. C'est une source majeure de faux positifs dans les outils de snapshot testing DOM.

Le visuel peut-il changer sans que le DOM change ?

Absolument. C'est même le cas le plus courant dans les applications modernes. Une modification de variable CSS, un changement de police externe, une mise à jour de framework CSS, un bug de z-index lié à une règle CSS modifiée — tout cela change le rendu sans toucher au HTML. La comparaison DOM est structurellement incapable de détecter ces régressions.

Qu'est-ce que la comparaison structurelle et en quoi diffère-t-elle des deux autres ?

La comparaison structurelle lit chaque élément du DOM et récupère ses propriétés CSS calculées — les styles réellement appliqués par le navigateur. Elle combine ainsi la vision structurelle du DOM et la vision effective du rendu, sans les inconvénients de la comparaison pixel-par-pixel (faux positifs, manque d'explication). C'est l'approche utilisée par Delta-QA.

Les snapshot tests Jest sont-ils suffisants pour détecter les régressions visuelles ?

Non. Les snapshot tests Jest comparent le HTML généré par vos composants, pas leur apparence. Ils sont utiles pour détecter les changements de structure accidentels, mais ils ne voient pas les changements CSS, les problèmes de layout, les conflits de z-index, ou les régressions typographiques. Ce sont des tests de structure, pas des tests visuels.

Comment Delta-QA évite-t-il les faux positifs courants en comparaison visuelle ?

Delta-QA ne compare pas des pixels — il compare des propriétés CSS calculées. Un curseur qui clignote, une animation à un frame différent, ou un léger anti-aliasing de font ne génèrent aucun diff parce que les propriétés CSS sous-jacentes n'ont pas changé. Seuls les changements réels de style, de position ou de dimension sont signalés.

Faut-il être développeur pour utiliser la comparaison structurelle de Delta-QA ?

Non. Delta-QA est un outil no-code. Vous installez l'application desktop, vous naviguez sur votre site comme vous le feriez normalement, et l'outil enregistre et compare automatiquement. Pas de SDK à intégrer, pas de script à écrire, pas de pipeline CI/CD à configurer. Tout se fait depuis l'interface graphique.