Vous êtes ici : Accueil | Tutoriels WordPress | Comment passer son site WordPress en HTTPS

Comment passer son site WordPress en HTTPS

securiser-wordpress-https

Depuis mai 2016, la Marmite est passée au HTTPS. Cela signifie que toutes les pages du site ont une URL débutant par https:// au lieu du classique http://.

Vous allez me dire : « Très bien, mais qu’est-ce que ça change concrètement ? Pourquoi as-tu fait ce choix ? En quoi est-ce important ? ». Eh bien c’est ce que nous allons voir dans ce nouvel article 🙂

Accrochez vos ceintures, voici le sommaire !

Info : Cet article est assez long (plus de 4000 mots). Si le sujet vous intéresse et que vous n’avez pas le temps de vous y plonger pour le moment, téléchargez-le au format PDF (en bonus, vous trouverez un code de réduction pour créer votre site chez o2switch). Cliquez ici pour le télécharger. 

Vous êtes toujours là ? Alors répondons à la question suivante.

Qu’est que le HTTPS, SSL et le TLS ?

Vous ne le savez peut-être pas mais lorsque vous naviguez sur un site dépourvu de HTTPS, les données que vous échangez sont en clair, c’est à dire que n’importe qui peut les lire, les analyser et les transmettre.

Bon, j’y vais un peu fort. On est d’accord que ce n’est pas le grand-père du coin qui va vous tracer (quoi que 😉 ).

Restreignons ce « n’importe qui » aux personnes (ou organisations) possédant de bonnes compétences techniques, certains logiciels et l’intention de vous espionner.

Même si le risque est assez faible, il n’est pas nul. Et franchement, qui aime se faire épier ?

Mais je n’ai rien à me reprocher !

Je n’en doute pas une seconde mais avouez que l’on n’a pas le même comportement lorsque quelqu’un surveille tous nos faits et gestes.

Cela arrive par exemple au travail, lorsque votre supérieur regarde ce que vous faites. On peut aussi vivre des situations similaires à l’école, quand le professeur passe derrière vous.

On peut dire qu’une sorte de pression psychologique s’applique sur vous (même si la personne qui passe n’en a pas l’intention) et va changer votre comportement.

Du coup, votre liberté s’en trouve affectée.

Sur Internet, il n’y a pas forcément quelqu’un qui rode derrière vous. Cela est beaucoup plus subtil.

Si l’on a l’intention de vous espionner, on peut enregistrer ce que vous avez fait sur tel ou tel site. Mais surtout, on peut récupérer vos informations personnelles (emails, mots de passe, nom, adresse, déplacements, coordonnées bancaires et j’en passe).

Là, ça devient moins drôle, n’est-ce pas ?

C’est pour lutter contre tout cela que le protocole HTTPS a été mis en place. Grâce à lui, les données que vous échangerez avec un site seront chiffrées (c’est à dire cryptées).

Encore mieux, vous serez certain de bien visualiser le site original et non une version modifiée par quelqu’un qui aurait intercepté la connexion. Eh oui, beaucoup de choses sont possibles en informatique !

Par contre, le HTTPS ne vous rendra pas anonyme. Il est toujours possible de savoir qui vous êtes (via votre adresse IP) et de connaître les sites que vous aurez visités

Pour résumer, on peut juste savoir que vous êtes allé sur tel site en HTTPS mais pas ce que vous y avez fait.

Comment fonctionne le HTTPS ?

Afin d’illustrer le fonctionnement du protocole HTTPS, faisons un retour rapide sur son grand frère, le protocole HTTP. Ici c’est assez simple, vous avez deux acteurs : le navigateur web (vous) et le serveur où est hébergé le site à afficher.

Schéma d'une requête HTTP

Dès que vous entrez une adresse dans votre navigateur, il envoie une requête HTTP pour demander la page. Le serveur la renvoie et le navigateur l’affiche. Plutôt facile, n’est-ce pas ?

Si vous voulez en savoir plus sur le fonctionnement d’un site web (et en particulier un site WordPress), jetez un oeil à l’article dédié à l’hébergement web.

Pour le HTTPS, d’autres acteurs entrent en scène mais nous allons retenir le principal : l’autorité de certification.

Ce genre d’organisme, également appelé tiers de confiance, délivre un certificat SSL/TLS pour que les créateurs de sites puissent mettre en place le HTTPS. Il en existe des dizaines d’autorités de certification mais les plus connues sont Comodo et GlobalSign.

Un certificat permet de chiffrer la connexion et de vérifier l’identité du site (suis-je bien connecté au site que je veux visiter ?).

Parlons rapidement des deux nouveaux acronymes cités auparavant : SSL et TLS.

On peut dire que le SSL et le TLS sont une sorte de surcouche qui va venir sécuriser une connexion HTTP classique. Un peu comme la gaine vient protéger un cable électrique si vous voulez :

Rôle du SSL/TLS dans le HTTPS

On retrouve souvent l’appellation SSL sur le web mais c’est un abus de langage.

En fait, SSL (Secure Socket Layer) est la première version de ce protocole de sécurisation. TLS (Transport Layer Security) a pris le relai pour plus de sécurité. Si cela vous intéresse, vous retrouverez l’historique complet sur Wikipédia.

Récapitulons.

Pour bénéficier du HTTPS sur un site, nous avons besoin d’une autorité de certification qui va nous délivrer un certificat SSL/TLS.

Voici comment cela s’intègre par rapport à notre schéma précédent :

Schéma simplifié d'une requête HTTPS

Je parie que vous ne vous doutiez pas qu’il se passait autant de choses. Et encore, j’ai dû simplifier pour que tout puisse tenir !

En tout cas, cela se passe très très vite. On n’y voit que du feu 🙂

Comment savoir si la connexion est sécurisée ?

Vous l’aurez deviné, le premier signe distinctif d’un site sécurisé est évidemment le début de son adresse (son protocole pour être plus précis) qui est passé de http:// à https://.

Cependant, les navigateurs mettent davantage en valeur les sites dotés du HTTPS grâce à un petit cadenas vert placé juste avant l’adresse. Voici l’exemple de WP Marmite avec Google Chrome :

Le cadenas vert du https

Pour d’autres sites, l’affichage un plus proéminent (nous verrons à quoi cela correspond plus tard dans l’article). C’est notamment le cas pour la page de commande d’Elegant Themes :

Le https sur Elegant Themes

Parfois, il arrive que certaines ressources (images, fichiers CSS ou JS) d’une page en HTTPS soient chargées en HTTP, c’est à dire de manière non sécurisée.

Dans ce cas, le cadenas vert ne s’affichera pas. Le webmaster devra corriger cela pour que le site soit totalement chiffré (nous verrons comment faire un peu plus bas dans l’article).

Voilà, maintenant vous en savez un peu plus sur ce qu’est le HTTPS. Cela dit, nous venons à peine d’effleurer le sujet !

2 Arguments de plus en faveur du HTTPS

Comme vous avez pu le lire précédemment, le HTTPS permet de sécuriser la navigation des visiteurs. Tout d’abord en chiffrant la connexion, puis en lui assurant que vous êtes bien le site que vous prétendez être.

Je tiens toutefois à vous présenter deux autres avantages liés à la mise en place du HTTPS sur un site.

Le référencement sera amélioré (dans le futur)

En 2014, Google a annoncé que le HTTPS était désormais considéré comme un signal pris en compte pour le référencement des sites.

Après plusieurs semaines d’utilisation du HTTPS, je ne peux pas vraiment vous avouer que le positionnement de la Marmite a beaucoup progressé grâce à ça.

