Agence Symfony : SaaS B2B, reprise et migration de vos applications

Vous avez choisi Symfony, ou vous en avez hérité, et vous cherchez une agence Symfony pour la suite. On développe des applications métier et des SaaS B2B sur Symfony et API Platform, on reprend des projets écrits par d'autres équipes et on les amène sur une version maintenue.

Réponse sous 24 h Diagnostic gratuit Sans engagement

Une agence Symfony, pour quoi faire ?

Vous avez déjà tranché la question du framework : vous êtes CTO ou responsable technique, ou votre entreprise hérite d'une application Symfony. Personne n'a besoin de vous vendre PHP. Il vous faut du code écrit dans les conventions du framework, des développeurs capables de lire celui d'une autre équipe, et, version par version, la date jusqu'à laquelle votre application reçoit des correctifs de sécurité.

Applications métier et SaaS B2B sur Symfony et API Platform
Reprise et maintenance (TMA) d'un projet Symfony existant
Audit de code, de dépendances et d'exploitation
Migration et montée de version vers une LTS
Direction technique : stack, architecture, règles de code
API et intégrations avec vos outils : ERP, CRM, paiement

Pourquoi Symfony tient la route sur un SaaS B2B

Une date de fin de support écrite

La LTS 7.4 reçoit des correctifs de sécurité jusqu'en novembre 2029, et symfony.com le publie. Vous planifiez vos montées de version au lieu de les subir le jour où une faille sort.

Des ruptures annoncées à l'avance

Entre deux versions mineures, Symfony s'engage sur la rétrocompatibilité. Ce qui disparaîtra à la majeure suivante est d'abord déprécié, et signalé.

Une API décrite par le code

API Platform génère les points d'entrée REST ou GraphQL et la documentation OpenAPI à partir de vos classes, et fournit la pagination et des filtres prêts à déclarer. Le budget va aux règles métier.

Des composants pour le métier

Workflow pour la machine à états d'une commande ou d'un dossier, Messenger pour les traitements asynchrones, Security pour les droits.

Nos prestations Symfony

Applications métier et SaaS B2B

Back-office, espace client, place de marché, SaaS par abonnement. On part de vos règles de gestion, et de ce qui doit rester vrai quand deux requêtes arrivent en même temps.

Symfony API Platform PostgreSQL Doctrine

Reprise et TMA

Votre prestataire est parti, ou votre équipe manque de bras. On réinstalle le projet à partir du seul dépôt pour vérifier qu'il se suffit, puis on corrige, on fait évoluer et on tient les versions à jour.

Maintenance corrective Évolutions Mises à jour

Audit de code

Notre grille tient en quatre plans : sécurité, données et conformité, dette technique, exploitabilité. Chaque problème relevé est localisé, et les points bloquants sont séparés de ce qui peut attendre.

Sécurité Dette technique composer audit

Migration et montée de version

De Symfony 4, 5 ou 6 vers la LTS 7.4, ou vers la branche 8. Une version majeure à la fois, les dépréciations traitées avant chaque saut, et la montée de PHP menée comme une étape à part.

Symfony 7.4 LTS Symfony 8 PHP 8.4

Direction technique

Choix de la stack, architecture, règles de code écrites avec leur commande de vérification, process d'équipe, relecture et fusion des Pull Requests. C'est le rôle que nous avons tenu sur ranksource.

Architecture Revue de code Intégration continue

API et intégrations

Ouvrir vos données à un partenaire, brancher un ERP, un CRM ou un paiement Stripe. API Platform fournit la plomberie HTTP ; le travail porte sur les droits, la validation et la forme des données.

API Platform OpenAPI Stripe Webhooks

SaaS B2B : une stack Symfony qui tiendra cinq ans

Vous lancez un SaaS B2B, ou une application métier que vos équipes ouvriront tous les matins. Son coût se jouera après le lancement, sur la montée de version qu'on a repoussée ou le jour où un partenaire demande un accès à l'API.

Aucune version de Symfony ne couvre à elle seule cinq ans à partir d'aujourd'hui : la LTS 7.4 reçoit des correctifs de sécurité jusqu'en novembre 2029, et la suivante, 8.4, est prévue pour novembre 2027, avec une sécurité annoncée jusqu'en novembre 2031. Une stack qui tient cinq ans est donc une trajectoire : une LTS, puis la suivante, avec les dépréciations traitées au fil de l'eau pour que le passage de l'une à l'autre ne tourne pas à la réécriture.

Le reste se joue dans l'architecture, dès les premières semaines. Le cas ranksource, plus bas, montre ce que ça donne sur une plateforme qui gère des paiements et des versements. Pour la facturation d'un SaaS, nous avons aussi documenté l'intégration des liens de paiement Stripe dans Symfony.

