Installer un certificat et basculer WordPress en https

WordPress SSL désigne la mise en place du https sur un site WordPress : installer un certificat chez l'hébergement du nom de domaine, configurer les URL, puis rediriger en 301. Chaque étape est simple, mais un bout de code oublié ou un plugin mal réglé laisse le cadenas barré.

SSL, TLS et https : de quoi parle-t-on sur un site WordPress ?

Le SSL d'un site WordPress est, dans le langage courant, le chiffrement des échanges entre le navigateur du visiteur et la machine qui héberge le blog. Le terme est resté, mais le protocole SSL (Secure Sockets Layer) a disparu : ses dernières versions sont dépréciées depuis 2015 et les connexions modernes reposent sur TLS (Transport Layer Security), en version 1.2 ou 1.3. Quand un hébergeur parle de « certificat SSL », il délivre en réalité un certificat TLS ; les deux noms désignent la même chose dans un panneau d'administration.

Le https n'est rien d'autre que le protocole http transporté dans ce tunnel chiffré. Le certificat joue deux rôles. Il prouve au visiteur que la machine contactée correspond bien au nom de domaine tapé dans la barre d'adresse, et il fournit la clé publique qui permet de négocier le chiffrement de la session. Sans certificat valide pour ce nom, le navigateur affiche une page d'alerte et la plupart des visiteurs repartent.

WordPress, de son côté, ne chiffre rien lui-même. Le CMS se contente de construire ses liens à partir de deux adresses enregistrées dans ses réglages : si elles commencent par http://, chaque page générée contient des liens, des images et des scripts en http, même quand le serveur sait répondre en https. C'est pour cette raison qu'une installation SSL réussie touche à trois niveaux distincts : le serveur web (le certificat), l'application (les URL de WordPress) et les données (les adresses écrites dans les articles, les widgets et les options du thème).

Un exemple concret aide à fixer les idées. Sur un blog installé en 2017 sous http://www.exemple.fr, chaque image insérée dans un article porte son adresse complète en http dans la table des publications. Poser un certificat ne modifie aucune de ces lignes : il faut les réécrire, sinon le navigateur charge une page chiffrée qui appelle des ressources en clair.

Pourquoi passer un site WordPress en https en 2026

Un site WordPress encore servi en http cumule aujourd'hui trois handicaps : un message d'alerte dans le navigateur, des données de connexion qui circulent en clair et un signal défavorable pour les moteurs de recherche. Depuis Chrome 68, sorti en juillet 2018, toute page en http porte la mention « Non sécurisé » à gauche de l'adresse. L'équipe de Chrome a annoncé fin 2025 l'activation par défaut de l'option « Toujours utiliser des connexions sécurisées » avec la version 154, prévue pour octobre 2026 : Chrome demandera alors une confirmation avant d'ouvrir un site public non chiffré.

La sécurité des comptes pèse encore plus lourd. La page de connexion wp-login.php transmet l'identifiant et le mot de passe de l'administrateur ; sur un réseau Wi-Fi public, ces informations restent lisibles par n'importe quelle personne connectée au même point d'accès si le site reste en http. Les cookies de session, les formulaires de contact et les commandes d'une boutique WooCommerce suivent le même chemin. Le chiffrement protège aussi contre l'injection de publicités ou de code par un intermédiaire, une pratique documentée chez certains fournisseurs d'accès et sur des réseaux d'hôtels.

Un pirate installé sur le même réseau peut aussi glisser un script malveillant dans une page non chiffrée. Pour une petite société qui encaisse des paiements par carte bancaire, le chiffrement n'a rien de facultatif : la norme PCI DSS impose de chiffrer toute transmission de données de carte sur un réseau ouvert, et les prestataires de paiement refusent les boutiques en http.

