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

Chaque OTP envoyé par Prelude doit être transmis à l'un des opérateurs de notre réseau de partenaires SMS. Ce choix s'effectue en quelques millisecondes, sans intervention humaine, et détermine quel prestataire délivre le message. Choisir entre ces différents prestataires, pour chaque message individuel, c'est ce que Prelude appelle l'arbitrage.

Pour faire le bon choix, encore faut-il savoir quels prestataires délivrent réellement les messages. Chaque fournisseur de SMS met en avant ses taux de délivrabilité. Mais ce chiffre n'est pas comparable d'un acteur à l'autre, ce qui le rend inutile comme signal de classement.

« Chaque fournisseur ne fournit pas les rapports de remise de la même façon, et certains ont leur propre définition de ce qui est en transit et de ce qui est délivré », explique Hugo Bauer, ingénieur logiciel au sein de l'équipe infrastructure de vérification chez Prelude. « Le SMS étant une technologie relativement ancienne, selon les fournisseurs, nos données peuvent manquer de précision. » 

Certains prestataires considèrent le SMS comme délivré dès qu'il atteint l'antenne-relais. D'autres attendent qu'il arrive directement sur le téléphone. Cette disparité ouvre la porte à des dérives : un fournisseur sachant que le volume de trafic lui est attribué selon son taux de délivrabilité a tout intérêt à gonfler ce chiffre. « Ils peuvent être tentés d'augmenter artificiellement leurs taux pour capter davantage de trafic », détaille Hugo, « puisque nous répartissons le trafic entre les prestataires. » Le premier défi a donc consisté à surmonter ces divergences entre opérateurs télécoms. 

L'équipe de Prelude a donc décidé de créer son propre signal. L'API Verify intègre un endpoint /check que les clients appellent dès qu'un utilisateur saisit son code. Un check réussi signifie que le message est arrivé, que l'utilisateur l'a lu et qu'il a renseigné les bons chiffres. C'est ce que nous appelons la conversion. Aucune ambiguïté, aucune manipulation possible : l'utilisateur a reçu son code, ou il ne l'a pas reçu.

Cette décision a permis à Prelude de bâtir des fondations fiables, et c'est précisément pourquoi tant de clients font confiance à Prelude, où la priorité est d'assurer l'accès aux utilisateurs, et non de gonfler artificiellement les volumes de SMS ou les tentatives de validation.

Le fonctionnement du système initial

À l'origine, le système d'arbitrage était simple par conception. Pour chaque prestataire dans chaque pays, il calculait un score combinant taux de conversion et coût. Un fournisseur plus économique pouvait l'emporter sur un fournisseur convertissant mieux si l'équation financière le justifiait. C'était un bon point de départ, et cela a suffi pendant un temps.

Lorsque Hugo a rejoint l'équipe, celle-ci a affiné le modèle. Des écarts de performance commençaient à apparaître au niveau des opérateurs mobiles et des types d'appareils. « Nous avons commencé à capter beaucoup plus de signaux et à affiner la granularité », explique Hugo. « Auparavant, nous n'avions que des statistiques par pays, puis nous avons ajouté la granularité par opérateur et par appareil, car pour certaines raisons, les SMS passaient moins bien sur certains modèles Android ou iOS précis. » La logique est restée la même, mais l'évaluation est devenue bien plus précise : un score unique par fournisseur et par pays s'est transformé en un score par fournisseur, par opérateur et par type d'appareil. 

Puis un grand compte e-commerce a rejoint la plateforme, révélant une limite devenue impossible à ignorer : un score de conversion unique partagé entre tous les clients d'un même prestataire ne peut distinguer les clients dont la conversion varie 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 nouveau client, lui, avait placé l'étape d'OTP à la toute fin de son tunnel de commande, comme validation finale avant l'achat.

Cette différence s'est immédiatement reflétée dans les chiffres. « Le produit Prelude Verify était principalement utilisé pour permettre la connexion à une plateforme », précise Hugo. Pour les utilisateurs de ce client en particulier, le cas d'usage était radicalement différent. « Ils l'utilisaient à la fin du parcours d'achat pour confirmer une commande. Leur taux de conversion était donc bien plus bas, car certains utilisateurs demandaient un OTP sans jamais saisir le code. Ils changeaient simplement d'avis. »

L'utilisateur n'avait pas manqué de recevoir le message : il avait simplement renoncé à son achat. Les tunnels de paiement connaissent des abandons qu'on ne retrouve jamais lors d'une connexion. Une partie des 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 distribué ou pas.

Ce client générait un trafic suffisant pour représenter une part majeure du volume de Prelude sur certains marchés secondaires. Avec un tel poids, son taux de conversion structurellement plus bas tirait la moyenne globale vers le bas pour tous les prestataires. Le système d'arbitrage réagissait en basculant le trafic vers le prestataire suivant. Le score de ce dernier s'effondrait alors pour la même raison. « Le système fonctionnait toujours, mais il manquait cruellement de précision », commente Hugo.

