Prix Vercel : quand la machine Basic réduit la facture des builds

La minute de build la moins chère ne suffit pas à trancher sur le prix Vercel. Le 3 septembre 2026, Vercel a proposé aux équipes Pro et Enterprise une nouvelle option Basic dotée de 2 vCPU, de 8 GB de mémoire et d’un tarif de $0.007 par minute de build. Elle ne réduit la facture que si le coût par build terminé reste inférieur à celui d’Elastic après prise en compte de la durée, des arrondis, des échecs et du temps d’attente.

Ce que Vercel a changé

Une machine de build est l’ordinateur temporaire que Vercel utilise pour installer les dépendances, compiler l’application et préparer son déploiement. Les projets payants disposent désormais d’un choix fixe plus modeste : les machines de build Basic sont accessibles avec les offres Pro et Enterprise, et plus seulement avec Hobby.

Basic fournit 2 vCPU, 8 GB de mémoire et 32 GB de stockage. Elastic peut attribuer de 4 à 30 vCPU et de 8 à 60 GB de mémoire selon la charge du projet. Elastic reste le choix par défaut des nouveaux projets payants.

Il s’agit donc d’une option, pas d’un nouveau réglage payant par défaut. Les nouveaux projets payants démarrent toujours sur Elastic, puis un owner peut choisir Basic dans les paramètres de l’équipe ou du projet. Les projets Hobby conservent la même machine incluse à 2 vCPU, désormais appelée Basic.

Cet article se concentre uniquement sur le choix de la machine de build. Le prix de l’offre, le crédit d’utilisation, les sièges, le trafic, les fonctions, le stockage et les modules complémentaires restent à intégrer dans l’analyse complète des tarifs Vercel.

Prix Vercel : raisonnez en coût par build terminé

Basic et Elastic partent du même tarif CPU : $0.0035 par minute-CPU. Les factures divergent parce que Basic utilise toujours 2 vCPU, tandis qu’Elastic en attribue entre 4 et 30.

Vercel arrondit la durée de chaque build à la minute supérieure. On obtient donc deux formules utiles :

• Basic : minutes de build arrondies à l’entier supérieur × $0.007.
• Elastic : minutes de build arrondies à l’entier supérieur × nombre de vCPU attribués × $0.0035.

Avec la plus petite allocation Elastic, soit 4 vCPU, le coût de départ atteint $0.014 par minute de build facturée. Basic revient donc à la moitié du prix par minute facturée. Les deux options reviennent au même prix lorsque Basic consomme exactement deux fois plus de minutes facturées ; Basic l’emporte s’il reste sous ce seuil.

Cette règle change dès qu’Elastic attribue plus de 4 vCPU. Elle varie également à chaque passage à la minute suivante, puisque Vercel arrondit séparément la durée de chaque build, et non le total mensuel. Pour estimer la facture, il faut partir de la durée et de la machine réellement attribuées, pas d’une simple lecture de la grille tarifaire.

L’économie de $7 est bien réelle dans cet exemple, mais elle n’est pas forcément utile. Si chaque preview bloque un développeur, un relecteur ou un agent de code, le ralentissement de la boucle de feedback peut coûter davantage que le gain sur la facture. Si les builds tournent en arrière-plan et que la file reste fluide, Basic offre le meilleur coût unitaire.

Les échecs doivent eux aussi entrer au numérateur. L’indicateur opérationnel pertinent correspond au total des frais de build divisé par le nombre de déploiements réussis. Une machine bon marché à la minute peut perdre son avantage si elle provoque des relances.

Pourquoi le temps d’attente pèse sur le workflow

La formule de facturation publiée par Vercel repose sur la durée du build et le nombre de CPU. Elle n’ajoute pas le temps passé dans la file comme poste supplémentaire. L’équipe, elle, en subit tout de même les effets.

Quand la concurrence à la demande est désactivée, Pro offre 3 emplacements de déploiement simultanés. Les builds qui dépassent ces emplacements actifs doivent attendre. Avec la concurrence à la demande, Vercel annonce jusqu’à 500 déploiements simultanés et facture les minutes de build consommées.

Un build Basic plus lent monopolise un emplacement plus longtemps. Ce point peut être négligeable pour un fondateur qui déploie un petit site quelques fois par jour. En revanche, l’effet peut vite devenir sensible lorsqu’un agent de code ouvre plusieurs previews, qu’une agence déploie de nombreux projets clients ou qu’une équipe pousse simultanément vers plusieurs branches.

Mesurez les deux délais :

• La durée du build détermine le coût de la machine après arrondi.
• Le temps d’attente plus la durée du build détermine le délai avant feedback.

Toute la décision tient dans ces deux mesures. Optimisez la première sans laisser la seconde dégrader le workflow.

À qui la machine Basic mérite-t-elle un test ?

Un fondateur solo avec une petite application

Le fondateur d’un SaaS peut faire passer un site marketing ou un tableau de bord léger sur Basic au niveau du projet, puis comparer le même build représentatif sur Elastic. L’intérêt est de réduire durablement la ligne consacrée aux builds sans modifier le reste de l’offre Vercel.

Le changement ne mérite d’être conservé que si le build reste fiable et si son éventuel ralentissement ne retarde pas les mises en production. Pour un projet déployé occasionnellement, l’écart en dollars peut être trop faible pour justifier un réglage manuel.

