Hébergement Drupal : Ce Que Drupal Exige Vraiment

L’hébergement Drupal est à l’origine de la plus grande partie de la réputation de lenteur de Drupal, et c’est presque toujours une décision d’achat plutôt qu’un problème logiciel. Un site est construit correctement, puis mis en ligne sur une offre calibrée pour un site vitrine composé d’une poignée de fichiers PHP. Le résultat est un système de gestion de contenu doté d’un vrai pipeline de rendu, tournant dans une limite mémoire qu’il ne peut pas changer, sur un cache d’opcode qu’il ne contrôle pas, sans shell pour exécuter son propre outillage.

La comparaison que tout le monde fait mentalement est celle avec WordPress, et c’est la mauvaise. WordPress tourne convenablement sur presque n’importe quoi parce que sa part de marché a forcé les hébergeurs à le faire tourner convenablement sur presque n’importe quoi. Drupal suppose un PHP récent, une base de données récente, un vrai backend de cache, une ligne de commande et un processus de déploiement qui traite la base de code comme un artefact de build plutôt que comme un dossier que l’on modifie.

De quoi Drupal a-t-il réellement besoin de la part d’un hébergeur ? Une version de PHP au niveau du seuil de votre version ou au-dessus, un MySQL, MariaDB ou PostgreSQL récent, 256 Mo de mémoire PHP en pratique, OPcache, un accès shell pour Composer et Drush, une vraie entrée cron, et un cache objet externe dès que vous avez des utilisateurs connectés. L’hébergement mutualisé bon marché échoue sur trois ou quatre de ces points à la fois.

Ce que Drupal exige réellement d’un serveur

Les prérequis publiés sont courts, précis et publics, et presque personne ne les lit avant d’acheter. Ils dépendent aussi de la version, ce qui compte particulièrement en ce moment, car deux de ces seuils bougent en décembre 2026.

Le seuil de version PHP n’est pas négociable

Drupal 11 exige PHP 8.3 au minimum et prend en charge 8.3, 8.4 et 8.5. Drupal 10 exige 8.1 et va jusqu’à 8.4, et Drupal 12 relève encore le seuil à PHP 8.5. Ces chiffres proviennent de la documentation Drupal sur les prérequis PHP, la seule version de cette liste qui mérite confiance.

Cela pèse plus lourd qu’il n’y paraît, car les branches PHP elles-mêmes expirent. La page des versions prises en charge sur php.net fixe la fin du support de sécurité de PHP 8.2 au 31 décembre 2026, celle de 8.3 au 31 décembre 2027 et celle de 8.4 au 31 décembre 2028. PHP 8.1 est déjà au-delà. Un hébergeur qui annonce « PHP 8.1 et 8.2 disponibles » propose une pile qui n’est déjà plus corrigée, ou qui ne le sera plus d’ici quelques mois.

Les deux échéances se télescopent. Drupal 10 arrive en fin de vie le 9 décembre 2026 et Drupal 12 sort la même semaine, d’après le calendrier des versions du cœur. Si votre hébergeur ne peut pas servir PHP 8.3 ou plus récent, vous ne pourrez plus faire tourner un Drupal pris en charge après cette date. Notre guide sur les coûts, options et échéances de la migration Drupal explique ce que cela implique si vous êtes encore en 10.

Les moteurs de base de données et leurs vrais minimums

Drupal 11 veut MariaDB 10.6 ou plus récent, MySQL 8.0 ou plus récent, PostgreSQL 16 ou plus récent, ou SQLite 3.45 ou plus récent, selon les prérequis du serveur de base de données. Drupal 10 est plus tolérant avec MariaDB 10.3.7, MySQL 5.7.8, PostgreSQL 12 et SQLite 3.26, ce qui explique pourquoi une montée de version impose parfois une mise à niveau de base de données que le client n’avait pas prévue.

Deux détails passent à la trappe. InnoDB doit être le moteur de stockage sur MySQL et MariaDB, parce que Drupal s’appuie sur les transactions et le verrouillage au niveau des lignes. Sur PostgreSQL, l’extension pg_trgm doit être créée sur la base Drupal avant l’installation, et un service de base de données managé qui n’autorise pas CREATE EXTENSION est inutilisable.

