26/08/2026
Après 10 ans avec Drupal, voici 7 choses que je ne ferai plus sur un projet Drupal 11.
Avec le recul, certaines pratiques que j'ai longtemps utilisées, je les évite désormais comme la peste. Pas par dogme, mais parce que j'ai appris à mes dépens que ça coûte cher plus t**d.
Voici mon petit aide-mémoire pour un projet sain, durable et performant :
1. Multiplier les modules contrib sans raison
Un module = une couche de config en plus, chargée à chaque requête. Avant d'en ajouter un, je vérifie si le cœur peut faire l'affaire. Si c'est un besoin ponctuel, je pèse le pour et le contre : module contrib ou module custom ? Tout est une question de temps, de budget et de vision client.
2. Modifier un module contrib à la main
Oui, c'est rapide. Mais c'est aussi une bombe à ret**dement au prochain update. Si je dois adapter un comportement, je privilégie une surcharge, un plugin, un event ou un service. Jamais je ne touche au code source du module.
3. Utiliser les hook_ par défaut
Pratiques, certes, mais pas toujours les plus performants. Aujourd'hui, je regarde du côté des services, plugins ou events. C'est plus propre et souvent plus rapide à l'exécution.
4. Penser aux performances à la fin
Sur un petit site, le cache cœur peut suffire. Mais sur un projet un peu plus costaud, j'intègre dès le départ Redis, APCu, et je découpe mes CSS par contexte (blog, service, etc.). Ça change tout sur la durée.
5. Utiliser Composer juste pour installer Drupal
Non, Composer, c'est bien plus que ça. Gestion des dépendances, reproductibilité, verrouillage des versions… Le composer.lock est mon meilleur allié pour garder un projet stable.
6. Attendre la production pour automatiser
Déploiement manuel, commandes en ligne, config à la main… Ça passe jusqu'au jour où ça casse. Maintenant, j'intègre CI/CD, scripts et environnements reproductibles dès le début. Même sur des projets modestes.
7. Voir une migration comme un simple transfert de données
Migrer, ce n'est pas juste copier des contenus. C'est repenser l'architecture, les modules, les médias, les permissions, les workflows… Et surtout, c'est l'occasion de corriger ce qui coinçait avant.
Au final, mon rapport à Drupal a changé.
Je ne cherche plus à faire fonctionner une fonctionnalité.
Je cherche à construire un système qui puisse évoluer, être maintenu, sécurisé et performant dans le temps.
10 ans plus t**d, c'est peut-être la plus belle leçon que Drupal m'a donnée.
Et aujourd'hui, avec Drupal, je vais encore plus loin.
Parce que non, Drupal n'est pas qu'un "CMS pour sites vitrines".
C'est une véritable plateforme pour construire des applications web complexes, des applications métier, des architectures sur mesure.
Et franchement, là où Symfony ou Laravel demandent des mois de développement, Drupal m'a permis d'aller bien plus vite.
Ajoutez à ça l'IA qui booste le quotidien (génération de code, analyse de besoins, aide à la structuration), et le temps de développement se réduit encore davantage.
Résultat : on gagne en agilité, en fiabilité, et on peut se concentrer sur ce qui compte vraiment : la valeur ajoutée pour le métier.
Alors oui, j'aime toujours autant Drupal.
Mais aujourd'hui, je l'aime pour ce qu'il devient : un allié de poids pour construire des systèmes solides, rapidement, et avec plaisir.
