La reconstruction de l'arbitrage : comment nous avons rendu notre scoring fournisseur plus intelligent

Chaque OTP envoyé par Prelude doit être confié à l'un des acteurs d'un réseau d'opérateurs SMS. Ce choix s'effectue en quelques millisecondes, sans intervention humaine, et détermine quel prestataire acheminera le message. Arbitrer entre ces prestataires, pour chaque message individuel, est ce que Prelude appelle l'arbitrage.

Pour faire le bon choix, vous devez savoir quels prestataires livrent réellement. Chaque fournisseur de SMS vous communiquera ses taux de délivrabilité. Mais ce chiffre n'est pas comparable d'un fournisseur à l'autre, ce qui le rend inutile comme indicateur de classement.

« Chaque prestataire ne fournit pas son rapport de délivrabilité de la même manière, et certains ont leur propre définition de ce qui est en transit et de ce qui est livré », explique Hugo Bauer, ingénieur logiciel au sein de l'infrastructure de vérification de Prelude. « Le SMS étant une technologie héritée du passé, nous pouvons, selon les prestataires, disposer de données inexactes. » 

Certains prestataires considèrent le SMS comme livré dès qu'il atteint l'antenne relais. D'autres attendent qu'il atteigne le téléphone lui-même. Cette incohérence ouvre la voie à un phénomène plus problématique : un prestataire qui sait que le trafic est attribué en fonction du taux de délivrabilité est incité à gonfler ce chiffre. « Ils peuvent tricher en augmentant artificiellement les taux de délivrabilité pour obtenir plus de trafic », explique Hugo, « car nous répartissons le trafic entre les prestataires. » Le premier défi consistait donc à surmonter ces écarts entre les opérateurs de télécommunications. 

L'équipe de Prelude a donc décidé de créer son propre indicateur. L' Verify API comprend un point de terminaison (endpoint) /check que les clients appellent lorsqu'un utilisateur saisit son code. Une vérification réussie signifie que le message est arrivé, que l'utilisateur l'a lu et qu'il a saisi les bons chiffres en retour. C'est ce que nous appelons la conversion. Pas d'ambiguïté, pas de manipulation. Soit l'utilisateur a reçu le code, soit il ne l'a pas reçu.

Cette décision a fourni à Prelude des fondations fiables, et c'est la raison pour laquelle de nombreux clients font confiance à Prelude, où l'accent est mis sur l'accès effectif des utilisateurs, et non sur le gonflement du nombre de SMS ou de tentatives.

Comment fonctionnait le système d'origine

Le système d'arbitrage d'origine était simple par conception. Pour chaque prestataire et dans chaque pays, il calculait un score combinant le taux de conversion et le prix. Un prestataire moins cher pouvait l'emporter sur un prestataire offrant une meilleure conversion si l'équation économique le justifiait. C'était un bon point de départ et, pendant un temps, cela a suffi.

Quand Hugo a rejoint l'équipe, celle-ci a apporté plus de précision. Des différences de performance apparaissaient au niveau de l'opérateur et de l'appareil. « Nous avons commencé à recevoir beaucoup plus de signaux et à affiner la granularité », explique Hugo. « Auparavant, il s'agissait uniquement de statistiques au niveau national, mais nous avons ensuite ajouté la granularité par opérateur et par appareil, car pour certaines raisons, les SMS étaient moins bien distribués sur certains modèles spécifiques d'Android ou d'iOS. » La logique restait la même, mais l'évaluation était désormais beaucoup plus fine : un score par prestataire et par pays est devenu un score par prestataire, par opérateur et par type d'appareil. 

Puis un client d'envergure dans l'e-commerce a rejoint la plateforme, et une limite de cette approche est devenue impossible à ignorer : un score de conversion unique partagé entre tous les clients d'un même prestataire ne permet pas de distinguer les clients dont les conversions diffèrent pour des raisons totalement indépendantes du prestataire lui-même.

Un cas d'usage inédit pour le modèle

