Django vs FastAPI sur Cloudflare Workers : lequel choisir ?

Django vs FastAPI sur Cloudflare Workers : lequel choisir ?

Choisissez Django si vous disposez déjà d’une application Django ou si votre backend doit couvrir tout le produit. Partez sur FastAPI pour créer de zéro une API typée, un service de webhooks ou un endpoint edge riche en entrées-sorties. Dans les deux cas, conservez l’origine actuelle si un paquet indispensable, le modèle de processus ou une charge avec état ne sont pas compatibles avec le runtime Workers.

Cloudflare a changé la donne le 2 septembre 2026. Les Python Workers peuvent désormais héberger directement des applications WSGI et ASGI grâce aux adaptateurs du module workers. WSGI est le contrat web synchrone historique de Python. ASGI lui succède avec un modèle asynchrone conçu pour superposer les opérations d’E/S, le streaming et les connexions longues. Dans ses exemples de lancement, Cloudflare associe explicitement Django à WSGI et FastAPI à ASGI, même si Django sait utiliser les deux protocoles.

Django est le choix de migration le plus sûr lorsque sa couche produit intégrée apporte déjà une valeur métier. Cloudflare documente maintenant des points d’entrée WSGI et ASGI, ainsi qu’un parcours django-cf vers D1 et les Durable Objects.

FastAPI est plus net pour un nouveau projet lorsque le livrable est une API plutôt qu’un produit web doté d’une administration. Cloudflare fournit la couche serveur ASGI : le Worker n’a donc pas à lancer Uvicorn ni à gérer de socket.

Côté prix, égalité jusqu’à ce que le temps CPU diverge

Aucun framework n’a l’avantage sur le prix. Les tarifs ont été vérifiés le 5 septembre 2026 sur les pages officielles en ligne : Django est gratuit et open source sous licence BSD, FastAPI est sous licence MIT, et Workers Paid débute à $5 par compte et par mois.

Ces $5 comprennent 10 millions de requêtes et 30 millions de millisecondes CPU par mois. Au-delà, les requêtes coûtent $0.30 par million, et le CPU $0.02 par million de millisecondes CPU. Les requêtes Static Assets sont gratuites et illimitées. Workers Free inclut 100,000 requêtes par jour, mais son quota de 10 ms de CPU par invocation en fait une mauvaise base de comparaison pour des applications bâties sur un framework non trivial.

Rapportez les deux frameworks à la même charge et le résultat est volontairement sans surprise. À 15 millions de requêtes dynamiques par mois et 7 ms de CPU moyen par requête, chacun coûte $8 par mois : $5 de base, $1.50 de dépassement sur les requêtes et $1.50 de dépassement CPU. À 100 millions de requêtes, toujours avec 7 ms de moyenne, chacun revient à $45.40 par mois.

Le calcul de sensibilité est plus utile qu’un benchmark de framework artificiel. Une fois le volume CPU inclus épuisé par les deux applications, chaque écart de 1 ms sur le CPU moyen modifie la facture de $0.30 à 15 millions de requêtes et de $2 à 100 millions de requêtes. Un écart mesuré de 5 ms vaut donc $1.50 ou $10 par mois à ces niveaux de trafic. C’est beaucoup trop peu pour justifier à lui seul une réécriture motivée par le coût de calcul.

Il n’existe aucun seuil où le tarif fournisseur départage les deux options. L’une ne devient moins chère que si son temps CPU mesuré, ses services annexes ou sa charge de maintenance diffèrent. Un framework rapide autour d’appels lents à la base de données ne sauvera pas l’architecture. À l’inverse, un framework intégré qui évite plusieurs semaines de remplacement peut rester le système le moins cher, même si un microbenchmark favorise son concurrent.

Django ou FastAPI : existant à migrer ou nouvelle API ?

L’adaptateur demande peu de changements ; migrer l’application, beaucoup plus. Les deux frameworks se contentent d’un point d’entrée minimal, mais tout ce qui se trouve derrière doit encore respecter le modèle de Cloudflare en matière de paquets, de stockage, de système de fichiers et de cycle de vie.

Migrer Django vers Cloudflare Workers : l’adaptateur n’est pas le problème

Django peut conserver son objet d’application WSGI standard et le confier à l’adaptateur de Cloudflare :

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

Cela suffit à faire le pont entre une requête entrante de Workers et l’objet appelable WSGI de Django. Cela ne migre ni la base de données, ni les fichiers persistants, ni les tâches planifiées, ni la stratégie de session, ni tous les paquets Django tiers.

