L’avertissement « La connexion à ce site n’est pas sécurisée » signifie que le navigateur ne peut pas garantir une communication chiffrée et authentifiée avec le site. Commencez par vérifier l’adresse, la date et l’heure de l’appareil, puis essayez un autre réseau et un navigateur à jour.

Si l’alerte concerne un seul site, ne saisissez aucun mot de passe ni numéro bancaire : le certificat TLS du site peut être expiré, mal installé ou associé au mauvais domaine. Si elle touche plusieurs sites, le problème vient plus probablement de l’appareil, du réseau, d’un proxy, d’un antivirus ou d’une interception HTTPS.

Pour le propriétaire du site, la correction consiste généralement à installer ou renouveler un certificat valide, fournir la chaîne intermédiaire complète, rediriger HTTP vers HTTPS et remplacer toutes les ressources HTTP restantes. Pour le visiteur, contourner l’alerte ne constitue pas une réparation. Ce guide sépare donc clairement les gestes sans risque pour l’utilisateur et les interventions techniques réservées à l’administrateur.

Table de matières

Que signifie « La connexion à ce site n’est pas sécurisée » ?

HTTPS protège l’échange entre le navigateur et le serveur au moyen de TLS. Pour comprendre la différence entre les deux protocoles, consultez aussi notre comparaison SSL ou TLS : lequel sécurise réellement une connexion ?.

Le certificat présenté par le serveur doit être valide dans le temps, correspondre au nom de domaine demandé et être rattaché à une autorité reconnue par l’appareil. Si l’une de ces vérifications échoue, le navigateur affiche une alerte ou bloque la page.

Le message peut aussi apparaître lorsqu’une page utilise simplement HTTP. Dans ce cas, il n’existe aucun chiffrement entre l’appareil et le site. Un tiers placé sur le même réseau pourrait observer ou modifier certaines données. Chrome distingue notamment les états sécurisé, informations ou non sécurisé, et dangereux. L’absence de cadenas ne prouve pas qu’un site est frauduleux, mais elle indique que la connexion ne fournit pas le niveau de protection attendu.

Enfin, une page HTTPS peut charger une image, un script, une police ou une feuille de style en HTTP. Ce contenu mixte dégrade la sécurité et peut être bloqué. Le certificat peut alors être correct alors que la page reste signalée comme imparfaitement sécurisée.

Faut-il continuer malgré l’avertissement du navigateur ?

Ne continuez pas si la page demande un identifiant, un paiement, une donnée médicale, un document ou une information personnelle. Ne cliquez pas non plus sur un lien reçu de manière inattendue par e-mail ou messagerie. Vérifiez l’orthographe du domaine : une lettre ajoutée, un tiret ou une extension différente peut révéler une imitation.

Le bouton permettant de poursuivre existe parfois pour les environnements internes, les laboratoires ou les équipements administrés avec un certificat privé. Il ne transforme pas la connexion en connexion fiable. Sur un site public, la bonne réaction est de revenir en arrière et d’informer le propriétaire.

Dans une entreprise, un proxy de sécurité peut inspecter les connexions HTTPS. Si son certificat racine n’est pas correctement distribué, des erreurs apparaissent. Google indique par exemple qu’un proxy d’interception comme Zscaler, Palo Alto Networks ou Fortinet peut provoquer NET::ERR_CERT_AUTHORITY_INVALID. Dans ce cas, contactez l’équipe informatique : n’installez jamais un certificat reçu d’un inconnu.

Tableau de diagnostic des messages les plus fréquents

Message ou code	Cause probable	Vérification utile	Responsable de la correction
Site en HTTP, « Non sécurisé »	HTTPS absent	Ajouter https:// à l’adresse	Propriétaire du site
NET::ERR_CERT_DATE_INVALID	Certificat expiré ou horloge incorrecte	Contrôler date, heure et validité	Visiteur ou propriétaire
NET::ERR_CERT_COMMON_NAME_INVALID	Domaine non couvert	Comparer domaine et certificat	Propriétaire
NET::ERR_CERT_AUTHORITY_INVALID	Autorité inconnue ou interception	Tester autre réseau et appareil	Propriétaire ou IT
SEC_ERROR_UNKNOWN_ISSUER	Chaîne ou racine absente	Examiner la chaîne TLS	Propriétaire ou IT
Contenu mixte	Ressource HTTP dans page HTTPS	Ouvrir la console Sécurité	Développeur
Erreur HSTS	Certificat invalide sur domaine strict	Corriger le certificat, sans contournement	Propriétaire
Alerte sur tous les sites	Antivirus, proxy, malware ou horloge	Tester un réseau fiable	Visiteur ou IT

