Spam du formulaire de contact PrestaShop : pourquoi un antispam à mots interdits ne fonctionne pas
Deux façons de perdre du temps, et la seconde est pire
Dans la boîte qui reçoit les messages du formulaire de contact arrivent deux choses : les demandes des clients et les propositions non sollicitées, c'est-à-dire référencement, netlinking, développeurs à l'heure, invitations à investir dans les cryptomonnaies et, de temps en temps, une tentative de se faire donner les identifiants du back-office.
La première façon de perdre du temps, c'est de tout lire. La seconde, pire, c'est d'arrêter de lire : quand presque tout est du déchet, le bon message n'est plus regardé qu'en passant. Un contact perdu ne laisse pas d'erreur dans les logs, il laisse un client qui s'en va sans dire pourquoi.
Pourquoi une liste de mots interdits ne fonctionne pas
La défense la plus répandue est une liste de mots : si le message contient « SEO », « gratuit », « offre », on le jette. Cela fonctionne une semaine, puis vient l'addition, parce que les mots qui apparaissent dans le spam sont les mêmes que ceux qu'utilisent les clients. « J'ai vu que vous faites une promotion sur le coffret de tournevis, la livraison est-elle gratuite au-dessus de 49 euros même pour les îles ? », c'est un client sur le point d'acheter.
Le défaut n'est pas dans la liste, il est dans la méthode : un mot ne porte pas avec lui l'intention de celui qui l'a écrit. C'est vrai aussi dans l'autre sens, parce qu'un spam bien écrit ne contient aucun mot suspect. En augmentant la sévérité, on bloque plus de vrais clients ; en la baissant, on laisse passer plus de spam : aucun réglage ne résout le problème, parce que ce n'est pas le bon signal.
Pourquoi le captcha ne suffit pas
Le captcha résout un problème différent, et il le résout bien : il empêche un programme de remplir le formulaire des milliers de fois. Il n'empêche pas une personne d'envoyer une proposition commerciale, ni un programme capable de le résoudre de faire de même. Captcha, honeypot et limite d'envois par IP regardent comment le message est arrivé ; ici, le problème, c'est ce qui est écrit dedans.
Un modèle qui décide au lieu d'écrire
La réponse à la mode à « ce message est-il du spam ? » consiste à interroger un modèle de langage : on écrit un prompt et on espère que le texte renvoyé sera interprétable. Cela marche jusqu'au jour où le modèle répond « Je dirais que oui, même si ça dépend », et le code qui attendait OUI ou NON décide au hasard.
Il existe un type de modèle pensé pour le cas inverse : il ne génère pas de texte, il répond à des questions typées. Il renvoie un chiffre pour chacune : pour une question oui/non, la probabilité que la réponse soit oui ; pour une question à choix multiple, l'option choisie, la probabilité de chacune et un indice de confiance, c'est-à-dire à quel point ce choix est net par rapport aux autres. La fonction Antispam Jev de notre module de formulaires de contact est construite sur l'un de ces modèles, Jev de TypeSafe AI.
La différence pratique, c'est que la décision reste dans le code : le modèle dit à quel point il est sûr, et ce qu'on en fait est décidé par un seuil que le commerçant peut modifier. Pour chaque message, six questions partent en un seul appel, évaluées en parallèle : est-ce de la publicité non sollicitée, contient-il des liens suspects, est-ce du phishing, est-ce un modèle envoyé en masse, quel service devrait répondre, est-ce urgent.
Le point le plus important, c'est le troisième état. Au-dessus du seuil haut, on agit et le message part dans une file de messages suspects ; en dessous, on ne fait rien, il passe, et l'évaluation reste dans le journal ; entre les deux, là où le modèle hésite, il faut la confirmation d'un second signal. « Je ne sais pas » est une réponse utile, si le code est écrit pour l'écouter.
Ce que nous avons mesuré
Ces chiffres viennent d'un essai que nous avons fait sur une installation de développement de PrestaShop 9, pas d'un test indépendant : dix messages rédigés par nous en italien, six légitimes et quatre indésirables.
Les six légitimes avaient été choisis pour être difficiles : un client en colère qui demande un remboursement et menace de contester le paiement auprès de sa banque, un message entièrement en majuscules, un avec le lien vers le site de son entreprise, un très long et confus, un de deux mots en italien (« Vous livrez en Sicile ? ») et celui plein de « gratuit », « offre » et « promotion ». Les six sont passés, avec une probabilité de publicité non sollicitée restée à 2 % ou moins. Les quatre indésirables (proposition SEO, phishing avec lien raccourci, invitation à investir, modèle générique envoyé en masse) sont tous partis dans la file des suspects, entre 98 % et 99 %.
Les dix appels ont pris entre 535 et 663 millisecondes, avec une moyenne de 596 ms, en consommant environ 900 à 1 240 tokens par message. Avec la fonction désactivée, le même envoi a pris 95 ms : la demi-seconde en plus est le prix de l'évaluation, et on ne la paie que si on l'active.
L'essai qui nous intéressait le plus était un autre : nous avons fait pointer le module vers une adresse qui ne répond pas. Après 4 057 millisecondes, c'est-à-dire le délai d'attente configuré, le message a été remis normalement et l'erreur a été inscrite dans le journal. Même chose sans clé et avec une clé erronée.
Ce qu'il ne fait pas, volontairement
Il ne supprime rien. Le spam reconnu part dans une file que le commerçant ouvre, lit, et dont il peut récupérer un message en un clic, auquel cas la notification retenue est envoyée. Le visiteur voit de toute façon l'écran de confirmation : on n'explique pas à celui qui envoie du spam comment il a été filtré, et un client qui s'y retrouverait par erreur ne se voit pas rejeté.
Il ne passe pas outre les choix du commerçant : l'aiguillage choisit parmi les services réellement configurés dans le module et n'intervient que là où l'adresse générique aurait été utilisée auparavant. En dessous du seuil de confiance, c'est le destinataire par défaut qui reste.
Les limites, dites d'avance
Le texte du message est envoyé à un prestataire tiers aux États-Unis : c'est un transfert de données personnelles hors de l'Union européenne, qui doit figurer dans la politique de confidentialité de la boutique. C'est pour cela que la fonction est désactivée par défaut, que le panneau indique en toutes lettres ce qui sort et vers qui, que l'envoi de l'adresse e-mail de l'expéditeur est désactivé sauf choix explicite, et que le module fournit une phrase prête à coller dans la politique de confidentialité en cinq langues : un texte à adapter et à faire vérifier, pas un avis juridique.
Le service est récent et facturé à la consommation : quand le crédit est épuisé, il cesse de répondre, et les messages passent comme lors de n'importe quelle autre erreur. Et dix messages disent que, sur ces dix-là, le filtre ne s'est pas trompé, pas qu'il ne se trompera jamais : c'est pour cela qu'existe la file, et pour cela que chaque évaluation est enregistrée avec probabilité, confiance, temps et tokens.
Où la trouver
Antispam Jev est une fonction de notre module de formulaires de contact pour PrestaShop, pas un module à part : ceux qui l'utilisent déjà la trouvent dans la configuration, désactivée. Si le problème que vous reconnaissez est le second de cet article, le vrai message qui se perd au milieu des autres, c'est celui pour lequel elle a été créée.
