Comment décidez-vous quand refactoriser plutôt que de réécrire un système de zéro ?

Question

IT Interview Practice · Accepted Answer

Par défaut, **refactoriser**. Une réécriture n'est justifiée que lorsque le système existant ne peut plus évoluer pour répondre aux besoins à un coût acceptable, et que vous pouvez continuer à délivrer de la valeur pendant que vous le faites. La plupart des réflexes « il nous faut une réécriture » sont en réalité un problème de tech debt non géré que le refactoring incrémental résout avec beaucoup moins de risque.

## Comment je raisonne

- **L'architecture cœur est-elle encore viable ?** Si le modèle de données, les frontières et le runtime peuvent s'étirer vers les nouveaux besoins, refactoriser. Si les hypothèses fondamentales sont fausses (mauvais paradigme de stockage, aucune façon de scaler, fin de vie du langage/de la plateforme), une réécriture devient un vrai candidat.
- **Quelle est la fréquence de changement ?** Le code qui change rarement n'a pas besoin d'être joli. Concentrer l'effort là où l'équipe travaille au quotidien.
- **Comprenons-nous le comportement actuel ?** Une réécriture jette des années de connaissances encodées sur les cas limites. S'il n'y a ni tests ni spec, une réécriture réintroduira d'anciens bugs.

## Un cadre de décision

| Signal | Pencher refactor | Pencher réécriture |
| --- | --- | --- |
| L'architecture convient aux besoins | Oui | Non |
| Couverture tests/spec | Faible ou élevée | Assez élevée pour vérifier la parité |
| Livraison possible de façon incrémentale | Oui | Difficile, big-bang |
| L'équipe comprend le code | Oui | Non, et les auteurs d'origine sont partis |

## Arbitrages

- **Refactor :** moindre risque, livraison continue, mais lent sur une fondation vraiment pourrie.
- **Réécriture :** page blanche, mais vous payez une **taxe de gel des fonctionnalités**, portez un **coût de double maintenance**, et risquez le classique piège de sur-ingénierie du second système.
- Préférer la voie intermédiaire du **strangler-fig** : dresser le nouveau système à côté de l'ancien, router le trafic de façon incrémentale, supprimer l'ancien pièce par pièce. Cela donne les bénéfices d'une réécriture avec un risque de niveau refactor.

## Pièges

- Réécrire pour des raisons **esthétiques ou de CV**, pas pour un coût business.
- Sous-estimer le comportement caché ; toujours caractériser d'abord le comportement actuel avec des tests.
- Une réécriture big-bang sur plusieurs trimestres qui ne livre rien — l'élan et la confiance s'effondrent tous deux.

## Pourquoi c'est important

Le choix refactor-vs-réécriture est l'une des décisions à plus fort levier qu'un Tech Lead prend. Trompez-vous vers la réécriture et vous pouvez geler la livraison pendant un an et échouer quand même ; trompez-vous vers le refactor et vous saignez lentement de la vélocité. La présenter comme une décision de coût et de risque, pas de goût, est ce qui sépare le jugement senior de la préférence.

Signal	Pencher refactor	Pencher réécriture
L'architecture convient aux besoins	Oui	Non
Couverture tests/spec	Faible ou élevée	Assez élevée pour vérifier la parité
Livraison possible de façon incrémentale	Oui	Difficile, big-bang
L'équipe comprend le code	Oui	Non, et les auteurs d'origine sont partis

Comment je raisonne

Un cadre de décision

Arbitrages

Pièges

Pourquoi c'est important

Questions connexes