# 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é.

- Source canonique : [https://allaux.fr/problemes/contenu-mixte-apres-passage-en-https](https://allaux.fr/problemes/contenu-mixte-apres-passage-en-https)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Ouvrez la console du navigateur : chaque ressource fautive est listée avec son adresse http:// complète, ce qui désigne le fichier ou l’enregistrement à corriger. Sur WordPress, remplacez les adresses en base avec un outil de search-replace qui gère les données sérialisées, puis contrôlez wp_options.siteurl et home. Sur PrestaShop, vérifiez PS_SSL_ENABLED et PS_SHOP_DOMAIN_SSL dans ps_configuration.

## 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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.

## Un remplacement en base de données n’est pas une opération anodine

> Certaines données sont stockées sous forme sérialisée, où la longueur de chaque chaîne est enregistrée avec elle. Un simple remplacement de « http:// » par « https:// » modifie cette longueur et rend la donnée illisible, ce qui casse des réglages entiers. L’opération demande un outil qui recalcule les longueurs.

## 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. ([/wordpress-woocommerce/migration/https-contenu-mixte](/wordpress-woocommerce/migration/https-contenu-mixte))
- **Passer son site en HTTPS** — La procédure complète quand la migration n’est pas encore terminée. ([/guides/passer-site-en-https](/guides/passer-site-en-https))
- **La sérialisation expliquée** — Pourquoi un remplacement brut dans la base casse certains réglages. ([/glossaire/serialisation](/glossaire/serialisation))
- **La redirection 301** — Comment mettre en place une redirection permanente propre vers HTTPS. ([/glossaire/redirection-301](/glossaire/redirection-301))

## FAQ

### Le contenu mixte est-il dangereux pour mes clients ?

Le risque réel est limité pour une image, sérieux pour un script : un fichier chargé en clair peut être modifié pendant son transport. C’est précisément pour cette raison que les navigateurs bloquent les scripts et laissent passer les images.

### Puis-je forcer le navigateur à tout charger en sécurisé ?

Il existe une directive qui demande au navigateur de tenter en HTTPS toute ressource appelée en HTTP. C’est un pansement utile en transition, pas une correction : si la ressource n’existe pas en sécurisé, elle disparaît quand même.

### Pourquoi le problème n’apparaît que sur certaines pages ?

Parce que le contenu mixte vient le plus souvent du contenu saisi, qui diffère d’une page à l’autre. Les pages générées automatiquement, elles, sont propres.

### Faut-il refaire le site pour passer proprement en HTTPS ?

Non. C’est un chantier de nettoyage et de configuration, pas une refonte. La durée dépend surtout du volume de contenu ancien à corriger.

### Mon référencement peut-il souffrir du contenu mixte ?

Ce qui pèse le plus, c’est la cohérence des adresses : deux versions du même site accessibles, ou des redirections en cascade. Le contenu mixte en lui-même dégrade surtout la confiance visible du visiteur.