Toutefois, ce signal pourrait prendre plus d’importance à l’avenir. C’est pourquoi je vous recommande d’y passer si vous créez un nouveau site (au moins, vous n’aurez pas à le faire plus tard).

Si votre site est déjà en ligne depuis un certain temps, la migration sera plus délicate donc faites attention si vous décidez de vous lancer. C’est également ce que préconise Olivier Andrieu d’Abondance.com dans une vidéo de juin 2016 :

 

J’avais un peu peur pour la Marmite (surtout après ce que le blog a vécu par le passé) mais au final tout s’est bien passé.

Même si la corrélation entre le HTTPS et un meilleur positionnement n’est pas encore très marqué, le pourcentage des sites sécurisés augmente. 10% du top 1 million des sites y sont passés selon BuildWith :

Pourcentage des sites en HTTPS

Malgré les recommandations des experts, je pense qu’il vaut mieux faire la transition maintenant que lorsque 90% des sites seront en HTTPS. Il y a des chances pour que Google donne plus d’importance au HTTPS à l’avenir.

D’ailleurs, le moteur de recherche nous le confirme sur cette page :

Google considère le protocole HTTPS comme un signal positif pour son classement. Il ne s’agit toutefois que d’un indicateur parmi tant d’autres. Il revêt moins de poids que l’aspect qualitatif d’un site. Ne vous attendez donc pas à percevoir à court terme des retombées majeures en termes de SEO en passant au HTTPS. À plus long terme, il est possible que Google accorde davantage d’importance à l’optimisation HTTPS.

Si ce premier argument ne vous a pas encore convaincu, voici le second.

On vous fera davantage confiance

À votre avis, de quoi les visiteurs ont le plus peur en ligne ?

De se faire avoir pardi ! Tomber sur des escrocs, des charlatans, des guignols !

Et autant vous le dire, il y en a des wagons…

 

Par contre (et heureusement), ce genre d’individu ne prend généralement pas le temps de bien faire les choses. Ils utilisent des thèmes WordPress horribles, leurs boutons d’achat se ressemblent tous et…

Leurs sites ne sont pas en HTTPS !

Si les navigateurs affichent un petit cadenas vert pour tous les sites sécurisés, ce n’est pas pour rien. Quand on le voit, on est de suite rassuré (même inconsciemment).

Quand on arrive sur un site que l’on ne connait pas, on cherche à prendre ses marques. En voyant un site au design propre, une bonne communauté et des URL avec HTTPS, on se dit que l’on n’est pas tombé sur le site du zozo du coin (enfin il y a moins de chances).

Rien que pour ça, je pense que ça vaut le coup de le mettre en place.

Pour finir sur ce point, dois-je vous rappeler que le HTTPS est indispensable pour les boutiques en ligne ? Eh oui, il faut bien chiffrer le numéro de carte bancaire des clients (tout comme leurs identifiants de connexion et leurs autres données personnelles) !

Comment obtenir un certificat SSL/TLS ?

Auparavant, il était assez compliqué de mettre en place le HTTPS sur son site (qu’il soit sous WordPress ou non). Il fallait acheter un certificat SSL/TLS par l’intermédiaire de son hébergeur ou directement via une autorité de certification si vous avez un serveur dédié.

Quand on ne l’a jamais fait, je vous avoue que cela pouvait prendre un peu de temps. On devait nécessairement fournir une preuve de son identité pour montrer que l’on était bien le propriétaire de son site.

Normal me direz-vous. Sinon comment voulez-vous que l’autorité de certification vous certifie ? ^^

Bon, c’était fastidieux mais il fallait obligatoirement passer par là.

Aujourd’hui, il est toujours possible de procéder ainsi (c’est même recommandé dans certains cas) mais un nouvel acteur est apparu…

Let’s Encrypt, vers un web 100% sécurisé

Let’s Encrypt est une autorité de certification fournissant des certificats SSL/TLS gratuitement. Leur mission est de chiffrer le web pour le rendre plus sécurisé.

De nombreux acteurs soutiennent et financent cette initiative. On peut citer par exemple citer Facebook, Free, OVH, Automattic ou encore Google.

Depuis leur lancement en décembre 2015, le nombre de certificats qu’ils délivrent est en train d’exploser :

Nombre de certificats SSL/TLS délivrés par Let's Encrypt

Cela a notamment été rendu possible grâce aux hébergeurs (OVH, Gandi, etc.) et aux plateformes comme WordPress.com qui ont intégré Let’s Encrypt pour leurs utilisateurs.

Génial ! Comment faire pour installer un de leurs certificats sur mon site ?!

Pas si vite cher ami. Avant de vous montrer comment faire, il faut que je vous reparle de la première méthode. Vous savez, celle où il faut ouvrir son porte-feuille.

Les autres types de certificats SSL/TLS

Bien qu’il soit possible de sécuriser son site gratuitement avec Let’s Encrypt, vous devez savoir qu’il y a un inconvénient majeur : la garantie.

En effet, si jamais un problème se pose au niveau du HTTPS et qu’un de vos clients se fait dérober des données personnelles, vous ne serez pas couvert.

On pourrait croire que cela n’arrive quasiment jamais mais parfois des failles de sécurité sont découvertes et exploitées. Ce fut par exemple le cas en 2014 avec la faille HeartBleed.

Si vous êtes un gros site et que vous gérez des dizaines de milliers de commandes, cela peut vite être problématique. Il faut donc assurer ses arrières.

C’est pourquoi il est possible de se procurer des certificats avec différents niveaux de garantie.

Des sites comme Symantec proposent des certificats à plus de 1000€ dont la garantie monte à 1,75 millions de dollars.

Enfin je vous rassure, seules les très grandes entreprises ont besoin de ce genre de certificat SSL/TLS 😉

Si vous voulez bénéficier d’une garantie en achetant un certificat, sachez qu’il en existe trois types :

  • Les certificats à validation de domaine (DV) : Dans ce cas, l’autorité de certification vérifiera jusque que vous êtes bien propriétaire du nom de domaine pour vous accorder le petit cadenas vert (la vérification se passe automatiquement en ligne) ;
  • Les certificats à validation de l’organisation (OV) : Pour obtenir ce type de certificat, vous devez prouver que vous êtes la personne morale détentrice du domaine à sécuriser et fournir des documents papier comme un extrait KBIS ou une attestation de domiciliation (cela prendra donc un peu plus de temps) ;
  • Les certificats à validation étendue (EV) : Ici, on ne rigole plus. Pour obtenir ce genre de certificat, il faudra montrer patte blanche. Les informations que vous transmettrez sur votre organisation seront vérifiées (existence légale, physique, numéro de téléphone, adresse, activité, etc) et auditées chaque année.

Ces derniers permettent de renforcer la confiance des visiteurs. Pour rappel, voici le genre de rendu que l’on peut obtenir avec les certificats EV (pour Extended Validation) :

Le certificat étendu de Gandi

Comme je vous l’ai dit, les démarches seront plus fastidieuses. Cela dit, si vous êtes une entité importante, je pense qu’il faut le faire.

Important : Pensez à renouveler votre certificat en avance si cela ne se fait pas automatiquement. Comptez bien un mois pour être large au niveau des démarches. Sinon vous troquerez votre beau cadenas vert pour un cadenas rouge voire un avertissement du navigateur. Et ça, ce n’est pas bon du tout !

Quel certificat SSL/TLS choisir ?

J’espère que je ne vous ai pas perdu avec toutes ces infos. Il semblerait que non puisque vous êtes encore là !

Pour répondre rapidement à la question, dans la majorité des cas un certificat gratuit de Let’s Encrypt fera largement l’affaire.

