Redirection HTTP vers HTTPS : comment la corriger

Votre site reste en HTTP ou multiplie les redirections HTTPS? Voici comment corriger les réglages Cloudflare, Apache, Nginx et LiteSpeed.

Pourquoi corriger ce problème?

Une adresse comme http://mon-site.example/page devrait rediriger vers son adresse définitive en HTTPS. Si elle reste en HTTP, la connexion n’est pas chiffrée. Si elle passe par plusieurs adresses, la navigation ralentit et les moteurs de recherche doivent suivre davantage d’étapes.

Objectif : une adresse HTTPS qui répond normalement (HTTP 200), et des anciennes variantes qui y aboutissent avec un seul code 301 ou 308 lorsque c’est possible.

Avant de changer la configuration

1. Vérifiez qu’un certificat TLS fonctionne pour le domaine, et pour www si ce sous-domaine est utilisé.
2. Identifiez où sont gérées les redirections : Cloudflare, hébergeur, Apache, Nginx ou WordPress.
3. Sauvegardez la configuration et prévoyez un retour arrière. Ne cumulez pas des règles concurrentes.

Solution Cloudflare

Always Use HTTPS (SSL/TLS → Edge Certificates) est l’option la plus connue, mais elle ajoute souvent un saut quand le site change aussi de nom d’hôte. En pratique, elle s’applique avant vos règles : http://www.mon-site.example passe d’abord par https://www.mon-site.example, puis seulement vers https://mon-site.example. Ça fait deux redirections au lieu d’une.

Elle suffit si toutes les variantes arrivent déjà à la bonne adresse sans autre changement. Sinon, confiez tout à des Redirect Rules (Rules → Redirect Rules), qui font le changement de protocole et de nom d’hôte en un seul saut. Exemple pour la destination https://mon-site.example :

Règle 1 — domaine principal (en premier) :

• Condition (Expression Editor) : (http.host eq "www.mon-site.example") or (http.host eq "mon-site.example" and not ssl)
• Destination dynamique : concat("https://mon-site.example", http.request.uri.path)
• Code : 301
• Preserve query string : activé.

Règle 2 — les autres sous-domaines en HTTP (facultative, en dernier) : elle remplace Always Use HTTPS pour le reste de la zone.

• Condition : (not ssl)
• Destination dynamique : concat("https://", http.host, http.request.uri.path)
• Code : 301
• Preserve query string : activé.

Une redirection arrête l’évaluation des règles suivantes : l’ordre compte. Procédez dans cet ordre pour ne jamais laisser le site sans HTTPS :

1. créez et activez les deux règles;
2. désactivez Always Use HTTPS;
3. vérifiez le résultat dans Redirect Audit : chaque variante doit arriver en une seule 301.

Les hôtes doivent être proxifiés par Cloudflare (nuage orange) pour que les Redirect Rules s’appliquent. Si la redirection est déjà faite dans un Worker, modifiez plutôt le Worker au lieu d’empiler deux couches de redirection.

Attention : le mode SSL/TLS « Flexible » peut provoquer une boucle lorsque le serveur d’origine force lui aussi HTTPS. Si possible, utilisez « Full (strict) » avec un certificat valide sur le serveur d’origine.

Solution Apache

Si vous gérez un VirtualHost dédié au port 80, Apache recommande une redirection permanente :

<VirtualHost *:80>
    ServerName mon-site.example
    ServerAlias www.mon-site.example
    Redirect permanent / https://mon-site.example/
</VirtualHost>

Le VirtualHost HTTPS doit être configuré séparément. Si vous n’avez accès qu’au fichier .htaccess, et que le serveur sait directement si la connexion est en HTTPS, vous pouvez combiner le changement de protocole et de nom d’hôte :

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^mon-site\.example$ [NC]
RewriteRule ^ https://mon-site.example%{REQUEST_URI} [R=301,L]

Placez ces règles avant celles de WordPress et adaptez-les à votre environnement. Derrière un proxy ou un CDN, %{HTTPS} peut ne pas refléter le protocole utilisé par le visiteur.

Solution Nginx

Dans le bloc server du port 80, redirigez directement :

server {
    listen 80;
    server_name mon-site.example www.mon-site.example;
    return 301 https://mon-site.example$request_uri;
}

Prévoyez aussi un bloc HTTPS pour www.mon-site.example s’il doit être redirigé : il lui faut un certificat valide pour ce nom. Gardez un bloc HTTPS distinct qui sert réellement mon-site.example. Avant d’appliquer, lancez nginx -t, puis rechargez Nginx.

Solution LiteSpeed / OpenLiteSpeed

LiteSpeed accepte la plupart des règles de réécriture de type Apache. Si vous utilisez .htaccess, vérifiez que la lecture de ce fichier et la réécriture sont activées. Avec OpenLiteSpeed, ces options doivent être activées explicitement, et un redémarrage peut être nécessaire après une modification.

Vérifier le résultat

Testez la racine du domaine et une page interne, par exemple /produits/?ref=test, pour vérifier que le chemin et les paramètres sont conservés. Dans Redirect Audit, la destination finale doit être en HTTPS et les variantes du domaine doivent converger vers la même adresse.

Ces exemples sont un point de départ : adaptez-les à votre configuration et testez-les avant de les appliquer à un site en production.