Régression visuelle vs dérive de structure : la surveillance comparée

Deux couches de la même page

Toute page web existe comme deux choses à la fois : un DOM — l'arbre structuré d'éléments que le navigateur construit à partir de votre HTML — et une image rendue, les pixels que le navigateur peint à partir de ce DOM et du CSS. Un changement peut apparaître dans une couche, dans l'autre ou dans les deux.

La surveillance de régression visuelle observe les pixels. La surveillance de dérive de structure observe le DOM. Comme une panne peut se cacher dans l'une ou l'autre couche, les deux vérifications détectent des problèmes différents — et c'est justement dans l'écart entre elles que vit la casse silencieuse.

Comment fonctionne la surveillance de régression visuelle

Les tests de régression visuelle capturent une capture d'écran de chaque page clé — Relvato le fait à la fois en viewport ordinateur et mobile — et la comparent, pixel par pixel, à une image de référence (baseline) approuvée. La comparaison est déterministe (un diff de pixels de type pixelmatch avec une tolérance à l'anticrénelage), de sorte qu'une page inchangée s'affiche à l'identique deux fois et que seul un vrai changement est signalé.

Elle détecte tout ce qui est visible : une régression CSS qui décale la mise en page, une police web qui n'a pas chargé, un changement de couleur ou d'espacement, une image d'en-tête surdimensionnée, un élément qui déborde sur mobile. Si une personne le remarquerait, un diff de pixels aussi.

Le prix de cette sensibilité, c'est le bruit. Les zones réellement dynamiques — une bannière tournante, un horodatage, un test A/B, un emplacement publicitaire — diffèrent à chaque exécution et seraient signalées comme faux positifs. Relvato gère cela avec des masques : vous excluez ces zones pour ne comparer que les pixels significatifs. Et comme « différent » n'est pas toujours « faux », chaque changement est mis en attente de revue face à la baseline — vous acceptez le nouveau rendu comme baseline, ou vous ignorez cette zone.

Comment fonctionne la surveillance de dérive de structure

La dérive de structure travaille une couche plus bas, sur le DOM lui-même. Au lieu d'une capture, Relvato construit une empreinte de la structure de la page — les éléments, sections et scripts qui la composent — et compare chaque exécution à l'empreinte approuvée. Ce qu'elle signale, c'est la présence et l'absence : une section disparue, un champ de formulaire évanoui, un script ajouté, un bouton « Ajouter au panier » supprimé.

C'est sémantique plutôt que basé sur les pixels, ce qui la rend robuste au bruit cosmétique. Un ajustement de couleur, un changement de police ou un décalage d'un pixel ne la déclenchent pas — seul un changement de ce dont la page est réellement faite. C'est ce qui la rend bonne pour détecter les régressions fonctionnelles : un bouton de paiement qui ne s'affiche plus, un script d'analytics ou de consentement qu'une mise à jour d'extension a supprimé, un widget d'avis qui a cessé de se charger en silence.

Elle a l'angle mort inverse du visuel : parce qu'elle ne regarde pas les pixels, elle ne verra pas une casse purement visuelle — une feuille de style qui a mal chargé la mise en page tout en conservant chaque élément présent. Et comme le visuel, elle travaille face à une baseline avec une revue accepter / ignorer, de sorte qu'un changement de balisage intentionnel est une validation en un clic, pas une alarme permanente.

Ce qui échappe à chacune

Les deux vérifications échouent dans des directions opposées. La régression visuelle peut manquer un changement invisible mais fonctionnel — un élément occupe toujours sa place mais son lien ou son gestionnaire a disparu, ou un script s'est évanoui sans trace visuelle. La dérive de structure peut manquer un changement visible mais structurellement identique — les mêmes éléments, restylés en une mise en page cassée.

Un exemple : une mise à jour du thème apporte un changement CSS qui pousse votre bouton « Acheter » hors de l'écran sur mobile. La régression visuelle le signale aussitôt — les pixels ont bougé. La dérive de structure reste au vert — l'élément bouton est toujours dans le DOM. Inversons : une mise à jour d'extension cesse d'afficher le script de votre bandeau de consentement. La dérive de structure signale le nœud manquant ; la régression visuelle peut-être pas, si le bandeau était sous la ligne de flottaison ou visuellement mineur. Aucune vérification n'est complète à elle seule.

Où elles se recoupent — et pourquoi les baselines comptent

Les deux vérifications partagent la même idée centrale : capturer une référence approuvée, puis signaler tout écart par rapport à elle. Cette référence — la baseline — est ce qui transforme « ceci a changé » en « ceci a changé par rapport à ce que vous avez validé ». Un changement n'est jamais considéré en échec pour toujours : vous l'acceptez comme nouvelle baseline, vous ignorez une zone ou une section précise, ou vous annulez une décision plus tard.

L'effet pratique, c'est que les deux vérifications deviennent plus silencieuses avec le temps. Au début, vous validez les changements intentionnels ; ensuite, un signalement veut dire quelque chose que vous n'attendiez pas. (La revue des baselines de Relvato — accepter, ignorer seulement certaines sections, annuler et réinitialiser — est décrite dans son propre guide pratique dans Docs.)

Comment Relvato exécute les deux

Relvato propose la régression visuelle et la dérive de structure comme deux parcours distincts et continus, et il est courant d'exécuter les deux sur la même page. À chaque changement — un déploiement, une mise à jour d'extension ou de thème, ou selon un calendrier — il recapture la capture d'écran et l'empreinte de structure, compare chacune à sa baseline et n'alerte que sur un écart réel.

Utilisez la régression visuelle là où l'apparence est le produit : landing pages, pages produit, le paiement. Utilisez la dérive de structure là où un élément manquant est le vrai risque : formulaires, boutons, tunnels, scripts tiers. Ensemble, elles couvrent les deux couches de la page, de sorte qu'un déploiement cassé n'a nulle part où se cacher — qu'il apparaisse dans les pixels, dans le DOM ou dans les deux.