Sa sortie le 19 Novembre 2015, a été célébrée comme la nouvelle saison annuelle de « Game of Thrones ». Il faut dire qu’il avait été attendu le bougre ! Maintes fois repoussé, Drupal 8 faisait limite figure d’arlésienne, mais 5 ans après Drupal 7, il est bien là !

19 novembre 2015 – 19 mai 2016, Drupal fêtera dignement ses 6 premiers mois d’existence et bénéficie déjà de sa première dent, Drupal 8.1, sorti  à la fin du mois d’avril.

Et comme le chantaient les philosophes  «Jacky Brown » et « Ben-J » du groupe « Nèg’ Marrons », dans les années 2000, je cite :

« Le temps passe et passe et passe
Et beaucoup de choses ont changé
Qui aurait pu s’imaginer que le temps se serait si vite écoulé,
On fait le Bilan, calmement en s’remémorant chaque instant
Parler des histoires d’avant comme si on avait 50 ans »

Et oui, c’est l’heure du (premier) bilan. Un bilan, qui selon l’auteur de cet article est un peu mitigé pour le moment (voilà, j’ai spoilé l’article !)

Pourquoi ? Comment ? Sommes-nous à l’abri d’un nouvel opus de Nèg’Marrons ? Nous allons essayer de répondre à toutes ces questions (sauf peut-être à la dernière) en nous focalisant surtout sur les aspects plus fonctionnels que techniques.

 

« Fonctionnel » VS « technique »

Disons les choses sincèrement. L’aspect technique d’une solution a tendance à autant m’intéresser que les « Anges » sur NRJ12. Ainsi, je préfère m’attacher à des considérations fonctionnelles lorsque je regarde ou teste une solution plutôt que de me limiter à une architecture technique.

 

STOP ! Amis développeurs, leader et même Directeur Technique, ne me lynchez pas encore (où attendez au moins la fin de cet article pour le faire !),  je n’ai rien contre vous (j’ai même des amis développeurs, que je ne paye pas forcément). Je comprends tout à fait que l’architecture technique de Drupal 8 ait un impact « positif » sur votre travail de tous les jours tant en termes de développement que de maintenabilité, toutefois votre vision du CMS et vos objectifs sont ici différents des miens.

 

De mon côté, je m’attendais et espérais secrètement que cette nouvelle version dénote un changement fonctionnel aussi important que celui que j’avais pu voir lors du passage de Drupal 6 à Drupal 7. C’était pour le coup une grosse surprise qui m’avait sevré du jour au lendemain de la plupart des solutions CMS que j’utilisais à l’époque.

 

 CMS : Un pour tous… mais pas tous pareils 

De l’avis de certains de mes confrères, « tous les CMS sont pareils à quelques différences près ».  Je trouve ce constat plutôt sévère mais admets que l’avènement du CMS tel que  nous l’avons connu à l’époque de l’« Age d’or » (se situant pour nos amis documentalistes entre le « bilan » des Nèg’ Marrons et la saison 1 de « Game of Thrones ») est révolu.

Depuis quelques années, c’est la crise au royaume des CMS. Il y a beaucoup d’acteurs sur le marché et il devient difficile de faire un choix sachant que beaucoup de solutions se ressemblent fonctionnellement.

Certains éditeurs, pour sortir un peu du lot, ont cherché à se différencier en dépassant la simple " gestion de contenu " en leur intégrant des fonctionnalités marketing (notamment tout ce qui attrait au CXM et au marketing automation).

Plus récemment encore, sans doute aidée par l’émergence de nouvelles technologies et par une concurrence accrue des CMS Java, cette évolution s’est déplacée sur un contexte plus technique : une meilleure adéquation de la solution « CMS » dans un environnement SI parfois dense (je parle bien ici d’interfaçage avec une solution de type GED, CRM … où le CMS joue le rôle de catalyseur), un socle technique « moins artisanal » basé sur un framework suffisamment répandu permettant à la fois d’accélérer le travail des développeurs et de consolider des compétences venant du monde CMS et de l’univers des Framework (et pour beaucoup Symfony).

 

Et c’est tout ? Non pas tout à fait.

 

Il y a eu (enfin) aussi une prise de conscience de certains éditeurs qui profitent de la sortie d’une nouvelle version pour se dire que finalement cela serait peut-être pas mal de faire appel à un ergonome ou à un UX pour dépoussiérer une interface « Back-Office » souvent vieillissante.  Ils ont surtout vu les contributeurs CMS occuper une place de plus en plus importante dans la prise de décision du choix de la solution CMS. Il fallait les draguer non pas à coup de « crack boum hue » mais par des mécanismes ludiques et immédiatement compréhensibles, par une grande liberté de contribution permettant de personnaliser de manière unitaire chaque page du site.

 

