Chrome passe au HTTPS par défaut : votre site risque-t-il un avertissement ?

Pendant des années, un site sans HTTPS affichait simplement la mention « Non sécurisé » dans la barre d'adresse, que beaucoup de visiteurs ne lisaient même pas. Ça change : Google a annoncé que Chrome allait demander l'accord de l'internaute avant d'ouvrir un site public qui ne propose pas de connexion sécurisée. Pour un dirigeant, l'enjeu est très concret : une page d'avertissement entre votre visiteur et votre site, c'est un visiteur qui peut renoncer avant d'avoir lu la première ligne.

La bonne nouvelle, c'est que dans l'immense majorité des cas, la vérification prend quelques minutes et la correction est simple. Voici ce qu'il faut savoir.

Ce que Google a annoncé

Dans un billet publié en octobre 2025 sur le blog Google Online Security, l'équipe sécurité de Chrome détaille le calendrier suivant (Google Online Security Blog) :

• Chrome 147 (avril 2026) : le réglage « Toujours utiliser des connexions sécurisées » est activé d'office pour les utilisateurs inscrits à la Navigation sécurisée renforcée (Enhanced Safe Browsing), soit plus d'un milliard de personnes selon Google.
• Chrome 154 (octobre 2026) : ce réglage devient actif par défaut pour tous les utilisateurs. Chrome tente alors chaque connexion en HTTPS et, si le site ne le propose pas, affiche un avertissement que l'internaute peut contourner.

Quelques précisions utiles pour relativiser sans minimiser :

• Le changement concerne les sites publics. Les adresses privées (réseau local, par exemple) sont traitées différemment.
• L'avertissement peut être contourné : l'internaute peut choisir de continuer. Mais c'est un frein, et personne ne sait combien de visiteurs hésiteront devant une page d'alerte sur le site d'une entreprise qu'ils ne connaissent pas encore.
• Dans une expérience menée sur Chrome 141, Google indique que l'utilisateur médian voit moins d'un avertissement par semaine, et le 95e percentile moins de trois. Autrement dit, la grande majorité du web est déjà en HTTPS : c'est précisément pour cela que les sites restés en HTTP deviennent des exceptions visibles.

Le calendrier peut évoluer. Avant d'agir sur la foi d'un article, y compris celui-ci, consultez les notes de version de Chrome pour la date exacte de déploiement.

Pourquoi ça compte au-delà du navigateur

Ce n'est pas qu'une question d'affichage.

La confiance. Un visiteur qui remplit un formulaire de contact ou un devis transmet un nom, un e-mail, parfois un téléphone. Sans HTTPS, ces données transitent en clair. Un message d'alerte avant même d'arriver sur la page fait mauvais effet pour un artisan, un cabinet ou une boutique dont le site est la première impression.

Le référencement. Google indique dans sa documentation Search Central que servir son site en HTTPS fait partie des éléments qu'il examine dans l'expérience de page. C'est un signal parmi beaucoup d'autres, pas un levier magique, mais un site en HTTP cumule un handicap évitable. Ça s'inscrit dans les bases du SEO technique : on règle d'abord les fondations.

La mesure. Mal configuré, le passage HTTP vers HTTPS crée des doublons d'URL, des redirections en chaîne et des statistiques éclatées entre deux versions du même site.

Vérifier votre site en dix minutes

Pas besoin d'outil payant. Voici la séquence à suivre.

1. Tester les quatre variantes de l'adresse

Tapez successivement http://votresite.fr, http://www.votresite.fr, https://votresite.fr et https://www.votresite.fr. Les quatre doivent aboutir à une seule adresse finale, en HTTPS. Si l'une affiche une erreur de certificat ou reste en HTTP, c'est le premier point à corriger.

2. Vérifier la redirection

La version HTTP doit rediriger vers la version HTTPS par une redirection permanente (301), en une seule étape. Une chaîne de trois redirections consécutives ralentit l'affichage et complique le travail des robots de Google.

3. Chercher le contenu mixte

