Deux ans de pilote automatique, un produit FinTech qui tourne, zéro maintenance. Jusqu'au jour où tout s'est effondré.
QuickFund a été rentable dès le premier mois. Micro-crédits, remboursements automatiques, scoring maison. Ça tournait. Alors j'y ai plus touché. Pendant deux ans. C'est la pire décision technique que j'ai prise.
50K€ de pertes parce que j'ai refusé de maintenir du code qui tournait. Pas un hack, pas le marché. Juste de la flemme technique.
Chronologie de l'incident
Lancement QuickFund
MVP fonctionnel. Scoring basique, interface minimale, process semi-automatisé. Rentable dès le mois 1.
Pilote automatique
Le produit tourne, je me concentre sur les autres filiales. Zéro mise à jour, zéro refactoring, zéro monitoring sérieux.
Premiers signaux
Quelques bugs remontés par les clients. Temps de réponse qui augmente. Je patche en urgence, je ne corrige pas la racine.
L'incident
Perte de données critiques. Des remboursements non comptabilisés. Des clients facturés deux fois. Le scoring qui retourne des résultats incohérents.
Décision radicale
J'arrête tout. Stop total. Aucun nouveau prêt. Audit complet du code, de la base de données, des process.
Restructuration
Réécriture complète. Nouvelle stack, nouveau scoring, nouveaux process. Le QuickFund d'aujourd'hui n'a rien à voir avec le MVP initial.
Décomposition des pertes
Remboursements perdus
Paiements reçus mais non comptabilisés dans le système
Double facturation
Clients débités deux fois, remboursements manuels
Prêts non recouvrables
Scoring défaillant ayant approuvé des profils à risque
Coût de restructuration
Temps, outils, audit externe
Total
Ce qui a causé le problème
La dette technique c'est du code que tu sais fragile mais que tu corriges pas. Des tests que tu écris pas. Un monitoring que tu mets pas en place parce que « ça marche ». Sur QuickFund j'avais accumulé :
Zéro test automatisé — chaque déploiement était un pari
Base de données sans contraintes d'intégrité — des doublons partout
Pas de système de logs — quand le bug arrive, tu sais pas quand ni pourquoi
API sans versioning — un changement cassait tout sans prévenir
Pas de backup automatisé — la base était le single point of failure
Ce que j'ai fait
La décision la plus dure c'est d'arrêter un produit qui rapporte de l'argent. Dire aux clients que je suspends les nouveaux prêts. Mais c'était ça ou continuer à patcher sur du code pourri.
Audit complet — 3 semaines pour cartographier chaque composant
Réécriture du scoring — algorithme revu, testé, validé manuellement
Migration de la base — PostgreSQL propre avec contraintes et indexation
Mise en place de tests — couverture à 85%+ avant tout redéploiement
Monitoring temps réel — alertes sur chaque anomalie financière
Process de déploiement — CI/CD, staging, validation humaine obligatoire
Les leçons
Cinq règles que j'applique maintenant dans chaque société du groupe.
Un produit qui tourne c'est pas un produit maintenu
Le fait que ça marche aujourd'hui garantit rien pour demain. Le code vieillit, les dépendances aussi.
Pas de code en prod sans tests
Si tu peux pas le tester, tu peux pas le déployer.
Le monitoring c'est pas optionnel
Tu dois savoir en temps réel ce qui se passe. Surtout quand tu gères de l'argent.
20% du temps dev = maintenance
Si tu planifies pas la maintenance, c'est l'incident qui la planifie pour toi.
Couper vaut mieux que patcher
Quand la dette est trop profonde, faut avoir le courage d'arrêter. Pas de continuer à mettre du scotch.
Le takeaway
50K€ parce que je pensais que « ça tourne » voulait dire « c'est solide ». C'était juste de la chance. Aujourd'hui QuickFund est plus robuste que jamais, mais j'aurais pu éviter tout ça en y passant 2h par semaine. La dette technique c'est un crédit sur ton futur toi, et les intérêts sont brutaux.
GL