• 15 mai 2017
  • GLEN DÉLÉZIR
  • News

Wordpress, Drupal : quotidien des CMS en agence

- 1 -

 Wordpress, Drupal : quotidien des CMS en agence

INTRODUCTION

Les années passent, et il faut bien se l’avouer les technologies web aussi. Face à ce (facile) constat de contexte en perpétuel renouvellement et effervescence, nous pouvons nous étonner de ne finalement pas voir notre champ lexical réellement amputé de certains termes remisés aux oubliettes. Quoiqu’on en dise PHP est toujours solidement ancré dans la boucle ainsi que moultes de ses vaillantes engeances (WordPress, Drupal, Joomla, EZpublish…). Si les effets de mode ont eu grandement raison de certains (SPIP), la plupart, au gré des sacro-saintes mises à jour majeures, ont réussi avec plus ou moins de succès à grandir dans la continuité du web afin d’être toujours présents dans cette course sans ligne d’arrivée visible.

Et, nous ouvriers du web, et usagers à temps plein de leurs complexes rouages (mais aussi colporteurs de leur bonne parole, de foi ou de force), quel regard « 2017 » peut-on se permettre d’apporter sur leurs états actuels et évolutions à venir ? Derrière les promesses marketing, comment ces outils nous servent-ils réellement au quotidien pour ériger ce à quoi ils sont voués : la réalisation des objectifs et desiderata du client ?

Afin d’essayer d’apporter un petit bout de réponse à cela, mais sans toutefois avoir la prétention de dresser un tableau balayant complètement le microcosme des CMS, nous allons ici établir une petite retrospective de notre quotidien en compagnie des deux principaux outils de gestion de contenu qu’il nous a été donné de pratiquer ces dernières années. Et j’appelle donc à la barre :

  • le Blog devenu CMS, autrement nommé WordPress
  • Drupal le mi-CMS, mi-framework (aka le CMF donc), au travers des 2 demi-frères Drupal 7 et Drupal 8
 wordpress-logo-notext-rgbdruplicon-large

Pour ce faire nous vous proposons d’entamer ce retour d’expérience par la présentation de notre cadre d’usage.

 

- 1 -

Notre cadre d'usage : produire du complexe, rapidement et avec maîtrise

 

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 !

 

- 2 -

Des prises en main fulgurantes

 

DÉPLOIEMENT INITIAL RAPIDE : A VOS MARQUES, PRÊTS…

WordPress / Drupal 7 et 8 : un téléchargement, une décompression, une base de donnée prête à la connexion… Et voila !
Les installeurs font leur travail et le socle de base est activé relativement rapidement. Pour peu qu’on sache exactement quelles nouvelles fonctionnalités ajouter via les extensions, il est raisonnable à ce stade d’être extrêmement optimiste sur l’aspect “temps consommé” pour pouvoir proposer des prestations assez étoffées fonctionnellement et très accessibles à nos divers clients. Ne reste plus pour ainsi dire qu’à orienter la fin des recherches vers le thème du FrontOffice et nous tiendrons notre nouveau site rien qu’à la force des installations.
Bon vous l’aurez évidemment compris on reste ici du cas de figure d’un site de « démonstration » qui n’existe que trop rarement dans les contes de Wéebs. De mémoire de « faiseur du web », un tel scénario ne se produit qu’une fois tous les 100 ans.

Mais quoiqu’on en dise force est de constater : les fichiers se déposent vite et on a l’impression d’avoir rapidement des tours de contrôle prêtes à l’emploi pour la suite. Car oui, si l’on parle bien de suite, c’est que nous n’en sommes en réalité qu’au commencement et qu’une tour de contrôle, comme son nom l’indique, c’est destinée… à contrôler. Donc allons contrôler. CQFD.

BACKOFFICE INTÉGRÉ ET PRISE EN MAIN ADMINISTRATIVE RAPIDE… OU LE CONCEPT DE LA PROGRAMMATION EN UI !

