Laravel vs NestJS (2026) : lequel choisir ? Leçons de projets réels

Pendant un bon moment chez We Do Dev Work, on me connaissait comme « la fille de Laravel ».

La réponse courte : choisissez Laravel pour une application métier classique (comptes, paiements, écrans d'administration, files d'attente) qu'une équipe PHP doit livrer vite : il prend la plupart des décisions pour vous. Choisissez NestJS quand le backend a des domaines bien distincts, que l'équipe écrit déjà du TypeScript, ou que le front-end et le back-end doivent partager un seul langage. Les deux sont opinionés : Laravel choisit votre stack, NestJS choisit votre structure.

C'était le premier framework backend avec lequel je me suis vraiment sentie à l'aise, et après l'avoir utilisé sur des projets comme PUT-IT-ON, où j'ai travaillé sur les paiements, la planification, les files d'attente et d'autres fonctionnalités backend, j'ai compris pourquoi. Laravel me rend productive. Beaucoup des décisions à prendre lorsqu'on construit une application web sont déjà prises, les différentes parties du framework fonctionnent bien ensemble, et une fois qu'on connaît la manière de faire de Laravel, on avance remarquablement vite.

Plus récemment, j'ai travaillé avec NestJS, notamment sur EngineeringScore, où nous construisons un backend qui analyse des sites web sur la sécurité, la performance, le SEO, l'accessibilité et la fiabilité avant de combiner ces résultats en un score transparent. C'est un type de projet très différent, et NestJS m'a amenée à penser autrement la façon de structurer des applications backend.

La conclusion simple serait que je suis passée de PHP à TypeScript et que j'ai découvert que je préférais l'un à l'autre, mais ce n'est pas vraiment ce qui s'est passé. J'aime toujours Laravel, et il y a de nombreux projets pour lesquels je le choisirais dès demain.

Ce que j'ai trouvé plus intéressant, c'est que Laravel et NestJS appartiennent en réalité à la même famille sur un point important : ce sont tous deux des frameworks opinionés. Ils ne se contentent pas de vous donner une collection d'outils en vous laissant vous débrouiller pour les assembler. Tous deux ont des idées bien arrêtées sur la manière dont une application backend doit être construite.

Ils ont simplement des opinions sur des choses différentes.

Laravel prend pour moi beaucoup de décisions d'application, ce qui explique en grande partie pourquoi il me rend si productive. NestJS laisse davantage de choix technologiques ouverts, mais il est beaucoup plus explicite sur les modules, les dépendances et les frontières architecturales, ce qui explique sans doute pourquoi il me fait davantage réfléchir à l'architecture.

Après avoir travaillé avec les deux, j'ai réalisé que cette différence est bien plus utile pour choisir entre eux que de simplement comparer PHP et TypeScript ou de dresser une énième liste de fonctionnalités de frameworks.

Où en sont les choses en octobre 2026

Depuis que j'ai commencé à écrire sur ce sujet, les deux frameworks ont évolué ; voici donc les faits actuels, vérifiés sur les sites officiels.

• Laravel 13 est sorti le 17 mars 2026. Il nécessite PHP 8.3 ou plus récent, reçoit des corrections de bugs jusqu'au T3 2027 et des correctifs de sécurité jusqu'au 17 mars 2028 (notes de version de Laravel). Laravel 12 reçoit encore des correctifs de sécurité jusqu'au 24 février 2027, mais sa période de corrections de bugs s'est terminée le 13 août 2026. Laravel 11 n'est déjà plus pris en charge côté sécurité.

• PHP : la version 8.5 (novembre 2025) est en support actif jusqu'au 31 décembre 2027. PHP 8.2 atteint la fin du support de sécurité le 31 décembre 2026 (php.net) : toute application Laravel encore sur 8.2 aura donc de toute façon bientôt besoin d'une mise à niveau de PHP.

• NestJS 12 a été publié pour la première fois le 27 août 2026, et la dernière version au moment de la rédaction est la 12.1.3 (12 octobre 2026) (versions de NestJS). Il nécessite Node.js 20.19+ ou 22.12+, et ses paquets principaux sont désormais livrés en ESM (notes de la v12.0.0).

