Corriger les contenus mixtes après passage en HTTPS

Si vous voyez un cadenas “non sécurisé” alors que votre site est bien en HTTPS, vous êtes presque toujours face à du contenu mixte : une page HTTPS qui charge encore des ressources en HTTP.

Le problème

Les navigateurs modernes bloquent ou dégradent l’affichage quand une page HTTPS tente de charger des scripts, feuilles de style, polices, images ou iframes en HTTP. Le symptôme le plus parlant est dans la console.

Mixed Content: The page at 'https://exemple.com/' was loaded over HTTPS,
but requested an insecure resource 'http://exemple.com/wp-content/uploads/2024/10/image.jpg'.
This request has been blocked; the content must be served over HTTPS.

Vous le verrez sur le front-end (souvent), parfois dans l’admin (éditeur de blocs qui charge une police/iframe), et plus rarement sur des endpoints AJAX/REST si un script est bloqué. Le déclencheur typique : migration HTTP → HTTPS, changement de domaine, passage derrière un CDN / reverse proxy, ou import de contenus depuis un ancien site.

Ce billet s’adresse aux utilisateurs WordPress 6.9.4 (avril 2026) et PHP 8.1+ qui veulent corriger proprement les contenus mixtes sans plugin. À la fin, vous saurez :

identifier précisément la ressource en HTTP (et d’où elle vient),
corriger les URL en dur dans le thème/plugins/snippets,
nettoyer la base de données sans casser les données sérialisées,
verrouiller HTTPS côté serveur/WordPress pour éviter les récidives.

Résumé rapide

Un contenu mixte = page en HTTPS + ressource chargée en HTTP (souvent une URL “en dur”).
Commencez par la console navigateur : elle donne l’URL exacte bloquée.
Corrigez d’abord le code (enqueues, shortcodes, templates) : c’est la source la plus fréquente.
Ensuite seulement, corrigez la base via WP-CLI search-replace (avec précautions sur la sérialisation).
Si vous êtes derrière un proxy/CDN, assurez-vous que WordPress “voit” HTTPS (sinon il régénère des URL en HTTP).
Après correction : purge cache (plugin/CDN), test en navigation privée, re-scan des pages clés.

Les symptômes

Cadenas barré / “Non sécurisé” dans Chrome/Edge/Firefox alors que l’URL est en https://.
Console navigateur : erreurs “Mixed Content” (souvent blocked pour JS/CSS, parfois “upgraded” pour des images).
CSS manquant (mise en page cassée) parce qu’une feuille de style HTTP est bloquée.
JS cassé : menus, sliders, tracking, formulaires, reCAPTCHA, player vidéo qui ne se charge pas.
Images qui ne s’affichent pas (souvent des URL d’images copiées/collées depuis l’ancien site).
Dans Elementor / Divi / Avada : un module “HTML/Code” ou un widget “Vidéo” qui pointe vers un http:// externe.
Sur certains sites derrière Cloudflare / un load balancer : WordPress génère des liens en HTTP (assets, canonical, redirections).

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
Cadenas “non sécurisé”	Image/iframe en HTTP dans le contenu	Console + “View source” / inspecteur	Solution 2 (DB) ou éditer la page
CSS non chargé	`wp_enqueue_style()` avec URL en dur `http://`	Onglet Network → CSS bloqué	Solution 1 (enqueues)
JS cassé	Script externe en HTTP (analytics, lib)	Console Mixed Content + Network	Solution 1 (corriger URL / protocole relatif / https)
URL générées en HTTP	Proxy/CDN mal déclaré, `is_ssl()` faux	`wp_get_environment_type()` OK mais `is_ssl()` faux	Solution 3 (headers + config)
Ça revient après purge	Cache/CDN sert une ancienne version	Headers cache, test incognito, purge CDN	Purge + invalidation + vérifier origin

Pourquoi ça arrive

Version simple : votre site est passé en HTTPS, mais certaines parties (images, scripts, CSS, iframes) pointent encore vers l’ancienne URL en HTTP. Le navigateur refuse de mélanger “sécurisé” et “non sécurisé”.

Version technique : WordPress produit des URL à plusieurs endroits (contenu, meta, enqueues, REST, sitemaps, shortcodes, blocs). Si une URL est stockée “en dur” avec http:// (dans un champ de post, une option, un builder, un thème, un plugin), elle ressort telle quelle. Et si WordPress ne détecte pas correctement HTTPS (proxy/CDN), il peut générer des URL absolues en HTTP via des fonctions qui dépendent du schéma.

