# Erreur 502, 503, 504 : le serveur abandonne en cours de route

> Contrairement à une erreur 500, ces trois codes ne viennent presque jamais du code de votre site. Ils sont émis par l’intermédiaire placé devant lui — répartiteur, cache, proxy de l’hébergeur — qui a attendu une réponse et a fini par renoncer. Savoir lequel a renoncé, et au bout de combien de temps, mène directement à la cause.

- Source canonique : [https://allaux.fr/problemes/erreur-504-et-delais-depasses](https://allaux.fr/problemes/erreur-504-et-delais-depasses)
- Langue : FR
- Dernière mise à jour : 2026-09-30

## Réponse directe

> Chronométrez : notez au bout de combien de secondes l’erreur tombe, 30, 60 ou 300. Ce nombre correspond à une limite configurée, jamais au hasard. Comparez-le à max_execution_time côté PHP et au délai d’attente du proxy dans le panneau d’hébergement. Un 502 est différent : le processus PHP-FPM s’est arrêté, et sa trace est dans error_log au même horodatage.

## Ce que dit chaque code

502 : l’intermédiaire a joint le service applicatif, mais celui-ci a renvoyé une réponse invalide ou s’est terminé brutalement. Typiquement, le processus qui exécute PHP a été tué en cours d’exécution, par manque de mémoire ou par le gestionnaire de ressources de l’hébergeur.

503 : le service est indisponible ou refuse de nouvelles demandes. C’est le code d’un service arrêté, d’une file d’attente pleine, ou d’un mode maintenance actif. C’est aussi celui qu’un CMS renvoie volontairement pendant une mise à jour.

504 : l’intermédiaire a bien transmis la demande, mais aucune réponse n’est arrivée dans le délai autorisé. Le site travaille encore quand la connexion est coupée. C’est le code d’une opération trop longue, pas d’une opération impossible.

## Isoler l’opération trop longue

1. **Chronométrer l’échec** — Notez le nombre de secondes avant l’apparition de l’erreur. Un chiffre rond et toujours identique — 30, 60, 120, 300 — est une limite configurée, pas un hasard. Ce chiffre identifie souvent le composant qui coupe.
2. **Repérer les pages concernées** — Une seule page d’administration, un export, un import, une recherche : l’erreur suit presque toujours une opération lourde précise, pas le site entier.
3. **Vérifier si le travail se fait quand même** — Un import qui renvoie une erreur 504 mais dont les produits apparaissent quand même en base signifie que le traitement continue côté serveur. Le relancer double alors les données.
4. **Regarder les tâches planifiées** — Une tâche automatique lourde qui se déclenche à heure fixe peut saturer le serveur et provoquer des 502 ou 504 sur les pages publiques pendant sa durée.
5. **Demander les limites en vigueur** — Durée maximale d’exécution, mémoire allouée, nombre de processus simultanés : ces trois valeurs déterminent le seuil, et l’hébergeur les communique.

## Augmenter le délai n’est pas toujours la bonne réponse

> Passer une limite de 30 à 300 secondes fait disparaître le message, mais laisse une page qui met cinq minutes à répondre — et retient un processus serveur pendant tout ce temps. Sur une opération répétée, cela fabrique la saturation qu’on voulait éviter. La bonne réponse est plus souvent de découper le traitement par lots.

## Les causes que je rencontre le plus

Un import ou un export de catalogue lancé d’un seul bloc sur plusieurs milliers de lignes.

Une page d’administration qui liste tous les enregistrements sans pagination réelle, alors que la table a grossi pendant des années.

Un appel à un service externe — transporteur, logiciel de gestion, fournisseur — qui ne répond plus, et dont l’attente bloque le chargement de la page entière.

Un pic de trafic sur un hébergement mutualisé, où le nombre de processus simultanés est plafonné.

Une requête en base sans index adapté, qui parcourt une table entière à chaque affichage.

## Continuer sur la bonne page

- **Choisir un hébergement e-commerce** — Quelles limites regarder quand les ressources sont réellement en cause. ([/guides/choisir-hebergement-ecommerce](/guides/choisir-hebergement-ecommerce))
- **Diagnostiquer une boutique lente** — Si les erreurs accompagnent une lenteur générale, la méthode de mesure. ([/guides/diagnostiquer-boutique-lente](/guides/diagnostiquer-boutique-lente))
- **Tâches cron qui ne s’exécutent pas** — Quand une tâche planifiée sature le serveur ou ne se termine jamais. ([/prestashop/problemes/taches-cron-ne-sexecutent-pas](/prestashop/problemes/taches-cron-ne-sexecutent-pas))
- **La base de données et ses index** — Pourquoi une requête sans index fait basculer une page dans le délai dépassé. ([/glossaire/base-de-donnees](/glossaire/base-de-donnees))

## FAQ

### L’erreur 504 est-elle un problème de mon hébergeur ?

Pas nécessairement. L’hébergeur émet le message, mais c’est votre site qui n’a pas répondu à temps. La question utile est : quelle opération dure aussi longtemps, et pourquoi.

### Pourquoi l’erreur n’apparaît que sur une seule page ?

Parce que cette page déclenche une opération que les autres ne déclenchent pas. C’est une excellente nouvelle pour le diagnostic : le champ de recherche est déjà réduit à quelques traitements.

### Un site en 503 pendant une mise à jour, est-ce normal ?

Oui, temporairement. Un 503 qui persiste après la fin de la mise à jour signifie que le fichier de maintenance n’a pas été supprimé, ce qui se corrige en quelques secondes avec un accès aux fichiers.

### Ces erreurs peuvent-elles venir d’une attaque ?

Un volume anormal de requêtes automatisées sature les processus disponibles et produit exactement ces codes. Les journaux d’accès permettent de distinguer un pic de trafic légitime d’un balayage automatisé.

### Faut-il passer sur un serveur dédié ?

Seulement si la mesure montre que les limites sont réellement atteintes par un usage normal. Sur un traitement mal découpé, un serveur plus puissant repousse le seuil de quelques mois, sans plus.