Vercel lance Python en disponibilité générale : six SDK et prise en charge de FastAPI

Vercel fait passer la prise en charge de Python en general availability. Il y a dix mois, l'entreprise s'était fixé pour objectif de faire de sa plateforme le meilleur endroit pour héberger des applications Python. Le résultat est désormais accessible à tous : détection automatique de quatre frameworks, exécution sur Fluid compute et six SDK Python pour le stockage, les files d'attente, les workflows, les sandboxes, les modèles et les API externes. Pour une entreprise née avec JavaScript et Next.js, c'est un pas notable vers le backend et les charges de travail d'IA, où Python reste le langage par défaut.

Ce que Vercel détecte et exécute d'elle-même

La plateforme lit les fichiers de dépendances du projet, y compris ceux gérés via uv, et reconnaît d'elle-même FastAPI, Flask, Django et FastHTML. Le build et le routage des requêtes se configurent automatiquement, et les fichiers statiques passent par le CDN en tenant compte des particularités du framework concerné. Inutile d'assembler la configuration à la main.

Le runtime repose sur CPython sous Linux. Vercel justifie ce choix par la compatibilité : les paquets et les outils auxquels les développeurs Python sont habitués doivent fonctionner sans contournement. Les applications s'exécutent sur Fluid compute, qui gère les requêtes concurrentes et monte en charge avec le trafic.

Paramètres clés de la version :

• runtime : CPython sur Linux ;
• calcul : Fluid compute avec gestion des requêtes concurrentes ;
• détection automatique : FastAPI, Flask, Django, FastHTML ;
• dépendances : prise en charge des projets uv ;
• fullstack : Vercel Services réunit backend et frontend dans un seul projet ;
• processus de longue durée : Vercel Daemons pour les workers qui récupèrent des tâches dans des files d'attente ou des bases de données.

Vercel Services répond à un problème classique des projets associant un backend Python à un frontend JavaScript. La commande `vercel dev` lance les deux parties en local, le déploiement de prévisualisation les assemble, et la mise en production comme le rollback se font en une seule action. Vercel Daemons couvre un autre cas d'usage : des conteneurs embarquant votre code, vos paquets et vos dépendances système restent actifs en permanence et dépilent la file de tâches.

Six SDK pour l'IA et les tâches de fond

La seconde moitié de l'annonce concerne les bibliothèques. Vercel a publié des versions Python de ses outils, avec annotations de types, async/await et gestionnaires de contexte :

• AI SDK for Python : génération et streaming des réponses des modèles, appel d'outils, construction d'agents ;
• Sandbox SDK : création d'environnements isolés pour exécuter du code ;
• Workflow SDK : workflows durables avec retries et sauvegarde de l'état d'exécution ;
• Queues SDK : envoi et réception de messages pour le travail en arrière-plan et les notifications ;
• Blob SDK : envoi et récupération de fichiers depuis le stockage objet ;
• Connect SDK : obtention des identifiants nécessaires pour appeler des API externes.

Cet ensemble est révélateur. Sandbox, Workflow et AI SDK forment le socle classique des applications agentiques : le modèle prend la décision, le code s'exécute en isolation et une longue chaîne d'étapes survit aux pannes. Auparavant, il fallait assembler cette combinaison à partir de services dispersés ou l'écrire en TypeScript.

À quoi cela ressemble dans un projet réel

Pour la démonstration, l'auteur de l'annonce a construit une application web collaborative pour notebooks Jupyter. Les utilisateurs créent des notebooks, les publient, forkent ceux des autres et écrivent du code avec un assistant IA. Le frontend repose sur Vite, le backend sur FastAPI, et les sources comme l'historique des conversations sont stockés dans PostgreSQL.

Quand un utilisateur ouvre un notebook, FastAPI crée ou réutilise un Vercel Sandbox avec Jupyter. Le code de l'utilisateur est isolé du backend de l'application, le navigateur se connecte directement à Jupyter, et les Drives montés fournissent les dépendances et les fichiers de travail. À l'enregistrement, le backend écrit le source dans PostgreSQL, convertit les modifications en HTML et envoie le résultat dans Blob. Les notebooks publiés sont servis via le CDN, sans lancer de noyau Python. Après la publication, FastAPI envoie un message via Vercel Queues afin que les mises à jour parviennent aux autres instances du backend.

Par où commencer

Pour un nouveau projet, le plus simple est de suivre le guide dédié à son framework. Pour du code existant, il vaut la peine de vérifier s'il correspond à la détection automatique : si les dépendances sont décrites via uv ou les fichiers standard, il se peut qu'aucun réglage ne soit nécessaire. Pour l'association de FastAPI et de Next.js, Vercel propose un cours distinct avec déploiement via Services.

L'annonce ne fournit aucune donnée sur les limites, les tarifs ni les démarrages à froid des fonctions Python. Avant de migrer une charge de production, mieux vaut les vérifier dans la documentation et sur un service pilote. Cela vaut surtout pour les dépendances ML lourdes et les workers de longue durée, où Daemons et Fluid compute donneront un profil de coûts différent.