Mon site Magento est en panne : le guide de dépannage d’urgence (Magento 2)

Votre boutique Magento est en panne, vous perdez des ventes à chaque minute, et vous cherchez une réponse rapide. Cet article est fait pour ça : les pannes Magento 2 les plus fréquentes, avec la commande exacte pour rétablir le service. Gardez-le en favori — le jour où votre site tombe, vous n’aurez pas le temps de chercher.

Un avertissement avant de commencer : toutes les commandes ci-dessous s’exécutent en SSH sur votre serveur, depuis la racine de votre installation Magento. Si vous n’avez pas d’accès SSH ou si vous n’êtes pas sûr de ce que fait une commande, arrêtez-vous et appelez quelqu’un. Une mauvaise manipulation sur une boutique en production peut aggraver la panne. Toutes ces commandes concernent Magento 2.4.x — pas Magento 1, dont les manipulations sont radicalement différentes et obsolètes.

Réflexe n°0 — activer l’affichage des erreurs pour comprendre

Avant de tenter quoi que ce soit à l’aveugle : une page blanche ou une erreur générique ne vous dit rien. Passez en mode développeur pour voir l’erreur réelle, ou consultez directement les logs.

# Voir le mode actuel
php bin/magento deploy:mode:show

# Consulter les derniers rapports d'erreur
tail -n 50 var/log/exception.log
tail -n 50 var/log/system.log
ls -lt var/report/ | head

Le fichier le plus récent dans var/report/ contient souvent l’ID d’erreur affiché à l’écran et la trace complète. C’est votre point de départ. Ne passez jamais une boutique de production en mode développeur de façon permanente — uniquement le temps du diagnostic, puis revenez en production.

Panne n°1 — Erreur 503 / le site est bloqué en maintenance

Symptôme : le site affiche « Service Temporarily Unavailable » ou une page de maintenance, front et back inaccessibles. Cause la plus fréquente : un flag de maintenance qui n’a pas été retiré après une opération (souvent un setup:upgrade interrompu).

# Solution propre
php bin/magento maintenance:disable

# Si la commande ne répond pas, supprimer le flag manuellement
rm -f var/.maintenance.flag

Si le 503 persiste après ça, vérifiez que ce n’est pas votre serveur web ou Varnish qui renvoie l’erreur — dans ce cas le problème est côté infrastructure, pas côté Magento.

Panne n°2 — Page blanche ou erreur 500 après un déploiement

Symptôme classique après un setup:upgrade ou un déploiement : le site charge une page blanche, ou le front s’affiche sans style (page « cassée », sans CSS ni images). Dans 9 cas sur 10, c’est le contenu statique qui n’a pas été redéployé.

# La séquence de récupération après un setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f fr_FR en_US
php bin/magento cache:flush

Adaptez les codes langue (fr_FR en_US) à ceux réellement configurés sur votre boutique. Si vous utilisez un thème spécifique, précisez-le avec --theme. Point important : la commande setup:static-content:deploy ne peut pas combiner --theme et --exclude-theme dans le même appel — il faut choisir l’un ou l’autre.

Panne n°3 — « Access Denied » en accédant à l’admin

Symptôme : vous êtes connecté au back-office mais chaque page affiche « Access Denied », ou un menu entier a disparu. Cause fréquente : les rôles ACL n’ont pas été correctement régénérés après une mise à jour ou l’ajout d’un module.

# Régénérer et vider
php bin/magento cache:flush
php bin/magento setup:upgrade
php bin/magento cache:flush

Si le problème vient d’un rôle utilisateur mal configuré, allez dans System → Permissions → User Roles, ouvrez le rôle concerné, et vérifiez que les ressources autorisées (« Role Resources ») sont bien cochées. Déconnexion/reconnexion après changement.

Panne n°4 — Mot de passe admin oublié / plus aucun accès

Symptôme : vous ne pouvez plus vous connecter au back-office et la récupération par email ne fonctionne pas. La solution Magento 2 n’est pas de modifier le mot de passe directement en base de données (contrairement à ce qu’on lit sur d’anciens tutoriels Magento 1 — le hash Magento 2 est bien plus complexe et une modification manuelle corromprait le compte). La bonne méthode : créer un nouvel admin en ligne de commande.

php bin/magento admin:user:create \
  --admin-user="nouveladmin" \
  --admin-password="MotDePasseFort123!" \
  --admin-email="admin@votredomaine.com" \
  --admin-firstname="Prenom" \
  --admin-lastname="Nom"