SQLite est réellement pris en charge et convient au développement local, mais ce n’est pas une réponse en production dès que plusieurs rédacteurs enregistrent du contenu, car la concurrence en écriture devient le plafond avant tout le reste.

Mémoire, extensions et serveur web

Le minimum documenté par Drupal est de 64 Mo de mémoire PHP, et il affiche des avertissements en dessous. La même page note que 128 Mo ou 256 Mo sont courants en production et que les installations riches en médias en demandent davantage. En pratique, retenez 256 Mo comme valeur de travail et prévoyez de l’augmenter pour la ligne de commande, car ce sont Composer et les grosses migrations qui consomment la mémoire, pas le service des pages.

La liste des extensions n’a rien de remarquable et mérite quand même une vérification : PDO avec un pilote de base de données, XML, JSON, mbstring, cURL, OpenSSL pour le HTTPS sortant, et GD ou ImageMagick pour les dérivés d’images. Drupal 12 ajoute Argon2 pour le hachage des mots de passe, une chose de plus qu’une très vieille compilation de PHP n’aura pas.

Côté serveur web, Drupal prend en charge Apache 2.4.7 ou plus récent et Nginx 1.1 ou plus récent, et ne prend plus en charge Microsoft IIS depuis Drupal 11.0.0. Apache a besoin de mod_rewrite pour les URL propres et de AllowOverride All pour que le .htaccess livré s’applique. Ce dernier point piège beaucoup de monde : certaines règles de protection de Drupal n’existent que dans le .htaccess, donc un déploiement Nginx doit les reproduire à la main dans la configuration du serveur. C’est une étape de routine qui est routinièrement oubliée, et l’une des premières choses que nous cherchons dans un audit de sécurité serveur.

Pourquoi l’hébergement mutualisé échoue avec Drupal

L’hébergement mutualisé n’est pas du mauvais hébergement. C’est un hébergement optimisé pour une autre forme d’application, et Drupal se heurte à ses contraintes en quatre endroits prévisibles.

Sans shell, ni Composer ni Drush

Le Drupal moderne est un projet Composer. Le cœur, les modules contribués et leurs dépendances PHP sont tous résolus par Composer, et dès que Composer gère un module, il doit aussi gérer le cœur. Mélanger Composer et des mises à jour manuelles de fichiers, c’est le chemin vers un site qui ne peut plus être mis à jour du tout.

Un panneau de contrôle avec gestionnaire de fichiers ne sait pas faire cela. Un client FTP non plus. Sans SSH, vous perdez aussi Drush, qui est l’outil par lequel se font réellement les reconstructions de cache, les imports de configuration, les mises à jour de base et les réinitialisations de mots de passe. Un site sur lequel vous ne pouvez pas lancer drush cr est un site où chaque étape de récupération devient un ticket de support.

Les limites que vous ne voyez pas, et encore moins ne changez

Un compte mutualisé vous donne un memory_limit fixé par quelqu’un d’autre, souvent 128 Mo et parfois moins, sans aucun moyen de le relever pour la seule migration qui a besoin de 512 Mo.

OPcache est le problème le plus sérieux. Il stocke en mémoire partagée le bytecode précompilé des scripts pour que PHP ne réanalyse pas les fichiers à chaque requête, et sur un hébergement mutualisé ce pool de mémoire est partagé entre des centaines de comptes. Drupal compte des milliers de fichiers PHP, c’est donc un locataire encombrant d’un pool pour lequel il est en concurrence, et il finit par s’y faire évincer. Le symptôme est un site rapide pendant une minute après une visite, et lent à nouveau une heure plus tard.

Vient ensuite ce qui manque totalement : pas de Redis, pas de Memcached, aucun contrôle sur le gestionnaire de processus PHP, et aucun moyen de faire tourner un worker de file d’attente au long cours.

Un cron qui ne tourne jamais vraiment

Le module Automated Cron de Drupal s’exécute toutes les trois heures par défaut et est déclenché par les visiteurs du site. Sur un site fréquenté, cela veut dire qu’un visiteur paie de temps en temps l’indexation de la recherche avec son temps de chargement. Sur un site calme, cela veut dire que le cron ne tourne pratiquement jamais, donc l’index de recherche se périme, les tables de logs ne sont jamais purgées et les mises à jour de sécurité disponibles ne sont jamais vérifiées.

