Services techniques gérés partout au Canada
Fièrement canadien

Guide

Corriger ERR_TOO_MANY_REDIRECTS : Cloudflare, .htaccess et WordPress (2026)

Les boucles de redirection sont presque toujours causées par le SSL Flexible de Cloudflare ou une règle .htaccess conflictuelle. Ce guide identifie la source exacte et la corrige étape par étape.

Processus éditorial : Cet article a été créé avec l’aide de l’intelligence artificielle et préparé pour publication par Gotekky.

Réponse rapide

À vérifier d’abord

Les boucles de redirection sont presque toujours causées par le SSL Flexible de Cloudflare ou une règle .htaccess conflictuelle. Ce guide identifie la source exacte et la corrige étape par étape.

ERR_TOO_MANY_REDIRECTS est l'une de ces erreurs qui peut empêcher complètement un site de se charger tout en vous donnant presque aucune information utile sur ce qui ne va pas réellement. Le navigateur a suivi une chaîne de redirections, chacune pointant vers une autre URL, et après avoir atteint sa limite il abandonne et affiche l'erreur. Le problème sous-jacent est un conflit de configuration quelque part dans votre infrastructure qui provoque un cycle de redirections plutôt qu'une redirection qui se résout vers une page finale.

 

La partie frustrante est que cette erreur peut venir de plusieurs endroits différents : Cloudflare, votre fichier .htaccess, les paramètres d'URL WordPress, un plugin de redirection, ou même une combinaison de plusieurs conflits. Ce guide parcourt chaque cause dans l'ordre du plus au moins courant, avec des instructions spécifiques pour diagnostiquer et corriger chacune.

 

Résumé rapide

 

  • La cause la plus courante sur les sites proxifiés par Cloudflare est le mode SSL Cloudflare défini sur Flexible combiné avec une règle de redirection HTTPS côté serveur
  • Les règles de redirection conflictuelles dans .htaccess, les paramètres d'URL WordPress et les plugins de redirection sont les causes suivantes les plus courantes
  • Vider vos cookies et cache de navigateur élimine les instructions de redirection stockées localement qui peuvent masquer un problème résolu ou compliquer le diagnostic
  • Les outils de développement du navigateur montrent la chaîne complète de redirections, ce qui vous indique exactement où la boucle se produit
  • La correction implique presque toujours soit de changer le mode SSL Cloudflare sur Complet, soit de corriger une règle de redirection .htaccess

 

Comment se produit une boucle de redirection

 

Une redirection est une instruction serveur qui indique à un navigateur d'aller vers une URL différente. Quand vous visitez une version HTTP d'une URL et que le serveur vous redirige vers la version HTTPS, c'est une seule redirection se résolvant correctement vers une destination finale. Une boucle de redirection se produit quand la destination finale d'une redirection est elle-même une URL qui déclenche une autre redirection vers là d'où vous venez, ou quand la chaîne de redirections passe en cycle par des URLs indéfiniment sans jamais atteindre une page avec un statut 200 OK.

 

Les navigateurs limitent le nombre de redirections qu'ils suivront avant d'abandonner pour éviter que les boucles infinies ne consomment des ressources. Chrome et Firefox s'arrêtent généralement après environ 20 redirections et affichent l'erreur ERR_TOO_MANY_REDIRECTS. L'erreur ne signifie pas que 20 destinations différentes sont impliquées. Cela signifie généralement que les mêmes deux ou trois URLs se redirigent mutuellement à répétition jusqu'à ce que la limite soit atteinte.

 

Le cycle de redirection est toujours causé par un conflit de configuration quelque part. Deux règles essaient chacune d'imposer leur propre version de l'URL correcte, et chaque redirection déclenche l'autre. Comprendre où vos redirections sont générées est le point de départ de chaque correction dans ce guide.

 

Étape 1 : Vider les cookies et tester depuis un mode incognito

 

