VPS au Canada : quand est-ce vraiment nécessaire ?

Votre VPS doit-il être hébergé 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 datacenter à New York prend environ 18 ms, contre environ 3 ms vers un datacenter à Toronto. Presque aucune application web ne peut faire la différence.

Trois éléments orientent les utilisateurs vers 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 elle est généralement plus faible que prévu. La facturation en dollars canadiens est pratique pour votre comptable. Vérifiez d’abord si le premier point vous concerne avant de prendre les autres critères en compte.

Cet article explique le fonctionnement général de ces 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 stricte

La LPRPDE (Loi sur la protection des renseignements personnels et les documents électroniques) est la loi fédérale canadienne sur la protection des renseignements personnels 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 fournir une protection 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 un éventuel durcissement de cette règle en 2019, puis a maintenu sa position existante. L’affirmation courante selon laquelle la LPRPDE impose que vos données résident au Canada est donc fausse, même si de nombreux contenus de fournisseurs d’hébergement 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 exige une évaluation avant l’envoi de renseignements personnels à l’extérieur de la province. Les renseignements doivent également bénéficier d’une protection adéquate dans le lieu où ils sont reçus. 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’appliquent aux organismes publics et aux entreprises qui les servent. La PIIDPA de la Nouvelle-Écosse limite le stockage de renseignements personnels à l’extérieur 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 missions du gouvernement fédéral suivent les orientations du gouvernement du Canada en matière de cloud. Elles exigent que les données Protégé B et de niveau 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 varient 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 strictement 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, vous faites alors votre choix en fonction de la latence et du prix.

Un centre de données canadien échappe-t-il à la compétence juridique américaine ?

Pas à lui seul. Le US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) couvre les données qui sont 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 Toronto exploitée par une entreprise américaine entre donc dans son champ d’application. Si le véritable enjeu concerne les procédures judiciaires étrangères plutôt que la géographie, les points déterminants sont l’opérateur du service et le détenteur des clés de chiffrement. Une adresse canadienne sur le bâtiment ne permet pas de répondre à cette question.

Le routage constitue une deuxième surprise. Le trafic entre deux villes canadiennes passe souvent par les États-Unis, car c’est là que se trouvent historiquement les accords de peering les moins coûteux. Les chercheurs parlent de routage en boomerang. Exécutez un traceroute avant d’affirmer 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 fournissent des indices et deviennent obsolètes, alors considérez-les comme une raison de poser la question à votre fournisseur, pas comme une preuve. Pour les données en transit, la réponse fiable est un chiffrement que vous contrôlez, pas une carte. Si vous voulez un chemin privé entre vos propres machines, un VPN WireGuard auto-hébergé vous en fournit un, sans tenir compte du pays traversé par la fibre.

Latence : mesurez-la, ne la supposez pas

La lumière dans une fibre parcourt environ 200 km par milliseconde. Chaque distance de 100 km ajoute donc environ 1 ms d’aller-retour, avant même de prendre en compte les équipements. Toronto et Vancouver sont séparées d’environ 3 400 km à vol d’oiseau, et davantage par câble, ce qui place le minimum autour de 40 ms. Les trajets 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 publiées typiques pour une ligne grand public bien connectée à Toronto. Elles servent de point de départ, pas de garantie. Vos propres mesures 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 attention particulière. Toronto et Montréal affichent environ 12 ms, une latence suffisamment faible pour que les deux villes se comportent comme une seule région dans la plupart des cas. Toronto et Vancouver affichent environ 62 ms, soit davantage que Toronto et 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 mesurer 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’analyse répartissent déjà les sessions par ville ou par région. Consultez ces données au lieu de deviner à partir de l’emplacement de votre bureau.

Mesurez ensuite depuis cet emplacement. Vous ne pouvez pas tester la latence vers Vancouver depuis un bureau à 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, qui possède des probes dans des villes canadiennes et 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 variation entre les paquets. Toute perte de paquets sur un chemin court est un problème qui mérite d’être examiné. Une gigue élevée perturbe davantage la voix et les jeux vidéo qu’une moyenne légèrement supérieure, car le récepteur doit mettre en mémoire tampon les paquets en fonction du paquet le plus lent plutôt que du paquet habituel.

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

mtr affiche la perte pour chaque saut. Si la commande se termine par une erreur de permission, exécutez-la avec sudo. Les sauts intermédiaires affichent régulièrement une perte qui n’est pas réelle, car les routeurs donnent la priorité la plus basse aux réponses ICMP qu’ils génèrent eux-mêmes. Seule une perte qui persiste jusqu’à la dernière ligne affecte réellement votre trafic. Lisez d’abord la ligne du bas, puis remontez.

Lorsque ICMP est bloqué ou limité, 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 écart 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 n’y 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 donc le port avec ufw pour le test, puis refermez-le lorsque vous avez 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 du transfert. Vous mesurez ainsi le téléchargement en plus de l’envoi. -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 des données par seconde du chemin vers New York. Les sauvegardes longue distance se comportent de la même manière. C’est pourquoi les sauvegardes hors site avec restic semblent lentes vers une cible distante, même avec une connexion 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, votre équipement d’accès souffre de bufferbloat. Aucun emplacement de centre de données ne peut corriger ce problème.

Effectuez plusieurs mesures, notamment le soir. La congestion à 21h correspond à la situation réelle de vos utilisateurs. La valeur de 4h est celle qu’une page commerciale préférerait mettre en avant.

Ce que signifie le round-trip time pour votre charge de travail

