Les 13 défauts mythiques (ou pas) de Drupal 8

Un bras de fer entre deux hommes
Thème

Ayant eu l'occasion de lire une récente étude comparative de Drupal et SPIP,  j'ai découvert une perception de Drupal qui n'est pas la mienne. Loin de moi l'idée de vouloir comparer Drupal et SPIP. En effet, je connais très mal SPIP, tout du moins seulement en tant qu'utilisateur de base, et beaucoup moins que Drupal, et donc je ne m'aventurerai pas sur une telle comparaison. Aussi, j'ai souhaité partager ces 13 défauts mythiques, réels ou perçus de Drupal 8, que j'ai pu (re)-découvrir récemment et qui me paraissent mériter un contre point.

Incompatibilité ascendante de Drupal 8

Effectivement les modules de Drupal 7 sont incompatibles avec Drupal 8. il faut dire aussi que la rupture technologique introduite avec la nouvelle version de Drupal 8 ne laissait pas de place pour une telle option. En revanche, la compatibilité ascendante de Drupal 8 vers ses futures versions majeures est quant à elle garantie. Disons que la rupture technologique de Drupal 8, avec l'adoption des meilleures pratiques actuelles en matière de développement web, la réduction de sa dette technique passée (coucou Drupal 6 et Drupal 7), a été suffisante pour pouvoir désormais épouser un chemin de mise à jour graduel, aussi bien fonctionnellement qu'au niveau de son API. 

Le faible nombre de modules et leur qualité

12 000 modules pour Drupal 7. Seulement 3 000 modules pour Drupal 8 dont 1 000 en version stable. L'offre de modules sur Drupal 8 est effectivement moins pléthorique, mais dans le même temps plus cohérente, avec des modules aux périmètres fonctionnels similaires qui se regroupent. Mais il est certain que nous n'avons pas encore la même couverture fonctionnelle que Drupal 7. En avez-vous besoin sur Drupal 8 est une autre question. Et la réponse ne peut se faire qu'au cas par cas.

Mais un autre aspect se dégage aussi sur Drupal 8 : l'implémentation d'une logique métier peut se faire beaucoup plus facilement et rapidement, grâce à sa nouvelle architecture. Quand vous pouviez atteindre le même résultat sur Drupal 7 avec 1 ou 5 modules. Les avantages et inconvénients se discutent. Et dépendent aussi des compétences à disposition pour concevoir votre projet Drupal 8.

La question du nombre de versions stables des modules est beaucoup plus pernicieuse. Je connais des modules en version bêta 10 fois plus fiable qu'une version dite stable d'un autre module Drupal 8. Tout dépend de la personnalité du mainteneur, de son esprit de perfection, ou pas. L'utilisation d'un tel chiffre est donc sujette à caution. Mais aborder cette question de la stabilité des modules disponibles peut induire un doute sur la qualité de ceux-ci. Drupal dispose d'un processus organisé (Le Project Application Review) pour autoriser de nouveaux développeurs à publier leur module sur drupal.org. Et globalement la qualité des modules disponibles s'en ressent, d'autant plus que l'architecture orientée objet de Drupal 8 rend plus délicat l'écriture de code spaghetti. A noter que depuis quelques mois ce processus n'est désormais plus obligatoire pour de nouveaux entrants, mais en parallèle une nouvelle politique en matière de couverture de sécurité a été mise en place. 

Les statistiques d'utilisation démontrent une faible adoption de Drupal 8

Les statistiques d'utilisation sont à analyser avec beaucoup de précaution. En effet ces statistiques proviennent des sites Drupal qui ont le module Update activé, module qui permet d'avertir un webmestre de mises à jour disponibles. Hors c'est typiquement le type de modules qui n'est jamais activé sur de très nombreux projets Drupal. Pourquoi ? D'une part ce module va effectuer des requêtes sur drupal.org pour détecter les mises à jour disponibles, et donc aura un impact sur les performances du site. D'autre part parce que de nombreux sites Drupal 8 sont gérés depuis Composer ou Drush, outils qui vous permettent de collecter ces informations en ligne de commande et de lancer les mises à jour adéquates en quelques secondes.

Mais il ne faut pas se cacher qu'effectivement Drupal 8 progresse lentement. Est-ce dû à une présence moins pléthorique de modules contribués sur Drupal 8 ? Est-ce une préférence pour migrer directement sur Drupal 9, et ne pas avoir à faire deux migrations ? Est-ce dû à cette rupture technologique et une montée en compétences nécessaire ? Est-ce dû à une question de positionnement de Drupal 8 qui clairement adresse des projets d'envergure au détriment de projets moins ambitieux ? Le débat est clairement posé au sein de la communauté Drupal.

