Planète JulienD

Drupal est un très bon outil, il est réputé, modulable et est utilisé par beaucoup d’entreprises et organisations. J’ai eu la chance de participer à beaucoup de projets ces 5 dernières années, et j’ai pu constater à quel point on pouvait en user et en abuser.
La réalisation d’un projet web est un subtil dosage entre les contraintes métiers et les contraintes de l’outil.
La flexibilité de Drupal conduit malheureusement parfois à vouloir trop l’adapter et à le tordre pour répondre au besoin tout en espérant que cela n’aura pas d’impact. Un outil reste un outil, c’est pourquoi dans ce post, j’essaie de vous donner quelques pistes afin que vous puissiez définir si oui ou non Drupal est un bon choix pour votre projet.

Quels sont les besoins métiers que vous devez réaliser ?

Avant de savoir si Drupal est fait pour vous, il est important de comprendre ce qui doit être fait. Trop souvent j’ai vu des entreprises se ruer sur le choix de la technologie avant d’avoir pleinement défini les problèmes à résoudre. Définissez ce que vous avez besoin de faire, ce que votre client veut, les problématiques métiers à résoudre et ce que les utilisateurs finaux attendent.

Le diable se cache dans les détails, ne vous contentez pas simplement d’une petit phrase expliquant ce qui doit être fait. Voici un exemple client que j’ai rencontré : « L’outil doit fournir un système de modération des contenus ». Rien de terrifiant en soi, néanmoins de la simple checkbox, au workflow complexe avec validation et rôle utilisateur, il existe des dizaines de solutions pour implémenter cela. Il est donc important que vous définissiez comment les choses doivent fonctionner et non pas simplement ce qu’elles doivent faire pour pouvoir évaluer si l’outil est adapté.

Est-ce que vous devez faire du E-commerce, Gérer des milliers de contenus, une disponibilité proche des 100% ou constuire une application affichant des données en temps réel ? C’est autant de questions que vous devez vous poser.

Quelle est la part du projet qui est réalisée nativement ?

Drupal dispose d’un coeur minimaliste qu’il est possible d’étendre avec ce que l’on appelle des modules. Ainsi, si votre besoin n’est pas natif, il existe surement dans un module. Avec le nombre de projets réalisés sous Drupal, il y a fort à parier que quelqu’un a déjà rencontré le même besoin et qu’il ait avec un peu de chance créé un module sur drupal.org.
Pour savoir si Drupal est fait pour vous, vous devez apprendre à le connaitre, découvrir ses forces et ses faiblesses. Arpenter la liste de modules afin de trouver ceux qui vous conviennent le mieux, inspecter le coeur pour savoir ce qu’il s’y cache.
Bien souvent un module réalise entre 60 et 80% de ce que vous souhaitez faire, ne négligez surtout pas la part manquante à réaliser. Ajouter un besoin supplémentaire à un module existant sans le hacker ou l’ endommager n’est pas toujours une mince affaire. Attention toutefois, certains modules nécessitent d’autres modules pour fonctionner et certains modules ne sont pas compatibles entre eux. N’hésitez pas à lire : [comment choisir un module Drupal en seulement 5 étapes]. De même que, si vous n’avez pas besoin de l’améliorer ou de le modifier, il y aura toujours une part de « Glue code », permettant de l’intégrer pleinement à votre site à estimer.

Avez-vous une idée de la part de sur-mesure à réaliser ?

Drupal est développé en PHP et est facilement extensible par le biais de modules. En utilisant les forces du langage on peut développer ce que l’on veut et ainsi le transformer en n’importe quoi. Pour la petite anecdote, il m’est arrivé par le passé de déconseiller l’utilisation de Drupal à un client. L’équipe technique a fait le choix de ne pas suivre mon conseil et a choisi d’adapter Drupal au besoin. Résultat, le développement du projet a été un fiasco complet, problème de performance, code spaghetti et retard de livraison pour finalement tout arrêter et repartir sur un framework comme je l’avais préconisé quelques mois avant. La leçon à retenir est que si la part des développements sur-mesure à faire est trop grande par rapport aux avantages de l’outil, il faut prendre conscience que ce n’est certainement pas le meilleur choix pour vous.

