Audit d’une application Symfony avant reprise : que vérifier ?

Vous héritez d’une application Symfony : un prestataire est parti, un développeur a changé de poste, ou l’outil tourne depuis des années sans que personne n’ose y toucher. Avant d’ajouter la moindre fonctionnalité, un audit court évite de découvrir les problèmes en production.

Cet article donne la checklist que j’utilise, les commandes à lancer et les questions à poser. Il complète l’article plus général sur la reprise d’un projet web existant et la dette technique.

En bref

Un audit d’application Symfony avant reprise vérifie six points : la version de Symfony et de PHP, l’état des dépendances, la présence de tests, l’emplacement de la logique métier, la qualité des données et la façon dont l’application est déployée. Il produit une liste de risques classés et une recommandation : stabiliser, mettre à jour, reprendre progressivement ou refaire une partie.

• Version : une application sur une version de Symfony ou de PHP qui ne reçoit plus de correctifs de sécurité est le premier risque à traiter.
• Dépendances : composer audit liste les failles connues en quelques secondes.
• Tests : sans tests sur les parcours critiques, chaque modification devient un pari.
• Logique métier : c’est elle qui coûte le plus cher à reconstruire, il faut la localiser avant tout.
• Livrable : une cartographie des risques et un plan d’action, pas une liste de 200 remarques de style.

Pourquoi auditer une application Symfony avant de la reprendre ?

Parce qu’une reprise sans audit fait payer les surprises au moment le plus coûteux. Le développeur découvre une version obsolète, une règle métier cachée ou un déploiement manuel au milieu d’une évolution demandée par le client. L’audit déplace ces découvertes avant le devis et avant la première modification.

Symfony aide beaucoup à ce stade. Le framework est structuré : routes, services, entités, formulaires et commandes ont une place attendue. Un projet qui respecte ces conventions se lit vite. Un projet qui les contourne se repère tout aussi vite, et c’est déjà une information utile pour estimer la reprise.

Quelle version de Symfony et de PHP fait tourner l’application ?

La commande bin/console about répond en une ligne : elle affiche la version de Symfony, ses dates de fin de maintenance et de fin de support, la version de PHP et l’environnement. C’est la première commande à lancer, avant même d’ouvrir le code.

Le point de vigilance est la date de fin des correctifs de sécurité. Une application exposée sur internet ne devrait pas tourner sur une version qui n’en reçoit plus. Voici l’état des versions au 8 octobre 2026, selon le calendrier officiel de Symfony :

Les versions intermédiaires qui ne figurent pas dans ce tableau (5.0 à 5.3, 6.0 à 6.3, 7.0 à 7.3, 8.0) ne sont plus maintenues. Côté PHP, les versions 8.1 et antérieures ne reçoivent plus de correctifs de sécurité. PHP 8.2 en reçoit jusqu’au 31 décembre 2026, PHP 8.3 jusqu’au 31 décembre 2027 et PHP 8.4 jusqu’au 31 décembre 2028.

Une version ancienne n’impose pas une refonte. Elle impose un plan de mise à jour, chiffré et ordonné. Passer d’une LTS à la suivante se fait en corrigeant d’abord les dépréciations signalées par la version actuelle.

Les dépendances sont-elles à jour et sans faille connue ?

Trois commandes Composer donnent l’état des dépendances : composer audit pour les failles de sécurité publiées, composer outdated --direct pour les paquets en retard, et composer validate pour la cohérence entre composer.json et composer.lock. Elles prennent quelques secondes et ne modifient rien.

Il faut ensuite regarder ce que les outils ne disent pas :

• les paquets abandonnés par leur auteur, sans version compatible avec la prochaine version de Symfony ;
• les bundles forkés ou copiés dans le dépôt, qui ne seront jamais mis à jour automatiquement ;
• les dépendances JavaScript (package.json, importmap.php) qui vieillissent souvent plus vite que le PHP ;
• les dépréciations, visibles avec bin/console debug:container --deprecations et dans l’onglet dédié du profiler.

Le volume de dépréciations est un bon indicateur du coût de la prochaine mise à jour. Quelques dizaines se traitent en quelques jours. Plusieurs centaines dispersées dans le code annoncent un chantier à découper.

Peut-on modifier le code sans tout casser ?

Oui si les parcours critiques sont couverts par des tests automatisés, non sinon. La question n’est pas le taux de couverture global. C’est de savoir si la connexion, la création d’un dossier, le calcul d’un montant ou l’export attendu par le client sont vérifiés à chaque modification.

Pour le savoir : lancer php bin/phpunit et noter si la suite passe, combien de temps elle prend et ce qu’elle teste réellement. Une suite qui échoue depuis des mois est une information en soi. Si les tests n’existent pas, l’audit indique quels parcours couvrir en premier avec des tests fonctionnels WebTestCase, avant toute évolution.

Trois commandes complètent ce contrôle en lecture seule : bin/console lint:container pour la configuration des services, bin/console lint:twig templates/ pour les gabarits et bin/console doctrine:schema:validate pour vérifier que le mapping Doctrine correspond à la base. Un outil d’analyse statique comme PHPStan, lancé à un niveau modéré, fait ensuite remonter les erreurs de types et le code mort.

