HTTPS et certificat SSL : un prérequis SEO, pas une option

Google a annoncé en 2014 que HTTPS deviendrait un signal de classement, une nouveauté suffisamment importante à l'époque pour faire la une de tous les blogs SEO. Plus de dix ans après, ce signal reste officiellement l'un des plus légers du classement — Google l'a répété à plusieurs reprises : à contenu équivalent, HTTPS ne fait pas gagner de position de façon mesurable. Ce qui a radicalement changé depuis, en revanche, ce n'est pas le poids du signal de classement, c'est le coût de ne pas l'avoir.

Depuis 2018, Chrome affiche un avertissement "Non sécurisé" explicite dans la barre d'adresse pour tout site en HTTP, visible par 100 % des visiteurs avant même qu'ils ne lisent une ligne de contenu. Pour un site qui collecte le moindre formulaire (contact, newsletter, commande), c'est un frein de confiance immédiat, indépendant de tout ce que Google fait ou ne fait pas dans son algorithme.

Un signal de classement faible, un prérequis de confiance fort

Cette distinction est souvent mal comprise. HTTPS n'est pas un levier qui pousse un site vers le haut des résultats — un site en HTTPS avec un contenu médiocre ne dépassera jamais un concurrent en HTTPS avec un excellent contenu, et le certificat SSL à lui seul n'a jamais fait gagner de trafic significatif à personne. Mais l'absence de HTTPS agit comme un frein à plusieurs niveaux qui, eux, ont un impact réel : l'avertissement navigateur fait fuir une partie des visiteurs avant la conversion, certaines fonctionnalités web modernes (géolocalisation, notifications push, certains formats d'image nouvelle génération) sont techniquement indisponibles en HTTP, et Google a confirmé traiter HTTPS comme le signal "départageur" par défaut entre deux pages autrement équivalentes.

Le piège du contenu mixte

Installer un certificat SSL ne suffit pas à obtenir un site pleinement HTTPS si des ressources continuent d'être chargées en HTTP — une image, une police, un script tiers appelé avec une URL commençant par "http://" plutôt que "https://". Ce phénomène, appelé contenu mixte (mixed content), déclenche un avertissement dans la console du navigateur, et pour les ressources actives (scripts, iframes), Chrome les bloque purement et simplement plutôt que de les charger en clair. Une page peut ainsi afficher le cadenas HTTPS dans la barre d'adresse tout en ayant, en réalité, des fonctionnalités cassées silencieusement à cause d'un script bloqué.

La cause la plus fréquente : des URLs codées en dur avec le protocole complet ("http://monsite.fr/image.jpg") dans un contenu ancien, une base de données, ou un thème CMS jamais mis à jour depuis la migration vers HTTPS — plutôt que des URLs relatives ou explicitement en "https://", qui s'adaptent automatiquement.

Les erreurs fréquentes d'une migration http vers https

• Rediriger tout le site vers la page d'accueil en HTTPS plutôt que chaque URL vers son équivalent exact — la même erreur de fond que pour une migration de domaine, qui perd le signal accumulé par chaque page individuelle.
• Oublier de mettre à jour les balises canonical, qui continuent de pointer vers la version HTTP — Google reçoit alors un signal contradictoire entre l'URL réellement servie et l'URL canonique déclarée.
• Ne pas mettre à jour le sitemap XML, qui référence encore les anciennes URLs en HTTP.
• Laisser les liens internes du site pointer en dur vers la version HTTP plutôt que HTTPS, forçant une redirection supplémentaire et inutile à chaque clic interne.
• Ne pas ajouter la propriété HTTPS dans Google Search Console en plus de l'ancienne propriété HTTP — sans quoi les données de performance se retrouvent scindées entre deux propriétés distinctes après la migration.

Vérifier son propre site en quelques secondes

Trois vérifications rapides suffisent à repérer l'essentiel des problèmes courants. D'abord, le cadenas dans la barre d'adresse du navigateur : un cadenas plein confirme un HTTPS propre, un cadenas barré ou une icône d'avertissement signale un problème de contenu mixte à investiguer immédiatement dans la console développeur (onglet Console, qui liste explicitement chaque ressource bloquée ou chargée en clair). Ensuite, vérifier qu'une requête vers la version HTTP de n'importe quelle page redirige bien automatiquement vers sa version HTTPS exacte, plutôt que vers la page d'accueil. Enfin, contrôler que la balise canonical de chaque page déclare bien l'URL en HTTPS, pas l'ancienne version HTTP oubliée après une migration.

Ce qu'un certificat SSL/TLS fait concrètement

Sans entrer dans la cryptographie sous-jacente, un certificat SSL (le nom d'usage reste "SSL" par habitude, bien que le protocole réellement utilisé aujourd'hui soit TLS, son successeur) a deux rôles distincts. Le premier est de chiffrer la connexion entre le navigateur et le serveur, pour qu'un tiers qui intercepterait le trafic sur le réseau (un Wi-Fi public, un opérateur, un acteur malveillant) ne puisse pas lire les données échangées — identifiants, numéros de carte bancaire, contenu d'un formulaire. Le second rôle, moins connu mais tout aussi important pour la confiance : le certificat prouve que le site est bien celui qu'il prétend être, délivré par une autorité de certification qui a vérifié a minima la propriété du nom de domaine.

C'est cette seconde fonction qui explique pourquoi un certificat expiré ou mal configuré déclenche une page d'avertissement bien plus agressive dans le navigateur qu'un simple message discret : le navigateur ne peut plus garantir à l'utilisateur qu'il communique avec le bon site, pas seulement que la connexion n'est pas chiffrée.

Les niveaux de validation : DV, OV, EV

Trois niveaux de certificats existent, avec un degré de vérification croissant de l'identité du titulaire. Le certificat à validation de domaine (DV) vérifie uniquement que le demandeur contrôle bien le nom de domaine — c'est le niveau largement majoritaire aujourd'hui, gratuit et automatisable, suffisant pour la quasi-totalité des sites. Le certificat à validation d'organisation (OV) vérifie en plus l'existence légale de l'entreprise. Le certificat à validation étendue (EV), le plus coûteux et le plus long à obtenir, impliquait autrefois l'affichage du nom de l'entreprise en vert dans la barre d'adresse — un affichage que les navigateurs majeurs (Chrome en tête, depuis 2019) ont progressivement supprimé, jugeant qu'il n'apportait pas la protection anti-phishing espérée. En pratique, pour l'immense majorité des sites, un certificat DV gratuit via une autorité comme Let's Encrypt offre exactement la même protection technique et le même cadenas qu'un certificat payant à plusieurs centaines d'euros par an.

Pourquoi un certificat expire (et pourquoi c'est voulu)

Un certificat SSL n'est jamais délivré à vie — la durée maximale autorisée par les navigateurs s'est même réduite au fil des années (jusqu'à 398 jours aujourd'hui pour la plupart des autorités, et des discussions sont en cours pour la raccourcir encore). Ce n'est pas un défaut mais un choix de sécurité délibéré : une durée de vie courte limite les dégâts si une clé privée est un jour compromise sans que personne ne le sache immédiatement, et force un renouvellement régulier qui garantit que les informations de validation restent à jour.

La contrepartie, bien connue des équipes techniques, est le risque d'oubli : un certificat qui expire sans renouvellement automatique fait basculer un site parfaitement fonctionnel la veille vers une page d'avertissement en plein écran le lendemain matin, sans aucun changement de code. C'est l'une des pannes les plus fréquentes et les plus évitables du web — la quasi-totalité des hébergeurs et des autorités de certification modernes (Let's Encrypt en tête, avec un renouvellement automatique tous les 90 jours) éliminent ce risque par défaut, à condition que l'automatisation soit correctement configurée et surveillée plutôt que simplement supposée fonctionner indéfiniment sans contrôle.

Les messages d'erreur les plus courants, décodés

HSTS : forcer HTTPS au niveau du navigateur

Même avec des redirections HTTP vers HTTPS correctement configurées côté serveur, un visiteur qui tape une URL sans préciser le protocole passe techniquement par une première requête non chiffrée avant d'être redirigé — une fraction de seconde pendant laquelle un acteur malveillant positionné sur le réseau pourrait théoriquement intercepter cette requête initiale. L'en-tête HTTP Strict Transport Security (HSTS) corrige ce point en indiquant au navigateur de mémoriser qu'un domaine doit toujours être contacté en HTTPS, pour toutes les visites futures, sans même tenter la version HTTP une seule fois.

C'est une configuration à activer une fois, au niveau du serveur ou du CDN, qui ne nécessite aucune maintenance ensuite — mais qui doit être mise en place avec prudence sur un site qui n'a pas encore un HTTPS parfaitement stable sur l'intégralité de ses sous-domaines, puisque l'en-tête peut, selon sa configuration, s'appliquer à tous les sous-domaines d'un coup et bloquer l'accès à un sous-domaine resté en HTTP par erreur.

L'effet sur la performance, au-delà de la confiance

HTTPS a aussi un effet indirect sur la performance, rarement mentionné dans les discours centrés uniquement sur la confiance : le protocole HTTP/2, qui permet de charger plusieurs ressources en parallèle sur une seule connexion et réduit mécaniquement les temps de chargement par rapport à HTTP/1.1, n'est disponible dans la pratique que sur une connexion HTTPS — aucun navigateur majeur ne l'implémente en clair. Un site resté en HTTP se prive donc aussi, sans le savoir, d'un gain de performance qui profite directement au LCP et aux autres métriques Core Web Vitals.

Le piège spécifique d'un CDN mal configuré

Un site derrière un CDN ou un proxy comme Cloudflare ajoute une couche de configuration supplémentaire, avec un piège classique : le mode de chiffrement "Flexible", qui chiffre la connexion entre le visiteur et le CDN, mais continue de parler en HTTP simple entre le CDN et le serveur d'origine. Si le serveur d'origine redirige lui-même tout trafic HTTP vers HTTPS (une configuration standard et saine en apparence), la combinaison des deux crée une boucle de redirection infinie : le CDN reçoit du HTTPS, parle en HTTP au serveur, qui le redirige vers HTTPS, que le CDN traduit à nouveau en HTTP vers le serveur, indéfiniment — visible pour l'utilisateur sous la forme d'une erreur "trop de redirections" (ERR_TOO_MANY_REDIRECTS), souvent après un changement de configuration DNS ou CDN sans rapport apparent avec le HTTPS lui-même.

Le correctif est simple une fois la cause identifiée : passer le mode de chiffrement du CDN sur "Complet" ou "Complet (strict)", qui maintient HTTPS de bout en bout, y compris entre le CDN et le serveur d'origine. C'est un des diagnostics les plus mal compris quand il survient, parce que le symptôme (boucle de redirection) ne pointe pas intuitivement vers sa cause réelle (une incohérence de protocole entre deux couches d'infrastructure distinctes).

Un cas concret de migration mal préparée

Un scénario fréquent sur les sites qui migrent tardivement vers HTTPS après plusieurs années en HTTP : le site bascule techniquement du jour au lendemain, les redirections 301 sont bien en place URL par URL, mais personne ne pense à vérifier le contenu déjà publié — des centaines d'articles de blog, par exemple, qui contiennent des images hébergées en interne avec des URLs absolues en HTTP codées en dur dans le corps du texte au moment de leur rédaction, des années plus tôt. Le site entier affiche alors un avertissement de contenu mixte sur une grande partie de ses pages historiques, invisible tant que personne n'inspecte la console du navigateur, mais bien réel pour Google et pour les visiteurs qui, eux, la voient.

Ce type de dette technique s'accumule silencieusement précisément parce que la page continue de s'afficher normalement à l'œil nu — seule une recherche systématique des URLs en "http://" dans la base de contenu, suivie d'un remplacement en masse vers des URLs relatives ou en "https://", permet de la purger complètement plutôt que de la découvrir page par page au hasard des signalements.

Questions fréquentes

Un certificat gratuit (Let's Encrypt) est-il aussi fiable qu'un certificat payant ? Oui, sur le plan technique : le niveau de chiffrement et la reconnaissance par les navigateurs sont identiques pour un certificat DV gratuit ou payant. La différence se situe uniquement sur des services annexes (garantie financière en cas de faille, support dédié, validation d'organisation) rarement utiles pour un site vitrine ou un blog.

Faut-il un certificat différent pour chaque sous-domaine ? Pas nécessairement : un certificat wildcard (couvrant "*.monsite.fr") protège tous les sous-domaines d'un coup, une alternative pratique à la gestion de certificats séparés pour chaque sous-domaine utilisé.

HTTPS protège-t-il contre le piratage d'un site ? Non — HTTPS chiffre la connexion entre le visiteur et le serveur, mais ne protège en rien contre une faille applicative, un mot de passe faible ou un plugin vulnérable côté serveur. C'est un sujet de confiance et de confidentialité des échanges, pas une protection contre l'intrusion.

Comment savoir si un certificat va bientôt expirer ? La plupart des navigateurs permettent de cliquer sur le cadenas puis d'afficher les détails du certificat, qui indiquent sa date d'expiration exacte. Pour un suivi à l'échelle d'un site ou de plusieurs domaines, des outils de surveillance externes peuvent envoyer une alerte automatique un mois avant l'échéance — une sécurité utile même quand le renouvellement est censé être automatique, puisqu'un échec silencieux de l'automatisation reste la cause la plus fréquente des coupures observées en pratique.

Perdre temporairement son HTTPS fait-il perdre son référencement durablement ? Pas si la coupure est corrigée rapidement. Google traite une indisponibilité HTTPS un peu comme une indisponibilité générale du site : un épisode court n'a généralement pas de conséquence durable une fois résolu, mais une coupure prolongée sur plusieurs jours peut entraîner une désindexation temporaire des pages concernées, le temps que Google constate que le problème est réglé lors d'un nouveau passage.

En résumé

HTTPS ne fera jamais gagner de position à lui seul, mais son absence — ou une implémentation bancale avec du contenu mixte, un certificat expiré ou une chaîne de certification incomplète — introduit une friction de confiance et des blocages techniques bien réels, indépendamment de tout ce que Google mesure dans son algorithme de classement. C'est un point binaire à corriger une fois pour toutes plutôt qu'un levier à optimiser en continu : soit c'est propre et automatiquement renouvelé sur l'ensemble du site, soit ça ne l'est pas — et le jour où ça casse, c'est rarement au moment le plus pratique.

Seoditum vérifie ce point automatiquement, avec preuve à l'appui, sur l'ensemble de votre site.