La page arrive bien en HTTPS, mais elle appelle encore des éléments en http : images, scripts, feuilles de style, polices ou formulaires. Le navigateur considère alors que la page n’est que partiellement chiffrée. Il retire le cadenas, affiche « Non sécurisé » ou bloque les éléments concernés, ce qui peut aussi casser une partie de l’affichage.
Pourquoi cette erreur apparaît
- Le site est passé en HTTPS, mais les contenus enregistrés dans la base (images insérées dans les pages, liens internes) gardent leurs anciennes adresses en http.
- Le constructeur de pages ou le thème a mémorisé des adresses en http dans ses réglages ou dans les fichiers CSS qu’il génère.
- Une adresse est écrite en dur en http dans le thème, un widget, le CSS personnalisé ou un code de suivi.
- Un service externe (police, vidéo, script de statistiques) est appelé en http, ou ne propose pas de version HTTPS.
- Les adresses dans Réglages > Général sont restées en http alors que le certificat est installé.
- Si « Non sécurisé » apparaît sur toutes les pages et que l’adresse commence par http://, il ne s’agit pas de contenu mixte : aucun certificat n’est actif et il faut d’abord en installer un.
Comment corriger le problème
Repérer les éléments chargés en http
Sur la page concernée, faites un clic droit, choisissez « Inspecter » puis ouvrez l’onglet Console. Chaque ligne Mixed Content donne l’adresse exacte de l’élément fautif. Le chemin indique souvent l’origine : wp-content/uploads pour les médias, le dossier du thème, celui d’une extension ou un domaine externe.
Passer les adresses du site en https
Dans Réglages > Général, les deux adresses doivent commencer par https://, à condition que le certificat fonctionne. Quand WordPress détecte un certificat valide, la page Outils > Santé du site propose aussi un bouton pour basculer le site en HTTPS.
Remplacer les anciennes adresses dans la base
Après un export complet de la base, remplacez http://monsite.fr par https://monsite.fr dans tout le contenu. Utilisez un outil qui respecte les données sérialisées, un format de stockage que WordPress emploie pour ses réglages et qu’un remplacement direct en SQL endommage : WP-CLI ou une extension de recherche et remplacement reconnue. Avec Elementor, utilisez ensuite son outil « Remplacer l’URL » (menu Elementor > Outils) et régénérez ses fichiers CSS.
Corriger les adresses écrites en dur
Cherchez http:// dans le CSS personnalisé (Apparence > Personnaliser), les widgets, les modèles d’en-tête et de pied de page et les codes de suivi. Pour un service externe, essayez la même adresse en https:// ; s’il n’existe pas de version sécurisée, hébergez la ressource vous-même ou retirez-la. Videz ensuite tous les caches.
Faire le remplacement avec WP-CLI
La première ligne sauvegarde la base, la deuxième simule le remplacement sans rien écrire, la troisième l’applique à toutes les tables du site. La colonne guid, l’identifiant permanent de chaque contenu, est laissée intacte pour que les flux RSS ne republient pas d’anciens articles. Répétez l’opération pour la variante avec www si elle a été utilisée.
wp db export avant-https.sql
wp search-replace 'http://monsite.fr' 'https://monsite.fr' --all-tables-with-prefix --skip-columns=guid --dry-run
wp search-replace 'http://monsite.fr' 'https://monsite.fr' --all-tables-with-prefix --skip-columns=guidFilet de sécurité côté serveur
Sur un serveur Apache doté du module mod_headers, cette ligne ajoutée au .htaccess (après en avoir gardé une copie) demande au navigateur de charger en https les ressources appelées en http. Elle masque le symptôme sans corriger la source, et ne sauve pas les ressources qui n’existent pas en HTTPS.
Header always set Content-Security-Policy "upgrade-insecure-requests"Exportez la base de données avant tout rechercher-remplacer : une adresse mal saisie se propage dans tout le site et seule cette sauvegarde permet de revenir en arrière.
Un autre message d'erreur ? Collez-le dans le décodeur : il le reconnaît et vous oriente vers la bonne fiche.
Ouvrir le décodeur