Netlify, Cloudflare Pages, Vercel et Sarpius servent tous des sites statiques depuis une edge mondiale. Voici comment ils diffèrent réellement sur la juridiction et le prix.
Mise à jour le 24 septembre 2026
Pour un build statique ou rendu côté client (Vite, un site SvelteKit prérendu, Astro, du HTML/CSS simple), les plateformes grand public Netlify, Cloudflare Pages, Vercel et Sarpius font toutes à peu près la même chose mécaniquement : tu pousses un dépôt git, obtiens un build téléversé une fois et servi depuis une edge mise en cache avec TLS automatique, sans coût de conteneur. Cloudflare Pages tourne directement sur le propre réseau de Cloudflare. Netlify et Vercel exploitent chacun leur propre CDN. Sarpius téléverse le build dans du stockage d'objets compatible S3 et le sert à travers son propre proxy edge, qui se trouve lui-même par défaut derrière le réseau de Cloudflare ; un site statique hébergé par Sarpius est donc mis en cache sur deux couches plutôt qu'une. Les différences pratiques portent sur la juridiction, sur l'autorisation ou non d'un usage commercial dans l'offre gratuite, et sur ce qui se passe une fois que le Project a aussi besoin d'un véritable backend.
Oui. L'assistant de connexion d'un dépôt Sarpius reconnaît Vite, SvelteKit, Astro, React, Vue, Angular, Hugo, Eleventy, Docusaurus, MkDocs et une sortie statique simple parmi ses 45 frameworks et runtimes détectés automatiquement, et classe chaque Component détectée comme « Servie depuis le stockage (statique) » ou « Conteneurs » avant que tu confirmes le plan. Une Component statique ne démarre jamais de conteneur, est facturée à la taille stockée (EUR 0.025/GB-month) plutôt qu'au trafic, et ses assets de build hachés (la forme app.4f3a9c12.js que Vite, Rollup et webpack produisent tous) reçoivent Cache-Control: public, max-age=31536000, immutable, tandis que tout le reste reçoit no-cache afin qu'un redéploiement soit toujours observé. Les routes de type répertoire se résolvent vers leur propre index.html, donc /blog sert correctement blog/index.html au lieu de revenir à la racine du site.
| Fonctionnalité | Sarpius | Netlify | Cloudflare Pages | Vercel |
|---|---|---|---|---|
| Entreprise / siège | Pays-Bas (KVK 73239038), possède son matériel | États-Unis (San Francisco) | États-Unis (San Francisco) | États-Unis (San Francisco) |
| Comment le build statique est servi | Stockage compatible S3 + edge propre à Sarpius, derrière le réseau de Cloudflare | CDN propre à Netlify | Directement sur le propre réseau mondial de Cloudflare | CDN propre à Vercel (126 PoPs, 19 régions, selon la propre documentation de Vercel) |
| Offre gratuite, usage commercial | Autorisé, indiqué dans les Conditions d'utilisation, section 5 | Aucune restriction explicite trouvée sur la page tarifaire actuelle de Netlify (vérifie avant de t'y fier) | Aucune restriction trouvée sur les pages de documentation/tarifs de Cloudflare Pages vérifiées | Explicitement réservée aux projets personnels et non commerciaux |
| Offre payante la moins chère | EUR 4.99/month par app supplémentaire (côté conteneur ; les Components statiques ne sont facturées qu'au stockage) | Offre « Personal » autour de $9/month, selon la page tarifaire actuelle de Netlify (considère les noms de niveau exacts comme « à vérifier ») | Offre gratuite : 500 builds/month, 100 Projects/account ; niveau « Workers Paid » pour des limites plus élevées | Pro : $20/month par siège |
| Juridiction de l'UE (entreprise, pas seulement centre de données) | Oui, entreprise néerlandaise, sans société mère américaine | Non, entreprise américaine | Non, entreprise américaine | Non, entreprise américaine |
| Conteneur/backend dans le même produit | Oui, first-party (PHP, Node, Python, Java, Go) | Pas de produit de conteneur first-party ; fonctions uniquement | Workers (serverless), pas des conteneurs | Fonctions serverless/edge, pas des conteneurs |
| Base de données managée dans le même produit | Oui : PostgreSQL, Redis, MariaDB | Aucune base de données first-party | D1 (compatible SQLite), KV, R2 | Aucune base de données first-party depuis l'abandon de Vercel Postgres/KV |
| Export Project / bundle de sortie | Bundle de migration Project : fichiers de conteneur, dumps SQL de bases de données, objets de bucket, manifeste de commit, secrets.env via un jeton à usage unique de 5-min derrière 2FA, rétention de 24h | Dépôt git uniquement ; aucune archive automatisée de stack complète | Dépôt git et Cloudflare API/wrangler ; exports distincts pour D1/KV/R2 | Dépôt git uniquement ; exports distincts des bases de données partenaires |
Le propre réseau de Cloudflare s'étend sur 348 villes dans 8 régions, selon le chiffre publié par Cloudflare, et celui de Vercel sur 126 Points of Presence dans 19 régions capables de calcul, selon la propre documentation de Vercel. Aucun de ces chiffres ne dit quelle loi d'entreprise régit tes données : Cloudflare Pages, Netlify et Vercel sont toutes des entreprises américaines, donc la question du CLOUD Act s'applique à la plateforme même lorsqu'un nœud edge précis se trouve par hasard dans une ville de l'UE. Sarpius est une entreprise néerlandaise sans société mère américaine et, pour un domaine où Cloudflare lui-même, comme sous-traitant, est le problème plutôt que l'emplacement du serveur, une « Privacy route » payante par domaine retire entièrement Cloudflare du chemin de requête de ce domaine, pour EUR 4.99/month en plus des EUR 1.99/month de frais de domaine personnalisé existants. Cette option fait perdre le CDN, le WAF et la protection DDoS de Cloudflare pour ce domaine ; c'est un véritable arbitrage, pas une mise à niveau gratuite.
C'est là que les quatre plateformes divergent le plus. Netlify, Cloudflare Pages et Vercel répondent chacune avec des fonctions serverless/edge : à courte durée de vie, limitées à une requête, sans processus de longue durée. Sarpius répond par un conteneur dans le même Project, connecté à une base de données Postgres, Redis ou MariaDB managée ; c'est mieux adapté à un véritable processus backend (une API Laravel, un worker Node, une tâche de longue durée) qu'à une poignée de fonctions sans état. Les propres Serverless Functions de Sarpius, le modèle function-per-request que les trois autres proposent déjà, sont prévues et ne sont pas encore disponibles.
Non. Une Component statique servie depuis le stockage d'objets est facturée aux GB stockés, pas à l'egress ; le bundle de bande passante de 10 GB et le tarif supplémentaire de EUR 0.05/GB s'appliquent aux apps conteneurisées, pas au chemin servi depuis le stockage.
Mécaniquement, oui : un build est téléversé une fois, les assets hachés sont mis en cache comme immuables, tout le reste est revalidé à chaque requête et le site se trouve derrière un CDN. La différence est l'opérateur de ce CDN : Vercel et Netlify exploitent le leur ; Sarpius sert depuis son propre proxy edge placé par défaut derrière le réseau de Cloudflare exploité séparément, avec une option de retrait payante par domaine.
Oui. Un Project est une application composée de plusieurs Components ; l'assistant détecte chacune séparément et place le front-end dans le stockage, le backend dans un conteneur, en partageant le routage, les bases de données et le stockage.
Oui. Les Conditions d'utilisation le disent explicitement à la section 5 : le Free Tier peut être utilisé à toute fin légale, y compris un usage commercial tel qu'un site d'entreprise ou le front-end d'un produit payant.
Oui. Tu peux générer un bundle de migration Project depuis l'espace de travail du Project derrière l'authentification à deux facteurs. Le bundle contient la sortie statique construite, les fichiers du conteneur actif, les dumps SQL de bases de données, les objets de bucket et un manifeste avec les SHA de commit git, des sommes de contrôle sha256 par fichier et des notes d'omission explicites. Les variables d'environnement déchiffrées sont diffusées sous forme de secrets.env au téléchargement avec un jeton unique de 5-min et ne sont jamais stockées dans l'artefact de bundle au repos. Les bundles sont téléchargeables pendant 24 heures et peuvent être créés une fois toutes les 24 heures.