Drupal 8 – Un futur découplé

    Les contenus digitaux ont évolué vers une distribution multi-format et multicanal. Nous nous attendons à pouvoir les consommer à tout moment et n'importe où. Comment cela influence-t-il les WCMS tels que Drupal ? Découvrez pourquoi le futur de Drupal est « découplé » et quelle importance cela revêt pour les rédacteurs, les administrateurs et les utilisateurs.

    Abonnez-vous à notre blog

    Une architecture SGC « découplée » signifie que deux systèmes ou plus sont capables de communiquer sans être directement connectés (ou « couplés »). D'ordinaire, un système a une connaissance très limitée des autres systèmes. Mais quels sont les avantages d'une architecture découplée ? Une structure découplée permet d'apporter des modifications à un système sans en affecter un autre. Cela confère davantage de flexibilité à la réutilisation d'un même contenu pour différentes interfaces. Le SGC, à l'épreuve du temps, s'adaptera facilement à tous les canaux émergents.

    Avec une architecture SGC découplée, les responsabilités sont également réparties entre les deux couches (voir la figure ci-dessous). Les systèmes consommant des contenus n'ont pas à se soucier de l'architecture des données, de la sécurité, de l'infrastructure ni d'autres facteurs, et le fournisseur de données (le service Web, dans notre cas particulier « Drupal découplé », dans lequel les éditeurs de contenu travaillent) n'ont pas à se préoccuper de la technologie frontend, de la mise en page, etc.

    Lorsque nous transposons cela à la configuration typique de Drupal, nous établissons essentiellement une ligne de démarcation entre la couche de présentation et l'administration de contenu de Drupal (frontend vs backend). On appelle cela « SGC (ou CMS) sans tête », où dans ce cas précis « Drupal sans tête », car les utilisateurs ne voient généralement pas la « tête », ou le thème de l'installation du SGC Drupal.

    Drupal 8 – Un futur découplé

    Dans cette configuration, Drupal agit uniquement comme fournisseur de données (service de contenu). Drupal fournit du contenu dans son format brut par l'intermédiaire de services Web (un type de mécanisme de communication entre différentes applications logicielles). À charge pour les consommateurs de ces données (les systèmes qui utilisent les services Web) de manipuler et de présenter visuellement les données. Prenons, par exemple, une instance Drupal qui fournit des données simples sur des événements via un service Web. Une application de calendrier iOS ou un site Web répertoriant tous les événements constituent deux types de consommateurs potentiels de ce contenu. Dans un tel cas, ces deux consommateurs (l'application et le site Web) récupèrent les données brutes (textuelles). Ils doivent ensuite manipuler les données collectées (afin de filtrer les informations qu'ils sont censés visualiser) et appliquer leurs styles respectifs (par exemple, créer un balisage HTML, appliquer une feuille de style CSS, etc.).

    Pourquoi un Drupal découplé ?

    Jusqu'à la version 7 de Drupal (2009), la consommation de contenu en ligne était quasi-limitée aux navigateurs sur les ordinateurs de bureau. Avec le développement des écrans tactiles et des appareils portables tels que les smartphones et les tablettes, l'accès mobile en ligne a progressivement gagné du terrain par rapport aux autres postes de travail, pour aboutir à une approche « mobile-first » des canaux digitaux. La présentation par défaut du contenu ne devait plus simplement être adaptée aux grands écrans d'ordinateurs, mais devait être optimisée pour tous les types d'écrans, des téléphones aux tablettes, en passant par les téléviseurs. La priorité absolue était et reste toujours de rendre le contenu non seulement disponible mais également entièrement fonctionnel, et de l'optimiser pour toutes les résolutions d'écran.

    Cependant, ces dernières années, nous observons un grand nombre de moyens alternatifs visant à afficher des contenus, allant de différents frameworks JavaScript, tels que AngularJS, ReactJS, Vue.JS.., des applications mobiles natives Android ou iOS à des widgets ne capturant que de petits morceaux de contenu afin de pouvoir les faire apparaître sur d'autres interfaces.

    Si nous désirons atteindre cet objectif avec Drupal, nous devons (entièrement) découpler le modèle de contenu du moteur de modélisation (Twig dans Drupal 8) afin d'exposer le contenu dans le système choisi par l'utilisateur.

    Ce principe s'appuie sur ce que nous appelons « COPE » (« Create Once, Publish Everywhere » ou « Créer une fois, et publier n'importe où »). Il s'agit d'un concept similaire à la publication à source unique, qui signifie que tous les contenus sont gérés dans un référentiel central (backend Drupal) et sont distribués à travers tous les canaux (« Pushed / Poussés » ou « Pulled / Tirés », lorsque les données sont requises).

    Un futur avec API-first ou bien découplé en dur ?

    Au cœur de Drupal 8, un support de base pour les services REST et l'échange de données est déjà en place. Mais l'API REST ne se laisse pas installer ni configurer facilement. Pour un découplage complet, Drupal nécessite encore un peu plus de développement. Deux initiatives communautaires travaillent actuellement sur ce sujet.

    La plus importante et la plus concrète est l'initiative API-first, dirigée par Wim Leers. Les contributeurs à API-first travaillent constamment afin d'améliorer l'API REST actuellement disponible, qu'ils promettent être la « meilleure de leur catégorie ». Avec plus de flexibilité, celle-ci vise à prendre en charge de nouveaux types d'intégration, un découplage progressif, puis un découplage total. L'objectif final est de rendre toutes les données de Drupal disponibles dans les deux API :

    • Une méthode RESTfully, prenant en charge JSON ou tout autre format de service REST au-delà de la valeur par défaut
    • Une méthode non-RESTfully, par exemple GraphQL ou CouchDB
    • Utiliser n'importe quel mécanisme d'authentification standard, à la fois pour les sites Web et les applications mobiles natives, par exemple OAuth2 et Cookie.

    Dans les prochaines versions de Drupal, nous verrons beaucoup d'avancées provenant de cette initiative. La plupart des nouvelles fonctionnalités doivent s'établir dans un module de contribution « stable » afin de pouvoir poursuivre la voie requise en vue d'une introduction dans la base Drupal. Cela signifie que ce module doit être disponible sur toutes les installations Drupal en tant qu'add-on. Si le « core comittee » (comité de base Drupal) prend la décision de transférer cette fonctionnalité vers la base, il sera alors sûr et certain qu'une version stable aura déjà été testée au préalable.

    Tout ce qui précède permet à Drupal d'être utilisé comme fournisseur de données « sans tête », mais une installation entièrement couplée est toujours nécessaire. Avec toute la dynamique de découplage, serait-il possible que Drupal évolue vers une API-only, plutôt qu'une API-first, ou encore une architecture entièrement découplée ? Il existe certainement un marché pour cette approche du côté du développement frontend dont nous avons parlé ci-dessus, ainsi que du côté back office administratif.

    Une deuxième initiative approuvée par le comité consiste à trouver un moyen de moderniser les pages de back office actuelles, qui datent de plusieurs années et qui n'ont été remises à jour que récemment. L'approche actuelle (ou preuve de concept) consiste à remplacer cette page par une application React à page unique. Bien que cette étape soit encore à un stade précoce et qu'il reste encore beaucoup de travail, il est certainement intéressant de voir le comité Drupal prendre une telle décision.

    Selon nous, il existe un certain nombre de questions ouvertes qui seront résolues au fur et à mesure de nos avancées :

    • Qu'adviendra-t-il du moteur de modélisation actuel (Twig) ? Les applications Twig et React fonctionneront-elles côte à côte ? Twig deviendra-t-elle « optionnelle » ?
    • Il existe des centaines de modules contribués. Sera-t-il nécessaire d'ajouter le support d'une interface découplée à chacun d'eux, ou retomberont-ils sur Twig ?
    • Est-ce une bonne idée de faire un choix fixe de framework (React) pour la base Drupal ?
    • Y aura-t-il un profil d'installation Drupal entièrement découplé ?

    En fin de compte, l'objectif est de créer une architecture de SGC découplée, tout en offrant une expérience monolithique. Les utilisateurs, les rédacteurs ainsi que les administrateurs ne se préoccupent pas de savoir si un site est découplé, rendu par Drupal ou encore par un code HTML statique. Ils veulent que leur expérience soit aussi fluide et cohérente que possible, tandis que les développeurs attendent une flexibilité maximale.

    Publié sur    Dernière mise à jour le 16/08/2018

    #Drupal, #Stratégie Digitale, #Gestion de Contenu, #Développement Web

    À propos de l'auteur

    Kevin is Drupal Web Developer and Consultant at Amplexor based in Belgium. Kevin is an Acquia Certified Developer with over 6 years of experience in planning, development, maintaining Drupal websites and leading development teams in Drupal. He has also volunteered at the organization of the yearly Belgian DrupalCamp event.

    SUBSCRIBE TO OUR BLOG