L’instrument tourne d’abord sur nous
LFW Monitor scanne LFW.com chaque jour avec le même moteur, les mêmes réglages et la même notation qu’il utilise sur les sites clients. Les scores de notre page d’accueil sont tirés de ce scan. La copie en direct n’apparaît que lorsqu’un scan achevé existe, et il n’y a pas de valeur factice : si nous n’avons pas mesuré, les chiffres n’y sont tout simplement pas.
Accessibilité : axe-core complet, WCAG 2.2 AA
L’accessibilité est auditée avec axe-core sur chaque page parcourue, contre WCAG 2.2 AA.
Un détail honnête qui mérite d’être dit : beaucoup d’outils rapportent aussi la catégorie accessibilité de Lighthouse à côté d’axe. Mais l’audit d’accessibilité de Lighthouse est un sous-ensemble d’axe ; exécuter les deux compte donc chaque problème en double et gonfle la liste des constats.
Nous exécutons axe complet, en dérivons le score d’accessibilité, et coupons la catégorie accessibilité de Lighthouse.
Les vérifications automatisées sont le plancher, pas le plafond : elles attrapent les défauts qu’une machine peut prouver. Le travail de conformité sur les engagements clients ajoute des tests manuels par-dessus.
Performance, SEO, bonnes pratiques : Lighthouse
Les scores de performance, SEO et bonnes pratiques viennent de Lighthouse, exécuté page par page dans un vrai Chrome headless. Les scores suivent l’échelle standard 0–100 de Lighthouse, donc ils sont comparables à ce que n’importe quel ingénieur obtiendrait en menant le même audit à la main.
La performance utilise le profil ordinateur ; pour notre propre site, nous publions aussi le profil mobile (un téléphone de milieu de gamme émulé sur une connexion bridée), parce qu’un chiffre sans l’autre flatte.
Au-delà des scores
Le même parcours vérifie aussi les échecs qui n’apparaissent dans aucun score :
| Vérification | Ce qu’elle attrape |
|---|---|
| Parcours et liens | Liens brisés, chaînes de redirections, pages inaccessibles |
| Contenu | Fautes de frappe (avec dictionnaire par site), années de copyright périmées |
| Intégrité | Cloaking et pourriel ou logiciel malveillant injecté : la page est récupérée comme notre propre moniteur, comme Chrome de bureau, comme Googlebot et comme Safari mobile, et la divergence entre eux est traitée comme le constat ; le DOM rendu est aussi comparé au HTML du serveur pour attraper les charges assemblées par script |
| WordPress | Exposition des médias par l’API REST, énumération d’utilisateurs, XML-RPC laissé ouvert |
Les constats ont un état : vous voyez ce qui a changé
Les constats portent une empreinte stable d’un scan à l’autre. Un nouveau scan met à jour l’ensemble en vigueur au lieu de produire une pile fraîche : les constats sont nouveaux, récidivants, résolus, ou silencieux parce que rien n’a changé. Une règle compte plus qu’elle n’en a l’air : un constat ne s’auto-résout que si la page où il vit a réellement été atteinte lors de ce scan. Une page qui tombe en erreur en plein parcours ne « répare » jamais discrètement ses propres problèmes.
Ce que nous publions, et ce que nous ne publions jamais
Pour notre propre site, nous publions les scores, le nombre de pages et le nombre de constats par gravité. Nous ne publions jamais le texte d’un constat, le nôtre ou celui de qui que ce soit. Une liste publique des défauts non corrigés d’un site est une carte pour les attaquants. C’est aussi pourquoi les constats des clients ne circulent que par le portail du client lui-même.