Contenu mixte : votre site HTTPS s’affiche « non sécurisé »

Le symptôme

Votre site est en HTTPS. Le certificat est valide, il ne périme pas avant des mois, et pourtant quelque chose ne va pas : l’indicateur du navigateur n’est pas celui d’une page saine, une image ne s’affiche plus, un widget a disparu, ou la mise en page s’est effondrée d’un coup sans que personne n’ait rien touché.

Dans la quasi-totalité des cas, il s’agit de contenu mixte : la page elle-même est servie en https://, mais elle appelle au moins une ressource en http://. Une image, un script, une police, une feuille de style. Le navigateur considère — à juste titre — que la chaîne est rompue : il ne sert à rien de chiffrer une page si un tiers peut en modifier le JavaScript au passage.

C’est un problème sournois pour une raison précise : il ne se voit pas forcément chez vous. Votre navigateur a peut-être mis la ressource en cache avant la migration, ou vous avez cliqué un jour sur « autoriser le contenu non sécurisé » et l’exception vous suit. La page paraît normale à son propriétaire et cassée pour tout le monde. C’est aussi pour cela qu’un diagnostic depuis l’extérieur vaut mieux qu’un coup d’œil sur son propre écran.

Deux messages de console, deux problèmes différents

Ouvrez la console du navigateur (F12, onglet Console) et rechargez la page. Vous verrez l’un de ces deux messages, ou les deux. La plupart des articles sur le sujet les traitent comme s’il s’agissait de la même chose. Ils ne le sont pas.

La répartition entre les deux catégories est fixée par les navigateurs, pas par vous :

• Bloqué sans discussion : <script src>, les feuilles de style (<link> et @import), <iframe>, <object>, les polices web, les appels fetch() et XMLHttpRequest, les WebSocket. Ce sont les ressources capables de modifier la page : les laisser passer en clair viderait le HTTPS de son sens.
• Surclassé automatiquement : <img src>, <audio>, <video>, <source> et les url() d’images en CSS. Ces ressources ne peuvent qu’altérer l’apparence de la page, jamais son comportement ; les bloquer d’emblée casserait trop de sites pour un gain de sécurité modeste.

Un détail qui surprend : le surclassement automatique ne s’applique pas aux adresses IP littérales. Une image appelée sur http://93.184.215.14/logo.png n’est pas réécrite ; elle est bloquée. Si vous servez encore des médias depuis l’adresse IP d’un ancien serveur, vous êtes dans le cas bloquant sans le savoir.

Pourquoi le surclassement n’est pas un correctif

C’est le piège central de ce sujet, et il mérite qu’on s’y arrête. Quand le navigateur surclasse une image de http:// vers https://, il fait une tentative — il ne garantit rien. Et surtout : si la version HTTPS échoue, il n’y a pas de retour au HTTP. La requête est simplement abandonnée et l’image n’apparaît pas.

Concrètement, une ressource surclassée disparaît dès que l’hôte distant présente le moindre défaut : pas de HTTPS du tout, certificat expiré, certificat qui ne couvre pas ce sous-domaine, chaîne de certification incomplète. Autrement dit, votre page dépend désormais de l’hygiène de certificat d’un tiers sur lequel vous n’avez aucune prise, et la panne se produira un jour où vous n’aurez rien changé. Une ressource surclassée n’est pas un problème résolu, c’est un problème en sursis.

Ajoutez à cela que le surclassement varie d’un navigateur et d’une version à l’autre, et que l’utilisateur peut le désactiver dans ses paramètres. Un site qui repose dessus s’affiche différemment selon les visiteurs. Ce n’est pas une base acceptable.

Trouver toutes les occurrences

Le premier réflexe — recharger la page et lire la console — donne un point de départ, mais il est trompeur pour trois raisons : il ne couvre que la page ouverte, il ne montre pas les ressources déjà en cache, et il dépend des exceptions enregistrées dans votre navigateur. Trois approches complémentaires :

1. Le code source brut. Ctrl+U, puis une recherche sur la chaîne http://. Attention aux faux positifs : les xmlns, les @context de données structurées et les adresses citées dans un texte ne sont jamais chargées par le navigateur. Ce qui compte, ce sont les attributs src, href, srcset, data, action et poster.
2. Une navigation privée, sans extension. Elle élimine le cache et les exceptions par site, qui sont la première cause de « chez moi ça marche ».
3. Un contrôle depuis l’extérieur. C’est le seul qui vous montre ce que voit un visiteur qui découvre votre site. Notre outil d’analyse charge votre page depuis nos serveurs, liste les ressources appelées en http:// et — c’est l’essentiel — sépare celles qui sont bloquées de celles qui sont seulement surclassées.

Une page suffit rarement. Le contenu mixte se cache surtout dans les gabarits partagés (en-tête, pied de page, barre latérale) et dans les vieux articles où une image a été collée à la main avec son adresse complète. Vérifiez au minimum l’accueil, une page de contenu ancienne et une page de formulaire.

Corriger à la source

La bonne correction consiste à réécrire les adresses. Trois formes possibles, par ordre de préférence :

• Chemin relatif à la racine — /images/logo.png. À utiliser chaque fois que la ressource est hébergée chez vous. C’est la forme la plus robuste : elle survit à un changement de domaine comme à un changement de protocole.
• Adresse complète en HTTPS — https://cdn.exemple.fr/x.js. Nécessaire pour les ressources tierces. Vérifiez que l’hôte répond réellement en HTTPS avant de basculer ; voir la section suivante.
• Adresse relative au protocole — //cdn.exemple.fr/x.js. À éviter aujourd’hui. Cette forme date d’une époque où un même site existait en HTTP et en HTTPS. Ce n’est plus le cas, elle complique la lecture du code et casse hors navigateur (aperçus, moulinettes, courriels). Elle traîne encore dans beaucoup de tutoriels ; ce n’est pas une raison pour l’écrire en 2026.