La plupart des clients de Prelude utilisaient les OTP pour la connexion ou la création de compte. Ce client, quant à lui, plaçait l'étape de l'OTP à la toute fin de son tunnel d'achat, comme confirmation finale avant de valider la commande.

Cette différence s'est directement ressentie dans les chiffres. « Le produit Prelude Verify était principalement utilisé pour permettre aux utilisateurs de se connecter à une plateforme », explique Hugo. Pour les utilisateurs finaux de ce client particulier, le cas d'usage était totalement différent. « Ils l'utilisaient à la fin du processus d'achat pour confirmer une commande. Leur taux de conversion était donc beaucoup plus bas, car certains utilisateurs demandaient des OTP mais ne saisissaient pas le code reçu. Ils changeaient simplement d'avis. »

L'utilisateur n'avait pas manqué de recevoir le message. Il avait simplement décidé de ne pas finaliser son achat. Les tunnels de paiement comportent un taux d'abandon naturel que l'authentification ne connaît pas. Un certain pourcentage d'acheteurs abandonne son panier entre l'ajout d'un article et la confirmation, que l'OTP arrive ou non. Cet abandon se produit, que le SMS soit livré ou non.

Ce client générait un trafic suffisant pour représenter une part importante du volume de Prelude sur certains marchés plus restreints. Avec un tel poids, son taux de conversion structurellement plus bas tirait la moyenne partagée vers le bas pour tous les prestataires. Le système d'arbitrage réagissait en déplaçant le trafic vers le prestataire immédiatement suivant dans le classement. Le score de ce dernier s'effondrait alors pour la même raison. « Le système dans son ensemble n'était pas hors service, mais il manquait de précision », explique Hugo.

Ce qu'un incident a mis en lumière

L'incident lié à ce grand client s'est avéré être un révélateur de trois schémas sous-jacents qui existaient depuis le début.

La fraude. Les attaques frauduleuses génèrent des demandes d'OTP qui ne seront jamais saisies. Dans les rares cas où un trafic frauduleux franchit les barrières de détection, ces tentatives non converties plombent le score du prestataire qui les a acheminées. « Lorsque la fraude passe, elle ne convertit généralement pas », explique Hugo. « Nous envoyons donc des tentatives via des prestataires sans jamais recevoir de validations. Par conséquent, la conversion globale s'effondre pour ces prestataires. » Le prestataire le mieux classé est touché en premier. Son score s'effondre. Le trafic bascule vers le suivant. Et l'attaque suit le mouvement.

N'hésitez pas à consulter notre article précédent de la série technique si vous souhaitez découvrir comment Prelude détecte et gère la fraude pilotée par des agents.

