victor-shulga/website-audit

Que fait website-audit ?

Une seule commande mesure le site ; vous confirmez ensuite ce qu'un script ne peut pas juger et remettez un rapport qu'un fondateur peut exploiter. L'audit est en lecture seule : il ne soumet jamais de formulaire, ne se connecte jamais, ne clique jamais sur quoi que ce soit qui change l'état, respecte robots.txt et marque une pause entre les chargements de pages.

Entrées

• URL (obligatoire). Demandez-la si l'utilisateur n'en a pas fourni.
• Limite de pages (optionnelle, par défaut 10). Utilisez 3–5 pour un aperçu rapide, 15–25 pour une base de référence complète avant reconstruction.
• Langue du rapport (optionnelle, par défaut = la langue dans laquelle l'utilisateur écrit).

Prérequis

• Node.js 22 ou plus récent (node --version). Lighthouse nécessite en plus Node ≥ 22.19 et npm (npx).
• Google Chrome ou Chromium. Détecté automatiquement sur macOS, Linux et Windows, y compris un Chromium déjà téléchargé par npx playwright install chromium. Sinon, définissez CHROME_BIN=/chemin/vers/chrome.
• Accès réseau au site audité, ainsi qu'à un CDN npm public (axe-core) et au registre npm (Lighthouse). Si l'un ou l'autre outil ne peut pas être récupéré, cette zone est marquée comme ignorée dans le rapport avec la raison ; l'exécution ne se termine pas en échec.

Étapes

1. Exécuter l'audit

<skill-dir> est le dossier dans lequel se trouve ce SKILL.md.

node <skill-dir>/scripts/audit.mjs https://exemple.com --limit 10

Options : --limit N · --delay MS (pause entre les pages, par défaut 1000) · --max-links N (vérifications des liens internes, par défaut 150) · --no-lighthouse · --no-axe · --max-minutes N (par défaut 15) · --out DOSSIER.

La sortie va dans ./website-audit/<domaine>/ relativement au dossier courant (remplacez avec --out ou la variable d'environnement WEBSITE_AUDIT_OUT) :

• website-audit-<domaine>-<date>.md : le rapport
• website-audit-<domaine>-<date>.json : mesures brutes, constats, scores, instantané
• screens/ : captures d'écran du premier écran par page, desktop et 390 px

La progression va sur stderr ; la dernière ligne stdout est un résumé JSON (ok, report, pages, seconds, overall, counts, scores, skipped). Le code de sortie 2 signifie que l'audit n'a pas pu être exécuté du tout (pas de Node 22, pas de Chrome, site inaccessible) : affichez le message à l'utilisateur, il indique quoi installer ou vérifier.

Une exécution de 10 pages prend environ 2 à 4 minutes ; Lighthouse ajoute 30 à 60 secondes.

2. Passage de relecture manuelle

Suivez <skill-dir>/references/manual-review.md :

1. Confirmez chaque P0 avec ses preuves (le script est littéral ; la protection anti-bot ou un formulaire JavaScript peuvent simuler un P0).
2. Résolvez chaque élément « vérifier manuellement » en lisant les captures d'écran dans screens/.
3. Assurez-vous que « Corriger en priorité » se lit comme le premier sprint de la reconstruction.

Modifiez le rapport markdown sur place. Ne modifiez pas le JSON ; c'est la base de référence brute.

3. Langue

Le script écrit en anglais. Si l'utilisateur écrit dans une autre langue, traduisez les en-têtes du rapport, les lignes « Pourquoi c'est important pour les prospects » et « Correction ». Conservez les URL, les sélecteurs, les noms de métriques, les codes HTTP et les étiquettes P0 à P3 tels quels.

4. Remise

Répondez avec : le score global, le nombre de P0 / P1, la liste « Corriger en priorité », les zones ignorées et pourquoi, ainsi que le chemin vers le rapport. Proposez de relancer l'audit sur le nouveau site plus tard avec la même limite pour remplir la colonne « après » de l'instantané.

Si l'utilisateur souhaite une régénération après modification des seuils : node <skill-dir>/scripts/report.mjs <chemin-vers-l-execution>.json réécrit le markdown à partir du JSON.

Ce que chaque zone couvre

Les détails, les seuils et les règles de priorité se trouvent dans <skill-dir>/references/checks.md. En résumé :

Zone	Comment
Mise en page mobile	chaque page à 360 / 390 / 768 px : défilement latéral, éléments dépassant du bord, balise viewport, cibles tactiles, texte trop petit
Bugs	erreurs et exceptions de console, requêtes 4xx/5xx et échouées, contenu mixte, images cassées, liens internes (HEAD/GET), cibles de formulaires (HEAD uniquement)
Accessibilité	axe-core injecté dans chaque page, tags WCAG 2.0/2.1 A + AA
Performances	Lighthouse mobile sur la page d'accueil ; timings navigateur (TTFB, LCP, CLS, poids, requêtes) sur chaque page
Parcours de conversion	CTA du premier écran sur desktop et téléphone, clics pour contacter, email / téléphone / réservation / formulaire de prospects, témoignages, études de cas, logos, chiffres
Bases SEO	titre, description, un H1, canonique, Open Graph, noindex, robots.txt, sitemap.xml

Règles

• Ne jamais soumettre, remplir ou cliquer sur des formulaires ; ne jamais se connecter ; ne jamais contourner la protection anti-bot ou un CAPTCHA. Si le site affiche une page de défi, signalez-le et arrêtez-vous.
• Respectez les règles d'interdiction de robots.txt ; conservez le délai par défaut sauf si l'utilisateur possède le site et demande une exécution plus rapide.
• Les constats marqués « vérifier manuellement » sont des hypothèses jusqu'à ce que vous examiniez la capture d'écran.
• Ne publiez le rapport nulle part par vous-même ; il peut décrire les points faibles d'un client.

Pas ce skill

• Critique de la copie, du positionnement et du message → website-copy-reframe.
• Une marque / un système de design à partir d'un site → design-system-generator.
• Classements de mots-clés, backlinks, estimations de trafic → un outil de données SEO.