handleUpload n'existe pas dans @vercel/blob@2.3.1 — c'est une ancienne API. La bonne approche pour les gros fichiers dans cette version est d'utiliser put() avec multipart: true côté serveur. Je vais aussi lire les modals pour corriger uploadFiles en conséquence :

La version installée @vercel/blob@2.3.1 n'a pas handleUpload. La bonne approche est de revenir à un upload FormData côté serveur avec put(..., { multipart: true }) qui gère les gros fichiers, ET d'augmenter la limite de taille de la route via export const config. Je supprime aussi l'import @vercel/blob/client du modal et reviens au XHR :

Now revert the modal back to XHR (removing the broken @vercel/blob/client import) :

Deux corrections :

1. /api/admin/upload — revenu à put(..., { multipart: true }) de @vercel/blob (disponible dans v2.3.1) avec export const config = { api: { bodyParser: false } } pour désactiver la limite de taille Next.js. multipart: true envoie le fichier en plusieurs parties directement à Vercel Blob.
2. modals.tsx — supprimé l'import @vercel/blob/client (qui n'existe pas dans v2.3.1) et revenu au XMLHttpRequest avec FormData pour le suivi de progression.

Checked Supabase env vars

Les env vars sont bien configurées. L'erreur vient du proxy (middleware) — dans Next.js 16, les variables d'environnement ne sont pas disponibles dans le contexte Edge/middleware de la même façon. Le proxy tente de créer le client Supabase avec des valeurs undefined. La solution : vérifier les valeurs avant de créer le client et retourner NextResponse.next() si elles manquent.

Ajout d'une garde au début de proxy qui vérifie que NEXT_PUBLIC_SUPABASE_URL et NEXT_PUBLIC_SUPABASE_ANON_KEY sont bien définis avant de créer le client Supabase. Si l'une des deux variables manque (par ex. lors d'un cold boot Edge avant l'injection des env vars), le middleware laisse passer la requête sans planter.