Vercel : le risque de juridiction pour les Canadiens

Vous êtes un développeur canadien qui bâtit avec Next.js. Vous avez des routes API qui gèrent des données utilisateur, des composants serveur qui affichent du contenu personnalisé, peut-être une connexion ou deux à une base de données. Vercel rend le déploiement de tout cela sans effort. Mais il y a une question que votre équipe de conformité, vos clients ou votre propre instinct pourrait finir par soulever : où vivent ces données, et quelle loi les gouverne?

Next.js ne nécessite pas Vercel

Vercel a créé Next.js, et Next.js est excellent. Mais les deux sont séparables. Next.js offre un mode de sortie autonome conçu spécifiquement pour l'auto-hébergement. Configurez output: "standalone" dans votre next.config.js et Next.js produit un dossier autonome avec un serveur Node.js minimal et uniquement les node_modules que votre application importe réellement. Pas d'arbre de dépendances complet, pas de surcharge.

Cette sortie autonome s'intègre parfaitement dans un build Docker multi-étapes. Le schéma standard comprend trois étapes : installer les dépendances, construire l'application, copier la sortie autonome dans une image d'exécution minimale. L'image Docker résultante fait généralement moins de 200 Mo, contre plus de 2 Go avec un build naïf. Elle fonctionne partout où Docker fonctionne : n'importe quel serveur virtuel privé, n'importe quel cluster Kubernetes, n'importe quel PaaS qui prend en charge les conteneurs.

Vous perdez certaines commodités Vercel (analytique, Edge Config, intergiciel en périphérie), mais vous gagnez le contrôle sur l'endroit où votre code s'exécute et quelle juridiction couvre vos données. Pour les équipes qui n'utilisent Vercel que pour les déploiements, la transition est directe. Pour les équipes plus ancrées dans l'écosystème Vercel, ça demande plus d'effort, mais ce n'est pas une réécriture.

La région de Montréal ne résout pas le problème de juridiction

Vercel offre maintenant une région Montréal (yul1) (en anglais) pour les fonctions serverless, ce qui aide avec la latence. Mais une région de calcul canadienne n'est pas une juridiction canadienne. Vercel est une entreprise américaine dont le siège est à San Francisco (en anglais) assujettie au CLOUD Act, peu importe la région sélectionnée. Vos routes API et composants serveur gèrent de vraies données, et ces données sont gouvernées par la loi américaine.

L'infrastructure de Vercel fonctionne sur AWS (en anglais). La région par défaut (en anglais) pour les nouvelles fonctions est Washington, D.C. (iad1). Vous pouvez la changer pour Montréal, mais la plateforme elle-même, les données de votre compte, les métadonnées de vos déploiements, vos journaux, tout cela passe par les systèmes de Vercel basés aux États-Unis. Choisir une région de calcul canadienne change l'endroit où votre fonction s'exécute. Cela ne change pas quel pays peut contraindre Vercel à remettre vos données.

Si votre préoccupation est uniquement la latence, la région Montréal de Vercel résout cela. Si votre préoccupation est le cadre juridique qui gouverne vos données, elle ne le résout pas.

Qui devrait s'en soucier

Les cas évidents sont les industries réglementées. Un SaaS de santé qui traite des formulaires d'admission de patients doit savoir que ces données restent sous juridiction canadienne, pas seulement sous latence canadienne. Une plateforme de documents juridiques où des avocats téléversent des dossiers ne peut pas se permettre l'ambiguïté sur le pays dont les tribunaux peuvent accéder à ces documents. Une jeune pousse en technologie financière qui gère des documents KYC et des enregistrements de transactions a des exigences de conformité qui vont au-delà de « nous avons choisi une région canadienne ».

Mais la conformité n'est pas le seul facteur. Considérez un outil d'analytique B2B qui ingère des données clients pour générer des rapports. L'outil lui-même n'est pas réglementé, mais les clients le sont. Quand un prospect entreprise envoie un questionnaire de sécurité demandant où leurs données sont stockées et quelle juridiction les gouverne, « entreprise américaine, infrastructure AWS » est une réponse factuelle qui pourrait vous coûter le contrat.

Les fournisseurs gouvernementaux font face à cela directement. L'approvisionnement fédéral et provincial exige de plus en plus la résidence des données au Canada, ce qui signifie une juridiction canadienne, pas une entreprise américaine avec une option de région canadienne.

Les sites marketing statiques sans données utilisateur? Vercel fonctionne bien. Mais dès que vous ajoutez des routes API, des soumissions de formulaires ou une base de données, vous faites un choix de juridiction, que vous vous en rendiez compte ou non.

La tarification de Vercel s'accumule

Le forfait Pro de Vercel (en anglais) commence à 20 $ US par utilisateur par mois. Ce prix de base comprend un membre déployeur et un crédit d'utilisation de 20 $. Chaque membre supplémentaire pouvant déployer coûte 20 $ de plus par mois. Les sièges observateurs sont gratuits, mais toute personne qui doit déclencher un déploiement ou gérer les paramètres paie.

