Le code HTTP 307 fait partie de ces réponses serveur que l’on croise rarement directement, mais qui jouent un rôle important dans la navigation web. Il indique une redirection temporaire, avec une particularité essentielle : la méthode utilisée par le navigateur doit être conservée. Pour un site web, une API ou une boutique en ligne, bien comprendre ce statut permet d’éviter des erreurs techniques, des pertes de données et des signaux SEO mal interprétés.
Le code HTTP 307 Temporary Redirect signifie qu’une ressource demandée se trouve temporairement à une autre adresse. Lorsqu’un navigateur, un robot d’exploration ou une application reçoit cette réponse, il doit refaire la requête vers l’URL indiquée dans l’en-tête Location. La redirection est donc bien temporaire, contrairement à une redirection permanente de type 301 ou 308.
Sa particularité tient à la conservation stricte de la méthode HTTP. Si la requête initiale est envoyée en POST, la requête redirigée doit rester en POST. Si elle est envoyée en PUT, elle doit rester en PUT. Cette règle distingue clairement le 307 d’autres codes historiques, dont le comportement a parfois été interprété différemment selon les navigateurs.
Le code 307 a été introduit avec HTTP/1.1 pour lever une ambiguïté importante. Pendant longtemps, certaines redirections temporaires pouvaient transformer une requête POST en GET, ce qui posait problème pour les formulaires, les paiements ou les appels d’API. Avec le statut 307, le client sait précisément quoi faire : recommencer la même requête, avec la même méthode et, le cas échéant, le même corps de requête.
Le fonctionnement est relativement simple. Un client demande une ressource, par exemple une page ou un point d’entrée d’API. Le serveur répond avec le code 307 et fournit une nouvelle URL dans l’en-tête Location. Le client envoie alors une seconde requête vers cette adresse. Ce mécanisme est invisible pour la plupart des internautes, sauf si la redirection échoue ou provoque un ralentissement perceptible.
Dans une navigation classique, un serveur peut renvoyer un HTTP 307 lorsqu’une page est temporairement déplacée, lorsqu’une opération de maintenance est en cours ou lorsqu’un service doit orienter les requêtes vers une autre infrastructure. Le statut est aussi utilisé dans certains environnements applicatifs, notamment pour préserver l’intégrité des requêtes sensibles.
Il existe également un cas particulier appelé parfois 307 Internal Redirect. Celui-ci peut être déclenché par le navigateur, notamment dans le contexte de politiques de sécurité comme HSTS, afin de forcer le passage de HTTP vers HTTPS. Dans ce cas, le serveur distant ne renvoie pas nécessairement un vrai code 307 : le navigateur applique une règle locale avant même d’envoyer la requête finale.
Le code 307 est souvent comparé au 302, car tous deux expriment une redirection temporaire. La différence se situe dans le traitement de la méthode HTTP. Historiquement, le 302 a été interprété de manière souple par de nombreux navigateurs, qui ont parfois transformé une requête POST en GET. Pour mieux comprendre cette logique, l’analyse du fonctionnement d’une redirection temporaire classique montre pourquoi le 307 apporte davantage de précision.
Le code 303, lui, répond à un autre besoin. Il indique au client de consulter une autre ressource avec une requête GET, souvent après l’envoi réussi d’un formulaire. Il est fréquent dans les scénarios où l’on veut éviter qu’un utilisateur renvoie deux fois la même action en actualisant la page. Le rôle du statut 303 après une requête illustre bien cette logique différente.
En résumé, le 307 est le choix adapté lorsqu’il faut signaler un déplacement temporaire sans modifier la nature de la requête. Le 302 reste courant pour des redirections simples de pages web, tandis que le 303 sert surtout à orienter l’utilisateur vers une ressource de confirmation. Cette distinction est importante pour les développeurs, car une mauvaise redirection peut entraîner une perte de données ou un comportement inattendu.
Le code 307 doit être utilisé lorsque le changement d’adresse est temporaire et que le serveur souhaite explicitement conserver la méthode HTTP. Il est particulièrement pertinent pour les services qui traitent des données envoyées par l’utilisateur ou par une application. Dans ces contextes, modifier une requête POST en GET pourrait empêcher une transaction, rompre une session ou exposer des paramètres de manière inappropriée.
Les cas d’usage les plus fréquents concernent les architectures web modernes, les API et les systèmes distribués. Le choix du 307 doit rester volontaire : il ne s’agit pas d’un simple remplacement automatique du 302, mais d’un statut à employer lorsque la conservation de la méthode est nécessaire.
À l’inverse, il vaut mieux éviter le 307 pour des déplacements définitifs. Si une page a changé d’adresse durablement, une redirection permanente sera plus appropriée. Le 307 indique clairement que l’URL d’origine peut redevenir valable. C’est cette notion de caractère temporaire qui doit guider la décision technique.
Du point de vue du référencement naturel, le code 307 est généralement compris comme une redirection temporaire. Les moteurs de recherche peuvent suivre la redirection et découvrir la destination, mais ils n’interprètent pas forcément ce signal comme un transfert durable de popularité ou d’indexation. L’URL initiale peut donc rester la référence principale si la redirection est censée être provisoire.
Pour un site éditorial ou e-commerce, l’usage prolongé d’un code 307 peut créer une ambiguïté. Si une page est redirigée temporairement pendant quelques heures ou quelques jours, cela ne pose généralement pas de difficulté majeure. En revanche, si la redirection reste active pendant plusieurs mois, les moteurs peuvent hésiter entre conserver l’ancienne URL ou traiter la nouvelle comme la version pertinente.
Le risque SEO principal vient souvent des redirections mal configurées : chaînes trop longues, boucles, incohérence entre les balises canoniques et les URL redirigées, ou encore redirections différentes selon les robots et les utilisateurs. Un 307 n’est pas négatif en soi, mais il doit correspondre à une intention claire. Une redirection temporaire permanente finit par envoyer un signal contradictoire.
Pour les contenus stratégiques, mieux vaut vérifier régulièrement les réponses serveur avec des outils d’audit technique, des journaux serveur ou des commandes de test HTTP. Cette surveillance permet d’identifier rapidement les redirections non prévues et de distinguer un comportement temporaire normal d’une erreur de configuration ayant un impact sur le crawl et l’indexation.
La première erreur consiste à utiliser un 307 par défaut sans réfléchir à la méthode HTTP. Beaucoup de frameworks ou de serveurs proposent plusieurs types de redirections, et le choix peut sembler secondaire. Il ne l’est pas. Une redirection qui conserve la méthode peut être indispensable dans une API, mais inutile pour une simple page d’information consultée en GET.
Une autre erreur fréquente concerne les boucles de redirection. Elles apparaissent lorsqu’une URL renvoie vers une autre, qui renvoie à son tour vers la première ou vers une chaîne sans fin. Dans ce cas, le navigateur interrompt la navigation. Pour l’utilisateur, cela se traduit par un message d’erreur. Pour les robots, c’est une perte de temps d’exploration et un signal technique dégradé.
Il faut aussi surveiller les redirections liées à HTTP et HTTPS. Une mauvaise combinaison entre configuration serveur, règles de proxy, CDN et politiques de sécurité peut générer des comportements difficiles à diagnostiquer. Les équipes techniques doivent documenter les règles appliquées et vérifier que chaque redirection mène directement vers la bonne URL finale.
La bonne pratique consiste à réserver le 307 aux situations réellement temporaires, à limiter les intermédiaires et à contrôler l’en-tête Location. L’URL indiquée doit être accessible, cohérente et stable pendant toute la durée de la redirection. En environnement critique, il est recommandé de tester les requêtes POST et les appels d’API afin de confirmer que le corps de requête est bien conservé.
Un code 307 peut être détecté avec les outils de développement du navigateur, dans l’onglet réseau. Lorsqu’une page est chargée, chaque requête affiche son statut HTTP, ses en-têtes et son URL de destination. Cette méthode est utile pour visualiser rapidement le parcours réel d’une redirection et repérer d’éventuelles chaînes inattendues.
Les administrateurs peuvent également consulter les journaux serveur. Ces fichiers donnent une vision plus complète du trafic, notamment pour les robots des moteurs de recherche, les applications tierces ou les utilisateurs qui ne rencontrent pas tous les mêmes règles. Les audits techniques SEO utilisent aussi des crawlers capables de signaler les redirections temporaires présentes sur un site.
Pour une API, le diagnostic doit inclure la méthode HTTP, les en-têtes et le contenu transmis. Un test limité à une requête GET ne suffit pas toujours. Si l’objectif est de valider un 307, il faut vérifier que la requête redirigée conserve bien la même méthode. C’est précisément ce comportement qui donne son utilité au HTTP 307 Temporary Redirect.
Le code HTTP 307 indique une redirection temporaire qui conserve la méthode de la requête initiale. Cette précision en fait un statut particulièrement utile pour les formulaires, les API et les opérations sensibles. Il ne doit toutefois pas être confondu avec une redirection permanente ni utilisé sans logique claire.
Sur le plan SEO, le 307 n’est pas problématique lorsqu’il répond à un besoin ponctuel. Il devient plus délicat s’il remplace durablement une redirection définitive ou s’il s’insère dans des chaînes complexes. La clé reste la cohérence : une redirection temporaire doit vraiment être temporaire, documentée et techniquement maîtrisée.
Bien configuré, le code 307 améliore la fiabilité des échanges entre navigateur, serveur et application. Mal utilisé, il peut provoquer des erreurs discrètes mais coûteuses. Pour les équipes web, il représente donc un outil précis, à manier avec méthode, surtout lorsque la conservation de la méthode HTTP est une condition essentielle au bon fonctionnement du service.
