Tests de régression visuelle dans le workflow CI : comment la mise en page entre dans le pipeline

Les équipes de développement modernes s'appuient sur leur pipeline d'intégration continue : chaque push déclenche un build, les tests unitaires s'exécutent, le linter contrôle le style, et ce n'est qu'une fois tout au vert que le code rejoint la branche principale. Ce filet de sécurité a pourtant un angle mort. Si le site ressemble encore, après la modification, à ce qu'il est censé être, le pipeline classique ne le vérifie pas. Un refactoring CSS peut passer tous les tests et pousser malgré tout le formulaire de contact derrière le pied de page.

La raison tient à la nature des types de tests habituels. Les tests unitaires vérifient des fonctions par rapport à des valeurs de retour attendues, les tests d'intégration l'interaction des composants, les tests de bout en bout parcourent des enchaînements à coups de clics et contrôlent que les éléments définis sont bien présents. Aucune de ces approches ne voit la page comme un être humain la voit : comme une image rendue. Un bouton peut être techniquement présent, cliquable et correctement libellé — et rester malgré tout invisible, blanc sur blanc.

Comment naissent de telles ruptures, le quotidien le montre : une mise à jour de dépendance entraîne une nouvelle version du framework CSS qui fixe différemment quelques espacements par défaut. Un refactoring renomme une classe utilitaire encore employée à un endroit oublié. Un fichier de police est remplacé et se révèle infimement plus large, sur quoi une navigation passe à la ligne. Rien de tout cela ne lève d'erreur, rien de tout cela n'échoue au build — et chacune de ces modifications paraît parfaitement inoffensive dans la vue du code.

Les tests de régression visuelle comblent cette lacune avec un principe simple. Pour un ensemble de pages définies, on fixe un état de référence, la fameuse baseline. Après chaque modification, de nouvelles captures d'écran sont produites, qu'un outil compare à cette baseline. Si l'image actuelle s'en écarte, le contrôle se déclenche, et un être humain tranche : modification voulue ou régression ?

La question intéressante en pratique est moins le si que le où : à quel endroit du workflow CI de tels contrôles ont-ils leur place ? Contrairement aux tests unitaires, qui travaillent directement sur le code source, les tests visuels ont besoin d'une page rendue et accessible par le réseau. Cela les déplace en bout de chaîne — là où une version exécutable de l'application existe déjà.

C'est pourquoi des services comme ScanU fonctionnent à partir d'une URL : on transmet l'adresse d'une page accessible, et le service produit en une trentaine de secondes des captures sur plusieurs navigateurs et classes d'appareils — Chrome, Firefox et Safari, chaque fois en vues mobile, tablette et bureau. Comment ScanU construit un tel passage de contrôle, étape par étape, le fournisseur le décrit lui-même ; le schéma de base vaut toutefois pour tout outil fondé sur des URL : sans un environnement qui livre le nouvel état, il n'y a rien à photographier.

C'est dans les workflows dotés de ce que l'on appelle des déploiements de prévisualisation que cela s'insère le plus élégamment. Beaucoup de plateformes d'hébergement construisent automatiquement, pour chaque pull request, un environnement de prévisualisation propre avec sa propre adresse. C'est précisément cette adresse qui constitue le point d'accroche naturel de la comparaison visuelle : la prévisualisation montre l'état après la modification, la baseline l'état validé qui la précède. Si la comparaison signale un écart, toutes les personnes concernées voient le problème avant que le code n'atteigne la branche principale — et la discussion a lieu là où elle doit avoir lieu : dans la revue de code.

Concrètement, l'ordre des opérations dans un tel pipeline ressemble à ceci : la CI construit d'abord le nouvel état, puis la plateforme d'hébergement publie l'environnement de prévisualisation et en renvoie l'adresse, et ce n'est qu'ensuite que l'étape de contrôle visuel peut démarrer. C'est exactement à cet endroit que, dans la pratique, les choses tournent le plus souvent mal. Qui déclenche la prise de captures avant que la prévisualisation ne soit entièrement déployée photographie une page à moitié chargée ou un message d'erreur — et la compare ensuite, très sérieusement, à la baseline. Une brève vérification de l'accessibilité de l'adresse de prévisualisation avant le passage proprement dit épargne ce genre de confusion. Une fois le rapport terminé, son lien a sa place sur la pull request, en commentaire ou dans le texte de description, afin que l'appréciation se fasse là où l'on parle de toute façon de la modification. Les rapports partageables, tels que ScanU les produit, sont pensés exactement pour ce geste : le rapport est la base de discussion commune, non une fenêtre d'outil qu'une seule personne a ouverte.

