Web Development
Quand un produit web ralentit, ce n’est pas toujours “le code”. Parfois, c’est l’architecture. Parfois, c’est le modèle de delivery. Et souvent, c’est le cumul de choix raisonnables à l’époque, devenus coûteux aujourd’hui.
Le bon arbitrage ne se résume pas à “on refait tout” ou “on patch”. Il se décide sur des signaux mesurables, une capacité d’équipe réelle, et un niveau de risque acceptable. Si vous voulez cadrer vite et proprement, Stralya intervient aussi en arbitrage reprise ou rebuild avec engagement de résultat.
Ce guide est volontairement orienté décision. Il donne une grille, des étapes, et les cas où chaque option devient un mauvais choix, même si elle “semble” la plus simple.
On recommande de formuler le problème en une phrase, avant d’ouvrir le code. Exemple : “livrer 8 features par trimestre sans régression” ou “diviser par 2,7 le temps de déploiement pour réduire le time-to-fix”. Sans cette cible, vous optimisez au hasard.
Ensuite, choisissez votre priorité dominante. Stabilité quand la prod est fragile. Vitesse quand le marché impose un rythme. Contrôle du risque quand la roadmap dépend d’un socle incertain, ou d’un audit à venir.
À partir du moment où vous comparez plusieurs options sur plusieurs critères, il faut une vue commune. Sinon, chaque partie prenante “gagne” avec ses propres métriques. Le tableau ci-dessous sert de base de discussion, pas de verdict automatique.
| Critère | Reprise ciblée de l’existant | Refonte progressive | Rebuild (nouveau socle) |
|---|---|---|---|
| Risque court terme | Faible si périmètre isolé | Moyen, dépend des migrations | Élevé au démarrage |
| Risque long terme | Monte si la dette reste | Diminue si trajectoire tenue | Faible si scope maîtrisé |
| Délai avant valeur | Semaines | Mois avec livraisons continues | Mois, valeur tardive |
| Coût de coordination | Bas, équipe réduite | Élevé, double run fréquent | Élevé, refonte produit + tech |
| Compatibilité roadmap | Bonne si peu de churn | Très bonne si découpage correct | Faible si roadmap bouge |
| Pré-requis d’architecture | Tests minimaux, observabilité | Strangling, contracts, CI/CD | Domain model clair, API strategy |
On recommande une reprise ciblée quand le produit a un noyau fiable, mais des zones “toxiques” identifiées. Typiquement, un module de facturation, une intégration ERP, ou un batch qui sature à chaque pic.
Les signaux concrets sont rarement esthétiques. Ils sont opérationnels, et mesurables sur 2 à 4 semaines.
On recommande une refonte progressive plutôt qu’un rebuild quand le produit doit continuer à livrer, tout en changeant de socle. C’est le cas le plus fréquent en B2B, avec contrats en cours, SLA, et intégrations qui ne peuvent pas “attendre la V2”.
La clé n’est pas “microservices vs monolithe”. La clé est le découpage et la gestion du double run : deux systèmes en parallèle, pendant une période plus longue que prévu, parce que la data et les usages ne migrent jamais en un week-end.
Ça surprend, mais on recommande parfois un rebuild parce que l’existant est devenu un système de contraintes. Si chaque feature demande de toucher 12 endroits, que le modèle de données est incohérent, et que la sécurité est “patchée”, la refonte progressive peut coûter plus cher qu’un nouveau socle bien cadré.
Le rebuild devient rationnel quand vous pouvez réduire le périmètre et verrouiller les exigences. Si le produit change toutes les deux semaines, repartir de zéro est un pari dangereux, même avec une excellente équipe.
On recommande une estimation en trois couches, parce que la précision n’est pas la même partout. Une équipe senior peut être précise sur un périmètre borné, et très incertaine sur un legacy non observé.
Pour arbitrer vite, utilisez une scoring simple, puis challengez les scores. Le but n’est pas de “mathématiser” une décision, mais d’éviter le débat circulaire.
| Axe | Question | Score 1 | Score 5 |
|---|---|---|---|
| Stabilité prod | Les incidents sont-ils localisés ? | Partout, causes variées | Zones claires, causes répétées |
| Capacité delivery | Peut-on livrer pendant le chantier ? | Non, tout casse | Oui, process et CI/CD solides |
| Clarté du domaine | Le métier est-il stable ? | Règles mouvantes | Règles stables et documentées |
| Complexité data | Migration data faisable par étapes ? | Non, couplage fort | Oui, domaines séparables |
| Contrainte conformité | Doit-on revoir sécurité et traçabilité ? | Refonte profonde nécessaire | Durcissement ciblé suffit |
Interprétation recommandée : si stabilité prod ≤ 2 et complexité data ≤ 2, un rebuild devient souvent le chemin le plus court vers un système maîtrisé. Si capacité delivery ≥ 4 et migration data ≥ 3, une refonte progressive est généralement le meilleur compromis. Si incidents localisés ≥ 4, une reprise ciblée est souvent plus rentable, à condition de traiter la cause, pas les symptômes.
Cette méthode suppose que vous pouvez observer la prod, accéder aux métriques, et faire parler les incidents. Si le produit est “air-gapped”, si les logs sont inutilisables, ou si l’accès aux environnements est verrouillé par un fournisseur, la première étape devient une remise à plat des accès et de l’exploitation.
Elle ne marche pas non plus si la décision est déjà politique. Si la direction veut “une V2” pour des raisons d’image, vous pouvez encore réduire le risque, mais vous ne ferez pas disparaître le coût d’opportunité. Dans ce cas, on recommande de verrouiller un périmètre minimal, une date de mise en service partielle, et des critères de décommission du legacy dès le départ.
La décision devient simple quand vous la rattachez à un risque mesuré, un périmètre borné, et une trajectoire de livraison. Si votre prod est stable et les douleurs localisées, une reprise ciblée est souvent le meilleur ROI. Si vous devez livrer tout en changeant le socle, la refonte progressive est la voie la plus sûre. Si le système est couplé partout et que la conformité ou la data imposent un changement profond, repartir de zéro peut être le choix le moins risqué, à condition de réduire le scope et de livrer par incréments.
Si vous voulez trancher en moins de 10 jours ouvrés avec un plan exécutable, contactez Stralya. On cadre l’option la plus rentable, on chiffre avec hypothèses explicites, puis on engage la delivery au forfait avec obligation de résultat. Envoyez votre contexte, vos contraintes, et vos accès d’observabilité, on vous répond avec une proposition de démarrage et un devis.
Le choix dépend de la priorité dominante : stabilité, vitesse ou contrôle du risque. Il faut formuler clairement l’objectif principal avant d’évaluer chaque option selon des critères mesurables comme le risque, le délai ou le coût de coordination.
La reprise ciblée présente un faible risque à court terme si le périmètre est isolé, mais peut augmenter la dette technique à long terme. La refonte progressive présente un risque moyen à court terme lié aux migrations, mais réduit la dette sur le long terme. Le rebuild a un risque élevé au démarrage, mais reste faible si le périmètre est bien maîtrisé.
Formuler le problème en une phrase claire permet de fixer une cible précise, évitant ainsi d’optimiser au hasard. Cela facilite la prise de décision et l’alignement des équipes sur des objectifs mesurables comme la fréquence de livraison ou la réduction du temps de déploiement.
La reprise ciblée permet de livrer de la valeur en quelques semaines, la refonte progressive nécessite plusieurs mois avec des livraisons continues, tandis que le nouveau développement (rebuild) implique un délai plus long avant d’obtenir une valeur significative.
Il est essentiel d’adopter une vue commune avec des critères partagés pour éviter que chaque partie prenante ne défende ses propres métriques. Un tableau comparatif basé sur le risque, les délais et les coûts de coordination peut servir de base d’échange sans imposer un verdict automatique.
{« @context »: « https://schema.org », « @type »: « Article », « headline »: « Refonte, reprise ou nouveau développement : quelle stratégie choisir ? », « description »: « Guide décisionnel pour CTO/CEO : reprendre l’existant, refondre ou repartir de zéro selon risques, budget, délais et dette technique. », « inLanguage »: « fr-fr », « articleSection »: « guide », « wordCount »: 2034}
{« @context »: « https://schema.org », « @type »: « FAQPage », « mainEntity »: [{« @type »: « Question », « name »: « Comment choisir entre refonte, reprise ciblée ou nouveau développement ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Le choix dépend de la priorité dominante : stabilité, vitesse ou contrôle du risque. Il faut formuler clairement l’objectif principal avant d’évaluer chaque option selon des critères mesurables comme le risque, le délai ou le coût de coordination. »}}, {« @type »: « Question », « name »: « Quels sont les risques associés à chaque stratégie ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « La reprise ciblée présente un faible risque à court terme si le périmètre est isolé, mais peut augmenter la dette technique à long terme. La refonte progressive présente un risque moyen à court terme lié aux migrations, mais réduit la dette sur le long terme. Le rebuild a un risque élevé au démarrage, mais reste faible si le périmètre est bien maîtrisé. »}}, {« @type »: « Question », « name »: « Pourquoi est-il important de formuler le problème avant d’agir ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Formuler le problème en une phrase claire permet de fixer une cible précise, évitant ainsi d’optimiser au hasard. Cela facilite la prise de décision et l’alignement des équipes sur des objectifs mesurables comme la fréquence de livraison ou la réduction du temps de déploiement. »}}, {« @type »: « Question », « name »: « Quelles sont les différences en termes de délai avant d’obtenir de la valeur selon la stratégie choisie ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « La reprise ciblée permet de livrer de la valeur en quelques semaines, la refonte progressive nécessite plusieurs mois avec des livraisons continues, tandis que le nouveau développement (rebuild) implique un délai plus long avant d’obtenir une valeur significative. »}}, {« @type »: « Question », « name »: « Comment éviter les biais dans la comparaison des options ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Il est essentiel d’adopter une vue commune avec des critères partagés pour éviter que chaque partie prenante ne défende ses propres métriques. Un tableau comparatif basé sur le risque, les délais et les coûts de coordination peut servir de base d’échange sans imposer un verdict automatique. »}}]}
