- WordPress, Drupal : quotidien des CMS en agence
- Notre cadre d'usage : produire du complexe, rapidement et avec maîtrise
- Des prises en main fulgurantes
- Le puissant développement modulaire et ses risques
- Des outils standards manquants à l'appel
- Une exploitation et un support laborieux
- Notre conclusion : des lacunes à leur reconnaître pour maximiser leurs avantages
Avant toute chose, il est important de décrire brièvement notre cadre d’usage, afin d’être conscient que le regard exposé ici fait suite à notre pratique dite « agence ». Étape nécessaire afin de mieux éclairer pour la suite l’axe critique dans lequel nous nous positionnons.
CHOIX DU CMS PAR TYPE DE PRODUCTION
Au sein de l’agence web Opsone, notre raison d’être est de faire, produire, rendre réalisables des produits web et ce au travers d’équipes multiples. Certes pas autant que les usines du type « votre-site-en-1-clic », mais évidemment bien plus qu’une équipe dédiée à un projet unique.
L’usage de CMS peut sembler alors tout trouvé pour cette nécessité de quantité/réactivité. Car c’est bien là la promesse commune qu’ils se partagent tous (c’est écrit sur la boite) : créer simplement et/ou efficacement des sites web ambitieux et pérennes aux fonctionnalités (presque) sans limite.
Ainsi dès qu’un projet en arrive au stade de l’étape de qualification du socle technique, et que ses diverses variables le rendent éligible à l’usage d’un de nos deux CMS favoris, nous ajustons plus finement la solution CMS qui sera à retenir.
Les règles de choix ne sont pas aussi facilement énonçables qu’un bon théorème pourrait l’être mais globalement voici les grandes lignes :
WordPress : niveau de complexité globale faible, gestion de données métier peu stratégique, niveau de maintenance d’exploitation peu important. Vocation finale qui tend à s’orienter vers le « site vitrine ».
Drupal : site à plus forte vocation métier, nécessité d’une forte maitrise des rouages et données du système, niveau de sécurité et d’exploitation important. Vocation finale plus orientée « extranet » ou « site communautaire ». Ok mais alors Drupal 7 ou Drupal 8 ?
(- Si nous dépassons d’un cran les notions de complexités et de nécessité de contrôle (selon notre baromètre), nous sortons de facto de ce cheminement en actant inévitablement pour des solutions Framework type Symfony 3 ou Ruby On Rails.)
Si l’on a pas peur d’une bonne séance de torture, voici pêle-mêle quelques grandes étapes clés de notre démarche lorsque nous soumettons ces CMS à La Question :
- dans quel environnement technologique serveur le site devra t’il évoluer (avec quelles contraintes DSI va t’il falloir composer)
- le site nécessitera t’il de la localisation / traduction ( ie : le site est-il multilingue ? )
- le site est-il multi-domaine supportant de fait des sites satellites / sous-sites ?
- le site possède t’il des automatismes de quelques sortes que ce soit (e-mailing, tirage au sort…) ?
- le site se connecte t’il à des systèmes tiers et/ou envoie t’il/met-il à disposition des données à des systèmes tiers ?
- le site passera t’il un audit de sécurité ? Et si oui, notre commanditaire saura t’il faire la part des choses entre ce qui tient de la responsabilité du CMS (et ses problèmes inhérents) et ce qui tient plus de nos développements.
- quelle performance devra t’on délivrer en terme de charge, rapidité et accès concurrents ?
- quelle composition d’équipe sera amenée à oeuvrer sur le développement ?
- …
Globalement les développements qui nous sont confiés nous amènent à devoir envisager, dans 75% des cas, des réponses débouchant sur les solutions techniques les plus complexes à mettre en oeuvre.
CYCLE DE VIE
Pour compléter cette description du cadre, il faut bien noter que notre retour d’expérience sur ces outils s’articule temporellement de la sorte :
- débute dès la phase de conception,
- englobe bien évidemment toute la phase de développement
- et s’étend jusqu’à la phase d’exploitation du produit.
Cela va sans dire : chaque CMS ayant ses finesses, il convient de bien connaitre les spécificités des uns et des autres afin de préparer au mieux en amont l’architecture qui va suivre. Cela enfonce peut-être des portes ouvertes, mais on n’entame pas un chantier sans connaitre ses principaux outils.
Ceci étant posé, nous pouvons maintenant nous permettre d’aller déployer nos petits compagnons. Et grâce à toutes leurs belles promesses et à l’aide des modulothèques aux extensions à portée de clic on devrait – à priori – ne faire qu’une bouchée des développements les plus retors ! Alors ne perdons pas plus de temps et partons à l’assaut des installations !