Les avertissements de contenu mixte font partie des problèmes les plus courants que rencontrent les propriétaires de sites WordPress après le passage de HTTP à HTTPS. Ils surviennent quand votre site se charge via une connexion HTTPS sécurisée, mais que certaines ressources de la page (images, scripts, feuilles de style, iframes) sont encore demandées en HTTP en clair. Les navigateurs traitent cela comme un risque de sécurité, à juste titre. La bonne nouvelle, c'est que le contenu mixte est simple à corriger une fois que l'on comprend d'où il vient.
À quoi ressemblent les avertissements de contenu mixte dans votre navigateur
Quand une page comporte du contenu mixte, les navigateurs réagissent différemment selon le type de ressource. Pour le contenu mixte « actif » (scripts, iframes, feuilles de style), la plupart des navigateurs bloquent entièrement la ressource et affichent un avertissement dans la console développeur. Pour le contenu mixte « passif » (images, audio, vidéo), la ressource peut quand même se charger, mais l'icône du cadenas dans la barre d'adresse disparaîtra ou affichera un triangle d'avertissement.
Dans Chrome, vous verrez des messages comme « Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource » dans la console. Firefox affiche un cadenas gris avec un triangle d'avertissement. Safari peut bloquer silencieusement certaines ressources sans retour visuel évident, ce qui rend le débogage plus délicat.
Le résultat pratique : votre site paraît cassé aux visiteurs. Les images peuvent ne pas se charger, les styles peuvent manquer et les scripts peuvent échouer. Pire, Google considère HTTPS comme un signal de classement, donc les problèmes de contenu mixte peuvent indirectement nuire à votre SEO.
Comment trouver toutes les sources de contenu mixte sur votre site
Avant de pouvoir corriger quoi que ce soit, vous avez besoin d'une liste complète des ressources HTTP chargées. Plusieurs méthodes fiables existent :
- Analyse InspectWP : lancez une analyse de votre site. La section HTML liste chaque URL non sécurisée trouvée sur la page, vous donnant un inventaire clair de ce qui doit être corrigé.
- Console DevTools du navigateur : ouvrez les outils de développement de votre navigateur (F12 ou Cmd+Maj+I sur Mac), allez dans l'onglet Console et rechargez la page. Chaque avertissement de contenu mixte apparaîtra ici avec l'URL exacte de la ressource fautive.
- Outil Why No Padlock : visitez whynopadlock.com et entrez votre URL. Il explore la page et signale toutes les ressources non sécurisées dans une liste simple.
- Test SSL Labs : bien qu'il serve principalement à vérifier votre certificat SSL, le test Qualys SSL Labs peut aussi signaler les problèmes de contenu mixte.
Pour les sites comportant de nombreuses pages, vous voudrez vérifier autre chose que la page d'accueil. Testez les pages de destination clés, les articles de blog (surtout les plus anciens) et toutes les pages avec des médias intégrés ou du contenu tiers.
Causes courantes de contenu mixte dans WordPress
Le contenu mixte vient rarement d'une seule source. Voici les coupables les plus fréquents :
- URL HTTP codées en dur dans le contenu des articles : si vous avez créé des articles et des pages avant le passage à HTTPS, toutes les URL d'images, les liens et les médias intégrés dans l'éditeur de contenu utiliseront encore
http://. WordPress les enregistre en URL absolues dans la base de données. - Fichiers de thème avec URL codées en dur : certains thèmes codent en dur les chemins d'images ou les URL de ressources externes avec
http://au lieu d'utiliser des URL relatives au protocole ou des fonctions WordPress. - Ressources d'extensions : les extensions plus anciennes ou mal maintenues peuvent charger leurs fichiers CSS et JavaScript avec des URL HTTP.
- Intégrations externes et iframes : les intégrations Google Maps, les vidéos YouTube (anciens codes d'intégration), les widgets de réseaux sociaux et les scripts publicitaires utilisent parfois HTTP.
- CSS personnalisé ou contenu de widget : images de fond, imports de polices ou autres ressources spécifiées dans des champs CSS personnalisés ou des widgets texte.
- Configuration CDN : si vous utilisez un CDN, il pourrait être configuré pour servir les ressources via HTTP plutôt que HTTPS.
Étape 1 : mettre à jour les URL WordPress et du site
Avant tout, assurez-vous que vos URL WordPress de base sont correctes. Allez dans Réglages, puis Général et vérifiez que l'adresse web de WordPress (URL) et l'adresse du site (URL) commencent toutes deux par https://. Si elles affichent encore http://, mettez-les à jour et enregistrez. Cela indique à WordPress de générer tous les liens internes en HTTPS.
Étape 2 : rechercher et remplacer les URL HTTP dans la base de données
La correction la plus efficace pour la grande majorité du contenu mixte est une recherche-remplacement à l'échelle de la base de données. Cela attrape les URL codées en dur dans les articles, les pages, les textes de widgets, les champs personnalisés, les options de thème et les données sérialisées.
Avec WP-CLI (la méthode recommandée pour qui maîtrise la ligne de commande) :
# Toujours faire un essai à blanc d'abord pour voir ce qui sera changé
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run
# Vérifiez attentivement la sortie, puis exécutez pour de vrai
wp search-replace 'http://example.com' 'https://example.com' --all-tables
# Si votre site utilise aussi le sous-domaine www, exécutez les deux variantes
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tablesWP-CLI gère correctement les données sérialisées, ce qui est essentiel. De nombreuses extensions stockent les paramètres sous forme de tableaux sérialisés dans la base de données, et un simple search-and-replace SQL casserait le format de sérialisation.
Corriger le contenu mixte avec l'extension Better Search Replace
Si vous n'avez pas accès à la ligne de commande, l'extension Better Search Replace fournit une alternative conviviale :
- Installez et activez Better Search Replace depuis le répertoire des extensions WordPress.
- Allez dans Outils, puis Better Search Replace.
- Dans le champ « Rechercher », entrez
http://example.com(votre vrai domaine). - Dans le champ « Remplacer par », entrez
https://example.com. - Sélectionnez toutes les tables dans la liste (Ctrl+A ou Cmd+A).
- Cochez d'abord « Exécuter en essai à blanc », puis cliquez sur « Lancer la recherche/remplacement ».
- Examinez les résultats. Si les remplacements semblent corrects, décochez « Exécuter en essai à blanc » et relancez.
Après le remplacement, videz tous les caches d'extensions de cache et vérifiez à nouveau votre site.
Utiliser Really Simple SSL comme correction rapide
L'extension Really Simple SSL adopte une approche différente. Au lieu de corriger les URL dans la base de données, elle réécrit dynamiquement les URL HTTP en HTTPS à la volée via le tampon de sortie et les filtres WordPress. Installez-la, activez-la, et elle s'occupe du reste automatiquement.
Cela fonctionne bien comme correction immédiate, mais ajoute un petit surcoût de traitement à chaque chargement de page. Pour de meilleures performances, il vaut mieux corriger les URL à la source (au niveau de la base de données) puis désactiver l'extension. Considérez Really Simple SSL comme un filet de sécurité plutôt qu'une solution permanente.
Corriger manuellement les fichiers de thèmes et d'extensions
Une partie du contenu mixte provient d'URL codées en dur dans les fichiers de thèmes ou d'extensions plutôt que de la base de données. Recherchez les références http:// dans le répertoire de votre thème actif :
# Rechercher des URL HTTP codées en dur dans votre thème
grep -r "http://" /path/to/wp-content/themes/your-theme/ --include="*.php" --include="*.css" --include="*.js"Remplacez toute URL HTTP codée en dur par HTTPS, ou mieux encore, utilisez des URL relatives au protocole (//example.com/resource.js) ou des fonctions WordPress comme esc_url() qui respectent le réglage de protocole du site.
Pour les extensions tierces, ne modifiez pas directement les fichiers d'extension (les mises à jour écraseraient vos modifications). Contactez plutôt l'auteur de l'extension ou cherchez une version plus récente prenant en charge HTTPS. Si une extension charge constamment ses ressources en HTTP, envisagez de la remplacer par une alternative mieux maintenue.
Ajouter une redirection HTTP vers HTTPS
Après avoir corrigé tout le contenu mixte dans la base de données et les fichiers, mettez en place une redirection au niveau serveur pour que toute requête HTTP restante soit automatiquement redirigée vers HTTPS :
# À ajouter au .htaccess (Apache)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Pour les serveurs Nginx, ajoutez ceci à votre bloc serveur :
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}Forcer HTTPS dans wp-config.php
Si votre site est derrière un reverse proxy ou un équilibreur de charge, WordPress peut ne pas détecter HTTPS correctement. Ajoutez ce qui suit à votre fichier wp-config.php :
define('FORCE_SSL_ADMIN', true);
// Si derrière un reverse proxy ou un équilibreur de charge
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}Vérifier vos corrections et prévenir tout futur contenu mixte
Après avoir effectué toutes les modifications, lancez une nouvelle analyse InspectWP. La liste des URL non sécurisées dans la section HTML doit être vide. Ouvrez aussi la console développeur de votre navigateur et confirmez qu'aucun avertissement de contenu mixte n'apparaît.
Pour empêcher le contenu mixte de revenir :
- Définir un en-tête Content-Security-Policy : ajouter
Content-Security-Policy: upgrade-insecure-requestsen en-tête de réponse indique aux navigateurs de mettre automatiquement à niveau les requêtes HTTP en HTTPS. Bon filet de sécurité. - Utiliser des URL relatives ou HTTPS : quand vous intégrez manuellement des images ou des ressources, utilisez toujours
https://ou des URL relatives au protocole. - Vérifier les intégrations tierces : avant de coller des codes d'intégration de services externes, vérifiez qu'ils utilisent HTTPS.
- Auditer régulièrement : configurez des rapports InspectWP automatiques pour détecter tout contenu mixte qui apparaîtrait après des mises à jour de contenu ou des changements d'extensions.