Le mot de passe doit contenir au moins 7 caractères avec lettres et chiffres, sinon Magento le refuse. Une fois connecté avec ce nouveau compte, vous pourrez réinitialiser l’ancien depuis l’interface.

Panne n°5 — Le site est devenu très lent d’un coup

Symptôme : pas de panne franche, mais des temps de chargement qui explosent. Trois causes à vérifier dans l’ordre.

Diagnostic d’une lenteur soudaine

1

Vérifier l’état des index

php bin/magento indexer:status — si des index sont « invalid », les reconstruire : php bin/magento indexer:reindex

2

Vérifier le mode de déploiement

php bin/magento deploy:mode:show — une boutique de production en mode « developer » est dramatiquement lente. Elle doit être en « production ».

3

Vérifier que le cache est actif

php bin/magento cache:status — tous les caches doivent être à 1 (activés). Un cache désactivé par erreur écroule les performances.

4

Regarder les ressources serveur

Si tout est correct côté Magento, le problème est peut-être côté serveur : RAM saturée, swap, MySQL surchargé. Là, ça relève de l’administration système.

Panne n°6 — Erreur après l’installation d’une extension

Symptôme : vous venez d’installer un module et le site plante. La priorité est de désactiver le module fautif pour rétablir le service, puis de diagnostiquer à froid.

# Désactiver le module problématique
php bin/magento module:disable Vendor_ModuleName
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento cache:flush

Remplacez Vendor_ModuleName par le nom réel du module (visible dans app/etc/config.php ou dans le message d’erreur). Ne supprimez pas les fichiers du module manuellement — module:disable est propre et réversible.

Panne n°7 — Impossible de se connecter (cookies rejetés) après changement de domaine

Symptôme : après un changement de domaine ou une migration, la connexion admin tourne en boucle — vous entrez vos identifiants et revenez à la page de login. Le domaine de cookie configuré ne correspond plus à l’URL réelle.

# Mettre à jour les URLs de base
php bin/magento config:set web/unsecure/base_url https://www.nouveaudomaine.com/
php bin/magento config:set web/secure/base_url https://www.nouveaudomaine.com/

# Purger le domaine de cookie hérité (via base de données)
# ATTENTION : sauvegardez la base avant toute requête SQL
php bin/magento cache:flush

Si le blocage persiste, le domaine de cookie est probablement figé dans core_config_data (chemins web/cookie/cookie_domain). La suppression de ces lignes en base résout le problème — mais toute manipulation SQL directe doit être précédée d’une sauvegarde complète de la base.

La commande qui résout une grande partie des cas

Si vous ne deviez retenir qu’une séquence, c’est celle-ci. Après la plupart des opérations qui tournent mal, ce nettoyage complet remet souvent les choses d’aplomb :

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f fr_FR
php bin/magento cache:flush

Attention : setup:di:compile et static-content:deploy peuvent prendre plusieurs minutes et générer une brève indisponibilité. À exécuter de préférence en dehors des heures de forte affluence, et jamais à l’aveugle sur une boutique en production si vous n’êtes pas sûr de vous.

FAQ

Je n’ai pas d’accès SSH — comment faire ?

La quasi-totalité de ces commandes nécessitent un accès SSH au serveur. Sans lui, vos options sont très limitées — vous pouvez parfois vider le cache depuis le back-office (System → Cache Management) si celui-ci est accessible, mais c’est tout. Si votre site est en panne et que vous n’avez pas d’accès SSH, contactez votre hébergeur ou un prestataire Magento en urgence.

Ces commandes fonctionnent-elles sur toutes les versions de Magento 2 ?

Oui, sur l’ensemble des versions 2.4.x. La syntaxe des commandes CLI Magento 2 est stable depuis plusieurs versions. En revanche, elles ne s’appliquent pas à Magento 1, dont l’architecture et les commandes sont entièrement différentes — Magento 1 n’est plus supporté depuis juin 2020 et ne devrait plus être en production.

Dois-je sauvegarder avant d’exécuter ces commandes ?

Pour les commandes de cache et de réindexation, le risque est faible. Pour tout ce qui touche à la base de données (requêtes SQL, changement de configuration critique) ou à la structure (setup:upgrade), une sauvegarde préalable de la base et des fichiers est fortement recommandée. Sur une boutique de production, la règle est simple : sauvegarde systématique avant toute opération non triviale.