Checklist QA visuelle : ce qu'il faut vérifier avant chaque release

Livrer une release sans QA visuelle est un pari risqué. Les tests fonctionnels confirment que les fonctionnalités marchent, mais ils ne confirment pas que l'interface s'affiche correctement. Un bouton peut réussir chaque test d'intégration et quand même chevaucher un champ de formulaire sur Safari mobile. Un titre peut s'afficher parfaitement en anglais et déborder de son conteneur une fois traduit en allemand.

Cette checklist couvre les vérifications visuelles que chaque équipe web devrait effectuer avant qu'une release ne passe en production. Utilisez-la telle quelle ou adaptez-la à votre stack technique et à votre audience.

Pourquoi une checklist visuelle est importante

Les bugs visuels sont particulièrement dommageables car ils sont immédiatement visibles pour les utilisateurs. Un élément mal aligné ou une mise en page cassée érode la confiance d'une manière qu'une réponse API lente ne peut pas. Pourtant, la QA visuelle est souvent la partie la moins structurée du processus de release — réalisée de manière incohérente, par différentes personnes, sans critères partagés.

Une checklist écrite résout ce problème en rendant la QA visuelle répétable et mesurable. Tout le monde dans l'équipe sait ce que signifie « visuellement vérifié », et aucune catégorie de vérification n'est omise parce que quelqu'un a oublié.

Mise en page et espacement

Les problèmes de mise en page sont les régressions visuelles les plus courantes. Vérifiez-les systématiquement :

La structure de la page est intacte — l'en-tête, le contenu principal, la barre latérale (si présente) et le pied de page s'affichent dans le bon ordre avec l'espacement attendu.
Les grilles et flexbox se redistribuent correctement — vérifiez aux largeurs desktop, tablette et mobile. Recherchez les retours à la ligne de colonnes inattendus ou les éléments débordant de leurs conteneurs.
L'espacement entre les sections est cohérent — les marges et le padding correspondent à la spécification design. Surveillez les sections trop proches ou trop éloignées les unes des autres.
Pas d'éléments superposés — vérifiez que les éléments positionnés en absolu (tooltips, dropdowns, modales) ne chevauchent pas le contenu et ne dépassent pas le viewport.
Les éléments sticky et fixed se comportent correctement — les en-têtes sticky et les pieds de page fixés restent en position lors du défilement sans masquer le contenu derrière eux.

Pour la vérification automatisée de la mise en page sur tous les breakpoints, consultez notre guide sur les workflows de tests cross-navigateurs.

Typographie et contenu

Les problèmes de rendu du texte sont subtils mais affectent la lisibilité et le professionnalisme :

Les titres suivent la bonne hiérarchie — les tailles et graisses H1, H2, H3 correspondent au design system.
Le texte courant est lisible — la taille de police, la hauteur de ligne et le contraste respectent les standards d'accessibilité. Testez avec du vrai contenu, pas du texte fictif.
Pas de troncature ni de débordement de texte — les longs titres, les chaînes traduites et le contenu dynamique rentrent dans leurs conteneurs. Vérifiez particulièrement avec des langues plus longues comme l'allemand.
Les liens sont visuellement identifiables — le soulignement, la couleur ou un autre style rend les liens reconnaissables sans se fier uniquement à la couleur.
Les blocs de code et le texte préformaté s'affichent correctement — les polices monospace se chargent, la coloration syntaxique fonctionne et le défilement horizontal apparaît pour les longues lignes.
Les listes s'affichent avec les bons marqueurs — les listes ordonnées montrent des numéros, les listes non ordonnées montrent des puces, et l'imbrication est visuellement claire.

Comportement responsive

Les bugs responsive représentent une part disproportionnée des problèmes visuels signalés par les utilisateurs :

Mise en page mobile (largeur 375 px) — vérifiez la page entière à la largeur mobile typique. La navigation se replie en hamburger, les images s'adaptent et le contenu s'empile verticalement.
Mise en page tablette (largeur 768 px) — c'est là que se cachent la plupart des bugs responsive. Les mises en page à deux colonnes doivent transitionner proprement, et les cibles tactiles doivent être dimensionnées de manière adéquate.
Mise en page desktop (largeur 1440 px) — l'expérience desktop principale. Les mises en page multi-colonnes s'affichent correctement et les largeurs maximales de contenu sont respectées.
Desktop large (largeur 1920 px+) — le contenu ne devrait pas s'étirer pour remplir les écrans ultra-larges. Vérifiez que les largeurs maximales et le centrage fonctionnent correctement.
Changements d'orientation — sur mobile et tablette, le passage entre portrait et paysage ne devrait pas casser la mise en page.
Comportement du zoom — le zoom navigateur à 150 % et 200 % ne devrait pas causer de chevauchements ou de contenu masqué.

Rendu cross-navigateurs

Les différents moteurs de navigateur interprètent le CSS différemment. Vérifiez au moins ces combinaisons :

Chrome desktop — votre rendu de référence. La plupart des utilisateurs verront cette version.
Firefox desktop — détecte les problèmes spécifiques à Gecko avec le gap flexbox, les métriques de police et les propriétés personnalisées.
Safari desktop — WebKit a un comportement unique pour backdrop-filter, position-sticky et flex-wrap.
Safari mobile (iOS) — tous les navigateurs iOS utilisent WebKit. La gestion du viewport, les insets de zone sûre et le comportement de défilement diffèrent du desktop.
Chrome mobile (Android) — vérifiez les cibles tactiles, le comportement du meta viewport et le styling spécifique mobile.

