Temps d'exécution
De plusieurs heures à quelques minutes.
Algorithme de profilage de risques sur des millions de fiches KYC (fintech / conformité bancaire).
Mission · Refonte
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.
Pour qui
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.
Approche
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.
Exemples de résultats
Ce que ça donne en production.
Architecture
De la feuille blanche à une plateforme SaaS en production.
Plateforme de conformité bancaire conçue et déployée intégralement.
Stack mobilisé
L'outillage.
Node.js · TypeScript · NestJS · microservices · BullMQ · MongoDB · PostgreSQL · GraphQL · Docker · Azure · Domain-driven design.
FAQ
Les questions fréquentes.
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 diagnostic, 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ères-tu 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.
Interviens-tu 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 20 minutes pour cadrer ton contexte. L'audit reste la porte d'entrée recommandée.