Votre site affiche encore http:// dans la barre d’adresse. Ou vous avez activé le SSL chez votre hébergeur, mais Chrome affiche toujours un cadenas barré ou un avertissement « non sécurisé ». Dans les deux cas, le problème se règle — à condition de traiter chaque cause dans le bon ordre.
Cet article couvre tout le parcours : activer le certificat SSL, forcer le HTTPS, et corriger les ressources qui chargent encore en HTTP à l’intérieur de vos pages.
Pourquoi votre site doit être en HTTPS
Google utilise le HTTPS comme signal de classement depuis 2014. Un site en HTTP part avec un désavantage dans les résultats de recherche. Sur une boutique en ligne, un navigateur qui affiche « non sécurisé » sur la page de paiement fait fuir les acheteurs — c’est mesurable dans les taux d’abandon de panier.
Le certificat SSL chiffre la connexion entre le navigateur du visiteur et votre serveur. Sans lui, les données échangées — mots de passe, coordonnées, numéros de carte — circulent en clair.
Étape 1 : activer le certificat SSL chez votre hébergeur
Avant tout, vérifiez que le certificat SSL est bien installé sur votre hébergement.
Sur OVH : connectez-vous à votre espace client, allez dans Web Cloud > Hébergements > votre hébergement > onglet « Informations générales ». Le certificat SSL doit apparaître comme actif. Sinon, cliquez sur « Commander un certificat SSL » — Let’s Encrypt est gratuit et suffisant pour la grande majorité des sites.
Sur o2switch : dans cPanel, cherchez la section « Sécurité » puis « SSL/TLS Status ». Vous pouvez activer Let’s Encrypt en un clic sur tous vos domaines depuis cette interface.
Sur Infomaniak : dans votre Manager, allez dans Hébergement Web > votre hébergement > Certificats SSL. Activez le certificat gratuit Let’s Encrypt.
Une fois activé, attendez quelques minutes puis testez en tapant l’url de votre site https://monsite.fr dans votre navigateur. Si la page charge sans avertissement, le certificat est opérationnel. Si le problème persiste, la suite de cet article couvre chaque cas possible.
Étape 2 : vérifier l'état réel de votre SSL
Avant de modifier quoi que ce soit, diagnostiquez précisément ce qui se passe.
Testez les quatre URLs suivantes une par une :
Le comportement correct : trois d’entre elles redirigent automatiquement vers une seule version. Si plusieurs s’ouvrent sans redirection, vous avez un problème de configuration.
Avec SSL Labs (ssllabs.com/ssltest) : entrez votre URL et obtenez un rapport complet sur votre certificat — validité, configuration, points faibles. C’est l’outil de référence pour un diagnostic approfondi.
Avec Why No Padlock (whynopadlock.com) : si le certificat est actif mais que le cadenas n’apparaît pas, cet outil liste toutes les ressources qui chargent encore en HTTP sur votre page. Gardez cette liste — vous en aurez besoin pour les étapes suivantes.
Étape 3 : forcer le HTTPS dans WordPress
Si votre site tourne sous WordPress, deux vérifications à faire avant de toucher au serveur.
Les URLs dans les réglages WordPress
Allez dans votre tableau d’administration WordPress en rendez-vous dans Réglages > Général. Les deux champs pointant vers votre site doivent commencer par https:// :
- Adresse Web de WordPress (URL) : https://monsite.fr
- Adresse Web du site (URL) : https://monsite.fr
Si l’un des deux affiche encore http://, corrigez-le et enregistrez.
Attention : si votre site disparaît après ce changement, le certificat SSL n’est pas correctement installé côté hébergeur. Revenez en arrière en modifiant directement les lignes siteurl et home dans la table wp_options via phpMyAdmin.
La redirection dans le .htaccess
Même avec les bons réglages WordPress, les visiteurs qui tapent http://monsite.fr doivent être redirigés automatiquement. Ouvrez votre fichier .htaccess à la racine de votre site (via FTP ou le gestionnaire de fichiers de votre hébergeur) et ajoutez les lignes suivantes :
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Le code 301 indique à Google que la redirection est permanente — votre autorité SEO accumulée en HTTP est transférée vers les URLs en HTTPS.
Étape 4 : vérifier le contenu mixte
Le certificat est actif, la redirection fonctionne, mais le cadenas reste barré sur certaines pages. C’est le problème du contenu mixte.
Votre page charge en https://, mais elle appelle des ressources en http:// — une image, une police, un script JavaScript. Le navigateur reçoit une page sécurisée qui contient des éléments non sécurisés.
Deux niveaux de gravité :
Contenu mixte passif — images, vidéos, audio en HTTP. Le navigateur les affiche mais signale le problème avec un cadenas barré.
Contenu mixte actif — scripts JavaScript, feuilles de style CSS, iframes en HTTP. Le navigateur les bloque complètement. Résultat : mise en page cassée, fonctionnalités qui ne répondent plus.
Pour identifier les ressources en HTTP : dans Chrome, clic droit > Inspecter > onglet Console. Les erreurs « Mixed Content » apparaissent en rouge avec l’URL problématique. Dans Firefox, cliquez sur le bouclier barré dans la barre d’adresse.
Étape 5 : mettre à jour les URLs dans la base de données
Si votre site existait avant l’activation du SSL, votre base de données contient des milliers de références en http:// — images, liens internes, options du thème. Activer le SSL ne les met pas à jour automatiquement.
Avec le plugin Better Search Replace :
- Installez Better Search Replace depuis l’administration WordPress
- Dans « Rechercher » : http://monsite.fr
- Dans « Remplacer par » : https://monsite.fr
- Sélectionnez toutes les tables
- Cochez « Exécuter comme un test ? » pour voir combien de remplacements seraient effectués
- Décochez et relancez pour appliquer
Désinstallez le plugin une fois terminé.
Étape 6 : corriger les ressources externes en HTTP
Même après la mise à jour de la base de données, certaines ressources viennent de serveurs externes et restent en HTTP.
Des polices Google Fonts. Certains thèmes anciens appellent les polices via http://fonts.googleapis.com. Cherchez dans functions.php et style.css, remplacez par https://.
Des scripts tiers. Un widget de réservation, un pixel de suivi, un outil de chat intégré manuellement — vérifiez que chaque URL commence par https://.
Des images hébergées ailleurs. Si vous avez copié des images depuis d’autres sites en utilisant leur URL directe, elles chargent depuis un serveur externe. Téléchargez-les et uploadez-les dans votre médiathèque.
Étape 7 : vérifier le thème et les plugins
Si le problème persiste, un thème ou un plugin génère des URLs en HTTP dans son code.
Désactivez tous vos plugins d’un coup, puis réactivez-les un par un en testant après chaque activation. Quand le cadenas disparaît à nouveau, vous avez trouvé le coupable. Vérifiez si une mise à jour est disponible — ce type de bug est souvent corrigé dans les versions récentes.
Le cas des plateformes Wix et Shopify
Sur Wix : le certificat SSL est activé automatiquement. Le contenu mixte apparaît quand vous avez intégré du contenu externe via un bloc HTML personnalisé — un widget tiers, un formulaire, un script de suivi. Ouvrez l’éditeur, repérez ces blocs et vérifiez chaque URL.
Sur Shopify : même logique. Les problèmes viennent généralement de thèmes achetés sur des marketplaces tierces avec des appels HTTP codés en dur, ou d’applications mal configurées. La correction se fait dans les fichiers Liquid du thème.
Étape 8 : vider le cache
Après chaque correction, videz systématiquement le cache avant de tester — sinon votre navigateur affiche l’ancienne version de la page et vous pensez que la correction n’a pas fonctionné.
Ctrl+Shift+R sur Windows, Cmd+Shift+R sur Mac pour forcer le rechargement. Videz aussi le cache de votre plugin WordPress (WP Rocket, LiteSpeed Cache, W3 Total Cache) et celui de votre hébergeur si votre offre en inclut un.
Testez toujours dans une fenêtre de navigation privée — elle ne charge aucune version mise en cache.
Votre site est toujours en http et non sécurisé ?
Passer un site en HTTPS sans casser quelque chose demande de toucher le serveur, la base de données et parfois le code du thème. Un .htaccess mal modifié rend le site inaccessible. Une mise à jour de base de données incorrecte corrompt des données sérialisées.
Si vous préférez déléguer, nous nous en occupons. Un audit de site couvre ce diagnostic complet et la correction — certificat, redirections, contenu mixte et vérification de l’indexation Google après migration.
Les questions fréquentes sur le problème http / https et la sécurisation de site
C'est quoi la différence entre HTTP et HTTPS ?
HTTP (HyperText Transfer Protocol) est le protocole qui permet l’échange de données entre un navigateur et un serveur. Les données circulent en clair — n’importe qui capable d’intercepter la connexion peut les lire. HTTPS est la version sécurisée : un certificat SSL chiffre les données échangées, les rendant illisibles pour quiconque tenterait de les intercepter. Pour l’utilisateur, la différence visible c’est le cadenas dans la barre d’adresse et l’URL qui commence par https://.
Est-ce que le HTTPS améliore le référencement Google ?
Oui, mais c’est un signal parmi des centaines. Google l’a confirmé officiellement en 2014 — un site en HTTPS part avec un léger avantage sur un site en HTTP à contenu équivalent. En pratique, le gain direct sur le classement reste modeste. L’impact indirect est plus important : un site en HTTP affiche un avertissement « non sécurisé » dans Chrome, ce qui fait fuir les visiteurs et augmente le taux de rebond — un signal négatif que Google mesure.
Est-ce que le certificat SSL est gratuit ?
Oui, dans la grande majorité des cas. Let’s Encrypt est une autorité de certification gratuite, reconnue par tous les navigateurs, proposée directement par OVH, o2switch, Infomaniak et la plupart des hébergeurs français. Il se renouvelle automatiquement tous les 90 jours. Les certificats payants (entre 50 et 300 € par an) offrent des garanties supplémentaires — validation étendue avec le nom de l’entreprise dans la barre d’adresse, assurance en cas de faille — mais pour un site vitrine ou une boutique standard, Let’s Encrypt est largement suffisant.
Pourquoi mon site affiche "non sécurisé" alors que j'ai activé le SSL ?
Le certificat est actif, mais des ressources à l’intérieur de vos pages chargent encore en HTTP — images, scripts, polices. C’est ce qu’on appelle le contenu mixte. Le navigateur détecte que la page est sécurisée mais que certains éléments ne le sont pas, et affiche l’avertissement. La solution passe par la mise à jour des URLs en base de données et la correction des ressources externes, détaillées dans les étapes 5 et 6 de cet article.
Est-ce que passer en HTTPS peut casser mon site ?
Oui, si la migration est mal faite. Les erreurs les plus fréquentes : modifier les URLs dans les réglages WordPress avant d’avoir activé le certificat côté hébergeur (le site disparaît), effectuer un chercher-remplacer dans phpMyAdmin sur des données sérialisées (des données corrompues), ou oublier de mettre à jour les liens externes qui pointent vers votre ancien URL en HTTP. En suivant les étapes dans l’ordre décrit dans cet article et en faisant une sauvegarde complète avant de commencer, le risque est limité.
Faut-il rediriger toutes les pages en HTTP vers HTTPS ?
Oui, avec une redirection 301 permanente. Sans elle, vos pages existent en double — une version HTTP et une version HTTPS — et Google peut les considérer comme du contenu dupliqué. Les liens que vous recevez vers la version HTTP n’alimentent pas la version HTTPS. La redirection 301 consolide tout : elle indique à Google quelle est la version de référence et transfère l’autorité accumulée.
Mon site e-commerce doit-il absolument être en HTTPS ?
Oui, sans exception. Les navigateurs bloquent activement les formulaires de paiement sur des pages non sécurisées. Stripe, PayPal et la plupart des solutions de paiement refusent de fonctionner sur un site en HTTP. Au-delà de la technique, un avertissement « non sécurisé » sur une page de commande suffit à faire abandonner un acheteur à deux clics de payer. Le RGPD impose également la protection des données personnelles collectées — un site e-commerce en HTTP expose son propriétaire à des risques légaux.
Combien de temps prend la migration HTTP vers HTTPS ?
Sur un site simple avec peu de contenu, une heure suffit si tout se passe bien. Sur une boutique WooCommerce avec des centaines de produits, des images mal référencées et des plugins tiers, comptez une demi-journée — entre le diagnostic, la mise à jour de la base de données, la vérification page par page et les tests. La partie qui prend le plus de temps n’est pas la technique mais le débogage des cas particuliers : un plugin qui génère des URLs en dur, une image hébergée sur un serveur externe qui ne répond plus, un thème avec des appels HTTP cachés dans ses options.
Google va-t-il re-indexer mon site après la migration ?
Oui. Après une migration HTTP vers HTTPS correctement effectuée avec des redirections 301, Google détecte les nouvelles URLs et met à jour son index progressivement. Sur un petit site, ça prend quelques jours à quelques semaines. Sur un site avec beaucoup de pages, jusqu’à deux mois. Vous pouvez accélérer le processus en soumettant votre sitemap mis à jour dans Google Search Console sous la nouvelle propriété HTTPS, et en demandant une inspection des URLs principales.