Causes (du plus fréquent au plus rare)

URL en dur dans le contenu : images, liens, iframes YouTube anciennes, scripts collés dans un bloc HTML.
URL en dur dans le thème : http:// dans un template, un header, une option du thème.
Enqueue incorrect : wp_enqueue_script() / wp_enqueue_style() avec une URL HTTP.
Options de page builders (Elementor/Divi/Avada) : URLs stockées dans postmeta ou JSON.
Proxy/CDN : WordPress croit être en HTTP (pas de header X-Forwarded-Proto ou mauvaise config), donc il génère des URLs HTTP.
Ressources externes non disponibles en HTTPS (rare aujourd’hui, mais ça existe encore).

Prérequis avant de commencer

Sauvegarde complète (fichiers + base). Pour la base, un dump SQL avant toute modification.
Un environnement de test (staging) si possible. J’ai souvent vu des “search/replace” faits en prod casser un builder ou une config sérialisée.
WordPress 6.9.4 et PHP 8.1+. Si vous êtes en dessous, corrigez d’abord : certains outils (WP-CLI récent, libs) supposent PHP moderne.
Outils utiles :
- Query Monitor (diagnostic des enqueues, hooks, requêtes).
- Health Check & Troubleshooting (désactiver plugins pour vous seul).
- WP-CLI installé sur le serveur (wp en ligne de commande).

Activer les logs (temporairement)

Sur un site qui “casse” après correction, vous gagnerez du temps avec des logs propres.

/* wp-config.php */

/* Active le debug (à faire sur staging ou temporairement en prod) */
define( 'WP_DEBUG', true );

/* Log dans wp-content/debug.log */
define( 'WP_DEBUG_LOG', true );

/* Évite d'afficher les erreurs aux visiteurs */
define( 'WP_DEBUG_DISPLAY', false );

Référence : Debug WordPress (developer.wordpress.org)

Solution 1 : remplacer les URL en dur dans le code (thème / plugin / snippets)

Le cas le plus rentable : un thème (ou thème enfant) qui enqueue un fichier via http://, ou un template qui imprime des URL absolues. C’est aussi ce qui revient le plus souvent après une migration, parce que le code est versionné et réintroduit le problème à la prochaine mise à jour.

Diagnostic

