Les tendances du marché

Le marché des CMS [1] est en continuel mouvement. Depuis le début des années 2000, les fusions et les rachats se succèdent, laissant place à de nouveaux acteurs (éditeurs locaux ou solutions Open Source) qui prennent pied, peu à peu, dans la cour des grands.

On peut classer les outils de gestion de contenu selon quatre axes principaux :

• Axe "Présence géographique" : on distingue les solutions dites "locales" (présentes presque uniquement sur le marché français, ou francophone) et les solutions "globales" (présente pratiquement partout dans le monde).
• Axe "Architecture de la solution" : les CMS se répartissent en deux familles : les outils de "gestion de contenu Web" et les outils de "gestion d’infrastructure Web". Les premiers reposent sur une base de contenus unique, qui sert à la fois pour la contribution et la restitution ; les seconds arborent une séparation forte entre instances de contribution et de restitution, avec un mécanisme de publication entre les deux.
• Axe "Type de contenus" : entre les solutions qui permettent de gérer de simples pages Web et les solutions autorisant la création de types de contenus personnalisés (de type catalogues produits), on trouve toute une gamme de solutions intermédiaires (blogs, gestion de contenus éditoriaux, etc.).
• Axe "Technologie utilisée" : les CMS se répartissent principalement entre deux technologies : Java et PHP. On trouve également quelques rares solutions en .NET ou en Python.

Jusqu’au milieu des années 2000, le marché des CMS Open Source était l’apanage presque exclusif des solutions PHP, qui ont profité de la démocratisation de l’accès à internet et aux hébergeurs supportant cette technologie. Il s’agissait principalement de solutions de type "gestion de site Web" permettant de réaliser et d’administrer simplement des sites Web à fort contenu éditorial. Depuis quelques années, on assiste à l’émergence de solutions Java plus orientées "gestion d’infrastructure Web" et donc ciblant davantage les sites d’entreprises à fort trafic.

Sur le marché français, les solutions qui sortent du lot aujourd’hui sont :

• En technologie PHP :
  • Spip (La Poste, EDF, France Télécom, Portail du gouvernement, Ministère de la jeunesse et des sports, Ministère de l’éducation nationale, Ministère de l’emploi et de la solidarité, STIF, Salon des entrepreneurs, etc.)
  • eZ Publish (INRA, Suez, AFNOR, Ca m’intéresse, WWF, National Geographic, CIRAD, MIT, Swissfirst, etc.)
  • Drupal (Saint Gobain, SGAR Aquitaine, Banque de France, Rue89.com, NASA, AOL, Warner Bross, Fox, etc.)
• En technologie Java :
  • Alfresco WCM (Electronic Arts, MIT, etc.) [2]
  • Magnolia (France24, PMU, Ministère des affaires publiques espagnol, Digital UK, JetTravel, Mepha Ltd., etc.)
  • Jahia (La Poste, Parlement européen, Journal Officiel, Valeo, BNP Paribas, JPMorgan, Université de Lausanne, Ministère des finances, Conseil régional d’Île de France, etc.)

Exemples de projets réussis

Refonte du portail du gouvernement avec Spip-Agora

Le Service d’Information du Gouvernement (SIG) a lancé en 2004 un chantier de refonte du site Internet du Premier Ministre sur la base du logiciel libre Spip. C’est une version améliorée, baptisée Spip-Agora, qui a été conçue et réalisée pour les besoins du projet.

Depuis son lancement en 2004, le site a connu une fréquentation en hausse continue. Le site sert en moyenne de l’ordre de deux millions de pages par mois, avec un pic à 143 170 visites le 1er juin 2005 (nomination du gouvernement). Afin de répondre à cette forte demande, le SIG a choisi de s’appuyer sur des caches Akamaï placés devant trois serveurs frontaux de faible puissance (monoprocesseurs à 800 MHz), mais qui garantissent une tolérance aux pannes. La contribution est quant à elle assurée par un serveur dédié permettant à une soixantaine de journalistes de saisir leurs articles dans le Back Office.

Notons enfin que le portail du gouvernement est certifié WAI et AccessiWeb (accessibilité pour les personnes présentant un handicap) et qu’il a reçu le Clic d’Or 2005 dans la catégorie "Site institutionnel".

Une grande mutuelle choisit eZ Publish pour la refonte de son site internet

Un client de Clever Age, actif dans le domaine des assurances, a souhaité remplacer l’outil de publication utilisé jusqu’alors (Lotus Notes), afin de permettre à un maximum de contributeurs de participer à l’animation du site, en parallèle d’une refonte globale du site Internet. A la suite d’une étude mettant en concurrence Spip, Drupal et eZ Publish, c’est ce dernier qui a été retenu, à la fois pour sa richesse fonctionnelle et sa facilité de prise en main.

