Baptiste Autin

• Une architecture web-XML
• Structure du site

• Un projet open-source dont je suis responsable : PHP_UML

Les systèmes de gestion de contenu

Pourquoi des CMS ?

Les systèmes de gestion de contenu (CMS : Content Management System) sont liés au développement rapide de la nouvelle « société de l'information ».
Plus précisément, ils sont nés :

• du besoin pour les entreprises et les individus de disposer d'outils pour gérer, de façon autonome, leurs contenus numériques (dont le volume va croissant)
• de la nécessité de publier rapidement de l'information sur Internet (un besoin qui était d'ailleurs à l'origine même de l'invention du web)
• de la volonté de réintroduire du collectif dans le travail en entreprise, et d'atténuer l'isolement causé par l'utilisation généralisée des ordinateurs : c'est le travail collaboratif.

De quoi sont-ils faits ?
Au sens large, un CMS comporte trois niveaux :

• un niveau accessibilité
• un niveau stockage
• un niveau métier

L'accessibilité renvoie aux interfaces grâce auxquelles l'utilisateur communique avec le CMS. Autrefois appelées « écrans » (dans le vieux jargon client-serveur), ces interfaces sont aujourd'hui de simples pages Internet.

Le niveau stockage, c'est la base de données : une base de données relationnelle (Oracle, MySQL...), une base documentaire propriétaire (Zope), un entrepôt XML, voire de simples fichiers texte.

Le niveau métier, ce sont tous les traitements que le CMS peut opérer avec les données, et qui sont spécifiques à l'application. Outre bien sûr la possibilité de créer et d'éditer une information, une des fonctionnalités les plus appréciées est la recherche, qui permet de retrouver une information précise dans la base, ou encore la possibilité de hiérarchiser les utilisateurs en fonction de profils, avec des droits définis, et de permettre ainsi la modération des contenus.
Grâce à la notion d'extension (ou de plugin), il est possible de greffer au système des fonctionnalités complémentaires (gestion de newsletters, commerce électronique, forum, agenda partagé, connectivité LDAP, etc.)

Remarquons que le terme de CMS peut aussi bien désigner bien un système de publication de pages web, qu'un portail de travail collaboratif : il se situe autant sur le versant internet que sur le versant intranet.
Les applications de GED (gestion électronique de documents) qui permettent de gérer avec une seule infrastructure des documents hétérogènes et, le cas échéant, non structurés (pages HTML, documents PDF, Word, images...) sont aussi considérées comme des CMS.

Cas d'utilisation

Je peux distinguer personnellement deux cas d'utilisation :

• Cas 1 : On est une entreprise, ou un particulier, et on souhaite disposer d'un outil pour publier, ou gérer simplement de l'information, sans le recours à un prestataire Internet
• Cas 2 : On est une agence web, et on veut optimiser le temps passé à développer des sites pour ses clients

Cas 1 : Cas d'une entreprise qui souhaite gérer son contenu

Si l'objectif de l'entreprise est de publier des données temporaires, condamnées à être détruites à terme, le CMS en mode blog est idéal. Wordpress, par exemple, est tout à fait adapté à ce type d'utilisation.

Mais si les données publiées ont une valeur métier pour l'entreprise (une base de données produit par exemple) alors un CMS « clef en main » ne sera peut-être pas la bonne solution, en tout cas, on ne faudra pas écarter l'hypothèse d'un développement spécifique. Les content management systems enregistrent en effet leurs données sans autre logique que la logique documentaire qui leur est propre. Le jour où l'entreprise devra exploiter ces contenus autrement, pour les mettre à la disposition d'un autre système par exemple, ou bien pour migrer vers un autre CMS, comment fera-t-elle, si rien n'a été prévu par le système ? Et ne parlons pas du cas, fréquent, de ces entreprises dont les données proviennent d'un système tiers (une base SQL, un entrepôt SAS, une application métier, un flux XML), qu'elles souhaitent intégrer dans leur outil de publication Internet.

Du coup, je crois que ces mêmes organisations qui veulent gagner en autonomie seront finalement contraintes, non sans un certain paradoxe, à faire appel à un prestataire extérieur, qui, après audit, leur installera un CMS (soit un système développé sur mesure, soit un outil du marché, sous licence commerciale) avec, le plus souvent, un contrat de maintenance à la clef...

Cas 2 : Cas d'une agence web

Les agences web ont d'abord vu dans les CMS l'occasion de réduire leurs coûts de production, dans un secteur particulièrement concurrentiel. A quoi bon développer sans arrêt les mêmes interfaces de gestion, les mêmes modules de newsletters, les mêmes forums ?
Pour les entreprises qui avaient rencontré des difficultés à mettre sur pied une plateforme efficace de développement (mutualisation des procédures, patterns, programmation objet...), on peut penser que les CMS ont eu un effet bénéfique sur elles, en les aidant à rationaliser leur système de production.

