CMS et blogs

Ce que couvre cette catégorie

Des systèmes pour rédiger, structurer et publier du contenu : des plateformes traditionnelles qui stockent et affichent les pages, des back-ends headless qui confient le contenu à autre chose, et des hybrides qui tentent de faire les deux sans agacer aucun des deux publics.

Les acheteurs se répartissent ici en deux camps aux besoins opposés. Une équipe marketing veut changer une page en dix minutes sans rien demander à personne. Une équipe d’ingénierie veut un contenu correctement modélisé, versionné, testable et livré par une interface. Les produits qui promettent les deux favorisent généralement l’un et tolèrent l’autre.

Les outils en glisser-déposer pour un site de quelques pages se trouvent dans créateurs de sites web. La documentation interne relève de documentation et base de connaissances.

Le modèle de contenu avant les fonctionnalités

Le modèle est la partie que l’on ne peut pas changer à bas coût plus tard.

Demandez si le contenu est stocké en champs structurés ou en un seul bloc de texte mis en forme. Les champs survivent aux refontes, alimentent plusieurs destinations et permettent de lister, filtrer et réutiliser. Un bloc ne s’affiche qu’une fois et enferme tout dans le balisage de l’éditeur qui l’a produit.

Interrogez ensuite sur les relations. Un auteur lié à ses articles, un produit lié à sa catégorie, une page liée à ses traductions : ces liens sont ce qui rend un site maintenable à deux cents pages plutôt qu’à vingt.

La réutilisation découle de la même décision. Si une mention légale, un prix ou un appel à l’action apparaît sur quarante pages, il doit exister une seule fois et être référencé, pas collé quarante fois puis corrigé trente-neuf.

L’édition, et qui la fait vraiment

Les personnes qui utilisent ce logiciel tous les jours ne sont généralement pas celles qui le choisissent.

Regardez un collègue non technique créer une page pendant l’essai. Notez où il hésite. Vérifiez s’il peut voir le résultat avant de publier, s’il peut annuler une erreur, et si l’aperçu montre le vrai design plutôt qu’une approximation.

Le circuit de validation compte dès que l’équipe dépasse deux éditeurs. Brouillons, publication programmée, étape de relecture et historique lisible de qui a changé quoi : voilà la différence entre un système et un document partagé avec un identifiant.

Publication, performances et question du référencement

Ce qui affiche le site détermine sa rapidité, et la vitesse est à la fois un critère de classement et une politesse.

Demandez à quoi ressemble le rendu. Des pages statiques reconstruites à la publication sont rapides et peu coûteuses à servir. Des pages rendues côté serveur demandent un cache que quelqu’un doit configurer. Des pages rendues côté client demandent de l’attention pour rester lisibles par les robots d’exploration.

Le reste de la préparation au référencement est sans éclat. Titres et descriptions modifiables par page. URL propres et stables. Redirections quand une URL doit changer. Gestion des URL canoniques pour tout ce qui est accessible par deux adresses. Plans de site mis à jour à la publication. Les produits qui cachent cela derrière un plugin ou une formule supérieure vous disent quelque chose de leurs priorités.

Les sites multilingues doivent tester tôt la gestion des traductions, car la greffer après coup revient presque à une refonte.

Ce que coûte l’exploitation

• Licence ou abonnement, par poste, par site ou par environnement.
• Hébergement, inclus dans les plateformes hébergées et entièrement à votre charge dans les systèmes auto-hébergés.
• Trafic et bande passante, mesurés sur de nombreuses formules hébergées.
• Builds ou rendus, comptés sur les plateformes qui reconstruisent le site à chaque modification.
• Maintenance, invisible sur la page des tarifs et bien réelle dans l’agenda.

Les systèmes auto-hébergés paraissent gratuits et ne le sont pas. Mises à jour, conflits de plugins, correctifs de sécurité et sauvegardes sont le travail hebdomadaire de quelqu’un, et ce travail a un salaire. Les plateformes hébergées déplacent le même travail dans la facture, où il est au moins facile à comparer.

Lisez le marché des extensions avant de décider. Un noyau bon marché avec quatre modules payants est un produit de gamme moyenne déguisé, et ce que cachent les pages de tarifs contient d’autres calculs de ce genre.

Migration, et la partie qui coûte du trafic

Passer d’un système de contenu à un autre est une opération connue, sauf sur un point : les adresses.

Le contenu s’exporte généralement sous une forme ou une autre et s’importe avec effort. Ce qui casse une migration, c’est de changer les URL sans redirections. Les moteurs de recherche et tous les liens jamais faits pointent encore vers les anciennes.

Prévoyez cela avant de choisir une plateforme. Listez chaque adresse publiée, décidez lesquelles survivent et associez les autres à leur remplaçante. Une table de redirections construite pendant le projet prend quelques heures. Reconstruite après coup à partir d’un rapport de liens cassés, elle prend des semaines, et le trafic baisse pendant tout ce temps.

Vérifiez aussi les autres détails hérités : gestion des images, données structurées, flux, et tout ce qui est intégré dans les anciennes pages et que le nouveau système affichera différemment ou pas du tout.