Les diffs de captures en pratique : baselines, seuils et faux positifs

Sur le papier, un test visuel est le type de test le plus simple du monde : deux images, une comparaison, terminé. Qui l'essaie s'aperçoit vite qu'entre « comparer deux images » et « savoir de façon fiable si le site est cassé » se loge tout un métier. Ce métier a trois notions centrales — baseline, seuil, faux positif — et qui les comprend comprend aussi pourquoi les tests visuels sont indispensables dans certaines équipes et désactivés au bout de trois semaines dans d'autres.

Au commencement se tient la baseline : un jeu de captures qui fixe l'état voulu de la page. L'important est ce que la baseline signifie — et ce qu'elle ne signifie pas. Elle n'est pas une mesure objective de la justesse, mais un instantané que quelqu'un a déclaré état de référence. Un diff contre la baseline ne dit donc jamais « la page est cassée », mais seulement « la page est différente de l'état validé ». Si différent veut dire aussi moins bon, aucun algorithme ne peut en décider.

La comparaison elle-même travaille, dans son principe, pixel par pixel : pour chaque position de l'image, l'écart de couleur entre la baseline et la capture actuelle est déterminé, et la somme des écarts donne une mesure du changement. Ce principe de base est robuste et rapide — et il comporte une faiblesse intégrée : il traite tout écart de la même façon, qu'un bouton d'ajout au panier ait disparu ou qu'une police ait été lissée de manière infimement différente.

C'est précisément de là que vient le plus grand problème pratique des tests visuels : le bruit. Le lissage des polices varie selon le système et selon le passage de rendu. Les contours sont dessinés tantôt un sous-pixel plus tôt, tantôt plus tard. Les images passent par une compression qui engendre des écarts de couleur minimes. Rien de tout cela n'est une régression — mais tout cela produit des différences de pixels. Une comparaison naïve qui déclenche l'alerte au moindre pixel divergent signale donc pratiquement toujours quelque chose.

La deuxième source de bruit, ce sont les contenus eux-mêmes. Une heure affichée change à chaque appel. Un carrousel ne s'arrête jamais deux fois sur la même image. Les emplacements publicitaires livrent des visuels changeants, les bandeaux de recommandation des produits changeants, un bandeau de cookies apparaît tantôt avant, tantôt après la capture. Qui photographie un site d'actualité le matin puis à midi obtient deux images totalement différentes — et les deux sont correctes.

L'outil contre le bruit s'appelle le seuil : ce n'est qu'une fois que l'écart dépasse une mesure définie que la comparaison est jugée notable. Commence alors un arbitrage qu'aucune optimisation ne fait disparaître. Un seuil strict signale la moindre broutille et engendre une fatigue face aux alertes ; un seuil généreux laisse passer de véritables erreurs — un prix décalé peut rester sous le seuil s'il ne concerne que quelques pixels. La seule bonne valeur n'existe pas ; il n'existe que la valeur appropriée à une page donnée et à une équipe donnée.

Pour fixer cette valeur, il existe au moins une méthode concrète : mesurer son propre bruit. Pour cela, on photographie la même page deux fois coup sur coup, sans rien changer, et on compare les deux prises entre elles. Toute différence que signale cette comparaison est par définition du bruit — lissage des polices, compression, timing. Qui répète cette mesure pour les pages et les combinaisons d'appareils les plus importantes connaît le niveau de fond de son environnement de contrôle et peut placer le seuil juste au-dessus, au lieu de le deviner. La méthode fournit au passage un signal d'alerte précoce : si le niveau de fond ainsi mesuré augmente sensiblement par la suite, c'est que l'environnement est devenu plus agité — et il vaut la peine d'en chercher la cause avant que les alertes ne perdent leur crédibilité.

La fatigue face aux alertes n'est pas un thème annexe et vague, mais le coup fatal le plus fréquent porté aux tests visuels. Un système de contrôle qui se déclenche trois fois par jour sans raison, plus personne ne le prendra au sérieux au bout de deux semaines — et alors l'alerte qui signale effectivement une page de paiement cassée n'est plus qu'une parmi tant d'autres que l'on évacue par routine. Un test visuel auquel l'équipe ne fait pas confiance est pire que pas de test du tout, parce qu'il feint une sécurité qu'il ne fournit pas.

Il vaut donc la peine de travailler sur les conditions générales avant de toucher au seuil. Ont fait leurs preuves : des données d'exemple figées plutôt que des données en direct dans les environnements de contrôle, des animations désactivées, des états de départ cohérents — par exemple une boîte de dialogue de cookies déjà traitée —, des temps d'attente suffisants jusqu'au chargement complet et des tailles de fenêtre identiques à chaque passage. Les indications propres à chaque outil ont leur place dans toute mise en route ; pour le service considéré ici, la documentation de ScanU sur le site du fournisseur les rassemble. Chacune de ces mesures supprime une source de bruit — et rend le seuil moins important, parce que les vraies et les fausses alertes se séparent plus nettement.

Pour les sources de bruit tenaces — l'emplacement publicitaire, la date du jour, la zone des commentaires d'utilisateurs —, certains outils offrent en outre la possibilité d'exclure des zones de l'image de la comparaison. C'est efficace, mais cela a un prix qu'il faut connaître : une zone exclue est un angle mort. C'est précisément là que tout et n'importe quoi pourra désormais se produire sans que personne ne le signale. L'arbitrage n'est donc pas « exclure ou supporter les faux positifs », mais : cette zone est-elle assez importante pour que l'on veuille être informé de ses changements ? Pour une bannière publicitaire rotative, la réponse est le plus souvent non ; pour une colonne de prix, toujours oui. Les zones d'exclusion définies méritent par ailleurs d'être documentées et revues de temps à autre — sinon les taches silencieuses s'accumulent, et le contrôle couvre moins de terrain que tous les intéressés ne le croient.

