HTTPS et référencement : ce que ça change vraiment

Passer un site en HTTPS change quatre choses concrètes. Le classement en fait partie, et c'est de loin la moins importante, ce qui est dommage, car c'est celle dont tout le monde débat. Les trois autres se voient tout de suite, se mesurent, et coûtent réellement quelque chose tant qu'elles ne sont pas réglées.

Les quatre effets, par ordre d'importance réelle

La colonne de droite explique le classement de la colonne de gauche : les trois premiers effets se constatent, le quatrième se suppose.

1. Les navigateurs étiquettent le site

C'est le vrai coût de rester en HTTP, et cela n'a rien à voir avec les moteurs de recherche. Les navigateurs modernes marquent les pages en HTTP simple comme « Non sécurisé » dans la barre d'adresse, et affichent un avertissement explicite dès qu'un formulaire demande quoi que ce soit : une adresse email, un mot de passe, un numéro de téléphone.

Votre visiteur ne sait pas ce qu'est un protocole. Il sait que son navigateur lui dit que quelque chose ne va pas, au moment précis où vous lui demandez de vous faire confiance. C'est un problème de conversion avant d'être un problème technique, et c'est celui qui justifie à lui seul la migration.

2. Vous perdez vos données de provenance

Celle-là surprend. Quand quelqu'un clique depuis une page HTTPS vers une page HTTP, le navigateur n'envoie aucun référent. La destination ne peut pas savoir d'où vient la visite.

Comme presque tout le web est aujourd'hui en HTTPS, un site en HTTP voit une grande partie de son trafic entrant enregistrée en « direct ». Vous ne perdez pas les visites : vous perdez la possibilité de savoir d'où elles viennent, ce qui est pire, parce que cela corrompt discrètement chaque décision prise à partir de vos statistiques. Un canal qui fonctionne très bien peut ainsi passer pour inutile pendant des mois, et se faire couper.

3. Certaines fonctions du navigateur cessent de marcher

La géolocalisation, les service workers, l'accès à la caméra et au micro, les notifications, et une liste grandissante d'API modernes ne fonctionnent que dans ce que les navigateurs appellent un contexte sécurisé. En HTTP, elles n'existent tout simplement pas.

Ce n'est pas un avertissement que l'on reçoit à l'avance : la fonction échoue, voilà tout, souvent silencieusement, et le développeur qui reprend le dossier cherche pendant une demi-journée un bogue qui n'existe pas.

4. Le classement, un peu

Google répète depuis des années que HTTPS est un signal léger : du genre à départager deux résultats par ailleurs équivalents. C'est réel, et c'est petit. Une page qui ne se positionne pas n'est pas retenue par son protocole.

Considérez-le comme la quatrième raison, pas la première. Et méfiez-vous des récits de sites dont le trafic a bondi après le passage en HTTPS : dans presque tous les cas, la migration s'est accompagnée d'un nettoyage d'URL, de redirections propres et d'un sitemap régénéré, et c'est ce travail-là qui a payé.

Combien de temps avant de voir un effet

C'est la question qui suit toujours, et la réponse honnête déçoit un peu.

Les trois premiers effets sont immédiats : l'étiquette disparaît dès la première page servie, le référent revient dès le premier clic, les API de navigateur fonctionnent au rechargement suivant. Rien à attendre, rien à surveiller.

Le quatrième ne se voit pas. Les nouvelles URL doivent être explorées, les anciennes doivent céder la place, et pendant quelques semaines les deux versions coexistent dans l'index. Un tassement passager du trafic est normal pendant cette période, et il ne dit rien de la qualité de la migration. Ce qui en dit quelque chose, c'est la proportion d'anciennes URL qui répondent correctement après une seule redirection.

La règle pratique : jugez une migration HTTPS sur ses redirections, pas sur sa courbe de trafic à quinze jours. La courbe reviendra ; une redirection oubliée, non.

Ce que HTTPS ne fait pas

Il faut le dire, parce que le mot « sécurisé » fait beaucoup de dégâts.

