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.
Ce que 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 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.
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. Chacun de ces signaux se relève et se consigne.
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. 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é.
Cette distinction est ce qui rend l’estimation honnête. 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 d’audit n’est pas un argument de vente. S’il est bien fait, il dit parfois que la reprise ne vaut pas la peine, ou qu’elle coûte plus que prévu. Cette honnêteté est précisément ce qui le rend fiable, et c’est elle qui distingue un audit sérieux d’une démonstration commerciale déguisée.
L’accompagnement Agenticiel pour 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. Agenticiel conduit ce travail d’audit avant tout engagement : on lit le code, on le fait tourner, on mesure la dette, et on rend un rapport qui distingue ce qu’on garde, ce qu’on renforce et ce qu’on réécrit, avec le coût de chaque poste.
La méthode commence par un audit facturé 1 500 euros, déduit du devis si le chantier part. On regarde réellement le code et la production, on mesure les signaux qui comptent, et on rend un rapport clair sur lequel vous pouvez décider. Vous ne vous engagez sur une reprise qu’après avoir vu les chiffres, pas avant.
Cette reprise est menée par une équipe de développeurs offshore francophones, basée à Madagascar. La sous-traitance de développement change le coût sans changer la rigueur de l’estimation : vous parlez directement à ceux qui ont lu votre code, en français, aux mêmes heures, et le devis repose sur ce qui a été mesuré, pas sur ce qui a été supposé.
Notre approche consiste à mesurer avant de chiffrer, et à chiffrer avant de s’engager : on lit le code, on le fait tourner, on distingue ce qui se garde de ce qui se réécrit, et on vous laisse décider sur des chiffres plutôt que sur une impression.