Connecter ses données : fichiers, base de données, API

Trois façons d’envoyer vos transactions

• Un fichier, déposé dans « Import des données » : sans aucun développement, pour une surveillance après coup.
• Une vue de votre base de données, lue par YARDA à intervalle régulier : le quasi temps réel sans développement.
• L’API, appelée par votre système à chaque transaction : la seule voie qui permet d’arrêter une transaction avant son exécution.

Les voies ouvertes dépendent de l’offre de votre organisation : l’import de fichiers, les connecteurs de base de données et l’API en temps réel ne sont pas inclus dans toutes les offres. Quand une voie ne l’est pas, la console le dit sur la page concernée.

Importer un fichier avec Connect

« Import des données » est dans la section Connecter du menu des administrateurs ; analystes et superviseurs l’ouvrent par la recherche. Déposez un fichier CSV (virgule, point-virgule ou tabulation), JSON ou un classeur Excel (première feuille), jusqu’à 50 Mo. Rien n’est importé avant votre confirmation.

1. « Que faire de ces transactions » : « Analyser et alerter » pour des transactions récentes, notées et versées dans la file des alertes ; « Ajouter à l’historique » pour des transactions passées, conservées sans analyse pour apprendre le comportement habituel de vos clients.
2. « Faire correspondre les colonnes » : YARDA propose une colonne du fichier pour chaque champ qu’il reconnaît. Vérifiez-les une à une, avec l’exemple tiré de la première ligne ; les champs obligatoires sont signalés.
3. « Comment le fichier écrit les dates » : quand les premières lignes ne permettent pas de distinguer le jour du mois, choisissez le format vous-même.
4. Pour un historique, « Faire le bilan du fichier » le lit en entier sans rien importer : lignes exploitables et refusées, doublons, période couverte, part des lignes qui remplissent chaque champ de votre type d’activité, indicateurs du modèle que le fichier alimente, et si un premier modèle peut en apprendre (5 000 transactions sur ses 90 derniers jours, chaque jour de la semaine présent). Changer la correspondance ou le format des dates demande un nouveau bilan.
5. Lancez avec « Analyser les transactions » ou, après le bilan, « Ajouter à l’historique ». « Abandonner ce fichier » l’écarte sans rien importer.

La rubrique « Imports » suit chaque fichier : son état, les lignes traitées, analysées, ajoutées à l’historique, déjà connues et refusées. De là, « Voir les transactions analysées », « Télécharger les décisions » en CSV ou Excel, et les lignes refusées avec leur raison. Un fichier laissé en cours de vérification se reprend avec « Reprendre ».

Faire lire une vue de votre base de données

Votre équipe technique crée une vue de vos transactions et un compte qui ne peut que la lire. L’équipe YARDA configure ensuite le connecteur avec vous : l’adresse de la base, le compte, la colonne qui ordonne les lignes, la correspondance des colonnes et la fréquence de lecture, de chaque minute à une fois par jour. Le mot de passe est chiffré et n’est plus jamais affiché.

Le connecteur lit les bases PostgreSQL, MySQL et SQL Server. Le compte de YARDA ne doit pouvoir que lire la vue : pour SQL Server, qui n’a pas de session en lecture seule, un compte seulement membre de db_datareader, ou mieux limité à SELECT sur la vue ; YARDA refuse un compte qui peut écrire dans la base ou dans le schéma de la vue, ou modifier la vue elle-même, et nomme chaque droit à lui retirer. Ses lectures apparaissent dans « Imports », marquées « Base de données », et la page « Santé » signale un flux qui reste silencieux.

Brancher l’API

L’espace « Développeurs », dans Connecter, réunit ce dont vos développeurs ont besoin : « Clés d’API », « Référence », « Requêtes », « Temps de réponse », « Webhooks » et « Environnement de test ». L’administrateur client y gère les clés ; votre politique peut ouvrir les journaux aux superviseurs.

• « Créer une clé », en production (clés qui commencent par mto_) ou en test (mto_test_). La clé n’est affichée qu’une fois, à sa création, et n’est jamais envoyée par e-mail : conservez-la dans un coffre-fort de secrets. Les utilisateurs du compte sont prévenus de toute clé créée ou révoquée.
• « Requêtes » liste les appels faits avec vos clés : méthode, route, réponse, temps passé dans l’API et identifiant de la requête, jamais leur contenu.
• « Webhooks » : « Ajouter un point de réception » pour que YARDA prévienne votre système des alertes, des décisions et des gels légaux (posés, levés, confirmés), par un envoi signé avec un secret propre à chaque point. « Renouveler le secret » laisse l’ancien signer encore pendant la bascule.
• « Environnement de test » : des transferts fictifs de la zone UEMOA sur 90 jours, pour essayer vos appels sans jamais toucher votre production.

Chaque appel, ses champs et ses réponses sont décrits dans la documentation de l’API, publiée sur ce site.

Suivre la mise en service

Pour l’administrateur client, « Mise en service » montre les sept étapes qui mènent à un service complet : profil du client, utilisateurs de la console, envoi des transactions, historique pour apprendre, un modèle en service, seuils adaptés à votre trafic, premières transactions analysées. Chaque étape est lue dans les données, jamais cochée à la main. Dès que l’historique importé suffit, le premier modèle s’entraîne seul, ses typologies critiques rejouées, puis entre en observation : il note à côté des règles sans rien décider, et ses données d’apprentissage servent de contrat de données. Une personne le met en service depuis la page Modèles, au vu de ses mesures. L’entrée quitte le menu une fois toutes les étapes franchies, et reste accessible par la recherche. Sous les étapes, « Données à transmettre » liste ce que votre organisation envoie avec chaque transaction, selon son type d’établissement et son mode d’analyse : chaque donnée y est exigée, recommandée ou facultative, avec la part de vos transactions des trente derniers jours qui la porte.