Prévention de la fraude Signifyd pour le Mexique et le Canada

Pilotage de l'implémentation de Signifyd, solution de prévention de la fraude au moment du paiement, sur les sites Salesforce Commerce Cloud de Lacoste, d'abord pour le Mexique puis pour le Canada, de la conception et du chargement des données historiques jusqu'aux ajustements après le go-live.

Contexte métier

Le canal de vente web représentait une part très importante et croissante des ventes de Lacoste, mais l'exposition à la fraude dans certains pays nécessitait des contrôles renforcés. Chaque commande frauduleuse générait des frais de gestion comme les disputes bancaires et les rétrofacturations (chargebacks). Lacoste avait déjà implémenté Signifyd aux États-Unis et au Brésil ; Signifyd attribue un score à chaque commande avant l'autorisation de paiement et prend la responsabilité des commandes qu'il valide. En tant que chef de projet digital pour la zone NORCAM (Amérique du Nord et centrale), responsable de l'implémentation au Mexique puis au Canada.

Contributions clés

Conception des appels API vers Signifyd avant l'autorisation de paiement Cybersource et paramétrage des règles d'acceptation et de refus en fonction du score.
Pilotage du projet de bout en bout entre le Mexique, la France et les États-Unis : planning, estimations, spécifications, cahiers de tests, plan de bascule et flash reports hebdomadaires.
Mise en place du chargement des données historiques (burn-in) depuis la base Salesforce afin que le scoring de Signifyd dispose d'un historique de commandes dès le premier jour.
Analyse des taux de refus élevés au démarrage et ajustement des paramétrages avec Signifyd, pour augmenter le taux d'acceptation.
Documentation de chaque point de paramétrage et de chaque développement, ce qui a permis de livrer le Canada en deux fois moins de temps que le Mexique.

Responsabilités en détail

Gestion de projet

Gestion de projet technique, planification, estimation et répartition des tâches
Flash report hebdomadaire sur l'avancement, les points d'attention et le reste à faire
Coordination des équipes à distance en France, aux États-Unis, au Mexique et au Canada
Relation avec l'éditeur Signifyd (paramétrage, réponses techniques)
Communication avec les équipes financières au Mexique chargées du suivi des impayés et des disputes bancaires

Analyse et conception

Analyse des écarts et ateliers
Conception des interfaces web services/API vers Signifyd
Corédaction et revue des spécifications techniques détaillées avant présentation aux responsables informatiques de Lacoste
Paramétrage des règles d'acceptation et de refus en fonction du score

Données

Extraction SQL de l'historique des commandes depuis la base Salesforce
Constitution des fichiers historiques au format Signifyd pour la burn-in period

Tests et mise en production

Cahiers de tests couvrant tous les scénarios, validés par le métier
Tests unitaires, d'intégration et de recette avec réunions quotidiennes
Plan de bascule : web services à activer, paramétrage à copier, montées de version, installations de plugins
Bascule de mise en production

Support

Hypercare avec état quotidien au métier (ventes en ligne, acceptées, refusées)
Suivi des anomalies, corrections manuelles et correctifs définitifs des incohérences de statuts
Ajustement des paramétrages Signifyd avec l'éditeur

L'enjeu

L'exposition à la fraude sur le site mexicain nécessitait des contrôles renforcés, et chaque transaction frauduleuse générait des frais de gestion comme les assurances ou les disputes bancaires. L'objectif était de remplacer les contrôles antifraude existants par Signifyd, d'améliorer le taux d'acceptation et de réduire la responsabilité liée aux rétrofacturations. Le modèle de Signifyd consiste à garantir les commandes qu'il accepte, Lacoste n'avait donc plus à s'occuper elle-même des impayés.

Le même projet avait déjà été réalisé pour les États-Unis et le Brésil, mais leur documentation n'était pas assez détaillée pour simplement le reproduire. Une grande partie du travail consistait à reprendre ces méthodes et à les réadapter à un nouveau pays, avec des équipes techniques en France, des responsables métier au Mexique et moi à New York.

Conception de la solution

Les sites de vente en ligne fonctionnent sur Salesforce Commerce Cloud, qui gère les prises de commande en ligne et la communication avec les entrepôts. Les paiements par carte passent par Cybersource, qui envoie le montant et le mode de paiement aux banques pour obtenir une autorisation. J'ai conçu l'intégration de sorte que Signifyd soit appelé avant l'autorisation Cybersource :

