Chrome 154 : mon site est en HTTP, ce qui change

Où en est-on, au jour près

Ce guide a été écrit quand l’échéance était encore devant nous. Elle ne l’est plus : Chrome 154 est passé en canal stable le 22 septembre 2026, et son déploiement se poursuit sur le parc installé pendant les semaines suivantes. Le calendrier complet, avec les seules dates qui comptent :

• Avril 2026 — Chrome 147. Le réglage « Toujours utiliser des connexions sécurisées » est activé d’office pour les utilisateurs de la Protection renforcée de Chrome. Une partie du public voit l’avertissement depuis ce moment-là.
• 22 septembre 2026 — Chrome 154 en canal stable. La version qui généralise le réglage est publiée. Les notes de version de Chrome sont explicites : le navigateur « interroge l’utilisateur par défaut lorsqu’il se connecte à un site par une connexion non sécurisée ».
• Octobre 2026 — généralisation. Chrome ne met pas tout le monde à jour le même jour : le déploiement d’une version s’étale sur plusieurs semaines. C’est pourquoi Google a annoncé « octobre 2026 » alors que la version est sortie en septembre.

Autrement dit : si votre site est en http://, la question n’est plus de savoir quand préparer la migration, mais combien de visiteurs ont déjà vu l’écran d’avertissement cette semaine.

Ce qui se passe, exactement

Quand un visiteur ouvre une adresse en http://, le navigateur ne charge plus la page directement. Il affiche d’abord un écran d’avertissement, avec deux boutons : Continuer vers le site et Retour. Chez Chromium, la fonctionnalité porte un nom parlant : Ask before HTTP, demander avant d’ouvrir en clair.

Trois précisions comptent, et elles sont presque toujours escamotées dans les articles qui annoncent la nouvelle.

Ce n’est pas un blocage. L’avertissement est contournable : un visiteur déterminé passera. Le problème n’est donc pas la petite minorité de fidèles qui cliqueront « Continuer » ; c’est l’inconnu qui arrive depuis une recherche, voit un écran d’alerte sur un site qu’il ne connaît pas, et fait demi-tour. Sur ce trafic-là, le taux de perte est proche de 100 %. C’est exactement le mécanisme d’un certificat invalide, dont on sait qu’il vide une audience en quelques heures.

L’exception accordée dure quinze jours. C’est le chiffre à connaître, et il explique pourquoi le propriétaire du site est le dernier à voir le problème. Quand un visiteur clique « Continuer », Chrome mémorise sa décision pour quinze jours, et ce délai est remis à zéro à chaque visite. Vous qui consultez votre propre site tous les jours, vous ne reverrez jamais l’écran après le premier clic. Vos visiteurs réguliers non plus. Vos visiteurs nouveaux, eux, le verront tous, à chaque fois.

Ce n’est pas une échéance future. Le même réglage est actif depuis avril 2026 pour les utilisateurs de la Protection renforcée, et depuis le 22 septembre pour tous ceux dont le Chrome est passé en 154. Le rendez-vous d’octobre n’ouvre pas le robinet : il achève de l’ouvrir en grand.

Ce qui n’est pas concerné

Google déploie ce réglage dans sa variante « sites publics ». La distinction est réelle et elle épargne beaucoup de monde :

• les adresses IP privées, du type 192.168.0.1 : votre box, votre imprimante réseau, votre NAS, l’interface d’administration d’un routeur ;
• les noms d’hôte à étiquette unique, sans point — serveur, nas, le nom d’une machine sur un réseau local ;
• les raccourcis d’intranet du type intranet/ ;
• localhost et les noms en .local, utilisés par les développeurs et par la découverte de services sur réseau local ;
• les domaines qui ont déjà envoyé un en-tête HSTS au navigateur — il n’y a rien à demander à l’utilisateur pour un site qui a déclaré ne jamais répondre en clair. C’est une raison de plus de faire l’étape 4 de la migration ci-dessous.

La raison est technique et non idéologique : on ne peut pas obtenir de certificat reconnu pour un nom qui n’est pas unique au monde. Personne ne peut prouver la propriété de 192.168.0.1, puisque des millions de réseaux l’utilisent en même temps. Ces adresses continueront donc à s’ouvrir sans avertissement.

En revanche, dès que votre site porte un nom de domaine public — le cas de tout site destiné à des clients — vous êtes concerné. Il n’y a pas de dérogation pour les petits sites, les sites vitrines, les sites sans formulaire ni les sites « qui ne collectent rien ».