Ouvrez la console (F12) → onglet Console → repérez la première erreur “Mixed Content”.
Dans l’URL de la ressource, regardez si elle vient de :
- votre domaine (http://exemple.com/wp-content/...) → thème/plugin/contenu,
- un domaine tiers (fonts, scripts) → script externe en HTTP.
Onglet Network → filtrez sur “CSS” / “JS” → voyez ce qui est bloqué.

Exemple AVANT (cassé) : enqueue en HTTP

<?php
// functions.php du thème enfant

add_action( 'wp_enqueue_scripts', function () {
	// MAUVAIS : URL en dur avec http://
	wp_enqueue_style(
		'mon-theme-fonts',
		'http://exemple.com/wp-content/themes/mon-theme/assets/fonts/fonts.css',
		array(),
		'1.0'
	);
}, 10 );

Exemple APRÈS (corrigé) : utiliser des URL dynamiques HTTPS-safe

<?php
// functions.php du thème enfant

add_action( 'wp_enqueue_scripts', function () {
	// BON : construit l'URL depuis le thème, WordPress gère le schéma (http/https) correctement
	$fonts_css = get_stylesheet_directory_uri() . '/assets/fonts/fonts.css';

	wp_enqueue_style(
		'mon-theme-fonts',
		$fonts_css,
		array(),
		'1.0'
	);
}, 10 );

Pourquoi ça marche : get_stylesheet_directory_uri() renvoie l’URL du thème enfant basée sur la configuration du site. Vous évitez une URL figée qui garde “http”. Référence : get_stylesheet_directory_uri()

Cas fréquent : URL du site concaténée “à la main”

J’ai souvent croisé ce pattern dans des snippets copiés d’anciens tutos :

<?php
// AVANT : cassé si home_url() est filtré ou si le schéma est incorrect derrière un proxy
$logo = home_url() . '/wp-content/uploads/logo.png';
echo '<img src="' . esc_url( $logo ) . '" alt="">';

<?php
// APRÈS : mieux (utilise l'ID du média, ou à défaut une URL relative)
$logo_id = (int) get_theme_mod( 'custom_logo' );

if ( $logo_id ) {
	// BON : WordPress renvoie l'URL correcte, gère tailles, CDN, etc.
	echo wp_get_attachment_image( $logo_id, 'full' );
}

Pourquoi c’est plus robuste : les URL d’uploads peuvent changer (CDN, sous-domaine, offload). En passant par l’ID, vous déléguez la construction de l’URL à WordPress. Référence : wp_get_attachment_image()

Cas page builders (Divi 5, Elementor, Avada)

Le contenu mixte ne vient pas toujours d’un enqueue. Sur Divi/Elementor/Avada, je le vois souvent dans :

un module “Code/HTML” qui contient un script http://,
un module “Vidéo” avec une iframe collée depuis une ancienne URL,
une police externe déclarée en HTTP dans une option de thème/builder.

Ce que je fais en premier : je retrouve la page concernée (via l’URL dans la console), puis j’édite le contenu du module et je remplace explicitement http:// par https:// (ou j’utilise une URL relative si la ressource est interne).

Anti-pattern : “filtrer tout le HTML” pour remplacer http → https

Vous verrez parfois des snippets qui font un remplacement global via the_content. Ça peut masquer le problème, mais ça casse vite des cas limites (JSON, scripts, URLs signées, liens externes qui ne supportent pas HTTPS), et ça ajoute un coût CPU sur chaque page.

<?php
// AVANT : anti-pattern (remplacement aveugle, performance et risques)
add_filter( 'the_content', function ( $content ) {
	return str_replace( 'http://exemple.com', 'https://exemple.com', $content );
}, 1 );

Si vous devez vraiment faire une correction “de secours”, faites-la ciblée, temporaire, et uniquement sur votre domaine. Mais le bon correctif reste : corriger la source (code ou DB).

Solution 2 : corriger les contenus mixtes dans la base (sans plugin)

Quand les URL HTTP sont stockées dans la base (posts, postmeta, options), il faut un search/replace sûr. Le piège : certaines données sont sérialisées (PHP serialize) ou encodées JSON. Un remplacement SQL naïf casse les longueurs sérialisées et fait tomber des builders.

Ce qu’il ne faut pas faire (AVANT) : UPDATE SQL direct

# AVANT : dangereux si des données sérialisées existent
# (ex: options, widgets, certains meta de builders)
mysql -u root -p -e "UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://exemple.com', 'https://exemple.com');"

Symptômes après ce genre de commande : Elementor qui affiche une page blanche, Divi qui “oublie” des modules, widgets cassés, erreurs PHP du type unserialize(): Error at offset dans les logs.

La méthode fiable : WP-CLI search-replace

WP-CLI gère correctement la sérialisation. Référence : wp search-replace

1) Dry-run (simulation)

# Remplacez par votre domaine exact
wp search-replace 'http://exemple.com' 'https://exemple.com' --all-tables --dry-run

Regardez quelles tables sont touchées. Sur des sites avec Elementor/Divi/Avada, attendez-vous à voir wp_postmeta et parfois des tables propres au builder.

2) Exécution réelle (avec précautions)

# 1) Sauvegarde DB (fortement recommandé)
wp db export "backup-avant-https-$(date +%F).sql"

# 2) Search/replace réel
wp search-replace 'http://exemple.com' 'https://exemple.com' --all-tables --precise --recurse-objects

–precise : plus lent mais plus sûr sur certains formats.
–recurse-objects : utile si des objets sérialisés contiennent des sous-structures.

Cas particulier : URLs d’uploads “codées en dur”

Parfois, le site a changé de structure (ex: http://exemple.com/wp-content/uploads/ → https://media.exemple.com/uploads/). Là, un simple remplacement de domaine ne suffit pas.

# Exemple : déplacer les uploads vers un sous-domaine média
wp search-replace 'http://exemple.com/wp-content/uploads/' 'https://media.exemple.com/uploads/' --all-tables --precise --recurse-objects

Attention : si vous avez un plugin d’offload (S3, etc.), vérifiez d’abord sa configuration. Sinon vous risquez de “figer” des URLs qui devraient être générées dynamiquement.

Vérifier et corriger les champs “Site Address”

Avant de lancer un search/replace massif, assurez-vous que WordPress est bien configuré en HTTPS :

Réglages → Général → Adresse web de WordPress (URL)
Réglages → Général → Adresse web du site (URL)

Ou en WP-CLI :

wp option get home
wp option get siteurl

Docs : get_option()

Solution 3 : verrouiller HTTPS côté serveur et côté WordPress (cas avancés)

Quand vous êtes derrière un reverse proxy (Cloudflare, ALB, Nginx proxy, hébergeur managé), il arrive que le navigateur soit en HTTPS mais que PHP reçoive une requête “interne” en HTTP. Résultat : is_ssl() renvoie faux, et WordPress génère des URL en HTTP dans certains contextes.

Référence : is_ssl()

3A) Vérifier ce que WordPress “croit”

