Comment configurer SSL et HTTPS sur PrestaShop

Dernière mise à jour : juin 2026.

Voici l’aspect d’une migration SSL qui prend souvent les propriétaires de boutiques PrestaShop au dépourvu : acheter le certificat, c’est la partie facile, les 10 %. Le certificat s’installe sur votre serveur en quelques minutes. Les 90 % restants — ceux qui cassent réellement les boutiques — se jouent dans PrestaShop, là où SSL est lié à la base de données, au réécriveur d’URL, au périmètre des cookies et à une option Activer le SSL sur toutes les pages à activer par étapes, qui peut vous bloquer hors de votre propre administration si vous la basculez dans le mauvais ordre. Ce guide traite précisément de ces 90 % : configurer correctement HTTPS spécifiquement sur PrestaShop, avec les vrais chemins du back-office, les clés de configuration exactes et la marche arrière à connaître quand quelque chose tourne mal.

Si vous voulez une vue d’ensemble plus large pour sécuriser une boutique — sécurité de l’administration, règles serveur, correctifs virtuels — ce point fait partie d’une liste plus complète ; commencez par la checklist de durcissement de la sécurité PrestaShop. Cet article reste volontairement centré sur SSL et HTTPS.

Pourquoi c’est non négociable pour une boutique PrestaShop

Vous savez probablement déjà que HTTPS chiffre la connexion. Voici pourquoi il est indispensable pour une boutique, en termes business très concrets :

• Les navigateurs font activement fuir vos clients lorsqu’une page est en HTTP. Chrome et Firefox signalent les pages en HTTP simple comme « Non sécurisé » dans la barre d’adresse — exactement au moment où un client s’apprête à saisir un numéro de carte. C’est un problème de conversion, pas seulement de sécurité.
• Les intégrations de paiement l’exigent. Les webhooks et les flux de redirection de Stripe, PayPal, Mollie et Adyen supposent des points de terminaison HTTPS. Un certificat à moitié configuré fait partie des raisons discrètes pour lesquelles un retour de paiement échoue sans bruit.
• C’est un signal de classement et une condition d’accès à HTTP/2. Google considère HTTPS comme un facteur de classement léger depuis 2014, et HTTP/2 — qui accélère réellement le chargement des pages grâce au multiplexage — n’est disponible qu’en HTTPS. La mesure qui sécurise votre boutique la rend donc aussi plus rapide.

Le bénéfice concret : une configuration correcte supprime l’avertissement du navigateur dans votre tunnel de commande, maintient vos retours de paiement fonctionnels et débloque gratuitement un niveau de performance supplémentaire. Une configuration à moitié faite — certificat présent, mais PrestaShop mal configuré — produit des alertes de contenu mixte et des mises en page cassées qui inspirent encore moins confiance qu’un simple HTTP.

Quel certificat acheter vraiment (alerte : probablement aucun)

Les certificats SSL existent en trois niveaux de validation. Le chiffrement est identique dans les trois cas — la différence de prix paie des formalités de validation, pas une sécurité plus forte.

Un certificat DV gratuit Let's Encrypt donne au navigateur du client exactement le même cadenas et le même chiffrement qu’un certificat EV à 500 EUR. Sauf si vous exploitez une activité B2B réglementée dont les acheteurs vérifient précisément les détails du certificat, prenez le DV gratuit et investissez plutôt cet argent dans votre boutique.

Étape 1 : Installer le certificat sur votre serveur

Cette étape se passe au niveau de l’hébergement, avant toute intervention de PrestaShop. Choisissez le chemin qui correspond à votre configuration.

• cPanel : ouvrez SSL/TLS Status et cliquez sur Run AutoSSL. L’outil émet et installe des certificats Let's Encrypt pour chaque domaine, puis les renouvelle automatiquement sur un cycle de 60 à 90 jours.
• Plesk : Websites & Domains → SSL/TLS Certificates → Install sous Let's Encrypt, puis cochez le renouvellement automatique.
• VPS / dédié (accès root) : installez Certbot. certbot --apache ou certbot --nginx obtient le certificat, modifie votre vhost et met en place une tâche cron ou un timer de renouvellement. C’est la voie la plus propre si vous contrôlez la machine.
• Cloudflare : l’offre gratuite termine SSL à la périphérie de Cloudflare. Détail critique ci-dessous — réglez le mode sur Full (Strict), jamais sur Flexible.