Vous n'avez pas besoin de vérifier chaque navigateur pour chaque page. Priorisez par données de trafic : couvrez les combinaisons qui représentent 90 % de votre audience. Consultez notre guide des tests de régression visuelle pour en savoir plus sur la construction d'une matrice navigateur.

États interactifs

Les éléments interactifs ont de multiples états visuels. Chacun nécessite une vérification :

Boutons — les états par défaut, survol, focus, actif, désactivé et chargement s'affichent tous correctement et sont visuellement distincts.
Champs de formulaire — les états vide, focus, rempli, erreur et désactivé. Vérifiez que les messages d'erreur apparaissent à la bonne position et ne décalent pas la mise en page.
Navigation — l'indicateur de page active, les effets de survol sur les liens, les menus déroulants s'ouvrent et se ferment à la bonne position.
Modales et dialogues — s'ouvrent en douceur, se centrent correctement sur toutes les tailles d'écran et affichent un fond visible. Le bouton de fermeture est accessible.
Tooltips et popovers — apparaissent à la bonne position par rapport à leur déclencheur. Ne sont pas coupés par les conteneurs overflow-hidden ou le bord du viewport.
États de chargement — les skeleton screens, spinners et barres de progression s'affichent correctement pendant le chargement des données.

Images et médias

Les médias visuels nécessitent leur propre ensemble de vérifications :

Les images se chargent et s'affichent — pas d'icônes d'image cassée. Toutes les images ont un texte alt approprié pour l'accessibilité.
Les images sont correctement dimensionnées — pas de distorsion ni de recadrage inattendu. Les proportions sont maintenues.
Les images responsive servent les tailles appropriées — les appareils mobiles ne téléchargent pas des images de taille desktop.
Les vidéos intégrées fonctionnent — les boutons de lecture s'affichent, les proportions sont correctes et les intégrations ne débordent pas de leurs conteneurs.
Les icônes s'affichent correctement — les icônes SVG s'affichent à la bonne taille et couleur. Les polices d'icônes se chargent sans afficher de caractères de substitution.

Accessibilité et couleur

La QA visuelle et l'accessibilité se chevauchent considérablement :

Le contraste des couleurs respecte WCAG AA — le texte et les éléments interactifs ont un contraste suffisant avec leurs fonds. Vérifiez les thèmes clair et sombre si applicable.
Les indicateurs de focus sont visibles — la navigation au clavier devrait montrer un anneau de focus clair sur tous les éléments interactifs.
Le mode sombre s'affiche correctement — si votre application supporte le mode sombre, vérifiez que tous les composants, images et textes sont lisibles dans les deux thèmes.
Pas d'information transmise uniquement par la couleur — les états d'erreur, les indicateurs de statut et les champs obligatoires utilisent des icônes ou du texte en plus de la couleur.

Vérifications visuelles liées à la performance

Les problèmes de performance peuvent se manifester sous forme de problèmes visuels :

Pas de décalage de mise en page pendant le chargement — le contenu ne saute pas pendant le chargement des polices, images ou scripts. Ceci est mesuré par le Cumulative Layout Shift (CLS).
Les polices web se chargent avant l'affichage — pas de flash de texte non stylé (FOUT) ni de texte invisible (FOIT) pendant le chargement de la page.
Le contenu au-dessus de la ligne de flottaison s'affiche rapidement — la partie visible de la page devrait apparaître en 1 à 2 secondes sur une bonne connexion.

Workflow de vérification pré-release

Utilisez ce workflow pour exécuter la checklist de manière cohérente :

Déployez en staging — vérifiez dans un environnement qui reproduit la production le plus fidèlement possible.
Exécutez les tests de screenshots automatisés — capturez les baselines sur votre matrice navigateur et appareil. Consultez notre guide d'automatisation CI/CD pour les instructions de mise en place.
Revoyez les diffs automatisés — classifiez chaque diff comme intentionnel, régression ou bruit.
Effectuez des vérifications manuelles ciblées — les tests automatisés couvrent le rendu statique. Vérifiez manuellement les états interactifs, les animations et les cas limites.
Documentez les résultats — enregistrez quelles vérifications ont réussi, lesquelles ont échoué et ce qui a été corrigé. Cela crée une piste d'audit pour les futures releases.
Approuvez ou bloquez — si toutes les vérifications passent, approuvez la release. Si des bugs visuels critiques persistent, bloquez jusqu'à leur résolution.

Adapter la checklist à votre équipe

Cette checklist est volontairement exhaustive. Pour votre équipe, personnalisez-la en fonction de :

Votre stack technique — si vous ne supportez pas le mode sombre, supprimez ces vérifications. Si vous utilisez un design system, ajoutez des vérifications au niveau des composants.
Votre audience — si 95 % de votre trafic vient de Chrome, réduisez le périmètre cross-navigateurs et augmentez les tests mobile.
Votre tolérance au risque — les applications critiques pour le chiffre d'affaires nécessitent des vérifications plus strictes. Les outils internes peuvent utiliser un processus plus léger.

L'essentiel est la cohérence. Une checklist plus courte exécutée à chaque release a plus de valeur qu'une checklist exhaustive qui est ignorée sous la pression des délais.

Continuer avec ScanU

Les tests de screenshots automatisés gèrent les parties les plus chronophages de cette checklist : la vérification de la mise en page, le rendu cross-navigateurs et les vérifications aux breakpoints responsive. ScanU capture des screenshots sur tous les navigateurs et appareils pour que votre équipe puisse se concentrer sur les états interactifs et les cas limites. Explorez les options de tarification sur Pricing, découvrez la plateforme sur Features et consultez les réponses aux questions courantes dans la FAQ.