VPS au Canada : que faut-il vraiment vérifier ?

Votre VPS doit-il être situé au Canada ?

Un hébergement VPS au Canada est pertinent lorsqu’une loi ou un contrat impose que les données restent sur le territoire canadien. C’est la seule raison impérative. Un aller-retour entre une connexion résidentielle à Toronto et un data centre de New York prend environ 18 ms, contre environ 3 ms vers un data centre de Toronto. Presque aucune application web ne peut faire la différence.

Trois facteurs incitent à choisir un serveur canadien. La résidence des données est une obligation légale. Elle suffit donc à trancher la question. La latence est mesurable et généralement plus faible que prévu. La facturation en dollars canadiens est pratique pour votre comptable. Déterminez d’abord si le premier facteur vous concerne avant d’examiner les autres critères.

Cet article explique le fonctionnement général des règles. Il ne constitue pas un avis juridique. Si une loi sur la protection de la vie privée s’applique à votre organisation, demandez conseil à votre service juridique.

Résidence des données : la seule exigence impérative

La PIPEDA (Personal Information Protection and Electronic Documents Act) est la loi fédérale canadienne sur la protection de la vie privée dans le secteur privé. Elle n’exige pas que les renseignements personnels restent au Canada. Elle considère l’envoi de données à un sous-traitant à l’étranger comme un transfert aux fins de traitement : votre organisation reste responsable des données, le sous-traitant doit leur assurer une protection comparable et vous devez informer clairement les personnes concernées de cette pratique. L’Office of the Privacy Commissioner a consulté les parties prenantes sur un éventuel renforcement de cette règle en 2019, puis a maintenu sa position. L’affirmation courante selon laquelle la PIPEDA impose que vos données restent au Canada est donc fausse, même si de nombreux contenus marketing d’hébergeurs la répètent.

De véritables règles de résidence existent. Elles s’appliquent dans des domaines plus précis.

• La Loi 25 du Québec impose une évaluation avant l’envoi de renseignements personnels hors de la province. Les renseignements doivent aussi bénéficier d’une protection adéquate dans le lieu de destination. Cette disposition est en vigueur depuis septembre 2023. Il s’agit d’une formalité et d’une décision que vous devez pouvoir justifier, pas d’une interdiction.
• Les règles du secteur public s’imposent aux organismes publics et aux entreprises qui les servent. La PIIDPA de la Nouvelle-Écosse limite le stockage de renseignements personnels hors du Canada. La FIPPA de la Colombie-Britannique comportait une règle similaire jusqu’à sa modification en 2021, qui autorise désormais le stockage à l’étranger après une évaluation.
• Les activités du gouvernement fédéral suivent les directives cloud du gouvernement du Canada. Celles-ci exigent que les données de niveau Protected B et supérieur restent au Canada.
• Les lois provinciales sur la protection des renseignements de santé ajoutent leurs propres conditions concernant le lieu de stockage des dossiers médicaux. Ces conditions diffèrent d’une province à l’autre.
• En pratique, les contrats clients et les appels d’offres publics sont le facteur le plus courant. Un questionnaire de sécurité qui indique « données au repos au Canada » vous engage aussi fermement qu’une loi, puisque vous l’avez signé.

Le test pratique est simple. Pouvez-vous citer la clause concernée ? Si personne dans votre organisation ne peut nommer la loi ou le contrat qui impose le Canada, votre choix repose alors sur la latence et le prix.

Un centre de données canadien est-il hors de portée de la justice américaine ?

Pas à lui seul. Le US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) couvre les données en la possession, sous la garde ou sous le contrôle d’un fournisseur américain, quel que soit l’emplacement du matériel. Une région de Toronto exploitée par une entreprise américaine entre donc dans son champ d’application. Si l’exigence réelle concerne les procédures judiciaires étrangères plutôt que la géographie, les éléments importants sont l’opérateur du service et le détenteur des clés de chiffrement. Une adresse canadienne sur le bâtiment ne suffit pas à répondre à cette question.

