Choisir un CMS auto-hébergé pour une équipe éditoriale : tester le cycle de publication
Comparez les CMS auto-hébergés en leur faisant suivre vos tâches de publication, du premier brouillon à la correction, à l’export et à la maintenance.
Pourquoi l’adéquation au flux de travail compte plus qu’une liste de fonctionnalités
Un CMS peut afficher des fonctionnalités adaptées en apparence et rendre malgré tout les tâches de publication quotidiennes laborieuses. Il ne suffit pas de vérifier si une plateforme propose des brouillons, des rôles ou la planification. Il faut aussi déterminer si votre équipe peut accomplir son travail clairement, avec les bonnes personnes impliquées et sans solutions de contournement évitables.
WordPress, Drupal, Ghost ou tout autre candidat doit être évalué en fonction de vos besoins. Le choix dépend de votre contenu, de vos responsabilités éditoriales et de votre configuration. Vérifiez les capacités de chaque candidat dans la version et la configuration que vous envisagez réellement.
- Évaluez des tâches de bout en bout plutôt que des fonctionnalités isolées.
- Utilisez le même contenu de test, les mêmes rôles et les mêmes critères d’acceptation pour chaque candidat.
- Consignez les solutions de contournement, les transmissions peu claires et les configurations nécessaires.
Cartographier le cycle de publication, exceptions comprises
Avant d’ouvrir une démonstration, notez le parcours d’un contenu représentatif au sein de votre équipe. Incluez le déroulement habituel et les situations qui l’interrompent. Une cartographie simple peut commencer par une commande ou une idée, puis passer par la rédaction, la révision, l’approbation, la publication et la maintenance ultérieure. Adaptez les étapes à votre processus.
Demandez à chaque personne impliquée ce qu’elle reçoit, ce qu’elle modifie, quelles décisions elle prend et comment elle sait que la personne suivante peut agir. Ajoutez des exceptions : une personne chargée de la révision indisponible, une correction après publication, un contenu à publier plus tard ou un brouillon mis en attente. Ces cas révèlent des difficultés qu’une démonstration bien rodée pourrait ne pas montrer.
- Indiquez chaque étape, le rôle responsable, la transmission et le résultat attendu.
- Précisez quelles étapes sont obligatoires et lesquelles dépendent du type de contenu ou du niveau de risque.
- Répertoriez les exceptions courantes, comme les brouillons renvoyés, les corrections urgentes et les changements de date.
- Définissez ce qui constitue une transmission réussie avant de comparer les systèmes.
Constituer un jeu de tests représentatif
Choisissez des contenus de test qui reflètent les besoins de votre équipe. Un seul article court suffit rarement à évaluer différentes structures, différents contributeurs ou divers besoins de révision. Utilisez des exemples plutôt que des contenus réels sensibles, sauf si votre organisation a approuvé l’environnement de test pour ce type de données.
Gardez le jeu de tests raisonnable, mais varié. Incluez les types de contenus publiés par votre équipe, les médias ou les liens utilisés et les contenus récurrents qui doivent apparaître à plusieurs endroits. Ajoutez des comptes de test correspondant aux responsabilités réelles, par exemple auteur, éditeur, approbateur et administrateur. Testez directement les autorisations au lieu de vous fier aux seuls intitulés des rôles.
- Sélectionnez un contenu courant, un contenu complexe et un contenu nécessitant une correction.
- Incluez des contributeurs et des réviseurs représentatifs de vos véritables transmissions.
- Ajoutez des exemples avec différents parcours de révision ou calendriers de publication, s’ils sont pertinents.
- Définissez les résultats attendus avant les tests pour comparer les candidats de façon cohérente.
Tester la rédaction, la révision, l’approbation et les aperçus
Réalisez un exercice complet, du brouillon à la décision. Demandez à une personne de créer ou de modifier le contenu de test, à une autre de le réviser, puis à la personne concernée de décider s’il peut être publié. Observez si chaque participant sait ce qu’il doit faire ensuite et si l’équipe distingue clairement les états pertinents dans son propre processus.
Testez les aperçus avec les personnes qui s’y fient. Vérifiez si elles peuvent évaluer le contenu dans une présentation utile à leur décision et si l’équipe repère facilement les modifications apportées après la révision. Évaluez le comportement dans la version et la configuration envisagées.
- La personne qui rédige sait-elle qui doit réviser le contenu et ce qu’il reste à faire ?
- La personne chargée de la révision peut-elle transmettre son avis ou sa décision comme prévu ?
- L’équipe peut-elle savoir si les modifications demandées ont été effectuées ?
- L’aperçu facilite-t-il la révision de la mise en page et des contenus liés, lorsqu’ils sont pertinents ?
- Que se passe-t-il lorsqu’une personne chargée de la révision refuse, met en attente ou renvoie un brouillon ?
Tester les révisions, la planification, les corrections et la réutilisation
Le cycle de publication ne s’arrête pas après l’approbation. Révisez un contenu, comparez sa nouvelle version à la précédente et déterminez quelles informations aideraient l’équipe à comprendre les modifications. Vérifiez directement le comportement disponible au lieu de présumer que l’historique ou la comparaison des versions fonctionneront d’une certaine manière.
Si votre équipe planifie des publications, testez la définition, la modification et l’annulation d’une date prévue. Vérifiez comment les personnes responsables peuvent confirmer cette date et réagir à un changement de calendrier. Pour les corrections, suivez le parcours complet, de la détection d’un problème à l’approbation et à la publication de la correction. Pour les contenus réutilisés, identifiez la source de référence et vérifiez comment les mises à jour sont gérées partout où le contenu apparaît.
- L’équipe peut-elle examiner les modifications antérieures pour faciliter les corrections ?
- La personne responsable peut-elle vérifier, modifier ou annuler une publication planifiée ?
- Une correction après publication est-elle attribuée, révisée et confirmée clairement ?
- Le personnel peut-il repérer où le contenu réutilisé apparaît et savoir comment ses mises à jour sont gérées ?
- Consignez les étapes manuelles, les contenus dupliqués et les responsabilités peu claires.
Vérifier les rôles et les transmissions au regard des responsabilités réelles
Commencez par les responsabilités plutôt que par les noms de rôles du CMS. Créez une courte matrice des accès indiquant qui peut créer, modifier, réviser, approuver, publier et gérer les paramètres. Testez chaque compte représentatif par rapport à cette matrice : les personnes doivent pouvoir accomplir le travail nécessaire sans effectuer les actions réservées à quelqu’un d’autre.
Incluez les situations temporaires ou moins fréquentes, comme le remplacement d’un collègue par une personne chargée de la révision ou l’intervention d’un administrateur pour débloquer un contenu. Déterminez qui demandera, approuvera et supprimera les accès. Un flux de travail qui dépend du compte d’une seule personne ou de connaissances informelles peut être difficile à maintenir.
- Énumérez les responsabilités professionnelles et les actions nécessaires avant de les associer aux rôles du système.
- Testez les accès avec des comptes distincts plutôt que de vous fier à la vue d’un administrateur.
- Vérifiez que les transmissions restent compréhensibles lorsqu’une personne est indisponible.
- Désignez les responsables des modifications de comptes et des décisions sur le flux de travail.
Évaluer la migration, l’exportation et la propriété à long terme des contenus
Le choix d’un CMS a des conséquences au-delà de la première publication. Déterminez ce que l’équipe pourrait devoir déplacer ou conserver : contenu, médias, liens, structure, métadonnées et traces des décisions éditoriales. Consultez la documentation du projet ou renseignez-vous sur les options d’exportation, puis effectuez un petit test avec des contenus représentatifs. Un bouton d’exportation ou une affirmation générale sur la portabilité ne garantit pas que le résultat répondra à vos besoins.
Définissez ce qu’une sortie réussie signifie pour votre organisation. Les éléments exportés sont-ils examinables ? Les informations nécessaires sont-elles préservées ? Quelles opérations exigeraient un travail manuel ou un processus distinct ? Les réponses dépendent de vos contenus et de vos exigences de conservation : explicitez-les plutôt que de supposer que tous les CMS gèrent la migration de la même façon.
- Dressez la liste des contenus et des informations associées à conserver ou à déplacer.
- Testez l’exportation de plusieurs types de contenus et incluez les médias associés lorsque c’est pertinent.
- Faites examiner le résultat par les personnes responsables des futures migrations ou des archives.
- Consignez les éléments absents, ceux qui nécessitent une transformation et les personnes responsables de ce travail.
Inclure l’hébergement et la maintenance dans la décision
Un CMS auto-hébergé exige que l’organisation détermine qui est responsable des services associés, en plus de l’expérience éditoriale. Précisez qui gère le serveur et l’application, qui vérifie les sauvegardes et les procédures de restauration, qui contrôle les accès et qui décide de la façon dont la maintenance sera assurée. Une plateforme adaptée aux éditeurs peut être mal choisie si personne n’est disponible pour assumer les responsabilités opérationnelles nécessaires.
Un déploiement géré peut modifier la répartition de certaines tâches liées à l’infrastructure, sans supprimer les responsabilités du client concernant les contenus, les accès, la gouvernance ou les besoins de reprise. Airbip propose le déploiement géré d’applications de catalogue sous forme de charges de travail Docker sur ses serveurs cloud. Le routage et les certificats TLS sont automatisés par Traefik et Let’s Encrypt. Airbip fournit également des vérifications DNS, la gestion du cycle de vie des services et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Consultez le site Airbip pour les offres et conditions commerciales actuelles, et définissez comment vos exigences concernant les données, les accès et la restauration seront prises en charge.
- Attribuez les responsabilités liées à l’application et à l’infrastructure avant le lancement.
- Demandez comment les sauvegardes sont configurées et comment votre équipe pourrait vérifier une restauration.
- Déterminez qui gère les accès, les domaines, la gouvernance des contenus et les décisions en cas d’incident.
- Choisissez un modèle de déploiement adapté aux capacités opérationnelles et aux exigences de contrôle de votre équipe.
Questions fréquentes
Comment une équipe éditoriale doit-elle comparer des CMS auto-hébergés ?
Comparez les candidats à partir d’un cycle de publication représentatif, avec les exceptions qui comptent pour votre équipe. Évaluez les résultats au regard de vos critères et tenez compte des solutions de contournement, de la configuration nécessaire et des responsabilités opérationnelles.
Une équipe doit-elle choisir WordPress, Drupal ou Ghost pour ses flux éditoriaux ?
Le choix dépend de vos types de contenus, de vos rôles, de votre processus de révision et de vos exigences opérationnelles. Évaluez chaque candidat dans la version et la configuration que vous envisagez, plutôt que de vous fier uniquement à son nom ou à une liste de fonctionnalités.
Que faut-il tester dans l’aperçu d’un CMS ?
Vérifiez si les personnes chargées de la révision peuvent évaluer le contenu dans une présentation utile à leur décision, notamment sa mise en page et les contenus liés lorsque c’est pertinent. Testez aussi comment l’équipe repère les changements apportés après la révision.
Comment évaluer l’exportation des contenus avant de choisir un CMS ?
Dressez la liste des contenus et des informations associées à conserver, puis effectuez une petite exportation à partir d’éléments représentatifs. Faites examiner le résultat par les personnes responsables de la migration ou des archives et consignez les omissions ainsi que le travail manuel nécessaire.
L’hébergement géré décharge-t-il l’équipe de ses responsabilités concernant un CMS auto-hébergé ?
Non. Un déploiement géré peut prendre en charge certaines tâches d’infrastructure, mais l’organisation doit toujours décider de la façon dont ses données, ses accès, sa gouvernance et ses besoins de restauration seront gérés. Clarifiez les responsabilités avant de choisir un modèle de déploiement.
Sources et lectures complémentaires
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group