Livrez l’interface que vous avez conçue — pas celle qui a glissé à travers la CI

Les tests fonctionnels répondent bien à une question : « ce bouton fait-il ce qu’il doit faire quand on clique dessus ? » Ils sont muets sur tout ce qui se passe avant le clic — si le bouton a la bonne couleur, la bonne taille, la bonne place, s’il reste lisible sur un écran de 360 pixels ou s’il est simplement visible après le dernier refactoring CSS. C’est exactement dans cette zone que vivent la plupart des incidents du jour J.

Les régressions réelles que nous observons, et que ScanU est conçu pour attraper, se regroupent autour d’une poignée de déclencheurs prévisibles :

• Un refactoring CSS écrase le gap d’un conteneur flex sur un unique point de rupture. Sur desktop, la mise en page paraît identique ; sur une tablette de 768 pixels, deux cartes se chevauchent désormais.
• Un ajustement de design tokens décale chaque valeur d’espacement de deux pixels. Rien ne casse ; une douzaine de compositions soigneusement équilibrées cessent silencieusement de l’être.
• Un widget tiers — une bannière de cookies, un live-chat, un emplacement publicitaire — déploie une mise à jour silencieuse qui déplace le first paint. Les Core Web Vitals régressent du jour au lendemain, sans aucun changement de code de votre côté.
• Une montée de version d’un framework remplace la pile de font-features par défaut. Les textes se reflow d’une demi-ligne sur les pages longues. Les CTA du hero passent soudain sous la ligne de flottaison.
• Le déploiement d’un feature flag réordonne le DOM. Sur Safari, le contexte d’empilement d’une modale change et le bouton de fermeture devient inclicable. Sur Chrome, tout paraît normal.

Aucune de ces modifications ne fait échouer une assertion. Toutes cassent quelque chose pour l’utilisateur. Le travail de ScanU est de rendre ce deuxième type de défaillance aussi facile à voir, à relire et à bloquer qu’un test unitaire en erreur. Lorsque le diff apparaît sur la pull request, une designer peut intervenir comme un reviewer intervient sur une signature de fonction — avant le merge, pas après la mise en production.

Ce basculement — passer de « on espère que quelqu’un le verra en staging » à « on relit un changement visuel comme on relit un changement de code » — est la valeur centrale d’un outil de tests de régression visuelle dans un pipeline de livraison moderne.

Chaque exécution est un pipeline en trois étapes. D’abord, ScanU navigue dans chaque moteur vers la page ou le composant à tester, attend un ensemble configuré de signaux de préparation — polices chargées, images décodées, réseau calme, un attribut data-ready ou une sonde JavaScript personnalisée — et épingle toutes les animations CSS sur leur image finale. Ensuite, il capture la page sur chaque viewport configuré dans la même exécution, avec du scroll-stitching pour les pages longues, de sorte que vous obteniez l’artefact complet et non pas seulement la portion visible. Enfin, il compare cette capture à la baseline acceptée et produit un résultat par paire (navigateur, viewport) : identique, dans la tolérance, ou significativement différent.

La comparaison elle-même n’est pas un diff de pixels naïf. ScanU applique un modèle perceptuel qui comprend l’anti-aliasing, le rendu sous-pixel et les écarts d’espace colorimétrique — pour qu’une bizarrerie de kerning sur WebKit ne soit pas confondue avec un bug. Le pipeline prend aussi en charge des masques explicites pour les régions que vous savez changeantes à chaque chargement — données en direct, horodatages relatifs, contenus randomisés, carrousels — de sorte que ces zones apportent zéro bruit au diff.

Quand un vrai changement apparaît, la plateforme présente trois vues synchronisées : la baseline, la capture actuelle et un overlay de diff qui met en évidence ce qui a bougé. Une seule décision à relire — accepter, rejeter ou mettre à jour la baseline — est enregistrée pour chaque changement, et cette décision devient une partie de l’historique du projet. Pas de dérive silencieuse, pas d’acceptation automatique : la baseline ne bouge que lorsqu’une personne autorisée le décide.

Le même pipeline peut être déclenché par trois points d’entrée : contre des URL en direct (production, staging, previews de PR), contre un site statique ou un bundle d’assets, ou contre des previews de composants dans une sandbox à la Storybook. La plupart des équipes utilisent la première voie pour les release gates, la seconde pour les artefacts de déploiement et la troisième pour le travail sur le design system — les trois alimentent le même stockage de baselines.

Quelle que soit la forme de l’équipe, ScanU est typiquement adopté pour l’une de cinq raisons : un incident récent en production qu’une régression visuelle aurait attrapé ; une migration de design system dont le périmètre d’impact est impossible à auditer manuellement ; un workflow CI/CD qui réclame un release gate plus riche que « tests passés » ; un livrable orienté client qui demande des preuves avant/après ; ou une posture compliance qui préfère un outillage de test hébergé en UE. Une intégration CI/CD partagée est derrière ces cinq cas — le même pipeline fait le travail qu’il soit déclenché par une PR, un merge ou une planification nocturne.