Un point que malheureusement, Drupal 8, semble avoir pour le moment, sous-estimé.

 

Une interface de contribution qui sent un peu la naphtaline de mamie !

Flashback ! Nous sommes début 2011. Eurotunnel espère une reprise de son activité, Météo France annonce des températures record pour cette saison, on assiste à une éclipse lunaire partielle en Europe (précisons de 7h50 à 10h30 uniquement) et Drupal 7 sort.  

Je me souviens de ce 5 janvier 2011.
J’installe frénétiquement D7 sur mon bon WAMP local sans véritablement croire au miracle. Il faut dire que Drupal 6 avait éveillé en moi un engouement plutôt limité - comparable à devoir organiser des stages d’épanouissement personnel en région Nord-Pas de calais -.

 

En quelques secondes, j’ai été conquis : Il faut dire que Drupal 7 balançait du « lourd »: intégration ingénieuse du « Back-office » « dans » le Front, Gestion basée une grande partie par du simple Drag and drop… pour n’en citer que quelques-uns.  Il y avait quelque chose de très innovant pour l’époque et qui a, je pense,  influencé d’autres solutions depuis.

Avec l’émergence des frameworks web de type AngularJs, le web a été propulsé dans une nouvelle ère, permettant aujourd’hui de faire tourner des applications web légères et souvent très ludiques.

J’attendais donc Drupal 8 avec un engouement certain et espérais que parmi ces « 200 nouveautés listées » une partie d’entre-elles concerneraient aussi la contribution et l’interface Back-office.

 

Au final, c’est une déception. Ce Back-office n’est finalement qu’une resucée de ce qui existait dans Drupal 7. Certes, le graphisme a été légèrement retouché et la principale « nouveauté » réside dans le portage du core de Drupal 8 de fonctionnalités qui  existaient déjà sous forme de modules ou de thèmes. Parmi les nouveautés mises en avant par l’éditeur on notera par exemple que :

  • l’Edition des contenus directement en Front-Office se faisait déjà sur Drupal 7 via le module « Edit »
  • l’enregistrement de contenus contribué sous forme de brouillon était présent depuis des années via le module « save draft »
  • L’intégration de CkEditor comme éditeur WYSIWYG par défaut sans passer par 2 puis un module Drupal
  • La possibilité d’avoir un Back-Office en Responsive Design existait déjà notamment via l’installation de thèmes BO comme le magnifique « Adminimal » (dont je suis fan !)

Quant à l’ergonomie, elle n’a pas bougé d’un iota et … c’est à peu près tout.

Bien sûr, je pourrais rajouter que la gestion des blocs ou des entités Drupal a été simplifiée mais  pour moi, ces aspects concernent plus le rôle d’un « Site Builder » ou  d’un « développeur » qu’un contributeur.

 

Certes, nous étions prévenus. Lors de la DrupalCon de Barcelone en Septembre 2015, Maitre Buytaert (le créateur de Drupal) sur son estrade perché tenait à peu près ce langage : « l’UX de Drupal 8 n’est pas top. Va falloir se bouger un peu le popotin pour changer cela, surtout si on veut convaincre des utilisateurs réfractaires à passer sur Drupal ».

C’était beau comme une promesse non tenue. Car si on pouvait se douter que Drupal 8 .0.0 n’allait pas faire évoluer l’interface et certaines pratiques de contribution, l’arrivée de Drupal 8.1 était sans doute l’occasion de corriger le tir et de « draguer » comme le font d’autres solutions, les contributeurs finaux qui se fichent des considérations techniques.  Et finalement Drupal 8.1 ne les écoutera pas plus.

 

Il y a cependant beaucoup de choses à faire à commencer peut-être par repenser la contribution :

  • La mise en place de types de contenus offrent de nombreux avantages mais pas de solutions lorsque le contributeur souhaite dans le cadre d’un article, intercaler de nouveaux champs dans un type de contenus définis en amont (cela reste possible via le module « Paragraph » et cependant pas aussi intuitif que sur de nombreuses autres solutions)
  • Intégrer par défaut un Dashboard de type « Workbench » qui permet plus facilement de voir et de suivre l’évolution de la contribution sur le site
  • Repenser la manière dont les articles sont contribués. Sur les formulaires longs, pouvoir plus facilement découper la contribution, ne serait-ce qu’en renvoyant sur une 2e page ou dans un menu caché le bloc correspondant aux propriétés qui n’est absolument pas pratique actuellement
  • ….

En conclusion, Drupal 8 n’a pas reproduit son exploit de Drupal 7. Le chemin est long et la communauté a tout à loisir de s’intéresser  à ces aspects dans les mois qui viennent, peut-être même pour la 8.2, mais une trop longue réaction de la communauté pourrait sans doute entrainer une double perte entre ceux qui préfèrent une autre solution et ceux qui quittent le bateau Drupal pour favoriser une autre solution.

 

