Decap CMS

Ce qu'est vraiment Decap CMS

Decap CMS (github.com/decaporg/decap-cms) règle bien un problème très précis : votre site est un dossier de fichiers Markdown dans un dépôt, et la personne qui veut changer une phrase n'utilise pas Git. Il s'installe sous le chemin d'administration du site que vous avez déjà. La version rapide, selon la description du projet lui-même, tient en un seul fichier HTML plus un fichier de configuration, le CMS étant chargé depuis un CDN ; l'installation complète passe par npm et laisse davantage de marge de personnalisation. Un YAML déclare votre modèle de contenu, l'éditeur en tire des formulaires, et chaque enregistrement devient un commit.

La surface d'édition s'assemble à partir de widgets, et l'éventail suffit à la plupart des sites : Markdown et texte enrichi, images et fichiers, dates, nombres, booléens, listes déroulantes, listes et objets imbriqués, plus un widget de relation pour faire pointer une entrée vers une autre. L'authentification se branche au lieu d'être supposée : le dépôt fournit des backends pour GitHub, GitLab, Bitbucket, Azure, Gitea et Forgejo, une passerelle Git hébergée et un proxy pour l'édition en local. Les médias peuvent rester dans le dépôt ou partir vers Cloudinary ou Uploadcare. La licence est MIT, et une offre payante nommée Decap Turbo existe pour les équipes qui veulent une gestion centralisée des comptes, des rôles plus fins, un proxy de base de données ou un accompagnement.

Une note de nommage qui vous épargnera une heure de confusion : le projet s'appelait Netlify CMS jusqu'en février 2023, et son propre README le dit. Une bonne part des tutoriels que vous trouverez emploient encore l'ancien nom et l'ancien paquet, et la configuration a évolué depuis leur rédaction.

Le compromis que vous acceptez

Un commit par enregistrement, c'est tout le principe, et il coupe des deux côtés. Votre contenu est versionné par défaut et peut être relu comme une pull request si vous le souhaitez : une modification de texte suit alors le même circuit qu'une modification de code, ce qui est réellement rare et précieux dans une équipe où personne ne sait qui a touché à la page d'accueil. Le prix, c'est la latence. Corriger une coquille équivaut à un build : si le build prend quatre minutes, la correction prend quatre minutes. Pour un site qui publie chaque semaine, cela n'a aucune importance. Pour un site qui publie toutes les heures, c'est le mauvais outil, et quelque chose avec une base de données derrière est le bon.

Il vaut mieux le situer face à ses voisins que le juger seul. Payload occupe l'autre extrémité du même axe : un framework complet avec sa propre base de données, ce qu'il vous faut quand le contenu est en réalité une application. Ghost est un produit de publication achevé, pas une couche posée sur votre dépôt. Decap est le plus mince des trois, et cette minceur est précisément l'intérêt : il ajoute un écran d'édition à un site qui fonctionne déjà et ne reprend rien d'autre à son compte.

Qui modifie la page une fois qu'elle est en ligne

Nous n'exploitons pas Decap, cette page n'avance donc rien sur son exploitation. Ce dont nous pouvons parler de première main, c'est la question à laquelle il répond, car nous y sommes arrivés par l'autre bout. Nous publions des pages d'atterrissage pour nos propres clients, et l'interface d'édition est une conversation : le client demande une modification et l'agent l'effectue. Un client a fait passer une page par trois séries de révisions en une seule séance, et le plus frappant a été de voir où filait le temps. Rien n'est parti dans l'éditeur. Tout est parti dans la décision de ce que la page devait dire.

C'est l'argument pour garder cette couche ennuyeuse. Quel que soit votre choix, le goulot d'étranglement se déplace vers le texte en une semaine environ : prenez l'option qui vous coûtera le moins d'entretien et passez la différence sur les mots. Si nous placerions malgré tout un éditeur adossé à Git devant quelque chose de plus lourd pour un petit site, c'est à cause d'une seconde leçon apprise cher : ce qu'émet un générateur de site statique, c'est du HTML fini, ce qui évite discrètement la panne qui nous a coûté des mois d'indexation sur nos propres pages rendues dynamiquement — un robot qui reçoit une coquille au lieu d'une page. Un montage qui commite du Markdown et reconstruit un site statique ne peut pas commettre cette erreur.

Publier est aussi le moment où l'outillage cesse d'aider. Un site que quelqu'un peut modifier n'est pas un site que quelqu'un a lu, et le travail d'après — être trouvé, être choisi, être relancé — relève d'une autre discipline que celle qui a mis la page en ligne. C'est ce vide que vise AgentCeres — l'AI Growth Officer, sur agentceres.com : une équipe marketing IA pilotée qui rédige le travail et attend qu'une personne approuve tout ce qui sort. Et si vous choisissez encore les fondations, AstroWind est un modèle de départ plutôt qu'un éditeur, et Webstudio est la réponse en constructeur visuel à la même question.