Le routage est la deuxième surprise. Le trafic entre deux villes canadiennes passe souvent par les États-Unis, car c’est là que le peering bon marché s’est historiquement concentré. Les chercheurs parlent de routage en boomerang. Exécutez un traceroute avant d’affirmer à qui que ce soit que vos paquets ne quittent jamais le pays.

traceroute vps.example.com

Les noms des hops contiennent des codes de ville tels que nyc, chi ou ash. Ces noms donnent des indications et deviennent obsolètes. Considérez-les donc comme une raison de questionner votre fournisseur, et non comme une preuve. Pour les données en transit, la réponse fiable est un chiffrement que vous contrôlez, et non une carte. Si vous voulez un chemin privé entre vos propres machines, un VPN WireGuard auto-hébergé vous en fournit un qui ne dépend pas du pays traversé par la fibre.

Latence : mesurez-la, ne la supposez pas

La lumière parcourt environ 200 km par milliseconde dans une fibre. Ainsi, chaque distance de 100 km ajoute environ 1 ms d’aller-retour, avant même l’intervention des équipements. Toronto et Vancouver sont distantes d’environ 3,400 km à vol d’oiseau, et davantage par câble, ce qui place le minimum autour de 40 ms. Les chemins réels donnent des valeurs plus élevées.

[
  {
    "label": "Toronto",
    "rtt_ms": 3
  },
  {
    "label": "Montreal",
    "rtt_ms": 12
  },
  {
    "label": "New York",
    "rtt_ms": 18
  },
  {
    "label": "Chicago",
    "rtt_ms": 24
  },
  {
    "label": "Northern Virginia",
    "rtt_ms": 26
  },
  {
    "label": "Dallas",
    "rtt_ms": 42
  },
  {
    "label": "Vancouver",
    "rtt_ms": 62
  },
  {
    "label": "London",
    "rtt_ms": 88
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 98
  }
]

Il s’agit de valeurs typiques publiées pour une ligne grand public bien connectée à Toronto. Elles servent de point de départ, pas de garantie. Vos propres valeurs dépendent de votre réseau d’accès et du peering de votre fournisseur. Elles varient aussi selon l’heure de la journée.

Deux lignes méritent une seconde lecture. Toronto–Montréal est d’environ 12 ms. La latence est suffisamment faible pour que les deux villes se comportent comme une seule région dans la plupart des cas. Toronto–Vancouver est d’environ 62 ms, soit davantage que Toronto–Northern Virginia, à 26 ms. Être au Canada ne signifie pas être proche de vos utilisateurs.

Le dernier kilomètre domine généralement le résultat. La fibre à domicile ajoute quelques millisecondes. Le câble en ajoute davantage lorsque la ligne est chargée. Une connexion mobile ajoute à elle seule plusieurs dizaines de millisecondes. Un utilisateur mobile à Toronto peut obtenir 50 ms vers un serveur situé à Toronto. Déplacer ce serveur à New York ne modifie alors son expérience que de quelques pour cent.

Comment tester la latence depuis l'emplacement de vos utilisateurs

Commencez par déterminer où se trouvent réellement vos utilisateurs. Vos outils d'analytics répartissent déjà les sessions par ville ou par région. Consultez ces données au lieu de vous baser sur l'emplacement de votre bureau.

Effectuez ensuite les mesures depuis cet emplacement. Vous ne pouvez pas tester la latence vers Vancouver depuis un poste à Ottawa. Louez un VPS à l'heure dans la ville cible pendant vingt minutes, puis détruisez-le. Demandez à un collègue ou à un client d'exécuter une commande. Vous pouvez aussi utiliser le réseau de mesure gratuit RIPE Atlas à l'adresse https://atlas.ripe.net. Il dispose de probes dans des villes canadiennes et vous permet d'exécuter des pings depuis celles-ci.

sudo apt update && sudo apt install -y mtr-tiny traceroute iperf3
ping -c 20 vps.example.com

Lisez les deux dernières lignes.

20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 17.412/18.006/19.882/0.594 ms

