Astro : poser les règles avant les pages, puis publier

Deux outils, deux moments. Claude Design sert à fixer les règles : tokens de couleur et d’espacement, surfaces, ce que la marque s’interdit. Claude Code sert à les appliquer. Séparer les deux n’est pas une coquetterie de méthode : c’est ce qui permet, plus tard, de dire d’une page qu’elle est fausse par rapport à une règle écrite, plutôt que par rapport à un goût.

Le système sort sous forme de variables CSS et d’un fichier de règles. Le second est le plus utile : il énumère ce qui est interdit. Aucune valeur hexadécimale en dur, aucune ombre portée, aucun rayon de bordure. Un script de vérification relit tout le dépôt et refuse le build en cas d’écart. Il a déjà rejeté du code que j’avais écrit moi-même, ce qui est exactement son travail.

// package.json — the repository's front door
{
  "scripts": {
    "check": "astro check",
    "adherence": "node scripts/check-adherence.mjs",
    "verify": "npm run check && npm run adherence && npm run build"
  }
}

Astro en sortie statique ne produit que du HTML, du CSS et quelques kilo-octets de script. Pas de rendu serveur, donc rien à maintenir en production : la page envoyée est celle qui a été construite. C’est ce qui rend l’hébergement quasi gratuit et la reprise possible par quelqu’un d’autre.

Le dépôt est privé, le site public. GitHub Actions construit, puis téléverse le dossier produit vers Cloudflare Pages. Deux secrets suffisent, un jeton d’API et l’identifiant de compte. Le déploiement est conditionné à la vérification : si une règle du système est enfreinte, rien ne part.

- name: Verify
  run: npm run verify
  working-directory: site

- name: Publish to Cloudflare Pages
  if: github.event_name != 'pull_request'
  uses: cloudflare/wrangler-action@v3
  with:
    apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
    workingDirectory: site
    command: pages deploy dist --project-name=preview-commutator --branch=main

• —On ne peut pas ajouter l’intégration Git à un projet Pages déjà créé. Si le projet a été monté en téléversement direct, il le reste ; il faut le recréer, ou assumer le pilotage par Actions : ce que fait ce site.
• —L’action wrangler découpe la commande sur les espaces. Une option contenant un message multiligne la fait éclater, et l’erreur ne dit rien d’utile. La commande doit tenir sur une ligne d’arguments simples.
• —Cloudflare ajoute un suffixe au sous-domaine du projet : le nom choisi ne donne pas l’adresse attendue. Il faut lire l’adresse réelle plutôt que la déduire.
• —Un domaine personnalisé ne se règle pas au DNS seul. Tant que le domaine n’est pas rattaché au projet côté Cloudflare, la résolution est correcte et le certificat échoue : un symptôme qui envoie chercher au mauvais endroit.
• —Le cache de bord sert longtemps. Une page renommée a continué d’être servie une semaine après sa suppression, avec un cache-control d’une semaine et un statut « HIT ». Supprimer une route ne l’atteint pas : il faut rediriger explicitement.

# public/_redirects — old addresses go straight to the final destination,
# not chained one into the next
/journal/*  /points-de-vue/:splat  301
/journal    /points-de-vue         301

Le nom de domaine, et rien d’autre. Le plan gratuit de Pages suffit largement pour un site de cette taille, et GitHub Actions ne facture pas les dépôts publics ni les petits volumes. Le coût réel est ailleurs : il est dans les règles écrites au départ, qui prennent une journée et évitent des semaines de reprises.

• Cloudflare Pages · Direct Upload
• cloudflare/wrangler-action
• Astro · Static output