2026 OpenClaw — inspection pré-déploiement en pratique :
Lighthouse, détection de liens morts et accessibilité sur Mac distant
Les fenêtres de mise en production compressent performance, liens cassés et accessibilité dans la même heure. Ce tutoriel HowTo montre comment reproduire, sur un Mac distant servant de nœud CI, un pipeline unique piloté par OpenClaw : Lighthouse pour les scores lab, détection de liens morts pour la cohérence des routes, règles d’accessibilité de base (axe-core, Pa11y ou catégorie a11y Lighthouse) pour éviter les régressions évidentes avant fusion ou déploiement. Vous trouverez ci-dessous la définition du périmètre, le graphe de tâches, des exemples de seuils, la structure d’artefacts, la politique de nouvelles tentatives (retry) et une FAQ — avec un parcours d’achat sans connexion en fin d’article.
01 ① Définition du périmètre d’inspection
Gelez d’abord la ligne de base pré-déploiement : hôtes canoniques, distinction préproduction / production, et une liste de routes graines (accueil, authentification, tunnel d’achat, paramètres, routes signalées par le produit ou la sécurité). Alimentez le crawler avec un sitemap ou un manifeste de routes ; fixez une profondeur maximale et un parallélisme compatible avec le budget CPU et la bande passante de votre Mac distant.
Documentez l’authentification (cookies, comptes de test en lecture seule) et les chemins nécessitant une session. Les widgets analytiques ou tiers restent en général en observation sauf s’ils sont first-party. Séparez explicitement les règles bloquent la fusion et celles en simple avertissement, et versionnez-les à côté du workflow OpenClaw (YAML, bundle de tâches ou dépôt « infra-as-code »). Ainsi, chaque release sait exactement ce qui est négociable avant le go-live.
- URL de base, libellé d’environnement et SHA Git injectés dans chaque nom de rapport.
- Préfixes
robots.txtet « ne pas crawler » partagés avec l’outil de liens morts. - Profondeur max, nombre max d’URL et concurrence par hôte alignés sur le CPU du Mac et l’egress.
- Listes block / warn versionnées avec le pipeline ou le bundle OpenClaw.
02 ② Orchestration des tâches OpenClaw
OpenClaw joue le rôle de planificateur et de colle entre CLI et scripts. Adoptez un graphe sériel stable : (1) contrôle de disponibilité de l’URL cible ; (2) Lighthouse sur les graines (mobile ou bureau), sortie JSON/HTML dans un répertoire figé ; (3) détection de liens morts avec code HTTP, URL finale et page référente ; (4) accessibilité via axe-core, Pa11y, ou la catégorie accessibilité de Lighthouse — choisissez un signal principal pour éviter les doublons bruyants.
Chaque étape émet du JSON (ou un format parseable) et un code de sortie non nul en cas de rupture de politique ; OpenClaw agrège les journaux et peut remonter l’état vers la CI distante (SSH, webhook, artefact). Épinglez Node et Chromium (.nvmrc, CHROME_PATH) pour que deux runs consécutifs sur le même nœud restent comparables. Pour approfondir Lighthouse planifié et alertes, voir Lighthouse en planifié et alertes ; pour un smoke test amont, smoke test pré-déploiement sur Mac distant.
03 ③ Seuils et tableau des portes qualité
Les seuils sont une politique produit : versionnez le tableau ci-dessous dans Git et reliez-le à votre changelog. Utilisez la médiane de trois exécutions Lighthouse pour la catégorie Performance afin de lisser la variance lab ; gardez LCP et CLS comparables d’un run à l’autre (même throttling, même build Chromium). Attribuez une gravité différente selon le type d’erreur : une 404 interne est un échec dur ; un timeout partenaire whitelisté peut rester en avertissement.
| Contrôle | Exemple de seuil | En cas d’échec |
|---|---|---|
| Lighthouse Performance (mobile) | Score ≥ 80 (médiane sur 3 runs) | Bloquer la fusion ou dérogation à deux owners |
| Catégorie Accessibilité Lighthouse | Score ≥ 90 | Avertir si bruit contraste ; bloquer si noms/rôles manquants |
| LCP (lab, même throttling) | ≤ 2,5 s | Descendre en warn si une LP marketing pic ponctuel |
| CLS (lab) | ≤ 0,1 | Bloquer sur tunnel de paiement |
| Liens morts internes | 0 × 404 / 410 / timeout / échec TLS / échec DNS | Corriger ou retirer le href ; pas d’ignore silencieux |
| Contenu mixte actif | 0 | Forcer HTTPS ou règles CDN |
| Gravité axe (ou équivalent) | Serious = 0 ; Moderate ≤ 3 | Dépassement Moderate : ticket + échéance |
Types d’erreur côté liens : 404/410 → contenu ou routage ; 5xx → amont ou rollback ; ETIMEDOUT / ECONNRESET → retry puis infra ; ERR_CERT_* → TLS ou horloge ; ENOTFOUND → DNS ou faute de frappe. Conservez systématiquement l’URL référente dans le rapport pour accélérer le correctif.
04 ④ Archivage des rapports et nouvelles tentatives
Stockez sous artifacts/AAAA-MM-JJ/<short-sha>/ avec les sous-dossiers lighthouse/, links/, a11y/ ; publiez-les comme artefacts de pipeline. Placez à la racine un manifest.json listant l’ID de run, les versions Node/Chromium et le profil de throttling — indispensable quand un auditeur ou un fournisseur cloud vous demande de « rejouer le même run ».
Ne retentez que les incidents transitoires : par exemple trois paliers de backoff (5 s / 15 s / 45 s) par URL. Une URL interne qui échoue après trois tentatives est un défaut stable. Pour la variance Lighthouse, comparez à la dernière médiane « verte » obtenue sur la même image Mac. Documentez dans le runbook les domaines externes autorisés à timeout sans bloquer la release, pour éviter les débats en salle de guerre.
- Conserver les listes blanches de domaines tiers à côté du tableau des portes dans Git.
- Les rapports de liens morts doivent inclure code statut, URL finale et référent.
- Performance : journaliser throttling, émulation et chaîne de version Chromium à chaque run.
05 ⑤ FAQ
Les scores préprod et prod divergent fortement. Alignez CDN, compression, en-têtes de cache et point de sortie réseau ; lancez les deux depuis la même région que votre Mac distant lorsque c’est possible et consignez le delta en pied de rapport.
Les partenaires externes time-out souvent. Passez en avertissement ou ajoutez une liste blanche par hôte ; gardez les liens internes sur la porte dure.
Le design entre en conflit avec des règles a11y strictes. Les violations « Serious » ne doivent jamais être ignorées sans trace : dérogation ticketée, propriétaire, date d’expiration. Les « Moderate » peuvent parfois partir en backlog daté si la politique interne le permet.
Pourquoi un Mac distant dans la CI ? Chromium et Safari/WebKit partagent une pile plus prévisible qu’un runner partagé bruyant ; vous réutilisez le même hôte pour élargir ensuite les garde-fous au-delà du seul Chrome.
OpenClaw remplace-t-il Jenkins/GitHub Actions ? Non : il orchestre les étapes locales lourdes (navigateur, artefacts) sur le nœud Mac pendant que votre plateforme CI déclenche et collecte les résultats.
OpenClaw sur un Mac distant permet aux équipes Web ops et aux responsables release front-end d’enchaîner Lighthouse, détection de liens morts et accessibilité dans un seul garde-fou CI reproductible : périmètre figé, ordre de tâches clair, tableau de seuils versionné, preuves JSON/HTML archivées, et retry ciblé sur le transitoire. Pour un hôte dédié aux audits longs et à la rétention d’artefacts, utilisez notre parcours d’achat ci-dessous sans connexion préalable.
Lighthouse, liens morts et accessibilité avant chaque release
Louez un Mac Mini M4 comme automate stable : OpenClaw, Chromium et stockage d’artefacts sans partager un runner surchargé. Finalisez l’achat sans créer de compte sur la page dédiée, puis consultez l’aide pour SSH/VNC et la mise en route.