Reprendre un projet Symfony existant : étapes, risques et coût

Par Adrien Messager-Diaz, développeur Symfony freelance · Mis à jour le 14 octobre 2026

Votre prestataire a disparu, votre développeur interne est parti, ou l'application tourne sur une version de Symfony qui n'est plus maintenue. Le site fonctionne encore, mais chaque correction devient risquée et personne n'ose plus toucher au code. Voici la méthode que j'applique pour reprendre une application Symfony existante sans casser la production, et pour décider en connaissance de cause entre maintenance, migration et refonte.

1. Les situations qui mènent à une reprise

Une reprise de projet Symfony démarre presque toujours dans l'une de ces situations :

• Changement de prestataire : l'agence ou le freelance ne répond plus, a fermé, ou la relation s'est dégradée.
• Départ du développeur interne : la seule personne qui connaissait l'application est partie, sans documentation.
• Version en fin de vie : Symfony 4 ou 5, PHP 7, des dépendances abandonnées. L'hébergeur menace de couper les anciennes versions de PHP.
• Rachat ou reprise d'entreprise : le nouvel acquéreur veut savoir ce que vaut réellement l'outil dont il hérite.
• Dégradation progressive : lenteurs, bugs qui reviennent, mises en production qui cassent autre chose.

Le point commun : on ne sait plus vraiment ce qu'il y a dans le code. La première étape n'est donc pas de corriger, mais de comprendre.

2. Avant le code : récupérer tous les accès

C'est l'étape la plus sous-estimée, et la plus urgente si l'ancien prestataire est encore joignable. Sans ces éléments, une reprise peut devenir impossible ou très coûteuse.

• Le code source complet, avec l'historique de ses modifications (le « dépôt Git »). Une simple copie des fichiers en ligne ne suffit pas : l'historique explique pourquoi le code est écrit ainsi.
• L'hébergement : accès au serveur et au panneau d'administration, et la façon dont les mises en ligne étaient faites.
• La base de données : accès et une sauvegarde récente, vérifiée.
• Les mots de passe et clés de configuration de l'application : accès aux services externes, clés d'API, identifiants techniques.
• Les services tiers : compte Stripe, service d'envoi d'e-mails, stockage de fichiers, Google Cloud, etc. Vérifiez qu'ils sont à votre nom et non à celui du prestataire.
• Le nom de domaine et les DNS : là encore, au nom de votre entreprise.

3. L'audit : ce qu'il doit vous apprendre

Un audit de code prend en général 1 à 2 jours. Son but n'est pas de juger le travail du prestataire précédent, mais de répondre à une question simple : combien coûte chaque chantier, et lequel est urgent ? Vous n'avez pas besoin de lire le code pour l'exploiter. Un bon rapport d'audit répond clairement à ces six questions :

1. Mon application est-elle encore à jour ? Une version de Symfony ou de PHP qui n'est plus maintenue ne reçoit plus de correctifs de sécurité. C'est souvent le premier point bloquant, et parfois l'hébergeur qui force la décision.
2. Est-elle exposée à des failles de sécurité ? Accès mal protégés, données clients lisibles par la mauvaise personne, mots de passe stockés dans le code : ce sont les points à corriger en priorité.
3. Le code peut-il être repris par quelqu'un d'autre ? Un code clair et organisé selon les standards se reprend en quelques jours. Un code désordonné rend chaque modification lente et risquée.
4. Où sont les règles de mon métier ? Vos calculs, vos tarifs, vos processus doivent être identifiables. S'ils sont dispersés partout, faire évoluer l'application coûtera cher.
5. Pourquoi est-elle lente ? Les lenteurs ont presque toujours quelques causes précises, souvent peu coûteuses à corriger une fois identifiées.
6. Peut-on modifier l'application sans risque ? Sans tests automatiques ni mise en production fiable, chaque correction est un pari, et chaque mise en ligne peut casser autre chose.

Le livrable est un rapport classé par priorité : ce qui est bloquant, ce qui peut attendre, et ce qui relève du confort, avec une estimation pour chaque point. Il doit être compréhensible par un dirigeant et exploitable par n'importe quel développeur, pas seulement par celui qui l'a rédigé.

