Reprendre une application Symfony mal codée par un autre prestataire : la méthode

Vous avez une application Symfony qui tourne, mais chaque évolution est une épreuve. Un seul développeur prétend la comprendre, les déploiements se font à la main et provoquent une montée d'angoisse, et personne n'ose toucher au cœur du code de peur de tout casser. Le prestataire qui l'a construite a disparu, ne répond plus, ou facture chaque correctif au prix fort. Vous héritez d'une base que personne n'a documentée et dont vous ne maîtrisez même pas tous les accès.

C'est une situation extrêmement fréquente, et la bonne nouvelle est qu'elle se traite avec méthode. Contrairement à l'intuition, la solution n'est presque jamais de tout jeter pour repartir de zéro. Cet article décrit la méthode en quatre phases que nous appliquons sur les missions de reprise d'applications Symfony héritées d'un autre prestataire, pour reprendre le contrôle, stabiliser, puis faire évoluer sereinement.

Reconnaître une application Symfony mal livrée

Avant de parler méthode, il faut savoir nommer le problème. Une application mal livrée ne se reconnaît pas à son apparence, qui peut être parfaitement soignée côté utilisateur, mais à une série de signaux côté ingénierie.

Le premier signal est la concentration de la connaissance sur une seule personne, le fameux bus factor de 1. Si un seul individu sait comment l'application fonctionne, vous n'avez pas un actif, vous avez une dépendance. Le deuxième signal est l'absence de tests automatisés sur le cœur métier : sans filet de sécurité, chaque modification devient une roulette russe, ce qui explique la peur de toucher au code. Le troisième est un déploiement manuel, long et stressant, sans procédure reproductible.

Viennent ensuite les signaux d'entretien négligé : une version de Symfony en fin de support, exposée à des failles non corrigées et bloquant toute montée de version de l'écosystème, des dépendances Composer abandonnées, et une accumulation de dette technique qui ralentit chaque nouvelle fonctionnalité. Pris isolément, aucun de ces signaux n'est dramatique. Réunis, ils dessinent une application que vous subissez au lieu de la piloter.

Pourquoi la réécriture complète est presque toujours une erreur

Face à ce constat, la tentation est grande de tout effacer pour repartir sur une base propre. C'est l'erreur la plus coûteuse possible, et le réflexe que tout prestataire sérieux devrait vous déconseiller.

Une application qui tourne en production, même mal codée, contient des années de règles métier implicites. Des cas particuliers, des correctifs accumulés face à des problèmes réels, des comportements attendus par vos utilisateurs : tout cela est encodé dans le code existant, souvent sans documentation. Une réécriture intégrale repart de zéro sur cette connaissance et reproduit les mêmes bugs que la première version avait fini par corriger, pendant de longs mois au cours desquels vous payez une nouvelle équipe sans livrer la moindre valeur nouvelle à vos clients.

Dans la quasi-totalité des cas, moderniser une application PHP legacy sans tout réécrire est moins risqué, moins cher et plus rapide à rentabiliser. La réécriture ne se justifie que lorsque le coût de remédiation dépasse réellement la valeur résiduelle de l'application, ce qui reste exceptionnel. Notre approche part toujours de l'existant plutôt que de la page blanche.

Phase 1 : reprendre le contrôle avant d'écrire la moindre ligne

La première phase ne contient aucune ligne de code. Elle consiste à reprendre la pleine possession de votre actif, ce qui est trop souvent négligé dans la précipitation.

Récupérer les accès et la propriété

Faites l'inventaire complet de ce que vous possédez réellement. Le dépôt Git avec son historique, les accès aux serveurs ou à l'hébergement, la gestion du nom de domaine chez le registrar, les enregistrements DNS, les secrets applicatifs, et les comptes des services tiers que l'application utilise : paiement, envoi d'e-mails, stockage, supervision. Il n'est pas rare qu'un client découvre à cette étape qu'il ne possède pas le domaine sur lequel repose tout son chiffre d'affaires.

Si l'ancien prestataire ne coopère pas, rappelez-vous que le code développé sur commande vous appartient dès lors que votre contrat prévoit une cession expresse des droits, ce qu'il faut vérifier avant toute démarche. Une demande écrite formelle, suivie si besoin d'une mise en demeure, débloque la majorité des situations. En parallèle, un repreneur compétent peut reconstituer une partie des accès à partir de ce dont vous disposez déjà.

Sécuriser le minimum vital

Une fois les accès en main, on sécurise immédiatement. La première action est de vérifier qu'une sauvegarde récente et restaurable existe, et de la tester, car une sauvegarde jamais restaurée n'est qu'une hypothèse. La deuxième est la rotation des secrets, surtout si les relations avec l'ancien prestataire se sont mal terminées : changez les mots de passe, régénérez les clés d'API, révoquez les accès devenus inutiles. La troisième est un état rapide de la sécurité de l'application, à commencer par la version de Symfony et de PHP et l'exposition à des vulnérabilités connues.

