Conception d'un score de risque d'e‑mail : une grille de notation simple basée sur des signaux

Qu'est‑ce qu'un score de risque d'e‑mail (et pourquoi vous pourriez en avoir besoin)

Un score de risque d'e‑mail est un nombre simple (ou une étiquette comme faible, moyen, élevé) qui estime la probabilité qu'une adresse e‑mail crée des problèmes pour votre activité. « Problèmes » signifie généralement inscriptions frauduleuses, rebonds, plaintes pour spam ou utilisateurs que vous ne pouvez plus joindre.

Ce n'est pas un verdict sur le fait qu'une personne soit « bonne » ou « mauvaise ». C'est un résumé rapide et cohérent des signaux que vous avez déjà.

Un score aide quand le pass/fail est trop grossier. Beaucoup d'adresses semblent valides en apparence mais restent risquées. Une adresse peut avoir une syntaxe correcte et un domaine réel, et pourtant être jetable, mal configurée ou liée à des schémas ayant déjà causé des abus.

Avec un score de risque, vous pouvez prendre des décisions cohérentes sans transformer chaque cas limite en débat. Les actions typiques sont :

• Autoriser l'inscription et procéder normalement
• Autoriser, mais ajouter de la friction (vérification par e‑mail, CAPTCHA, limites)
• Envoyer en revue manuelle pour les actions à forte valeur
• Bloquer l'inscription ou empêcher certaines actions

L'explicabilité est importante. Les équipes non techniques doivent pouvoir répondre « Pourquoi ceci est‑il à haut risque ? ». Visez des raisons simples comme « fournisseur jetable », « domaine incapable de recevoir des mails » ou « échec des vérifs de domaine ».

Une façon simple d'aligner tout le monde est d'associer chaque bande de score à une politique claire. Par exemple, 0–30 signifie faible risque et auto‑approuvé, 31–70 signifie risque modéré et exigence de vérification, 71–100 signifie risque élevé et blocage ou revue. L'objectif n'est pas un chiffre parfait, mais une décision que vous pouvez expliquer, mesurer et ajuster.

Signaux e‑mail à inclure : la liste pratique et courte

Commencez avec un petit ensemble de signaux faciles à expliquer et difficiles à manipuler. Vous pouvez en ajouter plus tard.

Commencez par des contrôles stricts de syntaxe. Ce n'est pas seulement « contient un @ ». Le parsing de type RFC repère les parties manquantes, caractères interdits, doubles points et formats trompeurs que beaucoup de systèmes gèrent mal. Les vérifs de syntaxe sont peu coûteuses et arrêtent les déchets évidents tôt, mais elles ne disent rien sur la capacité réelle de la boîte à recevoir du courrier.

Ensuite, vérifiez la santé du domaine. Deux contrôles font la majeure partie du travail : le domaine existe‑t‑il (résolution DNS) et publie‑t‑il des enregistrements MX. MX n'est pas parfait (certains domaines acceptent le courrier sans MX), mais c'est un bon indice d'atteignabilité. Un domaine tout récent sans configuration mail est souvent plus risqué à l'inscription.

Les drapeaux d'adresses jetables comptent surtout lors de la création de compte. Les boîtes jetables apparaissent dans l'abus d'essai gratuit, la chasse aux coupons et la capture de faux leads. Vous n'avez pas toujours besoin de les bloquer, mais vous devez les noter.

Vous pouvez aussi inclure des signaux de réputation avec prudence. Les listes noires et indicateurs de pièges à spam peuvent réduire les rebonds, mais des faux positifs existent. Traitez‑les comme des entrées de haute confiance seulement et préférez des actions douces (vérification supplémentaire) plutôt que des blocages fermes.

Enfin, ajoutez le contexte que vous avez déjà. L'e‑mail seul raconte rarement toute l'histoire. Des entrées utiles incluent l'origine de l'inscription, une vélocité d'inscription inhabituelle, des schémas répétés et ce qu'il s'est passé pour des inscriptions similaires auparavant.

Exemple : pendant une promotion, une adresse syntaxiquement valide sur un domaine sans MX plus un drapeau jetable et une haute vélocité d'inscription forment un signal beaucoup plus fort que n'importe lequel de ces contrôles pris isolément.

