Migrer vers AWS sans violer la Loi 25 du Québec.

AWS reste le cloud public dominant en 2026, y compris au Canada. Beaucoup de PME québécoises veulent profiter de sa richesse fonctionnelle (RDS, Lambda, S3, SageMaker) tout en respectant la Loi 25. Le problème est connu : AWS est une société américaine soumise au Cloud Act, ce qui crée une tension juridique potentielle avec la Loi 25 québécoise.

Faut-il bannir AWS pour autant ? Non. Avec une architecture rigoureuse, vous pouvez utiliser AWS pour la majorité de vos charges tout en restant défendable devant la CAI. Voici comment.

Comprendre l'enjeu juridique précisément

Le Cloud Act de 2018 permet aux autorités fédérales américaines de demander à toute entreprise basée aux États-Unis (donc Amazon, Microsoft, Google) de fournir des données qu'elle détient, indépendamment du pays où ces données sont stockées physiquement.

De son côté, la Loi 25 du Québec exige (article 17) une évaluation préalable avant tout transfert de renseignements personnels hors Québec, et impose des protections "équivalentes" à celles offertes au Québec. Or, le régime américain est régulièrement jugé non équivalent au régime québécois (similaire à la décision Schrems II côté européen).

Résultat : l'utilisation d'AWS pour stocker des renseignements personnels québécois exige une analyse documentée et des mesures techniques compensatoires.

Architecture recommandée : chiffrement client-side

La parade technique la plus solide est le chiffrement côté client avec gestion des clés hors AWS. Le principe : AWS héberge vos données, mais ne dispose jamais des clés de déchiffrement. Même sur réquisition Cloud Act, AWS ne peut fournir que des données chiffrées inexploitables.

Configuration pratique

• S3 : utiliser SSE-C (Server-Side Encryption with Customer-Provided Keys) ou mieux, chiffrer les données avec AWS Encryption SDK avant l'upload
• RDS : chiffrer les colonnes sensibles au niveau application avant insertion (ex : pgcrypto pour PostgreSQL)
• DynamoDB : utiliser DynamoDB Encryption Client pour chiffrer attribut par attribut côté client
• EBS : chiffrement BYOK avec KMS, mais les clés KMS restent gérées par AWS — préférez un HSM externe pour les workloads critiques

Gestion des clés (KMS) : la question critique

Si vous utilisez AWS KMS pour stocker vos clés de chiffrement, vous annulez en grande partie la protection : AWS contrôle les clés. Trois options selon votre niveau d'exigence :

1. KMS avec key policy stricte : suffisant pour usage Loi 25 standard, mais théoriquement contournable sur réquisition US
2. AWS CloudHSM : matériel dédié, clés non extractibles, mais toujours dans le périmètre AWS
3. HSM externe (Thales Luna, Entrust nShield) hébergé chez un opérateur canadien ou en interne : la seule architecture vraiment hors atteinte Cloud Act

Région ca-central-1 : oui mais avec garde-fous

AWS région Montréal est utile pour la latence et certaines exigences contractuelles de résidence des données, mais ne résout PAS l'enjeu Cloud Act. Configurations à appliquer impérativement :

Définir une Service Control Policy (SCP) au niveau de l'organisation AWS qui bloque toute création de ressource hors ca-central-1 :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideCanada",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ca-central-1"
        }
      }
    }
  ]
}

Cette SCP empêche tout employé de créer accidentellement une ressource hors Canada. À compléter par un AWS Config Rule qui audite la conformité régionale en continu.

Logs et données dérivées : le piège oublié

Même avec vos données principales en ca-central-1, plusieurs services AWS génèrent des données dérivées qui peuvent être stockées ailleurs :

• CloudTrail : par défaut, certains événements sont envoyés à us-east-1
• CloudWatch Metrics : agrégation potentielle hors région
• AWS Config : historique de configuration multirégion
• GuardDuty : indicateurs de menace globaux

Configurez explicitement chacun de ces services pour rester dans ca-central-1, et auditez régulièrement.

Évaluation des facteurs Loi 25 (EFVP) : ce qu'il faut documenter

Avant toute migration vers AWS, vous devez produire une EFVP (Évaluation des Facteurs relatifs à la Vie Privée) qui inclut spécifiquement la section "transferts internationaux". Cette section doit contenir :

• Identification précise des données concernées (catégories, volumes, sensibilité)
• Analyse du cadre juridique du destinataire (en l'occurrence, exposition Cloud Act)
• Description détaillée des mesures techniques compensatoires (chiffrement client-side, gestion HSM externe)
• Évaluation du risque résiduel après mesures
• Justification de la nécessité du transfert (pourquoi AWS plutôt qu'un cloud canadien)
• Plan de réversibilité (comment migrer ailleurs si la situation juridique change)

Cas où AWS n'est PAS recommandé

Pour certains profils de données, même une architecture rigoureuse AWS reste risquée. Préférez un cloud canadien ou un hébergement souverain pour :

• Données de santé (DSQ, dossiers médicaux, données génétiques)
• Données du secteur public (organismes gouvernementaux, ministères, municipalités sensibles)
• Données juridiques sensibles (dossiers de cabinets d'avocats traitant d'affaires confidentielles)
• Données financières au sens large pour institutions soumises à supervision AMF
• Renseignements personnels d'enfants (protection renforcée)

Alternatives canadiennes à considérer

Pour les charges sensibles, plusieurs alternatives 100 % canadiennes existent :

Fournisseur	Type	Datacenters
OVHcloud	IaaS / PaaS	Beauharnois (QC)
Sherweb	IaaS / Microsoft 365	Montréal, Toronto
iWeb	Hébergement managé	Montréal
4Degrees Colocation	Colocation	Montréal, Québec
Hopper / Vidéotron Affaires	Cloud hybride	Plusieurs sites QC

Pour les organisations qui veulent garder un contrôle total, notre équipe accompagne aussi le déploiement de datacenters privés sur sol canadien (voir notre service Datacenter).

Architecture hybride : le compromis pragmatique

Pour la plupart des PME québécoises, la meilleure approche est hybride :

• AWS pour les workloads techniques sans renseignements personnels (CDN, traitement d'images, ML training sur données anonymisées, sites publics)
• Cloud canadien ou datacenter privé pour les bases de données contenant des renseignements personnels
• Tunnels chiffrés entre les deux environnements pour les flux nécessaires

Cette architecture vous donne le meilleur des deux mondes : la richesse d'AWS pour l'innovation, la souveraineté canadienne pour les données sensibles.