Si vous désirez vous procurer un certificat SSL/TLS payant pour votre site (et bénéficier d’une garantie en cas de problème), la première chose à faire est de voir ce que votre hébergeur propose. Si vous n’êtes pas sur un serveur dédié, vous ne pourrez pas faire autrement.

En revanche, si vous avez accès à la configuration de votre serveur, le choix est assez vaste. Vous pouvez vous tourner vers les autorités de certifications comme Comodo, GlobalSign ou encore NameCheap (leur page de présentation est très bien faite d’ailleurs).

Gandi a mis en place un outil pour savoir quel certificat choisir. Bien sûr, ils prêchent pour leur paroisse mais cela pourra vous aider à y voir plus clair.

Dans la suite de cet article, nous allons voir…

Comment mettre en place Let’s Encrypt chez o2switch

Aujourd’hui, de plus en plus d’hébergeurs proposent à leurs clients des certificats SSL gratuits générés par Let’s Encrypt. C’est le cas d’OVH, de Gandi mais aussi d’o2switch, l’hébergeur que j’ai choisi pour la Marmite.

Je vous propose donc de voir comment installer le HTTPS si vous êtes client chez eux (si ce n’est pas le cas, allez voir ce qu’ils font (aff), ça vaut le coup !).

Une fois que vous aurez un compte chez eux et que vous aurez un ou plusieurs nom de domaine de liés, rendez-vous dans votre cPanel.

Dans la section Sécurité, cliquez sur Let’s Encrypt :

Let's Encrypt dans le cPanel

Cliquez ensuite sur le lien + Générer en face du domaine que vous comptez sécuriser :

Générer un certificat SSL

Sur la page suivante, sélectionnez éventuellement la version avec les www. Vous n’êtes pas forcé de le faire étant donné que nous ferons des redirections pour emmener les visiteurs sur la version HTTPS :

HTTPS sur un nom de domaine supplémentaire

Vous pouvez aussi installer un certificat sur votre boite email (si vous avez déjà un site, il faudra mettre à jour vos clients de messagerie). Quand vous aurez tout ce qu’il vous faudra, cliquez sur Activer !.

Et voilà, c’est terminé !

Le message suivant apparaîtra pour vous le confirmer :

Configuration de Let's Encrypt

Si vous avez déjà configuré un certificat classique, vous apprécierez la rapidité de mise en place 🙂

Notez qu’o2switch renouvellera automatiquement le certificat tous les 3 mois. Contrairement aux certificats classiques, vous n’aurez pas à vous en charger.

9 choses à faire absolument après l’activation du HTTPS

Très bien, le certificat est actif sur votre nom de domaine. Pourtant la configuration n’est pas encore terminée.

La liste de tâche diffère légèrement si vous partez d’un site vierge ou s’il s’agit d’une migration de HTTP vers HTTPS mais if faudra toujours commencer par…

1. Tout rediriger vers le site en HTTPS

Eh bien oui, maintenant que vous avez un site sécurisé autant en faire profiter vos visiteurs.

Pour l’instant, votre site est à la fois accessible via HTTP et via HTTPS. Il faut que tout renvoie vers le HTTPS sinon vous aurez des problèmes de contenu dupliqué.

Certains hébergeurs proposent de gérer au niveau de leur console d’administration mais vous pouvez aussi faire ça dans le fichier .htaccess.

Je vous ai déjà montré comment procéder dans cet article mais voici le morceau de code à inclure (en l’adaptant à votre nom de domaine bien sûr) :

# Redirection vers HTTPS 
RewriteCond %{SERVER_PORT} ^80$ [OR]
RewriteCond %{HTTPS} =off
RewriteRule ^(.*)$ https://monsite.com/$1 [R=301,L]

# Redirection du www vers non-www en HTTPS
RewriteCond %{HTTP_HOST} ^www\.monsite\.com [NC]
RewriteRule ^(.*)$ https://monsite.com/$1 [R=301,L]

Si votre site utilise le www, il faudra utiliser le code suivant pour la redirection :

# Redirection vers HTTPS 
RewriteCond %{SERVER_PORT} ^80$ [OR]
RewriteCond %{HTTPS} =off
RewriteRule ^(.*)$ https://www.monsite.com/$1 [R=301,L]

# Redirection du www vers non-www en HTTPS
RewriteCond %{HTTP_HOST} ^monsite.com [NC]
RewriteRule ^(.*)$ https://www.monsite.com/$1 [R=301,L]

Une fois que vous aurez l’impression que tout fonctionne, entrez votre nom de domaine dans cet outil pour vérifier que les redirections sont bien configurées (tout doit être au vert).

C’est très pratique car dans le cas de la Marmite, cela m’a permis de réaliser que les redirections n’étaient pas si directes que ça. En fait :

  • https://www.wpmarmite.com redirigeait vers :
  • http://wpmarmite.com qui redirigeait vers :
  • https://wpmarmite.com

et que :

  • http://www.wpmarmite.com redirigeait vers :
  • http://wpmarmite.com qui redirigeait vers :
  • https://wpmarmite.com

Alors que chaque adresse doit rediriger directement vers https://wpmarmite.com. Trop de redirections peuvent heurter votre positionnement dans les moteurs de recherches.

Ça serait dommage de se tirer une balle dans le pied n’est-ce pas ?

Attention : Si vous êtes chez OVH, vous devez savoir qu’ils ont activé Let’s Encrypt par défaut sur tous leurs hébergements. Que vous désirez utiliser HTTPS ou non, il vous faudra mettre en place des redirections sinon aurez des problèmes de contenus dupliqués !

2. Remplacer les URL en HTTP

Si vous ne créez pas un nouveau site, il va falloir mettre à jour toutes les URL en HTTP vers HTTPS.

Rassurez-vous nous n’allons pas faire cela à la main mais avec un script que la Marmite vous a déjà présenté dans son tutoriel sur la migration : j’ai nommé Search and Replace DB !

Je vous rappelle brièvement comment procéder (faites tout de même une sauvegarde avant au cas où !) :

  • Téléchargez le script et décompressez-le sur votre ordinateur ;
  • Placez-le à la racine de votre site en renommant son dossier (par exemple « kjhdqiuyrezeaz ») ;
  • Indiquez l’adresse de votre site SANS HTTPS dans le champ replace : http://monsite.com (et sans / à la fin !) ;
  • Indiquez l’adresse de votre site AVEC HTTPS dans le champ with : https://monsite.com (et toujours pas de / à la fin !) ;
  • Cliquez sur dry run pour voir si ça fonctionne bien ;
  • Cliquez sur live run pour tout remplacer dans votre base de données ;
  • Cliquez sur delete me pour supprimer le script de votre serveur.

Une fois l’exécution du script terminée, tous les liens insérés dans vos articles, pages, menus et dans les réglages du site seront désormais en HTTPS.

Pour vous en convaincre, connectez-vous à votre site et allez dans Réglages > Général. Vous devriez voir que les adresses ont été mises à jour :

L'adresse du site a changé dans l'administration

Votre site est toujours vivant ? Alors on continue !

3. Vérifier les ressources chargées par le thème

Bon ici, je vous avoue que ça se corse un peu. Parfois, il arrive que le thème charge toujours des fichiers (CSS, JS ou autre) en HTTP au lieu de HTTPS. On appelle ça les contenus mixtes (mixed content en anglais).

On pourrait être tenté de penser que ce n’est pas bien grave mais en fait si, car la page ne sera pas entièrement sécurisée.

Résultat des courses, le précieux cadenas vert risque de ne plus être affiché par votre navigateur (et exposera votre visiteur à des attaques).

À qui la faute ?

À l’auteur du thème ! (ou à vous si vous l’avez bidouillé n’importe comment)