• Node.js : v24 et v22 sont les branches LTS et v26 est la version courante ; les anciennes branches impaires et paires sont en fin de vie (versions de Node.js). En production, restez sur une branche LTS.

Une différence pratique : la politique de support de Laravel est simple et prévisible (une nouvelle version majeure par an, vers le T1, 18 mois de corrections de bugs, 2 ans de correctifs de sécurité). NestJS n'a pas de fenêtre de support fixe de ce type : avec NestJS, vous vous appuyez donc sur la dernière version majeure et sur le calendrier LTS de Node.js. Aucun des deux n'est un problème, mais prévoyez dans tous les cas une mise à niveau tous les un à deux ans. Si vous pesez aussi la question du langage, voyez Python vs Node.js et, pour l'autre grand duo de l'entreprise, .NET vs Java en 2026.

Être opinioné est un atout, pas une limite

Les développeurs emploient parfois « opinioné » comme s'il s'agissait d'une critique. Un framework vous dit comment organiser quelque chose, alors qu'une technologie moins opinionée vous laisse la liberté de décider vous-même.

Cette liberté semble attrayante, mais chaque décision a un coût.

Si un framework ne vous dit pas comment gérer quelque chose, quelqu'un dans l'équipe doit décider. Il faut choisir une bibliothèque, s'accorder sur un modèle, le documenter, s'assurer que tout le monde le suit et, avec un peu de chance, prendre une décision que l'on ne regrettera pas deux ans plus tard.

Un framework opinioné vous retire une partie de ces décisions.

C'est particulièrement utile en équipe. Quand j'ouvre un projet Laravel créé par un autre développeur Laravel, j'ai déjà une assez bonne idée de ce que je vais trouver. Les routes, contrôleurs, modèles, migrations, jobs et commandes ont des emplacements familiers. L'implémentation peut évidemment rester bonne ou mauvaise, mais on part au moins d'une compréhension commune de l'organisation de l'application.

NestJS offre quelque chose de similaire. Si j'ouvre une application NestJS que je ne connais pas, je m'attends à voir des modules, des contrôleurs et des providers. Je m'attends à ce que les dépendances soient injectées plutôt que créées n'importe où dans l'application. Là encore, rien de tout cela ne garantit un bon code, mais le framework fournit un langage commun aux développeurs qui y travaillent.

C'est pourquoi je pense que Laravel et NestJS sont plus comparables qu'ils n'y paraissent. L'un est un framework PHP et l'autre appartient résolument à l'écosystème TypeScript et Node.js, mais tous deux cherchent à donner des conventions aux équipes de développement plutôt que de les laisser devant une page blanche.

La différence devient intéressante quand on regarde les décisions que chaque framework veut prendre à votre place.

Laravel prend beaucoup de décisions à votre place

Laravel a une idée très complète de ce dont une application web a besoin.

Le routage, les migrations de base de données, la validation, l'authentification, les files d'attente, le cache, les événements, les tâches planifiées et les outils en ligne de commande ont tous des approches Laravel établies. Eloquent vous donne un ORM qui paraît être une extension naturelle du reste du framework, tandis que des outils comme Artisan simplifient de nombreuses tâches de développement répétitives.

Vous pouvez remplacer des parties de cet écosystème si vous avez une bonne raison de le faire, mais la plupart du temps ce n'est pas nécessaire.

Cela a un impact énorme sur la productivité.

Quand j'implémente une fonctionnalité, je peux passer plus de temps à réfléchir à la fonctionnalité elle-même et moins de temps à décider quel paquet doit résoudre chaque problème technique. Il y a généralement une manière de faire Laravel, il y a généralement une bonne documentation pour cela, et une très grande communauté a probablement déjà rencontré un problème semblable.

