Sur ce site, corriger un titre en ligne écrit un commit. Pas une ligne dans une base : un commit, avec une date et un diff. Le dernier en date s’appelle content: édition inline (1 champ), et il retire une phrase d’un jalon de la page « à propos ».
Beaucoup de clients touchent leur site du bout des doigts, par peur de tout casser. Des champs obscurs, un aperçu qui ment. Je ne leur donne pas tort : sur bien des sites la peur est fondée, et un champ mal rempli suffit à faire tomber une page.
Éditer sur le site, pas à côté
Avec Sveltia, on édite le site depuis le site. Connecté, on allume l’édition, on clique un titre, on le corrige, on publie : le build repart, c’est en ligne. Ce qu’on voit en éditant est ce qui sera publié, parce que c’est la même page. Pas d’aperçu séparé qui diverge, pas d’interface parallèle à apprendre.
La première fois, on cherche le piège. Il n’y en a pas, mais il y a une contrepartie : cette édition ne marche que sur des textes que le développeur a déclarés éditables. Un texte oublié dans un gabarit reste inaccessible tant que personne ne l’a branché.
Pourquoi un commit plutôt qu’une ligne de base
Chaque modification est un fichier texte versionné, donc tout se retrouve, et revenir en arrière ne demande pas de sauvegarde parce que la sauvegarde est le mécanisme lui-même. Le contenu est du Markdown et du JSON, relisible dans dix ans, exportable en une seconde puisqu’il est déjà exporté.
Deux personnes qui éditent le même texte en même temps, sur une base, produisent un écrasement silencieux : la dernière écriture gagne, la première disparaît sans trace. Ici, la publication relit la référence de la branche avant d’écrire et recommence si elle a bougé entre-temps. C’est le fonctionnement normal de git, récupéré gratuitement.
Une seule vérité, et une seule source d’erreur
Le CMS et les pages lisent les mêmes fichiers. Pas de synchronisation qui décroche.
En échange, il faut tenir un miroir. Un champ ajouté au schéma src/content.config.ts doit exister dans public/admin/config.yml, sinon il devient invisible depuis l’admin, et le site fonctionne parfaitement en dissimulant qu’une partie du contenu n’est plus éditable. C’est le genre de panne qui ne réveille personne.
Je n’ai pas trouvé mieux que de l’écrire en toutes lettres dans le fichier de règles du dépôt.
Ce que coûte la peur de casser
Un site qu’on n’ose pas modifier se fige. Les prix vieillissent, les références datent, une page décrit un service qui n’existe plus. Le coût d’un back-office intimidant est dans ces corrections qui ne sont jamais faites. Personne ne décide de laisser mentir son site. Il ment parce que le corriger demandait d’appeler quelqu’un, et que ça pouvait attendre.