Le piège que personne ne voit venir : votre site est en HTTPS, et l’avertissement s’affiche quand même

C’est le point le plus important de ce guide pour les sites déjà migrés, et celui qui va produire le plus de cas incompréhensibles dans les semaines qui viennent.

La documentation de Chromium est sans ambiguïté : l’avertissement se déclenche si une seule étape de la chaîne de redirection passe en clair, même lorsque la destination finale est en HTTPS. Et s’il y a plusieurs sauts non sécurisés, il y a plusieurs avertissements.

Or les chaînes de redirection sont partout, et elles sont invisibles depuis un navigateur :

• un raccourcisseur de liens ou un lien de suivi d’infolettre qui répond encore en http:// avant de rebondir vers votre page ;
• un ancien domaine que vous avez gardé et qui redirige vers le nouveau, avec une redirection posée il y a des années en clair ;
• un code QR imprimé sur un support, encodant une adresse en http:// qui aboutit bien, mais par une redirection ;
• un lien http://www.exemple.fr qui part vers http://exemple.fr avant d’aller enfin en https:// — la cascade classique, et elle compte comme deux étapes en clair.

Le test, sur une chaîne complète, tient en une commande :

curl -sIL http://exemple.fr | grep -i '^HTTP/\|^location:'

Vous devez voir une seule étape en http:// — la première, celle que vous ne pouvez pas éviter — puis du https:// jusqu’au bout. Si une adresse Location: intermédiaire commence par http://, c’est un avertissement pour tous les visiteurs qui empruntent ce chemin.

Ce que le HTTP coûte, en dehors de l’avertissement

Même en mettant l’avertissement de côté, rester en HTTP a un coût, et il se mesure. Ces effets-là existaient bien avant Chrome 154 et ne disparaîtront pas si vous décidez d’attendre.

Votre trafic de recommandation apparaît comme du trafic direct

C’est l’effet le moins connu et le plus pernicieux. Les navigateurs appliquent par défaut la politique de référent strict-origin-when-cross-origin. Traduction : quand une page en HTTPS pointe vers une page en HTTP, aucun référent n’est transmis. Le passage du chiffré au clair est traité comme une rétrogradation, et l’information est supprimée.

Conséquence pratique : si un blog, un annuaire, un forum ou un partenaire — tous en HTTPS aujourd’hui — vous envoie des visiteurs, votre outil de statistiques les compte en « direct ». Vous ne savez pas d’où ils viennent, vous ne pouvez pas identifier ce qui fonctionne, et vous sous-estimez mécaniquement la valeur des liens qu’on vous fait. Beaucoup de propriétaires de sites en HTTP concluent que leurs partenariats ne rapportent rien : en réalité, ils ne les voient pas.

La mention « Non sécurisé » est déjà affichée

Chrome et Firefox affichent « Non sécurisé » à côté de l’adresse de tout site en HTTP, depuis 2018. Et dès qu’une page contient un champ de mot de passe ou de carte bancaire, l’avertissement devient explicite, sous le champ lui-même, au moment précis où le visiteur allait taper quelque chose.

Vous êtes privé de HTTP/2 et HTTP/3

Aucun navigateur grand public n’implémente HTTP/2 ou HTTP/3 en clair. Rester en HTTP revient donc à rester en HTTP/1.1, avec une connexion par ressource et sans multiplexage. Sur une page ordinaire chargeant trente ou quarante fichiers, l’écart est visible sans outil de mesure — et il pèse sur les signaux de performance que Google observe.

Le référencement

HTTPS est un critère de classement annoncé par Google depuis 2014. Il est faible, et il serait malhonnête de promettre un gain de positions par la seule migration. Mais il est devenu un critère d’éligibilité plutôt que de départage : la quasi-totalité de vos concurrents l’ont, et à partir d’octobre, un utilisateur qui clique sur votre résultat verra un écran d’alerte avant votre page. Le taux de clic effectif, lui, va bouger nettement.

Migrer : la procédure complète

Sur un site ordinaire, l’opération prend d’une à trois heures et ne coûte rien. Les certificats Let’s Encrypt sont gratuits et automatiquement renouvelés ; tous les hébergeurs français grand public en proposent l’installation en un bouton depuis leur panneau de gestion. Si le vôtre facture le certificat en supplément, c’est un signal sur l’hébergeur, pas sur la technologie.

1. Obtenir le certificat, et vérifier ce qu’il couvre