Vous devez donc comprendre et estimer ce qui relève du natif, ce qui peut être réalisé facilement grâce à un module et ce qui approche les limites de l’outil (limites de performances, de maintenabilités, d’architectures…).

Est-ce que votre équipe maitrise Drupal ou pas ?

Depuis longtemps maintenant, il est admis que la courbe d’apprentissage de Drupal (en comparaison avec d’autres CMS) est longue. Il faut compter entre 1 et 3 mois pour qu’un développeur s’y retrouve facilement entre ce qui est fourni par le coeur de Drupal et ce qu’il est possible de faire grâce aux modules contribs. Prenez en compte le niveau d’expérience de votre équipe. N’hésitez pas à faire appel à un architecte ou à un lead dev (nb, l’auteur est freelance) pour vous épauler dans le cas où votre équipe serait novice.

A noter qu’il n’y a pas seulement l’équipe technique à prendre dans l’équation, il est important que les chefs de projet et product owner connaissent aussi l’outil.

Quel est votre budget ?

Et oui, il faut parler argent quand on parle de projet Drupal. Même s’il n’y pas de coût de licence, vous aurez d’autres coût auxquels il faudra faire face. Côté infrastructure, Drupal est assez gourmand, il vous faudra donc un hébergement de qualité et bien dimensionné. Coté développeurs c’est comme partout, les bons s’arrachent à prix d’or et sont souvent occupés des mois à l’avance. De plus, il y a plus d’offre que de demande, ce qui fait qu’il n’est pas toujours simple de constituer une équipe de qualité.

Quel est la taille de votre projet ?

Il faut être honnête, Drupal est conçu pour faire des gros sites et pas pour de simples sites vitrines. La robustesse de l’outil nécessite beaucoup de choses, du temps, des moyens, des connaissances. Or, je trouve que le retour sur investissement réalisé sur des petits projets n’est pas à la hauteur de ce qui pourrait être fait avec un wordpress par exemple.

Conclusion

Il n’existe pas de formule miracle pour déterminer si Drupal est un bon choix ou non pour un projet, cela dépend de plusieurs facteurs. A vous de mesurer les avantages et inconvénients entre le planning, le budget, l’engouement technologique, la motivation de l’équipe et leur capacité à apprendre.

C’est indéniable le web bouge et c’est certainement l’une des industries ou les outils évoluent aussi vite et sont aussi éphémères, ce qui est à la mode aujourd’hui ne le sera potentiellement plus demain. Le monde des CMS/CMF n’est pas épargné et subit son lot d’évolutions. Le problème n’est plus de savoir si telle ou telle fonctionnalité existe mais bel est bien de savoir si l’outil est capable de communiquer et de s’intégrer avec d’autres applications. Cette mutation du web a permis l’apparition de nouveaux usages tels que les SPA (single Page Application) ou MBaaS (Mobile Backend as a Service) dont le but est d’afficher des données dans un front web désolidarisé du backend.

Dans les articles précédents sur l’évolution des sites web et sur pourquoi Drupal 8 a subit une telle évolution Frédéric G. Marand et moi avons évoqué les applications orientées composants ou services. Par le passé, Drupal a prouvé qu’il était un excellent système de stockage de données et qu’il était capable d’exposer ces informations. Drupal 8 ira plus loin en intégrant cette capacité à s’associer de façon transparente avec d’autres applications externes à son coeur.

Drupal 8, l’impact sur les applications futures

L’application monolithique est un grand classique pour les projets réalisés avec Drupal, pour autant ce n’est pas parce qu’on peut tout faire avec que c’est une forcément une bonne idée. Est-ce que si votre boulanger se mettait à vendre des voitures et des outils de bricolage dans sa boutique vous ne trouveriez pas ça étrange ?

