C'était un jeudi soir et le site Next.js d'un client venait de tomber dans ce que je ne peux décrire que comme une spirale de timeout. Des fonctions serverless bloquées à 9,8 secondes, des utilisateurs voyant des écrans blancs, et moi qui vérifiais frénétiquement le tableau de bord de Vercel à minuit en essayant de déterminer si nous avions vraiment atteint une limite de plan ou si le code était juste terrible. (C'était les deux, honnêtement.) Ce projet était sur le plan Hobby. Il ne devrait probablement pas l'être.
J'ai déployé bien plus de 12 000 sites chez Seahawk Media au fil des années. Vercel fait constamment partie de notre stack, particulièrement pour le travail avec Next.js, rien d'autre ne s'en rapproche pour l'expérience développeur. Mais le plan Hobby a des angles tranchants qu'il est facile de rater jusqu'à ce qu'un projet vous morde. Donc voici ma véritable analyse sur où se trouvent ces angles et quand ils commencent à compter.
Ce que le Plan Hobby vous donne vraiment
Soyons précis. Depuis 2024, le plan Hobby de Vercel vous offre :
100 GB de bande passante par mois
6 000 minutes de build par mois
Délai d'expiration de 10 secondes pour l'exécution des fonctions serverless
100 invocations de fonctions serverless par jour... attendez, non. Cette limite n'existe pas. Mais il y a un plafond de 100 Go-heures d'exécution de fonctions serverless par mois
500 000 invocations de fonctions Edge par mois
1 build concurrent à la fois
Les déploiements sont limités aux comptes personnels uniquement (pas d'équipes)
Aucune utilisation commerciale autorisée selon les conditions de Vercel
Ce dernier point crée plus de confusion que n'importe quelle limite technique. Le plan Hobby est explicitement destiné aux projets personnels, non commerciaux. Si vous construisez quelque chose pour un client payant ou exploitez une activité quelconque dessus, vous violez déjà les conditions d'utilisation. J'ai vu des freelances le faire pendant des années et c'est un risque de responsabilité qui attend de se concrétiser.
Le délai d'expiration de 10 secondes pour les fonctions
C'est celui-ci qui pose problème. Dix secondes, ça semble beaucoup jusqu'à ce que vous fassiez un appel à une API tierce qui prend 4 secondes, que vous exécutiez une logique de base de données qui en ajoute 3, puis que vous fassiez quelque chose avec la réponse. Soudain vous êtes à 9,2 secondes sans aucune marge.
Sur le plan Pro, ce plafond monte à 60 secondes (et jusqu'à 900 secondes avec configuration sur Enterprise). Ce n'est pas une différence mineure. C'est la différence entre une intégration qui fonctionne et un produit fondamentalement cassé pour certains cas d'usage.
Build Minutes : Où Elles Disparaissent Plus Vite Que Tu Ne Le Penseras
6 000 build minutes par mois, ça semble généreux. Et pour un seul projet personnel, ça l'est probablement. Le problème, c'est que ce chiffre s'érode plus vite que prévu une fois que tu itères sérieusement.
En 2021, je maintenais un projet annexe, un agrégateur de contenu construit sur Next.js avec environ 400 pages statiques. J'avais ISR configuré mais je faisais aussi des reconstructions complètes fréquentes en expérimentant avec la couche de données. J'ai brûlé environ 4 200 build minutes en trois semaines. Pas parce que les builds étaient lents, mais parce que je les déclenchais constamment.
Chaque build sur un site Next.js de complexité moyenne peut facilement prendre 4 à 8 minutes. Si tu pushes sur main 15 fois par jour pendant le développement actif (ce qui est normal pour moi), ça représente 60 à 120 build minutes disparus en une seule journée. Fais ça pendant une semaine et tu auras consumé la moitié de ta allocation mensuelle.
Il n'y a pas de report. Les minutes ne se reportent pas d'un mois à l'autre. Et quand tu arrives à zéro, tes déploiements s'arrêtent. Point final.
Comment Ralentir la Consommation
Quelques trucs que je fais sur les projets Hobby plan pour préserver les build minutes :
Pushes vers une branche non-production pour les changements expérimentaux. Merge sur main seulement quand quelque chose est vraiment prêt.
Utilise vercel --prebuilt avec les sorties cachées où les artefacts de build n'ont pas changé significativement.
Configurez l'étape de build ignorée de Vercel pour ignorer les builds quand seuls certains fichiers changent (comme les mises à jour de readme ou les commits sans code).
Regroupez les commits. Au lieu de pousser 6 petits correctifs séparément, indexez-les et poussez une seule fois.
Rien de tout cela n'est révolutionnaire. Mais en pratique, la plupart des devs sur les plans Hobby poussent librement et se demandent pourquoi ils n'ont plus de minutes le 20 du mois.
Bande passante : Généralement Correct, Occasionnellement Pas
100 GB de bande passante par mois, c'est là que le plan Hobby est vraiment assez raisonnable. Pour un projet personnel, un portfolio, un petit blog, même un modeste projet SaaS en parallèle avec quelques centaines d'utilisateurs, vous ne toucherez probablement pas ce plafond.
Où ça pose problème, c'est avec les sites gourmands en images sans couche CDN appropriée devant, ou les sites qui connaissent un pic soudain. J'ai eu un client, musicien, dont le site était sur mon compte Vercel personnel pendant une période de transition (je n'aurais pas dû, je le sais, utilisation commerciale et tout ça). L'une de ses morceaux a été repérée par une playlist de bonne taille et le site a reçu environ 40 000 visites en 48 heures. L'utilisation de la bande passante a grimpé. Heureusement, nous étions sous le plafond mais c'était assez serré pour que je les fasse migrer du Hobby immédiatement.
Si vous utilisez l'optimisation des images Next.js, sachez que les images optimisées servies via Vercel comptent dans votre bande passante. Et le plan Hobby a un plafond de 1 000 images source optimisées par mois. C'est une limite dont presque personne ne parle et elle vous rattrapera absolument si vous gérez un portfolio photographique ou n'importe quel site au contenu gourmand en images.
La Question de l'Utilisation Commerciale Mérite Plus d'Attention
Je veux revenir sur ce point parce que je pense que c'est vraiment sous-estimé dans les cercles de freelance.