Au final, le site est capable de servir 5 à 6 pages par seconde en pleine charge. Pour ce faire, un seul serveur (Bi-processeur Intel DualCore, 5 GO de RAM) héberge à la fois le serveur Web (Apache 2) et la base de données (MySQL 5). En plus du cache intégré à eZ Publish, un mécanisme de cache bas niveau PHP (XCache) a été mis en place afin de réduire les temps de chargement des pages.

Lotus Notes étant toujours utilisé abondamment pour d’autres besoins de ce client, il est prévu prochainement de mettre en place des connecteurs entre Notes et eZ Publish, à base d’export XML des contenus.

Architectures types

Architecture de type "Gestion de contenu Web"

Dans cette architecture, une base de contenus unique est partagée entre le Back Office (où se fait la contribution des contenus) et le Front Office (où se fait la restitution des contenus, à savoir le site Internet ou Intranet à proprement parler).

Les éventuels contenus extérieurs au site sont agrégés directement dans la base de contenus, au moyen de mécanismes d’import / export, de flux RSS, etc.

La plupart des CMS PHP sont bâtis selon cette architecture. Il est toutefois possible de la scinder en deux (une base pour la contribution, une autre pour la restitution), à condition de mettre en œuvre un mécanisme de synchronisation entre les bases. C’est par exemple ce qui a été fait pour le site France Télécom Entreprises (Oléane), réalisé avec Spip.

Architecture de type "Gestion d’infrastructure Web" Cette architecture repose sur un découplage fort entre le Back Office (qui sert à la contribution des contenus) et le Front Office (qui sert à la restitution). Un mécanisme de publication permet de publier tout ou partie d’un site (contenus, pièces jointes, gabarits de restitution, etc.) de l’un vers l’autre.

Cette architecture, plus contraignante que la précédente (le processus de mise à jour est plus lourd), a l’avantage de limiter les risques de piratage d’un site public, puisqu’il est possible d’isoler le serveur de contribution.

Les critères de choix

Comme pour tout choix de solution, le choix d’un CMS doit prendre en compte les aspects fonctionnels, techniques et économiques. Nous nous intéressons ici avant tout aux fonctionnalités (les aspects techniques et économiques étant plus ou moins communs à l’ensemble des familles de solutions). Les outils de gestion de contenu peuvent être étudiés selon huit axes principaux :

• Contribution : Quels sont les profils des contributeurs ? Quels sont les types de contenus ? La solution doit-elle permettre la saisie en mode WYSIWYG ? La prévisualisation est-elle nécessaire ? L’interface doit-elle être disponible en plusieurs langues ? Etc.
• Catégorisation / rubriquage : Comment sont classés les contenus dans le Back Office ? Dans le Front Office ? A-t-on besoin de méta-données ? La navigation transverse (par contenus liés, nuage de tags, etc.) est-elle souhaitée ? Etc.
• Diffusion / personnalisation : Le site contient-il une partie privée, nécessitant authentification ? Est-il prévu de faire de la diffusion sélective de contenus, selon le profil du visiteur ? Doit-on prévoir un rendu sur plusieurs canaux (Web, WAP, etc.) ? Qui a la charge de créer des nouveaux gabarits de présentation ? Etc.
• Automatisation des processus : Quels sont les workflows de publication à mettre en place ? Doit-on prévoir des mécanismes de publication / dépublication automatiques ? Le versioning des contenus est-il souhaité ? A-t-on besoin de faire des traitements par lot ? Etc.
• Recherche : Quelles sont les fonctionnalités attendues du moteur de recherche en Front Office ? En Back Office ? A-t-on besoin d’agréger des résultats provenants de plusieurs moteurs ? Doit-on mettre à disposition les contenus pour un moteur externe ? Etc.
• Intégration : A-t-on besoin d’intégrer des contenus externes au site (flux RSS, Web Services, etc.) ? Doit-on mettre à disposition les contenus pour une utilisation externe ? La solution doit-elle se brancher sur un annuaire externe pour les contributeurs ? Les visiteurs du site ? Etc.
• Travail collaboratif : Quelles sont les fonctionnalités collaboratives attendues dans le Back Office (verrouillage d’un contenu, commentaires, forum de discussion, etc.) ? Sur le Front Office (forums de discussion, notation des articles, etc.) ? Est-il prévu de proposer des formulaires (contact, sondages, etc.) ? Etc.
• Business intelligence : Quelles sont les données utiles à récupérer en matière de fréquentation (nombre de visites, articles les plus vus, profil de visiteur, etc.) ? Est-il prévu de s’interfacer avec un système de tracking externe (Xiti, Weborama, etc.) ? Une analyse plus fine du comportement des visiteurs est-elle nécessaire (par exemple pour alimenter un moteur de règles) ? Etc.