Réflexion autour du CMS

Dans cet article, je vous propose de vous présenter rapidement les grands principes du CMS puis de vous parler des raisons qui m'ont poussé vers cette orientation particulière. Dans un second temps, nous verrons comment ces CMS s’intègrent dans le contexte de projets réels. Le personnage clef dans la réalisation d’un site web est le développeur. Souvent Ingénieur, nous parlerons des origines du métier.

Pour finir j'aborderai les concepts oubliés du CMS et l'importance du développeur dans cette approche de réalisation de sites web.

Les CMS Open-Source

Une Définition

Tout d'abord un CMS est une application de gestion de contenus. Ce sont les logiciels les plus utilisés dans la réalisation de sites web.

A ce jour WordPress représente 25% des sites web réalisés dans le monde.

Que l'on soit aficionado du Java ou du .NET il faut se faire une raison : les CMS PHP ont le vent en poupe et cela n'est pas près de changer.

 

Les Grandes Lignes Directrices

A l'origine de tous les grands CMS actuels, il y a une vision, un enjeu majeur qui est tout à fait honorable. Cet enjeu c'est le fait de rendre le CMS accessible au plus grand nombre et non pas seulement aux professionnels comme c'est le cas des frameworks.

Les CMS tels que Drupal où WordPress pour ne parler que de ceux que je connais sont conçu autours des axes suivants :

  • Facile à installer
  • Le maximum de chose est faisable directement en back-office
  • Facile à étendre

De ce fait, ces CMS ont pu proliférer chez les hébergeurs qui proposent des environnements mutualisés pour seulement quelques euros par mois.

Afin de permettre d’adapter le CMS à une variété de projets, chaque éditeur propose un moyen pour les développeurs de fournir à toute la communauté des modules qui vont s’ajouter aux fonctionnalités de base pour étendre les possibilités offertes par le CMS.

Le CMS au Quotidien

Quelques Cas d’Usage

A ce stade, il faut bien comprendre qu’un projet réel est rarement exclusivement axé sur la gestion de contenus. La gestion de contenus à proprement parler est la brique fonctionnelle la plus visible. C’est la part émergée de l’ice-berg. Dans un contexte professionnel, le CMS sera intégré à un environnement pré-existant : le SI ( système d’information ) de l’entreprise.

Bien que la création ou la mise à jour des contenus soit généralement à la charge d’une équipe éditoriale, une partie du site peut être alimentée par des composants externes ou le site lui-même peut exporter ses données à destination d’autres composants du SI.

C’est le cas par exemple dans l’utilisation d’un moteur de recherche avancé. Le CMS va fournir ses contenus à au moteur de recherche qui va indexer les données « à sa manière » afin de permettre des résultats plus fins que la recherche basique proposée par la plupart des CMS « nativement ».

Un autre cas d’usage qui nécessite une interopérabilité avec un composant externe est quand l’entreprise souhaite que les accès au back-office soient gérés par leur annuaire d’utilisateurs internes. Bien que le CMS soit capable de gérer de manière autonome la création de comptes utilisateurs et leur authentification cette partie peut être délégué à un LDAP.

Ces éléments montrent que dans la réalisation de site web basé sur un CMS il y a une part de développement ou d’extensibilité de l’application qui est attendu. Ce travail est réalisé par un développeur. De plus les CMS proposent généralement des milliers de modules communautaires qui permettent d’ajouter les fonctionnalités les plus demandées assez facilement.

Le Besoin de Personnalisation

L’autre besoin particulier dans les projets « réels » est la personnalisation. Les entreprises qui font appels à nous ont très généralement une charte graphique déjà définie, une image à laquelle doit s’intégrer le nouveau site qui sera réalisé. De ce fait des graphistes vont intervenir pour réaliser des maquettes, des photos du futur site.

L’équipe de développement aura alors pour rôle d’intégrer au CMS des éléments graphiques nouveaux et uniques à chaque projet.

C’est généralement le travail qui prend le plus de temps dans la réalisation d’un projet Web.

Le rôle du développeur : Êtes-vous Ingénieur, Artisan ou les deux ?

L’Histoire de l’Ingénieur

D’après Wikipédia, la notion d’ingénieur remonte à l’âge des Pyramides. Cependant l’on peut considérer que le métier d’ingénieur tel qu’on le conçoit de nos jours remonte à beaucoup moins loin.

Pendant les périodes de guerres où il était vital pour les corps d’armées terrestres de se déplacer rapidement et de ne pas rester longtemps au même endroit, l’un des besoins qui s’est rapidement fait sentir était de construire des ponts pour traverser les cours d’eau. Bien entendu dans ce contexte il n’y avait pas le temps d’y passer 6 mois. Il fallait aboutir à une solution opérationnelle le plus vite possible.

C’est à ce moment que sont intervenus les ingénieurs. Ils ont conçus des modules facile à transporter et qui s’assemblent comme des LEGO pour construire des ponts en quelques heures.

De nos jours la plupart des développeurs sont formés comme des Ingénieurs.

Ma vision du CMS

Un Socle Technique

Si vous avez eu la patience de lire jusque là, c’est maintenant que l’on passe au cœur du débat !

