CMS, définition des besoins

Rapide définition des besoins, sorte d’inventaire des tests à réaliser, pour la sélection d’un CMS, si tant est possible de n’en choisir qu’un. Dans la vraie vie, entre le client/ami qui a son point de vue, son ouverture d’esprit, ou tout simplement une volonté farouche de progresser dans un vrai monde Web 2.0, sans parler de l’architecture serveur parfois maintenue par un aficionado du todo.txt-mais-pas-plus, dans cette vraie vie, bien souvent, on installe ce qui est demandé.

Ceci n’est pas un cahier des charges, ni l’ombre d’un cahier des charges. Ce mémo est juste là pour donner quelques pointeurs.

Test et validation

Tester un CMS demande plusieurs jours/homme, et une bonne connaissance du système informatique, Internet.

Un sens de l’organisation sera un plus. L’outil sélectionné pour un site maintenu par un seul webmaster qui n’a en charge que le contenu n’est pas forcément celui qui conviendra à une équipe de modérateurs exigeants.

Le métier de l’entreprise peut également pondérer la décision.

Et comme tout a un coût...

Le test comparatif est limité :

• dans le temps : 1 à 2 jours max par outil
• dans l’environnement : Open Source, Apache, Mysql pour rester dans les grands standards. GPL ou dans le genre.
• dans ses outils : XHTML, CSS, Javascript. PHP pour sa maintenance.

Le scénario :

• Installation
  • En combien d’étapes ?
  • Tout ou partie en ligne, via interface web ?
• Simplicité de la publication d’un article
  • et de sa correction
  • avec illustration visuelle (photo, vidéo) et sonore
• Accessibilité de la partie publique, le front-office
• Accessibilité de la partie administrative, le back-office

En complément, et en vrac :

• Ajout de commentaires aux articles avec ou sans modération ?
  • Avec anti-spam ?
• Disponibilité de thèmes (structure de page et habillage) ?
• Widgets, plugins, extensions (pour quelles fonctionnalités) ?
• Adaptabilité, création de formulaires avec si possible MVC ?
• Flux RSS, sitemap et autres robots.txt (pour lecteurs et SEO) ?
• Quid de la communauté de développeurs/mainteneurs ?
• Localisation par compte, globale, front-office et/ou back-office ?
• Gestion de comptes utilisateurs (visiteur, rédacteur, correcteur, traducteur, éditeur, administrateur) ?
• Optimisation technique, temps de réponse, gestion du cache tout en permettant les blocs dynamiques ?

Accessibilité

Au sens WAI du terme, rendre accessible un site ne se limite pas à sa partie publiée, le front-office. La partie administrative, le back-office, doit aussi être accessible.

En termes plus larges, optimiser l’accessibilité d’un site web signifie optimiser pour :

• sa lecture. Un texte mal écrit n’est pas accessible. Une armada de bannières, une fenêtre surgissante, une image animée qui n’apporte rien au contenu recherché sont autant d’éléments qui rendent l’information inaccessible ;
• sa « navigation » entre les pages. Aussi bien le menu éponyme que l’éventuel fil d’Ariane, ce petit lien qui vous indique dans quelle rubrique est situé l’article que vous êtes en train de lire ;
• le tout aussi bien pour l’être humain que :
  • pour le robot des moteurs et annuaires ;
  • les téléphones mobiles, que le français appelle portables.

Les outils envisagés

DotClear, Drupal, EzPublish, Joomla !, SPIP, Typo3, WordPress, Xoops.

D’autres à piocher, peut-être, dans la Liste de systèmes de gestion de contenu disponible sur Wikipedia.

Les études comparatives

Glanés çà et là :

• Les chefs de file du marché (décembre 2010)
• Drupal et mySQL sont sur un serveur..., (2008, mais forums actifs 2010). Plus un comparatif Drupal/SPIP. Très long. Très intéressant.
• [Comparatif] DotClear ou Wordpress, lequel choisir ? (avril 2009)
• Petit comparatif Joomla ! Drupal (novembre 2008). Comportement et fonctionnalités.
• Quel CMS pour mon projet WEB ? (janvier 2008). Long, mais très intéressant.

Il en existe bien d’autres. Attention à ne pas tenir compte des billets périmés. Plus de deux ans dans ce domaine, c’est souvent perdre son temps. Ce qui sous-entend que ce billet lui-même a une durée de vie de, disons, 18 mois. Probablement moins.

Popularité des CMS

Faute d’avoir mieux, voici peut-être un indicateur : l’indice de popularité basé sur les recherches effectuées sur le grand Google.

France :

Monde :