Chapitre 01Comprendre
Pourquoi cet outil existe
Le contexte réel, les solutions écartées et les raisons de chaque refus. Ce chapitre n'apprend à rien faire : il explique pourquoi tout le reste est fait ainsi.
Le point de départ
Une agence livre des sites vitrines à des clients non techniques : boulangeries, cabinets, artisans, associations, petites structures de service. Le site est fait une fois, bien, et il est censé vivre plusieurs années.
Trois semaines après la livraison, il se passe toujours la même chose :
« Bonjour, est-ce que vous pouvez changer la photo de la page d'accueil et remplacer “ouvert le lundi” par “fermé le lundi” ? »
Cette demande coûte, à chaque fois : un aller-retour de courriels, une intervention de quinze minutes qui s'en facture quarante-cinq, un déploiement, une vérification. Multipliée par dix clients et par deux ans, elle devient une charge d'exploitation permanente pour un travail sans intérêt. Côté client, l'expérience est pire encore : il attend deux jours pour un mot, et il finit par ne plus rien demander — le site se périme.
Le besoin réel n'est donc pas « un CMS ». C'est : que le client puisse changer un texte, une photo, un témoignage, sans nous, sans se former, sans rien casser, et sans que le site perde ce qui a justifié qu'on le construise ainsi — sa vitesse et sa visibilité.
Ce qui a été écarté, et pourquoi
| Solution | Ce qu'elle apporte | Pourquoi elle a été écartée |
|---|---|---|
| WordPress | Le client édite, tout le monde connaît. | Une base de données et un serveur applicatif à maintenir par site, des mises à jour de sécurité perpétuelles, des extensions qui cassent, un hébergement plus cher et plus lent. Pour un site de sept pages qui change quatre fois par an, c'est une infrastructure entière à surveiller. |
| CMS headless (Contentful, Sanity, Strapi…) | Contenu structuré, API propre, bon outillage. | Un abonnement par site, un compte de plus pour le client, et le contenu qui part vivre chez un tiers. Surtout : le client édite dans un tableau de bord, pas sur sa page — il doit se représenter mentalement le rendu à partir d'un formulaire. |
| CMS sur Git (Decap, Tina…) | Le contenu reste dans le dépôt, pas de base de données. | On s'en est approché de très près. Mais l'édition reste un tableau de bord avec une arborescence de fichiers, et l'authentification suppose un compte Git ou un fournisseur d'identité pour le client. Deux choses qu'un boulanger n'aura pas. |
| Rien — le client redemande à l'agence | Zéro développement. | C'est la situation de départ, et c'est elle qu'on veut quitter. |
Le point commun des trois premières : elles rendent l'édition possible en éloignant le client de sa page. Le tableau de bord est l'endroit où un client non technique décroche. Il ne sait pas si « bloc hero, champ intro » est le paragraphe qu'il a sous les yeux, et il n'a aucune raison de le savoir.
La contrainte qui a tout décidé
Un site vitrine n'existe que pour être trouvé. Aujourd'hui, il doit l'être deux fois : par les moteurs de recherche, et par les assistants qui répondent à la place des moteurs — GPTBot, ClaudeBot, PerplexityBot, Google-Extended.
Ces robots ne rendent pas ou peu le JavaScript. Un contenu injecté côté navigateur est, pour eux, un contenu qui n'existe pas. Et leur budget d'exploration est plus court que celui de Googlebot : une page lourde est visitée moins souvent, moins profondément.
Cette contrainte élimine d'un coup toute une famille de solutions : celles où le contenu arrive après le HTML. Elle impose que chaque mot visible du site soit dans le HTML servi, avant la moindre ligne de JavaScript. Elle explique la règle la plus stricte du projet — pas d'hydratation sur une zone éditable — et le contrôle automatique qui la fait respecter (check-html).
Les deux idées
De ce point sont sorties deux décisions, et tout le reste en découle.
Idée 1
Le contenu est un fichier, injecté au build
Chaque page a un fichier JSON. Astro le lit au moment de la construction et écrit le texte dans le HTML. À l'exécution, il n'y a plus de contenu à charger : il n'y a qu'un fichier statique sur un CDN. Aucun appel réseau, aucune base de données, aucune latence.
Idée 2
L'édition se fait sur la page, pas ailleurs
Le client ouvre son site, entre une clé, et une interface se superpose à ses propres pages. Il clique sur le texte qu'il veut changer — celui qu'il voit — et il le change. Il n'y a rien à traduire mentalement entre un champ de formulaire et un rendu.
La conséquence de l'idée 1 est qu'une publication n'est pas une écriture en base : c'est un commit, qui déclenche une reconstruction du site. Le contenu publié est figé dans le HTML trente à soixante secondes plus tard. Ce délai est le prix de la garantie ; il est annoncé au client dans l'interface, en langage courant.
Git comme base de données
Puisque le contenu est un fichier, son stockage est le dépôt. On y gagne, sans écrire une ligne :
- l'historique — qui a changé quoi, quand, avec le texte exact avant et après ;
- la restauration — revenir en arrière est un geste standard, pas une fonctionnalité à développer ;
- la sauvegarde — le dépôt est déjà répliqué, il n'y a pas de base à sauvegarder ;
- la relecture — un changement de contenu se lit comme un diff.
C'est aussi ce qui rend l'hébergeur interchangeable : le contenu n'appartient à aucune plateforme. Le jour où l'hébergement change, on redéploie le même dépôt ailleurs.
Un seul auteur, une clé
Le client n'a pas de compte GitHub et n'en aura pas. Le dépôt et le jeton d'écriture appartiennent à l'agence. La question devient : comment autoriser une personne à écrire dans un dépôt dont elle ne connaît pas l'existence ?
La réponse retenue est la plus petite qui tienne : une clé par site, générée
aléatoirement, dont seule l'empreinte argon2id vit côté serveur. Le client la reçoit une
fois, la range dans son gestionnaire de mots de passe, et la saisit sur
/admin. Aucun compte à créer, aucun logiciel à installer, aucun fournisseur
d'identité tiers dans la boucle.
Une clé unique par site signifie un auteur par site : l'historique ne distingue pas
deux personnes qui se partageraient la clé. C'est un choix, pas un oubli. Un besoin de
traçabilité individuelle se traite en remplaçant une seule implémentation —
auth.ts — par une authentification déléguée. Voir
Sécurité et authentification.
Ce que l'outil refuse de faire
Le périmètre est gelé, et la liste des refus est aussi importante que la liste des fonctionnalités. Ne sont pas implémentés, et ne le seront pas sans décision explicite :
- workflow de validation à plusieurs rôles ;
- permissions granulaires par champ ou par page ;
- versionnement visuel du contenu (comparer deux versions à l'écran) ;
- tests A/B ;
- formulaires avec stockage des réponses ;
- recherche interne, commentaires, espace membre ;
- éditeur de mise en page — déplacer ou créer des blocs.
Si l'un de ces besoins remonte et qu'il est réel, ce n'est pas une fonctionnalité à ajouter : c'est le signe que le projet en question demande un CMS du marché. Le dire au cadrage coûte une conversation ; le découvrir au troisième mois coûte le projet.
La frontière, annoncée dès la livraison
Un outil d'édition sans frontière explicite dérive sans fin : après le texte vient la couleur, après la couleur la position du bloc, après la position la page entière. La frontière est donc posée le jour de la livraison, en une phrase :
Au client
Les textes, les images, les vidéos, les éléments de liste. Ce qui se dit.
Au développeur
La structure, la mise en page, la charte, la navigation. Ce qui se montre.
Cette frontière n'est pas qu'un discours : elle est appliquée par le code. Le client ne choisit pas une couleur, il choisit parmi les cinq couleurs de sa charte ; il ne choisit pas une taille en pixels, il choisit parmi sept crans. Une valeur hors liste fait échouer le build. Voir Charte et styles.
À qui cela s'adresse
Bon terrain
- Sites vitrines de 3 à 30 pages, une à trois langues.
- Un interlocuteur unique côté client.
- Contenu qui change quelques fois par mois, pas plusieurs fois par jour.
- Une agence qui suit plusieurs sites et veut une seule base de code à corriger.
Mauvais terrain
- Blog à publication quotidienne, catalogue de milliers de références.
- Plusieurs rédacteurs simultanés avec relecture obligatoire.
- Contenu dépendant d'un utilisateur connecté ou d'un stock en temps réel.
- Besoin de créer des pages entières sans développeur.
Ce que ça coûte
La version 1 a été construite en huit lots, pour environ vingt jours de développement. Ce chiffre n'a d'intérêt que rapporté au suivant : chaque site supplémentaire coûte un à deux jours, intégration graphique comprise, parce que rien de la logique d'édition n'est réécrit — elle est consommée comme une dépendance versionnée.
C'est la seule raison pour laquelle le projet est séparé en deux (inline-core
partagé, le reste propre au site) et la seule règle d'architecture qui compte vraiment à
long terme : un correctif de sécurité doit atteindre les dix sites en changeant un
numéro de version, pas en dix modifications à retrouver.
La suite explique comment tout cela s'agence : Comment ça marche.