Définition
Un programme Python s'exécute sur votre machine, affiche son résultat et se termine. Aucun visiteur ne peut le déclencher depuis un navigateur : entre l'adresse qu'il tape et la fonction que vous avez écrite, il manque tout un protocole, celui du web. Flask est ce chaînon manquant.
Ce cadre de travail web minimaliste relie une adresse à une fonction Python et prend en charge tout ce qui les sépare : lire la requête, en extraire ce que le visiteur a demandé, choisir le code de statut, renvoyer la réponse.
Au delà, il ne décide rien à votre place : ni base de données imposée, ni interface d'administration, ni système de comptes. Vous n'apprenez que ce dont vous avez besoin, mais vous brancherez vous-même ce que d'autres cadres livrent déjà en place.
Voici une application complète. Pas un extrait : le fichier entier.
from flask import Flask
app = Flask(__name__)
@app.route("/bonjour/<prenom>")
def bonjour(prenom):
return f"Bonjour {prenom}"Le @app.route est un décorateur : il n'exécute rien, il inscrit la fonction dans la table des adresses pour que Flask sache qui appeler quand la demande arrivera. <prenom> devient l'argument du même nom : /bonjour/Marie répond Bonjour Marie. Le reste est du Python ordinaire, avec les mêmes def et les mêmes dictionnaires qu'ailleurs.
Le problème qu'il résout
Pour mesurer ce qu'il apporte, imaginez vous en passer : ouvrir un port, interpréter la première ligne d'une requête HTTP, découper les entêtes, deviner l'encodage du corps, reformer une réponse valide. Rien de tout cela n'est le sujet de votre application, et rien ne change d'un projet à l'autre.
Il remplace donc deux choses : le module http.server, tout juste capable de servir les fichiers d'un dossier, et les quelques centaines de lignes que chaque projet réécrivait autrefois pour transformer une adresse en appel de fonction.
Une confusion revient souvent ici, autant la lever : Flask n'est pas un concurrent de requests. Les deux parlent HTTP, dans des sens opposés. requests part interroger un service extérieur, Flask attend qu'on vienne l'interroger. Un même projet les emploie souvent ensemble.
Flask, Django ou FastAPI
La comparaison honnête ne porte pas sur le nombre de fonctionnalités, mais sur le nombre de décisions. Flask vous laisse choisir, Django a déjà choisi pour vous. Ce qui tranche est le temps que vous acceptez de passer à décider.
Le tableau se lit dans ce sens : à gauche ce que Flask laisse ouvert, à droite ce que Django a refermé.
| Sujet | Flask | Django |
|---|---|---|
| Base de données | À brancher soi-même | Fournie, avec ses migrations |
| Administration | Rien, ou une extension | Générée automatiquement |
| Organisation des fichiers | Libre, donc à décider | Imposée, donc identique partout |
| Premier écran affiché | Six lignes | Une commande et plusieurs fichiers |
| Application de cinquante pages | Vous réécrivez ce que Django offre | Déjà présent |
Flask gagne au démarrage, Django gagne dans la durée : un projet qui grossit finit par réclamer des comptes, des migrations et un écran d'administration, que vous rebâtirez alors pièce par pièce.
FastAPI occupe une troisième place, plus récente : même légèreté que Flask, mais la validation des données entrantes et la documentation de l'interface sont déduites des annotation de type. Pour un service qui ne renvoie que du json, c'est devenu le choix par défaut. Flask garde l'avantage sur les projets qui servent de vraies pages HTML, ou quand l'extension dont vous avez besoin existe déjà.
La base de données, la connexion des utilisateurs et les migrations existent bel et bien du côté de Flask, mais en extensions séparées : Flask-SQLAlchemy, Flask-Login, Flask-Migrate. Elles se choisissent une par une, et l'équipe de Flask ne les maintient pas.
Quand il ne sert à rien
Un script lancé par une tâche planifiée, un traitement de fichiers, un calcul dans un carnet de notes : rien de tout cela n'a besoin de Flask. Ces programmes ont déjà quelqu'un pour les déclencher, et ce quelqu'un n'est pas un navigateur.
L'installer par précaution coûte plus cher qu'il n'y paraît : une dépendance de plus, un processus qui doit rester allumé, une surface exposée à surveiller, au profit d'une fonctionnalité que personne n'utilise. Une page vitrine relève du même calcul : un fichier HTML statique se charge plus vite et tombe en panne moins souvent.
Les trois pièges de la découverte
Le premier est le serveur de développement. La commande de lancement démarre un serveur prévu pour une seule personne, celle qui écrit le code, et il l'annonce lui-même dans la console. Une mise en ligne passe par un serveur d'application comme Gunicorn, qui lance plusieurs processus.
Le deuxième est l'état conservé dans une variable globale. Un compteur rempli au fil des requêtes fonctionne parfaitement sur votre machine, où un seul processus tourne. En production, plusieurs processus tournent côte à côte et chacun garde sa copie : la valeur change à chaque rechargement, sans qu'aucune erreur ne vous prévienne. Ce qui doit survivre à une requête appartient donc à une base de données ou à un cache.
Le troisième ne se paie pas en temps perdu mais en sécurité, et il concerne le mode de mise au point.
Ce mode ouvre dans le navigateur, à la moindre exception, une console capable d'exécuter du Python sur le serveur. Pendant l'écriture, c'est le meilleur outil de diagnostic qui soit. En ligne, c'est un accès à votre machine offert au premier visiteur qui provoque une erreur.
Questions fréquentes
Faut-il vraiment un environnement virtuel pour installer Flask ?
Oui, pour la même raison que n'importe quelle bibliothèque. Une installation avec pip dans le Python du système mélange les versions de tous vos projets : mettre Flask à jour pour l'un fait changer l'autre sans prévenir, et la panne apparaît des semaines plus tard. Un environnement virtuel par application isole ces dépendances.
Pourquoi mon fichier ne trouve-t-il plus Flask après l'avoir nommé flask.py ?
Parce que Python cherche d'abord dans le dossier courant. Votre fichier prend la place de la bibliothèque, et import rapporte votre propre code, qui ne contient rien de ce que Flask expose. Le symptôme est une ModuleNotFoundError ou une erreur d'attribut incompréhensible. Renommez le fichier, puis supprimez le dossier __pycache__, qui garde une version compilée de l'ancien nom.
Flask tient-il la charge d'un site très fréquenté ?
Ce n'est pas Flask qui encaisse la charge, c'est le serveur d'application placé devant lui et le nombre de processus qu'on lui accorde. La vraie limite est ailleurs : chaque requête occupe un processus du début à la fin, donc un appel lent à un service extérieur immobilise cette place. Sur ce profil, un cadre bâti sur asyncio rend la main pendant l'attente.