HTTPS partout : pourquoi et comment migrer son site

Comprendre le HTTPS : quelle différence avec HTTP

Quand j’ai commencé dans le développement web en 2014, le HTTPS était réservé aux sites e-commerce et aux banques. Aujourd’hui, après plus de 10 ans à configurer des serveurs et déployer des sites, je peux vous affirmer que le HTTPS est devenu un prérequis absolu pour tout projet web, du simple blog au portail institutionnel.

Le protocole HTTP (HyperText Transfer Protocol) transmet les données entre le navigateur de l’internaute et le serveur en clair. Concrètement, si quelqu’un intercepte la connexion sur un réseau Wi-Fi public, il peut lire les mots de passe, les numéros de carte bancaire et toutes les informations échangées. Le HTTPS ajoute une couche de chiffrement TLS (Transport Layer Security) qui rend ces données illisibles pour tout tiers.

Le fonctionnement repose sur un mécanisme de certificat SSL/TLS. Lorsqu’un visiteur accède à votre site, son navigateur vérifie le certificat, établit une connexion chiffrée via un échange de clés, puis toutes les communications transitent dans ce tunnel sécurisé. Ce processus, appelé « handshake TLS », prend moins de 100 millisecondes sur un serveur correctement configuré.

Pour bien comprendre les enjeux de sécurité liés à votre infrastructure, je vous recommande de consulter mon guide sur la configuration d’un serveur VPS Linux qui aborde les fondamentaux de la sécurité serveur.

Pourquoi migrer son site en HTTPS en 2026

La question n’est plus « pourquoi migrer » mais « pourquoi ne l’avez-vous pas encore fait ». Voici les raisons concrètes que j’explique systématiquement à mes clients.

Le référencement naturel en dépend directement

Google utilise le HTTPS comme signal de classement depuis août 2014. Ce qui était un bonus marginal est devenu un facteur discriminant. Dans les audits SEO que je réalise, je constate régulièrement qu’un site HTTP perd entre 10 et 15 positions par rapport à un concurrent HTTPS équivalent en contenu. Si vous travaillez votre SEO technique sur WordPress, le HTTPS est littéralement la première case à cocher.

La confiance des visiteurs

Depuis 2020, Chrome affiche la mention « Non sécurisé » dans la barre d’adresse pour tout site HTTP. Firefox fait de même. D’après les études de comportement utilisateur, 85 % des internautes quittent un site qui affiche cet avertissement, surtout s’il comporte un formulaire de contact ou de paiement. Pour une boutique WooCommerce, c’est simplement rédhibitoire.

Les performances avec HTTP/2

Le protocole HTTP/2 n’est disponible qu’en HTTPS. Il apporte le multiplexage des requêtes, la compression des en-têtes et le server push. En pratique, j’ai mesuré des gains de 20 à 50 % sur les temps de chargement après migration HTTPS + HTTP/2, notamment sur les sites riches en images. Combiné à un CDN comme Cloudflare, les résultats sont spectaculaires.

La conformité RGPD

Le Règlement Général sur la Protection des Données impose de mettre en œuvre des mesures techniques appropriées pour protéger les données personnelles. Un formulaire de contact sur un site HTTP transmet le nom et l’email de l’utilisateur en clair. En cas de contrôle de la CNIL, l’absence de HTTPS constitue un manquement caractérisé. Ce n’est pas théorique : des sanctions ont déjà été prononcées.

La protection contre les attaques

Le HTTPS protège contre les attaques de type man-in-the-middle (MITM), où un attaquant intercepte et modifie les communications. Il empêche également l’injection de contenu par des FAI ou des hotspots Wi-Fi malveillants. Pour une protection complète, pensez aussi à protéger votre site contre les attaques DDoS.

Choisir le certificat SSL adapté à son projet

Tous les certificats SSL ne se valent pas. Après avoir installé des centaines de certificats pour mes clients, voici comment je classe les options disponibles.

Certificat DV (Domain Validation)

Le certificat DV vérifie uniquement que vous contrôlez le nom de domaine. C’est le type délivré par Let’s Encrypt gratuitement. Il convient parfaitement pour un blog, un site vitrine ou un site WordPress classique. L’émission prend quelques secondes et l’installation est automatisable. J’ai rédigé un guide complet sur l’installation de Let’s Encrypt qui détaille la procédure.