Le chargement initial d’une page nécessite 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 résolution DNS s’effectue auprès d’un resolver, et non auprès de votre serveur. Elle est généralement mise en cache, donc une visite ultérieure l’ignore. En comptant le temps de bout en bout, un chargement initial accuse 72 ms de retard sur le chemin vers New York et 248 ms sur celui vers Vancouver. Ces deux valeurs deviennent 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 même connexion. Le 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 de l’origin n’a alors plus aucune importance pour ces ressources. C’est pourquoi un visiteur européen avec 98 ms jusqu’à Toronto peut tout de même obtenir une page rapide.

Les jeux multijoueurs en temps réel constituent le cas opposé, car le round trip fait partie de l’expérience. En dessous d’environ 50 ms, le jeu semble immédiat dans un jeu d’action rapide. Les joueurs commencent à remarquer le délai vers 80 ms et, 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 destinés à des jeux plus lents sont beaucoup plus tolérants. C’est pourquoi héberger un serveur Minecraft sur un VPS permet de supporter des distances qui ruineraient un jeu de tir.

C’est avec les bases de données qu’un mauvais choix de région cause 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 correspond à un aller-retour. Une page qui exécute 40 requêtes en paie donc 40 : à 18 ms chacune, cela représente presque une seconde, et à 62 ms chacune, plus de deux secondes. Pourtant, cette page a été mesurée à 30 ms lorsque la base de données se trouvait sur le même serveur. La réplication asynchrone vers une autre région convient aux read replicas et à la reprise après sinistre. Un commit synchrone sur une longue distance ajoute cette distance à chaque écriture.

Les sessions interactives se situent entre ces deux cas. SSH reste confortable jusqu’à environ 100 ms, puis semble lent, car chaque touche attend le retour de son écho. mosh effectue des prédictions localement et masque la majeure partie de ce délai. Les webhooks et les API internes doivent toujours se trouver dans la même région que le service qu’elles 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 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. Il s’agit d’une question financière, qui appelle une réponse financière. Elle ne doit jamais déterminer où circulent les paquets. Pour connaître le coût réel d’un serveur et comparer les offres sans vous laisser surprendre par les tarifs de renouvellement, consultez le coût mensuel réel d’un VPS.

Ce que vous coûte un marché plus petit

Le marché canadien de l’hébergement est petit comparé à celui des États-Unis. Des conseils honnêtes doivent aussi préciser ce à quoi vous renoncez.

• Moins de fournisseurs se disputent votre budget. Le prix par gigaoctet de RAM ou d’espace 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 trajet réseau long, 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 équipées de GPU sont plus faciles à trouver dans les régions américaines. Un VPS GPU peut donc ne pas être disponible 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 un argument marketing. Demandez à quels moments un opérateur est disponible.

Montréal fait exception en matière de prix. L’hydroélectricité du Québec est bon marché et les hivers réduisent les coûts de refroidissement. La région de Montréal dispose donc d’une capacité importante, à des tarifs compétitifs avec ceux des régions américaines. Si votre besoin porte sur le Canada plutôt que sur une ville précise, commencez par là.

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

Quand un 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. Rien d’autre dans cet article ne s’applique, 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 à distance ou trading. Hébergez dans la ville la plus proche et mesurez les deux options avant de signer quoi que ce soit.
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 devant les ressources statiques sera plus utile à un visiteur de Vancouver que le déplacement de l’origine.
4. Tout le reste, c’est-à-dire la plupart des cas. 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 les mêmes spécifications ne fournissent pas les mêmes performances : comment effectuer correctement un benchmark d’un VPS.

Quelle que soit votre décision, notez sa raison à côté. La personne suivante qui demandera si l’hébergement doit être au Canada mérite mieux qu’une supposition, et si la réponse reposait 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 auront plus d’importance pour votre sécurité que sa ville d’hébergement.

FAQ

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

Non. La PIPEDA (Personal Information Protection and Electronic Documents Act) n’impose aucune règle de résidence des données au secteur privé. Envoyer des informations personnelles à un sous-traitant situé dans un autre pays constitue un transfert à des 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 de ce transfert. L’Office of the Privacy Commissioner a consulté les parties prenantes sur une éventuelle modification de cette position en 2019, puis l’a maintenue. Les exigences de résidence proviennent d’autres sources : l’évaluation prévue par la Loi 25 du Québec, des lois applicables au secteur public telles que la PIIDPA de la Nouvelle-Écosse, les orientations du gouvernement du Canada sur le cloud ou une clause de votre propre contrat client.

Les utilisateurs canadiens remarqueront-ils qu’un serveur se trouve aux États-Unis ?

Pour une application web classique, non. Un aller-retour réseau entre Toronto et New York prend environ 18 ms, et environ 26 ms vers le nord de la Virginie. Ces valeurs sont toutes deux inférieures au temps 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 la remarquent dans les jeux en temps réel, les appels vocaux et toutes les situations où une personne réagit à une autre.

Un data centre canadien échappe-t-il à la législation américaine ?

Pas automatiquement. Le CLOUD Act américain s’applique aux données en la possession, sous la garde ou sous le contrôle d’un fournisseur américain, quel que soit l’emplacement du serveur. Une région canadienne exploitée par une entreprise américaine reste donc concernée. Si la procédure juridique é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 ne réside 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. Le réseau RIPE Atlas constitue une alternative gratuite, avec des probes dans des villes canadiennes. Si ICMP est bloqué, mesurez plutôt le temps de la requête réelle avec curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/. Cette commande fournit l’aller-retour TCP ainsi que le temps total jusqu’au premier octet.