Les CMS (Content Management System) permettent d'organiser, créer, modifier, supprimer, publier/dépublier des documents. Pour résumer, ils servent à gérer et manipuler une collection de documents. Il en existe une multitude comme le montre la liste mise au point par Karl Dubost ou encore le site de comparaison des CMS CMSMatrix. Certains sont spécialisés, comme Dotclear pour les blogs, Spip pour les e-zines, Lodel pour l'édition électronique ou Mediawiki pour les wikis. D'autres sont plus généralistes comme EzPublish, Joomla ou Nucleus. Ils utilisent des technologies différentes : PHP, Python, Perl ou JSP et possèdent des moyens différents de stocker l'information : bases de données relationnelles (MySQL pour beaucoup d'entre eux), fichiers XML voire même des fichiers textes. Il y en a donc pour tous les goûts et chacun peut faire son marché. Malgré tout, on peut identifier quatre problèmes que posent régulièrement les CMS :

• Gérer facilement tous types d'informations avec un seul CMS. En effet, une des limitations de la plupart des CMS repose sur l'impossibilité d'ajouter des informations précises et ainsi de modéliser à l'intérieur d'un même CMS des types d'informations différentes. Ainsi, l'utilisateur est souvent prisonnier de la modélisation du logiciel et ajouter une information signifie bien souvent la modification du code du logiciel. Les plugins peuvent éventuellement pallier ce défaut comme dans Dotclear, mais l'organisation de l'information n'est pas alors pensée de façon globale à l'échelle du site ce qui peut se révéler ennuyeux pour la maintenance et la conservation des informations

• Échanger et lier des informations. Même si les trackbacks et la syndication par fil RSS/ATOM permettent d'afficher des informations issues d'un site sur un autre, la liaison des informations reste encore trop partielle, ainsi les CMS sont souvent des vases clos qui ont du mal à communiquer avec l'extérieur. Par exemple, si vous possédez un fichier FOAF, pourquoi aucun CMS ne récupère directement les informations déjà présentes dans ce fichier, obligeant les utilisateurs à saisir à nouveau ces informations ? Un autre exemple, si on met en place une indexation du contenu ou la possibilité de « tagger » les informations, il serait intéressant de récupérer automatiquement des vocabulaires contrôlés comme des thésaurus basés sur SKOS ou de façon plus modeste de simplement récupérer automatiquement les tags d'un delicious ou de technorati. De la même façon, peu de CMS offrent des moyens avancés d'interopérabilité à part les fils de syndication et éventuellement le fichier FOAF1.

• Gérer les droits des utilisateurs. De la même façon que la modélisation de l'information est souvent figée, les droits des utilisateurs reposent souvent sur des modèles pré-conçus par les concepteurs qui sont impossible à modifier. Ainsi, très peu de CMS intègrent une logique de Workflow adaptable par les administrateurs/utilisateurs du CMS.

• L'organisation hiérarchique de l'information. La logique du papier est encore très visible dans la conception des CMS (comme dans toute les applications informatiques d'ailleurs), ainsi les documents sont souvent organisés de manière hiérarchique avec des répertoires, des catégories, des chapitres, des rubriques... Aucun CMS à ma connaissance ne permet d'organiser l'information de manière hypertextuelle et de naviguer avec des interfaces à facettes aussi bien dans l'interface d'administration (backoffice pour les intimes ;-) ) que sur le site.

Certains CMS implémentent des solutions qui répondent en partie aux quatre problèmes soulevés. Pour ne prendre qu'un exemple que je connais bien, lodel permet de modéliser facilement des types d'informations complètement différentes et de les organiser entre eux grâce au principe du modèle éditorial. Pourtant, une des limitations principales de ces CMS repose sur le choix de stockage des informations : la base de données relationnelle. Pour revenir à lodel, la mise en place du modèle éditorial2 a demandé l'ajout d'une couche au modèle relationnel de la base de données. Et, pour faire vite, on a utilisé un système qui n'était pas fait pour et qui, de fait, montre ces limites quand vous voulez avoir une granularité un peu plus poussée dans vos documents ou alors que vous voulez y agréger des modélisations existantes.

Un des moyens de pallier à ce défaut et certainement aussi de répondre aux autres problèmes posés serait de baser l'organisation du CMS sur la syntaxe RDF. Ainsi, un premier fichier RDF basé sur une ontologie en OWL pourrait décrire la modélisation et l'organisation des informations présentes sur le site. Chaque document pourrait se composer d'un fichier RDF regroupant les métadonnées (basées sur Dublin Core) et un fichier XML pour structurer les données (voire même plusieurs si vous voulez gérer le versionning de vos documents). Les informations concernant les utilisateurs pourraient être décrites dans un fichier basé sur FOAF et intégrant aussi le système d'ACL en RDF que le W3C a commencé à développer. La carte de structure hypertextuelle du site pourrait avantageusement être indiquée dans un autre fichier RDF (dont le schéma serait issu de METS ?). Et, il serait alors possible d'importer un schéma RDF particulier dont le logiciel intégrerait l'organisation pour proposer automatiquement des formulaires adéquats. Et pour finir, le système d'index/tags/étiquettes (appelez cela comme vous voulez) serait sous la forme d'un fichier SKOS. Evidemment, l'ensemble de ces fichiers pourraient être accessibles dans un souci d'interopérabilité : votre thesaurus en SKOS, votre fichier FOAF, votre contenu en RSS, votre modèle éditorial en OWL...

Oui, tout cela est joli, MAIS, car il y a un problème : pour qui ? pour quoi ? avec qui faire ce logiciel ? Cela fait deux semaines qu'on se documente avec Ghislain et Luc qui m'accompagnent dans cette réflexion. Il nous semble intéressant de partir dans cette direction, de se baser sur les technologies du Web sémantique qui semblent adaptées à nos besoins. Mais, un logiciel de ce type impose des contraintes lourdes :

• Quid du système de template ? La question récente d'Olivier Meunier sur son blog nous montre qu'il est difficile de faire l'impasse sur cette question ? XSLT serait la première réponse, mais le public est tout de suite plus restreint ;

• Quid du langage de requête ? SQL a le mérite d'être assez simple et connu, le système de boucles dans spip ou dans le lodelscript montre qu'il est assez aisé de développer un système permettant de donner accès au SQL sans en apprendre précisément la syntaxe, mais pouvons-nous faire la même chose avec RDQL ou SPARQL pour interroger les fichiers RDF ou même Xquery pour les fichiers XML ? Cette question recoupe finalement la question précédente : quel public et pour quoi faire ?

Bref, avant d'aller plus loin, il nous semble important de préciser le public visé, les besoins et donc les choix technologiques, alors si parmi mes quelques lecteurs, certains auraient des idées ou même seraient intéressés par ce projet, n'hésitez pas à m'envoyer un petit mail (oui, je sais, ce serait plus pratique avec les commentaires, mais c'est ainsi, ce sera le mail ;-) ).

Quelques notes en passant

1 D'après ce que j'ai pu voir, une telle fonctionnalité est offerte par Movable Type et par la plate-forme de blog Viabloga.

2 Si vous voulez une explication précise du principe du modèle éditorial dans Lodel, vous pouvez relire le commentaire que j'avais laissé sur le billet de Manue consacré aux FRBR : http://figoblog.org/document594.php.