Vercel active les WebSockets pour les fonctions Python en production

Le 23 juillet 2026, Vercel a activé le support des connexions WebSocket pour ses fonctions Python. Concrètement, une fonction serverless écrite en Python et déployée sur Vercel peut désormais garder une connexion ouverte avec le navigateur du visiteur, envoyer et recevoir des messages dans les deux sens, sans repasser par le cycle classique requête puis réponse puis fermeture. Jusqu'ici, ce comportement était réservé aux fonctions Node.js de la plateforme.

Ce n'est pas un détail de plomberie réservé aux spécialistes du temps réel. C'est la brique qui manquait pour construire, en Python et sans quitter l'écosystème Vercel, du chat en direct, de la collaboration multijoueur ou du streaming d'intelligence artificielle vraiment interactif.

Le problème que ce changelog résout

Une fonction serverless classique répond à une logique simple : une requête HTTP arrive, la fonction s'exécute, elle renvoie une réponse, la connexion se referme. Ce modèle convient très bien à une API REST ou à un rendu de page, mais il est structurellement incompatible avec le temps réel. Pour notifier un client sans qu'il ait à redemander, ou pour transmettre du contenu au fil de l'eau, il fallait jusqu'ici ruser : polling répété côté client, Server-Sent Events pour un flux à sens unique, ou délégation complète à un service tiers de websockets managés.

Pour les équipes qui écrivent leur backend en Python, ce qui est le cas de la quasi-totalité des projets qui manipulent des modèles d'IA, du machine learning ou de la donnée, cela signifiait souvent maintenir un second runtime Node.js uniquement pour la partie temps réel, ou sortir de Vercel pour héberger cette brique ailleurs. Le nouveau support WebSocket referme cet écart.

Ce que Vercel ajoute concrètement

D'après le changelog officiel, le support couvre à la fois les applications ASGI et WSGI, avec une compatibilité annoncée pour les frameworks Python les plus utilisés côté web : FastAPI, Django et Flask. Vercel cite explicitement trois familles d'usages : le streaming IA interactif, le chat en temps réel, et la collaboration multijoueur en direct.

Un exemple minimal, tiré directement de la documentation

Vercel illustre la fonctionnalité avec un serveur WebSocket FastAPI déployé comme une fonction classique, sans infrastructure additionnelle à provisionner :

import fastapi

app = fastapi.FastAPI()


@app.websocket("/api/ws")
async def websocket_endpoint(websocket: fastapi.WebSocket):
    await websocket.accept()
    try:
        while True:
            message = await websocket.receive_text()
            await websocket.send_text(message)
    except fastapi.WebSocketDisconnect:
        pass

Le principe : websocket.accept() ouvre la connexion, la boucle while True lit et répond tant que le client reste connecté, et l'exception WebSocketDisconnect permet de nettoyer proprement à la déconnexion. Ce fichier app.py se déploie comme n'importe quelle fonction Vercel : pas de serveur websocket à gérer à part, pas de configuration réseau spécifique.

Django et Flask ne sont pas les oubliés de la fête

En annonçant la compatibilité à la fois ASGI et WSGI, Vercel évite d'imposer FastAPI comme seul choix crédible pour faire du temps réel en Python. Django, avec son système Channels construit sur ASGI, et Flask, historiquement WSGI mais capable de basculer sur des extensions websocket, entrent tous les deux dans le périmètre. En pratique, cela veut dire que vous n'êtes pas obligé de réécrire un backend Django existant en FastAPI simplement pour ajouter une fonctionnalité de notifications en direct.

Pourquoi c'est particulièrement pertinent pour les usages IA

C'est là que l'angle dépasse le simple confort technique. La quasi-totalité des frameworks d'orchestration d'agents et de modèles de langage vivent nativement en Python. Jusqu'ici, streamer la sortie d'un modèle token par token vers un navigateur en repassant par une fonction Vercel Python forçait soit à sortir du langage pour la couche transport, soit à se contenter de Server-Sent Events, qui ne permettent qu'un flux à sens unique du serveur vers le client.

Avec un vrai canal bidirectionnel, le client peut interrompre une génération en cours, envoyer une correction ou une nouvelle instruction pendant que l'agent réfléchit encore, ou piloter une conversation multi-tours sans rouvrir de connexion à chaque message. C'est exactement le comportement attendu d'un assistant IA conversationnel moderne, et Vercel le rend désormais accessible sans quitter l'écosystème Python où vivent la plupart de ces projets.

Notre lecture chez CZSyn

Chez CZSyn, nous voyons régulièrement des clients qui veulent brancher un copilote interne ou un chatbot IA sur leur backend Python existant, et qui se retrouvent à devoir ajouter un second runtime rien que pour le temps réel. Cette annonce referme un vrai écart architectural : elle permet de garder un seul langage et une seule plateforme de déploiement, du prototype jusqu'à la mise en production.

Notre conseil pour une PME qui envisage ce type de projet : commencez par un prototype simple sur le modèle FastAPI fourni par Vercel, mesurez le comportement de votre fonction sous charge réelle (nombre de connexions simultanées, durée de vie des sessions), et vérifiez les limites de votre plan Vercel avant de vous engager sur une fonctionnalité temps réel critique pour vos utilisateurs. Une fonction serverless qui maintient une connexion ouverte ne se comporte pas tout à fait comme une fonction stateless classique, et ce sont ces détails d'exploitation qui font la différence entre une démonstration convaincante et un produit qui tient en production.

Sources primaires

• Vercel Changelog, « WebSocket support is now available for Python Functions », 23 juillet 2026.
• Documentation officielle Vercel, « Vercel Functions ».
• Documentation officielle FastAPI, « WebSockets ».