Côté référencement, Google a fait du https un signal de classement en août 2014. Son poids reste faible face à la qualité du contenu, mais la Search Console signale les pages non sécurisées dans son rapport « Expérience sur la page », et plusieurs fonctions récentes des navigateurs (géolocalisation, notifications, service workers d'une application web progressive) exigent une origine en https. HTTP/2 et HTTP/3, qui accélèrent le chargement des pages, ne fonctionnent dans les navigateurs qu'avec une connexion chiffrée.

Le coût, enfin, ne justifie plus aucun retard : l'autorité de certification Let's Encrypt délivre des certificats gratuits depuis 2016, et la quasi-totalité des hébergeurs mutualisés français les proposent sans manipulation.

Comment obtenir un certificat SSL gratuit pour WordPress ?

Un certificat SSL gratuit pour WordPress s'obtient presque toujours depuis le panneau de l'hébergeur, grâce à Let's Encrypt ou à une autorité équivalente comme ZeroSSL ou Sectigo via AutoSSL. Chez o2switch, OVHcloud, Hostinger, Infomaniak, PlanetHoster ou LWS, l'option se trouve dans la rubrique SSL ou Sécurité du domaine : une case à cocher ou un bouton génère le certificat, l'installe et programme son renouvellement. Avant de se demander si un certificat gratuit suffit à un site professionnel, il faut savoir qu'il chiffre exactement de la même façon qu'un certificat payant ; seule la vérification de l'identité du titulaire change.

Le certificat Let's Encrypt reste valide 90 jours. Le renouvellement se fait seul chez l'hébergeur, mais un échec silencieux arrive : nom de domaine expiré, DNS déplacé vers un autre fournisseur, sous-domaine supprimé. Le CA/Browser Forum a de plus voté en avril 2025 une réduction progressive de la durée maximale des certificats publics, ramenée à 200 jours depuis mars 2026, puis à 100 jours en mars 2027 et à 47 jours en mars 2029 : le renouvellement automatique devient la seule méthode tenable, y compris pour les certificats achetés.

Quel type de certificat choisir ?

Le type de certificat se choisit selon le niveau de vérification attendu et le nombre de noms à couvrir. Pour un blog, un site vitrine ou une petite boutique WordPress, un certificat à validation de domaine suffit. Les navigateurs n'affichent plus de barre verte pour les certificats à validation étendue depuis 2019 : le visiteur ne voit aucune différence entre les trois niveaux.

Installer le certificat chez l'hébergeur, avant de toucher à WordPress

L'installation du certificat SSL précède toute modification dans WordPress : basculer les adresses du site en https alors que le serveur ne répond pas encore en https coupe l'accès à l'administration. La première condition tient au DNS. Let's Encrypt vérifie que le nom de domaine pointe bien vers le serveur qui demande le certificat ; un domaine fraîchement transféré ou dont les enregistrements A et AAAA visent encore l'ancien hébergeur fait échouer la génération.

Le certificat doit couvrir les deux formes de l'adresse, le domaine nu (exemple.fr) et le sous-domaine www (www.exemple.fr). Un visiteur qui tape la forme oubliée tombe sinon sur une alerte de sécurité, avant même que la redirection n'entre en jeu. Le détail des réglages pour obtenir un certificat valable avec et sans www évite cette erreur, la plus fréquente sur les petits sites.

Une fois le certificat actif, un contrôle rapide consiste à ouvrir https://www.exemple.fr dans une fenêtre de navigation privée. Si la page s'affiche avec un cadenas, même avec des images cassées ou un message de contenu mixte, le serveur répond correctement et la suite peut commencer. Si le navigateur affiche « Votre connexion n'est pas privée », le certificat ne correspond pas au nom ou n'est pas encore propagé : il faut attendre quelques minutes ou relancer l'émission depuis le panneau.

Avant la moindre modification dans WordPress, deux sauvegardes s'imposent : un export complet de la base de données (phpMyAdmin, l'outil de l'hébergeur ou la commande wp db export) et une copie de wp-config.php. Les étapes suivantes réécrivent des adresses enregistrées dans des dizaines de tables, et une restauration propre ne prend que quelques minutes quand l'export existe. Sur un VPS sans panneau, Certbot génère le certificat depuis le terminal et installe un renouvellement planifié ; la logique reste la même.

Mettre en place le certificat selon l'hébergeur

La mise en place d'un certificat SSL pour WordPress suit les mêmes étapes chez tous les hébergeurs, mais l'emplacement du réglage change d'un panneau à l'autre. Le tableau de bord d'un hébergement mutualisé propose généralement une rubrique dédiée, et le certificat gratuit s'active en cliquant sur un seul bouton. Les parcours ci-dessous correspondent aux interfaces relevées en octobre 2026 ; les intitulés évoluent avec les mises à jour, et la documentation de support de chaque fournisseur fait foi.

• OVHcloud : dans l'espace client OVH, rubrique Web Cloud puis Hébergements, l'onglet Multisite liste chaque domaine rattaché. En cliquant sur le bouton d'action d'un domaine puis sur Modifier, la case SSL s'active ; la régénération du certificat depuis l'onglet Informations générales produit ensuite un certificat Let's Encrypt pour tous les domaines cochés. Chez OVH, l'émission prend généralement de quelques minutes à quelques heures.
• o2switch et les hébergeurs sous cPanel : l'outil SSL/TLS Status ou le module Let's Encrypt de cPanel liste les domaines et sous-domaines ; en cliquant sur le bouton d'exécution, le logiciel AutoSSL émet un certificat pour chacun et le renouvelle automatiquement.
• Hostinger : dans hPanel, la rubrique Sécurité puis SSL permet d'installer le certificat gratuit, souvent déjà actif sur les nouveaux sites.
• Plesk : l'extension SSL It!, disponible sur la plupart des installations Plesk, couvre le domaine, le www et également la messagerie, en cliquant sur une seule case par nom.

Le besoin d'un réglage spécifique se présente surtout dans trois cas : un domaine dont les paramètres DNS sont gérés chez un autre fournisseur, un site contenant des sous-domaines de messagerie (mail.exemple.fr) à couvrir aussi, et une machine dédiée administrée soi-même. Dans ce dernier cas, il faut se connecter en SSH et utiliser Certbot, le client recommandé par Let's Encrypt et le plus utilisé, qui fonctionne avec Apache comme avec Nginx : la commande certbot --apache ou certbot --nginx génère le certificat, l'inscrit dans la configuration et programme son renouvellement. Le dossier /etc/letsencrypt conserve les clés et les certificats, à inclure dans les sauvegardes.

Un webmaster qui gère les sites de plusieurs clients a besoin d'une vue d'ensemble : consulter chaque mois la date d'expiration de chaque certificat, ou utiliser un service de surveillance qui envoie une alerte par mail avant l'échéance. Pour un petit site, l'utilisation d'un certificat géré par l'hébergeur reste le meilleur choix : aucune commande à taper, aucun renouvellement à suivre, et un support à joindre si la validation échoue. Le choix de l'hébergeur lui-même, mutualisé ou VPS, pèse d'ailleurs davantage sur la sécurité du site que le type de certificat.

Changer les URL du site dans les réglages de WordPress

Les URL de WordPress se changent dans Réglages, Général : les champs « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » passent de http:// à https://, sans barre oblique finale, avant d'enregistrer les modifications. Une fois la page validée, WordPress déconnecte l'utilisateur, puisque le cookie de session était lié à l'ancienne adresse ; une nouvelle connexion sur l'adresse en https suffit. Depuis WordPress 5.7, sorti en mars 2021, l'outil Santé du site propose aussi un bouton qui effectue ce changement dès qu'il détecte un certificat valide, et qui réécrit au passage une partie des liens du contenu.

Si les deux champs sont grisés, les adresses sont fixées dans wp-config.php. La modification se fait alors dans ce fichier, au-dessus de la ligne qui demande d'arrêter l'édition :

define( 'WP_HOME', 'https://www.exemple.fr' );
define( 'WP_SITEURL', 'https://www.exemple.fr' );
define( 'FORCE_SSL_ADMIN', true );

La constante FORCE_SSL_ADMIN impose le chiffrement à la page de connexion et à toute l'administration, pour que mots de passe et cookies ne transitent jamais en clair, même si un lien en http traîne encore quelque part. Elle ne redirige pas les pages publiques : cette tâche revient au serveur web.

Sur une installation où l'administration n'est plus accessible, par exemple quand les URL ont basculé en https avant l'installation du certificat, ces deux constantes servent aussi de porte de secours : les écrire avec l'adresse en http rétablit l'accès, le temps de régler le certificat. Les mêmes valeurs se modifient avec WP-CLI : wp option update home et wp option update siteurl, ou directement dans la table wp_options depuis phpMyAdmin, lignes siteurl et home.

Rediriger tout le trafic http vers https

La redirection 301 de http vers https se règle au niveau du serveur web, pas dans WordPress. Elle remplit deux missions : envoyer les visiteurs qui arrivent par un ancien lien vers la version chiffrée et indiquer aux moteurs que l'adresse a définitivement changé, ce qui transfère le référencement des anciennes URL. Beaucoup d'hébergeurs proposent une option « forcer le https » dans le panneau du domaine ; l'activer dispense d'écrire la règle à la main.

Sur Apache : le fichier .htaccess

Sur un serveur Apache ou LiteSpeed, quelques lignes en tête du fichier .htaccess, au-dessus du bloc « BEGIN WordPress » que le CMS gère seul, suffisent :

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

Placer ces lignes à l'intérieur du bloc géré par WordPress serait une erreur : le CMS le réécrit à chaque enregistrement des permaliens et la règle disparaîtrait.

Sur Nginx

Nginx ignore le .htaccess. La redirection s'écrit dans la configuration du serveur, avec un bloc qui écoute le port 80 et renvoie tout vers le port 443 :

server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

Derrière Cloudflare ou un proxy

Derrière Cloudflare, un CDN ou un répartiteur de charge qui termine lui-même le chiffrement, le serveur reçoit des requêtes en http et la règle Apache renvoie sans fin vers https : c'est la boucle ERR_TOO_MANY_REDIRECTS. Deux solutions existent. Côté Cloudflare, régler le mode SSL/TLS sur « Full (strict) » plutôt que « Flexible », avec un certificat installé sur l'origine. Côté WordPress, lire l'en-tête X-Forwarded-Proto, comme le décrit la documentation officielle, en ajoutant dans wp-config.php :

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

Corriger le contenu mixte qui laisse le cadenas barré

Le contenu mixte désigne une page servie en https qui charge encore une ressource en http : une image, un script, une feuille de style, une police ou une vidéo intégrée. Les navigateurs bloquent les scripts et les feuilles de style appelés en clair et tentent de convertir les images en https ; selon le cas, la page perd sa mise en forme ou le cadenas affiche un avertissement. La documentation MDN de Mozilla détaille ce que chaque navigateur bloque ou tolère.

Ces adresses se trouvent surtout dans le contenu des articles, dans les widgets, dans les options du thème et des constructeurs de pages (Elementor, Divi, WPBakery), parfois dans le code du thème lui-même. Le remplacement global se fait de préférence avec WP-CLI, d'abord à blanc pour mesurer le nombre de lignes touchées :

wp search-replace 'http://www.exemple.fr' 'https://www.exemple.fr' --all-tables --dry-run
wp search-replace 'http://www.exemple.fr' 'https://www.exemple.fr' --all-tables

Cette commande gère les données sérialisées de WordPress, c'est-à-dire les tableaux PHP stockés sous forme de texte avec la longueur de chaque chaîne. Un rechercher-remplacer fait directement en SQL dans phpMyAdmin modifie la longueur réelle sans corriger la longueur déclarée, ce qui casse des widgets et des réglages du thème. Sans accès SSH, le plugin Better Search Replace offre la même fonction depuis l'administration, avec un mode de simulation.

Il reste ensuite à ouvrir la console des outils de développement du navigateur (touche F12) sur quelques pages types : accueil, article, page de contact, panier. Chaque ressource bloquée y apparaît avec son URL complète, ce qui permet de remonter à sa source : un logo codé en dur dans header.php, une police web appelée en http dans un vieux thème enfant, un iframe YouTube collé en 2016. Ces cas se corrigent à la main dans le fichier concerné, en écrivant l'adresse en https plutôt qu'en adresse relative au protocole (//exemple.fr), une pratique abandonnée.

Really Simple SSL et les autres plugins : utiles ou superflus ?

Really Simple SSL est le plugin le plus installé pour passer WordPress en https, avec plusieurs millions de sites actifs selon le répertoire officiel wordpress.org. Son principe est simple : il détecte le certificat, change les URL du site, ajoute la redirection et réécrit à la volée les adresses en http dans le code HTML envoyé au navigateur. Depuis 2024, l'extension s'appelle Really Simple Security et embarque aussi des fonctions de durcissement (authentification à deux facteurs, protection contre les attaques par force brute). Une faille critique d'authentification touchant cette fonction à deux facteurs a reçu un correctif en novembre 2024 : la tenir à jour compte plus que de l'installer.

SSL Insecure Content Fixer suit une logique voisine, centrée sur le seul contenu mixte, avec plusieurs niveaux de correction et un mode adapté aux proxys. Les deux plugins rendent service sur un site dont on ne maîtrise pas le serveur, ou pour diagnostiquer rapidement une installation héritée.

Leur limite tient à la méthode. Réécrire les adresses à chaque affichage ajoute un traitement à chaque page servie et masque le problème au lieu de le corriger : le jour où le plugin est désactivé, tout le contenu mixte réapparaît. Après une bascule faite dans les règles (certificat, URL, redirection serveur, remplacement dans la base), aucune extension SSL n'est nécessaire. La bonne pratique consiste à s'en servir comme outil de transition, puis à corriger la source et à désactiver la réécriture. Un site déjà lent gagne à vérifier aussi les causes d'un WordPress trop lent, car un plugin de plus n'arrange rien.

Que vérifier dans Google et dans le site une fois la bascule faite ?

Une fois le site WordPress en https, le travail porte sur les signaux envoyés aux moteurs de recherche et sur les services tiers qui connaissent encore l'ancienne adresse. Dans la Search Console, une propriété de type domaine couvre d'un coup http, https, www et sans www ; si le site n'était déclaré qu'en propriété préfixe d'URL, il faut en ajouter une pour https://www.exemple.fr et y soumettre le plan du site. Les sitemaps générés par WordPress ou par Yoast SEO et Rank Math reprennent seuls la nouvelle adresse, à condition que les URL du site aient changé dans les réglages.

La liste de contrôle compte une poignée de points :

• les liens internes du menu, du pied de page et des widgets texte, qui contiennent parfois l'URL complète en http ;
• les URL du flux RSS déclarées chez Feedly ou dans un outil d'envoi de lettres d'information ;
• la propriété Google Analytics et la balise Google Tag Manager, dont l'URL par défaut doit commencer par https ;
• les profils de réseaux sociaux, l'annuaire et la fiche Google Business Profile qui pointent vers le site ;
• les liens partagés dans les signatures de mail et les documents PDF, qui passeront par la redirection mais méritent une mise à jour.

La redirection 301 transmet l'essentiel du référencement des anciennes adresses ; un léger mouvement de positions pendant quelques semaines reste courant pendant que Google recrawle le site.

HSTS : à activer en dernier

HSTS (HTTP Strict Transport Security) est un en-tête qui demande au navigateur de refuser désormais toute connexion non chiffrée vers le domaine, pendant la durée indiquée par max-age. Son activation ne se fait qu'une fois tout le site et ses sous-domaines servis en https, en commençant par une durée courte (quelques minutes, puis une semaine) avant de passer à un an. L'inscription sur la liste de préchargement hstspreload.org exige un max-age d'au moins 31536000 secondes, la directive includeSubDomains et la mention preload : un choix difficile à défaire, à réserver aux sites dont toute l'infrastructure est stable.

Les problèmes fréquents après l'activation du SSL

Les problèmes rencontrés après l'activation du SSL sur WordPress se ramènent à une poignée de cas, presque toujours liés à un décalage entre le serveur et les réglages du site.

Boucle de redirection ou administration inaccessible

Le message ERR_TOO_MANY_REDIRECTS apparaît quand deux règles se renvoient la balle : une redirection http vers https côté serveur et un proxy qui parle en http à l'origine, ou un plugin SSL et une règle .htaccess qui se contredisent. Désactiver le plugin en renommant son dossier dans wp-content/plugins par FTP, puis lire l'en-tête X-Forwarded-Proto comme indiqué plus haut, règle la plupart des situations. Pour une administration inaccessible, les constantes WP_HOME et WP_SITEURL écrites en http rendent la main.

Certificat expiré ou non reconnu

Un certificat expiré déclenche une page d'alerte plein écran. La cause vient le plus souvent d'un renouvellement automatique qui a échoué : DNS déplacé chez un autre fournisseur, enregistrement CAA qui n'autorise pas Let's Encrypt, ou sous-domaine qui ne pointe plus vers le serveur. Relancer la génération depuis le panneau de l'hébergeur et lire le message d'erreur renvoyé suffit dans la majorité des cas. L'outil en ligne SSL Labs de Qualys donne un diagnostic complet de la chaîne de certification et de la configuration TLS.

Images manquantes, formulaires et paiements

Des images absentes de la médiathèque ou un formulaire qui ne s'envoie plus signalent un reste de contenu mixte ou un script tiers chargé en http, par exemple une ancienne version de reCAPTCHA. Sur une boutique, les passerelles de paiement exigent le https et vérifient l'URL de retour enregistrée dans leur interface : celle-ci doit passer en https elle aussi, sans quoi les notifications de commande se perdent.

WordPress multisite

Un réseau multisite en sous-domaines demande un certificat wildcard ou un certificat par sous-site, et la mise à jour des domaines dans les tables wp_blogs et wp_site en plus des options de chaque blog. La commande wp search-replace avec l'option --network traite l'ensemble du réseau en une passe. Les règles de sécurité propres aux CMS, des mises à jour aux permissions, sont regroupées dans la rubrique sur les protections qui tiennent un site CMS.

Cadenas, renouvellement et sous-domaines : les dernières hésitations sur le SSL de WordPress

Faut-il un certificat payant pour un site WordPress professionnel ?

Un certificat payant n'apporte aucun chiffrement supplémentaire à un site WordPress. Let's Encrypt chiffre avec les mêmes algorithmes ; un certificat OV ou EV vérifie seulement l'identité de l'entreprise, ce que les navigateurs n'affichent plus depuis 2019.

Le passage en https fait-il perdre des positions dans Google ?

Le passage en https ne fait pas perdre de positions durablement quand chaque ancienne URL renvoie en 301 vers sa version chiffrée. Des variations de quelques semaines restent possibles pendant que Google explore à nouveau le site.

Que faire si l'administration de WordPress ne s'ouvre plus après la bascule ?

Il suffit d'écrire WP_HOME et WP_SITEURL en http dans wp-config.php pour retrouver l'accès à l'administration, puis de vérifier que le certificat est bien actif sur le serveur avant de repasser les deux adresses en https.

Le plugin Really Simple SSL doit-il rester activé ?

Really Simple SSL se désactive sans risque une fois la redirection configurée sur le serveur et les adresses remplacées dans la base de données. Sa réécriture à la volée ne sert alors plus à rien et ajoute un traitement à chaque page.

Sources : documentation de WordPress pour les développeurs (HTTPS, wp-config.php, Santé du site) ; documentation de la commande wp search-replace de WP-CLI ; Mozilla MDN, contenu mixte ; Let's Encrypt ; CA/Browser Forum, vote SC-081 d'avril 2025 ; blog sécurité de Chrome.