Ajoutez temporairement ce snippet (sur staging) et regardez le HTML source :

<?php
// functions.php (temporaire)
add_action( 'wp_footer', function () {
	if ( current_user_can( 'manage_options' ) ) {
		echo '<!-- is_ssl=' . ( is_ssl() ? '1' : '0' ) . ' home_url=' . esc_url( home_url() ) . ' -->';
	}
}, 99 );

Si is_ssl=0 alors que vous êtes sur https://, vous avez un problème de headers proxy.

3B) Correctif côté serveur (recommandé)

Le meilleur fix est au niveau du proxy : envoyer X-Forwarded-Proto: https (ou équivalent), et configurer Nginx/Apache pour le respecter.

Comme les configs varient selon l’hébergeur, je donne ici un exemple typique Nginx (reverse proxy) :

# Exemple (Nginx) : transmettre le proto au backend PHP
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;

Ensuite, côté WordPress, vous pouvez reconnaître ce header (si votre stack le fournit).

3C) Correctif côté WordPress (fallback, à utiliser avec prudence)

Si vous ne contrôlez pas le serveur, un fallback dans wp-config.php peut dépanner. Risque : si un attaquant peut forger ce header (mauvaise config proxy), vous pouvez provoquer des comportements inattendus. Ne faites ça que si vous êtes sûr que l’en-tête est injecté par votre proxy de confiance.

<?php
// wp-config.php

// Fallback : force HTTPS si le proxy indique https.
// ATTENTION : n'utilisez ceci que si X-Forwarded-Proto est fiable dans votre infra.
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
	$_SERVER['HTTPS'] = 'on';
}

3D) Forcer la redirection HTTP → HTTPS

La redirection ne “corrige” pas le contenu mixte, mais elle évite que des visiteurs arrivent en HTTP (et que des URLs soient générées/cachées en HTTP).

Exemple Apache (.htaccess) :

# Apache : redirection vers HTTPS
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Sur Nginx, faites plutôt un server block qui écoute en 80 et redirige en 301 vers 443.

Vérifications après correction

Purger les caches :
- cache plugin (si présent),
- cache serveur (Varnish),
- cache CDN (Cloudflare),
- cache navigateur (testez en navigation privée).
Re-test de 5 à 10 pages représentatives (home, article, page builder, page contact, checkout si WooCommerce).
Console navigateur : plus aucune ligne “Mixed Content”.
Onglet Network : aucun asset bloqué, et les CSS/JS répondent en 200.
Vérifier le HTML source : liens canonical, og:url, scripts, styles doivent être en HTTPS.

Test WP-CLI simple

Après la migration, j’aime bien vérifier s’il reste des occurrences en base :

# Cherche les occurrences restantes (ne modifie rien)
wp db query "SELECT COUNT(*) AS nb FROM wp_posts WHERE post_content LIKE '%http://exemple.com%';"

Adaptez wp_posts si vous avez un préfixe différent.

Si ça ne marche toujours pas

Identifiez UNE URL HTTP exacte dans la console, copiez-la, puis cherchez sa source :
- si c’est un fichier du thème : cherchez dans le code (grep),
- si c’est une image : cherchez dans la page (éditeur) ou en base,
- si c’est externe : vérifiez si le fournisseur supporte HTTPS.
Vérifiez les conflits :
- Activez “Troubleshooting mode” via Health Check pour désactiver les plugins uniquement pour vous.
- Testez avec un thème par défaut (sur staging) pour voir si le thème injecte l’URL.
Contrôlez le cache :
- Si vous utilisez Cloudflare : “Purge Everything” (temporaire) + vérifiez que l’origin sert bien en HTTPS.
- Regardez les headers (cf-cache-status, x-cache).
Vérifiez la détection HTTPS :
- si is_ssl() est faux derrière un proxy, appliquez Solution 3.
Inspectez les enqueues :
- Query Monitor → “Scripts” / “Styles” → repérez une URL en HTTP.
Regardez les logs PHP (si vous avez touché au code) :
- wp-content/debug.log (si WP_DEBUG_LOG activé),
- logs serveur (php-fpm, nginx/apache).
Permaliens : si vous avez des redirections bizarres après migration, ré-enregistrez Réglages → Permaliens (ça regen les rewrite rules).

