# « Elementor et une suite de tests visuels : les faux positifs après mise à jour » > Après une mise à jour mineure d'Elementor, 40 % des captures de la suite de tests visuels ont divergé sans qu'aucun changement fonctionnel n'ait été livré. Diagnostic. - Auteur : Clément Hadrot - Publié le : 2025-10-24 - Mis à jour le : 2025-10-24 - Catégorie : Tests - URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/elementor-tests-visuels-faux-positifs/ ## L’essentiel - Une mise à jour mineure peut modifier des pixels sans changer le comportement - Les polices système chargées différemment faussent les captures - Isoler la cause avant d'élargir les seuils de tolérance Quarante-deux captures d'écran sur cent-cinq marquées comme différentes, alors que la mise à jour livrée ne touchait, d'après le changelog, que la gestion du cache interne des styles. Aucune fonctionnalité visible n'avait changé. C'est le genre de rapport de CI qui pousse à désactiver purement et simplement la suite de tests visuels — la mauvaise réaction, mais une réaction compréhensible face à ce niveau de bruit. Ce billet documente le diagnostic mené sur ce cas précis, pas l'outil de comparaison utilisé (Percy a été traité séparément pour un autre contexte). L'objectif : comprendre pourquoi une mise à jour sans changement fonctionnel déclenche un tel volume de faux positifs, et comment réduire ce bruit sans perdre la capacité de détecter de vraies régressions. ## Premier suspect : le rendu des polices Une bonne partie des divergences provenait de sections utilisant la police par défaut du thème, chargée via `@font-face` avec une stratégie `font-display: swap`. Selon la vitesse de réponse du CDN de polices au moment de la capture, le rendu du texte basculait entre la police de secours et la police définitive avant que le screenshot ne soit pris, produisant des largeurs de texte légèrement différentes d'une exécution à l'autre. La mise à jour d'Elementor n'y était pour rien directement — elle avait simplement modifié l'ordre de chargement de certains styles internes, ce qui a changé le moment exact où le rendu de police se stabilisait, révélant un problème de flakiness déjà latent dans la suite. ## Deuxième suspect : les widgets avec animation d'entrée Elementor propose des animations d'entrée (`fadeInUp`, `zoomIn`) sur ses widgets. La mise à jour avait légèrement modifié la durée par défaut d'une transition CSS interne. Un outil de capture qui ne désactive pas ces animations avant la prise de vue capture parfois une image intermédiaire de la transition, différente d'une exécution à l'autre selon la charge de la machine de CI. > L'essentiel à retenir : Une mise à jour mineure peut modifier des pixels sans changer le comportement ; Les polices système chargées différemment faussent les captures ; Isoler la cause avant d'élargir les seuils de tolérance ## La correction appliquée - Injection d'une feuille de style de test qui force `animation: none !important` et `transition: none !important` sur toute la page avant capture - Préchargement explicite des polices avec `font-display: block` dans l'environnement de test uniquement, pour garantir un rendu stable indépendant de la latence réseau - Ajout d'un délai fixe et documenté de 300 millisecondes après chargement de la page avant la capture, plutôt qu'un délai variable dépendant d'un évènement `load` peu fiable avec Elementor Après ces trois correctifs, le nombre de captures divergentes après une mise à jour mineure d'Elementor est passé de quarante-deux à trois, ces trois dernières correspondant à de vrais changements visuels mineurs (un espacement d'icône) que l'équipe a validés manuellement. ### Ce qu'il ne fallait pas faire La tentation initiale était d'élargir le seuil de tolérance de comparaison pixel à pixel. Cela aurait masqué le bruit, mais aussi une partie des vraies régressions — un seuil élargi pour absorber un problème de police masque tout aussi bien un bouton mal aligné de la même amplitude. ## Prévenir la prochaine mise à jour Nous exécutons désormais la suite de tests visuels deux fois de suite sur le même code, avant toute mise à jour, pour établir une ligne de base de stabilité. Si les deux exécutions sur un code identique divergent déjà, la cause est dans l'environnement de test, pas dans le code livré — un diagnostic qui aurait évité une bonne partie du temps perdu sur cet incident. > Un test visuel qui échoue deux fois de suite sur exactement le même code ne teste rien : il mesure le bruit de son propre environnement. ## En résumé Les faux positifs après une mise à jour d'Elementor viennent rarement d'Elementor lui-même, mais de dépendances indirectes — polices, animations, timing — que la suite de tests n'avait jamais stabilisées correctement. Isoler la cause avant d'élargir un seuil de tolérance reste le réflexe le plus rentable face à ce type d'incident.