Avant d'investiguer la configuration serveur, éliminez l'état local de votre navigateur comme variable. Certaines boucles de redirection persistent dans votre navigateur après que le problème de configuration sous-jacent a été résolu parce que les cookies définis pendant la boucle sont encore présents. Ces cookies peuvent instruire le navigateur de suivre une redirection à chaque requête, même quand le serveur ne génère plus la boucle lui-même.

 

Ouvrez une fenêtre de navigation privée ou incognito et essayez de charger votre site. Le mode incognito commence sans cookies ni données mises en cache. Si le site se charge correctement en mode incognito, le problème est dans les données stockées de votre navigateur plutôt que dans la configuration de votre serveur. Vider vos cookies et le cache de navigateur pour votre domaine devrait le résoudre.

 

Si le site boucle encore en mode incognito, le problème est dans la configuration de votre serveur et les étapes restantes s'appliquent.

 

Étape 2 : Tracer la chaîne de redirections dans les DevTools du navigateur

 

Avant de modifier quoi que ce soit, identifiez d'où viennent les redirections. Cela prend deux minutes et vous indique exactement quelle partie de votre infrastructure génère chaque redirection, ce qui vous évite de changer la mauvaise chose.

 

Ouvrez Chrome et appuyez sur F12 pour ouvrir les DevTools. Accédez à l'onglet Réseau et cochez la case Conserver le journal. Effacez les entrées existantes, puis tapez votre domaine dans la barre d'adresse et appuyez sur Entrée. Vous verrez une séquence de requêtes apparaître. Cliquez sur chacune avec un code de statut 301 ou 302 et regardez l'onglet En-têtes pour l'en-tête Location, qui montre vers où pointe cette redirection.

 

Tracez la chaîne du début à la fin. Une boucle SSL Flexible Cloudflare typique ressemble à ceci : votre domaine se charge en HTTPS, Cloudflare se connecte à votre serveur via HTTP, votre serveur redirige HTTP vers HTTPS, ce qui revient à Cloudflare, qui se reconnecte à votre serveur via HTTP, et ainsi de suite. Une boucle .htaccess pourrait rediriger de la version www vers la version non-www pendant qu'une autre règle redirige de non-www vers www.

 

Savoir exactement quelles URLs sont dans la boucle et si les redirections viennent du même serveur à chaque étape ou alternent entre différents points vous indique directement quelle configuration corriger.

 

Étape 3 : Vérifier votre mode SSL Cloudflare

 

Si votre site utilise Cloudflare, c'est la première configuration côté serveur à vérifier car c'est de loin la cause la plus courante de cette erreur spécifique. Le problème se produit quand le mode SSL Cloudflare est défini sur Flexible.

 

En mode Flexible, Cloudflare accepte les connexions HTTPS des visiteurs puis se connecte à votre serveur d'origine via HTTP sur le port 80. Si votre serveur a une règle .htaccess ou une configuration serveur qui redirige tout le trafic HTTP vers HTTPS, une boucle est créée : Cloudflare envoie une requête HTTP à votre serveur, votre serveur la redirige vers HTTPS, Cloudflare reçoit la redirection, se reconnecte via HTTP, reçoit une autre redirection, et le cycle continue.

 

La correction consiste à changer votre mode SSL Cloudflare. Connectez-vous à Cloudflare, sélectionnez votre domaine, accédez à SSL/TLS, et cliquez sur Vue d'ensemble. Changez le mode de chiffrement de Flexible à Complet. Le mode Complet dit à Cloudflare de se connecter à votre serveur d'origine via HTTPS, ce qui signifie que la redirection HTTP vers HTTPS du serveur n'est plus jamais déclenchée.

 

Si vous avez un certificat valide correctement signé sur votre serveur d'origine provenant de Let's Encrypt, Sectigo, ou une autre autorité de confiance, utilisez plutôt Complet (strict), qui vérifie en plus la validité du certificat. Si votre serveur d'origine n'a qu'un certificat auto-signé, utilisez Complet plutôt que Complet (strict).

 

