launch-audit
Explorez un site de préproduction ou en production, rassemblez des preuves, et remettez à une personne un rapport qu'elle peut utiliser.
La règle d'or
Lecture seule, rapport seulement. Rien dans cette compétence ne modifie un site, ne soumet un formulaire, ne modifie un paramètre, n'écrit vers une API fournisseur ou ne clique sur un contrôle destructeur. Chaque constatation est une recommandation accompagnée de preuves destinée à un humain.
Quatre autres règles qui en découlent, et que vous devez répéter lorsque vous présentez le rapport :
- Aucune limitation silencieuse. Chaque limite de couverture — nombre maximum de pages, profondeur, pages échantillonnées, externes non vérifiables — est signalée par son nom dans Non couvert.
- Des preuves pour chaque constatation. Une URL, un code de statut, une valeur d'en-tête, un chemin de capture d'écran.
Non couvertn'est jamais une réussite. Vous répétez cette section textuellement à la personne.- Ignorer n'est pas réussir. Chaque vérification ignorée a une raison.
1. Recueillir les entrées
Demandez ce que vous ne savez pas déjà. Ne devinez aucun de ces éléments.
- L'URL à auditer. Requis.
- Est-ce un site de préproduction ou en production ? Une cible de préproduction est censée être en noindex ; passez
--stagingpour qu'un noindex général passe de bloquant à informationnel. Sur une cible en production, c'est bloquant. - Ce site remplace-t-il un site existant ? Si oui, obtenez l'URL de l'ancien site et passez
--old-url. Cela doit être fait tant que les deux sites sont encore accessibles — généralement avant que le DNS ne soit changé. C'est le seul moment où une carte de redirections peut être construite automatiquement. - Des noms d'hôte de développement ou de préproduction qui auraient pu fuir dans le build. Passez chacun avec
--dev-host. Un nom d'hôte qui a fui est bloquant et l'audit ne peut rechercher que ceux qu'il connaît. - Playwright est-il installé ? Si oui, le niveau navigateur s'exécute : captures d'écran, accessibilité axe, Lighthouse, et si les analytics se déclenchent réellement. Si non, dites-le — environ un tiers du rapport n'a pas lieu, et le rapport indique quel tiers.
2. Exécuter le script
Exécutez-le ; ne lisez jamais son code source, et ne réimplémentez jamais ce qu'il fait. Tout ce qu'il fait est en lecture seule : il récupère les pages, en rend un échantillon, et écrit un lot sur le disque.
node scripts/launch-audit.mjs --url <url> [--old-url <url>] [--dev-host <host>] [--staging] [--browser auto|on|off] [--out <dir>]
Le chemin est relatif au propre répertoire de cette compétence — exécutez la commande depuis là, et écrivez le lot là où le travail réside avec --out.
Autres indicateurs : --max-pages (par défaut 200), --max-depth (par défaut 4), --ignore-robots, --baseline <chemin vers un fichier baseline.json antérieur>, --json, --config <chemin>, --help.
Le niveau navigateur est par défaut auto : il s'exécute si Playwright est présent et est ignoré avec une raison s'il ne l'est pas. Utilisez --browser on pour que son absence soit une erreur, off pour l'ignorer délibérément.
Il se termine avec le code 0 quel que soit le nombre de constatations — ceci rapporte, ne bloque pas. Une sortie 2 signifie une erreur d'utilisation. S'il suggère d'installer Playwright, relayez la suggestion ; n'installez rien sans qu'on vous le demande.
3. Lire le lot
Le script imprime le chemin du lot et écrit :
| Fichier | Contenu |
|---|---|
report.md | Constatations par dimension, puis État opérationnel et d'accès, puis Non couvert |
findings.json | Les mêmes constatations, lisibles par machine |
crawl.json | Chaque URL atteinte, son statut, sa profondeur et comment elle a été trouvée |
baseline.json | Un instantané à comparer après le lancement |
manifest.json | Exactement quels fichiers cette exécution a écrits |
redirects.csv | Une ligne par ancienne URL (uniquement avec --old-url) |
screenshots/ | Captures d'écran bureau, tablette et mobile par page rendue (niveau navigateur uniquement) |
lighthouse/ | Les scores et métriques mesurés par Lighthouse, par page et facteur de forme (niveau navigateur uniquement) |
Lisez report.md en premier : les bloqueurs, puis Non couvert, puis tout le reste. Savoir ce qui n'a pas été vérifié change la façon dont vous lisez une section propre. references/reading-the-report.md contient le tableau des sévérités et comment utiliser le lot.
4. Faire les trois passes de jugement vous-même
Le script rassemble des preuves pour trois examens qu'aucun vérificateur ne peut faire. Faites-les tous les trois avant de présenter quoi que ce soit. Chacun a un fichier de référence ; lisez-le avant le passage, pas après.
Captures d'écran — voir references/reading-the-report.md. Ouvrez les captures d'écran mobiles et bureau de chaque page rendue côte à côte et recherchez : rupture de mise en page, débordement horizontal, images manquantes, texte tronqué ou coupé, navigation qui ne se réduit pas à la largeur du téléphone, et images de substitution qui ont survécu jusqu'au lancement. Si aucun navigateur n'a été exécuté, il n'y a pas de captures d'écran, et cet examen n'a pas eu lieu — dites-le plutôt que de laisser son absence être considérée comme une réussite.
Formulaires — voir references/forms.md. Classez chaque formulaire de l'inventaire comme propriétaire, tiers ou mort, en utilisant les preuves du rapport. Dites ensuite à la personne quels formulaires nécessitent une soumission de test et exactement ce qu'il faut confirmer : le message de succès, la notification arrivant dans une boîte de réception surveillée plutôt que dans un dossier de spam, et l'enregistrement apparaissant là où il est censé être. Vous ne soumettez jamais un formulaire vous-même.
Coordonnées — voir references/content.md. Rassemblez chaque numéro de téléphone, adresse e-mail et adresse postale que le rapport a trouvé en une seule liste, vérifiez que les liens tel: composent les numéros affichés à côté d'eux, et demandez au propriétaire du site lesquels sont actuels. Un deuxième numéro de téléphone laissé sur une page envoie la moitié des appels nulle part, et rien ne peut dire de l'extérieur lequel est correct.
5. Présenter le rapport
Structurez votre résumé comme le rapport est structuré, et commencez par la décision plutôt que par un nombre. Quarante constatations faibles provenant d'un même modèle sont un correctif ; un bloqueur, c'est un lancement.
- Ce qui bloque le lancement. Une phrase simple par bloqueur. S'il n'y en a pas, dites-le directement.
- Constatations regroupées par dimension, sévérité la plus grave en premier dans chacune. Donnez la forme, pas seulement le nombre : "quatorze pages manquent de description — c'est un modèle, donc c'est un correctif". Nommez le correctif plutôt que l'échec, et dites ce qu'il coûte en termes simples.
- État opérationnel et d'accès. Ce sont les tâches du propriétaire du site, et ce sont celles qui ruinent les jours de lancement. Lisez les éléments
[human]à haute voix et obtenez une réponse pour chacun. - Non couvert, textuellement. Chaque ligne, non éditée, présentée honnêtement : "voici ce qui n'a pas été vérifié". Ne le résumez jamais, ne le qualifiez jamais de mineur, ne l'omettez jamais parce que la liste est longue.
Les deux vérifications qui ne s'exécutent jamais
Chaque rapport se termine par celles-ci, et elles sont là car ce sont les deux échecs qui font le plus mal et qu'aucune exploration ne peut jamais atteindre :
- Copie par rapport aux documents sources. Rien ici ne compare les mots du site avec la copie validée. Quelqu'un doit s'asseoir avec les deux et lire.
- Pages par rapport au périmètre convenu. Rien ici ne sait quelles pages étaient censées exister. Une page qui n'a jamais été construite est invisible pour un explorateur.
Dites les deux à voix haute lorsque vous présentez le rapport. Un site peut réussir toutes les vérifications de cette compétence et manquer encore la moitié de ce qui a été convenu.
Références
Lisez le fichier d'une dimension avant d'expliquer ses constatations. Chacun couvre ce que la constatation signifie, pourquoi elle est importante au lancement, comment la corriger sur les piles courantes, et ce que la vérification ne peut pas vous dire.
| Fichier | Couvre |
|---|---|
references/reading-the-report.md | Sévérités, la liste de contrôle des captures d'écran, Non couvert, présentation à un client |
references/indexability.md | Exploration et inventaire, noindex, robots.txt, sitemaps, canoniques, hreflang |
references/host.md | HTTPS, certificats, www vs apex, redirections, en-têtes de sécurité, page 404 |
references/head.md | Titres, descriptions, en-têtes, icônes, cartes sociales, données structurées |
references/links.md | Liens cassés et non vérifiables, texte de lien, mailto: et tel: |
references/images.md | Texte alternatif, dimensions, stratégie de chargement, poids, formats, vidéo |
references/forms.md | L'inventaire, les points de terminaison, la classification et la soumission de test |
references/accessibility.md | Le plancher HTML, les violations axe, et le passage manuel de quinze minutes |
references/performance.md | Indices et mesures, Lighthouse, et l'ordonnancement du travail |
references/analytics.md | Détection des balises, déclenchement, consentement, et passage de vérification |
references/content.md | Placeholders, dates obsolètes, variantes des coordonnées |
references/redirects.md | La carte de transition, redirects.csv, et l'écriture des règles |
references/ops.md | Authentification des e-mails, pages juridiques, et liste de contrôle de préparation |
Où cela se situe
pre-launch est la porte qui s'exécute contre le dépôt avant le déploiement. launch-audit est celle-ci : elle rapporte et ne bloque jamais. post-launch s'exécute dès que le DNS change et différencie la production par rapport à la base de référence que cet audit a écrite. Exécutez-les dans cet ordre.