Comment passer de HTTP à HTTPS ?

Passer de HTTP à HTTPS ne se résume pas à installer un certificat : il faut sécuriser la connexion, rediriger proprement, éviter le contenu mixte et vérifier l’impact sur le référencement et les outils de mesure. Une migration bâclée peut provoquer une chute de trafic organique, des avertissements de sécurité dans les navigateurs, voire une inaccessibilité partielle du site. Ce guide couvre chaque étape dans l’ordre, avec des exemples de configuration concrets et une checklist de validation finale.

Comprendre ce que change réellement le passage de http à https

HTTP (hypertext transfer protocol) transmet les données en clair entre le navigateur et le serveur. N’importe quel équipement situé sur le chemin réseau — un routeur wifi public, un proxy de fournisseur d’accès — peut lire, modifier ou injecter du contenu dans ces échanges. HTTPS ajoute une couche de sécurité en s’appuyant sur TLS (transport layer security), le successeur de SSL, pour chiffrer intégralement la communication.

Trois propriétés fondamentales sont garanties par HTTPS :

• Confidentialité : les données échangées (formulaires, cookies, identifiants, numéros de carte) deviennent illisibles pour toute machine non autorisée.
• Intégrité : TLS détecte toute modification du contenu en transit ; une altération invalide la connexion.
• Authentification : le certificat TLS prouve que le serveur appartient bien au domaine affiché, empêchant les attaques de type « homme du milieu ».

Côté navigateur, la transformation est visible : le protocole https:// remplace http:// dans la barre d’adresse, accompagné d’un pictogramme cadenas. À l’inverse, depuis 2018, Google Chrome marque explicitement les pages HTTP comme « Non sécurisé », ce qui nuit à la crédibilité du site auprès des visiteurs.

Du point de vue du référencement, Google a intégré HTTPS comme signal de classement dès 2014. En 2016-2017, le moteur a confirmé l’affichage d’alertes pour les sites HTTP collectant des données via formulaire. Aujourd’hui, opérer en HTTP pur expose à un double désavantage : pénalité de confiance utilisateur et signal SEO négatif. La migration n’est plus optionnelle pour tout site souhaitant rester compétitif.

Il est crucial de comprendre que, pour Google, une URL en http:// et la même URL en https:// sont deux adresses distinctes. Sans redirection et sans mise à jour des signaux (liens, canonicals, sitemap), le moteur peut indexer les deux versions simultanément, créant du contenu dupliqué et diluant l’autorité des pages. C’est précisément pourquoi la migration doit être traitée comme un projet technique structuré, et non comme un simple changement de configuration serveur.

Une fois ce cadre posé, la question pratique est : quel certificat TLS choisir, et comment l’obtenir ?

Choisir un certificat tls et l’obtenir, gratuit ou payant

Un certificat TLS est un fichier numérique délivré par une autorité de certification (CA, certificate authority) reconnue par les navigateurs. Il contient la clé publique du serveur, le nom de domaine couvert et la signature de la CA. Sans ce certificat, le navigateur refuse d’établir une connexion sécurisée ou affiche une alerte bloquante.

Il existe trois niveaux de validation, chacun répondant à des besoins différents :

Pour la grande majorité des sites, un certificat DV est suffisant : il chiffre les données sans vérifier l’identité du propriétaire. Un certificat OV ou EV est recommandé dès lors que le site collecte des informations confidentielles ou financières, car le niveau de validation étendue est présenté comme optimal pour ces contextes.

Let’s Encrypt est une autorité de certification gratuite, automatisée et reconnue par tous les navigateurs modernes. Elle délivre des certificats DV valables 90 jours, renouvelables automatiquement via l’outil certbot. La quasi-totalité des hébergeurs mutualisés intègrent aujourd’hui Let’s Encrypt en un clic. C’est la solution à privilégier pour les budgets serrés ou les projets à fort volume de sous-domaines.

Les certificats payants (DigiCert, Sectigo, GlobalSign…) apportent une garantie financière, un support dédié et des options wildcard ou multi-domaines plus flexibles. Leur durée de validité peut atteindre un an. Pour un site e-commerce traitant des paiements, l’investissement est justifié.

Pour obtenir un certificat, le processus standard comprend :

• Générer une CSR (certificate signing request) sur le serveur, contenant le nom de domaine et la clé publique.
• Soumettre la CSR à l’autorité de certification choisie.
• Valider la propriété du domaine (via un enregistrement DNS, un fichier placé sur le serveur ou un e-mail à l’adresse du domaine).
• Télécharger le certificat et la chaîne intermédiaire fournis par la CA.

