cbsch.net

J'avais déjà publié un article concernant les CMS sous l'angle de l'accessibilité. Toutefois, le débat est plus large dans le cadre de l'entreprise et nécessite de plus profondes considérations.

Pourquoi choisir un CMS?

Les arguments suivants sont fréquemment employés en faveur de l'emploi d'un CMS en entreprise:

• L'outil est déjà prêt à fonctionner: seules quelques adaptations semblent a priori nécessaire.
• Pas besoin d'injecter des fonds pour un développement propriétaire "maison".
• Facilité d'ajouts de nouvelles fonctionnalités sur une base stable et connue.
• Simplicité de la collaboration nécessitant une petite formation éventuelle pour se familiariser au backend.
• Possibilité d'un travail collaboratif: le web content manager n'a plus autant d'importance qu'avant.
• Facilités techniques: le webmaster devient un "simple" administrateur informatique.
• Le développement requiert moins de développeurs. En outre, ceux-ci ajoutent une plus-value au produit plutôt que de réaliser un outil pré-existant sous une forme différente.

Même si j'ai dû oublier certains arguments dans la liste ci-dessus, on remarque bien qu'ils tendent tous à l'économie: de moyens, de matériel, d'adaptations, de développement, de formation technique, etc. Toutefois, même si les choix sont guidés à la base par une perspective économique, un certain poids est également donné à la prospection, voire la spéculation: ajout de fonctions, malléabilité et adaptativité du produit, miroitement d'un développement sans cesse plus poussé et performant, présentation d'applications futures et de fonctionnalités poussées. Les CMS produisent parfois l'effet d'un formidable jouet, laissant l'imagination des développeurs s'envoler vers les cieux des "et si..." et des "avec ça plus tard on pourra...". Il est en effet plus enthousiasmant d'admirer un produit fini et de se projeter dans son utilisation que de concevoir un projet techniquement difficile, avec une phase de développement de longue haleine, et requérant de lourds moyens.

Une fois ces différents arguments développés et acceptés, la question suivante porte généralement sur le choix du produit. La plupart du temps, on distingue les CMS open source des CMS propriétaires. Nous verrons plus bas qu'une autre distinction possible est souvent omise, fort malheureusement.

Un choix manichéen: solutions open source et propriétaire.

Open source or not open source?

Encore une fois, l'open source en entreprise est trop souvent magnifié pour certaines de ses caractéristiques les plus attrayantes:

• Coût d'installation peu élevé, coût du produit de base (presque) inexistant.
• Grande évolutivité du produit: capacité de l'adapter aux besoins propres de l'entreprise, existence de modules.
• Communauté de développement active proposant des ajouts ou des corrections de manière régulière.
• Produit fini offrant de nombreuses fonctionnalités modulaires.
• Possibilité d'ouvrir le backend aux collaborateurs et, donc, de rendre les collaborations plus vivantes, nombreuses et larges.

De tels arguments jouent a priori un rôle primordial dans le choix d'un CMS open source. L'argument du coût est trop souvent prépondérant. On oublie également trop facilement que l'open source évolue vite, que les apports réalisés par la communauté ne sont pas forcément stables, que la communauté peut se diviser (cf. Joomla, phpNuke, etc.), voire disparaître purement et simplement. Autrement dit, quand on choisit un produit open source, d'autres considérations doivent être prises en compte et pondérer les avantages indéniables des produits libres de droit:

