Un client m'a appelé début janvier, absolument enthousiaste. « Gautam, je viens de lire que Vercel fait du Docker maintenant. On peut arrêter nos droplets DigitalOcean, non ? » Il exécutait trois droplets, deux à 24 $/mois chacun, une à 48 $. Il avait une feuille de calcul prête. Il voulait économiser de l'argent et il voulait l'économiser immédiatement.
Je lui ai dit d'attendre deux semaines le temps que je le teste réellement. C'est une bonne chose qu'il ait écouté.
Voilà : le support des conteneurs de Vercel est vraiment impressionnant. Et un VPS n'est toujours pas mort. Ces deux phrases sont vraies en même temps, et la nuance entre elles vaut la peine d'être comprise avant de commencer à faire docker push de tout vers l'infrastructure de Vercel et de vous demander pourquoi vos connexions WebSocket n'arrêtent pas de se déconnecter.
Ce que Vercel a réellement annoncé
Le support Docker de Vercel, déployé via leur Build Output API et formalisé par la suite pour une utilisation générale, vous permet de livrer un Dockerfile et de laisser Vercel gérer le runtime du conteneur. Plus besoin d'être confiné aux conventions Next.js ou aux structures de fichiers de fonctions serverless. Vous écrivez votre Dockerfile, Vercel le construit, l'exécute.
C'est un véritable tournant. Avant cela, si vous aviez un backend FastAPI ou un serveur Node personnalisé qui faisait quelque chose d'exotique, vous deviez soit le contortionner pour en faire une fonction serverless, soit maintenir une VPS fonctionnant aux côtés de votre frontend Vercel. C'est ce que la plupart d'entre nous faisions. C'était pénible mais ça marchait.
À quoi le Runtime Ressemble Vraiment
Le runtime conteneur de Vercel n'est pas du Docker bare-metal. C'est plus proche de ce que vous obtiendriez sur un service conteneur géré. Votre conteneur reçoit une requête, Vercel la route, le conteneur la traite. Les processus persistants fonctionnent. Vous pouvez exécuter quelque chose comme un serveur WSGI Python ou un binaire HTTP Go. Les tâches longues durée au sein d'un seul cycle de vie de requête n'ont pas de problème.
Mais les contraintes importent. Les conteneurs peuvent se mettre à l'échelle jusqu'à zéro. Les démarrages à froid existent. Et surtout : vous n'avez pas de stockage disque persistant. Si votre application écrit sur le système de fichiers local et s'attend à ce que ces fichiers soient là à la prochaine requête, vous allez avoir des problèmes.
Où les Conteneurs Vercel Brillent Vraiment
J'exécute une API Django REST sur les conteneurs Vercel depuis mars. C'est un service relativement simple axé sur la lecture pour un client média, principalement des requêtes GET, accédant à une base de données Neon Postgres. Pas d'écritures de fichiers. Pas de tâches de fond. Pas de WebSockets.
Ça a été excellent. Les aperçus de déploiement fonctionnent. L'intégration GitHub signifie que chaque PR obtient son propre environnement. La latence de démarrage à froid de ce conteneur particulier se situe autour de 800 ms à 1,2 secondes au premier accès après inactivité, ce qui semble mauvais mais est acceptable quand le trafic du client est irrégulier et prévisible.
Le coût de ce service ? Environ 20 $/mois avec le forfait Pro de Vercel pris en compte. L'équivalent sur DigitalOcean App Platform serait similaire. Un droplet brut serait moins cher, mais nous devrions le gérer nous-mêmes.
Le Scénario Où C'est Clairement un Gain
Pensez au projet d'agence typique. Un site marketing avec un CMS headless, une API légère pour un formulaire de contact ou une logique personnalisée, et un besoin de déploiements rapides. Auparavant, vous auriez Vercel pour le frontend et un droplet à 6 $ pour la petite API. Maintenant, vous pouvez tout mettre sur Vercel, utiliser un seul tableau de bord, avoir des aperçus de déploiement pour l'API aussi. Moins de choses à maintenir. Moins de choses qu'on oublie de mettre à jour.
Pour les freelances gérant entre cinq et quinze sites clients, cette simplicité opérationnelle vaut de l'argent réel même si le coût de calcul est légèrement plus élevé.
Où un VPS gagne toujours. C'est clair.
Bon. Je dois être direct ici, parce que l'enthousiasme autour des conteneurs Vercel a poussé certains développeurs à faire des erreurs coûteuses.
Opérations de système de fichiers persistant. Si votre app génère des PDFs et les stocke localement avant de les envoyer vers S3, d'accord, cette opération spécifique fonctionne. Mais si vous exécutez quelque chose comme une instance Meilisearch auto-hébergée qui écrit son index sur le disque, vous avez besoin d'un stockage persistant. Vercel ne vous donne pas de volume monté. Vous devriez ajouter quelque chose comme un service Meilisearch géré ou l'exécuter sur un VPS. Point final.
WebSockets et connexions longue durée. Les environnements serverless et conteneur de Vercel ont des délais d'expiration de requête. Je me suis heurté à ça avec un projet Seahawk fin 2024, avant même que le support Docker ne soit déployé. Nous construisions un outil collaboratif en temps réel pour un petit client SaaS. Nous avons essayé tout pour le faire fonctionner sur l'infrastructure serverless. Finalement, nous avons déplacé le serveur WebSocket vers un VPS Hetzner à 12 $/mois. Problème résolu. Le VPS tourne sans interruption depuis.
Workers d'arrière-plan et cron à l'échelle. Oui, Vercel a des cron jobs. C'est correct pour les tâches planifiées simples. Mais si vous exécutez quelque chose comme des workers Celery qui traitent continuellement une queue de jobs, vous voulez un processus qui tourne simplement. Un VPS le fait sans effort. Sur les conteneurs Vercel, vous travaillez à contre-courant.
Coût en volume. C'est celui-là qui surprend les gens. À faible et moyen traffic, les conteneurs Vercel sont compétitifs. Mais à très gros volumes de requêtes, la tarification par requête commence à se cumuler. Un serveur dédié Hetzner à 48 $/mois gère le traffic qui coûterait plusieurs centaines de dollars sur Vercel au pic. Mon client qui voulait arrêter ses droplets ? L'un d'eux exécutait un dashboard interne à fort traffic. J'ai fait les calculs. Garder le droplet coûtait £18/mois moins cher même après avoir pris en compte le temps de maintenance occasionnel.
Les workloads spécifiques que je ne bougerais jamais vers Vercel
Soyons concret. Voici les choses que j'oriente activement vers un VPS indépendamment de ce que Vercel publie :
- Bases de données auto-hébergées. Même une petite réplique Postgres pour la performance en lecture. Vercel n'est pas un hôte de base de données. Utilisez-le avec Neon, Supabase, ou PlanetScale, mais n'essayez pas d'exécuter Postgres lui-même là-bas.
- Traitement des médias. Jobs FFmpeg, files d'attente de redimensionnement d'images, tout ce qui est CPU-intensif avec des durées d'exécution imprévisibles. Un VPS Hetzner à 20 $ avec 2 vCPU le gère mieux et moins cher.
- Outillage interne qui tourne 24h/24. Agents de monitoring, agrégateurs de logs, serveurs proxy personnalisés. Ces services devraient simplement fonctionner. Toujours. La réduction à zéro est l'ennemi ici.
- Tout ce qui touche à un GPU. C'est évident, mais ça vaut le coup de le dire.
Et à l'inverse, voici ce que je mettrais en toute confiance sur les conteneurs Vercel aujourd'hui :
- API REST légères (FastAPI, Express, Gin) sans état persistant
- Applications Next.js ou Remix conteneurisées avec configuration serveur personnalisée
- API internes sollicitées uniquement pendant les heures de bureau (la réduction à zéro est en fait excellente ici)
- N'importe quel service où vous voulez vraiment des aperçus de déploiement par PR
Le Coût Caché Dont Personne ne Parle : la Complexité Opérationnelle
J'ai construit plus de 12 000 sites au fil des années chez Seahawk. Ce qui pose le plus problème aux agences et aux freelanceurs, ce n'est pas le coût du calcul. C'est la charge opérationnelle.
Un VPS semble bon marché à 6$/mois. Et c'est bon marché. Mais ensuite vous patcherez le serveur, le superviserez, configurerez Nginx, mettrez en place fail2ban, et occasionnellement vous vous connecterez en SSH à 23h parce que quelque chose se comporte bizarrement. Ce n'est pas gratuit. C'est du temps, et le temps coûte cher.
Vercel supprime tout cela. Tout comme Railway, Render et Fly.io. La vraie concurrence ici n'est pas « Vercel versus un VPS en isolation ». C'est « frais de plateforme gérée versus frais de temps d'exploitation ». Pour les opérateurs indépendants et les petites agences, les frais de plateforme gérée sont généralement la meilleure affaire.
En 2019, un client m'a confié un cahier des charges qui incluait la gestion de son serveur Ubuntu. J'ai ajusté mon devis en conséquence. Six mois plus tard, je recevais toujours des alertes sur l'espace disque d'un serveur que je « gérais » techniquement mais auquel j'avais complètement dénié la priorité. Depuis, j'ai été beaucoup plus délibéré quant à la question de savoir quelle infrastructure je prends en charge par rapport à ce que je paie à une plateforme de gérer.
Le framework que j'utilise réellement pour décider
Pas un organigramme magique. Juste une série de questions que je me pose sur chaque nouveau projet :
- Ce service écrit-il sur le disque et s'attend-il à ce que ces écritures persistent ? Si oui, cela nécessite un VPS ou du stockage géré.
- Ce service maintient-il des connexions de longue durée (WebSockets, SSE, flux gRPC) ? Si oui, VPS ou une plateforme qui l'explicite comme Fly.io.
- Ce service est-il limité par le processeur pendant des périodes prolongées ? Les conteneurs Vercel ont un plafond CPU. Le VPS gagne.
- L'équipe a-t-elle besoin de déploiements en aperçu et de GitOps sans réfléchir ? Vercel gagne.
- Le trafic sera-t-il constant et à gros volume ? Faites les calculs. Le VPS est généralement moins cher au-delà d'un certain seuil.
- C'est un projet solo ou une petite agence qui ne veut pas se préoccuper des serveurs ? Vercel vaut la prime.
Si les questions 1, 2 ou 3 sont oui, je vais chercher Hetzner ou DigitalOcean. Tout le reste, c'est une discussion.
À quoi ressemble réellement 2026 pour l'infrastructure
Les plateformes s'améliorent sur le stockage persistant. Fly.io a Fly Volumes. Render a des disques persistants. Vercel ajoutera probablement quelque chose de similaire à un moment donné, vu la fréquence des demandes. L'écart entre « plateforme managée » et « VPS avec contrôle total » se réduit.
Mais réduire n'est pas la même chose que fermer. Et l'économie du compute brut n'a pas fondamentalement changé. Une instance Hetzner CAX11 ARM à 3,79 €/mois reste une valeur absurdement bonne pour la bonne charge de travail. Personne ne fait mieux sur une plateforme managée pour un compute équivalent.
L'honnête état du monde en 2026, c'est ceci : le VPS n'est pas mort. Le VPS devient de plus en plus optionnel. Ce ne sont pas la même chose.
La plupart des nouveaux projets que je démarre chez Seahawk se répartissent maintenant par défaut sur Vercel ou Railway, sauf si quelque chose dans cette liste de questions ci-dessus déclenche une réponse différente. On a probablement réduit le nombre d'instances VPS actives qu'on gère d'environ 40 % au cours des dix-huit derniers mois. Mais celles qui restent y sont pour de bonnes raisons, et elles ne disparaîtront pas.
FAQ
Les conteneurs Vercel peuvent-ils remplacer Docker Compose pour la parité local-production ?
Un peu, mais pas vraiment. Docker Compose parle d'orchestrer plusieurs services ensemble localement. Vercel exécute un seul conteneur par déploiement. Si ta stack a un serveur web, un worker et Redis définis dans un fichier Compose, Vercel peut gérer la partie serveur web. Tu devrais toujours pointer sur Redis managé (Upstash est le choix courant) et gérer le worker séparément. La parité locale est meilleure qu'avant, mais Compose-vers-Vercel n'est pas une traduction directe.
Que se passe-t-il avec les conteneurs Vercel quand ils passent à zéro ?
Le processus du conteneur s'arrête. Quand une nouvelle requête arrive, Vercel le redémarre. Ce temps de redémarrage, c'est ta latence de démarrage à froid. Pour les binaires compilés (Go, Rust), c'est souvent moins de 500ms. Pour les runtimes plus volumineux comme les applications basées sur JVM, ça peut être 2 à 4 secondes. C'est vraiment important de tester ça en staging avant de te lancer, parce que certains clients vont absolument remarquer un premier chargement de 3 secondes.
Le support des conteneurs de Vercel est-il disponible sur le plan Hobby gratuit ?
Depuis début 2026, non. Les déploiements de conteneurs nécessitent au minimum le plan Pro. Le tier Hobby supporte toujours les fonctions serverless et les sites statiques. Ça vaut le coup de vérifier directement la page de pricing de Vercel puisque ça a changé avant et ça changera probablement encore.
Quand devrais-je utiliser Fly.io à la place de Vercel ou d'un VPS brut ?
Fly est mon choix privilégié quand j'ai besoin de processus persistants, de distribution globale près des utilisateurs, et que je ne veux pas gérer la configuration du serveur. Ça occupe un espace intéressant au milieu. Tu déploies des conteneurs, mais tu as plus de contrôle sur les régions, les tailles de machine, et les volumes persistants que Vercel n'en offre. Je l'utilise pour les APIs longue durée et tout ce qui a besoin de WebSockets et doit être dans plusieurs régions. Le compromis, c'est que la DX est un peu plus impliquée que l'intégration GitHub de Vercel.
---
Le VPS n'est pas quelque chose sur lequel tu devrais compter par défaut par habitude. Mais ce n'est pas non plus quelque chose que tu devrais abandonner par enthousiasme. Connais ta charge de travail. Fais tes calculs. Et peut-être attends deux semaines avant d'éteindre quoi que ce soit.
Lectures connexes : recherche de mots-clés par IA en 2026 : qu'est-ce que c'est, pourquoi tradition, SEO technique, et recherche par IA.