Après avoir changé le mode SSL, attendez une à deux minutes et testez à nouveau votre site. Cette correction résout la boucle immédiatement dans la plupart des cas.

 

Étape 4 : Examiner votre fichier .htaccess

 

Si vous n'utilisez pas Cloudflare, ou si vous avez déjà corrigé le mode SSL Cloudflare et que la boucle persiste, le fichier .htaccess est le prochain endroit à regarder. Ce fichier contrôle la réécriture d'URL et les règles de redirection pour les serveurs basés sur Apache, ce qui inclut la plupart des environnements d'hébergement cPanel.

 

Accédez à votre fichier .htaccess via le Gestionnaire de fichiers de cPanel. Naviguez jusqu'à la racine du répertoire public_html de votre domaine, activez Afficher les fichiers cachés dans les paramètres (puisque .htaccess est un fichier caché), et cliquez dessus pour voir son contenu.

 

Cherchez toute directive RewriteRule ou Redirect. Un .htaccess WordPress propre ne contient que ce bloc pour la gestion des permaliens :

 

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Toute règle de redirection supplémentaire au-delà de cela mérite examen. Un schéma problématique courant est deux règles de redirection qui entrent en conflit : une redirigeant de www vers non-www, et une autre redirigeant de non-www vers www. Un autre problème courant est une redirection HTTP vers HTTPS qui n'est pas conditionnée sur le fait que la requête soit déjà en HTTPS, la faisant rediriger des requêtes HTTPS vers HTTPS.

 

Une redirection HTTP vers HTTPS correctement écrite dans .htaccess doit vérifier si la connexion utilise déjà HTTPS avant de rediriger :

 

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

La condition RewriteCond %{HTTPS} off garantit que la redirection ne se déclenche que quand la requête n'est pas déjà en HTTPS. Sans cette condition, une requête HTTPS peut déclencher la redirection vers HTTPS à nouveau, créant une boucle.

 

Si vous utilisez Cloudflare et avez ce type de redirection dans .htaccess, sachez qu'en mode SSL Flexible, la connexion de Cloudflare à votre serveur est toujours via HTTP, donc la vérification %{HTTPS} off sera toujours vraie du point de vue du serveur, causant la boucle décrite à l'Étape 3. La vraie correction est le changement de mode SSL Cloudflare, pas la règle .htaccess.

 

Si votre .htaccess est devenu complexe ou contient des règles que vous ne pouvez pas retracer, l'approche la plus sûre est de le renommer temporairement en .htaccess.bak, ce qui le désactive effectivement, et de tester si la boucle se résout. Si c'est le cas, reconstruisez le fichier depuis zéro avec seulement les règles dont vous avez réellement besoin.

 

Étape 5 : Vérifier les paramètres d'URL WordPress

 

Si votre site utilise WordPress, les paramètres Adresse WordPress et Adresse du site dans le tableau de bord d'administration génèrent des redirections quand ils ne correspondent pas à l'URL que les visiteurs utilisent réellement. Ces paramètres se trouvent dans Réglages puis Général.

 

L'Adresse WordPress est l'URL où les fichiers principaux WordPress sont installés. L'Adresse du site est l'URL que les visiteurs utilisent pour accéder au site. Les deux doivent utiliser le bon protocole et correspondre exactement à votre domaine. Si l'Adresse WordPress est définie sur http://votredomaine.com pendant que votre serveur sert le site en HTTPS, WordPress générera une redirection de HTTPS vers HTTP pour correspondre à ses propres paramètres. Si une règle différente redirige simultanément de HTTP vers HTTPS, la boucle est complète.

 

Mettez à jour les deux champs pour utiliser https:// si votre site est en HTTPS. Sauvegardez et testez. Si vous ne pouvez pas accéder à l'administration WordPress parce que la boucle vous empêche de vous connecter, vous pouvez mettre à jour ces valeurs directement dans la base de données en utilisant phpMyAdmin. Dans la table wp_options, trouvez les lignes avec les valeurs option_name siteurl et home, et modifiez l'option_value avec l'URL HTTPS correcte.

 

