Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

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

Décrire mon problème Discuter sur WhatsApp

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.

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

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.

De quel type de développement s’agit-il ?
Partez-vous de zéro ou faut-il faire évoluer un existant ?

Reprendre un code existant non maîtrisé demande souvent un audit avant même de commencer à développer.

Une stack technique est-elle imposée ? (facultatif)
Combien de personnes utiliseront l’outil ? (facultatif)
Quelle est votre échéance ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

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.