Définir ce que le score doit prédire

Un score de risque ne fonctionne que si tout le monde s'accorde sur ce que « risque » signifie. Commencez par écrire la décision qu'il doit soutenir. Voulez‑vous bloquer les mauvaises inscriptions, réduire les rebonds, ou diminuer la charge support ? Si le score essaie de tout faire en même temps, il devient confus et difficile à régler.

Séparez risque de délivrabilité et risque de fraude

Ces notions sont liées, mais différentes.

Le risque de délivrabilité concerne votre capacité à atteindre l'adresse. Il se traduit par des rebonds durs, des rebonds répétés ou un dommage à la réputation d'expéditeur.

Le risque de fraude ou d'abus concerne l'utilisateur derrière l'adresse. Il se traduit par des rétrofacturations, abus de coupons, faux comptes, plaintes pour spam ou une valeur à vie anormalement basse.

Vous pouvez gérer cela de deux façons simples : garder deux scores séparés, ou garder un score unique mais le nommer clairement (par exemple « risque d'abus à l'inscription »).

Définissez l'issue et le coût des erreurs

Choisissez un résultat principal à prédire, puis ajoutez des secondaires plus tard. Bons objectifs de départ :

• « Cette adresse d'inscription va‑t‑elle rebondir dans les 7 jours ? »
• « Ce compte va‑t‑il déclencher un événement d'abus dans les 30 jours ? »
• « Cet utilisateur aura‑t‑il une faible valeur (pas d'activation, pas d'achat) sous 14 jours ? »

Décidez ensuite quel est le coût d'un faux positif. Si vous bloquez un vrai client, vous perdez du revenu et de la confiance. Si vous laissez passer une inscription risquée, vous payez en rétrofacturations, temps de support ou dégâts de délivrabilité. Votre tolérance à ces compromis doit guider les seuils.

Enfin, choisissez une échelle et ce qu'elle signifie. Une échelle 0–100 est facile à communiquer, à condition de définir des bandes comme 0–24 faible, 25–59 moyen, 60–100 élevé. Liez chaque bande à une action pour que le score soit plus qu'un chiffre.

Choisir un modèle de notation que vous pouvez expliquer

Un score de risque n'est utile que si les gens lui font confiance. Cela signifie que vous devez pouvoir répondre en termes simples : pourquoi cette inscription a‑t‑elle obtenu ce score, et que devons‑nous faire ensuite ?

Une grille à points est généralement le point de départ le plus simple. Elle fonctionne comme une checklist avec un total, et il est facile de l'inclure dans une politique. Une moyenne pondérée ou un petit modèle peuvent être plus précis, mais ils sont plus difficiles à expliquer quand quelqu'un demande « pourquoi cela a‑t‑il été bloqué ? »

Voici une approche de pondération simple avec quatre signaux de base. Gardez les calculs simples et les résultats clairs :

• Syntaxe et formatage (0 à 10) : fautes évidentes, caractères invalides, échecs de vérif RFC
• Santé du domaine (0 à 35) : le domaine existe, DNS valide, pas de drapeaux évidents
• Routage mail (0 à 35) : MX présent et normal, pas d'échecs durs
• Drapeaux jetables et listes de risque (0 à 20) : correspondance fournisseur jetable, schémas connus, indicateurs de pièges à spam

Cela fait 100 au total. Dans ce cadre, un score plus élevé signifie plus de risque.

Les données manquantes arrivent, surtout avec des timeouts DNS ou des échecs temporaires de lookup. Décidez à l'avance si « inconnu » doit être neutre, légèrement risqué ou une raison de retenter :

• Traitez un timeout comme « inconnu » et retentez une fois avant d'attribuer un score
• Si le MX est inconnu après la retry, appliquez une petite pénalité (par exemple +10), pas un échec automatique
• Si le domaine n'existe clairement pas, considérez‑le comme un échec catégorique indépendamment des autres signaux

Calibrez selon votre produit. Un flux B2B peut être plus strict sur la santé du domaine et le MX (on attend des e‑mails professionnels). Un flux grand public peut autoriser davantage les domaines gratuits mais doit être plus strict sur les drapeaux jetables.

