Déployer sur Cloudflare

À chaque publication, Menestrel appelle le deploy hook de ton projet Cloudflare : le build se relance depuis le dépôt Git et le site récupère le snapshot publié. Cloudflare existe en deux saveurs, et Menestrel gère les deux :

Workers Builds : la plateforme actuelle, vers laquelle Cloudflare oriente les nouveaux projets. Les deploy hooks y sont officiels depuis avril 2026. C’est le choix par défaut pour un nouveau site.
Cloudflare Pages : l’offre historique, toujours prise en charge. Si ton site tourne déjà sur Pages, rien à migrer. C’est aussi la seule saveur avec suivi réel du statut (voir l’étape 3).

Prérequis : un Worker ou un projet Pages relié à un dépôt Git (les deploy hooks n’existent que pour ces projets), et un site branché sur le loader Menestrel (voir Ton premier site).

Créer le deploy hook côté Cloudflare

Sur Workers Builds : dans Workers & Pages, sélectionne ton Worker, puis Settings > Builds > Deploy Hooks. Donne un nom (par exemple menestrel), choisis la branche de production, puis copie l’URL générée :
```
https://api.cloudflare.com/client/v4/workers/builds/deploy_hooks/xxxxxxxx
```
Sur Cloudflare Pages : sélectionne le projet Pages, puis Settings > Builds > Add deploy hook. L’URL a la forme :
```
https://api.cloudflare.com/client/v4/pages/webhooks/deploy_hooks/xxxxxxxx
```
Menestrel n’accepte que des URLs https sur l’hôte api.cloudflare.com. Toute autre URL est rejetée à la création de la cible.

Cette URL déclenche des builds sans autre authentification. Traite-la comme un secret : Menestrel la chiffre au repos et ne la réaffiche jamais.
Connecter la cible dans Menestrel

Dans l’admin, ouvre « Réglages du site », onglet « Déploiement », puis « Connecter un hébergeur ». Choisis le fournisseur Cloudflare, puis dans « Type », workers_builds ou pages selon l’endroit où tu as créé le hook. Donne un nom à la cible (par exemple « Prod Cloudflare ») et colle l’URL dans « URL du deploy hook ». Les trois autres champs sont facultatifs : tu peux déjà valider avec « Connecter ».
Activer le suivi du build (Pages uniquement)

Pour une cible pages, Menestrel peut suivre chaque build jusqu’à « En ligne » ou « Échec », avec un lien vers le déploiement Cloudflare. Remplis les trois champs facultatifs ; les trois sont nécessaires, deux sur trois ne suffisent pas :
- « Token API » : un token créé sur dash.cloudflare.com/profile/api-tokens, avec la permission de lecture sur Cloudflare Pages. Menestrel ne s’en sert qu’en lecture, pour lister les déploiements du projet, jamais pour agir dessus.
- « Id de compte » : l’identifiant du compte Cloudflare, visible dans l’URL du tableau de bord (dash.cloudflare.com/<id de compte>).
- « Nom du projet » : le nom du projet Pages, celui de l’URL <nom>.pages.dev.
Pour une cible workers_builds, ce suivi n’existe pas encore dans Menestrel : le déploiement s’arrête à « Déclenché » dès que le hook a répondu. Pour vérifier le build lui-même, ouvre l’historique de builds du Worker : la colonne « Triggered by » affiche le nom du hook.
Tester la cible

Le bouton « Tester » appelle réellement le hook : Cloudflare lance un vrai build, sans rien publier de nouveau. Ce n’est pas une simulation, un test qui ne construit rien ne prouverait rien. Si le hook répond, l’admin affiche « Hébergeur joint, déploiement déclenché. » ; sinon « Échec du test » avec le code d’erreur. Le build lui-même se vérifie côté Cloudflare : historique de builds du Worker, ou liste des déploiements du projet Pages.
Poser les variables d’environnement du build

Sur Workers Builds : dans le Worker, Settings > Build, section « Build variables and secrets » (les variables de runtime, ailleurs, ne sont pas vues par le build). Sur Pages : Settings > Environment variables du projet. Dans les deux cas, pose :
Fenêtre de terminal
```
MENESTREL_CONTENT_URL=https://content.menestrel.dev/p/prj_xxx/pk_xxx
```
Le loader lit alors le snapshot publié directement sur le CDN : le build passe même si l’application Menestrel est éteinte ou en maintenance. Ne pose pas MENESTREL_TOKEN en production. Détail des variables : Variables d’environnement.

Ce que Menestrel envoie à Cloudflare

À chaque déclenchement, Menestrel fait un POST nu sur le hook, sans corps ni paramètre : les deploy hooks Cloudflare n’acceptent pas d’étiquette. Contrairement à Netlify, le build n’affiche donc pas l’id du snapshot ; le lien entre publication et build se lit dans « Déploiements récents », côté Menestrel.

Avec le suivi activé (cible pages), Menestrel interroge GET https://api.cloudflare.com/client/v4/accounts/<id de compte>/pages/projects/<nom du projet>/deployments avec le token : une première fois 15 secondes après le déclenchement, puis à intervalles plus espacés jusqu’à la minute, pendant 45 minutes au plus. Le statut de la dernière étape du build (latest_stage) fait foi : active s’affiche « En construction », success devient « En ligne », failure devient « Échec », canceled devient « Annulé ».

Lire les états dans « Déploiements récents »

État	Sens
En file	Menestrel a mis le déclenchement en file d’attente.
Déclenché	Le hook a répondu. État final pour `workers_builds`, ou pour `pages` sans suivi.
En construction	Cloudflare construit le site (`pages` avec suivi).
En ligne	Le déploiement est servi.
Échec	Le build a échoué, ou le hook est resté injoignable.
Annulé	Déploiement annulé côté Cloudflare, cible indisponible au déclenchement, ou build en file remplacé par une publication plus récente.

Échecs répétés : mise en pause

Un déclenchement raté est retenté, trois tentatives au plus par build. Après trois échecs consécutifs, la cible passe « En pause » et Menestrel cesse de l’appeler : marteler un hook cassé ne répare rien et noie l’historique. Corrige la cause (hook supprimé côté Cloudflare, URL erronée, token expiré), puis clique « Reprendre ». Le compteur d’échecs repart à zéro et la publication reconstruit à nouveau le site.