avg est la valeur principale. mdev est la gigue, c'est-à-dire la dispersion entre les paquets. Toute perte de paquets sur un chemin court indique un problème à examiner. Une forte gigue perturbe davantage la voix et les jeux vidéo qu'une moyenne légèrement plus élevée, car le récepteur doit mettre en buffer le paquet le plus lent plutôt que le paquet habituel.

mtr --report --report-cycles 50 vps.example.com

mtr affiche la perte pour chaque hop. S'il se termine par une erreur de permission, exécutez-le avec sudo. Les hops intermédiaires affichent régulièrement une perte qui n'est pas réelle, car les routeurs donnent la priorité la plus faible aux réponses ICMP qu'ils génèrent eux-mêmes. Seule une perte qui continue jusqu'à la dernière ligne affecte réellement votre trafic. Lisez d'abord la dernière ligne, puis remontez.

Lorsque ICMP est bloqué ou limité en débit, mesurez directement le protocole utilisé.

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://vps.example.com/

Chaque champ indique un nombre de secondes cumulées depuis le début de la requête. connect moins dns correspond à un aller-retour TCP. tls moins connect correspond à la négociation. ttfb moins tls correspond à un aller-retour supplémentaire, auquel s'ajoute le temps mis par votre application pour répondre. C'est dans ce dernier intervalle que les sites lents perdent généralement le plus de temps. Un ttfb de 0.8 s sur un chemin court indique un problème applicatif. Déplacer le serveur dans une autre ville ne changera rien.

Pour mesurer le débit, exécutez le serveur sur le VPS et le client depuis l'emplacement de l'utilisateur. iperf3 écoute sur TCP 5201. Ouvrez le port avec ufw pour le test, puis refermez-le une fois terminé.

iperf3 -s

iperf3 -c vps.example.com -t 20
iperf3 -c vps.example.com -t 20 -R
iperf3 -c vps.example.com -t 20 -P 8

-R inverse le sens. Vous mesurez ainsi le download aussi bien que l'upload. -P 8 ouvre huit flux parallèles. Si huit flux sont beaucoup plus rapides qu'un seul, la limite vient de la fenêtre TCP sur un chemin long, et non de la liaison elle-même. Un flux unique ne peut transporter qu'une seule fenêtre par aller-retour. Avec la même fenêtre, le chemin vers Vancouver transporte environ un tiers de données par seconde par rapport au chemin vers New York. Les sauvegardes sur longue distance se comportent de la même façon. C'est pourquoi les sauvegardes hors site avec restic semblent lentes vers une cible distante, même sur une liaison rapide.

Laissez un ping s'exécuter dans un deuxième terminal pendant que iperf3 fonctionne. Si l'aller-retour passe de 20 ms à 300 ms pendant le transfert, cela indique un bufferbloat dans votre propre équipement d'accès. Aucun emplacement de data centre ne peut corriger ce problème.

Effectuez plusieurs mesures, notamment le soir. La congestion à 9pm correspond à la situation réelle de vos utilisateurs. La valeur de 4am est celle qu'une page commerciale préférerait citer.

Ce que le temps aller-retour signifie pour votre charge de travail

Le chargement initial d’une page effectue quatre allers-retours avant que le navigateur puisse afficher quoi que ce soit.

[
  {
    "label": "DNS lookup",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TCP handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TLS 1.3 handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "Request and first byte",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "All four round trips",
    "toronto_to_new_york_ms": 72,
    "toronto_to_vancouver_ms": 248
  }
]

La recherche DNS s’effectue auprès d’un resolver, et non auprès de votre serveur. Elle est généralement mise en cache. Une visite suivante l’ignore donc. Mesuré de bout en bout, un chargement initial accuse un retard de 72 ms sur le chemin vers New York et de 248 ms sur celui vers Vancouver. Ces deux valeurs sont négligeables face à une seule requête de base de données de 400 ms. Une fois la connexion ouverte, HTTP/2 et HTTP/3 transportent simultanément de nombreuses requêtes sur cette connexion. Ce coût n’est donc payé qu’une fois, et non pour chaque fichier. Placez les ressources statiques sur un CDN (content delivery network). La ville où se trouve l’origine n’a alors plus d’importance pour ces ressources. C’est pourquoi un visiteur européen ayant 98 ms de latence vers Toronto peut tout de même obtenir une page rapide.

