Reconnaître le contenu mixte sans le confondre avec une panne HTTPS
Votre page s’ouvre en HTTPS, mais une image manque, les polices changent ou un formulaire perd sa présentation. La console du navigateur indique « Mixed Content » et mentionne une ressource demandée en HTTP. Le document principal utilise une connexion sécurisée ; une partie de ce qu’il cherche à charger conserve une adresse non sécurisée.
L’objectif est de retrouver l’endroit qui produit cette adresse, puis de lui fournir une destination HTTPS fonctionnelle. Installer une nouvelle extension n’est pas nécessaire pour commencer. Une photographie insérée dans un article, une feuille de style générée et une adresse de CDN ne se corrigent toutefois pas au même endroit.
Si le navigateur affiche un avertissement de certificat avant même d’ouvrir le site, faites d’abord vérifier ce certificat. Si la page alterne entre deux adresses et termine par « trop de redirections », examinez la configuration HTTPS. Un remplacement des liens d’images ne résout pas ces deux situations. De même, une image déjà demandée en HTTPS mais renvoyant une erreur 404 appelle un diagnostic de fichier ou de chemin, pas un remplacement du protocole.
Obtenir une preuve sur la page réellement touchée
Ouvrez la page publique concernée, puis les outils de développement du navigateur. Dans Chrome, le menu contextuel Inspecter permet d’y accéder. Consultez Console et Réseau, puis rechargez la page avec ces panneaux ouverts. Les libellés peuvent varier selon la langue du navigateur.
Repérez le message de contenu mixte et l’adresse complète qu’il désigne. Dans Réseau, ouvrez la demande correspondante : relevez son URL, son résultat et son initiateur, c’est-à-dire ce qui l’a déclenchée. L’initiateur peut être le document, un script ou une redirection. Cette information aide à retrouver le réglage responsable.
Ne concluez pas à partir de toute occurrence du texte http:// dans le code. Une adresse citée dans un paragraphe n’est pas nécessairement chargée. Un lien ordinaire vers une autre page relève de la navigation ; une image intégrée ou un script intervient dans la page actuelle. Gardez une seule ressource comme témoin pour votre première correction.
- Notez l’adresse de la page, celle de la ressource, le message et l’heure.
- Précisez si le défaut apparaît déconnecté, connecté ou dans les deux cas.
- Comparez une page touchée et une page utilisant le même composant sans défaut visible.
Comprendre pourquoi certaines images restent visibles
Les navigateurs modernes peuvent convertir automatiquement certaines demandes de médias HTTP en HTTPS. D’autres ressources, notamment des scripts ou des feuilles de style, sont bloquées. Le comportement dépend aussi de la façon dont le média est intégré : toutes les images ne suivent pas le même traitement.
Une image affichée malgré un avertissement peut donc utiliser une adresse HTTPS au moment du téléchargement, alors que le document conserve une référence HTTP. Regardez ensemble le message de la console et la demande finale. Une correction durable doit supprimer la mauvaise référence à sa source, sans compter uniquement sur cette conversion.
L’apparence de l’icône située à côté de l’adresse ne constitue pas, à elle seule, un diagnostic. Inversement, l’absence de message au premier chargement ne couvre pas les éléments chargés plus tard. Faites défiler la page jusqu’à la galerie et ouvrez le menu ou l’onglet concerné, sans envoyer de formulaire réel pour ce simple relevé.
Vérifier que la destination HTTPS existe vraiment
Pour une image ou un fichier statique public, copiez l’adresse signalée dans un nouvel onglet et remplacez seulement le début http:// par https://. Conservez le nom d’hôte et le chemin. Le bon résultat est le même fichier, accessible sans avertissement de certificat et sans retour vers HTTP. Ne rejouez pas une requête de paiement ou une action d’administration.
Si cette adresse affiche un certificat invalide, une page d’erreur ou un autre fichier, arrêtez le remplacement. Il faut faire réparer la destination ou choisir une ressource adaptée. Un certificat couvrant le domaine principal ne prouve pas que le sous-domaine des médias est correctement configuré.
L’ouverture directe d’un fichier confirme une disponibilité, pas nécessairement son utilisation dans la page : d’autres règles peuvent encore intervenir. Après correction, contrôlez donc aussi la demande intégrée. Pour une ressource externe sans HTTPS utilisable, demandez au fournisseur son adresse actuelle ou remplacez le composant. N’autorisez pas le contenu non sécurisé dans le navigateur pour masquer le défaut.
Préparer une correction réversible et choisir son parcours
Avant de modifier le contenu, copiez le bloc ou le réglage concerné et conservez l’ancienne adresse. Avant une intervention sur la base ou les fichiers, obtenez une sauvegarde datée des deux, gardée dans un emplacement privé hors du répertoire public. Vérifiez qu’une personne sait la restaurer et que l’accès à l’hébergement fonctionne encore si l’administration devient inaccessible.
Sur une boutique active, une sauvegarde ancienne contient aussi un état ancien des commandes. Elle sert de recours et de référence ; elle n’autorise pas à remplacer toute la base en cas d’erreur. Préparez la modification sur une copie de travail lorsque son périmètre dépasse quelques champs.
- Parcours 1 : quelques articles, images ou réglages visuels contiennent une ancienne adresse. Utilisez l’éditeur et les réglages existants.
- Parcours 2 : une migration a laissé de nombreuses références au même domaine. Préparez un remplacement ciblé, compatible avec les données WordPress.
- Parcours 3 : des adresses HTTP réapparaissent ou touchent les ressources du thème, d’une extension ou du CDN. Corrigez le système qui les génère.
Parcours 1 : corriger une image ou un bloc depuis l’éditeur
Dans Articles ou Pages, ouvrez le contenu identifié et sélectionnez l’image concernée. Si elle appartient à votre médiathèque, utilisez Remplacer, puis la médiathèque, pour sélectionner le même média dont l’adresse sécurisée a été vérifiée. Vous évitez ainsi un nouvel envoi du fichier et la création d’un doublon inutile. Si la médiathèque propose elle-même une adresse HTTP, vérifiez d’abord les adresses générales et la configuration décrites plus loin.
Contrôlez ensuite le texte alternatif, la légende, le lien éventuel et les dimensions : la correction de l’adresse ne doit pas effacer ces réglages. Enregistrez, puis vérifiez la page publique et sa demande réseau. Le champ qui définit le lien cliquable autour de l’image ne remplace pas forcément l’adresse du fichier affiché.
Pour un bloc HTML personnalisé, copiez d’abord son contenu dans vos notes, puis corrigez uniquement l’URL de la ressource repérée. Pour un média externe, utilisez l’adresse sécurisée confirmée par son fournisseur. Si le même HTTP revient après enregistrement, ne multipliez pas les remplacements : passez au diagnostic de configuration.
En cas de résultat incorrect, remettez le bloc sauvegardé ou son réglage précédent. Si quelqu’un a édité l’article entre-temps, récupérez seulement l’élément modifié au lieu de restaurer toute une ancienne version du texte.
Retrouver un logo, un arrière-plan ou une police
Une ressource présente sur plusieurs pages provient parfois d’un modèle partagé. Avec un thème à blocs, cherchez le bloc correspondant dans Apparence, puis Éditeur. Avec un thème classique, les options peuvent se trouver dans Apparence, puis Personnaliser, ou dans les réglages propres au thème. Ces écrans dépendent du thème actif et de vos droits.
Ne changez que le modèle, le logo ou le réglage désigné par votre relevé. Une modification d’en-tête peut toucher tout le site : notez son étendue avant d’enregistrer et contrôlez au moins deux pages qui l’utilisent. Conservez la valeur précédente pour pouvoir la rétablir.
Si l’initiateur est une feuille de style, recherchez l’adresse de l’image ou de la police dans le CSS personnalisé concerné. Une image d’arrière-plan peut être définie dans une règle url(...) sans apparaître comme bloc Image dans l’article. Corrigez cette référence après avoir vérifié sa destination. Si le fichier CSS est produit automatiquement, modifiez plutôt le réglage d’origine selon le troisième parcours.
Vérifier les adresses WordPress avant un traitement en lot
Sur WordPress auto-hébergé, consultez Réglages, puis Général avec un compte autorisé. L’adresse de WordPress désigne l’emplacement de l’installation ; l’adresse du site désigne l’adresse publique. Elles peuvent avoir des chemins différents. Ne les rendez pas identiques par principe et ne supprimez pas un sous-répertoire pour résoudre du contenu mixte.
Si le seul écart confirmé est HTTP au lieu de HTTPS, vérifiez d’abord que les destinations sécurisées fonctionnent et notez les deux valeurs. Corrigez alors le protocole en conservant l’organisation prévue. Reconnectez-vous si nécessaire et contrôlez le site. Outils, puis Santé du site peut aussi proposer une migration HTTPS native lorsqu’elle est applicable ; ne forcez pas son apparition si votre configuration ne la permet pas.
WordPress sait réécrire à l’affichage certaines anciennes URL HTTP du site lorsqu’il est configuré pour le faire. Cela ne constitue pas une conversion permanente de toutes les données, de tous les fichiers et de tous les domaines externes. Refaites le relevé réseau : si la ressource témoin est déjà corrigée, aucun remplacement massif n’est justifié.
Parcours 2 : simuler un remplacement ciblé après migration
Ce parcours demande un accès technique, WP-CLI disponible et la certitude d’être dans la bonne installation. Demandez l’intervention de l’hébergeur si vous n’avez pas ces accès. Certains réglages contiennent des données sérialisées : leur format enregistre notamment des longueurs de chaînes. Un remplacement SQL brut peut rendre ces structures illisibles.
WP-CLI sait traiter ces données. L’exemple suivant simule le remplacement d’une adresse propre au site dans les tables des publications et de leurs métadonnées. Remplacez le domaine d’exemple et le préfixe wp_ par ceux qui ont été vérifiés. Conservez le chemin exact si les ressources sont dans un sous-répertoire. Ne remplacez jamais simplement tout http:// par https://.
L’option --dry-run n’enregistre pas les remplacements en base ; --precise utilise le traitement PHP, plus lent. --skip-columns=guid préserve les identifiants GUID, qui ne doivent pas être réécrits pour nettoyer des liens. Examinez les tables, colonnes et nombres de remplacements annoncés avant toute application.
wp search-replace 'http://votre-domaine.example/' 'https://votre-domaine.example/' wp_posts wp_postmeta --skip-columns=guid --precise --dry-runAppliquer uniquement le périmètre réellement vérifié
Le nombre de correspondances ne prouve pas que chaque changement est souhaitable. Faites examiner des exemples dans les champs concernés, notamment si des produits, des contenus historiques ou des données de constructeur partagent ces tables. Une simulation inattendue impose de revoir la recherche et son périmètre avant de continuer.
Après validation sur la copie de travail, sauvegarde récente et préparation du retour arrière, la personne responsable peut reprendre la commande validée en retirant uniquement --dry-run. Gardez son compte rendu dans un emplacement privé. Une recherche littérale peut manquer certaines adresses encodées : une absence de résultat ne prouve pas que la page est corrigée.
Ne rajoutez pas toutes les tables pour obtenir davantage de résultats. Des options ou des tables d’extension nécessitent un examen distinct, idéalement depuis leurs réglages. En multisite, faites identifier le site et les tables exacts par l’administrateur du réseau ; cet exemple n’autorise pas une opération sur l’ensemble des sites.
Sans accès WP-CLI, transmettez le périmètre à l’hébergeur ou utilisez la procédure de migration documentée du constructeur déjà installé. L’installation immédiate d’un outil supplémentaire ne remplace ni ce diagnostic ni la sauvegarde.
Parcours 3 : réparer les URL qui sont générées à nouveau
Une ancienne adresse qui revient dans de nouvelles pages signale une source encore active. Faites comparer les réglages effectifs avec la configuration de l’installation. Les constantes WP_HOME et WP_SITEURL, lorsqu’elles existent dans wp-config.php, remplacent les valeurs utilisées par WordPress sans réécrire les valeurs stockées en base. Leur présence peut aussi rendre les champs correspondants non modifiables dans l’administration.
La personne chargée de l’hébergement doit donc identifier ce qui définit réellement l’adresse avant toute correction. Si elle intervient dans un fichier, elle en garde une copie privée et prévoit sa remise en place. Retirer une constante au hasard peut réactiver une ancienne valeur de la base et faire perdre l’accès au site.
Si l’adresse est écrite directement dans le code d’un thème ou d’une extension, transmettez le fichier et la référence au mainteneur. Une correction durable utilise les fonctions WordPress adaptées pour produire les URL. Évitez une modification improvisée dans le thème parent : elle peut disparaître à la prochaine mise à jour. Faites valider la correction sur la copie de travail avant son déploiement.
Recréer les styles générés après avoir corrigé leur origine
Un formulaire peut être correctement présenté dans l’éditeur et perdre ses styles sur la page publique. Une galerie peut fonctionner dans un article et échouer dans un autre. Ces différences invitent à comparer les ressources réellement chargées ; elles ne prouvent pas, à elles seules, qu’une extension est défectueuse.
Après correction de l’adresse source, utilisez la fonction documentée de l’outil déjà présent pour recréer ses fichiers générés. Avec Elementor, la documentation actuelle indique Elementor, Editor, Home, puis Tools et Clear Files & Data, suivi de Save Changes ; la traduction et les menus peuvent différer selon la version. Sauvegardez d’abord et limitez cette intervention aux sites utilisant réellement ce constructeur.
Ne supprimez pas manuellement tout le dossier uploads pour obtenir le même effet : il contient aussi les médias originaux et peut accueillir d’autres données. Après régénération, relevez à nouveau l’URL du CSS. Si elle reste en HTTP, revenez à son réglage d’origine. Si l’adresse est correcte mais que l’ancienne page persiste, examinez le cache.
Traiter un CDN ou un proxy sans affaiblir HTTPS
Si les ressources proviennent d’un CDN, vérifiez le nom d’hôte exact dans le réglage du service ou de son extension déjà installée. Confirmez que ce nom fournit les fichiers attendus en HTTPS, puis corrigez le protocole ou l’adresse selon la configuration du fournisseur. Conservez la valeur précédente. Ne remplacez pas arbitrairement le domaine du CDN par celui du site : les fichiers peuvent ne pas y être disponibles au même chemin.
Derrière un proxy inverse, WordPress peut recevoir une requête HTTP alors que le visiteur utilise HTTPS. Faites vérifier par l’hébergeur la transmission du protocole et la confiance accordée au proxy. Ne copiez pas un extrait qui fait confiance à un en-tête fourni par n’importe quel visiteur. Une mauvaise interprétation peut également provoquer une boucle de redirections.
Une redirection HTTP vers HTTPS ne suffit pas pour une ressource bloquée avant son chargement. La directive upgrade-insecure-requests peut convertir des demandes, mais elle ne crée pas une destination HTTPS manquante. Ne désactivez pas la vérification des certificats et ne réduisez pas la sécurité TLS pour faire disparaître un message.
Vérifier la correction au-delà de la première page
Commencez par purger la copie en cache de la page ou du fichier modifié avec les commandes de votre solution existante. Un cache du serveur ou du CDN peut subsister après celui de WordPress. Procédez par couche identifiable et par périmètre utile ; une purge générale répétée ne corrige aucune adresse source.
Reprenez ensuite votre page témoin dans un contexte déconnecté et dans un autre navigateur à jour. Si le défaut n’existe que dans un profil, examinez ses extensions avant d’accuser le site. Utilisez les protections normales du navigateur. Le résultat attendu combine une ressource HTTPS correcte, la disparition de son avertissement et le bon fonctionnement de l’élément.
- Rechargez l’accueil, une page touchée et une autre page utilisant le même modèle.
- Faites apparaître les médias différés, les menus et les éléments interactifs concernés.
- Comparez l’affichage sur une largeur mobile et sur ordinateur.
- Vérifiez l’administration après une modification des adresses générales.
- Si un formulaire est essentiel, utilisez un environnement ou un mode de test prévu, sans créer de commande réelle pour vérifier son apparence.
Revenir en arrière ou transmettre un diagnostic exploitable
Si une correction détériore le résultat, annulez d’abord la modification ciblée : bloc sauvegardé, réglage précédent ou fichier concerné. Pour un traitement en base, faites comparer les données modifiées avec la sauvegarde sur une copie séparée. Un remplacement inverse global de HTTPS vers HTTP pourrait abîmer des références qui étaient déjà correctes.
Préservez les commandes, commentaires et textes enregistrés depuis la sauvegarde. Une restauration complète de production exige un plan qui tient compte de ces ajouts ; ce n’est pas le retour arrière habituel d’une correction d’adresse.
Sur WordPress.com, les certificats sont gérés par la plateforme : utilisez l’éditeur pour vos contenus et son assistance pour la configuration inaccessible depuis votre offre. Dans tous les cas, transmettez la page touchée, la ressource, son initiateur, le message exact et les changements déjà tentés. Retirez les cookies, jetons et informations privées des relevés. Ce dossier permet au mainteneur de corriger une origine précise au lieu de lancer plusieurs réparations sans lien démontré avec la panne.