Le nouveau guide du paquet Django publié par Cloudflare ouvre au framework une véritable voie de stockage native. Le paquet django-cf fournit des backends compatibles SQLite pour D1 et les Durable Objects. Tous deux pilotent l’ORM synchrone de Django ; Cloudflare demande donc de servir cette configuration via WSGI. Pour un produit CRUD qui repose déjà sur les modèles, formulaires, fonctions d’authentification et interface d’administration, conserver ces couches peut épargner bien plus de travail qu’un changement de framework ne ferait économiser en coûts d’exécution.

L’obstacle apparaît lorsque le système existant suppose un serveur classique. Un pilote de base de données peut exiger un wheel natif impossible à charger dans Workers. Les fichiers envoyés par les utilisateurs ne peuvent pas rester dans le système de fichiers de l’isolate. Un ordonnanceur local au processus ou un pool de threads ne se transpose pas. La prise en charge de Django signifie que le protocole de requête fonctionne ; elle ne certifie pas l’ensemble de l’application installée.

Migrer FastAPI vers Cloudflare Workers : idéal pour un service ciblé

L’adaptateur direct de FastAPI est plus court, car le framework parle déjà ASGI :

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

Cloudflare remplit le rôle de serveur ASGI normalement confié à Uvicorn. FastAPI conserve ses déclarations de routes, la validation Pydantic, l’injection de dépendances et la documentation OpenAPI générée. Un nouveau récepteur de webhooks, une API JSON typée ou un service adossé aux bindings démarre ainsi avec moins de mécanique applicative que Django.

En contrepartie, il faut assembler les briques. FastAPI n’impose volontairement ni base de données ni modèle de données. Il n’intègre pas non plus l’interface de gestion de contenu de Django. À vous de choisir ces composants, de vérifier chaque paquet dans l’environnement Workers et d’assumer leur intégration. C’est un avantage pour un service bien délimité, mais une charge pour un produit dont les équipes ont besoin d’un back-office dès le premier jour.

Verdict sur la migration : Django pour une application déjà bâtie avec Django ; FastAPI pour une nouvelle API. Réécrire un système Django qui fonctionne avec FastAPI au seul motif que les deux peuvent désormais tourner en edge serait le mauvais chantier.

WSGI ou ASGI sur Cloudflare : FastAPI gagne sur les traitements concurrents, Django garde le choix

ASGI est le modèle de requête le plus solide pour un nouveau service riche en E/S, mais WSGI reste le parcours documenté pour intégrer l’ORM Django à Cloudflare. Le protocole se choisit en fonction de la charge, pas à partir d’une affirmation générale selon laquelle l’asynchrone serait toujours plus rapide.

WSGI présente l’application comme un appelable synchrone. L’adaptateur WSGI actuel de Cloudflare exécute cet appelable dans le gestionnaire fetch asynchrone du Worker, convertit le corps de la requête provenant d’un ReadableStream JavaScript et renvoie au client l’itérable de réponse de l’application sous forme de flux. C’est une couche de compatibilité pour les applications synchrones matures, pas un second serveur web exécuté dans l’isolate.

ASGI permet à l’application d’attendre les opérations réseau et de stockage sans immobiliser le chemin de requête dans un appel synchrone. L’adaptateur de Cloudflare convertit aussi les événements WebSocket d’ASGI en WebSockets Workers. FastAPI repose nativement sur ce modèle. Django peut également l’utiliser : « Django » et « WSGI » ne sont donc pas synonymes.

Le choix du stockage peut inverser celui du protocole. Cloudflare indique que ses backends D1 et Durable Objects pour Django pilotent tous deux l’ORM synchrone et doivent être servis via WSGI. Si l’intérêt de Django tient à son ORM, suivre ce parcours WSGI documenté est plus cohérent que d’imposer l’étiquette ASGI à une couche de données synchrone.

Avec FastAPI, l’asynchrone n’aide que lorsque les opérations peuvent se superposer. Un endpoint qui consacre l’essentiel de son temps à une validation séquentielle ou à du Python gourmand en CPU continue de consommer du CPU. Un endpoint en attente de plusieurs opérations HTTP ou bindings Cloudflare indépendants a une raison bien plus nette d’utiliser ASGI.

Démarrage : le piège du lifespan de FastAPI

Django sur WSGI offre actuellement le modèle de démarrage le plus prévisible dans Workers. FastAPI fonctionne, mais ses hooks de lifespan ne se comportent pas comme dans un processus Uvicorn de longue durée.

Cloudflare réduit le travail de démarrage à froid de Python grâce à des snapshots de déploiement. Lors du déploiement, la plateforme crée un isolate V8, injecte Pyodide, exécute le module d’entrée du Worker et ses imports de premier niveau, puis prend un snapshot de la mémoire WebAssembly. Une requête peut charger ce snapshot au lieu de reconstruire l’environnement Python depuis zéro. Le code de portée globale doit tout de même être analysé et exécuté dans la limite de démarrage de 1 seconde imposée par la plateforme. Cloudflare documente directement ce cycle de vie.