Phase 2 : l'état des lieux technique

Le contrôle repris, on dresse un diagnostic objectif. Cette phase ressemble à un audit, mais avec un objectif opérationnel : décider quoi faire, dans quel ordre. Elle est plus légère qu'une due diligence technique menée en contexte de rachat, dont l'enjeu est de valoriser un actif, mais elle en partage les outils.

On part de l'analyse statique. PHPStan configuré au niveau le plus élevé que la base supporte révèle en quelques minutes l'ampleur des problèmes de typage et de cohérence. On mesure ensuite la couverture de tests automatisés réelle, en distinguant les tests qui protègent vraiment le métier du décor qui ne teste rien. On scanne les dépendances avec la commande officielle composer audit, on identifie le code mort qui pollue la lecture, et on repère les anti-patterns structurels.

Le point décisif est de croiser ces constats avec l'historique Git. Un module complexe mais stable, que personne ne modifie jamais, n'est pas une urgence. Un module complexe et constamment retouché est un point chaud qui concentre le risque. Cette priorisation par la fréquence de modification distingue un audit de code PHP utile d'une simple liste de défauts sans hiérarchie.

Phase 3 : stabiliser, documenter, réduire le bus factor

Avec une cartographie claire, on stabilise avant d'ajouter quoi que ce soit de nouveau. L'objectif de cette phase est simple : être capable de déployer en confiance.

On commence par poser des tests de non-régression sur les parcours métier critiques, ceux dont une panne coûte directement de l'argent ou des clients. Ces tests ne visent pas une couverture parfaite, mais un filet de sécurité sur ce qui compte vraiment. On met ensuite en place une pipeline d'intégration et de déploiement minimale, qui exécute l'analyse statique et les tests à chaque modification et automatise la mise en production, pour transformer le déploiement angoissant en non-événement.

En parallèle, on s'attaque au bus factor en documentant l'essentiel. Une documentation technique structurée selon l'approche Diátaxis suffit à rendre le projet transmissible : architecture générale, décisions structurantes, procédures d'exploitation. L'objectif n'est pas d'écrire un roman, mais de faire en sorte qu'un développeur Symfony senior puisse livrer une évolution non triviale en quelques jours, et non en quelques semaines de rétro-ingénierie.

Phase 4 : faire évoluer sereinement

Une fois la base sous contrôle, l'évolution redevient possible sans angoisse. La règle d'or de cette phase est de prioriser la remédiation par la valeur métier, pas par la perfection technique.

Toutes les imperfections d'une base héritée ne se valent pas. Certaines ralentissent réellement la roadmap ou exposent à un risque, d'autres sont seulement inélégantes et peuvent attendre. Un bon plan de remédiation séquence les chantiers en fonction de leur impact sur votre activité, et intègre les éventuelles montées de version dans un guide de migration progressif, en s'appuyant sur le guide officiel de montée de version majeure plutôt que sur un grand saut risqué. La référence du calendrier des versions Symfony sert de boussole pour planifier ces montées sans subir les fins de support.

L'évolution se fait alors de façon incrémentale, chaque livraison s'appuyant sur le filet de tests et la pipeline mis en place à la phase précédente. Vous passez d'un mode défensif, où l'on évite de toucher au code, à un mode offensif, où l'on crée à nouveau de la valeur.

Choisir le bon prestataire pour la reprise

La reprise d'un projet existant est un exercice différent du développement d'une application neuve, et tous les prestataires n'y sont pas à l'aise. Choisir le bon prestataire Symfony pour cette mission demande de repérer quelques signaux.

Le premier signal positif est la posture du diagnostic. Un partenaire sérieux veut comprendre l'existant avant de s'engager et propose un pré-audit. Le signal d'alarme inverse est celui qui, avant même d'avoir lu une ligne de votre code, vous recommande de tout réécrire : c'est souvent plus confortable pour lui que pour vous. Le second critère est la capacité à inscrire la reprise dans la durée, à travers une tierce maintenance applicative qui sécurise votre application au-delà du diagnostic initial. La reprise de projet Symfony n'est pas un acte ponctuel, c'est le début d'une relation de confiance retrouvée.

Conclusion

Hériter d'une application Symfony mal codée par un autre prestataire n'est pas une fatalité, et encore moins une condamnation à tout réécrire. C'est un problème qui se traite avec méthode : reprendre le contrôle de ses accès, dresser un état des lieux objectif, stabiliser pour déployer en confiance, puis faire évoluer en priorisant la valeur. Chacune de ces phases réduit votre dépendance et augmente la valeur de votre actif.

La première étape est toujours la plus simple : poser un diagnostic. Si vous reconnaissez votre situation dans cet article, prenez le temps d'un premier échange pour cadrer le périmètre. Notre pré-audit Symfony identifie en quelques jours l'état réel de votre application et le plan d'action pour en reprendre la main, sans engagement.