L’argument de la vitesse ne tient pas
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. C’est une intuition raisonnable. Nous l’avons mesurée, et elle est fausse — ou plutôt, elle est vraie contre certains concurrents et fausse contre les autres, ce qui revient à dire qu’elle ne décide de rien.
| Plateforme | DNS | TCP | TLS | TTFB |
|---|---|---|---|---|
| pages.cloudflare.com | 3 ms | 13 ms | 20 ms | 54 ms |
| swigs.cloud | 3 ms | 16 ms | 22 ms | 57 ms |
| www.netlify.com | 4 ms | 13 ms | 30 ms | 78 ms |
| www.infomaniak.com | 3 ms | 11 ms | 17 ms | 97 ms |
| vercel.com | 3 ms | 13 ms | 31 ms | 109 ms |
Lisez la première ligne : Cloudflare répond plus vite que nous, de trois millisecondes. C’est un écart sans signification pratique, mais il suffit à détruire l’argument commercial. Un réseau de diffusion mondial a un point de présence à Zurich et à Genève ; il est chez vous au même titre qu’un serveur valaisan. Prétendre le contraire serait vous mentir sur quelque chose que vous pouvez vérifier en trente secondes.
Le seul enseignement solide du tableau concerne Vercel : vercel.com répond en 109 ms là où une plateforme proche répond en 55. La poignée de main TCP est pourtant identique (13 ms) — ce n’est donc pas une question de distance jusqu’au premier serveur, mais de ce qui se passe derrière. Une différence de cinquante millisecondes sur le premier octet est réelle, mesurable, et parfaitement invisible pour un utilisateur qui charge une page de deux mégaoctets.
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.