Overblog Suivre ce blog
Editer l'article Administration Créer mon blog

Recherche

15 avril 2008 2 15 /04 /avril /2008 20:00

Avant de se demander quel CMS, expliquons déjà pourquoi un CMS ? En effet, on peut coder "from scratch" ou avec un framework ou un environnement de développement, comme Zend Framework ou Symfony.

En théorie, le système idéal serait un Framework qui implémente MVC (model/view/controller). Dans le monde PHP, c'est Symfony qui est un des plus prometteur dans ce domaine. Mais il y en a une bonne dizaine d'autres.

Il faut quelques jours (à temps plein) pour apprendre à s'en servir.
Par exemple, en suivant ce tutoriel, on arrive théoriquement à faire un site web 2.0 pour une durée estimée de 24 heures (soit une heure par jour pendant 24 jours) :
http://www.symfony-project.org/askeet/1_0/24
En dehors de PHP, la communauté la plus active est Ruby On Rail. On trouve de nombreux débats sur l'intérêt ou non de passer à Ruby. Mais comme PHP5 et PHP6 sont équipés pour être aussi efficaces que Ruby, et que l'on peut coder objet et MVC avec PHP, je n'étudierai pas d'autres pistes que celles construites avec PHP.
C'est bien noté que la productivité d'un développeur ROR est meilleure, toutefois cela reste à mesurer en prenant en compte tous les autres paramètres (par exemple : infrastructure technique du serveur, disponibilité de librairies et de codes, disponibilité des compétences).

La guerre des langages continue de faire couler beaucoup d'encre virtuelle, et c'est à mon avis une question complètement annexe. On se focalise inutilement sur le langage alors que les choix sont faits aux deux autres extrémités du problème. Pour faire simple, disons que ces deux extrémités sont l'infrastructure technique et l'IHM. L'infrastructure est déterminante parce qu'on ne choisi jamais vraiment sur quel serveur et avec quelles bases de données ou applicatifs existants le projet devra vivre. A l'autre extrémité, l'interface utilisateur et la qualité de l'implémentation des fonctionnalités est critique parce que c'est la seule chose qui compte vraiment pour les clients ou les utilisateurs. Et en général, ce sont eux qui payent.
C'est pourquoi il existe des projets en .Net, Java, Coldfusion, Flex, Flash, Zope, Ruby... etc.

Ce n'est donc pas PHP que je choisis, mais le fait d'avoir à ma disposition des serveurs administrés par des professionnels pour quelques Dinars, un choix d'applicatifs incroyables avec des interfaces web efficaces et innovantes. Mais surtout, ce sont des milliers de développeurs, webmasters, graphistes et entreprises sur lesquels je peux compter en cas de problème.

Je choisis l'écosystème PHP


Restons donc sur un chemin bien balisé : Linux, Apache, PHP, MySQL.
On trouve facilement les compétences, des projets réussis et les infrastructures sont disponibles.

Coder à partir de briques de base est effectivement la meilleure solution si on part de rien, si on dispose des ressources nécessaires et si on est un peu victime du syndrome NIH (Not Invented Here). Partir "from scratch" alors que justement, depuis Linux, toute l'évolution de l'Open Source vise à fournir des outils de plus en plus proches des besoins de l'utilisateur final est un peu paradoxal.
Justement, avec le nombre incroyable d'outils "prêts à l'emploi" il doit bien y avoir la perle rare !
Mais ce graal est bien une utopie. Il faudra rester pragmatique et faire des compromis. Soit.

Abandonnons ici l'idée d'utiliser un framework MVC ou le Zend Framework. Cela nécessite clairement des compétences professionnelles de haut-niveau et le recours à un prestataire spécialisé, freelance ou SSII.
Cela pose d'autre part le problème de la maintenance et de l'évolution de ce code. En effet, même si il est développé dans les règles de l'art, il faudra bien le gérer au quotidien et le faire évoluer.

Je choisis un CMS PHP

Je ne veux pas partir de zéro, même avec une librairie ou un framework. Je veux un système sur lequel je puisse réellement m'appuyer, et qui pourra être mis à jour. En clair, cela s'appelle un CMS : Content Management System, ou une variante d'un tel logiciel.

Il nous reste donc un grand nombre de CMS à tester. Quels critères pouvons-nous bien utiliser pour les départager ? Comment savoir si tel ou tel tout nouveau projet n'est pas la "killer app" de demain ?
Nous ne savons pas ce qu'il faut pour réussir à tous les coups, mais en revanche, nous avons une idée de ce qu'il ne faut pas faire.
Les critères déterminants sont :

  1. fonctionnalités, parmi celles dont on a besoin, il en faut le plus possible, y compris et surtout la possibilité d'avoir une IHM au top niveau,
  2. stabilité et robustesse, sans cela, on ne peut pas développer des compléments ni faire de paramétrages en confiance,
  3. modularité, pour pouvoir gérer des mises à jour et segmenter les problèmes, respecter la charte de codage et documenter son code,
  4. communauté, si il n'y a personne pour soutenir le projet et y contribuer alors il n'a pas d'intérêt. Les innovations vont beaucoup trop vite,
  5. licence libre : la possibilité juridique de l'utiliser et le modifier sans avoir de droits à payer.