Comme l’a dit Frédéric, l’heure de gloire de la publication simple est derrière nous, aujourd’hui les attentes du marketing portent sur la personnalisation de l’expérience utilisateur en fonction des données acquises. Cela implique que les utilisateurs soient connectés et aient une identité persistante multisupport. On parle alors de session multi-device qui permet de reprendre la navigation ou encore vos achats là où vous en étiez et ce quel que soit le support.

Or lorsque Drupal fabrique ses pages pour un utilisateur connecté (pages générées à la volée et non chargées depuis le cache) cela consomme beaucoup de ressources. Il est rare de voir des pages de front web fabriquées avec moins de 50 requêtes SQL et autant de chargements de cache. Drupal est un outil performant pour la gestion de contenus néanmoins il n’est pas réputé pour ses performances d’affichage (cas pour un Drupal de base sans optimisation).

Ainsi la partie affichage à l’utilisateur final est susceptible d’être déplacé hors de Drupal en tant qu’application distincte basée sur des Javascript tels que AngularJs ou React afin de servir à la fois du web et du mobile qui ne cesse de grandir. C’est ce que l’on appelle le « headless Drupal ». Laissons à Drupal ce qu’il sait très bien faire, stocker et manipuler les données et déportons le front vers des technologies plus souple et plus rapide à mettre en place. Pour vous donner un exemple d’utilisation, on pourrait créer un B.O. unifié pour vos utilisateurs qui centraliserait vos contenus et vos produits puis différents sites web ayant chacun une thématique particulière qui viendraient consommer un webservice de façon à proposer des contenus ou produits à l’utilisateur.

Ainsi il faudra repenser Drupal comme un service de backend utilisé par des applications tiers qui consommeront des webservices pour servir l’expérience utilisateur, tout en gardant des temps de réponses performant grâce à la paralellisation.

Cette séparation entre le front et le back de l’application va nous offrir l’opportunité de raccourcir les cycles de développement et augmenter son efficacité tout en utilisant les dernières technologies et methodologies. La mutation de Drupal en API de contenus va permettre de réduire les problématiques multi-devices que l’on rencontre couramment.

Drupal 8 est à un point important de son évolution, ça passe où ça casse. Cette métamorphose à venir est de loin la plus grosse refonte qui ait été faite. Et vous, comment voyez-vous le futur des applications Drupal ? Comment comptez-vous vous y prendre ?

Il y a un mois de cela, lors de l’appel aux sessions pour Drupagora j’ai proposé plusieurs sujets en relation avec le thème de l’année qui était le E-commerce, malheureusement aucune session n’a passé la sélection. Néanmoins le comité de pilotage est revenu vers moi en me demandant de parler de l’avenir de Drupal, de l’impact sur le développement web et du futur des applications.

Dans ce sujet on ne peut plus vaste, qui touche à la fois à Drupal, aux technologies actuelles et à l’architecture logicielle j’ai souhaité ne pas uniquement donner mon point de vue et c’est pourquoi j’ai demandé à Frédéric G. Marand de co-animer cette session avec moi afin d’être le plus proche de la réalité. Difficile de trouver mieux comme co-présentateur en terme d’expérience et de contribution que ce soit dans la communauté Drupal ou ailleurs.

Nous avons donc passé quelques heures à confronter nos idées et points de vues afin de présenter notre vision du futur. Voici la synthèse de notre session résumée en quelques billets de blog :

• Le web et son évolution, du code maison au Micro-Framework
• Les changements dans le développement d’applications
• Drupal 8, les conséquences de cette évolution signifie
• Une vision sur l’avenir proche du web

La présentation de notre session :

“It’s ready, when it’s ready!” Nous connaissons tous cette citation, qui fait partie de la communauté Drupal. Ce n’est un secret pour personne, Drupal 8 sera bien plus compliqué à appréhender que les versions précédentes. Malheureusement il est encore impossible de définir une date de sortie, néanmoins on peut se dire qu’il nous reste encore quelques mois devant nous. Utilisons ainsi ce temps pour comprendre et découvrir tous les pré-requis de cette nouvelle version.

Depuis quelques mois maintenant j’ai commencé à agréger une liste d’articles de façon à être au point sur les dernières nouveautés apportées par D8. Du coup, voici un résumé des meilleurs ressources que j’ai pu trouver.

