Lundi matin. Un client vous écrit pour savoir si sa commande de samedi est bien passée, parce qu'il n'a rien reçu. Vous ouvrez le back-office et elle est là, payée. Celle de dimanche aussi, et toutes celles de la semaine. Votre boutique vend, mais depuis votre passage à PrestaShop 9, pas un seul e-mail n'est arrivé à qui que ce soit.
Si vous envoyez avec votre propre serveur de messagerie —celui d'OVH, Microsoft 365, Gmail ou celui de votre hébergeur— sur le port 587, vous n'avez rien mal configuré. C'est un bug de PrestaShop 9, présent dans toutes les versions de la 9.0.0 à la 9.1.5, et il n'a été corrigé que dans la 9.2, publiée le 30 septembre 2026.
Allez dans Paramètres avancés → Logs. Si chaque commande y a laissé une ligne de ce genre, c'est votre cas :
Mailer Error: Connection could not be
established with host
"ssl://ssl0.ovh.net:587":
stream_socket_client(): SSL operation
failed with code 1. OpenSSL Error
messages: error:0A00010B:SSL
routines::wrong version numberLe nom du serveur sera le vôtre. Ce qui trahit le bug, c'est le ssl:// devant et le :587 derrière. Vous obtenez le même message immédiatement en cliquant sur « Envoyer un e-mail test » dans Paramètres avancés → E-mail.
Le piège, c'est tout ce qui ne se passe pas. Le client ne voit aucune erreur, la commande est enregistrée et le paiement passe. C'est pour ça qu'on met des jours à s'en rendre compte, et c'est presque toujours un client qui vous prévient, en réclamant sa facture ou son numéro de suivi.
Il existe deux façons de chiffrer la conversation avec un serveur de messagerie. Dans l'une, tout est chiffré dès la première seconde : c'est ce qu'attend le port 465. Dans l'autre, on se salue d'abord en clair, puis on demande à passer à une conversation chiffrée : c'est le port 587. Ce sont deux portes différentes, et chacune attend qu'on frappe à sa manière.
Jusqu'à PrestaShop 8, l'option « TLS » du back-office frappait à la porte du 587 comme cette porte l'attend. PrestaShop 9 a changé la brique qui envoie les e-mails (de SwiftMailer à Symfony Mailer) et, au passage, ce que fait cette option : « TLS » chiffre désormais dès la première seconde. Elle frappe au 587 comme si c'était le 465, le serveur répond par un bonjour en clair et PrestaShop, qui attendait une réponse chiffrée, n'y comprend rien. C'est ça, le « wrong version number ».
Voilà pourquoi tout casse au moment de passer de la 8 à la 9 : les mêmes réglages qui fonctionnaient cessent de fonctionner sans que vous ayez touché à quoi que ce soit. Et voilà pourquoi l'option « SSL » d'avant a disparu : dans PrestaShop 9, la liste de chiffrement ne propose plus que « Aucun » et « TLS ».
Cela se change dans Paramètres avancés → E-mail, avec « Utiliser mes propres paramètres SMTP » coché. Ce qu'il faut mettre dépend des ports qu'accepte votre fournisseur, et nous l'avons vérifié un par un sur les serveurs de onze fournisseurs :
ssl0.ovh.net), Gmail, IONOS, Brevo ou Mailjet— : chiffrement TLS et port 465. C'est ainsi qu'est configurée notre propre boutique, qui tourne sous PrestaShop 9.smtp.office365.com), Email Pro d'OVH (pro1, pro2 ou pro3.mail.ovh.net) et Exchange d'OVH— : chiffrement Aucun et port 587. Avec eux, en 9.0 et 9.1, « TLS » ne fonctionne sur aucun port.Nous savons que la deuxième option fait hésiter, parce qu'elle dit « Aucun ». Mais cela ne veut pas dire que votre mot de passe circule en clair. Avec cette option, PrestaShop 9 dit bonjour en clair et, dès que le serveur propose de chiffrer —tous ceux-là le proposent—, il chiffre la conversation avant d'envoyer l'identifiant et le mot de passe. Nous l'avons vérifié sur les serveurs de Microsoft 365 et d'OVH : la connexion est chiffrée (TLS 1.3 chez Microsoft, TLS 1.2 chez OVH) avant que la moindre donnée ne parte.
Enregistrez, envoyez l'e-mail test et, s'il arrive, c'est réglé : les commandes passées à partir de maintenant envoient leurs e-mails. Celles qui sont restées en route ne repartent pas toutes seules. Sur la fiche de chaque commande, dans l'historique des statuts, le bouton « Renvoyer l'e-mail » renvoie l'e-mail de ce statut, comme celui du paiement accepté ou de la commande expédiée.
Si vous aviez choisi « SSL » avec le port 465 dans PrestaShop 8, l'envoi continue de fonctionner après la mise à jour : PrestaShop 9 garde cette valeur et la traite comme son « TLS ». Le problème arrive le jour où vous ouvrez cette page et enregistrez, même pour modifier autre chose. Comme « SSL » n'est plus dans la liste, le back-office affiche « Aucun », et c'est ce qui est enregistré. Avec « Aucun » et le 465, la boutique attend une réponse qui ne vient jamais, et le log indique Connection to "…:465" timed out.
Nous l'avons reproduit sur notre boutique de test. Avant d'enregistrer quoi que ce soit sur cette page, vérifiez que le chiffrement affiche bien ce que vous voulez.
La 9.2 le corrige à la racine : « TLS » fonctionne de nouveau sur le 587, comme dans PrestaShop 8. C'est la modification 42197 du projet, qui clôt un ticket ouvert en août 2024. Elle n'est pas arrivée à temps pour la 9.1.5, la dernière de la série 9.1 : si vous êtes sur n'importe quelle 9.0 ou 9.1, vous avez le bug.
Ce que vous réglez aujourd'hui en suivant cet article reste valable après la mise à jour —« TLS » avec le 465 et « Aucun » avec le 587 envoient de la même façon en 9.2—, donc il n'y a rien à défaire. Réparez vos e-mails maintenant et mettez à jour quand cela vous arrange, sans vous presser : la 9.2 apporte de gros changements, comme le nouveau tunnel de commande sur une seule page, et vos modules de paiement et de livraison doivent être prêts. Une mise à jour de ce genre se teste d'abord sur une copie de la boutique.
Microsoft a annoncé qu'à la fin de décembre 2026, l'envoi depuis des applications avec identifiant et mot de passe sera désactivé par défaut, et c'est exactement ainsi qu'envoie PrestaShop. L'administrateur de votre compte Microsoft pourra le réactiver, et la date de suppression définitive sera annoncée au second semestre 2027. Si votre boutique dépend de Microsoft 365 pour ses e-mails, c'est le bon moment pour la passer sur un service d'envoi transactionnel comme Brevo ou Mailjet et ne plus avoir cette date en tête.
Le log vous dit où chercher. S'il indique Failed to authenticate, c'est l'identifiant ou le mot de passe : l'identifiant est toujours l'adresse complète, et chez Microsoft 365 la boîte doit avoir l'envoi SMTP authentifié activé. S'il indique timed out, soit ce port n'existe pas chez votre fournisseur —Microsoft 365 et Email Pro d'OVH n'ont pas de 465—, soit vous êtes tombé dans le piège de la liste, soit votre hébergeur bloque la sortie sur ce port.
Et si vous préférez que quelqu'un qui l'a déjà résolu y jette un œil, envoyez-nous le message du log et votre version de PrestaShop. Nous vous disons quoi mettre dans votre cas et, s'il y a autre chose derrière, nous le remettons en marche.
Une fois vos e-mails repartis, faites qu'ils vaillent la peine d'être ouverts : nous en parlions dans la confirmation de commande est la pire page de votre boutique.
Votre boutique affiche un faux « vérifiez que vous êtes humain » ? Quelqu'un y a glissé du code. Où il se cache dans…
Parfait depuis l'étranger, timeout depuis l'Espagne les jours de match. Ce n'est pas votre serveur : c'est une IP…
Un module, une application, un serveur qui vous donne du fil à retordre ou juste un avis. La première consultation ne coûte rien, et il en sort un devis ferme avec un prix et une date.