Détaillons donc ces différents critères.

Version stable et exemples de sites en production

Le risque est très grand de partir avec un outil instable qui ne montre pas des sites opérationnels. Cela signifie inévitablement qu'il faudra se plonger dans de nombreux aspects du code pour compléter ce qui manque. On se place dans une situation très incertaine et surtout, on ne dispose pas d'un outil véritablement opérationnel, là, maintenant, tout de suite.
Les versions dont le numéro est inférieur à 1.0.1 sont en général à garder pour la veille technologique.
Les produits qui ne montrent pas au moins un site a fort trafic en dehors de celui de l'auteur du logiciel sont probablement suspects.
Nous pouvons donc exclure la grande majorité des systèmes, en assumant le fait que, peut-être, nous avons raté quelque chose d'exceptionnel. Mais on garde en veille ceux qui semblent les plus prometteurs.

Fonctionnalités

La liste des fonctionnalités minimales qui est demandée à un CMS est assez longue. Elle dépend évidemment de ce que l'on veut en faire mais l'indispensable est certainement :
  • Pages accessibles (SEO, RSS, CSS...). Un site qui n'est pas au minimum optimisé pour le référencement naturel est quasiment condamné à rester invisible. Il doit également être accessible pour tout ce qui va venir le visiter, en premier lieu les humains qui vont le regarder, mais aussi les agents, robots, téléphones mobiles etc...
  • Gestion des utilisateurs (inscription, rôles...). Comment imaginer un site web qui ne puisse pas s'adapter à mon cas particulier ?
  • Gestion évoluée des contenus (textes, images, sons, vidéos). Appelons cela des "contenus", même si ce terme est théoriquement à bannir. Mais il s'agit bien de fournir des informations à des clients, ou leur permettre d'en échanger. Il est peu probable que l'on puisse se satisfaire de codes ASCII ou HTML. Il est donc indispensable d'avoir des dispositifs efficaces de gestion de l'information (visualisation, tagging, arborescence, navigation, recherche... etc).
  • Interface graphique (possibilités de personnalisation). Pour jouer sur la corde sensible de vos visiteurs, les fidéliser, leur faire plaisir, vous devez être agréable à regarder n'est-ce pas ? Avant de vous lire, ils vous regardent. Et ils vont décider en quelques secondes. Si vous n'avez pas une interface soignée, vous n'avez pas tous les atouts de votre côté.

Si il manque un seul de ces éléments, le CMS est à oublier. Ensuite, on a besoin d'autres fonctionnalités, c'est pourquoi il est important de les préciser avant de commencer à répertorier les CMS candidats. La différence peut se faire sur des détails mais aucun compromis n'est possible sur les points précédents.
Les besoins peuvent être par exemple : géolocalisation, affichage sur un mobile, gestion de formulaires, bases de données, de documents, exportations et importations, génération de documents, workflows, édition, wiki, forum, images et photos, streaming vidéo...
On voit très rapidement que le nombre de détails et de fonctions à mettre en place sur un site web est très rapidement énorme. Plusieurs centaines d'éléments sont à orchestrer pour le moindre site. Cela milite donc encore plus pour l'utilisation d'un CMS mature. Est-ce que je suis sûr de pouvoir coder tout cela moi-même avec Zend Framework, CakePHP ou Symfony ? Ok, demain, sans doute...

Modularité

Le système doit apporter toutes les fonctionnalités requises pour un site web en ce qui concerne son interface tout en étant codé de façon irréprochable. Cela fait deux critères mais qui se rejoignent. Un système de modules ou de plugins s'avère indispensable pour configurer des fonctionnalités avancées, parce que tout le monde ne veut pas les mêmes. Mais un tel système est très complexe. Il est donc indispensable de se prémunir contre les bugs, les incompatibilités et les dégradations de performances en utilisant un code très structuré.
Excluons donc tous les systèmes pour lesquels les avis de professionnels sont négatifs ou mitigés en ce qui concerne la qualité du code.
Des mots clefs comme "API" et "XML" sont difficile à ignorer. Si la documentation du logiciel ne mentionne rien sur ces sujets, il est probable qu'il ne soit pas très modulaire.
Parce que justement, il restera toujours quelque chose de spécifique à coder, il est vital de disposer d'une infrastructure modulaire. Cela permet de préserver la possibilité de mise à jour de l'application et la mise en place de fonctions spécifiques. Ce sont les compromis faits pour satisfaire ce dilemme majeur qui sont déterminants. Et c'est donc sur ce point que l'on peut juger de la différence entre plusieurs CMS. On voit donc que selon la finalité et la complexité des projets, on doit bien sûr préconiser des CMS différents.
Il est également important de constater que les modifications et adaptations "sauvages" ou tout simplement non documentées d'un CMS ne permettent pas de s'en sortir dans la durée.
Cela peut provenir de l'équipe de développement, qui n'a pas le temps ou les compétences disponibles, ou du CMS, qui n'est pas assez paramétrable pour y implémenter les fonctionnalités demandées.