Ce qu'un incident a mis en lumière

Cet incident chez un grand compte a mis en évidence trois phénomènes qui existaient en réalité depuis le début.

La fraude. Les attaques de fraude génèrent des demandes d'OTP qui ne seront jamais validées. Dans les rares cas où le trafic frauduleux passe à travers les mailles des outils de détection, ces tentatives non converties pénalisent le 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 certains prestataires, mais nous ne recevons jamais de checks. La conversion globale chute donc pour ces prestataires. » Le fournisseur le mieux noté encaisse le coup en premier. Son score s'effondre. Le trafic bascule vers le suivant. L'attaque suit le mouvement.

Découvrez notre article précédent dans la série consacrée à l'ingénierie si vous souhaitez savoir comment Prelude détecte et gère la fraude automatisée par agents.

Le filtrage des Sender ID. Prelude enregistre les identifiants d'expéditeur (Sender ID) auprès des opérateurs afin que les clients puissent envoyer des SMS sous leur nom de marque. Mais certains opérateurs bloquent les noms qu'ils jugent potentiellement trompeurs, et lorsque cela arrive, le phénomène est indétectable dans les statistiques globales. 

Un client utilisait ainsi un nom de marque contenant un terme générique du commerce de détail. Certains opérateurs avaient inscrit ce terme sur liste noire, les fraudeurs utilisant fréquemment des noms à consonance commerciale pour usurper l'identité de sites d'e-commerce. Les messages de ce client n'étaient pas du tout distribués par ces opérateurs, mais les statistiques globales du fournisseur semblaient pourtant excellentes, car seule une fraction de son trafic passait par ces routes concernées.

« Seuls quelques opérateurs filtraient ce nom, donc rien n'apparaissait au niveau macro », raconte Hugo. « Le fournisseur semblait performant chez ces opérateurs parce que les autres clients passaient sans problème, et le client semblait performant dans ce pays parce que les autres opérateurs distribuaient bien ses messages. On ne s'en rend compte qu'en isolant un client sur un opérateur donné, et là, ce n'est pas une simple baisse, c'est un mur. » 

Les bases de référence des clients. Certains clients convertissent naturellement moins bien que d'autres, non pas à cause du prestataire, mais en raison du fonctionnement même de leur produit. Une banque demandant à ses utilisateurs de s'authentifier ne convertit pas de la même manière qu'une application e-commerce demandant de confirmer un achat. « En moyenne, il y a un écart sur une même route », observe Hugo. « Une route correspond à un fournisseur dans un pays donné, et l'on observe environ 10 % d'écart d'un client à l'autre. » Autrement dit, le client A et le client B peuvent tous deux router via le même fournisseur dans le même pays et afficher 10 points d'écart de conversion, non pas parce que l'un est mieux distribué que l'autre, mais simplement parce que leurs utilisateurs n'ont pas le même comportement. Même prestataire, même pays, 10 points d'écart : le score décrivait en réalité le comportement des clients, pas la performance du fournisseur.

Conséquence directe dans ces trois cas : la moyenne partagée était incapable de faire la part des choses entre « ce fournisseur sous-performe » et « ce fournisseur achemine par hasard le trafic de clients qui convertissent différemment ».

Vers un modèle plus performant

Première tentative : plafonner la contribution des clients

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

Cette approche se heurtait à une limite majeure. « Nous retirions simplement une énorme quantité de données de l'équation », précise Hugo. « Dans certains pays où quelques clients génèrent l'essentiel du trafic, plafonner le volume par client risquait de fausser les statistiques globales par manque de données. »

Le plafonnement protégeait en théorie l'intégrité du score partagé. En pratique, il obligeait à écarter l'essentiel du trafic, et un score reposant sur un échantillon réduit et non représentatif n'est pas plus fiable qu'un score basé sur des données biaisées. Un problème chassait l'autre.

Deuxième tentative : des classements distincts par client

L'étape suivante a consisté à attribuer à chaque grand compte son propre modèle dédié, basé exclusivement sur ses propres données.

Cela a apporté un gain immédiat et très concret. « En nous basant uniquement sur leurs données, nous avons pu identifier des opérateurs qui ne délivraient pas à cause de ce problème d'enregistrement », explique Hugo. « Le système a automatiquement basculé vers d'autres prestataires. » Isoler les données d'un client a permis de révéler son problème de Sender ID pour la première fois.

Mais cela a posé un problème inverse pour les plus petits clients. « Le système a besoin d'un volume important de données pour être fiable », souligne Hugo, « et si l'on n'utilise que les données du client alors que son trafic est insuffisant, l'échantillon statistique est trop faible. Le niveau de confiance n'est pas assez élevé sur le résultat, et nous finissions par sélectionner les mauvais fournisseurs. »

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