ScanU est construit et hébergé dans l’Union européenne ; le stockage et le traitement se font sur une infrastructure exploitée en UE. Pour les équipes aux engagements de résidence des données — secteurs régulés, acheteurs publics, clients B2B sensibles à la confidentialité — c’est souvent une exigence d’achat, non une préférence. ScanU est conçu pour satisfaire cette exigence sans obliger à un compromis sur les capacités produit.

Quelques choix de design délibérés en découlent :

• Minimisation des données. La plateforme stocke les captures et les métadonnées nécessaires au diff ; elle n’aspire ni le code source de la page, ni les cookies, ni les corps de requête qui n’apportent rien au diff.
• Masquage par défaut dans les contextes sensibles. Les champs connus pour contenir des données personnelles — en-têtes de compte, adresses e-mail, numéros de commande — peuvent être déclarés comme régions masquées, de sorte que l’image capturée soit déjà caviardée lorsqu’elle est écrite dans le stockage.
• Contrôle d’accès. Qui peut voir un diff est un droit de premier ordre. Reviewers, contributeurs et auditeurs externes reçoivent des rôles explicites, et chaque mise à jour de baseline est tracée avec la personne qui l’a autorisée.
• Transparence sur les sous-traitants. La liste des sous-traitants est publiée et versionnée. Aucun pipeline d’analytics caché ne voit vos captures.
• Rétention sous votre contrôle. Baselines et artefacts de diff sont conservés pour l’horizon que vous configurez ; les anciennes exécutions expirent automatiquement au lieu de s’accumuler en silence.

Pour la posture de confidentialité complète — sous-traitants, hébergement régional, DPA, fenêtres de rétention — voyez la documentation RGPD et traitement des données. Pour la plupart des équipes, la réponse courte suffit : vos captures restent en UE, et la plateforme est construite pour qu’elles y restent.

Les bugs visuels se regroupent dans une poignée de motifs récurrents. Chacun paraît trivial en isolé ; chacun peut partir en production sans un seul test rouge. Tous sont remontés comme diff lors du prochain passage de ScanU, avant que la PR ne soit mergée.

• Décalages d’espacement. Un utilitaire de gap passe de 16 à 20 pixels ; une grille de cartes qui respirait paraît soudain étriquée sur mobile. Le HTML est inchangé ; la mise en page ne l’est pas.
• Mises en page cassées après déploiement. Une montée de version du pipeline laisse tomber un plugin PostCSS qui autopréfixait backdrop-filter. Sur Safari, une barre de navigation rend soudain opaque là où elle floutait.
• Régressions CSS par décalage de spécificité. Un changement d’ordre de classes Tailwind, une nouvelle couche utilitaire ou une cascade refactorisée modifient subtilement la règle gagnante — un titre perd sa couleur d’accent sur une poignée de pages.
• Points de rupture responsive défaillants. Un nouvel item de nav déborde au breakpoint tablette et repasse sur une deuxième ligne, poussant le hero sous la ligne de flottaison sur iPad et sur les grands Android.
• Différences de rendu entre navigateurs. Un design qui s’appuie sur text-wrap: balance est net sur Chrome mais reste déséquilibré sur les moteurs qui ne l’ont pas encore livré. Sans contrôle cross-browser, c’est invisible sur la machine du développeur.
• Dérive de polices et de typographie. Un fournisseur de polices échange un subset, les graisses se décalent de cent grammes, et chaque paragraphe d’un site marketing se reflow d’un quart de ligne. La densité de copie change ; aucun diff dans le dépôt ne l’explique.
• Régressions de widgets tiers. Un éditeur de bannière de consentement déploie une mise à jour qui rend le bouton d’acceptation invisible sur les thèmes sombres. Votre taux de conversion chute ; vos tests passent.
• Dérive du design system. Un composant bouton change l’offset de son focus ring. Vingt consommateurs dépendent de ce composant. Vingt pages ont maintenant un rendu subtilement différent. Personne ne relit vingt pages à la main.
• Bugs visuels qui s’échappent en production. Tous ceux ci-dessus, multipliés par les routes et les breakpoints que personne n’ouvre dans une semaine donnée, sur les navigateurs que personne dans l’équipe n’utilise au quotidien.

L’ aperçu des fonctionnalités détaille les primitives de détection — tolérances perceptuelles, régions masquées, capture au scroll, branching de baseline — et montre à quelle catégorie ci-dessus chacune répond. Pour la plupart des équipes, la version courte tient en trois phrases : si quelque chose change visuellement, ScanU le remarque ; si c’est attendu, vous l’acceptez en un clic ; sinon, vous l’avez attrapé avant qui que ce soit d’autre.