Due diligence technique : l’acheteur va aussi acheter vos problèmes
Deux projets de cession, un mois de préparation chacun : les personnes clés, licences, contrats et risques à documenter pour répondre aux questions de l’acquéreur.
Gridky, fintech de l’investissement immobilier, gère plus de 40 000 biens à travers 12 régimes fiscaux, avec des exigences de sécurité bancaire. Quand je suis arrivé, la course au marché avait laissé une dette technique considérable.
Chaque matin, je regardais des centaines d’exceptions tomber dans Slack. Le même défaut revenait sous plusieurs messages ; je les regroupais à la main. Plus personne d’autre ne lisait ce canal. Environ 10 bugs en production par semaine, des déploiements bi-hebdomadaires stressants : pour moi, nous avions atteint la banqueroute technique.
Le produit devait évoluer : simulateur financier, moteur de recherche avancé, standardisation OpenAPI. Mais rien de tout ça n’était possible tant que les fondations n’étaient pas solides.
La baisse d’environ 80 % est une estimation rétrospective. Les fréquences rapportées — environ 10 bugs par semaine puis 1 à 2 par mois après six mois — sont des ordres de grandeur distincts, pas la série utilisée pour calculer ce pourcentage. La période de six mois inclut les suites de la stabilisation ; elle ne désigne pas la pause des fonctionnalités, qui a duré un mois et demi.
Ce qui devait changer
Environ 10 bugs en production par semaine. Les alertes Slack étaient devenues du bruit de fond. Les déploiements bi-hebdomadaires étaient des événements stressants.
L’équipe courait après les bugs au lieu de construire le produit. La dette technique accumulée pendant la course au marché bloquait toute évolution.