Les jeux multijoueurs en temps réel sont le cas opposé, car le temps aller-retour constitue l’expérience. En dessous d’environ 50 ms, un jeu d’action rapide semble instantané. Les joueurs commencent à remarquer la latence vers 80 ms. Au-delà de 120 ms, ils accusent le serveur. Dans ce cas, la région détermine réellement la qualité du produit. Les serveurs de jeux plus lents sont beaucoup plus tolérants. Ainsi, exécuter un serveur Minecraft sur un VPS permet de supporter des distances qui ruineraient un jeu de tir.

Les bases de données sont le domaine où le choix de la région peut causer les problèmes les plus importants. Ne placez jamais l’application dans une région et sa base de données dans une autre. Chaque requête est un aller-retour. Une page qui effectue 40 requêtes en paie 40 : à 18 ms chacune, cela représente presque une seconde. À 62 ms chacune, cela dépasse deux secondes, alors que la même page mesurait 30 ms avec la base de données sur le même serveur. La réplication asynchrone vers une autre région convient aux réplicas en lecture et à la reprise après sinistre. Un commit synchrone sur un chemin long ajoute ce délai à chaque écriture.

Les sessions interactives se situent entre les deux. SSH reste confortable jusqu’à environ 100 ms, puis devient lent, car chaque frappe attend le retour de son écho. mosh effectue des prédictions localement et masque la majeure partie de cette latence. Les webhooks et les API internes doivent toujours se trouver dans la même région que le service qu’ils appellent.

Facturation, devise et taxes

Payer en dollars canadiens évite les frais de transaction à l’étranger facturés par l’émetteur de votre carte, généralement d’environ 2.5% en août 2026, et vous permet de tenir votre comptabilité dans une seule devise. Un fournisseur canadien facture la GST ou la HST, qu’une entreprise enregistrée peut récupérer sous forme de crédit de taxe sur les intrants. C’est une question financière, qui appelle une réponse financière. Elle ne doit jamais déterminer où les paquets sont acheminés. Pour connaître le coût réel d’un serveur et comparer les offres sans subir le tarif de renouvellement, consultez le coût mensuel réel d’un VPS.

Ce qu’un marché plus petit vous coûte

Le marché canadien de l’hébergement est petit par rapport aux États-Unis. Des conseils honnêtes doivent aussi préciser ce que vous perdez.

• Moins de fournisseurs se disputent votre budget. Le prix par gigaoctet de RAM ou de disque est donc généralement plus élevé pour une machine de même catégorie.
• La capacité se concentre à Toronto et à Montréal, avec une présence moindre à Vancouver et à Calgary. Une deuxième région canadienne pour le failover implique souvent un long chemin réseau, ou un hébergement hors du pays malgré tout.
• Un petit hébergeur régional peut exploiter un seul bâtiment relié à un ou deux opérateurs upstream. Demandez combien il y en a et ce qui se passe lorsque l’un d’eux tombe en panne.
• Le choix de matériel est plus limité. Les grandes instances et les machines GPU sont plus faciles à trouver dans les régions américaines. Il est donc possible qu’un GPU VPS n’existe pas dans la taille souhaitée et dans la ville souhaitée.
• La couverture du support chez un petit hébergeur est une question concrète, pas une question marketing. Demandez à quels moments un humain est disponible.

Montréal fait exception en matière de prix. L’hydroélectricité du Québec est peu coûteuse et les hivers réduisent les coûts de refroidissement. La région de Montréal offre donc une capacité importante à des tarifs concurrentiels avec ceux des régions américaines. Si votre exigence est le Canada plutôt qu’une ville précise, commencez par là.

Si les offres de VPS canadiennes semblent trop limitées pour la charge de travail, comparez un VPS avec un serveur dédié avant de conclure que le problème vient du pays.

Quand l’hébergement VPS au Canada est le bon choix

