Transferts hors Québec

L'article 17 de la LPRPSP est l'un des plus impactants pour les PME modernes : toute communication de renseignements personnels hors du Québec exige une évaluation des facteurs relatifs à la vie privée (EFVP) préalable. Cela inclut, en principe, toute utilisation d'un service infonuagique dont les serveurs ne sont pas au Québec, même si le fournisseur est canadien (Ontario, Colombie-Britannique, etc.).

Ce chapitre clarifie quand une EFVP est requise, comment la structurer et comment minimiser la charge administrative.

Qu'est-ce qu'un transfert hors Québec?#

Communication = tout acte qui rend un renseignement accessible à une entité située physiquement hors du territoire québécois. Cela comprend :

• Hébergement sur un serveur hors Québec (Microsoft Azure East US, AWS us-east-1, Google Cloud us-central1).
• Sous-traitance : un fournisseur québécois qui héberge les données sur son propre fournisseur hors Québec.
• Accès à distance : un employé en Ontario qui se connecte au serveur québécois et consulte les données depuis son poste.
• Sauvegarde : un backup envoyé vers un centre de données non-québécois.
• Analytique : envoi de données à Google Analytics, Mixpanel, Hotjar, etc.

Ce qui n'est pas un transfert hors Québec :

• Accès par un employé québécois à un serveur québécois (la donnée ne sort pas du territoire).
• Hébergement dans un centre de données canadien situé au Québec (Azure Canada Est — région située à Québec, GCP Montréal, Datacenter Cologix MTL, etc.).
• Transmission à un sous-traitant québécois qui héberge au Québec, avec engagement contractuel exprès.

L'obligation d'EFVP pour les transferts hors Québec (art. 17)#

Avant de communiquer à l'extérieur du Québec un renseignement personnel, la personne qui exploite une entreprise doit procéder à une évaluation des facteurs relatifs à la vie privée.

Cette obligation découle de l'article 17 de la LPRPSP. Elle est distincte de l'obligation d'EFVP prévue à l'article 3.3, laquelle vise tout projet d'acquisition, de développement ou de refonte d'un système d'information impliquant des renseignements personnels — que ce projet comporte ou non un transfert hors Québec. Un même projet (par exemple l'implantation d'un nouveau SaaS hébergé hors Québec) peut donc déclencher deux EFVP séparées : l'une pour le système lui-même (art. 3.3), l'autre pour le transfert hors Québec qu'il implique (art. 17). Ce chapitre porte sur cette seconde obligation.

L'EFVP requise par l'article 17 doit analyser :

1. La sensibilité du renseignement.
2. La finalité de son utilisation.
3. Les mesures de protection (contractuelles et techniques) qui l'accompagneraient.
4. Le régime juridique applicable dans le pays de destination, notamment les principes de protection des renseignements personnels y étant applicables.

Et l'article 17 ajoute :

La communication peut s'effectuer si l'évaluation démontre que le renseignement bénéficierait d'une protection adéquate, notamment au regard des principes de protection des renseignements personnels généralement reconnus.

Le test de la protection adéquate#