Vous n'avez pas encore choisi votre socle ? Commencez par notre article sur les cas où Symfony est le bon choix, et ceux où il ne l'est pas. Si la vraie question est de savoir s'il faut développer un outil ou garder un abonnement, la méthode de calcul logiciel sur mesure ou SaaS y répond avant nous. Et si vous cherchez un prestataire pour un outil web sans avoir d'avis sur la technique, notre page développement web est écrite pour vous.

Deux sujets voisins ont leur propre page. Une boutique ou une marketplace e-commerce sur Sylius, une plateforme e-commerce open source construite sur Symfony : voyez notre agence Sylius. Un modèle de langage à brancher dans une application Symfony, avec les composants Symfony AI ou le protocole MCP : c'est la page Symfony AI.

ranksource : une marketplace B2B construite sur Symfony et API Platform

ranksource est une place de marché de contenu sponsorisé : des annonceurs y achètent des articles et des liens, des éditeurs de sites y vendent des emplacements. De l'argent réel y circule, entre paiements, portefeuilles et versements aux éditeurs.

Nous l'avons conçue et développée, et nous en avons assuré la direction technique : la stack, l'architecture, les règles de code et le process d'équipe. Cinq personnes de notre équipe ont produit 1 796 commits sur les huit premiers mois du projet. Le premier commit, c'est nous : une API Symfony et API Platform sur PostgreSQL, rejointe ensuite par une interface React en TypeScript. Sur les 164 Pull Requests fusionnées par merge commit, 116 l'ont été par notre direction technique, dernier filtre avant la branche d'intégration. Le dépôt vit dans notre organisation GitHub et la production tourne sur notre infrastructure.

Plusieurs choix de ce projet valent pour tout SaaS qu'on veut encore maintenir dans cinq ans.

La sérialisation vit hors des entités. Aucune entité Doctrine ne décide de ce qui sort dans l'API : sur 869 fichiers PHP, zéro attribut #[Groups], tout est décrit dans des fichiers YAML séparés. Changer ce qu'un endpoint expose ne touche jamais au code métier, et la même entité se lit différemment selon qu'on est annonceur, éditeur, administrateur ou partenaire externe. La règle est triviale ; la tenir huit mois à cinq, y compris sur les fonctionnalités livrées dans l'urgence, l'est beaucoup moins.

Le double versement est bloqué par la base. Une même ligne de commande ne peut entrer que dans un seul versement, et cette garantie est portée par une contrainte d'unicité en base. Un bug, un double clic ou deux requêtes concurrentes échouent donc au niveau de la base, sans produire de double virement.

L'API partenaire est versionnée dès la v1. La version est dans l'URL, pour qu'une v2 coexiste sans casser les consommateurs de la première. Un firewall dédié évite que le jeton statique du partenaire soit décodé comme un JWT, et les jetons sont stockés sous forme d'empreinte SHA-256, montrés une seule fois.

Les règles transverses embarquent leur propre vérification. Chacune se termine par une checklist et les commandes qui la vérifient. Nous les avons rejouées au moment de l'analyse du dépôt ; les écarts qu'elles trouvent encore, la spécification les nomme elle-même. Les documents de convention écrits sans ce mécanisme, eux, décrivaient encore un framework front abandonné depuis.

Nous avons aussi fait un arbitrage : livrer vite et repousser la vérification. Sur ces huit premiers mois, l'intégration continue contrôlait la syntaxe PHP, les fichiers YAML, la compilation TypeScript et les builds, mais n'exécutait pas les suites de tests. Notre grille d'audit range l'absence de tests au plan de la dette technique, et elle vaut aussi pour notre propre code. Le projet complet est raconté dans notre cas client sur l'anatomie de la marketplace ranksource.

D'autres applications web Symfony figurent dans notre portfolio : LudiLabel, Getfluence et ELEO (application web et API Symfony).

Migration Symfony 7 et 8 : passer sur une version maintenue, une majeure à la fois

Au 24 septembre 2026, voici les versions de Symfony qui reçoivent encore des correctifs, d'après le calendrier publié par le projet.

Versions de Symfony maintenues au 24 septembre 2026 : statut, fin des correctifs de bugs, fin des correctifs de sécurité et version minimale de PHP
Version Statut Bugs corrigés jusqu'à Sécurité jusqu'à PHP minimum
Symfony 8.1 Stable, sortie en mai 2026 janvier 2027 janvier 2027 8.4
Symfony 7.4 LTS, sortie en novembre 2025 novembre 2028 novembre 2029 8.2
Symfony 6.4 LTS, sortie en novembre 2023 novembre 2026 novembre 2027 8.1
Symfony 5.4 LTS, sécurité seulement terminé en novembre 2024 février 2029 (prolongation sponsorisée) 7.2.5

