Laravel ou Symfony : comment nous tranchons.

Les deux cadres sont excellents, et c’est précisément ce qui rend la question difficile. Aucun projet raisonnable n’échoue parce qu’on a choisi l’un plutôt que l’autre. Le choix a pourtant des conséquences, et elles portent bien moins sur la technique que sur la durée de vie du code, la manière de recruter et le coût de reprise par une autre équipe.

Cet article décrit comment nous tranchons réellement sur un projet, avec les quatre critères que nous appliquons dans l’ordre — et les arguments qui circulent sans rien départager.

Ce qui les rapproche, et qu’on oublie de dire

Ils partagent le même langage, le même gestionnaire de dépendances, et plusieurs composants : la couche de requête HTTP, la console, la traduction, le moteur de gabarits de l’un est utilisable dans l’autre. Un développeur compétent sur l’un devient productif sur l’autre en quelques semaines, pas en quelques mois.

Ils ont aussi le même rythme de publication annuel et des versions à support long. Sur les critères qui comptent pour une direction — pérennité, sécurité, disponibilité des correctifs, taille de l’écosystème — ils sont à égalité. Tout argumentaire qui prétend le contraire vend une préférence.

Les quatre critères qui décident, dans l’ordre

1. Qui reprendra le code

Le critère le plus déterminant n’est pas technique. Un projet vit cinq à dix ans et change de mains une ou deux fois.

• Si le client a une équipe interne, on choisit ce qu’elle connaît. Cet argument l’emporte sur tous les autres, et il n’y a pas de débat à avoir.
• Si le projet est repris par un prestataire local, la disponibilité des profils compte. En France, le marché Symfony est historiquement dense sur les grands comptes et le secteur public ; le marché Laravel est plus large sur les éditeurs, les jeunes structures et les indépendants.
• Si l’entreprise a déjà un parc d’applications, l’homogénéité vaut plus que l’optimum : maintenir deux cadres différents double la charge de veille et de mise à jour.

2. La nature du domaine métier

C’est le critère technique qui discrimine vraiment.

• Symfony est plus à l’aise quand le domaine est complexe et durable : règles métier nombreuses, entités fortement reliées, invariants à protéger, besoin de séparer strictement le métier de l’infrastructure. Sa couche de persistance, fondée sur un gestionnaire d’entités, rend naturelle la modélisation d’un domaine riche. Sa configuration explicite rend visible ce qui est branché où — utile à dix développeurs, pesant à un seul.
• Laravel est plus rapide quand le domaine est simple et le produit large : beaucoup d’écrans, beaucoup de formulaires, des tableaux de bord, des tâches planifiées, des files d’attente, des notifications, une interface d’administration. Sa couche de persistance, fondée sur un enregistrement actif, écrit en trois lignes ce qui en demande quinze ailleurs — et devient encombrante dès que les règles métier se densifient.

Formulé autrement : le premier protège un modèle métier complexe contre l’usure du temps, le second permet de livrer davantage de fonctionnalités par semaine. Sur un outil de gestion interne ou un espace client à trente écrans, l’écart de vitesse est réel. Sur un moteur de tarification à deux cents règles, l’écart de robustesse l’est aussi.

3. Ce qui est déjà fourni

Comparez le périmètre, pas le cadre.

Laravel livre d’emblée une pile complète : files d’attente, ordonnanceur, diffusion d’événements, stockage de fichiers, notifications multicanal, authentification, et un écosystème officiel pour l’administration, la facturation par abonnement ou le déploiement. Symfony fournit des composants de très grande qualité qu’on assemble, avec un écosystème tiers mûr mais moins intégré.

Conséquence budgétaire mesurable : sur un projet à dominante applicative, les briques d’infrastructure déjà présentes représentent facilement quelques semaines de développement sur mesure économisées. Sur un projet où le métier pèse davantage que la plomberie, cet avantage s’efface.

4. Le coût d’exploitation à trois ans

Le critère que personne ne regarde au moment du choix, et le seul qui se paie.

• La montée de version. Les deux publient chaque année. Un projet qui suit les versions à support long et met à jour tous les douze à dix-huit mois reste peu coûteux ; un projet resté trois versions en arrière devient un chantier de réécriture, quel que soit le cadre choisi. C’est une décision de maintenance, pas de technologie.
• La discipline imposée. Symfony contraint davantage, ce qui ralentit au démarrage et protège quand l’équipe tourne. Laravel autorise beaucoup, ce qui accélère et laisse s’installer des raccourcis si personne ne tient la barre. Sur un projet à plusieurs mains et sur plusieurs années, ce point pèse plus lourd que la vitesse initiale.
• Les tests. Les deux les outillent correctement. Un projet sans tests coûtera cher dans les deux cas, et c’est le vrai facteur de dérive.

Les arguments qui ne départagent rien

• « L’un est plus rapide que l’autre. » À l’échelle d’une application web réelle, la performance vient des requêtes à la base, du cache et de la conception des pages. L’écart entre les deux cadres est négligeable devant une requête mal indexée.
• « L’un est plus professionnel. » Un jugement de milieu, pas un critère. Des applications critiques tournent sur les deux.
• « L’un est plus sûr. » Les deux traitent correctement l’injection, le cloisonnement des sessions, la falsification de requête et l’échappement des gabarits. Les failles que nous rencontrons viennent des dépendances tierces et des règles d’accès mal écrites, jamais du cadre lui-même.
• « L’un est plus moderne. » Les deux suivent les évolutions du langage à quelques mois près.

Comment nous tranchons, en pratique

Trois questions, dans cet ordre, et la décision tombe presque toujours d’elle-même.

• Qui maintiendra ce code dans trois ans ? S’il y a une réponse, elle décide.
• Le cœur du projet est-il un domaine métier ou un volume de fonctionnalités ? Domaine riche et durable, Symfony. Produit large à livrer vite, Laravel.
• Quelle part du projet est de la plomberie déjà résolue ? Si elle est importante, le cadre le plus intégré fait gagner des semaines réelles.

Et une remarque qui vaut pour les deux : le choix du cadre pèse moins sur le coût total que trois décisions prises au même moment — la modélisation des données, la couverture de tests, et la personne qui répond quand le site tombe. Sur les reprises de projets que nous menons depuis notre agence web à Paris, l’origine des dérives est presque toujours là, jamais dans le nom du cadre.

En résumé

Symfony et Laravel sont à égalité sur la pérennité, la sécurité et la performance : le choix se fait sur quatre critères, dans l’ordre. Qui reprendra le code — ce que connaît l’équipe l’emporte sur tout. La nature du domaine — riche et durable pour l’un, large et rapide à livrer pour l’autre. Ce qui est déjà fourni — la pile intégrée économise des semaines sur un projet applicatif. Et le coût d’exploitation à trois ans, qui dépend de la discipline de mise à jour, pas du cadre. Les arguments de vitesse, de sérieux ou de modernité ne départagent rien.