Jetons d'API et sécurité

Un token d’API authentifie une machine auprès d’un projet : le loader pendant un build, le CLI sur ton poste. Chaque token appartient à un seul projet et porte une portée qui borne ce qu’il autorise. La règle : toujours la plus petite portée qui suffit.

Les trois portées

Portée	Préfixe du secret	Sert à
`read_published`	`cmt_pub_`	Lire le contenu publié : le loader au build, `menestrel pull`.
`read_draft`	`cmt_drf_`	La future préviz des brouillons. Lit aujourd’hui la même chose que `read_published`.
`admin`	`cmt_adm_`	Le poste développeur : `sync`, `import`, `export`, lecture du schéma, écriture de contenu par l’API.

read_published couvre tout ce dont un site public a besoin : récupérer le dernier snapshot publié et ses fichiers. C’est la portée du build, il n’en faut jamais plus sur un déploiement public. En production, le mieux reste de ne pas poser de token du tout : avec MENESTREL_CONTENT_URL, le build ne dépend plus de l’API. Voir Variables d’environnement.

read_draft est réservé aux préversions : un déploiement de relecture qui montrera aussi les brouillons. Cette préviz n’est pas encore ouverte : en attendant, cette portée lit exactement le même contenu publié que read_published. Ne le mets jamais sur le site public : une préversion qui expose des brouillons publie ce qui n’était pas prêt.

admin est la portée du CLI côté développeur. menestrel sync, import et export la vérifient et refusent toute autre portée (code de sortie 5) ; menestrel init avertit si le token fourni n’est pas admin. C’est aussi la portée exigée pour lire le schéma et écrire du contenu par l’API.

Le cycle de vie d’un token

Création : réglages du projet, onglet « Jetons d’API ». Réservée aux propriétaires et administrateurs de l’organisation. Expiration optionnelle : 90 jours, 1 an, une date choisie, ou jamais.
Suivi : la liste affiche le dernier usage de chaque token. Un token « jamais utilisé » depuis des mois est un candidat à la révocation.
Révocation : immédiate. Tout ce qui utilise le token s’arrête à la requête suivante. Un token révoqué ou expiré reçoit la même réponse 401, sans préciser pourquoi : un secret volé n’apprend rien à celui qui le teste.
Audit : création et révocation sont journalisées, avec l’auteur et la date.

Bonnes pratiques

Un token par usage. « Build Vercel », « CI GitHub », « Poste de Léa » : trois tokens, pas un partagé. Révoquer l’un n’éteint pas les autres, et le libellé dit qui casse si tu révoques.
Jamais dans le repo. Un token vit dans une variable d’environnement. menestrel init le pose dans .env et ajoute .env au .gitignore ; sur Vercel, Netlify ou en CI, utilise les variables d’environnement du projet.
Rotation sans coupure. Crée le nouveau token, bascule les environnements, révoque l’ancien. Deux tokens valides coexistent sans problème.
En cas de fuite, révoque d’abord. La révocation est immédiate et sans effet sur les autres tokens : commence par là, cherche ensuite comment le secret est sorti.

Tes données : où, et sous quelles règles

Hébergé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).

RGPD. Pour les contenus et les comptes d’éditeurs, Menestrel agit comme sous-traitant : DPA signable en ligne, liste publique des sous-traitants (Scaleway, Bunny, Stripe pour le paiement, Scaleway TEM ou Brevo pour les emails), tout ajout notifié 30 jours à l’avance. Aucun tracker tiers dans l’admin.

Durées de conservation. Après résiliation, le contenu est conservé 30 jours, avec un export proposé avant suppression. Les sauvegardes sont gardées 30 jours, les journaux 12 mois.

Export complet, à tout moment. npx menestrel export ressort tout : content/ en Markdown, data/ en JSON, media/ avec les originaux. Pas de format propriétaire, pas de préavis, pas de ticket au support : le jour où tu pars, tu pars avec tout. Voir la référence CLI.