Quand une équipe reprend un produit existant, la tentation la plus forte est aussi la plus dangereuse : tout réécrire. Le code est ancien, il a des dettes, il manque de tests, et l’intuition dit qu’il serait plus propre de repartir de zéro. Cette intuition coûte cher, car elle jette par-dessus bord la seule chose que le produit possède réellement : le fait qu’il marche, qu’il a des utilisateurs, et qu’on sait ce qu’il fait.
Reprendre un produit, ce n’est pas le remplacer. C’est faire le tri entre ce qui doit disparaître et ce qui doit rester, en se fondant sur des critères objectifs plutôt que sur une préférence esthétique. Un code sans tests mais qui rapporte de l’argent ne mérite pas le même traitement qu’un code propre mais qui ne sert à rien. La valeur d’usage, pas l’élégance, doit décider.
Cet article propose des critères concrets pour décider quoi garder et quoi réécrire, puis un ordre de travail qui évite les deux pièges symétriques : la réécriture totale qui met le produit en danger, et l’immobilisme qui le condamne à une lente agonie technique.
Trier par la valeur, pas par l’émotion
Le premier réflexe à corriger est le jugement esthétique. Un développeur qui arrive sur un code ancien le trouve laid, et c’est normal : il n’a pas l’historique des décisions qui l’ont façonné. Mais la laideur n’est pas un critère de réécriture. Beaucoup de code laid fonctionne très bien, gère des cas limites que personne n’a documentés, et rapporte tous les jours. Le réécrire, c’est risquer de perdre ces cas limites sans rien gagner pour l’utilisateur.
Le critère qui compte est la fréquence de modification et la charge de travail qu’elle impose. Un module que l’on touche toutes les semaines et qui résiste à chaque modification est un candidat sérieux à la réécriture, car son coût se paie en continu. Un module que l’on ne touche jamais, même laid, peut rester en l’état : le coût de sa réécriture ne serait jamais amorti.
Un exemple concret : un module de génération de factures, écrit il y a cinq ans, que l’équipe modifie chaque mois pour suivre les évolutions de la réglementation. Chaque modification casse quelque chose ailleurs, chaque déploiement demande des tests manuels longs. Ce module mérite d’être réécrit, parce que son coût de maintenance est payé tous les mois. À l’inverse, un module de conversion de dates, figé depuis des années, peut rester tel quel sans que personne n’en souffre.
Garder ce qui marche, isoler ce qui bloque
La règle la plus utile d’une reprise tient en une phrase : on ne touche pas à ce qui marche. Cela paraît trivial, et pourtant c’est la première chose que les refontes oublient. On garde les modules stables, on garde les interfaces qui fonctionnent, on garde les données telles qu’elles sont. On ne réécrit que ce qui bloque réellement : ce qui casse, ce qui ralentit, ce qui empêche d’ajouter ce qui compte.
Cette approche suppose de distinguer trois catégories. Le cœur stable, que l’on ne touche pas. Les points de douleur, que l’on réécrit ou que l’on contourne. Et les zones intermédiaires, sur lesquelles on attend d’avoir plus d’informations. La tentation de tout classer dans la deuxième catégorie est forte, mais il faut la résister : chaque réécriture est un risque, et on ne prend des risques que là où la douleur est avérée.
La méthode du motif « étrangleur » illustre bien cette logique. Plutôt que de réécrire un module d’un bloc, on remplace ses morceaux un par un, en laissant l’ancien code servir les chemins non encore migrés. Le nouveau code grossit pendant que l’ancien rétrécit, sans jamais interrompre le service. C’est la façon la plus sûre de réécrire ce qui doit l’être sans mettre le produit en danger.
Décider par la preuve, pas par la rumeur
Avant de réécrire quoi que ce soit, il faut comprendre pourquoi le module fait mal, et cette compréhension ne vient pas de la lecture du code mais de la mesure. On pose des métriques sur les temps de réponse, sur les erreurs, sur la fréquence de modification, sur le temps passé en correction. Ce sont ces chiffres, et non des impressions, qui désignent les vrais candidats à la réécriture.
La mesure révèle souvent des surprises. Un module que tout le monde accusait d’être lent se révèle acceptable, et le vrai goulot est ailleurs, dans une requête de base ou un appel externe que personne n’avait remarqué. Inversement, un module que l’on croyait stable concentre en réalité la majorité des incidents. Sans mesure, on réécrit au hasard, et le hasard coûte cher.
Cette phase de mesure a un second bénéfice : elle produit le filet de sécurité dont la réécriture aura besoin. Des tests posés sur le comportement actuel du module, avant toute modification, permettent de vérifier après coup que le nouveau code fait exactement la même chose. Sans ces tests, toute réécriture est un saut dans le vide ; avec eux, elle devient une transformation contrôlée.
L’ordre d’une reprise réussie
L’ordre de travail d’une reprise suit une logique de risque décroissant. On commence par ce qui fait mal et que l’on maîtrise le mieux, pour installer la confiance. On enchaîne par les points de douleur les plus coûteux, ceux dont la correction débloque le plus de valeur. On termine par les zones stables que l’on documente et que l’on fige, pour qu’elles cessent d’être une charge mentale.
À chaque étape, on applique la même discipline : comprendre, mesurer, tester, puis seulement modifier. Cette discipline ralentit le début du chantier, mais elle l’accélère ensuite, car chaque étape s’appuie sur la précédente au lieu de la défaire. C’est la différence entre une reprise qui aboutit et une refonte qui traîne des mois avant d’être abandonnée.
Il faut enfin résister à l’envie de tout faire d’un coup. Une reprise se gagne par petits chantiers successifs, chacun livrable et vérifiable, plutôt que par un grand chantier dont la fin recule sans cesse. Chaque petit chantier terminé rend le produit meilleur, et c’est cette accumulation qui finit par transformer le code sans jamais le casser.
L’accompagnement Agenticiel pour reprendre sans tout casser
Faire ce tri entre ce qui se garde et ce qui se réécrit demande de la méthode et de l’expérience. Agenticiel accompagne les équipes qui reprennent un produit existant : mesure des points de douleur, cartographie du code, choix de ce qui reste et de ce qui change, et déroulement du chantier par étapes sûres.
Ce travail est mené par une équipe de développeurs offshore francophones, basée à Madagascar. La sous-traitance de développement vous donne la profondeur d’équipe nécessaire pour mener une reprise sans détourner vos développeurs de leur travail quotidien. Vous parlez directement à ceux qui reprennent le code, dans votre langue, aux mêmes heures.
Notre approche consiste à faire primer la valeur d’usage sur l’esthétique : on garde ce qui marche, on réécrit ce qui bloque, et on avance par petits chantiers livrables de façon à transformer le produit sans jamais l’interrompre.