Vercel est une plateforme qui, une fois connectée à un dépôt, construit et publie une application à chaque push, en donnant à chaque branche sa propre adresse à consulter. Elle ajoute à cela des fonctions exécutées à la demande, un réseau de diffusion de contenu et un cache pour les pages rendues côté serveur.
Sa plus grande force est banale, et donc efficace : quelques minutes suffisent entre un dépôt vide et une adresse qui fonctionne, sans rien configurer. Sa plus grande faiblesse est tout aussi simple : la facture reste imprévisible tant que tu n'as pas compris exactement ce que tu paies.
Deux changements à connaître
La documentation décrivant cette plateforme vieillit vite, et deux changements récents invalident une bonne partie de ce que tu trouveras en ligne.
Le premier concerne la scission entre deux types de fonctions. Pendant des années, il fallait choisir entre un environnement edge, rapide à démarrer mais limité en capacités, et un environnement Node classique, plus lent à démarrer mais complet. Le produit autonome de fonctions edge a été retiré en juin 2025, et la réponse recommandée est désormais un seul environnement Node avec un accès complet aux interfaces.
Cela simplifie la vie plus qu'il n'y paraît. Ça supprime toute une classe de bugs où une bibliothèque fonctionnait en local et échouait après déploiement, parce que l'environnement edge ne disposait pas d'un module qu'elle utilisait.
Le second changement concerne la facturation, et c'est celui qui compte le plus pour la note finale. Les fonctions sont facturées pour le temps de travail réel du processeur, et non pour la durée de l'appel mesurée par une horloge. Attendre la réponse d'une base de données ou d'un modèle de langage n'est pas facturé, puisque le processeur est alors inactif.
Ce que cela change pour les coûts
La différence entre ces deux modèles est fondamentale, et elle change l'économie de classes entières d'applications.
Prends une fonction qui interroge une base de données, attend huit cents millisecondes la réponse, puis passe cinquante millisecondes à traiter le résultat. Avec l'ancien modèle, tu payais pour huit cent cinquante millisecondes. Avec le nouveau, tu payes pour cinquante, puisque le reste n'était que de l'attente.
Plus ton application attend, plus l'économie est grande. Une route qui appelle un modèle de langage et attend cinq secondes la réponse coûte une fraction de ce qu'elle coûtait avant. Une route qui redimensionne des images ou trie un grand ensemble en mémoire n'y gagne rien, puisque le processeur y travaille vraiment.
La concurrence s'ajoute à cela. Une seule instance sert plusieurs appels à la fois, donc le temps d'attente d'une requête est utilisé pour en servir une autre. Ça fait encore baisser la facture et raccourcit les démarrages à froid, puisque moins d'instances sont nécessaires.
La conclusion pratique : si ton idée du coût de cette plateforme date d'avant ce changement, recalcule-la. Pour une application qui attend surtout des services externes, la différence se chiffre souvent en plusieurs fois le coût initial.
Les déploiements de prévisualisation, la pièce maîtresse de l'offre
Chaque branche obtient sa propre adresse, et chaque demande de fusion un lien vers une version contenant précisément ces changements.
Ça ressemble à un détail, et c'est pourtant la raison la plus citée pour laquelle les équipes restent sur cette plateforme malgré le coût. Une personne en charge du design relit un changement sur un site qui tourne réellement, pas sur une capture d'écran. Un client clique dans l'application réelle avant que quoi que ce soit n'atteigne la production. Les tests automatisés reçoivent une adresse qui sert exactement le code en cours de revue.
Deux choses méritent d'être surveillées. Les previews sont publiques par défaut sous une adresse difficile à deviner, donc si l'application dans cet état peut atteindre de vraies données, il faut activer une protection d'accès. Et : chaque preview utilise les variables d'environnement assignées à cet environnement, donc les pointer vers la base de données de production est facile et dangereux. Une base de données séparée pour les previews règle le problème une bonne fois pour toutes.
Pour le travail en local, un confort d'adresse similaire vient de Portless, un outil sorti des laboratoires du même éditeur : au lieu de localhost:3000, tu ouvres un projet sous un nom du type boutique.localhost, en HTTPS et avec des cookies séparés par application, de sorte que deux services lancés en même temps arrêtent de se déconnecter mutuellement. Le prix à payer, c'est une installation sur chaque machine de l'équipe et l'ajout d'une autorité de certification privée au magasin de confiance du système, ce qui relève de la politique de sécurité dans certaines entreprises.
La structure des coûts en pratique
La facture comporte plusieurs lignes, et une seule d'entre elles est évidente.
Le plan gratuit suffit pour les projets personnels et les portfolios, avec la réserve qu'aucune activité commerciale n'y est autorisée. Le plan payant démarre à vingt dollars par personne et par mois, et inclut un forfait d'usage au-delà duquel tu payes le dépassement.
Les lignes qui surprennent ne sont généralement pas les fonctions. Le transfert de données, les requêtes servies par le réseau de diffusion de contenu, le stockage et la revalidation des pages générées de façon incrémentale, ainsi que l'optimisation des images, peuvent chacun dépasser le coût de l'exécution du code.
L'optimisation des images mérite sa propre phrase, car c'est la source de surprise la plus fréquente. Chaque taille et chaque format générés pour chaque image comptent séparément, donc une galerie de deux cents photos affichées en cinq tailles représente mille éléments, et non deux cents.
Avant d'inscrire cette plateforme dans un budget, regarde l'onglet d'utilisation après la première semaine de trafic en production. La répartition des lignes y diffère généralement de ce que l'équipe avait supposé, et c'est la seule base sérieuse pour décider.
Il vaut aussi la peine de savoir que la plateforme dispose d'un mécanisme intégré contre exactement la facture décrite plus haut, et que les équipes s'en servent rarement. Les nouvelles équipes reçoivent par défaut un budget d'usage de deux cents dollars, avec des notifications par e-mail, par SMS et dans le tableau de bord, et ce seuil peut être modifié. Les projets peuvent aussi être configurés pour se mettre en pause automatiquement une fois le budget atteint à cent pour cent.
Tranche ce réglage en connaissance de cause dès le premier déploiement en production, car les deux réponses se défendent. La pause automatique protège contre une facture après une boucle incontrôlée ou un pic de trafic, mais elle met le site hors ligne. Une alerte sans pause laisse le site en ligne et reporte la décision sur une personne qui dort peut-être à ce moment-là.
Cache et régénération des pages
C'est l'endroit où la plateforme donne le plus, et où il est le plus facile de désactiver par accident ce pour quoi tu payes.
Une page générée une fois et servie depuis le réseau de diffusion coûte une fraction d'une page recalculée à chaque requête, et répond en quelques dizaines de millisecondes plutôt qu'en centaines. La régénération incrémentale te permet de la garder statique tout en la rafraîchissant après un certain temps, ou à la demande dès que le contenu change.
Le problème, c'est la facilité avec laquelle tu en sors sans l'avoir décidé. Lire un en-tête de requête, aller chercher un cookie, ou appeler une fonction qui renvoie l'heure actuelle transforme une route statique en route dynamique, et tu n'en vois le résultat que dans la facture et dans les temps de réponse.
Le diagnostic est simple une fois que tu sais où regarder. Le résultat du build indique pour chaque route si elle est statique ou dynamique, et comparer cette liste à ce que tu attendais prend une minute.
npx vercel buildFais-le une fois après chaque changement important, car un seul import ajouté à un composant partagé peut faire basculer une douzaine de routes d'un coup.
L'invalidation est une question à part. Le rafraîchissement basé sur le temps est simple et suffisant pour un contenu qui peut être obsolète pendant quelques minutes.
export const revalidate = 600
export default async function Page() {
const posts = await fetchPosts()
return <List posts={posts} />
}L'invalidation à la demande, déclenchée depuis un système de gestion de contenu après publication, donne une fraîcheur immédiate et nécessite une seule route pour recevoir le signal. Cette seconde route vaut généralement une heure de travail, car elle supprime le compromis entre fraîcheur et coût.
import { revalidateTag } from 'next/cache'
import { NextRequest } from 'next/server'
export async function POST(req: NextRequest) {
if (req.headers.get('x-webhook-secret') !== process.env.WEBHOOK_SECRET) {
return new Response('Forbidden', { status: 401 })
}
revalidateTag('posts')
return Response.json({ revalidated: true })
}Vérifier le secret dès la première ligne n'est pas une formalité. Une route d'invalidation sans cette vérification permet à n'importe qui de forcer la reconstruction de toutes les pages, et c'est un moyen peu coûteux de faire grimper la facture de quelqu'un d'autre.
Variables d'environnement et secrets
Trois environnements, chacun avec son propre jeu de variables, et cette distinction mérite d'être bien posée dès le départ.
Les variables marquées comme publiques arrivent dans le code exécuté par le navigateur, donc n'importe qui ouvrant les outils de développement les voit. C'est évident, et c'est pourtant l'endroit le plus courant où fuit une clé vers un service externe : quelqu'un a ajouté le préfixe public pour que ça fonctionne dans un composant client, et ça a fonctionné.
Les variables sans ce préfixe ne sont disponibles que côté serveur, et tout ce qui doit rester secret doit y vivre. La règle est simple : si une valeur permet à quelqu'un d'agir en ton nom, elle ne peut pas être publique, et l'appel qui l'utilise doit passer par une route serveur.
Les variables du tableau de bord se récupèrent pour le travail en local avec une seule commande, plutôt que de maintenir une seconde copie à la main.
npx vercel env pull .env.local
npx vercel env add STRIPE_SECRET productionN'oublie pas non plus que modifier une variable ne prend pas effet tout seul. Les valeurs sont figées au moment du build, donc après modification, il faut redéployer. Ça provoque une confusion récurrente, puisque le tableau de bord affiche la nouvelle valeur pendant que l'application tourne encore sur l'ancienne.
Vercel face aux alternatives
| Solution | Point fort | Faiblesse | Quand la choisir |
|---|---|---|---|
| Vercel | Déploiements de prévisualisation, zéro configuration | Coût élevé avec un fort transfert | Une application Next.js, une équipe sans personne dédiée à l'infra |
| Cloudflare | Transfert bon marché, réseau mondial | Plus de travail de configuration | Fort trafic statique, budget sous contrôle |
| Railway | Conteneurs classiques, bases de données incluses | Pas de previews de ce niveau | Un backend qui ne rentre pas dans le moule des fonctions |
| Ton propre serveur | Contrôle total, coût prévisible | La maintenance est pour toi | Trafic stable, quelqu'un dans l'équipe sait faire |
La première ligne gagne par le confort, pas par le prix, et ça vaut la peine de le dire clairement. Une équipe sans personne dédiée à l'infrastructure obtient déploiements, previews, certificats, réseau de diffusion et retours en arrière sans rien configurer. C'est un vrai gain de temps, à mettre en balance avec la facture plutôt qu'à ignorer quand on compare les tarifs.
La dernière ligne mérite d'être envisagée en cas de trafic stable et prévisible. Une application qui sert une charge régulière en continu coûte moins cher sur une machine à prix fixe que sur une facturation à l'usage, et cet écart se creuse avec l'échelle.
Où cette plateforme ne convient pas
Tranche cette question tôt, car migrer après un an coûte cher.
Les tâches longues ne conviennent pas. Les fonctions ont une limite de temps d'exécution, donc traiter un fichier vidéo, générer un gros rapport ou importer plusieurs centaines de milliers d'enregistrements demande une infrastructure séparée ou un découpage en étapes.
Les processus d'arrière-plan ne conviennent pas. Une file consommée en continu, un écouteur de changements sur une base de données ou une connexion maintenue ouverte ont besoin de quelque chose qui tourne en permanence plutôt que de démarrer à la demande.
Une application au fort transfert de données devient coûteuse ici. Un service vidéo, de l'hébergement de fichiers ou un site avec beaucoup de graphismes génère des coûts de transfert face auxquels une solution auto-gérée se rembourse vite.
Un backend composé de nombreux services s'y adapte mal aussi. Un modèle basé sur les fonctions convient aux routes qui traitent des requêtes, et fonctionne moins bien pour un système avec plusieurs processus, des files et des tâches planifiées entre eux.
Conseils pratiques
Quelques réflexes économisent de l'argent et des nerfs sur la durée avec cette plateforme.
Mets des limites de dépense dès le premier jour. La facturation à l'usage signifie qu'un bug provoquant une boucle de requêtes se transforme en facture plutôt qu'en message de quota épuisé.
Surveille le cache. Une route qui aurait pu être statique et qui est devenue dynamique à cause d'une lecture d'en-tête accidentelle s'exécute à chaque requête au lieu d'une seule fois. C'est la cause la plus fréquente d'un bond soudain du nombre d'invocations sans bond de trafic.
Limite les tailles d'image à celles que tu utilises vraiment. Le jeu de points de rupture par défaut génère des variantes que l'interface n'affichera jamais.
Garde la base de données proche des fonctions. Une requête vers une base de données située de l'autre côté d'un océan ajoute de la latence à chaque requête, et avec la facturation au temps CPU, ça ne fait pas grimper le coût, ça gâche juste la sensation d'utilisation.
Dernier point : ne lie pas ta logique métier aux concepts propres à cette plateforme. Les routes écrites comme de simples fonctions se déplacent ailleurs sans réécriture ; celles construites sur des mécanismes propres à cet éditeur ne le peuvent pas.
Erreurs courantes
La première, c'est de pointer l'environnement de preview vers la base de données de production. Chaque branche atteint alors de vraies données, et un test qui supprime des enregistrements les supprime réellement.
La deuxième, c'est l'absence de limite de dépense. Avec la facturation à l'usage, une erreur coûteuse ne s'arrête pas d'elle-même.
La troisième, c'est de rendre une route dynamique sans s'en rendre compte. Une seule lecture d'en-tête ou de cookie désactive la génération statique et multiplie le nombre d'invocations.
La quatrième, c'est de s'appuyer sur des connaissances antérieures au changement de facturation. Les calculs basés sur la durée de l'appel surestiment le coût des applications qui attendent surtout des services externes.
La cinquième, c'est de faire tourner ici des tâches longues. La limite de temps d'exécution d'une fonction les coupe en plein milieu, et le résultat ressemble à une panne aléatoire.
La sixième, c'est d'ignorer le coût de l'optimisation des images. Chaque variante compte séparément, donc une galerie peut générer plus d'éléments que le reste du site réuni.
FAQ
Vercel est-il gratuit ?
Le plan gratuit suffit pour les projets personnels, l'apprentissage et les portfolios, mais aucune activité commerciale n'y est autorisée. Le plan payant démarre à vingt dollars par personne et par mois, et inclut un forfait d'usage au-delà duquel le dépassement est facturé.
Les Edge Functions existent-elles encore ?
Le produit autonome de fonctions edge a été retiré en juin 2025. La réponse recommandée, ce sont des fonctions tournant sur le runtime Node, qui donnent un accès complet aux interfaces et utilisent une facturation basée sur le temps de travail réel du processeur.
Pour quoi est-ce que je paie exactement avec les fonctions ?
Pour le temps pendant lequel le processeur exécute réellement ton code. Attendre la réponse d'une base de données ou d'une interface externe n'est pas facturé, donc les applications qui passent le plus clair de leur temps à attendre coûtent nettement moins cher qu'avec une facturation basée sur l'horloge.
Vercel fonctionne-t-il uniquement avec Next.js ?
Non, elle prend en charge les frameworks populaires et les sites statiques. L'intégration avec Next.js va le plus loin, puisque les deux viennent de la même entreprise, donc certaines capacités y fonctionnent sans configuration et demandent des réglages ailleurs.
Quand vaut-il mieux choisir autre chose ?
En cas de fort transfert de données, de tâches longues, de processus d'arrière-plan et de charge stable et prévisible. Dans ces cas-là, Railway, Cloudflare ou un serveur classique s'avèrent moins chers ou simplement mieux adaptés.
Le changement de facturation est décrit dans le journal des modifications de l'éditeur, et le détail des plans sur la page des tarifs.