# Plateforme de transferts d'argent Colombie → Venezuela Source: https://slash-digital.io/fr/case-studies/remittance-platform/ Réseau de transferts · Colombie → Venezuela Nous avons remplacé le système ASP.NET d'un réseau qui encaisse des pesos en Colombie et paie des bolivars au Venezuela. La nouvelle plateforme compte 8 rôles, un MFA obligatoire et chaque mouvement d'argent dans des fonctions Postgres. Démarrer un projet Voir la vidéo Un transfert Pago Móvil de bout en bout : le point de vente remplit le formulaire et confirme, consulte la liste du jour, puis l'opérateur ouvre l'ID dans sa file. Données fictives. En bref Nous avons remplacé le système ASP.NET Web Forms d'un réseau de transferts d'argent entre la Colombie et le Venezuela. La nouvelle plateforme couvre les 8 rôles de l'activité, du point de vente qui encaisse les espèces à l'opérateur qui paie en bolivars, avec un MFA obligatoire pour tous et chaque mouvement d'argent dans des fonctions de la base de données. Le premier commit date du 14 septembre 2026 ; fin octobre, la plateforme tournait avec les vrais utilisateurs du réseau. Client: Réseau de transferts · Colombie → Venezuela Secteur: Transferts d'argent et bureaux de change Où: Colombie → Venezuela Année: 2026 Livrables: - Plateforme web à 8 rôles - MFA TOTP et accès sur invitation - Argent géré dans des fonctions Postgres - Migration depuis SQL Server - Rapports avec export XLSX et CSV Services: - Logiciel sur mesure - Applications web - Cybersécurité 8, rôles, tous avec MFA obligatoire 132, tests automatisés, tous au vert 6 semaines, du premier commit aux vrais utilisateurs 01 Le contexte ## Un système Web Forms qui déplaçait de l'argent réel Le réseau travaille avec deux maisons de change et des points de vente en Colombie qui encaissent des pesos en espèces. Le point de vente crée le transfert vers un compte bancaire ou vers Pago Móvil, et vend des recharges téléphoniques et des forfaits TV sur un solde prépayé en pesos. Au Venezuela, les opérateurs paient depuis les comptes en bolivars de la maison de change et joignent le justificatif de la banque. Tout cela tournait sur une application ASP.NET Web Forms adossée à SQL Server. En septembre 2026, nous avons reçu l'app et une sauvegarde de sa base. Nous avons écrit le nouveau cœur de zéro, en gardant l'ancien système comme référence pour les règles métier et comme source de données. 02 Conception et réalisation ## L'argent ne bouge que dans la base de données Chaque opération d'argent est une fonction SECURITY DEFINER dans Postgres (Supabase, région sa-east-1), et le navigateur n'écrit jamais un solde. Derrière, on trouve une comptabilité en partie double, un schéma d'audit qui n'accepte que des insertions, des clés d'idempotence pour qu'un double clic ne crée pas deux transferts et des codes de confirmation liés au hash de chaque requête. Le schéma tient en 73 migrations et l'app appelle une centaine de fonctions distinctes. L'interface est en Next.js 16.4 avec React 19.2 et TypeScript, sur Vercel, avec 66 pages et 22 routes d'API. L'accès se fait uniquement sur invitation, avec MFA par app d'authentification (TOTP), 30 minutes d'inactivité au plus, 8 heures de session maximum et une seule session par utilisateur. Les justificatifs de paiement arrivent dans un bucket privé en quarantaine, passent par un scanner isolé et sont refusés si leur SHA-256 existe déjà. Les données de l'ancien système sont passées de SQL Server à Postgres avec un ETL écrit pour le projet. - 01 ### Le point de vente crée le transfert Il retrouve l'expéditeur et le bénéficiaire par numéro de pièce d'identité, choisit virement bancaire ou Pago Móvil et voit en direct le débit sur son solde et les bolivars reçus. Pago Móvil applique le taux × 1,01. Un code à 6 chiffres valide l'envoi, et un reçu sort avec son ID opérationnel. - 02 ### L'opérateur paie au Venezuela La file se met à jour toutes les 10 secondes et sépare le travail par maison de change. Ouvrir un ID le réserve à cet opérateur, qui choisit le compte source, téléverse le justificatif et voit la commission interbancaire de 0,3 % avant de payer. - 03 ### 8 rôles, 38 actions Point de vente, paiements, administrateur, distributeur, distributeur senior, achats, super-vendeur et vendeur. Les 38 actions soumises à permission découlent du rôle, et un administrateur peut autoriser ou bloquer une action pour une personne sans toucher à son rôle. - 04 ### 132 tests automatisés Vitest exécute 132 tests unitaires et de composants, tous au vert. Onze fichiers Playwright avec axe-core parcourent les flux complets et vérifient l'accessibilité, et GitHub Actions lance la CI. 03 Galerie ## Le projet en images 8 images · Ouvrez une image pour la voir en grand. Les transferts du jour du point de vente : vente, coût, marge et bolivars envoyés, avec filtres par statut et par canal et export XLSX et CSV. La confirmation sur téléphone : bénéficiaire, canal, montant, débit sur le solde du point de vente, taux et bolivars reçus. La file de paiements en direct, par maison de change : en attente, payés aujourd'hui, achats de bolivars à confirmer et maisons en retard. L'opérateur ouvre un ID : coordonnées du bénéficiaire, compte source, justificatif et commission interbancaire de 0,3 % avant de payer. Activation du MFA à la première connexion : QR code (flouté ici) ou clé manuelle, puis le code à 6 chiffres de l'app d'authentification. Permissions par utilisateur : des exceptions qui autorisent ou bloquent une action précise au-delà de ce que donne le rôle. Taux COP/VES par maison de change, dans un historique non modifiable : le plus récent s'applique, et le publier demande un code. Journal d'audit : qui a fait quoi et quand, avec action, entité, IP et résultat, dans des enregistrements que personne ne peut effacer. 04 Résultats ## Six semaines du premier commit à l'exploitation Entre le 14 septembre et le 29 octobre 2026, le dépôt a reçu 71 commits, avec des revues client les 6, 8 et 13 octobre. Fin octobre, la plateforme tournait avec les vrais utilisateurs du réseau, sur une URL accessible uniquement sur invitation. Nous n'avons pas encore de chiffres de volume ni de délais de paiement publiables. Le client est confidentiel : les captures utilisent des données fictives et deux maisons de change inventées, Andina et Orinoco. - Système ASP.NET Web Forms remplacé par une plateforme propriétaire - 8 rôles et 38 actions soumises à permission, MFA obligatoire pour tous - 73 migrations et une centaine de fonctions en base - 132 tests automatisés, tous au vert Questions fréquentes ## Les questions qu'on nous pose souvent **Pourquoi gérer l'argent dans des fonctions de la base de données ?** Parce qu'une seule fonction Postgres vérifie le solde, passe l'écriture en partie double et enregistre l'audit dans la même transaction. En cas d'échec, rien ne reste à moitié fait, et aucun navigateur ne peut écrire un solde. **Peut-on migrer les données de l'ancien logiciel de bureau de change ?** Oui. L'ETL du projet lit la sauvegarde .bak de SQL Server et la charge dans Postgres. Les soldes hérités servent de point de départ, et chaque mouvement suivant est passé par les nouvelles fonctions. **Le MFA est-il obligatoire pour tous les utilisateurs ?** Oui, pour les 8 rôles. L'utilisateur arrive sur invitation, choisit son mot de passe, active une app d'authentification par QR code ou clé manuelle, puis chaque connexion demande le code à 6 chiffres. Ce code n'est jamais envoyé par WhatsApp.