Formulaire Webflow : ce que fait la plateforme contre le spam

Où va l’envoi d’un formulaire Webflow ?

D’après l’aide de Webflow, vous choisissez, formulaire par formulaire, où part l’envoi :

• chez Webflow, qui le conserve dans les réglages du site, rubrique « Forms » ;
• dans un courriel de notification ;
• vers un webhook (une adresse extérieure) ou une application connectée ;
• vers une action personnalisée : le formulaire envoie directement à une adresse que vous donnez, sans passer par Webflow.

Avec le filtrage du spam actif, Webflow met à part les envois qu’il juge indésirables. L’action personnalisée ne se combine ni avec la conservation chez Webflow ni avec les notifications. Cet article ne dit de Webflow que ce que son aide publique dit ; ces pages et leurs menus changent : vérifiez dans votre compte. L’aide conseille aussi de mettre dans le message d’erreur du formulaire un moyen de vous joindre, une adresse e-mail par exemple.

Que propose Webflow contre le spam ?

L’aide range les moyens en quatre méthodes :

• Le champ reCAPTCHA : un élément du formulaire qui demande au visiteur de se déclarer humain. L’aide reconnaît qu’il peut nuire à l’expérience des visiteurs et être contourné par des robots plus évolués.
• Le blocage des robots : un réglage du site, pour tous les formulaires. Selon l’aide, il analyse les mouvements de souris, les saisies et d’autres signaux pour bloquer les envois des robots ; le bouton d’envoi reste désactivé pendant que la protection charge.
• Le filtrage du spam : un autre réglage du site, qui examine les données envoyées pour écarter les envois indésirables.
• Le champ piège (honeypot) : un champ caché, avec du code de votre côté pour écarter les envois où il est rempli.

Les deux réglages se trouvent dans « Site settings », rubrique « Apps & Integrations » ; l’aide donne l’intitulé exact de l’entrée. Aucune page lue ne donne de chiffre d’efficacité : l’effet sur votre formulaire se constate sur vos propres envois.

Que demande le champ reCAPTCHA de Webflow ?

D’après l’aide, le champ se pose dans un formulaire ; elle décrit la version à case à cocher. Vous enregistrez votre site chez le fournisseur du service, qui remet une clé de site et une clé secrète, à coller dans les réglages du site. Avant d’activer :

• l’activation vaut pour tout le site : un formulaire sans champ reCAPTCHA ne peut plus être envoyé, dès l’enregistrement du réglage, même sans republier. Ajoutez d’abord le champ à chaque formulaire ;
• avec une action personnalisée, ou sur un site exporté, l’intégration native ne fonctionne pas comme prévu : la vérification est à brancher vous-même, selon le guide du fournisseur.

Le champ demande un geste au visiteur : lisez l’article sur l’accessibilité des CAPTCHA avant d’en faire votre méthode principale.

Voir : CAPTCHA et accessibilité : ce que disent les WCAG et le W3C · Remplacer reCAPTCHA : ce qu’il faut vérifier avant de changer

Comment poser le champ piège sans gêner un lecteur d’écran ?

L’aide décrit la technique avec un exemple de code. Ses précautions :

• un nom de classe sans « hidden » (« caché ») et des noms de champ réalistes ;
• le champ caché par la position, l’opacité ou display:none : l’aide prévient que certains robots reconnaissent ces moyens, et que la structure devra peut-être changer à mesure que les robots apprennent ;
• tabindex="-1" sur le champ et aria-hidden="true" sur son libellé, pour qu’on ne l’atteigne pas au clavier et qu’un lecteur d’écran ne le lise pas.

Le code de l’exemple désactive le bouton d’envoi dès que le champ reçoit une saisie. Il s’exécute dans la page : un programme qui envoie le formulaire sans la charger ne le déclenche pas (raisonnement sur l’exemple, non vérifié sur un site Webflow).

Voir : Glossaire : honeypot · Spam sur un formulaire de contact : que faire, mesure par mesure

Que ne permet pas un formulaire Webflow natif ?

Valider les champs, limiter les rafales, vérifier un jeton : ces défenses se font sur votre serveur. Avec un formulaire natif, l’envoi part chez Webflow, pas chez vous, et dans les pages d’aide lues aucun réglage ne fait appeler votre serveur avant que Webflow l’accepte. Le webhook et l’application connectée y ressemblent :

• le webhook envoie les envois à une adresse extérieure, avec une clé secrète pour vérifier la signature des messages ;
• l’application connectée les envoie à un service tiers, en plus de Webflow.

L’aide ne dit pas qu’ils permettent de refuser un envoi avant que Webflow le conserve : non vérifié. Sur un formulaire natif, un jeton posé par un script dans la page n’est donc lu par personne chez vous à l’envoi ; vous ne pouvez trier qu’après coup.

Et si vous avez un serveur à vous ?

L’aide prévoit l’autre route : l’action personnalisée. Dans les réglages du formulaire, vous retirez les destinations Webflow et notifications, choisissez « Custom action », donnez l’adresse de votre serveur et la méthode, POST ou GET. C’est alors votre code qui reçoit l’envoi : il peut le valider, vérifier un jeton, limiter les rafales et décider quoi répondre. Ce que vous perdez, d’après l’aide :

• l’envoi n’est plus conservé chez Webflow : plus de liste dans « Forms », plus de boîte à spam ;
• les notifications par courriel de Webflow s’arrêtent ;
• l’intégration reCAPTCHA native ne fonctionne plus comme prévu.

Vous entretenez alors ce serveur, ses clés et ses secrets : un vrai coût pour un site vitrine. Les mesures à y mettre sont celles de l’article sur le spam du formulaire de contact.

Voir : Spam sur un formulaire de contact : que faire, mesure par mesure

Où Antisy se place

Antisy est un contrôle anti-bot invisible (on parle parfois de « CAPTCHA invisible »), pour les formulaires. Une balise dans la page charge le script ; à l’envoi, il met un jeton court dans le champ caché antisy-token ; votre serveur envoie ce jeton à Antisy avec son secret et lit la réponse, allow ou deny. Il n’y a que ces deux résultats, et la réponse n’en donne jamais la raison.

Sur un formulaire Webflow : Antisy n’a ni intégration native à Webflow ni extension, et l’appel se fait depuis un serveur à vous. Avec un formulaire natif, dont l’envoi part chez Webflow, aucun serveur à vous ne reçoit l’envoi : Antisy ne le protège pas. Avec une action personnalisée, votre serveur peut faire l’appel et refuser l’envoi sur deny ; vous renoncez alors à ce que Webflow fait des envois. Le script n’a pas été essayé sur une page Webflow : non vérifié.

L’accès se fait sur liste d’attente : n’attendez pas Antisy pour agir. Antisy ne distingue pas le démarchage tapé à la main, n’annonce aucun taux de détection, et refuse un appareil très lent qui n’achève pas son calcul à temps. Il s’ajoute aux méthodes ci-dessus, il ne les remplace pas.

Voir : Cas d’usage : protéger un formulaire de contact · Documentation : quels formulaires le script couvre · Glossaire : CAPTCHA invisible · Questions fréquentes : quelle différence entre Antisy et un CAPTCHA ? · Les guides d’intégration

Où en est Antisy ?

L’accès se fait sur liste d’attente. L’API et le tableau de bord sont en service depuis le 27 octobre 2026, hébergés chez Infomaniak à Genève ; aucun client n’est encore en production. Le pilote a commencé le 9 novembre 2026 sur nos propres formulaires.

Voir : Le pilote · Rejoindre la liste d’attente

Questions fréquentes