Audit d'une application Symfony : où aller, et par quels paliers

L'audit répond à une seule question : sur quelle version votre application doit se trouver, et par quels paliers y arriver sans arrêter les livraisons. En cinq jours de travail, il produit un chemin ordonné, la frontière entre ce qu'un outil peut réécrire et ce qui restera manuel, et ce que chaque palier expose comme risque. C'est une prestation facturée, sur devis selon le périmètre, et le rapport vous appartient sans restriction, y compris si vous confiez l'exécution à quelqu'un d'autre.

Ce que l'audit mesure vraiment

Ce n'est ni un devis déguisé, ni une revue de code ligne à ligne, ni un audit de sécurité applicative. C'est un diagnostic de décision, destiné à une DSI ou à un responsable technique qui doit arbitrer entre monter maintenant, monter par étapes étalées, ou tenir la position jusqu'à une date choisie. L'analyse porte sur le dépôt, les fichiers de dépendances et les versions réellement servies par vos environnements, jamais sur le contenu de vos données de production, et un accord de confidentialité est signé avant tout accès.

Une précision qui évite un malentendu : l'audit ne monte pas votre application. Il établit ce qu'il faudrait faire, dans quel ordre, et ce que chaque étape suppose d'avoir en place avant d'être lancée. Notre parti pris tient en une phrase : un audit qui ne peut pas conclure « ne bougez pas maintenant » n'est pas un audit, c'est une plaquette. Séparer le diagnostic de l'exécution est précisément ce qui permet au premier de le dire.

Pourquoi l'audit est facturé

Cinq jours d'analyse ne sont pas un geste commercial : c'est le temps qu'un intervenant passe dans votre dépôt, dans vos verrous de dépendances et dans vos entretiens. Le facturer change ce que le diagnostic a le droit de dire. Payé pour lui-même, il n'a pas à être rentabilisé par le chantier qu'il est censé arbitrer, et conclure « restez sur votre LTS jusqu'à sa fin de support » ne lui coûte rien.

Le montant dépend du périmètre, et l'écart est réel : une application isolée, un monolithe de dix ans avec plusieurs dizaines de bundles tiers, ou plusieurs applications Symfony partageant des bibliothèques internes ne demandent pas le même travail. Le tarif vous est donc communiqué sur devis, une fois le périmètre arrêté avec vous. Le premier échange reste sans frais, et il suffit à écarter les cas où l'audit n'apporterait rien : une application déjà en 7.4 sur un PHP couvert n'a pas besoin de nous.

Les 6 axes d'analyse

Ce que nous regardons en premier, et pourquoi

L'axe version part du fichier de verrouillage et non de la documentation du projet, parce que le verrou décrit ce qui tourne vraiment ; il est comparé aux versions déclarées supportées par le projet, soit 6.4, 7.4 et 8.1 au 9 août 2026, la 5.4 n'étant plus couverte qu'en sécurité. L'axe PHP fait la même chose sur l'autre horloge, celle de php.net : PHP 8.1 est sorti de support fin 2025 et PHP 8.2 s'arrête le 31 décembre 2026. L'axe bundles ouvre le verrou et cherche, dépendance par dépendance, laquelle refusera la cible. L'axe Doctrine situe la ligne d'ORM et le pilote de mapping, parce que le document de montée du projet impose une séquence propre, DBAL puis ORM, qui ne se superpose pas à celle du framework. L'axe tests mesure ce que vous êtes capables de voir : un chemin qu'aucun test ne parcourt n'émettra aucun avertissement, ce qui n'est pas la même chose qu'être propre. L'axe dépréciations transforme cette visibilité en nombre, avec le pont PHPUnit décrit par le guide officiel de montée majeure.

Ces six axes ne pèsent pas le même poids, et nous ne les traitons pas dans l'ordre du tableau. Le premier geste est toujours le même : ouvrir le verrou Composer et relever la version de PHP servie en production. Ces deux informations, prises ensemble, restreignent immédiatement l'éventail des trajectoires possibles et donnent le cadre dans lequel les quatre autres axes ont un sens. Un chemin de paliers construit avant de les connaître est une hypothèse, pas un plan.

Le livrable : un chemin de paliers, pas une liste de tâches

Le rapport fait 12 à 20 pages selon la taille de l'application. Il s'ouvre sur la position actuelle, établie et non déclarée : Symfony résolu dans le verrou, PHP de chaque environnement, ligne de Doctrine, et la date à laquelle chacun de ces trois éléments cesse d'être couvert, source à l'appui. Vient ensuite le chemin : les paliers ordonnés, chacun formulé comme une livraison autonome, avec ce qui le déclenche, ce qu'il contient, et ce qui doit être vert avant de passer au suivant.