Certificat OV (Organization Validation)

Le certificat OV vérifie l’identité de l’organisation. L’autorité de certification contrôle les documents légaux de l’entreprise. Comptez entre 50 et 200 € par an. Je le recommande pour les sites institutionnels et les intranets d’entreprise qui doivent afficher une garantie d’authenticité renforcée.

Certificat EV (Extended Validation)

Le certificat EV impose une vérification approfondie de l’entreprise. Il était historiquement associé à la barre d’adresse verte, mais les navigateurs ont supprimé cet affichage visuel depuis 2019. Son intérêt a donc considérablement diminué. Les tarifs oscillent entre 150 et 500 € par an. Je ne le recommande plus que pour les banques et les sites de paiement à forte volumétrie.

Certificat Wildcard

Un certificat Wildcard protège un domaine et tous ses sous-domaines (*.monsite.fr). Let’s Encrypt le propose gratuitement via la validation DNS. C’est mon choix systématique quand je gère un WordPress multisite ou un projet avec plusieurs sous-domaines (blog.monsite.fr, app.monsite.fr, api.monsite.fr).

Installer un certificat SSL sur son serveur

L’installation dépend de votre type d’hébergement. Je vais couvrir les scénarios les plus courants que je rencontre au quotidien.

Sur un hébergement mutualisé (OVH, o2switch)

La bonne nouvelle : la plupart des hébergeurs mutualisés intègrent désormais Let’s Encrypt directement dans leur panneau de contrôle. Chez o2switch comme chez OVH, l’activation se fait en quelques clics depuis cPanel ou l’espace client.

Sur cPanel (o2switch, par exemple) :

1. Connectez-vous à cPanel
2. Accédez à la section « SSL/TLS Status » ou « Let’s Encrypt »
3. Sélectionnez votre domaine et cliquez sur « Issue » ou « Installer »
4. Le certificat est actif en quelques secondes

Sur l’espace client OVH :

1. Rendez-vous dans Web Cloud > Hébergements > votre hébergement
2. Onglet « Multisite »
3. Cliquez sur les trois points à côté de votre domaine, puis « Modifier »
4. Cochez « SSL » et validez

Si vous hésitez entre les deux, mon comparatif VPS vs mutualisé vous aidera à choisir la bonne formule.

Sur un VPS avec Nginx

C’est la configuration que je déploie le plus souvent. Voici la procédure complète avec Certbot, le client officiel de Let’s Encrypt.

Installation de Certbot :

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

Obtention et installation automatique du certificat :

sudo certbot --nginx -d monsite.fr -d www.monsite.fr

Certbot modifie automatiquement la configuration Nginx pour activer HTTPS et ajouter la redirection HTTP vers HTTPS. Le résultat dans votre fichier de configuration Nginx ressemblera à ceci :

server {
    listen 443 ssl http2;
    server_name monsite.fr www.monsite.fr;

    ssl_certificate /etc/letsencrypt/live/monsite.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monsite.fr/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/monsite.fr;
    index index.php index.html;
}

server {
    listen 80;
    server_name monsite.fr www.monsite.fr;
    return 301 https://$host$request_uri;
}

Sur un VPS avec Apache

sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d monsite.fr -d www.monsite.fr

Certbot gère la configuration Apache automatiquement, y compris l’activation du module mod_ssl et la redirection.

Migrer un site WordPress vers HTTPS pas à pas

Après avoir installé le certificat SSL sur le serveur, il reste à configurer WordPress pour utiliser HTTPS. Voici la procédure que j’applique systématiquement pour mes clients.

Étape 1 : sauvegarder intégralement le site

Avant toute manipulation, réalisez une sauvegarde complète de votre site WordPress. Base de données et fichiers. C’est non négociable. En 10 ans, je n’ai jamais eu de problème irréversible grâce à cette habitude.

Étape 2 : modifier les URL dans les réglages WordPress

Dans Réglages > Général, modifiez les deux champs :

• Adresse web de WordPress (URL) : https://monsite.fr
• Adresse web du site (URL) : https://monsite.fr

Vous pouvez aussi le faire via wp-config.php pour plus de sécurité :

