Sécurité et données
Ce que nous faisons de vos données, sans approximation
Un responsable de la conformité doit pouvoir répondre à son autorité de contrôle. Cette page dit où se trouvent vos données, ce que YARDA conserve et ne conserve pas, et comment les accès sont contrôlés et tracés. Elle dit aussi ce qui n’existe pas encore.
Hébergement
Où sont vos données
Toutes les données de la plateforme sont aujourd’hui hébergées aux États-Unis, hors de l’espace UEMOA.
| Composant | Prestataire | Lieu | Ce qui s’y trouve |
|---|---|---|---|
| Base de données | Neon (PostgreSQL) | États-Unis | Toutes les données : transactions, analyses, dossiers, déclarations, journal d’audit, comptes, modèles entraînés. |
| API et cache | Railway | États-Unis | Aucune donnée durable : le service lit et écrit dans la base ; le cache ne garde que des données temporaires. |
| Console et site | Vercel | Réseau mondial de diffusion | Aucune donnée durable : la console interroge l’API. |
Base de données
- Prestataire
- · Neon (PostgreSQL)
- Lieu
- · États-Unis
- Ce qui s’y trouve
- Toutes les données : transactions, analyses, dossiers, déclarations, journal d’audit, comptes, modèles entraînés.
API et cache
- Prestataire
- · Railway
- Lieu
- · États-Unis
- Ce qui s’y trouve
- Aucune donnée durable : le service lit et écrit dans la base ; le cache ne garde que des données temporaires.
Console et site
- Prestataire
- · Vercel
- Lieu
- · Réseau mondial de diffusion
- Ce qui s’y trouve
- Aucune donnée durable : la console interroge l’API.
Un hébergement plus proche de nos clients, dans la région ou chez l’établissement, est à l’étude : l’application n’a besoin que d’une base PostgreSQL, d’un cache Redis et d’un hôte de conteneurs. Le transfert de données hors de l’UEMOA peut appeler des formalités auprès de votre autorité de protection des données : parlons-en avant tout pilote.
Vos données
Ce que YARDA conserve, et ce qu’il ne conserve pas
YARDA n’a pas besoin de savoir qui sont vos clients pour analyser leurs opérations. Les identifiants sont remplacés dès l’arrivée, avant tout enregistrement, quelle que soit la voie : API, fichier, base de données, listes ou filtrage.
Des identifiants pseudonymisés
Clients, téléphones, portefeuilles, marchands, agents, points de retrait et appareils deviennent une empreinte à clé (HMAC-SHA256). La clé est propre à votre établissement : YARDA ne peut pas retrouver l’identifiant d’origine.
Des noms jamais conservés
Les noms et les adresses éventuellement transmis avec une transaction ne sont pas enregistrés. Les noms envoyés au filtrage des sanctions sont comparés en mémoire, puis oubliés.
Des opérations conservées en clair
Montant, devise, date, pays, corridor, canal, type d’opération, niveau de connaissance du client et votre référence de transaction : ce qu’il faut pour analyser et pour rendre compte.
Dix ans au moins, jamais moins
Les données de vos obligations de lutte contre le blanchiment sont conservées au moins dix ans et ne sont jamais supprimées automatiquement : leur suppression, une fois la durée passée, reste votre décision.
Les données pseudonymisées restent des données personnelles : la pseudonymisation réduit le risque, elle ne supprime pas les obligations. YARDA les traite en qualité de sous-traitant de votre établissement. Les comptes des utilisateurs de la console (nom, adresse e-mail) sont conservés en clair.
Isolation
Chaque établissement dans son propre espace
Vos données ne se mêlent jamais à celles d’un autre opérateur, ni dans les écrans, ni dans les modèles.
Un filtre appliqué à chaque requête
Chaque lecture et chaque écriture en base est restreinte à votre établissement par la couche d’accès aux données elle-même, et non écran par écran.
Des pseudonymes propres à chacun
Le même numéro de téléphone donne deux pseudonymes différents chez deux établissements : rien ne permet de rapprocher leurs clients.
Vos modèles, vos réglages
Modèles entraînés sur vos seules données, seuils, règles, listes et politique propres à votre établissement.
Accès
Qui peut faire quoi
Les droits suivent la fonction de chacun, et les actes sensibles demandent une confirmation de plus.
Quatre rôles
Lecture seule, analyste, superviseur, administrateur client. Chaque rôle comprend les droits du précédent, et l’API vérifie chaque droit, pas seulement l’écran.
Mots de passe et double authentification
Douze caractères au moins, stockés sous forme de hachage bcrypt, tentatives limitées. Double authentification par application (TOTP) avec codes de secours, que votre politique peut rendre obligatoire.
Des sessions maîtrisées
Jeton d’accès d’une heure, session renouvelée au plus sept jours par défaut, durée maximale réglable. Chacun voit ses sessions ouvertes et peut toutes les fermer.
Une confirmation pour les actes sensibles
Par défaut, les exports, l’approbation et la transmission d’une déclaration, l’activation d’une règle et la création d’une clé demandent à l’utilisateur de confirmer d’abord son identité.
Des clés d’API à droits limités
Conservées sous forme d’empreinte, affichées une seule fois, avec une durée de vie et des droits choisis. Une échéance de renouvellement peut être imposée, avec un rappel.
Le support YARDA, visible
Chaque accès de l’équipe YARDA à votre espace est listé dans la console. Votre politique peut le soumettre à votre accord, limité à 72 heures ; un accès d’urgence exige un motif et prévient vos administrateurs.
Traçabilité
Chaque acte laisse une trace vérifiable
Ce que l’on fait dans YARDA s’enregistre au moment où on le fait, et l’enregistrement ne peut pas être retouché.
Un journal d’audit chaîné
Chaque entrée porte l’empreinte SHA-256 de la précédente et s’écrit dans la même transaction que l’acte. La base refuse toute modification ou suppression d’une entrée.
Des déclarations scellées
Une déclaration transmise est figée et son empreinte affichée ; la console vérifie que la copie conservée n’a pas changé.
Des modèles vérifiés
Chaque modèle est vérifié par son empreinte SHA-256 au chargement : un fichier altéré est refusé.
Des secrets chiffrés
Les échanges passent par HTTPS. Les secrets de double authentification, les mots de passe des connecteurs et les clés remises par lien sont chiffrés, chacun par sa propre clé.
Sous-traitants
Les prestataires qui interviennent
Strictement pour les besoins du service, comme le décrit notre politique de confidentialité.
Neon
Base de données PostgreSQL, États-Unis, chiffrée au repos par l’hébergeur.
Railway
Hébergement de l’API et du cache, États-Unis.
Vercel
Hébergement du site et de la console.
Resend
Envoi des e-mails de la console : invitations, réinitialisations, avis. Reçoit l’adresse du destinataire.
Comet ML
Registre d’une partie des modèles d’IA de chaque client.
Un questionnaire de sécurité à remplir ?
Envoyez-le-nous : nous y répondons point par point, avec la même franchise que cette page.