Avant toute manipulation, effectuer une sauvegarde complète du site (fichiers et base de données) est indispensable. Si quelque chose tourne mal lors de la configuration, cette sauvegarde permet de revenir à l’état initial sans perte de données.

Avec le certificat en main, l’étape suivante consiste à l’installer côté serveur et à activer HTTPS dans l’application.

Installer le certificat et activer https côté serveur et application

L’installation d’un certificat TLS implique de placer les bons fichiers au bon endroit sur le serveur, puis de configurer le logiciel web pour écouter sur le port 443 (HTTPS) et présenter ce certificat aux navigateurs. La procédure varie selon l’environnement : serveur dédié/VPS sous Apache ou Nginx, hébergement mutualisé avec panneau de contrôle, CDN en frontal, ou CMS comme WordPress.

Sur Apache, la configuration minimale d’un virtual host HTTPS ressemble à ceci :

ServerName example.com SSLEngine on SSLCertificateFile /etc/ssl/certs/example.com.crt SSLCertificateKeyFile /etc/ssl/private/example.com.key SSLCertificateChainFile /etc/ssl/certs/ca-bundle.crt DocumentRoot /var/www/html

Il faut activer le module mod_ssl (a2enmod ssl) et redémarrer Apache. La chaîne de certificats intermédiaires doit impérativement être incluse via SSLCertificateChainFile ; son absence provoque des erreurs sur certains navigateurs et appareils mobiles.

Sur Nginx, la configuration équivalente :

Il est recommandé de désactiver les protocoles obsolètes (SSLv3, TLS 1.0, TLS 1.1) et de restreindre les suites de chiffrement pour obtenir un score de sécurité élevé. L’outil SSL Labs permet de tester la configuration et d’identifier les failles.

Avec Let’s Encrypt et Certbot, sur un serveur Ubuntu avec Nginx :

sudo certbot –nginx -d example.com -d www.example.com

Certbot modifie automatiquement la configuration Nginx, installe le certificat et programme un renouvellement automatique via cron ou systemd. Le renouvellement tous les 90 jours est géré sans intervention manuelle, ce qui élimine le risque d’expiration oubliée — une cause fréquente d’alertes de sécurité en production.

Sur un hébergement mutualisé, l’activation se fait généralement depuis le panneau de contrôle (cPanel, Plesk) en quelques clics, sans accès SSH. L’hébergeur installe et renouvelle souvent le certificat automatiquement.

Avec un CDN (Cloudflare, Fastly, AWS CloudFront), le certificat peut être géré au niveau du CDN, qui termine la connexion TLS en frontal. Dans ce cas, la connexion entre le CDN et le serveur d’origine doit également être sécurisée pour éviter une zone de vulnérabilité en backend. Cloudflare propose le mode « Full (strict) » qui exige un certificat valide sur le serveur d’origine.

Sur WordPress, après activation du certificat côté serveur, il faut mettre à jour l’URL du site dans Réglages > Général en remplaçant http:// par https://. Des extensions comme Really Simple SSL automatisent cette étape et gèrent les redirections de base, mais elles ne remplacent pas une configuration serveur correcte.

