Mon-Opquast, blogs et CMS

Par Élie Sloïm, le 25 avril 2006, dans .

Parmi les bientôt 5000 utilisateurs Mon-Opquast, nous avons quelquefois des remarques et soutiens de la part de créateurs de systèmes de gestion de contenu (CMS). Nous avons notamment eu des retours de la part de membres de l’équipe Joomla, Mambo, Dotclear et quelques autres.

Il se trouve qu’en termes de qualité Web, les systèmes de gestion de contenu ont pour principal de effet de déplacer une partie souvent importante de la qualité Web de l’utilisateur vers le système de gestion de contenu en lui-même. Lorsque l’on crée des sites statiques en HTML, ce qui devient de plus en plus rare, la quantité d’éléments à maîtriser est considérable, notamment en ce qui concerne la structure des pages, l’accessibilité, la conformité, les menus, le fil d’Ariane, etc.

Dès lors qu’on utilise un système de gestion de contenu, du plus simple au plus complexe, une grande partie de ces questions sont déplacées et ne sont plus entre les mains de l’utilisateur du système qui passe du statut de webmaster du site à celui de responsable éditorial, voire de contributeur de son propre site.

C’est la raison pour laquelle il peut s’avérer intéressant de vérifier la conformité non plus d’un site en cours de production, mais d’un système de gestion de contenu (blog, wiki, publication d’articles, module de forum, etc.), et ce même avant que le moindre contenu n’y ait été ajouté.

Ce travail de vérification en amont a été effectué pour l’outil de création de blogs Dotclear par Franck Paul, un utilisateur Mon-Opquast que nous ne connaissions pas jusqu’à maintenant. Et c’est à tout à fait passionnant, car cela permet de juger de la quantité de travail qui reste de la responsabilité des utilisateurs après avoir installé l’outil.

Autrement dit, si l’on avait à comparer ce type de résultats pour plusieurs systèmes de blogs ou de gestion de contenu, nous pourrions obtenir une vue globale du niveau de qualité intrinsèque de chaque outil au regard des bonnes pratiques Opquast. Cela ne nous dirait pas tout sur la qualité réelle de l’outil, mais tout de même, cela nous montrerait que tous les systèmes de gestion de contenu ne sont pas forcément égaux et qu’à toute bonne pratique traitée à la source par les développeurs de l’outil correspond un travail de moins pour les utilisateurs de cet outil.

Je vous laisse consulter le travail considérable qu’a effectué Franck, et je tiens vraiment à le remercier à la fois pour ce qu’il a fait là, mais aussi pour les idées qu’il a fait germer dans ma petite tête 😉

Si vous avez envie de reproduire le test pour d’autres outils, je pense qu’il pourrait être intéressant d’ouvrir un compte Opquast dédié, qui contiendrait des déclarations qualité pour les principaux outils de gestion de contenu. S’il y a des volontaires pour lancer ce genre de tests, nous ouvrons un compte dédié, permettant de tester plusieurs sites en mode multi-utilisateur, et je crée les utilisateurs en fonction de vos retours. Par la suite, nous testons des outils « bruts de décoffrage » et nous publions les déclarations qualité.

A mon humble avis, celles-ci pourraient être très intéressantes pour toute personne qui se trouve en position de choisir un CMS ou un outil de blogs. J’attends vos commentaires ou votre avis sur la question.

Si ça c’est pas du Web 2.0 😉

A bientôt
Elie Sloïm

7 commentaire(s)

  1. Bonjour,

    Suite à différentes lectures qui mon interpelées[1], je souhaiterai participer à une étude sur la qualité du CMS SPIP.
    En effet, l’association où je travail utilise principalement SPIP pour réaliser des sites dynamiques. Valider SPIP à l’aide des bonnes pratiques d’Opquast permettrait de mettre en lumière les différents points a améliorer et de se fait les communiquer ensuite aux developpeurs de SPIP.

    Concient que mes compétences sur l’accessibilité et la qualité des sites web sont loin d’être parfaite, il me sera difficile de réaliser un étude aussi précise que celle produite par Frank Paul. Mais, j’essairai d’être le plus précis possible dans cette démarche.

    Quelqu’un souhaiterai t’il se joindre à moi ?

    [1]
    http://www.opquast.com/dotclear/... (ce billet)
    list.accessiweb.org/piper… (post sur la liste accessibilité numérique)

  2. Le problème avec SPIP, c’est que le squelette à une influence considérable sur le résultat final…

    Il faudrait donc tester non pas SPIP, mais toute une série de squelettes…

  3. Débat intéressant ! Comme le souligne Franck dans son billet, la conformité du code – produit par un CMS qui offre une séparation claire entre contenu et présentation, prend en compte les standards et l’accessibilité – est accessible moyennant un peu de travail. C’est apparemement le cas de Dotclear, mais je pense qu’on peut penser que Textpattern, Drupal ou MODx sont également susceptibles d’être rapidement conformes aux bonnes pratiques.

    De mon côté, puisque je fais partie de l’équipe officielle, je soumettrai l’idée à l’équipe de dév. Avant ça, j’essaierai de tester les sites que j’ai conçu sous MODx (modxcms.com/forums/index…. voir aussi l’article que j’ai rédigé pour Framasoft, en français : http://www.framasoft.net/article... mais je suis plutôt optimiste 🙂

    Concernant la remarque au sujet des templates/gabarits (chez SPIP on dit squelette) : une bonne base de test est de prendre le template par défaut de l’application.

    La préoccupation principale, pour une application web, ce sont les extensions (plugin, modules ou autre…). Elles sont quasiment systématiquement utilisées, ce qui souligne l’importance d’une API bien écrite, et de template de plugin eux-aussi bien conçus. Ca complique très largement la tâche !

  4. Olivier nous fait une vrai remarque.
    J’ai touché a SPIP également il y a quelques temps, et nul doute que les test ne doivent pas etre que superficiels !

Les commentaires sont fermés.