Site WordPress non sécurisé : corriger une erreur de certificat SSL

Un lundi matin, une cliente essaie de commander et son navigateur lui affiche en grand « Votre connexion n’est pas privée ». Elle ne sait pas si elle doit continuer. Vous ouvrez votre propre site : même écran. Votre site WordPress est non sécurisé aux yeux de tous vos visiteurs, et le téléphone commence à sonner.

J’ai vu ce scénario sur des sites de TPE et de PME plus souvent que n’importe quelle autre panne. La bonne nouvelle, c’est que les causes se comptent sur les doigts d’une main, et qu’un navigateur suffit pour trouver laquelle est la vôtre. Voici la méthode que j’applique, dans l’ordre.

Pourquoi mon site WordPress est-il affiché « non sécurisé » ?

Un certificat SSL est un fichier installé sur le serveur de votre site. Il sert à deux choses : chiffrer les échanges entre le visiteur et le site, et prouver que le site est bien celui qu’il prétend être. Quand le navigateur ne parvient pas à vérifier ce certificat, ou qu’il trouve des éléments non chiffrés dans la page, il avertit le visiteur. Le terme technique est HTTPS : c’est ce « s » final, et le cadenas à gauche de l’adresse, qui disent que tout va bien.

Le plus important, c’est de distinguer deux situations qui n’ont presque rien en commun. Dans la première, le navigateur refuse d’afficher la page et propose de « revenir en lieu sûr ». Chrome affiche alors un code comme NET::ERR_CERT_DATE_INVALID (certificat expiré) ou NET::ERR_CERT_COMMON_NAME_INVALID (certificat émis pour un autre nom). Firefox parle de SEC_ERROR_EXPIRED_CERTIFICATE ou de SSL_ERROR_BAD_CERT_DOMAIN. Le site tourne, mais personne ne peut y entrer sans passer outre une alerte. C’est le cas urgent.

Dans la seconde, la page s’affiche normalement, mais le cadenas a disparu, ou il porte un triangle, ou la barre d’adresse indique « Non sécurisé ». Le certificat est le plus souvent valide. C’est la page qui charge au moins un élément (une image, une feuille de style, un script) à une adresse en http://. Les navigateurs appellent ça du contenu mixte. Rien ne bloque, mais un visiteur attentif le remarque, surtout sur un formulaire ou une page de paiement.

Alerte plein écran : regardez le certificat. Cadenas abîmé sur une page qui s’affiche : regardez le contenu de la page.

Cette règle ne couvre pas tous les cas, mais elle dit par où commencer, et c’est déjà beaucoup quand on est pressé.

Comment savoir si le problème vient du certificat ou du contenu de la page ?

Il vous faut un navigateur, un accès à l’administration de WordPress et dix minutes. Je ne touche à rien avant d’avoir fait ce diagnostic, parce que la moitié des dégâts que je répare viennent de corrections lancées trop vite.

Étape 1 : lire le code d’erreur et le détail du certificat

Cliquez sur l’icône à gauche de l’adresse (cadenas, triangle ou « Non sécurisé »), puis ouvrez le détail de la connexion et le certificat. Deux informations comptent : la date de fin de validité et la liste des noms couverts. Une date dépassée, c’est un certificat expiré. Un nom absent de la liste, c’est un certificat qui ne couvre pas la bonne adresse, par exemple exemple.fr sans www.exemple.fr.

Le code d’erreur affiché sous le message est votre premier indice : c’est aussi ce qu’il faut copier dans Google ou dans une IA pour trouver de l’aide ciblée. Le tableau ci-dessous reprend les codes que je rencontre le plus sur des sites WordPress.

Quand la page est bloquée, le bouton « Avancé » affiche la raison exacte du refus sans vous obliger à continuer. Pour un second avis, le test gratuit SSL Labs analyse le certificat et la configuration du serveur. Il est lent, mais il montre aussi ce que voit un visiteur qui arrive par l’autre version de votre adresse.

Étape 2 : repérer les adresses en http dans la console

Si le certificat est bon mais que le cadenas reste abîmé, ouvrez la page concernée, appuyez sur F12 et allez dans l’onglet « Console ». Le navigateur y liste chaque ressource chargée en http, avec son adresse complète :

Mixed Content: The page at 'https://www.exemple.fr/' was loaded over HTTPS,
but requested an insecure script 'http://www.exemple.fr/wp-content/themes/mon-theme/js/slider.js'.
This request has been blocked; the content must be served over HTTPS.

