Aujourd’hui les CMS occupent une part de marché grandissante dans la mise en place des sites Web, mettre en place un site Web et déployer un CMS sont devenus sont presque devenus des synonymes. Pourtant, est ce que ces outils sont bien conçu en accord avec les bonnes pratiques du génie logiciel, de la qualité Web, de l’accessibilité, sont ils performants, sont ils des outils des pour répondre facilement aux problématiques propres à chaque projet, à chaque client. Pas besoin d’entretenir le suspense, ce ne sont pas de bons outils mais ce sont les meilleurs pour l’instant … Explications
WordPress, Drupal et Joomla écrasent le marché
Water & Stone, agence de webdesign spécialisée dans les CMS open source depuis 2003, publie une étude approfondie (19 CMS sont analysés) qui a pour but de déterminer quels sont les CMS les mieux placés en terme de taux d’adoption et d’image de marque. Ce ne sera une surprise pour personne, l’étude identifie WordPress comme le leader incontesté suivi du duo Joomla/Drupal . L’étude identifie également Elgg et… MODx comme « étoiles montantes » :)
Une architecture techniquement dépassé
Initiés aux début des années 2000, ces produits se sont basé sur les standard de l’époque. C’était les début de PHP 4, le modèle objet était défaillant et très limité. Le génie logiciel quasi inexistant à l’époque. Les hébergeurs ont aussi une part de responsabilité, ils ont pendant longtemps proposé uniquement PHP 4, ce qui n’a fait que ralentir l’adoption d’un modèle objet cohérent.
La compatibilité ascendante a propagée ces vestiges d’un temps révolu.
L’industrialisation de PHP n’est apparu que bien plus tard. Il aura fallu attendre la fin de l’année 2009 et la sortie de PHP 5.3 pour avoir un modèle objet complet et les éléments indispensables (namespaces, closures, …) pour pouvoir coder dans les meilleurs conditions.
Un modèle qui fait consensus
Un autre aspect qu’il faut prendre en compte, c’est le niveau de connaissances des bonnes pratiques de programmation, de génie logiciel des personnes qui vont intervenir sur les projets. Beaucoup de d’utilisateur ne maitrise pas les concepts de la programmation orientés objets, ils en maitrise parfois la syntaxe. Parler de chaine de responsabilité, de factory, de builder à une personne qui connait à peine la différence entre des attributs privé et public, c’est un non sens.
La programmation procédurale est quelque chose de beaucoup plus facile à assimiler et comprendre pour les non-initiés. Tous les utilisateurs, contributeurs n’ont pas eu la chance d’être formé à la programmation orientés objets.
Le modèle mis en place dans ces CMS est un modèle beaucoup accessibles pour les néophytes. Pourtant, elle regorgent de mauvaises pratiques qui finalement rendent les développement sous les CMS plus complexes qu’avec un modèle objet.
WordPress : la sur-exploitation des variables globales
Dans WordPress, le concept de Loop passent exclusivement par des variables globales.
Ce concept permet d’être efficace dans un premier temps. L’écriture de template avec WordPress est rapide dans la plupart des cas.
En revanche, l’utilisation des variables globales rend plus difficile la compréhension d’un programme ainsi que son débuggage et sa modification ultérieure, il est également nécessaire de maitriser tous le processus pour connaitre les implications d’un changement dans une variable globale. Ainsi, dès que l’on veut aller plus loin, le niveau d’expertise nécessaire pour maintenir l’application dans un état stable est bien plus important que pour un programme dans une logique où tout est bien cloisonnée.
On trouve exactement le même concept dans la notion de boucles sous SPIP. On gagne peut être en efficacité si aucune personnalisation n’est demandé. Après, on commence vite à perdre du temps à manipuler ces variables globales, identifier les effets de bords et les corriger.
Drupal : l’hérétique
Drupal n’est pas a véritablement un CMS. Dries Buytaert, développeur initial du projet à partir de 2000 à l’université d’Anvers, le définit comme « assembleur rapide de site web » (Rapid website assembler).
Ici, ce n’est pas forcément l’outil qui n’est pas adapté mais son utilisation. C’est plutôt un outils de prototypage. Pour une utilisation, comme CMS, je suis en accord avec l’avis de Gauthier Delamarre
Je prendrais que 2 exemples sur le planète drupalfr qui traduisent bien les difficultés que posent Drupal en terme de développemet :
Il faut noter que le modules est le module le plus utilisé. Ça fait froid dans le dos.
Drupal, n’est pas mauvais, si le périmètre fonctionnel correspond aux possibilités du produit (sans views et sans panels) alors oui Drupal est efficace. Sinon, passer votre chemin.
Joomla!
Joomla! a contrario, a pris le parti de réécrire une partie de son CMS en en dégageant un framework, il est d’un bon niveau mais inférieur aux cadors des frameworks PHP (Zend, Symfony, eZ Components, …) . C’est le seul CMS à proposé un véritable modèle MVC. En revanche, certains aspects ne sont pas implémentés comme les ACL ou des hiérarchisation des contenus sur plus 2 niveaux (Implémenter dans la version 1.6 actuellement en beta).
Pourtant, cette aspect n’est pas mis en valeur par la communauté ni dans la presse spécialisé. Il faut vraiment fouiller pour connaitre ne serait ce que son existence.
Des communautés très actives
Les communautés sont très actives et proposent des fonctionnalités aux travers des systèmes d’extensions qui répond aux problématiques clients. Pour chacun de ces CMS, on peut compter 100 à 200 modules, extensions, composants suivant la terminologie utilisables sur les milliers annoncées.
C’est un atout indéniables, malheureusement, c’est à double tranchant, un module mal codés et c’est le site entier qui en subit les conséquences. Il est nécessaire d’auditer chaque module pour connaitre les fonctionnalités proposées et les limites, les risques de sécurités potentielles. Il est souvent plus rapide de réécrire un module qui correspond aux métiers que l’on veut, que de trouver l’extension ou la combinaison d’extension qui va permettre de réaliser cette tâche.
Couverture fonctionnel
On peut voir les CMS comme une solution qui permet de faire des sites vite fait à des prix discount. Oui, à partir du moment où l’on accepte les fonctionnalités proposées par le CMS. Suivant le projet, un CMS avec ces extensions peut couvrir de 50% à 100% des besoins. Si la couverture est totale, le CMS est le bon choix.
Sinon, il faut bien regarder car les fonctionnalités qu’il faut développer. Il est important de comprendre que les CMS n’offrent pas des frameworks assez puissant pour permettre à un développeur d’être efficace. Le temps de développement d’une fonctionnalité est plus long sur un CMS que sur d’autres plate-formes et le niveau de connaissance de l’outils doit être beaucoup plus élevé pour pallier tous les effets de bords. Même si c’est au travers de hook que les modifications se font, on travaille sur un existant. Il était toujours plus complexe de modifier un existant pour l’adapter à ces besoins que de partir de la feuille blanche.
Si la couverture fonctionnel de l’outil est basse, le CMS peut devenir un véritable gouffre financier..
L’idée reçu qu’un CMS ne peut être utilisé par des non-développeurs est vrai mais jusqu’à un certain point.
Zend Framework et Symfony sont elle des alternatives crédibles ?
Ces 2 frameworks sont des agrégats de bonnes pratiques de programmation, il offre des fonctionnalités complètes et qui correspondent à la grande majorité des besoins.
Pour faire un parallèle avec le batiment, le CMS peut être comparé à des préfabriqués que l’on assemble, les frameworks comme les matériaux (briques, fenêtres, portes, tuiles, charpentes, ….).
La mise en place d’un site batit sur des frameworks est plus longues en première approche. Il faut le temps d’obtenir le pré-fabriqué du CMS (au moins les fonctionnalités utiles et nécessaires). Ensuite, le gain se fait sentir, le développement de nouvelle fonctionnalité est beaucoup plus simples et plus rapides qu’avec un CMS.
Le cout du pré-fabriqué du CMS peut paraitre rédhibitoire mais il peut parfaitement être développé par un prestataire pour le premier client et réutilisé pour les autres, le coût de fabrication peut donc être répartie sur plusieurs projets.
On voit également apparaitre des couches CMS batit sur les frameworks Diem, Sympal, Digitalus, … . Elle n’offrent pas encore toutes les possiblités de WordPress, Drupal ou Joomla mais l’avenir est clairement à ce type de solutions qui combinent les avantages du préfabriqués et les avantages d’un framework puissant.
Malheureusement, la situation est a nuancé. Le Zend Framework et Symfony ont entamés des évolutions majeures. Symfony abandonne le modèle fullstack et part sur un framework de type composant. La fin du support de la version 1.4 est prévue pour fin 2012. Le Zend Framework va aussi entammer une petite révolution avec la version 2.
Il va falloir attendre que ces versions 2 se finalisent, que les composants CMS soit développés dessus et se stabilisent, pour pouvoir remplacer les bon vieux CMS comme Joomla, WordPress et Drupal par ces nouveaux produits plus efficaces. La question n’est pas savoir si WordPress, Drupal et Joomla vont disparaitres pour la production de sites mais la question est quand ? Pas avant 2012.
très bonne analyse des raisons pour lesquelles le code de Worpress et des autres sont une horreur à customiser. Facilement modifiable dans un premier temps, mais il faut être un expert dès qu’on déborde un tout petit peu du sujet.
point de détail : je ne sais pas pourquoi Zend Framework a mis framework dans son nom, ça ressemble vraiment plus à une librairie façon PEAR (j’utilise les 2 côte à côte d’ailleurs) qu’à un framework façon symphony auquel tu dois d’adapter pour créer des pages
problème de définition peut être ?
ces softs ont de beaux jours devant eux car honnêtement monter un blog wordpress aujourd’hui se fait à coup de souris, ce qui m’a franchement impressionné, moi qui code depuis toujours tout ce que je mets sur le Web. Cette rapidité et cette facilité fait que dans un environnement non-professionnel, ce sont de bonnes options.
Mais comme tu le dis, dès que l’on a des besoins spécifiques, on met le doigt dans une usine à gaz et c’est d’expert dont on a besoin. Et ça un client aura du mal à le comprendre et donc à l’accepter
Il y a framework et framework fullstack (comme symfony v1).
La différence notable entre PEAR et ZF, et plus généralement entre framework et librairies c’est la notion de couplage entre les composants : dans PEAR il n’en y a pas vraiment alors que c’est central dans le ZF.
Concernant SPIP, où vois-tu des globales dans les boucles ?
PS. On est preneurs de conseils avisés, car on a bien conscience de nos limites en ingéniérie logicielle. Vu qu’à la base on n’est pas des ingénieurs, mais des gens qui souhaitent publier sur le web, le plus facilement possible, et souvent sans budget.
Ah bé merci, je vais encore bien me faire voir de la communauté moi, si tu mets deux de mes articles pour illustrer ton chapitre « Drupal : l’hérétique » (ndlr: c’est pas interdit de mettre les liens direct, car je les mets souvent à jour :-)
Ceci étant dit, même si je suis moi aussi d’accord avec ce que dit Gauthier, se baser sur l’usage généralement fait d’un outil, drupal en l’instance, pour en déduire qu’il s’agit d’un simple système de prototypage est un peu rapide. De même se base sur les phrases chocs de Dries pour induire que ce n’est pas un CMS, est là aussi un peu réducteur. A ce rythme, java est juste un système permettant de faire des webservices…
Pour moi, Drupal EST un CMS (en tout cas autant qu’un Joomla si l’on part dans ce sens) qui vit au milieu d’un paradoxe, avec d’un côté cette croyance schtroumpfesque que l’on peut construire une application web à coup d’interface graphique, de l’autre un cadre applicatif efficace, même s’il est sûrement moins canonique et complet qu’un Zend framework ou Symfony.
Maintenant je suis moi aussi contraint de faire le triste constat que même pour ceux qui se disent développeur, c’est souvent la première approche qui l’emporte. La faute en revient sûrement à la facilité dans ce système de développer des modules pour tout et n’importe quoi (nous en avons tout de même plusieurs milliers) , induisant la croyance qu’en les enquillant les uns derrière les autres, on allait s’économiser spécification, conception, développement, test et maintenance, et surtout gagner beaucoup d’argent… Dans cet usage, Drupal est effectivement surtout un générateur d’usines à gaz.
Cependant, ces pratiques n’enlèvent en rien à l’outil ce qu’il est intrinsèquement. Ses API (form, schema, database, field, etc.) et son architecture modulaire type µkernel en font une plateforme solide pour qui désire développer et construire sérieusement son application. A titre d’exemple, pas un seul de mes sites n’utilise Views ou Panels (pour reprendre tes deux exemples), et ils s’en passent remarquablement bien (y compris mediapart qui n’est pas une petite bestiole).
En conclusion, Drupal est ce que vous en faite, ce qui est, je pense, le cas de n’importe quelle plateformes.
Enfi, il faut pas trop le dire, mais j’ai déjà vu de magnifiques hérésies développées en Symfony ;-)
« Tous les utilisateurs, contributeurs n’ont pas eu la chance d’être formé à la programmation orientés objets. »
Oui, tout comme d’autres n’ont pas eu la chance d’être formé à l’orthographe, hein…
Sinon, merci pour cet article synthétique et intéressant.
@yoran j’ai mis les liens originaux, je ne connaissais pas ton blog, bookmarqué.
Il est certain que Views et Panels rend la maintenance beaucoup plus complexe. On ne choisit pas toujours le code que l’on récupère. C’est dommage car on peut s’en passer. Même si son l’intégration de Views a fait grincer beaucoup de dents dans la communauté, le fait qu’il ne soit pas intégrer dans le core dans la version 7 est une bonne chose.
Il y a d’excellente idées qui proviennent de Drupal mais aussi de WordPress, Joomla, … . Cependant, les API n’ont pas la qualités de celles des frameworks, et cela rend le développement plus long et plus difficile.
Tu peut dire qu’il y a de magnifiques hérésies avec Symfony, comme avec tout autres outils, car cela reste un outil et la qualité dépend de la personne qui se sert de l’outil.
@antoine effectivement, je n’ai pas cette chance là, et je sais combien c’est difficile d’apprendre après coups. J’essaye de faire des efforts, visiblement pas assez. Merci pour cette piqure de rappel.
Analyse intéressante, je suis bien d’accord avec toi !
J’espère moi aussi que des outils basés sur des frameworks vont faire rapidement leur apparition.
Joomla seul CMS à proposer un véritable modèle MVC ?
http://www.spip.net/fr_article3497.html est un article qui justement indique comment étendre SPIP en respectant un formalisme MVC…
Sans vouloir manquer de respect à SPIP, le modèle est propre mais on ne peut pas vraiment parler de modèle MVC en parlant des répertoires action, exec et inc.
J’ai toujours un peu de mal avec de dire qu’une application utilise les patterns de la POO sans en utiliser la syntaxe. Je me trompe peut être.
Salut,
Effectivement les CMS basés sur un framework, qui plus est existant, commencent à être recherché depuis la courte apparition de ces frameworks et de la bonne structuration / industrialisation qu’ils apportent au fur et à mesure de leur maturation. Ces frameworks avec et basés sur le concept objet, sont les 2 éléments précurseurs de l’anoblissement du PHP par rapport à d’autres langages dit plus sérieux.
Sinon, que pense une personne avertie telle que toi du CMS TomatoCMS http://www.tomatocms.com/ , basé sur Zend Framework ?
Vraiment un très bon article, accompagné d’une analyse pertinente.
Ne pense-tu pas que les outils basés sur des frameworks peuvent devenir trop lourd? Ça oblige de passer à travers plusieurs niveaux de couches et les performance s’en voit réduites.
Bonne analyse effectivement. J’aurais bien aimé avoir un avis sur yacs. Peu connu mais qui, à mon avis interessé, mériterait que l’on s’y interesse
Tout réside dans ce qu’on veut faire.
Les CMS existants basés sur les frameworks Zend et autres sont des usines à gaz (en terme de poids et d’installations). Mais ils sont de véritables bijoux structurels.
Les « vieux » CMS (DP, WP, JOOMLA) sont certes moins bien écrits (c’est un euphémisme), plus lents (vive les caches soft et hard) etc…
Mais leur communauté est énorme. Et là faut juste ce rendre à l’évidence.
Donc arrêtez de faire de la propagande sur leur disparition. Perso a fait au moins 5ans que j’entends cela. Je pense qu’il est plus cohérent de parler de leurs futures évolution.
Les sites demandant du spécifique à foison sont et resteront la tête de proue des framework. Pour le reste, les vieux CMS resteront en place.
Désolé.
Je ne parle pas de disparition des CMS, je pense plutôt à une migration vers des CMS basé sur des frameworks. La direction prise par Joomla est certainement l’une des plus intéressantes.
Si disparition, il y a ce sera celle des mauvaises pratiques. Difficile de rester quand certain produit veulent maintenir artificiellement un modèle en place. Qui utilise encore aujourd’hui PHP-Nuke ou ses dérivées ? SPIP ne voit il pas ces parts de marchés décroitre ?
La situation est aujourd’hui très paradoxale, on forme des gens aux tout objet depuis 10 ans. Et quand, il arrive sur le marché du PHP : il faut qu’ils apprennent le procédurale. Il y a aujourd’hui plus de gens formés pour utiliser convenablement un framework que de gens pour utiliser convenablement les API d’un CMS. L’arrivé de PHP 5.3 qui permet de rendre plus professionnel le monde PHP ne date pas d’il y a 5 ans, et les frameworks ne sont pas pour l’instant des bijoux structurels. Il faut encore attendre qu’il prennent en compte les apports majeurs de cette version en terme de structure.
C’est l’une des grandes questions du monde PHP en ce moment, quelles directions suivrent ? Industrialiser pour récupérer les développeurs partis sous d’autres cieux (.NET, Java, Python, …) ou garder une image d’un grand amateurisme (dans le bon sens du termes) accessibles aux plus grand nombres.
Salut,
Je suis d’accord pour reconnaitre la supériorité du modèle objet sur le procédural, etc. Mais il y a une chose qui me défrise à chaque fois (et faire une permanente tous les jours, c’est pas top) c’est l’argument de la maintenance et de l’évolution des CMS codés « à l’ancienne ».
C’est le problème des développeurs du CMS, pas de ceux qui vont l’utiliser !
Par ailleur, je ne suis pas sûr que le modèle procédural de WordPress, par exemple, empêche les développeurs de plugins de le faire en modèle objet.
@bruno Il faut distingué 2 type d’utilisation des CMS. On peut soit l’utiliser en simple consommateur sans utiliser l’API, et dans ce cas il n’y a pas de problème d’évolution mais une limite dans les fonctionnalités proposées.
A part le blog de ma mère, je n’ai jamais eu l’occasion de mettre en place ce type de site.
En revanche, dès qu’on commence à utiliser l’API, on devient sensible au changement de l’API.
L’exemple le plus marquant est sans doute celui de Joomla : l’API a été modifié en profondeur entre la version 1 et la version 1.5. Sans utiliser le mode de compatibilité, les extensions ne fonctionnent plus. La version 1.6 va faire disparaître ce mode de compatibilité. Donc, il va falloir faire évolué les extensions pour coller à la nouvelle API.
C’est peut être juste une question de vocabulaire, mais à partir du moment où j’utilise les API d’un CMS, je suis un utilisateur, différent de l’utilisateur final mais utilisateur quand même.
L’utilisateur final n’est pas directement concernés, je te l’accorde mais les modifications du codes doivent à un moment donnée être financée et dans le cas d’extension bien spécifique, la facture est bien pour le client.
Sur les modules plus communautaires, un client va payer pour tous les autres, et il est fort probable que l’on hérite de l’évolution gratuitement.
En tout cas, merci pour la remarque, j’ai tendance à oublier ce type d’utilisation des CMS.
Great info thanks! What language is close to php as far as functionality and ease of use?
« On peut voir les CMS comme une solution qui permet de faire des sites vite fait à des prix discount. »
C’est bien pour ça qu’on les utilises ;)