Une fois HTTPS actif et validé (accès direct à https://example.com sans erreur), l’étape critique suivante est de forcer tout le trafic HTTP vers HTTPS sans créer de boucles ni de chaînes de redirection.

Rediriger tout le trafic de http vers https sans casser le site

La redirection 301 (moved permanently) est le mécanisme standard pour signaler aux navigateurs et aux moteurs de recherche que l’URL a changé de façon permanente. Elle transfère la majorité du « link equity » (autorité de lien) vers la nouvelle URL, ce qui est essentiel pour préserver le SEO. Une redirection 302 (temporaire) ne doit pas être utilisée ici : elle ne transfère pas l’autorité et peut désorienter Googlebot.

Règles de redirection sur Apache (.htaccess) :

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

Cette règle redirige toutes les requêtes HTTP vers leur équivalent HTTPS, en conservant le chemin et les paramètres. Elle doit être placée en tête du fichier .htaccess, avant d’autres règles de réécriture, pour éviter les conflits.

Sur Nginx, la méthode recommandée est un bloc server dédié au port 80 :

server { listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri; }

Attention à ne pas utiliser rewrite ^ https://… permanent; dans Nginx : cette syntaxe est moins performante et peut créer des problèmes avec certains chemins.

La gestion www/non-www doit être résolue simultanément. Il faut choisir une forme canonique (avec ou sans www) et rediriger l’autre systématiquement. Exemple pour canonicaliser sur https://example.com (sans www) :

server { listen 80; server_name www.example.com example.com; return 301 https://example.com$request_uri; } server { listen 443 ssl; server_name www.example.com; return 301 https://example.com$request_uri; }

Deux pièges classiques à éviter absolument :

• Les boucles de redirection : elles surviennent quand une règle HTTP → HTTPS renvoie vers HTTP, souvent à cause d’un CDN ou d’un proxy qui transmet la requête en HTTP en interne alors que la règle .htaccess détecte HTTP et redirige à nouveau. La solution est d’inspecter l’en-tête X-Forwarded-Proto plutôt que HTTPS dans ce contexte.
• Les chaînes de redirection : http://www → http:// → https:// en trois sauts au lieu d’un seul. Chaque saut ajoute de la latence et dilue le transfert d’autorité. Toutes les variantes (http/www, http/non-www, https/www) doivent pointer directement vers la version canonique finale en une seule redirection 301.

Sur WordPress, la mise à jour de l’URL dans les réglages génère automatiquement des redirections, mais il est préférable de les implémenter aussi au niveau serveur pour éviter que PHP soit chargé inutilement pour chaque requête HTTP entrante.

Les redirections en place, le trafic arrive bien sur HTTPS — mais les pages elles-mêmes peuvent encore contenir des ressources chargées en HTTP, ce qu’on appelle le contenu mixte.

Corriger le contenu mixte et mettre à jour toutes les urls internes

Le contenu mixte (mixed content) désigne toute ressource chargée en HTTP sur une page servie en HTTPS. Les navigateurs modernes bloquent ou signalent ces ressources, ce qui peut casser l’affichage, désactiver des fonctionnalités JavaScript ou afficher un cadenas barré dans la barre d’adresse — annulant visuellement le bénéfice de la migration.

Il existe deux catégories :

• Contenu mixte passif : images, vidéos, fichiers audio chargés en HTTP. Le navigateur les affiche avec un avertissement mais ne les bloque pas toujours.
• Contenu mixte actif : scripts JavaScript, feuilles de style CSS, iframes, XMLHttpRequest. Ces ressources sont bloquées par défaut dans Chrome et Firefox car elles peuvent modifier le DOM et compromettre la sécurité de la page entière.

Comment détecter le contenu mixte ?

• La console développeur du navigateur (onglet Console et onglet Network) liste toutes les ressources bloquées ou en avertissement.
• L’extension « Why No Padlock ? » ou des outils en ligne comme SSL Checker effectuent une analyse automatique page par page.
• Un crawl complet avec Screaming Frog (en mode HTTPS) identifie les URLs internes encore en HTTP dans le code source.

Correction dans la base de données WordPress : la majorité des URLs en dur sont stockées en base. Le plugin Search & Replace ou la commande WP-CLI permettent de remplacer en masse :

wp search-replace ‘http://example.com’ ‘https://example.com’ –skip-columns=guid

L’option –skip-columns=guid préserve les GUIDs des articles, évitant des problèmes de synchronisation avec les flux RSS.

Pour les ressources externes (CDN, polices Google Fonts, scripts tiers, APIs), vérifier que chaque appel utilise https:// ou un chemin relatif au protocole (//cdn.example.com/script.js). Si un service tiers ne propose pas HTTPS, il faut envisager de l’héberger localement ou de le remplacer.

Canonicals et balises hreflang : toutes les balises doivent pointer vers la version HTTPS. Une canonical en HTTP sur une page HTTPS envoie un signal contradictoire à Google et peut provoquer une indexation de la mauvaise version.

Les balises hreflang pour les sites multilingues doivent également être mises à jour vers HTTPS dans toutes leurs occurrences. Les données structurées (schema.org) contenant des URLs absolues sont aussi concernées.

Les liens internes dans le contenu éditorial (articles, pages, menus de navigation) doivent être mis à jour. Sur un site statique, un simple find & replace dans les fichiers HTML suffit. Sur un CMS, la commande WP-CLI ou un plugin de remplacement en base de données est plus fiable.

Une fois le contenu mixte éliminé et toutes les URLs internes en HTTPS, il est temps de s’assurer que les outils de mesure et le SEO sont correctement configurés pour la nouvelle version du site.

Préserver le seo et la mesure: search console, analytics, sitemap et canonical

Google traite http://example.com et https://example.com comme deux sites distincts. Sans actions explicites, le moteur peut continuer à indexer les URLs HTTP (via des liens externes non redirigés), diviser l’autorité entre les deux versions et perdre temporairement des positions. La fenêtre de récupération dépend de la qualité de la migration.

Google Search Console : il faut ajouter la propriété HTTPS comme nouvelle propriété et la vérifier (via balise HTML, DNS ou Google Analytics). La propriété HTTP existante reste utile pour surveiller les erreurs résiduelles et les liens entrants encore en HTTP. Dans la nouvelle propriété HTTPS :

• Soumettre le sitemap XML mis à jour, contenant exclusivement des URLs en HTTPS.
• Vérifier les paramètres d’URL si des règles de normalisation étaient configurées.
• Surveiller le rapport de couverture d’index pour détecter toute URL HTTP encore indexée ou toute erreur 404 générée par la migration.

Le sitemap XML doit être régénéré pour ne contenir que des URLs HTTPS. Sur WordPress, les plugins SEO (Yoast, Rank Math) le font automatiquement après la mise à jour de l’URL du site. Pour un site statique, il faut régénérer le sitemap manuellement ou via le script de génération.

Le fichier robots.txt doit également référencer la version HTTPS du sitemap :

Sitemap: https://example.com/sitemap.xml

Si le robots.txt contient des règles pointant vers des URLs absolues en HTTP, les mettre à jour pour éviter toute ambiguïté.

Google Analytics : dans les propriétés Universal Analytics ou GA4, mettre à jour l’URL par défaut du site vers HTTPS. Sans cette modification, les rapports d’acquisition peuvent afficher des sessions en « direct » au lieu de leur source réelle, car le passage de HTTPS vers HTTP supprime le referrer. Les campagnes UTM dans les liens existants (newsletters, réseaux sociaux) ne sont pas affectées par la migration si les redirections 301 sont en place, mais il est prudent de mettre à jour les liens trackés vers HTTPS directement.

Les backlinks externes : les liens provenant d’autres sites en HTTP seront redirigés via les 301 en place. Le transfert d’autorité est effectif mais légèrement dilué à chaque saut. Il est utile de contacter les partenaires principaux pour leur demander de mettre à jour leurs liens vers HTTPS, surtout pour les domaines à fort trafic référent.

Surveiller l’indexation dans les semaines suivant la migration : utiliser la commande site:example.com dans Google pour vérifier que les URLs indexées sont bien en HTTPS. Un pic d’URLs HTTP encore indexées indique que les redirections ne sont pas correctement appliquées ou que des liens internes en HTTP subsistent.

Avec le SEO et la mesure sécurisés, la dernière étape est de valider l’ensemble de la migration avec une checklist rigoureuse et d’activer les mécanismes de sécurité avancés comme HSTS.

Tester, sécuriser et monitorer après migration: checklist et pièges à éviter

La migration est techniquement terminée, mais elle n’est validée qu’après une batterie de tests systématiques. Voici la checklist de validation à parcourir avant de considérer le projet clos :

• Certificat TLS valide : accéder à https://example.com depuis plusieurs navigateurs (Chrome, Firefox, Safari, mobile). Aucune alerte de sécurité ne doit apparaître. Vérifier la date d’expiration et le renouvellement automatique.
• Redirections 301 fonctionnelles : tester avec curl -I http://example.com et curl -I http://www.example.com. La réponse doit être un 301 direct vers https://example.com en un seul saut.
• Absence de contenu mixte : ouvrir la console navigateur sur les pages principales (accueil, article, page de contact, tunnel de conversion). Aucune erreur mixed content ne doit apparaître.
• Codes HTTP corrects : les pages HTTPS doivent retourner 200. Vérifier l’absence de 404 générés par la migration avec un crawl Screaming Frog ou un rapport Search Console.
• Canonicals corrects : inspecter le code source des pages principales et vérifier que les balises canonical pointent vers HTTPS.
• Sitemap soumis : confirmer la soumission dans Google Search Console propriété HTTPS et vérifier que toutes les URLs du sitemap retournent 200.
• Analytics fonctionnel : vérifier en temps réel dans Google Analytics que les sessions sont bien enregistrées après navigation sur le site HTTPS.
• Performance : mesurer le temps de chargement avant/après avec PageSpeed Insights ou WebPageTest. TLS ajoute une légère latence (handshake), compensée par HTTP/2 qui n’est disponible que sur HTTPS.

Activer HSTS (HTTP Strict Transport Security) est l’étape de sécurisation finale. Cet en-tête HTTP indique aux navigateurs de ne jamais tenter de connexion HTTP sur le domaine, même si l’utilisateur tape http:// manuellement. Il élimine le risque d’attaque de downgrade.

Configuration Apache :

Header always set Strict-Transport-Security « max-age=31536000; includeSubDomains »

Configuration Nginx :

add_header Strict-Transport-Security « max-age=31536000; includeSubDomains » always;

HSTS doit être activé uniquement après avoir validé que tout fonctionne parfaitement. Une fois l’en-tête envoyé avec un max-age élevé, les navigateurs qui l’ont reçu refuseront toute connexion HTTP pendant la durée spécifiée — impossible à annuler côté serveur pour ces visiteurs. Commencer avec max-age=300 (5 minutes) pour tester, puis augmenter progressivement.

La directive preload permet d’inscrire le domaine dans la liste de préchargement HSTS des navigateurs (hstspreload.org), offrant une protection dès la première visite. C’est irréversible à court terme : ne l’activer que sur un domaine définitivement en HTTPS.

Erreurs fréquentes à éviter après migration :

• Certificat incomplet : oublier la chaîne intermédiaire provoque des erreurs sur Android et certains navigateurs d’entreprise.
• Blocage dans robots.txt : une règle Disallow: / accidentellement activée en production pendant la migration peut désindexer l’ensemble du site en quelques jours.
• Chaînes de redirection non résolues : vérifier avec un outil de trace de redirections (Redirect Checker) que chaque URL HTTP aboutit en un seul 301.
• Renouvellement automatique non configuré : un certificat Let’s Encrypt expiré affiche une erreur bloquante pour tous les visiteurs. Vérifier le cron ou le timer systemd de certbot.
• Propriété Search Console non vérifiée : sans propriété HTTPS vérifiée, les alertes de Google (pénalités manuelles, problèmes d’indexation) ne sont pas reçues.

Monitoring continu : mettre en place une alerte d’expiration de certificat (UptimeRobot, Better Uptime ou un script cron) et surveiller les rapports Search Console hebdomadairement pendant les deux mois suivant la migration. Les fluctuations de positions sont normales dans les premières semaines ; elles se stabilisent généralement une fois que Google a recrawlé et réindexé les URLs HTTPS.

FAQ

Comment transformer HTTP en HTTPS ?

Il faut obtenir un certificat TLS auprès d’une autorité de certification (Let’s Encrypt pour une option gratuite), l’installer sur le serveur, configurer l’écoute sur le port 443, mettre en place des redirections 301 de HTTP vers HTTPS, corriger le contenu mixte et mettre à jour toutes les URLs internes, les canonicals et le sitemap XML.

Comment HTTP se transforme-t-il en HTTPS ?

HTTP devient HTTPS lorsque le serveur est configuré pour utiliser le protocole TLS : un certificat numérique est présenté au navigateur lors de la connexion, une poignée de main (handshake) TLS chiffre la session, et toutes les données échangées sont chiffrées et authentifiées. Du côté de l’URL, le préfixe http:// est remplacé par https:// et un cadenas apparaît dans la barre d’adresse.

Comment activer le mode HTTPS ?

Après installation du certificat TLS, activer HTTPS revient à configurer un virtual host sur le port 443 (Apache ou Nginx), à activer le module SSL, à spécifier les fichiers de certificat et de clé privée, puis à tester la configuration. Sur WordPress, mettre à jour l’URL du site dans les réglages. Sur un hébergement mutualisé, l’activation se fait depuis le panneau de contrôle. Vérifier ensuite l’absence d’erreur dans le navigateur et de contenu mixte.

Comment rediriger HTTP vers HTTPS ?

Sur Apache, ajouter dans le fichier .htaccess une règle RewriteRule avec la condition %{HTTPS} off et le flag R=301. Sur Nginx, créer un bloc server écoutant sur le port 80 avec un return 301 https://…. La redirection doit être permanente (301), directe (un seul saut), et couvrir toutes les variantes (www/non-www, HTTP/HTTPS) pour éviter les chaînes de redirection qui nuisent aux performances et au SEO.

La migration HTTP → HTTPS est un projet technique qui se joue sur les détails : un certificat incomplet, une chaîne de redirection oubliée ou un canonical en HTTP suffisent à annuler des semaines de travail SEO. Traiter chaque étape dans l’ordre, tester méthodiquement avec la checklist et monitorer l’indexation pendant les semaines suivantes garantit une transition sans perte de trafic ni de sécurité.