Je crois cependant qu'il faut souligner un certain nombre de choses :

• sur le terrain économique d'abord
  Il faut un certain temps pour maîtriser un CMS, d'où un investissement initial en temps de formation, dont il n'est pas dit qu'il sera rapidement rentabilisé, surtout si le système choisi s'avère inadapté par rapport aux besoins de l'entreprise, ou du projet. Par ailleurs, le temps passé à adapter un CMS à la charte graphique et aux fonctionnalités définies par le cahier des charges peut s'avérer assez lourd, tant et si bien que le gain global n'est pas, selon moi, si important que cela pour les agences web, par rapport à un développement spécifique bien rôdé. Le gain est surtout organisationnel : les CMS ont contraint les agences à mieux gérer leur briques logicielles, et à améliorer leur approche qualité.
• sur le versant RH :
  Si une agence fait le choix de se spécialiser sur un certain CMS (choix qui se défend, vu la complexité de mise en oeuvre de ces systèmes), elle prend le risque de ne pas réussir à trouver les bons développeurs qui vont avec. Il faut d'ailleurs remarquer qu'on n'enseigne pas tel ou tel CMS à l'école : ils sont tellement nombreux, différents et versatiles, qu'il est vain de vouloir intégrer leur enseignement dans un programme scolaire. Alors qu'en sera-t-il dans 3 ou 4 ans, lorsqu'il faudra faire évoluer des sites écrits avec des systèmes en déclin ?
• enfin sur l'aspect technique
  Un CMS repose sur la conception de gabarits (ou templates) ainsi que sur la définition d'une typologie de contenus. A cet égard, Typo3 possède un système assez fouillé par exemple. Mais plus un CMS est souple dans sa gestion des gabarits et des types de données, plus son langage de templating est complexe.
  Or n'y a-t-il pas, dans ce foisonnement de procédures, de syntaxes et de langages propres à chaque CMS, une contradiction essentielle avec la tendance à la standardisation et à la normalisation qui a cours aujourd'hui sur le web ?
  Que les CMS produisent du code XHTML « propre » sur le frontend est une chose, qu'ils soient eux-mêmes écrits en faisant appel aux standards en est une autre...
  Franchement, on peut s'interroger sur l'avenir de tous ces langages, du DTML de Zope au TypoScript de Typo3, des squelettes de SPIP au moteur de template Smarty, des curly brackets de ezPublish à la librairie PHP vlibTemplate, dans un monde qui rêve (enfin) d'interopérabilité...
  On se croirait revenu à la guéguerre Microsoft/Netscape, lorsque chacun cherchait, indépendamment de ce que faisait son concurrent, à développer son propre système, sa propre approche, sa propre école, convaincu d'être le meilleur...
  Mais je crois que les lois du marché feront leur office, et l'offre se restreindra de nouveau.
  J'ignore quel système parviendra à s'imposer, mais mon petit doigt me dit que les techniques de transformation XSL, que j'ai exposées dans mon article précédent, utilisées par exemple dans des CMS encore en développement (comme Apache Lenya) joueront un rôle clef. Les possibilités de connectivité XML seront, elles aussi, décisives.

En attendant, il faut faire avec ce que l'on a. A savoir, choisir entre :

• un CMS riche et puissant, couvrant le maximum de fonctionnalités, et ne nécessitant que le minimum de développement spécifique
• un CMS léger (la mode actuellement), pour une prise en main quasi-immédiate, faisant l'économie du développement du backend, et laissant une plus grande latitude dans la manière de développer le frontend.

Au jour d'aujourd'hui, j'ignore quelle est la solution la plus économique pour une entreprise, même si je suis spontanément attiré vers la seconde option : des outils simples et légers.
On voit d'ailleurs apparaître des systèmes « sans base de données » stockant les contenus directement dans une page XHTML, ce qui me semble parfaitement logique (a priori un document hyper-structuré n'a pas grand chose à faire dans une base de données relationnelle) mais ces systèmes restent encore à améliorer.

Conclusion

J'ai eu personnellement à intégrer et/ou utiliser différents systèmes : Typo3 (à Préférences en 2004), Plone/Zope (à Cardinal-Systems en 2006), SPIP (en 2006), Wordpress (en 2006).
Mon retour d'expérience est contrasté, vous l'avez compris, et je crois que les content management systems n'ont toujours pas atteint le stade de la maturité, malgré le besoin que nous avons d'eux.
L'air est aux standards ouverts, pas aux coquilles closes qui n'interopèrent qu'avec elles-mêmes, et, de ce point de vue là, les CMS actuels doivent encore s'améliorer.