Pour régler ça, il va falloir mettre les mains dans le code et corriger les ressources chargées en HTTP. Vous pourrez vous aider de l’inspecteur de code de votre navigateur pour traquer les contenus mixtes (via l’onglet console).

Trouver le contenu mixte sur une page HTTPS

Comme vous pouvez le voir ci-dessus, le contenu mixte n’est pas chargé par le navigateur (en l’occurrence un iframe).

Pour en savoir plus sur ce problème et comment les détecter, jetez un oeil à cet article du Journal du Net qui est très bien fait.

Rendez-vous également en fin d’article pour découvrir des extensions pour corriger ce problème quasi automatiquement.

4. Forcer le HTTPS dans l’administration

Ce n’est pas parce que l’on fournit une version du site en HTTPS aux visiteurs qu’il faut s’en passer dans l’administration, n’est-ce pas ?

Normalement, ça devrait déjà être le cas grâce aux redirections mises en place précédemment mais vous pouvez insérer ce code dans le fichier wp-config.php pour forcer cela :

// Forcer le HTTPS dans l'administration
define('FORCE_SSL_ADMIN', true);

Au moins, vous serez certain que WordPress se charge bien en HTTPS.

5. Mettre à jour le fichier robots.txt

Continuons avec l’édition de fichiers avec robots.txt. Ce fichier normalement situé à la racine de votre site permet de dire aux robots d’indexation ce qu’ils peuvent faire sur votre site.

Ici, il n’y a pas grand chose à faire à part mettre à jour l’adresse du sitemap de votre site. Vous n’aurez qu’à ajouter un « s » 🙂

6. Mettre à jour votre site dans Google Search Console

La Marmite n’a pas encore abordé le sujet en détail mais Google Search Console sert à suivre l’indexation de votre site par Google. C’est donc un outil incontournable pour tous les webmasters !

Si vous l’utilisez, il n’est malheureusement pas possible de spécifier que votre site est désormais en HTTPS. Il faudra suivre les instructions de Google pour ajouter votre site.

Pour cela, cliquez sur l’engrenage en haut à droite de GSC (Google Search Console), cliquez sur Changement d’adresse et laissez-vous guider.

Site HTTPS dans Google Search Console

Nous aurons l’occasion de revenir plus en détail sur GSC prochainement. Abonnez-vous à la newsletter pour être prévenu 😉

7. Mettre à jour Google Analytics

Eh oui, il ne faut pas l’oublier celui-là ! Ça a failli m’arriver avec la Marmite…

Contrairement à GSC, vous n’aurez pas à supprimer votre site pour le rajouter ensuite (sinon vous perdriez toutes vos statistiques !).

Pour dire à Google Analytics que votre site utilise désormais le HTTPS, rendez vous dans Admin > Propriété (de votre site) > Paramètre de la propriété et sélectionnez https:// pour le champ URL par défaut :

HTTPS dans Google Analytics

Allez, reprenez votre souffle, on arrive bientôt au bout de cet article (bravo vous venez de parcourir plus de 3500 mots !).

8. Attention aux compteurs des boutons de partage

Inévitablement, vous si vous utilisez les boutons de partage officiels de Facebook, Twitter ou autre, les compteurs vont être réinitialisés.

En effet, les URL n’étant plus les mêmes, pour les réseaux sociaux il ne s’agit plus du même partage !

Vous allez perdre tous vos partages sociaux

Vous allez perdre tous vos partages sociaux…

C’est bête mais vous ne pouvez rien y faire si vous utilisez les boutons officiels. Il ne vous restera plus qu’à obtenir de nouveaux partages pour vos contenus (d’où l’intérêt de passer au HTTPS le plus rapidement possible).

Toutefois, sachez qu’il vous reste une chance de les récupérer.

L’extension premium Social Warfare, vous donnera la possibilité d’afficher le bon nombre de partages pour vos contenus (HTTP + HTTPS).

9. Tester votre certificat SSL/TLS

Enfin, quel que soit le certificat que vous aurez choisi, sachez que vous avez la possibilité de le tester sur ce site. Cela prend un peu de temps mais à la fin vous aurez un tableau présentant les statistiques importantes ainsi qu’une note globale.

Vous pouvez voir que la Marmite s’en sort plutôt bien 🙂

Tester son certificat SSL

Ce test vous permettra de vous assurer que vous n’êtes pas vulnérable à certaines failles SSL.

Et les extensions WordPress liées au HTTPS alors ?

Il est vrai qu’il existe pas mal d’extensions pour optimiser des sites en HTTPS sur le répertoire officiel.

Certaines d’entre-elles proposent des fonctionnalités intéressantes mais d’autres sont totalement inutiles. Regardons cela de plus près :

WordPress HTTPS

wordpress-https-plugin

Je ne pense pas me tromper en disant qu’il s’agit de l’extension qui est la plus recommandée. Pourtant, elle n’a pas été mise à jour depuis 3 ans (oui, ça pique) et elle a déclenché une erreur lorsque je l’ai installée.

Malgré tout, elle semble fonctionner correctement.

Elle permet notamment de :

  • Rediriger les pages chargées en HTTP vers leur version HTTPS (chose inutile dans notre cas car nous avons géré cela précédemment dans le fichier .htaccess) ;
  • Ne pas charger les éléments indisponibles en HTTPS ;
  • Charger des ressources externes via leurs serveurs sécurisés (par exemple Gravatar) ;
  • Se servir du HTTPS sur certaines pages ou articles.

Cette dernière fonctionnalité peut s’avérer intéressante si vous ne désirez pas perdre vos compteurs de partage. Vous pourrez garder vos pages et articles populaires en HTTP et passer tout le reste en HTTPS.

Je suis cependant septique à l’idée d’employer cette extension étant donné que l’auteur ne semble pas décidé à la mettre à jour.

Voir cette extension sur le répertoire officiel (mais je ne vous la recommande pas)

Really Simple SSL

Really Simple SSL

Cette extension est celle qui est la mieux maintenue à jour. Elle est également très légère et se configure rapidement (en fait, je n’ai rien eu à faire !).

Comme pour l’extension précédente, Really Simple SSL permettra de rediriger les pages chargées en HTTP vers HTTPS (jusque là, rien d’extraordinaire).

Là où ça devient plus intéressant, c’est au niveau de la gestion du contenu mixte. Vous vous rappelez, ce sont ces éléments qui ne sont pas chargés en HTTPS sur les pages et qui empêchent l’apparition du petit cadenas vert.

Eh bien cette extension remplace dynamiquement les adresses des ressources pour qu’elles soient chargées correctement.

Le seul cas où cela ne pourrait pas fonctionner serait où la ressource à afficher serait placée sur un autre serveur ne disposant pas d’un certificat SSL. Il vous faudrait alors rapatrier cette ressource sur votre site et mettre à jour son adresse.

Voir cette extension sur le répertoire officiel (une version pro est aussi disponible avec davantage de fonctionnalités)

SSL Insecure Content Fixer

SSL Insecure Content Fixer

Si vous avez décidé de gérer les redirections au niveau du fichier .htaccess, il ne vous reste plus qu’à gérer les éventuels problèmes de contenus mixtes.

Ça tombe bien, une extension a été développée exclusivement pour ça : SSL Insecure Content Fixer.

Une fois que vous l’aurez installée, vous pourrez définir le niveau de correction à employer sur votre site :

Corriger le contenu mixte dans WordPress