Étape par étape : construire une grille de notation simple

Un bon score commence par rendre comparables des signaux désordonnés. Ne cherchez pas à noter chaque détail. Convertissez chaque signal en quelques catégories que n'importe quel collègue non technique pourra reconnaître et expliquer.

1) Catégorisez d'abord chaque signal

Choisissez 3 à 4 catégories par signal. Par exemple : syntaxe (valide, douteuse, invalide), santé du domaine (saine, inconnue, cassée), drapeau jetable (non, peut‑être, oui), et historiques (bon historique, mixte, mauvais). Gardez des noms simples.

Ensuite, attribuez des points avec un schéma simple : bon = peu de points, incertain = moyen, mauvais = beaucoup. Si les adresses jetables sont votre principal vecteur d'abus, donnez à ce signal plus de poids que des quirks mineurs de syntaxe.

Un flux pratique :

• Transformez chaque signal brut en une catégorie avec des règles fixes
• Donnez à chaque catégorie une valeur en points (ex. 0, 10, 25)
• Additionnez les points pour obtenir un total
• Contraignez le total à une plage stable (comme 0–100)
• Stockez les catégories, les points et le score final pour chaque décision

2) Mappez les bandes de score aux actions

Le score n'a de valeur que s'il déclenche une action cohérente. Gardez peu de bandes et évidentes :

• 0–24 : autoriser l'inscription
• 25–59 : autoriser, mais ajouter une étape de vérification (OTP e‑mail, CAPTCHA, revue manuelle pour flux à forte valeur)
• 60–100 : bloquer ou exiger une preuve plus forte

Le logging n'est pas optionnel. Sauvegardez les buckets d'entrée (pas seulement le score final) et l'action prise. Si vous utilisez une API de validation d'e‑mail, conservez les sorties clés sur lesquelles vous vous êtes appuyé afin de comparer les scores aux résultats réels plus tard.

Un exemple concret de grille (suffisamment simple pour une politique)

Une grille simple fonctionne mieux quand elle est facile à expliquer au support, à la fraude et au marketing. Commencez à 0 point (risque le plus faible) et ajoutez des points quand un signal augmente la probabilité que l'adresse rebondisse, soit fausse ou mène à un abus.

Table d'exemple de notation

Seuils et actions

• Faible risque (0–29) : autoriser l'inscription
• Risque moyen (30–59) : autoriser, mais ajouter de la friction (vérification e‑mail, limites de débit, revue manuelle)
• Haut risque (60+) : bloquer ou exiger une preuve forte (OTP + vérifs supplémentaires)

Conseil pour les cas limites : si la syntaxe est valide et le domaine résout mais qu'il n'y a pas de MX, traitez par défaut comme risque moyen, pas blocage automatique. Certains domaines sont mal configurés temporairement et vous ne voulez pas refuser des utilisateurs légitimes.

Pour garder la grille stable quand vous ajoutez de nouveaux signaux, plafonnez l'impact de tout nouveau signal (par exemple +10 à +15) et ne changez les seuils qu'après avoir des données d'issue.

Scénario d'exemple : noter des inscriptions pendant une campagne

Une grosse promo peut changer votre trafic du jour au lendemain. Vous obtenez plus de vrais clients, mais aussi plus de bots, chasseurs de coupons et personnes utilisant des adresses jetables. Un score de risque vous aide à décider qui peut s'inscrire sans friction et qui doit passer une vérification.

Supposons une échelle 0–100 (plus = plus risqué). Vous exécutez des signaux de validation (syntax, domaine et MX, drapeaux jetables, et vos propres historiques) dans un pipeline, puis vous attribuez des points.

Voici deux inscriptions issues de la même campagne :

Pour la deuxième inscription, « ajouter vérification » peut être léger : OTP par e‑mail, lien magique, ou exiger une vérification avant de remettre la promo. Vous ne bloquez pas tout le monde, vous n'ajoutez des ralentisseurs que là où les signaux le justifient.

Avec le temps, ajustez les poids à partir des résultats, pas des suppositions. Si les e‑mails marqués jetables convertissent et restent actifs, réduisez la pénalité. Si un domaine particulier produit des rebonds, des rétrofacturations ou des plaintes, augmentez les points liés à l'historique domaine.