Notez que dans ce billet je ne parlerai pas des nouveautés de Drupal 8 mais plutôt des bases à avoir pour commencer à développement avec Drupal 8.

Programmation PHP moderne

POO, Classes et objets.

La Programmation Orientée Objet n’a rien de nouveau et s’est standardisée dans tous les languages de développement et frameworks, pourtant c’est assez nouveau dans le monde de Drupal. Jusqu’à maintenant réservée à quelques spécificités, la POO fera partie intégrale de Drupal 8. Rien de tel que de revoir ses bases pour être au courant des dernières nouveautés, voici quelques liens qui pourront vous aider.

Ressources :

• Documentation officielle PHP au sujet de la POO (En).
• PHP the right way (En).

Namespace

Les namespaces sont arrivés avec PHP 5.3 afin de résoudre deux problèmes avec les fonctions et les classes quand on veut écrire du code réutilisable. Premièrement, la collision de même nom entre portion de code et deuxièmement la possibilité de créer des alias pour les noms longs de fonction ou de classe à rallonge. Avec cette nouvelle version de Drupal, vous trouverez l’utilisation des namespaces un peu partout.

Ressources :

• Documentation officielle PHP sur les namespaces (En).
• Comment utiliser les namespaces en PHP (En) via Sitepoint.

Autoloaders, PSR-0 et PSR-4

PSR–0 est un standard de chargement de classe (l’autoloading) permettant de définir une façon automatique d’inclure des classes PHP sans avoir à utiliser les fonctions telles que require() ou include(). PSR-0 se base sur le namespace d’une classe afin de définir sa position dans le file system.

PSR-4 a pour objectif de réduire la structure des dossiers pour l’autoloader. Cela a fait couler pas mal d’encre dans sur drupal.org – Drupal and PSR-0/PSR-4 Class Loading.

Ressources :

• Standard de l’autoloading – PSR-0 (En).
• Autoloaders: PSR-0 vs. PSR-4 (En) via sitepoint.
• namespaces et autoloading pour Drupal 8 (En).

Annotations

Les annotations sont des meta-datas qui peuvent être ajoutées à votre code afin d’être lues lors de l’execution de celui-ci. Cela sert pour la définition et la configuration mais les annotations n’affectent pas la sémantique du code.

Personnellement je ne suis pas un grand fan des annotations, pour moi les commentaires doivent rester des commentaires, de façon à donner des informations et de la description sur le comportement d’une fonction. Changer un commenta ire ne devrait pas changer le comportement d’une fonction.

Ressources :

• Les annotations en PHP (Fr) cette présentation faite par Rafael Dohms décrit très bien le principe des annotations.
• Drupal 8 et les plugins basés sur le système d’annotation (En)

Design patterns

Il y a de fortes chances que si vous avez à résoudre un problème de conception, un autre développeur l’ait déjà résolu. Ainsi les design patterns (En) sont des guides applicables à n’importe quel language de programmation de façon à solutionner un problème. L’avantage d’utiliser des design patterns est que cela rend votre code plus maintenable, et que cela offre une solution éprouvée.

Ressources :

• Guide du débutant aux design patterns (En) via tutsplus.

Dependency injection

C’est certainement l’un des design patterns les plus compliqués à bien expliquer, toutefois c’est probablement l’un des plus simple à utiliser. Ok, le nom est effrayant, mais je suis sûr que vous l’appliquez sans le savoir. Pour bien comprendre ce que c’est, je vous suggère de regarder comment Fabien Potencier l’explique.

Ressources :

• Qu’est-ce que l’injection des dépendances ? (En) par Fabien Potencier.
• Introduction à Pimple et les services containers (En) de Juan Treminio.

Symfony 2

Ce n’est plus la nouvelle de l’année, Drupal 8 utilisera quelques composants tout droit venus de Symfony 2. Comme souvent il y a du pour et du contre sur le fait d’apprendre Symfony 2 pour faire du Drupal 8. Personnellement, Je dirais qu’y jeter un coup d’oeil avant de jouer avec D8 ne vous tuera pas, au contraire cela vous permettra certainement de mieux comprendre certain concepts. En bref, quelques heures à regarder et découvrir Symfony 2 est un bon investissement.

