5 frameworks web « batteries incluses » à connaître

Un framework web « batteries incluses » fournit le routage, un ORM avec migrations de base de données, l’authentification, les tâches en arrière-plan, l’envoi d’e-mails et un environnement de test sous la forme d’un ensemble cohérent. L’équipe configure des valeurs par défaut au lieu de choisir et d’assembler des bibliothèques distinctes.

Si vous développez avec Express ou Next.js, vous connaissez le scénario. La fonctionnalité à livrer est un e-mail de réinitialisation de mot de passe, mais vous passez d’abord une semaine à comparer des ORM, des bibliothèques de files d’attente et des solutions d’envoi d’e-mails, avant de découvrir que la bibliothèque d’authentification n’est pas compatible avec votre système de stockage des sessions.

Cet article présente cinq frameworks, dans cinq langages, qui fournissent ces briques pour vous : Rails, Django, Laravel, Phoenix et Loco. Pour chacun, vous trouverez le langage, ce qui est inclus, ce qui fait sa réputation et le profil d’équipe auquel il convient, selon les mêmes critères.

Qu’est-ce qu’un framework « batteries incluses » ?

Un framework « batteries incluses » considère les couches backend standard comme partie intégrante du framework plutôt que comme des modules complémentaires. Vous disposez du routage, de l’accès aux données et des migrations, de l’authentification, d’une file d’attente de tâches, d’un système d’envoi d’e-mails et d’un harnais de test, tous conçus pour fonctionner ensemble, avec des générateurs qui produisent du code exploitant chacune de ces couches.

Si vous venez d’Express, la différence est la suivante : vous choisiriez normalement un ORM comme Prisma, une file d’attente comme BullMQ, une bibliothèque d’authentification et une solution d’envoi d’e-mails, puis vous les intégreriez et les mettriez à jour une par une. Dans un framework « batteries incluses », toutes ces briques proviennent d’un seul et même projet. Elles partagent la même documentation et les mêmes générateurs, et sont mises à jour ensemble dans une même version. JavaScript dispose de ses propres options en la matière. AdonisJS est le plus proche de ce modèle, comme nous l’expliquons dans notre article sur les frameworks JavaScript inspirés de Rails. NestJS, de son côté, se concentre sur la structure de l’application plutôt que sur l’intégration de toutes les couches.

Les frameworks « batteries incluses » conviennent aux équipes dont la principale contrainte est de livrer des fonctionnalités. Ils sont nettement moins adaptés lorsque les exigences vont régulièrement à l’encontre des choix du framework en matière de données, d’authentification ou de déploiement. Ils conviennent également mal aux équipes qui souhaitent remplacer certaines couches individuellement, ainsi qu’aux services suffisamment petits pour qu’un routeur et une bibliothèque suffisent. Certains écosystèmes privilégient par culture la composition de petites bibliothèques. Go en est l’exemple type, comme nous l’expliquons dans notre guide des frameworks web Go.

Le couplage est le prix à payer d’un framework « batteries incluses ». Les valeurs par défaut qui accélèrent la première mise en production lient aussi votre logique métier aux conventions du framework, ce qui pèse au moment des mises à jour ou lorsqu’il faut tester de manière isolée.

Ruby on Rails

Rails est le framework Ruby qui a popularisé le principe de convention plutôt que configuration (convention over configuration). C’est la référence à l’aune de laquelle se mesurent les quatre autres. Rails 8.1 est la série de versions actuelle, et le dernier correctif est Rails 8.1.4.

Ce qui est inclus : le routage, Active Record avec les migrations, Action Mailer, Active Job et un framework de test par défaut. Depuis la version 8.0, Rails intègre un générateur d’authentification par défaut, qui ajoute les modèles, contrôleurs, vues, routes et migrations nécessaires à une connexion basique et à la réinitialisation du mot de passe. Pour les tâches en arrière-plan, Solid Queue est le backend Active Job par défaut des nouvelles applications. Il s’appuie sur la base de données : vous n’avez donc pas besoin de Redis.

Ce qui fait sa réputation : ses générateurs et ses conventions. Si les fichiers, les classes et les tables respectent les noms attendus, le routage et le mapping des modèles fonctionnent quasiment sans configuration.

bin/rails generate scaffold Post title:string body:text

La commande scaffold de Rails génère un modèle, une migration, un contrôleur, des vues, des routes et des tests pour une ressource CRUD complète.

Pour qui : les petites équipes qui veulent le workflow fondé sur les conventions le plus abouti et qui acceptent volontiers les partis pris de Rails.

Django

Django est le framework « batteries incluses » de Python. Sa fonctionnalité phare est une interface d’administration générée à partir de vos modèles. L’équipe Django a annoncé la sortie de Django 6.1 en août 2026.

Ce qui est inclus : le routage d’URL, un ORM qui génère les migrations à partir des modifications de modèles, django.contrib.auth, une API d’envoi d’e-mails et un framework de test. Depuis Django 6.0, le cœur du framework inclut un framework Tasks (django.tasks) permettant de définir et de mettre en file d’attente des tâches en arrière-plan. Ses backends intégrés sont destinés au développement et aux tests : l’exécution des tâches en production nécessite donc un backend de worker tiers distinct.

Ce qui fait sa réputation : le site d’administration de Django, qui construit une interface de back-office fonctionnelle à partir de vos définitions de modèles. Une stack assemblée à partir de bibliothèques distinctes ne vous offre pas cela.

python manage.py startapp blog

