La question de savoir si un site doit être développé avec un CMS ou un framework est l’une des plus posées et traitées dans le monde du développement web. Il n’existe pas de technologie ultime permettant de tout faire de manière optimale. Chaque outil, créé pour le développement, répond initialement à une demande spécifique à laquelle aucune autre solution pré-existante ne semblait répondre convenablement.
Qu’est ce qu’un CMS ?
Les CMS (Content Management System) sont des outils / logiciels offrant des fonctionnalités livrées clé-en-main et rapidement installables. Ils permettent de développer un site vite et à moindre coût. Le peu d’efforts nécessaires à leur mise en place les rend accessibles sans avoir besoin de connaissances techniques poussées. En revanche, leurs avantages font aussi leurs inconvénients. Le fait d’avoir des fonctionnalités déjà développées les rend plus difficilement modifiables et, leur accessibilité au plus grand nombre, en fait généralement des outils moins performants et optimisables.
Les CMS les plus populaires sont (ils sont en PHP):
Qu’est-ce qu’un Framework ?
Les frameworks sont le plus souvent constitués par un ensemble de librairies correspondant aux tâches les plus redondantes et fastidieuses du développement. Elles permettent à des développeurs de se concentrer sur les fonctionnalités spécifiques à un projet. Leur architecture est bien plus flexible que celle des CMS et leurs fonctionnalités plus avancées. Les frameworks s’adressent à des développeurs de plus haut niveau et ont eu un rôle éducationnel indéniable en apportant au monde du développement des pratiques visant à en améliorer la qualité : tests de qualité, outils de déploiements automatisés, bonnes pratiques, développement orienté objet, optimisation de cache…
Les Frameworks parmis les plus populaires sont :
- Django en Python
- Symfony, Zend en php
- Ruby on Rail en Ruby
Que choisir?
Le choix de l’outil dépend principalement de deux facteurs :
- quel est la taille du projet ?
- quels sont les besoins d’optimisation ?
La facilité de mettre en place un CMS induit très souvent en erreur. Beaucoup de responsables de projets, pensent que parce que les coûts de développement sont inférieurs dans les tous premiers temps, il en sera ainsi de la maintenance. Ce n’est pas le cas.
En général, pour un projet de plus d’une vingtaine de jours, il est plus avantageux de construire l’application / site autour d’un framework. Un délai plus long sur un CMS implique des développements et des besoin d’adaptation conséquents qui vont au-delà de la simple installation de modules et de l’intégration du design interactif. Dans ce cas, un framework sera dans la majorité des cas aussi rapide à mettre en place. Il offrira , en outre, des avantages conséquents de flexibilité, de stabilité et de performances.
Il est très important de prendre aussi en compte le fait que la plupart du temps, on a tendance à ne voir que le coût de développement initial. Or, si un site se développe en quelques mois, sa durée de vie se compte en années, au cours desquelles de nouvelles fonctionnalités devront être implantées. Il faut s’assurer que si on part sur un CMS les mises à jours seront peu complexes à mettre en place. Ce qui est rarement le cas.
Enfin, il faut aussi étudier le besoin de performances de son site. Si on prévoit un gros volume d’accès, les possibilités de caching et l’architecture plus puissantes des frameworks répondront mieux à la demande. Certes un CMS est capable de tenir des grosses montées en charge, mais cela implique souvent un coût en infrastructure serveur supérieur, qui à terme le rend plus coûteux qu’un framework.
Certains CMS évoluent vers des framework
Aujourd’hui, la séparation entre les deux systèmes tend à s’amenuiser. Par exemple, Drupal dans sa version 8 à clairement décidé à se rapprocher des frameworks en changeant radicalement son architecture et en la basant sur Symfony 2. Apparaissent aussi des outils, tel que Centurion, qui se définissent comme des CMF (Content Management Framework), à mi-chemin entre les deux univers.
PS: Je précise que si dans notre équipe, Django, Symfony et Ruby and Rail ont notre faveur, nous développons et maintenons aussi beaucoup de sites en Drupal, Worldpress et Joomla… ainsi que d’autres technologies comme celles pour des applications natives pour iOS et Android.
About Guillaume Pousseo
En tant que Chef de la Technologie, Guillaume est tourné vers une démarche de qualité et d’optimisation des développements et il apporte à RevSquare son savoir-faire et ses connaissances en matière de programmation, d’architecture et de management de projets informatiques. Il gère aujourd’hui une équipe de plus d’une cinquantaine de développeurs Web et Mobile. Pour en savoir plus.
Personellement, je crois que l’utilisation d’un framework peut considérablement ralentir un projet à grande charge.
Bien entendu , chaque projet est différent. Lorsque la vitesse/performance est ultra prioritaire (dans presque tout les projets), il faut développer des solutions “custom” en utilisant du “low level” le plus possible.
Un framework serait viable pour facilité le travail en équipe ou pour une rapidité de développement? Si tel est le cas des développeurs , une sérieuse restructuration s’impose.
Je suis d’accord pour l’application des tests unitaires etc .. Cependant ces test peuvent bien s’implanter en solo.
Un framework rajoute beacoup de “processing”, de “validation”, des cycles perdu si codé correctement. Ensuite, vient les ORM, je serais curieux de savoir combien de gens utilise des DB différentes d’ou la vrai utilisation d’un ORM serait nécessaire. Le client au final suivra toujours les recommendations du fournisseur.
Le CMS servira seulement si il y a un client qui doit utilisé/modifié sur réception et utilisation du produit. Sinon il existe aucun autre avantage VS un framework. Par ailleur, la plupart des frameworks fournisse un outil de création automatisé des interface de gestion (admin backend).
Bref, voila mon avi.
Bonjour Mathieu,
Merci beaucoup pour votre commentaire. Je suis d’accord avec vous sur l’aspect des performances.
Néanmoins, et vous avez raison de le souligner, tout dépend du contexte. Dans le cas d’une agence digitale, la première demande d’un client est souvent le délai de livraison court et les coûts. Il est alors opportun d’utiliser des solutions “out of the box” qui permettent d’avoir à disposition des librairies déjà développées. Le choix se résume donc souvent à CMS vs Framework. Une solution custom serait plus longue à mettre en place, à débugger et à documenter (il est capital que le client puisse s’affranchir de son prestataire s’il le souhaite).
Sur des projets réalisés en interne, je pense que le framework peut aussi être un bon choix dans certains cas. Certes, il demandera plus de processing, mais ce désavantage est comblé par d’autres facteurs.
Je pense qu’il sera plus facilement maintenable car il permettra d’intégrer plus facilement de nouveaux développeurs dans l’équipe. La période de “ramp up” est nettement moins grande quand on peut recruter un développeur ayant des expériences sur un outil que quand il faut qu’il l’apprenne “from scratch” (avec tous les risques de mauvaises pratiques au début qui peuvent alourdir le code et affecter sa stabilité).
Il permet d’avoir une architecture et des modules testés à très grande échelle qui garantissent une stabilité et des performances. Quand on part sur un modèle custom, il n’est pas toujours certain que l’architecture s’avérera efficace sur le long terme. C’est un risque à vraiment considérer.
L’orm fait partie de ces avantages de maintenabilité. Je ne suis pas tout à fait d’accord avec vous que sa “vrai utilisation” soit de passer d’un sgbd à un autre. Il est vrai que le système peut être relativement gourmand. En échange, l’abstraction en code OO permet une architecture bien plus facilement évolutive et contributive. En outre elle s’accompagne de fonctionnalités telles que les migrations qui permettent de versionner les évolutions d’une base de données qui sont extrêmement pratique et sécurisantes pour les déploiements en production. Pour finir, si il est rare de changer de sgbd au cours d’un projet, l’usage de l’ORM permet de s’affranchir des versions et de pouvoir facilement intégrer des mises à jours et évolutions.
De plus en plus, les frameworks deviennent plus des librairies que l’on peut ou non charger plutôt qu’un outil monolithique qui impose des fonctionnalités inutiles qui pourraient alourdir l’application. En outre, avec une bonne utilisation des systèmes de cache il est possible d’optimiser le processing assez aisément. Et, pour finir, le framework peut s’adjoindre de langages plus low level tel GO pour les briques nécessitant le plus de performances.
Bref, le framework peut être plus gourmand qu’une solution développée maison. Mais il offre souvent une plus grande maintenabilité et une architecture pérenne. Ce sont à mon avis des avantages conséquents sur un projet d’envergure car ils assurent stabilité et flexibilité à long terme. Mais, bien sûr, le plus important est de toujours bien regarder les spécificités d’un projet. Il n’existe pas d’outil ou de solution ultime! Il ne faut pas négliger non plus l’équipe et ses capacités. Un outil peut être magnifié ou défiguré… Tout dépend de ce que l’architecte et les développeurs en feront
Dans le cas d’un blog ou d’un site “plaquette” avec des fonctionnalités simples et proposées nativement par l’outil, le choix du CMS est le bon. On installe l’outil, on définit le design et les profils utilisateurs, on active les widgets utiles et on donne la main aux contributeurs.
Si on s’arrête là, c’est qu’on a fait le bon choix.
Mais si on commence à vouloir “adapter” le CMS à son métier, utiliser des widgets maisons et modifier des fonctionnalités du CMS, on a tout faux.
Sans compter l’important besoin de formation des équipes pour avoir une maitrise parfaite, le choix d’un CMS sur un grand projet peut être aussi très coûteux aussi en terme d’infrastructure. Pour la refonte d’un site (initialement en PHP/Mysql maison), nous sommes passés de 2 à 9 serveurs avec des fonctionnalités moindres et des performances nettement inférieures.
En cette période où les systèmes se multiplient (Tablettes, smartphones…), un autre élément important (et trop souvent oublié) dans le choix d’un CMS est le format des données et leur accessibilité. Si certains CMS utilisent des structures relativement simples (articles, produits, users …) certains CMS poussent la notion objet à l’extrême (une version d’un champ de données = 1 enregistrement) multipliant ainsi de façon considérable les requêtes et temps d’accès et rendant quasiment impossible la réutilisation simple de ces données hors du CMS.
Le développement d’un projet complexe avec une bonne structuration et en utilisant des librairies évolutives (Framework ou autres) sur une base de données structurée selon son métier reste pour moi la meilleure des solutions.