Le code exact compte davantage que le texte général. Notez-le avant d’effacer les données du navigateur. Une capture d’écran contenant le code, l’heure et le domaine aide l’hébergeur ou l’administrateur à reproduire l’incident.

Première vérification : adresse, date, heure et réseau

Relisez l’adresse caractère par caractère. Pour distinguer domaine, sous-domaine et chemin, notre explication sur ce qu’est une URL et comment la lire fournit les repères essentiels. Accédez au site depuis un favori connu ou saisissez directement son domaine au lieu de suivre un lien.

Vérifiez ensuite la date, l’heure et le fuseau horaire. Mozilla confirme qu’une horloge incorrecte peut faire apparaître un certificat valide comme expiré ou pas encore valide.

Passez du Wi-Fi aux données mobiles, ou inversement. Si l’alerte disparaît, le routeur, le DNS, un portail captif ou un dispositif d’inspection du premier réseau est probablement impliqué. Sur un Wi-Fi public, ouvrez une page HTTP neutre pour afficher le portail de connexion, puis reconnectez-vous au site. Évitez toute opération sensible tant que le réseau n’est pas identifié.

Testez enfin le même domaine sur un second appareil. Un seul appareil touché oriente vers son horloge, son navigateur, son antivirus ou son magasin de certificats. Tous les appareils touchés sur plusieurs réseaux orientent vers le serveur. Cette comparaison simple évite des suppressions de cache inutiles.

Corriger l’alerte dans Chrome et Microsoft Edge

Mettez Chrome ou Edge à jour, fermez toutes les fenêtres puis relancez le navigateur. Testez en navigation privée : si la page s’ouvre, une extension ou une donnée locale peut intervenir. Désactivez temporairement les extensions récemment ajoutées, surtout celles qui modifient le trafic, les publicités, les VPN ou la sécurité.

Effacez uniquement les données du site concerné avant de supprimer tout l’historique. Un cookie défectueux ne rend pas un certificat invalide, mais une ancienne redirection ou un état HSTS peut compliquer le diagnostic. Redémarrez ensuite l’appareil et le routeur.

Si le code indique une autorité inconnue sur un ordinateur professionnel, arrêtez le diagnostic autonome et contactez l’administrateur. Notre guide dédié à NET::ERR_CERT_AUTHORITY_INVALID détaille les vérifications propres à ce code.

Si l’erreur ne vise qu’un domaine public et persiste sur plusieurs appareils, le propriétaire doit corriger son serveur. Ne désactivez pas la vérification des certificats et n’utilisez pas d’option de lancement supprimant les contrôles TLS.

Corriger l’erreur de connexion sécurisée dans Firefox

Firefox affiche souvent un code détaillé sous « Avancé ». Copiez ce code. SEC_ERROR_EXPIRED_CERTIFICATE indique une date dépassée ; SEC_ERROR_UNKNOWN_ISSUER signale une chaîne ou une autorité inconnue ; les erreurs MOZILLA_PKIX concernent la validation selon la politique de certificats de Mozilla.

Vérifiez l’horloge, mettez Firefox à jour et utilisez son mode de dépannage pour neutraliser temporairement extensions et accélération. Si plusieurs sites HTTPS échouent, Mozilla cite parmi les causes courantes l’analyse chiffrée d’un antivirus, les outils de surveillance d’entreprise et les logiciels malveillants. Ne désactivez une fonction de sécurité que le temps d’un test contrôlé, puis réactivez-la.

Le mode HTTPS uniquement peut avertir lorsqu’un site ancien ne propose aucune version sécurisée. Cela ne signifie pas que Firefox est cassé : le site doit migrer vers HTTPS. Pour une application interne, l’autorité privée doit être déployée selon la politique de l’organisation.

Que faire sur Android, iPhone ou iPad ?

Activez la date et l’heure automatiques, puis redémarrez le téléphone. Comparez Wi-Fi et réseau mobile. Oubliez et rejoignez à nouveau le Wi-Fi si l’alerte ne survient que sur ce réseau. Sur un réseau public, terminez d’abord l’authentification du portail captif.

Mettez le système et le navigateur à jour. Un appareil trop ancien peut ne plus posséder les racines ou protocoles nécessaires. Supprimez les profils VPN, DNS ou certificats uniquement si vous savez qui les a installés. Sur un téléphone professionnel, demandez l’accord de l’administrateur.

