Comment rediriger HTTP vers HTTPS dans WordPress

Faire passer votre site WordPress de HTTP à HTTPS n'est plus optionnel. Les navigateurs signalent les sites HTTP comme « Non sécurisés », Google utilise HTTPS comme signal de classement, et les données de vos visiteurs sont transmises en clair sans chiffrement. Après avoir installé un certificat SSL, vous devez correctement rediriger tout le trafic HTTP vers HTTPS et résoudre les éventuels problèmes de contenu mixte. Ce guide couvre chaque étape du processus, de l'obtention d'un certificat au débogage des boucles de redirection derrière des équilibreurs de charge.

Pourquoi HTTPS est important au-delà de la sécurité de base

La raison évidente de HTTPS est le chiffrement. Sans lui, tout ce qui transite entre le navigateur de votre visiteur et votre serveur (envois de formulaires, identifiants de connexion, cookies, données personnelles) peut être intercepté par n'importe qui sur le même réseau. Mais HTTPS est important pour plusieurs autres raisons qui affectent directement le succès de votre site :

• Facteur de classement SEO : Google a confirmé en août 2014 que HTTPS est un signal de classement. Bien qu'il s'agisse d'un signal léger, toutes choses égales par ailleurs, la version HTTPS d'une page sera mieux classée que la version HTTP. Dans les niches concurrentielles, chaque signal compte.
• Avertissements du navigateur : Chrome, Firefox, Safari et Edge affichent tous des avertissements « Non sécurisé » pour les pages HTTP, en particulier celles avec des champs de formulaire. Cela érode la confiance des visiteurs et augmente les taux de rebond. Chrome a progressivement rendu ces avertissements plus visibles depuis Chrome 68 (juillet 2018).
• Support de HTTP/2 et HTTP/3 : les protocoles modernes comme HTTP/2 et HTTP/3, qui améliorent considérablement la vitesse de chargement des pages grâce au multiplexage et à la compression des en-têtes, nécessitent HTTPS en pratique. Tous les principaux navigateurs ne prennent en charge HTTP/2 que via TLS.
• Données de référent : lorsqu'un visiteur clique sur un lien d'une page HTTPS vers une page HTTP, le navigateur supprime l'en-tête de référent. Cela signifie que vous perdez les données analytiques sur la provenance de votre trafic. Si votre site est en HTTPS, vous préservez les données de référent provenant d'autres sites HTTPS.
• Service Workers et PWA : les fonctionnalités Progressive Web App comme la mise en cache hors ligne, les notifications push et l'invite « Ajouter à l'écran d'accueil » nécessitent HTTPS.

Obtenir un certificat SSL gratuit avec Let's Encrypt

Vous n'avez pas besoin de payer pour un certificat SSL. Let's Encrypt fournit des certificats gratuits, automatisés et validés par domaine (DV) qui sont approuvés par tous les principaux navigateurs. La plupart des hébergeurs ont intégré Let's Encrypt dans leurs panneaux de contrôle, mais si vous gérez votre propre serveur, voici comment le configurer avec Certbot :

# Installer Certbot sur Ubuntu/Debian
sudo apt update
sudo apt install certbot

# Pour Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Pour Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot configurera automatiquement votre serveur web pour utiliser le certificat et mettra en place une tâche cron pour le renouvellement automatique. Les certificats Let's Encrypt sont valables 90 jours, mais le processus de renouvellement automatique gère cela de manière transparente. Pour vérifier que le renouvellement automatique fonctionne :

# Tester le processus de renouvellement (ne renouvelle pas réellement)
sudo certbot renew --dry-run

# Vérifier la minuterie de renouvellement
sudo systemctl status certbot.timer

Si votre hébergeur propose un SSL en un clic via son panneau de contrôle (SiteGround, Bluehost, HostGator, etc.), utilisez plutôt celui-ci. C'est le même certificat Let's Encrypt mais géré par votre hôte, ce qui signifie une chose de moins à maintenir.

Étape 1 : mettre à jour les URL WordPress

Avant de configurer les redirections, indiquez à WordPress que votre site utilise désormais HTTPS. Allez dans Réglages > Général et mettez à jour les deux champs :

• Adresse web de WordPress (URL) : changez http://example.com en https://example.com
• Adresse web du site (URL) : changez http://example.com en https://example.com