Communauté

Un logiciel Open Source avec une licence libre ne peut vivre qu'avec une vaste communauté d'utilisateurs et de développeurs. Une communauté internationale est donc un signe de vitalité d'un projet. Les CMS qui sont uniquement francophones ne peuvent pas espérer rivaliser avec les autres parce qu'ils n'arriveront jamais à regrouper assez de compétences. A contrario, il est important de disposer d'une communauté d'utilisateurs francophones qui s'affiche. Cela est au moins la preuve que le logiciel en question fonctionne en français.
La diversité de la communauté est très importante. On ne pourra rien faire si il n'y a que des informaticiens. On ne pourra rien faire non plus si il n'y a que des graphistes. Il est utile aussi de ne pas être trop marqué par une communauté métier, par exemple le monde de l'éducation (Moodle, Elgg...) ou les journalistes (Spip). A long terme, cela représente beaucoup de risques.

Open Source avec Licence Libre

Si on ne prends pas un outil Open Source, on se retrouve dans un des cas précédents où l'on dépend d'un prestataire pour faire évoluer son produit. Eliminons donc tous les produits qui ne sont pas vraiment Open Source, c'est à dire qui ne sont pas développés par une communauté libre qui affiche clairement son objectif de pérennité de la licence. Bien entendu, cela n'exclus pas des services professionnels autour du projet, comme par exemple Zend et PHP. Mais les projets supportés exclusivement par une entreprise ou qui ressemblent à des versions de démonstration pour tester le marché sont à éviter à priori.

Déploiement, installation et exploitation

Enfin, je rajoute quelques points qui ne sont pas forcément cruciaux, mais qui peuvent avoir leur importance. Est-ce que l'on dispose d'un système d'installation ou de configuration automatisé ? Quelle est la taille du logiciel ? Est-ce qu'on peut l'installer sur un hébergement mutualisé classique ? Est-ce qu'il existe un système de mise à jour, de gestion de versions ?
Bref, quand la versions .gz du logiciel fait plusieurs dizaines de Mo, qu'il faut modifier la configuration de Apache et installer des logiciels spécifiques sur le serveur, il est nécessaire de bien vérifier si c'est de ce logiciel dont on a besoin.


Liste des CMS PHP candidats


Comment construire cette liste ? Par chance, il y a beaucoup de journaux et de sites web qui répertorient les CMS PHP.
Ceux qui ont une antériorité suffisante, c'est à dire quelques années, sont assez visibles sur le web pour que l'on puisse en faire la liste.

Nous avons donc : Spip, Joomla, Typo3, Drupal, CMSMadeSimple, PhpNuke, Guppy, ModX, EzPublish, Midgard.
En ajoutant deux logiciels supplémentaires : Wordpress et DotClear, parce que cela peut servir à faire des sites web simples.
Et enfin, un ajout du mois de mars 2008 suite à un commentaire avisé : Xoops.
Signalons également ici Elgg, parce que c'est un logiciel de gestion de communauté qui est basé sur les technologies des blogs et qui est très prometteur.

Cette liste est provisoire et elle devra être revue avec les logiciels PHP les plus utilisés.
Les autres logiciels potentiellement polyvalents mais non retenus ici sont :
  • Les wikis
  • Les logiciels de e-commerce
  • Les héritiers de PhpNuke tels que Xoops
  • Les groupwares divers, logiciels de gestion de projet, outils collaboratifs (Simple Groupware...)
  • les logiciels d'enseignement à distance (Moodle...)

Il y a aussi ceux que je n'ai pas testé en détail récemment (comme par exemple Copix) où ceux dont j'ignore l'existence. Rien que sur Sourceforge, on trouve plusieurs centaines de projets de CMS PHP.


A partir d'ici, c'est à vous d'écrire la suite, mais donnons un exemple :