• Le support du produit sur site générera des coûts: est-ce que l'adaptation du produit à nos besoins coûtera plus cher que la production ou l'achat d'une solution propriétaire?
• L'outil doit avoir une stabilité à tout épreuve: doit-on envisager un downgrade vers une solution stable ou doit-on figer le produit?
• Le CMS devra théoriquement être intégré au workflow de l'entreprise: cette compatibilité exige-t-elle des aménagements? Si oui, quels seront les moyens à mettre en oeuvre pour y arriver?
• Les pages publiées devront suivre certaines normes: accessibilité (dans le cas d'un site gouvernemental surtout), charte graphique, variété de contenu, etc. Le CMS envisagé donne-t-il les moyens de se conformer facilement et si possible sans aucun aménagement à de tels critères?
• Quelle est la courbe d'apprentissage du backend? Combien nous coûtera la formation des collaborateurs?
• Si des aménagements doivent être faits, est-ce que nous possédons déjà les ressources humaines nécessaires pour le faire? Devra-t-on créer de nouveaux postes?
• Peut-on avoir une vision à long terme une fois le CMS installé? Si oui, de quelle durée? Quels sont les coûts estimés sur le long terme une fois cet outil installé?

Et si on cassait la tirelire?

L'installation d'un produit open source n'est pas chose aisée, surtout si on la considère sous l'angle très manichéen du "open source or not". Fréquemment, lors du choix du CMS que l'on installe en entreprise, on lorgne également du côté des solutions propriétaires. Et, là, deux arguments majeurs viennent changer radicalement la donne, et enterrent bien souvent l'open source:

1. Les solutions propriétaires peuvent être aménagées avant leur installation et ce souvent sans d'énormes modifications de son coût: en fin de compte, il s'agit d'une relation commerciale standard au cours de laquelle on achète le produit fini que l'on veut, et non pas un produit par défaut à aménager. Les questions du workflow, de l'adaptation du produit et de son développement passent donc au second plan.
2. Le produit acheté est stable et ne dépend pas d'une communauté mais d'une société. On pourra rétorquer que ce n'est pas un argument garant de sa pérennité. Bien au contraire: les sociétés commerciales ont des fondements et des garanties que ne présentent pas (ou très rarement) les communautés open source.

Après cette brève présentation du choix du CMS en abordant la question de la propriété, il me paraît absolument indispensable de présenter une autre approche, complémentaire et indissociable, qui permettra de mieux pondérer les éléments présentés ci-dessus, et orienter le débat vers un développement moins systématiquement antagoniste.

Quid de l'orientation métier?

Cette question peut sembler totalement triviale lors du choix d'un CMS: on entend généralement installer un simple gestionnaire de contenu. Celui-ci est sensé générer des pages web, souvent avec un approche collaborative. A priori, on a trop souvent tendance à considérer le site web de l'entreprise comme une simple vitrine: détachée, gérée par un autre département dans un autre secteur, voire (pire) par une entreprise externe dûment mandatée. Ce type de perspective réductrice a tendance à poser de très lourds problèmes peu après: si l'on ne tient pas compte du workflow et du cycle de vie de différents documents, qu'adviendra-t-il quand d'autres fonctionnalités offertes par internet devront être intégrées? Plus concrètement aussi, comment prendre en compte tous les environnements de travail, les outils de production et les besoins techniques des différents services appelés à collaborer via le CMS?

Afin de pouvoir répondre à tous les besoins d'une entreprise, les CMS sont malheureusement bien souvent démunis quand on leur parle d'application métier. Leur intéraction ou leur intégration dans un workflow peuvent poser de très importants problèmes de développement, de ressources ou d'infrastructures. Afin de pouvoir pleinement jouir de toutes les possibilités que l'on attend à l'heure actuelle d'un site web, l'intégration de son moteur dans le workflow, ou l'emploi d'une GED qui serve également de CMS est une solution plus raisonnable. Cela permet l'ajout facilité de fonctions plus complexes (validation dynamique de formulaires ou gestion de flux de documents en XML, par exemple).

Choisir un CMS, c'est choisir son mode de vie.

Concluons ces considérations par une petite note ouverte: en fin de compte, que l'on choisisse l'une ou l'autre des solutions n'est pas tant grave, tant que les réflexions qui ont mené à ce choix ont considéré toutes les options. Trop souvent, on se focalise sur l'un des points ci-dessus, et le débat vire vite à un débat entre les pro open source et leurs adversaires. Ce débat réducteur doit être dépassé. En fin de compte, un CMS, en entreprise, doit pouvoir s'intégrer à l'environnement et proposer des outils adaptés et adaptables, tout en restant dans une fourchette de coûts acceptables: à lui de s'adapter au contexte, et non l'inverse.

Que l'on choisisse un CMS, produise son propre outil ou emploie une GED: le choix est libre, mais il doit être réfléchi. De lui dépendra non seulement la manière dont le site sera perçu dans l'entreprise mais également la manière dont il se présentera aux "clients".