Warning: Undefined variable $author_details in /home/navigation-webcom/navigation-web.com/htdocs/wp-content/plugins/wp-user-profile-avatar/includes/wp-author-box-social-info.php on line 114
Obtenir un certificat SSL gratuit avec Let’s Encrypt prend quelques minutes et ne coûte rien, mais le cadenas n’apparaît pas toujours dans la barre d’adresse, car la cause la plus fréquente n’est pas le certificat lui-même, mais des ressources encore chargées en HTTP, ce qui oblige à repérer les éléments qui cassent le HTTPS au lieu de s’arrêter à l’installation. Un site en contenu mixte reste vulnérable et mal vu par Google.
Un cadenas absent malgré un certificat valide
Pourquoi le navigateur refuse-t-il d’afficher le cadenas après l’installation de Let’s Encrypt ? Le certificat est valide, délivré gratuitement et de façon automatisée par une autorité de certification à but non lucratif opérée par l’Internet Security Research Group, mais cette validité technique ne garantit pas que toutes les ressources secondaires du site, telles que les images, les scripts ou les feuilles de style, soient elles-mêmes servies de manière sécurisée, car leur chargement dépend de la configuration du serveur et des URLs saisies dans le code. Le problème vient d’ailleurs : presque toujours de ces éléments en HTTP.
Ce contenu mixte casse immédiatement la protection TLS. Même si la page principale répond en HTTPS, Google utilise d’ailleurs le HTTPS comme signal de classement depuis 2014, ce qui rend ces erreurs coûteuses au sens propre comme au figuré, car chaque ressource non sécurisée peut non seulement dégrader la confiance de l’utilisateur, mais aussi affecter indirectement le référencement naturel, la vitesse perçue et la sécurité réelle de la navigation.
Un certificat commercial à validation de domaine coûte encore entre 50 et 200 euros par an, sans offrir davantage de sécurité qu’un certificat Let’s Encrypt correctement installé, car le chiffrement repose sur les mêmes protocoles TLS et la même cryptographie asymétrique, quelle que soit l’autorité qui a émis le certificat. La différence se joue sur le support et la garantie. Beaucoup de webmasters pensent que payer plus cher évite les contenus mixtes, mais le navigateur ne vérifie pas le prix du certificat : il vérifie uniquement la provenance de chaque ressource.
Repérer les requêtes HTTP qui trahissent le site
La console du navigateur affiche souvent des avertissements explicites, mais il faut savoir où regarder, car un message bloqué peut concerner une image de l’en-tête, un script de statistiques ou une police de caractères, par exemple un ancien fichier de CSS chargé en HTTP. Corriger la page d’accueil ne suffit pas pour que tout le site redevienne propre.
Les outils de développement intégrés à Chrome ou Firefox, accessibles via un raccourci clavier ou le menu contextuel, donnent une vue détaillée des requêtes bloquées, comme une image ou un script externe. Il ne faut pas se limiter au premier onglet. Consultez les panneaux Réseau ou Sécurité pour voir toutes les demandes en attente.
Les points de contrôle qui évitent les oublis
- Ouvrir la console et filtrer les messages « mixed content » pour identifier l’URL exacte de la ressource bloquée.
- L’onglet Sécurité des outils de développement, trop souvent négligé.
- Combien de requêtes HTTP figurent encore dans le panneau Réseau après tri par protocole ?
- Un test sur plusieurs pages produit-il le même avertissement ou s’agit-il d’un cas isolé ?
- La touche « Recharger en ignorant le cache » révèle parfois des contenus mixtes masqués.
Cette vérification ne prend que quelques minutes. Elle suffit pourtant à révéler des contenus mixtes que l’œil ne voit pas, comme une police de caractères chargée en HTTP ou un pixel de suivi oublié, par exemple.
Certains contenus mixtes ne viennent pas du code, mais d’un plugin ou d’une extension qui injecte des scripts. Les bloqueurs de publicité, les barres d’outils installées par mégarde ou certaines extensions de navigateur qui s’exécutent en arrière-plan ajoutent parfois des requêtes HTTP sur lesquelles le webmaster n’a aucun contrôle, car elles fonctionnent sans avertissement et sans demande explicite de l’utilisateur.
Dans ce cas, un test en navigation privée avec les extensions désactivées aide à distinguer un problème du site d’un parasite local. Le diagnostic devient plus fiable, surtout quand plusieurs navigateurs donnent des résultats différents. Cette précaution évite de corriger des erreurs qui n’existent pas sur le serveur.
Corriger les erreurs sans tout casser
Certbot, développé par l’Electronic Frontier Foundation, automatise l’obtention et le renouvellement du certificat, mais il ne corrige pas les contenus mixtes : il faut passer en revue les liens inscrits en dur dans les articles, les réglages du thème et les fichiers de configuration. Remplacer chaque URL par sa version HTTPS suffit, à condition que la ressource réponde en HTTPS. Une image qui renvoie une erreur HTTP en HTTPS bloquera le cadenas.
Franchement, peu de sites ont besoin d’un certificat payant. Quand une ressource externe ne propose pas de version HTTPS, des options s’offrent à vous : la remplacer par une alternative sécurisée ou la déplacer localement. La politique de sécurité du contenu peut forcer la réécriture en HTTPS via upgrade-insecure-requests, mais ce n’est pas définitif. Pour valider après coup, un outil comme mess-france.com refait le parcours des ressources et signale celles qui posent problème.
Prévenir les contenus mixtes sur les prochaines publications
Utiliser des liens relatifs, rédiger les URLs en HTTPS et vérifier les intégrations externes évitent de revivre la même situation. Sur WordPress, un réglage de l’adresse du site dans les options générales suffit à forcer le protocole, mais les anciens médias insérés en HTTP nécessitent une mise à jour en base. Il ne faut pas bricoler une redirection globale ; chaque lien HTTP doit être corrigé à la source.
Le cadenas redevient visible après vidage du cache. Cela ne dispense pas d’un contrôle en navigation privée, car les extensions de navigateur peuvent mémoriser d’anciennes réponses. Adopter une règle simple aide aussi : avant de cliquer sur publier, chaque lien inséré devrait être ouvert une fois en HTTPS. Les équipes les plus rigoureuses ajoutent cette vérification à leur recette de mise en production, au même titre que le test des formulaires ou la sauvegarde de la base.
Le cadenas se mérite après l’installation
Le passage en HTTPS ne s’achève pas à l’obtention d’un certificat gratuit. Tant qu’une image, un script ou une feuille de style circule en HTTP, le navigateur refuse d’afficher le cadenas, car la présence d’une seule requête non sécurisée suffit à empêcher l’activation du cadenas, même si le certificat est parfaitement valide et couvre correctement le domaine principal.
Les outils de développement du navigateur et une revue méthodique des URLs suffisent pourtant à éliminer ces contenus mixtes. Une fois la correction faite, le site redevient cohérent. Vérifierez-vous les requêtes réseau de toutes vos pages avant de considérer le HTTPS comme terminé ?
