La vitesse ne départage pas grand-chose
Le discours habituel de l’hébergement européen tient en une phrase : vos utilisateurs sont ici, vos serveurs devraient l’être aussi, donc votre site ira plus vite. L’intuition est bonne. Les chiffres la nuancent beaucoup.
Encore faut-il mesurer la bonne chose. Le temps du premier octet, tel qu’on le cite d’ordinaire, additionne la résolution DNS, la poignée de main TCP, celle de TLS, puis la réponse du serveur. Les trois premières dépendent de la distance et du réseau, pas de l’hébergeur. Nous les séparons donc.
| Plateforme | À froid | Serveur seul |
|---|---|---|
| pages.cloudflare.com | 50 ms | 15 ms |
| swigs.cloud | 66 ms | 20 ms |
| www.netlify.com | 75 ms | 29 ms |
| vercel.com | 110 ms | 66 ms |
Nos machines répondent en vingt millisecondes. C’est trois fois plus rapide que Vercel et un tiers plus rapide que Netlify. Mais Cloudflare répond en quinze, et il faut le dire aussi : un réseau de diffusion mondial a des points de présence à Zurich et à Genève, il est donc chez vous exactement comme un serveur romand. Sur ce terrain, la proximité géographique ne nous donne aucun avantage décisif.
Voilà pourquoi nous ne vendons pas la vitesse. Cinq millisecondes ne décident de rien, et vous pouvez vérifier ce tableau vous-même en une minute.
Ce qui tient à la place
Trois raisons de partir résistent à l’examen. Aucune n’est technique.
La juridiction, qui ne se mesure pas en millisecondes
Vercel Inc. est une société américaine. Peu importe la région où tournent vos fonctions : le fournisseur relève du droit américain, et notamment du CLOUD Act de 2018, qui oblige un prestataire soumis à la juridiction des États-Unis à remettre les données qu’il détient, y compris lorsqu’elles sont stockées à l’étranger. Ce n’est pas une opinion sur les États-Unis, c’est le texte. Nous l’avons détaillé dans un guide séparé.
Pour un site vitrine, cela n’a aucune conséquence pratique. Pour une application qui traite des dossiers médicaux, des données RH ou des pièces comptables de clients suisses, c’est la question qui décide de tout le reste.
La facturation à l’usage, et sa queue
Le modèle de Vercel facture ce que vous consommez : invocations, transfert, minutes de compilation, optimisations d’images. C’est excellent tant que vous êtes petit, et c’est exactement là que le modèle se retourne : le jour où un article passe sur un agrégateur, la facture suit le trafic. Nous ne publions pas de comparaison chiffrée ici, pour une raison simple : les grilles tarifaires changent plusieurs fois par an, et un article qui cite des prix ment six mois plus tard. Allez les lire à la source.
Ce qui ne change pas, c’est la structure : un forfait est prévisible et vous fait payer ce que vous n’utilisez pas ; l’usage est juste et vous expose à la surprise. Le bon choix dépend de votre tolérance à la surprise, pas d’un tableau comparatif.
La dépendance aux fonctions propriétaires
C’est le point que les articles de comparaison sautent, et c’est le seul qui vous coûtera du temps. Next.js est un projet libre ; une partie de ses fonctions les plus commodes ne s’exécute correctement que sur l’infrastructure de son éditeur, ou demande un travail d’équivalence ailleurs.
| Fonction | Hors de Vercel | Ce qu’il faut faire |
|---|---|---|
| Rendu serveur, routes API | Fonctionne | output: "standalone", un conteneur, un port. |
| ISR et revalidation | Fonctionne, seul | Le cache vit dans l’instance. Avec plusieurs instances, il faut un cache partagé. |
| Optimiseur d’images | À remplacer | Un service d’images, ou unoptimized avec des fichiers déjà en WebP. |
| Middleware Edge | À déplacer | S’exécute au nœud, plus au bord. La latence ajoutée redevient visible. |
| Déploiements d’aperçu par branche | À reconstruire | Rien ne le remplace tout seul. C’est la vraie perte. |
| Analytics et Speed Insights | À remplacer | Plausible, Matomo, ou rien. |
La migration, concrètement
Une application Next.js sort de Vercel avec une ligne de configuration. Le mode standalone demande à Next de produire un serveur autonome, avec seulement les dépendances qu’il utilise réellement.
const nextConfig = {
output: "standalone",
};
export default nextConfig;La compilation écrit alors .next/standalone, qui se lance avec node server.js et écoute sur PORT. À partir de là, n’importe quel hébergeur capable de faire tourner un conteneur Node fait l’affaire, le nôtre compris, qui détecte ce cas sans qu’on lui dise quoi que ce soit.
Si votre site est entièrement statique, c’est encore plus simple : output: "export" produit un dossier de fichiers, et il ne reste plus qu’un serveur web à les servir. C’est le choix qu’on a fait pour la page que vous lisez.
Ce qu’il faut retenir
Ne partez pas de Vercel pour la vitesse : depuis la Suisse, un bon réseau de diffusion fait jeu égal avec un serveur local, et nos propres mesures le montrent. Partez si la juridiction compte pour vos données, si vous voulez une facture qui ne dépend pas de votre trafic, ou si vous refusez de dépendre de fonctions qui n’existent que chez un seul fournisseur.
Et si aucune de ces trois raisons ne vous concerne, restez. Un hébergeur honnête vous le dit aussi.
Sources
- [1]Mesures de latence, script conservé dans le dépôt du site, sous tasks/mesure-latence.sh. Sept passages par cible, médiane retenue, exécuté le 2 septembre 2026 depuis Lausanne.
- [2]Next.js : Deploying, mode standalone, documentation officielle du mode de sortie autonome et de ses limites hors de la plateforme de l’éditeur.
- [3]H.R.4943, CLOUD Act (115e Congrès, 2018), texte de loi américain sur l’accès aux données détenues à l’étranger par un prestataire soumis à la juridiction des États-Unis.