"Le site Web a rencontré une erreur inattendue. Veuillez essayer de nouveau plus tard."
Si vous avez un site Drupal, vous avez probablement déjà vu cette phrase. Elle dit tout et rien : quelque chose est cassé, bonne chance. Pas de code d'erreur, pas de piste, juste une invitation à réessayer plus tard, comme si le problème allait se régler seul. (Il ne se règle jamais seul.)
Ça fait quinze ans que je fais du Drupal : des sites que j'ai construits, et surtout des sites qu'on m'a apportés cassés. À force, un constat s'impose : un site Drupal ne tombe presque jamais en panne tout seul. Derrière chaque écran blanc, chaque erreur 500, chaque formulaire muet, il y a presque toujours une mise à jour. Celle qu'on a faite un peu vite, ou celle qu'on n'a jamais faite.
Voici donc les quatre familles de panne que je retrouve le plus souvent en dépannage Drupal, de la plus spectaculaire à la plus sournoise. Pour chacune : le symptôme, la cause racine, et le bon geste.
Famille 1 : l'écran blanc (ou l'erreur 500) après une mise à jour
Le site marchait vendredi. Lundi matin, c'est une page blanche, ou une erreur 500. Dans le récit qu'on me fait au téléphone, ça commence souvent par "on a mis à jour un module". Et parfois, plus déroutant : "on n'a touché à rien".
Les deux versions pointent vers deux causes racines différentes.
La première, c'est la mise à jour qui s'est mal passée : une dépendance manquante, un patch maison qui ne s'applique plus, ou du code fraîchement mis à jour qui exige une version de PHP que le serveur n'a pas. Le module s'installe, le site tombe.
La seconde, c'est le cas "on n'a touché à rien", et c'est celle que je croise le plus sur les vieux sites : l'hébergeur a monté la version de PHP. Le mutualisé migre en PHP 8, le vieux Drupal 7 ou un module contrib jamais mis à jour ne suit pas, et le site casse un mardi à 4 h du matin sans le moindre déploiement. Les hébergeurs finissent tous par couper les vieilles versions : la fin de vie de PHP 7 a déclenché exactement ce genre de cascade, et les sites qui n'avaient pas suivi sont tombés.
Le bon geste, dans les deux cas, commence par la lecture des logs, jamais par un correctif à l'aveugle : le watchdog de Drupal quand le site répond encore, les logs PHP de l'hébergeur sinon. Un drush cr réflexe masque parfois le symptôme quelques minutes, sans rien réparer du tout. Ensuite, selon le diagnostic : passer le site en mode maintenance, rejouer la mise à jour sur une copie, ou épingler la version de PHP chez l'hébergeur le temps de porter le code. Le réflexe pro tient en une phrase : on reproduit la panne sur une copie avant de toucher à la prod.
Petit aparté : l'écran blanc a un surnom chez les devs Drupal, le WSOD, white screen of death. Quand une panne a son propre acronyme, c'est qu'elle arrive souvent.
Famille 2 : la mise à jour impossible
Celle-ci ne ressemble pas à une panne, et c'est le piège. Le site fonctionne. Mais plus personne n'ose le mettre à jour : composer update hurle des conflits de dépendances, les patchs maison ne s'appliquent plus, et update.php affiche des mises à jour de base de données en attente depuis des mois. Le sujet finit par devenir tabou : tout le monde sait qu'il faudra y passer un jour, et chacun espère que ce sera après son départ.
La cause racine porte un nom : la dette de maintenance. Chaque mise à jour sautée rend la suivante plus risquée. Les écarts de versions se creusent, un module contrib abandonné bloque la montée du coeur, les patchs maison divergent du code qu'ils étaient censés corriger. Pendant ce temps, le projet avance sans vous : Drupal 11 est déjà là, et chaque version laissée passer s'ajoute à l'addition. Au bout de deux ans, la mise à jour n'est plus une opération de routine : c'est un chantier.
Le bon geste commence par un principe : on ne force jamais un composer qui refuse. Ce refus est un garde-fou, pas un obstacle. On lit ce qu'il raconte, on identifie le module bloquant, on met à jour par étapes sur une copie, puis on rejoue les mises à jour de base de données, via update.php ou drush updb, une fois le code redevenu cohérent. Et il faut nommer une réalité du terrain : parfois, la bonne réponse est de désinstaller un module abandonné plutôt que de s'acharner à le porter.
Soyons honnêtes : c'est la famille de panne la moins spectaculaire, et la plus chère. Parce qu'elle ne casse rien de visible, jusqu'au jour où il faut mettre à jour, pour une faille de sécurité ou une version de PHP montée d'office par l'hébergeur, et où plus rien ne passe.
Famille 3 : le site qui se dégrade sans casser
Pas de panne franche ici, juste des signes qu'on met rarement bout à bout : le site ralentit, les contenus programmés ne se publient plus au bon moment, les mails du formulaire de contact n'arrivent plus, la recherche interne renvoie des contenus qui n'existent plus, le disque du serveur se remplit.
La cause racine, dans la plupart des cas : les tâches de fond ne tournent plus. Le cron de Drupal, c'est le coeur battant silencieux du site : indexation de la recherche, purge des caches, files d'attente, nettoyage des logs. Un jour, il s'est arrêté, et personne ne s'en est aperçu, parce qu'un site sans cron continue d'afficher ses pages. Ajoutez un cache qui n'est plus jamais reconstruit proprement, des logs qui s'accumulent, un hébergeur qui a changé ses règles d'envoi de mails sans prévenir, et vous obtenez un site qui a l'air en vie mais qui n'assure plus ses fonctions.
Le bon geste tient en un écran : le rapport d'état de Drupal (le status report). Il dit presque tout : dernière exécution du cron, version de PHP, mises à jour de sécurité en attente, erreurs de configuration. C'est la première chose que je regarde en arrivant sur un site inconnu, avant même d'ouvrir le code. Dix minutes de lecture suffisent souvent à comprendre depuis combien de temps le site vit sans surveillance.
Le point qui pique : ces pannes-là ne génèrent jamais d'appel d'urgence. Un formulaire de devis qui n'envoie plus ses mails ne fait aucun bruit. Il coûte juste des semaines de demandes perdues, jusqu'à ce que quelqu'un s'en aperçoive, en général au détour d'une phrase : "tiens, on n'a plus de demandes depuis un moment".
Famille 4 : le site piraté parce que jamais mis à jour
Les symptômes sont variés : des redirections vers des sites douteux, des pages de spam indexées dans Google sous votre nom de domaine, un navigateur qui affiche un avertissement rouge avant d'ouvrir la page, un hébergeur qui suspend le compte. Et parfois rien de visible du tout : les compromissions discrètes existent, et ce sont les pires. D'ailleurs, le propriétaire est rarement le premier à découvrir le problème : c'est Google, un client, ou l'hébergeur.
La cause racine est presque toujours la même : des mises à jour de sécurité ignorées pendant des années. Drupal a sa mémoire collective sur le sujet : Drupalgeddon, en 2014 puis en 2018. Des failles critiques du coeur, corrigées le jour même de leur annonce côté Drupal, et exploitées pendant des années sur les sites qui n'avaient jamais appliqué le correctif. Le pattern n'a pas changé depuis : une faille publiée est une faille scannée, les robots ratissent le web en continu, et un site non patché finit par être trouvé. La notoriété du site n'y change rien : c'est mécanique, la même mécanique qui fait que les failles s'accumulent dans le code jamais mis à jour.
Le bon geste, quand c'est arrivé : isoler d'abord (mode maintenance), sauvegarder l'état du site tel quel pour l'analyse, puis repartir d'une base saine, code propre et contenus vérifiés, plutôt que de nettoyer à la main. Un site nettoyé sans avoir identifié la porte d'entrée se refait pirater, souvent en quelques jours. Et une fois le site rétabli, combler le retard de mises à jour qui a ouvert la porte, sinon on paiera deux fois la même leçon.
Le point commun : la maintenance différée
Quatre familles, une seule cause. Un site Drupal tenu, mises à jour de sécurité appliquées, cron surveillé, version de PHP suivie, traverse les années sans drame : j'en connais qui tournent depuis plus de dix ans. Un site laissé seul, lui, finit par collectionner les quatre familles, dans l'ordre ou dans le désordre : d'abord la mise à jour impossible, puis la dégradation silencieuse, et un jour l'écran blanc ou le piratage.
Dépanner, c'est mon quotidien, et j'aime ça : chaque panne est une petite enquête. Mais le vrai travail commence après la réparation : faire en sorte que le dépannage ne soit plus nécessaire. Ça s'appelle la maintenance, et ça coûte nettement moins cher qu'une urgence.
Bref : Drupal tient très bien la route quand quelqu'un tient le volant. C'est un CMS vivant, avec des versions qui avancent, des correctifs de sécurité réguliers et des dépendances qui bougent, et c'est précisément ce qui le rend solide depuis plus de vingt ans. Les quatre familles de panne de cet article partagent le même antidote : quelqu'un qui garde un oeil sur le site, même quand tout va bien. Surtout quand tout va bien.