Vous pourrez choisir entre :

  • Off : Pour ne rien corriger (vous n’aurez donc pas de cadenas vert) ;
  • Simple : Pour corriger la plupart des problèmes ;
  • Content : Pour analyser et corriger vos publications et widgets textes ;
  • Widgets : Pour analyser et corriger les ressources de n’importe quel widget ;
  • Capture : C’est le mode barbare. Cela analysera le contenu et les ressources de toutes vos pages et les corrigera (par contre, cela sera gourmand en ressources).

Personnellement, je vous conseille de sélectionner Content. Si vous avez encore des soucis, essayez avec les niveaux suivants.

Si le problème persiste toujours, vous n’aurez pas d’autre choix que de régler cela manuellement. Ouvrez l’inspecteur de code, allez dans l’onglet Console, repérez d’où vient le problème et corrigez-le dans votre thème ou votre contenu.

Voir cette extension sur le répertoire officiel (je vous la recommande si vous ne voulez pas trop vous salir les mains).

Conclusion : Restez sur vos gardes

Ça y est, vous avez à présent un site sécurisé grâce à un certificat SSL/TLS. Vos visiteurs peuvent donc accéder à votre site en HTTPS.

Grâce à vous, ils seront certain de bien avoir accès à votre site (et non pas une version modifiée par un malfrat du web) et personne ne pourra savoir qu’ils feront sur votre site (sauf vous bien sûr).

Cependant, le HTTPS ne fait pas tout !

Par exemple dans le cas d’une boutique en ligne, si vos clients utilisent des mots de passe foireux, on pourra toujours tenter d’accéder à leur compte afin de passer des commandes en leur nom.

Pour lutter contre ça, vous pouvez leur générer automatiquement des mots de passe, changer l’adresse de la page de connexion et limiter les tentatives de connexion.

Il y a bien d’autres choses à faire pour sécuriser son site, nous aurons l’occasion d’en reparler prochainement !

Comptez passer au HTTPS prochainement ? Et si vous l’avez déjà fait, pour quel certificat avez-vous opté ? Utilisez-vous une extension en complément ? Dites-moi tout en commentaire 😉

Si vous avez apprécié cet article, inscrivez-vous à la newsletter

Recevez gratuitement les prochains articles et accédez à des ressources exclusives. Plus de 10000 personnes l'ont fait, pourquoi pas vous ?

C'est parti, je m'inscris !