Trois sections complètent ce chemin. La répartition entre ce qu'un réécrivain automatique traitera et ce qui restera manuel, établie en confrontant vos dépréciations réelles au catalogue de règles de Rector plutôt qu'à une impression. La stratégie de validation, qui indique pour chaque palier ce qui sert de preuve : tests existants, tests à écrire avant de commencer, parcours manuels scriptés. Et la liste des points de blocage possibles, essentiellement des bundles tiers sans version compatible, avec pour chacun l'option de remplacement identifiée. Le tout est livré en PDF, accompagné du tableau de dépendances qui a servi à l'établir.

Le rapport est conçu pour servir après sa lecture. Il tient comme base de consultation auprès d'autres prestataires, puisqu'il décrit un périmètre identique pour tout le monde plutôt qu'une intention vague. Il tient aussi comme document d'arbitrage interne : les dates de fin de support y sont citées avec leur source, ce qui permet de discuter un calendrier sans avoir à croire sur parole celui qui présente le dossier. C'est là que la propriété intégrale du document prend son sens.

Déroulement sur cinq jours

Votre charge totale tient dans une demi-journée, répartie sur la semaine. Le calendrier de ces cinq jours est arrêté avec vous et suppose que les accès soient disponibles au démarrage : un audit qui commence sans le dépôt et sans les versions des environnements passe sa première journée à attendre, ce que nous préférons dire avant plutôt que facturer après.

Cette charge réduite n'est pas un raccourci, elle vient de la nature du travail. Lire un fichier de verrouillage, exécuter une suite de tests instrumentée ou comparer des calendriers de support ne demande pas votre présence. Nous sollicitons vos équipes là où l'information ne peut venir que d'elles : pourquoi telle dépendance a été figée, ce que fait exactement un bundle interne, quelles fenêtres calendaires sont interdites côté métier.

L'audit est conduit par Bertrand Dumast, fondateur de Smartshift : un seul interlocuteur du cadrage à la restitution, sans relais intermédiaire. Son parcours, vingt ans de projets numériques B2B, près de sept ans chez Kaliop sur des catalogues et des données produit, puis sept ans chez Amazon Web Services, est détaillé sur la page à propos du site.

Ce qu'on vous demande en entrée

• Un accès en lecture au dépôt, ou une archive du code source dans l'état déployé en production.
• Les fichiers `composer.json` et `composer.lock` de la branche réellement en ligne, pas ceux de la branche de développement.
• La version de PHP servie par chaque environnement, poste de développement compris, et la valeur du réglage `platform` si le projet en définit un.
• La configuration PHPUnit du projet et, si la suite existe, le rapport du dernier lancement.
• La liste des bundles internes ou développés sur mesure, avec une phrase sur ce que chacun fait.
• Un interlocuteur technique disponible deux heures et un référent métier disponible une heure.

Confidentialité : un accord est signé avant tout accès, aucune donnée de production n'est extraite, et les accès comme les copies de travail sont détruits dans les 30 jours suivant la restitution.

Et si la conclusion est de rester sur la LTS actuelle

C'est une conclusion possible, et elle est écrite noir sur blanc quand elle s'impose. Une application en Symfony 6.4 reçoit des correctifs de sécurité jusqu'au 30 novembre 2027 d'après la page de version du projet. Si son interpréteur est lui aussi couvert et si aucune dépendance ne la bloque, il n'existe aucune raison technique de lancer le chantier ce trimestre. Le rapport recommande alors de tenir la position et de préparer la suite, et il le formule aussi précisément que s'il recommandait l'inverse.

« Préparer » n'est pas un mot creux, cela désigne un contenu daté : installer le pont PHPUnit pour rendre les dépréciations visibles, faire descendre le plafond de tolérance à chaque livraison, monter PHP en premier puisque c'est le chantier indépendant du framework, et convertir ce qui devra l'être de toute façon, par exemple un mapping Doctrine encore porté par des annotations. Ce travail se fait pendant que tout fonctionne, il se livre par petits morceaux, et il transforme la montée suivante en formalité. La date de fin de support fixe l'échéance, pas la date de démarrage.

L'inverse s'écrit avec la même franchise. Une application posée sur une branche déjà arrêtée, exposée sur Internet, avec des dépendances abandonnées, n'a pas de trajectoire confortable : nous refusons de la présenter comme une montée de version tranquille pour rendre le devis plus facile à signer. Dans ce cas, le rapport ne cherche pas à rendre le chemin agréable, il le rend explicite, y compris sur ce qu'il faudra remplacer plutôt que migrer.

Questions fréquentes