Comment fonctionne cette vérification
Scanaris lit le HTML de ta page servie en HTTPS et cherche des références à des ressources commençant par http:// : scripts, feuilles de style, iframes, images, vidéos, audio et polices. Il les sépare en deux groupes. Le contenu mixte actif (scripts, styles, iframes) ouvre un constat de sévérité moyenne, parce que ces ressources peuvent exécuter du code ou modifier la page. Le contenu mixte passif (images, vidéo, audio) ouvre un constat de sévérité faible : il n'exécute rien, mais il voyage en clair et casse le cadenas. Seules les références présentes dans le HTML initial sont examinées ; les ressources ajoutées ensuite par JavaScript ne sont pas vues par cette voie.
Pourquoi c'est important
Un script chargé en HTTP dans une page HTTPS est le pire des cas : celui qui contrôle le réseau peut le remplacer par un autre et exécuter ce qu'il veut dans ta page, avec la session de l'utilisateur. C'est pour ça que les navigateurs modernes le bloquent purement et simplement, et que ton site se casse en silence sur cette partie. Pour les images, le navigateur les charge mais retire le cadenas ou affiche un avertissement « non sécurisé », ce que voit l'utilisateur. Dans les deux cas, le message est le même : la page prétend être sûre et ne l'est pas tout à fait.
D'où ça vient
Presque toujours de vieux code : des URL copiées d'un tutoriel ou d'un template d'il y a des années, une bibliothèque liée depuis un CDN qui n'avait pas HTTPS à l'époque, des images d'un blog migré, ou un champ de base de données avec l'URL complète d'une image envoyée quand le site était encore en HTTP. Sous WordPress, c'est typique après un passage de HTTP à HTTPS sans mise à jour des URL stockées.
Comment corriger
- Change les références en https:// ou en chemins relatifs (
/images/photo.jpg), qui héritent du protocole de la page. C'est la solution correcte et définitive. - Si une ressource externe n'a pas de HTTPS, télécharge-la et sers-la depuis ton domaine, ou trouve une autre source. En 2026, presque rien de légitime n'est encore en HTTP seul.
- Sous WordPress, mets à jour les URL stockées en base avec un outil de recherche-remplacement qui respecte la sérialisation, et vérifie les URL du site dans les réglages généraux.
- Comme filet de sécurité, la directive CSP
upgrade-insecure-requestsdit au navigateur de convertir automatiquement les requêteshttp://de ta page enhttps://. Ça aide pendant que tu nettoies le code, mais ça ne remplace pas le nettoyage : la ressource doit exister en HTTPS pour que ça marche.
Content-Security-Policy: upgrade-insecure-requests
Vérifie que c'est corrigé
curl -s https://tondomaine.com | grep -oE '(src|href)="http://[^"]+"' | sort -u
Rien ne doit sortir. Ensuite, ouvre la page avec la console du navigateur : toute ressource mixte chargée par JavaScript y apparaît comme avertissement ou blocage.
Questions fréquentes
Ma page charge bien et a le cadenas. Pourquoi est-ce signalé ?
Parce que le navigateur bloque peut-être la ressource en silence ou la passe en HTTPS de lui-même. La référence dans ton HTML reste en http:// et d'autres clients (robots, vieux navigateurs, e-mails) ne font pas cette correction.
Les URL commençant par // sont-elles du contenu mixte ?
Non. Les URL relatives au protocole héritent de celui de la page et chargent en HTTPS sur du HTTPS. Malgré tout, il est recommandé aujourd'hui d'écrire https:// directement.
Un lien <a href="http://…"> compte-t-il ?
Non. Un lien ne charge rien dans ta page ; il emmène seulement l'utilisateur ailleurs. Le contenu mixte, c'est ce que la page intègre.