Comment automatiser des captures d'écran pour valider une refonte ?

Une refonte se juge à l'œil sur cinq pages et se casse sur les huit cents autres. C'est la mécanique habituelle : le client valide l'accueil, deux pages de rubrique et un article, la mise en ligne se passe bien, et trois semaines plus tard on découvre que les anciennes pages construites autrement affichent des images débordantes, des tableaux tronqués ou des titres qui se chevauchent. La comparaison automatisée de captures d'écran répond exactement à ce problème : elle photographie chaque page avant et après, superpose les deux images, et signale les différences. Ce n'est pas un test fonctionnel, cela ne vérifie ni un formulaire ni un panier, mais cela détecte en quelques minutes ce qu'un relecteur humain ne verrait qu'au bout de plusieurs jours. L'outillage nécessaire tient en un pilote de navigateur sans interface et une bibliothèque de comparaison d'images, tous deux libres et installables en une commande, ce qui rend la méthode accessible à une agence de trois personnes comme à une équipe technique constituée. La difficulté n'est donc ni le coût ni l'installation, elle tient entièrement au choix des pages et à la stabilisation des rendus, deux points que ce guide traite en priorité.

Choisir les pages à photographier

Photographier huit cents pages est possible et généralement inutile. L'objectif n'est pas l'exhaustivité mais la couverture des gabarits : deux pages construites avec le même modèle casseront de la même façon, et la seconde n'apprend rien. Ce raisonnement est le même que celui d'un plan de recette classique, tel que nous le décrivons dans notre rubrique création web, à ceci près qu'il porte ici sur l'apparence et non sur le comportement.

Un échantillon par gabarit, pas par page

La première liste se construit en inventoriant les modèles d'affichage réellement utilisés : accueil, page de rubrique, page de rubrique paginée, article court, article long, article avec tableau, article avec galerie, page de contact avec formulaire, page légale, page de recherche, page 404. Pour chacun, deux ou trois exemples suffisent, choisis parmi les plus anciens plutôt que les plus récents. Les contenus récents sont écrits avec les conventions actuelles ; ce sont les contenus anciens, importés d'un ancien système ou rédigés avant une refonte précédente, qui contiennent les structures HTML surprenantes que le nouveau thème n'a pas prévues.

Ajouter les pages qui concentrent les incidents

À cette liste par gabarit s'ajoutent les pages qui ont déjà posé problème. Toute page ayant fait l'objet d'un correctif spécifique mérite d'être surveillée, parce qu'un correctif spécifique est exactement ce qu'une refonte efface. On y ajoute les pages les plus visitées, dont le coût d'une régression est le plus élevé, et les pages contenant un élément inséré à la main : un iframe, un tableau importé d'un tableur, une infographie surdimensionnée. Une liste de soixante à cent URL couvre confortablement un site de quinze cents pages, et se parcourt en quelques minutes.

Les largeurs à retenir

Deux largeurs suffisent dans la plupart des cas, une de bureau et une de téléphone, à condition de les choisir aux endroits où les choses se cassent. La largeur de téléphone doit être étroite, autour de 390 pixels, et non 414 : les débordements apparaissent d'abord sur les écrans les plus petits. La largeur de bureau gagne à être prise juste au-dessus d'un point de rupture plutôt qu'au milieu d'une plage, parce que c'est là que les grilles basculent. Ajouter une troisième largeur intermédiaire, autour de 1 000 pixels, révèle souvent des problèmes que ni le téléphone ni le grand écran ne montrent, notamment sur les menus.

Une capture pleine page ou une capture d'écran visible

La capture pleine page photographie la totalité du document, du haut jusqu'au pied de page, quelle que soit sa longueur ; la capture d'écran visible ne retient que la portion affichée à un instant donné. La première paraît évidemment supérieure, et elle l'est pour détecter un bloc disparu au milieu d'un article, mais elle a un défaut sérieux : un écart minuscule situé en haut de page, une marge modifiée de trois pixels, décale tout ce qui suit et transforme une différence locale en différence intégrale. Sur les gabarits courts, la pleine page reste le bon choix. Sur les articles de six mille pixels de haut, il vaut souvent mieux prendre trois captures ancrées sur des repères stables, l'en tête, le premier titre de section, le pied de page, quitte à manquer une portion intermédiaire. Le compromis se décide gabarit par gabarit et se note dans la liste des URL, à côté de la largeur.

Stabiliser la page avant de la photographier