Cas tordu que je vois en pratique : contenu mixte injecté par un script de tracking

Certains scripts (anciens tags) chargent une ressource http:// dynamiquement. Même si votre HTML est propre, le navigateur bloque ensuite. Dans ce cas :

désactivez temporairement le tag (GTM, plugin analytics),
retestez,
remplacez la ressource par une version HTTPS (ou retirez-la).

Pièges et erreurs courantes

Symptôme / erreur	Cause probable	Solution recommandée
“Mixed Content … has been blocked” sur un CSS	`wp_enqueue_style()` avec URL en dur HTTP	Solution 1 : utiliser `get_stylesheet_directory_uri()` / `plugins_url()`
Ça marche en local, pas en prod	CDN/proxy modifie le schéma, cache différent	Solution 3 + purge CDN + vérifier headers
Elementor/Divi : mise en page cassée après search/replace SQL	Sérialisation cassée	Restaurer backup DB + refaire via WP-CLI (Solution 2)
Erreur PHP : `unserialize(): Error at offset ...`	Remplacement SQL direct dans `wp_options`/`wp_postmeta`	Restaurer DB + WP-CLI search-replace
Le snippet ne fonctionne pas / écran blanc	Code copié au mauvais endroit, point-virgule manquant	Mettre le code dans un thème enfant, vérifier `debug.log`
URLs encore en HTTP après correction	Cache navigateur/CDN sert une version ancienne	Purge + test incognito + vérifier l’origin
WordPress génère des liens en HTTP	`is_ssl()` faux derrière proxy	Solution 3 (headers + fallback wp-config.php)

Erreurs humaines que je vois tout le temps

Copier un snippet dans un plugin de snippets, puis oublier qu’il est actif sur toutes les pages (et casser le site après une faute de syntaxe).
Utiliser le mauvais hook (ex: modifier des URL dans init alors que le problème vient d’un enqueue sur wp_enqueue_scripts).
Oublier de vider le cache (surtout Cloudflare) et croire que “ça n’a rien changé”.
Tester directement en production sans export DB. Le jour où un builder casse, il n’y a plus de retour arrière propre.
Suivre un tutoriel d’avant 2020 qui recommande des remplacements globaux dans the_content ou des requêtes SQL brutes.

Variante / alternative

Méthode sans code : plugin de correction de contenu mixte

Vous avez demandé “sans plugin”, et je maintiens que c’est la meilleure approche pour un correctif durable. Cela dit, dans une urgence (site en prod, pas d’accès SSH, pas de staging), un plugin de “mixed content fix” peut servir de béquille temporaire.

Le compromis : ces plugins injectent souvent des filtres de sortie (output buffering) ou des remplacements à la volée. Ça peut :

ajouter du CPU,
masquer un vrai problème de config proxy,
casser des URLs signées (CDN privé, API).

Si vous passez par là, faites-le temporairement, puis revenez aux Solutions 1–3.

Méthode plus avancée : CSP “upgrade-insecure-requests”

Une Content Security Policy peut demander au navigateur de tenter un upgrade automatique des requêtes HTTP vers HTTPS. C’est pratique pour des images/iframes, mais ce n’est pas une correction serveur et ça ne marche pas si la ressource n’existe pas en HTTPS.

Je ne le recommande pas comme solution principale, mais comme filet de sécurité sur un parc de pages legacy.

Éviter ce problème à l’avenir

Ne stockez pas d’URL absolues quand vous pouvez stocker des IDs (médias, logos, images de fond). Utilisez les fonctions WordPress qui reconstruisent l’URL.
Dans le code, n’écrivez jamais http:// en dur pour des ressources internes. Utilisez :
- get_stylesheet_directory_uri(), get_template_directory_uri()
- plugins_url() / plugin_dir_url( __FILE__ )
- wp_upload_dir() si vous devez viser uploads (rare)
Sur un site derrière proxy/CDN : validez une fois pour toutes que is_ssl() est vrai en prod. C’est la différence entre un site stable et un site qui régénère des URLs HTTP au hasard.
Après migration :
- faites un wp search-replace en staging,
- puis scannez 10–20 pages clés,
- puis seulement déployez en prod.
Performance : évitez les remplacements dynamiques via filtres de contenu. Corrigez à la source (code/DB). C’est plus rapide et plus fiable.