L'article 17 n'exige pas une protection identique ni même « équivalente » à celle du Québec, mais une protection adéquate — c'est le terme retenu par la loi. Cette adéquation s'évalue notamment au regard des « principes de protection des renseignements personnels généralement reconnus ». Le Guide EFVP de la CAI en énumère onze, à titre non exhaustif (inspirés des lignes directrices de l'OCDE, de la LPRPDE et du RGPD) :

• Responsabilité : imputabilité de l'organisation, politiques, personne responsable désignée.
• Détermination des fins : fins légitimes établies avant la collecte.
• Limitation de la collecte : collecte minimale, par des moyens licites.
• Consentement : information adéquate et consentement libre, sauf exception.
• Protection dès la conception et par défaut.
• Limitation de l'utilisation, de la communication et de la conservation.
• Exactitude des renseignements.
• Sécurité : mesures appropriées à la sensibilité, gestion des incidents.
• Transparence : politiques et pratiques accessibles.
• Droits des personnes concernées : accès, rectification.
• Recours : possibilité de contester un refus ou de porter plainte.

Une protection adéquate suppose des garanties juridiques (régime de l'État destinataire) et contractuelles (entente avec le destinataire) qui respectent ces principes, de façon proportionnée à la sensibilité et à la finalité des renseignements. Si l'EFVP conclut à l'absence de protection adéquate, la communication doit être refusée.

Régimes souvent jugés favorables dans l'analyse#

• Autres provinces canadiennes : l'Alberta et la Colombie-Britannique ont des lois du secteur privé (PIPA) que le gouvernement fédéral reconnaît comme « substantiellement similaires » à la LPRPDE — mais cette reconnaissance sert à exempter ces provinces de la LPRPDE; ce n'est pas une équivalence reconnue par la CAI au sens de l'art. 17. Aucune liste officielle de la CAI ne dispense un transfert vers ces provinces d'une EFVP au cas par cas : la parenté de ces lois avec la LPRPSP est un facteur favorable dans l'analyse du régime juridique, pas une présomption automatique. Les autres provinces, couvertes par la LPRPDE fédérale, s'analysent aussi au cas par cas.
• Union européenne : le RGPD offre des garanties globalement comparables, souvent plus strictes — un facteur très favorable dans l'analyse.
• Royaume-Uni : même logique (UK GDPR).

Régimes exigeant généralement des mesures compensatoires#

• États-Unis : le régime sectoriel américain (HIPAA, GLBA, CCPA en Californie) ne couvre pas l'ensemble des renseignements personnels, et l'accès gouvernemental (FISA, CLOUD Act) est un facteur défavorable dans l'analyse du régime juridique.
• Autres juridictions : à évaluer au cas par cas.

Pour un transfert vers un régime jugé insuffisant à lui seul, la communication demeure possible si des mesures contractuelles et techniques suffisantes comblent l'écart et assurent, au final, une protection adéquate. C'est la situation de la majorité des SaaS américains.

Les mesures contractuelles compensatoires#

Un contrat avec le fournisseur doit, au minimum :

• Encadrer la finalité de l'utilisation (le fournisseur ne peut utiliser les données qu'aux fins du contrat).
• Interdire les communications subséquentes sans consentement.
• Prévoir la notification en cas d'incident de confidentialité côté fournisseur.
• Permettre l'audit, ou à défaut exiger des certifications externes (SOC 2, ISO 27001, ISO 27701).
• Prévoir le retour ou la destruction des données à la fin du contrat.
• Clauses de juridiction : rattachement au Québec ou à une juridiction amie.

Microsoft, AWS et Google publient tous des Data Processing Addenda (DPA) contenant des clauses contractuelles types. Pour un transfert Loi 25, il faut vérifier et compléter: la formulation « RGPD only » n'est pas suffisante en soi.

Structure d'une EFVP pour une PME#

Une EFVP n'a pas besoin d'être un document de 80 pages. Pour une PME qui déploie un nouveau SaaS, un rapport de 3 à 5 pages structuré suffit habituellement.

Gabarit d'EFVP, version condensée#

1. Description du traitement : quel service, quel fournisseur, quels renseignements, combien de personnes, pendant combien de temps.
2. Finalité : pourquoi ce transfert est nécessaire. Alternatives canadiennes évaluées.
3. Sensibilité : ordinaires / sensibles / mixte. Justification.
4. Flux de données : schéma simple montrant où les données vont.
5. Régime juridique du destinataire : pays, loi applicable, autorité de surveillance, recours.
6. Mesures techniques : chiffrement au repos, chiffrement en transit, cloisonnement tenant, accès restreint.
7. Mesures contractuelles : référence au DPA signé, clauses spécifiques ajoutées.
8. Risques résiduels : ce qui subsiste malgré les mesures, probabilité, impact.
9. Décision : transfert autorisé / autorisé avec conditions / non autorisé.
10. Revue : date de la prochaine revue (annuelle typique).

Notre rôle côté TI#

Chez HiloTech, nous produisons la partie technique de l'EFVP : architecture du flux de données, configuration du chiffrement, journalisation des accès, vérification des clauses techniques du DPA (résidence, chiffrement, sous-traitants, notifications). L'analyse juridique du régime applicable et la décision finale sont du ressort de l'avocat du client.

Exemples concrets#

Microsoft 365 Canada Central#

• Résidence par défaut : données au repos au Canada (Toronto + Quebec City selon le service).
• Accès : employés Microsoft dans le monde entier peuvent accéder pour support. DPA de Microsoft encadre.
• EFVP requise : oui. Notre équipe documente la partie technique (résidence Canada Central/Est, DPA Microsoft, MFA, journalisation) pour chaque client; la conclusion d'autorisation, avec ou sans conditions, doit être validée par votre avocat pour votre contexte propre — elle peut varier selon les cas d'usage (ex. Copilot).

ChatGPT Enterprise / API OpenAI#

• Résidence : États-Unis. Possibilité de résidence européenne/canadienne sur certains plans.
• Politique d'utilisation : OpenAI s'engage à ne pas entraîner ses modèles sur les données API (par défaut).
• EFVP requise : oui. Des cas similaires concluent souvent que l'usage pour des données non sensibles est plus facilement défendable et que les données de santé ou de mineurs exigent des mesures renforcées — la conclusion pour votre organisation doit être validée par votre avocat au cas par cas. Alternative partielle : la plateforme HiloIntelligence peut être hébergée au Canada, mais son routeur relaie par défaut vers des fournisseurs américains (OpenAI, Anthropic, etc.) — l'analyse de transfert s'applique alors de la même façon, sauf en optant pour des modèles auto-hébergés sur infrastructure canadienne, qui éliminent le transfert.

Serveur internalisé au siège social#

• Résidence : Longueuil, QC.
• EFVP : non requise (pas de transfert hors Québec).
• Cela reste la solution la plus simple sur le plan Loi 25, au détriment de la scalabilité.

Sauvegarde gérée par HiloTech#

• Résidence : centres de données canadiens (Québec et Ontario), certifiés SOC 2 et ISO 27001. Aucune donnée ne franchit la frontière canadienne.
• Protection : règle 3-2-1 avec copie hors-site immuable, chiffrement AES-256.
• EFVP : la copie en Ontario demeure un transfert hors Québec à documenter, mais l'analyse est simplifiée — destination canadienne, garanties techniques et contractuelles fortes, flux limité à la sauvegarde.

Sous-traitance d'un fournisseur québécois hébergé hors Québec#

Cas classique : vous engagez un fournisseur de facturation québécois qui, à son tour, héberge ses serveurs chez un hyperscaler américain. Oui, c'est un transfert hors Québec. Le fournisseur québécois doit déclarer ses dépendances et assumer la responsabilité d'en documenter la conformité.

Liste de contrôle rapide#

• Inventaire des flux de données avec identification de ceux qui sortent du Québec.
• Une EFVP existe pour chaque flux identifié.
• Les DPA des principaux fournisseurs sont signés et archivés.
• Les conditions techniques (chiffrement, MFA, cloisonnement) sont vérifiées annuellement.
• Les alternatives à résidence québécoise ont été évaluées (même rejetées).
• Le responsable RP tient un registre centralisé des EFVP.

Erreurs fréquentes#

• « Notre SaaS est canadien, donc c'est bon. »: Canadien ≠ québécois. Un fournisseur de l'Ontario qui héberge en Ontario constitue un transfert hors Québec. L'analyse reste obligatoire.
• Copier-coller l'analyse RGPD.: Les régimes sont comparables mais pas identiques. La CAI attend un raisonnement calibré sur la Loi 25.
• Ignorer les sous-traitants de fournisseurs.: Microsoft a des sous-traitants. AWS a des sous-traitants. Un DPA sans liste à jour des sous-traitants est incomplet.
• Ne faire qu'une seule EFVP globale.: Chaque finalité distincte, chaque catégorie de données distincte, demande une analyse à part. Une EFVP globale pour « Microsoft 365 » ne couvre pas un nouveau cas d'usage IA intégré par Copilot.

Questions à poser à votre conseiller juridique#

• L'Ontario n'a pas de loi générale du secteur privé reconnue substantiellement similaire à la LPRPDE (seule sa loi sur la santé, la PHIPA, l'est) : c'est donc la LPRPDE fédérale qui s'applique aux activités commerciales en Ontario. Ce régime fédéral offre-t-il une protection adéquate pour nos transferts Québec–Ontario?
• Nos contrats fournisseurs actuels respectent-ils l'article 17, ou des avenants sont-ils nécessaires?
• Quel est le seuil de matérialité en dessous duquel une EFVP allégée suffit?
• Le CLOUD Act américain change-t-il l'analyse du caractère adéquat de la protection? Comment documenter le risque résiduel?