Qualité et accessibilité

Un build réussi est nécessaire mais pas suffisant. Lisible sépare les contrôles automatiques, les inspections de sortie et la recette navigateur.

Pipeline recommandé

bun run typecheck
bun run check:all
bun run preview

typecheck exécute astro check sur les sept variantes. check:all valide d’abord les assets Open Graph, les règles de style éditorial et le contrat de conformité inter-variantes, puis enchaîne, pour chaque variante, le typecheck, le build, check-links, check-assets et le contrôle des images Open Graph. C’est le fait de l’exécuter sur toutes les variantes, et non sur la seule variante active, qui empêche le socle commun de diverger entre elles.

Les commandes individuelles restent disponibles pour une boucle plus rapide sur la variante active :

bun run check-links
bun run check-assets
bun run build

check-links inspecte les références du contenu avec concurrence et timeout limités. check-assets applique des budgets sur le résultat construit.

Couches de tests

Au-delà des contrôles de build, quatre couches automatiques protègent le socle commun.

Tests unitaires. bun run test exerce les helpers partagés (requêtes sur les articles, formatage, RSS, llms.txt, rendu Open Graph, focus trap) avec le runner de tests de Bun et happy-dom.

Tests de bout en bout. bun run test:e2e lance la suite Playwright sur des variantes construites : scans d’accessibilité avec axe, switcher de thème, picker d’accent, palette de recherche, changement de langue, visionneuse d’images, rendu Mermaid, overlay de démarrage et pages portfolio. Construisez les variantes ciblées et installez Chromium (bun x playwright install chromium) avant de la lancer.

Lint et style éditorial. bun run lint applique Biome à tout le dépôt. bun run check-style verrouille les règles éditoriales : aucun tiret long dans les sources et le contenu, aucun emoji dans la documentation Markdown.

Conformité et dérive. check-conformance (inclus dans check:all) valide le contrat inter-variantes ; une déviation volontaire doit être déclarée dans conformance-exceptions.json avec sa raison, et une déviation non déclarée fait échouer la CI. Pour les refactors, bun run check-drift --save capture une base de référence du HTML normalisé de chaque page de chaque variante construite ; après le changement, bun run check-drift liste chaque page dont le rendu a bougé, et chaque écart doit être justifié par le changement en cours.

Intégration continue

Chaque pull request exécute Biome, les tests unitaires et les règles de style, puis check-variants sur une matrice filtrée par chemins (une variante ne se reconstruit que si elle ou le socle commun a changé), la suite Playwright sur deux variantes et les budgets Lighthouse sur une. Un workflow nocturne exécute la matrice complète, les budgets Lighthouse par variante et la suite de bout en bout sur les six variantes publiques. Les budgets de lighthouserc.json exigent 90 en performance et 95 en accessibilité, bonnes pratiques et SEO.

Audit de contenu

• fichiers FR/EN de même basename ;
• clés de frontmatter symétriques ;
• titres et descriptions dans les limites du schéma ;
• images présentes et textes alternatifs utiles ;
• aucune URL interne morte ;
• brouillons absents de la production.

Accessibilité

• parcours complet au clavier ;
• focus visible sur chaque contrôle ;
• un seul h1, puis une hiérarchie de titres logique ;
• labels accessibles sur les icônes ;
• contrastes AA dans les deux thèmes et pour l’accent personnalisé ;
• animations désactivées ou réduites avec prefers-reduced-motion ;
• route annoncée après une transition Astro.¹

Performance

Le HTML et le CSS doivent porter l’essentiel. Les composants React utilisent la directive d’hydratation la plus tardive compatible avec leur rôle. Mermaid, Giscus et les visionneuses se chargent à la demande.

Mesurez au minimum :

• taille HTML/CSS/JS par page ;
• Largest Contentful Paint et Cumulative Layout Shift ;
• nombre de scripts exécutés sur une page simple ;
• stabilité d’une navigation après plusieurs transitions ;
• poids des images et polices.

Validation visuelle

Une fonctionnalité graphique doit être testée dans un vrai navigateur : mobile, desktop, thème clair, thème sombre et réduction de mouvement. Un diagramme Mermaid est valide seulement si les boîtes et flèches SVG sont visibles, pas si le code source reste affiché. Mermaid et draw.io doivent présenter une viewport non nulle, des contrôles de zoom fonctionnels, une entrée en plein écran et une sortie avec Échap en dev comme sur le build servi. Une arborescence doit déplier ses dossiers, sélectionner les éléments actifs et conserver un overflow lisible sur une viewport étroite.

Recette du preview en direct

Lorsqu’un comportement partagé ou une variante change, vérifiez au moins deux variantes dans le workflow de preview en direct : passez d’une route commune à l’article de démonstration, changez FR/EN sans rechargement, testez les viewports bureau et mobile, puis copiez et rouvrez l’URL partagée. Le SHA source affiché doit correspondre à la révision Lisible synchronisée et chaque route embarquée doit rester en noindex.

Références internes

• Markdown enrichi pour les cas de rendu ;
• Internationalisation pour la matrice FR/EN ;
• Build et déploiement pour la recette distante ;
• Dépannage pour les symptômes connus.