Le piège WordPress : la sérialisation

Sur un site WordPress, les adresses en dur ne sont pas seulement dans les fichiers du thème : elles sont dans la base de données, dans le contenu des articles, dans les options et dans les réglages d’extensions. La tentation est de lancer un UPDATE … SET … REPLACE(…) en SQL sur toute la base. Ne le faites pas.

WordPress stocke une grande partie de ses réglages sous forme de tableaux PHP sérialisés, un format qui préfixe chaque chaîne par sa longueur en caractères : s:27:"http://exemple.fr/logo.png". Remplacer http:// par https:// allonge la chaîne d’un caractère sans mettre le compteur à jour. Le résultat est une donnée illisible : réglages d’extensions perdus, widgets vidés, options de thème réinitialisées. Le dégât n’apparaît pas tout de suite, et il est pénible à défaire.

Utilisez un outil qui comprend la sérialisation. En ligne de commande : wp search-replace 'http://exemple.fr' 'https://exemple.fr' --all-tables --dry-run — le --dry-run annonce ce qui serait modifié sans rien écrire, et il n’y a aucune raison de s’en passer. Sans accès SSH, les extensions de recherche-remplacement sérialisée font le même travail. Dans tous les cas, une sauvegarde de la base avant, pas après.

Pensez aussi à mettre à jour les deux réglages siteurl et home, et à vérifier que votre redirection HTTP vers HTTPS est bien en place côté serveur.

Quand la ressource tierce n’a pas de HTTPS

Il reste des cas où l’hôte distant ne propose tout simplement pas de HTTPS. En 2026, c’est devenu rare, et cela dit quelque chose : un service qui n’a pas migré en dix ans n’est probablement plus maintenu. Trois issues, dans l’ordre :

1. Rapatrier la ressource chez vous. Pour une image, une police ou un script figé, c’est l’affaire de quelques minutes — et cela supprime au passage la fuite d’adresses IP de vos visiteurs vers un tiers, exactement comme pour les polices Google.
2. Changer de fournisseur. Pour un widget, une carte, un lecteur vidéo, il existe presque toujours un équivalent moderne servi en HTTPS.
3. Retirer la ressource. Une fonctionnalité qui casse le HTTPS de tout un site pour un bénéfice marginal ne mérite pas qu’on la garde.

Ce qu’il ne faut pas faire : demander aux visiteurs d’autoriser le contenu non sécurisé dans leurs réglages. Aucun d’entre eux ne le fera, et ceux qui le feraient n’auraient pas dû.

upgrade-insecure-requests : un pansement, pas une réparation

L’en-tête suivant demande au navigateur de réécrire en HTTPS toutes les ressources appelées en clair, y compris celles de la catégorie bloquante :

Content-Security-Policy: upgrade-insecure-requests

C’est utile — pendant une migration, sur un site ancien dont on ne peut pas réécrire tout le contenu d’un coup. Mais il faut savoir ce que cette ligne ne fait pas :

• Elle ne répare rien. Les adresses restent fausses dans votre base et dans vos fichiers, et vous héritez du problème du surclassement décrit plus haut : si la version HTTPS échoue, la ressource disparaît.
• Elle ne remplace pas HSTS. Elle ne s’applique pas à la navigation elle-même : un visiteur qui arrive sur votre site par un lien en http:// depuis un site tiers n’est pas protégé. Seul Strict-Transport-Security couvre ce cas — les deux se complètent, ils ne se substituent pas l’un à l’autre.
• Elle ne surclasse pas vos liens sortants. Un <a href="http://autre-site.fr"> reste tel quel, par choix délibéré des navigateurs : réécrire une navigation vers un tiers casserait trop de choses. C’est précisément ce qui devient gênant en octobre 2026.

Et un avertissement : si vous croisez block-all-mixed-content dans un tutoriel, c’est que le tutoriel est périmé. Cette directive est dépréciée et n’a plus d’effet utile. Ne la recopiez pas.

Octobre 2026 : vos liens sortants deviennent un problème

Google a annoncé en octobre 2025 le calendrier d’activation par défaut de l’option « Toujours utiliser des connexions sécurisées » dans Chrome. Elle affiche un avertissement — franchissable, mais bien visible — avant d’ouvrir un site public en http:// :

Les sites privés — adresses IP locales, noms sans point, intranets — sont exclus du dispositif. Pour un site public, la conséquence est directe et souvent négligée : chaque lien en http:// que vous pointez enverra vos visiteurs sur un écran d’avertissement. Pas votre site : le site d’en face. Un lien vers un partenaire, une source, une administration, un vieux billet de blog — et votre lecteur voit un écran rouge après avoir cliqué chez vous.

Le ménage est simple et vaut la peine d’être fait avant octobre : passez vos liens sortants en revue, essayez la version https:// de chacun, et corrigez ceux qui répondent. Ceux qui ne répondent toujours pas en HTTPS pointent vers des sites qui seront de toute façon devenus difficiles d’accès ; c’est le bon moment pour décider s’ils méritent encore un lien.

Vérifier votre site maintenant

Notre outil d’analyse ouvre votre page depuis nos serveurs, sans cache ni exception locale, et rapporte séparément : les ressources bloquées, les ressources seulement surclassées, et les liens sortants en http:// qui déclencheront un avertissement à partir d’octobre 2026. Il contrôle au passage la validité du certificat, les en-têtes de sécurité et les traceurs déposés avant consentement, qui relèvent de la même hygiène de base.