Que vérifier avant de croire que l'agent l'a construit

L'agent dit que c'est fait. Cette affirmation et l'état du site sont deux faits distincts, et la distance entre eux explique tous les mauvais lancements. Ce qui suit n'est pas un plaidoyer général pour la prudence.

Mesurer n'est pas regarder

Nous avons une fois fait passer un titre par tous nos contrôles. Taille calculée correcte, boîte englobante correcte, largeur de défilement dans la limite, et visiblement cassé dans un vrai navigateur. L'outil de mesure ne composait pas la page comme un navigateur.

Le contrôle de débordement standard compare la largeur de défilement à la largeur client. Il ne trouve pas un contenu qui tient dans sa propre boîte mais qu'un ancêtre en overflow: hidden coupe. Il faut remonter la chaîne des ancêtres et intersecter les rectangles.

Le build est l'artefact, pas la source

Lire la source dit ce qui a été écrit, pas ce qui est livré. Deux règles de même spécificité se résolvent par la dernière du fichier, donc modifier la première est du code mort qui semble correct. Toute vérification fiable s'exécute sur la sortie compilée.

Du texte introuvable par grep

Chercher une chaîne dans la source est la façon dont un agent vérifie un changement de texte, et dans un framework à composants cela échoue régulièrement. Une phrase scindée entre deux expressions JSX ne renvoie aucune correspondance alors qu'elle est bien à l'écran.

Les fichiers remplacés sur place

Un optimiseur d'images qui met en cache par chemin source continue de servir l'ancien fichier après écrasement, malgré un rebuild complet. L'échec est partiel, ce qui ressemble à un bug de mise en page. Vérifiez les dimensions naturelles rendues, pas les attributs.

Le droite-à-gauche est une mise en page, pas une traduction

Si le site a une locale arabe, la mise en miroir révèle des décisions que personne n'a prises. Une page traduite qui s'affiche sans erreur n'a pas été vérifiée. Voir ce que les outils RTL manquent et construire un site arabe.

À quoi ressemble une boucle de vérification utilisable

• Vérifiez la sortie compilée, jamais la source. La source est une déclaration d'intention.
• Rendez dans un vrai moteur de navigateur pour tout ce qui est visuel, et regardez l'image.
• Préférez un contrôle qui fait échouer le build à un contrôle que quelqu'un lance.
• Quand un résultat vous surprend, suspectez l'instrument avant le site. La moitié de nos pires rapports étaient des contrôles cassés.

Emballer cela en quelque chose que l'on lance plutôt que l'on retient, c'est à quoi servent les skills, et la moitié recherche est dans la checklist SEO.

Une animation en pause, pas cassée

L'animation déclenchée au défilement est la fausse alerte la plus fréquente. Un navigateur sans interface avec une boucle de frames gelée n'avance jamais la timeline. Ce n'est pas mort, c'est en pause, et le contrôle qui les distingue consiste à piloter la timeline directement.

Lisez la réponse, pas le code de statut

Une page qui renvoie 200 prouve que la route a résolu. Elle ne prouve pas que le contenu est le bon, ni que le framework n'a pas rendu une limite d'erreur avec un 200. Vérifiez quelque chose que seule la bonne page contiendrait.

L'accessibilité est aussi un problème de vérification

Le balisage généré est structuré avec assurance et souvent faux des mêmes façons : un div cliquable à la place d'un bouton, un champ dont l'étiquette visuelle n'est pas associée. Les pratiques WAI-ARIA décrivent le motif correct pour chaque composant.

Une passe automatisée attrape la moitié mécanique. Elle n'attrape pas un ordre de focus absurde ni une modale qui ne piège pas le focus. Voir pourquoi une surcouche d'accessibilité n'est pas un correctif.

Laissez l'outil énoncer ses limites

Chaque contrôle devrait dire ce qu'il n'a pas vérifié. Un rendu à une seule largeur n'est pas un contrôle responsive. Le mode d'échec n'est pas un contrôle qui renvoie une mauvaise réponse, mais un contrôle qui renvoie une réponse vraie et étroite que l'on lit comme large.

Où trouver la réponse qui fait autorité

Chaque contrôle ci-dessus ne vaut que la définition qui le sous-tend, et pour les mesurables cette définition est publiée. La vitesse en est le cas le plus net: les seuils des Core Web Vitals sont fixes et évalués sur des visites réelles, Lighthouse dit sans détour qu'il est un outil de laboratoire, et PageSpeed Insights affiche terrain et laboratoire côte à côte pour que vous les voyiez diverger. Pour tout ce que vous voulez affirmer sur le rendu plutôt que sur la source, un pilote de navigateur réel comme Playwright vous donne un contrôle committable, ce qui fait la différence entre une vérification et une impression.

Les deux articles compagnons poussent cela dans des directions opposées. Les hooks qui verrouillent un dépôt de site transforme ces contrôles en quelque chose qui tourne sans qu'on y pense, et les Core Web Vitals sur un site construit par agent couvre la seule classe de défauts qu'aucun contrôle de cette page ne peut voir, parce qu'elle est invisible une fois la page stabilisée.