core-techs2.png
Ë
Par Core-Techs • jeudi 19 novembre 2015

Retour sur la Drupalcon de Barcelone (4/4) : Pertinence de la technologie

Petite histoire des CMS

Flashback ! Il  y a presque 20 ans, les notions de pages et de contenus étaient très liées : le webmaster disposait d’un unique fichier HTML dans lequel figuraient à la fois le fond (le contenu) et la forme (la page).

Lorsqu’il était amené à faire évoluer le graphisme de son site, le webmaster devait modifier chaque page HTML… qu’il devait ensuite télécharger sur un serveur distant pour qu’il puisse être lu par un navigateur web.

 

Lorsqu’il était amené à faire évoluer le graphisme de son site, le webmaster devait modifier chaque page HTML… qu’il devait ensuite télécharger sur un serveur distant pour qu’il puisse être lu par un navigateur web.

Grâce aux CMS, ce temps est révolu : l’arrivée des CMS, il y a environ 15 ans, a rendu possible dans un premier temps la séparation du conteneur (la page) et du contenu (l’article) via une interface, appelée Back-Office.

Le contenu saisi – obligatoirement en HTML à l’époque – s’insérait par la suite dans un gabarit de page prédéfini, dont le rendu visuel était  toujours généré par le serveur, s’affranchissant ainsi des contraintes précédemment évoquées.

 

Par la suite ces mêmes CMS ont bénéficié de nouvelles fonctionnalités simplifiant grandement le travail des contributeurs : mise en place d’un éditeur WYSIWIG pour saisir du texte, séparation des rôles et des droits permettant une décentralisation des tâches au niveau du Back-Office, création de workflow de validation des contenus …

 

L'arrivée des CMS, il y a environ 15 ans, a rendu possible dans un premier temps la séparation du conteneur (la page) et du contenu (l’article) via une interface, appelée Back-Office.

Ce qui est intéressant de retenir de ce petit rappel historique, c’est que les CMS et plus généralement les langages de programmation comme le PHP, ont permis de propulser nos sites dans une nouvelle ère, facilitant d’une part le travail des équipes éditoriales et techniques et d’autre part ouvrant de nouvelles perspectives pour nos sites web avec l’apparition de la vidéo  et également de nouveaux usages (RSE, e-commerce…).

 

Disons-le clairement : les CMS ont « ringardisé »  nos vieux outils de création de sites web « classiques » et se sont reposés pour beaucoup sur leurs acquis en valorisant un nombre de plus en plus conséquent de modules sans forcément investir dans des contrées plus sinueuses (outils Marketing, Expérience User-centric…).

Dries reconnait lui-même que Drupal 8 a mis le paquet sur « l’expérience développeur » au détriment de  « l’expérience utilisateur » (UX). Cette confidence est d’autant plus étonnante qu’il existe aujourd’hui sur le marché des frameworks qui répondent à ces 2 aspects.

 

CMS versus Framework : la nouvelle bataille ?

En clair, est-ce que les choix stratégiques  de Drupal sont les bons ? L’arrivée des frameworks web répondant à la fois à des considérations techniques et comportementales n’ont-ils pas eu raison de nos bons vieux CMS ? Sont-ils amenés à disparaître ?

Avant de répondre à cette question, rappelons tout d’abord qu’un framework est une bibliothèque logicielle intégrant un ensemble de fonctionnalités préexistantes permettant de faciliter et d’accélérer le travail des développeurs.

Il existe sur le marché différents types de frameworks applicables à différents usages (application web, logiciel, application mobile, orienté gestion de contenus, orientés design…).

 

Aujourd’hui,  de nombreux frameworks peuvent, en fonction des modules qui sont installés, se réorienter vers différentes activités informatiques ou usages…. à la manière de solutions CMS, qui, par des modules ou des distributions spécifiques, peuvent répondre eux aussi à différents types d’usages.

 

Ces frameworks disposent de librairies  ou de composant pré-utilisables, permettant de travailler dans un « cadre de travail », tout comme Drupal le fait aussi via la disposition de modules permettant d’accélérer les développements. C’est d’ailleurs pour cette raison que beaucoup considèrent Drupal comme un CMF et non comme un CMS, car son ambition va au-delà de la gestion de contenus classique chère à certaines autres solutions.

Il y a donc des similitudes entre les frameworks et Drupal, même si on a à faire à deux approches différentes :

  • D’un côté, une architecture traditionnelle dite « monolithique » où le front-end est partie intégrante du CMS,
  • De l’autre, la mise en place d’une architecture découplée dite aussi « sans tête » où le front-end est décorrélée du CMS.