Les mêmes adresses reviennent en boucle et pointent presque toujours vers une ou deux sources : le logo du thème, une police chargée depuis un service externe, un vieux script de plugin. Notez-les. En pratique, c’est cette liste qui fait gagner une heure. Vérifiez aussi, dans Réglages > Général, que « Adresse web de WordPress » et « Adresse web du site » commencent bien par https.

Comment installer ou renouveler un certificat SSL sur WordPress ?

Si le diagnostic révèle un certificat expiré ou absent, il faut en obtenir un nouveau. Dans l’immense majorité des cas, ça se passe chez l’hébergeur, pas dans WordPress. La plupart proposent un certificat gratuit, souvent basé sur Let’s Encrypt, qu’on active en quelques clics depuis l’espace client (rubrique « SSL », « Sécurité » ou « Certificats », selon l’hébergeur) et qui se renouvelle ensuite tout seul.

Si le renouvellement automatique n’a pas fonctionné, la cause la plus fréquente est une vérification de domaine qui échoue. Elle échoue après un changement de DNS, un transfert de domaine, une migration, ou parce qu’une redirection empêche le serveur de répondre à la vérification. Si vous avez récemment changé d’hébergeur, regardez de ce côté en premier ; j’ai détaillé les pièges dans mon article sur la migration d’un site WordPress vers un nouvel hébergeur sans coupure.

Faut-il un plugin pour passer son site en HTTPS ? Pas pour obtenir le certificat. Un plugin comme Really Simple SSL peut ensuite aider à corriger les adresses et la redirection, mais il ne remplace pas le certificat, et il ne répare rien si ce dernier est expiré. Je le recommande avec modération : une fois le site propre, la plupart du temps, on peut s’en passer.

Certificat gratuit ou payant : lequel choisir pour un site de TPE ?

Pour un site vitrine, un blog ou une boutique de TPE, le certificat gratuit de l’hébergeur suffit. Le chiffrement est le même. Ce qui change avec un certificat payant, c’est la validation de l’organisation (une vérification administrative de l’entreprise), la garantie contractuelle et parfois le support. Les navigateurs n’affichent plus de différence visible pour le visiteur.

Un point à connaître : la durée de vie des certificats raccourcit. Let’s Encrypt émet des certificats de 90 jours, et la durée maximale des certificats publics est passée à 200 jours le 15 mars 2026, selon le calendrier adopté par les navigateurs et les autorités de certification. Concrètement, plus le renouvellement est fréquent, plus il doit être automatique. C’est un argument de plus pour ne jamais gérer ça à la main.

Comment corriger le contenu mixte et les redirections HTTPS ?

Quand le certificat est valide mais que le site reste non sécurisé, on entre dans le territoire du contenu mixte et des redirections. C’est là que je passe le plus de temps sur les dépannages, et c’est là que les mauvaises idées coûtent le plus cher.

Le contenu mixte : remplacer les anciennes adresses en http

Un site qui a longtemps vécu en http garde des centaines d’adresses en dur dans sa base de données : images insérées dans les articles, liens internes, réglages du thème, fichiers de styles générés par Elementor. Passer au HTTPS n’a pas réécrit tout ça. Le certificat est parfait, mais chaque ancienne adresse déclenche l’alerte.

La correction consiste à remplacer http par https dans ces adresses. Si votre site est construit avec Elementor, l’outil Elementor > Outils > Remplacer l’URL sert précisément à ça, suivi d’une régénération des fichiers CSS. Pour le reste, un plugin de recherche et remplacement fait l’affaire, à condition d’avoir une sauvegarde sous la main. La documentation de MDN sur le contenu mixte détaille ce que les navigateurs bloquent et pourquoi.

ERR_TOO_MANY_REDIRECTS : comment sortir d’une boucle de redirection HTTPS ?

Chrome et Edge affichent « Cette page ne fonctionne pas : le site vous a redirigé à de trop nombreuses reprises », avec le code ERR_TOO_MANY_REDIRECTS. Firefox écrit « La page ne redirige pas correctement », Safari « trop de redirections ». Test rapide : ouvrez le site en navigation privée ou supprimez les cookies du site. Si l’erreur disparaît, elle venait du navigateur. Sinon, ce sont presque toujours plusieurs règles HTTPS qui se superposent.

Un plugin, une règle dans le fichier .htaccess, une option chez l’hébergeur, un réglage du CDN : chacun force le https de son côté, et le navigateur tourne en rond. Une seule couche doit s’en charger, et il faut savoir laquelle. Si vous obtenez une boucle, retirez des règles, n’en ajoutez pas.

Avec un CDN comme Cloudflare, regardez le mode de chiffrement entre le CDN et votre serveur. Le mode « flexible » combiné à une redirection https côté serveur est une recette connue pour tourner en rond. Autre prudence : n’activez HSTS, qui force définitivement le https dans le navigateur du visiteur, qu’une fois que tout le site fonctionne en https. Revenir en arrière est long.