Le filtrage des Sender ID (identifiants de l'expéditeur). Prelude enregistre les Sender ID auprès des opérateurs afin que les clients puissent envoyer des SMS sous le nom de leur propre marque. Mais certains opérateurs bloquent les noms qu'ils jugent potentiellement trompeurs, et lorsque cela se produit, c'est invisible dans les chiffres globaux. 

L'un des clients avait un nom de marque qui incluait un terme de distribution très courant. Certains opérateurs avaient placé ce terme sur leur liste noire, car les fraudeurs utilisent fréquemment des noms génériques à consonance commerciale pour usurper l'identité d'entreprises d'e-commerce. Les messages du client n'étaient pas du tout distribués par ces opérateurs, mais les statistiques globales du prestataire semblaient tout à fait normales, car seule une fraction de son trafic total empruntait les routes concernées.

« Seuls quelques opérateurs filtraient ce nom, donc rien n'apparaissait aux niveaux d'analyse que nous observions », explique Hugo. « Le prestataire semblait performant chez ces opérateurs car le trafic d'autres clients passait, et le client semblait s'en sortir dans ce pays car les autres opérateurs distribuaient ses messages. On ne s'en rend compte que lorsqu'on observe un client spécifique sur un opérateur précis, et là, ce n'est pas une simple baisse, c'est un mur. » 

Les comportements de base des clients. Certains clients convertissent naturellement à des taux inférieurs à d'autres, non pas en raison de la qualité d'un prestataire, mais à cause du fonctionnement même de leur produit. Une banque demandant à ses utilisateurs de s'authentifier n'obtient pas la même conversion qu'une application d'e-commerce leur demandant de confirmer un achat. « En moyenne, il y a une différence sur la même route », indique Hugo. « Une route correspond à un prestataire dans un pays donné, et il y a environ 10 % d'écart entre les clients. » En d'autres termes, un Client A et un Client B peuvent tous deux envoyer des messages via le même prestataire dans le même pays, et leurs taux de conversion respectifs peuvent afficher un écart de 10 points de pourcentage, non pas parce que l'un bénéficie d'une meilleure délivrabilité que l'autre, mais parce que leurs utilisateurs se comportent différemment. Le même prestataire, le même pays, un écart de 10 points. Le score décrivait en réalité les clients, et non le prestataire.

Dans les trois cas, le résultat était le même : la moyenne partagée était incapable de distinguer un « prestataire sous-performant » d'un « prestataire qui se trouve simplement à servir des clients aux comportements de conversion différents ».

Vers un modèle plus performant

Première tentative : Plafonner la contribution des clients

Le premier réflexe a été de limiter l'influence d'un client unique sur le score partagé. Si un client représente la moitié du trafic dans un pays, son poids est plafonné.

Cette approche présentait une limite fondamentale. « Nous retirions simplement une grande quantité de données de l'équation », explique Hugo. « Dans certains pays où une poignée de clients représente la majeure partie du trafic, si nous limitons le volume de données par client, les statistiques globales risquent de devenir trop imprécises par manque de données. »

Le plafonnement protégeait en théorie l'intégrité du score partagé. En pratique, cela revenait à écarter la majorité des données de trafic. Or, un score basé sur un échantillon restreint et non représentatif n'est pas plus fiable qu'un score basé sur des données biaisées. On remplaçait simplement un problème par un autre.

Deuxième tentative : Des classements distincts par client

L'approche suivante consistait à attribuer à chaque grand client son propre modèle dédié, construit exclusivement à partir de ses propres données.

Cela a permis d'obtenir un gain bien réel. « Comme nous n'utilisions que leurs propres données, nous avons identifié certains opérateurs qui ne distribuaient pas les messages en raison de ce problème d'enregistrement d'identifiant », explique Hugo. « Le système basculait alors automatiquement vers d'autres prestataires. » Le fait d'isoler les données d'un client a rendu son problème de Sender ID visible pour la première fois.

Mais cela a créé une difficulté différente pour les plus petits clients. « Le système a besoin de beaucoup de données pour bien fonctionner », explique Hugo, « et en n'utilisant que les données d'un seul client, si celui-ci n'a pas assez de trafic, l'échantillon statistique est trop faible. Nous ne pouvons pas nous fier au résultat. Par conséquent, nous choisissions les mauvais prestataires. »

Le dilemme était bien réel : les données par client apportent de la précision mais perdent en volume. Les données partagées apportent du volume mais perdent en précision.

Le système actuel : Emprunter les données, miser sur les probabilités

Un client sans grand historique commence par emprunter les données collectives, puis s'appuie de plus en plus sur ses propres données à mesure qu'il se développe. Le trafic est ensuite réparti entre les prestataires proportionnellement à la probabilité de chacun d'être le plus performant, plutôt que d'attribuer tout le trafic à un unique vainqueur.

« Nous avons simplement décidé d'appliquer une formule pour utiliser les statistiques globales », explique Hugo, « et plus ils gagnent en trafic, plus ils ont de données, et plus nous utilisons leurs propres données. Mais nous continuons à utiliser les données globales. C'est un mélange de données globales et de données client, et plus le client a de données, plus l'impact sur le score est important. »

La transition est continue, sans effet de seuil brutal. Il n'y a pas de moment précis où le modèle bascule d'un coup.

Hugo prend un exemple concret : « Disons qu'un nouveau client e-commerce arrive. Le premier problème est que ses taux de conversion de base seront inférieurs à nos taux de conversion de base de référence. Le second est qu'à ses débuts, il n'a pas de trafic du tout. Nous ne pouvons donc pas nous fier à ses statistiques. Nous allons démarrer avec les statistiques globales, et au fur et à mesure de sa montée en charge, ses données seront de plus en plus intégrées dans un mix entre les données globales et ses données propres. »

La pondération est construite autour de la confiance statistique plutôt que de catégories arbitraires. « Pour un prestataire qui n'enregistre que dix tentatives par jour, les données ne sont statistiquement pas fiables », explique Hugo. « Le niveau de confiance n'est pas suffisant. Dans le nouveau système, nous avons élaboré une formule mathématique qui calcule cet indice de confiance. C'est sur cette base que nous sélectionnons désormais les prestataires. Plus nous avons de données, plus nous sommes confiants dans la performance du prestataire. » 

« Pour les clients plus modestes, nous utilisons toujours les statistiques globales », ajoute Hugo. « Ainsi, le système fonctionne de manière optimale pour les deux profils. »

Où la différence se fait-elle réellement sentir pour les clients ?

La description la plus fidèle de l'impact au quotidien réside dans la résilience, plutôt que dans une hausse spectaculaire des performances.

« Au jour le jour, vous ne verrez pas de grande différence », tempère Hugo. « Peut-être une légère amélioration du taux de conversion, mais elle reste minime, de l'ordre d'un demi-point tout au plus. L'amélioration se manifeste réellement lorsqu'un problème technique survient chez un prestataire, un souci d'enregistrement ou autre, ou lorsqu'une attaque de fraude passe entre les mailles du filet. Le système va alors réagir et s'adapter en conséquence. »

La panne de prestataire survenue en août en est une illustration concrète. Prelude faisait tourner l'ancien et le nouveau système en parallèle, ce qui a permis une comparaison directe. « Nous avons eu un problème avec un prestataire qui ne délivrait plus aucun message », explique Hugo, « et le nouveau système s'est adapté bien plus efficacement que le précédent. Il a basculé d'un prestataire à l'autre beaucoup plus rapidement. Le taux de conversion est resté bien plus stable pendant l'incident. »

Auparavant, cette stabilité exigeait une intervention manuelle. « Lorsque la première version de l'arbitrage était active, nos outils de surveillance nous signalaient des anomalies, mais l'arbitrage ne réagissait pas correctement. Nous devions couper des routes manuellement pour limiter l'impact sur les taux de conversion de nos clients. Désormais, tout se fait automatiquement. »

Gérer les angles morts : La prochaine étape

Un défi reste à relever : les différents clients ont des taux de conversion de référence distincts, indépendamment du prestataire qui achemine leur trafic.

« Chaque client a un comportement qui lui est propre », explique Hugo. « Une application de fintech ne réagit pas comme une application d'e-commerce. Nous mesurons donc les taux de conversion par client pour connaître leur niveau de référence, afin de pouvoir évaluer l'impact de chaque prestataire de manière indépendante, sans nous limiter aux seuls taux de conversion bruts. »

La prochaine étape consiste à mesurer la référence propre à chaque client, à la soustraire de ses observations, et à comparer les prestataires sur la base de la différence restante. « Ce n'est pas qu'une question de volume », conclut Hugo. « C'est aussi lié à la manière dont les utilisateurs se comportent sur leur application, car cela influe directement sur leur processus de connexion et leurs taux de conversion. »

Ce chantier est en cours, et l'architecture pour le soutenir est déjà opérationnelle.

Hugo Bauer est ingénieur logiciel chez Prelude, spécialisé dans l'infrastructure de vérification et les systèmes de routage.

Cet article fait partie de la série technique de Prelude, où l'équipe partage les coulisses du développement du produit. Découvrez d'autres articles sur notre blog ou lancez-vous avec Prelude.