Le contrat de lifespan habituel de FastAPI est pensé comme celui d’un processus : le code de démarrage s’exécute une fois avant que l’application accepte des requêtes, puis le code d’arrêt une fois après qu’elle a terminé. Le code source actuel de l’adaptateur ASGI de Cloudflare fait quelque chose de sensiblement différent. Sa fonction fetch lance l’application ASGI, envoie un événement de démarrage du lifespan, traite une requête, puis envoie l’événement d’arrêt. Le commentaire dans le code décrit un cycle de démarrage et d’arrêt avant et après la requête.

Avec l’adaptateur actuel, le code de lifespan s’exécute donc à l’échelle de chaque requête. Le chargement d’un modèle, la création d’un pool de connexions, le préchauffage d’un schéma ou la récupération d’une configuration distante placés à cet endroit peuvent se répéter au lieu d’être amortis sur un isolate. Ce n’est pas une raison d’écarter FastAPI. Il faut en revanche garder ce travail peu coûteux et idempotent, puis déplacer les initialisations déterministes et sûres vers du code capable de profiter du snapshot de déploiement de Cloudflare.

Dans l’exemple de Cloudflare, l’application WSGI de Django est créée au niveau du module et ne comporte aucun cycle de lifespan ASGI. Son initialisation appartient donc au chemin de démarrage global, avec la limite de 1 seconde comme contrainte. Si vous retenez le point d’entrée ASGI de Django et utilisez des composants sensibles au lifespan, auditez-les avec le même comportement d’adaptateur.

Cloudflare Workers et Python : tous les frameworks rencontrent le même mur

Sur ce point, c’est une égalité qui peut éliminer les deux frameworks. Django et FastAPI s’exécutent dans le même environnement Pyodide au sein de V8 : aucun des deux n’échappe aux limites de paquets, de mémoire, de système de fichiers ou de démarrage.

La documentation de Cloudflare sur les paquets indique que pywrangler regroupe les dépendances déclarées dans pyproject.toml. Les sources prises en charge comprennent les paquets Python pur et PyEmscripten issus de PyPI, ainsi que ceux fournis avec Pyodide. PyEmscripten désigne le format de wheel ciblant WebAssembly. Cloudflare décrit encore cet écosystème comme naissant, et certains paquets ne disposent d’aucun wheel compatible.

Les vérifications impératives de la plateforme sont simples :

• Le bundle Worker décompressé ne peut pas dépasser 64 MiB, sur Free comme sur Paid.
• Chaque isolate dispose de 128 MB de mémoire.
• Le démarrage en portée globale doit s’achever en 1 seconde.
• Le système de fichiers Python est éphémère et privé à chaque isolate.
• threading et multiprocessing peuvent être importés, mais ne fonctionnent pas dans la VM WebAssembly.

Le système de fichiers fait échouer davantage de migrations que la signature de l’adaptateur ne le laisse penser. Les fichiers temporaires conviennent. Les uploads persistants, les rapports générés, les fichiers SQLite utilisés comme stockage durable et les caches partagés sur disque, non. Placez les objets durables dans D1, Durable Objects, KV ou R2 en fonction du mode d’accès, pas dans un répertoire qui disparaît avec l’isolate. Les limites exactes figurent dans le guide Cloudflare de la bibliothèque standard Python.

La compatibilité des paquets est un critère binaire, à examiner avant les performances. Construisez le graphe réel des dépendances, pas un sous-ensemble de démonstration. Un import réussi dans CPython sur un poste de travail ne prouve rien quant à la disponibilité des extensions natives dans Pyodide.

Framework Python pour API ou produit : FastAPI et Django ont chacun leur terrain

Django l’emporte lorsque l’unité de travail est un produit ; FastAPI, lorsqu’il s’agit d’un service. Cette distinction résiste mieux au temps que le débit obtenu par chaque framework sur une route synthétique.

Meilleur choix pour un produit avec administration : Django

Django regroupe l’authentification des utilisateurs, l’administration du contenu, un ORM, des templates, des middlewares et d’autres fonctions courantes des produits web. Sa présentation officielle cite explicitement l’authentification et l’administration du contenu. Si une petite équipe opérationnelle doit gérer clients, commandes, autorisations et contenus éditoriaux, l’admin intégré peut apporter plus de valeur que quelques millisecondes gagnées sur le surcoût du framework.