Ces outils ont l’avantage certain de proposer une Interface Utilisateur embarquée tant pour la partie administration (BackOffice) que pour la partie publique (FrontOffice). Le backoffice est généralement à prendre tel qu’il est. Et le frontoffice est lui prévu plus adaptable car facilement remplaçable par le biais des « thèmes ».

WordPress : L’interface backoffice est assez simple et épurée et se montre rapidement efficace quand il s’agit de la présenter au client pour qu’il puisse prendre les contrôles de sa propre partie à savoir les saisies éditoriales. Toutefois attention aux modulivores : gros risque de transformer votre backoffice en arbre de noël suite à une séance de shopping d’extension trop effrénée. On adorera (ou pas) ces éléments de pubs qui s’ajoutent à côté des options clés par exemple. Et puis que dire de cette grande liberté de monter des interfaces n’ayant rien à voir d’une extension à l’autre ? Peut-être pour rendre les sessions d’administration moins rébarbatives ? Mais non, nous ne serons pas mauvaise langue et laisserons les usagers se faire leur propre idée sur ces aspects.
Pour sûr : nous ne lui enlèverons pas sa qualité indéniable d’être accessible aux webmasters les plus débutants.

Drupal 7 / Drupal 8 : Côté Drupal, l’interface se montre aussi efficace, quoique plus complexe. Ses codes sont plus rigoureux et ne se prêtent pas trop aux élans créatifs des développeurs BackEnd en pleine crise d’ergonomite aiguë. Cela rend un outils certes moins « sexy », mais globalement moins déroutant lorsqu’on passe d’un module à l’autre. Tout du moins pour l’aspect « de prime abord ». Car le grand dilemme du Backoffice Drupal est d’arriver très rapidement à écarter toute une couche de la population des divers profils webmasters amener à interagir sur le dossier. Seule une partie très restreinte du backoffice restera alors humainement compréhensible (au gré de quelques efforts de paramètrage supplémentaires de surcroit), poussant l’outils vers une frontière dangereuse où seuls les programmeurs du projet finiront par s’y retrouver dans leur création. Et si l’on pousse trop loin le bouchon, il sera alors impératif de palier cette complexité à grand renfort de documentations spécifiques. Point qui peut s’avérer évidemment tout à fait entendable si bien anticipé en amont.

Globalement, on saluera ces outils pour faire l’effort de proposer quelque chose « in core » là où les développements framework bas niveau nous imposent des chantiers entiers de façonnage concernant les interfaces de l’administration à proposer. Seule recommandation ici : connaitre (et faire connaitre) les avantages, risques et limites de ces interfaces toutes prêtes pour ne pas générer des frustrations/frictions inutiles tant chez le client que chez le prestataire aux commandes du développement.

Et maintenant allons regarder sous le capot du côté du développement comment nous allons bien pouvoir réussir à ajuster précisément l’outil à ces quelques demandes clientes qui ne semblent pas rentrer dans les cases…

 

- 3 -

Le puissant développement modulaire et ses risques

 

LES MODULOTHÈQUES / EXTENSIOTHÈQUES : LES MEILLEURES ALLIÉES ENNEMIES

Point d’orgue de ces CMS : proposer à la communauté des codeurs, des possibilités d’étendre la base du moteur initial. Il y a en effet pratiquement un module pour tout. Sauf évidemment pour les « petits » ajustements du client, mais ça l’histoire aura tendance à l’oublier. Donc oui si ces modules peuvent aller du simple ajout automatique de bouton de partage social, jusqu’à l’ajout d’une boutique e-commerce entière, il ne faut pas perdre de vue que cela fera les choses telles que l’ont décidé les auteurs et que toute modularité de facade avancée, elle n’en sera forcement que toute relative. On dit que c’est dans le détail que se cache le diable… et bien malgré le côté séduisant de la vitesse d’amorce citée ci-dessus, c’est bien à ce stade que les choses vont se compliquer, car des détails il va assurément en pleuvoir.
Et l’ajout massif et sans limite des modules, sera certes grisant, mais rendra les derniers mètres pour atteindre le nirvana “du comportement fonctionnel ultime” d’une longueur interminable.

