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 Quebec, 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 (art. 3.3 + art. 17)#

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

L'EFVP 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 est permise si l'évaluation démontre que le renseignement bénéficierait d'une protection équivalente.

Le test d'équivalence#

« Équivalente » ne signifie pas identique. La CAI a indiqué qu'il faut évaluer globalement si :

• Les droits individuels (accès, rectification, retrait) sont garantis.
• Un organisme de surveillance indépendant existe.
• Des recours effectifs existent.
• Les transferts subséquents sont encadrés.

Pays à protection généralement équivalente#

• Autres provinces canadiennes : oui pour l'Alberta et la Colombie-Britannique (régimes provinciaux reconnus substantiellement similaires à la LPRPDE). À évaluer pour les autres provinces sous PIPEDA.
• Union européenne : oui (RGPD est globalement plus strict).
• Royaume-Uni : oui (UK GDPR).

Pays à protection non-équivalente#

• États-Unis : non, globalement. 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) expose les données au-delà des normes québécoises.
• Autres juridictions : à évaluer au cas par cas.

Pour un transfert vers un pays sans protection équivalente, la communication est néanmoins permise si des mesures contractuelles suffisantes compensent l'écart. 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 Hilo Tech, 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. Mais conclusion typique = autorisé avec conditions (DPA + MFA + journalisation). Modèle réutilisable pour tous les clients Hilo Tech.

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. Conclusion typique = autorisé pour usages non sensibles uniquement; non autorisé pour données de santé ou de mineurs sauf mesures renforcées. Alternative : plateforme IA privée (voir HiloIntelligence).

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é.

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#

• Le régime de l'Ontario (LPRPDE provinciale de facto) est-il considéré équivalent 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 d'équivalence? Comment documenter le risque résiduel?