Si le site fonctionne sur ordinateur mais pas sur mobile, vérifiez qu’il présente la chaîne intermédiaire complète : certains navigateurs reconstituent une chaîne manquante alors que d’autres appareils échouent.

Le propriétaire doit tester le domaine avec plusieurs clients. Pour un visiteur, le changement de navigateur peut confirmer le symptôme, mais ne répare pas un certificat réellement invalide.

Vérifier antivirus, VPN, proxy et logiciel malveillant

Un antivirus peut déchiffrer puis rechiffrer le trafic pour l’analyser. Il présente alors son propre certificat au navigateur. Si sa racine locale est absente, expirée ou corrompue, tous les sites semblent invalides. Mettez l’antivirus à jour et utilisez sa documentation officielle. Évitez d’ajouter manuellement une racine téléchargée sur un forum.

Désactivez temporairement un VPN connu pour comparer, puis reconnectez-le. Sur un proxy d’entreprise, seul le service informatique doit modifier les certificats. Si le problème apparaît après l’installation d’un programme gratuit, lancez une analyse complète avec l’outil de sécurité du système.

Un test sur un autre réseau est décisif : si plusieurs sites échouent uniquement derrière un proxy ou un routeur, le serveur distant n’est probablement pas responsable. Documentez l’adresse, le code, le navigateur et le réseau avant d’ouvrir un ticket.

Propriétaire du site : contrôler le certificat TLS

Vérifiez la date d’expiration, le nom commun et surtout les noms alternatifs du certificat. Le domaine avec www et le domaine sans www doivent être couverts si les deux sont utilisés. Contrôlez également la chaîne intermédiaire, l’algorithme, la clé privée associée et le certificat réellement servi par chaque nœud du CDN ou du répartiteur de charge. Si le navigateur signale plutôt un usage de clé incompatible, suivez le diagnostic de l’erreur ERR_SSL_KEY_USAGE_INCOMPATIBLE.

Renouvelez le certificat auprès de votre autorité ou de votre hébergeur, puis rechargez la configuration du serveur. Automatisez le renouvellement et surveillez son échec. Un certificat renouvelé sur disque n’est pas utile si Nginx, Apache, IIS, le proxy ou le CDN continue de présenter l’ancien.

Testez toutes les variantes du domaine et plusieurs réseaux. Une propagation DNS ou une ferme de serveurs mal synchronisée peut rendre l’erreur intermittente. N’activez HSTS qu’après avoir confirmé le fonctionnement HTTPS de tous les sous-domaines concernés.

Rediriger HTTP vers HTTPS sans créer de boucle

Après l’installation du certificat, configurez une redirection permanente de HTTP vers HTTPS. Microsoft recommande cette redirection lorsque le serveur possède déjà HTTPS. Gardez une seule source de redirection : serveur, CDN ou application. Des règles contradictoires peuvent produire une boucle.

Sur WordPress, définissez les adresses WordPress et du site en HTTPS seulement lorsque le certificat fonctionne. Mettez à jour les URLs internes dans la base avec un outil qui respecte les données sérialisées. Videz ensuite les caches du plugin, du serveur et du CDN.

Testez les pages, l’administration, les formulaires, l’API, les fichiers et les redirections canoniques avec et sans www. Conservez une sauvegarde avant toute modification globale. Le navigateur doit recevoir une redirection vers une URL dont le certificat couvre exactement le nom demandé.

Éliminer le contenu mixte dans WordPress et les autres CMS

Le contenu mixte apparaît lorsqu’une page HTTPS charge encore une ressource en HTTP. Let’s Encrypt le définit comme une page HTTPS utilisant des sous-ressources HTTP ; le navigateur peut les bloquer ou marquer la page comme moins sûre.

Ouvrez les outils de développement, onglets Console et Sécurité, puis relevez chaque URL HTTP. Corrigez les images, scripts, CSS, polices, iframes et appels d’API à leur source. Dans WordPress, contrôlez le contenu, les options du thème, le constructeur, les widgets et les extensions. Une réécriture automatique peut masquer temporairement le problème, mais la correction durable consiste à enregistrer des URLs HTTPS valides.

Élément	Emplacement fréquent	Correction
Images	Contenu ou médiathèque	Remplacer l’URL HTTP
CSS et polices	Thème ou cache	Régénérer les fichiers
Scripts	Extension ou balise externe	Utiliser une source HTTPS
Iframe	Carte, vidéo, paiement	Mettre à jour le code intégré
API	JavaScript ou configuration	Modifier l’endpoint et CORS

Cas particuliers : HSTS, réseau interne et serveur local