WordPress : nous avons ici des modules au kilomètre pour satisfaire les désirs fonctionnels les plus fous. Contrat rempli de ce côté vous pouvez foncer tête baissé.
Mais, tout de même, petites spécificités des extensions de WordPress :

  • La qualité du code extrêmement variable de la programmation de ces extensions. Surtout ne cherchez pas à afficher les erreurs PHP sous peine de commencer à douter du bien fondé de votre choix de CMS (que nous haïssons ces moments de doute où l’on re-vérifie par deux fois si l’on n’a pas récupéré par erreur une version en branche DEV). Et donc par la même, vous allez finir par vous questionner sur votre capacité intrinsèque à faire cohabiter vos sacro-saints principes dans l’outil : pourquoi se debugger quand l’outil lui-même nous parasite. Les logs d’erreur seraient-ils passés de date de nos jours ?

 

  • La compatibilité erratiques des extensions. En effet, après le code spaghetti, on apprend ici à relever un peu le goût avec le code spaghetti aux Hooks. Alors pour ceux qui ne connaissaient pas, c’est une recette extrêmement conviviale qui permet de mettre un peu de tout et surtout n’importe quoi dans la marmite. Pour au final aboutir sur l’assurance de brouiller toutes les saveurs. Là encore, prévoir des grands moments de doute, et des appels à l’aide réguliers aux super-debuggeurs des alentours. Cela va sans dire : éviter de trouver des extensions qui se marchent sur les fonctionnalités : elles ne feront pas du tout bon ménage. Pire encore elles pourraient même bien cacher leur jeu jusqu’à la fatidique découverte de données frauduleuses sournoisement entrain de se jouer de vous.

 

  • Le système de licence alambiqué. Les extensions de nature gratuite qui s’entremêlent avec des extensions aux divers systèmes de licences payantes (par domaine unique, multi-domaine, par clé…) rendent extrêmement confu la maintenance du site en organisation prestataire/client. Et complexifie par la même d’un sacré degré l’usage d’environnements multiples (vous savez, les fameux trois frères, DEV, STAGING, PROD).

Drupal 7 : La aussi plutôt conséquente pour ce CMS, on appréciera, par rapport à son voisin WordPress, le niveau de sérieux/qualité plus élevé des programmes proposés. Basé sur des concepts similaires (les hooks) on retombe parfois sur des travers partagés, mais la structure proposée laisse déjà moins de place aux fantaisies les plus déraisonnables.

Drupal 8 : Alerte spéciale concernant cette nouvelle version du CMS. Changer le moteur en profondeur expose bien évidemment la communauté à opérer une grosse courbe de ré-apprentissage. Et de fait les modules mastodontes ne s’en retrouvent pas du tout tous exploitables à l’heure actuelle. Et l’on apprend ainsi honteusement à pousser un « ouf » de soulagement quand une version APLHA (ou DEV …) pointe le bout de son nez sur la page officielle du module (ou sur un GIT non officiel…). Résultat Drupal 8 est certes plus puissant, carré, moderne, pro etc etc … mais ne permet pas pour l’heure de revendiquer une modularité à toute épreuve comparée à son ancêtre version 7. Tout du moins pas dans le cadre d’un CMS « prêt à websiter » tel qu’on nous le vend au travers du message Drupal.

LES THÉMOTHÈQUES

Sur la même base que les modules/extensions, nous pouvons trouver sur les sites spécialisés un large choix de thèmes disponibles pour habiller en 2 clics nos FrontOffices.

