L'exécution de l'assurance qualité (QA) pilotée par l'IA sur un outil de conception Web a rapporté « Toutes les fonctionnalités fonctionnent, succès », pourtant le canvas n'affichait rien. Ce faux succès n'était pas un bug dans le raisonnement du modèle ; c'était un effet secondaire de la manière dont le navigateur gère les onglets cachés et de la façon dont le script de test mesurait la « santé » au lieu du rendu visuel.

Pourquoi les agents de QA par IA peuvent manquer un canvas vide

Ils exécutent du JavaScript, capturent des captures d'écran et laissent le modèle déduire si une fonctionnalité s'est comportée correctement. En pratique, deux angles morts techniques produisent systématiquement des succès alors que l'interface utilisateur est en réalité vide.

Explication de la limitation (throttling) des onglets cachés

Chrome MCP exécute souvent des tests dans des onglets en arrière-plan pour laisser la fenêtre principale libre pour d'autres tâches. Lorsque le document.visibilityState d'un onglet est hidden, le navigateur limite le pipeline de rendu :

  • Le JavaScript continue de s'exécuter, donc aucune erreur d'exécution n'apparaît.
  • Les rappels (callbacks) requestAnimationFrame cessent de s'activer, laissant le nombre de trames d'animation à zéro.
  • Les minuteurs s'activent beaucoup moins souvent ; un test qui attendait des intervalles de 33 ms n'en a observé que quatre.

L'agent d'IA voit des résultats JS propres et une capture d'écran, et suppose que l'animation a fonctionné. Comme la boucle de rendu n'a jamais produit de pixels, le défaut visuel reste caché.

Correctifs pour les problèmes d'onglets cachés

  • Gardez l'onglet de test visible pour toute vérification de canvas, d'animation ou de graphisme.
  • Déclenchez les interactions uniquement une fois que l'onglet est au premier plan.
  • Insérez une courte attente (quelques secondes) avant de capturer la capture d'écran, pour vous assurer que le tampon de trame (frame buffer) a été alimenté.
  • Si un onglet caché doit être utilisé, préfacez le rapport d'une clause de non-responsabilité telle que « rendu non observé visuellement ».

Santé du code vs comportement des fonctionnalités

La plupart des scripts de QA par IA évaluent la « santé du code » : ils confirment que les gestionnaires de clics (click handlers) sont connectés, qu'aucune exception JavaScript n'a été levée et que les bibliothèques requises sont chargées. Ces signaux prouvent que le code a été exécuté, pas que l'interface utilisateur a changé comme prévu. Un élément canvas peut être créé, une routine de dessin appelée, et ne toujours rien afficher si les commandes de dessin ciblent un tampon de taille nulle ou un asset vide.

Cette distinction est importante car un chemin de code sain peut masquer l'absence d'un artefact visuel.

Ajouter des vérifications de comportement

  1. Identifier les éléments dynamiques – Parcourez la source pour trouver les balises canvas, les champs file-input, les boutons de téléchargement et les boucles d'animation.
  2. Définir des résultats observables – Pour un canvas, exigez une vérification au niveau du pixel pour confirmer que le bitmap n'est pas vide. Pour un champ de fichier, vérifiez qu'une image d'aperçu apparaît. Pour un téléchargement, confirmez qu'un fichier est créé sur le système de fichiers. Pour les animations, affirmez qu'une propriété suivie change au fil du temps.
  3. Rapport de couverture – Joignez un tableau à la sortie de la QA listant chaque fonctionnalité, le statut de la santé du code et le résultat de la vérification du comportement. Tout ce qui manque d'une vérification de comportement reste « non vérifié » plutôt que « succès ».

L'application de cette règle a réduit considérablement les faux positifs dans la suite de tests de l'auteur et a également révélé des incohérences CSS où la feuille de style déclarait une couleur mais où le pixel rendu différait.

Étapes pratiques pour des tests visuels fiables

  • Exécutez les tests dans un onglet visible dès que la fonctionnalité implique un rendu.
  • Attendez que l'interface utilisateur se stabilise ; un délai fixe de quelques secondes suffit souvent, mais une approche plus robuste consiste à interroger (poll) un canvas non vide à l'aide de getImageData.
  • Séparez les assertions de santé du code des assertions visuelles dans le script de test ; laissez le modèle d'IA évaluer chaque aspect indépendamment.
  • Journalisez l'état de visibilité et les compteurs de trames (appels requestAnimationFrame) dans la sortie de diagnostic.
  • Documentez toute exécution inévitable dans un onglet caché avec des avertissements explicites afin que les réviseurs en aval comprennent la limitation.

Ce qu'il faut surveiller ensuite

À mesure que les outils de QA assistés par l'IA prolifèrent, les développeurs doivent les traiter comme des assistants, et non comme des arbitres. Les métriques de santé du code seront toujours un indicateur incomplet du comportement face à l'utilisateur. La conclusion est simple : un modèle d'IA ne peut rapporter que ce qu'il voit. Si le navigateur ne peint jamais parce que l'onglet est caché, ou si le script de test ne demande jamais « quelque chose est-il apparu à l'écran ? », le modèle déclarera joyeusement un succès. L'ajout d'une exigence de visibilité et d'une étape de vérification du comportement transforme un succès superficiel en un résultat fiable.