Une capture n'a de valeur que si la même page photographiée deux fois de suite donne exactement la même image. Cette condition, qui semble évidente, est presque toujours fausse au premier essai : la page contient une animation, un compteur, une date, une image chargée paresseusement ou un contenu aléatoire, et la comparaison signale des centaines d'écarts qui ne veulent rien dire. Le travail de stabilisation ressemble à celui d'un smoke test avant mise en production : il s'agit de rendre le résultat reproductible avant de chercher à l'interpréter.

Neutraliser les animations et les apparitions au défilement

Les thèmes modernes font apparaître les blocs à mesure du défilement, généralement en jouant sur l'opacité. Photographier une page dans cet état donne une image dont la moitié est invisible, et différente à chaque exécution selon le moment où la capture est prise. La solution consiste à injecter une feuille de style qui force l'opacité à un et annule toute transformation avant la capture. Le même traitement s'applique aux animations décoratives, aux carrousels qui défilent seuls et aux effets de parallaxe, qui produisent un décalage de quelques pixels à chaque prise.

Forcer le chargement de tout le contenu

Le chargement paresseux des images est une bonne pratique de performance et un poison pour la comparaison visuelle : une image absente réserve un espace vide qui se remplira plus tard, et la capture attrape l'un ou l'autre état au hasard. Il faut donc parcourir la page de haut en bas avant de photographier, par petits sauts, en laissant à chaque palier le temps aux images d'arriver, puis remonter et attendre que le réseau soit silencieux. Sur une page très longue, ce parcours prend deux à trois secondes, ce qui reste négligeable sur une centaine d'URL.

Masquer ce qui bouge par nature

Certains éléments ne peuvent pas être stabilisés et doivent être exclus : un bandeau de consentement qui apparaît au premier passage, une date affichée en clair, un compteur de commentaires, un bloc d'articles récents, une publicité. La méthode la plus simple consiste à les masquer par la même feuille de style injectée avant la capture. Le point important est de masquer les mêmes éléments avant et après, et de conserver cette liste dans le script plutôt que dans la mémoire de celui qui l'a écrit : une exclusion oubliée six mois plus tard produit des faux positifs que personne ne sait plus expliquer.

Écrire la recette de stabilisation une seule fois

Les traitements décrits ci dessus ont un point commun : ils s'appliquent à toutes les pages du même site, jamais à une seule. Les regrouper dans une fonction unique, appelée juste après le chargement et avant toute prise, évite la dérive la plus courante, celle où la page d'accueil reçoit un traitement que les articles n'ont pas et où la comparaison finit par mesurer des différences de méthode plutôt que des différences d'affichage. Cette fonction contient l'injection de la feuille de style neutralisante, le parcours vertical complet, l'attente du silence réseau et la remontée en haut de page. Sur un site où le consentement conditionne l'affichage, on y ajoute la pose du témoin correspondant avant la première navigation, ce qui est plus fiable que de masquer le bandeau après coup : masqué, il continue parfois de bloquer le défilement, et le parcours vertical ne charge alors aucune image.

Comparer les images et lire les écarts

Une fois les deux séries constituées, la comparaison consiste à superposer chaque paire et à mesurer la différence. Trois résultats sont possibles, et il faut les distinguer avant toute interprétation : les images ont des dimensions différentes, ce qui signale un changement de hauteur de page ; elles ont les mêmes dimensions mais diffèrent sur une zone ; elles sont strictement identiques. Ce troisième cas est le plus fréquent sur une refonte bien menée, et c'est lui qui donne confiance dans les écarts signalés ailleurs. La démarche est comparable à celle d'un test de performance d'un site Internet : on cherche moins une valeur absolue qu'un écart par rapport à une référence.

Différence de dimensions plutôt que de contenu

Une page qui grandit ou rétrécit de quelques pixels ne mérite pas d'attention ; une page qui passe de six mille à neuf mille pixels de haut en mérite beaucoup. L'écart de hauteur est le premier indicateur à regarder, avant même la comparaison des pixels, parce qu'il signale un changement structurel : un bloc qui ne s'affiche plus, une marge multipliée, une grille qui est passée d'une colonne à trois. Trier les paires par écart de hauteur décroissant met les vrais problèmes en tête de liste et évite de commencer par les cas anecdotiques.

Localiser la zone qui diffère

Quand les dimensions concordent, la comparaison pixel à pixel donne une zone rectangulaire englobant toutes les différences. Cette zone est plus utile que le pourcentage de pixels différents, souvent trompeur : un décalage d'un pixel sur toute la hauteur d'une colonne affecte beaucoup de pixels sans constituer un problème, alors qu'un titre disparu n'en affecte que quelques milliers. Produire une image de différence, où seules les zones distinctes apparaissent, permet de trancher en un coup d'œil au lieu de rouvrir les deux pages côte à côte.