Et pour certaines fonctionnalités…ben c’était mieux avant !

La grande force de Drupal c’est son extensibilité. A quelques retardataires prêts,  il  y a 34 000 modules sur Drupal dont plus de 11.800 sur Drupal 7 et (seulement)  1.600 sur Drupal 8.

Drupal a toujours été basé sur un modèle un peu original. Le socle technique est volontairement limité en fonctionnalités pour laisser toute la latitude à chacun d’installer les modules correspondants aux besoins dudit site en question.

Par exemple, si vous n’avez pas de workflow de validation sur votre site, cette fonctionnalité ne vous est d’aucune utilité et vous n’avez pas besoin d’installer un ou des modules de workflows. Car oui, dans le monde de Drupal, plusieurs modules peuvent répondre à un même besoin.

Forest Gump disait : « La vie c'est comme une boîte de chocolats, on ne sait jamais sur quoi on va tomber » Avec Drupal et notamment D8, c’est un peu la même chose, on a affaire à des modules de qualités très disparates dont le niveau de stabilité n’est pas toujours bien indiqué : un module « unstable » est parfois plus « stable » qu’un autre module indiqué en « Recommanded release ». Il faut donc les tester un à un… et on ne sait jamais sur quoi on va tomber.


Drupal, c’est aussi un peu le syndrome « Nintendo ». La célèbre firme japonaise est coutumière du fait en lançant des nouvelles consoles qui disposent d’un line-up limité et constitué de jeux de qualité souvent discutables.

Voilà maintenant plus de 5 mois que la solution est sortie. Elle intègre une quantité limitée de modules opérationnels et ne dispose toujours pas de l’intégralité des modules « stars » qui font son succès parmi lesquels (attention instant émotion, à écouter avec une petite musique de circonstance genre https://www.youtube.com/watch?v=9Qn2Pp1QiWA) :

 

  • « Media Entity », par exemple,  qui permet -excusez du peu – de bénéficier d’une gestion des médias sous forme de DAM n’est toujours pas opérationnel et m’oblige à utiliser IMCE (ce qui est pour le coup vraiment moche, surtout après avoir gouté à « Media » ou à « ScalD »). On peut d’ailleurs se demander pourquoi un tel module n’est pas fourni avec la solution tellement cette fonctionnalité est importante dans le monde des CMS.
  •  « Webform », qui permet de gérer les formulaires existe bien sur Drupal sous un autre nom. Mais ce nouveau module reste limité, notamment sur la possibilité d’enregistrer les résultats, de les exporter. On espère que le module historique retrouvera rapidement le chemin de Drupal 8 d’autant plus qu’il n’est même plus sur la liste des modules portés par l’éditeur, un comble !
  • « Panels » qui permet une gestion simplifiée et ludique de la création des pages. Ce n’est sans doute pas le module le plus important à porter mais il fait toujours son petit effet lorsqu’il est montré. Pour le coup, le module est « pre-release » c’est-à-dire qu’il est proche d’une sortie officielle et normalement déjà exonéré de tous les bugs critiques.  Panels sur D7 est très agréable à utiliser : un enfant de 10 ans peut comprendre son fonctionnement en quelques minutes.  Quant à Panels pour D8, c’est une autre histoire. Il est préférable avant de s’y attaquer de résoudre préalablement le mystère de la vie, réputé moins compliqué.
  • « Feeds » qui permet d’agréger du contenu dans Drupal. Les puristes pourront me dire que migrate (qui est proposé par défaut dans D8) le fait tout aussi. Ils ont raison mais Feeds reste plus facilement configurable et dispose d’une interface graphique qui ne nécessite pas encore d’avoir un niveau de maitrise équivalent à celui de panels sur D8.


Je n’en cite volontairement que quelques uns mais la liste est longue et n’inclut même pas mes « chouchous », (OG, Notify…) ni les modules que j’ai l’habitude de proposer à mes clients (linkchecker, Views data export..).


Il est incompréhensible que 5 mois après la plupart de ces modules soient : « toujours pas portés », « en cours de portage … mais inutilisables»,  « En cours de portage … mais utilisables à vos risques et périls », « ça va sortir… un jour ») alors qu’ils constituent, je le redis la « crème » des modules de l’écosystème de Drupal depuis parfois plusieurs générations !


Une mobilisation générale pour porter en priorité ces modules, associée pourquoi pas  à un coup de main de la part de l’"éditeur", serait formidable.
Ces portages me semblent plus prioritaires que certaines nouvelles fonctionnalités actuellement menées par l’"éditeur" et la communauté Drupal et qui concernent là encore, des considérations plus techniques que fonctionnelles.


Le changement d’une version majeure à une autre a toujours eu, du moins dans un premier temps, un impact plutôt « négatif » sur la communauté.