La documentation recommande plutôt de déclencher le cron depuis l’extérieur, parce qu’il tourne alors toujours à l’heure et consomme moins de ressources. Cela demande une vraie entrée crontab, que l’offre la moins chère ne fournit pas.

Les couches de cache et celle que votre visiteur touche

Drupal met en cache bien plus que la plupart des gens ne l’imaginent, et ces couches ne sont pas des alternatives. Elles s’empilent, et chacune rattrape ce que la couche au-dessus n’a pas pu faire.

OPcache se situe entièrement sous Drupal

OPcache n’est pas une fonctionnalité de Drupal. Il met en cache le bytecode PHP compilé au niveau de l’interpréteur, il s’applique donc à chaque requête, qu’un cache Drupal soit touché ou non. Ratez cela et rien au-dessus ne pourra compenser, car chaque requête paie la recompilation du framework avant même d’atteindre le routeur. Dimensionnez généreusement la mémoire partagée et désactivez la validation des horodatages en production, où l’ensemble des fichiers ne change qu’au déploiement.

Internal Page Cache et Dynamic Page Cache

Internal Page Cache est un module du cœur, activé par défaut, et il ne sert que les utilisateurs anonymes. Il part du principe que tout visiteur anonyme voit la même page, stocke la réponse entière à la première requête et la réutilise. Pour un site vitrine sans personnalisation, c’est cette couche qui fait presque tout le travail.

Dynamic Page Cache fait aussi partie du cœur et est aussi activé par défaut, et il met en cache pour tout le monde, y compris les utilisateurs authentifiés. Il fonctionne en laissant le système de rendu transformer en marqueurs les parties réellement personnelles d’une page, et en mettant en cache tout ce qui les entoure. C’est pourquoi une page Drupal vue en étant connecté peut rester majoritairement en cache : seuls le menu utilisateur et quelques blocs sont vraiment dynamiques.

BigPipe et le cache de rendu

Sous les deux se trouve le cache de rendu, qui met en cache les blocs, les champs, les résultats de vues et les rendus d’entités pris un à un. Une page qui rate le cache de page est le plus souvent assemblée en grande partie à partir de succès du cache de rendu, plutôt que reconstruite depuis la base de données.

BigPipe s’occupe du reste. Il est dans le cœur depuis Drupal 8.1, stable depuis 8.3 et présent dans le profil d’installation standard depuis 8.5. Au lieu d’attendre que chaque marqueur soit résolu, il envoie immédiatement la page cacheable et diffuse ensuite les fragments personnalisés. Il ne demande aucune configuration, et il aide bien davantage les utilisateurs connectés que les anonymes.

Sur un site bien configuré, le visiteur anonyme touche donc l’Internal Page Cache, ou le CDN placé devant, et ne rencontre jamais l’essentiel de tout cela. Le rédacteur connecté touche à chaque requête le Dynamic Page Cache, le cache de rendu et BigPipe, et c’est pour cela que le trafic authentifié coûte tellement plus cher.

Le cache objet externe

Chaque couche ci-dessus a besoin d’un endroit où ranger ses entrées. Par défaut, c’est la base de données, dans des tables de cache, ce qui signifie que vos lectures de cache entrent en concurrence avec vos requêtes de contenu sur le même serveur.

Le module Redis déplace les backends de cache, de verrous, de flood et de files d’attente vers Redis ou un stockage compatible comme Valkey, via l’extension PhpRedis, l’extension Relay ou la bibliothèque Predis en PHP pur. Memcached est l’équivalent alternatif. Pour un petit site anonyme, cela change peu de chose. Pour un site avec des utilisateurs connectés, c’est en général la plus grosse amélioration disponible, parce que cela retire de la base la charge d’écriture la plus bruyante et rend le verrouillage bon marché.

Reverse proxy et CDN devant Drupal

Un reverse proxy comme Varnish ou Nginx, ou un CDN, répond aux requêtes avant même que PHP n’intervienne. Pour le trafic anonyme, c’est la différence entre servir une page en quelques millisecondes et la servir en quelques centaines. C’est aussi la couche qui fait le plus peur, parce qu’un cache périmé sur un site d’actualité ou une boutique est une panne visible.