PUT-IT-ON a été un bon exemple pour moi. La plateforme demandait un ensemble de fonctionnalités comprenant les paiements, la planification, les files d'attente et la logique très orientée base de données qu'on attend d'une plateforme métier. Construire ce genre de chose implique beaucoup de décisions d'architecture, mais aussi de nombreux problèmes qui ne sont pas propres au produit.

Je ne veux pas inventer une nouvelle manière de traiter les tâches en arrière-plan chaque fois qu'un projet a besoin d'une file d'attente. Je ne veux pas concevoir un système de migrations parce que le schéma de la base a changé. Ce ne sont pas ces problèmes qui rendent PUT-IT-ON unique ; disposer d'un framework qui fournit déjà de solides solutions permet donc de consacrer davantage de temps de développement aux problèmes qui comptent vraiment pour le produit.

C'est ce que je veux dire quand je dis que Laravel me rend productive.

Ce n'est pas simplement que PHP serait plus rapide à écrire, ou que Laravel aurait une syntaxe pratique. C'est que le framework retire de ma journée un nombre étonnant de décisions.

Productivité ne veut pas dire que Laravel est réservé aux applications simples

Il y a ici un piège évident.

Quand on décrit Laravel comme facile à utiliser et rapide pour développer, la conclusion qui suit est souvent qu'il est parfait pour de petites applications mais qu'il faut quelque chose de « plus architectural » dès qu'un système devient grand.

Je ne pense pas que ce soit juste.

Laravel ne vous empêche pas de créer de bonnes frontières, de séparer la logique métier ou de concevoir correctement une grande application. Vous pouvez introduire des services, des actions, des domaines, des repositories ou d'autres modèles là où ils ont du sens. Laravel vous laisse beaucoup de latitude pour concevoir une application sophistiquée.

Le risque est en fait une conséquence de la productivité que Laravel peut offrir.

Comme il est si facile d'ajouter une méthode de contrôleur, d'étendre un modèle Eloquent ou de mettre un peu plus de logique dans une classe existante, on peut continuer à avancer vite pendant assez longtemps sans être forcé de repenser la structure. Si l'équipe de développement manque de discipline, une première année très productive peut créer une troisième année beaucoup moins productive.

Ce n'est pas la faute de Laravel. On peut créer une architecture désastreuse avec n'importe quel framework, NestJS compris.

Cela signifie en revanche que les développeurs doivent reconnaître le moment où la commodité qui les a fait avancer vite au début doit être complétée par des décisions d'architecture plus solides à mesure que l'application grandit.

NestJS a une autre opinion

NestJS m'a paru familier à certains égards parce qu'il est lui aussi opinioné, mais l'accent est différent.

NestJS a des idées bien arrêtées sur la structure.

Les modules définissent les frontières au sein de l'application. Les contrôleurs gèrent les requêtes entrantes. Les providers contiennent des fonctionnalités qui peuvent être injectées là où on en a besoin. L'injection de dépendances fait partie du framework, au lieu d'être introduite plus tard parce que la base de code est devenue difficile à tester ou à maintenir.

Cela signifie que l'architecture devient visible très tôt dans le projet.

Même pour une fonctionnalité relativement simple, on est encouragé à se demander quel module en est responsable, quel provider doit implémenter la logique et quelles dépendances ce provider doit avoir.

Parfois, c'est excellent.

Parfois, c'est aussi plus de travail.

Si je construis une application CRUD très simple, il y a des situations où la structure supplémentaire ne m'apporte pas immédiatement beaucoup de valeur. Créer un module, un provider et un DTO de plus n'est pas automatiquement de la bonne architecture simplement parce que tout a été réparti dans davantage de fichiers.

L'architecture doit résoudre la complexité, pas la créer.

NestJS a commencé à avoir beaucoup plus de sens pour moi quand j'ai travaillé sur un backend dont la complexité était déjà réelle.

EngineeringScore est un backend très différent

EngineeringScore analyse des sites web et les évalue dans plusieurs domaines, dont la sécurité, la performance, le SEO, l'accessibilité et la fiabilité. Ces résultats doivent ensuite se combiner pour produire un score selon une méthodologie transparente et déterministe.