HSTS oblige le navigateur à utiliser HTTPS et interdit généralement de contourner un certificat invalide. C’est une protection contre le retour forcé vers HTTP. Le propriétaire doit corriger le certificat ; supprimer arbitrairement la politique locale ne résout pas la configuration publique.

Pour un intranet, une autorité de certification privée peut être légitime, à condition que sa racine soit distribuée de manière contrôlée aux appareils autorisés. Pour localhost, Let’s Encrypt explique qu’un certificat public classique n’est généralement pas adapté : utilisez l’outillage de développement prévu et limitez l’écoute à l’environnement nécessaire.

Les équipements anciens utilisant TLS 1.0 ou 1.1 peuvent échouer dans Edge, ces protocoles étant désactivés par défaut. La solution est de moderniser le serveur, pas de réactiver durablement des protocoles obsolètes sur les postes.

Erreurs à éviter pendant le dépannage

Cliquer sur « Continuer » puis saisir des données sensibles.
Installer un certificat racine reçu par e-mail ou téléchargé sur un forum.
Désactiver définitivement l’antivirus ou la validation TLS.
Réinitialiser tout l’appareil avant d’avoir comparé réseau et navigateur.
Confondre certificat valide et absence de contenu mixte.
Activer HSTS avant de tester tous les sous-domaines.
Renouveler le certificat sans recharger le serveur.
Faire une recherche-remplacement brute dans une base WordPress sérialisée.
Supposer que vider le cache corrige un certificat expiré.

Une méthode sûre progresse du constat vers la cause : relever le code, comparer appareils et réseaux, vérifier l’horloge, puis intervenir au bon niveau. Chaque changement doit être réversible et suivi d’un nouveau test.

Scénarios pratiques pour trouver la cause plus rapidement

Scénario 1 : l’alerte apparaît seulement sur le Wi-Fi de l’hôtel

Le site fonctionne en données mobiles et sur un autre réseau. Le certificat public n’est probablement pas en cause. Terminez la connexion au portail captif, oubliez puis rejoignez le réseau et évitez les opérations sensibles. Si plusieurs domaines restent touchés, utilisez un réseau de confiance.

Scénario 2 : un seul site échoue sur tous les appareils

Le code indique une date invalide ou un nom de domaine différent. Le propriétaire doit renouveler ou remplacer le certificat. Vider le cache de chaque visiteur ne produira pas de correction durable.

Scénario 3 : tous les sites HTTPS échouent sur un ordinateur

Vérifiez l’horloge, les mises à jour, l’antivirus, le VPN et les certificats installés. Si l’ordinateur appartient à une organisation, contactez l’équipe informatique avant de retirer une racine ou un profil.

Scénario 4 : la page affiche HTTPS mais le navigateur indique encore un risque

Ouvrez la console et recherchez le contenu mixte. Une seule iframe, police ou requête API HTTP peut suffire à provoquer un avertissement ou un blocage. Corrigez l’URL à sa source, puis purgez les caches.

Scénario 5 : l’erreur apparaît après un renouvellement

Comparez le certificat servi à celui installé. Un CDN, un ancien nœud ou un processus non rechargé peut continuer à présenter l’ancien certificat. Vérifiez également les intermédiaires et chaque variante du domaine.

Scénario 6 : seul un ancien téléphone échoue

Le système peut ne plus recevoir les autorités racines et protocoles actuels. Mettez-le à jour si possible. Ne réduisez pas la sécurité du serveur pour conserver un client obsolète sans analyse de risque.

Scénario 7 : la page d’accueil est sécurisée, mais le paiement ne l’est pas

Testez chaque étape du parcours, y compris les redirections vers le prestataire et le retour vers la boutique. Le sous-domaine de paiement peut utiliser un certificat distinct ou charger une ressource HTTP. Suspendez le parcours si des données sont transmises avant la correction.

Scénario 8 : l’erreur est intermittente

Répétez le test depuis plusieurs réseaux et relevez l’adresse IP obtenue. Un seul serveur derrière le répartiteur de charge peut présenter une chaîne ancienne. Corrigez la configuration de tous les nœuds avant de considérer l’incident comme résolu.

Scénario 9 : le certificat est valide, mais le nom ne correspond pas au domaine

Ce cas survient souvent après un changement d’hébergement, l’ajout d’un sous-domaine ou une mauvaise configuration du serveur virtuel. Le certificat peut être parfaitement valide tout en couvrant exemple.com et non boutique.exemple.com. Vérifiez le nom affiché dans l’adresse, les noms alternatifs du certificat et le serveur qui répond réellement. Une redirection ne corrige pas la première connexion si le navigateur doit d’abord joindre un domaine dont le certificat est incorrect.

