Qu’est-ce que HTTPS: Notre guide #1 sur le fonctionnement de HTTPS

Le cadenas dans la barre d’adresse de votre navigateur, c’est la manifestation visible d’un protocole qui travaille en coulisses à chaque chargement de page. Ce protocole, c’est HTTPS. Il chiffre les données échangées entre votre navigateur et le serveur, authentifie l’identité du site, et protège les informations contre toute interception. Comprendre comment fonctionne HTTPS, ce que protège réellement un certificat SSL, quels types de certificats existent et comment migrer un site depuis HTTP : c’est ce que couvre ce guide.

HTTPS : définition et signification de l’acronyme

HTTPS est l’acronyme de HyperText Transfer Protocol Secure. C’est la version sécurisée du protocole HTTP, qui est le protocole de base utilisé pour transférer des données entre un navigateur et un serveur web depuis les origines du web.

HTTP transmet les données en clair. N’importe qui capable d’intercepter le trafic entre votre ordinateur et le serveur peut lire ces données sans aucune difficulté. HTTPS ajoute une couche de chiffrement via le protocole TLS (Transport Layer Security). Les données échangées sont cryptées avant d’être transmises, et seul le destinataire légitime peut les déchiffrer.

Un point de terminologie utile : on parle encore couramment de certificat SSL, mais SSL (Secure Sockets Layer) est le prédécesseur de TLS. Il a été déprécié en 2015 suite à des failles de sécurité. La technologie utilisée aujourd’hui est TLS, dans sa version 1.3 depuis 2018. Le terme « SSL » persiste dans le langage courant et dans les interfaces des hébergeurs, mais il désigne en pratique un certificat TLS.

Comment fonctionne HTTPS : le chiffrement et le TLS handshake

Comprendre comment fonctionne HTTPS nécessite de saisir un mécanisme clé : le TLS handshake, ou négociation TLS. C’est la séquence d’échanges qui se produit en quelques millisecondes à chaque nouvelle connexion sécurisée, avant même que la première donnée utile ne soit transmise.

Voici ce qui se passe concrètement quand votre navigateur se connecte à un site HTTPS :

1. Le serveur présente son certificat. Dès que votre navigateur contacte un serveur HTTPS, le serveur lui envoie son certificat TLS/SSL. Ce certificat contient la clé publique du serveur et les informations d’identité validées par une Autorité de Certification (AC).

2. Le navigateur vérifie le certificat. Votre navigateur consulte sa liste d’Autorités de Certification reconnues (Mozilla, Microsoft, Apple et Google maintiennent chacun leur propre liste). Si le certificat présenté a bien été signé par une AC de confiance, n’a pas expiré et correspond bien au domaine visité, la connexion peut continuer. Dans le cas contraire, le navigateur affiche un avertissement de sécurité.

3. L’échange de clés. Le navigateur utilise la clé publique du serveur pour chiffrer une clé de session temporaire. Cette clé de session est unique à cette connexion et à cette session. Seul le serveur, qui possède la clé privée correspondante, peut la déchiffrer.

4. La session chiffrée s’établit. Une fois la clé de session partagée de façon sécurisée, les deux parties l’utilisent pour chiffrer et déchiffrer toutes les données échangées pendant la session. C’est ce qu’on appelle le chiffrement symétrique : une seule clé, partagée de façon sécurisée, sert des deux côtés. Résultat : la communication est rapide et entièrement chiffrée.

L’ensemble de cette séquence prend moins de 100 millisecondes sur une connexion normale. TLS 1.3, la version actuelle, a réduit le nombre d’allers-retours nécessaires par rapport à TLS 1.2, ce qui améliore légèrement les performances de chargement.

Ce que HTTPS protège et ce qu’il ne protège pas

HTTPS protège trois choses de façon fiable :

La confidentialité. Les données échangées sont chiffrées. Formulaires, mots de passe, numéros de carte bancaire, cookies de session : tout ce qui transite entre le navigateur et le serveur est illisible pour un tiers qui intercepterait le trafic.

L’authenticité. Le certificat TLS garantit que vous communiquez bien avec le serveur légitime du domaine visité, pas avec un serveur qui usurpe son identité. C’est la fonction de l’Autorité de Certification : elle a vérifié que le demandeur du certificat contrôle bien le domaine concerné.

L’intégrité. Les données échangées n’ont pas pu être modifiées en transit. Chaque message inclut un code d’authentification qui permet au destinataire de vérifier qu’il n’a pas été altéré.

Ce que HTTPS ne protège pas, en revanche :

La résolution DNS. Quand vous tapez une URL, votre navigateur interroge un serveur DNS pour convertir le nom de domaine en adresse IP. Cette requête DNS est visible en clair sur le réseau, même si la connexion au site est ensuite chiffrée en HTTPS. Un observateur externe peut donc savoir que vous avez visité un domaine particulier, sans pouvoir voir les pages précises ni les données échangées. Des technologies comme DNS over HTTPS (DoH) existent pour chiffrer aussi cette étape, mais ne sont pas encore universelles.

