Drupal
Drupal a une réputation qui le précède : lourd, exigeant, réservé aux grosses machines. La réputation a un fond. Drupal demande plus de cadrage qu'un CMS éditorial classique, et ouvrir l'outil sans projet précis derrière, c'est se condamner à passer trois mois à organiser ce qui aurait pu tenir sur un autre socle en trois semaines. La question utile n'est pas de savoir si Drupal est bon ou mauvais. C'est de savoir à quel moment un projet en a vraiment besoin, et ce moment existe.
Le seuil est celui de la structure. Un site qui empile des pages, des articles et quelques rubriques tient sur un CMS éditorial sans surcoût. Un site qui doit modéliser un domaine entier, avec des types d'objets différents qui se renvoient l'un à l'autre, des taxonomies imbriquées, des champs personnalisés par profil, change de catégorie. C'est là que Drupal commence à valoir ce qu'il coûte. On parle d'un annuaire d'établissements liés à des activités liées à des labels liés à des saisons, d'une base patrimoniale qui croise lieux, événements, personnages et œuvres, d'un portail de service public où chaque procédure a sa fiche, son service instructeur, ses pièces jointes types et ses statuts. Sur ce genre de contenu, organiser la donnée proprement dès le départ évite des années de bricolage.
Le terrain le plus naturel reste l'institutionnel. Collectivités, parcs, organismes publics, grandes structures à contenu dense où la publication se fait à plusieurs et où l'administration a besoin de tenir la cohérence d'un fonds qui grossit chaque année. Drupal y est solide pour des raisons concrètes : son moteur de droits permet de découper finement qui voit quoi et qui édite quoi, ses workflows de publication acceptent qu'un brouillon passe par un relecteur avant d'être validé par un responsable, et son back-office, austère mais propre, ne dérive pas quand vingt contributeurs s'y croisent. Ce sont des qualités qu'on ne remarque pas tant qu'on n'en a pas besoin, et qui deviennent décisives le jour où le site doit tenir à dix mains.
Notre cas le plus net sur ce terrain reste la plateforme de labellisation des socio-professionnels du Parc naturel régional du Vercors, en 2019. Le besoin tenait en une phrase : permettre à des hébergeurs, des prestataires d'activité et des artisans de candidater à un label du parc à travers un questionnaire en plusieurs étapes, propre à chaque profession, avec une administration capable de suivre les dossiers, de valider les établissements et de pousser les fiches retenues vers le système d'information touristique Apidae. Côté contenu, la matière était dense : plusieurs types d'objets, des questionnaires conditionnels qui ne se ressemblaient pas d'un métier à l'autre, des liens entre fiches, des statuts qui évoluent. Drupal 8 a permis de modéliser ce périmètre sans empiler les rustines, et ce que cette plateforme a montré, c'est exactement le terrain où Drupal gagne : du contenu structuré, un back-office qui distribue les rôles, et une logique métier qui dépasse la publication d'articles.
Le moteur de champs et de types de contenu est la pièce centrale, celle par laquelle tout passe. Là où d'autres CMS proposent un modèle d'article qu'on étire pour tout faire rentrer, Drupal part du principe inverse : on définit chaque type d'objet en fonction du métier, on lui donne ses champs propres, ses relations, ses gabarits d'affichage. Une fiche établissement n'est pas un article qu'on adapte ; c'est un type à part, avec ses adresses, ses horaires, ses équipements, ses photos référencées et ses liens vers des activités. La cohérence de la donnée se tient au niveau du modèle, pas du gabarit de page. C'est plus lent à poser au départ, et c'est exactement ce qui rend le site sain dix ans plus tard.
Les vues, l'autre grand mécanisme du cœur de Drupal, font le pendant. À partir des types de contenu déjà modélisés, on construit toutes les listes, les filtres, les blocs et les sous-pages dont le site a besoin sans repasser par du code à chaque fois. Un annuaire filtré par catégorie, une page qui croise plusieurs types d'objets, un bloc qui remonte les contenus les plus récents d'une rubrique : tout se configure au-dessus du modèle de données. La rédaction et l'administration gagnent une autonomie réelle sur l'évolution des écrans, sans dépendre d'un développeur pour chaque ajustement de tri ou de filtre. Cette puissance a un coût d'apprentissage côté admin, et on prend le temps de la formation pour que l'outil soit vraiment tenu après la livraison.
Les versions à jour de Drupal, 8, 9, 10 et la suite, ont rapproché l'outil de l'écosystème PHP moderne. Le socle s'appuie sur Symfony pour ses composants bas niveau, ce qui veut dire qu'un développement custom dans Drupal n'est pas un dialecte isolé : on retrouve les patterns d'injection de dépendances, les services, les events, les routes. Pour une équipe technique qui doit reprendre le code, l'entrée se fait sur des bases connues. Le revers, c'est que les montées de version majeures demandent un vrai chantier de migration ; on les anticipe au cadrage, et on les traite en travail dédié plutôt qu'en bricolage entre deux livraisons. C'est le prix d'un socle qui dure, et il se planifie.
Les modules officiels du cœur et de la communauté couvrent une part énorme des besoins courants sans aller chercher du code tiers fragile : workflows, traduction de contenu, médias, formats de texte, recherche, services web. Quand on installe un module, on regarde d'abord s'il appartient à ce noyau officiel ou s'il est maintenu par un acteur reconnu de la communauté. Le piège, comme sur tous les CMS extensibles, c'est l'empilement de modules tiers à demi maintenus qui finissent par bloquer une montée de version ou ouvrir une faille. On le dit clairement avant d'installer quoi que ce soit, et tout ce qui peut être codé proprement dans un module custom de projet l'est, parce que c'est la part du code qu'on contrôle réellement.
Le multilingue est un domaine où Drupal est très à l'aise depuis ses versions récentes, et c'est souvent ce qui décide du choix sur les projets institutionnels ou touristiques. Tout est traduisible nativement : les contenus bien sûr, mais aussi les libellés d'interface, les types de champs, les éléments de configuration, les chaînes de l'administration. On ne duplique pas un site par langue ; on travaille sur une base unique qui se décline. Pour une collectivité qui doit publier en français, en anglais et dans une langue régionale, ou pour un site touristique tourné vers plusieurs marchés étrangers, c'est un terrain où l'outil tient ses promesses sans contournement.
L'interconnexion avec un système d'information métier fait partie du paysage habituel. Drupal sait exposer ses contenus en API REST et JSON, consommer des flux externes, programmer des imports automatisés. Sur Vercors, c'est ce qui a permis aux fiches d'établissements validées par les administrateurs de remonter automatiquement dans Apidae, avec une simple étape de validation pour le côté humain. La même mécanique vaut pour brancher un annuaire interne, alimenter un autre site qui consomme la donnée, ou recevoir un flux d'un partenaire. Drupal est un bon citoyen d'un système d'information qui a déjà plusieurs briques, et c'est souvent ce qui lui ouvre la porte là où un CMS éditorial classique resterait à part.
Côté gouvernance et hébergement, Drupal s'inscrit dans des cadres exigeants. L'écosystème est utilisé largement par des administrations, des universités, des grandes entreprises, ce qui veut dire que l'outil a déjà été passé au crible sur les sujets de sécurité, d'accessibilité et de conformité. Les correctifs de sécurité du cœur sont publiés à un rythme tenu, l'équipe de sécurité de la communauté est sérieuse, et on s'en sert. On respecte les standards d'accessibilité du cœur, on tient les versions à jour, on suit les avis de sécurité et on tient un journal de ce qui est appliqué. Sur les projets publics, ce sérieux n'est pas un bonus, c'est une condition.
Maintenant, la franchise inverse : on ne sort pas Drupal pour faire ce qu'un autre outil fait mieux. Une vitrine de quelques pages, un site éditorial simple où la rédaction veut publier vite sans modéliser de domaine, un blog : Drupal y serait surdimensionné, et on oriente vers WordPress. Un site marchand au catalogue lourd avec des règles de prix complexes : on parle plutôt de PrestaShop ou Shopify selon le contexte. Une application métier dense avec des règles de gestion qui s'empilent : on construit ça en Symfony. Drupal a son terrain ; il n'est pas là pour le reprendre à la place des autres. C'est aussi pour ça qu'on le sort moins souvent que ces stacks, et qu'on le fait sans hésiter quand c'est le bon outil pour le contexte qu'on a en face.
Reste la question de l'IA, qui finit par se poser sur tout projet. Sur un fonds documentaire dense, et c'est typiquement le terrain où Drupal vit, l'IA a de quoi servir : recherche augmentée qui comprend la question d'un visiteur plutôt que de matcher des mots-clés, assistance à la rédaction pour suggérer des descriptions ou homogénéiser un fonds patrimonial, classement automatique d'archives en taxonomies déjà modélisées. Ces fonctions se posent en couche par-dessus le socle, après que la modélisation du contenu tient. Elles ne justifient pas à elles seules de partir sur Drupal, et elles n'ouvrent jamais la porte à l'outil par effet de plaquette. Quand le contenu structuré appelle Drupal et que l'IA apporte un gain réel par-dessus, les deux se rejoignent proprement. Sinon, on l'écarte.
Au fond, le choix de Drupal se ramène à une question qu'on pose au cadrage. Le contenu est-il un fonds structuré, à plusieurs types d'objets reliés, édité à plusieurs mains avec des rôles et des validations, prévu pour durer dix ans et grossir ? Si oui, Drupal est dans ses qualités natives et on s'en sert sans détour. Sinon, on prend un outil plus léger, et on assume de dire que Drupal n'est pas le bon. La compétence n'est pas de défendre une stack, c'est de placer la bonne au bon endroit. Quand c'est Drupal, on le fait sérieusement, avec la modélisation, les rôles, les workflows et la maintenance qu'il mérite.