Erreurs courantes et comment les éviter

La façon la plus rapide de perdre la confiance dans un score est de traiter un signal comme un verdict. Les signaux e‑mail sont bruyants : les réseaux plantent, les domaines sont mal configurés temporairement et des gens réels utilisent parfois des adresses qui paraissent suspectes.

Erreur 1 : traiter « jetable » comme « toujours bloquer »

La détection jetable est utile, mais ce n'est pas synonyme de fraude. Si vous la sur‑pondérez, vous bloquerez de vrais utilisateurs cherchant la confidentialité ou un essai rapide. Une approche plus sûre est de la scorer fortement, puis de la coupler au contexte (vélocité d'inscription, intention de paiement, vérifs de domaine/MX).

Erreur 2 : transformer un souci DNS temporaire en risque permanent

Les timeouts DNS arrivent. Ne notez pas un timeout comme « domaine inexistant ». Gardez une catégorie « inconnu maintenant », réessayez une fois, et n'augmentez le risque que légèrement sauf si d'autres signaux confirment.

Erreur 3 : cumuler des signaux qui n'apportent pas d'information nouvelle

Il est facile de doubler une idée. Par exemple, « pas de MX » et « échec de vérif de domaine » peuvent être deux vues d'un même problème. Si vous ajoutez les deux à plein poids, vous gonflez le risque sans améliorer la précision. Choisissez la version la plus claire, ou réduisez les poids quand les signaux se recoupent.

Erreur 4 : laisser le score dériver

