Basculer un site WordPress en HTTPS paraît simple, jusqu’au moment où on https://gardewp.fr/securite-wordpress/ voit des images en HTTP, des scripts bloqués, une page d’accueil qui se met à boucler, ou le formulaire de connexion qui échoue en silence. Forcer HTTPS, c’est à la fois une mesure de sécurité et un chantier de compatibilité. L’objectif, c’est de renforcer la sécurité WordPress sans dégrader l’expérience, ni casser le routage, ni provoquer des effets de bord sur le cache et les formulaires.
Je l’ai vu dans des migrations “rapides” où tout semblait correct côté navigateur, puis où un plugin tiers (ou un widget) chargait encore une ressource en HTTP. Résultat: contenu “mixte”, cookies jugés non sûrs selon la configuration, et parfois des erreurs aléatoires sur les pages sensibles. À l’inverse, une approche trop prudente peut laisser des pages accessibles encore en HTTP, ce qui réduit l’intérêt de la bascule.
Le bon compromis, c’est une stratégie en couches: vérifier que le serveur parle bien HTTPS, forcer les redirections proprement, corriger les URL internes, traiter les cas particuliers (reverse proxy, multisite, cache), puis vérifier que l’administration et les performances ne prennent pas un coup.
HTTPS, sécurité et vraie valeur opérationnelle
Le HTTPS ne remplace pas les mises à jour de WordPress, ni le durcissement des droits, ni une bonne hygiène de mots de passe. Mais il ferme un canal très concret: la plupart des attaques les plus simples visent la session et le contenu transitant entre le navigateur et le serveur. Avec HTTPS, les échanges sont chiffrés, ce qui limite l’interception et la manipulation.
Au niveau applicatif, forcer HTTPS réduit aussi les confusions de cookies. Beaucoup de problèmes “ça marchait hier” viennent d’un cookie de session marqué pour un contexte non sécurisé, ou d’un serveur qui reçoit une requête “tombée” en HTTP à cause d’un proxy ou d’une règle incomplète. Quand tout passe en HTTPS, ces angles morts se ferment.
Il y a une différence importante entre “avoir un certificat” et “forcer réellement l’ensemble du site à utiliser HTTPS”. On peut très bien servir des pages en HTTPS, tout en gardant des liens internes, des redirections partielles, ou des endpoints d’administration qui répondent encore en HTTP. C’est là que la sécurité devient plus “théorique”.
Avant de toucher aux redirections: trois diagnostics qui évitent 80% des bugs
Avant de modifier quoi que ce soit dans .htaccess, Nginx ou les réglages de WordPress, je commence par des vérifications très concrètes. Le but est de comprendre d’où viennent les requêtes et comment le serveur interprète le “schéma” (http ou https).
1) Le navigateur affiche-t-il vraiment un cadenas stable sur toutes les pages ? Pas seulement l’accueil. Je teste pages publiques, une page avec un formulaire, et une page d’administration.
2) Est-ce qu’un reverse proxy ou un CDN est impliqué ? Cloudflare, un load balancer, un proxy applicatif, ou même un plugin de cache côté hébergeur peuvent changer les en-têtes reçus par WordPress. Si WordPress ne lit pas “X-Forwarded-Proto”, il peut croire que la requête est en HTTP alors qu’elle est envoyée en HTTPS au navigateur.
3) Qu’est-ce que cache et redirections ont déjà modifié ? Certains hébergeurs activent déjà des redirections HTTPS. D’autres laissent des règles qui se contredisent. Quand on ajoute une règle de redirection à côté de celle existante, on obtient des boucles, surtout si la règle est asymétrique (par exemple, elle force un sous-domaine mais pas le domaine racine).
Ces diagnostics donnent le fil rouge pour le reste. Ils déterminent surtout où appliquer la force HTTPS: côté serveur, côté application WordPress, ou via des en-têtes proxy.
Déterminer le point de contrôle: serveur, WordPress, ou deux à la fois
Dans un système “classique” (aucun proxy), forcer HTTPS au niveau serveur est généralement le plus fiable. WordPress n’a pas besoin de gérer les redirections globales si le serveur le fait correctement.
Dans un système avec proxy (CDN, load balancer), c’est souvent l’en-tête qui fait foi. Le serveur frontal redirige vers HTTPS pour le client, mais WordPress peut encore recevoir des requêtes “http” si le proxy ne transmet pas correctement le schéma. Dans ce cas, la redirection côté WordPress peut être utile, mais il faut d’abord que WordPress comprenne le bon protocole.
Enfin, il y a la zone “contenu”. Même avec une redirection parfaite, il peut rester des ressources en HTTP dans la base WordPress: images, styles, scripts, champs d’URL dans des paramètres de plugins. Ce n’est pas une question de redirection, mais de cohérence des URLs.
Forcer HTTPS sur Apache avec soin (cas .htaccess)
Si votre site utilise Apache et que vous avez accès à la racine WordPress, .htaccess est souvent l’endroit où appliquer une règle de redirection vers HTTPS. L’approche la plus sûre dépend de la structure, par exemple la présence de sous-dossiers, de réécritures déjà en place, et le fait d’être derrière un proxy.
Je recommande une règle qui ne redirige pas inutilement et qui évite les boucles. En pratique, la logique recherchée est simple: si la requête actuelle n’est pas en HTTPS, alors on la redirige vers la même URL en HTTPS, en conservant la requête et le chemin.
À ce stade, le risque principal n’est pas la redirection elle-même, c’est le conflit avec d’autres règles déjà actives. Si vous avez un plugin de sécurité ou un mécanisme hébergeur qui modifie déjà .htaccess, vous pouvez créer une alternance HTTP vers HTTPS, puis l’inverse, selon la façon dont le serveur interprète les requêtes.
Un autre piège, plus discret: certains serveurs répondent en HTTPS mais la variable utilisée pour détecter le schéma ne reflète pas la réalité si un proxy intervient. La redirection basée sur des variables “internes” peut être fausse. Dans un contexte proxy, mieux vaut aligner d’abord la configuration pour que WordPress reçoive le schéma correct, puis ne garder qu’une redirection minimale.
Forcer HTTPS sur Nginx: privilégier la redirection serveur
Sur Nginx, la logique est généralement propre: on redirige en amont, dans le bloc serveur qui reçoit les requêtes sur le port 80. Comme Nginx est souvent “front” sur la couche réseau, c’est généralement l’endroit le plus robuste pour forcer HTTPS.
Le point délicat revient souvent au même: si vous êtes derrière un proxy et que vous recevez des requêtes déjà “terminées TLS” (TLS au niveau proxy), vous devez vous assurer que les en-têtes et la config Nginx reflètent correctement le schéma. Sinon, vous pouvez rediriger trop tôt ou vous tromper sur l’URL canonique.
WordPress et le protocole: wp-config, en-têtes proxy, et cohérence interne
Même quand la redirection fonctionne, WordPress peut générer des liens en HTTP si ses “valeurs de contexte” sont mal calibrées. La zone de tension, c’est souvent la façon dont WordPress détermine l’URL complète de votre site.
Dans WordPress, certaines décisions passent par siteurl et home. Vous pouvez les vérifier dans les réglages WordPress (et parfois via la base de données si vous avez dû réparer après une migration). Si ces champs pointent en HTTP, WordPress peut continuer à produire des liens en HTTP même si le navigateur vous renvoie vers HTTPS.
Ensuite, en contexte proxy, WordPress doit comprendre que la requête externe est en HTTPS. Si un proxy met des en-têtes comme X-Forwarded-Proto, WordPress (ou un plugin) doit les interpréter. Sinon, vous obtenez souvent des symptômes typiques: boucles de redirection en connexion, formulaires qui renvoient vers http:// au lieu de https://, et des cookies qui semblent “perdus”.
Un détail que j’ai vu plus d’une fois: certains plugins de cache ou de sécurité normalisent l’URL, mais ne gèrent pas correctement les cas où le protocole détecté diffère du protocole réel. Par exemple, un mécanisme qui force HTTPS peut être activé deux fois: une fois via serveur, une fois via WordPress, mais avec des détections incohérentes. Le résultat est un ping-pong de redirection.
Mets à jour les URL internes, sinon tu auras du “mixte” qui contamine tout
Le navigateur peut afficher une page en HTTPS mais bloquer des ressources en HTTP. On voit alors des images qui ne se chargent pas, des polices qui sautent, ou des scripts qui ne s’exécutent pas. Ce n’est pas seulement esthétique: certains plugins s’appuient sur des scripts pour la validation de formulaires ou la synchronisation de contenus.
En pratique, il faut traiter la base et le thème. L’idée n’est pas de “tout réécrire à la main”, mais de s’assurer que les URL internes reflètent HTTPS.
Deux approches coexistent:
- Corriger directement les paramètres de site et, si nécessaire, les occurrences d’URL en base (dans options, et parfois dans les contenus ou métadonnées de plugins). Corriger au plus près des sources, par exemple les paramètres dans l’interface de certains plugins (URL de API, endpoints, webhooks).
J’insiste sur un point: faire un changement d’URL en masse sans sauvegarde, sans plan de restauration et sans tester les pages qui utilisent des médias, c’est là qu’on casse des choses. Les champs d’URL ne sont pas toujours utilisés comme on l’imagine, et des plugins stockent parfois des chemins ou des fragments qui se comparent de manière stricte.
Si vous devez faire une conversion des URLs en base, faites-le en gardant un œil sur le multisite, sur les contenus “en dur” dans des widgets, et sur les plugins qui stockent leurs URLs dans des options sérialisées.
Gestion des redirections: éviter les boucles et respecter les endpoints sensibles
Quand on force HTTPS, la redirection ne doit pas provoquer de boucles. Une boucle se produit souvent quand:
- la règle redirige une URL vers la même URL, mais avec un protocole ou un hôte différent, WordPress croit qu’il faut rediriger parce que son contexte est en HTTP, et le serveur redirige à nouveau de l’autre sens.
Les endpoints d’administration sont particulièrement sensibles. Même une redirection qui semble “fonctionner” sur des pages publiques peut échouer sur wp-login.php ou sur des pages qui déclenchent des requêtes POST. Dans ces cas, les navigateurs et le client de WordPress peuvent réagir différemment à une série de 301 et 302.
Je me base sur un principe empirique: sur une bascule, la redirection doit être déterministe. Si la logique dépend d’une variable qui peut varier selon le chemin ou les en-têtes, on s’expose à des comportements imprévisibles.
C’est pour cela que je privilégie une stratégie où une seule couche décide vraiment de la redirection globale, et où l’autre couche se contente de refléter la cohérence des URLs.
Cas particuliers qui demandent un jugement pratique
Il y a des configurations où “forcer HTTPS” n’est pas une commande unique, mais une suite de corrections ciblées.
Multisite
En multisite, les champs home et siteurl peuvent diverger par site. Forcer HTTPS sur l’ensemble peut exiger des réglages plus larges, et parfois des transformations dans des tables supplémentaires. Si vous basculez sans vérifier chaque site du réseau, vous pouvez vous retrouver avec un sous-site en HTTPS et un autre encore en HTTP, ou des redirections qui ne s’alignent pas.
sous-dossiers et réécritures
Si WordPress est installé dans un sous-dossier (par exemple example.com/wordpress), les règles de redirection doivent conserver correctement le préfixe de chemin. Une règle trop agressive peut oublier le préfixe et rediriger vers un endpoint inexistant.
Plugins de cache et minification
Certains plugins génèrent des URLs de ressources, ou servent des fichiers via des endpoints propres. Après force HTTPS, ils peuvent produire du contenu en HTTP dans le cache, ou continuer à référencer des assets en HTTP jusqu’à purge.
Authentification et SSO
Si vous utilisez un SSO ou des intégrations externes, la validation des redirections OAuth et des “redirect URIs” peut échouer si le protocole n’est pas cohérent. Même si WordPress “fonctionne”, vos flux d’auth peuvent ne plus revenir vers le bon domaine.
Une checklist courte avant de basculer en mode “tout HTTPS”
Avant d’activer la force HTTPS de façon irréversible, j’aime bien passer par une courte vérification. Pas une religion, plutôt un filet de sécurité.
- Vérifier que la page d’accueil, une page typique, et la page d’administration s’affichent bien en HTTPS sans redirections répétées Contrôler l’absence de contenu mixte (images, scripts, polices) dans la console navigateur Confirmer que home et siteurl sont en https, pas en http Tester la connexion et un formulaire qui fait un POST (contact, commentaires, e-commerce si applicable) Purger ou invalider le cache applicatif si vous passez par un plugin ou un système serveur
Si une de ces étapes échoue, on corrige d’abord la cause. Une redirection “propre” ne compense pas une incohérence d’URL interne.
Étape de bascule progressive: réduire les surprises
Dans les environnements où je n’ai pas la certitude que tout est propre (hébergeur imprévisible, plugins en place, migration récente), je préfère une bascule progressive.
Une façon pragmatique de faire consiste à:
- activer d’abord HTTPS côté serveur, mais en surveillant la cohérence, vérifier les pages clés, puis renforcer la redirection pour éviter toute requête en HTTP, enfin traiter les URL internes et purger le cache.
Ce rythme évite de transformer un problème de protocole en problème de contenu, alors que la vraie cause était simplement un champ siteurl resté en http, ou un header proxy manquant.
Durcir après la bascule: ajouter ce qui complète la sécurité sans casser
Forcer HTTPS est une étape. La sécurité réelle vient d’un ensemble cohérent: mises à jour, durcissement des droits, protection contre les accès sensibles, et headers utiles.
Après la bascule, c’est le bon moment pour vérifier rapidement:
- que les connexions sont bien sécurisées partout (dont l’administration), que vos cookies de session ne régressent pas sur certains chemins, que les ressources chargées via le navigateur sont bien en HTTPS, et que vos règles de sécurité ne bloquent pas des endpoints légitimes.
Je reste prudent avec les headers “agressifs”. Par exemple, activer certaines politiques de sécurité peut casser des scripts si votre site charge des ressources externes non prévues. Une activation progressive, couplée à des tests sur pages réelles, coûte moins cher que du dépannage en production.
Erreurs typiques et comment les diagnostiquer vite
On ne s’en sort pas sans reconnaître les symptômes.
- Boucle de redirection lors de la connexion: souvent un décalage entre le protocole perçu par WordPress et le protocole réel. Cible probable: en-têtes proxy mal lus, ou home/siteurl incohérents, ou règle serveur qui se contredit. Contenu mixte malgré HTTPS: URLs internes en HTTP, ou ressources générées par un plugin qui conserve une ancienne config. Cible probable: conversions d’URL incomplètes, ou paramètres de plugins. Ressources qui ne se chargent que sur certaines pages: cache partiel, ou assets référencés différemment selon le contexte (widgets, pages builders, conditions dans le thème). Formulaires qui échouent après redirection: redirections trop nombreuses sur POST, ou règles qui transforment des endpoints. À isoler en testant sans redirect applicatif supplémentaire.
Le réflexe gagnant: regarder la chaîne de redirection dans l’inspecteur réseau, et comparer ce que WordPress pense avec ce que le navigateur fait réellement.
Restez cohérent: une règle “doit” décider, le reste doit simplement suivre
L’idée la plus utile que j’ai retenue au fil des bascules, c’est la cohérence. La force HTTPS ne devrait pas être un concours entre plusieurs composants.
Si vous forcez au niveau serveur, laissez WordPress générer les bons liens, mais évitez d’empiler des redirections supplémentaires qui peuvent diverger selon le chemin. Si vous comptez sur WordPress pour la redirection, faites en sorte que WordPress détecte correctement le protocole, surtout derrière un proxy.
C’est cette cohérence qui renforce la sécurité WordPress de façon durable, sans transformer la bascule en une longue série de micro-corrections.
Points de contrôle final (ce que je vérifie avant de dire “c’est bon”)
Quand tout est en place, je refais un tour complet, pas seulement “est-ce que l’accueil charge”.
Je vérifie aussi:
- la page de connexion et la navigation entre tableaux de bord, un parcours utilisateur complet, au moins un formulaire et un lien qui ouvre une page différente, les URLs partagées (copier-coller d’un lien vers une page interne), et la cohérence des assets (aucun chargement en http visible).
Si tout passe sans alerte, alors la bascule est réellement “propre”.
Conclusion opérationnelle sans artifices
Forcer HTTPS sans casser WordPress, c’est moins une question de “trouver la bonne règle” qu’une question d’aligner toutes les couches: serveur, protocole perçu par WordPress, URLs générées, et cache. Quand vous faites cette mise en cohérence étape par étape, la redirection devient une mesure simple, et la sécurité s’améliore sans effets de bord.
Si vous me donnez votre configuration (Apache ou Nginx, présence ou non d’un reverse proxy/CDN, installation en racine ou en sous-dossier, et si c’est du multisite), je peux vous proposer une stratégie de force HTTPS adaptée, avec les endroits exacts où appliquer la règle, et les pièges à éviter pour votre cas.