Symfony 4 en fin de vie, un PHP que l'hébergeur ne veut plus, des bundles abandonnés depuis trois ans : une application en retard ne se remonte pas d'un bond. Elle se remonte par paliers, dans un ordre connu, sans arrêter vos développements pendant six mois.
Le devis d'une migration ne s'écrit pas au ressenti. Je commence par inventorier ce que vous avez vraiment : versions, dépendances, tests, code mort, ce qui casse au premier palier et ce qui ne cassera qu'au dernier. Vous recevez un chemin daté et chiffré avant que j'ouvre le premier fichier.
Prestataire Symfony depuis la version 2, j'ai mené plusieurs refontes de plateformes existantes avec montée de version majeure. Les ruptures de chaque version, les pièges de Doctrine, les bundles qui n'ont pas survécu : c'est du terrain connu, pas une découverte facturée à votre compte.
Cet inventaire commence toujours par la même question, et sa réponse surprend presque tout le monde : j'ai raconté ce qu'un fichier composer.lock dit vraiment de ce qui épingle une application, sur un site qui n'avait pas bougé depuis Symfony 4.4.
Versions de Symfony, de PHP et de Doctrine, bundles abandonnés, extensions manquantes, dépendances qui n'existent plus, dette et failles connues. Cet état des lieux écrit est facturé à part, et il vous reste même si vous confiez les travaux à quelqu'un d'autre.
On ne passe pas de Symfony 3 à Symfony 8 d'un coup : on avance version par version, en traitant les dépréciations avant chaque palier plutôt qu'après. Chaque étape se termine par une application qui tourne, donc déployable, donc interruptible si vos priorités changent.
Une application sans tests se migre à l'aveugle. J'écris d'abord de quoi couvrir les parcours qui font vivre votre activité, puis j'ajoute l'analyse statique au niveau maximum : à partir de là, une régression se voit avant vos utilisateurs, et pas par eux.
Mise en production préparée, retour arrière prévu, surveillance des erreurs les premiers jours. Je livre aussi ce qui évite de retomber en retard : un rythme de mises à jour mineures qui coûte quelques heures par an, au lieu d'un chantier tous les cinq ans.
Vitrine & réservation bien-être
Refonte complète du site d'un praticien bien-être : présentation des soins, prise de rendez-vous en ligne et back-office d'administration. Symfony 8 + Tailwind.
Boilerplate SaaS pour Symfony
Boilerplate commercial pour lancer un SaaS Symfony sans réinventer l'infrastructure : authentification (magic links, 2FA), facturation Stripe & Lemon Squeezy, multi-tenant avec équipes et rôles, dashboard admin (MRR, churn), chat IA en streaming. Suite de tests qui rejoue des cycles de facturation complets depuis des webhooks signés, PHPStan au niveau maximum sans aucune dérogation.
Assistant juridique par IA
Plateforme privée d'aide à la constitution de dossiers juridiques, assistée par IA : journal de faits horodatés avec pièces, assistant répondant à partir du dossier (RAG), contrôles de confidentialité granulaires. Hébergement en France, données chiffrées.
Cela dépend de la quantité de code et de sa qualité, pas du nombre de versions de retard : une application testée et sans bundle exotique remonte vite, une application de deux cents mille lignes sans un seul test demande d'abord d'en écrire. L'inventaire répond à cette question en un à deux jours, et c'est exactement à ça qu'il sert.
Non, et c'est la raison des paliers. Un chantier de six mois mené sur une branche à part se termine toujours par une fusion impossible. Chaque palier se termine ici par une application déployable : vos développements continuent entre deux paliers, sur la même branche que le reste de l'équipe.
Migrer, dans la grande majorité des cas. Une réécriture repart de zéro sur des règles métier qui ne sont écrites nulle part ailleurs que dans le code existant, et se paie deux fois : une fois pour refaire, une fois pour redécouvrir ce qu'on avait oublié. Je ne propose une réécriture que quand je peux montrer pourquoi, et ça reste minoritaire. Quand plus personne ne tient l'application, la question n'est d'ailleurs plus la version mais la reprise du projet existant, et elle se traite en premier.
Non. C'est la version sur laquelle j'ai commencé, ses conventions me sont familières, et le chemin jusqu'à la 8 est long mais balisé. Ce qui coûte cher n'est pas l'âge du framework, c'est le code qui le contourne : du métier écrit dans les contrôleurs, des requêtes SQL à la main, des bundles maison que personne n'a documentés.
Elle monte dans le même mouvement, et souvent d'abord : chaque version de Symfony impose un minimum de PHP, et votre hébergement impose un maximum. L'ordre des deux montées fait partie du plan, parce que se tromper dessus oblige à refaire une étape entière.
Mon tarif de référence est de 650 € par jour. L'inventaire se facture au temps passé, un à deux jours dans la plupart des cas. Les paliers, eux, se chiffrent au forfait une fois l'inventaire fait : à ce moment-là le périmètre est enfin connu, donc l'engagement est tenable des deux côtés.
Donnez-moi la version de Symfony, celle de PHP, et depuis combien de temps l'application n'a pas été mise à jour. Je réponds sous 24 h avec un premier avis sur l'ampleur du chantier, et sur ce qui doit passer en premier.