Choisir un CMS à partir du travail réel de l’équipe

Décrire ce que les personnes devront publier

Dressez la liste des contenus réels : pages de service, actualités, fiches, documents, langues et médias. Pour chaque type, précisez les champs utiles, les relations entre contenus et la fréquence de mise à jour. Une démonstration avec une page vide ne révèle pas les difficultés liées à une fiche longue, à une traduction ou à la correction d’une erreur.

Identifiez les rôles : qui rédige, qui relit, qui valide et qui publie ? Faites jouer un scénario complet à la future équipe : créer une page, enregistrer un brouillon, corriger un lien, remplacer une image et retrouver la version précédente. La gestion des droits doit suivre ces responsabilités plutôt qu’un accès administrateur partagé.

• Trois contenus représentatifs à reproduire.
• Personnes responsables de l’édition et de la validation.
• Étapes de brouillon, publication et correction.

Comparer les capacités sur un scénario identique

Faites exécuter le même travail dans les solutions comparées avec des contenus représentatifs. Exemple fictif : un rédacteur corrige une fiche traduite avec un titre long et une image ; il doit prévisualiser, soumettre ou publier selon son rôle. Relevez ce qui vient du cœur, d’une extension ou d’un développement. La recherche, les URL et les alternatives d’image doivent être examinées sur le résultat public.

Évaluez séparément la qualité du site public : vitesse, accessibilité des composants, stabilité sur mobile et maîtrise du HTML produit. Un éditeur confortable ne suffit pas si le rendu impose des pages lourdes ou empêche de corriger les défauts. Le cahier des charges aide à fixer les critères avant la démonstration.

Testez les droits avec un compte de démonstration correspondant au futur rédacteur. Dans les rôles WordPress par défaut, Author peut publier ses propres articles, mais cela ne lui donne pas publish_pages ni la modification des articles d’autrui. Contributor peut préparer ses articles sans les publier et ne reçoit pas upload_files par défaut. Une équipe qui doit corriger des pages de service ne peut donc pas choisir son rôle sur le seul mot « auteur ». Le tableau ci-dessous présente quelques capacités, pas la liste complète des permissions.

Vérifiez à la fois une opération autorisée et une opération qui doit être refusée, sur des contenus de test. La documentation distingue rôles et capacités : extensions et personnalisations peuvent les modifier ; une installation Multisite ajoute aussi des différences d’administration. Notez le type de contenu, le propriétaire de l’article et le statut du document. Un menu masqué ne démontre pas à lui seul que l’opération est interdite côté serveur. Conservez le résultat observé avec la configuration essayée, sans étendre les droits pour contourner un échec.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

Chiffrer l’exploitation et la sortie

Additionnez hébergement, abonnement éventuel, extensions, maintenance, sauvegardes, formation et temps d’édition. Pour une solution hébergée, vérifiez les limites de l’offre et la reprise des données. Pour une installation gérée par votre équipe, nommez la personne chargée des mises à jour, des dépendances et des incidents. Les coûts dépendent de l’architecture et du contrat : ne déduisez rien du seul prix d’entrée.

Demandez un export test des contenus, médias, URL et métadonnées, puis vérifiez ce qu’il permet réellement de réutiliser. Un export de textes n’est pas nécessairement une sauvegarde restaurable du site. La documentation WordPress sur l’export illustre bien cette distinction pour ce système ; adaptez le contrôle à l’outil retenu.

Comparez la sortie avec un contenu qui comporte des relations : catégorie, auteur, version linguistique et image. Relevez les identifiants conservés et la façon de retrouver les fichiers. Un texte importé sans sa catégorie ou une image encore servie par l’ancien site ne prouvent pas que la reprise est autonome.

Pour WordPress, distinguez le WXR de contenu des fichiers, du thème et des extensions. Pour un catalogue Shopify, distinguez les données produit, les adresses d’images et l’inventaire. Demandez un essai de réimport avant de choisir la solution, avec le travail de remise en forme et de configuration observé séparément.

• Coût total et responsable des mises à jour.
• Format et complétude de l’export.
• Possibilité de recréer une page hors de la solution choisie.

Décider avec des preuves conservées

Conservez les écarts observés et la personne qui accepte chaque compromis. Exemple fictif : une solution publie facilement, mais le rédacteur ne peut pas corriger une ancienne version sans assistance ; ce temps et cette dépendance doivent entrer dans la décision. Essayez une page pilote avec son circuit complet avant de reproduire le modèle. Une liste de fonctions identiques ne prouve pas une autonomie identique.

Conservez les accès et la propriété des contenus dans l’organisation, avec une procédure de transmission. À la réception, refaites les gestes quotidiens sans l’aide du prestataire : éditer, publier, revenir en arrière et exporter. Cette autonomie observable vaut davantage qu’une liste de fonctions commerciales.

Faire travailler la personne qui publiera

Pendant l’essai, demandez au futur contributeur de corriger un tarif, remplacer une image avec son alternative et programmer une publication. Notez les droits nécessaires et les erreurs récupérables. Une démonstration menée uniquement par un vendeur ne révèle pas l’autonomie réelle de l’équipe après la livraison.