Comment savoir si l’alerte « non sécurisé » cache un piratage de mon site ?

Tout ce qui précède suppose un problème de certificat ou de contenu. Ce n’est pas toujours le cas. Si Chrome affiche « Site dangereux » ou « Le site que vous allez ouvrir contient des logiciels malveillants », le chiffrement n’est pas en cause : l’alerte vient de la Navigation sécurisée de Google, et elle signale que votre site a très probablement été piraté. Un certificat valide n’y change rien.

Autres signes : des redirections vers des sites inconnus quand on arrive depuis Google, un compte administrateur que personne n’a créé, des pages que vous n’avez jamais écrites dans les résultats de recherche. Ouvrez la Google Search Console, rubrique « Problèmes de sécurité » : Google y classe ce qu’il a détecté en contenu piraté, logiciels malveillants ou ingénierie sociale. Tout est détaillé dans la documentation du rapport sur les problèmes de sécurité.

Étape 1 : mettre le site en maintenance et sauvegarder l’état infecté, fichiers et base de données. Étape 2 : traquer les fichiers infectés et les portes dérobées, ces petits fichiers cachés qui laissent le pirate revenir après le nettoyage. Avec WP-CLI, la commande wp core verify-checksums compare les fichiers de WordPress à ceux de la version officielle. Pour les extensions et le thème, je réinstalle la version d’origine plutôt que de réparer à la main.

Étape 3 : fermer la faille. Mises à jour de WordPress, des extensions et du thème, puis changement de tous les accès : tableau de bord, FTP ou SFTP, base de données, compte de l’hébergeur. Je régénère aussi les clés de sécurité de wp-config.php, ce qui déconnecte toutes les sessions ouvertes, celle du pirate comprise. Étape 4 : le site propre, lancez la demande de réexamen dans la Search Console en décrivant ce que vous avez corrigé. Le délai varie selon le problème signalé.

Ensuite, la sécurité de votre site se joue dans la durée : surveillance continue des fichiers modifiés, mises à jour régulières, sauvegardes testées. C’est le quotidien de la sécurité WordPress ; j’ai détaillé la marche à suivre dans mon article sur la conduite à tenir quand un site WordPress est piraté.

Quelles erreurs éviter quand on répare un site non sécurisé ?

L’erreur la plus courante, c’est d’agir avant d’avoir compris. On installe un plugin de redirection, puis on ajoute une règle dans le .htaccess, puis on active l’option de l’hébergeur « au cas où ». Une demi-heure plus tard, le site est pire qu’au départ. Deuxième piège : lancer un remplacement massif dans la base de données sans copie préalable. Si vous n’avez pas encore de routine de sauvegarde, mon article sur l’automatisation des sauvegardes WordPress explique comment la mettre en place sans y passer vos soirées.

Troisième piège, plus rare mais coûteux : acheter un certificat payant dans la précipitation. Si le renouvellement automatique a échoué, en acheter un autre sans comprendre pourquoi ne corrige pas la cause, et vous payez pour un doublon.

Quand faut-il demander de l’aide ?

Il y a des cas où insister seul ne mène nulle part. Si le certificat est expiré et que votre espace client ne propose aucun bouton pour le renouveler, ou si l’alerte persiste après l’intervention du support de l’hébergeur, la cause se trouve probablement dans les DNS ou la configuration du serveur. Même chose si vous êtes enfermé hors de l’administration.

C’est aussi l’occasion de vous demander si votre hébergement est adapté : un renouvellement qui échoue à répétition est souvent le symptôme d’un environnement que personne ne suit. Mon article pour choisir un hébergement WordPress adapté à une TPE ou une PME donne des repères concrets. Le tableau ci-dessous résume ce que je regarde en premier.

Comment éviter que ça se reproduise ?

Le plus utile, au fond, est une habitude : regarder de temps en temps la date de fin du certificat, comme on surveille la date de renouvellement du nom de domaine. Je l’ai intégrée à la checklist de maintenance mensuelle de WordPress. Vérifiez aussi que le renouvellement automatique est bien activé chez votre hébergeur, et notez l’échéance dans votre agenda. Un outil de supervision qui envoie un e-mail avant l’expiration fait très bien le travail.

Si l’alerte est déjà là et que vous ne voyez pas d’où elle vient, je peux regarder le contexte de votre site WordPress ou WooCommerce, identifier la cause probable et vous proposer une intervention adaptée.

Questions fréquentes

Partager cet article : LinkedIn · Facebook · X · WhatsApp · E-mail