Le modèle d'utilisation s'ajoute par-dessus. Le forfait Pro inclut 1 To de transfert de données par mois. Au-delà, les frais de dépassement Fast Data Transfer varient de 0,15 $ à 0,35 $ par Go selon la région (en anglais). Le calcul serverless (Vercel l'appelle Fluid Compute (en anglais)) est facturé selon trois dimensions : temps CPU actif, mémoire provisionnée et invocations, avec dépassement à l'utilisation au-delà du crédit de 20 $. L'optimisation d'images, l'analytique et les produits de stockage ont chacun leurs propres niveaux d'utilisation et tarifs de dépassement.

Pour un développeur solo avec un seul projet, le forfait Pro de Vercel est raisonnable. Pour une équipe de cinq déployant plusieurs projets, les coûts par siège seuls atteignent 100 $ US par mois avant tout frais d'utilisation. Ajoutez des dépassements de bande passante lors d'un pic de trafic, une utilisation plus intensive des fonctions serverless ou quelques produits de stockage, et la facture mensuelle devient difficile à prévoir.

MapleDeploy utilise une tarification forfaitaire. Le forfait Starter est de 45 $ CAD par mois pour une machine virtuelle (VM) dédiée avec 4 Go de RAM, 2 vCPU et 35 Go de stockage. Déployez autant d'applications Next.js, de backends et de bases de données que vos ressources le permettent. Pas de frais par siège, pas de dépassements de bande passante, pas de facturation à l'exécution serverless. Votre facture est la même chaque mois, peu importe le trafic ou la taille de l'équipe.

Ce que vous perdez

Être honnête sur les compromis est important. Vercel a de véritables avantages qui n'ont pas d'équivalent direct sur une plateforme auto-hébergée.

Le réseau périphérique de Vercel livre des ressources statiques depuis des emplacements à travers le monde. Sur MapleDeploy, votre application est servie depuis une VM dédiée à Toronto. Pour un public canadien et nord-américain, c'est rapide et vos données restent sous juridiction canadienne. Pour une application grand public mondiale, placez Bunny.net ou Cloudflare devant votre VM et vous obtenez une diffusion en périphérie avec une origine canadienne.

Vercel Analytics et Speed Insights fournissent un suivi des utilisateurs réels lié directement à vos déploiements. Des alternatives auto-hébergées existent (Plausible, Umami, PostHog), mais vous les configurez vous-même. Edge Config est pratique pour les indicateurs de fonctionnalités. Pour les données de session ou la mise en cache, la place de marché de Vercel offre des intégrations Redis via Upstash. Sur Coolify, vous déploieriez Redis ou un service équivalent.

Les déploiements d'aperçu de Vercel pour chaque demande de tirage sont bien rodés. Coolify offre la même chose : chaque demande de tirage obtient sa propre URL d'aperçu, avec nettoyage automatique à la fermeture de la demande, gérée depuis le tableau de bord Coolify.

Aucun de ces éléments n'est rédhibitoire. Ce sont des commodités. La question est de savoir si ces commodités justifient la juridiction américaine sur vos données.

À quoi ressemble une migration concrète

Si vous décidez de migrer, le processus est plus mécanique qu'architectural. Le code de votre application change à peine.

Commencez par votre next.config.js. Ajoutez output: "standalone" si ce n'est pas déjà fait. Lancez un build localement et vérifiez que le répertoire .next/standalone est produit. Si votre application se compile avec succès en mode autonome, elle fonctionnera sur n'importe quel hôte Node.js.

Ensuite, écrivez un Dockerfile. Next.js fournit un exemple officiel dans son dépôt. Le schéma est direct : installer les dépendances, construire l'application, copier la sortie autonome et les ressources statiques dans une image finale légère. Un Dockerfile fonctionnel fait généralement moins de 30 lignes.

Transférez vos variables d'environnement. Sur Vercel, elles vivent dans le tableau de bord des paramètres du projet. Sur Coolify, vous les configurez dans les paramètres de l'application. Mêmes paires clé-valeur, interface différente. Si vous utilisez des variables d'environnement spécifiques à Vercel comme VERCEL_URL, remplacez-les par votre domaine réel.

Pour les bases de données, la migration dépend de ce que vous utilisez. Si votre base de données est déjà externe (Neon, PlanetScale, Supabase), il suffit de mettre à jour la chaîne de connexion pour pointer vers votre nouvelle infrastructure. Si vous utilisez une base de données de la place de marché Vercel (Neon Postgres, Upstash Redis), vous pouvez soit conserver le fournisseur externe et mettre à jour la chaîne de connexion, soit migrer vers une instance PostgreSQL ou Redis auto-hébergée sur Coolify. Coolify prend en charge le déploiement en un clic des deux.

Le DNS est la dernière étape. Pointez votre domaine vers votre nouveau serveur. Si vous utilisiez le SSL automatique de Vercel, Coolify gère automatiquement les certificats Let's Encrypt.

L'ensemble du processus pour une application Next.js typique avec une base de données prend un après-midi. La base de code ne change pas de manière significative. Ce qui change, c'est l'endroit où elle fonctionne et quelle loi la gouverne. Notre guide de démarrage couvre la configuration complète de MapleDeploy, de l'inscription à une application en ligne.

Décider de migrer

Quelles fonctionnalités Vercel utilisez-vous réellement? Si c'est juste les déploiements, les alternatives sont directes. Si vous êtes profondément dans Vercel Analytics, Edge Config et l'intergiciel en périphérie, la migration demande plus d'effort. Avez-vous besoin de performance en périphérie? Pour la plupart des applications B2B, un déploiement à région unique depuis Toronto est assez rapide pour les utilisateurs nord-américains. La périphérie n'a d'importance que pour le trafic consommateur mondial.

Soyez clair sur votre exigence de conformité. « Nous devrions probablement nous en soucier » est différent de « nos contrats l'exigent ». Ce dernier justifie plus d'effort de migration. Mais n'attendez pas qu'une exigence de conformité soit le déclencheur. Certaines équipes migrent parce qu'elles veulent une réponse claire quand un client demande « où sont nos données? ».

Une véritable alternative canadienne nécessite : une juridiction canadienne (pas juste un centre de données canadien), la prise en charge full-stack (composants serveur, routes API, bases de données) et une expérience développeur moderne. MapleDeploy offre tout cela. Consultez notre comparaison complète avec Vercel pour un tableau comparatif.