Widget de validation email pour formulaire
Le widget valide une adresse directement dans un formulaire, pendant la saisie, sans écrire de code d'intégration. Il s'ajoute avec une seule balise, qui ne contient aucune clé API. Il applique exactement les mêmes contrôles que l'API et propose une correction quand le domaine saisi ressemble à un domaine connu.
Une balise à coller
L'installation tient en une balise, à coller avant la fermeture de la page. Le script trouve seul les champs d'adresse email du formulaire, lit sa configuration auprès du serveur, et se met en place. Aucun code d'intégration à écrire, aucune dépendance à installer, aucun secret dans la page.
<script async src="https://api.yeswecheck.fr/widget/ywc-email-widget.js" data-ywc-widget="VOTRE_ID_WIDGET"></script>Le code à coller ne contient aucune clé API. Il porte l'identifiant du widget, et rien d'autre : la clé est résolue côté serveur, elle ne circule jamais dans la page publique.
Par défaut, le widget s'accroche aux champs qui déclarent
input[type="email"]. Un sélecteur différent peut être configuré
quand le formulaire n'utilise pas ce type de champ.
Ce que voit la personne qui saisit
Le widget affiche l'état du champ pendant la saisie et propose une correction quand le domaine ressemble à un domaine connu. Les messages sont configurables, en français comme dans une autre langue. Rien n'est bloqué de force : le widget informe, et c'est le formulaire qui décide de refuser ou non.
Correction des fautes de frappe
Un domaine mal orthographié est reconnu et la bonne graphie est proposée. C'est le gain le plus immédiat sur un formulaire d'inscription, et il ne coûte aucun crédit.
Messages configurables
Chaque état porte son propre message, modifiable : adresse valide, risquée, invalide, indéterminée, ou vérification en cours.
Apparence
L'affichage de l'état du champ, de l'icône de statut et des indications de contrôle s'active ou se désactive indépendamment.
Ce qui protège un widget
Un widget vit dans une page publique : son identifiant est visible de tous. Ce qui le protège n'est donc pas le secret de cet identifiant, mais ce que le serveur accepte d'en faire. Deux garde-fous s'appliquent ensemble : la portée de la clé, et la liste des domaines autorisés à l'utiliser.
Une clé liée à un widget passe en portée « widget » et doit déclarer au moins un domaine autorisé. Une requête émise depuis un autre domaine est refusée, et la portée « widget » interdit à cette clé tout autre usage de l'API.
| Appel | Rôle |
|---|---|
| GET /v2/widget/config | Configuration publique d'un widget, lue par le script embarqué. |
| POST /v2/widget/validate | Validation appelée par le widget depuis un site client. |
La configuration détaillée d'un widget, messages personnalisés et seuils compris, n'est jamais exposée dans la page publique : le script la lit auprès du serveur.
Plafonds d'usage et défi anti-robot
Un formulaire public attire les robots. Deux mécanismes complémentaires y répondent : des compteurs qui plafonnent l'usage par adresse IP, par appareil et par clé, et un défi de calcul qui s'exécute dans le navigateur avant la validation. Une détection d'énumération tourne en plus, sans configuration.
- Plafonds. Des compteurs par adresse IP, par appareil et par clé plafonnent l'usage du widget. Au-delà du seuil, la vérification SMTP est désactivée ou la requête refusée, selon la configuration.
- Défi de calcul. Un défi de calcul peut être exigé avant chaque validation, ou seulement quand la vérification SMTP est demandée. Il s'exécute dans le navigateur, sans image à déchiffrer et sans service tiers.
- Détection d'énumération. La détection est silencieuse : aucun blocage n'est renvoyé à l'appelant, pour ne pas apprendre à l'attaquant qu'il est repéré. L'organisation reçoit une alerte par courriel, avec des exemples concrets et un blocage en un clic. Le blocage tombe donc quand elle le décide, pas au moment où l'attaquant pourrait s'en apercevoir.
La protection contre l'énumération est active sur API, widget, traitement par lots, sans configuration côté client.
Ce que consomme un widget
Les règles de facturation du widget sont celles de l'API, sans exception. Un widget configuré sans vérification SMTP ne consomme jamais de crédit, quel que soit le trafic du formulaire. Avec vérification SMTP, un crédit est débité par adresse pour laquelle le serveur destinataire a permis de conclure.
Un crédit est débité si et seulement si la vérification SMTP a été demandée et que le statut final n'est pas « unknown ».
Les 18 contrôles gratuits s'appliquent à chaque saisie, sans quota : la correction de faute de frappe, la détection d'adresse jetable et le contrôle du domaine ne coûtent rien.
Questions fréquentes
- Le code à coller contient-il une clé API ?
- Le code à coller ne contient aucune clé API. Il porte l'identifiant du widget, et rien d'autre : la clé est résolue côté serveur, elle ne circule jamais dans la page publique.
- Que se passe-t-il si quelqu'un copie mon identifiant de widget ?
- Une clé liée à un widget passe en portée « widget » et doit déclarer au moins un domaine autorisé. Une requête émise depuis un autre domaine est refusée, et la portée « widget » interdit à cette clé tout autre usage de l'API.
- Le widget consomme-t-il des crédits à chaque frappe ?
- Un crédit est débité si et seulement si la vérification SMTP a été demandée et que le statut final n'est pas indéterminé. Un widget configuré sans vérification SMTP ne consomme jamais de crédit, quel que soit le nombre de saisies.
- Le widget protège-t-il contre les robots ?
- Des compteurs par adresse IP, par appareil et par clé plafonnent l'usage du widget. Au-delà du seuil, la vérification SMTP est désactivée ou la requête refusée, selon la configuration. Un défi de calcul peut en outre être exigé avant chaque validation.
Aller plus loin
Quand le formulaire demande un contrôle plus fin que ce que le widget expose, l'API rend le même résultat avec le détail complet des contrôles. Pour nettoyer une base d'adresses déjà collectées plutôt que d'en filtrer l'entrée, le traitement par lots applique les mêmes règles.