Les métadonnées de trafic. La taille des échanges, leur fréquence, et le temps passé sur un site restent visibles même en HTTPS. Un observateur réseau ne peut pas lire vos données, mais peut analyser ces « canaux secondaires » pour en tirer des informations comportementales.

La sécurité du site lui-même. HTTPS sécurise le canal de communication. Il ne dit rien sur la qualité du code du site, la présence de failles applicatives, ou la légitimité du site. Un site de phishing peut très bien être en HTTPS et afficher un cadenas vert — le cadenas signifie seulement que la connexion est chiffrée, pas que le site est digne de confiance.

Les trois types de certificats SSL : DV, OV, EV

Tous les certificats TLS/SSL ne se valent pas. Ils diffèrent par le niveau de vérification effectué par l’Autorité de Certification avant de les délivrer. Choisir le bon type dépend de l’usage du site.

Certificat DV (Domain Validation). L’Autorité de Certification vérifie uniquement que le demandeur contrôle le domaine. Aucune vérification de l’identité de l’organisation derrière le domaine. C’est le certificat le plus rapide à obtenir (quelques minutes via Let’s Encrypt) et le moins coûteux. Il est adapté aux blogs, sites vitrines et outils internes. Il assure le chiffrement complet mais ne prouve rien sur l’identité juridique du propriétaire du site.

Certificat OV (Organization Validation). L’AC vérifie à la fois le contrôle du domaine et l’existence juridique de l’organisation (extrait Kbis ou équivalent, adresse vérifiée). Les informations de l’organisation sont visibles dans les détails du certificat. Délai d’obtention : quelques jours. Adapté aux sites professionnels qui collectent des données personnelles ou traitent des formulaires de contact sensibles.

Certificat EV (Extended Validation). Le niveau de vérification le plus élevé : l’AC soumet le demandeur à 14 points de contrôle, vérifiant l’identité légale, l’adresse physique, la capacité juridique du signataire et l’existence opérationnelle de l’entreprise. Délai : une à deux semaines. Utilisé historiquement par les banques et e-commerces pour afficher une barre d’adresse verte avec le nom de l’entreprise. Depuis 2019, Chrome et Firefox ont supprimé cet affichage visuel distinctif. Les EV sont aujourd’hui surtout pertinents pour les établissements financiers et les plateformes de paiement soumis à des exigences réglementaires strictes comme PCI DSS.

Pour la grande majorité des sites — y compris les e-commerces de taille standard — un certificat DV délivré par Let’s Encrypt est suffisant techniquement. Let’s Encrypt est une Autorité de Certification à but non lucratif qui délivre des certificats DV gratuits, renouvelables automatiquement tous les 90 jours, et reconnus par tous les navigateurs majeurs.

HTTPS et SEO : ce que Google dit réellement

HTTPS est un signal de classement Google depuis 2014. Google l’a annoncé officiellement dans un billet de blog de son équipe Webmaster Central en août 2014, qualifiant HTTPS de « légère préférence » dans l’algorithme. À l’époque, l’impact était marginal. Il a progressivement pris de l’importance à mesure que la proportion de sites HTTPS sur le web augmentait.

L’impact indirect est aujourd’hui plus significatif que l’impact direct. Depuis juillet 2018 (Chrome 68), Google Chrome affiche un avertissement « Non sécurisé » dans la barre d’adresse sur toutes les pages HTTP. Cet avertissement est visible par tous les utilisateurs de Chrome, qui représente plus de 65 % du marché des navigateurs en France selon Statcounter (2024). Un site en HTTP qui reçoit du trafic depuis Chrome subit une dégradation de la confiance utilisateur mesurable : taux de rebond plus élevé, durée de session réduite. Ces signaux comportementaux influencent indirectement le référencement.

Un effet moins connu : HTTPS préserve les données de référence dans Google Analytics. Quand un utilisateur clique sur un lien depuis un site HTTPS vers un site HTTP, la donnée de provenance est perdue — le trafic apparaît comme « accès direct » dans Analytics. En HTTPS vers HTTPS, la source est correctement tracée. Pour tout site qui utilise Analytics pour piloter sa stratégie marketing, passer en HTTPS améliore la qualité des données de trafic.

Migrer de HTTP vers HTTPS : les étapes et les pièges à éviter

Google traite la migration HTTP vers HTTPS comme une migration de site avec changement d’URL. Un impact temporaire sur le trafic est possible pendant la période d’indexation des nouvelles URLs, mais il se résorbe en quelques semaines si la migration est correctement exécutée. Voici les étapes dans l’ordre, avec les points de vigilance que la plupart des guides omettent.

