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
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 <link>, 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 --preciseL’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/themesetwp-content/pluginstoute occurrence dehttp://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.