98 commentaires Ajoutez le vôtre

  1. Très bon guide, merci Alex ! Cela résume exactement ce qu’il convient de faire en cas de changement. Si tout est suivi à la lettre, il ne devrait y avoir aucun changement de position dans Google.

    Petite précision concernant l’achat de certificat. Let’s Encrypt est une bonne initiative mais non recommandée pour des sites e-commerce. Un certificat payant offre, tu l’as dit, des garanties et ne coûte que quelques dizaines d’euro par an. De plus, la sécurité est différente : un certificat gratuit pour de la connexion à son back-office WordPress suffira, prendre les CB sur son site ce n’est pas la même chose !

    Enfin, c’est une question de confiance vis-à-vis du client. La présence d’un certificat vérifiée par des autorités (cela passe par un coup de téléphone, des échanges de documents légaux, etc.) est un gage de confiance. Les taux de conversions semblent également plus élevés avec la fameuse barre verte (à voir en fonction de chacun pour autant). 😉

    Répondre
    • Merci pour ton retour Aurélien 🙂

  2. Bonjour, merci pour l’article très complet et le script très utile ! Je suppose qu’il peut servir aussi quand on change de nom de domaine ? Car j’ai souvent des sites en refonte sur des noms provisoires que je rebascule sur le nom principal, et dans la base directement c’est long à faire !

    Petite question du coup à propos des www : doit-on du coup modifier les urls et tout rediriger vers l’adresse https:// sans les www ? quelle est la meilleure utilisation avec ou sans www ? Cela a t-il un impact aussi ?

    merci d’avance

    merci !

    Répondre
    • Bonjour Nathalie,

      Tout à fait, le script peut aussi aider dans le cas d’un changement de nom de domaine. Pour les www, je ne pense pas que cela a une si grande importance. Personnellement, je ne les mets pas par choix purement esthétique.

  3. Très bon article ! Moi qui repoussait en permanence le passage au https parce qu’un peu effrayé par la lourdeur de la tâche… Me voilà rassuré et prêt à sauter sur mon clavier 😊 Merci Alex

    Répondre
    • Merci Raphael !
      Le plus important dans cette tâche étant de bien faire ses redirections et de remplacer les URLs sur son site 🙂

      Bon courage

  4. Merci pour ces explications claires. Est-ce que cela fonctionne aussi pour les sous-domaines… En effet, Let’s Encrypt ne fournit pas (à ma connaissance) de certificat wildcard… donc il faut créer ses certificats sous-domaine par sous-domaine ?

    Répondre
    • Salut Nico,

      Chez o2switch, on peut générer un certificat SSL pour un sous-domaine. Il n’y a qu’à cliquer sur Générer et tout se passera comme pour un domaine classique 🙂
      Bonne continuation et merci pour ton commentaire !

  5. Un excellent article comme d’habitude.

    Répondre
    • Merci Natacha 😉

  6. Alex j’aime beaucoup votre blog et l’article que tu as rédige est très instructif 👍

    Ps : dès que tu fais une formation sur Clermont-Ferrand fais nous signe 👌🏼

    Répondre
    • Merci beaucoup 🙂
      Je ne fais pas (encore) de formations mais je note ça si jamais ça devait changer !

  7. Bonjour, J’ai migré mon site il y a quelques temps chez o2switch à la suite de tes conseils et je ne le regrette pas (merci).
    Je viens de suivre la procédure que tu indiques et tout c’est très bien passé.
    Pour être à 100% conforme, j’ai dû ré uploader quelques images et modifier le chemin vers des fichiers css du style « http://fonts.googleapis.com/css?family=Pacifico »
    Maintenant tout est OK
    encore merci pour ce tuto ……

    Répondre
    • Félicitations Edith 🙂

      Content que ce tuto ait pu t’aider !

  8. Super Alex merci, bon ducoup cela me donne envie de le faire mais je vais encore relire et relire et aussi relire 😉
    @+
    Greg

    Répondre
  9. Rah, j’ai suivi le tuto, mais tout est pété :/

    J’ai été jusqu’à la mise à jour des URL dans la base de données. Et il ne me retrouve plus rien : la page d’accueil du site fonctionne, le back-office aussi, mais les articles & pages renvoient vers des 404.

    J’arrive pas à comprendre … :'(

    Répondre
    • Salut Thomas,

      As-tu rafraichi les permaliens dans Réglages > Permaliens ?

      Sinon si tu as bien suivi le tuto, tu as dû faire une sauvegarde avant de remplacer les URL n’est-ce pas ?

    • Hello !

      (désolé, je n’arrive pas à répondre à ton commentaire directement, j’ai fais « répondre » au mien).

      Alors oui, j’ai updraft plus qui me fait des sauvegardes quotidiennes et heureusement, la mienne datait du matin.

      Donc j’ai tout remis en arrière, pas de véritable catastrophe. Je retenterai sûrement un peu plus tard, mais du coup j’ai deux questions :

      -> C’est quoi la manipulation à faire dans Réglages > permaliens ?
      -> J’utilise Sf move login, pour déplacer ma page de connexion. Et je ne sais pas pourquoi, quand je suis passé au HTTPS j’avais une erreur 404 sur ma page de connexion (celle de SF move login) et, le plugin étant toujours actif, pas la possibilité de passer via la page /wp-login.php. Du coup j’avais un site full https, mais sans possibilité d’accéder au back-office. C’est assez étrange. Et même en enlevant le texte d’Sf move login dans le .htaccess et en supprimant le plugin, rien à faire.

      Tu as déjà rencontré ce problème ?

    • Salut Thomas,

      Ouf, tu me rassures. Ca m’aurait embêté que tu perdes ton site !

      Tu as juste à cliquer sur Enregister les modifications dans Réglages > Permaliens

      Quand tu retenteras, désactive SF Move Login avant au cas où. Après si tes URL n’étaient pas bien changées le plantage était normal.
      A+

    • Ok, c’est noté.

      Je retenterai quand je me serai remis de mes émotions !

      Merci du tuyau 🙂

  10. Excellent article, merci de votre aide.

    Tout semble fonctionner mais si j’enlève volontairement le ‘s’ de mon url le site ne redirige pas tout seul vers le https, pourquoi ?

    Répondre
    • Salut Loïc,

      Je viens de tester et ça fonctionne de mon côté. J’imagine que tu as réglé le problème 🙂

  11. Alex,

    Sur l’url principale tout marche mais sur une url de page, non.
    Exemple http://tedxclermont.fr/mentions-legales/

    Répondre
    • Chez moi ça fonctionne en tout cas 🙂

    • Pareil, ça ajoute le S direct 😉

  12. Bonjour,

    merci pour cet article !

    je suis sous OVH, j’ai ajouté les lignes de code proposées à mon .htaccess (présent à la racine).

    linksspy (lien donné ici) me dit que tout est OK

    j’ai lancé Search and Replace DB en mode « dry run » et il me sort :

    The dry-run option was selected. No replacements will be made.

    « 2: Class __PHP_Incomplete_Class has no unserializer in /home/monsite/www/repertoiresearchandreplacedb/srdb.class.php on line 735

    2: Class __PHP_Incomplete_Class has no unserializer in /home/monsite/www/repertoiresearchandreplacedb/srdb.class.php on line 735 »

    Je n’ai pas osé continuer plus loin du coup, et les navigateurs firefox et opera me mettent qu’ils bloquent du contenu
    Que puis-je faire ?

    Merci !

    Répondre
    • Bonjour Marine,

      A mon avis, le script n’a pas été envoyé en totalité sur ton serveur. Supprime le dossier et renvoie-le 😉

  13. Je viens de le changer et tout fonctionne 🙂
    Merci.

    Répondre
    • Salut Loïc, je viens de voir ton message et j’ai le même problème actuellement sur mon site, la page principale fonctionne mais lorsque j’enlève le « s » dans les URL ça ne fonctionne pas. Comment avais-tu réglé ce problème ?
      Merci !

  14. Bonjour Alex,

    merci pour ta réponse 🙂

    j’ai supprimé et ré-uploadé le script, mais toujours la même erreur.

    J’ai effectué des recherches et j’ai trouvé plusieurs cas qui mentionnent cette même erreur quand le plug-in Yoast est présent :
    https://github.com/interconnectit/Search-Replace-DB/issues/165
    https://github.com/Yoast/wordpress-seo/issues/4571

    Du coup, j’ai désactivé la sitemap de Yoast mais cela ne suffit pas.
    Je trouve ce plugin très utile.
    Je ne sais pas si je dois tenter de mettre les paramètres par défaut de Yoast comme indiqué par un utilisateur, effectuer le changement avec Search Replace DB, puis remettre Yoast.

    Qu’en penses-tu ?

    Répondre
    • Bonjour Marine,

      Ah effectivement, il s’agit d’un soucis au niveau de Yoast SEO. Tu peux essayer ce qui est suggéré. Après je ne peux pas te dire que ça va forcément fonctionner :/

  15. Très bon guide. Ne manque qu’une chose : la gestion des langues et traductions. Le passage en SSL peut mettre un joyeux bordel dans WPML. Certaines traductions ne se font plus pour des raisons obscures et on peut galérer pour les traduire. Mais le guide est très utile. Bravo et merci.

    Répondre
    • Salut Yannick,
      J’ai tenté de rédiger un article le plus généraliste possible. Les problématiques avec WPML sont trop spécifiques à mon sens. Le support de WPML devrait pouvoir t’aider 🙂

    • Bonjour,
      J’utilise 3 langues sur mon site avec WPML et je n’ai pas de problème, la migration c’est bien passée.

  16. Article très instructif et comme toujours très détaillé.
    Migrer vers un site sécurisé présente des risques en termes de fausses manipulations. Suivre votre tuto à la lettre est l’une des solutions.

    Répondre
    • Merci beaucoup 🙂

  17. Salut Alex,

    il faut faire les modifications de Redirections dans le htaccess. avant d’activer l’extension Really Simple SSL ?

    Répondre
    • Bonjour Daniel,

      Really Simple SSL se charge des redirections donc tu n’es pas forcé de les faire via le fichier .htaccess 😉

  18. Cet article est tres bien fait.
    J’ai passé tout mon site https sans encombres grace à vos conseils avisés.
    Merci

    Répondre
  19. Juste une remarque concernant les réécritures d’url dans le fichier .htaccess, je recommande, après avoir audité des sites passés récemment en SSL gratuit avec OVH ( CMS WordPress et Prestashop), de placer les lignes de réécritures d’URL (décrite par Alex en 1)tout au début du fichier .htaccess avant toutes écritures, pour être certain que google n’ai pas de confusion entre la version Http et Https et avoir du duplicate content, surtout si on a déjà un .htaccess bien dodu…
    Je ne sais pas si c’est propre à OVH mais en tout cas, j’ai fait pas mal de test avant de fixer proprement les deux versions aux yeux de google même si dans la barre d’adresse, tout était OK.

    Répondre
    • Merci pour ton retour Christophe 🙂

  20. Très bonnes infos. Merci. Juste un peu perturbé sur la partie GSC car je n’ai pas la même interface que celle de la copie d’écran. Super pour le partage.

    Répondre
    • Salut Nicolas,
      Quelle interface as-tu exactement ? Cela n’a pas bougé chez moi en tout cas.

  21. Salut Alex, j’ai hébergé mon site web sur un hébergeur local en Côte d’Ivoire puisque j’utilise le domaine .ci pour mon site. Le problème c’est qu’il ne propose pas le certificats SSL générés par Let’s Encrypt. Je voudrais savoir s’il y’a une possibilité pour l’installer.

    Répondre
    • Salut,

      SI ton hébergeur ne propose pas Let’s Encrypt, tu vas devoir passer par un certificat classique (et donc payant). Je te suggère de contacter ton hébergeur pour en savoir plus.

    • Merci pour la réponse. J’ai fait des recherches sur google pour savoir comment installer Let’s Encrypt quand l’hébergeur ne le propose pas. j’ai découvert une vidéo sur YouTube qui parle du sujet. Mais le problème il faut avoir accès au SSH de son serveur. J’ai contacté mon hebergeur pour savoir pourquoi je n’ai pas accès au SSH.

      Autre préoccupation, je voudrais savoir si j’installe Let’s Encrypt de cette manière; est ce que le certificat sera mis a jour automatiquement.

      voici le lien de la video https://www.youtube.com/watch?v=XDKvrFKWdvM

    • Non, le certificat ne sera pas mis à jour automatiquement. Dans le cas d’o2switch, ce sont eux qui renouvellent les certificats.

  22. Salut Alex,
    Comme tjs, très bon article!
    Je n’ai pas encore lancé mon site et compte l’héberger chez o2switch : tu as des conseils pour mettre le https en place from scratch? (et s’éviter les pbms de migration…)

    Merci d’avance,
    CLem

    PS : pour info, quand j’utilise chrome pour aller sur le site de la marmite, le https est barré en rouge 🙂 (Tu ns diras d’où ça venait…)

    Répondre
    • Salut Clément,

      Si tu es chez o2switch, tu peux faire ça assez simplement via le cPanel (comme indiqué dans l’article en fait 😉 ).

      Pour le HTTPS de la Marmite, c’est bizarre. Chrome ne me signale pas cela de mon côté. Peux-tu me contacter par email et me montrer une capture d’écran ?

  23. Salut,

    Très bon article pour passer en HTTPS. Je signale un soucis que l’on ne sait pas corriger avec OVH.
    On se retrouve avec XX cookies qui ne sont pas sécurisés, on a configuré l’en-tête HTTP Set-Cookie avec Apache mais rien n’y fait…

    Vue avec OVH mais ne savent pas non plus.

    D’ailleurs si quelqu’un à rencontré ce soucis et à la solution on est preneur… 🙂 (certificat ssl ovh payant à 49€et hébergement perso).

    Répondre
    • Salut Christophe,

      Si OVH ne peut pas t’aider en ayant la main sur ton serveur, je ne vais pas pouvoir faire grand chose… Enfin peut-être qu’un lecteur de la Marmite aura la solution 🙂

  24. Encore un tuto très réussi, la preuve, j’ai passé mon site en https en une heure … et ça marche !!!
    Merci Alex 😉

    Répondre
    • Super Guy ! Content de voir que tout s’est bien passé !

  25. Merci beaucoup pour ce tuto vraiment détaillé et précis ! J’ai passé 2 petits sites au HTTPS sans souci, il m’en reste un bien plus gros et avec des pub adsense et autres iframe… je n’ose pas trop le passer maintenant, j’ai peur de mettre un beau bazar avec les plug-in et de perdre de l’argent au passage.
    Si tu as des retours de ce point de vue là…

    Autre question, pour la Search console, tu dis de faire la manip « changement d’adresse » mais Google indique « Actuellement, cet outil n’accepte pas les déplacements de site qui impliquent une modification du nom de sous-domaine, un changement de protocole (de HTTP à HTTPS) ou une modification du chemin d’accès uniquement. » (ici : https://support.google.com/webmasters/answer/83106 ).

    Donc si j’ai bien compris, on valide les 4 versions de son site (avec/sans S, avec/sans www), on met des rel canonical vers le https pour chaque page (Il faut régler quelque chose avec Yoast ou ça se fait dans la BDD à l’étape 2 ?) et on envoie 2 sitemaps à la GSC. C’est bien cela ?

    Merci encore pour ce gros travail explicatif !

    Répondre
    • Bonjour Julie,

      Pour ton site, fais une sauvegarde et restaure-le si tout ne se passe pas comme prévu.

      Au niveau de GSC, il faut créer une nouvelle propriété pour le site en https et faire le changement d’adresse pour l’ancien (vers le nouveau). Par contre, il n’y a pas besoin valider les 4 versions. Actuellement, tu utilises seulement une version (disons sans www) et l’autre version (avec www) est censée être redirigée. Il faudra donc rediriger les 2 versions http vers le https (ainsi que le https avec www).

      Est-ce que tu me suis ? ^^

    • Oui j’ai tout suivi ;). Merci !

  26. Salut Alex, très bon article qui couvre le sujet complet sur le HTTPS.
    Moi, je traine encore à migrer mon blog en https vue que j’ai un problème avec les contenus mixtes et les codes, je maitrise pas très bien.
    Pouvez-vous nous fournir un article détaillé sur comment fixer le problème de contenus mixtes ?

    Répondre
    • Bonjour Smach,

      Vous trouverez une extension dans cet article pour corriger les contenus mixtes récalcitrants 😉

  27. Super tuto, j’y suis arrivé sans problème… enfin, une fois qu’OVH a bien voulu résilier mon CDN… car le SSL n’est pas compatible avec le CDN;

    Merci encore pour le gain de temps !

    Répondre
  28. Remoi

    Je suis allé chercher bien loin et en anglais des informations qui sont sur le site officiel :
    https://support.google.com/webmasters/answer/83106

    Point 3 de : Avant de procéder à une demande de changement d’adresse

    Du coup que conseilles-tu de prévenir Google de ce changement ?

    Encore merci pour ce superbe article

    Répondre
    • Bonjour Oliv’ j’ai tendance à penser qu’en suivant les recos de Google, on prend le meilleur chemin

  29. Salut Alex,

    Merci pour tes conseils, la migration s’est faite sans problème.

    Répondre
    • Super Pierre 🙂

  30. Salut Alex,

    Merci pour le tuto et la réduc o2switch!
    Je suis actuellement la formation wpchef.

    Comme je créé un nouveau site, j’en ai profité pour faire l’installation wordpress en https directement et installer let’s encrypt.
    J’ai uniquement modifié le fichier « .htaccess » puis testé la redirection (étape2) et le certificat SSL/TLS (étape9).

    Comme le site est tout nouveau, je sais bien entendu que les étapes 6 à 8 ne sont pas nécessaires, par contre qu’en est-il des étapes 3 à 5?

    Est-ce vraiment nécessaire? Je préfèrerais éviter de tout casser dès le début 🙂

    Merci!
    CLément

    Répondre
    • Salut Clément,

      Avec plaisir pour o2switch !
      Pour les étapes 3 à 5, ce n’est pas obligatoire mais c’est préférable 😉

  31. Bonjour Alex,

    Merci pour ton article, il m’a beaucoup aidé !

    Répondre
  32. Bonjour et merci beaucoup pour ce sujet.

    J’ai essayé comme tu l’as indiqué avec les codes sources pour le transfert en https, et après avoir été sur http://www.linksspy.com il ne me pas tout en vert, j’ai « through a redirect chain. This hurts your rankings » .
    Pourrait tu m’aclairer à ce niveau la? merci

    Répondre
    • bonjour jc, il peut y avoir plusieurs raisons à cette situation. Nous ne pouvons malheureusement pas faire de support faute de temps. Si le problème persiste je vous invite à contacter un développeur freelance qui solutionnera votre problème très rapidement.

  33. Salut Alex,

    merci beaucoup pour ce tuto qui m’a bien aidé à passer mon site en https.
    J’ai modifié les fichiers .htaccess, utilisé le logiciel SSL Insecure Content et modifié certains trucs à la main (notamment niveau css).
    Search and Replace DB n’a pas fonctionné ni un autre du même genre.

    Cela a pris du temps en revanche pour que tout fonctionne bien car un plugin n’était pas compatible https, et là cela semble OK.
    http://www.ssllabs.com me donne un A

    Répondre
    • Merci pour votre retour Marine !

  34. Merci beaucoup pour ce tuto ! Je suis chez 1&1 et un jour j’ai reçu un mail indiquant qu’on pouvait sécuriser son site avec un certificat SSL, j’avais fait la demande mais je ne m’en suis plus occupé (certificat fourni par Symantec).
    Résultat, grâce a ton artcile je me suis rendue compte que j’avais bien un site en https que je n’utilisais pas et donc du contenu dupliqué ! Je me suis donc empressée de suivre tes conseils pour réparer ma boulette 🙂 !
    J’ai tout réussi (même les contenus mixtes grâce à l’extension SSL Insecure Content Fixer) et j’ai mon petit cadenas vert partout !
    Par contre, je n’ai pas réussi pour la Search Console, quand je clique sur « Changement d’adresse », sur l’étape 1 il m’indique « Aucun site disponible » alors que je l’ai bien ajouté et validé …
    Et je me suis rendu compte que je n’ai pas de fichier robots.txt ! C’est grave docteur ? Mais j’ai l’extension WP Sitemap Page …
    En tout cas merci beaucoup !

    Répondre
  35. Bonjour,

    Suite à l’installation du let’s encrypt via le Cpanel de o2switch et pares avoir fait les redirections nécessaires je n’ai plus accès à mon site ni à l’administration wordpress, toutes les page s’affiche en erreur 404.

    Un conseil?

    Répondre
    • Bonjour Morgane, avez-vous contacté o2switch ? Ils sont hyper réactifs et très aidants.

    • merci de votre retour, effectivement je les ai contacté, ils ont résolu le problème très rapidement!

      Merci

  36. Bonjour,

    Est-ce que l’utilisation du plugin Really Simple SSL suffit pour effectuer le passage en https correctement? Ou faut-il quand même effectuer certaines actions manuellement?

    Merci d’avance pour l’information

    Répondre
  37. Bonjour
    Fournissez vous une prestation pour l’effectuer sur note site wordpress (basé sur wordpress multisite).
    Merci

    Répondre
    • Bonjour Pierre, désolé nous ne proposons pas de prestation cependant je vous invite à contacter un freelance wordpress qui fera ça très rapidement. Je vous conseille la plateforme upwork, hopwork (fr), ou fiverr pour ce type de job

  38. Bonjour, bonjour et merci pour ce tuto qui m’a bien aidé dans cette étape 🙂

    Je rencontre seulement un problème depuis le passage au ssl … les iframe de l’administration ne s’affiche plus, donc plus possible de mettre à jour les newsletter de Mail Poet par exemple… Dans la console j’ai deux jolis message :
    « Load denied by X-Frame-Options:  » et « Error: Permission denied to access property « document »  »
    Alors j’ai tenté de modifier le header via htaccess mais ça ne change rien 🙁
    Auriez-vous un conseil, une idée ?

    Merci pour tout.

    Répondre
    • Bonjour elricka, malheureusement nous n’avons pas le temps pour faire du support mais je vous invite à consulter la faq de mail poet ou de contacter un freelance

  39. Bonjour Marmitte,

    J’essaie de faire une redirection d’un site en https en suivant tes recommandation mais visiblement cela ne fonctionne pas.
    Suis un peu perdu dans la marche à suivre!!
    Un conseil personnalisé??

    Répondre
    • Bonjour Marc, nous n’avons malheureusement pas le temps pour faire du support, je vous invite à contacter un freelance wordpress qui fera le job très rapidement et à moindre coût.

  40. C’est encore moi, sachant que tu vérifies les messages, j’en profite pour rajouter quelque choses à mon précédent message que j’ai oublié avant de cliquer sur envoyer :

    MERCI !

    Bon, j’espère que tu ne validera pas ce message Ahah !

    Répondre
    • quand un visiteur nous remercie, il faut le valider ahah 🙂

  41. Merci Nicolas.

    Répondre
  42. Excellent article, clair et bien détaillé.

    Cependant, j’ai une question: quel intérêt pour un blog basique ou un site vitrine de passer en https ? Parce que pour moi, strictement aucun.

    On verra si Google « force » ou plutôt incite à passer en https en donnant des bons points.

    Répondre
    • Salut Ahmed,

      Tot ou tard, Google pénalisera vraiment les sites non sécurisés. A mon sens, il faut faire la bascule le plus tôt possible pour être prêt à ce moment là 😉

  43. Merci beaucoup d’avoir pris le temps de répondre 🙂 En fait il s’agissait d’un problème lié à l’hébergeur (x-frame-options) … Donc bon à savoir pour ceux qui passe par un mutu, il suffit de prendre le temps de bien expliquer (3 jours) et ça peu rentrer dans l’ordre. Merci encore pour ce tuto et à bientôt !

    Répondre
  44. Bonjour et merci pour ce tuto que j’ai appliqué à la lettre avec un certificat let’s encrypt chez OVH.
    Malheureusement, il y a un problème important qui n’arrive pas qu’à moi.
    J’ai les sauvegardes en principe avec BackWPup qui ne démarrent plus.
    Idem avec UpdraftPlus.
    Apparement le cron ne fonctionne plus. OVH m’a conseillé d’utilisé leur cron mais pour le moment sans succès ou d’utiliser un plugin compatible https ????
    Un utilisateur de BackWPup propose quelques lignes en PHP pour corriger le problème, mais chez moi, rien de mieux.

    ici :
    https://wordpress.org/support/topic/curl-error-35-error140770fcssl-routinesssl23_get_server_hellounknown-protoc/

    Répondre
  45. Bonjour,

    Je rencontre un problème de méthodologie pour mettre en place le https sur un blog WP chez OVH.

    Ma question est relative au fichier htacces, pour l’instant le fichier qui est sur le serveur est :

    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    # END WordPress

    OVH me demande de placer ces lignes dans mon fichier htacess :

    RewriteEngine On
    RewriteCond %{SERVER_PORT} 80
    RewriteRule ^(.*)$ https://www.votredomaine.fr/$1 [R,L]

    Sans plus d’explicitions de leur par, je voudrais savoir où dois-je placer ces lignes ?

    Merci de votre aide.

    Christophe

    Répondre
    • Bonjour cbonnet, faute de temps, nous ne pouvons pas faire de support sur ce genre de demande mais je vous invite à contacter OVH qui propose un accompagnement

  46. merci infiniment grâce à vous et au web j’y arrive presque et mon 2e site sera en ligne bientôt (1 site vitrine et celui ci le plus dur le site de commerce en ligne merci merci merci

    Répondre
    • Top merci pour votre joli mot alia

  47. pour répondre à christophe impossible de suivre les instructions d’Ovh bug et site non accessible après modification. IL semblerait que ce soit parce que le fichier .htaccess ne soit pas à la racine du site mais dans www
    SO il faut le dupliquer et le mettre vraiment à la racine cad avant www

    Répondre
  48. Hello !

    J’ai resuivi le tuto (2e essai) et tout marche bien et proprement. Which is cool.

    Juste une petite précision sur SSL Insecure Content Fixer : C’est très efficace, TROP efficace.
    En fait ça remplace tout le contenu HTTP par du HTTPS, même quand l’équivalent HTTPS n’existe pas.

    Du coup, ça casse les liens : une image insérée dans un article en HTTP est remplacée par le même lien en HTTPS, que celui-ci existe ou non.

    Et comme cela semble se faire à la volée, ce n’est pas détectable par Broken Link Checker qui voit les liens en HTTP (soit comme ils sont écris dans le corps des articles).

    Du coup on a le choix : soit un l’utilise et on passe tout en HTTPS (donc toutes les pages sont bien sécurisées) mais il y a beaucoup de liens cassés qu’il faut détecter à la main, soit on ne s’en sert pas, mais on a du contenu non sécurisé (insecure content) chargé sur la page.

    Je n’ai pas encore trouvé de solution, si j’y arrive, je la partagerai 🙂

    Bonne journée !

    Répondre
  49. Bonjour,

    Merci pour cet article. Vous parlez de garanties dans le cas de divulgation de données personnelles de clients en cas de faille de sécurité.

    Qu’en est-il des données personnelles de prospects ou simples lecteurs ? N’y a-t-il pas un risque à ce niveau là ?

    A bientôt,
    François

    Répondre
    • Bonjour François, quel type de données pour un simple lecteur ?

  50. Hello d’un fan de Marrakech !
    Merci pour ce super article, que je vais m’empresser de mettre en application sur mes sites wordpress.
    J’utilise CloudFlare: est-ce que la procédure est différente?
    Merci!

    Répondre

Laisser un commentaire

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

La Marmite ne peut malheureusement pas fournir de support. Merci d'en tenir compte dans votre commentaire 😉

Si vous ne lui en voulez pas, donnez-lui un j'aime sur Facebook :



216 Shares
Share121
Tweet47
Share48