Données d'accessibilité Lighthouse indisponibles

Ce que vérifie ce contrôle

Indique que l’audit n’a pas pu récupérer les données d’accessibilité Lighthouse depuis l’API PageSpeed Insights (PSI) de Google. Sans elles, le score d’accessibilité Lighthouse et plusieurs audits au niveau des règles (contraste de couleur, échecs de règles axe) n’ont pas pu s’exécuter, donc le module accessibilité renvoie un résultat partiel basé uniquement sur les contrôles HTML statiques que MetricSpot effectue localement.

Pourquoi c’est important

Ce n’est pas un problème avec votre site — c’est un problème avec l’exécution de l’audit. Cinq causes courantes :

• Pas de clé API PSI configurée. Les installations MetricSpot auto-hébergées doivent avoir GOOGLE_PSI_KEY défini ; sans clé, l’endpoint PSI public limite agressivement les requêtes.
• Quota PSI épuisé. Le palier gratuit est de 25 000 requêtes/jour par clé, 400/minute. Une instance auto-hébergée qui lance beaucoup d’audits sur une courte fenêtre atteint la limite de burst.
• Votre page bloque Chrome headless. Certains sites utilisent Cloudflare Bot Fight Mode ou un WAF personnalisé qui signale le user-agent PSI Chrome et renvoie un 403.
• La page est derrière un login. PSI accède à l’URL en anonyme. Si le contenu auditable est derrière une authentification, le rendu PSI public voit l’écran de login, pas la vraie page.
• La page est inaccessible depuis le réseau de Google. Géo-blocage, listes blanches d’IP, DNS internes — n’importe lequel empêche PSI de récupérer l’URL.

Un résultat « Lighthouse indisponible » pour un audit est généralement un hoquet transitoire de PSI. Des occurrences répétées sur plusieurs audits pointent vers l’une des causes ci-dessus.

Comment le corriger

Si vous exécutez MetricSpot en auto-hébergement :

# Obtenez une clé : https://developers.google.com/speed/docs/insights/v5/get-started
echo "GOOGLE_PSI_KEY=AIza…" >> .env
# Redémarrez le worker
dokku ps:restart metricspot

Sans clé, PSI vous laisse faire ~1 requête par minute en anonyme. Avec une clé, vous avez 25 000/jour.

Si vous êtes sur MetricSpot managé (app.metricspot.com) — le quota est déjà configuré. Un résultat « Lighthouse indisponible » ici signifie que PSI lui-même a échoué sur cette URL. Essayez :

1. Relancer l’audit. PSI renvoie des 500 transitoires environ 1 % du temps.
2. Auditer une URL publique non authentifiée. Confirmez que la page est accessible sans cookie de session.
3. Vérifier vos règles WAF / bot. Si vous utilisez Cloudflare, ajoutez le user-agent PSI à votre liste blanche. PSI se déclare comme Chrome-Lighthouse.
4. Reproduire sur l’outil PSI public — si l’outil public échoue aussi sur votre URL, le problème est reproductible et pas spécifique à MetricSpot.

Pour les pages qui ne peuvent vraiment pas être auditées par PSI (tableaux de bord admin, espaces réservés aux clients), le reste du module accessibilité de MetricSpot tourne quand même sur le HTML qu’on peut récupérer — texte alternatif, étiquettes de formulaire, attribut lang, texte de lien descriptif, hiérarchie des titres, points de repère. Ces contrôles statiques constituent l’essentiel de la conformité WCAG de toute façon. PSI ajoute le score Lighthouse dynamique par-dessus.

Questions fréquentes

Quelle est la différence entre ce résultat et « Score d’accessibilité Lighthouse » ?

Le score d’accessibilité Lighthouse se déclenche quand le score est sous le seuil. Ce résultat se déclenche quand PSI n’a pas renvoyé de score du tout. Ils sont mutuellement exclusifs — vous verrez l’un ou l’autre, pas les deux.

Puis-je désactiver PSI et n’utiliser que les contrôles statiques ?

Vous pouvez — laissez GOOGLE_PSI_KEY= vide et MetricSpot saute PSI entièrement. Vous perdez le score Lighthouse, les contrôles dynamiques axe-core et les Core Web Vitals des données de labo. La plupart des utilisateurs gardent PSI activé.

Est-ce que ça affecte mon score d’audit global ?

La pondération du module accessibilité tient compte des données PSI manquantes — votre score global est calculé à partir des contrôles qui ont tourné, pas pénalisé pour ceux manquants. Corriger la cause sous-jacente (liste blanche WAF, mur de login) laisse les contrôles dynamiques contribuer la prochaine fois.