Étape 1 : installer le certificat SSL sur le serveur

La majorité des hébergeurs proposent aujourd’hui l’installation de Let’s Encrypt en un clic depuis leur interface d’administration. OVH, Infomaniak, PlanetHoster, Ionos : tous intègrent cette option. Si votre hébergeur ne le propose pas nativement, c’est un signal que votre contrat de maintenance et hébergement mérite d’être revu.

Vérifiez après installation que le certificat est bien reconnu en accédant à votre site en https://. Le cadenas doit apparaître sans avertissement. Si vous obtenez une erreur de certificat non reconnu, le certificat n’a pas été correctement installé ou votre hébergeur utilise une AC non reconnue.

Étape 2 : forcer les redirections 301 de HTTP vers HTTPS

Une fois le certificat installé, votre site est accessible à la fois en HTTP et en HTTPS. Il faut forcer le HTTP vers HTTPS via des redirections 301 (redirection permanente). Sur un serveur Apache, cela se configure dans le fichier .htaccess :

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

Sur WordPress, le plugin Really Simple SSL configure automatiquement ces redirections et met à jour les URL internes en un clic. C’est la solution la plus sûre pour éviter les erreurs de syntaxe dans le .htaccess.

Étape 3 : corriger le contenu mixte

C’est le piège post-migration le plus fréquent et le moins documenté. Le contenu mixte (mixed content) survient quand une page servie en HTTPS charge des ressources (images, scripts, feuilles de style, iframes) via des URL en HTTP. Le navigateur bloque ou avertit sur ces ressources, et le cadenas disparaît ou affiche un avertissement.

Les causes les plus fréquentes : des images dont les URLs sont codées en dur en HTTP dans la base de données, des scripts tiers chargés en HTTP (widgets, outils d’analytics anciens), des iframes vers des ressources non sécurisées.

Pour détecter le contenu mixte : ouvrez la console développeur du navigateur (F12) sur votre site HTTPS et regardez l’onglet « Console ». Les ressources mixtes apparaissent en avertissement ou en erreur. Sur WordPress, le plugin Really Simple SSL détecte et corrige automatiquement la majorité des cas. Pour les cas résiduels, une recherche et remplacement dans la base de données WordPress (via WP-CLI ou un plugin dédié) remplace toutes les occurrences HTTP par HTTPS.

Étape 4 : mettre à jour la Search Console et Google Analytics

Google Search Console traite HTTP et HTTPS comme deux propriétés distinctes. Après migration, ajoutez la version HTTPS de votre site comme nouvelle propriété dans la Search Console et soumettez votre sitemap XML mis à jour. Conservez l’ancienne propriété HTTP pendant quelques mois pour suivre les éventuelles erreurs d’indexation.

Dans Google Analytics, mettez à jour l’URL du site dans les paramètres de la propriété (Administration > Informations sur la propriété) pour qu’elle pointe vers la version HTTPS. Si vous utilisez Google Tag Manager, vérifiez que les URL configurées dans vos balises sont bien en HTTPS. Si vous utilisez Bing Webmaster Tools, la même mise à jour est nécessaire de votre côté.

Pour plus de conseils sur la migration HTTPS, Google a publié un guide vidéo de référence :

Étape 5 : surveiller les semaines suivantes

Après la migration, surveillez quotidiennement la Search Console pendant 4 à 6 semaines. Les points à vérifier : l’évolution de l’indexation des URLs HTTPS, la disparition progressive des URLs HTTP dans les rapports de couverture, l’absence d’erreurs de crawl liées à des redirections en boucle. Un pic temporaire d’erreurs 404 ou de soft 404 dans les premières semaines est normal : il reflète Googlebot qui recrawl les anciennes URLs et découvre les redirections.

Pourquoi un site sans HTTPS est un problème en 2025

Les sites en HTTP sont aujourd’hui minoritaires sur le web. Selon les données de navigation de Google (rapport Chrome Platform Status, 2024), plus de 95 % des pages chargées dans Chrome dans les pays francophones le sont en HTTPS. Un site encore en HTTP est donc statistiquement anormal, et traité comme tel par les navigateurs et les moteurs de recherche.

Concrètement, un site sans HTTPS en 2025 subit quatre conséquences mesurables. L’avertissement « Non sécurisé » de Chrome, visible par la majorité de vos visiteurs. Un désavantage de classement SEO direct dans l’algorithme Google. Une dégradation des données analytiques (trafic référent perdu, attribué à tort en accès direct). Et pour tout site qui collecte des données personnelles, un risque de non-conformité RGPD : la collecte de données via un formulaire non chiffré constitue une mesure de sécurité insuffisante au sens de l’article 32 du règlement.

La création d’un site web professionnel inclut aujourd’hui systématiquement l’installation et la configuration HTTPS comme standard de base, pas comme option.