Du point de vue du produit, c'est une seule fonctionnalité : analyser mon site web et me dire à quel point son ingénierie est bonne.

Du point de vue du backend, c'est un ensemble de responsabilités assez différentes.

Une analyse de performance n'a pas besoin de savoir comment l'accessibilité est mesurée. Les contrôles de sécurité ont d'autres exigences que les contrôles SEO. Le composant chargé de calculer un score final ne devrait pas avoir à comprendre chaque détail d'implémentation des analyseurs qui produisent les résultats sous-jacents.

Il y a aussi des services externes, des API et des processus en arrière-plan, ce qui fait que le backend comporte naturellement plusieurs frontières.

Dans cet environnement, la structure que NestJS encourage devient très utile.

Au lieu de nous demander comment mettre toutes ces fonctionnalités dans une seule application, nous pouvons réfléchir aux différents domaines à l'intérieur de cette application et définir comment ils communiquent. L'injection de dépendances rend ces relations explicites, tandis que les modules nous donnent un endroit naturel pour tracer les frontières.

C'est ce que je veux dire quand je dis que NestJS me fait davantage réfléchir à l'architecture.

Ce n'est pas que NestJS crée magiquement une meilleure architecture. Une application NestJS mal conçue peut quand même avoir des dizaines de modules aux responsabilités floues et des dépendances partout.

La différence, c'est que le framework me remet sans cesse des questions d'architecture sous les yeux.

Avec Laravel, j'ai souvent le sentiment que le framework me demande : « Que veux-tu construire ? »

Avec NestJS, je me surprends plus souvent à me demander : « À quel endroit cela doit-il appartenir ? »

Les deux questions sont utiles.

NestJS vous donne de la structure, mais il vous reste des choix à faire

Il y a une autre différence importante.

Les opinions de Laravel vont assez loin dans la stack technologique. Eloquent est le choix évident pour la base de données. Laravel a son propre système de files d'attente, son propre système de migrations, ses solutions d'authentification et un vaste écosystème d'outils officiels ou étroitement intégrés.

NestJS vous donne une solide structure d'application mais laisse davantage de choix périphériques ouverts.

Vous pouvez utiliser Prisma ou TypeORM. Vous devez décider comment la persistance doit fonctionner. Il existe différentes approches pour les files d'attente et le traitement en arrière-plan. Même la plateforme HTTP sous-jacente n'est pas totalement figée.

Pour certaines équipes, cette flexibilité est exactement ce qu'elles veulent. Pour d'autres, c'est simplement une liste de décisions plus longue.

Aucune des deux n'est automatiquement meilleure.

Si les exigences techniques de l'application sont inhabituelles, disposer de ces choix peut être précieux, car on ne lutte pas contre des hypothèses posées par le framework. Si l'on construit quelque chose de relativement classique, devoir prendre ces décisions peut revenir à passer du temps sur des problèmes que Laravel a déjà résolus pour vous.

C'est probablement la principale raison pour laquelle je ne vois plus la comparaison comme PHP contre TypeScript.

C'est en réalité une question de savoir où vous voulez que le framework décide et où vous voulez que votre équipe d'ingénierie décide.

TypeScript reste une raison majeure

Bien sûr, le langage n'est pas anodin.

Chez We Do Dev Work, nous utilisons beaucoup TypeScript, en particulier côté front-end ; NestJS a donc un avantage organisationnel évident. Les développeurs déjà familiers avec TypeScript n'ont pas besoin de changer de langage quand ils passent du front-end au backend, et nous pouvons utiliser des outils et des pratiques de développement similaires des deux côtés.

Pour une équipe full-stack TypeScript, c'est vraiment utile.

Mais je ne choisirais pas NestJS uniquement parce que « un seul langage partout » fait plus propre sur un schéma d'architecture.

Une équipe de développeurs Laravel expérimentés ne va pas soudain devenir plus productive parce que la direction a décidé que TypeScript est plus moderne. L'expertise existante compte, tout comme l'écosystème qui entoure une application existante.

