« Non sécurisé » dans le navigateur : pourquoi et comment corriger

Cause n°1 : pas de HTTPS (ou pas de redirection)

Si votre site est servi en http:// sans certificat, le navigateur le marque systématiquement « Non sécurisé », car les données circulent en clair. La solution est d'installer un certificat SSL/TLS — gratuit avec Let's Encrypt, et le plus souvent inclus et activable en un clic sur les hébergements mutualisés (fonction « SSL/TLS » ou « AutoSSL » de cPanel) — puis de rediriger tout le trafic HTTP vers HTTPS.

Cas piégeux très fréquent : le certificat existe et la page https:// fonctionne, mais la version http:// reste accessible en parallèle. Tant qu'un visiteur (ou un ancien lien) peut atterrir sur la page non chiffrée, l'avertissement réapparaît. Une redirection 301 permanente, côté serveur, règle définitivement le problème.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

Cause n°2 : un certificat invalide ou expiré

Le message « Votre connexion n'est pas privée » (codes NET::ERR_CERT_…) signale un certificat en cause : expiré, ne couvrant pas le bon domaine, ou dont la chaîne de confiance est incomplète (un certificat intermédiaire manquant). Le certificat Let's Encrypt expire tous les 90 jours : s'il n'est pas renouvelé automatiquement, le site bascule en erreur du jour au lendemain, sans prévenir.

Vérifiez la date d'expiration et la couverture exacte du domaine. CheckCyber affiche l'émetteur, le nombre de jours restants et le protocole négocié pour diagnostiquer ce point en un coup d'œil, et vous alerte quand l'échéance approche.

Cause n°3 : du contenu mixte

Votre page est bien en HTTPS mais charge certaines ressources (images, scripts, polices, vidéos) en http:// ? C'est le « contenu mixte » (mixed content) : le navigateur affiche alors un cadenas barré ou « contenu non sécurisé », car une partie de la page voyage encore en clair. Il faut corriger ces URL pour qu'elles pointent toutes vers https://, généralement dans le contenu de votre site ou les réglages d'un thème. Notre guide dédié détaille la marche à suivre, y compris la directive upgrade-insecure-requests qui automatise la correction.

Cause n°4 : le cas du « www » et des sous-domaines

Un grand classique : le certificat couvre exemple.com mais pas www.exemple.com (ou l'inverse), si bien que le site est sécurisé sur une URL et « non sécurisé » sur l'autre. Émettez un certificat couvrant les deux variantes, ou un certificat wildcard (*.exemple.com), et assurez-vous que la redirection envoie bien vers une seule version canonique (par exemple toujours vers https://exemple.com).

Pensez aussi aux sous-domaines réellement utilisés (boutique., blog.) : chacun a besoin d'être couvert par un certificat valide, sans quoi il déclenchera l'avertissement de son côté.

Vérifier que tout est rentré dans l’ordre

Après correction, testez chaque variante d'adresse : http://exemple.com, http://www.exemple.com, https://www.exemple.com doivent toutes mener, via redirection, à votre version sécurisée canonique, avec le cadenas. Videz le cache de votre navigateur (un ancien avertissement peut rester affiché) et relancez un audit CheckCyber pour confirmer le certificat, la redirection et l'absence de contenu mixte.