Drupal est un CMS qui, aujourd'hui, fait briller les yeux de bien des DSI ou services com, mais c'est aussi un CMS qui fait briller de larmes de désespoir ceux d'un grand nombre de développeurs, de chefs de projet, d'AMOA qui ont eu des expériences de projets complexes avec Drupal.

Si comme dans le vie de tout projet, il y a des pièges que l'on ne peut éviter, avec Drupal, il y en a qui sont récurrents et identifiables.

Un CMS ne fait pas le café

Quel prestataire ne s'est pas vu imposer l'utilisation de Drupal pour un développement métier ? Drupal c'est un nom, rassurant, exploité par les plus grands, mais ce n'est pas une bonne solution pour tous les projets. Ce choix peut même parfois signer l'échec d'un projet avant même son démarrage. Ceci n'est pas lié à Drupal en soi, mais lié au fait que cela soit un CMS… et le cœur d'utilisation d'un CMS est la gestion de contenu. Toute autre utilisation vous mènera à triturer l'essence même de l'outil et aussi très probablement à faire des développements sur mesure tellement spécifiques que votre projet deviendra extrêmement complexe voir inmaintenable (ou à un coût considérable). Si vous souhaitez faire un développement métier, orientez-vous vers un framework tel que Symfony ou Django. Ce sont là aussi des valeurs sures, épaulées par une communauté très importante avec nombre de professionnels.

Votre projet mêle éditorial et métier ? Pas de problème : utilisez Drupal pour la partie éditoriale et Symfony pour la partie métier et faites la glue avec ESI.

Lorsque vous rédigez votre cahier des charges, portez une attention particulière aux technologies que vous imposez car l'impact sur la réussite du projet est considérable.

Le prestataire, ce héros

Vous allez après la rédaction du cahier des charges, choisir un prestataire. Ce choix doit être influencé par le type de projet que vous souhaitez mettre en place :

• une agence web sera à l'aise sur un site vitrine, événementiel, institutionnel
  
• une agence de développement sera adaptée pour des portails, des sites et des applications présentant des fonctionnalités complexes ou métier.

Une agence web aura davantage un profil intégrateur Drupal et fera usage des modules communautaires. Cela ne pose aucun problème tant que le besoin fonctionnel reste simple.

Si vous avez un besoin un peu plus complexe, il faut faire appel à une agence de développement, à des experts Drupal qui vous éviteront tous les pièges techniques et fonctionnels d'un projet complexe.

Trop de modules tuent le module

Les modules communautaires, c'est formidable mais à utiliser avec parcimonie. Plus vous utiliserez de modules dans un projet plus cela aura un impact sur les performances, la sécurité et la TMA (Tierce Maintenance Applicative).

Les performances

Certains modules sont un réel gain de temps sur de petits sites, mais sur des sites un peu plus importants ils deviennent handicapants pour les performances. Nous pouvons citer parmi les plus courants Views, Display Suite, Ctools, Context, ACL, Advanced Forum, OG, Panels, etc.

La sécurité

Plus vous utilisez de modules, plus le nombre de failles potentielles est important. Pour les modules les plus utilisés, le risque est assez faible. Par contre pour les modules plus "confidentiels", le risque est réel et proportionnel au nombre de modules.

La TMA

L'erreur serait de penser que si on utilise des modules communautaires, la TMA sera plus simple. Encore une fois, c'est probablement le cas pour les modules les plus utilisés, mais pas systématiquement non plus. En effet, le risque d'utiliser trop de modules est que des conflits apparaissent entre ces modules. Ces conflits peuvent générer des bugs parfois difficiles à identifier. Cela a un impact lors des développements mais aussi au cours de la TMA : à chaque mise à jour, un problème peut apparaître et si les mises à jour fonctionnelles ne paraissent pas toujours nécessaires, celles liées à la sécurité sont indispensables.

Tous ces beaux gabarits

L'un des postes les plus importants en terme de budget sur Drupal est bien souvent l'intégration graphique. Le temps d'intégration d'un gabarit est incompressible. La seule façon d'économiser sur ce point est de réaliser une charte graphique "intelligente". Nous constatons assez souvent que les chartes graphiques des projets sont hétérogènes et manquent de cohérence. Sur un projet qui devrait comporter 20 gabarits, il y en a parfois 40. Bien souvent, cela n'apporte rien et cela perd l'internaute qui n'a plus ses points de repère d'une page à l'autre. S'il y a un point qui peut vous permettre de maîtriser facilement le budget d'un projet, c'est la maîtrise du nombre de gabarits à intégrer.

Tous connectés !

Le mode connecté sur Drupal fait frémir bien des experts. L'impact en terme de performance est conséquent. Un projet avec une part importante de fonctionnalités en mode connecté doit être bien réfléchi dès le démarrage du projet. Autant l'utilisation de systèmes de cache permet de booster les performances en mode anonyme autant ce n'est pas le cas en mode connecté car bien souvent les informations et les fonctionnalités accessibles sont liées à l'utilisateur. Si le projet est mal pensé, au final il y a un espoir qu'il fonctionne malgré tout mais cela se fera sans miracle : la compensation sera au niveau de l'hébergement et les répercussions sur le budget seront importantes.

Le mot de la fin

Chez Makina Corpus, nous aimons Drupal, mais pas pour tous les projets. Avant de vous lancer, n'hésitez pas à faire intervenir un expert pour une étude. C'est un investissement qui vous permettra au final de :

• réussir le projet à venir ;
• économiser vos nerfs et votre énergie lors de la réalisation du projet ;
• avoir un développement pérenne.

Crédits :
  Super héros : Conçu par Freepik
  Sketch : Conçu par Freepik
  Drupman : Makina Corpus