Une agence aux projets clients très différents

Une agence ne devrait pas imposer la même machine à tous les comptes. Affectez les petits sites vitrines et les projets éditoriaux à Basic, projet par projet. Conservez Elastic pour les boutiques plus importantes, les monorepos et les applications riches en dépendances tant que leurs propres mesures ne justifient pas un changement.

Le gain se lit dans la marge de chaque projet. Un client peu gourmand en ressources n’a plus à hériter de la même machine de build que l’application la plus lourde de l’agence.

Un responsable technique qui pilote des agents de code

Le développement assisté par des agents modifie le volet volume de l’équation. Davantage de commits automatisés peuvent produire davantage de previews ; un petit écart de coût se répète alors plus souvent.

Le responsable technique doit mesurer une rafale représentative, pas un déploiement isolé en période calme. Si Basic réduit le coût par build terminé, mais que l’allongement des exécutions occupe les 3 emplacements disponibles et crée une file d’attente, la machine moins chère a simplement déplacé le coût de la facture vers le délai d’exécution.

Un responsable de plateforme Enterprise

Basic est disponible avec Enterprise, mais une clause du contrat peut empêcher toute modification en libre-service. Les clients Enterprise dont le contrat active les machines Enhanced utilisent celles-ci par défaut et doivent contacter leur responsable de compte pour modifier leurs préférences de machine.

Comment basculer un projet et mener le test

Commencez par modifier un seul projet. L’expérience reste ainsi isolée des autres applications et le même réglage permet de revenir facilement en arrière.

1. 1

   Établir la référence Elastic

   Dans Vercel Observability, ouvrez Build Diagnostics et sélectionnez un déploiement représentatif. Relevez la durée du build, la machine attribuée, l’usage facturé, le temps d’attente et l’aboutissement du déploiement. Pour le test Basic, conservez des conditions de cache et une révision de code comparables.

2. 2

   Choisir Basic pour le projet

   Ouvrez le projet dans Vercel, puis accédez à Settings, Build and Deployment et Build Machine. Sélectionnez Basic, puis enregistrez. Vercel propose le même choix au niveau de l’équipe, mais le réglage par projet constitue un premier test plus prudent. Le rôle owner est nécessaire pour accéder aux paramètres de la machine de build.

3. 3

   Passer par la commande CLI documentée

   À partir de la version 59.6.0, la CLI Vercel permet de modifier le projet avec cette commande :

   vc project update --build-machine basic

   L’erreur classique consiste à utiliser une ancienne CLI et à conclure que le choix de la machine n’est pas disponible. Vérifiez la version avant d’interpréter l’échec de la commande comme une restriction de l’offre.

4. 4

   Rejouer la même charge

   Relancez le build de la même révision représentative avec des conditions de cache comparables. Relevez les mêmes données : durée, machine, usage facturé, temps d’attente et résultat. Pour un workflow piloté par des agents, incluez une rafale habituelle afin que la file d’attente puisse se manifester.

5. 5

   Décider à partir des résultats

   Calculez le coût mensuel total des builds, puis divisez-le par le nombre de déploiements réussis. Conservez Basic si ce coût unitaire diminue et si le délai global respecte toujours l’objectif de l’équipe. Revenez à Elastic dans les paramètres Build Machine si la vitesse, la mémoire ou la fiabilité se dégrade au point d’annuler l’économie.

Les limites à ne pas minimiser

Basic est une machine plus petite, pas une version plus efficace d’Elastic. Son plafond de mémoire reste fixé à 8 GB. Elastic peut monter jusqu’à 60 GB et 30 vCPU lorsque la charge l’exige.

L’arrondi peut également absorber une petite économie. Quelques secondes au-delà d’une limite de minute déclenchent la facturation d’une minute entière supplémentaire. Comparez l’usage facturé affiché par Vercel, et non un calcul au chronomètre arrondi à votre avantage.

Elastic continue aussi de s’adapter à l’évolution du projet, alors que Basic reste fixe. Un choix pertinent pour la petite application actuelle peut ne plus l’être après l’ajout de dépendances, de routes ou de ressources générées.

Qui doit agir, attendre ou passer son tour ?

• Agissez cette semaine si un projet Pro ou Enterprise exécute des builds stables, peu gourmands en ressources et assez nombreux pour qu’un écart récurrent par build compte réellement.
• Attendez si le projet est limité par le CPU, gourmand en mémoire, proche de la limite de 45 minutes ou déjà sensible aux files de previews. Commencez par établir une référence Elastic propre.
• Ignorez ce changement tarifaire avec Hobby. La machine incluse à 2 vCPU a été renommée Basic, mais ni la machine ni les conditions de l’offre n’ont changé.
• Vérifiez d’abord le contrat si les machines Enhanced sont activées avec Enterprise. La décision peut revenir au responsable de compte.

Le test à lancer lundi

Lundi, choisissez un petit projet représentatif. Lancez le même build sur Elastic puis sur Basic, et relevez la durée, l’usage facturé, les CPU attribués, le temps d’attente et le résultat. Gardez l’option qui réduit le coût par build terminé sans dépasser l’objectif de délai de l’équipe.

Abonnez-vous à la newsletter pour recevoir d’autres analyses claires des changements de plateforme qui affectent le budget ou le workflow.