Site Drupal cassé : que faire en urgence ?

Votre site Drupal ne répond plus. Écran blanc, erreur 500, message de base de données incompréhensible, ou simplement page qui ne charge plus. Le pic de stress monte vite, surtout quand le site est en production et qu'il génère du trafic ou des transactions.

Bonne nouvelle : la plupart des incidents Drupal ont une cause identifiable et une solution connue. Mauvaise nouvelle : si vous tâtonnez, vous risquez d'aggraver la situation. Voici les étapes méthodiques pour diagnostiquer et réparer un site Drupal cassé sans paniquer.

Les symptômes courants d'un site Drupal en panne

Avant d'agir, identifiez précisément ce que vous voyez. Le diagnostic dépend du symptôme.

L'écran blanc de la mort (WSOD)

Vous chargez la page d'accueil, vous voyez une page blanche, sans aucun message. C'est le fameux White Screen Of Death de Drupal. Il signifie qu'une erreur PHP fatale a interrompu l'exécution avant qu'aucun contenu ne soit envoyé au navigateur, et que l'affichage des erreurs est désactivé en production (ce qui est normal).

Erreur 500 ou erreur 503

Le serveur renvoie un code d'erreur HTTP. La 500 indique une erreur applicative (PHP, base de données, configuration). La 503 indique souvent un problème de ressources serveur (mémoire saturée, processus PHP épuisés) ou un mode maintenance mal configuré.

Erreur de connexion à la base de données

Le message "PDOException" ou "Error establishing a database connection" apparaît clairement. Le site ne peut pas joindre MySQL ou MariaDB. Cause : serveur de base de données arrêté, mot de passe modifié, fichier settings.php corrompu, ou disque saturé.

Le site fonctionne mais affiche du contenu cassé

Pages partiellement rendues, blocs vides, mise en page complètement déstructurée. Souvent dû à un problème de cache, à un module incompatible récemment activé, ou à une mise à jour partielle.

Le back-office est inaccessible alors que le front fonctionne

Vous arrivez sur le site visiteur mais /user/login plante. Causes typiques : problème de session, conflit de module sur les routes admin, ou Twig debug activé en production.

Diagnostic rapide : les premières vérifications

Vérifier les logs

C'est toujours la première étape. Ne touchez à rien tant que vous n'avez pas regardé les logs.

# Logs Apache ou Nginx
tail -50 /var/log/apache2/error.log
tail -50 /var/log/nginx/error.log

# Logs PHP-FPM
tail -50 /var/log/php8.3-fpm.log

# Logs Drupal (watchdog) si la base est accessible
drush watchdog:show --count=20 --severity=error

Le message d'erreur exact vous dira presque toujours quel module, quel fichier ou quelle ligne pose problème. Notez ces informations avant de toucher à quoi que ce soit.

Vérifier l'état du serveur

# Espace disque (très souvent la cause)
df -h

# Mémoire
free -h

# Processus PHP qui tournent
ps aux | grep php

Un disque plein à 100% est une des causes les plus fréquentes de pannes mystérieuses. Si df montre 100%, libérez de l'espace avant tout autre diagnostic.

Drush status

Si vous avez accès au serveur en SSH et que Drush est installé, lancez immédiatement :

drush status

Vous obtenez en quelques secondes : version Drupal, état de la base, version PHP, mode maintenance actif ou non, statut du cache. Si Drush ne se lance pas, le problème est probablement bas niveau (PHP, permissions, base de données).

Tester en mode maintenance

Activer le mode maintenance peut limiter les dégâts pendant le diagnostic, surtout si le site est public.

drush state:set system.maintenance_mode 1 --input-format=integer
drush cache:rebuild

Pensez à le désactiver après remédiation : drush state:set system.maintenance_mode 0.

Les causes les plus fréquentes (et comment les corriger)

Une mise à jour qui tourne mal

Vous avez fait composer update puis drush updatedb, et tout est cassé. C'est la cause la plus fréquente d'incident.

Premier réflexe : revenez à l'état précédent.

git checkout HEAD~1 composer.lock
composer install
drush cache:rebuild

Si vous avez une sauvegarde de la base d'avant la mise à jour, restaurez-la. Si vous n'en avez pas, c'est exactement le moment de mettre en place une stratégie de sauvegarde et un environnement de staging avant tout futur déploiement. Notre forfait de maintenance Drupal mensuelle inclut systématiquement ces deux éléments.

