From Http to Https : Le Guide Complet

Tu t’es déjà pété les dents sur une migration http – https ? Tu as déjà eu envie de mettre des tartes au premier développeur que tu croises ? Alors bienvenue au club ! Mes multiples (et récentes…) migrations http-https m’ont poussé à approfondir le sujet pour vous pondre un petit guide complet qui vous sortira du pétrin à chaque fois. Ou presque. 

Comme vous le savez, de plus en plus d’articles mentionnent le « push » du HTTPS dans les résultats, au-delà du simple certificat de sécurité, substantifique moelle initiale du bouzin. Pour Google, plus il y aura de https, plus les moteurs de recherche seront une place forte et sûre. Du coup, mettre en oeuvre une migration entre http et https aujourd’hui paraît être indispensable.

#1 : Performance et HTTP/2

Lors de la dernière conférence Velocity à Amsterdam, Load Impact & Mozilla ont affirmé qu’avec le HTTP/2, les utilisateurs pouvaient espérer un temps de chargement optimisé de 50 à 70% par rapport à HTTP/1.1. Mais pour bénéficier de cet avantage, vous devez mettre en place le HTTPS, pour des problématiques de supports navigateurs.

#2. SEO & Rankings

En 2014 déjà, Matt Cutts (#SoLongMyFriend…) annonçait déjà le HTTPS comme un « ranking signal » pris en compte par Google. L’ancien responsable de la webspam Team, au cours de nombreux articles, disséminait quelques indices pour indiquer que le HTTPS deviendrait au fil des ans un facteur de positionnement beaucoup plus puissant.

Capture d’écran 2017-10-31 à 21.37.14

Selon les dernières données de l’outil « BuildWith », 6,3% du Top 100.000 des sites mondiaux utilisent le SSL (Juin 2016), ils n’étaient que 4,3% en Novembre 2014.

#3. Que vous apporte le https ?

Pourquoi devez-vous, dès aujourd’hui, prioriser le passage de votre site de http à https ?

  • Confidentialité

Sans HTTPS, toute donnée privée est accessible, par exemple, d’un Wi-fi public. Si vous êtes en train d’acheter en ligne, on est d’accord que vous n’avez pas envie qu’un petit sacripant regarde au-dessus de votre épaule…

  • Intégrité

Elle permet de prouver que l’information va d’un point A à un point B de manière complète et authentifiée. Le HTTPS assure la non-modification du site internet (si Wi-fi public, il n’y aura pas de possibilité d’ajout de publicité, de réduction de qualité des images pour sauver de la bande passante, etc…)

  • Authentification

La base du https et du certificat SSL. De cela, on peut dire qu’elle est le fer de lance de la migration http – https. Cela prouve au navigateur sur lequel vous êtes que le site example.com est bien le site example.com (je pense notamment aux banques et services d’achat ou de transfert d’argent en ligne)

#4. Type de certificat HTTPS

Il y a différents types de certificats Https, qui peuvent être classés selon la nomenclature suivante :

  • Certificat d’identification

a. DV (Domain Validated)

Le plus commun de tous les certificats qui permet de matcher votre domaine avec une clé publique précise. Le moins cher de tous les certificats (environ 10$)

b. EV (Extended Validation)

EV vérifie la légitimité de l’entreprise qui s’est procurée le certificat. C’est le plus fiable des certificats qui s’obtient après une série de vérifications que même Les Experts Las Vegas ils l’ont jamais fait. La vérification de l’entité détentrice de l’EV se fait selon un process bien rôdé :

Contrôle du domaine (DV)

Contrôle du volume de ventes (vérification de l’activité actuelle de la société)

Présence dans les annuaires comme les Pages Jaunes

Un numéro de téléphone valide

c. OV (Organization Validated)

Comme l’EV, l’OV permet de vérifier la légitimité de l’entité qui a contracté le certificat. A contrario de l’EV, l’OV est chère et requiert quelques paliers de vérification en plus. Peu utilisé par les entreprises.

#5. Configuration

Pour récapituler avant de rentrer dans le vif du sujet, voici les quatre composants de l’encryptage HTTPS :

a. L’Initial Key Exchange (utilisant des algorithmes asymétriques : clé privée ou publique)

b. L’Identity Certification (délivré par une autorité de certification ; DV, EV, OV)

c. L’Encryption Message (Le chiffrement, algorithmes symétriques)

d. Digestion Message (Algorithmes cryptographiques)

Comme vous pouvez le constater, chacun des composants possède une interaction avec un algorithme qui utilise différentes tailles de clés. Le deal du HTTPS se situe également dans le fait que le client et le serveur s’accorde sur la configuration des combinaisons d’identification et de chiffrement qu’ils vont utiliser. Ceux cités ci-dessus, intrinsèquement, possèdent des sous-combinaisons, d’où l’intérêt d’accorder les violons.

Par exemple, le message HTTPS suivant ECDHE-RSA-AES256-GCM-SHA384 signifique :

  • Que l’Initial Key Exchange utilisera l’algorithme de clé ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
  • Le CA utilisé sera le RSA (Rivest-Shamir-Adleman algorithm)
  • Le message de chiffrement va utiliser le Advanced Encryption Standard (AES) avec une clé 256 bit, en mode GCM
  • L’intégrité sera vérifiée en utilisant l’algorithme SHA utilisant une clé 384bit

Bon, maintenant que vous savez ça, il est l’heure de passer au comment du pourquoi de la migration http-https. Mais avant …

#6. Comment ça marche ? 

Bah oui tiens Michel ! Comment qu’on fait ?

a. Crawl pré-migration

Que vous ayez un petit site de 5 pages à migrer, ou 60 000 pages produits, il faut réaliser un crawl ! Déjà parce qu’un crawl par semaine c’est pas déconnant pour un #SEO, et également parce qu’il vous faut détecter les potentiels soucis techniques rencontrés par votre site.

Au delà de ça, vous devez également comprendre tous les tenants et aboutissants du CMS que vous utilisez pour votre site. Facilite-il les migrations (Drupal, si tu m’entends) ? Et enfin, soyez surs d’avoir lister tous les points qui peuvent se péter la tronche au moment de la migration (redirection de paiement, scripts, API, etc…)

En gros, vous devez identifier tous les points de vulnérabilité de votre site avant de penser à la migration.

b. Vérifiez les rankings

Comme pour un avion traversant une zone de turbulences, une migration http-https va entraîner, la plupart du temps, des soubresauts dans vos rankings. Soyez surs que vous pouvez vérifier en peu de temps après le passage en https, les mouvements subis.

Pour cela, rien de plus facile. Un dernier export depuis votre outil de positionnement préféré avant le passage en https, on met tout ça dans un Excel Drive, et aux lueurs des premiers rankings post-https, on vient coller une nouvelle colonne pour voir les éventuels mouvements. Le plus important étant de suivre les turbulences des urls qui étaient les mieux positionnées avant la refonte.

c. Choisissez le bon plan de déploiement

Comme disait Hannibal : « J’adore qu’un plan se déroule sans accroc »

Le choix ici est assez simple :

  • Déploiement en prod direct ?
  • Déploiement en pré-prod, phase de testing, puis mise en prod ?
  • Création d’un site miroir de test pour voir si tout est ok (cher et chronophage)

Bien évidemment, le choix de votre plan de déploiement va varier en fonction de la complexité et la densité de votre migration, mais vous ne regretterez peut être pas de prendre la dernière option, notamment si les points de vulnérabilité évoqués auparavant se comptent sur les doigts de vos mains ET de vos pieds…

d. Acquérir le certificat SSL

Pour déclencher le HTTPS, il faut adopter un certificat SSL. Choisissez un provider de confiance et soyez surs d’avoir le bon niveau de sécurité. Le certificat recommandé par Google est en 2048-bit key.

Vous devez ensuite faire le choix de le prendre pour un seul domaine ou plusieurs. Une fois que vous avez obtenu tout cela, soyez surs que vous l’avez correctement déployé sur votre site.

#7. Best Practices SEO

Une fois que le certificat est acquis, déployé, configuré et testé, il est temps de s’atteler à la bonne configuration des 301 pour éviter qu’un utilisateur ne retombe sur une vieille page http cachée dans le congélo à la mode Courjault. Rappelez vous d’une chose :

Quand la migration est terminée, aucune de vos pages ne doit être disponible dans les deux versions !

Sinon, bonjour le duplicate content ! Une fois que les redirections sont testées, voici une checklist de tout ce que vous devez vérifier sur votre site.

a. Problématique de crawl et d’indexation

Vous voulez que Google sache que vous avez migré en HTTPS ? Rien de plus simple :

  • Checkez votre fichier Robots.txt et vérifiez que vous n’avez pas restreint l’accès aux pages en HTTPS
  • Vérifiez les HTTPS sur TOUTES les pages, y compris celles en noindex

Une fois que tout vous parait en ordre…revérifiez une seconde fois (on n’est jamais trop prudent). A ce stade là, il serait utile de faire un petit Xenu (ou Integrity pour les MACiens) pour voir si une 404 n’apparaît pas quelque part, ou si vous avez encore dans des articles par exemples, des liens en http (qu’il faudra mettre en dur)

b. Chaînes de redirection

Ca m’est arrivé ! Votre site aura probablement ce que l’on appelle des « bunchs » de redirections. (« paquets »).

Exemple : Si vous aviez une page en www redirigeant vers une page en no-www, redirigeant elle-même désormais sur une https no-www , vous pouvez observer quel maillage de la chaîne peut être supprimé pour améliorer le temps de chargement mais également pour ne pas perdre de jus SEO en route…

Un temps de chargement de tortue équivaut à une succession de redirections (le plus souvent inutiles). Cela vous fait perdre des utilisateurs ET du ranking. Ne négligez pas cette étape. Pendant que vous y êtes, vérifiez que toutes les anciennes pages correspondent aux bonnes landings sur le nouvel https.

c. Canonical, Alternate, Hreflang

Des tags manquant et qui se sont perdus en chemin pendant la migration, peuvent créer de la confusion auprès des bots.

Après une migration, tous les rel=canonical doivent pointer sur des URL en HTTPS. Si vous utilisez du rel=alternate ou du hreflang, cette précaution s’applique également.

d. Mixed Content (Medias, Fonts, Structured Data…)

Disons qu’un visiteur atterrisse sur une page qui possède du contenu textuel, mais également des images, un script, et une ressource externe se chargeant en parallèle, et que tout ce contenu fut généré sur votre ancien site en HTTP.

En amont, on imagine que toute la page est sécurisée grâce au HTTPS, mais une ressource non-cryptée présente sur la page est une porte ouverte aux attaques en tout genre (même sur un site en https !). Voilà le talon d’Achille du HTTPS aujourd’hui, le contenu autre que le texte et qui vient fragiliser tout le process de sécurisation.

Pour être sur que vos medias, vos fonts et autres contenu hors-texte soient « safe », vous devez repasser sur tous vos liens internes et toutes les ressources qui peuvent faire tanguer votre site. Voici toutes celles que vous devez checker et qui doivent avoir une URL en HTTPS :

  • Vidéos, Audios, Images
  • Fonts
  • Frames
  • JS et CSS dans le HTML
  • Images, Fonts, et tout autre url dans les JS et CSS files
  • Tags Open Graph
  • Toutes les URL des données structurées présentes sur le site
  • Tout autre lien interne

Cela peut être très très chronophage, mais vous sauvera surement du naufrage annoncé !

#8. Best practices post-déploiement

Tester tout encore une fois (bon…pas que ça devienne un TOC non plus…). Réalisez un nouveau crawl via Xenu (ou Screaming Frog hein, on n’est pas zoophobe). Vérifiez toutes les ressources qui ont pu être endommagées pendant la migration et qui chargent encore en HTTP. Réparez les redirections qui apparaissent comme défaillantes.

Le plus important étant qu’après le déploiement, toutes vos URL ressortent en code 200 dans vos crawls

Retournez à votre checklist des points vulnérables pour voir si tout est désormais en HTTPS.

a. Faites comprendre à Google que vous avez migré.

Google voit un passage en HTTPS comme une migration d’URL.

Vous devez donc impérativement rajouter votre propriété HTTPS à votre Google Search Console

Ensuite, générez un tout frais tout beau sitemap avec les url en HTTPS et soumettez le à Google !

Enfin, transférez tous les autres paramètres (fichier de désaveu, listes des paramètres d’URL) vers cette nouvelle propriété.

b. Récap’

Si vous suivez tous les points évoqués ci-dessus, vous aurez l’âme en paix pour migrer votre site de HTTP vers HTTPS.

Voici donc un petit tableau récap’ !

Made by Aleh Barysevich©
Made by Aleh Barysevich©

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *