Sanity, puis Payload : le CMS qu'on a choisi deux fois
De Sanity à Payload, deux mois après le premier choix : comment les accès par langue, le coût de l'édition et les données partagées ont orienté notre décision.
L’essentiel en bref
On a commencé la refonte avec Sanity. Deux mois plus tard, on est passés sur Payload. Les besoins d'accès par langue et de gestion des données ont pesé davantage que prévu dans ce second choix.
Je suis Jim. Dans le premier article de la série, j'ai expliqué pourquoi on quittait WordPress et pourquoi on retenait Astro pour le site. Restait le CMS, l'outil dans lequel l'équipe allait écrire, traduire et publier. C'est ce choix que l'on a repris en cours de route.
Pourquoi on avait retenu Sanity
Sanity permet de définir une structure de contenu et de la séparer de l'affichage du site. Cette souplesse nous intéressait pour les articles et les différents types de pages.
Je l'avais aussi envisagé pour le site d'Eva, où il restait une alternative au CMS visuel. Mais les besoins n'étaient pas les mêmes : d'un côté une personne, de l'autre 2700 pages et une équipe répartie sur sept langues.
Notre premier choix tenait compte de l'édition. Il fallait pousser davantage la vérification des accès et du fonctionnement à l'échelle de l'équipe.
Les accès par langue
Je voulais qu'un rédacteur polonais travaille sur le polonais et qu'un traducteur allemand travaille sur l'allemand. Ces restrictions devaient être appliquées par le CMS, pas seulement suggérées par l'interface.
Sanity propose des droits et des ressources de contenu personnalisés. Sa documentation décrit notamment le filtrage des documents, avec des fonctions disponibles sur certaines offres Enterprise. Ce n'est donc pas une incapacité de l'outil à gérer des permissions fines.
Pour notre projet, le niveau d'offre et la configuration nécessaires ne correspondaient pas à ce qu'on voulait mettre en place. Ce point était une contrainte de départ, et on l'avait sous-estimé.
Le modèle de coût et les données partagées
Le coût des accès d'édition comptait aussi dans notre comparaison. Avec plusieurs rédacteurs et traducteurs, il fallait regarder le modèle retenu pour toute l'équipe, pas seulement pour les deux personnes qui configuraient le CMS au départ.
Enfin, on voulait centraliser des données réutilisées dans les pages, puis les afficher par des références. Sanity permet de modéliser du contenu structuré. Notre préférence allait néanmoins vers une configuration que l'on pouvait développer et maintenir directement avec le reste du projet.
Ces points ne font pas de Payload un meilleur CMS dans tous les cas. Ils expliquent pourquoi il répondait davantage à notre manière de travailler.
Le changement du 22 mai
Le 22 mai, avec Max, le développeur du projet, on a décidé d'arrêter la mise en place sur Sanity pour passer à Payload.
Une partie du travail devait être reprise. On a préféré le faire à ce stade, avant d'installer toute l'équipe et de transférer les contenus. Sur un prochain projet, je vérifierais ces exigences avant de commencer l'import.
Ce que Payload nous permettait de mettre en place
Une installation sur notre infrastructure. Dans ce fonctionnement, on ne paye pas un siège de CMS supplémentaire pour chaque rédacteur. Il reste l'hébergement, la base de données, les mises à jour et le travail de maintenance. L'auto-hébergement ne rend pas ces coûts nuls.
Un schéma en TypeScript. Les collections, comme les articles, les pays, les fiches et le glossaire, sont définies dans la configuration. On peut les faire évoluer dans le même environnement de développement que nos autres outils.
Des règles d'accès en code. Payload permet de définir les droits par opération, document ou champ. On peut donc écrire les restrictions correspondant à notre modèle de langues, puis les tester avec les comptes de l'équipe.
L'éditeur permet également d'intégrer des blocs propres au projet. L'un d'eux sert à insérer des références vers les données partagées.
Les tokens dynamiques
Un token est une référence à une donnée, au lieu d'une valeur recopiée dans le texte. Quand une page utilise un taux de TVA, le rédacteur peut insérer cette référence dans l'article.
Le mécanisme évite de rechercher chaque copie d'un chiffre. Il ne met pas à jour les valeurs qui resteraient écrites en dur, et une référence manquante peut poser problème. Il faut donc suivre les usages et contrôler le rendu. On a construit ce système pour notre modèle de contenu.
Une fois le CMS choisi et le modèle de contenu posé, il restait à transférer les 2700 pages en sept langues, avec les redirections et les vérifications nécessaires après la bascule.