Snippet “hygiène” : refuser les URL HTTP internes lors d’un enqueue (optionnel)

Sur des projets d’équipe, j’ajoute parfois un garde-fou en dev/staging. Ça n’empêche pas tout, mais ça attrape vite un enqueue mal écrit.

<?php
// functions.php (plutôt en environnement de dev/staging)
add_filter( 'script_loader_src', 'bpcab_refuser_http_interne', 10, 2 );
add_filter( 'style_loader_src', 'bpcab_refuser_http_interne', 10, 2 );

function bpcab_refuser_http_interne( $src, $handle ) {
	// Ne touchez pas aux URLs vides
	if ( empty( $src ) ) {
		return $src;
	}

	$home = home_url();

	// Si la ressource pointe vers votre domaine en http://, on log pour corriger à la source
	if ( str_starts_with( $src, 'http://' ) && str_contains( $src, parse_url( $home, PHP_URL_HOST ) ) ) {
		if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
			error_log( sprintf( '[HTTPS] Enqueue HTTP détecté (%s) : %s', $handle, $src ) );
		}
	}

	return $src;
}

Note : str_starts_with() nécessite PHP 8+ (OK avec votre cible 8.1). Docs : str_starts_with (php.net)

Ressources

Questions fréquentes

Est-ce que WordPress 6.9.4 corrige automatiquement le contenu mixte ?

Non. WordPress peut générer des URL correctes si la config HTTPS est bonne, mais il ne peut pas deviner que du contenu stocké (posts/options) doit être réécrit. Les navigateurs, eux, bloquent.

Dois-je remplacer toutes les occurrences de “http://” par “https://” ?

Non, pas aveuglément. Remplacez uniquement votre domaine (ou vos anciens domaines) et uniquement ce qui doit être en HTTPS. Certaines URLs externes ne supportent pas HTTPS, et certaines URLs signées ne doivent pas être modifiées.

Pourquoi un simple UPDATE SQL casse Elementor/Divi/Avada ?

Parce que beaucoup de données sont sérialisées (ou structurées) et incluent des longueurs. Un remplacement SQL modifie la chaîne sans mettre à jour ces longueurs. WP-CLI search-replace sait gérer ça.

Je suis sur Cloudflare, tout est en HTTPS, mais j’ai encore des Mixed Content. Pourquoi ?

Deux causes fréquentes : (1) Cloudflare sert en HTTPS, mais l’origin fournit encore des HTML/assets avec des URL HTTP (cache ou base non corrigée). (2) WordPress ne détecte pas HTTPS côté origin (proxy), et génère des URL HTTP.

Les images en HTTP sont parfois “upgraded” automatiquement, c’est bon signe ?

Ça dépend. Certains navigateurs tentent un upgrade pour des images, mais pas pour des scripts/CSS. Et si l’image n’existe pas en HTTPS, vous aurez des erreurs intermittentes. Corrigez quand même à la source.

Je peux corriger uniquement avec une redirection 301 HTTP → HTTPS ?

Non. Une redirection force l’accès au site en HTTPS, mais elle ne change pas les URLs intégrées dans vos pages. Le navigateur verra toujours “page HTTPS qui demande une ressource HTTP” et bloquera.

Que faire si une ressource externe n’existe pas en HTTPS ?

Remplacez-la (autre fournisseur), auto-hébergez-la (si la licence le permet), ou supprimez-la. Pour un script, il n’y a pas de contournement propre : il sera bloqué.

Après correction, je vois encore du HTTP mais seulement pour moi. Normal ?

Souvent oui : cache navigateur, service worker, cache CDN régional, ou une extension qui injecte un script. Testez en navigation privée, puis depuis un autre réseau, et purgez le CDN.

Faut-il modifier `WP_HOME` / `WP_SITEURL` dans wp-config.php ?

Seulement si vous avez une bonne raison (environnements multiples, config immuable). Sinon, les valeurs en base suffisent. Si vous les définissez dans wp-config.php, assurez-vous qu’elles sont en HTTPS, sinon vous “réintroduisez” le problème.