Le choix technologique doit inclure les personnes qui vont l'utiliser.

C'est particulièrement important pour une agence, car nous ne choisissons pas une fois pour toutes notre framework favori pour l'utiliser indéfiniment. Chaque client a des systèmes existants différents, des équipes internes différentes, des exigences différentes et des plans différents sur la personne qui maintiendra le logiciel après le lancement.

Parfois Laravel est le choix évident. Parfois c'est NestJS. Parfois ni l'un ni l'autre.

Alors, quand choisirais-je Laravel ?

Après avoir travaillé avec les deux frameworks, je pencherais pour Laravel lorsque l'application profite davantage de son écosystème intégré que de l'exposition de chaque choix d'architecture.

Des exemples typiques :

• Une application métier avec beaucoup de CRUD et de fonctionnalités de base de données.

• Une plateforme qui a besoin d'authentification, de files d'attente, de tâches planifiées, de notifications et d'autres fonctionnalités backend courantes.

• Un projet où mettre rapidement en ligne une première version de production solide est particulièrement important.

• Une application construite ou maintenue par une équipe ayant une solide expérience de PHP et de Laravel.

• Un projet où les conventions existantes de Laravel résolvent déjà l'essentiel des problèmes techniques qui entourent la logique métier proprement dite.

C'est pourquoi Laravel a fonctionné si naturellement pour quelque chose comme PUT-IT-ON. Il y avait beaucoup de logique métier sur mesure à construire, mais aussi de nombreux problèmes classiques d'application web pour lesquels je n'avais pas besoin de la liberté d'inventer ma propre solution.

J'avais besoin qu'ils fonctionnent.

Laravel m'a permis de me concentrer là-dessus.

Et quand choisirais-je NestJS ?

Je pencherais pour NestJS lorsque la structure du backend elle-même constitue une part importante du défi d'ingénierie.

Par exemple :

• Une application avec plusieurs domaines clairement séparés.

• Un backend qui coordonne plusieurs API ou services externes.

• Des systèmes avec plusieurs workers ou processus remplissant des responsabilités différentes.

• Une équipe de développement très orientée TypeScript, où les connaissances front-end et backend se recoupent souvent.

• Des applications où des frontières de dépendances explicites deviendront de plus en plus importantes à mesure que le produit grandit.

• Des projets où nous voulons délibérément plus de contrôle sur la persistance, l'infrastructure ou d'autres éléments de la stack backend.

EngineeringScore entre beaucoup plus naturellement dans cette catégorie. Les domaines d'analyse, la logique de scoring et les services de support nous donnent de vraies frontières à modéliser ; la structure d'architecture n'est donc pas là parce que NestJS nous a dit de la créer. Elle est là parce que le produit a réellement cette complexité.

C'est une distinction importante.

Laravel vs NestJS en un coup d'œil

Lequel choisir ?

Mes règles empiriques, dans l'ordre où je les applique :

1. Commencez par l'équipe. Si les personnes qui le maintiendront sont fortes en PHP, choisissez Laravel. Si elles vivent dans TypeScript tous les jours, choisissez NestJS. Un framework que votre équipe connaît vaut mieux qu'un framework qui paraît meilleur sur le papier.

2. Le backend est-il surtout classique ? Connexions, paiements, e-mails, files d'attente, écrans d'administration et rapports : choisissez Laravel et consacrez votre temps à la logique métier.

3. Le produit a-t-il de vrais domaines distincts ? Plusieurs analyseurs, workers ou API externes qui ne doivent pas se connaître : choisissez NestJS.

4. Devez-vous lancer rapidement ? Laravel vous mène généralement plus tôt à une première version solide.

5. Partagez-vous du code avec un front-end TypeScript ? NestJS facilite le partage des types et des outils.

6. Toujours indécis ? Choisissez celui que l'équipe connaît, et notez dans tous les cas les frontières des modules ou des domaines. De bonnes frontières comptent plus que le framework.