Les cache tags sont ce qui rend un CDN sûr

La réponse de Drupal, ce sont les cache tags. Les cache tags décrivent des dépendances de données, écrites sous forme de chaînes comme node:5, user:3 ou node_list. Chaque élément mis en cache enregistre les tags dont il dépend, si bien que modifier le nœud 5 invalide tous les fragments, pages et vues en cache qui le référençaient, où qu’il apparaisse.

Le point important, c’est que Drupal peut publier ces tags vers l’extérieur. Des modules contribués les émettent dans un en-tête Surrogate-Key pour Fastly ou Cache-Tag pour Cloudflare, et le CDN purge alors par tag quand Drupal le lui dit. Cela transforme un CDN, d’un pari fondé sur le temps, en un cache piloté par les événements : vous pouvez fixer une longue durée de vie, parce qu’une modification purge exactement les URL concernées en quelques secondes.

Surveillez le budget d’en-tête. La documentation Cloudflare sur la purge par cache tag plafonne l’en-tête Cache-Tag agrégé à 16 Ko après le nom du champ, soit environ 1 000 tags uniques, avec un maximum de 1 024 caractères par tag dans un appel d’API et 100 tags par purge depuis le tableau de bord. Une vue Drupal qui liste beaucoup d’entités peut générer bien plus de tags que cela, si bien qu’une page qui liste tout fera silencieusement déborder l’en-tête, à moins que le module ne soit configuré pour les tronquer ou les hacher.

Choisir un hébergement Drupal : quatre niveaux, honnêtement

Il existe quatre options réelles, et la bonne se décide selon que vous avez du trafic authentifié et selon que vous avez quelqu’un pour exploiter le serveur. Les fourchettes ci-dessous correspondent à ce que paient habituellement nos clients britanniques, hors TVA, et elles sont indicatives plutôt que reprises d’un fournisseur.

Hébergement mutualisé

Ne convient à personne qui exploite Drupal en production. Il échoue en même temps sur l’accès shell, la mémoire, le cache d’opcode, le cache objet et le cron. Si le budget s’arrête vraiment là, une petite instance non managée à un prix comparable est un meilleur usage de l’argent.

VPS ou instance cloud non managée

Environ GBP 20 à GBP 120 par mois achètent une machine avec un accès root complet, ce qui convient à la grande majorité des sites Drupal. Vous choisissez la version de PHP, dimensionnez OPcache, installez Redis, posez une crontab et configurez Nginx correctement. Ce que vous n’obtenez pas, c’est quelqu’un pour le faire, le corriger, le surveiller ou le restaurer à deux heures du matin. Ce niveau est le bon quand vous avez un développeur ou une agence sous contrat, et le contrat est le vrai coût, pas l’instance.

Plateformes spécialisées Drupal managées

L’hébergement Drupal managé démarre autour de GBP 40 par mois pour un petit site et grimpe vite avec le trafic, les environnements et le niveau de support. Ce que vous achetez, c’est une pile imposée qui est déjà correcte, plus un déploiement basé sur Git, des environnements de préproduction, des sauvegardes et quelqu’un qui comprend Drupal au bout du fil. C’est un bon rapport quand l’alternative est personne, et un mauvais quand vous payez un prix de plateforme pour un site vitrine qui reçoit 4 000 visites par mois.

Infrastructure entièrement sur mesure

Base de données séparée, nœuds de cache dédiés, serveurs applicatifs derrière un répartiteur de charge, stockage objet pour les fichiers. Cela commence à avoir du sens au-dessus d’environ GBP 400 par mois, et seulement quand le trafic authentifié, les intégrations ou des exigences de conformité rendent les niveaux managés inconfortables. C’est le niveau le plus capable et le plus exigeant, parce que vous devenez propriétaire des correctifs, de la supervision et de la reprise après sinistre. Notre guide du développement web Drupal explique d’où vient cette complexité côté application.

Déploiement : on ne modifie pas les fichiers sur le serveur

