Ils avaient levé 800 000 euros, recruté une équipe de cinq développeurs, et leur application devait révolutionner la gestion des vignobles occitans. Dix-huit mois plus tard, le CTO est parti, le code est inexploitable, et la trésorerie fond. Cette startup montpelliéraine n'est pas un cas isolé.
Reprendre un projet IT en difficulté est un exercice délicat. Mais c'est souvent moins coûteux que de tout recommencer à zéro, à condition de procéder méthodiquement.
Les signaux d'alerte qui auraient dû alerter
Avant d'analyser comment reprendre un projet, comprenons pourquoi ils échouent. Dans le cas de cette startup montpelliéraine, plusieurs signaux étaient présents dès les premiers mois :
- Absence de documentation : le code existait, mais personne ne savait exactement ce qu'il faisait
- Dette technique galopante : pour aller vite, l'équipe avait accumulé des raccourcis qui rendaient chaque évolution plus complexe
- Turnover des développeurs : trois départs en un an, chacun emportant sa connaissance du projet
- Scope creep : les fonctionnalités s'ajoutaient sans jamais rien retirer
- Tests inexistants : chaque modification risquait de casser autre chose
Étape 1 : L'audit technique sans complaisance
Avant de décider quoi faire, il faut savoir ce qu'on a. Un audit technique rigoureux examine :
L'audit doit être réalisé par quelqu'un d'externe au projet, capable de porter un regard objectif. Le résultat : un rapport clair indiquant ce qui est récupérable, ce qui doit être refait, et une estimation réaliste des efforts.
Étape 2 : La décision critique - réparer ou reconstruire ?
C'est la question à un million d'euros. Et la réponse n'est pas toujours celle qu'on espère.
- L'architecture de base est saine
- Le code couvre 60%+ des besoins
- La dette technique est localisée
- L'équipe originale peut transmettre
- Le time-to-market est critique
- L'architecture est fondamentalement inadaptée
- La sécurité est compromise en profondeur
- Chaque correction crée de nouveaux bugs
- Aucune documentation, aucun transfert possible
- Les technologies sont obsolètes
Dans le cas de notre startup, l'audit a révélé une architecture monolithique impossible à faire évoluer, des failles de sécurité critiques, et un code spaghetti où personne ne s'y retrouvait. Verdict : reconstruire le cœur applicatif en conservant certains modules périphériques.
Étape 3 : Sécuriser ce qui peut l'être
Même si on décide de reconstruire, il y a souvent des éléments à préserver :
- Les données : clients, transactions, historiques - c'est souvent l'actif le plus précieux
- Les specs fonctionnelles : même imparfaites, elles documentent les besoins métier
- Les retours utilisateurs : ce qui fonctionne, ce qui manque, ce qui frustre
- Les intégrations : API tierces déjà connectées, flux de données établis
- Le nom de domaine et le SEO : le référencement acquis a de la valeur
La sécurisation des données est prioritaire : avant toute manipulation, on sauvegarde tout, on documente l'existant, on fige un état de référence.
Étape 4 : Constituer la bonne équipe de reprise
Reprendre un projet en difficulté demande des compétences spécifiques. Ce n'est pas un projet greenfield où tout est possible : il faut composer avec l'existant, gérer la frustration, et avancer malgré les zones d'ombre.
Un développeur senior ayant déjà vécu des reprises de projets, capable de lire du code legacy, patient face à la documentation manquante, et suffisamment diplomate pour ne pas critiquer systématiquement les choix précédents.
Pour les startups montpelliéraines sans équipe technique interne, l'externalisation vers un partenaire spécialisé permet d'accéder à cette expertise sans les contraintes d'un recrutement.
Étape 5 : Planifier la reconstruction par phases
L'erreur classique : vouloir tout refaire d'un coup. La bonne approche : des itérations courtes avec des livrables tangibles.
Corriger les bugs critiques, sécuriser les données, documenter l'existant, mettre en place le monitoring.
Refonte de l'architecture, migration progressive des fonctionnalités essentielles, tests automatisés.
Migration des données, formation des utilisateurs, bascule en production, période de garantie.
Les coûts réels d'une reprise
Combien coûte la reprise d'un projet IT ? La réponse dépend de nombreux facteurs, mais voici des ordres de grandeur pour une application métier de complexité moyenne :
C'est souvent moins que le coût d'un projet from scratch équivalent, car on capitalise sur les apprentissages et les assets existants. Mais c'est rarement le budget initialement prévu par les fondateurs.
Éviter que ça se reproduise
Une fois le projet repris, comment éviter de retomber dans les mêmes travers ?
- Documentation obligatoire : chaque fonctionnalité documentée avant d'être considérée comme terminée
- Tests automatisés : couverture minimale de 70% du code critique
- Revues de code : aucun code en production sans relecture par un pair
- Dette technique trackée : un backlog dédié, traité régulièrement
- Bus factor > 1 : au moins deux personnes connaissent chaque partie du système
Pour les startups qui n'ont pas les ressources d'une équipe technique complète, un accompagnement externe régulier permet de maintenir ces bonnes pratiques sans exploser les coûts.
Le cas de notre startup : épilogue
Six mois après l'audit initial, l'application a été reconstruite sur des bases saines. Le périmètre fonctionnel a été réduit à l'essentiel, mais il fonctionne. La startup a dû lever un bridge de 200 000 euros pour financer la reprise, et retarder son lancement commercial de huit mois.
Aujourd'hui, elle compte 150 clients viticulteurs en Occitanie. Le CTO actuel, recruté après la crise, a mis en place une culture technique rigoureuse. La leçon a été douloureuse, mais elle a été apprise.
Si votre projet IT est en difficulté à Montpellier ou ailleurs, n'attendez pas que la situation devienne irrécupérable. Un audit précoce coûte quelques milliers d'euros. Une reconstruction d'urgence en coûte des dizaines de milliers.