WordPress / Drupal 7 : Ici c’est assez simple, nous pouvons reprendre les mêmes freins et remarques que ci-dessus. Les expériences de déploiement sont plus au moins agréables en fonction des qualités de confection de ces bouts de code. Attention à ne pas céder trop vite aux appels des sirènes de l’économie de temps et de budget sur ce poste du développement :

  • une adaptation d’une base n’est pas toujours facile… et peut finir par devenir au final plus chronophage que d’avoir fait le choix initial de créer son propre thème « from scratch ».
  • il faut bien garder en tête qu’un thème dans ces systèmes CMS est loin de n’être qu’une intégration CSS. Ce qui peut poser d’énormes problèmes de compatibilité avec l’ensemble des modules mis en place, et lors de la future procession des mises à jour core/module qui aura inéluctablement lieu.

Drupal 8 : Qui dit Drupal 8, dit Symfony, dit Twig. Autrement dit un nouveau système de template « optimisé pour » en sus et place du bon vieux template à la mode PHP. Ici pour notre expérience concrète sur la question, fort de notre expérience passée sous Drupal 7, nous avons fait le choix d’acter pour le portage du système de thème Zen. A bien comprendre qu’il ne s’agissait pas de profiter de la beauté toute figée d’un thème « prêt à déployer », mais plutôt de rester dans le cadre d’une proposition d’implémentation et de structures afin de réaliser notre propre création. Et la ce fut la stupeur. De souvenir d’une simplicité limpide… nous sommes tombés dans un délire hiérarchique total à la complexité que nous trouvons finalement peu justifiée. Nous mettrons notre choix stratégique sur le coup d’un jugement maladroit et on ne nous y reprendra certainement pas. Force est de constater : les bons tuyaux de Drupal 7 ne seront clairement pas ceux de Drupal 8. Mais c’est dans le fond normal : l’outil change ses bases et ça lui donne une sacré bonne excuse !

Vous l’aurez compris, c’est à ce niveau de la partie, que “le jeu” se complique. Si les Core sont plus ou moins armés de processus rodés et ont fait l’objet de politiques satisfaisantes pour frapper fort, c’est dans l’ouverture à la communauté qu’on va trouver le meilleur. Car oui c’est indéniable tous ces modules accessibles sont un fabuleux puit sans fond. Mais en sus du meilleur, avouons le, nous allons surtout aussi aller côtoyer le pire. Que cela soit par l’usage exacerbé et patchwork de bouts de code finalement issus de divers horizons ou bien par des niveaux de qualités inégaux dans leur réalisation. L’ensemble rendra le façonnage du projet sur ces bases d’autant plus mis à rude épreuve que la complexité demandée augmentera. Et nous parlons bien la malheureusement de difficultés exponentielles.

Mais s’il y a bien des complexités reconnues dans toute production Web, comment “nos voisins côté Framework” s’en sortent-ils ? Car maintenant qu’on en parle : où se trouvent toutes ces belles initiatives structurantes dont on entend vanter monts et merveilles sur le reste de la toile ?

 

- 4 -

Des outils standards manquants à l'appel

Un outil globalement moderne se doit-il d’être fondé sur des outils/concepts faisant preuve eux-mêmes d’une certaine « modernité » ? De notre point de vue, sans le cacher, nous aurions aimé entendre un “oui” comme réponse. Surtout à l’heure où les initiatives sur le Net n’ont jamais été si prolifiques et puissantes. Mais la réalité au travers de nos CMS est malheureusement moins éclatante qu’attendue.

Pêle-mêle voici quelques petits troublions qu’il nous est donné de croiser au gré des développements Internet, et qui, de notre avis, sont loin d’être des outils anecdotiques :

  • Composer, gestion de dépendance
  • Outils Console
  • Gestion de configuration
  • La programmation Objet
  • ORM
  • MVC
  • migration
  • SEO
  • CDN
  • Système de cache
  • WYSIWYG