Si vous ne pouvez pas accéder au tableau de bord d'administration (par exemple, si vous êtes déjà bloqué dans une boucle de redirection), vous pouvez définir ces valeurs directement dans wp-config.php :

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

Ou mettez à jour la base de données directement via WP-CLI :

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Étape 2 : redirection HTTP vers HTTPS au niveau du serveur

La redirection doit avoir lieu au niveau du serveur (et non en PHP) pour deux raisons : c'est plus rapide car cela ne nécessite pas le chargement de WordPress, et cela garantit que toutes les requêtes (y compris les fichiers statiques, les images et les appels d'API) sont redirigées, pas seulement les URL gérées par WordPress.

Apache (.htaccess)

Ajoutez ceci tout en haut de votre fichier .htaccess, avant les règles de réécriture WordPress (avant le commentaire # BEGIN WordPress) :

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

Le drapeau R=301 envoie une redirection permanente, ce qui indique aux moteurs de recherche de mettre à jour leur index vers la version HTTPS. N'utilisez pas R=302 (redirection temporaire) car les moteurs de recherche ne transféreront pas l'équité des liens vers la nouvelle URL.

Nginx

Dans votre configuration Nginx, créez un bloc server distinct pour HTTP qui redirige tout vers HTTPS :

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... reste de votre configuration
}

Utiliser return 301 dans Nginx est plus efficace que d'utiliser rewrite car cela ne nécessite pas de traitement regex.

Étape 3 : forcer HTTPS dans wp-config.php

Ajoutez ces lignes à votre fichier wp-config.php, au-dessus du commentaire « That's all, stop editing! » :

// Forcer SSL pour la zone d'administration WordPress
define('FORCE_SSL_ADMIN', true);

// Gérer SSL derrière un proxy inverse ou un équilibreur de charge
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

La constante FORCE_SSL_ADMIN garantit que la page de connexion WordPress et le tableau de bord d'administration utilisent toujours HTTPS, même si quelqu'un essaie d'y accéder directement via HTTP.

Corriger les boucles de redirection derrière les équilibreurs de charge et les proxys inverses

C'est l'un des problèmes les plus courants avec les configurations HTTPS de WordPress, et il piège beaucoup de monde. Si votre site est derrière un équilibreur de charge, Cloudflare, un proxy inverse ou un CDN, la connexion entre le proxy et votre serveur est souvent en HTTP simple, même si la connexion entre le visiteur et le proxy est en HTTPS. Votre serveur voit une requête HTTP et tente de rediriger vers HTTPS, le proxy renvoie la requête en HTTP, et vous vous retrouvez dans une boucle de redirection infinie. Le navigateur affiche « ERR_TOO_MANY_REDIRECTS ».

La solution est la vérification de l'en-tête X-Forwarded-Proto montrée ci-dessus. Le proxy ajoute cet en-tête pour indiquer à votre serveur quel protocole la requête originale a utilisé. Lorsque WordPress voit que le protocole transféré est HTTPS, il traite la connexion comme sécurisée et ne déclenche pas de redirection.

Si la vérification d'en-tête standard ne fonctionne pas, votre proxy peut utiliser un en-tête différent. Vérifiez auprès de votre hébergeur. Les variantes courantes incluent :

// Pour certains équilibreurs de charge utilisant X-Forwarded-Ssl
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
    $_SERVER['HTTPS'] = 'on';
}

// Pour Cloudflare (qui définit aussi X-Forwarded-Proto, mais juste au cas où)
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
    $visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
    if (isset($visitor->scheme) && $visitor->scheme === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
}

Étape 4 : remplacer les URL HTTP dans la base de données

Votre base de données WordPress contient des URL HTTP codées en dur dans le contenu des articles, les paramètres des widgets, les options de thème et les données sérialisées. Vous devez toutes les remplacer par des versions HTTPS. Le meilleur outil pour cela est la commande search-replace de WP-CLI :

# D'abord, faites un essai à blanc pour voir ce qui changerait
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Si l'essai à blanc semble correct, exécutez le remplacement réel
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Gérez aussi les variations www/non-www le cas échéant
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

