Vous ouvrez votre console un matin, et là, une avalanche de lignes rouges. Mixed Content: The page at 'https://…' was loaded over HTTPS, but requested an insecure script. Le site fonctionne. Mais le cadenas a disparu, et Chrome affiche un « Non sécurisé » que vos visiteurs verront avant même de lire votre contenu.
J'ai connu ça sur un site que je gérais il y a quelques mois : migration HTTPS faite en une soirée, cadenas vert partout… sauf sur les pages de catégorie. Un widget de notation produit chargeait encore une image en http:// et une bannière publicitaire injectée par un partenaire appelait un script non chiffré. Résultat : environ un tiers des pages du site étaient signalées comme non sécurisées par le navigateur, et je ne l'ai vu qu'après une plainte d'un visiteur.
Le contenu mixte, c'est ça : le problème le plus bête de la migration HTTPS, et celui que presque tout le monde rate.
Points clés à retenir
- Le contenu mixte, c'est une page servie en HTTPS qui va chercher des ressources en HTTP : le lien n'est alors plus chiffré de bout en bout.
- Les navigateurs bloquent désormais les ressources actives (scripts, iframes, CSS) et signalent les passives (images, vidéos). Le cadenas disparaît dans les deux cas.
- La cause n'est presque jamais le code que vous avez écrit : c'est un widget tiers, un CDN mal configuré ou une URL absolue oubliée dans une base de données.
- Le diagnostic tient en trois gestes : console DevTools filtrée sur
mixed-content, inspection de la source HTML, et recherche deshttp://résiduels. - L'en-tête CSP
upgrade-insecure-requestscorrige beaucoup de cas en une ligne, mais ne remplace pas un vrai nettoyage.
Le contenu mixte : pourquoi HTTPS ne suffit pas à vous rendre sûr
Quand un navigateur charge une page en HTTPS, il s'attend à ce que toutes les ressources qui composent cette page arrivent par le même canal chiffré. Si une seule image, un seul script, une seule police d'écriture arrive en HTTP, la règle est rompue : un attaquant sur le réseau peut modifier cette ressource en transit, et par ricochet injecter du code dans une page que vous croyez protégée.
Contenu mixte actif ou passif : la différence qui change tout
Les navigateurs ne traitent pas tout de la même manière. Le contenu actif peut exécuter du code ou modifier le DOM : scripts JavaScript, iframes, feuilles de style, objets <object>. Celui-là est bloqué purement et simplement, parce que l'impact est immédiat.
Le contenu passif se contente de s'afficher : images, sons, vidéos. Il est souvent « mis à niveau » automatiquement ou affiché avec un avertissement, mais le cadenas saute quand même.
Une distinction que je vois souvent mal comprise : une image bloquée n'empêche pas la page de fonctionner, donc on ne la remarque pas. Un script bloqué, lui, casse des fonctionnalités. C'est le passif qui est le plus insidieux.
Le diagnostic pas à pas : trouver la ressource coupable
Avant de corriger, il faut localiser. Et là, franchement, la console du navigateur fait 80 % du travail.
Étape 1 : la console filtrée
- Ouvrez la page concernée dans Chrome ou Firefox.
- Ouvrez les DevTools (F12, ou clic droit > Inspecter).
- Direction l'onglet Console ou Sécurité selon le navigateur.
- Tapez
mixed-contentdans le champ de filtre. - Chaque ligne rouge vous donne l'URL exacte de la ressource fautive et son type.
Sur le site dont je parlais plus haut, cette simple manipulation a identifié sept ressources en quelques secondes : trois images de widget, deux scripts de tracking, une police Google Fonts et un iframe YouTube.
Étape 2 : l'inspection de la source et des fichiers
La console ne voit que ce qui s'exécute. Un http:// oublié dans une balise srcset ou dans un url() CSS peut passer inaperçu si la ressource est en cache.
Deux commandes utiles en local :
curl -sI https://votre-site.compour vérifier les en-têtes renvoyés par le serveur.- Un
grep -rn "http://"sur le dossier des templates et des fichiers statiques, en excluant les commentaires et les URL de documentation.
Étape 3 : n'oubliez pas la base de données
Le piège que j'ai mis trois semaines à comprendre sur un projet client : les URL des images étaient stockées en dur dans la base, saisies à l'époque de WordPress 4.x. Le thème était propre, le serveur était propre, mais chaque article ré-affichait une image en HTTP.
Un SELECT avec un LIKE '%http://%' sur les tables de contenu, et le tour était joué.
Corriger : les méthodes classées par efficacité
Toutes les corrections ne se valent pas. Voici comment je les hiérarchise aujourd'hui.
| Méthode | Effort | Couverture | Limite |
|---|---|---|---|
| Réécriture des URL dans le code et la base | Élevé | Définitive | Long, risqué en cas d'oubli |
| Réécriture serveur / plugin de migration | Moyen | Bonne sur les contenus gérés | Ne touche pas aux ressources externes |
En-tête CSP upgrade-insecure-requests | Faible | Très large | Pas supporté partout, masque le problème |
| HSTS avec préchargement | Moyen | Force HTTPS côté navigateur | Ne corrige pas les URL fautives |
| Correction via le fournisseur tiers | Variable | Nécessaire pour les widgets | Dépend d'un tiers que vous ne contrôlez pas |
La solution en une ligne : upgrade-insecure-requests
Ajoutez cet en-tête à votre configuration serveur ou dans une balise meta :
Content-Security-Policy: upgrade-insecure-requests
Le navigateur remplace automatiquement chaque appel HTTP par HTTPS. Pratique pour un site existant dont vous ne pouvez pas tout auditer, mais attention : si la ressource n'existe pas en HTTPS côté tiers, vous obtenez une erreur 404 au lieu du contenu attendu. Je l'utilise en filet de sécurité, jamais comme correction unique.
Les cas que presque tout le monde oublie
Les ressources chargées « en dur » dans votre HTML, c'est la partie facile. Le vrai problème vient d'ailleurs.
- Les polices d'écriture : un
@importen HTTP dans votre CSS, et c'est toute la page qui perd son cadenas. - Les iframes vidéo : un lecteur intégré sans le paramètre HTTPS casse le lien.
- Les pixels de tracking et les scripts tiers : souvent les derniers à être audités, et les plus fréquents.
- Les balises srcset : si vous ne fournissez qu'une seule URL en HTTP dans une liste de variantes, c'est celle-ci qui sera choisie par le navigateur sur certains écrans.
- Un service worker enregistré en HTTP qui continue de servir du cache après votre migration.
Les questions qu'on me pose souvent
Comment enlever le blocage de site ?
Si votre navigateur affiche un écran d'avertissement « Votre connexion n'est pas privée » ou « Site non sécurisé », il ne s'agit pas d'un blocage de votre site à proprement parler : le navigateur signale que la connexion n'est pas chiffrée ou que le certificat est invalide. Trois vérifications dans l'ordre : le certificat est-il valide et non expiré, la date de votre système est-elle correcte (un décalage d'horloge provoque ce type d'erreur, c'est bête mais fréquent), et l'URL est-elle bien en https:// et non en http:// ? Une fois ces trois points réglés, l'avertissement disparaît au rechargement suivant.
Pourquoi est-ce que je ne peux pas accéder aux sites commençant par HTTPS ?
L'impossibilité d'accéder à un site en HTTPS vient très rarement du protocole lui-même. Les causes plausibles : certificat expiré ou mal installé côté serveur, nom d'hôte qui ne correspond pas au certificat, pare-feu ou proxy d'entreprise qui intercepte la connexion, ou antivirus configuré pour inspecter le trafic chiffré. Le message d'erreur du navigateur indique laquelle de ces causes est en jeu ; il faut le lire, pas le contourner en cliquant sur « continuer ».
Comment sécuriser un site en HTTPS ?
Le socle tient en quatre éléments : un certificat valide et renouvelé automatiquement, une redirection permanente de tout le trafic HTTP vers HTTPS, l'absence totale de ressources en HTTP dans vos pages, et l'en-tête HSTS pour empêcher les navigateurs de revenir à HTTP. Un audit régulier des ressources tierces est le complément indispensable : c'est par elles que le cadenas saute le plus souvent.
Comment rétablir HTTPS ?
Si le cadenas a disparu sans changement de votre côté, la cause est presque toujours une ressource externe modifiée. Rechargez la page, ouvrez la console, filtrez sur mixed-content : l'URL fautive vous attend. Si le problème persiste après correction, videz le cache du site et testez en navigation privée pour éliminer une version mise en cache.
Ce que j'en ai tiré, à titre personnel
Après plusieurs migrations, ma conviction est simple : le contenu mixte est un problème de surveillance, pas de configuration. Une page propre aujourd'hui peut redevenir mixte demain parce qu'un partenaire a changé son CDN ou qu'un widget a été mis à jour.
Ce que j'ai fini par installer sur chaque projet, c'est un contrôle automatique dans la chaîne de déploiement : un script qui ouvre les pages principales avec un navigateur headless et vérifie l'absence de messages mixed-content dans la console. Ça m'a coûté une demi-journée de mise en place, et ça m'a épargné au moins deux incidents depuis.
Reste une question ouverte : combien de sites en 2026 affichent encore un cadenas trompeur parce que personne n'a jamais ouvert leur console ? Probablement plus que ce qu'on imagine. Et si vous ne savez pas quelle réponse donner pour le vôtre, c'est déjà un début de réponse.