WordPress : Bon alors la oublions tout bonnement tout ce qui vient d’être listé ci-dessus. Si par un heureux hasard il nous arrive de croiser quelques bouts d’objet, ils sont tout mélangés au sein d’un environnement tout de même extrêmement procédurale. Les architectures de structuration du système sont très légères et en injecter soi-même revient à donner naissance à un monstre contre nature. La gestion de dépendances n’est abordée qu’au travers des extensions maison (ou pas) et n’est de fait pas réellement orientée vers des possibilités de librairies php externes « non extension WordPress ». Concernant la gestion des configurations, vous n’échapperez pas au supplice du « presque tout en base de données ». Et au niveau des petits extras, du type Cache, CDN ou SEO, des choses peuvent être comblées plus sereinement mais il faudra obligatoirement greffer des extensions pour vous ouvrir les chemins … en espérant qu’ils aient été abordés dans le sens où vous en aurez nécessité.
Seul le bon vieux WYSIWYG trône fièrement au centre de l’outil afin de promettre encore plus de monts et merveilles pour le meilleur (et des fois pour le pire).

Drupal 7 : Il partage ici aussi globalement la même sauce que WordPress pour bonne partie des remarques ci-dessus. Toutefois plus de modules techniques viennent tenter de combler des vides, mais la encore ne faisant pas partie du Core, ils peuvent vite se retrouver relégués à des initiatives dans l’initiative. Et ainsi ne s’en trouvent pas forcement suivi par le reste de la communauté. Ce qui rend leurs efforts certes extrêmement louables, ne l’oublions pas, mais non concrètement salvateurs au risque d’alourdir considérablement les performances ou prises en main.

Drupal 8 : Avec cette toute nouvelle version, Drupal nous prouve qu’il ne pense pas pouvoir tenir la route en continuant sur son ancienne base historique. Et c’est ainsi qu’une grosse partie du moteur s’est vue rafraichie par l’arrivée de certaines parties du Framework Symfony. Nous voyons avec plaisir plus de structurations se mettre en place, gageur, à priori, d’une architecture plus véloce. Toutefois des concepts propres à l’outils étant encore en partie conservés faute à sa mutation non entièrement rodée, nous avons pour l’heure l’impression d’être face à une solution hybride un peu déroutante. On note par exemple le mixte du tout objet avec quelques traces de procédural qui font office d’ovni, un usage de Composer qui ne coule pas encore de source, la gestion des configurations qui, malgré des tentatives louables de changer la donne, est encore un peu extrême et non fluide, un outil de Console unique non identifié (Drush ou Drupal Console)… Bref ici c’est certes plus moderne, mais étrangement on n’arrive pas encore à dérouler les bons principes (reconnus) faisant pourtant les jours heureux des technologies voisines. Dommage.

La phase de réalisation technique ayant été maintenant majoritairement abordée, tournons-nous pour finir vers des sujets annexes, mais néanmoins importants au bon déroulé d’une production web : le travail collaboratif, la mise en exploitation et le support.

 

- 5 -

Une exploitation et un support laborieux

 

MISE À JOUR / MAINTENANCE / TRAVAIL COLLABORATIF : HARO SUR LE CADRAGE ET LA SOUPLESSE

