Contenu mixte et cadenas cassé après le passage en HTTPS

Votre connexion n’est pas privée

En anglais : Your connection is not private

Vous avez installé un certificat SSL et basculé le site en HTTPS, mais le navigateur n’affiche pas le cadenas attendu. Plusieurs symptômes se ressemblent et ont des causes très différentes : un cadenas barré ou un « Non sécurisé » alors que l’adresse commence par https://, des images, polices ou styles qui disparaissent, une mise en page cassée, ou une page entière « Votre connexion n’est pas privée » qui empêche d’accéder au site.

Le premier cas relève du contenu mixte (mixed content) : la page est servie en HTTPS, mais certaines ressources sont encore demandées en http://. Le second relève du certificat (absent, expiré, mal installé). La suite de cette fiche vous aide à les distinguer, puis à les corriger.

Ce que signifie cette erreur

Les navigateurs distinguent deux types de contenu mixte. Le contenu mixte passif (images, vidéos) est souvent affiché, mais le cadenas est dégradé. Le contenu mixte actif (scripts, feuilles de style, iframes, appels Ajax) est bloqué, ce qui casse l’affichage ou les fonctions. La console du navigateur (touche F12, onglet « Console ») liste chaque ressource en cause, avec un message du type « Mixed Content: The page at … was loaded over HTTPS, but requested an insecure … ».

Côté WordPress, tout dépend de ce que le site a enregistré. Les adresses sont stockées en dur à trois endroits : les options home et siteurl (« Réglages > Général », champs « Adresse web de WordPress (URL) » et « Adresse web du site (URL) »), le contenu des articles et des pages en base de données, et les fichiers de thème ou d’extension. Pour amortir la migration, WordPress remplace à l’affichage les anciennes URL en http:// du site par leur version HTTPS dans le contenu, les extraits, les widgets de texte et le CSS personnalisé (wp_replace_insecure_home_url() dans wp-includes/https-migration.php), mais seulement si l’option https_migration_required est active et si home et siteurl utilisent HTTPS et le même domaine. Ce filet ne couvre pas tout : champs personnalisés, données de constructeurs de pages, CSS généré, ressources de thème.

