veilletech.fr
22 sept. Feed du jour
#05 CLOUDFLARE Article

Cloudflare Python Workers : FastAPI, Django et Postgres

Python n'est plus l'invité des Workers. Reste à savoir si vos dépendances ont fait le voyage.

Après deux ans de préversion, Python Workers est en disponibilité générale. Les bindings Cloudflare s'utilisent en Python natif, FastAPI, Flask et Django tournent via des connecteurs ASGI et WSGI, et des sockets réimplémentés ouvrent Postgres et MySQL via Hyperdrive. La PEP 783, acceptée, standardise la compilation des paquets natifs vers WebAssembly.

3 min de lectureintermédiairevidéo 1:26
Partager
Sommaire6 sections
  1. Ce qui se passe
  2. Les trois verrous qui sautent
  3. Les paquets natifs : un standard plutôt qu'une exception
  4. La limite
  5. Comment s'y prendre
  6. À retenir

Ce qui se passe

Le 21 septembre 2026, Cloudflare passe Python Workers en disponibilité générale, deux ans après la première préversion. Le socle ne change pas : un interpréteur Python compilé en WebAssembly (Pyodide) tourne dans le runtime des Workers. Ce qui change, ce sont les trois verrous qui rendaient l'ensemble difficile à utiliser pour une vraie application.

Les trois verrous qui sautent

Les bindings en Python natif. Envoyer un dictionnaire dans une Queue exigeait de le convertir explicitement en objet JavaScript :

Python
# Avant
self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))
# Maintenant
self.env.QUEUE.send({"key": "value"})

La conversion est désormais prise en charge par le runtime et le SDK, pour tous les bindings : Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows.

Les frameworks web. Sur un serveur, une application FastAPI tourne derrière uvicorn. Dans un Worker, la plateforme joue ce rôle, et deux connecteurs traduisent la requête entrante vers les interfaces standard ASGI et WSGI :

Python
from fastapi import FastAPI
from workers import asgi

app = FastAPI()

@app.get("/")
async def root():
    return {"message": "Hello, world!"}

Default = asgi.entrypoint(app)   # wsgi.entrypoint(app) pour Django ou Flask

Tout framework conforme à ASGI ou WSGI est concerné, pas seulement ces trois.

Le réseau. Dans un bac à sable WebAssembly, les appels système de socket échouent toujours, ce qui excluait asyncpg ou aiomysql. Cloudflare les a réimplémentés au-dessus de l'API connect des Workers : les pilotes ouvrent leurs connexions sans rien savoir du mécanisme, et atteignent Postgres ou MySQL via Hyperdrive. Côté HTTP, requests et httpx passent désormais par fetch grâce à des contributions en amont, ce qui rend utilisables openai, langchain et le SDK mcp.

Les paquets natifs : un standard plutôt qu'une exception

Un paquet avec des extensions C, C++ ou Rust doit être compilé pour WebAssembly. Jusqu'ici, l'équipe de Cloudflare compilait et hébergeait ces paquets à la main, ce qui limitait le catalogue. Elle a proposé la PEP 783, désormais acceptée, qui définit une plateforme PyEmscripten : un mainteneur peut publier une roue pour cette cible, utilisable par tout environnement qui l'implémente — navigateur compris. La chaîne de compilation de Pyodide a été stabilisée, et cibuildwheel sait produire ces roues.

La limite

L'écosystème commence seulement à publier des roues PyEmscripten : un paquet natif qui n'en a pas ne tournera pas. Cloudflare invite à signaler les manques sur Discord ou GitHub. L'annonce promet aussi de meilleures performances et une empreinte mémoire réduite, sans chiffre à l'appui pour l'instant.

Comment s'y prendre

  1. Partir du dépôt cloudflare/python-workers-examples : serveur MCP, RAG avec Vectorize, orchestration Queue et Workflows, flux WebSocket sur Durable Object.
  2. Lister les dépendances natives de l'application et vérifier leur disponibilité pour PyEmscripten avant tout portage.
  3. Pour une base existante, déclarer un binding Hyperdrive dans la configuration Wrangler, puis garder le pilote habituel.

Source : Python Workers are now generally available, blog Cloudflare, 21 septembre 2026.