WordPress : 

  • Multi-environnement : Alors ici attention concept : et si on se permettait de stocker en dur dans la base de donnée absolument toutes les références URL du domaine faisant tourner le site ? Et en prime sous un format serialisé PHP hautement intouchable ?
    Et ainsi l’hérésie fût totale au commencement… mais plus grave : elle persiste et signe encore de nos jours !
    Qu’est-ce qu’il s’est passé messieurs à ce moment de la conception où cet axe fort a été durement ancré dans le marbre ? Comment avec cette ineptie peut-on devenir le système web qui fait tourner 25% des sites d’Internet (parait-il ?). Et ce n’est pas l’utilisation possible de l’initiative annexe wp-cli (pour son search-replace salvateur) qui pardonnera quoi que ce soit. Grave faute de goût à notre sens.
  • La mode du “maximum de configuration en base de données”, va assurément vous faire travailler votre mémoire réflexe puisque vous allez oeuvrer non stop à assurer une synchronisation humaine de clics en tout genre pour essayer tant bien que mal de conserver l’ensemble des changements du site sur l’ensemble des bases existantes sur le projet. Donc à moins de travailler directement en production (de nos jours serait-ce vraiment sérieux ?), dès le moment que vous aurez une deuxième base de données (un collègue, une pré-production), vous prenez le risque d’être plus ou moins en désyncronisation « acceptable ». A moins de réaliser des échanges par écrasement de vos bases dans leur globalité… ce qui ne va pas s’en évidemment causer d’autres types de problèmes.
  • Le système de module proposant d’alerter sur les mises à jour, nous aurions pu espérer du pain béni pour opérer nos mises en place de contrat de maintenance. Mais il n’en est malheureusement rien. Les modules se mettent à jour constamment pour un rien (essentiellement des débugs), il n’y a aucun moyen de filtrer clairement les mises à jour pour ce qui nous intéresse concrètement à savoir : la sécurité. Ce qui force ainsi ni vu ni connu à constamment jouer à la roulette russe lors d’une mise à jour à le malheur de corriger à la fois ET une faille de sécurité MAIS qui ajoute aussi plein de superbes nouveautés (ou des bugfix) non recherchées… qui iront 1 fois sur 3 crasher le système entier puisque les incompatibilités sont monnaies courantes entre extensions.. mais aussi entre versions d’extensions.
    Ici le casse-tête est ainsi total car cela demande concrètement à chaque mise à jour d’extension d’auditer en profondeur ses tenants et aboutissants…. ainsi que d’aller expliquer pourquoi la maintenance « invisible » coûte finalement plus cher que la phase de réalisation.
  • Et nous l’avons déjà vu plus haut : les systèmes de licence divers et variés ne vont pas pour arranger le casse-tête qui se met en place gentillement mais sûrement.

Drupal : 

  • Multi-environnement : bien plus sérieux que WordPress à ce niveau car avec un peu d’attention, il vous est possible d’éradiquer toute trace du domaine dans votre base.
  • Drupal 7 gestion des configurations : on en revient ici aux problèmes du tout en base. Des initiatives peuvent nous aider dans ce chemin de croix, mais globalement ça reste très très laborieux dès qu’on dépasse le nombre d’une base de donnée.
  • Drupal 8 gestion des configurations : injection du YAML (entendre extraction des configurations en base de données dans des fichiers versionnables / partageables)… et ça fait mal. Donc on notera l’effort pour proposer un processus de cadrage des données structurantes en objectifs de synchronisation. Mais qui en découle sur une verbosité extrême un peu déroutante de prime abord.
  • Mises à jour de modules : ici le concept de canal de sécurité est réellement appréciable puisqu’il permet de concentrer l’effort de maintenance sur les mises à jour importantes (et non celles dites évolutives en dehors cadre de votre prestation). La qualité de programmation fournie est globalement plus sérieuse ce qui évite les plus grosses déconvenues vécues sous WordPress.

DOCUMENTATION : ERREMENTS ET QUESTIONNEMENTS

Puisque nous ne sommes pas censés connaître sur le bout des doigts l’absolue documentation d’Internet, les supports de référence sur les langages et systèmes sont un élément important à prendre en considération.

Et encore une fois concernant nos 2 protagonistes il y a à boire et à manger. Certes nous avons bien accès à des documentations listant l’ensemble des références fonctionnelles des librairies des Core, mais nous restons souvent sur notre faim en matière de réponses à nos interrogations. Il manque souvent un exemple ou explication d’un cadre réel d’utilisation. Nous ne parlerons pas des documentations au niveau des modules tiers car elles se montrent plus souvent inexistantes qu’autre chose.

Et nous voila alors partis à la grande aventure de la recherche d’espoir au travers Google (et son compère StackOverflow) ou voire encore des commentaires(/questions)(/échos virtuels) d’utilisateurs en détresse sur les-dites documentations en question. Mais heureusement de temps à autre le Graal pointe le bout de son nez au travers d’un tutoriel extrêmement bien réalisé qu’une âme charitable a pris le temps d’expliciter suite à ses découvertes. Sauf qu’une dernière étape se dressera devant vous : l’espoir que ce tutoriel d’il y a 3 ans corresponde bien à la bonne version de votre module présentement utilisé.

