1. Origine
Vercel a été fondée en 2015 par Guillermo Rauch sous le nom de ZEIT, avec une ambition assez simple : rendre la mise en ligne d'une application aussi banale qu'un git push. L'entreprise a pris son nom actuel en 2020.
C'est la même équipe qui développe Next.js, ce qui explique que les deux outils avancent au même rythme : une fonctionnalité du framework est généralement disponible sur la plateforme le jour de sa sortie. Le modèle a fait école bien au-delà : build automatique à chaque commit, URL de préversion par branche, mise en production sans interruption de service.
2. Utilité
Le déploiement est l'endroit où beaucoup de projets perdent du temps : environnements qui divergent, mises en ligne redoutées, allers-retours interminables pour faire valider une modification. Vercel supprime l'essentiel de ces frictions.
Ce qui change le plus dans le quotidien d'un projet, c'est la préversion : chaque branche produit une URL réelle, partageable au client sans rien installer. La validation se fait sur le site tel qu'il sera, pas sur une capture d'écran. La mise en production consiste alors à promouvoir un build déjà testé, et le retour arrière est immédiat en cas de problème.
3. Fonctionnalités
Vercel couvre toute la chaîne entre le dépôt de code et le visiteur, sans serveur à administrer.
- Déploiement continu depuis GitHub, GitLab ou Bitbucket, déclenché à chaque push
- Préversions : une URL unique par branche et par commit, avec commentaires de revue posés directement sur la page
- Rollback instantané : chaque déploiement reste accessible, revenir à la version précédente prend quelques secondes
- Réseau edge mondial : les fichiers statiques sont servis depuis le point de présence le plus proche du visiteur
- Fonctions serverless et edge pour la logique côté serveur : API, webhooks, authentification
- Variables d'environnement par contexte (développement, préversion, production), sans dupliquer la configuration
- Domaines et certificats TLS gérés et renouvelés automatiquement
- Analytics et Speed Insights : audience et Core Web Vitals mesurés sur le trafic réel, pas en laboratoire
- Stockage intégré (base de données, clé-valeur, fichiers) pour les projets qui en ont besoin
4. Cas concrets
→ Sur un projet en recettage, chaque correction poussée génère une URL de préversion que le client ouvre directement : les retours portent sur la page réelle plutôt que sur une capture, et la version validée est promue en production sans nouvelle manipulation.
→ Sur une application Next.js, les fonctions serverless prennent en charge l'authentification, les appels à la base de données ou les webhooks de paiement sans provisionner la moindre infrastructure : le code de l'API vit dans le même dépôt que l'interface et se déploie avec elle.
5. Prix
Un plan Hobby gratuit couvre les projets personnels et les démonstrations, avec déploiements illimités et domaine personnalisé. Les usages professionnels passent par un plan Pro facturé par utilisateur et par mois, qui débloque les collaborateurs, des limites d'usage supérieures et le support. Point de vigilance : la facturation dépend aussi de la consommation réelle (bande passante, invocations de fonctions), ce qui demande de surveiller les pics de trafic et de poser des limites de dépense dès la mise en production.
→ Tarifs : vercel.com/pricing
6. Questions fréquentes
Vercel ou Cloudflare pour héberger un site ?
Les deux servent depuis un réseau mondial et font très bien le travail. Vercel est le choix le plus direct pour un projet Next.js, avec lequel l'intégration est totale. Cloudflare est souvent plus intéressant sur les coûts à volume élevé et quand le projet s'appuie déjà sur son écosystème : DNS, stockage, Workers, sécurité.
Est-on enfermé sur la plateforme ?
Pas sur le framework : Next.js est open-source et se déploie ailleurs. En revanche, plus on utilise les services propres à Vercel (stockage, analytics, fonctions edge spécifiques), plus une migration demande de travail. C'est un arbitrage à faire au début du projet, pas à la fin.
La facture peut-elle déraper ?
Elle est liée à la consommation, donc oui en cas de pic de trafic inattendu ou de fonction mal optimisée. Des plafonds de dépense et des alertes sont configurables : sur un projet en production, c'est la première chose à régler.
