Reprise de code : estimer l'ampleur avant de s'engager

Reprendre un code existant est une des missions les plus délicates du développement, parce que l’ampleur réelle du travail ne se voit pas de l’extérieur. Un produit peut sembler fonctionner parfaitement et cacher une dette technique considérable, ou paraître chaotique et être en réalité solide. Signer un devis de reprise sans avoir mesuré ce qu’on reprend, c’est engager du temps et de l’argent sur une hypothèse.

L’estimation d’une reprise ne consiste pas à deviner, mais à lire le code, à le faire tourner, et à mesurer des signaux objectifs. Ce travail d’audit prend quelques jours, et il est le seul moyen de transformer une incertitude en chiffres. Sans lui, le devis se fonde sur une impression, et l’impression se paie en surprises.

Cet article décrit ce qu’il faut mesurer avant de s’engager, dans quel ordre, et comment transformer ces mesures en une estimation défendable qui protège à la fois celui qui reprend et celui qui confie.

L’ampleur d’une reprise ne se résume pas au volume de code

Le réflexe est de compter les lignes de code. C’est la mesure la plus facile et la plus trompeuse. Un gros volume de code simple se reprend facilement, un petit volume de code dense peut cacher une complexité redoutable. Le nombre de fichiers ne dit rien de la façon dont ils se tiennent entre eux.

Les signaux qui comptent sont ailleurs. La structure du projet : y a-t-il des modules, des frontières claires, ou un monolithe entremêlé. La présence de tests : peut-on changer quelque chose sans tout casser. L’état de la documentation et des dépendances : le code est-il à jour, ou figé sur des versions obsolètes. Ces signaux se lisent en quelques jours de lecture attentive, et ils donnent une bien meilleure idée de l’ampleur que n’importe quel comptage.

Faire tourner le code : la première vérité

Avant de mesurer quoi que ce soit, il faut faire tourner le produit. C’est la première vérité d’une reprise : un code qu’on ne parvient pas à lancer en local n’est pas estimable. Cette étape révèle l’état des dépendances, la présence d’une documentation d’installation, la facilité à reproduire l’environnement. Un projet qui se lance en une commande, par exemple grâce à un fichier Docker Compose, est déjà à moitié repris. Un projet qui exige des jours de configuration pour démarrer annonce une reprise longue.

Faire tourner le code donne aussi accès au produit tel qu’il est, et non tel qu’il est décrit. On constate les fonctionnalités réellement présentes, celles qui sont cassées, celles qui n’existent que dans les promesses. C’est à ce moment que l’écart entre ce qu’on croyait reprendre et ce qu’on reprend réellement se révèle, et il faut le mesurer avant de chiffrer.

Lire les chemins critiques en premier

On ne lit pas un code à reprendre de bout en bout, ce serait impossible et inutile. On lit d’abord les chemins critiques : ce qui touche à l’argent, ce qui touche aux données des utilisateurs, ce qui casse le plus souvent. Ces chemins concentrent à la fois le risque et la valeur, et ils donnent une image fidèle de l’état général du code.

Sur ces chemins, on cherche trois choses. Le degré d’enchevêtrement : combien de fichiers une modification traverse. La présence de tests : peut-on modifier sans craindre. La lisibilité : un développeur qui arrive peut-il comprendre l’intention en quelques minutes. Le résultat de cette lecture se traduit en une évaluation par zone, et c’est elle qui fonde l’estimation. Un assistant comme Claude Code ou Cursor accélère cette lecture (résumer un module, retrouver tous les appels d’une fonction), mais le jugement sur le risque reste celui d’un développeur.

Mesurer la dette technique en chiffres

La dette technique n’est pas une notion floue, elle se mesure. Le taux de couverture des tests, s’ils existent. Le nombre de dépendances obsolètes ou non maintenues. La fréquence des erreurs en production, si on y a accès. Le temps que prend un déploiement, et le nombre d’étapes manuelles qu’il suppose (un point que l’on traite en mettant en place une CI/CD). Chacun de ces signaux se relève et se consigne, avec des outils standards : le rapport de couverture de Vitest ou Jest, Dependabot ou npm audit pour les dépendances, Sentry pour les erreurs, SonarQube pour la duplication et la complexité. Sur un produit généré avec Supabase, on ajoute la vérification des règles d’accès aux données.

Ces mesures permettent de hiérarchiser la reprise. Un code sans tests mais bien structuré se reprend en posant des tests, ce qui est prévisible (c’est le cas typique du code généré par IA à refactorer). Un code enchevêtré avec des dépendances mortes exige d’abord un travail de découplage, ce qui est long et risqué. L’estimation finale découle de cette hiérarchie, et non d’un coefficient appliqué au volume.

L’estimation : chiffrer ce qu’on garde, ce qu’on renforce, ce qu’on réécrit

Une reprise sérieuse aboutit rarement à tout réécrire, et jamais à tout garder. L’estimation doit donc distinguer trois catégories. Ce qu’on garde, qui fonctionne et qu’on ne touche pas. Ce qu’on renforce, qui fonctionne mais manque de tests, de structure ou de documentation. Ce qu’on réécrit, qui est trop cassé ou trop mal conçu pour valoir la peine d’être sauvé. Les critères de ce tri sont détaillés dans reprendre un produit : ce qu’on garde et ce qu’on réécrit.

Cette distinction rend l’estimation fiable. Elle évite les deux dérives symétriques : le devis qui promet une refonte totale là où un renforcement suffit, et le devis qui sous-estime en promettant de tout conserver. Elle donne au client une visibilité sur ce qui est fait, pourquoi, et à quel coût, et elle protège le prestataire d’un engagement flou.

Le livrable d’un audit : un rapport, pas une promesse

L’audit qui précède l’estimation doit produire un rapport écrit : ce qui a été lu, ce qui a été mesuré, ce qui est gardé, renforcé, réécrit, et le coût de chaque poste. Ce rapport est le contrat de la reprise. Il transforme une mission opaque en un plan lisible, et il permet au client de décider en connaissance de cause, y compris de ne pas donner suite.

Un rapport bien fait peut conclure que la reprise ne vaut pas la peine, ou qu’elle coûtera plus que prévu. C’est ce qui en fait un véritable outil de décision.

Passer à l’action : estimer une reprise sans se tromper

Estimer l’ampleur d’une reprise de code, c’est d’abord la mesurer, et cette mesure ne s’improvise pas. Elle suit l’ordre décrit plus haut : faire tourner le code, lire les chemins critiques, chiffrer la dette, puis classer chaque zone entre ce qu’on garde, ce qu’on renforce et ce qu’on réécrit, avec le coût de chaque poste.

C’est ainsi que commencent nos reprises : l’Audit de reprise, 750 € en 3 jours. On lit le code, on observe la production, on mesure les signaux qui comptent, et on rend un rapport écrit sur lequel vous pouvez décider. Les produits construits avec Lovable, Bolt, v0, Cursor ou Claude Code passent par la même grille : ils se lancent souvent facilement, mais leurs chemins critiques méritent une lecture attentive.

Si vous vous apprêtez à confier ou à reprendre un produit, le détail de la démarche est sur la page reprendre et scaler un produit.