Bref sur ce point on s’arme de patience, de capacité de recherche poussée (et de faire le tri), et d’un constat clair qu’il y aura très souvent absolue nécessité à ouvrir les entrailles des codes d’extensions et librairies utilisées si l’on veut entrevoir la lumière. C’est le détail “main dans le cambouis” qui n’était pas forcement marqué en astérisque à côté des promesses affichées.

Suite à ces divers points que nous avons abordé au travers de notre regard de fidèles pratiquants, nous pouvons maintenant en venir à notre conclusion.

 

- 6 -

Notre conclusion : des lacunes à leur reconnaître pour maximiser leurs avantages

 

En 2017, toutes ces solutions ont toujours l’air de s’imposer « naturellement » grâce à leur axe marketing bien ancré qui séduira très certainement en priorité les décisionnaires pour leurs avantages annoncés sur les délais de réalisation (donc de coût) et leur extensibilité sans limite.

Mais à y regarder à deux fois, il faut bien discerner l’existence du risque caché au bout du compte qui est de transformer toutes ces belles promesses en un Frankenstein mal ficelé et inexploitable. Il n’est pas question ici de décrier leur évidente puissance / utilité, mais plutôt de questionner une réalité perçue que nous trouvons trop souvent enjolivée chez une partie des équipes projets.

Quoiqu’on en dise il s’agit en réalité, au même titre que d’autres technologies voisines, de systèmes (de plus en plus) complexes à mettre en oeuvre avec leurs avantages mais aussi leurs inconvénients. Inconvénients qui se transforment en réels désavantages s’ils ne sont pas pris au sérieux du fait d’être trop souvent passés sous silence dans les discours marketing vertueux.

Parallèlement, les productions Web deviennent toujours plus exigeantes. Car au delà du terrain de la facilité d’usage d’une interface, les commanditaires s’attendent globalement tous à hériter d’un package total qu’il faut dorénavant être en mesure d’assurer qualitativement :

  • robustesse d’une conception vis à vis du fonctionnel tout autant que ses performances face à la montée en charge
  • pérennité à l’usage et dans ses données mis en oeuvre
  • rapidité d’évolutivité
  • maintenabilité et lisibilité
  • compatibilité aux normes
  • sécurité

Face à ce périmètre extrêmement riche à combler, il faut assurément mettre en oeuvre beaucoup d’efforts et moyens pour aboutir aux résultats visés, sans en oublier quelques uns en chemin. Et c’est ce piège que nous cherchons à prévenir dans des contextes où l’apparente facilité est toujours plus poussée en avant.

 

Concernant nos CMS abordés ici, il s’agit de bien prendre conscience de leurs avantages tout autant que de leurs limitations. Seule réalité à notre sens permettant de leur adjoindre des phases de conseil / expertise / processus qualité supplémentaires étant au final seuls gages de proposer une production mieux maîtrisée.
Ne pas les prendre en considération, en étant uniquement axé sur la facilité d’approche qu’ils proposent, expose toute l’équipe projet (des techniciens aux usagers, du prestataire au commanditaire) à diverses déconvenues pouvant réellement mettre à mal la pertinence et l’efficacité des productions.

 

Les CMS Drupal et WordPress en 2017 ? Cela sera toujours un OUI avec lesquels nous composerons. Mais un OUI toujours adossé de bonnes doses d’analyse et de lucidité qu’on ne fera surtout pas l’économie d’oublier.
Et avec malgré tout toujours l’espoir secret de les voir venir jouer sur le terrain des standards actuels où ils se sont montrés beaucoup trop frileux/autocentrés jusqu’ici.


Vous avez apprécié cet article ? Inscrivez-vous à notre newsletter :