La fin prochaine de la maintenance de Drupal 8

Drupal 8 pourrait être maintenu seulement jusqu'en 2019, puis en 2021 pour la maintenance de sécurité. Bref, une durée de vie courte pour l'investissement nécessaire avec une incertitude sur l'effort à produire pour ensuite migrer sur la prochaine version majeure Drupal 9.

La date de la fin de maintenance pour Drupal 8 n'est pas connue à ce jour, et une telle annonce relève plus aujourd'hui de l'astrologie que d'éléments factuels avérés. En outre la nouvelle politique en matière de compatibilité ascendante permet d'envisager une migration douce et continue vers les prochaines versions de Drupal, mineures ou majeures. Lire Faut-il attendre Drupal 9 pour mon projet web ? à ce sujet pour plus de détails. 

Drupal 8 dispose de peu de thèmes

Drupal dispose de peu de thèmes prêt à l'emploi sur drupal.org, comparé à Wordpress par exemple. Mais nous pouvons en trouver de nombreux, au même titre que les autres CMS, sur les plateformes en ligne proposant ces produits. Et pour 40$ vous pouvez acquérir un thème Waouh!. Selon votre besoin, votre projet, cela peut tout à fait suffire. Vous en aurez pour votre argent, mais pas plus. Ces thèmes sont bien souvent des distributions qui intègrent des logiques métier ou fonctionnelles au niveau de la couche de thème. Bref un vrai méli-mélo, comme tous les thèmes prêt à l'emploi sur ces plateformes en règle générale pour tous les CMS. Mais si vous ne prévoyez pas de lourdes adaptations, ces thèmes peuvent être un bon compromis.

Avec des projets d'envergure, ou avec de nombreuses personnalisations, il est toujours préférable de concevoir son propre thème, si vous ne voulez pas, à un moment donné, vous battre contre celui-ci et ses implémentations. Et dans ce cas Drupal 8 dispose de nombreux framework déjà intégrés (Bootstrap, Foundation, etc) qui constituent une base solide pour réaliser votre thème responsive.

La composition d'un contenu avec Drupal 8

Comparer la puissance de composition d'un contenu avec Drupal 8 et les raccourcis typographiques de SPIP me paraît révéler une profonde méconnaissance de Drupal. Drupal permet de composer un contenu complexe de façon structurée, permettant au webmestre, au rédacteur, bref au producteur de contenus, de faire des mises en page complexes en se concentrant sur son contenu uniquement et non sa mise en forme. Le module Paragraphs est une des méthodes permettant de structurer ces données d'un contenu tout en offrant aux utilisateurs une grande liberté dans leur composition. Tandis que les raccourcis typographiques de SPIP permettent certes de faire des mises en page élaborées, mais en se battant plus ou moins, au sein d'un champ texte unique.

Clairement nous ne parlons pas du tout de la même chose ici. Des données structurées permettant des croisements de contenus, des navigations transversales ou verticales, permettant des mises en page complètement maîtrisées par la couche de thème, et non par l'auteur du contenu dont ce n'est ni le travail ni la vocation, n'ont rien à voir avec l'utilisation d'un champ texte unique où on y insère pelle-mêle, tant bien que mal, ses contenus et leurs mises en forme.

Gestion des droits puissante mais compliquée

La gestion des droits sous Drupal 8 est puissante mais peut vite devenir compliquée avec plus de 100 cases à cocher. Certes cela peut être vrai. Mais cela révèle aussi une méconnaissance de Drupal et/ou une mauvaise approche/conception du projet. De nombreuses solutions permettent de gérer les droits d'accès autrement que par l'affectation de droits à des rôles sur des contenus. L'utilisation de la taxonomie peut être une autre approche permettant de rendre dynamique la gestion des droits : les droits ne sont pas affectés à des rôles sur des contenus de façon statique, mais peuvent être donné dynamiquement en fonction des attributs des contenus. Et ceci sans paramétrage lourd. La gestion des droits, en fonction des besoins, peut être simplifiée. Mais ce n'est pas la gestion des droits de Drupal qui est compliqué, ce sont des besoins exprimés en matière de gestion de droits qui peuvent être complexes. Et Drupal peut adresser tout type de besoin. Si les besoins sont simples, la gestion des droits sera tout autant simple.

Une couverture fonctionnelle réduite de Drupal 8

