11 juin 2026

Laisser un client modifier un site statique sans lui ouvrir le dépôt

Cinq façons de donner les droits d'édition à un client non technique sur un site statique, ce que chacune coûte réellement en support, et les deux questions qui tranchent.

Vous avez construit un site statique rapide. Il se déploie sur un CDN, ne coûte presque rien à héberger, et affiche de bons scores partout où on mesure. Puis le client demande comment il change un tarif, et vous réalisez que la réponse honnête est « vous m’envoyez un mail ».

Cette réponse tient environ trois mois. Après, elle devient une interruption récurrente pour vous et une frustration silencieuse pour lui, et l’un des deux finit par y remédier.

Voici les cinq options réelles, avec ce que chacune coûte vraiment.

Option 1 : il vous envoie un mail

Prenons-la au sérieux, parce que c’est la bonne réponse plus souvent que les développeurs ne l’admettent.

Si le contenu bouge deux fois par an et que vous facturez déjà un forfait de maintenance, une modification de cinq minutes entre dans ce que vous êtes payé à faire. Ajouter un CMS, c’est un abonnement, une séance de prise en main, et un outil que le client utilise si rarement qu’il en oublie le fonctionnement entre deux visites.

Où ça casse : au moment où la fréquence dépasse une fois par mois environ. À partir de là, les interruptions vous coûtent plus en changements de contexte que n’importe quel abonnement, et le client commence à se sentir gênant quand il demande. Ce sentiment est le vrai dégât : c’est de là que vient « notre prestataire web est difficile à joindre », et c’est ce qui met fin aux relations.

Option 2 : vous lui donnez le dépôt

La version sans CMS : vous apprenez le markdown au client, vous lui créez un compte GitHub, il modifie les fichiers depuis l’interface web.

J’ai vu ça fonctionner exactement une fois, avec un client qui se trouvait être ingénieur. Pour tous les autres, ça casse au premier conflit de fusion, ou à la double authentification, ou au moment où il modifie astro.config.mjs par accident parce que le fichier était dans la liste.

Où ça casse : presque toujours. Le mode d’échec n’est pas qu’il casse le site, même si ça arrive. C’est qu’il n’ose plus y toucher, et vous revoilà à l’option 1, en ayant payé la mise en place.

Option 3 : un CMS git

Decap, Sveltia, Keystatic, Tina. Une interface à formulaires qui commite du markdown dans votre dépôt. Gratuit, sans serveur, contenu dans Git.

C’est un vrai progrès : le client voit des champs plutôt que des fichiers, et ne peut pas modifier votre configuration par erreur. Ce qui n’a pas disparu, c’est le compte. Pour autoriser le CMS à écrire dans le dépôt, votre client a besoin d’une identité sur GitHub ou GitLab, et doit accorder à une application le droit d’écrire dans un dépôt de code. Pour un développeur, ce n’est rien. Pour une fleuriste, c’est un écran sincèrement déroutant.

L’autre chose qui n’a pas disparu, c’est vous. Chaque site est un fichier de configuration que vous tenez à la main, chaque version majeure apporte ses ruptures, et les images partent dans Git pour y rester.

Où ça casse : sur un parc. Un site, ça va. Vingt sites, c’est une taxe de maintenance permanente et une catégorie d’appels au support que vous prendrez toujours. Le comparatif détaillé couvre les cas où ça reste le bon choix.

Option 4 : un CMS headless

Contentful, Sanity, Storyblok, Strapi, Prismic. Une API de contenu hébergée, une vraie interface d’édition, aucun accès au dépôt pour personne.

Ça règle proprement le problème côté client. L’édition est agréable, les médias sont gérés, et personne ne voit GitHub.

Ça en introduit deux nouveaux. Le prix, qui est par projet ou par siège et s’additionne brutalement sur un parc : au relevé du 8 août 2026, Contentful passe du gratuit à 300 € par mois sans rien entre les deux, Sanity facture 15 $ par siège, Storyblok ajoute 20 $ par mois pour chaque langue supplémentaire. Et le dernier kilomètre : ces outils publient dans leur propre API et, au mieux, déclenchent un webhook. Savoir si votre site s’est reconstruit, si la construction a échoué, si la page que le client vient de modifier est réellement servie, ne les regarde pas. Votre client clique sur Publier et reçoit une confirmation qui signifie « enregistré dans notre base », ce qui n’est pas ce qu’il comprend.

Où ça casse : quand le nombre de sites multiplie le prix, et quand personne ne remarque une construction ratée avant un visiteur.

Option 5 : un CMS qui va jusqu’au bout

La cinquième option est celle que nous avons construite, lisez donc la suite en sachant qui écrit.