Le piège le plus courant : un certificat émis pour exemple.fr mais pas pour www.exemple.fr, ou l’inverse. La moitié de vos visiteurs — ceux qui tapent l’autre forme, ou qui suivent un vieux lien — tombent alors sur une erreur de certificat, qui est pire qu’une page en HTTP : elle n’est pas contournable d’un clic. Vérifiez que les deux noms figurent dans le certificat avant de mettre la redirection en place.

2. Rediriger en 301, une seule fois

Une redirection permanente (301), pas temporaire (302) : c’est elle qui transfère l’antériorité de vos pages vers leurs nouvelles adresses. Et une seule redirection, pas deux en cascade : http://www doit aller directement à https:// sans repasser par http:// sans www.

Sur Apache, dans le .htaccess à la racine :

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://exemple.fr%{REQUEST_URI} [R=301,L]

Sur nginx, dans un bloc serveur dédié :

server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://exemple.fr$request_uri;
}

Le %{REQUEST_URI} — $request_uri chez nginx — n’est pas facultatif : sans lui, toutes vos pages profondes atterrissent sur l’accueil, et chacune de ces redirections est un lien entrant perdu.

Remarquez que les deux règles ci-dessus envoient directement vers l’adresse finale, en une étape. C’est ce que demande la section précédente sur les chaînes de redirection : une règle qui corrigerait d’abord le www en HTTP, puis le protocole, produirait deux sauts en clair et donc deux avertissements.

3. Corriger le contenu mixte

C’est l’étape qui casse les sites, et c’est celle qu’on découvre après coup. Une fois vos pages servies en HTTPS, toute ressource encore appelée en http:// — image, script, police, feuille de style — est soit bloquée, soit rattrapée en silence par le navigateur. Le sujet a ses propres pièges, notamment sur WordPress où un remplacement SQL direct casse les données sérialisées : il est traité en détail dans notre guide contenu mixte.

4. Passer HSTS en dernier, et prudemment

L’en-tête Strict-Transport-Security demande au navigateur de refuser définitivement le HTTP sur votre domaine. C’est ce qui ferme la fenêtre d’interception qui subsiste sur la toute première visite, avant même la redirection. C’est utile, et c’est le bon réflexe — une fois que tout le reste fonctionne.

Bonus direct depuis Chrome 154 : un domaine pour lequel le navigateur a déjà reçu un en-tête HSTS ne déclenche pas l’avertissement, puisqu’il ne tentera même pas le HTTP. HSTS n’est donc plus seulement une bonne pratique de sécurité : c’est la ceinture qui protège vos visiteurs des avertissements dus à un vieux lien.

L’ordre importe, parce que HSTS n’a pas de marche arrière immédiate. Un navigateur qui a reçu l’en-tête une fois refusera le HTTP pendant toute la durée annoncée, même si vous retirez l’en-tête entre-temps. Commencez donc par une durée courte, max-age=300, le temps de vérifier que rien ne casse ; passez ensuite à six mois (max-age=15552000), la valeur couramment recommandée.

Quant à la directive preload, qui inscrit votre domaine dans une liste embarquée dans les navigateurs : ne l’ajoutez pas tant que vous n’êtes pas certain de ne jamais revenir en arrière, y compris sur les sous-domaines. La sortie de cette liste se compte en mois, au rythme des versions des navigateurs, et aucune manipulation de votre côté ne l’accélère. Le détail des autres en-têtes est dans notre guide en-têtes de sécurité HTTP.

5. Mettre à jour ce qui pointe vers l’ancienne adresse

• Search Console : si votre propriété est de type « préfixe d’URL », elle ne suit pas le changement de protocole — il faut déclarer une nouvelle propriété en https://. Une propriété de type « domaine », validée par DNS, couvre les deux d’office ; c’est celle à privilégier.
• Le plan du site et les balises canoniques : ils doivent tous annoncer les adresses en https://. Un canonique laissé en HTTP demande explicitement à Google d’indexer l’ancienne version.
• Les liens écrits en dur dans vos pages, vos modèles d’e-mail, vos signatures et vos anciennes infolettres.
• Vos statistiques : attendez-vous à une rupture visible dans les courbes, et à voir apparaître d’un coup les sources de trafic qui étaient jusque-là comptées en « direct ».

Le piège du demi-chemin

Il existe un état intermédiaire beaucoup plus répandu qu’on ne le croit : le certificat est installé, le site répond correctement en https://… et continue à répondre en http://, sans redirection. Personne ne s’en aperçoit, parce que le propriétaire tape lui-même l’adresse en HTTPS et voit un cadenas.