Où se trouve la logique métier ?

Dans une application Symfony saine, les règles métier vivent dans des services dédiés, appelés par des contrôleurs courts. Dans une application qui a vieilli vite, elles sont dispersées : dans les contrôleurs, dans les templates Twig, dans des listeners Doctrine, dans des commandes lancées par cron ou directement en SQL.

Localiser cette logique est l’étape la plus rentable de l’audit, car c’est elle qui coûte le plus cher à reconstruire si on la perd. Quelques repères :

• bin/console debug:router liste toutes les routes : les plus longues à lire révèlent souvent les contrôleurs surchargés ;
• les fichiers les plus souvent modifiés sont les zones à risque, visibles avec git log --format= --name-only | sort | uniq -c | sort -rn | head -20 ;
• les commandes planifiées (crontab, Scheduler, Messenger) portent souvent des règles que personne n’a documentées ;
• les utilisateurs actuels connaissent les exceptions que le code gère silencieusement : un entretien de trente minutes vaut parfois une journée de lecture.

Comment l’application est-elle déployée, sauvegardée et surveillée ?

Une application qu’on ne sait pas redéployer ne peut pas être reprise sans risque. L’audit doit établir comment le code arrive en production, si un environnement de recette existe, où sont les secrets et si les sauvegardes de la base ont déjà été restaurées au moins une fois.

Points à vérifier :

• le déploiement est-il scripté (Deployer, Docker, CI) ou fait à la main par FTP ?
• les migrations Doctrine sont-elles à jour (bin/console doctrine:migrations:status) ou la base a-t-elle été modifiée directement ?
• les secrets sont-ils dans .env.local ou le coffre de Symfony, ou versionnés dans le dépôt ?
• les logs de production sont-ils lus, et une erreur déclenche-t-elle une alerte ?

Combien de temps dure un audit et que doit-il livrer ?

Quelques jours suffisent pour une application de taille modeste avec un accès complet au code, à une copie de la base et à un environnement de test. Une application avec de nombreux modules, des intégrations tierces et une logique métier dense demande davantage. La durée se fixe après un premier échange sur le périmètre et les accès disponibles.

Le livrable doit permettre de décider, pas d’impressionner. Il contient :

• le contexte, les usages critiques et le périmètre réellement examiné ;
• l’état du socle : versions, dépendances, architecture ;
• les constats, avec ce qui a été observé et ce qui reste à vérifier ;
• les risques classés par impact sur les utilisateurs ;
• un plan d’action et les options de reprise.

La page audit technique d’application web détaille ce format d’intervention.

Exemple : passer de Symfony 5.4 à 6.4 sur une application en production

Sur le projet Circular Certified de Schneider Electric, la plateforme de gestion des retours a été créée sous Symfony 5.4, puis a évolué vers Symfony 6.4 pendant qu’elle était utilisée. Elle génère des PDF et des bons DHL et échange avec d’autres briques par API sécurisée.

Ce type de migration se prépare exactement avec les points ci-dessus : corriger les dépréciations signalées par la 5.4, vérifier que chaque bundle a une version compatible, sécuriser les parcours critiques par des tests, puis déployer avec une recette. L’enjeu n’était pas la nouveauté technique, mais la continuité d’usage pour les équipes qui traitaient les retours chaque jour.

FAQ

Faut-il mettre à jour Symfony avant de reprendre le développement ?

Pas toujours avant, mais toujours dans le plan. Si la version ne reçoit plus de correctifs de sécurité, la mise à jour passe en premier. Si elle est encore supportée, on peut livrer les évolutions urgentes et planifier la mise à jour juste après.

Peut-on auditer une application sans accès à la production ?

Oui, à condition d’avoir le code source, une copie anonymisée de la base et un moyen de lancer l’application. Sans accès à la production, l’audit précise simplement ce qui n’a pas pu être vérifié, comme les performances réelles ou la configuration du serveur.

Un audit de code remplace-t-il un test d’intrusion ?

Non. Une revue de code repère des faiblesses dans un périmètre convenu, mais ne garantit pas l’absence de vulnérabilités. Un test d’intrusion demande un cadre et des compétences spécifiques.

Reprendre ou refaire : qui décide ?

Le client, à partir des constats de l’audit. Le rôle de l’audit est de rendre la décision lisible : coût d’une mise à jour, risques d’une réécriture, parties qui peuvent être conservées telles quelles.

Conclusion

Auditer une application Symfony avant de la reprendre, c’est répondre à quelques questions simples avec des outils que le framework fournit déjà : quelle version, quelles failles, quels tests, où sont les règles métier, comment on déploie. La plupart des commandes citées ici ne modifient rien et peuvent être lancées dès le premier jour.

Le résultat attendu est une décision argumentée, pas un verdict. Si vous reprenez une application Symfony que plus personne n’ose modifier, décrivez-moi la situation : on commence par lire ce qui existe.

Sources : calendrier de support publié sur symfony.com/releases et versions supportées sur php.net, consultés le 8 octobre 2026.