Quand les campagnes changent et que les attaquants s'adaptent, les poids d'hier ne valent plus forcément. Revuez les issues (rebonds, plaintes, rétrofacturations, taux d'activation) régulièrement et surveillez les changements soudains.

Erreur 5 : apprendre à partir des mauvaises données

Séparez test et production. Des données de test comme [email protected], des scripts QA et des domaines internes peuvent polluer vos labels « bon vs mauvais ».

Checklist pratique pour prévention :

• Séparez « invalide » de « temporaire/inconnu »
• Limitez l'impact des drapeaux jetables sauf si d'autres signaux confirment
• Retirez ou réduisez le poids des signaux qui se chevauchent
• Surveillez les métriques d'issue et réajustez régulièrement
• Excluez le trafic non‑production des entraînements et rapports

Comment valider et affiner le score avec les issues

Un score n'a de sens que s'il correspond à ce qui arrive ensuite. Traitez votre score comme une prédiction vérifiable.

Commencez par collecter les issues liées à l'inscription : délivré vs rebondi, plaintes, abus de compte, rétrofacturations, flags support et toute fraude confirmée.

Choisissez quelques bandes (par ex. Faible, Moyen, Élevé) et révisez‑les à fréquence fixe. Hebdomadaire suffit au début ; quotidien aide lors de grosses campagnes ou de changements de politique.

Que mesurer par bande de score

Cherchez la séparation : le haut risque doit avoir des issues significativement pires que le bas risque. Suivez un petit ensemble de métriques :

• Taux de rebond et rebond dur par bande
• Événements d'abus/fraude par bande
• Taux d'acceptation en revue manuelle par bande
• Part des inscriptions par bande, pour détecter des changements soudains
• Signaux de valeur en aval (activation, conversion payante) si disponibles

Si les bandes se ressemblent, vos signaux ne suffisent pas ou vos seuils sont mal placés. Par exemple, si « Élevé » a le même taux de rebond que « Faible », vous êtes soit trop strict sur des signaux innocents, soit trop permissif sur des signaux forts.

Comment ajuster sans tout casser

Changez une chose à la fois, et rendez le changement mesurable. Le réglage le plus sûr est souvent le seuil, pas tout le modèle.

Faites un A/B test (ou un petit holdout) avant de déployer de nouveaux cutoffs. Exemple : pendant une semaine, bloquez seulement le 1 % d'inscriptions les plus risquées dans le groupe test, tandis que le groupe contrôle utilise la politique actuelle. Comparez rebonds, abus et perte de bons utilisateurs.

Checklist rapide avant déploiement

Les problèmes de mise en production viennent souvent d'actions floues, de garde‑fous manquants ou d'entrées bruyantes.

• Confirmez que vous ne scorez que des adresses passant des règles de syntaxe de base (et traitez les fautes évidentes de façon cohérente)
• Vérifiez que le domaine est réel et peut recevoir du mail, incluant MX (ou l'équivalent que vous avez choisi)
• Décidez comment gérer les fournisseurs jetables : bloquer, challenger ou autoriser avec limites
• Définissez ce que signifie « risque de domaine » pour votre app (domaines nouvellement vus, fournisseurs rares, ou mauvais historique)
• Assurez‑vous que chaque signal peut être expliqué en une phrase dans les logs et notes support

Ensuite, mappez le score à une action. Si deux personnes de votre équipe prendraient deux actions différentes pour le même score, la politique n'est pas prête.

Si vous voulez une quatrième bande pendant les campagnes, ajoutez‑la explicitement (et gardez‑la simple à gérer) : très haut risque peut être throttlé ou bloqué.

Détails opérationnels : logging, explicabilité et stabilité

Une grille ne sert que si vous pouvez l'exploiter au quotidien. Traitez votre score comme un système de décision : loggez assez pour le déboguer, expliquez‑le aux humains et gardez‑le stable sous trafic réel.

Commencez par du logging qui permet de recréer la décision pour toute inscription. Capturez les entrées brutes (résultat de syntaxe, vérifs domaine/MX, drapeau jetable, toute correspondance liste noire), le score final et l'action prise (autoriser, friction, revue, blocage). Stockez un request ID pour que le support retrouve rapidement l'historique complet.

Rendez le score lisible en une phrase. À côté du score numérique, conservez une courte raison que quelqu'un peut lire en cinq secondes. Par exemple : « Fournisseur jetable + échec MX, score 82, bloqué. »

Stabilité sous trafic réel

Les vérifs e‑mail peuvent échouer pour des raisons indépendantes de l'utilisateur. Prévoyez timeouts, retries limités, quotas et solutions de secours sûres. Si les vérifs échouent, renvoyez un état « inconnu » conservateur plutôt que de laisser le score varier fortement.

Confidentialité et conservation

Les logs d'e‑mail sont sensibles. Conservez seulement ce dont vous avez besoin, restreignez l'accès et fixez une durée de rétention (par ex. 30 à 90 jours pour les signaux bruts). Si vous avez besoin d'analyses long terme, stockez des agrégats ou des identifiants hachés au lieu des adresses complètes.

Prochaines étapes : implémentez, mesurez et gardez la simplicité

Commencez petit. Votre premier score doit être une grille claire qu'un collègue peut lire et appliquer sans tableur. Si vous ne pouvez pas expliquer pourquoi une inscription a obtenu 72 plutôt que 28, vous n'y aurez pas confiance quand ça comptera.

Déployez quelques signaux que vous comprenez, puis ajustez seulement après avoir des issues réelles (rebonds, rétrofacturations, rapports d'abus, activations réussies). Gardez les actions simples pour les rendre opérationnelles :

• Faible risque : autoriser l'inscription normalement
• Risque moyen : ajouter une friction légère (vérification e‑mail ou CAPTCHA)
• Haut risque : exiger une preuve plus forte, limiter les actions ou envoyer en revue

L'implémentation est plus simple quand les signaux clés arrivent au même endroit. Par exemple, Verimail (verimail.co) fournit une API de validation d'e‑mail qui renvoie des vérifs comme la syntaxe conforme à la RFC, la vérification de domaine, la recherche MX et la correspondance jetable et liste noire dans une seule réponse. Utilisez ces résultats comme entrées pour votre grille, puis gardez les règles de décision dans votre app pour qu'elles restent faciles à expliquer et à changer.

Une fois en production, mesurez cela comme une fonctionnalité produit. Loggez le score, la bande, l'action prise et l'issue observée plus tard. Revuez un petit échantillon de faux positifs (bloqués mais légitimes) et de faux négatifs (autorisés mais nuisibles), puis ajustez une règle à la fois. La version la plus simple que vous surveillez et mettez à jour bat un modèle compliqué que personne ne peut expliquer.