Cet état cumule les inconvénients des deux :

• Google voit deux sites identiques à deux adresses et doit choisir lequel indexer. Vos liens entrants se répartissent entre les deux versions au lieu de s’additionner.
• Les visiteurs qui arrivent par un ancien lien, un signet ou un annuaire restent en clair — et verront l’avertissement d’octobre, certificat ou pas.
• Le cadenas apparaît ou non selon le point d’entrée, ce qui produit des rapports de bug incompréhensibles.

Le test tient en une ligne, depuis un terminal : curl -I http://exemple.fr. Vous devez voir un 301 et un en-tête Location: pointant vers https://. Si vous voyez un 200, votre site est encore servi en clair, quoi qu’en dise le cadenas de votre propre navigateur.

Vous gérez un parc de machines

Si vous administrez les Chrome d’une entreprise, d’une école ou d’une collectivité, le comportement se pilote par stratégie, et il vaut mieux le savoir avant que le service d’assistance ne reçoive les premiers appels.

• HttpsOnlyMode — impose ou relâche le réglage sur les postes gérés. Les valeurs utiles sont force_balanced_enabled (le comportement par défaut de Chrome 154, avertissement sur les sites publics seulement) et force_enabled (avertissement partout, y compris sur le réseau interne).
• HttpAllowlist — la liste des hôtes pour lesquels l’avertissement est supprimé. C’est la bonne réponse pour un équipement interne joignable par un nom public mais incapable de servir du HTTPS : on lève l’avertissement pour cette machine-là, pas pour tout le web.

Désactiver globalement le réglage sur tout un parc est techniquement possible, et c’est une mauvaise affaire : cela retire la protection sur l’ensemble des sites visités pour ne rien régler sur le seul qui pose problème.

Et les autres navigateurs ?

Firefox propose depuis plusieurs années un mode « HTTPS uniquement » à trois états — désactivé, activé, activé en navigation privée seulement — et applique déjà HTTPS par défaut en navigation privée. Ce n’est donc pas, en navigation normale, le même degré d’automatisme que Chrome 154.

Edge partage le moteur Chromium : la mécanique y est présente. Mais la date d’activation par défaut relève de Microsoft, pas de Google ; ne présumez pas qu’elle sera la même, dans un sens comme dans l’autre. En pratique, la part de marché de Chrome suffit à rendre la question secondaire : ce qui décide de votre trafic, c’est ce que fait Chrome.

Et si migrer est réellement impossible ?

Le cas existe. Un service accessible uniquement par son adresse IP, un équipement industriel dont l’interface web n’a pas été mise à jour depuis dix ans, un outil interne derrière un pare-feu : ces situations ne se résolvent pas par un certificat.

La bonne nouvelle est que la variante « sites publics » décrite plus haut couvre déjà la plupart de ces cas : une IP privée ou un nom d’hôte sans point ne déclenche pas l’avertissement. Restent les services publiquement accessibles qui ne peuvent pas obtenir de certificat — une IP publique nue, par exemple. Là, il n’y a pas de contournement propre : la réponse est de placer le service derrière un nom de domaine, même gratuit, ce qui rend le certificat possible.

Ce qu’il ne faut pas faire : demander à vos utilisateurs de désactiver le réglage dans leur navigateur. C’est possible, Google l’a prévu, mais c’est reporter sur eux le coût d’un problème qui est le vôtre — et cela abaisse leur protection sur tous les sites qu’ils visitent, pas seulement le vôtre.

Vérifier votre site maintenant

Notre outil d’analyse ouvre votre page depuis nos serveurs et vous dit, en une adresse : si le site répond en HTTPS, si la redirection depuis HTTP est en place, si le certificat est valide et pour combien de temps, si HSTS est présent et avec quelle durée, et s’il reste du contenu mixte à corriger.

Une fois la migration faite, le vérificateur de liens complète le tableau : il repère les liens sortants que vous faites encore en http://, et signale ceux qui répondent par une redirection. Les deux méritent votre attention : un lien en clair envoie votre visiteur sur l’écran d’avertissement avant de l’envoyer chez le destinataire, et il est facile à oublier parce qu’il fonctionne parfaitement aujourd’hui.

Trois choses à contrôler ce mois-ci, dans l’ordre, si vous n’en faites que trois : votre site répond bien en https:// ; la redirection depuis http:// existe et se fait en une seule étape ; aucun de vos liens sortants, codes QR et anciens domaines ne passe par une étape en clair.