Dans le paysage financier actuel, la vitesse et la fiabilité ne sont pas de simples fonctionnalités, mais des exigences de conformité. Concevoir un système de gestion de la relation client (CRM) pour le secteur Fintech nécessite un changement de paradigme par rapport aux systèmes monolithiques traditionnels basés sur des bases de données relationnelles et des appels synchrones. Dans ce guide technique, basé sur l’expérience de développement du système BOMA, nous explorerons comment une architecture event-driven (orientée événements) sur Google Cloud Platform (GCP) peut résoudre les défis d’évolutivité, de cohérence et de réactivité typiques du secteur.

Pourquoi une Architecture Event-Driven dans la Fintech ?

Un CRM Fintech ne se limite pas à stocker des fichiers clients. Il doit réagir en temps réel aux dépôts, aux changements de statut KYC (Know Your Customer), aux fluctuations du marché et aux interactions des utilisateurs. Une approche traditionnelle Request/Response (HTTP synchrone) crée un couplage fort entre les services, entraînant des goulots d’étranglement et des défaillances en chaîne potentielles.

L’architecture event-driven (EDA) inverse ce modèle. Au lieu que les services s’appellent directement, les composants émettent des “événements” (faits survenus, comme PaymentReceived ou LeadCreated) qui sont consommés de manière asynchrone par d’autres services. Selon la documentation de Google Cloud Architecture, ce modèle améliore considérablement la résilience et l’évolutivité du système.

La Stack Technologique GCP : Le Cas BOMA

Pour le projet BOMA, le choix de la stack technologique s’est porté sur des services gérés serverless afin de minimiser la surcharge opérationnelle et de maximiser l’évolutivité :

• Google Pub/Sub : La dorsale de messagerie pour l’ingestion et la distribution des événements.
• Cloud Functions (2e Gen) : Couche de calcul pour exécuter la logique métier en réponse aux événements.
• Firestore : Base de données NoSQL orientée documents pour l’état de l’application et les mises à jour en temps réel.
• BigQuery : Entrepôt de données pour l’analyse historique et les rapports de conformité.

1. Découplage avec Google Pub/Sub

Le cœur battant de l’architecture est Google Pub/Sub. Chaque action significative dans le CRM est publiée sous forme de message sur un Topic spécifique.

Modèle d’Implémentation

Imaginons le flux d’un nouvel utilisateur qui s’inscrit :

1. Le frontend appelle une API Gateway.
2. L’API publie un événement sur le topic user-onboarding.
3. Pub/Sub garantit la persistance du message et répond immédiatement au client (faible latence).

À ce stade, plusieurs Subscriptions (Abonnements) activent des workers indépendants :

• Sub A (CRM Core) : Crée le profil sur Firestore.
• Sub B (Compliance) : Lance les contrôles anti-blanchiment (AML) via un fournisseur externe.
• Sub C (Notification) : Envoie l’email de bienvenue.

Bonne Pratique Technique : Dans la Fintech, l’ordre des événements est critique (vous ne pouvez pas retirer des fonds avant de les avoir déposés). Nous utilisons les Ordering Keys de Pub/Sub (ex. l’ID utilisateur) pour garantir que les messages relatifs au même client soient traités dans un ordre séquentiel, tout en maintenant l’évolutivité parallèle sur différents utilisateurs.

2. Firestore : Base de Données Documentaire et Temps Réel

Le choix de Firestore par rapport à Cloud SQL est dicté par la nécessité de mises à jour en temps réel sur le tableau de bord des opérateurs du CRM. Firestore utilise des écouteurs (snapshot listeners) qui permettent au frontend de se mettre à jour automatiquement lorsqu’un document change, sans nécessiter de polling continu.

Modélisation des Données pour la Fintech

Bien que Firestore soit NoSQL, la structure des données doit être rigoureuse. Une structure typique pour un CRM Fintech pourrait être :

/users/{userId}
    - profileData (Map)
    - kycStatus (String)
    /transactions/{transactionId}
        - amount (Number)
        - currency (String)
        - status (String)
        - timestamp (Timestamp)

Attention au Hotspotting : Évitez d’utiliser des timestamps ou des ID séquentiels comme clés de documents si vous prévoyez des écritures massives (>500/sec), car cela concentre la charge sur une seule plage de clés. Utilisez des ID générés aléatoirement ou des hashs.

3. Logique Serverless avec Cloud Functions

Les Cloud Functions agissent comme le liant entre Pub/Sub et Firestore. Chaque fonction est un microservice atomique avec une responsabilité unique.

Exemple : Gestion de Changement d’État Pratique

Lorsqu’un contrôle KYC est terminé, un événement KycCompleted active une Cloud Function. Cette fonction :

1. Lit la charge utile (payload) de l’événement.
2. Exécute une Transaction Firestore pour mettre à jour le statut de l’utilisateur de PENDING à APPROVED.
3. Publie un nouvel événement UserActive pour débloquer les fonctionnalités de trading.

4. Le Défi de la Cohérence : Idempotence et Transactions

C’est la section la plus critique pour un CTO ou un Lead Engineer. Les systèmes distribués comme Pub/Sub garantissent une livraison “at-least-once” (au moins une fois). Cela signifie que, rarement, votre Cloud Function pourrait recevoir le même événement de paiement deux fois.

Solution : Idempotence

Pour éviter les doubles débits ou les états corrompus, chaque opération doit être idempotente. Voici comment l’implémenter dans Firestore :

1. Chaque événement Pub/Sub doit avoir un eventId unique (généré à la source).
2. À l’intérieur de la transaction Firestore, vérifiez si l’eventId a déjà été traité dans une collection de support processed_events.
3. S’il existe, la fonction se termine avec succès sans rien faire (le système reconnaît l’événement comme déjà géré).
4. S’il n’existe pas, la fonction exécute la logique métier et écrit l’eventId dans la collection de support, le tout de manière atomique.

Cette approche garantit l’intégrité des données financières même en cas de tentatives automatiques (retry) de la part de l’infrastructure Google.

5. Analytics Avancée avec BigQuery

Un CRM ne sert pas seulement à gérer, mais à comprendre. Les données opérationnelles sur Firestore ne sont pas optimisées pour des requêtes analytiques complexes (ex. “Quel est le taux de conversion moyen par région au cours du dernier trimestre ?”).

Pour cela, nous implémentons un pipeline de streaming vers BigQuery. Nous pouvons utiliser l’extension officielle “Stream Firestore to BigQuery” ou une Cloud Function dédiée qui écoute les changements sur Firestore et insère les données dans des tables partitionnées sur BigQuery.

Cela permet à l’équipe de Data Science d’analyser les entonnoirs de conversion et le comportement des utilisateurs sans impacter les performances de la base de données opérationnelle du CRM.

Conclusions

Construire un CRM Fintech avec une architecture event-driven sur Google Cloud offre des avantages indéniables en termes de découplage et d’évolutivité. Cependant, cela déplace la complexité de la gestion de l’infrastructure vers la gestion de la logique applicative (gestion des erreurs, idempotence, cohérence à terme).

En suivant les modèles décrits — l’utilisation rigoureuse de Pub/Sub pour la mise en mémoire tampon, Firestore pour l’état en temps réel et les contrôles d’idempotence transactionnels — il est possible de créer un système robuste capable de gérer les volumes et la criticité des applications financières modernes.

Foire aux questions