« 500 Internal Server Error » sur chaque page consultée dans une langue autre que la langue par défaut, immédiatement après une migration vers un nouvel hébergeur mutualisé : c’est le symptôme exact rencontré sur un site vitrine traduit avec TranslatePress en mode automatique par proxy. Les pages en langue source restaient parfaitement fonctionnelles, ce qui a orienté le diagnostic dès le départ vers le mécanisme de traduction lui-même plutôt que vers une panne générale du serveur.
Symptôme : tout casse, sauf la langue source
Le site utilisait le mode de traduction automatique par proxy de TranslatePress, qui fonctionne en interceptant les requêtes du visiteur, en récupérant le contenu original, puis en le faisant transiter par les serveurs de traduction automatique de l’extension avant de renvoyer la page traduite au navigateur. Ce mécanisme suppose que le serveur d’hébergement puisse établir lui-même une connexion sortante vers l’infrastructure de TranslatePress.
Après la migration, chaque requête sur une URL en langue non par défaut renvoyait une erreur 500 générique, sans message explicite côté navigateur. Les journaux d’erreur PHP du serveur, une fois consultés, affichaient un délai d’attente dépassé lors d’un appel wp_remote_post(), sans autre précision immédiate.
Diagnostic : un accès sortant bloqué chez le nouvel hébergeur
Le nouvel hébergeur mutualisé appliquait, par défaut, un pare-feu réseau restrictif sur les connexions sortantes depuis les comptes d’hébergement, une pratique courante pour limiter les usages abusifs mais rarement documentée clairement dans les offres commerciales. L’ancien hébergeur ne bloquait aucune connexion sortante, ce qui expliquait pourquoi le mode proxy fonctionnait sans difficulté avant la migration.
Un test simple a permis de confirmer l’hypothèse : une tentative de connexion sortante manuelle depuis le serveur, via une commande curl exécutée en SSH vers l’infrastructure de TranslatePress, échouait avec un délai d’attente identique à celui observé dans les journaux PHP.
curl -v --max-time 10 https://api.translatepress.com/
# curl: (28) Failed to connect: Connection timed out
Ce résultat confirmait que le blocage se situait au niveau réseau du serveur, en amont de tout code WordPress ou configuration de l’extension. Aucun réglage dans l’administration de TranslatePress ne pouvait corriger un pare-feu sortant appliqué au niveau de l’infrastructure d’hébergement.
Correctif : ouvrir les ports sortants nécessaires
La correction a nécessité un ticket auprès du support du nouvel hébergeur, demandant explicitement l’ouverture des connexions sortantes en HTTPS, port 443, vers les domaines utilisés par l’infrastructure de traduction automatique de TranslatePress. Certains hébergeurs mutualisés exigent une liste blanche précise de domaines plutôt qu’une ouverture générale du port 443 sortant, pour des raisons de sécurité internes.
Après ouverture de cet accès sortant, une nouvelle tentative de curl depuis le serveur a confirmé la connexion, et les pages traduites ont immédiatement recommencé à s’afficher normalement, sans qu’aucune modification n’ait été nécessaire côté WordPress ou côté configuration de l’extension elle-même.
- Vérifier d’abord si le problème touche toutes les langues ou seulement certaines.
- Tester la connexion sortante du serveur avec une commande
curldirecte. - Demander explicitement l’ouverture des ports sortants nécessaires au support de l’hébergeur.
Prévention : documenter les dépendances réseau avant toute migration
La leçon la plus utile de cet incident concerne la préparation des migrations futures, pas seulement le correctif lui-même. Toute extension fonctionnant en mode proxy ou dépendant d’un service externe accessible depuis le serveur mérite d’être documentée explicitement dans une checklist de migration, avec la liste des domaines et ports nécessaires en sortie.
Une migration d’hébergeur ne se limite jamais au transfert des fichiers et de la base de données ; elle inclut la vérification de chaque dépendance réseau sortante que le site sollicite silencieusement.
Un test post-migration systématique
Depuis cet incident, l’équipe ajoute une étape de recette spécifique après toute migration d’hébergeur : consulter au moins une page dans chaque langue traduite automatiquement, avant même de considérer la migration comme terminée. Ce test, qui prend moins de cinq minutes, aurait permis de détecter le problème immédiatement plutôt que plusieurs heures après la mise en production, lorsque des visiteurs ont commencé à signaler l’incident.
Ce qu’il faut retenir
Une erreur 500 limitée aux pages traduites, sur un site utilisant un mode de traduction par proxy, doit systématiquement faire suspecter un blocage réseau sortant plutôt qu’un problème de configuration de l’extension elle-même. Le réflexe curl en ligne de commande depuis le serveur reste le moyen le plus rapide de confirmer ou d’écarter cette hypothèse avant d’explorer des pistes plus complexes.