Le client passe commande sur le site Salesforce Commerce Cloud.
Avant l'autorisation, le site appelle Signifyd au travers d'une interface web services/API avec les données de la commande.
Signifyd évalue le risque à partir des informations sur le client, sa localisation, son mode de paiement et son historique, l'adresse de commande et de livraison, l'adresse e-mail et son historique, croisées avec son propre réseau.
Les règles d'acceptation et de refus que j'ai paramétrées transforment le score en décision.
La commande poursuit ensuite vers l'étape d'autorisation Cybersource avec la décision de Signifyd.

J'ai identifié chaque besoin technique (interfaces et points de paramétrage Salesforce), participé à la conception des interfaces, corédigé les spécifications techniques détaillées et effectué la revue de chaque document avant de le présenter aux responsables informatiques de Lacoste.

Données historiques : la burn-in period

La partie la plus importante du projet n'était pas l'interface mais les données. L'algorithme de Signifyd s'appuie sur l'historique : la toute première commande d'un client obtient un score plus faible, de même qu'une adresse e-mail différente de celle des commandes précédentes. Démarrer avec un historique vide aurait conduit à refuser de bons clients.

J'ai extrait le plus d'historique de commandes possible de la base Salesforce à l'aide de requêtes SQL et, avec l'équipe, constitué des fichiers au format attendu par Signifyd.
Les plugins Signifyd ont également été activés avant le go-live pour alimenter sa base avec des données réelles (la burn-in period). Pendant cette phase, nous avons dû résoudre des problèmes de cohérence dans les données extraites du prestataire de paiement.

Organisation du projet

Élément	Fonctionnement
Équipe	Deux personnes techniques en France (implémentation et paramétrage de Salesforce), les équipes finance et métier au Mexique, Signifyd, l'équipe du prestataire de paiement
Mon rôle	Chef de projet informatique : planning, estimations, répartition des tâches, relation éditeur, pilotage des tests
Phases	Cadrage, conception, réalisation, recette, go-live, support
Reporting	Un flash report hebdomadaire : statut des phases, indicateurs (périmètre, coûts, planning, organisation), risques et prochaines étapes
Tests	Cahiers de tests couvrant tous les scénarios, validés par le métier ; tests répartis dans l'équipe avec des réunions quotidiennes
Bascule	Web services à activer, paramétrage à copier, montées de version de la solution, installations de plugins

Deux risques que j'ai suivis de près : une date de go-live juste après une période de soldes et un gel du code informatique sur la même période.

Difficultés et solutions apportées

Taux de refus élevés après le go-live. Les premiers résultats ont été plutôt décevants, avec des taux de refus très élevés. J'ai analysé les causes grâce aux données récupérées et travaillé avec Signifyd pour ajuster les paramétrages de l'algorithme, assouplir certains critères et augmenter le taux d'acceptation. L'amélioration a été très visible pour le métier.
Incohérences de statuts. Certaines commandes apparaissaient en attente dans les systèmes Lacoste alors que Signifyd les avait validées. Je les ai d'abord corrigées manuellement pour que les commandes continuent d'avancer, puis j'ai proposé une solution permanente.
Visibilité après le go-live. J'ai assuré le suivi avec les outils de reporting de Signifyd et envoyé chaque jour au métier un état (ventes en ligne, acceptées, refusées) avec la liste des anomalies et leur statut de résolution. Pour la première fois, le métier disposait des chiffres réels d'acceptation et de refus au lieu d'estimations, et pouvait ainsi se fixer des objectifs de réduction de la fraude et comprendre la source des fraudes.

Canada

La documentation des États-Unis et du Brésil n'ayant pas suffi, j'ai documenté chaque action, point de paramétrage et développement pendant le projet Mexique. Lorsque Lacoste a lancé le Canada après le Mexique, j'ai réutilisé cette documentation et livré le Canada en deux fois moins de temps.

Ce que j'en retiens

Un outil antifraude ne vaut que par l'historique dont il dispose au démarrage. Planifier le chargement des données et la burn-in period comme un chantier à part entière, et documenter l'implémentation pour pouvoir la reproduire pays par pays, a compté davantage que la réalisation de l'interface elle-même.