Le tribunal qualité : des règles qui sont du code

Dans la plupart des projets, les règles de qualité vivent dans un document que personne ne relit. Ici, elles vivent dans des scripts qui s’exécutent. C’est la convention fondatrice de cette base : une règle qui n’est pas vérifiée par du code n’est pas une règle, c’est un vœu.

Les cinq audits

La commande npm run audit enchaîne cinq vérifications, chacune avec un périmètre précis :

• audit:content — les règles éditoriales : chaque contenu porte un statut valide, chaque image a un texte alternatif, chaque bloc a un block_key stable et unique, et aucun contenu archivé n’est référencé par la navigation.
• audit:seo — les fondamentaux du référencement : chaque page et chaque article a un title et une description de longueur raisonnable, et les slugs sont propres (minuscules, tirets, slash final).
• audit:security — le gardien : aucun secret commité par accident (tokens GitHub, clés API, secrets OAuth), aucune hydratation JavaScript côté client non justifiée, aucun script tiers hors des emplacements approuvés.
• audit:cms — la cohérence des trois sources de vérité des blocs : ce que Sveltia laisse éditer (config.yml), ce que Zod valide au build (config.ts) et ce qu’Astro sait rendre (lib/blocks.ts) doivent décrire exactement les mêmes champs.
• audit:links — chaque lien du site (navigation, boutons d’action, liens markdown) respecte la convention maison et pointe vers une route réellement publiée.

Chaque audit est rapide, lisible, et dit précisément quel fichier pose problème.

Les tests unitaires

À côté des audits, npm run test lance vitest sur la logique du dépôt : les regex de validation des liens, la construction de la carte des routes, les helpers de contenu. Les audits vérifient le contenu ; les tests vérifient que les vérificateurs eux-mêmes fonctionnent.

La CI bloquante

Le workflow quality.yml rejoue tout — types, build, tests, audits — sur chaque push et chaque pull request. S’il échoue, rien ne part en production. Il n’y a pas de bouton « déployer quand même » : un contenu invalide casse le build au lieu de publier une erreur, comme expliqué dans Bien démarrer avec cette base.

Le filet le plus court : la sauvegarde

Attendre le push pour découvrir un lien cassé, c’est déjà trop tard quand on travaille avec un agent IA. Un hook exécute donc audit:links à chaque enregistrement d’un fichier de contenu : un lien mort est signalé à la seconde où le fichier est sauvegardé, avec le message d’erreur exact. L’agent (ou l’humain) corrige immédiatement, sans aller-retour avec la CI.

Pourquoi du code plutôt que de la prose

Trois raisons, dans l’ordre d’importance :

1. La prose s’oublie, le code s’exécute. Un audit tourne à chaque push, qu’on y pense ou non.
2. Le message d’erreur est la documentation. Quand audit:seo échoue, il dit quel fichier, quel champ, quelle limite — pas besoin de chercher la règle dans un wiki.
3. Les agents IA en profitent autant que les humains. Un agent qui reçoit un feedback bloquant et précis se corrige seul ; un agent qui doit interpréter un guide de style dérive.

Ce dépôt étant un template, chaque site cloné hérite du tribunal complet. La qualité n’est pas une étape du projet : c’est une propriété du socle.