Les équipes sans environnement de prévisualisation se rabattent sur l'environnement de préproduction et contrôlent après la fusion, mais avant le déploiement en production. C'est la deuxième meilleure solution : les régressions se remarquent plus tard, une fois que plusieurs modifications se sont déjà mélangées, et la recherche du coupable devient plus laborieuse. Un passage régulier supplémentaire contre le site de production intercepte en outre des changements qui ne proviennent pas du tout du code maison — par exemple lorsqu'un script intégré depuis l'extérieur ou une mise à jour du CMS déplace l'apparence.

L'intégration technique est à cet égard la plus petite partie du travail. La plus grande relève du processus : l'entretien de la baseline. Une baseline n'est pas un artefact technique, mais un accord — voilà à quoi la page doit ressembler. Qui déploie une modification de design voulue doit ensuite actualiser sciemment la baseline, faute de quoi chaque passage suivant signalera le même écart attendu. Qui, à l'inverse, l'actualise par réflexe après chaque alerte finira un jour par ériger une véritable erreur en état de référence.

Une pratique a fait ses preuves : traiter les mises à jour de baseline comme des modifications de code. Quelqu'un les examine, quelqu'un les valide, et la validation reste traçable. ScanU présente pour cela la baseline et l'état actuel côte à côte et produit des rapports partageables. Cela paraît peu spectaculaire, mais change la collaboration : des collègues du design ou de la gestion de produit peuvent eux aussi juger un écart sans démarrer un environnement de développement — et la décision « voulu ou cassé » n'est souvent pas purement technique.

Une équipe devrait par ailleurs clarifier à qui appartient le contrôle. Les tests visuels que personne ne s'est vu attribuer tombent immanquablement en déshérence : les rapports s'accumulent, personne ne se sent responsable, et au bout d'un mois tout le monde les ignore. La même règle que pour les builds cassés a fait ses preuves — celui qui a provoqué la modification s'occupe de l'écart signalé, et une astreinte tournante garde un œil sur les passages réguliers.

La planification englobe aussi la question de la fréquence des contrôles. Chaque commit n'a pas besoin du passage complet sur toutes les pages et toutes les combinaisons d'appareils. Les modèles de facturation comme le système de crédits de ScanU rendent cette réflexion concrète : le palier gratuit comprend 500 crédits par mois pour un projet, les paliers payants vont de 3000 crédits pour 19 euros jusqu'à 50000 crédits pour 49 euros par mois. Qui fait passer chaque exécution du pipeline par l'ensemble des profils d'appareils épuise vite son contingent — et produit au passage plus de rapports que l'équipe ne peut en regarder.

Un échelonnement est plus judicieux. Les pull requests qui modifient des styles ou des gabarits reçoivent la comparaison sur les pages les plus importantes ; un passage quotidien ou hebdomadaire couvre l'ensemble plus large sur tous les navigateurs ; avant une livraison, tout tourne une fois. Le rapport signal-bruit reste ainsi sain, et chaque alerte a une chance réelle d'être prise au sérieux. Un test visuel dont l'équipe évacue les messages par routine vaut moins que pas de test du tout.

Pour le choix des pages, la règle est : des gabarits plutôt que des instances. Une boutique en ligne n'a pas à photographier 2000 fiches produit, mais une page représentative par type de mise en page. La page d'accueil, une page produit ou article par gabarit, le panier, les formulaires et la page d'erreur couvrent, dans la plupart des projets, l'essentiel du risque. Les pages à forte valeur commerciale — le processus de paiement, par exemple — méritent alors davantage de combinaisons d'appareils que l'Impressum, les mentions légales obligatoires sur les sites allemands.