Le drapeau --dry-run est important. Il vous montre exactement combien de remplacements seront effectués dans chaque table sans rien modifier réellement. Examinez la sortie avant d'exécuter le remplacement réel. Le drapeau --all-tables garantit que les tables personnalisées (provenant d'extensions comme WooCommerce, ACF ou les constructeurs de pages) sont incluses.

WP-CLI gère correctement les données sérialisées, ce qui est essentiel. Si vous essayez d'effectuer un simple find-and-replace SQL, vous casserez les tableaux sérialisés car les valeurs de longueur de chaîne ne correspondront plus. N'exécutez jamais une requête SQL REPLACE() brute à cette fin.

Corriger les problèmes de contenu mixte

Le contenu mixte se produit lorsque votre page HTTPS charge des ressources (images, scripts, feuilles de style, iframes) via HTTP. Les navigateurs bloquent entièrement le contenu actif mixte (scripts, feuilles de style) et peuvent avertir à propos du contenu passif mixte (images). Cela entraîne des fonctionnalités cassées ou des icônes d'avertissement jaunes dans la barre d'adresse.

Pour trouver les problèmes de contenu mixte :

1. Console du navigateur : ouvrez les DevTools (F12) et regardez l'onglet Console. Les avertissements de contenu mixte apparaissent sous forme de messages jaunes ou rouges listant les URL exactes des ressources problématiques.
2. InspectWP : lancez une analyse et consultez la section HTML. InspectWP détecte les ressources non sécurisées (HTTP) chargées sur les pages HTTPS et les répertorie une par une.
3. Why No Padlock : le site whynopadlock.com analyse votre page et signale toutes les ressources de contenu mixte avec leurs URL source.

Sources courantes de contenu mixte et comment les corriger :

• URL codées en dur dans les fichiers de thème : recherchez les références http:// dans les fichiers PHP et CSS de votre thème. Remplacez-les par https:// ou mieux encore, utilisez des URL relatives au protocole (//) ou des fonctions WordPress comme esc_url().
• Images dans le contenu des articles : la commande search-replace de WP-CLI (étape 4) gère la plupart d'entre elles. Pour les cas tenaces, vérifiez le HTML brut dans l'éditeur de texte.
• Widgets et paramètres du Customizer : les URL d'images dans les widgets, les en-têtes personnalisés et les paramètres du Customizer sont stockées sous forme de données sérialisées. WP-CLI search-replace les gère correctement.
• Contenu de constructeur de pages : Elementor, Beaver Builder, Divi et d'autres constructeurs de pages stockent leur contenu dans des formats personnalisés. WP-CLI avec --all-tables les attrape généralement, mais vérifiez en chargeant les pages construites avec votre constructeur de pages.
• Ressources externes : si vous chargez des polices, des scripts ou des images depuis des domaines externes via HTTP, mettez à jour ces URL. La plupart des CDN et services de polices (Google Fonts, cdnjs, etc.) prennent en charge HTTPS.

Utiliser Really Simple SSL comme alternative

Si l'approche manuelle vous semble écrasante, l'extension Really Simple SSL automatise la majeure partie du processus. Installez-la, activez-la, et elle :

• Détectera automatiquement votre certificat SSL.
• Mettra à jour l'URL du site WordPress et l'URL d'accueil vers HTTPS.
• Mettra en place une redirection 301 de HTTP vers HTTPS via PHP (ou .htaccess si possible).
• Corrigera le contenu mixte en remplaçant les URL HTTP à la volée.

L'inconvénient de Really Simple SSL est qu'elle corrige le contenu mixte dynamiquement à chaque chargement de page, ce qui ajoute une légère surcharge de traitement. Il est préférable de corriger les causes profondes (URL de la base de données, références codées en dur) puis de supprimer l'extension. Considérez-la comme un pont utile lors de la migration, pas comme une solution permanente.

Étape 5 : ajouter l'en-tête HSTS

HTTP Strict Transport Security (HSTS) indique aux navigateurs d'utiliser toujours HTTPS pour votre domaine, même si l'utilisateur tape http:// dans la barre d'adresse. Après avoir confirmé que HTTPS fonctionne correctement sur votre site (pas de contenu mixte, pas de boucles de redirection), ajoutez l'en-tête HSTS :

Apache (.htaccess)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