L'architecture découplée a plusieurs avantages :

  • Elle permet  tout d’abord, la mise en place de ce qu’on appelle l’ « optimistic Feedback » (une réponse apparaît avant que le serveur traite la requête d'un utilisateur). Il n’y a plus d’appel serveur à chaque requête formulée par l’utilisateur en front et donc pas / plus de temps d’attente à l’affichage d’une information pourvue qu’elle soit stockée comme composant de la page.
  • Elle rend réalisable la mise en place d’interfaces utilisateur non-bloquantes (l'utilisateur peut continuer à interagir avec l'application tandis que des portions de pages sont toujours en cours de chargement). C’est notamment ce que propose Facebook lorsque vous visionnez une vidéo pendant que la page continue à se charger.
  • Elle facilite la mise en place d’applications web légères et globalement très ludiques, comme c’est par exemple le cas de Trello, un outil de gestion de projet en ligne qu’il est conseillé d’aller voir.

Ecran de Trello, un outil de gestion de projet en ligne ludique

Au-delà de la prouesse technique, il est surtout intéressant de constater que ces « fonctionnalités »  permettent de répondre parfaitement à des problématiques UX (expérience utilisateur) et UI (Interface utilisateurs).  Certains comportements UX et UI comme le menu « burger »,  « le scroll infini », la possibilité de trier des résultats de recherche sans recharger la page restent possibles dans Drupal mais nécessitent du code là où les frameworks Front-end disposent déjà d’une librairie / d’un composant pré-utilisable.

 

L’approche découplée a cependant quelques inconvénients. Cela concerne surtout la perte des fonctionnalités majeures intégrées à Drupal et qui justifie finalement l’utilisation d’une solution CMS : l’absence de la barre d’outil éditoriale, la disparition de la gestion des contenus « in-line » (avec Quick Edit) ou de la mise en page (avec Panels), la prévisualisation, le RDFa (syntaxe permettant d'ajouter des données structurées dans une page HTML ou document XML) …  

 

Ecran de présentation des limitations d'un site sans CMS

L’une des problématiques que nous avons précédemment abordée et qui constitue elle aussi un critère d’UX, est le temps de chargement des pages. Par son approche   « client Side Apps », il s’agit d’un avantage non négligeable pour les frameworks alors que la « gestion du cache »  a toujours été un point faible de Drupal 6 et, dans une moindre mesure, Drupal 7 sur la partie connectée.

Actuellement, Drupal 8 est la seule solution CMS qui, en version 8, est compatible avec BigPipe. Cette solution offre des performances  assez étonnantes comme le démontre la vidéo postée sur youtube.

 

Présentation de BigPipe

 

Même si les deux approches sont différentes, et que, disons-le clairement, Drupal 8 est à la traine sur cet aspect, il est toujours réconfortant de constater que Dries a conscience de cette lacune.

 

Pour y remédier, plusieurs solutions sont actuellement en chantier : Utilisations d’une API unique limitant ainsi les requêtes serveurs, et aussi de GraphQL, un langage de requête de données pour décrire des requêtes complexes dont une présentation complète est disponible ici.

Dries estime que, Drupal 8 couplé à GraphQL est LA solution idéale pour la construction d‘applications et de sites web. Elle constitue une réponse sérieuse à ce que propose les frameworks comme il le souligne en conclusion de sa démonstration.
 

Faut-il considérer ces Frameworks comme une menace ?

C’est un fait, l’arrivée des frameworks Front-End, appuyés par de grands acteurs du web (Google pour AngularJS, Facebook et Instagram pour React.js) a chamboulé un certain nombre de nos habitudes. Les frameworks sont désormais une alternative sérieuse à nos outils actuels.

Ont-ils signé pour autant la mise à mort de Drupal et de manière plus générale la fin des solutions CMS ?

Pour Dries, la réponse est « NON » d’autant plus que Drupal, contrairement à d’autres solutions CMS, n’est pas fermé  à la « complémentarité » éventuelle de ces solutions.

 

Rest in Drupal 8

Son API complètement redéfinie en D8, permet de fournir aux frameworks utilisés en Front, les données exactes attendues. Drupal peut alors servir d’interface de gestion et de stockage de l’ensemble des données qui sont, par la suite, alimentés via une API sur n’importe quelle autre solution permettant cet interfaçage, frameworks compris.

C’est d’ailleurs ce qu’a démontré quelques jours plus tard John Ennews, en expliquant, dans le cadre d’une des sessions, comment il est possible de créer un site utilisant Drupal au niveau Back-end et AngularJS au niveau Front-end.

Cette session, captée en vidéo est disponible sur youtube et fera l’objet d’un future article sur le blog de Core-Techs. Cette même technologie est d’ailleurs retenue pour tous les projets de refonte des sites de Radio France.

 

Il n’y a donc pas de crainte à avoir sur l’éventuelle pérennité de la solution Drupal 8 qui, comme nous venons de le dire, est ouvert à plusieurs approches.

 

Quel futur pour Drupal ?

Une 3e approche se dessine : « l’architecture progressive »

Il reste à combiner pour le futur de Drupal le meilleur de ces deux approches, celles que Dries définit comme étant la 3e approche, « l’architecture progressive », à mi-chemin entre l’approche traditionnelle et moderne et sur lequel  Drupal 8 se  base et qui nécessite encore de nombreuses améliorations. Cette vision est détaillée sur son blog.

 

Pour Dries, c’est cette 3e approche, couplée à celle de GraphQL qui font de Drupal le principal compétiteur face  à des solutions CMS, innovantes ou frameworks MVC.

 

Pour Dries, c’est cette 3e approche, couplée à celle de GraphQL, qui font de Drupal le principal leader face  à des solutions CMS, innovantes ou frameworks MVC.

L’avenir nous dira s’il a été, une fois de plus, visionnaire…