FAQ et dépannage

Deux parties. D’abord les questions qu’on nous pose avant de brancher un premier site. Ensuite le dépannage : chaque cause décrite ici correspond à un comportement réel du loader, du CLI ou de l’admin, avec les messages exacts.

FAQ produit

Et si Menestrel ferme ?

Ton site continue de tourner. La défaillance douce n’est pas une promesse marketing, elle est structurelle :

• Le site en production ne dépend pas de nous. C’est un ensemble de fichiers statiques chez ton hébergeur : rien dans le service d’une page ne passe par Menestrel.
• Les builds passent encore. MENESTREL_CONTENT_URL lit le snapshot publié sur le CDN, pas sur l’application. Un redéploiement pendant une panne, ou après, aboutit.
• L’export complet est disponible sur tous les plans, gratuit compris. npx menestrel export ressort content/ en Markdown, data/ en JSON à l’identique et media/ avec les originaux. Aucun format propriétaire, aucun ticket au support.

Après une résiliation, le contenu est conservé 30 jours, avec un export proposé avant suppression. Le mécanisme complet est décrit dans Comment Menestrel fonctionne.

Pourquoi Astro seulement ?

Parce que la profondeur d’intégration ne se partage pas. Le loader est un loader Content Layer natif : les entrées sortent typées, avec des ids pensés pour getStaticPaths, la locale et les traductions exposées pour ton routing i18n. menestrel import lit directement tes content collections. Les composants (RichText, CmsImage, CmsSeo) sont des composants Astro.

Un CMS « compatible tous frameworks » aurait dû renoncer à tout ça. Les deux dernières majors d’Astro sont supportées, voir Compatibilité Astro. Si ton site n’est pas sur Astro, Menestrel n’est pas fait pour toi, et on préfère te le dire.

Où sont mes données ?

En France. La base de données, les médias et les snapshots sont hébergés chez Scaleway, région Paris. La distribution publique passe par un CDN européen (Bunny). DPA signable en ligne, liste publique des sous-traitants, aucun tracker tiers dans l’admin. Le détail, durées de conservation comprises, est dans Jetons d’API et sécurité.

Mon site reste-t-il 100 % statique ?

Oui. Le contenu n’est nécessaire qu’au moment du build : le loader lit un snapshot publié, astro build produit des fichiers statiques, et en production le site n’envoie aucune requête vers Menestrel, ni au chargement d’une page, ni en arrière-plan. Un pic de trafic sur ton site est l’affaire de ton hébergeur statique, jamais celle du CMS.

Combien ça coûte ?

Gratuit pour un site (1 site, 2 éditeurs, 200 entrées, 2 langues). Ensuite 3 €/mois par site facturé à l’année, ou 5 €/mois sans engagement. Le tarif auquel tu souscris est figé à vie. Le détail des plans est sur menestrel.dev.

Dépannage

Le build sort une collection vide

getCollection() renvoie [] alors que l’admin montre du contenu. Trois causes réelles, dans l’ordre où les vérifier :

1. MENESTREL_OFFLINE=1 est resté dans le .env. C’est la priorité la plus haute du loader : même avec MENESTREL_CONTENT_URL ou MENESTREL_TOKEN posés, il lit .menestrel/snapshot/, c’est-à-dire la fixture de démonstration du starter ou un pull qui date. Le starter pose cette variable par défaut ; menestrel init la commente quand il installe ton token. Commente-la, ou rafraîchis le cache avec npx menestrel pull.
2. Rien n’est publié dans cette collection. Un snapshot ne contient que les entrées publiées : un brouillon n’y figure jamais. Une entrée non publiée dans une langue est servie avec sa langue de repli, puis avec la langue par défaut ; elle ne disparaît d’une langue que si aucune langue de sa chaîne de repli n’est publiée. Vérifie le statut par langue dans l’admin, puis publie.
3. Le snapshot lu n’est pas le dernier. Un MENESTREL_SNAPSHOT_ID épinglé ou un pull antérieur à la publication te sert un contenu exact, mais vieux.

Si aucune source n’est configurée (ni URL, ni token, ni mode hors-ligne), il n’y a pas de collection vide silencieuse : le build échoue avec ce message, la porte de sortie incluse.

[menestrel] No content source configured. Set MENESTREL_CONTENT_URL, or MENESTREL_TOKEN, or run `npx menestrel pull` and set MENESTREL_OFFLINE=1.

Astuce

Demander une collection absente du snapshot échoue aussi, au lieu de renvoyer [] : [menestrel] Collection 'services' does not exist in this snapshot. Ce message pendant un build hors-ligne signifie presque toujours que le cache local date d’avant ton menestrel sync.

Le loader échoue avec HTTP 401 ou 403

Le message ressemble à [menestrel] GET https://... failed with HTTP 401. Ces deux codes ne disent pas la même chose :

• 401 : le token est inconnu, révoqué ou expiré. La réponse ne précise jamais lequel, c’est voulu : un secret volé n’apprend rien à celui qui le teste. Crée un nouveau token dans « Réglages du site », onglet « Jetons d’API », et remplace l’ancien dans le .env ou chez l’hébergeur.
• 403 : le token existe mais sa portée ne suffit pas. sync, import et export exigent un token admin (préfixe cmt_adm_) ; pour le loader au build, read_published (cmt_pub_) suffit.

En production, le mieux reste de ne poser aucun token : avec MENESTREL_CONTENT_URL, le build lit le CDN et ne peut plus rencontrer de 401. Voir Variables d’environnement.

Le déploiement ne se déclenche pas

La publication crée bien un snapshot, mais rien ne se reconstruit. Tout se vérifie dans « Réglages du site », onglet « Déploiement » :

• Aucun hébergeur connecté. Publier matérialise le snapshot, mais rien ne se reconstruit tant qu’un hébergeur n’est pas branché.
• La cible est « En pause ». Après trois échecs consécutifs de déclenchement, Menestrel arrête de marteler l’hébergeur et met la cible en pause. Corrige la configuration (hook supprimé côté hébergeur, token révoqué…), puis clique « Reprendre » : le compteur d’échecs repart à zéro.
• La cible est « Désactivé ». Elle a été coupée volontairement : bouton « Activer ».
• Ce n’est pas en panne, c’est regroupé. Chaque projet a une fenêtre de regroupement des builds (90 secondes par défaut, réglable), plus un quota de déclenchements par heure selon le plan. Les publications en rafale sont regroupées, jamais rejetées.

Le cycle complet, machine à états du déploiement comprise, est dans Publication et versions.

L’import s’est interrompu

Relance la même commande. menestrel import tient un état local dans .menestrel/import-state.json, écrit de façon atomique après chaque entrée, et la reprise est sans doublon :

• les entrées déjà créées sont sautées (comptées « ignorées » dans le bilan final), jamais recréées ;
• les médias sont dédupliqués par empreinte SHA-256 : rien n’est ré-uploadé ;
• une coupure au milieu d’une requête est couverte : si le serveur avait déjà créé l’entrée (slug déjà pris, singleton déjà présent), la reprise la signale (avertissement already_exists) au lieu de la dupliquer.

Un fichier source modifié après import est signalé (avertissement source_changed) mais jamais ré-importé : une fois la migration faite, l’admin est la seule source de vérité. Le parcours complet est dans Importer un site existant.