Profilage KYC
Un temps d'exécution divisé par 12.
Algorithme de profilage de risques sur des millions de fiches KYC, mesuré en benchmark avant la mise en production.
Refonte d'un backend Node.js pour passage à l'échelle
Conception et mise en œuvre d'architectures Node.js capables d'absorber la croissance produit et la volumétrie. Pour les équipes dont le backend actuel tient sur le périmètre initial mais plafonne dès que la charge ou le modèle de données se complexifient.
Les signaux qui déclenchent cette mission.
La croissance révèle les limites
Ce qui tenait à 10k utilisateurs ne tient plus à 100k. Latences qui grimpent, jobs qui s'empilent, coûts cloud qui dérapent.
Couplage fort et déploiements lents
Une modification dans un module casse un autre, le monolithe demande une relecture complète à chaque release, et chaque déploiement prend plus d'une heure.
Base de données saturée
Les requêtes lentes se multiplient, les index ne suffisent plus, les traitements lourds bloquent les requêtes utilisateur. Le choix du modèle de données montre ses limites.
Ce que je fais concrètement.
-
Cartographie des points de rupture
Identification des goulots d'étranglement réels (mesure avant intuition) et séparation entre ce qui doit être refondu, réécrit, ou simplement ajusté.
-
Architecture cible pragmatique
Microservices, job queues (BullMQ), séparation lecture/écriture, modélisation DDD quand c'est justifié. Pas de sur-ingénierie : on découpe ce qui doit l'être, on garde ce qui tient.
-
Migration progressive
Mise en œuvre sans interruption de service. Chaque bloc migré est déployé, mesuré, validé avant de passer au suivant. Rollback possible à chaque étape.
Ce que ça a donné.
Architecture
D'une V1 à refondre à une V2 lancée et transmise.
Plateforme de conformité bancaire : architecture de la V2 conçue avec le CTO, algorithme de profilage et alertes développés de A à Z. L'équipe interne l'a menée jusqu'en production.
Stack technique
Les outils mobilisés sur ce type de mission.
Node.js · TypeScript · NestJS · microservices · BullMQ · MongoDB · PostgreSQL · GraphQL · Docker · Azure.
Questions fréquentes
Sur cette mission en particulier.
Faut-il forcément passer par une architecture microservices pour scaler un backend Node.js ?
Non. Les microservices sont un outil parmi d'autres et introduisent leur propre complexité (réseau, cohérence, observabilité distribuée). Pour certains cas, un monolithe modulaire bien découpé avec des job queues suffit largement. Le choix vient du contexte, pas d'un parti pris d'architecte.
Comment éviter d'interrompre le service pendant une refonte d'architecture ?
Par migration progressive. On isole les modules à refondre, on déploie les nouveaux en parallèle de l'existant (strangler pattern), on bascule le trafic par palier. Rollback possible à chaque étape. Aucune big bang release.
Quels volumes gérez-vous habituellement ?
Jusqu'à plusieurs millions d'enregistrements traités de manière asynchrone (BullMQ, workers dédiés) et des API soumises à plusieurs milliers de requêtes par minute. L'expérience fintech / conformité est particulièrement adaptée aux charges asynchrones lourdes.
Intervenez-vous sur le choix de base de données (MongoDB vs PostgreSQL) ?
Oui, le choix du stockage fait partie intégrante de la refonte. J'ai l'expérience des deux (MongoDB pour les modèles flexibles, PostgreSQL pour les besoins relationnels stricts), et je recommande celle qui sert vraiment le cas d'usage — pas celle qui est à la mode.
On en parle ?
Un premier échange de 30 minutes pour cadrer votre contexte, sans engagement.