|
Les
problèmes des logiciels de
CMS
Des
solutions lourdes - Les produits les plus
connus des directions informatiques sont
généralement les plus chers. Ces
outils (citons Vignette et Interwoven, mais il y en
a plusieurs dizaines, une
liste non exhaustive se trouve
ici),
conçus pour des grands comptes,
prétendent gérer toutes les
situations de publication rencontrées par ce
type de clients. Hélas, il en résulte
souvent des produits complexes, lourdingues
même, nécessitant de nombreux
composants sur au moins un serveur de test et un
serveur public ("serveur de production"), à
savoir une base de données, le CMS
lui-même, et souvent un produit
intermédiaire appelé serveur
d'application qui effectue les traitements
complexes au sein de la base des pages.
Ces
produits ont pour inconvénient d'être
gourmands en ressource, et lorsque les pages sont
générées à chaque
requête de l'internaute depuis la base de
données, le serveur peut vite atteindre la
saturation, obligeant à un ajouter un autre,
puis un troisième, etc., au fur et à
mesure que votre site a du
succès.
Des
clauses tarifaires inacceptables - Or, les
politiques tarifaires officielles (heureusement
négociables, le plus souvent) des "gros"
vendeurs de CMS auront vite fait de vous mettre
financièrement à genoux si vous devez
empiler les serveurs: licences facturées au
nombre de serveurs, voire au nombre de processeurs
dans les serveurs, voire à la puissance des
processeurs (On croit rêver !!!), auxquelles
l'éditeur ajoute souvent un coût
variable en fonction du nombre de personnes qui
contribuent au site (parfois 400 Euros, parfois...
1000), faites le calcul pour une
société de 10000 personnes dont 10%
sont des contributeurs potentiels... Sans parler de
la maintenance annuelle.
Une
louche de consulting... - Cela ne suffit pas ?
La plupart de ces programmes sont tellement
complexes à déployer que vous devrez
payer une forte somme en conseil (d'où le
nom de "consultingware" souvent donné
à ce type de logiciel) simplement pour
paramétrer l'engin, et commencer à
avoir le droit de remplir un squelette de site
livré vide.
Certes,
des éditeurs plus jeunes tentent de sortir
des produits de prix intermédiaires, et le
mouvement Open Source commence à
créer de bons produits sur ce créneau
(citons "Zope
&endash; Content Management
framework",
utilisé dans certains ministères, ou
"Spip",
utilisé par de nombreux sites associatifs et
quelques journaux.).
Des
interfaces médiocres - Mais les
problèmes ne sont pas que financiers. Pour
en avoir testé quelques-uns uns
(catégorie "payants et chers..."), j'ai pu
me rendre compte que les interfaces utilisateur de
ces produits variaient du moyen au
désastreux pour le simple producteur
d'information, supposé
non-spécialiste d'informatique. Notamment,
la récupération de documents produits
par Office sans normalisation des modèles
word (fréquent dans les structures, de plus
en plus nombreuses, où les cadres assurent
eux même la dactylographie de leurs
écrits...) peut être difficile, ce qui
est un comble.
Trop
de fonctions, pas toujours utiles - Enfin,
lorsque le déploiement d'un CMS a
été trop pensé en terme de
produit, de fonctionnalités, et pas assez en
terme de simplification de la tâche pour les
personnes contribuant au site, celles ci se
trouvent confrontées à des outils
(workflows de validation, classement par rubrique
incompréhensible, etc...) qui leur
compliquent la vie plus qu'il ne la leur
simplifient.
Bref,
tout n'est pas rose dans le petit monde du CMS.
Peut-on espérer que cela s'améliore
?
Du
côté des
éditeurs
Certains
éditeurs ont compris que pour satisfaire
leurs clients, ils devaient améliorer
l'interface utilisateur et appliquer des tarifs
plus sains: soit une licence élevée
mais fixe par site, quel que soit le nombre de
serveurs et de contributeurs, soit un coût
d'installation nul et une licence par contributeur
moyennement élevée, et
dégressive.
De
plus, certains essaient de simplifier leurs
produits en supprimant des fonctions certes
fortement demandées par leurs premiers
clients, mais dont on peut se passer au
final.
Peut
on supprimer certaines fonctions ?- L'exemple
le plus significatif est celui du workflow de
validation généralement
intégré aux produits de CMS: L'auteur
est supposé, une fois son texte
terminé, l'envoyer à un de ses chefs
pour que celui ci le valide à
l'intérieur de l'outil... cela alourdit
fortement le processus. Or, dans la plupart des
cas, les utilisateurs s'échangent des
documents word par mel, et se valident les uns les
autres par la même voie, avant que le texte
ne soit publié. Dans ces conditions, un
workflow est-il nécessaire ? Joel Spolsky,
gourou de l'utilisabilité et éditeur
du CMS
"small business"
Citydesk,
pense que non, aussi a-t-il enlevé ces
outils dans la version de base de son produit.
Résultat, un logiciel moins riche des
fonctions qui servent le moins, mais avec quatre
boutons de base à connaître pour le
producteur de contenus.
Un
autre exemple est celui des langage de
programmation des CMS (celui qui permet
d'automatiser la gestion des sommaires). Dans les
produits les plus chers, celui ci est souvent
dérivé de langages informatiques
complets, quant ils n'ont pas tout simplement
recours à Java ou Visual Basic. Trop
complexe pour bien des webmestres qui ne viennent
pas du monde de la programmation. Or des produits
comme SPIP
ou Citydesk
(encore...) ont fait un effort de simplification de
leur langage en ne gardant que les fonctions
nécessaires à l'édition
automatisée de sommaires (une tâche
assez simple d'un point de vue informatique),
rendant leur programmation accessible à un
honnête codeur HTML.
A
l'avenir, peut être que l'usage intelligent
de technologies comme Flash ou Java permettra de
s'affranchir des limitations du navigateur et de
créer des interfaces utilisateur vraiment
conviviales. Mais les progrès des
éditeurs de logiciel seront sans doute plus
lents que dans les rêves de tout chef de
projet web.
C'est
donc à l'acheteur de se prémunir
contre les pièges du CMS en
négociant finement ses achats, et en
adoptant de bonnes démarches de mise en
œuvre. Voyons en les grandes
lignes.
Du
côté des acheteurs
L'un
des pièges lors d'une consultation en
vue d'acheter un CMS est de vouloir
sélectionner à la fois un
intégrateur (en général une
SSII) et le produit CMS. Cette approche est le plus
sur moyen de vous retrouver avec un binôme
bancal "bon CMS/Mauvais intégrateur", ou
vice-versa. Si vous en avez la possibilité,
faites d'abord le choix du produit qui
paraîtra le plus adapté à vos
besoins, puis choisissez (éventuellement
avec l'aide de l'éditeur) un
intégrateur compétent sur cette
plate-forme.
Le
deuxième point à négocier
fermement est bien sûr l'aspect financier
du CMS. Pour le cas ou la solution que vous
retiendriez ne serait pas un logiciel Open Source,
vous devez impérativement vous
prémunir contre les conséquences
financières d'une multiplication
imprévue des besoins en serveurs, ou un
coût excessif du déploiement au fur et
à mesure que vous déconcentrez la
production du site.
Pour
arriver à ce résultat, une
première piste est de sélectionner de
préférence des outils qui
transforment les pages de type "base de
données" sur le serveur de travail en url
statique sur le serveur de production à
chaque fois que c'est possible, ce qui est souvent
le cas, sauf pour les pages résultant d'une
requête complexe (résultat de
recherche, interrogation directe d'une base de
données, panier d'achats). Même si
vous avez en base de données 10.000 fiches
produit, il vaut mieux générer 10.000
pages statiques, si possible avec une url lisible,
sur le serveur de production, que 10.000
assemblages à la demande de pages
dynamiques, sauf si les fiches produits sont
paramétrables de façon complexe.
Ainsi, la charge supportée par le serveur
est-elle moindre.
En
outre, les clauses du contrat doivent être
"bétonnées": S'il vend un produit
avec une licence par serveur, le fournisseur doit
s'engager sur un nombre maximum de serveurs
nécessaires pour servir votre trafic actuel,
dans des conditions de temps de réponse bien
précisées. Ces besoins maximaux
doivent prendre en compte diverses
hypothèses de multiplication de votre
audimat (après tout, mieux vaut
prévoir le succès...). Il doit vous
consentir un coût par serveur fortement
dégressif, si possible plafonné, et
vous devez lui imposer des pénalités
en cas de non-respect des performances
annoncées.
De
surcroît, vous devez éviter que le
coût par contributeur ne soit prohibitif.
La négociation d'une licence
illimitée paraît nécessaire
pour les moyennes et grandes
entreprises.
Tous
ces conseils sont moins pertinents si vous avez la
chance qu'une solution Open Source convienne
à vos besoins. J'y reviendrais plus
loin.
Commencez
petit
Si
vous êtes un petit acheteur et si vous n'avez
pas d'expérience du CMS, vous avez
intérêt, sauf urgence maximale,
à éviter de commencer par un projet
à grande échelle. Je recommande
fortement, si vous en avez le temps, de commencer
par une expérience limitée avec un
outil comme Citydesk (propriétaire, mais
assez bon marché et très simple
à utiliser), ou comme Spip (interface moins
conviviale, mais totalement gratuit), ou Zope-CMF
(Logiciel gratuit et beaucoup plus ambitieux que
les deux précités, mais
nécessitant un intégrateur
programmeur sérieux pour démarrer,
donc coût total un peu plus cher que pour les
deux autres) afin de vous constituer une
première expérience de gestion de
site pour CMS, et ainsi de sélectionner
ultérieurement, si nécessaire, une
solution complète en connaissant mieux le
sujet. Vous serez ainsi mieux à même
de négocier avec vos différents
prestataires.
L'open
source, futur du CMS ?
Où
mettre le budget ? - Imaginons qu'une solution
open source (cf. ce lien) vous paraisse "proche" de
vos besoins mais encore imparfaite
(fonctionnalité importante manquante,
interface utilisateur encore "rugueuse"
côté production...). Si vous avez un
budget important pour votre opération, faut
il acheter un poids lourd de type interwoven,
broadvision, vignette, ou utiliser ce budget
à faire développer le morceau de code
manquant à la solution open source que vous
avez ciblée ?
N'ayant
pas d'expérience de cette approche, je ne
puis certifier qu'elle soit meilleure, car l'achat
de développement de code spécifique
n'est pas toujours une voie facile. Mais imaginez
que vous ayez à reproduire votre solution
sur plusieurs projets parallèles, ou que
vous deviez multiplier les serveurs pour faire face
à votre succès... Les logiciels
libres représentent alors un avantage
financier incontestable.
Le
libre, c'est l'avenir du CMS - Selon moi, les
progrès des solutions libres rendront
très vite (si ce n'est déjà
fait) sans intérêt les grosses usines
à gaz propriétaires à
plusieurs dizaines ou centaines de milliers
d'Euros. Seuls des logiciels commerciaux
très peu chers, mais qui offriront un
avantage déterminant - comme par exemple une
interface utilisateur ultra simple, favorisant la
productivité de l'équipe web -
pourront éventuellement concurrencer les
solutions libres, car leur prix de licence ne sera
pas déterminant dans le calcul du coût
global de possession de la solution.
Le
CMS, 1/3 de technique, 2/3 de
management
Mesures
d'accompagnement - Le déploiement d'un
CMS sur une échelle large vous obligera
à définir de nombreuses mesures
d'accompagnement, comme la définition du
rythme et du niveau de déconcentration de la
production du site (tout le monde ? Des
correspondants du webmestre ?), les formations
associées, une procédure de
validation et de contrôle préventif de
la qualité des contenus compatibles avec
votre culture d'entreprise, des catégories
et autres typologies de classement de vos contenus
à la fois adaptées au langage de
votre public et à celui de vos
collaborateurs, leur permettant de classer sans
peine les pages aux bons endroits.
Sans
oublier qu'il vous faudra adapter l'interface de
contribution à vos contraintes locales, en
supprimant les fonctions inutiles de l'interface
utilisateur accessible à vos auteurs. Ceci
peut nécessiter un ou deux petits tests
d'utilisabilité de votre interface de
production.
Enfin,
il faudra vous assurer que le site produit procure
une bonne expérience utilisateur à
ses visiteurs, et donc inclure des tests pendant
son cycle de développement.
La
démarche managériale autour d'un
projet de CMS pouvant à elle seule faire
l'objet d'un livre, je m'y attellerai
ultérieurement. En attendant, vous pouvez
vous reporter aux ressources mentionnées
dans les liens associés.
Conclusion
Mettre
en œuvre un CMS qui vous satisfera ne peut pas
se faire à la légère, tant ces
projets se révèlent structurants pour
votre activité. Aussi devez-vous
soigneusement préparer chacune des
étapes d'une telle opération. A cette
fin, avant de vous lancer dans un projet
d'envergure, recueillez le maximum
d'expériences, soit par des tiers, soit
grâce à des pré-projets de
taille limitée, sous peine de faire face
à des "coûts d'essuyage de
plâtres"
conséquents.
|
",
comment introduire un CMS en
pensant d'abord à vos
clients.