Formulaire de contact serverless : ce que cela veut vraiment dire

« Serverless » est né comme un terme précis : votre code s'exécute sous forme de fonction, sur l'infrastructure de quelqu'un d'autre, et vous n'avez jamais à provisionner, corriger ou faire évoluer un serveur vous-même. Appliqué aux formulaires de contact, le terme a dérivé - il est désormais utilisé pour deux configurations vraiment différentes, et laquelle vous choisissez change la quantité de travail que vous acceptez d'assumer.

Voici la distinction, et où se situe un backend de formulaires hébergé dans tout ça.

Les deux choses que « formulaire de contact serverless » peut désigner

Cherchez cette expression et vous trouverez deux réponses différentes mélangées :

• Vous écrivez une fonction. Une AWS Lambda, un Cloudflare Worker, une fonction Vercel ou Netlify - un petit gestionnaire que vous déployez, qui reçoit le POST, envoie un e-mail via un fournisseur comme SES ou Resend, et renvoie une réponse.
• Vous n'écrivez aucun code backend. Votre formulaire envoie une requête POST directement vers un service hébergé qui existe déjà - aucune fonction à écrire, déployer ou versionner.

Les deux sont « serverless » au sens strict : aucun des deux n'implique une machine sur laquelle vous vous connectez en SSH pour la corriger. Mais ils se situent à des points très différents sur l'échelle de l'effort.

Option A : votre propre fonction

Écrire votre propre gestionnaire vous donne un contrôle total sur la charge utile, le modèle d'e-mail et la destination de stockage. Ce contrôle s'accompagne d'une véritable responsabilité :

• Les cold starts. Une fonction qui n'a pas tourné récemment met un moment à démarrer, ce qui se traduit par une première soumission lente sur les sites peu fréquentés.
• La délivrabilité des e-mails vous incombe. Enregistrements SPF, DKIM et DMARC, une réputation d'envoi à protéger, et un compte fournisseur à configurer et surveiller.
• Le filtrage anti-spam vous incombe. Rien n'empêche un bot d'envoyer un POST directement vers l'URL de votre fonction, sauf si vous construisez vous-même une limitation de débit, un honeypot ou un défi CAPTCHA.
• Le stockage vous incombe, si vous voulez le moindre historique. Sans appel à une base de données dans la fonction, une soumission dont l'envoi d'e-mail échoue disparaît tout simplement.

C'est le bon compromis quand le formulaire déclenche une vraie logique métier - écrire dans un CRM, lancer un workflow, tout ce qui dépasse « faire parvenir le message à un humain ». Pour un simple formulaire de contact, c'est beaucoup de plomberie indifférenciée à assumer.

Option B : aucun code backend

L'autre lecture de « serverless » élimine complètement la fonction. Votre <form> envoie un POST vers un point de terminaison qui existe déjà, géré par quelqu'un d'autre, où la réception, le filtrage anti-spam, les notifications et le stockage sont déjà construits et déjà en fonctionnement. Vous n'écrivez aucun code backend et ne déployez rien - il n'y a aucune fonction à vous à démarrer à froid, corriger ou surveiller, parce qu'il n'y a aucune fonction à vous dans le tableau.

Le compromis, c'est le contrôle : vous obtenez le filtre anti-spam du fournisseur, sa politique de rétention, ses canaux de notification - pas une logique sur mesure qui vous appartient. Pour un formulaire dont tout le travail consiste à « me faire parvenir la soumission de manière fiable », ce n'est presque jamais un coût réel.

Lequel convient vraiment à un formulaire de contact

La plupart des formulaires de contact n'ont pas besoin d'une logique de workflow sur mesure - ils doivent simplement atteindre un humain sans se perdre ni être filtrés comme spam. Si c'est là tout le travail, écrire et assumer une fonction revient à résoudre un problème que vous n'avez pas : vous passerez de vraies heures sur des enregistrements SPF et une logique de limitation de débit pour réinventer ce qu'un backend hébergé fait déjà. Optez pour votre propre fonction quand le formulaire alimente autre chose qu'une boîte de réception - une écriture en base de données, un workflow payant, un processus en plusieurs étapes qu'un service générique ne peut pas exprimer. (Pour le tableau plus large de ce que fait un backend de formulaires au quotidien, voir qu'est-ce qu'un backend de formulaires.)

Formhook : le point de terminaison qui existe déjà

Formhook est le second type de serverless. Pointez un formulaire vers https://formhook.app/f/{apiKey} et il n'y a rien à déployer, à démarrer à froid, ou à corriger - pas même une fonction. Le filtrage anti-spam (un champ honeypot, une limitation de débit, et une option Cloudflare Turnstile activable), le stockage, un tableau de bord consultable, et les notifications - e-mail plus notifications push sur tous les niveaux, y compris Gratuit - tournent déjà avant que vous n'écriviez la moindre ligne de code. Les webhooks sortants, avec détection automatique de Discord, Slack et Teams, couvrent les cas où vous voulez transmettre une soumission à un autre système, sans avoir non plus à écrire cette fonction réceptrice.

Le niveau Gratuit gère 250 soumissions par mois sans carte bancaire requise. Pro ajoute les téléversements de fichiers jusqu'à 10 Mo et un domaine d'envoi vérifié avec réponse directe ; Studio relève le plafond à 25 000 soumissions par mois pour les équipes. Consultez la documentation pour l'intégration elle-même, ou les tarifs pour le détail complet.

Vous utilisez un framework ? Retrouvez le guide pas à pas pour Next.js.