define('WP_HOME', 'https://monsite.fr');
define('WP_SITEURL', 'https://monsite.fr');

Étape 3 : rechercher-remplacer dans la base de données

C’est l’étape critique. WordPress stocke les URL en absolu dans la base de données (articles, pages, options, widgets). Il faut remplacer toutes les occurrences de http://monsite.fr par https://monsite.fr.

J’utilise WP-CLI pour cette opération, c’est la méthode la plus fiable :

wp search-replace 'http://monsite.fr' 'https://monsite.fr' --all-tables --precise

L’option –precise gère correctement les données sérialisées de WordPress, ce qui évite de casser les options des thèmes et des plugins. C’est un détail que beaucoup de tutoriels oublient et qui provoque des erreurs difficiles à diagnostiquer.

Si vous n’avez pas accès à WP-CLI, le plugin Better Search Replace fait le même travail depuis l’interface d’administration.

Étape 4 : forcer HTTPS dans wp-config.php

define('FORCE_SSL_ADMIN', true);
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

La seconde condition est indispensable si votre site est derrière un reverse proxy ou un CDN comme Cloudflare, car le serveur web ne voit pas directement la connexion HTTPS du visiteur.

Étape 5 : vérifier le thème et les plugins

Certains thèmes WordPress et plugins anciens codent des URL en dur. Vérifiez particulièrement les fichiers du thème enfant, les widgets personnalisés et les réglages du thème Astra ou de votre constructeur de pages. Les URL de logos, favicon et images de fond sont souvent oubliées.

Corriger le contenu mixte et les erreurs courantes

Le contenu mixte (« mixed content ») est le problème numéro un que je rencontre après une migration HTTPS. Il se produit quand une page HTTPS charge des ressources (images, scripts, feuilles de style) en HTTP.

Identifier le contenu mixte

Ouvrez les DevTools de Chrome (F12), onglet Console. Les erreurs de contenu mixte apparaissent en jaune (avertissement) ou en rouge (bloqué). Vous pouvez aussi utiliser l’outil en ligne Why No Padlock ou le plugin WordPress SSL Insecure Content Fixer.

Pour un audit complet du site, j’utilise Screaming Frog en filtrant les URL internes en HTTP. Sur un site de 500 pages, cet outil identifie en quelques minutes toutes les ressources problématiques.

Les sources les plus fréquentes de contenu mixte

• Images insérées dans les articles : le search-replace résout 90 % des cas
• Polices Google Fonts chargées en HTTP dans le thème : remplacez http:// par // (protocole relatif) ou https://
• Scripts externes (analytics, widgets, iframes) : mettez à jour les URL d’intégration
• CSS avec url() pointant vers des ressources HTTP : vérifiez les feuilles de style personnalisées
• Contenu intégré (vidéos, cartes, formulaires tiers) : la plupart des services proposent désormais des URL HTTPS

La solution rapide avec le header CSP

En attendant de corriger toutes les références HTTP, vous pouvez ajouter un en-tête Content-Security-Policy pour forcer la mise à niveau automatique :

# Dans .htaccess (Apache)
Header always set Content-Security-Policy "upgrade-insecure-requests"

# Dans nginx.conf (Nginx)
add_header Content-Security-Policy "upgrade-insecure-requests" always;

Cette directive demande au navigateur de charger automatiquement les versions HTTPS des ressources HTTP. C’est un filet de sécurité, pas une solution définitive : corrigez les URL à la source dès que possible.

Redirections 301 et SEO post-migration

La redirection HTTP vers HTTPS est l’étape la plus critique pour préserver votre référencement. Une erreur ici peut coûter des mois de travail SEO.

Configurer la redirection 301 globale

Sur Apache (.htaccess) :

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

Sur Nginx :

server {
    listen 80;
    server_name monsite.fr www.monsite.fr;
    return 301 https://$host$request_uri;
}

Le code 301 indique une redirection permanente. Les moteurs de recherche transfèrent alors la quasi-totalité du « jus SEO » vers la nouvelle URL HTTPS. J’insiste : utilisez 301, jamais 302 (temporaire).

Mettre à jour Google Search Console