Le « contenu mixte » apparaît quand une page en HTTPS charge encore une image, un script ou une police depuis une adresse en HTTP. Le navigateur peut alors bloquer l'élément ou afficher un cadenas barré. Ouvrez la console des outils de développement du navigateur (touche F12) : les ressources concernées y sont signalées. Les images insérées il y a plusieurs années dans le contenu sont les coupables habituelles.

4. Contrôler le certificat

Le certificat doit couvrir toutes les variantes utilisées (avec et sans www, sous-domaines compris) et se renouveler automatiquement. Un certificat expiré produit une alerte bien plus bloquante qu'un simple site en HTTP. La plupart des hébergeurs proposent aujourd'hui des certificats gratuits avec renouvellement automatique : vérifiez simplement que l'option est active chez le vôtre.

5. Aligner les références internes

Une fois le site en HTTPS, tout le reste doit suivre :

• les liens internes et la balise canonique pointent vers les adresses en HTTPS ;
• le plan de site (sitemap) liste uniquement des URL en HTTPS ;
• une propriété HTTPS (ou de domaine) est déclarée dans Search Console ;
• les outils externes (formulaires, fiche d'établissement, réseaux sociaux, signatures e-mail) utilisent les adresses sécurisées.

Les pièges classiques

Oublier un sous-domaine. Le site principal est propre, mais le blog, la boutique ou la page de prise de rendez-vous hébergés sur un sous-domaine restent en HTTP. C'est l'oubli le plus fréquent.

Activer HSTS trop tôt. L'en-tête HSTS indique au navigateur de ne plus jamais essayer le HTTP sur votre domaine. C'est une bonne pratique, mais à activer une fois que tout le site et tous ses sous-domaines fonctionnent correctement en HTTPS, car un retour en arrière est lent à propager.

Négliger les embeds anciens. Une carte, une vidéo ou un widget intégré à l'époque en HTTP peut casser l'affichage sécurisé d'une page entière. Pensez-y aussi quand vous faites le tri des scripts tiers de votre site.

Migrer sans plan. Passer en HTTPS pendant une refonte demande la même rigueur qu'une migration d'adresses : redirections testées, sitemap mis à jour, suivi dans Search Console dans les semaines qui suivent.

Quelle que soit votre plateforme

Ce chantier concerne tous les types de sites, quelle que soit leur technologie. Sur un constructeur de site ou un CMS, le HTTPS est souvent déjà géré par l'hébergeur : il suffit alors de vérifier les points ci-dessus, surtout les anciens contenus et les sous-domaines. Sur un site développé sur mesure, la configuration se décide à la conception : certificat, redirections, en-têtes de sécurité et sitemap sont réglés d'emblée et se vérifient à chaque mise en ligne. Dans les deux cas, ce n'est pas un projet, c'est une vérification à planifier une fois par an.

Et si votre site est déjà en HTTPS ?

Alors vous n'aurez probablement rien à changer, mais profitez de l'occasion pour un contrôle de routine. Notez la date d'expiration de votre certificat et assurez-vous qu'un e-mail d'alerte arrive à une adresse réellement lue. Faites aussi le tour des pages les plus anciennes : ce sont elles qui cumulent le plus souvent un lien ou une image oubliés en HTTP. Une demi-heure par an suffit à éviter la mauvaise surprise le jour où un visiteur, ou un client potentiel, tombe sur une alerte.

En résumé

• Chrome 154, annoncé pour octobre 2026, doit rendre l'accès sécurisé obligatoire par défaut pour les sites publics, avec un avertissement contournable en cas d'absence de HTTPS.
• Testez les quatre variantes de votre adresse, la redirection 301, le contenu mixte et le certificat.
• Alignez ensuite canoniques, sitemap, Search Console et outils externes.
• Traitez les sous-domaines et les anciens contenus : c'est là que se cachent les oublis.

Vous n'êtes pas sûr de l'état de votre site, ou vous préparez une refonte et voulez que la sécurité, le SEO et la performance soient réglés dès le départ ? Contactez Origin : on vérifie votre configuration avec vous et on vous dit précisément ce qui, le cas échéant, mérite d'être corrigé. Vous pouvez aussi découvrir nos expertises en sites sur mesure, référencement et performance.