La parole est aux speakers : Vincent Toullec

Jusqu’à l’AFUP Day 2021, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Toi qui es un grand fan de Symfony, comment en es-tu venu à faire du Drupal ?

Ma première expérience sur Drupal s’est faite par le biais d’APSIDE, dans le cadre d’un nouveau projet pour un grand groupe de prestation de déménagement.

En théorie, mon profil de développeur Symfony devait être un atout pour aborder ce CMS. Il s’est avéré que prendre en main un CMS, même s’il est basé sur un framework, n’est pas chose facile.

Beaucoup de concepts théoriques doivent être maîtrisés avant de pouvoir exploiter correctement Drupal, et surtout éviter de réinventer la roue, ou s’orienter vers une solution sans avoir pris en compte les concepts propres au CMS.

Le client fait souvent le choix du CMS au détriment des frameworks. Qu’en penses-tu ?

Dans l’absolu, ce n’est pas une mauvaise idée, les clients ont fini par comprendre qu’ils auraient plus de liberté dans la rédaction de contenus avec un CMS qu’avec un framework.

Grâce aux nombreux plugins communautaires, on trouve rapidement ce qui conviendra aux rédacteurs et rédactrices de contenus, sans besoin de développements spécifiques.

Cependant, cet atout des CMS se heurte aux besoins particuliers des clients.

Par exemple, le client pourrait demander l’implémentation d’un calendrier de rendez-vous, mais devant répondre à des contraintes métiers. Dans ce genre de cas, même si un plugin communautaire aurait pu faire l’affaire, les devs vont certainement devoir développer un plugin from scratch pour avoir la totale maîtrise des fonctionnalités et contraintes de ce calendrier.

Les développeurs ou développeuses doivent alors être force de proposition et évaluer la proportion / le nombre de contenus à rédiger VS nombre de fonctionnalités.

Dans le cas d’un client qui veut rédiger énormément de contenu, le CMS suffira, avec peut-être quelques widgets à développer.

Pour un site web qui comporte une majorité de widgets dans des pages avec un contenu simple (titre / intro / contenu / image), un framework suffirait amplement.

Mon analyse est fortement influencée par mon expérience sur Drupal. Donc un CMS, bien exploité, ne sera pas forcément un frein pour les devs.

Malheureusement le client peut toujours avoir le dernier mot sur le choix du type de techno.

Trouves-tu que le mode « Headless » est un bon atout pour les CMS ?

Des nouveaux frameworks Front End voient souvent le jour, simplifiant de plus en plus la création d’interfaces graphiques dynamiques, ce qui est souvent plus complexe à faire avec des CMS.

Le couple CMS Headless et Front End JS (ou autre que JS) est très intéressant dans le sens où la logique métier va être isolée dans le front, et la rédaction de contenu ou les éléments de configuration seront stockés côté CMS.

Partant de là, on peut imaginer beaucoup de cas pratiques en front : une application mobile hybride, un framework qui consomme des éléments de configuration ou du contenu, ou plusieurs plateformes qui consomment la même instance de CMS.

Les plugins communautaires permettent de couvrir les aspects sécurité, l’authentification ou le format d’export des données.

Dans le cas de Drupal j’ai pu testé différents modes Headless :
– Natif : grâce au plugin JSONAPI
– Personnalisé : via un plugin custom qui construit le flux JSON selon mes besoins
– Views : C’est un plugin natif Drupal qui permet de mettre à disposition des flux de données, configurables via le Back-End. On peut d’ailleurs y plugger un module d’authentification  par clé d’API.

Je pense que le mode Headless est le futur des CMS, car la couche Front-End des CMS ne me paraît pas assez flexible.