Le propriétaire doit émettre un certificat couvrant chaque nom utilisé, ou retirer les noms qui ne doivent plus répondre. Contrôlez aussi la configuration SNI lorsque plusieurs sites partagent la même adresse IP : le serveur peut présenter le certificat d’un voisin si le bloc d’hôte est mal associé. Après correction, testez le domaine avec et sans www, les sous-domaines publics et les liens enregistrés dans les e-mails ou les applications.

Scénario 10 : l’alerte apparaît après l’installation d’un antivirus ou d’un VPN

Certains logiciels inspectent le trafic HTTPS en créant localement une connexion intermédiaire. Le navigateur voit alors un certificat généré par le logiciel plutôt que celui du site. Si la racine locale est absente, expirée ou mal déployée, plusieurs sites peuvent échouer simultanément. Comparez le nom de l’émetteur sur un appareil sain et sur l’appareil touché, sans publier de capture contenant des informations sensibles.

Mettez le logiciel à jour et consultez sa documentation officielle. Sur un poste personnel, un test temporaire de la fonction d’inspection peut confirmer la cause, à condition de la réactiver aussitôt et de ne réaliser aucune opération sensible pendant le test. Sur un poste professionnel, laissez l’équipe informatique contrôler les politiques, certificats racines et journaux. Supprimer une racine d’entreprise au hasard peut couper l’accès aux applications internes.

Scénario 11 : WordPress repasse en HTTP ou crée une boucle de redirection

Vérifiez d’abord que l’adresse WordPress et l’adresse du site utilisent toutes deux HTTPS, puis identifiez quel composant force la redirection : serveur, CDN, extension ou application. Lorsque plusieurs couches réécrivent l’adresse, elles peuvent se renvoyer la requête indéfiniment. Derrière un proxy, WordPress doit aussi recevoir correctement l’information indiquant que la requête d’origine était sécurisée.

Désactivez uniquement la règle suspecte, videz les caches et testez dans une fenêtre privée. Recherchez ensuite les anciennes URLs HTTP dans le contenu, les options du thème et les constructeurs de pages avec un outil compatible avec les données sérialisées.

Faites une sauvegarde avant le remplacement. Enfin, testez la page d’accueil, l’administration, la connexion, les formulaires, les médias et les appels d’API : une page apparemment corrigée ne prouve pas que tout le site l’est.

Checklist finale pour confirmer la correction

L’adresse affichée est correcte et commence par HTTPS.
Le certificat est valide, non expiré et couvre le domaine.
La chaîne intermédiaire est complète.
HTTP redirige une seule fois vers l’URL HTTPS canonique.
La console ne signale aucune ressource HTTP.
Le site fonctionne sur Chrome, Edge, Firefox, Android et iOS.
Les formulaires, paiements et API utilisent HTTPS.
Le renouvellement est automatisé et surveillé.
Les caches du site et du CDN ont été purgés.
Aucun contrôle TLS n’a été désactivé pour masquer l’erreur.

FAQ

Vider le cache suffit-il ?

Non. Cela peut corriger une ancienne redirection ou une donnée locale, mais pas un certificat expiré, un mauvais domaine ou une chaîne incomplète.

Pourquoi le site fonctionne-t-il sur un appareil seulement ?

Les magasins de certificats, versions système, réseaux et capacités de reconstruction de chaîne diffèrent. Cette différence aide à diagnostiquer une chaîne incomplète ou un appareil obsolète.

Le cadenas garantit-il qu’un site est honnête ?

Non. HTTPS protège la connexion au domaine affiché ; il ne garantit ni la qualité du service ni l’identité commerciale au-delà des informations validées.

Puis-je utiliser un VPN pour contourner l’alerte ?

Un VPN peut aider à confirmer qu’un réseau intercepte la connexion, mais ne rend pas fiable un certificat invalide présenté par le site.

Sources officielles consultées

Vérifier que la connexion d’un site est sécurisée, Google Chrome.
Messages d’erreur courants dans Chrome, Google Chrome.
Régler les codes d’erreur de sécurité, Mozilla.
Échec de la connexion sécurisée, Mozilla.
Outil Sécurité de Microsoft Edge, Microsoft.
Résolution des problèmes SSL dans IIS, Microsoft.
Glossaire : contenu mixte, Let’s Encrypt.
Certificats pour localhost, Let’s Encrypt.

Comment réparer l’avertissement « La connexion à ce site n’est pas sécurisée » ?