Dans Workers, django-cf ouvre à ce modèle intégré un accès à D1 ou aux Durable Objects. En contrepartie, il renforce le couplage à un ORM synchrone et oblige à faire entrer une surface de framework plus large dans les limites du runtime.

Meilleur choix pour une API typée : FastAPI

FastAPI s’articule autour d’OpenAPI, de JSON Schema, de la validation Pydantic et de l’injection de dépendances. Sa documentation sur les fonctionnalités explicite aussi le compromis : le choix de la base de données et du modèle de données reste ouvert. C’est la bonne architecture pour une passerelle API, un récepteur de webhooks, un endpoint de modèle ou un petit service qui communique avec des bindings et des API distantes.

L’absence d’admin et d’ORM intégrés n’est pas un défaut tant que le service n’en a pas besoin. Elle devient un coût de livraison dès qu’une personne non technique a besoin d’un back-office.

Meilleur choix pour la vitesse brute : pas de preuve sur Workers

Selon la page de benchmarks de FastAPI, la suite indépendante TechEmpower a historiquement classé FastAPI sous Uvicorn parmi les frameworks Python les plus rapides. TechEmpower mesurait des charges standardisées portant sur JSON, les bases de données, les ORM, les templates et des cas connexes. Elle ne mesurait pas les adaptateurs Pyodide de Cloudflare, et le projet a pris fin le 24 mars 2026. Ces résultats constituent un signal historique attribué, pas une prévision de déploiement sur Workers.

Cloudflare n’a publié aucun benchmark comparant Django et FastAPI à travers ces adaptateurs. La vitesse brute sur Workers restera donc inconnue tant qu’une route représentative n’intégrera pas sa validation, ses bindings, ses appels à la base de données, son format de réponse, son comportement au démarrage et les métriques CPU de Workers.

Ce que coûte réellement un changement, et qui devrait s’en abstenir

Ne changez pas de framework uniquement pour accéder à Cloudflare : tous deux sont désormais pris en charge. Ne basculez que si le framework cible supprime davantage de travail applicatif que la migration n’en crée.

Réécrire une application Django avec FastAPI oblige à remplacer ou à séparer les modèles, migrations, écrans d’administration, flux d’authentification, middlewares, templates et tous les paquets qui s’appuient sur le cycle de requête Django. Le résultat peut être excellent pour une API ciblée, mais il ne s’agit pas d’un simple réglage de déploiement. Si l’admin et l’ORM sont largement utilisés, la bascule détruit d’abord un avantage avant d’en créer un nouveau.

Passer de FastAPI à Django n’a de sens que si le produit a dépassé une architecture centrée sur les services et a besoin de la couche opérationnelle intégrée de Django. Sinon, cela ajoute des conventions et des composants inutiles à une petite API.

FastAPI peut monter une application Django WSGI sous un chemin grâce à a2wsgi.WSGIMiddleware. Cette méthode permet une décomposition progressive sur des serveurs classiques. Dans Workers, elle ajoute un paquet et une frontière de protocole, tandis que les parcours de démarrage de Cloudflare documentent chaque framework séparément. Considérez un Worker combiné comme une intégration sur mesure à valider, pas comme le raccourci par défaut.

Quelle que soit la direction envisagée, chiffrez ces volets de migration :

• Données : compatibilité des schémas, migrations, comportement des transactions et transfert vers D1, Durable Objects ou un autre stockage accessible.
• Fichiers : les ressources statiques peuvent utiliser Workers Static Assets, tandis que les médias utilisateurs persistants exigent un stockage d’objets durable comme R2.
• Tâches en arrière-plan : remplacez les ordonnanceurs locaux au processus, pools de threads et processus enfants par des traitements asynchrones natifs de la plateforme.
• Dépendances : résolvez le lockfile complet pour Python Workers, puis contrôlez le bundle de 64 MiB et le résultat du démarrage en 1 seconde.
• Exploitation : reconstruisez les journaux, alertes d’erreur, retours arrière de déploiement, secrets et une référence de performances par route.

Qui ne devrait pas changer ? Un monolithe Django stable, doté d’une base de données opérationnelle et de workflows d’administration importants, ne devrait pas devenir FastAPI par effet de mode. Un service FastAPI dépendant de wheels natifs indisponibles ne devrait pas migrer vers Workers simplement parce que le framework possède désormais une page de documentation. Une équipe dont la latence provient surtout d’une base de données éloignée devrait corriger l’emplacement des données avant de changer de modèle de requête.

Le test à lancer lundi

La semaine prochaine, validez une route représentative, pas toute l’application. Choisissez celle qui reflète les contraintes de paquets, d’état et de latence du système en production, puis servez-vous-en pour éliminer rapidement les mauvaises options.

FAQ : Django et FastAPI sur Cloudflare Workers