Un client m'a appelé un lundi matin l'année dernière. Pas un message. Un appel téléphonique. Ce n'est jamais bon signe. Il avait déployé un site marketing Next.js sur le plan Pro de Vercel le jeudi précédent, avait lancé un produit le week-end, et s'était réveillé avec une facture de 340 $ dans sa boîte de réception. Le site avait très bien fonctionné. Le trafic avait explosé. Et Vercel avait discrètement mesuré chaque gigaoctet de données quittant leur réseau. Il n'avait pas défini de limite de dépenses. Aucune alerte configurée. Rien.
Cet appel est la raison pour laquelle je consacre maintenant vingt minutes à l'hygiène de facturation Vercel avec chaque client avant de déployer quoi que ce soit en production.
Voici ce que vous devez comprendre sur la façon dont Vercel facture la bande passante, pourquoi cela prend les gens au dépourvu, et ce qu'il faut vraiment faire à ce sujet.
---
Ce que « Sortie » signifie réellement sur Vercel
L'egress est la data transférée hors du réseau de Vercel vers l'utilisateur final. Chaque image, chaque bundle JavaScript, chaque réponse API, chaque fichier de police. Si ça quitte leur edge et arrive dans un navigateur, ça compte.
Sur le plan Hobby vous avez 100GB de bande passante par mois, inclus. Sur Pro c'est 1TB. Ça semble beaucoup. Mais voilà le truc : si vous servez de grandes images, si vous faites du rendu côté serveur sur des pages avec des payloads JSON lourds, ou si votre app connaît un pic de trafic soudain, vous pouvez dépasser 1TB plus vite que vous ne le penseriez. Vercel facture $0,15 par GB de dépassement sur Pro au moment où j'écris (vérifiez toujours leur page de tarification actuelle parce que ça bouge).
Donc 500GB au-delà de votre limite c'est $75. Pas catastrophique. Mais un moment viral, une configuration d'optimisation d'image ratée, ou un scraper qui martèle vos API routes ? Ça peut être des milliers.
Pourquoi Ça Prend Les Gens Par Surprise
Le truc c'est que le développement local ne vous donne aucune indication. Vous buildez vite, vous déployez vite, tout semble aller bien. Le dashboard de Vercel montre l'utilisation de la bande passante mais il ne vous crie pas après. Si vous n'avez pas proactivement configuré une alerte de facturation, vous l'apprenez quand la facture arrive.
---
Les Configs Les Plus Susceptibles de Wrecker Votre Facture
J'ai audité beaucoup de déploiements chez Seahawk. Il y a quatre coupables que je vois encore et encore.
1. Images Non Optimisées Contournant next/image
next/image est vraiment bon dans ce qu'il fait. Il redimensionne, convertit en WebP, et cache. Mais j'ai vu des projets où les développeurs tiraient les images directement d'une balise <img> pointant vers des fichiers en pleine résolution dans un bucket S3, proxifiés via une API route Vercel. Chaque requête tirait un JPEG de 4MB à travers le réseau de Vercel au lieu d'un WebP de 200KB depuis un edge CDN. Multipliez ça par 50 000 vues de page et faites le calcul.
Utilisez toujours next/image avec une configuration remotePatterns appropriée. Si la source de l'image est externe, assurez-vous qu'elle passe par le cache du CDN et ne fait pas d'aller-retour à travers vos fonctions serverless.
2. Routes API qui retournent des payloads volumineux
En 2021, j'ai construit un catalogue de produits e-commerce pour un détaillant britannique. Leur route API récupérait une liste de produits depuis leur base de données et retournait l'objet produit entier, y compris les champs que le front-end n'utilisait jamais. Description, notes SKU internes, métadonnées de variantes, tout. Chaque réponse faisait environ 80 KB au lieu des 12 KB dont elle avait besoin.
Affinez vos réponses API. Retournez uniquement les champs que le client consomme réellement. Si vous utilisez quelque chose comme Prisma, utilisez select pour limiter ce que vous récupérez. Si vous utilisez une API tierce, transformez et réduisez le payload avant de l'envoyer en aval.
3. ISR avec des fenêtres de revalidation courtes sur les routes à fort trafic
L'Incremental Static Regeneration est brillant en théorie. En pratique, si vous définissez revalidate: 30 sur une page qui reçoit 10 000 hits par minute, vous mettez toujours en cache correctement. Mais si vous la définissez à revalidate: 1 parce que vous vouliez des mises à jour quasi en temps réel et avez oublié de la changer... vous faites essentiellement du SSR avec des étapes supplémentaires et payez l'egress sur chaque réponse de cache presque manquée.
Soyez délibéré sur vos fenêtres de revalidation. La plupart du contenu n'a pas besoin de se revalider chaque seconde.
4. Fonctions serverless sans en-têtes de cache
Celui-ci est subtil. Si votre réponse de fonction serverless n'inclut pas un en-tête Cache-Control (ou la combinaison s-maxage / stale-while-revalidate de Vercel), la réponse n'est pas mise en cache à la périphérie. Chaque requête accède à la fonction et fait l'aller-retour complet. Vous perdez complètement l'avantage du CDN et payez l'egress sur chaque réponse.
`` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 ``
Cet en-tête seul a fait économiser de l'argent réel à mes clients. Sérieusement. La documentation de caching de Vercel explique le comportement de l'en-tête en détail. Lisez-la une fois correctement.
---
Comment configurer les alertes de facturation (avant d'en avoir besoin)
Cela devrait être l'étape une avant tout déploiement en production. Pas l'étape sept.
- Allez dans les paramètres de votre équipe Vercel.
- Sous Billing, trouvez Spend Management.
- Définissez une limite de dépense (plafond strict, où Vercel cesse de servir les requêtes après la limite) ou un seuil de notification (alerte douce, vous envoie un email quand vous atteignez un montant).
- Je recommande de définir une notification à 50% de ce que vous considéreriez comme douloureux, et une limite stricte à environ 120% de votre facture mensuelle prévue.
Le plafond strict est une arme à double tranchant. Si vous l'atteignez, votre site s'arrête. Réfléchissez donc bien. Pour un site marketing? D'accord, imposez un plafond strict. Pour un SaaS avec des utilisateurs payants? Définissez des notifications généreuses et surveillez le tableau de bord à la place.
---
Déléguer les tâches lourdes ailleurs
Vercel n'est pas un CDN pour les assets statiques. Je veux dire, il a un CDN, mais vous payez par gigaoctet qui en sort. Pour les assets statiques en gros volume, mettez-les quelque part de moins cher.
Je route les gros fichiers média via Cloudflare R2 depuis environ dix-huit mois. R2 n'a aucun frais de sortie. Vous payez le stockage et les opérations, pas les données qui sortent. Pour les sites lourds en images, c'est une vraie économie. Un de mes clients gère une plateforme de portfolio photographique et payait environ 180 $/mois en frais de sortie Vercel. On a déplacé toutes les images en haute résolution et les assets de galerie vers R2, on a gardé les miniatures via next/image, et la facture Vercel est tombée à moins de 40 $.
Les alternatives qui méritent d'être connues :
- Cloudflare Pages pour les déploiements statiques où vous n'avez pas besoin des fonctionnalités edge de Vercel. Tier gratuit généreux, aucun frais de sortie.
- AWS CloudFront devant S3 si vous êtes déjà dans l'écosystème AWS. Les coûts de transfert sont plus bas que les tarifs de dépassement de Vercel à grande échelle.
- BunnyCDN est bon marché et rapide pour la pure livraison d'assets. Je l'ai utilisé sur quelques migrations WordPress-vers-Next.js à fort trafic où le volume d'assets était important.
Le point, c'est : Vercel est le bon endroit pour exécuter votre logique d'application Next.js. Ce n'est pas toujours le bon endroit pour servir vos gigaoctets de média.
---
Surveillance de l'utilisation en temps réel
Ne vérifiez pas votre tableau de bord uniquement à la fin du mois. C'est comme ça que mon client s'est retrouvé à m'appeler un lundi.
Quelques outils que j'utilise vraiment :
- Vercel Analytics vous donne les données au niveau de chaque page et c'est utile pour identifier quelles routes génèrent le plus de trafic (et donc le plus de bande passante sortante).
- Axiom s'intègre parfaitement aux drains de journaux de Vercel et vous permet de requêter la taille des requêtes au fil du temps. J'ai commencé à l'utiliser fin 2022 et ça a été utile sur les gros projets pour corréler les pics de trafic aux augmentations de bande passante sortante.
- Configurez un simple cron (Vercel supporte nativement les crons maintenant) qui appelle leur API et envoie un message à un canal Slack quand la bande passante dépasse un seuil. J'ai construit une version légère de ça pour l'infrastructure propre de Seahawk. Ça prend deux heures, ça épargne pas mal d'anxiété.
L'API REST de Vercel expose les données de déploiement et d'utilisation. Ce n'est pas l'API la plus élégante du monde mais elle fait ce qu'il faut pour des alertes basiques.
---
La Décision Architecturale Dont Personne Ne Parle
Voici quelque chose que je ne vois pas assez discuté : parfois Vercel n'est pas le bon choix par défaut.
Si votre projet est un site marketing statique sans vraie fonctionnalité dynamique, vous n'avez pas besoin de Vercel. Cloudflare Pages ou le tier gratuit de Netlify feront le travail sans aucune préoccupation de bande passante sortante. Vous ne « gaspillez » pas Vercel, vous utilisez juste pas le bon outil pour la charge de travail.
À l'inverse, si tu construis une véritable app Next.js avec du edge middleware, des server components, et des API routes qui font du vrai travail, Vercel vaut le coup de payer. Le DX est genuinely excellent et le réseau edge est rapide. Fais juste en sorte que l'architecture soit correcte dès le départ.
L'erreur que j'ai faite tôt dans ma carrière (vers 2016, avant même que Vercel existe, à l'époque où je figais le déploiement sur Heroku et Netlify) était de traiter la plateforme de déploiement comme une afterthought gratuite. Le choix de la plateforme façonne ton profil de coûts autant que le choix de ta base de données. Prends-le au sérieux.
---
FAQ
Le plan Hobby est-il soumis à des frais d'egress si je dépasse 100GB ?
Non. Sur le plan Hobby, Vercel ne facture pas de dépassement ; il ralentit ou suspend le déploiement une fois que tu atteins la limite. Ce n'est pas top de toute façon, mais tu ne recevras pas de facture surprise. Les factures surprises arrivent sur Pro et Enterprise où l'usage est mesuré au-delà du montant inclus.
L'optimisation d'images de Vercel compte-t-elle dans l'egress ?
Oui. Les images optimisées servies via next/image comptent toujours dans l'egress. Les économies se font sur la taille du fichier : tu sers un WebP de 180KB au lieu d'un JPEG de 3MB, donc l'egress par image est beaucoup plus bas. C'est l'optimisation elle-même qui réduit le coût, pas une exemption spéciale.
Puis-je utiliser un CDN custom devant Vercel pour réduire l'egress ?
Tu peux mettre le proxy de Cloudflare devant ton déploiement Vercel. Cloudflare met en cache les réponses à son edge, ce qui signifie que les requêtes qui touchent le cache de Cloudflare ne atteignent jamais Vercel du tout. Cela peut réduire significativement à la fois l'egress et les invocations de fonction. Il y a quelques restrictions avec les preview deployments et la gestion des headers, mais pour la production, c'est une approche courante et légitime. La documentation de Cloudflare sur le proxying couvre la configuration.
Quelle est la cause unique la plus importante des factures Vercel inattendues ?
D'après mon expérience : la gestion des images. Soit des images en pleine résolution servies sans optimisation, soit des routes d'optimisation d'images appelées à chaque requête sans mise en cache appropriée. Réglez d'abord votre pipeline d'images, tout le reste ensuite.
Vercel vous notifie-t-il automatiquement si l'utilisation augmente soudainement ?
Non par défaut. Vous devez le configurer. Il n'y a pas d'alerte prête à l'emploi qui dit « vous avez utilisé 80 % de votre bande passante ». C'est là le problème. Définissez vos seuils de gestion des dépenses le même jour où vous configurez votre déploiement en production. Pas plus tard.
---
Vercel est une excellente plateforme. Je l'utilise, Seahawk l'utilise, et je continuerai à la recommander pour les bons projets. Mais c'est un service mesuré qui fonctionne sur une infrastructure réelle, et la tarification le reflète. Les développeurs qui souffrent des factures surprises sont presque toujours ceux qui l'ont traité comme un CDN gratuit et n'ont jamais regardé les paramètres de facturation. Cinq minutes de configuration au moment du déploiement vous épargneront un appel téléphonique très désagréable le lundi matin.
Lecture connexe : Sites de bijouterie de luxe qui se chargent en moins de 1,5 secondes, Core Web Vitals et vitesse WordPress.