Contenu mixte WordPress : corriger le cadenas barré en HTTPS

Le cadenas est barré — et pourtant tu as bien installé ton SSL

Le certificat SSL est actif, l’URL affiche bien https://, mais le navigateur refuse de montrer le cadenas vert : une petite barre oblique rouge, parfois un triangle orange, ou un message “non sécurisé” en barre d’adresse. Résultat : les visiteurs ne font pas confiance, et sur un site e-commerce ou premium, ça se ressent sur les conversions. On voit ça sur le taux de conversion avant même d’ouvrir Google Analytics.

Bonne nouvelle : c’est un problème 100 % réparable. La cause est presque toujours la même — des ressources encore chargées en http:// sur une page désormais servie en https://. C’est ce qu’on appelle le contenu mixte (mixed content).

Pourquoi le cadenas devient barré après le passage en HTTPS

Quand le navigateur charge une page en HTTPS, il applique une règle stricte : toutes les ressources de la page doivent aussi être servies en HTTPS. Dès qu’une seule image, un script, une feuille de style ou une iframe pointe encore vers http://, le navigateur lève une alerte.

Deux niveaux d’alerte existent :

• Contenu mixte passif (passive mixed content) : images, vidéos, audio chargés en HTTP. Le navigateur affiche le cadenas barré ou dégradé mais bloque rarement la ressource.
• Contenu mixte actif (active mixed content) : scripts JS, feuilles CSS, iframes chargés en HTTP. Le navigateur bloque la ressource et peut carrément casser la mise en page ou des fonctionnalités entières.

D’où viennent ces URLs en http:// ?

• Des URLs codées en dur dans la base de données WordPress lors de l’ancienne installation (articles, pages, widgets, options de thème).
• Des médias uploadés avec une URL absolue stockée en http:// dans la table wp_posts ou wp_postmeta.
• Des scripts tiers (Google Fonts, scripts analytics anciens, widgets réseaux sociaux) appelés avec un ancien lien HTTP.
• Des CSS ou JS de plugins qui construisent leurs URLs depuis une option en base mal mise à jour.
• Un wp-config.php ou .htaccess qui force encore l’ancienne URL en HTTP.

Solution 1 — Vérifier les URLs racines dans WordPress

Avant toute manipulation, confirme que WordPress lui-même connaît la bonne URL HTTPS. Dans le back-office :

Réglages → Général → vérifie les deux champs :

• Adresse web de WordPress (URL)
• Adresse web du site (URL)

Les deux doivent afficher https://ton-domaine.com. Si l’un d’eux est encore en http://, corrige-le directement ici — ou via wp-config.php si tu n’as pas accès à l’admin :

define('WP_HOME', 'https://ton-domaine.com');
define('WP_SITEURL', 'https://ton-domaine.com');

C’est la première vérification, et elle règle parfois le problème à elle seule.

Solution 2 — Forcer la redirection HTTPS dans .htaccess

Même si WordPress connaît la bonne URL, un visiteur qui arrive en http:// doit être redirigé. Dans le .htaccess à la racine du site :

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

Si tu es sur un hébergeur avec proxy (OVH, Cloudflare), la variable %{HTTPS} peut être masquée. Utilise alors :

RewriteCond %{HTTP:X-Forwarded-Proto} !https

Solution 3 — Trouver les ressources mixtes avec les outils du navigateur

Avant de modifier la base de données, identifie précisément ce qui charge en HTTP.

1. Ouvre la page problématique dans Chrome ou Firefox.
2. F12 → onglet Console : filtre sur les avertissements “Mixed Content”.
3. Onglet Réseau → filtre sur le schéma http:// : tu vois exactement quels fichiers sont concernés (images, scripts, fonts…).

Note les URLs problématiques. Certaines viennent de plugins tiers — dans ce cas, c’est une mise à jour ou un remplacement du plugin qui règle le problème, pas un search-replace.

Solution 4 — Search & Replace en base de données (la correction principale)

C’est ici que réside 80 % du travail. Toutes les URLs http://ton-domaine.com stockées en base doivent devenir https://ton-domaine.com.

Méthode A : plugin Better Search Replace (recommandée)

1. Installe et active Better Search Replace (gratuit, actif, bien maintenu).
2. Menu Outils → Better Search Replace.
3. Champ “Rechercher” : http://ton-domaine.com
4. Champ “Remplacer par” : https://ton-domaine.com
5. Sélectionne toutes les tables wp_*.
6. Coche d’abord “Effectuer un test ?” pour voir combien de lignes seront affectées sans rien modifier.
7. Si le résultat est cohérent, décoche le test et lance le remplacement.

⚠️ Fais une sauvegarde complète (base + fichiers) AVANT. Sans ça, tu joues sans filet.

Méthode B : WP-CLI (si tu as accès SSH)

wp search-replace 'http://ton-domaine.com' 'https://ton-domaine.com' --all-tables --dry-run
# Enlève --dry-run quand tu es prêt

WP-CLI gère les données sérialisées (tableaux PHP encodés en base) correctement — avantage sur un simple SQL brut.

Méthode C : phpMyAdmin (dernier recours)

Utilise un UPDATE ciblé sur wp_options, wp_posts, wp_postmeta. Attention : les données sérialisées (options de thèmes, builders de page) peuvent se corrompre avec un simple REPLACE() SQL. Préfère les méthodes A ou B.

Solution 5 — Plugin Really Simple SSL pour le contenu résiduel

Une fois le search-replace fait, il peut rester quelques URLs HTTP orphelines (resources d’un CDN externe, iframe YouTube en HTTP, etc.). Le plugin Really Simple SSL ajoute un filtre PHP qui réécrit à la volée les URLs HTTP en HTTPS dans le HTML généré — sans toucher à la base.

C’est un filet de sécurité, pas une solution principale. Ne l’utilise pas pour éviter le search-replace : la base doit rester propre.

Solution 6 — Ajouter un en-tête CSP pour détecter (et bloquer) le reste

Si après tout ça tu veux être certain qu’aucune ressource HTTP ne passe, déploie un en-tête Content-Security-Policy en mode rapport :

Header always set Content-Security-Policy-Report-Only "default-src https:; report-uri /csp-report"

Le navigateur envoie un rapport chaque fois qu’une ressource HTTP est détectée — sans rien bloquer encore. Quand les rapports sont vides, tu peux passer en mode Content-Security-Policy strict. C’est une couche de surveillance utile, surtout sur des sites à fort enjeu de confiance — typiquement un e-commerce ou une marque premium.

Tableau récapitulatif : cause → solution

Quand passer la main à un pro

Si après le search-replace et la vérification des URLs racines le cadenas reste barré, c’est que la source HTTP vient d’un script ou d’un plugin qui reconstruit ses URLs dynamiquement — et qu’il faut auditer le code. De même, si ton site repose sur un builder de page complexe (Divi, Elementor, Oxygen), certaines métadonnées encodées en JSON imbriqué dans du sérialisé PHP résistent au search-replace classique. C’est le genre de situation où une mauvaise manipulation peut casser la mise en page — et où une maintenance assurée par une agence fait la différence entre trente minutes de travail et une soirée de galère. Les problèmes de performance liés à un HTTPS mal configuré ont aussi tendance à s’accumuler en silence bien après la migration.