Drupal 8 : quel retour d'expérience ?

Nous sommes au début 2016, dans le pipe un projet de refonte d’un portail multi-sites localisés dans 17 pays et 12 langues, trois objectifs sont définis : unifier l’architecture, moderniser le design, et intégrer de nouvelles fonctionnalités, le déploiement devra être progressif s’étalant sur 12 mois.

Pour le client la solution technique doit répondre à deux critères essentiels : robustesse et pérennité. Il s’agit d’un projet structurant à dimension internationale, engageant des investissements et un temps de mise en œuvre important.

Drupal était un candidat naturel, mais quelle version adopter ? 7 ou 8 ?

Choisir Drupal 7, c’est choisir l’assurance d’une version stable, approuvée, riche par le support et les modules communautaires existants, c’est aussi le choix de la maitrise. Chez Pyxicom nous produisons depuis 7 ans plus de 40 projets Drupal par an, des projets allant de 20JH à 500 JH. 

Mais la sortie de la version Drupal 8 est en soit annonciatrice du déclin de la version précédente, ce qui aura comme conséquence, d’engager le client dans un projet basé sur une technologie sur une courbe de fin de vie.

Choisir Drupal 8, c’est choisir un CMS moderne intégrant des fonctionnalités minimisant significativement les temps de développement, avec des outils puissants d’intégration continue. Cependant, il nécessite un certain temps de prise en main, (il faut compter 3 à 4 semaines pour un développeur confirmé) et surtout à l’époque, il n’avait pas encore fait ses preuves en production, et le peu de modules communautaires existant présentaient quelques dysfonctionnements.

De point de vue fonctionnel, les deux versions répondaient parfaitement au besoin, un dilemme se posait, d’ailleurs c’est le même dilemme qui est posé à ce jour par beaucoup d’agences.

Après la réalisation de prototypes de validation de faisabilité. L’enthousiasme de l’équipe de développement l’emporta au final, La décision a été prise de partir sur Drupal 8.

La compréhension et la flexibilité du partenaire fut aussi un facteur facilitateur, en commun accord nous avons provisionné une enveloppe budgétaire spéciale pour contourner ou corriger les bugs du core. 

En cours de route il s’est avéré bien sage de prévoir cela, plusieurs points bloquants ont été rencontrés et solutionnés par du hard coding, à titre d’exemples :

• Le moteur de recherche qui ne fonctionnait pas avec les mots clés composés de 3 caractères

• Le filtre views qui n’intégrait pas la recherche via un champs de sélection multiples

• Des modules instables : easy breadcrumb, Meta tag, Pathauto

• …

Heureusement, beaucoup de ces points ont été fixé ultérieurement par l’application de correctifs officiels.

Le premier site pays a été mis en ligne en mai 2016, nous pensons que ce projet faisait partie des premiers sites Drupal 8 mis en production en Europe.

Aujourd’hui avec notre partenaire la satisfaction est totale, le déploiement dans les 17 pays s’est terminé récemment et nous avons devant nous 4 à 5 années de maintenabilité, parallèlement le core team a annoncé que les bugs-fixes et les améliorations de Drupal 7 s’arrêteront en octobre 2017. Rétrospectivement nous pouvons dire que nous avons fait le bon choix.

Depuis ce premier lancement nous avons produit une dizaine de projets Drupal 8, un bel outil qui représente 60% de nos activités de développement CMS.

Après la petite histoire, je vous livre ici les cinq conclusions majeures retenues de nos différentes expériences, en espérant que cela vous soit utile :

Oui, beaucoup de modules anciennement communautaires sont maintenant intégrés dans le core, le backoffice a été enrichi et incarne toute la philosophie d’un outil CMS, où l’on peut à travers des clics créer des formulaires avancés, des vues, des filtres, manipuler les templates, etc. Cela pourrait même agacer les développeurs amoureux des algorithmes car il y a moins de code à écrire. Mais ils ne seront pas non plus déçu en cas de besoins de développements sur mesure grâce aux API Drupal, Drupal console, etc.

Il y a deux façons de faire dans Drupal 8 : le theming par programmation et le theming par clique : 

• La première approche consiste à créer un fichier template (Twig & HTML) pour chaque page, bloque, ou objet. 

• La deuxième approche permet de créer et définir la structure des pages ainsi que l’agencement des éléments par clique directement dans le backoffice, cela à travers un écosystème de modules intégrés à deux modules centraux : Display suite et Panels.

Un grand débat est ouvert au niveau de la communauté entre les partisans de chaque approche, nous avons essayé les deux modes, dans la pratique nous avons un penchant à utiliser la première, car elle permet une meilleure maitrise de la qualité du rendu html, et donne plus de possibilités de customisations.

Sans nul doute, c’est la fonctionnalité technique la plus surprenante, à travers quelques clics le mécanisme d’export/import des configurations (Type de contenus, vues, champs, block…), facilite grandement les livraisons itératives, ou les passages d’un environnement de recette vers la production. Et cela s’applique également sur les contenus Data et médias.

Sur le volet performance, au fil des projets et en confrontant l’outil à la réalité de la production, nos craintes se sont dissipées, hormis les optimisations classiques (cache, compression, désactivation du mode débug…) Drupal 8 ne nécessite aucun effort particulier pour optimiser le temps de chargement des pages.

Chez Pyxicom nous sommes conquis, aujourd’hui pour tous les nouveaux projets Drupal, nous recommandons à nos clients exclusivement la version 8.

Alors si vous êtes en phase d’étude avant-projet, pour la réalisation d’un nouveau site Drupal, j’espère que cet article vous aidera à prendre la bonne décision.