La valeur max-age=31536000 (un an) indique aux navigateurs de mémoriser la politique HSTS pendant 12 mois. Commencez par une valeur plus courte comme max-age=86400 (un jour) pendant les tests, puis augmentez-la une fois que vous êtes sûr que tout fonctionne. La directive includeSubDomains étend la politique à tous les sous-domaines. N'ajoutez preload que si vous prévoyez de soumettre votre domaine à la liste de préchargement HSTS (hstspreload.org), qui code en dur l'exigence HTTPS de votre domaine dans les navigateurs eux-mêmes.

Configuration HTTPS pour CDN et Cloudflare

Si vous utilisez Cloudflare ou un autre CDN, la configuration HTTPS comporte une couche de complexité supplémentaire :

• Cloudflare Flexible SSL : le trafic est chiffré entre le visiteur et Cloudflare, mais la connexion entre Cloudflare et votre serveur est en HTTP simple. C'est le plus facile à mettre en place (aucun certificat SSL nécessaire sur votre serveur) mais offre une sécurité incomplète. Les données entre Cloudflare et votre serveur ne sont pas chiffrées.
• Cloudflare Full SSL : le trafic est chiffré des deux côtés, mais Cloudflare ne vérifie pas le certificat de votre serveur. Vous avez besoin d'un certificat SSL sur votre serveur, mais il peut être auto-signé.
• Cloudflare Full (Strict) SSL : le réglage recommandé. Le trafic est chiffré des deux côtés et Cloudflare vérifie le certificat de votre serveur. Utilisez un certificat Let's Encrypt valide ou un Cloudflare Origin Certificate.

Si vous passez de Flexible à Full (Strict), assurez-vous d'abord que votre serveur dispose d'un certificat SSL valide installé. Sinon, votre site sera hors ligne car Cloudflare ne peut pas établir de connexion sécurisée à votre serveur.

Cloudflare propose également « Always Use HTTPS » sous SSL/TLS > Edge Certificates, qui effectue la redirection HTTP vers HTTPS à la périphérie de Cloudflare. C'est plus rapide qu'une redirection sur votre serveur d'origine car le visiteur n'atteint jamais votre serveur pour la requête HTTP.

Vérifier l'expiration du certificat SSL et le renouvellement automatique

Un certificat SSL expiré est pire que pas de certificat du tout. Les navigateurs affichent un avertissement plein écran que la plupart des visiteurs ne traverseront pas, et votre site est effectivement hors ligne. Voici comment surveiller votre certificat :

# Vérifier la date d'expiration du certificat
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Vérifier les jours jusqu'à l'expiration
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Si vous utilisez Let's Encrypt avec Certbot, le renouvellement automatique devrait être configuré automatiquement. Mais vérifiez qu'il fonctionne réellement en consultant les journaux de renouvellement de Certbot :

# Vérifier le journal de renouvellement de Certbot
cat /var/log/letsencrypt/letsencrypt.log | tail -20

# Lister tous les certificats et leurs dates d'expiration
sudo certbot certificates

Pour les sites de production, mettez en place une surveillance qui vous alerte lorsque votre certificat approche de l'expiration. Des services comme UptimeRobot, StatusCake ou même une simple tâche cron qui vérifie la date du certificat peuvent vous éviter une indisponibilité inattendue.

Vérifiez votre configuration HTTPS avec InspectWP

Après avoir terminé la migration, lancez une analyse InspectWP pour vérifier que tout fonctionne correctement. InspectWP vérifie plusieurs aspects liés à HTTPS :

• Détection SSL/TLS : confirme que votre site est servi via HTTPS.
• Contenu mixte : détecte toute ressource HTTP (images, scripts, feuilles de style) chargée sur vos pages HTTPS.
• En-tête HSTS : vérifie que l'en-tête Strict-Transport-Security est présent et correctement configuré.
• Redirection HTTP : vérifie si la version HTTP de votre site redirige correctement vers HTTPS.
• En-têtes de sécurité : examine les autres en-têtes liés à la sécurité qui complètent votre configuration HTTPS.

Si InspectWP signale des avertissements de contenu mixte, utilisez la console du navigateur pour identifier les ressources spécifiques et corrigez-les en utilisant les méthodes décrites ci-dessus. Lancez une autre analyse après chaque correction jusqu'à ce que le rapport revienne propre.