Le même arbitrage vaut pour les profils d'appareils. Les paliers tarifaires de ScanU se distinguent aussi par le nombre d'appareils disponibles — de dix dans le palier gratuit jusqu'à 98 dans le plus grand. Cela pousse à l'exhaustivité, mais davantage de profils signifie davantage d'images, davantage de crédits et davantage de travail de relecture. Plus praticable est de se régler sur ses propres statistiques de fréquentation : les trois ou quatre combinaisons d'appareils par lesquelles arrive réellement la majorité des visiteuses et visiteurs, plus un représentant de chacun des extrêmes — très étroit, très large.

Un obstacle mérite une attention particulière : les contenus dynamiques. Encarts rotatifs, recommandations personnalisées, bandeaux de cookies, heures affichées ou publicités modifient l'image à chaque appel — sans la moindre régression. Ces faux positifs sont la raison la plus fréquente pour laquelle des équipes désactivent à nouveau les tests visuels après quelques semaines. Les remèdes sont connus : des environnements de test avec des données d'exemple figées, des animations désactivées, des états de départ cohérents. Les faux positifs ne disparaissent jamais tout à fait, mais on peut les ramener à un niveau supportable.

L'honnêteté commande aussi de nommer les limites. Une comparaison de captures réussie ne dit rien de la question de savoir si le formulaire envoie effectivement des données, si la recherche renvoie des résultats ou si le processus de paiement va jusqu'au bout. Les tests visuels contrôlent la présentation, pas la fonction — ils complètent les tests unitaires et de bout en bout, ils ne les remplacent pas. Qui réduit sa couverture de tests fonctionnels au profit de captures d'écran échange un risque contre un autre.

La portée du résultat dépend elle aussi de l'environnement. Les contrôles fondés sur une URL photographient ce que livre l'adresse indiquée. Si l'environnement de préproduction diffère nettement de la production — autres données, autres feature flags, scripts tiers absents —, c'est une image déformée que l'on contrôle. Et les zones situées derrière une authentification exigent des réflexions à part avant qu'un service externe puisse seulement les saisir.

Pour que le contrôle reste ancré dans l'équipe, un rapport sobre à ses résultats aide. Il vaut la peine de dresser de temps à autre un bilan : combien d'écarts signalés étaient de véritables régressions, combien de faux positifs, combien de modifications voulues ? Si le rapport bascule du côté des faux positifs, ce n'est pas une raison pour désactiver, mais une commande de travail adressée à l'environnement de test. Et si la comparaison ne trouve simplement rien pendant des mois, une équipe peut aussi abaisser la fréquence des contrôles — la discipline de test ne signifie pas déploiement maximal, mais juste mesure.

L'historique est un aspect sous-estimé. Si une régression ne se remarque qu'au bout de plusieurs jours, le regard en arrière aide : quand la page avait-elle l'air correcte pour la dernière fois, quelle période entre en ligne de compte comme cause ? ScanU conserve les historiques entre trois et 90 jours selon le palier tarifaire. Cela aussi relève de la planification — un historique de trois jours est vite épuisé par un week-end prolongé, tandis que 90 jours répondent également à la question de savoir si un problème existait déjà avant la dernière livraison trimestrielle.

Pour se lancer, beaucoup plaide en faveur d'un petit commencement : un projet, une poignée de pages, un passage hebdomadaire plus un passage par livraison. À mesure que la confiance dans les alertes grandit suit l'imbrication plus étroite avec le pipeline. Les détails de fonctionnement figurent dans la documentation de ScanU ; un aperçu en français est proposé par la page produit francophone du fournisseur.

Reste la question de fond : l'effort en vaut-il la peine ? La réponse dépend moins de la taille de l'équipe que de la fréquence des changements. Qui déploie chaque semaine produit chaque semaine des occasions de ruptures silencieuses de mise en page — et, sans contrôle systématique, ne les découvre que lorsque les utilisatrices et utilisateurs les ont vues depuis longtemps. Le pipeline CI a appris au quotidien du développement à attraper les erreurs de logique avant la publication. Il y a peu de raisons de refuser la même protection à la couche la plus visible d'un site web.