Ressources :

• Documentation officielle de Symfony 2 (En)
• Créez votre propre framework… Grace à Symfony2 (En) par Fabien Potencier.

Si vous souhaitez aller un peu plus loin et avoir une vue plus complète des composants SF2 inclus dans Drupal 8, je vous suggère de lire cet article you got Symfony in my Drupal 8 (En) ou celui-ci Symfony 2 in Drupal 8 (En)

Bibliothèques additionnelles ajoutées à D8

En plus de ce que l’on a déjà pu voir, Drupal 8 inclura des librairies externes de façon à ne pas réinventer ce qui existe. D’ailleurs quelques-unes de ces librairies sont utilisées dans l’écosystème Symfony.

Composer

Composer est un outil de gestion des dépendances qui a été adopté en D8 pour gérer les bibliothèques additionnelles telles que Symfony ou encore Twig.
A la racine de Drupal vous pourrez apercevoir un fichier nommé composer.json, structuré d’une certaine manière de façon à définir les dépendances ainsi que leurs versions.

Ressources :

• Documentation officielle (En)
• Composer pour les développeurs occupés (En) par Rafael.

Doctrine

Doctrine Database Abstraction Layer (DBAL) est une surcouche d’abstraction entre l’application et la base de données. Cette API permet de s’interfacer simplement avec la plupart des système de base de données.

N’ayez crainte, Doctrine ne fait pas vraiment parti de Drupal 8 (certainement pour D9), Drupal 8 utilise seulement le composant de lecture des annotations de Doctrine (Cf le commentaire de Chx sur drupal.stackexchange).

Ressources :

• Documentation officielle (En)
• D.org – Pensez à utiliser Doctrine pour les entités (En)

Easy RDF

EasyRdf est une bibliothèque PHP permettant de manipuler simplement et efficacement du RDF.

Ressources:

• Site officiel (En)

Guzzle

Guzzle est un client HTTP en Php qui permet de s’interfacer avec des applications tiers mettant à disposition des web-services.

Ressources :

• Guzzle, consommer des web-services facilement (Fr)
• Documentation officielle (En)

PHPUnit

PHPUnit est un framework de test P-Sour PHP. Celui-ci à été choisi en remplacement de Simpletest comme nouvel outil afin d’assurer la qualité du code de D8. On ne le répétera jamais assez, mais les tests unitaires sont la meilleure méthode pour détecter une regression sur un projet.

Ressources :

• Documentation officielle (En)
• D.org – manuel PHPUnit (En)

Twig

Au revoir PHPTemplate, bonjour Twig! PHPTemplate nous aura bien rendu service mais il est maintenant temps pour lui de prendre sa retraite. Twig est un moteur de template moderne pour PHP qui peut être enrichi via un API. Il est facile d’utilisation, sécurisé et flexible.

Ressources :

• Site officiel (En)
• Les standards de développement pour Twig (En)
• Drupal 8 et Twig, les standards de développement (En)

YAML

Au lieu d’utiliser notre format de fichier maison, la décision a été prise pour D8 d’utiliser quelque chose de plus commun et standardisé. YAML est un standard pour la création de fichier de configuration.

Ressources :

• YAML, C’est quoi ? (Fr)
• YAML – wikipedia (En)

Le mot de la fin

J’ai essayé de ne pas donner trop de lien et de sélectionner les meilleurs pour chaque sujet parce que cela représente beaucoup d’informations. Néanmoins si vous voulez proposer un article pour complémenter ce post, ce sera avec plaisir. En regardant la longueur de ce post de pré-requis, on peut dire que Drupal 8 a changé et est différent des précédentes versions. Cela montre aussi la volonté de plus de qualité et de professionnalisme de la part de la communauté.

Je continuerai de mettre à jour cette liste et en attendant, j’espère que vous y trouverez votre bonheur.