Alternativement, vous pouvez définir ces valeurs directement dans wp-config.php en ajoutant ces lignes avant le commentaire qui dit "C'est tout, arrêtez l'édition !" :

 

define('WP_HOME', 'https://votredomaine.com');
define('WP_SITEURL', 'https://votredomaine.com');

Ces constantes remplacent les valeurs de la base de données et prennent effet immédiatement sans avoir besoin d'accéder au tableau de bord d'administration.

 

Étape 6 : Vérifier les plugins de redirection et les paramètres de plateforme

 

Si vous avez un plugin de gestion des redirections installé, vérifiez s'il contient des règles qui créent un cycle. Des plugins comme Redirection ou le gestionnaire de redirections de Yoast SEO peuvent générer des conflits avec les redirections au niveau serveur dans .htaccess, en particulier si les deux essaient d'imposer simultanément la même redirection HTTPS ou www canonique.

 

Désactiver temporairement tous les plugins et tester si la boucle se résout est la façon la plus rapide de confirmer si un plugin est impliqué. Si la boucle disparaît après la désactivation, réactivez les plugins un par un et testez après chacun jusqu'à ce que la boucle revienne. Le dernier plugin activé avant que la boucle réapparaisse est probablement la source.

 

Pour les sites WooCommerce ou les sites utilisant un proxy inverse ou un équilibreur de charge devant le serveur web, les en-têtes HTTP_X_FORWARDED_PROTO peuvent affecter la façon dont le serveur détecte si une requête est HTTP ou HTTPS. Si le serveur n'interprète pas correctement ces en-têtes, il peut traiter les requêtes HTTPS comme HTTP et les rediriger, créant une boucle. C'est un scénario moins courant mais qui mérite investigation si les autres étapes ne résolvent pas le problème.

 

Confirmer la correction

 

Après avoir apporté des modifications, testez votre site depuis une fenêtre incognito fraîche pour confirmer que la boucle est entièrement résolue. Utilisez un vérificateur de redirections en ligne comme httpstatus.io ou redirect-checker.org pour tracer la chaîne complète de redirections et confirmer qu'elle se résout vers un seul statut 200 OK plutôt qu'une chaîne de 301.

 

Confirmez également que vos redirections prévues fonctionnent toujours correctement. Si vous dépendez de la canonicalisation de www vers non-www ou de la redirection HTTP vers HTTPS, vérifiez que celles-ci redirigent toujours comme prévu plutôt que de produire des erreurs après vos modifications.

 

Si vous avez apporté des modifications au mode SSL Cloudflare, attendez quelques minutes pour que le changement se propage sur le réseau périphérique de Cloudflare avant de tester.

 

Gérer les redirections via WHMCS

 

Si votre hébergement est géré via notre portail client, vous pouvez accéder à cPanel directement depuis votre compte WHMCS pour modifier votre fichier .htaccess via le Gestionnaire de fichiers ou pour vérifier le statut SSL/TLS. Accédez à Mes services, cliquez sur votre forfait d'hébergement, et utilisez le lien de connexion cPanel dans les détails du service.

 

Si vous ne pouvez pas accéder à votre site en raison de la boucle de redirection et rencontrez des difficultés à diagnostiquer la cause, ouvrez un ticket de support depuis votre espace client WHMCS avec votre nom de domaine, une description de quand le problème a commencé, et tout changement récent que vous avez apporté à vos paramètres Cloudflare, .htaccess, ou la configuration WordPress. Notre équipe peut examiner les journaux au niveau serveur et votre configuration de redirection actuelle pour identifier la source de la boucle.

Gotekky

Besoin d’aide pour choisir la prochaine étape?

Décrivez ce que vous observez et le résultat recherché. Nous identifierons si un service géré, un projet défini ou une évaluation technique payante est la bonne prochaine étape.