Une application en production qui vieillit, un legacy que plus personne n'ose toucher : le code source fait foi. Je reconstruis la spécification depuis le code, puis je réécris l'application avec une documentation complète et 100 % de couverture de tests. Vous récupérez un système que vous maîtrisez.
Le développeur d'origine est parti, la documentation manque ou a divergé du code. Plus personne n'ose toucher au système, et chaque évolution devient un risque. Le code source reste la seule vérité disponible : c'est de lui que repart la spécification.
L'application fonctionne et porte votre activité, mais la dette s'accumule : stack vieillissante, tests absents, évolutions de plus en plus lentes et risquées. La rétro-spec fixe ce que le système fait réellement, la réécriture le remet aux standards : documentation, tests, CI.
Dans les deux cas, la valeur est la même : reprendre le contrôle. La modernisation ne change pas ce que fait votre application — elle vous rend la capacité de la faire évoluer sans crainte, preuve à l'appui : chaque comportement est documenté et verrouillé par un test.
On ne forfaitise jamais l'inconnu, on forfaitise sa réduction. La rétro-spec est un cadrage au forfait dont le livrable ferme le périmètre : c'est lui qui rend la phase suivante chiffrable avec précision, et qui vous laisse libre de la confier à qui vous voulez.
Analyse du code source, outillée par mon pipeline agentique : reconstruction de la spécification fonctionnelle et technique, cartographie du système et de ses dépendances, identification des zones à risque. Livrable : la spec reconstituée, la cartographie et un plan de reprise comparant les scénarios en coût, risque et délai.
Exécution du scénario retenu : réécriture complète ou réécriture des parties bloquantes, à fonctionnalités identiques. Sur un périmètre fermé par la rétro-spec, la phase s'engage au forfait ; sur un périmètre encore ouvert, en régie. Standards complets : specs exécutables, revue, documentation, couverture de tests à 100 % (unitaire, intégration, E2E), CI/CD.
Une application modernisée se maintient. Le run est couvert par un abonnement de maintenance, avec le même niveau d'exigence que la réécriture. La spécification, la documentation et les tests produits vous appartiennent : le système reste réversible et reprenable par un tiers.
Les PME sans équipe d'ingénierie interne d'abord : le logiciel a souvent été construit à l'extérieur ou par un développeur parti depuis. Selon une étude Syntec, 64 % des PME ne disposent d'aucune documentation exploitable de leur patrimoine logiciel.
J'interviens en opérateur unique, en autonomie complète sur une branche isolée, avec votre validation finale comme seule porte. Aucune équipe à mobiliser chez vous, aucun processus interne à réorganiser.
Les plus grandes organisations sont également concernées, à l'échelle d'un module : un composant legacy critique, sans spécifications ni tests, peut être modernisé sans toucher au reste du système.
Les patrimoines applicatifs lourds de grands comptes, multi-équipes et critiques, relèvent d'un dispositif d'équipe et sortent du cadre de cette page.
Un module photo hérité sans spécifications ni tests, utilisé des millions de fois par mois. Rétro-ingénierie des spécifications, couverture de tests portée à 100 % (unitaire, intégration, E2E), modernisation du plugin. Stabilité nettement supérieure et baisse marquée des retours support.
Recommandé sur Malt par Philippe Acquier, Salim Laimeche, Nicolas Lapointe et 5 autres.
Par une rétro-spec : le code source fait foi. La spécification est reconstruite à partir du code existant, avec une cartographie du système et un plan de reprise. Sur cette base, l'application est réécrite avec documentation complète et couverture de tests totale. La démarche fonctionne même sans documentation et sans le développeur d'origine.
Une documentation rétroactive : la spécification fonctionnelle et technique est reconstruite en analysant le code source, seule source fiable quand la documentation manque ou a divergé. Le livrable comprend la spec reconstituée, la cartographie du système et un plan de reprise chiffrable. C'est cette étape qui ferme le périmètre et rend la suite forfaitisable.
Parce que c'est la couverture de tests qui transforme la réécriture en reprise de contrôle durable : chaque comportement décrit dans la spécification reconstruite est verrouillé par un test (unitaire, intégration, E2E). Les évolutions futures deviennent sûres, et le système reste vérifiable par un tiers.
Pas toujours. La rétro-spec produit un plan de reprise qui compare les scénarios en coût, risque et délai : réécriture complète, réécriture des parties bloquantes ou consolidation du code existant. L'arbitrage se fait sur pièces, avant tout engagement de développement.
Le run est couvert par un abonnement de maintenance, avec le même niveau d'exigence que la réécriture elle-même : revue, tests automatisés, CI. L'objectif reste la réversibilité : la spécification, la documentation et les tests produits vous appartiennent, et le système reste reprenable par un tiers.