Comment supprimer l’alerte « Non sécurisé »

Ce que signifie vraiment l’alerte

Les navigateurs affichent « Non sécurisé » dans la barre d’adresse quand la page elle-même est arrivée en HTTP, sans chiffrement. N’importe qui sur le même Wi-Fi, un routeur compromis ou l’opérateur du réseau peut lire et modifier ce que le visiteur envoie et reçoit, y compris les mots de passe et les formulaires de contact. Un cadenas barré d’un avertissement, ou l’absence de cadenas sur une page https://, indique généralement du contenu mixte : la page est en HTTPS, mais une image, un script ou un formulaire y utilise encore http://.

L’alerte est désormais plus difficile à ignorer. Avec Chrome 154, sorti en octobre 2026, l’option « Toujours utiliser des connexions sécurisées » est activée par défaut : Chrome essaie d’abord HTTPS et, en cas d’échec, affiche un avertissement plein écran et demande l’accord du visiteur avant d’ouvrir un site HTTP public. Chrome affiche aussi cet avertissement quand une redirection sur le chemin de votre page utilise HTTP, même si la page finale est en HTTPS.

Étape 1 : installez un certificat gratuit

La plupart des hébergeurs incluent un certificat gratuit. Cherchez « SSL/TLS », « Let’s Encrypt » ou « AutoSSL » dans votre espace client et activez-le pour yourdomain.com et www.yourdomain.com. Si vous gérez votre propre serveur, Certbot obtient un certificat Let’s Encrypt gratuit et le renouvelle automatiquement :

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
# Apache: install python3-certbot-apache and use --apache instead of --nginx

Payer un certificat ne rend pas la connexion plus sûre. Un certificat gratuit validé par domaine offre le même chiffrement et le même cadenas.

Étape 2 : redirigez HTTP vers HTTPS

Le certificat seul ne suffit pas : les gens tapent encore votre adresse sans https://, et d’anciens liens pointent vers http://. Répondez à chaque requête HTTP par une redirection permanente (301) vers le même chemin en HTTPS. Sur nginx :

server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://yourdomain.com$request_uri;
}

Sur Apache ou un hébergement mutualisé, placez ceci en haut du fichier .htaccess à la racine de votre site :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Derrière Cloudflare, activez SSL/TLS → Edge Certificates → Always Use HTTPS et réglez le mode SSL sur Full (strict) dès que votre serveur dispose de son propre certificat valide. Le mode « Flexible » combiné à une redirection sur votre serveur provoque souvent des boucles de redirection sans fin.

Étape 3 : passez WordPress (ou votre CMS) en https://

Dans WordPress, ouvrez Réglages → Général et passez l’Adresse web de WordPress et l’Adresse web du site en https://. Les liens déjà enregistrés dans les articles et les widgets indiquent toujours http://. Avec WP-CLI, vous pouvez les remplacer en une fois ; lancez d’abord la simulation et sauvegardez la base de données avant l’exécution réelle :

wp option get siteurl
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --dry-run
# looks right? back up the database, then run it again without --dry-run

Étape 4 : corrigez le contenu mixte

Ouvrez la page, appuyez sur F12 et regardez la Console : le navigateur liste chaque ressource qu’il a bloquée ou dégradée parce qu’elle était demandée en http://. Passez ces URL en https:// (ou en chemins relatifs) et remplacez tout widget tiers qui ne gère pas HTTPS. Le guide sur les redirections et le contenu mixte fournit des commandes de recherche et une ligne Content-Security-Policy qui met à niveau automatiquement les requêtes restantes.

Étape 5 : vérifiez chaque étape de la chaîne de redirection

Le nouvel avertissement de Chrome se déclenche aussi quand une étape de redirection utilise HTTP, par exemple https://yourdomain.com → http://www.yourdomain.com → https://www.yourdomain.com. Suivez la chaîne depuis chaque adresse de départ et vérifiez que seule la toute première requête est en http:// :

for u in http://yourdomain.com http://www.yourdomain.com https://yourdomain.com https://www.yourdomain.com; do
  echo "== $u"; curl -sIL "$u" | grep -iE '^(HTTP/|location:)'
done

Idéalement, chaque adresse atteint la page finale en une seule redirection. Mettez aussi à jour les liens que vous maîtrisez : votre fiche d’établissement Google, vos réseaux sociaux, votre signature e-mail et vos annonces.

Étape 6 : verrouillez avec HSTS

Quand chaque page et chaque sous-domaine fonctionnent en HTTPS, ajoutez l’en-tête Strict-Transport-Security pour que les navigateurs ignorent complètement HTTP lors des visites suivantes. Commencez par un max-age court et augmentez-le quand vous êtes sûr de vous. Voir HSTS expliqué.

Vous voyez encore un avertissement ?

• Une erreur de certificat en plein écran (par exemple NET::ERR_CERT_DATE_INVALID) est un autre problème : voir les erreurs de certificat SSL expliquées.
• Sur certaines pages seulement : ces pages chargent encore quelque chose en http://, ou un formulaire envoie vers une adresse http://.
• Pour certains visiteurs seulement : un ancien favori ou lien en http://, une redirection en cache, ou un sous-domaine sans certificat.
• Après un changement d’hébergeur ou de CDN : le nouveau serveur n’a peut-être pas encore le certificat, ou il sert un certificat pour un autre nom.

Ce que vérifie HackGrade

L’analyse gratuite de HackGrade vérifie la redirection HTTP vers HTTPS, la fiabilité du certificat et sa date d’expiration, la version de TLS, HSTS et le contenu mixte de votre page d’accueil, et explique les premières corrections en langage simple. Elle lit uniquement ce que voit le navigateur de n’importe quel visiteur.