L’évolution des technologies,  surtout pour cette version 8, a sans doute provoqué une fois de plus la « déroute » d’une bonne partie des développeurs qui n’ont pas ou plus le niveau, soit n’ont pas le temps de continuer à maintenir et ou à porter un module. Dans ce deuxième cas, s’il n’y a pas de repreneurs, on peut préparer la mise en bière et chanter l’éloge funèbre ou espérer bénéficier dans quelques mois d’un module « ++ » comme cela semble être parfois le cas (« Groups » en remplacement de « Organic Groups »).


Cette « professionnalisation » des ressources, déjà remarquée lors du passage de Drupal 6 à Drupal 7,  fait sans doute du bien à une solution technique souvent critiquée, y compris par ses propres développeurs et retarde considérablement le portage de certains modules, y compris ceux qui sont appréciés par la communauté… Je parle bien entendu de cette race de modules qui font qu’on va au moins 2 fois par jour sur la page dudit module pour vérifier une éventuelle activité, voire mieux un éventuel « commit ».


La taille de la communauté et le niveau parfois limite « surhumain » de certains développeur trèèès talentueux, rattrapera et inversera la tendance et il faudra attendre encore 6 à 8 mois pour bénéficier d’un écosystème vraiment intéressant et digne de la réputation « couteau-suisse » de Drupal.


En attendant, ce sont nous, des sociétés comme Core-Techs,  qui devront composer le choix de Drupal 8 avec ses qualités et ses défauts, qu’il faudra combler par des petits développements spécifiques pour les clients les plus impatients.

« ENNEMY IS COMING ! »

Question : que fait la concurrence pendant que Drupal « se requinque » ?

Réponse : Il avance tout droit et grappille quelques parts de marché.


Attention donc à la concurrence et plus particulièrement aux « jeunes » solutions CMS qui arrivent sur le marché et qui bénéficient parfois de l’aspect « nouveauté ». En tant qu’intégrateur, nous avons pu tester, notamment lors du dernier AgoraCMS, quelques solutions CMS récentes qui, même si elles n’arrivent pas à un niveau fonctionnel aussi abouti que Drupal, proposent des choses  plutôt chouettes : une interface très agréable,  une prise en main immédiate.

On sent que ces éditeurs en herbe ont une connaissance poussée des principales solutions existantes (et que les budgets « café » et « Comité d’Entreprise » ont été réinjectés en R&D).

Certes, elles n’ont pas forcément énormément de références, un périmètre fonctionnel et une communauté beaucoup plus réduite que celles de « Drupal », « Wordpress » ou même « SPIP » !… mais elles se rattrapent par des fonctionnalités innovantes et une contribution très « user-friendly » qui devraient trouver échos sur certaines solutions CMS.

 

Il est nécessaire que Drupal réagisse s’il veut garder son « leadership » et que l’usabilité de la solution devienne un sujet aussi sensible que l’environnement technique qui le compose comme malheureusement la « 8.0 » puis la « 8.1 » le laisse entendre.

Il serait dangereux que, comme pour d’autres solutions du marché, l’effort technique soit tellement mis en avant qu’elle en devienne en quelque sorte « élitiste ».

En bref, tout le contraire de la réputation qu’elle a réussi à se forger jusqu’à présent.


Il faut composer avec Drupal 8 pour obtenir le meilleur de demain.

Drupal 8 finalement, c’est un peu une voiture évolutive livrée en Kit. Vous avez actuellement le moteur et les roues motrices, vous pouvez avancer avec mais ne pourrez bénéficier de toutes les options promises par le constructeur comme la climatisation, l’autoradio, le GPS… que dans plusieurs mois. Alors forcément, on ronge un peu notre frein ...

On attend, on regarde la concurrence, le modèle précédent, plus complet mais qu’il faudra revendre dans 2 à 3 ans.

Drupal 8  n’est pas une mauvaise voiture, loin de là.  Il y a quand même des choses très positives à souligner sur cette version, comme la gestion du mobile first, la gestion du multilinguisme ainsi qu'un cadre de développement plus agréable (passage de la dev à la prod, mise en place d’une vraie API Rest permettant de mieux s’intégrer avec d’autres solutions), des points sur lesquels beaucoup (dont nous) se sont attardés aux travers d’articles spécifiques.


Drupal est un produit hautement perfectible à qui on doit laisser le temps de s’installer. C’est pour cette unique raison qu’il faut, sauf cas particulier, développer tous nos nouveaux projets en Drupal 8 plutôt qu’en Drupal 7.


C’est une sorte de pari sur l’avenir.

 

Rendez-vous dans 6 mois pour voir s’il a été gagné.

 

 

 

Publié par Adimeo
CEO Adimeo
Retrouvez moi sur :

Sur les mêmes sujets