Le système en production : combiner les données, miser sur les probabilités

Un client disposant de peu d'historique s'appuie d'abord sur les données globales, puis s'oriente progressivement vers ses propres données au fur et à mesure que son volume grandit. Le trafic est ensuite réparti entre les prestataires selon la probabilité que chacun soit le plus performant, plutôt que d'être attribué à un seul gagnant.

« Nous avons mis au point une formule qui utilise les statistiques globales », détaille Hugo, « et plus le client génère de trafic, plus il accumule de données, et plus nous utilisons ses propres métriques. Mais nous conservons toujours une part globale. C'est un équilibre entre données globales et données client, où le poids du client dans le score grandit avec son volume de données. »

La transition se fait en continu, sans palier brutal. Il n'y a pas de seuil rigide où le modèle bascule d'un coup.

Hugo illustre cela par un cas concret : « Prenons l'exemple d'un nouveau client e-commerce qui nous rejoint. Premier écueil : ses taux de conversion de base seront inférieurs à nos taux de conversion de référence. Second écueil : à son lancement, il n'a aucun trafic. Nous ne pouvons donc pas nous fier à ses statistiques. Nous démarrons avec les statistiques globales, et plus son trafic augmente, plus ses données propres entrent dans la pondération avec les données globales. »

Cette pondération repose sur un indice de confiance statistique plutôt que sur des segments arbitraires. « Pour un prestataire qui ne compte que dix tentatives par jour, la donnée n'est pas fiable sur le plan statistique », explique Hugo. « L'indice de confiance est insuffisant. Dans le nouveau système, nous avons élaboré une formule mathématique qui calcule cet indice. C'est sur cette base que nous sélectionnons les prestataires. Plus nous avons de données, plus notre confiance dans la performance du prestataire est solide. » 

« Pour les clients plus modestes, nous continuons d'utiliser les statistiques globales », ajoute Hugo. « Le système est donc performant pour les deux profils. »

Ce que cela change concrètement pour nos clients

Au quotidien, le bénéfice le plus tangible se traduit par une meilleure résilience plutôt que par une hausse spectaculaire des scores.

« Au jour le jour, la différence n'est pas spectaculaire », reconnaît Hugo. « Peut-être un léger gain de taux de conversion, mais très minime, de l'ordre d'un demi-point tout au plus. L'amélioration se ressent surtout en cas d'incident technique chez un prestataire, d'un souci d'enregistrement d'expéditeur ou d'une attaque de fraude non interceptée. Le système réagit et s'adapte en temps réel. »

La panne d'un prestataire survenue en août en a été la preuve directe. Prelude faisait alors tourner l'ancien et le nouveau système en parallèle, ce qui a permis une comparaison immédiate. « Nous avons eu un souci avec un prestataire qui ne délivrait plus aucun message », rapporte Hugo, « et le nouveau système s'est adapté bien plus efficacement que l'ancien. Il a réorienté le trafic d'un prestataire à un autre beaucoup plus vite. Le taux de conversion est resté bien plus stable pendant l'incident. »

Auparavant, cette stabilité exigeait une intervention humaine. « Lors de la première version de l'arbitrage, nous disposions d'outils de monitoring et nous repérions les anomalies, mais l'arbitrage ne réagissait pas de manière optimale. Nous devions couper des routes manuellement pour limiter l'impact sur le taux de conversion de nos clients. Aujourd'hui, tout se fait de manière automatique. »

Naviguer à l'aveugle : la prochaine étape

Une question reste ouverte : chaque client possède son propre taux de conversion de référence, indépendamment du prestataire qui achemine ses messages.

« Chaque client présente un comportement différent », observe Hugo. « Une application fintech ne réagit pas comme une application d'e-commerce. Nous mesurons donc les taux de conversion par client pour déterminer leur niveau de base, afin d'évaluer l'impact propre à chaque prestataire, sans nous limiter au seul taux de conversion brut. »

La prochaine étape consiste à évaluer la référence propre à chaque client, à la retrancher des résultats observés pour ce client, et à comparer les prestataires sur la base du différentiel restant. « Ce n'est pas qu'une question de volume », conclut Hugo. « C'est aussi lié au comportement des utilisateurs au sein de l'application, car cela influence directement leur parcours de connexion et leurs taux de conversion. »

Ces développements sont en cours, et l'architecture technique est déjà en place.

Hugo Bauer est ingénieur logiciel chez Prelude, spécialiste des infrastructures de vérification et des systèmes de routage.

Cet article fait partie de notre série technique Prelude, où l'équipe détaille les coulisses de nos solutions. En savoir plus sur le blog ou commencer à utiliser Prelude.