Un module incompatible

Un module contribué a été mis à jour vers une version incompatible avec votre version de Drupal, ou avec un autre module. Identifiez le coupable via les logs.

# Désactiver un module spécifique
drush pm:disable nom_du_module -y
drush cache:rebuild

Si le module est essentiel au fonctionnement et que vous ne pouvez pas le désactiver, vérifiez sur drupal.org si une version corrective existe.

Mémoire PHP insuffisante

L'erreur "Allowed memory size of X bytes exhausted" est explicite. Augmentez la limite dans php.ini ou settings.php.

// dans settings.php
ini_set('memory_limit', '512M');

Si le problème survient lors d'opérations spécifiques (import massif, génération de cache), c'est normal. Si le site bascule en erreur sur une simple page d'accueil, c'est qu'un module fait fuiter de la mémoire et qu'il faut investiguer plus loin.

Permissions de fichiers cassées

Drupal a besoin d'accès en écriture sur certains répertoires (sites/default/files, dossier de cache, dossier de logs). Si les permissions ont été modifiées (par un déploiement, un changement de propriétaire), le site casse.

# Restaurer des permissions correctes
sudo chown -R www-data:www-data web/sites/default/files
sudo find web/sites/default/files -type d -exec chmod 755 {} \;
sudo find web/sites/default/files -type f -exec chmod 644 {} \;

Cache corrompu

Parfois le simple fait de vider le cache résout des problèmes mystérieux qui ne devraient pas exister.

drush cache:rebuild

Si Drush n'est pas accessible, vous pouvez aussi vider manuellement les tables cache_* dans la base, ou supprimer le contenu du dossier sites/default/files/php et sites/default/files/css/js.

Quand faire appel à un expert Drupal

Tentez le diagnostic et les corrections de premier niveau si vous avez les compétences techniques. Mais arrêtez et appelez de l'aide dans les situations suivantes :

• Le site est en production et génère du chiffre d'affaires : chaque heure d'indisponibilité coûte cher, ce n'est pas le moment d'apprendre.
• Vous suspectez une compromission de sécurité : un site piraté demande une investigation forensique avant restauration. Restaurer un backup compromis ne sert à rien.
• Vous avez tenté plusieurs corrections sans succès : chaque action non documentée complique le diagnostic suivant.
• Le site est sur Drupal 7 : les ressources se raréfient, et beaucoup de modules ne sont plus maintenus. Un expert Drupal 7 fait gagner des heures.

Notre support Drupal d'urgence intervient dans la journée sur les incidents critiques, avec un audit immédiat des logs, un diagnostic précis et une remédiation encadrée. Sur les sites suivis en maintenance Drupal mensuelle, ce type d'incident est généralement évité par la prévention.

Prévenir plutôt que guérir

La majorité des incidents Drupal sont prévisibles et évitables. Quelques règles simples réduisent drastiquement le risque :

1. Déployez via un environnement de staging. Jamais en direct sur la production.
2. Sauvegardez avant chaque mise à jour. Et testez la restauration au moins une fois par mois.
3. Mettez à jour régulièrement. Une mise à jour toutes les six semaines est gérable. Six mois de retard, ça l'est beaucoup moins.
4. Documentez vos modules custom. Le futur vous (ou votre successeur) vous remerciera.
5. Mettez en place du monitoring. Disponibilité, temps de réponse, espace disque, certificat SSL : un outil basique vous prévient avant que vos utilisateurs ne le fassent.

Ces points sont systématiquement couverts par un forfait de maintenance professionnel, et c'est précisément pourquoi un site bien maintenu casse rarement.

En résumé

Un site Drupal cassé n'est presque jamais perdu. Le diagnostic suit toujours la même séquence : identifier le symptôme, lire les logs, vérifier l'état serveur, isoler la cause, appliquer la correction adaptée. Avec méthode, la plupart des incidents se règlent en quelques heures.

La vraie question, ce n'est pas comment réparer un site cassé, c'est comment éviter qu'il casse au prochain déploiement. La maintenance régulière, les sauvegardes testées, le staging et le monitoring sont les quatre piliers qui transforment Drupal d'une plateforme fragile en un CMS fiable sur la durée.