Choisir un CMS pour un projet client : les questions à poser avant la démo
Les tableaux de fonctionnalités sont la pire façon de choisir un CMS pour du travail client. Douze questions qui prédisent le comportement d'un outil la deuxième année, et à quoi ressemble une bonne réponse.
Les tableaux de fonctionnalités sont une mauvaise façon de choisir un CMS pour du travail client. Tout outil sérieux propose du texte enrichi, des médias, des rôles et une API : le tableau ressort à égalité, et vous choisissez sur le prix ou sur la démonstration la plus léchée.
Ce qui différencie réellement ces outils, c’est leur comportement la deuxième année : quand le collègue du client est parti, quand le modèle doit changer, quand une construction échoue un vendredi, quand vous avez quinze sites au lieu d’un.
Voici les douze questions qui prédisent cela, et à quoi ressemble une bonne réponse. Elles se posent avant la démonstration, parce qu’une démonstration est conçue pour répondre à d’autres questions.
L’argent
1. Combien ça coûte à mon vrai nombre de sites ?
Pas par site : au total, à quinze ou vingt, avec deux éditeurs et deux langues chacun. Les éditeurs tarifent pour une entreprise à un site web, et le calcul change de nature quand on multiplie.
Une bonne réponse est un nombre que vous pouvez calculer vous-même depuis la page de tarifs. Une mauvaise réponse demande un rendez-vous commercial.
2. Combien coûte un éditeur de plus ?
Si la réponse n’est pas zéro, faites le calcul à quarante éditeurs, parce que le nombre d’éditeurs d’une agence croît avec chaque client. La facturation au siège vous pousse à partager un identifiant entre plusieurs personnes, ce qui détruit votre journal d’activité précisément quand vous en avez besoin.
3. Combien coûte une langue de plus ?
En Europe, ça compte plus qu’on ne le croit. Certains éditeurs facturent vingt dollars par mois et par langue supplémentaire, par site, indéfiniment. Un site vitrine trilingue peut coûter plus cher en suppléments de langue qu’un abonnement de parc entier ailleurs.
Le client
4. De quoi mon client a-t-il besoin pour se connecter ?
Une adresse email est la bonne réponse. Un compte GitHub est un appel au support, à chaque fois, indéfiniment. Tout ce qui suppose une identité sur une plateforme de développeurs produira de la confusion au moment exact où le client est déjà agacé.
5. Combien d’écrans peut-il atteindre alors qu’il ne devrait pas ?
Chaque réglage qu’un client peut voir est une question qu’il pourra vous poser plus tard, et une chose qu’il peut casser pendant vos vacances. Demandez à voir la vue de l’éditeur, pas celle de l’administrateur.
6. Que voit-il après avoir cliqué sur Publier ?
La question la plus révélatrice de cette liste. Si la réponse est une confirmation signifiant « enregistré », le client croira sa modification en ligne alors qu’elle peut ne pas l’être, et il l’apprendra par un client à lui. Si la réponse nomme un état et une heure, quelqu’un a fait le travail ingrat de suivre le déploiement.
Le modèle
7. Le modèle de contenu peut-il vivre sous gestion de version ?
Un modèle cliqué dans une administration ne se compare pas, ne se relit pas, ne se branche pas et ne se copie pas vers le site seize. Un modèle dans un fichier, si. Pour un site c’est de l’esthétique ; sur un parc, c’est la différence entre un après-midi et une semaine par nouveau projet.
8. Que se passe-t-il si je renomme un champ contenant des données ?
Demandez à le voir. Le bon comportement est de détecter le changement destructeur et de refuser de l’appliquer en silence. « Les anciennes données ont disparu » est rédhibitoire, et vous ne le découvrirez qu’après que c’est arrivé à un client.
9. Montrez-moi l’export, maintenant.
Pas une description : la commande réelle, sur l’offre gratuite, et regardons ce qui en sort. Du markdown et du JSON à une forme que votre outil suivant sait lire, c’est une sortie. Un export maison, non.
Cette question compte d’autant plus que votre parc grandit, parce que migrer vingt sites est un chantier que personne ne financera, ce qui veut dire que le jour où le prix monte, vous le paierez.
L’exploitation
10. Que se passe-t-il si je demande la ressource d’un autre client par son identifiant ?
La bonne réponse est 404, partout. Un 403 confirme que la ressource existe, ce qui, sur un parc de clients, veut dire que votre client peut découvrir avec qui d’autre vous travaillez.
11. D’où la construction lit-elle le contenu, et que se passe-t-il pendant une panne ?
Si la construction appelle l’API vivante de l’éditeur, son mauvais après-midi devient votre déploiement raté. Si elle lit un instantané immuable depuis un CDN, une panne n’a aucune importance pour le site de votre client. Demandez s’ils l’ont réellement testé, pas si ça devrait marcher.
12. Qui est derrière, et que se passe-t-il s’ils arrêtent ?
Pour de l’open source : combien de mainteneurs, quelle est la dernière version, existe-t-il une offre payante qui finance. Pour de l’hébergé : comment sont-ils financés, depuis quand existent-ils, à quoi ressemble l’export. Aucune de ces réponses n’est éliminatoire en soi. Ne pas savoir, si.
Trois questions qui ne valent pas la peine
Pour l’équilibre, voici trois choses qu’on évalue souvent et qui prédisent très peu.
« A-t-il un éditeur visuel ? » Ça paraît décisif et ça l’est rarement, parce que la vraie question dessous est de savoir si votre client compose des pages ou remplit des champs. Un client qui change un tarif et une photo quatre fois par an ne tire aucune valeur d’un éditeur visuel et le paiera tous les mois. Une équipe marketing qui assemble des pages d’atterrissage en tire énormément. Déterminez lequel des deux vous avez avant de pondérer ce critère.
« Combien d’intégrations propose-t-il ? » Une longue liste d’intégrations est un artefact de communication. Pour un site vitrine, il vous en faut exactement une : votre framework. Un CMS avec deux cents intégrations et un loader Astro médiocre vaut moins qu’un CMS avec un seul loader excellent.
« Est-ce open source ? » Question réellement importante pour certains clients et sans objet pour la plupart, et régulièrement utilisée comme substitut à « puis-je faire confiance », ce qu’elle n’est pas. L’open source ne vous protège de la disparition d’un éditeur que si vous pouvez réellement le faire tourner vous-même, ce qui, pour un parc de vingt sites, veut dire exploiter vingt instances. Demandez plutôt l’export : c’est ce qui protège réellement, et cela vaut pour les produits ouverts comme fermés.
À quoi ressemble une bonne réponse
Sur les douze, le motif d’une réponse digne de confiance est le même : précise, vérifiable, et prête à nommer une limite.
« Publier prend une à trois minutes parce qu’il y a une construction, et l’interface montre la progression » est une bonne réponse. « Publier est instantané » est une mauvaise réponse pour un site statique, parce que c’est faux et que vous découvrirez comment.
Méfiez-vous de tout éditeur, nous compris, qui répond aux douze sans rien concéder. Chacun de ces outils est mauvais à quelque chose, et ceux qui refusent de dire quoi sont ceux qui vous surprendront.
Nos propres réponses, y compris les gênantes
Puisque c’est notre blog, voici les nôtres, brièvement.
Le coût est par site, éditeurs et langues illimités dès le premier plan payant. Les clients se connectent avec une adresse email. Il n’y a aucun écran de réglages pour un éditeur. Après Publier, il voit une progression finissant par en ligne à telle heure. Le modèle est du TypeScript dans votre dépôt. Les changements de schéma destructeurs sont détectés et refusés plutôt qu’appliqués. L’export est une commande, sur tous les plans y compris le gratuit, produisant du markdown et du JSON au format des content collections. Les requêtes vers un autre client renvoient 404. Les constructions lisent un instantané immuable sur un CDN, et nous le vérifions en coupant notre API.
Et les limites, parce que la section précédente les exige : publier prend une à trois minutes. Il n’y a pas de constructeur de pages visuel. Il n’y a pas d’API de contenu à la requête. Il n’existe pas de version auto-hébergée. Nous prenons en charge Astro et rien d’autre. Nous sommes une petite équipe sur un produit jeune, ce qui est un risque réel à intégrer, et la raison pour laquelle la question de l’export est celle qu’il faut nous poser le plus durement.
La démonstration elle-même, et comment la mener
Si un outil survit aux questions, la démonstration mérite d’être menée plutôt que subie.
Amenez votre propre projet. Demandez à modéliser une vraie collection d’un vrai site client, avec ses vrais champs et son champ pénible. Tous les CMS se démontrent magnifiquement sur un article de blog avec un titre et un corps. Le comportement intéressant apparaît sur le champ qui ne rentre pas.
Demandez la vue de l’éditeur, pas celle de l’administrateur. Les éditeurs démontrent l’interface d’administration, celle que vous utiliserez deux fois par mois. Votre client, lui, vit dans la vue d’édition, et sur plusieurs produits elle est visiblement moins soignée.
Cassez quelque chose exprès. Publiez avec un champ obligatoire vide. Envoyez une photo HEIC d’iPhone. Supprimez une image utilisée par une page en ligne. Les messages d’erreur obtenus prédisent mieux la deuxième année que n’importe quelle fonctionnalité.
Chronométrez la publication. Mesurez, et demandez ce que voit l’éditeur pendant qu’il attend.
Une demi-heure passée ainsi vous apprend plus qu’une semaine de lecture de documentation, et c’est la seule partie de l’évaluation qu’on ne peut pas faire depuis une page de tarifs.
Comment se servir de cette liste
Imprimez-la, ou gardez-la dans une note. Posez les questions 1, 6 et 9 avant même de réserver une démonstration, parce qu’elles éliminent la plupart des options en dix minutes et ne mobilisent que votre temps.
Les neuf autres méritent d’être passées en revue avec un vrai projet en tête plutôt que dans l’abstrait. Et si vous voulez la version par éditeur, les comparatifs passent en revue Contentful, Strapi, Sanity, Storyblok, Directus et la famille des CMS git, chacun avec les cas où il est le meilleur choix.