Sources : symfony.com/releases et php.net, consultés le 24 septembre 2026. La 8.2 est attendue en novembre 2026 ; la prochaine LTS, 8.4, en novembre 2027.

Une version sortie du calendrier ne reçoit plus aucun correctif, même quand une faille est publiée. Toute version absente du tableau n'en reçoit déjà plus : Symfony 4, les mineures 5.0 à 5.3, 6.0 à 6.3 et 7.0 à 7.3, et la 8.0. Pour la 6.4, les correctifs de bugs s'arrêtent en novembre 2026 et ceux de sécurité en novembre 2027. PHP a son propre calendrier : PHP 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026. À partir de janvier 2027, une application Symfony 7.4 restée sur PHP 8.2 tourne donc sur un moteur qui n'est plus maintenu, alors que le framework l'est encore.

Notre ordre de marche s'appuie sur la politique de versions de Symfony, qui ne supprime rien sans l'avoir d'abord déprécié.

L'inventaire. Version de Symfony et de PHP en production, bundles tiers et leur compatibilité avec la version visée, tests existants et ce qu'ils couvrent réellement. La commande composer audit liste déjà les dépendances visées par un avis de sécurité, et celles qui sont abandonnées.

La dernière mineure de votre branche. 5.4, 6.4 ou 7.4 : entre deux mineures, Symfony garantit la rétrocompatibilité. C'est sur cette version qu'on voit toutes les dépréciations de la branche, dans la barre de debug et dans le résumé que le PHPUnit Bridge affiche à chaque exécution des tests.

Zéro dépréciation, puis le saut. Contraintes Composer sur la nouvelle majeure, mise à jour des recettes Flex avec composer recipes:update, lecture du fichier UPGRADE de la version : c'est le chemin que la documentation officielle décrit.

Une majeure à la fois. De la 5.4 on passe à la 6.4, puis à la 7.4, parce que chaque majeure retire les dépréciations de la précédente, et qu'on ne les voit toutes qu'une fois arrivé sur la dernière mineure.

Pour choisir entre la 7.4 et la branche 8, regardez votre rythme de mise à jour. Les deux sont sorties en novembre 2025 ; la 8 a retiré ce que la 7.4 dépréciait et exige PHP 8.4. Pour une seule date à retenir, visez la LTS 7.4. Si votre équipe monte de version tous les six mois, la branche 8 mène à la LTS 8.4, prévue pour novembre 2027. Les apports de Symfony 7.0 sont résumés dans notre article sur les nouveautés de Symfony 7, et le même calendrier est expliqué pour un lecteur non technique dans notre guide du socle technique.

Une migration dérape pour des raisons connues : l'absence de tests, qui oblige à tout revérifier à la main ; un bundle tiers abandonné, à remplacer ou à reprendre soi-même ; du code qui contourne le framework au lieu de l'étendre, et qui casse sans prévenir ; une montée de PHP menée en même temps, sans retour arrière prévu. Aucune durée ne vous sera annoncée avant qu'on ait lu le dépôt : c'est l'objet du diagnostic offert. Quand les tests manquent, nous recommandons d'en écrire d'abord sur les parcours qui font rentrer de l'argent, avant de toucher à la moindre version.

Des développeurs Symfony pour reprendre un code écrit par d'autres

Reprendre une application Symfony écrite par une autre équipe commence par une vérification simple : est-ce qu'elle se reconstruit sans son auteur ?

Sur un dépôt qu'on découvre, on déroule notre grille d'audit. On réinstalle le projet à partir de son seul contenu, on lit la configuration de sécurité et les règles d'accès côté serveur, on liste les dépendances et leurs avis de sécurité, on repère où vivent les règles de gestion, et on regarde ce que les tests protègent vraiment. Vous recevez un état des lieux écrit, qu'une autre équipe que la nôtre peut vérifier point par point. Si l'application a été écrite en partie par une IA, notre grille d'audit d'une application générée par IA détaille les quatre plans vérifiés.

Vient ensuite la maintenance : corrections, évolutions, et montées de version calées sur le calendrier de Symfony et de PHP.

Nous codons avec des assistants IA, encadrés par des règles écrites pour Symfony et API Platform : notre article sur les règles Cursor pour Symfony et API Platform montre à quoi elles ressemblent. Sur ranksource, des commits portent la co-signature d'un agent IA.

Si le chantier consiste à brancher l'application sur votre CRM ou votre ERP, les quatre scénarios d'intégration par API posent les questions à trancher avant d'écrire du code.

Ce que coûte une équipe Symfony chez EpickOne

