Drupal ou stack statique : comment choisir selon la taille du projet

Un collectif Drupal qui publie un article expliquant quand il ne faut pas utiliser Drupal, cela peut surprendre. C'est pourtant le conseil que nous donnons régulièrement en cadrage de projet : une partie des demandes qui nous arrivent n'ont pas besoin de Drupal, et le dire tôt évite à tout le monde une erreur coûteuse. Cet article pose la grille de décision que nous utilisons réellement.

Le faux débat CMS contre statique

Le débat "CMS contre générateur de site statique" est mal posé. Il oppose deux outils comme s'ils visaient le même problème, alors qu'ils répondent à des besoins différents. Un CMS comme Drupal est un système de gestion de contenu : son cœur de métier est la gouvernance éditoriale, les rôles, les workflows, la structure de données. Un générateur statique (Eleventy, Astro, Hugo) est un outil de publication : il transforme des fichiers en pages HTML servies telles quelles, sans base de données ni couche applicative.

La bonne question n'est donc pas "quelle technologie est la meilleure", mais "quelle est la taille réelle du problème éditorial à résoudre". C'est la taille du projet, au sens de sa complexité de contenu et d'organisation, qui doit décider. Pas la mode, pas l'habitude du prestataire.

Ce que Drupal apporte réellement, et ce qu'il coûte

Drupal est conçu pour les situations où le contenu est un système à gouverner, pas une collection de pages à afficher.

Ce qu'il apporte. Une modélisation de contenu fine (types, champs, taxonomies, relations), des rôles et permissions granulaires, des workflows éditoriaux (brouillon, révision, validation, publication planifiée), un multilingue natif qui tient à grande échelle, des modules d'intégration éprouvés (CRM, ERP, SSO, API métier), une gestion de la volumétrie (des dizaines de milliers de contenus interrogeables et filtrables) et un socle sérieux pour les obligations d'accessibilité RGAA ou EN 301 549. Pour les architectures multi-sites, une usine à sites partageant socle et gouvernance est difficile à répliquer autrement.

Ce qu'il coûte. Une infrastructure applicative complète : PHP, base de données, serveur à surveiller. Des mises à jour de sécurité à appliquer sans exception, donc une maintenance mensuelle qui est un engagement récurrent, pas une option. Une expertise réelle pour les évolutions : Drupal mal maîtrisé se dégrade vite. Un coût d'entrée plus élevé, en argent et en délai, que la valeur ne justifie qu'à partir d'un certain seuil de complexité.

Ce qu'une stack statique apporte, et ce qu'elle interdit

Ce qu'elle apporte. Des performances excellentes par construction : servir un fichier HTML sera toujours plus rapide que générer une page dynamique. Une surface d'attaque quasi nulle : pas de base de données à compromettre, pas de CMS à mettre à jour en urgence. Un coût d'hébergement dérisoire et une maintenance réduite à presque rien. Pour un site vitrine de quelques dizaines de pages avec un seul éditeur, c'est un rapport valeur-coût imbattable.

Ce qu'elle interdit. Dès que plusieurs personnes doivent publier sans passer par un développeur, le modèle craque. Pas de workflow de validation, pas de permissions par section, pas de recherche native sur un grand volume, pas de contenu personnalisé ou soumis à connexion. Le multilingue reste possible mais tout est à assembler à la main, et chaque besoin dynamique (formulaires avancés, espace membre, commerce) devient un service externe à intégrer et à payer. Une stack statique qui accumule ces rustines finit par coûter plus cher qu'un CMS bien choisi, en pire.

Une grille de décision concrète

Cinq critères suffisent à trancher la grande majorité des cas.

Volumétrie de contenu. En dessous d'une centaine de pages, le statique tient sans effort. Au-delà de quelques centaines de contenus structurés, interrogeables, filtrables, un CMS devient nécessaire.

Nombre d'éditeurs. Un seul éditeur, à l'aise avec un processus simple : statique. Plusieurs contributeurs réguliers, avec des droits différents selon les sections : Drupal.

Complexité des workflows. Publication directe sans validation : statique. Chaîne de relecture, validation juridique ou hiérarchique, publication planifiée, archivage réglementé : Drupal.

Intégrations. Un formulaire de contact et un outil d'analyse d'audience : statique. CRM, SSO, annuaire interne, API métier, données synchronisées : Drupal.

Budget de maintenance. Aucun budget récurrent possible : le statique est le seul choix honnête, car un CMS sans maintenance devient une dette de sécurité. Un budget récurrent existe et le besoin le justifie : Drupal rend ce budget productif.

Si vos réponses se répartissent entre les deux colonnes, c'est la trajectoire à trois ans qui départage : un site simple appelé à devenir une plateforme justifie Drupal d'entrée de jeu, un site qui restera simple ne le justifiera jamais.

Deux exemples pour se situer

Un projet qui appelle Drupal. Une institution publique : plusieurs milliers de contenus, quatre langues, une dizaine de contributeurs répartis par direction, une chaîne de validation avant publication, un annuaire connecté au système interne et une obligation légale d'accessibilité. Chaque critère de la grille pointe vers un CMS, et c'est le profil type des projets de nos réalisations. Utiliser du statique ici reviendrait à recoder un CMS, en moins bien.

Un projet qui ne l'appelle pas. Une PME de services : un site vitrine de trente pages, un blogue, un formulaire de contact, une personne qui publie occasionnellement, aucune intégration. Installer Drupal ici, c'est imposer des années de maintenance pour des capacités qui ne serviront jamais. Une stack statique moderne livre un site plus rapide, plus sûr et moins cher à faire vivre. C'est un besoin si distinct que nous le servons sous une marque dédiée : au Québec, notre offre statique pour les PME est opérée par Altitude Numérique, précisément parce que ce type de projet mérite un outil pensé pour lui plutôt qu'un Drupal réduit.

En résumé

Drupal n'est ni la réponse universelle ni un dinosaure dépassé : c'est un outil de gouvernance de contenu, rentable à partir d'un certain seuil de complexité et surdimensionné en dessous. La grille est simple : volumétrie, nombre d'éditeurs, workflows, intégrations, budget de maintenance. Si votre projet coche les critères de la colonne Drupal et que vous cherchez des profils seniors pour le mener, parlons-en. Et s'il ne les coche pas, le meilleur service qu'un expert Drupal puisse vous rendre est de vous le dire.