# Comment les banques doivent surveiller la distribution des codes OTP et la fraude

> Les indicateurs clés de performance (KPI) dont les banques ont besoin sur leur tableau de bord, les signaux de fraude qui méritent une alerte et le plan d'action opérationnel pour les modes de défaillance des mots de passe à usage unique (OTP) les plus susceptibles d'entraîner des coûts.

- URL canonique: https://www.broadnet.me/fr/blog/bank-otp-delivery-monitoring-fraud-playbook
- Langue: fr
- Dernière mise à jour: 2026-09-24
- Éditeur: BroadNet (https://www.broadnet.me)

- Publié le: 2026-04-30
- Auteur: BroadNet Industry Research

Pour une banque, un code OTP n'est pas une simple notification. Il s'agit d'un contrôle essentiel sur les flux clients les plus sensibles en matière de sécurité : connexion, confirmation de transaction, ajout de bénéficiaire, activation de carte, association d'appareil. Un code OTP non reçu peut bloquer un client ; un code reçu mais intercepté, rejoué ou invalidé par un système automatisé peut entraîner des pertes directes dues à la fraude et des échanges avec les autorités de régulation. Les banques ont donc besoin d'une gestion des codes OTP plus rigoureuse que les autres expéditeurs de services A2P : une meilleure instrumentation, une alerte plus proactive en cas de suspicion de fraude et une procédure documentée pour les défaillances prévisibles. Voici en quoi consiste cette gestion.

## Les cinq indicateurs clés de performance (KPI) qui devraient être affichés au mur

La plupart des banques mesurent la distribution des codes OTP par un seul chiffre, le « taux de distribution ». Or, ce chiffre est presque toujours erroné, car le taux de distribution indiqué par le fournisseur de messagerie correspond au taux de réussite de l'envoi, et non au taux auquel un code OTP est réellement parvenu au client qui l'a utilisé. Cinq indicateurs, suivis par canal et par opérateur de destination, permettent d'obtenir une image fidèle.

1. Taux de livraison de bout en bout — proportion de demandes de code OTP pour lesquelles l’opérateur destinataire a renvoyé un DLR positif pendant la période de validité du code. Il s’agit du taux de livraison réel, et non du taux d’acceptation des soumissions.
2. Latence p50, p95, p99 — transmission au terminal, par canal et par opérateur de destination. Suivi sous forme de série temporelle, et non de valeur unique ; l’alerte est déclenchée par une dégradation par rapport à une ligne de base glissante plutôt que par un seuil absolu.
3. Taux de nouvelle tentative — proportion de requêtes OTP ayant entraîné un nouvel envoi, déclenché par l’utilisateur ou le système, pendant la période de validité. Une augmentation du taux de nouvelle tentative est le premier signe de dégradation de la distribution principale ; elle précède presque toujours la baisse explicite du taux de distribution.
4. Taux de rejet des identifiants d'expéditeur — proportion de soumissions rejetées au niveau de l'opérateur en raison d'un identifiant d'expéditeur incorrect. Une valeur différente de zéro indique un problème d'enregistrement ; une alerte doit être émise en cas de tolérance zéro.
5. Taux de complétion des codes OTP — proportion de demandes de codes OTP pour lesquelles l’utilisateur a saisi le code avec succès. C’est le seul indicateur de performance clé (KPI) ayant une réelle importance commerciale ; tous les autres indicateurs y contribuent. Un taux de distribution de 99 % associé à un taux de complétion de 70 % indique que le message est arrivé trop tard ou que l’expérience utilisateur lors de la saisie est défaillante ; une distribution sans complétion n’est pas synonyme de succès.

## Les signaux de fraude qui méritent d'être signalés

L'infrastructure OTP constitue également une surface d'attaque. Trois types d'abus sont courants et tous détectables à partir des données déjà collectées par la banque.

### 1. Demandes répétées de code OTP pour le même MSISDN

Un attaquant qui analyse le flux de mots de passe à usage unique (OTP) d'un compte unique — manuellement ou via un script — produit une signature caractéristique : de nombreuses requêtes OTP pour un même numéro de téléphone, souvent rapprochées dans le temps, parfois avec des adresses IP ou des chaînes User-Agent différentes lors de la session d'origine. Un utilisateur légitime (qui ne parvient réellement pas à retrouver son code) effectue au maximum trois à cinq tentatives en quelques minutes ; un profil d'attaque se caractérise par des dizaines, voire des centaines de tentatives. Les seuils d'alerte doivent être stricts : plus de dix requêtes OTP pour un même numéro MSISDN en quinze minutes indiquent presque toujours soit une attaque, soit une intégration défaillante, deux problèmes qui nécessitent une attention particulière.

### 2. Anomalies géographiques et comportementales

Une demande de code OTP (mot de passe à usage unique) provenant d'une session située dans un pays et associée à un numéro de téléphone historiquement lié à un autre pays n'est pas forcément synonyme de fraude (il peut s'agir d'un client en déplacement), mais il est préférable de renforcer l'authentification plutôt que de simplement accepter la demande. Si l'on y ajoute des modifications de l'empreinte numérique de l'appareil (nouveau navigateur, nouvel identifiant d'appareil, installation d'une nouvelle application), le signal est encore plus fort. Le système d'analyse des risques de la banque devrait déjà effectuer cette vérification pour l'autorisation des transactions ; l'étendre à l'émission des codes OTP représente un gain rapide.

### 3. Énumération limitée et bourrage d'identifiants

Un attaquant plus sophistiqué énumère les identifiants de compte via le processus de récupération de mot de passe, en restant délibérément sous la limite de requêtes OTP par compte tout en sondant de nombreux comptes en parallèle. La signature est un taux élevé de requêtes OTP provenant de nombreux MSISDN distincts et d'une plage source restreinte, souvent avec un faible nombre de requêtes par MSISDN, échappant ainsi aux alertes par compte. La détection nécessite une agrégation des données par origine (adresse IP, type d'appareil, modèle de session) plutôt qu'une analyse par compte. Il s'agit précisément du mode opératoire des attaques par injection de SMS (SMS pumping) que certains attaquants utilisent contre l'infrastructure OTP pour monétiser les remises versées par message aux fournisseurs ; s'en protéger permet de lutter simultanément contre la fraude et l'inflation des coûts pour les fournisseurs.

