Le certificat est en règle, sa date d'expiration est encore loin, et le navigateur affiche quand même « Non sécurisé » à côté de votre adresse, ou un cadenas barré. Parfois la page s'affiche en prime sans aucune mise en forme, comme si le thème avait disparu.
C'est une panne à part entière, et elle se répare sans toucher au certificat. Vérifiez d'abord que vous êtes sur le bon guide : si vous avez un écran d'avertissement à pleine page qui vous empêche d'atteindre le site, lisez plutôt le certificat SSL expiré ou invalide, les gestes n'ont rien de commun avec ceux qui suivent.
Ce que le navigateur affiche fait tout le tri
Les deux pannes sont couramment traitées ensemble, et c'est une erreur qui coûte des heures. Elles ne produisent pas le même écran et ne se réparent pas au même endroit.
Un avertissement à pleine page. Fond gris, un titre du genre « Votre connexion n'est pas privée », un code en majuscules du type NET::ERR_CERT_DATE_INVALID, un bouton pour revenir en arrière. Vous ne voyez pas votre site, il faut cliquer sur « Paramètres avancés » pour passer outre. Le problème est dans le certificat : expiré, émis pour un autre nom, chaîne incomplète. Autre guide.
Un site qui s'affiche, avec une mention discrète dans la barre d'adresse. Le mot « Non sécurisé », un cadenas barré, un triangle ou un rond d'information selon le navigateur. Vos pages sont là, vos visiteurs naviguent, mais l'indicateur de sécurité est tombé. C'est cette page.
Le site s'affiche mais tout est de travers. Texte brut aligné à gauche, aucune couleur, images empilées, menu déroulé en liste. Le propriétaire conclut que le thème est cassé et part chercher au mauvais endroit. C'est la variante grave de la même panne, expliquée plus bas.
Un dernier cas mérite trente secondes avant de toucher à quoi que ce soit : l'avertissement ne vient pas de votre site. Dans un fil que nous avons lu, le propriétaire a cherché une journée avant de comprendre que ses propres extensions de navigateur injectaient du contenu dans ses pages. Ouvrez votre site depuis un téléphone en 4G, hors de votre réseau. Si le cadenas est normal là-bas, le problème est sur votre poste.
En trente secondes
Testez depuis un autre appareil et un autre réseau. Fenêtre privée, extensions désactivées, téléphone en données mobiles. Cela élimine votre navigateur, votre cache et votre réseau en une minute.
Ouvrez la console du navigateur et rechargez la page. F12 sous Windows et Linux, Cmd Option I sur Mac, puis l'onglet Console. Chaque ressource fautive y apparaît sur sa propre ligne, avec son adresse complète. C'est le geste central de ce guide.
Regardez si la mise en page tient. Une page correcte avec un simple avertissement et une page qui s'affiche nue ne sont pas au même stade de gravité.
Ce qui se passe réellement
Votre page arrive par une connexion chiffrée. Le navigateur la lit, y trouve des appels vers des images, des feuilles de style, des polices, des scripts, et va les chercher un par un. Si l'une de ces adresses commence par http://, la page devient un mélange de chiffré et de non chiffré. Les navigateurs appellent cela du mixed content, « contenu mixte » dans les messages en français. Le nom importe peu, la suite compte : le navigateur ne réagit pas de la même façon selon ce que la ressource fait dans la page.
Le cas passif. Une image, une vidéo, un fichier son. Ces éléments s'affichent mais ne peuvent ni modifier la page ni lire vos cookies. Le navigateur les tolère souvent, tente parfois de les récupérer en https de lui-même, et se contente de retirer le cadenas. Rien ne casse visuellement, et le propriétaire ne comprend pas ce qu'on lui reproche.
Le cas actif. Une feuille de style, un script, un cadre intégré. Ces éléments-là peuvent réécrire la page entière, donc un intermédiaire capable de les modifier en route contrôlerait votre site chez chacun de vos visiteurs. Le navigateur ne prend pas le risque : il refuse de les charger, purement et simplement. La feuille de style n'arrive jamais, et votre page apparaît sans aucune mise en forme.
Voilà pourquoi tant de gens décrivent un problème de thème alors qu'ils ont un problème d'adresses. Le thème est intact, ses fichiers sont à leur place, ils sont simplement demandés par une adresse que le navigateur a décidé d'ignorer.
Le diagnostic : la console, pas un scanner
Des services en ligne analysent une page et listent les ressources non sécurisées. Ils dépannent, mais ils ne voient qu'une page à la fois, ignorent ce qui n'est chargé qu'après connexion, et certains sont à l'abandon. La console du navigateur fait mieux : gratuite, utilisable sur un site en production, et elle nomme la ressource fautive avec son adresse complète.
Ouvrez la console, laissez-la ouverte, puis rechargez la page. Les lignes à chercher commencent toutes par Mixed Content: dans Chrome et les navigateurs de la même famille. Elles se terminent de deux façons, et cette fin est votre diagnostic :
This request has been blocked; the content must be served over HTTPS.La ressource est active, elle a été bloquée, c'est elle qui casse votre mise en page. Priorité absolue.This content should also be served over HTTPS.La ressource est passive, elle s'est chargée, elle vous coûte le cadenas et rien d'autre.
Firefox dit la même chose autrement, avec la formule « Blocage du chargement du contenu mixte actif » et l'adresse fautive juste derrière.
Deux précautions. Rechargez avec la console ouverte : les messages ne s'affichent pas rétroactivement, une console ouverte après coup reste vide et laisse croire que tout va bien. Passez plusieurs pages, pas seulement l'accueil : un article, une page de contact, un panier. Chaque gabarit charge ses propres ressources, et la panne se cache souvent dans un module qui n'apparaît qu'à un endroit.
Il faut aussi savoir quoi ignorer, parce que la console d'un site WordPress normal n'est jamais vide. Les avertissements sur l'attribut SameSite des cookies, les 404 sur une icône, les messages d'une extension bavarde n'ont aucun rapport. Ne retenez que ce qui contient Mixed Content ou « contenu mixte ».
Un piège coûte régulièrement une demi-journée, et il mérite d'être nommé. En regardant le code source d'une page, vous verrez presque toujours xmlns="http://www.w3.org/2000/svg" dans les icônes. Ce n'est pas une ressource. C'est un identifiant d'espace de noms, une simple étiquette qui se trouve avoir la forme d'une adresse, et le navigateur ne va jamais la chercher. Elle survit à tous les remplacements en base parce qu'elle est régénérée à chaque affichage. Si votre seule trouvaille est là, vous n'avez rien trouvé.
Pour compléter la console, une commande donne la liste brute des adresses en clair présentes dans le code d'une page :
curl -s https://votre-domaine.fr/ | grep -oE "http://[^\"' ]+" | sort -u
Deux limites : elle ne voit que le code initial, pas ce qu'un script va chercher ensuite, et elle vous rendra le xmlns des SVG. Lue avec ça en tête, elle repère d'un coup un domaine qui n'a rien à faire là.
Les causes, dans l'ordre où on les rencontre
Le site est passé en https, la base est restée en http
C'est la situation la plus courante. Le certificat a été activé, le site répond en https, mais les adresses enregistrées dans WordPress n'ont pas suivi. Chaque image insérée dans un article porte son adresse absolue en http, chaque réglage d'extension aussi.
Commencez par les deux champs de Réglages, Général : « Adresse web de WordPress » et « Adresse web du site ». Les deux en https, sans barre oblique finale. Enregistrez, videz les caches, rechargez.
Si les deux champs sont grisés et impossibles à modifier, ce n'est pas un bogue. Quelqu'un a défini les adresses en dur dans wp-config.php, et ces constantes prennent le pas sur la base :
define( 'WP_HOME', 'https://votre-domaine.fr' );
define( 'WP_SITEURL', 'https://votre-domaine.fr' );
Corrigez le https directement dans ces deux lignes, ou retirez-les pour repasser par l'administration. Ce détail bloque beaucoup de monde, et rien à l'écran ne l'explique.
Une fois les deux adresses en ordre, il reste le contenu déjà publié. C'est l'objet de la section sur le chercher-remplacer.
Une adresse écrite en dur dans un thème ou une extension
Certains thèmes et certaines extensions écrivent l'adresse complète du site dans leurs fichiers plutôt que de la demander à WordPress. Le fichier reste en http après la migration, et aucun passage en base ne le corrigera.
Avec un accès en ligne de commande :
grep -rIn "http://votre-domaine.fr" wp-content/themes wp-content/plugins
Sinon, la console vous a déjà donné l'adresse fautive : cherchez son nom de fichier dans le gestionnaire de fichiers de votre hébergeur.
Cas voisin, très fréquent sur les sites refaits : du contenu copié depuis un ancien site, collé dans l'éditeur avec ses balises d'image. Ces adresses ne pointent même pas chez vous, mais vers un site qui n'existe peut-être plus.
Une ressource appelée en http chez un tiers
Une police, une carte, un badge d'avis, un script de statistiques, un lecteur vidéo. La ressource est chez quelqu'un d'autre, et c'est votre page qui l'appelle en clair.
Une commande sépare les deux situations. Testez si le service répond en https :
curl -I https://le-domaine-tiers.fr/le-fichier.js
Si une réponse arrive, il suffit de corriger le s manquant dans l'appel. Si la connexion échoue, le service ne propose pas de https, et aucun réglage de votre côté n'y changera rien. Il faut alors héberger le fichier chez vous quand la licence le permet, ou renoncer à la fonctionnalité. Pour une police, la copier dans le thème est de toute façon la meilleure décision.
Un script que vous n'avez jamais ajouté
Si la console nomme un domaine que vous ne reconnaissez pas, et qu'aucune de vos extensions ne justifie sa présence, arrêtez-vous. Une ressource en clair injectée dans toutes vos pages, souvent un script, est un symptôme d'intrusion et pas un reste de migration. Le nettoyage se fait alors dans l'autre sens, en commençant par les fichiers, et c'est le sujet du guide sur le site WordPress piraté. Ne vous contentez surtout pas de retirer la ligne : elle reviendra.
Le cache qui ressert les anciennes adresses
Vous avez corrigé, rien ne change. Avant de conclure à un échec, videz dans cet ordre : le cache de l'extension de cache, celui de l'hébergeur s'il en propose un, celui du service placé devant le site le cas échéant, puis celui de votre navigateur. Rechargez en navigation privée pour être sûr de voir la nouvelle version.
Les constructeurs de pages ajoutent une difficulté. Ils ne stockent pas seulement le contenu, ils fabriquent des fichiers de style qu'ils gardent sur le disque. Ces fichiers contiennent les anciennes adresses et continuent d'être servis tant qu'ils n'ont pas été régénérés, ce qui explique que tant de gens voient le problème revenir après l'avoir corrigé. L'outil de régénération se trouve dans les réglages du constructeur, à côté de son outil de remplacement d'adresses.
L'en-tête de sécurité, comme filet et non comme réparation
Un serveur peut demander au navigateur de tenter en https toutes les ressources appelées en clair, au moyen d'un en-tête :
Content-Security-Policy: upgrade-insecure-requests
Ce que cela fait : les appels en http sont réécrits à la volée par le navigateur, la mise en page cesse de casser, le cadenas revient. Ce que cela ne fait pas : corriger vos adresses, qui restent fausses en base. Et si la ressource visée n'existe pas en https, elle ne se charge toujours pas, elle échoue simplement autrement.
Utilisez-le pour tenir pendant que vous réparez, ou comme garde-fou une fois le vrai travail fait. Pas à la place du travail. Le même raisonnement vaut pour les extensions qui réécrivent les adresses à chaque affichage : elles masquent le symptôme au prix d'un traitement sur chaque page, et le jour où on les désactive, tout revient. Pendant le diagnostic, la variante Content-Security-Policy-Report-Only signale sans rien bloquer.
Le chercher-remplacer en base, et le danger que personne ne dit
Reste le gros du travail : remplacer http://votre-domaine.fr par https://votre-domaine.fr dans tout le contenu déjà publié.
Sauvegardez la base avant. Exportez-la depuis phpMyAdmin ou le panneau de votre hébergeur, et gardez le fichier ailleurs que sur le serveur. Ce n'est pas une formalité, la suite explique pourquoi.
La tentation est d'ouvrir phpMyAdmin et de lancer une requête UPDATE ... REPLACE sur la table des contenus. Ne le faites pas, et voici la raison exacte.
WordPress ne stocke pas que du texte. Les réglages d'extensions, les options de thème, les données des constructeurs de pages sont enregistrés sous forme sérialisée par PHP, un format qui écrit devant chaque chaîne sa longueur en caractères. Une adresse comme http://votre-domaine.fr/logo-entete.png est rangée ainsi :
s:39:"http://votre-domaine.fr/logo-entete.png"
Le 39 compte les caractères. Remplacez http par https et la chaîne en fait 40, mais le 39 reste écrit devant. PHP relit ce bloc, trouve une longueur qui ne correspond pas, et abandonne la lecture de la valeur entière. Le résultat n'est pas une adresse un peu fausse, c'est un réglage perdu : configuration d'extension revenue à zéro, options de thème vides, contenu de page qui disparaît. Le tout sans le moindre message d'erreur, et souvent constaté plusieurs jours après.
Il faut donc un outil qui comprend la sérialisation et recalcule les longueurs. Deux familles existent : les extensions de recherche et remplacement, que l'on installe le temps de l'opération puis que l'on désinstalle, et la ligne de commande de WordPress si votre hébergement donne un accès SSH. Dans les deux cas, deux règles :
Faites un essai à blanc d'abord. Les extensions sérieuses proposent une case à cocher pour simuler sans écrire, et annoncent le nombre de remplacements prévus. En ligne de commande :
wp search-replace 'http://votre-domaine.fr' 'https://votre-domaine.fr' \
--all-tables --precise --dry-run
Retirez --dry-run quand le résultat annoncé vous paraît cohérent. L'option --precise est celle qui force le traitement propre de la sérialisation.
Remplacez la chaîne la plus longue possible. http://votre-domaine.fr, pas http://. Un remplacement trop large touche des adresses externes légitimes, des exemples cités dans des articles, et des données sans rapport.
Les deux lignes siteurl et home de la table des options ne sont pas sérialisées et se corrigent à la main sans risque. Ce sont les seules. Un fil d'assistance que nous avons lu montre un demandeur qui a voulu faire davantage dans phpMyAdmin et s'est retrouvé avec un site inaccessible et une erreur de connexion à la base.
Si le cadenas ne revient pas
La console est vide et l'avertissement reste. Regardez ailleurs. Un certificat qui ne couvre pas la variante www de votre domaine donne un avertissement sur une visite sur deux, selon la façon dont le visiteur a tapé l'adresse. Cela relève du certificat.
Tout est corrigé mais le navigateur affiche encore l'ancien état. Les navigateurs gardent beaucoup de choses en mémoire, y compris des consignes de sécurité liées à votre domaine. Testez depuis un appareil qui n'a jamais visité le site avant de conclure.
L'avertissement n'apparaît que sur une page. Une ressource propre à un gabarit, un module dans un pied de page conditionnel, un contenu collé dans un seul article. La console sur cette page donne la réponse en dix secondes.
Ce que nous ne faisons pas. Notre forfait couvre la panne : rendre le site sûr aux yeux du navigateur et documenter d'où venaient les appels en clair. Il ne couvre pas la reconstruction d'une mise en page abîmée dans un constructeur, ni la refonte d'un thème. Si vous en êtes à votre deuxième soirée sur le sujet, faire réparer un site WordPress qui affiche un avertissement coûte 149 € HT, remis en ligne ou remboursé.
Comment éviter que ça revienne
Corrigez les adresses avant de téléverser quoi que ce soit. Sur un site dont l'adresse enregistrée est restée en http, chaque image ajoutée dans la médiathèque naît avec une adresse en clair. Vous réparez d'un côté pendant que vous cassez de l'autre. Un propriétaire dont nous avons lu le récit voyait le cadenas revenir, puis repartir dès la publication suivante.
Hébergez vos polices et vos icônes chez vous. Une dépendance externe de moins, c'est un appel en clair de moins le jour où le service tiers change ses adresses ou ferme.
Ouvrez la console après chaque changement de thème ou chaque nouvelle extension. Dix secondes, sur deux ou trois pages. C'est le moment où un appel en clair s'introduit, et le seul où il est facile à attribuer.
Méfiez-vous du contenu collé. Un article repris d'un ancien site apporte ses balises d'image et leurs adresses. Réinsérez les images par la médiathèque plutôt que de coller le code.
Questions fréquentes
Pourquoi mon site n'est pas sécurisé alors que le certificat est valide ?
Parce que le certificat protège la connexion à votre page, pas ce que la page va chercher ensuite. Si elle arrive en https mais demande une image, une feuille de style ou un script en http, le navigateur considère que l'ensemble n'est plus garanti et retire le cadenas. Le renouveler ne changera rien.
Comment enlever l'avertissement « non sécurisé » sur WordPress ?
Ouvrez la console, rechargez la page, notez chaque adresse en http qu'elle nomme. Corrigez les deux champs d'adresse dans Réglages, Général. Passez ensuite le contenu publié avec un outil de recherche et remplacement qui gère la sérialisation PHP, jamais avec une requête SQL brute. Videz les caches, puis reprenez la console pour vérifier qu'il ne reste rien.
Peut-on autoriser le navigateur à afficher les ressources bloquées ?
Chrome et Firefox proposent un réglage par site qui lève le blocage. Il n'agit que sur l'ordinateur où vous l'activez : vos visiteurs verront toujours la page cassée. Utile trente secondes pour confirmer un diagnostic, ça ne répare rien.
Pourquoi la mise en page casse-t-elle au lieu de simplement afficher un avertissement ?
Parce que la ressource concernée est active. Une feuille de style ou un script peuvent réécrire toute la page, donc le navigateur refuse de les charger en clair au lieu de se contenter de vous prévenir. Une image en clair, qui ne peut rien réécrire, passe avec un simple avertissement. C'est la même panne, à deux niveaux de gravité.
Pourquoi le cadenas redevient barré après avoir tout corrigé ?
Trois explications, dans cet ordre. Un cache qui ressert l'ancienne version, y compris les fichiers de style d'un constructeur de pages, qu'il faut régénérer explicitement. Une extension qui réécrivait les adresses à l'affichage et qui a été désactivée. Ou l'adresse du site restée en http, qui recontamine chaque nouveau média téléversé.