Le CMS est souvent vu par les clients, les Ingénieurs d’affaires et plus généralement par une grande partie des intervenants comme un outil clef en main permettant d’administrer du contenu et souvent rien de plus. Pourtant comme on l’a vu précédemment aucun projet n’est 100 % gestion de contenus (à part peut-être le blog d’un amateur – par opposition au blog d’entreprise où le nombre de personnes qui gèrent l’outil est plus important).

Concevoir le CMS comme un logiciel permettant uniquement de gérer des contenus est selon moi l’erreur la plus courante. De nos jours, les CMS les plus utilisés sont bien plus que cela. Ils sont un socle technique ou framework associé à un back-office orienté gestion de contenus (et seulement le back-office).

Bien que jusqu’à il y a peu, les éditeurs de CMS développaient leur propre framework pour faire fonctionner leur CMS, le besoin en évolutivité et personnalisation qui a été intégré dans la vision qui guide le développement de ces applications à conduit ces éditeurs (Drupal, eZ Publish notamment) à remplacer le cœur du CMS par le framework Symfony. Bien que cela soit une démarche qui va dans le sens d’améliorer et de simplifier l’évolutivité de la solution, il faut savoir que même les CMS qui n’intègrent pas Symfony sont basés sur un « cœur » qui est un véritable framework avec de grandes possibilités d’extension, d’évolutivité.

Le développement d’applications métiers basé sur un CMS n’a donc pour moi pas plus de limites que le développement basé sur un framework. Il a même l’avantage de standardiser l’interface utilisateur d’administration là où les solutions « from scratch » laissent libre cours à l’imagination des développeurs. Pourtant l’ergonomie est un métier à part entière et un développeur n’est pas ergonome. Le développeur ne devrait pas être en situation de créer lui-même une interface web sans cadre.

Je ne compte plus les applications « from scratch » que j’ai rencontré dont les utilisateurs se plaignent du manque d’ergonomie.

Le Vrai Rôle du Développeur

Le problème principal pour les développeurs dans le contexte du CMS est qu’il est très tentant pour eux et pour leurs employeurs de les inciter à utiliser autant que faire se peut, les modules fournis par la communauté. A-t-on parlé de l’adage : « Une ligne de code que l’on n’a pas écrite est une ligne de code que l’on aura pas à tester et pas à déboguer. »? Dans ce contexte le développeur peut passer la grande majorité de son temps à installer et configurer des modules moyennant uniquement des actions en back-office. C’est un fait, il est possible de créer tout type de sites web avec les modules proposés par les communautés.

Mais ceci pose plusieurs problèmes.

Les performances des sites qui contiennent plusieurs dizaines de modules sont très largement entachées. En effet le CMS avant l’affichage de chaque page va initialiser un par un tous les modules. Vous comprendrez aisément que plus il y en a et plus cette phase d’initialisation durera longtemps. A tel point que certains sites ont des pages qui mettent plusieurs très longues secondes à s’afficher au point de faire fuir les utilisateurs.

Les failles de sécurité sont également un problème. Les modules contiennent très souvent une ou plusieurs fonctionnalités qui vont nous intéresser et d’autres dont nous n’avons pas besoin. Mais si nous choisissons de l’utiliser il faut tout prendre. Dans ce cas on ajoute une grande quantité de code au projet dont la sécurité n’est pas optimale. En effet si les CMS sont régulièrement testés par des experts contre les failles de sécurité et des patchs sont produits régulièrement pour combler les failles qui sont découvertes vous comprendrez que ce n’est pas possible de couvrir l’ensemble des dizaines de milliers de modules fournis par la communauté. Les modules sont donc à minima beaucoup moins souvent mis à jour par des patchs de sécurité. Seul les modules les plus utilisés sont testés et mis à jour régulièrement.

Installer un module créé par quelqu’un d’autre c’est un peu comme donner ses clefs au voisin qu’on ne connaît pas et lui demander d’arroser ses plantes en son absence. Cela peut fonctionner mais on peut aussi avoir des mauvaises surprises !

L’autre point négatif de multiplier l’installation des modules communautaires et que si les modules sont souvent testés unitairement avant d’être publiés afin de vérifier qu’ils fonctionnent bien et qu’ils ont une tolérance aux erreurs qui ne fait pas planter le site web, les modules sont rarement testés entre eux puisqu’ils sont développés par des équipes complètement différentes, qui ne se connaissent pas et qui ne travaillent pas ensemble.

Il n’est donc pas rare d’avoir des interactions entre des modules qui produisent des bugs alors que chaque module pris individuellement fonctionne bien.

Le dernier aspect que je tiens a évoquer dans cette démarche et que le fait d’installer et configurer des modules n’est certainement pas le travail le plus passionnant pour un développeur.

~

C’est là qu’on arrive au vrai rôle du développeur !

Le développeur n’est pas seulement un ingénieur qui doit assembler des modules comme on le ferait pour construire rapidement un pont. Le développeur est aussi un artisan qui doit mettre en œuvre son savoir faire technique et son expérience pour développer des modules sur mesures qui correspondent vraiment aux besoins des projets sur lesquels il intervient. Ces modules contiendront moins de bugs, donc moins de failles de sécurité et seront plus performant qu’un ensemble de modules communautaire.
Dans ce contexte on arrive à des applications performantes et qui répondent aux attentes des clients.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.