La commande startapp de Django crée un package d’application contenant des modules pour les modèles, les vues, l’enregistrement dans l’interface d’administration, les tests et les migrations. Le cœur de Django ne propose pas de générateur de scaffold CRUD.

Pour qui : les équipes qui travaillent déjà en Python, et les applications qui ont besoin d’outils d’administration internes dès le premier jour.

Laravel

Laravel est le framework PHP qui dispose de l’écosystème officiel le plus vaste des cinq. Laravel 13 est la version majeure actuelle.

Ce qui est inclus : Laravel regroupe dans un même framework le routage, l’ORM Eloquent avec les migrations, un système de files d’attente, l’envoi d’e-mails, le moteur de templates Blade, la CLI Artisan et les tests. Les starter kits officiels génèrent l’authentification, et des packages officiels comme Echo prennent en charge la diffusion en temps réel côté client.

Ce qui fait sa réputation : une API dans laquelle les files d’attente, l’envoi d’e-mails et la base de données s’utilisent comme une seule et même bibliothèque, ainsi qu’un large éventail de packages officiels pour tout ce qui sort du cœur du framework.

php artisan make:model Post --migration --controller --resource

Avec ces options, la commande make:model de Laravel crée un modèle Eloquent accompagné de la migration correspondante et d’un contrôleur de ressource.

Pour qui : les équipes qui veulent bénéficier d’un hébergement PHP largement disponible et qui préfèrent les packages officiels aux solutions issues de la communauté.

Phoenix

Phoenix transpose l’approche « batteries incluses » à Elixir. Il associe des générateurs et la bibliothèque de base de données Ecto à LiveView, qui permet de construire des interfaces interactives rendues côté serveur. Phoenix 1.8 est la version actuelle.

Ce qui est inclus : le routage, les schémas et migrations Ecto, Channels et PubSub, ainsi que mix phx.gen.auth. Ce générateur produit une authentification par e-mail avec connexion par lien magique par défaut (les mots de passe étant disponibles en option), construite sur LiveView par défaut. Le point fort de Phoenix est LiveView.

mix phx.gen.html Blog Post posts title:string body:text

La commande mix phx.gen.html de Phoenix génère un contexte, un schéma, une migration, un contrôleur, des templates et des tests.

Pour qui : les produits temps réel pour lesquels vous préférez ne pas maintenir une SPA distincte.

Loco

Loco est un framework Rust inspiré de Rails, construit sur Axum, dont les modèles et les migrations reposent sur SeaORM. La page d’accueil du projet le présente comme du Rust « batteries incluses », en version v1.2.0.

Ce qui est inclus : la page d’accueil de Loco mentionne les modèles, les contrôleurs, les tâches en arrière-plan, l’envoi d’e-mails et l’authentification, le tout généré et intégré. L’authentification repose sur JWT.

cargo loco generate scaffold post title:string content:text

D’après la documentation des générateurs de Loco, la commande scaffold de Loco crée un modèle, une migration, des types de requête et de réponse, un contrôleur d’API JSON avec ses routes, ainsi qu’un test de modèle. Les routes générées exigent une authentification JWT, sauf si vous passez l’option --no-auth.

Pour qui : les équipes qui veulent à la fois un backend Rust compilé et typé et le workflow de Rails.

Comment choisir un framework « batteries incluses » ?

Partez du langage que votre équipe maîtrise déjà, puis départagez les candidats grâce à leur fonctionnalité phare. Choisissez Django pour son interface d’administration prête à l’emploi. Choisissez Rails pour ses générateurs fondés sur les conventions. Choisissez Laravel pour ses packages officiels et sa facilité d’hébergement. Choisissez Phoenix pour des interfaces temps réel rendues côté serveur, et Loco pour profiter du même modèle en Rust. Avant de vous engager, exécutez la commande de génération du framework présélectionné sur une fonctionnalité réelle de votre backlog, et évaluez la quantité de code que vous devriez écrire au-delà de ce qu’elle vous fournit.

FAQ

Le framework Tasks intégré à Django remplace-t-il Celery ?

Pas entièrement. Le module django.tasks ajouté dans Django 6.0 permet de définir, de valider et de mettre en file d'attente des tâches, ainsi que de stocker leurs résultats, mais il ne fournit pas de worker. Ses backends intégrés ImmediateBackend et DummyBackend sont destinés au développement et aux tests. En production, vous installez un backend tiers qui fournit une file d'attente persistante et un processus worker, et vous exécutez ce worker séparément. Celery reste la meilleure option pour les tâches interdépendantes.

Puis-je utiliser Rails ou Laravel comme backend exclusivement API pour un frontend React ou Next.js ?

Oui. La commande rails new my_api --api vous fournit une pile de middlewares allégée et fait hériter ApplicationController de ActionController::API. Elle empêche également les générateurs de créer des vues, des helpers et des assets, si bien que les scaffolds renvoient du JSON. Depuis Laravel 11, php artisan install:api crée le fichier routes/api.php et installe Laravel Sanctum, qui gère l'authentification par jeton pour les SPA et les clients mobiles.

Existe-t-il un framework « batteries incluses » pour Node.js ?

AdonisJS est l'équivalent le plus proche pour Node.js. Il s'agit d'un framework TypeScript qui fournit l'authentification, un ORM, la validation, l'envoi d'e-mails, les files d'attente, la mise en cache et les tests sous forme de briques conçues pour fonctionner ensemble. Sa couche de données est Lucid, un ORM Active Record construit sur Knex qui inclut les migrations. Les tests reposent sur Japa, un framework de test développé par la même équipe. L'authentification prend en charge les sessions pour les applications web et les jetons d'accès pour les API.