4. Stabiliser, migrer ou réécrire ?

L'audit débouche sur l'une de ces trois trajectoires. Le choix dépend moins de la qualité du code que de la valeur de l'application pour votre activité et de ce que vous voulez en faire dans les deux prochaines années.

Le plus souvent, la bonne réponse est une combinaison : on stabilise d'abord (correctifs urgents, mise en production fiable), puis on met à jour par étapes, et on ne réécrit que les parties qui le justifient vraiment.

5. Mettre à jour une ancienne version de Symfony

Une mise à jour de Symfony se fait par étapes, une version majeure après l'autre, avec une mise en ligne à chaque étape. C'est plus long sur le papier qu'un grand saut, mais c'est beaucoup plus sûr : si un problème apparaît, on sait exactement d'où il vient, et votre application reste en service pendant toute l'opération.

Avant de commencer, on sécurise les parcours qui rapportent de l'argent (connexion, commande, paiement, exports) avec des vérifications automatiques : ce sont eux qui ne doivent jamais casser.

Les applications très anciennes (Symfony 2 ou 3) sont un cas à part : leur structure est si différente des versions actuelles que la mise à jour se rapproche d'un remplacement progressif, morceau par morceau. Pour connaître la version à viser, voir le point sur les versions de Symfony, et pour le détail de la démarche, le guide de migration Symfony.

6. Combien coûte une reprise de projet Symfony ?

Tout dépend de la taille de l'application et de son état, mais voici des ordres de grandeur réalistes pour une application métier de taille moyenne :

Le facteur qui fait le plus varier le budget n'est pas la quantité de code, mais l'absence de tests et de documentation : chaque modification doit alors être vérifiée à la main. C'est pourquoi l'audit est la seule façon d'obtenir un chiffrage fiable, et pourquoi je le propose comme une prestation à part, sans engagement sur la suite.

7. Les erreurs à éviter

• Laisser partir l'ancien prestataire sans les accès. Récupérer un domaine ou un compte Stripe après coup peut prendre des semaines.
• Décider de tout réécrire avant d'avoir audité. La réécriture rassure, mais elle est presque toujours plus longue et plus chère que prévu.
• Corriger sans filet. Sans tests sur les parcours critiques, chaque correctif peut en casser un autre.
• Reporter la migration de version. Plus on attend, plus il y a d'étapes à franchir, et plus l'hébergeur risque d'imposer une version de PHP incompatible.
• Garder le savoir dans une seule tête. Exigez une documentation à jour, une procédure de mise en ligne écrite et un code source hébergé au nom de l'entreprise, quel que soit le prestataire.

Questions fréquentes

Peut-on reprendre un projet Symfony sans l'ancien prestataire ?

Oui, à condition de récupérer le code source complet (idéalement avec l'historique de ses modifications), les accès à l'hébergement et à la base de données, et les clés de configuration. Symfony impose des conventions qui permettent à un autre développeur de comprendre l'application, même sans documentation.

Combien de temps faut-il pour reprendre en main une application Symfony ?

Comptez 1 à 2 jours d'audit pour savoir où vous en êtes, puis quelques jours pour remettre en place un environnement de travail et une mise en ligne fiables. Une migration de version majeure prend de quelques jours à quelques semaines selon la taille du projet et la couverture de tests.

Faut-il tout réécrire quand le code est de mauvaise qualité ?

Rarement. Une réécriture complète fait perdre des années de règles métier implicites et bloque les évolutions pendant des mois. Dans la plupart des cas, il vaut mieux stabiliser, ajouter des tests sur les parcours critiques, puis remplacer les parties les plus fragiles module par module.

Mon application est en Symfony 2 ou 3, est-ce récupérable ?

Les données et la logique métier le sont presque toujours. Le code lui-même demande souvent une migration lourde, car la structure des projets a changé avec Symfony 4. Un audit permet de chiffrer la migration progressive et de la comparer à une reconstruction ciblée.