La qualité d'un CMS ne se juge pas seulement au travers de la qualité de son architecture, de son API, mais aussi au travers de ses fonctionnalités out of the box, permettant d'accomplir des mises en page, des comportements spécifiques, en quelques clics. On peut rapprocher la valeur d'un CMS avec celle du diamant. La valeur d'un diamant brut ne vaut pas grand chose, tandis que celle d'un diamant travaillé est sans commune mesure.
Et c'est cette qualité qui est la première ressentie lors d'une première découverte de Drupal 8. La richesse des modules de Drupal 8 contribue à cette qualité, et favorise l'entrée de nouveaux utilisateurs, quelque que soit leur profil. Moi-même je ne suis pas sûr que je serais rentré sur Drupal sans cette richesse fonctionnelle, accessible à tous.
Drupal 8 est un framework extrêmement puissant, modulaire. Cet aspect s'adresse avant tout à un public de développeurs, soit quelques dizaines (ou centaines) de milliers d'utilisateurs, qui sont aussi la force vive, productive de Drupal. Mais la cible de Drupal, en tant que gestionnaire de contenus, n'est-elle pas aussi ce public amateur, ces quelques millions d'utilisateurs, aux profils variés, utilisateurs qui deviendront potentiellement contributeur, développeur, thémeur, testeur. ils ne doivent pas devenir les parents pauvres de Drupal 8. Ces utilisateurs qui ne franchissent pas le pas vers Drupal 8 aussi car tel ou tel module, qui peut être au demeurant très simple, n'est pas porté sur Drupal 8.
Réaliser un projet Drupal 8 ne nécessite pas forcément d'être un expert Drupal 8 ou plus simplement un développeur Drupal 8. Certaines de ses nouveautés, comme sa gestion révolutionnaire du cache par exemple, sont à disposition de tous, sans une once de configuration (cf. Faut-il un expert Drupal 8 pour se lancer ?). Mais il est vrai aussi qu'il est rare de pouvoir réaliser un projet Drupal 8 aujourd'hui sans devoir à un moment ou un autre se lancer dans le code ou appliquer un patch ou deux. Sans doute parce que les projets Drupal 8 ont tendance à adresser des projets aux logiques métier spécifiques aussi (ou plutôt l'inverse).
Dans le même temps, de nouvelles initiatives ont vu le jour suite à la DrupalCon 2016 (Nouvelle Orléans) visant à exploiter la nouvelle architecture de Drupal. Ces initiatives visent à intégrer dans le coeur de Drupal de nouvelles fonctionnalités, orientées sur le contenu mais aussi l'expérience utilisateur entre autres, au fur et à mesure de ses versions majeures publiées tous les six mois, au moyen des modules expérimentaux (Content moderation par exemple, ou encore Place blocks, Settings Tray, la gestion des médias avec la suite Media entity intégrée au coeur de Drupal à partir de la version 8.4). Mais comme leur nom l'indique, il n'est pas conseillé d'utiliser ces modules en production, car ils peuvent à tout moment être modifiés structurellement sans rétro-compatibilité ni chemin d'upgrade, sauf à disposer de quelques développeurs (très) expérimentés pouvant assurer ces transitions qui peuvent être douloureuses.
Aussi bien la perspective de disposer de solutions riches et disponibles nativement dans le coeur de Drupal est réjouissante, force est de constater qu'il est à tout le moins risqué de les utiliser maintenant, tant qu'elles n'auront pas dépassé ce stade expérimental. Est-ce cet espace temps incertain de la transition qui fait qu'on puisse préférer des solutions sur mesure, car maîtrisées, à des modules en cours d'intégration au coeur ? L'incertitude est l'ennemie de l'investissement comme on dit. La politique des modules expérimentaux, pour ceux qui la lise, peut en refroidir plus d'un. Une évolution de cette politique, avec une phase intermédiaire assurant un chemin d'upgrade, ne pourrait-elle pas élargir le panel d'utilisateurs de ces modules expérimentaux, et donc élargir le public qui indirectement ou directement va participer à leur finalisation, que ce soit au travers de rapport de bugs, de tests, d'améliorations, de corrections ?
C'est justement cette voie qui vient d'être adoptée avec le changement de politique sur la gestion et l'intégration des modules expérimentaux dans le coeur de drupal 8 (cf. [policy, no patch] Adjust experimental modules process/requirements in response to user/developer feedback). Et ceci est une très bonne nouvelle, car désormais les modules dits expérimentaux seront intégrés dans le coeur de Drupal 8 en version bêta au minimum, ce qui signifie qu'ils bénéficieront d'un support et d'un chemin d'upgrade le cas échéant. Et que nous pourrons les utiliser au plus tôt, mais sans risquer l'infarctus à chaque mise à jour.
Au risque de décevoir les plus téméraires d'entre nous.
Ajouter un commentaire