FormRoute par FNB Solutions : l'envoi des formulaires par e-mail à grande échelle
L'architecture de FormRoute, backend transactionnel pour formulaires de contact sur Amazon SES, isolé par site, qui remplace les outils d'e-mailing marketing.
Points clés
- FormRoute est un service transactionnel d'envoi des formulaires par e-mail conçu par FNB Solutions. Il reçoit les soumissions des formulaires de sites web et les achemine via Amazon SES.
- Chaque site est isolé : il dispose de sa propre identité d'envoi et de ses propres limites, si bien qu'un formulaire défaillant ne peut pas nuire à la délivrabilité d'un autre site.
- Aux volumes d'un formulaire, l'envoi ne coûte presque rien : Amazon SES facture 0,10 $ pour 1 000 e-mails (tarifs AWS). FormRoute achemine aujourd'hui environ 9 000 soumissions par mois pour plus de 40 sites.
- Il remplace les plateformes d'e-mailing marketing pour les formulaires de contact, dont les tarifs reposent sur des campagnes et des listes d'abonnés que les formulaires n'utilisent jamais. Le formulaire de contact de ce site fonctionne avec FormRoute.
Cet article décrit l'architecture et les contraintes de conception de FormRoute, le service d'envoi des formulaires par e-mail de FNB Solutions.
FormRoute répond à un problème précis : acheminer de façon fiable les soumissions de formulaires d'un site web jusqu'à une boîte de réception. Il est conçu pour des usages transactionnels comme les formulaires de contact, les demandes de renseignements et les inscriptions.
Contexte métier
Un formulaire de contact, c'est simple.
La plupart des sites reçoivent très peu de soumissions, souvent quelques-unes par jour seulement. Le besoin est clair : accepter une soumission et la livrer de façon fiable dans une boîte de réception.
Pourtant, l'envoi des formulaires repose généralement sur la plateforme d'e-mail déjà en place. Il s'agit souvent d'un service orienté marketing comme SendGrid ou Brevo, même quand aucune fonctionnalité marketing n'est nécessaire.
Avec le temps, cela crée une charge inutile. Ces plateformes sont construites autour des listes d'abonnés, des campagnes, des statistiques et de l'automatisation, dont aucune ne sert à l'envoi d'un simple formulaire. Résultat : un coût plus élevé, davantage de configuration à maintenir et une infrastructure partagée qui n'a pas été pensée pour cet usage.
Les comptes et les clés d'API partagés sont particulièrement courants dans les agences. C'est pratique, mais cela lie entre eux des sites qui n'ont rien à voir. Un seul formulaire mal configuré ou détourné peut dégrader la réputation d'envoi de tous les autres, sans qu'on sache facilement quel site est à l'origine du problème.
FormRoute traite directement ce cas d'usage précis. Il offre un chemin dédié entre la soumission du formulaire et l'envoi de l'e-mail, sans fonctionnalités marketing, sans réputation partagée et sans complexité superflue.
Le problème
La plupart des sites web n'ont pas besoin d'une plateforme d'e-mail complète. Ils ont besoin d'un moyen fiable de livrer les soumissions de formulaires dans une boîte de réception.
Les formulaires de contact et les points d'entrée similaires sont transactionnels et à faible volume. Ils sont pourtant souvent branchés sur des services d'e-mailing marketing conçus pour les campagnes, l'automatisation et la gestion d'abonnés.
En pratique, cela signifie souvent :
- Un seul compte SendGrid ou Brevo partagé
- Une même clé d'API réutilisée sur de nombreux sites
- Des domaines d'expédition et une réputation d'IP partagés
- Peu de contrôles contre les abus au niveau du formulaire
Ce montage est pratique, mais il lie entre eux des sites sans rapport. Un seul formulaire mal configuré ou détourné peut dégrader la délivrabilité de tous les sites qui utilisent le même compte.
Pour les agences qui gèrent de nombreux sites clients à faible trafic, l'impact est difficile à détecter. Les formulaires continuent d'afficher un succès, mais les messages n'arrivent plus. Le temps que le problème soit repéré, sa cause est noyée parmi plusieurs sites, et la corriger impose une rotation des clés, des changements de compte ou une reconfiguration dans l'urgence.
FormRoute y répond en isolant par défaut l'envoi de chaque formulaire et en considérant les abus comme une situation attendue, pas comme une exception.
Objectifs de conception
FormRoute repose sur un petit nombre de contraintes explicites.
Périmètre strictement transactionnel
Tous les messages sont déclenchés par la soumission d'un formulaire par un utilisateur final et livrés dans une boîte de réception désignée. Le système ne gère ni campagnes, ni listes d'abonnés, ni envois en masse, ni workflows d'automatisation. Limiter ainsi le périmètre simplifie la délivrabilité, la conformité et la gestion des abus.
Traitement prévisible des soumissions
La latence de soumission d'un formulaire ne doit pas dépendre des fournisseurs d'e-mail en aval ni de services tiers. Le chemin de réception accepte, valide et accuse réception des requêtes de façon synchrone, même lorsque les systèmes d'envoi sont dégradés ou indisponibles.
L'abus comme condition normale de fonctionnement
Le trafic automatisé, les tentatives de rejeu et les erreurs de configuration côté client sont traités comme des entrées attendues. La limitation de débit, la validation et l'application des règles font partie du comportement de base, et non de contrôles ajoutés après coup.
Isolation des tenants
Chaque site fonctionne avec ses propres limites, identifiants et réputation. Un problème d'envoi ou un abus touchant un site ne doit pas affecter les autres. Cette isolation guide à la fois l'architecture du système et le modèle de coûts du service.
Vue d'ensemble de l'architecture
FormRoute utilise une architecture à deux chemins qui sépare la réception de l'envoi :
-
Couche de réception des soumissions Valide les requêtes, applique les contrôles anti-abus et met en file d'attente les soumissions acceptées.
-
Workers d'envoi en arrière-plan Envoient les e-mails et exécutent des actions secondaires facultatives.
Le chemin de la requête HTTP est volontairement minimal. Les soumissions sont validées, soumises à la limitation de débit, enregistrées, mises en file d'attente, puis acquittées immédiatement. Aucun appel externe (SES, API Google) n'est effectué pendant le traitement de la requête de l'utilisateur.
Cela garantit une latence prévisible et empêche les pannes de services tiers de se propager en erreurs côté frontend.
Entités principales
| Couche | Entité | Rôle |
|---|---|---|
| Contrôle | Tenant | Compte client et état de facturation |
| Contrôle | Site | La configuration de formulaire d'un site web |
| Réception | Soumission | Un contenu de formulaire validé et assaini |
| Envoi | Tâche | Une tâche d'envoi en file d'attente |
| Audit | Événement | Rebond, plainte ou résultat d'envoi |
Chaque site appartient à un seul tenant et applique ses propres limites, secrets et règles d'envoi.
Réception des soumissions
Les soumissions de formulaires sont acceptées sur un point d'entrée unique :
POST /v1/submit
Les formats pris en charge sont JSON et application/x-www-form-urlencoded, ce qui assure la compatibilité avec les formulaires HTML natifs et les outils no-code.
À la réception, la couche de réception effectue les étapes suivantes de façon synchrone :
- Vérification de l'origine par rapport à une liste d'autorisation
- Validation de la clé secrète propre à chaque site
- Contrôle d'un champ pot de miel (honeypot)
- Heuristique de délai minimal avant soumission
- Vérification CAPTCHA adaptative
- Limitation de débit appuyée sur Redis (par IP, par site et combinée)
- Contrôle d'idempotence à l'aide d'un identifiant de requête
- Assainissement du contenu et limite de taille
Si un contrôle échoue, la soumission est rejetée immédiatement. Si tous les contrôles passent, la soumission est enregistrée et mise en file d'attente pour un traitement en arrière-plan.
Les soumissions acceptées renvoient toujours 200 OK, sans exposer le résultat de l'envoi.
Idempotence et protection contre le rejeu
Les points d'entrée publics des formulaires sont fréquemment sollicités plusieurs fois par les navigateurs, les proxys et les scripts côté client.
Pour éviter les envois en double, FormRoute prend en charge une idempotence explicite au moyen d'un identifiant de requête. Chaque couple (siteId, requestId) est enregistré avec une durée de vie (TTL) fixe. Les soumissions rejouées renvoient un succès mais ne créent aucune tâche supplémentaire.
Ainsi, les nouvelles tentatives, les rechargements de page ou les erreurs réseau ne peuvent pas produire d'e-mails en double.
Envoi en arrière-plan
Les workers d'envoi fonctionnent indépendamment de la couche de réception.
Pour chaque tâche en file d'attente, un worker :
- Détermine l'identité d'envoi vérifiée du site
- Construit le contenu d'un e-mail transactionnel
- Envoie via Amazon SES avec des délais d'expiration explicites
- Enregistre les identifiants de message du fournisseur et les résultats
Les échecs sont relancés avec un délai exponentiel (exponential backoff). Les tâches qui dépassent le nombre maximal de tentatives sont déplacées dans une file de lettres mortes (dead-letter queue) pour analyse.
Des workers secondaires facultatifs prennent en charge les tâches non critiques, comme l'ajout des soumissions dans Google Sheets. Ils sont totalement isolés de l'envoi des e-mails : ils ne bloquent rien et ne multiplient pas les nouvelles tentatives en cas d'échec.
Isolation des tenants et délivrabilité
L'isolation des tenants est une exigence de premier ordre.
Chaque site est associé à :
- Un domaine ou sous-domaine d'expédition vérifié
- Ses propres limites de débit et de volume
- Ses propres indicateurs d'abus et de délivrabilité
Les signaux de réputation, comme les rebonds, les plaintes et les volumes anormaux, sont surveillés en continu. Les sites ou tenants qui dépassent les seuils de sécurité sont automatiquement mis en pause, ce qui bloque tout nouvel envoi et préserve la réputation de l'ensemble du système.
Les coupe-circuits sont immédiats et réversibles : les opérateurs peuvent contenir un abus sans affecter les clients qui n'ont rien à voir.
Réception des événements et boucles de rétroaction
FormRoute s'abonne aux événements d'envoi de SES.
Les notifications de rebond et de plainte sont enregistrées comme des événements immuables et rattachées au site et au tenant d'origine. Ces événements alimentent des règles d'application automatiques et des indicateurs de santé à long terme.
Grâce à cette boucle de rétroaction, le comportement d'envoi s'adapte aux signaux réels plutôt qu'à des hypothèses.
Sécurité et traitement des données
FormRoute évite délibérément de collecter des comptes ou des profils d'utilisateurs finaux.
- Les contenus sont assainis et leur taille est limitée
- Les secrets sont stockés sous forme hachée et comparés en temps constant
- Les identifiants des fournisseurs sont isolés de la logique applicative
- Toutes les transitions d'état sont horodatées et auditables
Les politiques de conservation purgent automatiquement les soumissions passées après des durées définies, ce qui réduit l'exposition et les contraintes de conformité.
Caractéristiques opérationnelles
- Latence d'API prévisible sous charge
- Aucune dépendance synchrone à des services tiers
- Nouvelles tentatives bornées
- Règles d'acceptation et de rejet déterministes
- Modes de défaillance explicites, au rayon d'impact clairement délimité
Le système est conçu pour se dégrader sans risque. Lorsque des limites sont dépassées ou qu'un abus est détecté, les soumissions sont rejetées proprement.
Enjeux économiques et structure des coûts
FormRoute est pensé comme une infrastructure économique pour un cas d'usage précis.
Les plateformes d'e-mail généralistes fixent leurs prix autour de fonctionnalités marketing comme la gestion des abonnés, les campagnes, les modèles, les statistiques et l'automatisation. Ces fonctionnalités déterminent le coût minimal, même lorsqu'elles ne servent pas. Pour le simple envoi de formulaires, c'est une dépense inutile.
Pour les agences qui gèrent de nombreux sites à faible trafic, cette structure de coûts passe mal à l'échelle. Les minimums par compte augmentent de façon linéaire, tandis que les comptes partagés introduisent un risque opérationnel lié à la réputation commune et au manque de visibilité sur les échecs.
FormRoute limite volontairement son périmètre. Sans stockage d'abonnés, sans logique de campagne et sans outils lourds d'interface, son coût dépend avant tout de l'infrastructure de base. L'envoi des e-mails est assuré par Amazon SES, où le trafic transactionnel de formulaires n'entraîne généralement que des frais d'utilisation minimes.
Le prix reste donc stable à mesure que le nombre de sites augmente. Les agences peuvent prendre en charge de nombreux sites clients sans multiplier les coûts. Les freelances et les propriétaires de sites peuvent utiliser le service sur la durée, sans remettre en question leur choix de plateforme d'e-mail ni supporter le surcoût d'offres orientées marketing.
La facturation annuelle réduit encore les frais et favorise un usage prévisible.
Pour donner un ordre de grandeur : au tarif à la carte d'Amazon SES de 0,10 $ pour 1 000 e-mails (tarifs AWS), 9 000 soumissions par mois coûtent moins de 1 $ d'envoi. La difficulté n'est pas le prix mais la délivrabilité : c'est pourquoi FormRoute respecte les exigences d'authentification des consignes de Google pour les expéditeurs d'e-mails et surveille les rebonds et les plaintes site par site grâce aux jeux de configuration SES.
Résultat
FormRoute apporte une solution ciblée à l'envoi des formulaires de sites web.
En limitant son périmètre aux soumissions transactionnelles et en imposant l'isolation au niveau de chaque site, il évite les risques de réputation partagée et les risques opérationnels propres aux plateformes d'e-mail généralistes. Le comportement d'envoi, les modes de défaillance et les limites sont explicites et prévisibles.
Le résultat : un chemin fiable et peu coûteux entre un formulaire public et une boîte de réception, qui ne dépend pas d'une infrastructure d'e-mailing marketing partagée.
FormRoute n'est pas une plateforme d'e-mail généraliste. C'est de l'infrastructure : un périmètre volontairement limité, conçu pour fonctionner avec un minimum d'attention au quotidien.
Nous concevons ce type de services ciblés pour nos clients dans le cadre du développement d'applications web sur mesure, et nous les exploitons dans le cadre d'un partenariat technique sur le long terme. Pour un autre système interne construit sur les mêmes principes, découvrez TokenHub.
Pour aller plus loin
- AWS, Qu'est-ce qu'Amazon SES ? et La délivrabilité avec Amazon SES (en anglais)
- AWS, Surveiller votre activité d'envoi (en anglais)
- Google, Consignes pour les expéditeurs d'e-mails
- IETF, RFC 7489 : DMARC (en anglais)