Un piège Cloudflare mérite d’être souligné, car il touche particulièrement les boutiques PrestaShop : en mode Flexible, le trajet visiteur-vers-Cloudflare est chiffré, mais le trajet Cloudflare-vers-votre-serveur reste en HTTP simple. Le cadenas semble correct, mais PrestaShop voit une requête HTTP, et ce décalage est la cause numéro un de la boucle de redirection décrite plus bas dans la section dépannage. Utilisez Full (Strict), qui exige un certificat sur votre origine (même un certificat Let's Encrypt gratuit) et chiffre les deux trajets.

Étape 2 : Activer SSL dans PrestaShop — dans le bon ordre

Une fois le certificat actif sur le serveur, PrestaShop doit encore être configuré pour l’utiliser. C’est l’étape qui bloque des utilisateurs hors de leur administration, donc avancez méthodiquement.

Allez dans Paramètres de la boutique → Général dans le back-office (PrestaShop 1.7, 8 et 9.x). Il y a deux interrupteurs, et l’ordre compte :

• Passez Activer le SSL sur Oui et enregistrez. PrestaShop servira alors les pages sensibles (connexion, tunnel de commande, compte client) en HTTPS, sans toucher au reste. Vérifiez que le back-office et un tunnel de commande se chargent encore.
• Seulement ensuite, passez Activer le SSL sur toutes les pages sur Oui. Cela force toutes les URL du front-office en HTTPS.

Pourquoi procéder en deux temps : si votre certificat ou votre configuration proxy présente une erreur subtile et que vous activez les deux options d’un coup, PrestaShop peut commencer à rediriger l’administration vers un point HTTPS cassé, et vous perdez l’accès à l’écran dont vous avez besoin pour annuler. Les activer une par une permet au premier interrupteur de révéler le problème tant que le back-office reste accessible.

Si vous vous êtes quand même bloqué dehors

Voici la procédure de récupération à retenir. Les deux options correspondent à deux lignes dans ps_configuration : PS_SSL_ENABLED et PS_SSL_ENABLED_EVERYWHERE. Ouvrez phpMyAdmin (ou le client de base de données de votre choix) et mettez les deux à 0 :

UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE');

(Remplacez ps_ par le préfixe réel de vos tables.) Cela désactive l’application forcée du SSL, rétablit l’accès à l’administration et vous laisse corriger le vrai problème — généralement l’en-tête proxy évoqué plus bas — avant de réessayer. Videz ensuite le cache (supprimez le contenu de var/cache/) pour que le changement soit pris en compte.

Définir correctement les URL de la boutique

Allez dans Paramètres de la boutique → Trafic & SEO → SEO & URL et utilisez le panneau Définir l’URL de la boutique en bas de cette page (en multiboutique, il s’agit de l’écran dédié aux URL des boutiques). Les champs Domaine de la boutique et Domaine SSL doivent être identiques — des noms d’hôte bruts comme yourstore.com, sans préfixe http:// ni https://, et sans barre oblique finale. PrestaShop ajoute lui-même le protocole selon les options SSL. Coller une URL complète dans ces champs est une cause classique d’adresses doublées comme https://https//yourstore.com.

Étape 3 : Rediriger tout le trafic HTTP vers HTTPS

Après avoir activé SSL dans PrestaShop, forcez la redirection avant que l’application ne fasse quoi que ce soit. Placez la règle près du début du fichier public .htaccess, après l’avoir testée en préproduction.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Activer SSL « sur toutes les pages » fait générer des liens HTTPS par PrestaShop, mais les anciens favoris, les backlinks et les adresses saisies manuellement arrivent encore en HTTP. Une seule adresse canonique en HTTPS — imposée par une redirection 301 — maintient les clients sur la version chiffrée et empêche les moteurs de recherche de traiter HTTP et HTTPS comme deux sites dupliqués.

Le piège propre à PrestaShop : PrestaShop possède son fichier .htaccess. Dès que quelqu’un clique sur Générer le fichier .htaccess dans Paramètres de la boutique → Trafic & SEO → SEO & URL, tout le fichier est réécrit et les règles de redirection ajoutées à la main disparaissent. La redirection elle-même, ainsi que la bonne manière d’ajouter des règles qui survivent à la régénération, relèvent de la configuration au niveau fichier — un sujet détaillé dans PrestaShop .htaccess : règles de sécurité et de performance. Les options plus propres, qui évitent entièrement le problème de régénération :

• Cloudflare : activez Always Use HTTPS dans SSL/TLS → Edge Certificates. La redirection se fait à la périphérie, avant même que la requête n’atteigne votre serveur — plus rapide, et insensible à la régénération de .htaccess.
• Nginx : un bloc server sur le port 80 qui exécute return 301 https://$host$request_uri; — une configuration que PrestaShop ne touche jamais.

Étape 4 : Traquer le contenu mixte (la partie qui casse les mises en page)

Le contenu mixte est le problème sur lequel vous passerez réellement du temps. Une page HTTPS qui charge une image, un script ou une feuille de style via http:// déclenche des avertissements dans le navigateur — et les navigateurs modernes bloquent purement et simplement les scripts mixtes, ce qui explique qu’une boutique puisse apparaître totalement sans style ou afficher un formulaire de paiement inerte juste après la migration.

Pour le trouver : ouvrez la boutique dans Chrome, appuyez sur F12, puis consultez l’onglet Console à la recherche de lignes du type « Mixed Content: the page at https://… requested an insecure resource http://… ». Chacune indique l’URL fautive.

Sur PrestaShop, le contenu mixte se concentre dans quelques endroits prévisibles :

• http:// codé en dur dans la base de données. Descriptions de produits, descriptions de catégories et pages CMS où quelqu’un a collé une URL d’image absolue en http://. C’est la source la plus fréquente.
• Ressources de modules. Des modules anciens ou mal écrits qui enregistrent CSS/JS avec une URL explicite en http:// au lieu d’utiliser $this->context->link ou les assistants de PrestaShop sensibles au protocole. Mettez le module à jour ou signalez-le à son développeur.
• Modèles d’e-mails. Images référencées en HTTP dans les e-mails transactionnels, modifiables dans Apparence → Thème d’e-mail.
• Fichiers du thème. URL CSS de background-image ou de polices codées en dur en http:// dans les feuilles de style d’un thème personnalisé.
• Intégrations tierces. Polices, outils d’analyse, vidéos ou widgets sociaux chargés en HTTP.

La recherche-remplacement en base de données

Pour les occurrences en base de données, exécutez des mises à jour ciblées après sauvegarde. Les champs les plus importants se trouvent dans ps_product_lang (description, description_short), ps_category_lang (description) et ps_cms_lang (content) :

UPDATE ps_product_lang SET description = REPLACE(description, 'http://yourstore.com', 'https://yourstore.com');

Répétez l’opération pour chaque champ et chaque table. La correction robuste à long terme consiste à utiliser désormais des URL relatives au protocole ou en HTTPS dans les contenus ; le plus propre reste de cesser complètement de coller des URL absolues avec domaine dans les descriptions. Faites toujours une sauvegarde de la base de données avant tout UPDATE en masse — il n’y a pas d’annulation.

Étape 5 : Reconfigurer les services externes qui vous croient encore en HTTP

Google traite http:// et https:// comme des propriétés distinctes ; une migration qui saute cette étape vous fait donc sortir discrètement de vos propres rapports. Vérifiez les points suivants :

• Google Search Console : ajoutez https://yourstore.com comme nouvelle propriété — elle n’hérite pas de l’historique de la propriété HTTP.
• Google Analytics / Merchant Center : mettez à jour l’URL de la propriété ou du site web en https:// ; une ancienne URL de flux HTTP dans Merchant Center peut entraîner le refus de produits.
• Sitemap : régénérez-le afin que chaque entrée soit en HTTPS. Si vous utilisez un module de sitemap, régénérez-le via le module plutôt qu’avec l’outil du cœur. Notre propre module de sitemap mypresta.rocks reprend automatiquement le protocole depuis vos réglages SSL ; une régénération après l’activation de SSL produit donc des URL HTTPS propres, sans modification manuelle — une chose de moins à retenir.
• Webhooks de paiement : mettez à jour les URL de notification dans les tableaux de bord de vos prestataires — PayPal IPN, point de terminaison webhook Stripe, webhook Mollie — vers https://. Un webhook resté en HTTP entraîne des échecs silencieux de changement de statut de commande.

Étape 6 : Vérifier, ne pas supposer

Parcourez cette checklist avant de considérer la migration terminée :

• La page d’accueil en HTTPS affiche un cadenas propre, sans avertissement.
• Pages produit, catégorie et CMS — la Console ne signale aucun contenu mixte.
• Un test complet du tunnel de commande aboutit en HTTPS, retour de paiement inclus.
• Toutes les pages du back-office se chargent en HTTPS.
• La saisie de http://yourstore.com redirige en 301 vers https://.
• Un seul hôte canonique — www ou sans www, mais pas les deux accessibles en parallèle.
• Lancez le test serveur gratuit SSL Labs server test (ssllabs.com/ssltest) ; visez un A ou A+.

Les trois pannes derrière la plupart des tickets « HTTPS a cassé ma boutique »

Boucle de redirection infinie

Le grand classique. Votre hébergeur ou Cloudflare termine SSL en amont et transmet la requête à PrestaShop comme du HTTP simple. PrestaShop voit du HTTP, redirige vers HTTPS, puis le proxy lui renvoie la requête en HTTP — indéfiniment. La solution consiste à faire confiance, côté PrestaShop, à l’en-tête X-Forwarded-Proto du proxy afin qu’il reconnaisse que la requête d’origine était en HTTPS. Sur Cloudflare spécifiquement, passer de Flexible à Full (Strict) résout directement le problème. Sur d’autres reverse proxies, vous devrez peut-être prendre en compte l’en-tête forwarded-proto au niveau du serveur web ou de .htaccess.

La boutique se charge sans style / le formulaire de paiement est inerte

Presque toujours du contenu mixte bloqué — une feuille de style ou un script que le navigateur a refusé de charger en HTTP sur une page HTTPS. Revenez à l’étape 4 : lisez la Console, trouvez la ressource http://, corrigez sa source.

Les images ont disparu après la migration

Il s’agit généralement d’images produit ou CMS avec des URL http:// codées en dur, ou d’un CDN d’images qui ne sert pas le HTTPS. La recherche-remplacement en base de données de l’étape 4 traite le premier cas ; pour le second, confirmez que votre CDN ou hébergeur d’images prend en charge HTTPS.

Une note pour aller plus loin

Une fois HTTPS propre et vérifié, l’étape suivante naturelle est HSTS (HTTP Strict Transport Security), qui indique aux navigateurs de refuser entièrement HTTP pour votre domaine. C’est puissant et légèrement dangereux — un max-age trop long sur un site mal configuré peut rendre le domaine inaccessible — donc cela relève plutôt du durcissement des en-têtes de sécurité que d’un ajout rapide dans cet article. Nous couvrons HSTS, les en-têtes de sécurité et les autres règles côté serveur dans le guide de sécurité et de performance .htaccess, et SSL s’inscrit dans une démarche plus large dans la checklist complète de durcissement. Si vous préférez d’abord une explication complète sans jargon, le guide en langage clair pour sécuriser votre boutique est une entrée en matière plus douce.

SSL sur PrestaShop n’est pas difficile, mais il ne pardonne ni l’ordre approximatif ni les particularités de la plateforme : activez les options une par une, connaissez la récupération via ps_configuration avant d’en avoir besoin, attendez-vous à trouver encore quelques URL http:// cachées en base de données, et vérifiez avec la Console plutôt qu’à l’œil. Faites cela, et le gain est immédiat — plus de « Non sécurisé » dans votre tunnel de commande, des retours de paiement qui s’exécutent et la vitesse de HTTP/2 gratuitement. Faites-en le projet de la semaine ; c’est l’un des après-midi les plus rentables que vous puissiez consacrer à votre boutique.

Questions fréquentes

J’ai activé SSL et maintenant le back-office redirige sans fin — comment récupérer l’accès ?

C’est la boucle de redirection, presque toujours causée par un proxy qui sert à PrestaShop une requête en HTTP simple alors que le trajet navigateur-vers-périphérie est en HTTPS. La récupération rapide consiste à désactiver l’application forcée dans la base de données : UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE'); (remplacez le préfixe de table), puis à vider le cache en supprimant le contenu de var/cache/. Cela rétablit l’accès à l’administration. Avant de réactiver SSL, corrigez la vraie cause — sur Cloudflare, passez de Flexible à Full (Strict) ; sur un autre reverse proxy, faites en sorte que PrestaShop prenne en compte l’en-tête X-Forwarded-Proto afin qu’il reconnaisse que la requête d’origine était en HTTPS.

Un certificat gratuit Let's Encrypt est-il vraiment aussi sûr qu’un certificat payant ?

Pour le chiffrement, oui — il est identique. Un certificat DV de Let's Encrypt donne au navigateur du visiteur le même cadenas et le même chiffrement TLS qu’un certificat EV à 500 EUR. Le prix des certificats OV et EV paie les formalités de validation (l’identité juridique de votre entreprise est vérifiée), pas une cryptographie plus forte, et les navigateurs ont supprimé la barre verte avec le nom de l’entreprise, qui était le seul avantage visible de l’EV. Sauf si vous exploitez une activité B2B réglementée dont les acheteurs vérifient précisément les détails du certificat, prenez le DV gratuit.

Ma boutique se charge sans style ou le formulaire de paiement est inerte après le passage à HTTPS — pourquoi ?

Presque toujours à cause de contenu mixte bloqué : une page HTTPS charge une feuille de style ou un script via http://, et les navigateurs modernes refusent de charger des scripts non sécurisés sur une page sécurisée. Ouvrez la boutique dans Chrome, appuyez sur F12, puis consultez l’onglet Console — chaque ligne « Mixed Content » indique l’URL http:// fautive. Les coupables habituels sont les liens absolus en http:// collés dans les contenus produit ou CMS (à corriger par recherche-remplacement en base de données après sauvegarde), les anciens modules qui enregistrent leurs ressources avec un protocole codé en dur, et les feuilles de style de thèmes personnalisés. Corrigez la source, pas le symptôme.

Pourquoi dois-je activer les deux options SSL une par une ?

Parce que l’ordre est votre filet de sécurité. Activer le SSL (PS_SSL_ENABLED) ne force HTTPS que sur les pages sensibles — connexion, tunnel de commande, compte client — donc si votre certificat ou votre proxy présente une erreur subtile, le problème apparaît alors que vous pouvez encore atteindre le back-office. Ce n’est qu’après avoir confirmé que l’administration et un tunnel de commande se chargent encore que vous activez Activer le SSL sur toutes les pages (PS_SSL_ENABLED_EVERYWHERE). Activez les deux d’un coup sur une configuration cassée, et PrestaShop peut commencer à rediriger l’administration vers un point HTTPS mort — en vous bloquant hors de l’écran précis dont vous avez besoin pour annuler.

Dois-je faire quelque chose dans Google Search Console après le passage à HTTPS ?

Oui. Google traite http:// et https:// comme des propriétés distinctes ; ajoutez donc https://yourstore.com comme nouvelle propriété — elle n’hérite pas de l’historique de la version HTTP. Mettez aussi à jour les URL dans Analytics et Merchant Center vers HTTPS (une ancienne URL de flux HTTP dans Merchant Center peut entraîner le refus de produits), régénérez votre sitemap afin que chaque entrée soit en HTTPS, et repointez les webhooks de paiement (PayPal IPN, Stripe, Mollie) vers le point de terminaison HTTPS. Un webhook resté en HTTP provoque des échecs silencieux de statut de commande.

Dois-je activer HSTS tout de suite ?

Pas comme première action. HSTS indique aux navigateurs de refuser entièrement HTTP pour votre domaine, ce qui est positif — mais un max-age trop long défini sur un site qui n’est pas parfaitement propre peut rendre le domaine inaccessible, et la directive est difficile à annuler parce que les navigateurs la mettent en cache. Validez d’abord HTTPS de bout en bout (Console propre, tunnel de commande fonctionnel, 301 depuis HTTP, note A/A+ au test SSL Labs), puis ajoutez HSTS avec le reste du durcissement de vos en-têtes de sécurité plutôt que pendant la migration elle-même.