HTTPS chiffre le transport entre le navigateur et votre serveur. Il ne rend pas votre site sûr : une faille applicative, un mot de passe faible ou une extension vérolée restent exactement ce qu'ils étaient. Il ne cache pas le nom de domaine visité, seulement le chemin et le contenu. Et il ne dit rien de l'honnêteté du site : un site de hameçonnage obtient un certificat gratuit en trois minutes, exactement comme vous.

Le cadenas signifie « la connexion est chiffrée », pas « ce site est digne de confiance ». Cette confusion est répandue, y compris chez des gens sérieux.

La partie qui mérite vraiment du soin

Passer en HTTPS signifie que toutes les URL de votre site changent. http://exemple.com/guide et https://exemple.com/guide sont deux adresses différentes, du point de vue des moteurs comme de vos propres liens internes.

C'est donc une migration, avec le travail habituel : une redirection pour chaque ancienne URL, les balises canoniques mises à jour, le sitemap régénéré, et, celui qu'on oublie, les liens absolus en http:// écrits dans le contenu, qui continuent de pointer vers l'ancien protocole et déclenchent une redirection pour chaque lecteur. La check-list des liens en migration couvre toute la séquence ; rien là-dedans n'est propre à HTTPS, et c'est exactement l'idée.

Un point mérite d'être surveillé les semaines suivantes : les URL qui répondaient en HTTP et qui n'ont pas d'équivalent en HTTPS produisent des 404 en série. Tous ne méritent pas une correction, mais ceux vers lesquels un autre site pointe encore, oui, et ce sont les premiers à traiter.

Le contenu mixte, la panne d'après

Une page servie en HTTPS qui charge une image, un script ou une feuille de style en http:// produit du contenu mixte. Les navigateurs bloquent purement et simplement les scripts et les feuilles de style concernés, et signalent le reste.

Le symptôme est déroutant : la page s'affiche, la mise en page est cassée, et aucune erreur serveur n'apparaît nulle part. La console du navigateur est le seul endroit qui le dit. C'est la raison pour laquelle une migration HTTPS se vérifie page par page sur les gabarits principaux, et pas seulement en regardant si le cadenas est vert sur l'accueil.

HSTS, à activer en connaissance de cause

L'en-tête Strict-Transport-Security demande au navigateur de n'utiliser que HTTPS pour votre domaine, pendant une durée que vous fixez. C'est une bonne pratique, et c'est aussi un engagement difficile à annuler : tant que la durée court, un visiteur déjà venu ne peut plus atteindre votre site en HTTP, même si vous le vouliez.

La méthode raisonnable est d'activer une durée courte, de vérifier que tout le site et tous les sous-domaines répondent correctement en HTTPS, puis d'allonger. L'inverse, une durée d'un an posée le premier jour, transforme un certificat oublié sur un sous-domaine en panne que personne ne peut contourner.

Et ensuite, il faut l'entretenir

Un certificat n'est pas un achat unique. Il expire, et le jour où cela arrive vos visiteurs reçoivent une page de blocage en plein écran plutôt qu'un avertissement discret, généralement parce qu' un renouvellement automatique a échoué en silence des semaines plus tôt.

Et cette panne-là ne ressemble à rien de ce que vos outils surveillent : le serveur répond, le site est debout, et pourtant plus personne n'entre. Elle relève du même réflexe que les quinze premières minutes d'un incident, c'est-à-dire regarder ce qu'un visiteur reçoit avant de regarder ce que la machine croit servir.

Un dernier effet, qui ne se voit qu'à l'extérieur : tous les liens que d'autres sites vous ont donnés pointent désormais vers une redirection. Ils continuent de fonctionner, et ils passent tous par un saut de plus. Ce que devient un backlink quand vos URL changent vaut d'être lu avant la bascule, pas après.

Le passage en HTTPS, c'est une journée de travail. Le garder valide, c'est la partie continue, et c'est celle qui coûte réellement du trafic aux gens.