Tests Visuels Flaky : Pourquoi Ils Détruisent Votre QA et Comment les Stabiliser
Un test flaky (ou test instable) est un test qui produit des résultats différents — succès ou échec — pour un même code et une même configuration, sans qu'aucune modification n'ait été apportée au système testé.
Voici une opinion qui va peut-être vous déranger : un test visuel flaky est pire que pas de test du tout. Et ce n'est pas une provocation gratuite. Un test absent ne coûte rien au quotidien. Il ne bloque pas votre pipeline. Il ne consomme pas le temps de votre équipe. Il ne détruit pas la confiance dans votre infrastructure de test. Un test flaky fait tout cela, chaque jour, et il le fait insidieusement — parce que chaque faux échec ressemble juste assez à un vrai pour exiger une investigation.
Les données de Google sur leurs propres systèmes de test sont éloquentes : environ 1,5 % de leurs tests sont flaky à un moment donné, mais ces tests consomment une part disproportionnée du temps d'ingénierie. Si une entreprise de la taille et de la compétence technique de Google n'a pas éliminé le problème, c'est que la question n'est pas triviale. Et dans le domaine spécifique du test visuel, le problème est amplifié par la nature même de ce qu'on compare.
Pourquoi les tests visuels sont particulièrement vulnérables à l'instabilité
Le test visuel automatisé introduit une couche de non-déterminisme que les tests unitaires ou fonctionnels ne connaissent pas. Un test unitaire vérifie qu'une fonction retourne la bonne valeur. Un test fonctionnel vérifie qu'un bouton déclenche la bonne action. Ces résultats sont binaires et déterministes — la fonction retourne 42 ou non, le bouton navigue vers la bonne page ou non.
Le test visuel, lui, vérifie que le rendu de votre interface correspond à une image de référence. Et le rendu d'une page web est le résultat d'une chaîne de processus complexes, chacun introduisant sa propre variabilité : le parsing HTML, l'application du CSS, l'exécution du JavaScript, le chargement des ressources externes, le calcul du layout, la rasterisation, la composition. Chaque étape dépend de facteurs qui varient d'une exécution à l'autre.
Un test fonctionnel qui vérifie que le bouton "Ajouter au panier" fonctionne est insensible au fait que le bouton ait bougé de 0,3 pixel à droite. Un test visuel, lui, le détecte. Et cette détection est tantôt un vrai positif (le bouton a bougé à cause d'un bug CSS), tantôt un bruit de rendu sans signification. C'est exactement cette ambiguïté qui rend les tests visuels flaky.
Les quatre causes principales des tests visuels flaky
Le timing : le problème que vous ne pouvez pas ignorer
Le web est asynchrone par nature. Quand vous demandez au navigateur de capturer un screenshot, la page est-elle réellement prête ? La réponse est presque toujours : ça dépend.
Le chargement d'une page web n'est pas un événement unique — c'est une cascade d'événements. Le HTML est parsé, le CSS est appliqué, les scripts sont exécutés, les images se chargent, les polices web s'appliquent, les requêtes API retournent des données, les composants se rendent. Chaque étape a une durée variable. Une requête API qui prend habituellement 50 ms peut en prendre 300 si le serveur est sous charge. Une image qui se charge en 100 ms peut prendre 2 secondes si le réseau est lent.
La stratégie classique est d'attendre que la page soit "prête" — l'événement DOMContentLoaded, l'événement load, ou l'absence d'activité réseau. Mais aucun de ces signaux ne garantit que le rendu visuel est complet. L'événement load se déclenche quand les ressources initiales sont chargées, mais les composants rendus côté client via JavaScript peuvent continuer à se charger bien après. L'absence d'activité réseau ne signifie pas que tous les éléments sont peints — le navigateur peut encore être en train de calculer le layout ou de rasteriser des éléments complexes.
Résultat : votre screenshot capture parfois une page complète, parfois une page en cours de rendu. Le même test passe le lundi et échoue le mardi, pour aucune raison liée à votre code.
Les animations : du mouvement dans un médium statique
Un screenshot est une image fixe. Une animation est un changement continu. Les deux sont fondamentalement incompatibles pour la comparaison automatisée. Nous avons détaillé ce problème dans notre guide sur les animations CSS et le test visuel, mais voici l'essentiel.
Si votre page contient une animation de 300 ms qui se lance au chargement, le moment exact de la capture du screenshot par rapport au début de cette animation varie d'une exécution à l'autre. À 100 ms, l'élément est à un tiers de son animation. À 200 ms, il est aux deux tiers. Les deux screenshots sont "corrects" — ils reflètent fidèlement l'état de la page au moment de la capture — mais ils sont visuellement différents, et l'outil de comparaison signale un échec.
Les animations infinies (spinners, skeleton loaders, indicateurs de progression) sont encore pires : il n'existe aucun moment "stable" pour capturer le screenshot, parce que l'élément est en perpétuel mouvement.
Le contenu dynamique : tout ce qui change sans vous
Les dates et heures qui s'affichent dans votre interface changent à chaque seconde. Les publicités tournent selon des algorithmes que vous ne contrôlez pas. Les avatars générés aléatoirement sont différents à chaque session. Les notifications en temps réel apparaissent de manière imprévisible. Les compteurs de visiteurs en ligne, les badges "nouveau", les messages de bienvenue personnalisés — tout ce contenu varie entre deux exécutions de test.
Chaque variation est détectée comme une différence visuelle. Chaque différence fait échouer le test. Et comme ces variations ne sont pas des bugs, chaque échec est un faux échec — un résultat flaky qui consomme votre temps sans rien apporter.
Le contenu dynamique est particulièrement traître parce qu'il est souvent distribué dans toute la page. Ce n'est pas un élément isolé que vous pouvez facilement exclure — c'est une date dans l'en-tête, un compteur dans la sidebar, un timestamp dans chaque message d'un fil de discussion.
Le réseau et l'infrastructure : les variables que vous ne maîtrisez pas
Votre test s'exécute dans un environnement qui dépend de ressources externes : serveurs d'API, CDN pour les images et les polices, services tiers pour les widgets et les analytics. La latence de chacune de ces ressources varie d'une exécution à l'autre.
Dans un pipeline CI/CD, le problème est amplifié. Votre runner CI partage des ressources avec d'autres jobs. La charge CPU disponible varie. La mémoire fluctue. Le réseau entre le runner et vos serveurs traverse des routes différentes selon le moment de la journée. Tous ces facteurs affectent le temps de rendu de la page, et donc l'état visuel au moment de la capture.
Un test qui passe systématiquement sur la machine du développeur peut échouer de manière intermittente en CI, simplement parce que l'environnement CI est moins prévisible. C'est frustrant, et c'est extrêmement courant.
Le coût réel des tests flaky
Le coût le plus visible est le temps de triage. Chaque test flaky qui échoue en CI nécessite une investigation : quelqu'un doit regarder les résultats, les comparer manuellement, décider si c'est un vrai bug ou du bruit, et relancer le pipeline si nécessaire. À raison de 5 à 15 minutes par investigation, et avec plusieurs échecs flaky par jour, le temps s'accumule rapidement.
Mais le coût le plus destructeur est invisible : c'est la perte de confiance. Quand une équipe apprend que les tests visuels échouent "tout le temps" sans raison, elle développe un réflexe de relance automatique. "Le test visuel a échoué ? Relance, ça va passer." Ce réflexe est rationnel — la plupart du temps, la relance suffit. Mais le jour où le test échoue à cause d'un vrai bug, le réflexe est le même : relance. Et le bug passe en production.
Ce phénomène a un nom dans la littérature sur la fiabilité logicielle : le "cry wolf effect", d'après la fable du garçon qui criait au loup. Une fois installé, il est très difficile à inverser. La confiance perdue dans une suite de tests prend des mois à reconstruire — si elle se reconstruit jamais.
Il y a aussi un coût d'opportunité. Le temps que votre équipe passe à gérer des tests flaky est du temps qu'elle ne passe pas à écrire de nouveaux tests, à améliorer la couverture, ou à corriger de vrais bugs. Les tests flaky ne sont pas juste un problème — ils sont un frein actif à l'amélioration de votre qualité logicielle.
Les stratégies de stabilisation qui fonctionnent
Contrôler l'environnement de rendu
La première ligne de défense est de minimiser la variabilité de l'environnement. Utilisez un navigateur headless dans un conteneur contrôlé avec une résolution fixe, des polices pré-installées, et une configuration réseau déterministe. Cela ne résout pas tout, mais cela élimine une catégorie entière de variabilité.
Concrètement, cela signifie figer la version du navigateur, installer toutes les polices utilisées par votre application dans le conteneur, désactiver le rendu GPU (qui introduit du non-déterminisme), et configurer un viewport de taille fixe. C'est un investissement initial, mais il se rentabilise rapidement.
Neutraliser les animations
Injectez une feuille de style qui force toutes les animations et transitions à une durée de zéro. Cela fige instantanément tous les éléments animés dans leur état final, éliminant le problème de timing. La plupart des frameworks de test visuel proposent cette option, et elle devrait être activée par défaut dans tous vos tests visuels.
Attention cependant : certaines animations sont fonctionnelles (un carrousel qui affiche le contenu, un accordéon qui déplie une section). Les désactiver peut cacher des parties de l'interface. Pour ces cas, attendez que l'animation atteigne son état final plutôt que de la désactiver.
Stabiliser le contenu dynamique
Pour le contenu qui change à chaque chargement, vous avez plusieurs options selon le contexte.
Les dates et heures peuvent être figées en configurant l'environnement de test avec une date fixe. Les publicités et widgets tiers peuvent être désactivés dans l'environnement de test. Les données d'API peuvent être mockées pour retourner des réponses constantes. Les avatars générés peuvent être remplacés par des images statiques dans les fixtures de test.
L'objectif est de créer un environnement de test où le seul facteur variable est le code de votre interface — tout le reste est contrôlé.
Attendre intelligemment
Au lieu de compter sur un délai fixe (attendre 3 secondes après le chargement), utilisez des stratégies d'attente basées sur l'état réel de la page. Attendez que les éléments critiques soient visibles, que les images soient chargées, que les polices soient appliquées, que les requêtes réseau soient terminées.
Les navigateurs modernes et les outils d'automatisation offrent des API pour observer l'état du DOM et du réseau. Utilisez-les pour définir des conditions de stabilité précises plutôt que des délais arbitraires.
Adopter une comparaison qui tolère le bruit
La comparaison pixel à pixel est la plus sensible au non-déterminisme du rendu. Les algorithmes perceptuels (SSIM, pHash) sont plus tolérants. L'approche structurelle — comparer le DOM et les propriétés CSS calculées plutôt que les pixels — est la plus résistante au bruit de rendu, parce qu'elle ignore par nature les variations sub-pixel qui causent la majorité des échecs flaky.
Le test visuel no-code comme solution au problème de maintenance
Un aspect souvent négligé du problème flaky est la maintenance. Les tests visuels basés sur du code (Playwright, Cypress, Selenium) nécessitent des scripts qui naviguent vers la page, interagissent avec les éléments, et capturent le screenshot. Ces scripts sont eux-mêmes une source d'instabilité : un sélecteur CSS qui ne trouve plus l'élément, un timing de clic qui rate sa cible, une assertion qui échoue parce que le texte a changé.
Les outils no-code comme Delta-QA éliminent cette couche de fragilité. Vous n'écrivez pas de scripts — vous configurez vos tests visuellement. L'outil gère le chargement, l'attente, la stabilisation, et la comparaison. Quand un élément change de sélecteur, l'outil s'adapte sans intervention. Quand le layout évolue, vous mettez à jour la baseline en un clic plutôt qu'en modifiant du code.
C'est une philosophie différente : au lieu de coder des tests fragiles que vous devez constamment réparer, vous configurez des vérifications visuelles que l'outil maintient pour vous.
Quand supprimer un test flaky
Si un test visuel échoue de manière intermittente malgré toutes vos tentatives de stabilisation, la décision la plus courageuse — et souvent la plus sage — est de le supprimer. Un test flaky que personne ne corrige est un test qui dégrade activement votre pipeline. Il entraîne votre équipe à ignorer les échecs. Il crée du bruit qui masque les vrais problèmes.
Supprimez-le, documentez pourquoi, et remplacez-le par une vérification plus ciblée. Parfois, un test fonctionnel qui vérifie que l'élément est présent et correctement positionné via le DOM est plus fiable qu'un screenshot comparison sur un composant instable.
Le but n'est pas d'avoir le maximum de tests — c'est d'avoir des tests auxquels votre équipe fait confiance.
FAQ
Quelle est la différence entre un test flaky et un faux positif ?
Un faux positif est un résultat de test qui signale un problème qui n'existe pas — une seule occurrence suffit. Un test flaky est un test qui produit des résultats inconsistants d'une exécution à l'autre pour le même code. Un test flaky produit des faux positifs de manière intermittente. Tous les tests flaky génèrent des faux positifs, mais tous les faux positifs ne viennent pas de tests flaky — certains sont systématiques.
Comment mesurer le taux de flakiness de mes tests visuels ?
La méthode la plus simple est de lancer la même suite de tests visuels plusieurs fois d'affilée sans modifier le code et de compter les tests dont le résultat change entre les exécutions. Cinq exécutions consécutives suffisent pour identifier les tests les plus instables. Divisez le nombre de tests dont le résultat a varié par le nombre total de tests pour obtenir votre taux de flakiness.
Les tests visuels no-code sont-ils moins flaky que les tests codés ?
Ils éliminent une catégorie de flakiness — celle liée aux scripts de test eux-mêmes (sélecteurs fragiles, timing de navigation, gestion d'état). Mais ils restent soumis aux mêmes contraintes de rendu navigateur que les tests codés. L'avantage principal est la réduction de la surface de fragilité : moins de code, moins de points de défaillance potentiels.
Faut-il relancer automatiquement les tests visuels qui échouent ?
La relance automatique (retry) est un pansement, pas une solution. Elle masque le problème de flakiness au lieu de le résoudre. Si vous devez activer les retries, limitez-les à une seule relance et marquez les tests qui ont nécessité une relance pour les investiguer. Un test qui ne passe qu'au deuxième essai est un test flaky qui attend d'être corrigé.
Quel est le seuil de flakiness acceptable en CI/CD ?
Visez un taux de flakiness inférieur à 1 % de votre suite de tests totale. Au-delà de 3 %, l'impact sur la productivité devient mesurable. Au-delà de 5 %, votre équipe développe presque certainement le réflexe de relancer systématiquement les pipelines qui échouent, ce qui signifie que votre suite de tests a perdu sa crédibilité comme filet de sécurité.
Delta-QA aide-t-il à stabiliser les tests visuels ?
Delta-QA réduit la flakiness à la source en utilisant une approche structurelle plutôt que pixel à pixel. Les variations de rendu sub-pixel, d'antialiasing et de timing qui causent la majorité des échecs intermittents sont ignorées nativement. Combiné à l'approche no-code qui élimine les scripts de test fragiles, Delta-QA produit des résultats de test fiables et reproductibles sans configuration complexe.
Un test visuel n'a de valeur que si votre équipe lui fait confiance. Les tests flaky détruisent cette confiance jour après jour. Au lieu de passer votre temps à stabiliser des scripts fragiles et à trier des faux échecs, adoptez un outil conçu pour la fiabilité dès le départ.