Développement Symfony

Pourquoi vous atterrissez sur cette page

Si vous cherchez un développeur Symfony, c’est généralement pour l’une de ces trois raisons : votre projet WordPress ou PrestaShop a atteint ses limites et vous avez besoin d’une architecture sur mesure ; vous héritez d’une application Symfony existante que personne ne maîtrise plus en interne ; ou vous démarrez un projet qui doit exposer une API propre, gérer des règles métier complexes et tenir dans le temps sans que chaque évolution devienne un chantier.

Symfony n’est pas le bon choix par défaut pour un site vitrine ou une boutique en ligne standard — WordPress et PrestaShop font ça très bien, plus vite et moins cher. Symfony devient pertinent quand il y a une vraie logique métier à modéliser : des workflows, des permissions fines, des intégrations avec des systèmes tiers, un volume de données qui justifie une couche d’accès propre. Ce type de projet s’inscrit plus largement dans le développement d’applications web sur mesure, dont Symfony est l’une des briques possibles côté serveur.

Je développe en PHP et Symfony depuis le début de mon activité freelance à Paris, en 2010. Je m’en sers pour construire des applications et des API, pas des sites de contenu — pour ça, j’oriente plutôt vers Next.js côté front ou du CMS classique selon le besoin.

Ce que je construis avec Symfony

La majorité de mes missions Symfony tournent autour de trois briques : une API qui sert de socle à une application front séparée, une couche de persistance propre, et un back-office qui colle aux processus réels de l’équipe plutôt que d’obliger l’équipe à s’adapter à un outil générique.

Ce socle sert aussi bien à alimenter une application CRM ou outil métier qu’à fournir l’API d’une application front en Next.js. Le choix de la stack front est indépendant : Symfony côté serveur n’impose rien côté client.

Comment j’assemble la stack techniquement

Sur un projet neuf, je pars généralement d’API Platform pour exposer les ressources principales : ça évite d’écrire à la main des contrôleurs REST pour chaque entité et ça donne une documentation OpenAPI générée automatiquement, ce qui facilite le travail si une autre équipe doit consommer l’API. Doctrine gère la persistance et les migrations ; je fais attention dès le départ aux relations et aux index, parce que corriger un problème de performance sur une base de données qui a déjà des millions de lignes coûte largement plus cher que d’y penser à la conception.

Messenger entre en jeu dès qu’il y a des traitements qui ne doivent pas ralentir la réponse à l’utilisateur : notifications, génération de PDF, synchronisation avec un service tiers. Je le configure avec une file d’attente (Doctrine, Redis ou un service managé selon le contexte) et des retries pour que les échecs transitoires n’entraînent pas de perte de données.

Je documente les décisions structurantes au fil du projet, pas seulement le code — c’est ce qui permet à une autre équipe de reprendre l’application sans devoir tout redécouvrir en lisant le code source.

Les cas où je vous déconseille Symfony

Si votre projet est un site vitrine, une page de présentation ou une boutique en ligne standard sans logique métier particulière, Symfony est disproportionné. Vous paierez plus cher pour un résultat que WordPress ou PrestaShop couvrent très bien, avec un écosystème de thèmes et de modules qui vous fera gagner du temps. Je vous orienterai vers ces solutions si c’est votre cas, même si ça veut dire ne pas facturer une mission Symfony.

Si votre équipe technique en interne maîtrise déjà Node.js et pas PHP, il vaut souvent mieux rester cohérent avec les compétences disponibles : un projet en NestJS sera plus facile à reprendre par vos développeurs qu’une API Symfony qu’ils devront apprendre à maintenir. La cohérence avec l’équipe qui va vivre avec le code après moi compte autant que la qualité technique du choix initial.

Enfin, si le besoin est purement front — un site de contenu, une landing page, une interface qui consomme une API déjà existante — Symfony n’a rien à faire dans l’équation : autant partir directement sur du Next.js ou un CMS.

Combien coûte un projet Symfony

Un développement d’application sur mesure en Symfony démarre à

— c’est le tarif d’entrée pour une application avec une vraie logique métier, pas pour un site vitrine. Le prix final dépend du nombre d’écrans, de la complexité des règles métier, des intégrations avec des systèmes tiers et du besoin ou non d’un back-office complet.

Pour une mission ponctuelle sur un projet Symfony existant — audit, montée de version, ajout d’une fonctionnalité — je facture en régie entre 400 et 700 € HT par jour selon la complexité. Une fois l’application en production, un accompagnement en maintenance démarre à 80 € HT par mois : surveillance, mises à jour de sécurité des dépendances, corrections mineures.

Je donne un chiffrage précis après avoir vu le périmètre réel du projet, pas un forfait générique : un projet Symfony avec dix entités et trois rôles utilisateurs n’a rien à voir avec un projet à cinquante entités et des workflows d’approbation à plusieurs niveaux.

Comment se déroule une mission

Je démarre par un échange sur le périmètre fonctionnel : qui utilise l’application, quelles données elle manipule, quelles intégrations sont nécessaires. Ça me permet de proposer une architecture avant d’écrire la première ligne de code, plutôt que de la découvrir en cours de route. Pour un projet neuf, je livre généralement par lots fonctionnels testables, pas en un seul bloc à la fin.

Sur une reprise d’application existante, la première étape est un audit du code et de la base de données pour identifier ce qui est fragile avant de toucher à quoi que ce soit — c’est ce qui évite les mauvaises surprises en cours de mission.

Je travaille seul, sans sous-traitance : la personne qui cadre le projet est celle qui écrit le code et qui reste joignable une fois l’application livrée. C’est un choix qui limite le nombre de projets que je peux mener en parallèle, mais qui évite la perte d’information entre celui qui vend et celui qui développe.

Questions fréquentes

Questions fréquentes

Pourquoi choisir Symfony plutôt que Laravel ou un framework Node.js ?+

Symfony a une architecture stricte et une séparation claire des responsabilités, ce qui aide sur des projets longs avec plusieurs contributeurs. Le choix dépend aussi des compétences déjà présentes dans votre équipe : si elle maîtrise Node.js, j’oriente plutôt vers du NestJS.

Pouvez-vous reprendre une application Symfony existante que je ne maîtrise plus ?+

Oui, c’est une part importante de mon activité. Je commence toujours par un audit du code et de la base de données pour comprendre ce qui a été fait avant de proposer des évolutions.

Combien de temps pour développer une application Symfony ?+

Ça dépend entièrement du périmètre : une API avec un back-office simple peut être livrée en quelques semaines, une application avec des workflows métier complexes prend plusieurs mois. Je donne un délai précis après avoir vu le cahier des charges.

Faites-vous aussi le front-end de l'application ?+

Oui, je peux livrer le front en Next.js connecté à l’API Symfony, ou me limiter à l’API si vous avez déjà une équipe front. Les deux fonctionnent, l’important est de le décider dès le cadrage.

Assurez-vous la maintenance après la livraison ?+

Oui, avec un forfait à partir de 80 € HT par mois qui couvre la surveillance et les mises à jour de sécurité. C’est optionnel : certains clients préfèrent gérer ça en interne une fois l’application stabilisée.

Symfony est-il adapté à un petit projet ?+

Pas toujours. Si votre besoin est un site vitrine ou une boutique simple, je vous oriente vers WordPress ou PrestaShop, moins coûteux et plus rapides à mettre en place pour ce type de besoin.