Eliminons...


  • Les plus anciens, réputés "usines à gaz", pour lesquels le travail d'apprentissage et l'investissement en temps n'est probablement pas à la hauteur des résultats par rapport à une approche radicalement innovante (ROR ou Symfony). On enlève donc Midgard et Typo3, malgré tout le bien que l'on peut en penser.
  • On enlève aussi PhpNuke (et presque tous ses clones) parce que la recette n'est plus à la mode et à cause de trop de problèmes d'architecture.
  • Les plus simplistes ou incomplets ou trop jeunes sont également à retirer : Guppy, ModX, CMSMadeSimple.
  • Spip, par son côté trop franco-français et son système de méta langage est également exclus. Trop spécifique et probablement vieillissant. C'est quand même une solution très bien adaptée aux "sites éditoriaux".
  • Wordpress reste un bon candidat pour réaliser des blogs ou des sites de quelques pages. On le retire tout de même de la liste. Même si pour certaines fonctionnalités il est possible de trouver des plugins incroyables.
  • Elgg est un framework d'applicatif web de réseau sociaux très prometteur mais encore instable et avec une communauté balbutiante. Pour un vrai projet en production, c'est un risque trop important à prendre. Il est donc exclus provisoirement.
  • Les logiciels conçus pour publier des blogs s'avèrent très performants comme CMS simples. En dehors de Wordpress, DotClear est également une très bonne solution. Mais même si l'on peut pousser les limites du blog à l'extrême et utiliser ou programmer des plugins très particuliers, dans certains cas, cela sera insuffisants.
  • EzPublish est une solution complète avec un support francophone très actif.  eZ publish intègre en standard des fonctionnalités comme le e-commerce. Les eZComponents en font un framework qui ressemble par certains aspects à Symfony ou Zend Framework. Cela reste une solution assez lourde. Le code source fait difficilement moins de 30 Mo.
  • Reste le duo Joomla et Drupal. D'après les rumeurs des blogs de geeks, sur la robustesse et la solidité, c'est Drupal qui l'emporte. Pour la facilité de prise en main et la rapidité de déploiement, c'est Joomla. Pour un projet conséquent et avec des fonctionnalités spécifique à intégrer, c'est donc Drupal qui l'emporte.

En conclusion


Le meilleur candidat pourrait être Drupal dans la catégorie "CMS classique". Pour un site encore plus complexe il y a donc eZ Publish. Et pour un site plus simple, Wordpress.
Ce n'est pas encore gagné, il reste à mettre en place un prototype pour vérifier que toutes les fonctionnalités souhaitées peuvent être implémentées avec cet outil. Plusieurs jours sont nécessaires pour installer une plateforme de test, identifier les modules à installer, apprendre à configurer le système, mettre en place les interfaces et les thêmes... etc.

Reste donc à vérifier si ce choix correspond à mon projet web. Et c'est donc ici que je m'arrête. Parce que pour répondre à cela, il faudrait définir ce projet et vérifier comment implémenter chacun de ses éléments. Sachant qu'il y aura plusieurs façons de le faire...

Les CMS cités ici sont tous très utilisés et restent de très bons choix. Mais vous devrez constituer votre propre grille d'analyse en fonction de vos besoins et de vos ressources.
Source http://www.phpfrance.com

Partager cet article

Repost 0

commentaires

Trinoo 14/09/2009 12:32

Bien que mon commentaire arrive avec 17 mois de retard, l'Article est très interessant, c'est le tri selectif parmi tous les languages et frameworks pour finaliser avec Drupal qui est amusant à lire.Je ne suis pas d'accord avec ta vision concernant les MVC. Le MVC excellent dans la facilité de la maintenance et de l'évolution de l'application sans se heurter à un mur ou se retrouver dans un cul de sac.Il est certain que ça demande un temps d'apprentissage au début, mais par la suite ça sera un gain de temps considérable.Il y a toujours un compromis entre l'accéssibilité, la souplesse et les performances.Si on reste dans le domaine de PHP, Typo3 ressemble à une usine à Gaz par rapport à Drupal, mais une fois maitrisé, il peut même nous préparer le café le matin. Je pense qu'il faut faire des petites ballades de temps en temps pour explorer d'autres technologies et solutions de développement, ne pas être imperméable à ce qui est different.La migration vers une autre techno après des années de travail est une opération très couteuse, Mais quand on voit l'exemple de NUXEO qui ont abondonné Python et toute la communauté francophone de ZOPE pour se diriger vers Java. C'est qu'il est temps de changer la voiture et d'en acheter une neuve. Reste à voir si c'était un bon choix, quand on voit qu'ORACLE à racheté SUN.Pour moi le meilleurs CMS qu'on puisse avoir, c'est celui qu'on developpe soit même, ça ne sera pas productif, mais certainement le plus optimisé pour le référencement naturel quand on est un connaisseur dans le SEO.Merci pour ce comparatif de technologie, bien que nos avis divergent.Bonne continuation! 

Articles Récents

Liens