Le cadenas ne s’affiche plus après le passage en HTTPS
Le certificat est valide, le site répond bien en HTTPS, et pourtant le cadenas est barré ou accompagné d’un avertissement. Ce n’est pas un problème de certificat : c’est que la page, servie de manière sécurisée, va chercher une partie de son contenu par une adresse non sécurisée. Le navigateur le signale, et parfois bloque purement et simplement l’élément concerné.
Deux niveaux de gravité
Le navigateur distingue le contenu mixte passif — images, vidéos, sons — du contenu mixte actif — feuilles de style, scripts, cadres intégrés. Le premier est affiché mais dégrade l’indicateur de sécurité. Le second est purement et simplement bloqué, parce qu’un script chargé en clair pourrait être remplacé en cours de route.
C’est ce qui explique un symptôme déroutant : après un passage en HTTPS, la mise en page s’effondre ou une fonction cesse de répondre alors que rien n’a été modifié dans le code. Le fichier existe, il est simplement refusé par le navigateur. La console du navigateur nomme alors précisément chaque ressource bloquée.
Où se cachent les adresses restées en HTTP
-
Dans les descriptions saisies en administration
C’est la source la plus fréquente et la plus longue à nettoyer : des années de fiches produit et de pages contenant des images collées avec leur adresse complète en http.
-
Dans les réglages du CMS
L’adresse de la boutique est enregistrée en base. Tant qu’elle reste en http, une partie des liens générés le reste aussi, y compris dans les e-mails envoyés.
-
Dans le thème et les modules
Une adresse écrite en dur dans un gabarit ou une feuille de style échappe à tout remplacement fait en base de données.
-
Dans les scripts tiers
Anciennes balises de suivi, polices, cartes, bibliothèques appelées depuis un service externe qui ne propose plus de version sécurisée.
-
Dans les fichiers de style eux-mêmes
Une image d’arrière-plan déclarée en http dans un fichier CSS ne se voit pas dans le code de la page : elle n’apparaît que dans la console du navigateur.
Ce qu’il reste à vérifier ensuite
Une fois le contenu mixte traité, deux points terminent le chantier. La redirection permanente de l’adresse non sécurisée vers l’adresse sécurisée doit être unique et directe : une chaîne de redirections en cascade dilue le signal envoyé aux moteurs et ralentit chaque visite. Et les adresses déclarées dans le plan de site, les balises canoniques et les données de suivi doivent toutes utiliser la version sécurisée, sans quoi les statistiques se coupent en deux.
- Vérifiez aussi les liens internes écrits en dur avec l’adresse complète : ils forcent une redirection inutile à chaque clic.
- Sur un site multilingue, chaque version linguistique a ses propres adresses à contrôler.
Continuer sur la bonne page
-
HTTPS et contenu mixte sur WordPress
Le cas WordPress détaillé, avec le problème des données sérialisées.
-
Passer son site en HTTPS
La procédure complète quand la migration n’est pas encore terminée.
-
La sérialisation expliquée
Pourquoi un remplacement brut dans la base casse certains réglages.
-
La redirection 301
Comment mettre en place une redirection permanente propre vers HTTPS.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.