## Le manuel opérationnel des modes de défaillance prévisibles

Dans chaque banque, trois types d'incidents liés aux mots de passe à usage unique (OTP) se répètent. Disposer d'une procédure écrite pour chaque type d'incident — et non d'un manuel improvisé sous la pression — permet de passer d'une reprise d'activité en 4 heures à une reprise en 15 minutes.

### Guide pratique 1 — Dégradation des routes des opérateurs de destination

Signal : la latence p95 augmente sur un opérateur de destination spécifique tandis qu'elle reste stable pour les autres, et le taux de livraison vers cet opérateur diminue. Action : vérifier que la dégradation provient du routage et non d'un problème interne (le taux d'acceptation des requêtes reste à 100 %), basculer le trafic OTP de cet opérateur vers la route secondaire dans le moteur de routage, et notifier le centre d'opérations réseau (NOC) du fournisseur pour confirmation et estimation du délai de rétablissement. Reprise : rétablir le trafic une fois que les indicateurs de la route principale sont revenus à leur niveau de base pendant 30 minutes. La procédure complète doit comporter dix lignes et être mise en œuvre trimestriellement.

### Plan d'action 2 — Pic de rejet d'identifiants d'expéditeur

Signal : le taux de rejet des identifiants d’expéditeur passe de zéro à une valeur non nulle, presque systématiquement pour un marché de destination. Action : vérifier si l’enregistrement de l’identifiant d’expéditeur a expiré ou a été révoqué auprès de l’autorité de régulation du marché de destination (cause la plus fréquente), confirmer auprès de l’agrégateur local, basculer vers un identifiant d’expéditeur de secours enregistré pour le marché concerné si disponible, et relancer l’enregistrement. Le délai de récupération dépend de l’autorité de régulation, et non de la banque ; l’objectif de la procédure est de limiter l’impact de l’incident pendant cette période.

### Plan de jeu 3 — attaque coordonnée de pompage OTP

Signal : le coût par code OTP valide augmente fortement ; le volume de soumissions vers certaines plages de numéros (souvent proches des numéros surtaxés ou avec des préfixes de pays spécifiques) explose ; le taux de réussite de ces soumissions est quasi nul. Action : activez la liste blanche des préfixes de destination si ce n’est pas déjà fait (il s’agit du contrôle le plus efficace), limitez l’émission de codes OTP depuis les voies d’origine affectées, contactez l’équipe antifraude de votre fournisseur de messagerie. Rétablissement : désactivez la liste blanche une fois l’attaque terminée – pour la plupart des banques, il est déconseillé de la maintenir désactivée en permanence. Voir [HLR Lookup pre-flight](https://www.broadnet.me/products/hlr-lookup) comme solution structurelle pour atténuer ce type de problème.

## Des choix architecturaux qui rendent possibles les scénarios.

Les plans d'action reposent avant tout sur des décisions architecturales prises avant l'incident, et non sur des improvisations pendant celui-ci. Trois d'entre eux méritent une attention particulière.

- Au départ, mise en place d'un système d'authentification par mot de passe unique (OTP) multicanal : au minimum SMS et appel vocal ; idéalement, SMS, modèle d'authentification WhatsApp et appel vocal avec basculement automatique documenté. Le basculement est un mécanisme de contrôle, et non une solution de repli ; il doit être activable par route et par catégorie sans modification du code.
- La télémétrie de diffusion et de latence par canal et par opérateur est essentielle : sans elle, les tableaux de bord présentés ci-dessus ne sont qu’un vœu pieux. Les données doivent provenir du fournisseur de messagerie sous forme de flux DLR structurés, et non de rapports PDF mensuels.
- Inventaire documenté des identifiants d'expéditeur avec dates de renouvellement — ce registre devrait être géré par l'équipe de conformité de la banque, et non par le fournisseur de messagerie ; les lacunes dues à une négligence du fournisseur en matière de renouvellement restent à la charge de la banque lorsque le trafic cesse d'arriver.

## Discussion avec le fournisseur : quelles données doivent être renvoyées ?

Un contrat de messagerie de niveau bancaire spécifie les données opérationnelles renvoyées par le fournisseur, et pas seulement la grille tarifaire unitaire. Attendez-vous, au minimum :

- Webhooks DLR en temps réel que la banque peut authentifier (par exemple une [signature HMAC-SHA256](https://www.broadnet.me/answers/hmac-sha256-dlr-signing) à secret partagé si le fournisseur signe ses rappels, ou une liste d'adresses IP autorisées) afin que la banque puisse rapprocher les soumissions avec la livraison réelle dans son propre SIEM.
- Rapports quotidiens de livraison et de latence ventilés par opérateur de destination, ID de l'expéditeur et route, adaptés à l'intégration dans la pile d'observabilité de la banque.
- Résumés mensuels des incidents, incluant la chronologie, la cause première et les mesures d'atténuation, pour tout incident côté fournisseur ayant affecté le trafic de la banque.
- Des contacts directs pour les escalades au sein du centre d'opérations réseau (NOC) et de l'équipe de lutte contre la fraude du fournisseur, selon un accord de niveau de service (SLA) avec des délais de réponse définis.

> Le service [OTP](https://www.broadnet.me/products/otp) de BroadNet fournit des analyses de livraison, de latence et d'achèvement par canal et par opérateur sous forme de flux structurés — et la même couche de détection de fraude qui protège le côté opérateur est disponible pour les clients OTP d'entreprise sous forme de notation préalable des requêtes avant leur conversion en envois facturables.

## Préparation réglementaire — une dimension souvent négligée

Lors des inspections, les banques centrales et les autorités de régulation des services financiers posent de plus en plus de questions précises sur l'infrastructure de distribution des mots de passe à usage unique (OTP) : quel est le SLA ? quel est le mécanisme de basculement ? quelle est la piste d'audit ? comment les schémas de fraude sont-ils détectés et traités ? Les banques capables de répondre en cinq minutes à partir d'un dossier opérationnel standard réussissent sans problème ; celles qui doivent improviser leur réponse en plein contrôle échouent. Les indicateurs clés de performance (KPI) et les procédures mentionnés ci-dessus constituent les éléments de ce dossier ; il convient de les considérer comme des documents de conformité autant que comme des documents opérationnels.

## Un anti-modèle courant pour prendre sa retraite

De nombreuses banques intègrent l'OTP à leur service d'authentification plutôt que de le considérer comme un système autonome. Résultat : l'intégration de la messagerie est gérée par le développeur initial du flux d'authentification, souvent une personne ayant depuis changé d'équipe ; le suivi des données de distribution par opérateur est négligé ; le premier signe de dégradation est une augmentation soudaine des demandes d'assistance client, sans lien apparent avec un problème de messagerie. La solution réside dans la structure : un responsable désigné pour l'infrastructure OTP, accompagné d'une petite équipe permanente (ou d'une équipe partenaire clairement identifiée), un examen trimestriel du tableau de bord des indicateurs clés de performance (KPI) et un exercice annuel complet de simulation d'incident réaliste, basé sur les procédures décrites précédemment. Les fournisseurs de messagerie institutionnelle réalisent tous des revues trimestrielles conjointes avec leurs clients ; si ce n'est pas le cas du vôtre, demandez-le.

## Ce à quoi ressemble le bien, en chiffres

Une infrastructure OTP bancaire performante, acheminant les codes vers un marché réglementé du CCG via des routes directes d'opérateurs, avec la chaîne de secours et les contrôles antifraude décrits précédemment, devrait atteindre : un taux de réussite de bout en bout supérieur à 99 % (vérification effective du client, et non simple livraison), une latence p95 inférieure à cinq secondes sur le canal principal, un taux de rejet de l'identifiant de l'expéditeur nul, un taux de nouvelle tentative inférieur à 3 % (au-delà duquel l'expérience utilisateur et le coût se dégradent), et un taux de blocage des requêtes OTP pour fraude inférieur à 1 % du trafic légitime (les faux positifs sont importants ; un blocage trop systématique nuit à l'expérience client). Les banques dont les performances sont nettement inférieures à ces chiffres présentent en production une ou plusieurs des sept causes d'échec décrites dans le [guide de dépannage de la livraison des codes OTP](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting) ; un diagnostic est donc indispensable avant toute optimisation.

## Lectures complémentaires

- [Pourquoi les messages OTP échouent et comment résoudre les problèmes de livraison](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting)
- [Comment la vérification flash des appels affecte les revenus A2P des opérateurs](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact)
- [Stratégie de messagerie omnicanale pour le e-commerce et la logistique](https://www.broadnet.me/blog/omnichannel-messaging-ecommerce-logistics-strategy)
- Glossaire — [qu'est-ce qu'un OTP](https://www.broadnet.me/answers/what-is-otp), [qu'est-ce que le pompage de SMS](https://www.broadnet.me/answers/what-is-sms-pumping), [qu'est-ce qu'un DLR](https://www.broadnet.me/answers/what-is-dlr)
- Pages produits — [Service OTP](https://www.broadnet.me/products/otp) et [MyOTP voice OTP](https://www.broadnet.me/products/myotp)
- Couverture — [Routage conforme aux normes OTP et TDRA des Émirats arabes unis](https://www.broadnet.me/coverage/uae)