Oui j'avoue Drupal ne dispose pas nativement du système de rubriques de SPIP, ni de son moissonnage, ni des raccourcis typographiques, ni de la possibilité d'insérer une pièce jointe dans un corps de texte, de la possibilité de programmer des dates de publication, et des possibilités de mises en forme des articles de SPIP. Pour certains manques fonctionnels, je pense que Drupal 8 peut même l'assumer fièrement. Mais de là à dire que la couverture fonctionnelle de Drupal 8 est plus réduite que celle de SPIP, les bras m'en tombent.

Migration des données chronophage

La migration d'un site SPIP vers Drupal 8 est chronophage avec beaucoup de reprise de données manuelles. En fait cela dépend du site cible. Si le projet Drupal est réalisé avec la même structure de SPIP, à savoir un titre, un corps de texte, un champ mot-clés, une rubrique (plus sans doute encore quelques autres que je dois oublier) alors cette migration peut être complètement automatisée. Drupal 8 dispose nativement d'un framework (Migrate)  permettant de mettre en place ce schéma de migration, de base de données à base de données (une moulinette maison peut aussi faire l'affaire, tout dépend des contraintes de la migration). Mais si vous souhaitez profiter d'une migration vers Drupal 8 pour structurer vos données (par exemple mettre une date dans un champ Date, mettre un prix dans un champ Prix, mettre une image dans un champ Image, etc) et tant qu'à faire enrichir vos contenus pour permettre des croisements de contenus, des navigations transversales, de la publication croisée, alors oui une migration SPIP vers Drupal sera chronophage car vous devrez intervenir sur vos contenus migrés pour les enrichir avec les nouvelles données qui n'existent pas encore. 

L'administration de Drupal 8 c'est compliqué

Oui Drupal 8 n'est pas simple à administrer. Mais on ne peut pas comparer SPIP et Drupal 8 sur ce pure aspect de l'administration. Les deux CMS ont une approche complètement différente. SPIP est un site clé en main, avec un backoffice identique (aux plugins installés près) sur tous les sites SPIP. Vous ne trouverez pas un site Drupal identique à un autre site Drupal. Le backoffice de Drupal 8 est à disposition d'un administrateur qui va construire le site, créer ses types de contenus, ses listings, ses taxonomies. Un administrateur qui va construire aussi un backoffice destiné aux utilisateurs du site, aux webmestres, pour l'édition des contenus. Le backoffice de SPIP est à disposition d'un webmestre qui va pouvoir commencer à publier son contenu, créer ses rubriques.

Oui Drupal 8 est plus compliqué parce que ce n'est pas la même cible d'utilisateurs, si on compare un site SPIP et un site Drupal fraichement installé. Mais la puissance de Drupal 8 consiste justement à pouvoir concevoir, facilement un backoffice sur mesure, à destination des webmestres, sans toutes les options de configuration qui relèvent d'une administration technique, et non d'une administration éditorial. Drupal est un CMF (Content Management Framework) avant d'être un CMS.

Drupal 8 est moins performant

Clairement Drupal 8 est moins performant que Drupal 7, si nous faisons une comparaison brut de benchmark. Et certainement encore moins performant que SPIP. Tout comme SPIP doit être moins performant qu'une page HTML statique. Tout simplement Drupal 8 embarque beaucoup plus de code, et ne propose pas le même niveau d'architecture et de fonctionnalités.

Néanmoins, Drupal 8 dispose d'un système de cache ultra performant aussi bien pour les visiteurs anonymes que pour les utilisateurs authentifiés, avec un système de cache dynamique révolutionnaire. Il intègre nativement dans son coeur BigPipe, technique inventée par Facebook, pour améliorer encore la performance ressentie, et la technique dite TurboLinks, avec le module Refreshless, qui permet de ne charger que les parties de pages qui changent, et non la page entière.

Drupal 8 dispose de toute une palette d'outils pour lui permettre de propulser des sites à très forte fréquentation. Par exemple si la gestion du cache depuis la base de données ne suffit pas à répondre au trafic de votre site, on peut là encore changer de système pour stocker le cache natif de Drupal sur Redis ou encore Memcache. Et si encore cela ne suffit pas pour répondre aux dizaines ou centaines de milliers de visiteurs par jour, il est toujours possible de coupler un Varnish ou un Nginx en front de votre site.

Drupal 8 est plein de bug

Ah bon ? Vous connaissez un système informatique, relativement complexe, qui n'a pas de bugs. La belle affaire. Oui Drupal dispose d'un bugtracker, public, qui permet à la communauté Drupal de travailler ensemble, de corriger les bugs, d'échanger, de proposer de nouvelles fonctionnalités. Cacher les bugs d'un système ne signifie pas qu'ils n'existent pas. Drupal est aussi une plateforme, une communauté, mature, organisée. 

Il faut reconnaître aussi que Drupal 8 est un système jeune, qui a été ré-écrit presque complètement, et comme tout nouveau système il doit essuyer quelques défauts de jeunesse. L'écriture systématique de tests automatisés est aussi une nouveauté introduite avec Drupal 8, tests automatisés qui ne peuvent que renforcer sa maturité sur le court et moyen terme. Plus un système est complexe, plus il couvre de cas d'usage divers et variés, plus ses utilisateurs sont nombreux et exigeants et plus nombreux seront les bugs potentiels. Un système d"information simple, avec une base restreinte d'utilisateurs, aura mathématiquement moins de bugs, soit du fait d'une couverture fonctionnelle plus réduite, soit du fait qu'ils n'auront pas encore été découvert.

Enfin Drupal 8 avec sa nouvelle politique en matière de gestion de version, et une feuille de route autorisant des évolutions fonctionnelles lors de chaque release mineure, est un système en constante évolution. De nombreux bugs présents dans le coeur de Drupal sont liés à sa politique de modules expérimentaux (cf. https://www.drupal.org/core/experimental), politique qui permet d'intégrer au plus vite de nouvelles fonctionnalités dans le coeur, et permettre ainsi aux développeurs d'itérer sur ce nouveau module. La plupart des modules expérimentaux intégrés au coeur n'ont pas vocation à être utilisé en production, sauf à disposer de compétences expertes sur Drupal, et intègrent donc le coeur de Drupal 8 en version alpha. Partant de ce constat, il est tout à fait logique de trouver de nombreux bugs majeures ou critiques.

Il est certain qu'une voiture de Formule 1 demande plus de maintenance, soit plus exigeante, est plus sujette à des pannes qu'une voiture de série fabriquée sur le même modèle depuis de nombreuses années. C'est sa nature.

Drupal n'est pas sécurisé

Cinq bulletins de sécurité, dont une faille critique, ont été publiés en 2016. Cela permet-il de dire que Drupal 8 n'est pas sécurisé ?

Le risque zéro n'existe pas, la sécurité infaillible non plus. Drupal 8 est reconnu comme étant un des CMS les plus sécurisés au monde. L'important n'est pas ici de savoir si Drupal a eu ou aura une faille de sécurité, mais comment Drupal gère celle-ci. La gestion de la faille SA-CORE-2014-005 en est une parfaite illustration.

En outre il faut souligner que ces bulletins de sécurité, critiques ou non, permettent d'évaluer très précisément la menace, et si les conditions d'une attaque potentielle sont effectivement réunis pour votre site Drupal. Ce qui n'est pas systématiquement le cas, vu l'aspect modulaire du coeur de Drupal. 

Conclusion

Certains défauts de Drupal 8 ne sont pas mythiques. Ils sont bien réels. Drupal 8 est plus volumineux et plus lent, si on mesure ses performances brutes sans les outils à disposition. Mais certains défauts sont aussi justement compensés par toute une palette d'outils mis à disposition. D'autres défauts quant à eux me paraissent plus relever d'une méconnaissance réelle de Drupal, quand cela ne relève pas tout simplement de la brève de comptoir. Oui c'est plus compliqué de construire un immeuble de 5 étages qu'une cabane en bois. Ce ne sont pas les mêmes matériaux, ni les mêmes techniques, ni les mêmes fondations. Mais au final, pour l'usage quotidien d'un immeuble ou d'une cabane, pour utiliser un ascenseur, rien de compliqué, il faudra appuyer sur un bouton (sauf que la cabane n'aura pas d'ascenseur), pour allumer un chauffage il faudra tourner un bouton, etc. La seule différence résidera dans les capacités respectives de ces constructions.

 

Commentaires

Soumis par kagou (non vérifié) le 01/06/2017 à 07:43 - Permalien

On peut rajouter que la migration depuis un site simple en version 7 vers la 8 est une galère avec en plus des soucis utf8 avec les serveurs sous MySQL. Ce qui est un comble car cette même migration vers un site sous Wordpress passe comme un charme en quelques clicks avec le bon plugin...

Je ne m'aventurerai pas vers une telle conclusion sur un cas particulier. J'ai réalisé quelques migrations D7 -> D8 sans avoir rencontrer les soucis que vous évoquez. Cela s'est réalisé même plutôt en douceur. Mais cela dépend très certainement aussi du site source. C'est difficile d'en tirer des généralités.

Soumis par Michael Cottrell (non vérifié) le 07/07/2017 à 22:07 - Permalien

Quel article si bien équilibré! Ce n'est clairement pas la défense d'un "fanboy", mais un survol de Drupal 8 avec toutes ses qualités et défauts. Une omission m'apparaît évidente: au début de l'article, "un [sic] récente étude comparative de Drupal et SPIP" devrait inclure un lien vers l'étude en question.

Merci pour le signalement de la typo. C'est corrigé. Cette étude n'est pas disponible en ligne. C'est pourquoi il n'y a pas de lien. Mais en substance, elle ne fait qu'affirmer de façon succincte les différents points soulignés par ce billet (Drupal 8 est plein de bugs, Drupal 8 n'est pas sécurisé, Fin de maintenance de Drupal 8 en 2019, etc.).

Soumis par Maïeul Rouquette (non vérifié) le 16/07/2017 à 11:44 - Permalien

<blockquote>
Clairement nous ne parlons pas du tout de la même chose ici. Des données structurées permettant des croisements de contenus, des navigations transversales ou verticales, permettant des mises en page complètement maîtrisées par la couche de thème, et non par l'auteur du contenu dont ce n'est ni le travail ni la vocation, n'ont rien à voir avec l'utilisation d'un champ texte unique où on y insère pelle-mêle, tant bien que mal, ses contenus et leurs mises en forme.
</blockquote>

Pour le coups, il y a là une profonde méconnaissance de SPIP.
D'une part, les raccourcis SPIP ne mettent pas en forment, mais en sens (structure de titre, emphase, listes etc.)
D'autre part, SPIP permet d'avoir plus qu'un champ texte, même si par défaut il n'y a que celui là qui est affichée.

L'objet de base de SPIP est l'article (au sens d'article de journal) qui comprend donc:
- un chapo (désormais masqué par défaut)
- un texte
- un ps (désormais masqué par défaut)

Mais depuis un bout de tps il est possible d'ajouter ses propres champs (champ extra) et de concevoir ses propres objets (API Objet + si on souhaite le clickodrome "fabrique").

Donc oui SPIP propose des éléments structurés … Que le site que vous avez migré ne les a pas utilisés est un autre problème.

Soumis par fabrice le 16/07/2017 à 21:30 - Permalien

En réponse à par Maïeul Rouquette (non vérifié)

Merci pour votre retour. Oui en l'occurrence je connais très mal SPIP, comme indiqué en introduction. Mais la comparaison portait entre les champs de Drupal et ses possibilités de composition, avec Paragraphs entre autre, et les raccourcis typographiques de SPIP qui ne sont ni plus ni moins que des shortcodes (ou tout simplement du markdown) à insérer dans le body. Très bonne nouvelle que SPIP puisse disposer d'éléments structurés. Dommage que la plupart des sites SPIP que j'ai vu n'en dispose pas.

Salut fabrice,
je ne connais pas des masses Drupal non plus, mais du coup, est-ce que tu pourrais nous donner un exemple de ce que tu appelles du "contenu structuré", de quelle structure tu parles, etc ? Ou bien sans t'embêter, une ou plusieurs URL de doc de cette fonctionnalité ou d'exemples qui l'utilisent ? Ça m'intéresse de comprendre, et donc de savoir s'il existe vraiment un équivalent ou pas, justement pour savoir avec quoi ça devrait être comparé. :)

Ce que j'entends par "données structurées" est de structurer les différents informations d'un contenu dans des champs séparés et dédiés à ce type d'information (champ date pour une date, champ décimal pour un prix, champ texte simple + auteur pour une citation, champ téléphone pour un téléphone, champ mail pour un mail, champ lien pour un lien, etc.) et ne pas avoir toutes ces infos dans un champ texte unique.

Ceci permet de mieux controller le rendu de ces éléments, sans que l'auteur n'ait à s'en soucier (contrairement à un champ body unique). Et aussi de pouvoir bien sûr requêter / trier ces contenus en fonction de ces attributs connus. Ou encore déclencher des logiques métiers en fonction de ces attributs.

Entre outre cela permet aussi de donner un contrôle complet à l'auteur d'un contenu pour réaliser des mises en page complexes, sans qu'il ait à se soucier de leur mises en forme. Mais ceci fera l'objet d'un prochain billet sur le sujet. Un récent billet sur le sujet peut être une bonne introduction : https://www.previousnext.com.au/blog/component-based-design-paragraphs-…

Ajouter un commentaire