# Contenu mixte après le passage en HTTPS : traquer les ressources en http:// > Le certificat est posé, le cadenas reste barré. Voici comment repérer méthodiquement chaque image, script ou iframe encore appelé en clair sur un WordPress. - Auteur : Clément Hadrot - Publié le : 2020-01-24 - Mis à jour le : 2020-01-24 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/contenu-mixte-https-ressources-http/ ## L’essentiel - Console navigateur = premier réflexe - wp_options garde souvent l'ancienne URL - search-replace bat le remplacement manuel Le client a appelé un vendredi après-midi, ce qui n'annonce jamais une bonne nouvelle. Son certificat TLS venait d'être posé la veille par l'hébergeur, la redirection `http` vers `https` fonctionnait, et pourtant Chrome affichait toujours un cadenas barré d'un point d'exclamation orange. « Contenu non sécurisé », disait le message. Le site tournait, les visiteurs pouvaient naviguer, mais l'image de sérieux en prenait un coup à chaque page produit. Ce cas revient plus souvent qu'on ne le pense : basculer un site en HTTPS n'est jamais un simple changement de protocole. Chaque ressource appelée en dur avec un préfixe `http://` continue d'être chargée en clair, et le navigateur le signale sans pitié. Voici la méthode qui permet de retrouver et corriger ces appels résiduels sans y passer la nuit. ## Identifier la source du problème avec les outils du navigateur Avant toute chose, ouvrez la console développeur de Chrome ou Firefox sur la page concernée. L'onglet Console liste chaque ressource bloquée ou signalée comme non sécurisée, avec son URL complète. C'est la piste la plus rapide, bien plus fiable qu'un grep aveugle dans les fichiers du thème. Classez les alertes par type : une image simple n'a pas le même niveau de gravité qu'un script ou une iframe. Les navigateurs modernes bloquent purement et simplement les scripts et polices en `http://` chargés depuis une page `https://`, alors qu'ils se contentent d'afficher un avertissement pour une image. C'est souvent ce qui explique qu'un site « a l'air de marcher » alors que la console hurle. ## Passer wp_options et la base au peigne fin > L'essentiel à retenir : Console navigateur = premier réflexe ; wp_options garde souvent l'ancienne URL ; search-replace bat le remplacement manuel La cause la plus fréquente ne se trouve pas dans le thème mais dans la base de données elle-même. Les options `siteurl` et `home` de la table `wp_options` gardent parfois l'ancien préfixe `http://` si la bascule a été faite uniquement côté serveur, sans jamais toucher WordPress. Vérifiez-les avec WP-CLI : ``` wp option get siteurl wp option get home wp option update siteurl 'https://exemple.fr' wp option update home 'https://exemple.fr' ``` Une fois ces deux options corrigées, la majorité des appels générés dynamiquement par WordPress (les balises ``, les URL de thème, les flux RSS) basculent automatiquement. Mais le contenu déjà enregistré dans `wp_posts`, avec des images ou des liens en dur insérés depuis des années, reste inchangé. C'est là qu'intervient `wp search-replace`, en mode simulation d'abord : ``` wp search-replace 'http://exemple.fr' 'https://exemple.fr' --dry-run wp search-replace 'http://exemple.fr' 'https://exemple.fr' --all-tables --precise ``` L'option `--precise` évite les faux positifs sur des chaînes sérialisées, ce qui est essentiel puisque de nombreux réglages de plugins stockent des tableaux PHP sérialisés dans `wp_options` : un remplacement naïf casserait la longueur déclarée de la chaîne et corromprait la donnée. ## Les pièges classiques du srcset et des thèmes tiers Même après ce nettoyage, certaines images continuent d'apparaître en clair. La cause est souvent l'attribut `srcset` généré par WordPress pour les images responsives : si l'image originale a été uploadée avant la bascule HTTPS et que son URL absolue en base contenait déjà `http://`, le search-replace précédent aurait dû la corriger. Si ce n'est pas le cas, vérifiez que le remplacement a bien couvert la table `wp_postmeta`, où sont stockées les métadonnées d'images (tailles, chemins). Autre source récurrente : les thèmes et extensions qui codent en dur une URL de CDN ou de police externe. Grep reste utile ici, directement sur les fichiers : - Rechercher dans `wp-content/themes` et `wp-content/plugins` toute occurrence de `http://` suivie d'un nom de domaine autre que celui du site (les CDN de polices Google, par exemple). - Vérifier les champs de personnalisation du thème (Customizer) : logo, favicon et image de fond y sont souvent stockés en URL absolue. - Contrôler les widgets de type « texte » ou « HTML personnalisé », qui contiennent fréquemment un lien ou une image collée à la main des années plus tôt. ## Automatiser la détection après correction Une fois le ménage fait, il est tentant de considérer le sujet clos. C'est une erreur : un nouvel article publié demain peut réintroduire un lien en clair copié depuis un ancien brouillon. Un contrôle périodique léger évite de revivre la même alerte client six mois plus tard. Un script shell simple, exécuté en tâche cron hebdomadaire, permet de scanner le contenu publié à la recherche de références en `http://` : ``` wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%http://%' AND post_status='publish'" ``` Ce type de requête ne remplace pas une vigilance éditoriale, mais il alerte rapidement si un contributeur a collé un lien externe ou une image sans passer par la médiathèque. ## En résumé Le contenu mixte n'est jamais un problème de configuration serveur mal faite : c'est un résidu de contenu qui n'a pas suivi la bascule. Corriger `siteurl` et `home`, exécuter un `search-replace` précis sur toute la base, puis traquer les URL codées en dur dans le thème et les widgets suffit à faire disparaître le cadenas barré dans la quasi-totalité des cas. Gardez la console du navigateur comme premier réflexe de diagnostic : elle pointe directement la ressource fautive, sans devoir deviner.