Autre piège : la fonction is_ssl() (wp-includes/load.php) ne reconnaît le HTTPS que si $_SERVER['HTTPS'] vaut on ou 1, ou si le port est 443. Derrière un répartiteur de charge, un CDN ou un proxy inverse qui termine le SSL, PHP reçoit une requête en clair : WordPress se croit en HTTP et génère des URL http://.

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Cadenas barré, page correcte	Contenu mixte passif (images, médias en http://)	Console du navigateur ; contenu en base ; thème
Styles ou scripts absents, page cassée	Contenu mixte actif bloqué	Console : ressources bloquées ; CSS d’Elementor ; options home et siteurl
Page « Votre connexion n’est pas privée » avant tout affichage	Certificat absent, expiré ou pour un autre nom	Détails du certificat ; certbot certificates ; www et sans www
Redirige en boucle ou « trop de redirections »	Mode SSL du CDN ou redirection mal paramétrée	Fiche sur les redirections ; mode « Full » côté CDN
Site en HTTPS mais WordPress génère du http:// derrière un proxy	is_ssl() ne détecte pas le HTTPS	En-tête X-Forwarded-Proto ; wp-config.php
Seules certaines pages (Elementor, formulaires) sont touchées	URL en dur dans les données du constructeur	_elementor_data ; outil de remplacement d’URL

Les causes les plus fréquentes

1. Des URL http:// restées en base de données dans les articles, pages, widgets, menus, options de thème.
2. Des ressources codées en dur dans un thème, une extension ou un script (images, polices, bibliothèques JavaScript chargées en http://).
3. Les adresses du site (home et siteurl) encore en HTTP, donc des liens et ressources générés en HTTP.
4. Un proxy ou un CDN qui termine le SSL sans que WordPress en soit informé (is_ssl() faux).
5. Un certificat invalide : expiré, installé pour exemple.fr mais pas pour www.exemple.fr, chaîne intermédiaire manquante.
6. Des données de constructeur de pages ou du CSS généré qui conservent l’ancienne URL (Elementor, par exemple).

Solutions pas à pas

Sauvegardez la base de données et les fichiers avant toute modification. Les remplacements en base sont difficiles à annuler. Du moins invasif au plus technique :

1. Identifier les ressources en cause

Ouvrez la page, puis la console du navigateur (F12). Chaque ligne « Mixed Content » donne l’URL exacte de la ressource en http://. Notez son domaine : s’il s’agit de votre domaine, la correction se fait en base ; s’il s’agit d’un service tiers, vérifiez s’il propose une adresse HTTPS (la plupart la proposent). Pour un audit méthodique, l’article contenu mixte après le passage en HTTPS détaille comment les repérer.

2. Vérifier les adresses du site

Dans « Réglages > Général », les deux adresses doivent commencer par https://. Elles peuvent aussi se contrôler et se corriger en WP-CLI :

wp option get home
wp option get siteurl
wp option update home 'https://www.exemple.fr'
wp option update siteurl 'https://www.exemple.fr'

Si l’administration n’est plus accessible, définissez-les temporairement dans wp-config.php (les valeurs de ce fichier prennent le dessus sur la base) :

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

WordPress sait aussi vous guider : si le site est accessible en HTTPS mais configuré en HTTP, l’écran « Santé du site » affiche « Votre adresse de site n’est pas configurée pour utiliser le HTTPS » et propose « Mettre à jour votre site pour utiliser le HTTPS ».

3. Remplacer les anciennes URL en base de données

Utilisez WP-CLI, qui traite correctement les données sérialisées (ce qu’un simple remplacement SQL casserait). Faites d’abord un essai à blanc :

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

L’option --skip-columns=guid préserve les identifiants globaux des contenus, qui ne doivent pas changer. Répétez l’opération pour la variante sans www ou pour les domaines qui ont changé. Sans WP-CLI, une extension de remplacement d’URL fait le même travail ; si vous passez par phpMyAdmin, ne remplacez jamais à la main des champs contenant du texte sérialisé.

Pour retrouver où se cachent les URL, cette requête liste les contenus concernés :

SELECT ID, post_type, post_title
FROM wp_posts
WHERE post_content LIKE '%http://www.exemple.fr%'
   OR ID IN ( SELECT post_id FROM wp_postmeta WHERE meta_value LIKE '%http://www.exemple.fr%' );

Adaptez le préfixe wp_ de vos tables.

4. Cas d’Elementor : données et CSS

Elementor garde les URL dans ses données (_elementor_data) et dans des fichiers CSS générés. Après le remplacement en base, allez dans « Elementor > Outils > Général » et cliquez sur « Effacer les fichiers et les données » pour régénérer le CSS. L’onglet « Remplacement d’URL » permet aussi de remplacer l’ancienne adresse par la nouvelle. En ligne de commande :

wp elementor replace-urls http://www.exemple.fr https://www.exemple.fr
wp elementor flush-css

Le cas complet d’un site dont le CSS est cassé après migration est décrit dans CSS Elementor cassé après migration de domaine.

5. Dire à WordPress qu’il est en HTTPS derrière un proxy

Si un proxy, un répartiteur de charge ou un CDN termine le SSL et parle en HTTP avec votre serveur, ajoutez ceci dans wp-config.php, avant le commentaire « stop editing » :

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

N’ajoutez ce bloc que si le proxy est de confiance et fixe lui-même cet en-tête : sinon, n’importe qui pourrait forger la valeur. Gardez à l’esprit que le mode « Flexible » de certains CDN, qui chiffre uniquement entre le visiteur et le CDN, provoque des boucles de redirection : voir la fiche trop de redirections.

6. Forcer la redirection HTTP vers HTTPS

Une fois les ressources corrigées, redirigez tout le trafic en clair. Sur Apache (dans le .htaccess, au-dessus du bloc WordPress) :

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

Sur nginx, dans un bloc server dédié au port 80 :

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

Derrière un proxy qui termine le SSL, testez l’en-tête X-Forwarded-Proto plutôt que %{HTTPS}, sous peine de boucle. Si des pages passent en 404 après la bascule, voyez la fiche pages en 404 et permaliens.

7. Réparer un certificat invalide

Si le navigateur affiche « Votre connexion n’est pas privée » avec un code du type NET::ERR_CERT_DATE_INVALID ou NET::ERR_CERT_COMMON_NAME_INVALID, le problème est le certificat et non le contenu. Contrôlez-le depuis le serveur :

# Certificats Let's Encrypt gérés par Certbot et dates d'expiration
sudo certbot certificates

# Ce que voit un visiteur
openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Vérifiez que le certificat couvre bien les deux noms (avec et sans www), qu’il n’est pas expiré, et que le serveur envoie la chaîne complète (fullchain.pem, pas seulement cert.pem). Le renouvellement automatique est expliqué dans Let’s Encrypt et Certbot sous WordPress. Si le certificat est expiré et que l’administration impose le HTTPS, FORCE_SSL_ADMIN et un certificat expiré explique comment retrouver l’accès.

8. Rustine temporaire : upgrade-insecure-requests

En attendant le nettoyage complet, l’en-tête CSP upgrade-insecure-requests demande au navigateur de charger en HTTPS toutes les ressources déclarées en http:// :

# nginx
add_header Content-Security-Policy "upgrade-insecure-requests" always;

# Apache (mod_headers)
Header always set Content-Security-Policy "upgrade-insecure-requests"

Cela ne fonctionne que si la ressource existe réellement en HTTPS ; ne remplace pas la correction des données.

Prévenir l’erreur

• Basculez en HTTPS dans cet ordre : certificat valide, redirection, adresses du site, remplacement en base, puis vérification de la console.
• Faites toujours le remplacement avec wp search-replace (données sérialisées respectées) et sauvegardez avant.
• Utilisez des URL relatives au protocole ou, mieux, directement en HTTPS pour les ressources tierces.
• Activez le renouvellement automatique du certificat et surveillez sa date d’expiration.
• Une fois le site stable en HTTPS, envisagez l’en-tête HSTS (Strict-Transport-Security) ; testez d’abord avec une durée courte.