Le principe est que publier devrait vouloir dire que la page est en ligne, pas qu’une ligne a été écrite. Concrètement, quand l’éditeur clique sur Publier :

1. Le contenu courant est figé dans un instantané immuable, poussé sur un CDN.
2. Le CMS déclenche la reconstruction chez l’hébergeur où le site vit déjà : Vercel, Netlify, Cloudflare Pages, GitHub Actions, ou un serveur ordinaire.
3. Il suit le déploiement et montre à l’éditeur l’état réel, jusqu’à « en ligne à 14 h 32 ».

Les conséquences qui comptent, au-delà du message agréable : parce que l’instantané est sur un CDN et non dans l’API, une construction aboutit même pendant que le CMS est éteint. Le site de votre client n’a aucune dépendance à notre égard une fois construit. Nous le vérifions exprès en coupant l’API et en confirmant qu’un déploiement passe encore.

Le client se connecte avec une adresse email. Pas de plateforme de développeurs, pas d’écran d’autorisation, pas de dépôt.

Les deux questions qui tranchent

Tout ce qui précède se résume à deux questions.

À quelle fréquence le contenu change-t-il ?

Moins de six fois par an, n’achetez pas de CMS. Traitez ça dans votre forfait et dépensez l’argent ailleurs. Entre une fois par mois et une fois par semaine, un CMS se rembourse en interruptions évitées. Tous les jours ou plus, la vraie question est de savoir si un site statique est encore la bonne forme.

De combien de sites êtes-vous responsable ?

Un seul site change complètement le calcul. Sur un site, un CMS git est gratuit et sa maintenance est négligeable, ou une offre gratuite de headless est assez généreuse pour ne jamais payer. C’est le parc qui casse tout : le prix par projet se multiplie, les configurations tenues à la main se multiplient, et les appels au support aussi.

Le moment que personne ne prépare : la passation

Quelle que soit l’option retenue, il y a un moment où vous montrez l’outil au client, et ce moment décide si tout ce qui précède aura servi.

Deux choses ratent systématiquement.

Vous démontrez l’interface, pas son métier. Le réflexe du développeur est de faire visiter : voici les collections, voici la médiathèque, voici les réglages. Le client hoche la tête poliment et ne retient rien, parce que rien n’était rattaché à une chose qu’il veut réellement faire. Ce qui marche, c’est d’accomplir sa vraie tâche devant lui : « vous voulez changer le tarif d’une prestation, c’est exactement ça, trois clics ». Puis vous lui laissez la souris et vous le regardez le faire une fois.

Vous lui donnez trop de droits. Si le client peut modifier la navigation, restructurer les collections ou changer les réglages du site, l’un d’eux finira par le faire, un jour où vous êtes en vacances. Donnez à un éditeur les champs dont il a besoin et rien d’autre. Ce n’est pas de la défiance, c’est la même raison qui fait qu’on ne se donne pas un accès permanent à la base de production.

Une mesure utile à retenir : si un client bloque plus de dix minutes sur une modification de routine, c’est un défaut de votre configuration, pas un problème de formation. Chaque fois que nous avons creusé un de ces moments, la correction était de notre côté.

Ce que nous ne faisons volontairement pas

Puisque c’est notre blog, les limites ont leur place ici plutôt qu’en note de bas de page.

La publication passe par un build, en général une à trois minutes. Si votre client a besoin qu’une modification soit visible en dix secondes, nous ne sommes pas la bonne forme et le rendu serveur l’est.

Pas de constructeur de pages visuel. Le développeur définit les champs, le client les remplit. Si votre client compose des pages d’atterrissage à partir de blocs et veut voir la mise en page en tapant, Storyblok fait ça mieux que nous ne le ferons jamais.

Astro uniquement. Ni Next, ni Nuxt, ni Hugo. C’est un pari assumé : un seul framework, un loader natif et typé, une compatibilité garantie sous quatorze jours à chaque version majeure. Si votre stack est ailleurs, nous ne sommes pas une option.

Nous sommes un service hébergé. Il n’existe pas de Menestrel auto-hébergé. Si votre client exige que le contenu vive sur son infrastructure, un CMS git ou Strapi est votre réponse.

Par où commencer

Pour voir le côté édition sans rien engager, le plan gratuit couvre un site complet avec deux langues et deux éditeurs, sans carte bancaire. npm create menestrel@latest met un projet debout en une commande, et menestrel import lit les content collections d’un site Astro existant, images comprises, si vous en avez déjà un à déplacer.

Si vous préférez voir comment nous nous situons face à l’outil que vous utilisez déjà, les comparatifs passent en revue Contentful, Strapi, Sanity, Storyblok, Directus et la famille des CMS git, un par un, avec les cas où ils sont le meilleur choix.