« Alors, Django ou FastAPI ? » La question m'est tombée dessus un mardi soir, dans un bar, par un pote qui venait de signer son premier client pour une petite app de gestion de stock. Il avait lu trois comparatifs, tous écrits par des gens visiblement très intelligents, et il en était ressorti avec encore moins de certitudes qu'avant. Je lui ai dit : « Combien d'écrans ? » Il m'a répondu : « Six. » Et là, tout était réglé. Il n'avait pas un problème de framework. Il avait un problème de cahier des charges.
C'est le piège numéro un quand on veut choisir un framework Python pour le backend : on compare des outils avant d'avoir regardé le projet. Les trois grands noms qui reviennent partout — Django, Flask, FastAPI — ne résolvent pas le même problème, et à mon sens la vraie question n'est jamais « lequel est le meilleur » mais « lequel va vous faire perdre le moins de temps sur ce projet précis ».
Points clés à retenir
- Django = monolithe complet, batteries incluses : l'admin, l'ORM et l'auth vous sont offerts, à condition d'accepter sa façon de faire.
- Flask = un socle minimal, vous assemblez le reste. Parfait pour une API étroite ou un outil interne, pénible dès que le projet grossit.
- FastAPI = API moderne, typée, asynchrone. Excellent quand le projet est une API, fragile quand il doit aussi rendre des pages.
- Le critère décisif n'est pas la popularité, c'est le temps que vous allez passer à maintenir le bazar dans six mois.
- Un seul critère universel : qui va reprendre le code, et est-ce que cette personne a déjà touché à l'outil choisi ?
Trois frameworks, trois projets qui n'ont rien à voir
Je vais être direct, quitte à déplaire : la plupart des articles sur le sujet comparent les frameworks comme des voitures, en listant les chevaux. Sauf qu'un framework backend, c'est plutôt une cuisine. Certaines arrivent équipées, d'autres sont des plans de travail vides avec une plaque à côté.
Django : l'appartement meublé
Django vous donne l'admin. C'est le seul argument qui ait jamais suffi à décider quelque chose dans ma vie de développeur. Vous déclarez vos modèles, et vous avez une interface pour créer, modifier, supprimer vos données. Sans écrire une ligne de HTML. Sur le projet stock de mon pote, ça représentait grosso modo deux semaines de travail économisées.
Le revers, et il est réel : Django impose sa structure. Le routage, l'ORM, la gestion des migrations, tout a une manière officielle. Vous pouvez en sortir, mais à chaque écart vous payez. J'ai vu des équipes se battre des mois contre l'ORM pour finir par écrire du SQL brut dans tous les coins — à ce stade, autant ne pas avoir pris Django.
Le temps de démarrage est plus long qu'annoncé. Pas les tutoriels, hein, le vrai démarrage : comprendre les migrations, les apps, les settings par environnement. Comptez plusieurs semaines avant d'être à l'aise sur un projet non trivial.
Flask : la boîte à outils
Flask ne fait presque rien, et c'est son charme. Une route, un décorateur, ça tourne. Pour une API de trois endpoints ou un outil interne qui interroge une base, c'est imbattable en vitesse de mise en route.
Ma plus grosse erreur avec Flask ? Un service qui devait rester petit et qui a grossi pendant dix-huit mois. À la fin, j'avais un dossier utils/ de 40 fichiers, deux bibliothèques de migrations concurrentes, et une authentification maison que personne n'osait toucher. Flask ne vous empêche pas de faire ça. Il ne vous aide pas non plus à ne pas le faire.
La règle que j'en tire : Flask est un excellent choix si vous pouvez répondre à la question « qu'est-ce qui va m'empêcher de tout casser dans un an ? » par une réponse concrète. Si la réponse est « rien », fuyez.
FastAPI : le cadre moderne, pensé pour les API
FastAPI est arrivé plus tard et a sauté directement sur l'asynchrone et le typage. Vous déclarez un schéma avec les annotations de type Python, et vous obtenez validation, sérialisation et documentation interactive quasi gratuites. Sur une API REST neuve, le gain de productivité est net.
Attention à un détail que les comparatifs oublient : FastAPI sert des API. Si votre projet doit aussi afficher des formulaires, gérer des sessions navigateur, envoyer des emails de confirmation, vous allez reconstruire à la main des choses que Django vous donne emballées. C'est parfaitement faisable. C'est juste du travail que vous choisissez consciemment.
Le tableau que j'aurais aimé trouver il y a quelques années
Plutôt que de longs paragraphes, un tableau. Les notes sont les miennes, elles sont subjectives, assumez-les comme telles.
| Critère | Django | Flask | FastAPI |
|---|---|---|---|
| Mise en route | Lente | Immédiate | Rapide |
| Admin / back-office | Inclus et excellent | À construire | À construire |
| ORM | Intégré, puissant | Au choix | Au choix |
| Asynchrone | Support partiel selon les briques | Possible, pas le cœur du modèle | Natif |
| Validation des données | Via formulaires et sérialiseurs | Manuelle | Automatique grâce au typage |
| Pages HTML rendues | Son terrain | Correct | Possible mais pas l'idée première |
| Courbe d'apprentissage | Raide | Douce | Moyenne |
| Meilleur cas d'usage | App complète, back-office lourd | API étroite, outil interne | API publique, services typés |
L'arbre de décision que je donne à chaque débutant
Voilà ce qui manque partout, et c'est pourtant le plus utile. Posez-vous ces questions dans cet ordre, et arrêtez-vous à la première réponse positive.
- Le projet doit-il afficher des pages à des humains, avec des comptes, des formulaires et un back-office ? → Django.
- Est-ce une API qui n'a pas besoin de rendre de HTML, avec des schémas de données à valider et des clients qui consomment du JSON ? → FastAPI.
- Est-ce petit, jetable, ou est-ce que vous voulez comprendre ce qui se passe sous le capot ? → Flask.
- Vous n'arrivez pas à répondre ? Alors le projet est mal défini, et aucun framework ne corrigera ça.
J'insiste sur la question 4. J'ai vu au moins trois projets où le choix du framework a été débattu pendant des semaines alors que personne n'avait écrit une seule ligne de spécification. Le débat était un substitut confortable à la vraie décision.
Et HTMX, dans tout ça ?
Question qu'on me pose de plus en plus : est-ce que je peux éviter un framework front-end en rendant le HTML côté serveur et en ajoutant juste ce qu'il faut d'interactivité ? Oui, et c'est même un choix que je défends de plus en plus. Un Django ou un Flask qui rend des fragments HTML, plus une petite bibliothèque côté navigateur pour les mettre à jour, ça couvre énormément de besoins réels. Vous gardez une seule base de code, un seul déploiement, et vous ne maintenez pas deux écosystèmes.
C'est peut-être l'angle le plus sous-estimé de la décision : le meilleur framework backend pour votre projet est souvent celui qui vous évite d'en avoir un second.
Les questions qu'on me pose juste après
Quel framework front-end choisir ?
Ça dépend d'abord de si vous avez vraiment besoin d'un framework front-end. Si votre application affiche surtout des formulaires, des listes et des pages qui se rechargent, un rendu côté serveur suffit largement et vous économise une architecture entière. En revanche, dès que l'interface devient très interactive — édition en temps réel, tableaux complexes, état partagé entre plusieurs vues — un framework côté navigateur se justifie. Le choix précis importe moins que la question de départ : avez-vous un besoin qui ne se règle pas autrement ?
Quel est le meilleur langage pour le backend ?
Il n'y en a pas un, et quiconque vous en donne un seul se trompe ou vend quelque chose. Ce qui compte, c'est l'adéquation entre le langage, l'équipe et la nature du projet. Python est un très bon choix quand la lisibilité, la vitesse de développement et la richesse des bibliothèques priment sur la performance brute. Un langage compilé ou plus bas niveau sera préférable pour des traitements intensifs. La vraie question reste : qui va maintenir ce code, et avec quoi est-il à l'aise ?
Angular est-il un framework front-end ou back-end ?
Front-end, sans ambiguïté. Angular s'exécute dans le navigateur et gère l'interface utilisateur, la navigation entre vues et les appels vers votre serveur. Il n'a rien à voir avec le choix de votre framework backend Python : les deux vivent de chaque côté d'une frontière qui est le plus souvent une API HTTP.
Quel est le meilleur IDE pour Python ?
Celui dans lequel vous ne perdez pas de temps à configurer. En pratique, les éditeurs avec un bon support du langage, de la complétion et du débogage couvrent l'immense majorité des besoins, y compris pour du Django ou du FastAPI. Mon conseil pratico-pratique : choisissez un éditeur qui comprend les annotations de type, parce que FastAPI et les projets Django modernes en dépendent lourdement. Et ne changez pas d'éditeur en même temps que de framework — un chantier à la fois.
Ce qui décide vraiment, et que personne ne mesure
À la fin, le facteur qui pèse le plus lourd n'apparaît dans aucun comparatif : le coût de la reprise. Un projet Django repris par quelqu'un qui connaît Django se passe bien. Un projet Flask bricolé maison repris par un inconnu se passe mal, systématiquement. Sur les trois dernières années, les seuls projets où j'ai vraiment souffert n'étaient pas ceux écrits dans le « mauvais » framework — c'étaient ceux dont la structure ne racontait rien à personne.
Alors si vous devez retenir une chose de ce billet : choisissez le framework dont la structure par défaut ressemble le plus à ce que vous auriez fait de toute façon. Django si vous voulez être guidé. FastAPI si tout est API. Flask si vous savez exactement pourquoi vous le prenez. Et si vous hésitez encore, écrivez la liste des écrans de votre application. Le framework se choisira tout seul — c'est ce qui est arrivé à mon pote du bar, et son app de stock tourne toujours.