Distinguer le faux positif du vrai problème

Le réflexe, devant une différence, doit être de refaire deux captures de la même version. Si l'écart se reproduit entre deux prises identiques, il vient de l'instabilité de la page et non de la refonte, et il faut retourner à l'étape de stabilisation. Ce contrôle prend trente secondes et évite les longues investigations sur des animations que personne n'avait pensé à neutraliser. Une fois cette vérification faite, un écart persistant est un vrai écart, et il ne reste qu'à décider s'il est voulu ou non.

Fixer un seuil de tolérance qui a du sens

Aucune comparaison sérieuse ne travaille à l'identité stricte du pixel : le rendu des polices varie légèrement d'une exécution à l'autre, et l'antialiasing suffit à faire différer deux captures pourtant identiques à l'œil. Les outils de comparaison exposent donc un seuil, exprimé en écart de couleur par pixel, sous lequel deux pixels sont considérés comme égaux. Une valeur autour de 0,1 sur une échelle de 0 à 1 absorbe le bruit de rendu sans masquer un vrai déplacement. Le second seuil, celui du nombre de pixels différents tolérés avant de déclarer un écart, est plus délicat : exprimé en pourcentage de la surface, il laisse passer les régressions des pages longues, où quelques milliers de pixels ne pèsent presque rien. Le raisonner en valeur absolue, quelques centaines de pixels quelle que soit la taille de la page, donne des résultats nettement plus cohérents entre gabarits.

Intégrer la comparaison au déroulement d'un projet

Une comparaison visuelle ponctuelle apporte peu. Sa valeur vient de sa répétition, et de son intégration au moment où une régression coûte encore peu de choses à corriger. Sur les refontes que nous menons, la série de référence se constitue avant la première ligne de code, sur le site en production, et sert d'étalon jusqu'à la mise en ligne. Toute autre référence, prise sur une préproduction déjà modifiée, mesure la dérive par rapport à un état intermédiaire et rate précisément ce qu'on cherche.

Prendre la référence avant de commencer

La série de référence se prend sur le site en production, dans son état actuel, et se conserve telle quelle jusqu'à la fin du projet. Il faut la stocker hors du dépôt de code, car une centaine de captures pleine page pèse plusieurs centaines de mégaoctets, et la nommer d'après l'URL et la largeur plutôt que d'après un numéro d'ordre : une liste d'URL qui évolue en cours de projet décale tous les numéros et invalide silencieusement les comparaisons.

Rejouer à chaque étape, pas seulement à la fin

La comparaison gagne à tourner à chaque livraison intermédiaire, ce qui transforme un rapport final de trente écarts en trois rapports de dix, chacun immédiatement rattachable à ce qui vient d'être modifié. C'est la même logique qu'une intégration continue, appliquée à l'apparence. Sur un projet mené sur plusieurs semaines, cela change complètement le travail de correction : on ne cherche plus quelle modification parmi cinquante a cassé un affichage, on le sait.

Conserver le rapport comme preuve de recette

Le dernier intérêt est contractuel. Un rapport listant les URL comparées, les largeurs testées, les écarts détectés et leur traitement constitue une trace de recette opposable, ce qu'aucune validation de vive voix ne remplace. Il vaut également pour la suite : conservé après la mise en ligne, il devient la référence de la prochaine intervention, et permet de vérifier en quelques minutes qu'une mise à jour de thème ou d'extension n'a rien déplacé.

Ce que la comparaison visuelle ne verra jamais

Il reste à connaître les angles morts, faute de quoi le rapport vert donne une confiance excessive. La comparaison d'images ne dit rien du code sous jacent : deux pages visuellement identiques peuvent avoir perdu leurs données structurées, leur balise canonique, leurs attributs de langue ou la hiérarchie de leurs titres, autant d'éléments invisibles à la photographie et déterminants pour le référencement. Elle ne dit rien non plus des états qu'elle ne visite pas, un menu déployé, un formulaire en erreur, un panneau ouvert au clic, ni du comportement au survol. Elle ignore enfin tout ce qui relève du temps de chargement, puisqu'elle attend justement que la page soit complète avant de photographier. Une recette de refonte complète superpose donc trois contrôles distincts, l'apparence par la comparaison d'images, le balisage par une extraction automatique des balises critiques sur les mêmes URL, et le comportement par quelques scénarios joués de bout en bout. Ces trois contrôles se lancent depuis la même commande et produisent un rapport unique, faute de quoi ils finissent exécutés séparément, à des moments différents, et personne ne sait plus lequel a réellement tourné avant la mise en ligne.