Parce que Composer résout l’arbre de dépendances complet, la base de code du serveur est une sortie, pas un espace de travail. Modifier sur place le fichier d’un module signifie que le prochain composer update l’écrasera, et cela signifie que votre code de production ne correspond plus à rien de ce qui se trouve dans Git.

Un processus de livraison sain construit l’artefact ailleurs. Lancez composer install à partir du composer.lock versionné dans votre CI, pour que le build soit reproductible et que l’hôte de production n’ait jamais besoin de Composer, de mémoire PHP pour la résolution des dépendances, ni d’un accès en écriture à vendor. Livrez le résultat, exécutez les mises à jour de base, importez la configuration, reconstruisez les caches. Le retour arrière consiste à pointer vers l’artefact précédent.

Cela règle aussi tranquillement la question de l’hébergement. Un hébergeur qui attend de vous que vous modifiiez des fichiers en FTP est incompatible avec la façon dont Drupal se maintient, quoi qu’en dise sa fiche technique.

Où s’insère la synchronisation de configuration

Drupal conserve la configuration active en base et l’exporte dans des fichiers YAML, et c’est ainsi que les types de contenu, les champs, les vues et les réglages circulent entre environnements. La documentation sur la gestion de la configuration explique que l’UUID du site doit correspondre entre la source et la destination, ce qui est la raison habituelle de l’échec d’un premier import.

Concrètement, cela veut dire que la configuration est du code. Elle est versionnée, relue et déployée avec le reste, et l’étape d’import fait partie de la livraison au lieu d’être cliquée après coup dans l’interface d’administration. L’hébergement doit le permettre : il vous faut un endroit où lancer l’import, et un environnement où un import échoué peut être annulé plutôt qu’appliqué à moitié en production.

Fichiers, médias et sauvegardes

Drupal a deux systèmes de fichiers et la différence porte du poids. Le public se trouve sous la racine web et est servi directement par le serveur web. Le privé se trouve en dehors de la racine web, et chaque requête vers un fichier privé traverse Drupal pour que les droits soient vérifiés.

Les fichiers privés coûtent donc bien plus cher que les publics, parce que chaque téléchargement démarre PHP, et un site qui sert de gros documents privés a besoin d’une marge dont un serveur de fichiers statiques n’aurait pas besoin.

Déporter les médias vers du stockage objet

Dès que les fichiers vivent sur le serveur applicatif, la mise à l’échelle horizontale et les reconstructions deviennent pénibles, et chaque sauvegarde emporte toute la médiathèque. Déplacer le système de fichiers public vers un stockage objet compatible S3 sépare les deux, laisse le CDN servir les médias directement et rend un serveur applicatif réellement jetable.

Un test de restauration prouve ce qu’une sauvegarde ne peut pas prouver

Une sauvegarde prouve qu’un fichier existe. Un test de restauration prouve que le fichier est complet, que la base et les fichiers proviennent du même instant, que vos identifiants fonctionnent encore, et que vous savez combien de temps cela prend. Ce sont quatre modes de défaillance distincts et aucun n’est visible depuis une coche verte dans un panneau de contrôle.

Testez-le chronomètre en main au moins deux fois par an et notez le chiffre. Si la restauration prend six heures et que votre tolérance est d’une heure, c’est l’architecture qui pose problème, pas la sauvegarde. Le temps de reprise est une exigence d’hébergement, et il a sa place dans le cahier des charges plutôt que dans un incident.

Dimensionner correctement un hébergement Drupal

Les pages vues sont la mauvaise unité. Un site avec 200 000 pages vues anonymes par mois derrière un CDN peut être à l’aise sur une petite instance, tandis qu’un site avec 8 000 pages vues peut souffrir si la plupart d’entre elles sont vues par des utilisateurs connectés.

Le trafic authentifié est le vrai facteur

Les requêtes anonymes peuvent être servies par le cache de page ou le CDN sans toucher à PHP. Les requêtes authentifiées, non. Chacune d’elles parcourt le pipeline de rendu, vérifie les droits sur chaque entité, résout les marqueurs et écrit des données de session. La question pratique n’est pas combien de visites vous recevez, c’est combien d’utilisateurs connectés simultanés vous avez, et ce que ces utilisateurs ont le droit de voir.

