Emmanuel SAUVAGE

11 min de lecture

Refonte Symfony ou évolutions ciblées : critères opposables en cadrage

Comment trancher entre gros chantier et itérations : dette mesurable, risques métier, coût marginal d’une feature — avec repères concrets pour un cadrage freelance.

  • Symfony
  • Architecture
  • Cadrage
Schéma : évolutions ciblées versus refonte large Itérations risque maîtrisé livrable court Refonte coût global transfert / QA Décision produit & technique

Ce que cette note ne fait pas

Elle ne remplace pas un audit sur votre codebase réelle. Elle fournit des critères opposables en atelier : vous pouvez les noter sur un tableau blanc et aboutir à une décision traçable (utile en freelance comme en comité interne).

Trois signaux qui penchent vers des évolutions ciblées

  • Les tests (même minimaux) existent sur la zone concernée — ou peuvent être ajoutés en une itération courte sans mock titanesque.
  • Le périmètre fonctionnel est clair : une file d’attente de tickets rédigés comme des scénarios reproductibles, pas une liste de « sensations ».
  • Les dépendances Symfony / PHP sont encore dans une branche maintenue : montée de version incrémentale possible sans sauter trois LTS d’un coup.

Trois signaux qui justifient une refonte (ou un morcellement)

  • Couplage métier / infrastructure illisible : la même couche mélange règles fiscaires, accès SQL brut, appels HTTP et configuration — aucun test ne peut être écrit sans simuler demi-prod.
  • Coût marginal d’une feature qui explose : chaque évolution touche 12 fichiers et crée des régressions hors périmètre (symptôme fréquent de « big ball of mud »).
  • Contrainte de conformité ou sécurité non rattrapable : sessions, journalisation, droits — quand la remédiation itérative coûte plus cher que réécrire un module borné.

Technique : encapsuler avant de « tout jeter »

Avant de lancer un big bang, un pattern utile sous Symfony consiste à borner le legacy derrière un service applicatif ou une façade, puis faire passer les nouveaux cas par du code testable : 

// Exemple d'intention : façade injectable, tests sur le contrat.
namespace App\\Pricing;

interface QuoteEngineInterface {
public function forOrder(OrderId $id): Quote;
}


final readonly class LegacyBackedQuoteEngine implements QuoteEngineInterface {
public function __construct(private LegacyPricingFacade $inner) {}


public function forOrder(OrderId $id): Quote {
    return $this->inner->buildQuote($id);
}


}

L’intérêt n’est pas la longueur du snippet — c’est le contrat : vous pouvez écrire un test sur QuoteEngineInterface et remplacer l’implémentation legacy plus tard sans arrêter le produit.

Comment j’utilise ce cadre en cadrage client

Je demande systématiquement une estimation en jours / semaines pour trois scénarios : patch ciblé, refactor de module, réécriture bornée — avec les hypothèses écrites (périmètre, risque métier, fenêtre de déploiement). Si les ordres de grandeur divergent d’un facteur 3 ou plus, on creuse avant de choisir.

FAQ

Faut-il toujours monter de version Symfony avant de refaire ?

Pas « toujours », mais une LTS récente réduit le risque et clarifie les chemins de migration (composants dépréciés documentés). À défaut, documentez explicitement la dette de version comme risque projet.

Les microservices règlent-ils le problème ?

Souvent non : sans frontières métier claires, on duplique le chaos réparti. Un monolithe modulaire bien borné reste souvent plus simple à faire évoluer pour une PME.