Reprise de logiciel existant / Reprise de projet Symfony
Confiez votre projet, à des experts du framework Symfony
Votre prestataire a disparu, ne suit plus, ou ne vous convient plus. Le projet est développé avec le framework Symfony, Nous le reprenons là où il en est : sans repartir de zéro, sans le juger, en commençant par un audit complet pour avoir une visionpartagé du point de départ.
C'est notre stack depuis nos premiers projets. Nous savons ce qu'on trouve dans un projet Symfony laissé sans suivi, et comment le mettre dans les meilleurs conditions pour que vous puissiez le faire vivre.
Ça vous parle ?
Les situations que nous rencontrons le plus souvent
Le freelance qui a construit le projet ne répond plus
Il a changé de vie, ou simplement de clients. Le logiciel tourne, personne ne peut plus y toucher, et chaque semaine qui passe rend la reprise un peu plus coûteuse.
Symfony 4, PHP 7, et personne n'ose y toucher
Le projet n'a pas été mis à jour depuis des années. L'agence est encore là mais n'a plus les compétences, ou plus le temps, et vous répond que ce serait un projet à part.
Chaque évolution coûte plus cher que la précédente
Le prestataire livre, mais les régressions reviennent, les délais glissent, et les choix techniques ne sont jamais expliqués. Vous ne savez plus si votre exigence est légitime.
Le parcours
Auditer, stabiliser, puis faire évoluer
Pas d'improvisation : chaque reprise suit le même ordre, parce que c'est l'ordre qui évite de casser ce qui tourne.
Audit de reprise : savoir ce qu'on reprend
Avant de toucher une ligne de code, nous lisons le projet : dépendances, versions, bundles, modèle de données, tests, déploiement. Le livrable est un rapport classé par criticité, avec ce qui est récupérable en l'état, ce qui doit être remplacé, et par quoi commencer. Vous le validez avant de vous engager sur la suite : c'est un point de situation clair, même si vous ne continuez pas avec nous.
- Accès au dépôt, environnement local reproductible
- Lecture outillée : six points, détaillés plus bas
- Le même rapport que notre audit de code
Stabiliser : sécurité, tests, déploiement
Nous traitons d'abord ce qui expose le projet : failles connues sur les dépendances, mises à jour de sécurité, accès mal protégés. Puis ce qui le rend fragile : un déploiement reproductible, des tests sur les parties critiques, une documentation qui ne dépend plus d'une seule personne. Chaque sprint de deux semaines livre sur un environnement de recette.
- Vulnérabilités publiées traitées en premier
- Intégration continue et retour arrière testé
- Tests sur les règles métier avant d'y toucher
Migrer et faire évoluer, palier par palier
Une fois le projet stabilisé, la montée de version se fait dans le flux de maintenance : Symfony, PHP, Vue.js, bundle par bundle, avec Rector pour la part mécanique et des tests pour le reste. Les évolutions fonctionnelles reprennent en parallèle, priorisées avec vous. Le projet est de nouveau un actif qui évolue, pas un risque qu'on gère.
- Vers la dernière LTS de Symfony, sans interruption
- Les demandes en attente enfin traitées
- Contrat de maintenance
Ce que nous demandons
Les conditions d'une reprise qui se passe bien
Reprendre un projet écrit par quelqu'un d'autre, c'est accepter d'être jugé sur un code qu'on n'a pas écrit. Ces conditions protègent la relation autant que le projet, pour commencer sur de bonnes bases.
Un accès direct au dépôt et à un environnement
Un code avec historique pour pouvoir si référer en cas de question. Le dépôt Git et un environnement où le projet tourne : sans eux, personne ne peut dire réellement ce qu'il reprend.
Un périmètre de responsabilité écrit
Ce qui est dans notre périmètre, ce qui ne l'est pas, et qui arbitre quand la frontière est floue. Si un autre intervenant reste sur le projet, c'est la condition pour que la cohabitation tienne.
Un interlocuteur qui tranche
Quelqu'un chez vous qui décide, et qui n'est pas un relais de l'ancien prestataire. Une reprise où personne n'arbitre est perdue pour tout le monde, et nous préférons le dire avant.
Pas d'endossement d'un incident dont nous ne maîtrisons pas la cause
Diagnostiquer, oui. Porter la responsabilité d'un incident né d'un code ou d'une infrastructure que nous n'avons pas encore repris, non. C'est ce qui protège la relation dans les premières semaines.
Les deux premières semaines
Ce que nous analysons dans un projet Symfony
Reprendre un projet, c'est d'abord savoir ce qu'on reprend. Sur Symfony, le framework nous donne une grande partie de la carte. Le reste se lit dans six endroits, toujours les mêmes, et chacun est une section du rapport de reprise.
composer.json et le verrou des dépendances
La liste exacte de ce dont le projet dépend, version par version. C'est là qu'on voit les librairies abandonnées, les contraintes qui bloquent toute montée de version, et l'écart avec le calendrier de support.
Librairies abandonnées
Plus de mainteneur, plus de correctif : chacune fige la version de tout ce qui en dépend.
Contraintes bloquantes
Une version épinglée il y a cinq ans, une librairie qui refuse PHP 8 : ce qui interdit la montée avant même de l'avoir tentée.
Failles publiées
composer audit et osv-scanner, puis chaque alerte qualifiée : concernée ou pas, exploitable ou pas.
La version de Symfony et de PHP face au calendrier
Nous confrontons vos versions aux dates officielles de fin de support, que nous tenons à jour et contrôlons automatiquement. Vous savez ce qui presse et ce qui peut attendre, et si la question est de migrer ou non, elle a sa propre page.
PHP
La version installée, la date où elle cesse de recevoir des correctifs de sécurité, et la première cible réaliste.
Symfony
LTS ou non, jusqu'à quand, et combien de majeures séparent le projet de la LTS courante.
Ce qui presse
Une version déjà hors support passe avant tout le reste. Une version couverte encore un an laisse le temps de stabiliser d'abord.
Les bundles, un par un
Chaque bundle est maintenu, en fin de vie ou abandonné. Un bundle mort fige la version de tout le reste, et le rapport dit lequel, et par quoi il se remplace.
Administration
Sonata ou EasyAdmin : le bundle le plus lourd à remplacer, et le plus souvent en retard.
API
API Platform, ou une API écrite à la main : ce qu'un front ou un partenaire consomme, et qui ne doit pas casser.
Authentification, médias, PDF
Les bundles utilitaires oubliés, dont le mainteneur a parfois disparu sans que personne le remarque.
Doctrine, les entités et les migrations
Le modèle de données est la partie la plus précieuse du projet et la moins documentée. Nous lisons les entités, l'historique des migrations, et ce que la base contient réellement.
Entités et relations
Le modèle tel que le code le décrit : c'est souvent la seule documentation exacte du métier.
Historique des migrations
Complet et rejouable, ou absent : dans ce cas, la base a été modifiée à la main, sans trace.
Ce que la base contient
Colonnes inutilisées, données dupliquées, écarts entre le schéma déclaré et le schéma réel.
Les tests, la CI et l'environnement
Ce qui est testé, comment le projet se construit, comment il se déploie, et si quelqu'un d'autre que l'ancien prestataire peut le faire. Souvent, la réponse est non, et c'est la première chose qu'on règle.
Suite de tests existante
Exécutée telle quelle : ce qu'elle couvre, ce qu'elle vérifie vraiment, et ce qui échoue déjà.
Construction et déploiement
Une intégration continue qui tourne, ou une procédure dans la tête d'une personne.
Transmissibilité
Le projet se lance sur un poste neuf en une commande, ou il faut trois jours et l'ancien prestataire.
Les dépréciations et ce que Rector automatise
Le framework signale lui-même tout ce que la prochaine version retirera. Ce journal, plus l'analyse statique, mesure exactement le chemin jusqu'à une version supportée, et Rector en parcourt seul la part mécanique.
Journal des dépréciations
Comptées par composant : c'est la distance exacte jusqu'à la version suivante.
Analyse statique
PHPStan avec les extensions Symfony et Doctrine, au niveau le plus strict que le projet supporte.
Part automatisable
Ce que Rector corrige seul, souvent la moitié, et ce qui demande un développeur qui comprend le code.
Au-delà du code
Parfois, les causes d'un projet qui s'enlise ne sont pas dans le code
Nous ne disons jamais de mal du prestataire sortant : il est souvent compétent et mal cadré. Quand les mêmes problèmes reviennent après chaque livraison, la cause est ailleurs : dans la façon dont l'équipe travaille, dans ce qui n'est écrit nulle part, ou dans la distance entre ceux qui décident et ceux qui développent. La reprise s'étend à ces trois terrains, sinon le prochain prestataire héritera du même problème.
Organisation d'équipe et gestion de projet
Comment les demandes arrivent, qui les priorise, comment elles sont livrées et recettées. Un prestataire compétent sans cadre produit des régressions et des délais qui glissent : ce que vous constatez vient souvent du flux, pas des personnes. La reprise pose le cadre avant de juger le code.
- Rituels, tickets, planning
- Circuit d'une demande jusqu'en production
- Ce que nous avons fait chez Caprenov
Documentation métier et processus
Les règles que le logiciel applique sont-elles écrites quelque part, ou seulement dans le code et dans la tête du prestataire qui part ? Sans référentiel commun, chaque évolution se renégocie, et un changement de prestataire coûte une partie du métier.
- Glossaire et règles métier
- Processus tels qu'ils sont réellement pratiqués
- Écarts entre le logiciel et le terrain
Faire travailler ensemble métier et technique
Le métier ne comprend pas pourquoi une demande simple prend trois semaines, l'équipe technique ne comprend pas pourquoi la priorité change chaque lundi. C'est souvent là que la relation précédente s'est usée. Nous accompagnons les deux côtés à se lire, pour que les décisions se prennent avec les bonnes informations.
- Vocabulaire commun
- Ce que le métier doit savoir de la technique, et l'inverse
- Direction technique dans la durée
Des projets Symfony repris
Repris, modernisés, exploités depuis
Trois reprises de projets Symfony écrits par d'autres : un projet entier, un cœur de calcul, un backoffice. Aucun n'a été refait, tous ont suivi depuis les évolutions majeures de Symfony et de Vue.js.
Wellscan : l'intégralité du projet
Un MVP développé par un indépendant, repris en entier
La première version avait été développée par un freelance, et elle faisait le travail. Nous avons repris l'intégralité du projet : audit, stabilisation, puis montée en charge, cloisonnement des données et conformité aux exigences de grands comptes. Six ans, 8 baromètres, et une plateforme revendue en 2024.
La Maison Saint-Gobain : le backoffice, l'API et le calcul
Le système de chiffrage des travaux et de calcul des aides, repris et protégé par des tests
Nous avons repris le backoffice, l'API et tout le système de calcul des aides et de chiffrage des travaux. Les formules d'origine sont devenues des tests automatisés qui bloquent le déploiement en cas d'écart. 3 refontes complètes depuis, des pics de charge lors de spots sur TF1 et M6, et 7 ans de collaboration.
CAPRENOV+ : le backoffice et l'espace client
Après la refonte du simulateur, la reprise des parties Symfony
Suite à la refonte de l'application CAPRENOV+, PIA-Production nous a confié les parties backoffice et espace client, développées en Symfony. Le projet a suivi depuis les évolutions majeures de Symfony et de Vue.js, sans chantier de rattrapage.
GLOSSAIRE
Le vocabulaire d'une reprise Symfony
Les termes que vous lirez dans le rapport de reprise et dans les échanges avec l'équipe. Chaque définition dit d'abord ce que ça change pour vous, puis ce que ça veut dire dans le projet.
- Bundle
- Une brique réutilisable qui ajoute une fonctionnalité entière à Symfony : une administration, une API, une authentification. Le projet en dépend autant que du framework. Un bundle dont le mainteneur a disparu bloque la montée de version de tout le reste : c'est le premier point que nous vérifions.
- LTS
- Long Term Support : la version de Symfony maintenue trois ans, plus une année de correctifs de sécurité, contre huit mois pour les autres. C'est la cible de toute reprise, parce qu'elle donne du temps entre deux migrations. Une version hors LTS laissée sans suivi se retrouve sans correctif en moins d'un an.
- Dépréciation
- Une fonctionnalité que le framework signale comme condamnée : elle marche encore, elle disparaîtra à la prochaine version majeure. Symfony les journalise en continu. Leur nombre mesure exactement le travail qui sépare le projet de la version suivante, et Rector en corrige une partie seul.
- composer.lock
- Le fichier qui fige la version exacte de chaque librairie installée. Sans lui, deux installations du même projet ne se ressemblent pas. C'est la première chose que nous lisons : il dit ce dont le projet dépend vraiment, ce qui est abandonné, et ce qui interdit toute montée de version.
- Entité Doctrine
- Une classe PHP qui décrit une table de la base de données et ses relations : un client, une commande, une facture. L'ensemble des entités est le modèle de données du projet, et souvent sa seule documentation exacte, parce que le code l'exécute tous les jours.
- Migration de schéma
- Une modification de la base écrite sous forme de script versionné, rejouable sur chaque environnement dans le même ordre. Son historique raconte l'évolution du projet. Quand il manque ou qu'il diverge de la base réelle, c'est le signe que des modifications ont été faites à la main, sans trace.
- Rector
- L'outil qui réécrit automatiquement le code pour suivre une montée de version de PHP ou de Symfony : signatures, méthodes renommées, syntaxes retirées. Il traite la part mécanique, souvent la moitié du travail. Le reste demande un développeur qui comprend ce que le code fait.
- Intégration continue
- Une chaîne automatique qui, à chaque modification, construit le projet et lance ses tests avant qu'un humain ne relise. Si elle n'existe pas, chaque livraison dépend de la vigilance d'une personne. C'est l'une des premières choses que nous posons sur un projet repris.
- Environnement de recette
- Une copie de l'application, sur un serveur séparé de la production, où vous validez chaque livraison avant que vos utilisateurs la voient. Un projet qui n'en a pas livre directement en production, et chaque mise à jour est un pari.
- Palier de migration
- Une montée de version se fait une majeure à la fois, jamais en sautant : de Symfony 4 à 5, puis de 5 à 6. Chaque palier a sa liste de dépréciations à traiter et ses tests à repasser. Sauter un palier, c'est perdre les messages qui disent ce qui va casser.
D'autres termes sont définis dans notre glossaire général.
Notre savoir-faire
L'expertise qui s'adapte à votre situation
Quel que soit votre point de départ, nous avons les compétences pour vous accompagner : créer de zéro, reprendre l'existant, valider une idée ou moderniser un outil qui montre ses limites.
Développement logiciel sur mesure
Vous avez un besoin métier que les logiciels du marché ne couvrent pas. On conçoit votre outil de zéro, depuis le cahier des charges jusqu'à la mise en production.
Reprise et refonte de logiciel
Votre logiciel existant freine votre transformation numérique : trop lent, trop rigide, impossible à faire évoluer. On reprend le code et on développe un outil spécifique à votre contexte.
TMA et maintenance évolutive
Votre logiciel est en production et doit le rester : corrections, évolutions, mises à jour de sécurité. Une équipe dédiée qui le connaît et le maintient dans la durée.
Prototype et MVP
Vous avez une idée de produit ou de SaaS à valider. On construit un premier outil fonctionnel pour tester vite et à moindre coût.
Hébergement et maintenance
Votre application tourne, mais qui s'assure qu'elle reste disponible, sécurisée et à jour ? On prend en charge le déploiement et le suivi.
Transformation Excel en logiciel
Votre Excel fonctionne mais commence à montrer ses limites. On le transforme en outil métier : automatisation des tâches répétitives, collaboration en temps réel, évolutivité sans contrainte.
Un projet repris, c'est un projet qu'on va exploiter pendant des années. On ne le juge pas à l'entrée, on le lit.
Ce que je regarde en premier, ce n'est pas la qualité du code, c'est si quelqu'un d'autre que son auteur peut le déployer. Quand la réponse est non, c'est par là qu'on commence.
Nos engagements
Ce que vous pouvez exiger de nous
Propriété totale du code source
Vous êtes pleinement propriétaire du code que nous développons pour vous et pouvez maîtrisez son évolution.
Développement 100 % en France
Équipe est basée en France, communication simplifié sans décalage horaire pour une bonne compréhension.
Hébergement cloud souverain
Déploiement sur une infrastructure française avec support réactif. Vos données restent en France.
Votre projet Symfony a besoin d'une nouvelle équipe ?
Décrivez-nous la situation
Le prestataire, la version, ce qui bloque aujourd'hui. Nicolas vous dit ce qui est récupérable en l'état, ce qui presse et ce qui peut attendre. Premier échange gratuit, sans engagement, et sans jugement sur ce qui a été fait avant.
Appel de 30 min → Audit de reprise → Première livraison au premier sprint
« Nous collaborons avec l'équipe Smartbooster depuis 3 ans sur un projet stratégique pour notre activité.
Nous avons largement dépassé la relation « client/prestataire », l'équipe Smartbooster nous accompagne au quotidien dans le développement de nos outils digitaux.
Une équipe experte, réactive et à l'écoute… Je recommande évidemment ! »
« Je recommande vivement Nicolas ! Il a cette grande qualité de structuration des projets qui permet d'avancer toujours de manière positive. En outre il est force de proposition et fait preuve d'une grande créativité.
Vous pouvez compter sur Nicolas ! »
Pour aller plus loin
Approfondir votre réflexion
Le rapport de reprise est le même que celui de notre audit de code : analyse statique, dépendances, tests, architecture, plan d'action priorisé.
Comment nous montons de version palier par palier, ce que Rector automatise, et ce que chaque majeure a changé.
Ce qui se passe après la reprise : un contrat qui couvre corrections, mises à jour et évolutions, pour que le projet ne soit plus jamais à reprendre.
Six versions à renseigner, et l'outil situe chacune dans son calendrier de support. C'est le constat que nous établissons en premier sur tout projet repris.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Oui, et c'est le cas le plus délicat, parce que quelqu'un doit décider. Nous ne vous dirons jamais que votre prestataire travaille mal : nous vous donnerons les critères qui objectivent ce que vous constatez, régressions, délais, choix techniques injustifiés, et vous conclurez. Si l'audit montre que le travail est correct et simplement mal cadré, nous vous le dirons aussi.
C'est notre point de départ le plus fréquent. Sur Symfony, la structure du framework nous donne déjà une grande partie de la carte : services, routes, entités, commandes. Nous reconstruisons le reste au fil des deux premières semaines, et nous ajoutons des tests sur les parties critiques avant d'y toucher.
Ça dépend de ce que dit le calendrier de support. Si votre version est encore couverte, on reprend d'abord, on stabilise, et on migre ensuite dans le flux de maintenance, palier par palier : une montée de version sur un projet qu'on ne connaît pas encore est le meilleur moyen de casser quelque chose sans le voir. Si votre version ne reçoit plus de correctif de sécurité, la migration vers une version supportée est la première mission de la reprise, juste après l'audit : tant qu'elle n'est pas faite, chaque faille publiée reste ouverte. Le bandeau en haut de page dit dans quel cas vous êtes, et notre outil d'analyse de montée de version le précise pour vos versions exactes de PHP et de Symfony.
Oui, quel qu'il soit. Des vues Twig classiques, du Symfony UX avec Stimulus et Turbo, ou un front Vue.js : c'est du Symfony dans les trois cas, et nous le reprenons de la même façon. Vue.js et Tailwind sont un bonus que nous maîtrisons, pas une condition. Un front Vue 2 laissé sans suivi est d'ailleurs souvent le vrai blocage fonctionnel du projet, avant le backend.
Ce qui compte est ce que vous possédez : le dépôt de code, les accès serveurs, le nom de domaine, les données. Si vous les avez, la reprise ne dépend de personne d'autre. Si vous ne les avez pas, c'est la première chose à récupérer, et nous vous disons dans quel ordre et comment.
L'audit de reprise prend 2 à 5 jours. Ensuite, la première livraison sur un environnement de recette vient en général dans le premier sprint de deux semaines : ce sont les corrections critiques et les mises à jour de sécurité identifiées à l'audit.
Un projet repris devient un projet exploité : la reprise débouche sur un contrat de maintenance, où corrections, montées de version et évolutions passent par le même flux. C'est ce qui évite qu'il faille un jour le reprendre à nouveau.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.