Si vous voulez un deuxième avis sur un projet réel, jetez un œil à nos projets ou parlez-nous d'une équipe dédiée. Et si vous avez déjà une application Laravel ou NestJS et que vous ne savez pas dans quel état elle est, vous pouvez la passer dans EngineeringScore, l'audit de site web gratuit que nous avons construit avec NestJS.

Ce que je me demande maintenant avant de choisir

Il y a quelques années, j'aurais probablement choisi Laravel simplement parce que c'était celui que je connaissais le mieux. Ce n'est d'ailleurs pas forcément une mauvaise raison. Être productive avec une technologie que l'on comprend vaut souvent plus que choisir le framework théoriquement parfait que l'on n'a jamais utilisé en production.

Aujourd'hui, je prendrais la décision de façon plus délibérée.

Avant de choisir entre Laravel et NestJS, voici les questions auxquelles je voudrais répondre :

• Quel type d'application construisons-nous réellement ?

• Quelle part du backend relève de fonctionnalités classiques d'application web ?

• Où se trouve la vraie complexité du produit ?

• Cette complexité se divise-t-elle naturellement en domaines distincts ?

• Combien de systèmes et d'API externes le backend va-t-il coordonner ?

• En combien de temps devons-nous atteindre une version de production utile ?

• Quelle technologie l'équipe existante connaît-elle le mieux ?

• Les développeurs travailleront-ils régulièrement des deux côtés, front-end et backend ?

• Avons-nous intérêt à choisir nos propres composants d'infrastructure, ou créons-nous simplement des décisions dont nous n'avons pas besoin ?

• Qui maintiendra cette application après deux ou trois ans de développement ?

Cette dernière question est une de celles que j'apprécie davantage à mesure que je travaille sur de plus gros projets.

Un choix de framework ne concerne pas seulement l'agrément du premier sprint. Vous choisissez les conventions que les futurs développeurs rencontreront en ouvrant le projet après que des centaines de fonctionnalités, d'intégrations, de corrections et de changements se seront accumulés.

Le meilleur framework n'est donc pas forcément celui qui vous permet d'écrire le premier endpoint le plus vite, ni automatiquement celui qui vous donne le plus d'outils d'architecture.

C'est celui dont les opinions correspondent à l'application que vous construisez réellement.

Suis-je toujours la fille de Laravel ?

Probablement.

J'aime toujours travailler avec Laravel, et il y a de nombreux projets pour lesquels sa productivité et son écosystème intégré en feraient mon premier choix. Travailler avec NestJS ne m'a pas convaincue que Laravel était le mauvais framework ; il m'a simplement donné une autre façon de penser le développement backend.

Mon sentiment initial sur les deux frameworks n'a pas vraiment changé non plus : Laravel me rend productive, tandis que NestJS me fait davantage réfléchir à l'architecture.

Ce qui a changé, c'est que je comprends mieux pourquoi.

Laravel est opinioné sur une grande partie de la stack applicative et supprime de nombreuses décisions que je n'ai simplement pas besoin de prendre sur chaque projet. NestJS est opinioné sur la structure et rend les modules, les responsabilités et les dépendances beaucoup plus explicites, tout en laissant davantage de technologies périphériques entre nos mains.

C'est pourquoi je pense qu'ils méritent d'être dans la même conversation bien qu'ils viennent d'écosystèmes complètement différents. Les deux frameworks essaient d'aider les développeurs à gérer la complexité de la construction et de la maintenance d'applications backend ; ils choisissent simplement de supprimer des types de complexité différents.

Et après avoir travaillé avec les deux, c'est la question que je poserais maintenant avant de choisir entre eux : quelles décisions est-ce que je veux que le framework prenne pour moi, et lesquelles sont assez importantes pour que je veuille les prendre moi-même ?

Sources

• https://laravel.com/docs/13.x/releases
• https://www.php.net/supported-versions.php
• https://nodejs.org/en/about/previous-releases
• https://github.com/nestjs/nest/releases
• https://github.com/nestjs/nest/releases/tag/v12.0.0