Lundi matin, plus personne ne répond
Le scénario est toujours le même. Un email resté sans réponse depuis deux semaines. Un numéro qui ne sonne plus. Un message LinkedIn vu mais jamais répondu. Votre freelance a disparu. Ou votre agence a fermé. Ou votre développeur salarié a posé sa démission vendredi et part dans un mois — sans que personne d’autre ne comprenne le code.
Et pendant ce temps, votre application tourne. Vos clients l’utilisent. Votre chiffre d’affaires en dépend. Mais plus personne ne sait la faire évoluer, la corriger, ni même la surveiller.
Vous n’êtes pas seul. On a repris plus de 50 projets dans cette situation exacte depuis 2012. Des PME, des startups, des grands groupes. Des applications Rails vieilles de 8 ans, des apps React Native livrées à moitié, des back-offices PHP critiques sans un seul test. On en a tiré une méthode, des chiffres, et une conviction : dans 90% des cas, votre application est sauvable.
Le vrai piège : le devis de refonte
Voici ce qui se passe dans 80% des cas. Vous montrez le code à un nouveau prestataire. Il regarde, fronce les sourcils, et vous dit : “Honnêtement, il faut tout refaire.” Vous recevez un devis entre 100 000 et 250 000 euros. Vous êtes sous le choc, mais vous vous dites que c’est peut-être nécessaire.
Dans l’immense majorité des cas, c’est faux.
Michael Feathers, l’auteur de Working Effectively with Legacy Code (la bible de la reprise de code), écrit que presque tout code legacy est récupérable si on utilise les bonnes techniques. Le problème n’est pas le code. Le problème, c’est que le nouveau prestataire ne connaît pas le code — et réécrire est plus confortable qu’apprendre.
Sur nos 50+ reprises, on a recommandé une refonte complète 4 ou 5 fois. Le reste du temps, l’application existante était sauvable. L’écart de coût n’est pas anodin :
| Refonte complète | Reprise progressive | |
|---|---|---|
| Budget | 80 000 a 250 000 euros | 15 000 a 60 000 euros |
| Delai | 6 a 18 mois | 2 a 8 semaines pour stabiliser |
| Risque | Eleve (nouveau code = nouveaux bugs) | Faible (on part de ce qui marche) |
| Interruption | Oui, souvent | Non |
| ROI | 18+ mois avant retour | Immediat |
Vous avez recu un devis de 150 000 euros pour tout refaire ? Avant de signer, faites auditer par un tiers independant. Il y a de fortes chances que votre application soit sauvable pour une fraction de ce prix.
Pourquoi “attendre” est la pire decision
Chaque mois sans maintenance, c’est un risque supplementaire. Ce n’est pas une metaphore — c’est de la mecanique logicielle.
Les dependances vieillissent. Votre application utilise des dizaines de bibliotheques open-source. Chacune publie des mises a jour de securite. Sans personne pour les appliquer, les failles s’accumulent. L’OWASP Top 10 — le classement de reference des vulnerabilites web — place les composants obsoletes parmi les risques les plus courants.
Les certificats expirent. On a vu des applications tomber un mardi matin parce qu’un certificat SSL avait expire sans que personne ne le surveille. Un incident de ce type, c’est 1 a 3 jours d’activite perdue, plus la confiance de vos clients.
Les hebergeurs montent de version. Votre serveur tourne sur une version de PHP, Ruby ou Node qui sera bientot obsolete. Le jour ou l’hebergeur force la mise a jour, votre application peut cesser de fonctionner du jour au lendemain.
Le cout de l’inaction est mesurable. Selon l’etude Stripe sur la productivite des developpeurs, les equipes perdent en moyenne 23% de leur temps a gerer de la dette technique. Pour une application orpheline, ce chiffre monte en fleche : sans personne pour la maintenir, chaque intervention future coutera 2 a 5 fois plus cher qu’aujourd’hui.
Les 4 etapes pour reprendre le controle
Voici la methode qu’on applique depuis 14 ans. Elle fonctionne que votre application soit en Rails, React, PHP, Python ou n’importe quelle autre stack.
Etape 1 : Recuperez vos acces (jour 1 — urgence absolue)
Avant de penser code, verifiez que vous possedez la totalite de vos actifs numeriques. C’est la priorite absolue — tout le reste peut attendre.
Checklist des acces critiques :
- Code source — GitHub, GitLab, Bitbucket. Verifiez que l’organisation ou le depot est bien au nom de votre entreprise, pas au nom personnel du prestataire
- Hebergement — serveurs, base de donnees, stockage fichiers (AWS, OVH, Scaleway…)
- Noms de domaine et DNS — Gandi, OVH, Cloudflare. Qui est le titulaire du domaine ?
- Services tiers — Stripe (paiement), SendGrid (email), Firebase (notifications), analytics
- Stores mobiles — App Store Connect, Google Play Console. Les comptes sont-ils au nom de votre societe ?
- Secrets et cles API — variables d’environnement, fichiers de configuration
Si des acces manquent, c’est un probleme juridique avant d’etre un probleme technique. Le code que vous avez finance vous appartient (sauf clause contraire dans le contrat). Un avocat specialise en propriete intellectuelle peut envoyer une mise en demeure. Dans notre experience, ca suffit dans la majorite des cas.
Etape 2 : Faites auditer par un tiers independant (3 a 5 jours)
Un audit serieux n’est pas une estimation de devis. C’est un diagnostic medical de votre application. Il repond a trois questions :
- Securite — Y a-t-il des failles exploitables aujourd’hui ?
- Stabilite — L’application peut-elle continuer a tourner 3 mois sans intervention ?
- Evolutivite — Peut-on ajouter des fonctionnalites sans tout casser ?
Comme l’ecrit Martin Fowler, le createur du concept de refactoring, la question n’est jamais “ce code est-il beau ?” mais “ce code peut-il evoluer en securite ?”. Un code moche mais stable vaut mieux qu’une reecriture elegante qui ne livre pas.
Ce que l’audit produit concretement :
- Une cartographie de l’architecture existante
- Une liste priorisee des risques (critique / important / mineur)
- Une estimation chiffree : reprise vs. refonte, avec les couts associes
- Un plan d’action sur 8 semaines
C’est suffisant pour prendre une decision eclairee — et eviter les devis de refonte injustifies.
Etape 3 : Stabilisez d’abord (semaines 1 a 4)
La tentation, c’est de vouloir ajouter des fonctionnalites tout de suite. Resistez. Les premieres semaines doivent servir a une seule chose : rendre l’application maintenable.
Semaine 1 — Securiser. Corriger les failles critiques identifiees par l’audit. Mettre a jour les dependances les plus vulnerables. Activer le monitoring pour detecter les problemes avant vos utilisateurs.
Semaine 2 — Documenter. Cartographier les flux de donnees, les integrations tierces, les regles metier implicites. Michael Feathers appelle ca “characterization tests” : ecrire des tests qui decrivent ce que le code fait reellement, pas ce qu’il devrait faire. C’est la fondation de toute reprise reussie.
Semaines 3-4 — Consolider. Mettre en place l’integration continue, automatiser les deploiements, creer un environnement de test isole. Appliquer la Boy Scout Rule de Robert C. Martin : chaque fois qu’on touche a un fichier, on le laisse un peu plus propre qu’on ne l’a trouve.
Ce n’est pas la partie la plus gratifiante. C’est la partie indispensable. Sans elle, vous echangez un prestataire disparu contre un nouveau prestataire qui navigue a vue dans le meme code opaque.
Etape 4 : Ameliorez progressivement (en continu)
Une fois l’application stable et surveillee, on reprend les evolutions. Mais de maniere incrementale, en utilisant ce que Martin Fowler appelle le Strangler Fig Pattern : on enveloppe progressivement l’ancien code dans de nouvelles couches, sans jamais tout casser d’un coup.
Le principe est simple :
- Chaque changement est petit, teste et deploye individuellement
- On commence par les zones a plus forte valeur business
- L’ancien code continue de fonctionner tant que le nouveau n’est pas valide
- On mesure l’amelioration avec des metriques concretes (temps de deploiement, taux d’erreur, frequence des incidents)
Les equipes DORA mesurent la performance technique avec quatre metriques cles : frequence de deploiement, delai de mise en production, taux d’echec des changements, et temps de restauration du service. En 3 mois de reprise structuree, on voit typiquement ces metriques s’ameliorer de 40 a 60%.
Un cas concret : MyMove, le comparateur VTC
L’histoire de MyMove illustre parfaitement cette methode. Un comparateur de tarifs VTC en production, 5 APIs differentes (Uber, Bolt, Kapten, G7…), zero documentation, et un prestataire disparu.
On a suivi exactement les 4 etapes :
- Acces — Recuperation de tous les comptes et cles API aupres du fondateur
- Audit — Cartographie des 5 integrations en 3 jours. Verdict : code recuperable, mais fragile
- Stabilisation — Creation d’adaptateurs uniformes pour chaque API, mise en place du monitoring
- Evolution — Integration de nouveaux fournisseurs en 3 jours au lieu de 3 semaines
Resultat : incidents divises par 5, equipe autonome, cout total inferieur a 20% d’une refonte. Le detail technique est dans l’article du blog.
Les rares cas ou la refonte se justifie
Parfois, reprendre n’a reellement pas de sens. En 14 ans, on a identifie trois situations :
La technologie est morte. Plus de developpeurs disponibles sur le marche. Un framework que plus personne ne maintient. Une version de langage en fin de vie sans chemin de migration. On a vu des applications en CoffeeScript, en Backbone.js, en PHP 5.3. Parfois, le bassin de competences est tellement reduit que la reprise couterait plus cher que la reecriture.
Le code ne tourne plus du tout. L’hebergement a ete coupe, la base de donnees est corrompue, les backups n’existent pas. C’est rare, mais ca arrive.
Les besoins metier ont radicalement change. L’application a ete concue pour un modele d’affaires qui n’existe plus. C’est le cas de chocobonplan : apres 5 ans d’evolution, l’application React Native accumulait tellement de dette technique que chaque correction creait de nouvelles regressions. La reecriture etait la bonne decision — mais on l’a executee sans jamais couper l’ancien systeme.
En dehors de ces trois cas, la reprise progressive est presque toujours la meilleure option.
Le vrai cout de la decision
Voici ce que nos 50+ reprises nous ont appris sur les couts reels :
| Scenario | Cout typique | Delai | Risque |
|---|---|---|---|
| Audit seul (diagnostic) | 3 000 a 8 000 euros | 3-5 jours | Nul |
| Stabilisation urgente | 10 000 a 25 000 euros | 2-4 semaines | Faible |
| Reprise complete + evolution | 25 000 a 60 000 euros | 2-4 mois | Modere |
| Refonte complete | 80 000 a 250 000 euros | 6-18 mois | Eleve |
| Ne rien faire (cout annuel de l’inaction) | 30 000 a 80 000 euros | — | Critique |
La derniere ligne est celle qu’on oublie toujours. Ne rien faire a un cout : incidents, perte de clients, opportunites ratees, securite degradee. Ce cout est reel, meme s’il n’apparait pas dans une facture.
La bonne question a se poser
Votre application tourne. Elle rend service. Plutot que “faut-il tout refaire ?”, la bonne question c’est celle de Kent Beck : d’abord, faites que ca marche. Ensuite, faites que ce soit bien. Ensuite, faites que ce soit rapide.
Pour votre application orpheline, “faire que ca marche” signifie : securiser, documenter, stabiliser. Un audit de quelques jours suffit pour savoir ou vous en etes — et il vous protege contre les devis de refonte injustifies.
Votre prestataire est parti et vous ne savez pas par ou commencer ? On reprend des projets orphelins depuis 2012.