1. Ajoutez la propriété HTTPS de votre site dans Google Search Console
2. Soumettez le nouveau sitemap (https://monsite.fr/sitemap.xml)
3. Vérifiez que les anciennes URL HTTP sont bien redirigées en utilisant l’outil d’inspection d’URL
4. Surveillez le rapport de couverture pendant les 4 à 6 semaines suivantes

Mettre à jour les liens externes

Modifiez l’URL de votre site sur tous les profils que vous contrôlez : Google Business Profile, réseaux sociaux, annuaires, et surtout votre signature d’email professionnel. Les redirections 301 fonctionnent, mais un lien direct en HTTPS est toujours préférable pour le SEO.

Les en-têtes de sécurité à ajouter

Profitez de la migration pour renforcer la sécurité avec les en-têtes HTTP recommandés :

# HSTS : force HTTPS pendant 1 an
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

# Protection contre le clickjacking
Header always set X-Frame-Options "SAMEORIGIN"

# Protection XSS
Header always set X-Content-Type-Options "nosniff"

Le header HSTS (HTTP Strict Transport Security) est particulièrement important : il indique aux navigateurs de ne jamais tenter de se connecter en HTTP, même si l’utilisateur tape manuellement http:// dans la barre d’adresse. Attendez d’avoir vérifié que tout fonctionne en HTTPS avant de l’activer, car il est difficile à annuler.

Vérifier et automatiser le renouvellement du certificat

Les certificats Let’s Encrypt expirent après 90 jours. C’est volontaire : des durées courtes encouragent l’automatisation et limitent l’impact d’une compromission de clé. Certbot configure automatiquement un timer systemd ou une tâche cron pour le renouvellement.

Vérifier que le renouvellement automatique fonctionne

sudo certbot renew --dry-run

Si cette commande s’exécute sans erreur, votre renouvellement automatique est opérationnel. Je recommande de mettre en place un monitoring serveur qui vérifie la date d’expiration du certificat et vous alerte 14 jours avant l’échéance.

Que faire si le renouvellement échoue

Les causes les plus fréquentes d’échec que je rencontre :

• Port 80 bloqué par le pare-feu : Certbot a besoin du port 80 ouvert pour la validation HTTP-01
• Configuration DNS incorrecte : le domaine ne pointe plus vers le serveur. Vérifiez vos enregistrements DNS
• Nginx ou Apache en erreur : un fichier de configuration cassé empêche le rechargement après renouvellement
• Espace disque insuffisant : Certbot a besoin de quelques Mo pour écrire les nouveaux certificats

Pour un certificat Wildcard, le renouvellement utilise la validation DNS-01, ce qui nécessite un plugin DNS compatible (Cloudflare, OVH, etc.) ou un script personnalisé.

Comparatif des solutions SSL par hébergeur

Selon votre choix de nom de domaine et d’hébergeur, l’implémentation du SSL varie considérablement. Voici un comparatif basé sur mon expérience directe avec chaque plateforme.

Pour un comparatif plus détaillé entre les hébergeurs WordPress premium, consultez mon article Kinsta vs WP Engine. Et si vous hésitez entre un hébergement classique, mon comparatif OVH vs o2switch vous donnera tous les éléments de décision.

Un point important : si vous utilisez Cloudflare en mode proxy, vous avez en réalité deux connexions SSL distinctes. La première entre le visiteur et Cloudflare (toujours chiffrée), et la seconde entre Cloudflare et votre serveur. Configurez le mode « Full (Strict) » dans Cloudflare pour que les deux segments soient chiffrés avec des certificats valides. Le mode « Flexible » laisse la connexion serveur en HTTP, ce qui crée une fausse impression de sécurité.

Tester la qualité de son installation SSL

Une fois le certificat installé, testez la configuration avec SSL Labs (ssllabs.com). Visez une note A ou A+. Les points qui font perdre des points :

• Protocoles obsolètes activés (TLS 1.0, TLS 1.1) : désactivez-les
• Suites de chiffrement faibles : utilisez la configuration recommandée par Mozilla
• Absence de HSTS : ajoutez l’en-tête comme décrit plus haut
• Chaîne de certificats incomplète : assurez-vous de servir le fullchain.pem, pas seulement le certificat

Si vous gérez un hébergement WooCommerce, la note SSL Labs A+ n’est pas un luxe, c’est une nécessité pour inspirer confiance à vos acheteurs.