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.

  • 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.