Une décision voisine porte sur le cadrage de l'image. Une prise de la seule zone visible de la fenêtre contrôle ce que les visiteuses et visiteurs voient sans faire défiler — rapide et économe, mais aveugle à tout ce qui se trouve en dessous. Une prise de la pleine longueur de la page saisit tout, mais réagit plus fortement : si un élément de la partie haute grandit de vingt pixels, tout le reste de la page se décale vers le bas, et la comparaison marque des surfaces dont le contenu n'a pas changé du tout. Pour des pages compactes et stables, la pleine longueur est le plus souvent le bon choix ; sur des pages très longues et très vivantes, il peut être plus avisé de contrôler ciblément les sections critiques. Là non plus, il ne s'agit pas d'une broutille technique, mais d'une décision sur les erreurs que l'on veut voir — et sur celles que l'on accepte sciemment.

Le deuxième grand thème méthodologique est l'entretien de la baseline dans la durée. Les sites changent volontairement : refontes, nouveaux contenus, opérations saisonnières. Après chaque modification voulue, la baseline doit être mise à niveau, faute de quoi chaque passage à venir signalera la même différence attendue. Le danger réside dans la routine : qui considère les mises à jour de baseline comme un clic fastidieux finit par les faire par réflexe — et érige ainsi tôt ou tard une véritable erreur en nouvel état de référence. À partir de là, chaque passage au vert confirme la version cassée.

Contre cela, un principe simple aide : les mises à jour de baseline sont des validations et méritent le même soin qu'une revue de code. Quelqu'un examine la différence, quelqu'un décide sciemment, quelqu'un peut retracer la décision plus tard. Les outils y aident plus ou moins bien ; ScanU, par exemple, présente la baseline et l'état actuel côte à côte et produit des rapports partageables, de sorte que des non-techniciens puissent eux aussi juger un écart — quelles fonctions de comparaison sont disponibles dans le détail, la page des fonctions du service le montre. Le principe est toutefois indépendant de l'outil : valider une baseline est une décision de fond, pas une décision technique.

Une dimension est volontiers passée sous silence dans les textes d'introduction : le temps. Les régressions ne se remarquent pas toujours tout de suite. Commence alors la recherche : depuis quand est-ce ainsi ? Quelle modification entre en ligne de compte ? C'est là que l'historique paie — la possibilité de consulter des états plus anciens et de circonscrire le moment du changement. Chez ScanU, la conservation dépend du palier tarifaire, de trois jours dans le palier gratuit jusqu'à 90 jours dans le plus grand. Pour la méthode, cela signifie : qui ne contrôle que rarement a besoin d'historiques remontant plus loin ; qui contrôle chaque jour circonscrit bien les périodes même avec un historique court.

Reste la limite la plus fondamentale du procédé : le fossé sémantique. Une comparaison de pixels ne sait pas ce qu'elle compare. Deux pixels de décalage sur un bouton de paiement peuvent être le symptôme d'une grille de mise en page cassée ; vingt pixels de décalage dans un pied de page sont le plus souvent sans importance. Le diff ne connaît pas la différence — il mesure de la surface, pas du sens. Le dernier mot revient donc toujours à un être humain qui connaît la page et sait situer quel écart a une portée commerciale.

Et enfin ce qu'un diff de captures ne peut par principe pas voir : tout ce qui ne se dépose pas dans l'image. Une page peut avoir l'air irréprochable et afficher malgré tout des données fausses, un formulaire peut être parfaitement rendu et échouer à l'envoi, un serveur peut livrer correctement des contenus périmés. Les tests visuels sont une couche de l'édifice de test — à côté des tests fonctionnels, de la supervision et d'une curiosité humaine occasionnelle —, non son remplacement.

Comment les différentes briques s'assemblent, un exemple joué de bout en bout le montre — non une étude de cas, mais un enchaînement typique. Semaine un : une équipe crée des baselines pour dix pages et trouve le lendemain matin des dizaines d'écarts signalés. L'examen montre que presque tous remontent à un carrousel et à la boîte de dialogue des cookies. Semaine deux : calmer l'environnement de contrôle — données d'exemple figées, état de départ défini, animations coupées ; les passages deviennent silencieux. Semaine trois : une mise à jour de dépendance décale, dans l'un des trois moteurs, les espacements de la navigation — la première vraie trouvaille, que personne n'aurait remarquée auparavant, parce qu'au quotidien personne n'ouvre par routine tous les moteurs. Semaine quatre : une refonte de la page d'accueil engendre des différences attendues sur toutes les vues ; après examen, la baseline est actualisée sciemment. Rien dans ce déroulé n'est spectaculaire — et c'est précisément là le point. La valeur ne naît pas de trouvailles dramatiques, mais du passage d'un « tout a probablement bonne allure » à un « depuis le dernier état validé, rien d'indésirable n'a changé » vérifié. Comment un passage de contrôle isolé se déroule techniquement, la présentation étape par étape de ScanU le montre.

Qui veut se lancer s'en sort bien avec un ordre simple : définir d'abord un petit ensemble de pages importantes, puis calmer l'environnement de contrôle, puis produire les baselines et s'accorder en équipe sur qui juge et valide les écarts — et négocier seulement ensuite les seuils et la fréquence des contrôles. L'aperçu de ScanU en français offre une entrée en matière francophone ; la méthode qui la sous-tend vaut pour tout outil de cette catégorie. Car voilà, au bout du compte, l'enseignement central : la valeur des tests visuels ne naît pas dans l'algorithme qui compare des pixels, mais dans le procédé qui l'entoure — des références propres, des seuils honnêtes et des personnes qui jugent les différences au lieu de les évacuer d'un clic.