1. Une loi, un contrat ou une politique du secteur public désigne le Canada. Hébergez au Canada. Le reste de cet article ne s’applique pas, et vous devez également obtenir par écrit du fournisseur son engagement concernant la résidence des données.
2. Vos utilisateurs se trouvent dans une même agglomération canadienne et la charge de travail dépend de la latence : jeux multijoueurs, voix, bureaux distants ou trading. Hébergez dans la ville la plus proche et mesurez les deux options avant de vous engager.
3. Vos utilisateurs sont répartis dans tout le pays. Toronto ou Montréal couvre la plus grande part de la population, et un CDN placé devant les ressources statiques apporte davantage à un visiteur de Vancouver que le déplacement de l’origine.
4. Dans tous les autres cas, qui représentent la plupart des situations. Choisissez en fonction du prix et du matériel réellement fourni, puis vérifiez la qualité du support à 2am. Effectuez d’abord un benchmark du candidat, car deux offres présentant la même fiche technique n’ont pas les mêmes performances : comment effectuer correctement un benchmark d’un VPS.

Quelle que soit votre décision, notez-en la raison à côté. La personne qui demandera ensuite si ce système doit être hébergé au Canada mérite mieux qu’une supposition. Si la réponse reposait un jour sur une clause contractuelle, quelqu’un devra pouvoir la retrouver. Une fois le serveur en place, les dix premières minutes sur un nouveau VPS comptent davantage pour votre sécurité que sa ville.

FAQ

Le PIPEDA exige-t-il que mes données restent au Canada ?

Non. La PIPEDA (Loi sur la protection des renseignements personnels et les documents électroniques) n’impose aucune règle de résidence des données au secteur privé. Envoyer des renseignements personnels à un sous-traitant dans un autre pays constitue un transfert aux fins de traitement : votre organisation reste responsable des données, le sous-traitant doit les protéger de manière comparable et vous devez informer clairement les personnes concernées que ce transfert a lieu. Le Commissariat à la protection de la vie privée a consulté les parties prenantes sur une modification de cette position en 2019, puis l’a maintenue. Les exigences de résidence proviennent d’autres sources : l’évaluation exigée par la Loi 25 du Québec, des lois du secteur public comme la PIIDPA de la Nouvelle-Écosse, les directives du gouvernement du Canada sur le cloud ou une clause de votre propre contrat client.

Les utilisateurs canadiens remarqueront-ils un serveur situé aux États-Unis ?

Pour une application web classique, non. Un aller-retour entre Toronto et New York prend environ 18 ms, et un aller-retour vers le nord de la Virginie environ 26 ms. Ces temps sont tous deux inférieurs à celui entre Toronto et Vancouver, qui est de 62 ms. Les utilisateurs remarquent le temps de réponse du serveur et le poids des pages bien avant de remarquer 20 ms de latence réseau. En revanche, ils le remarquent dans les jeux en temps réel, les appels vocaux et toute situation où une personne réagit à une autre.

Un centre de données canadien échappe-t-il à la législation américaine ?

Pas automatiquement. Le US CLOUD Act s’applique aux données détenues, conservées ou contrôlées par un fournisseur américain, quel que soit l’emplacement du serveur. Une région canadienne exploitée par une entreprise américaine reste donc couverte. Si la procédure judiciaire étrangère est votre véritable préoccupation, examinez qui exploite le service et qui détient les clés de chiffrement, plutôt que l’adresse du bâtiment. Le chiffrement avec des clés que vous détenez vous-même limite les données qu’un fournisseur peut remettre.

Comment mesurer la latence depuis une ville où je n’habite pas ?

Louez un VPS à l’heure dans cette ville, exécutez ping -c 20 et mtr --report --report-cycles 50 vers votre propre serveur, puis détruisez le VPS. Le réseau RIPE Atlas est une solution gratuite, avec des sondes dans des villes canadiennes. Si ICMP est bloqué, mesurez plutôt la requête réelle avec curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/. Cette commande indique l’aller-retour TCP ainsi que le temps total jusqu’au premier octet.