Les rédacteurs sont le cas extrême. Les écrans d’administration de contenu comptent parmi les pages les plus lourdes de Drupal, et ils sont non cacheables par définition, donc un site où douze rédacteurs travaillent en même temps a une vraie exigence de concurrence que son trafic public ne laisse jamais deviner.

Vues, taxonomie et travail de file d’attente

Au-delà du trafic authentifié, les postes de coût fiables sont les grandes vues avec beaucoup de filtres et de relations, qui produisent des jointures coûteuses, les arbres de taxonomie profonds, dont les hiérarchies de termes sont parcourues à chaque rendu, et le travail de cron ou de file d’attente comme l’indexation de la recherche, les imports de flux et la génération de dérivés de médias.

Les workers de file d’attente ne devraient pas partager les ressources du serveur web avec les visiteurs si vous pouvez l’éviter. Sur un site important, ils appartiennent à un processus ou à une instance séparés, pour qu’un retard d’import ne puisse pas ralentir le front. C’est une décision d’architecture prise au moment de l’achat, et c’est le point où les niveaux managés cessent de convenir et où l’infrastructure sur mesure commence à convenir.

Prendre la bonne décision

Le schéma est constant. L’hébergement n’est pas sous-dimensionné, il a la mauvaise forme : pas de shell, pas de cache objet, un cache d’opcode contrôlé par quelqu’un d’autre, et une version de PHP sur le point de sortir du support. Déplacer le même site vers une instance correctement spécifiée, à un prix comparable, l’emporte en général sur n’importe quelle optimisation front-end.

Mecanik spécifie, construit et maintient des infrastructures Drupal dans le cadre de notre travail de développement de sites web, et examine les piles existantes via un audit de sécurité serveur quand la préoccupation est l’exposition plutôt que la vitesse. Si ce sont des personnes plutôt qu’une plateforme qu’il vous faut, notre guide pour recruter un développeur Drupal explique quoi regarder.

Questions fréquentes

Quelles sont les exigences serveur minimales pour Drupal 11 ? PHP 8.3 ou plus récent, et MariaDB 10.6, MySQL 8.0, PostgreSQL 16 ou SQLite 3.45 comme base de données. Côté serveur web, Apache 2.4.7 ou Nginx 1.1 et plus récents, Microsoft IIS n’étant plus pris en charge à partir de Drupal 11.0.0. Drupal avertit en dessous de 64 Mo de mémoire PHP, mais 256 Mo est le chiffre réaliste en production.

Drupal peut-il tourner sur un hébergement mutualisé ? Il s’installera et servira des pages, mais l’hébergement mutualisé échoue en général sur trois ou quatre exigences à la fois : pas d’accès shell pour Composer ou Drush, une limite de mémoire PHP que vous ne pouvez pas relever, pas de Redis ni de Memcached, et un cron qui ne se déclenche que lorsqu’un visiteur charge une page. Ce sont ces conditions qui produisent la réputation de lenteur de Drupal.

Combien devrait coûter un hébergement Drupal ? Un petit site Drupal sur une instance non managée correctement configurée se situe généralement entre GBP 20 et GBP 120 par mois avant que quiconque l’exploite. Les plateformes Drupal managées commencent couramment près de GBP 40 et montent dans les centaines avec le trafic et les environnements. L’infrastructure sur mesure commence à se justifier au-dessus d’environ GBP 400. Le niveau le moins cher est rarement le résultat le moins cher.

Drupal a-t-il besoin de Redis ? Pas pour un petit site anonyme, où le cache de page interne et la base de données suffisent. Dès que vous avez des utilisateurs connectés, des rédacteurs ou un espace membres, un cache objet externe comme Redis ou Memcached retire de la base les lectures de cache, les verrous et les files d’attente, et c’est en général la plus grosse amélioration disponible pour le prix.

Un CDN est-il sûr devant un site Drupal dynamique ? Oui, à condition d’invalider par cache tag plutôt que par durée. Drupal enregistre des tags comme node:5 pour tout ce dont une réponse dépend, et des modules les traduisent en en-têtes Cache-Tag ou Surrogate-Key pour que le CDN purge exactement les pages qu’une modification a touchées. Sans invalidation par tag, vous choisissez entre des pages périmées et un cache qui n’aide jamais.