Un certificat SSL donne l’impression d’un site inviolable, souvent à tort. Une migration HTTPS laisse souvent des URL en HTTP, ce qui crée des mélanges de protocoles affaiblissant la protection. Distinguez les certificats, comprenez ce que le navigateur bloque. Corriger ces contenus mixtes exige de la méthode, pas de la chance. Un site en HTTPS avec un cadenas doré peut encore charger une image en HTTP ; c’est là que le bât blesse.
Les certificats SSL ne se valent pas tous
Un certificat DV valide uniquement le nom de domaine. Aucun organisme n’a vérifié l’identité de l’entreprise derrière le site. Un certificat OV ajoute une vérification de l’organisation, ce qui rassure les visiteurs qui prennent le temps de cliquer sur le cadenas. Le certificat EV pousse la logique encore plus loin en affichant le nom de la société directement dans la barre d’adresse, mais certains navigateurs ont renoncé à cette présentation.
Franchement, tout dépend de ce que vous vendez. Un certificat DV suffit pour un site vitrine, alors qu’un OV se justifie si vous collectez des données personnelles ou des paiements, même occasionnels, car la vérification de l’organisation devient alors un atout de confiance pour l’internaute qui souhaite connaître l’identité du prestataire avant de transmettre ses informations. Le DV reste l’option la plus abordable du lot. Le certificat ne corrige pas les URL en HTTP oubliées.
Le contenu mixte, ce fantôme hérité de la migration
Un contenu mixte, qu’on appelle aussi « HTTP sur HTTPS », apparaît quand un site TLS charge des éléments en HTTP non sécurisé, ce qui conduit le navigateur à croire qu’il affiche une page chiffrée alors que certaines ressources voyagent en clair, rendant la protection partiellement inutile. Ces ressources se repèrent par leur URL commençant par http://.
Le contenu mixte passif, aussi appelé contenu d’affichage, se limite aux éléments encapsulés qui ne peuvent pas interagir avec le reste de la page, comme des images ou des vidéos, ce qui signifie qu’un attaquant peut éventuellement bloquer ou remplacer une image chargée via HTTP, mais sans jamais pouvoir modifier le reste de la page. Ce risque reste visuel.
Le contenu mixte actif est bien plus dangereux, car il concerne des éléments ou des dépendances servis via HTTP qui peuvent interagir avec la page web entière et la modifier, ce qui autorise un code malveillant à s’exécuter, contrairement au passif qui altère seulement l’apparence. Un clic sur un lien piégé peut compromettre la session.
Prenons une bannière en HTTP sur une page de paiement en HTTPS. Le cadenas s’affiche, mais le navigateur a bloqué la ressource. Ce scénario montre que le cadenas ne suffit pas à préserver l’intégrité visuelle de la page, surtout pour les logos de paiement. Vous ne le voyez pas toujours, car l’alerte est discrète. La vérification manuelle du code reste indispensable. Sur un blog, c’est anecdotique ; sur une boutique, cela peut coûter une vente.
Repérer les contenus mixtes sans se perdre
Ouvrez la console du navigateur via un clic droit puis « Inspecter l’élément », car l’onglet « Console » ou « Réseau » affiche les requêtes avec leur protocole, ce qui signale les adresses en http précédées d’un avertissement orange ou rouge au besoin. Après chaque migration, parcourez les pages principales une par une. Des extensions listent automatiquement ces requêtes, ce qui accélère le repérage sur les gros sites.
Ce que la console affiche vraiment
- Une alerte rouge qui mentionne clairement un contenu mixte bloqué.
- Un cadenas barré ou un triangle d’avertissement dans la barre d’adresse.
- Pourquoi certaines images s’affichent-elles encore en HTTP ?
- Des requêtes http:// listées dans l’onglet Réseau, souvent en contraste avec les https://.
- Une simple ligne d’avertissement qui passe inaperçue si on ne la cherche pas.
Gardez une trace écrite des URL fautives dans un simple fichier texte, car certains contenus mixtes passifs, bien que non bloquants, restent visibles dans l’onglet Réseau, et les noter évite souvent par la suite de les oublier lors de la correction. Parfois, le navigateur ne signale rien : la ressource est déjà en HTTPS. Après chaque modification, videz le cache et forcez le rechargement, sinon les anciens résultats masquent les corrections.
Corriger les URL et verrouiller les redirections
Remplacez chaque adresse en http:// par sa version en https:// ou, encore mieux, par un chemin relatif lorsque le fichier est hébergé sur le même domaine, sans oublier les fichiers CSS et JavaScript qui déclenchent souvent les blocages les plus sournois. Cette option évite de retoucher le code en cas de changement de domaine. Elle simplifie la maintenance et réduit les risques de régression.
Les redirections permanentes forcent le serveur à renvoyer toute demande HTTP vers HTTPS, mais un fichier .htaccess mal configuré peut créer des boucles infinies si le certificat est mal installé, et un audit complet passe par l’analyse des URL, comme l’explique viareferencement.com avec des exemples concrets. Pensez aussi aux CDN, dont les URL HTTP apparaissent parfois.
Ne négligez pas non plus les sous-domaines et les CDN, qui conservent parfois des références HTTP, car la correction des contenus mixtes se joue dans les détails du code, pas dans le choix du certificat, et un DV bien configuré protège mieux qu’un EV sur un site truffé d’URL en clair. Relisez systématiquement le code source avant la mise en ligne.
Le cadenas ne vaut que par les URLs qu’il verrouille
Installer un certificat SSL, qu’il soit DV, OV ou EV, ne transforme pas une page en coffre-fort, car le vrai travail commence après, quand on traque les adresses http laissées dans le code, les images chargées en clair et les scripts actifs oubliés. Un site peut afficher un cadenas parfait et rester vulnérable. Le vrai problème est la discipline de migration. Quand avez-vous vérifié que toutes vos ressources passent par HTTPS ?