Notre tarif journalier figure ci-dessous. Le nombre de jours dépend de votre projet et on ne le devine pas : on le chiffre après un diagnostic offert, sur votre dépôt ou votre cahier des charges.

600 à 900 EUR
tarif journalier
Diagnostic offert avant tout devis
On regarde votre code, votre version de Symfony et vos échéances de support avant de chiffrer
Une migration se chiffre après l'inventaire des dépendances et des tests
Reprise d'un projet : l'audit du dépôt passe avant tout engagement sur la maintenance

Prêt à lancer votre prochain projet ?

Racontez-nous votre idée. On vous répond sous 24h avec une première analyse et des pistes concrètes — sans engagement.

24h
Temps de réponse
50+
Projets livrés
100%
Projets maintenus
2
Agences en France

Pourquoi choisir EpickOne ?

Des développeurs backend Symfony

Laurent et Alexis, nos deux développeurs backend, sont experts Symfony et API Platform. Vous parlez aux gens qui écrivent le code.

La direction technique, sur pièces

Sur ranksource, la stack, l'architecture, les règles de code et le process d'équipe sont les nôtres : le détail est dans le cas client plus haut.

Des dates sourcées

Pour chaque version en production, on vous donne la date de fin des correctifs de sécurité, avec le lien vers symfony.com ou php.net.

Questions fréquentes

Développeur Symfony freelance ou agence Symfony : que choisir ?
Un freelance convient bien à une mission cadrée, quand quelqu'un en interne relit son code. Quand personne ne peut le relire, une agence ajoute ce filtre : sur ranksource, c'est notre direction technique qui a fusionné la majorité des Pull Requests intégrées par merge commit. Chez nous, deux développeurs backend Symfony et API Platform, deux développeurs frontend et un designer.
Quelle version de Symfony choisir pour un nouveau projet ?
Au 24 septembre 2026, deux options tiennent. La LTS 7.4 (PHP 8.2 minimum) reçoit des correctifs de sécurité jusqu'en novembre 2029. La branche 8 (PHP 8.4 minimum) sort une mineure tous les six mois, chacune maintenue huit mois, jusqu'à la LTS 8.4 prévue pour novembre 2027 : elle suppose de monter de version à ce rythme. Pour un SaaS B2B qui veut une seule date à retenir, la 7.4, sur une version récente de PHP : PHP 8.4 reçoit des correctifs de sécurité jusqu'au 31 décembre 2028, PHP 8.5 jusqu'au 31 décembre 2029.
Mon application tourne sur Symfony 4 ou 5 : faut-il tout réécrire ?
Pas forcément, et on ne le décide pas sans avoir lu le code. Symfony 4 n'est plus maintenu ; la 5.4 ne reçoit plus que des correctifs de sécurité, jusqu'en février 2029, grâce à une prolongation financée par un sponsor. La voie normale passe par les dernières mineures, 4.4 puis 5.4, 6.4 et 7.4, en traitant les dépréciations à chaque étape. La réécriture se discute quand le code contourne massivement le framework, ou quand aucun test ne protège les règles de gestion. Le calendrier et la méthode de migration
Combien de temps prend une migration Symfony ?
Ça dépend du nombre de versions majeures à franchir, du volume de dépréciations, des bundles tiers qui n'ont pas suivi et de la présence de tests. Nous ne donnons pas de durée sans avoir vu le dépôt : le diagnostic offert sert à la chiffrer.
Reprenez-vous une application Symfony développée par une autre agence ?
Oui. On commence par un audit du dépôt, et vous recevez un état des lieux écrit avant de décider de la suite. Notre grille d'audit en détail
Combien coûte un développeur Symfony chez EpickOne ?
Nous facturons à la journée, et c'est le nombre de jours qui fait la différence d'un chantier à l'autre. Pour une montée de version, il dépend surtout des majeures à franchir et des tests déjà en place ; pour un SaaS, du périmètre de la première version. On le chiffre après le diagnostic offert. Voir le tarif journalier
Développez-vous aussi des boutiques Sylius ?
Oui. Sylius est une plateforme e-commerce open source construite sur Symfony, et nous lui consacrons une page à part. Notre agence Sylius
Pouvez-vous intégrer un modèle de langage dans une application Symfony ?
Oui. Sur ranksource, un service passe par un composant de Symfony AI pour contrôler les messages de négociation entre annonceurs et éditeurs. Les composants Symfony AI, le protocole MCP et ce que nous en faisons sont détaillés sur une page dédiée. Symfony AI et MCP

Parlons de votre projet

Vous avez un projet en tête ? Discutons ensemble de la façon dont nous pouvons vous aider à le concrétiser.

Réponse sous 24 h ouvrées Devis & diagnostic gratuits Sans engagement