Microsoft 365 Copilot au Canada : résidence vs inférence

Un projet de déploiement de Microsoft 365 Copilot au Canada ne doit jamais se réduire à une question binaire : « les données restent-elles au Canada ? ». Cette formulation masque au moins quatre problématiques distinctes — le lieu de stockage des données au repos, le lieu de traitement d'une requête, ce que l'utilisateur peut réellement retrouver dans son organisation, et l'état d'avancement de vos propres travaux de conformité. Cet article s'adresse aux administrateurs Microsoft 365, aux responsables de la protection des renseignements personnels et aux équipes de gouvernance qui doivent trancher entre déployer maintenant ou attendre.

Résidence des données et inférence : deux notions à ne pas confondre

La façon la plus utile d'évaluer Microsoft 365 Copilot consiste à séparer clairement deux notions : le stockage (« data at rest ») et le traitement (« inference »).

Pour un tenant éligible provisionné au Canada et respectant les conditions produit applicables, Microsoft s'engage à stocker au repos, dans la géographie concernée, certaines catégories de données client — notamment le contenu des interactions Microsoft 365 Copilot conservé, ainsi que l'index sémantique associé. C'est un engagement contractuel réel : il fixe un lieu géographique pour des données précises stockées par le service, plutôt que de laisser cette localisation totalement indéterminée.

Cet engagement ne signifie pas que chaque élément de chaque interaction Copilot est traité exclusivement au Canada. L'inférence est le calcul qui interprète une requête (prompt) et produit une réponse. La documentation actuellement publiée par Microsoft indique que, pour les clients situés hors Union européenne, les requêtes peuvent être traitées aux États-Unis, dans l'UE, ou dans d'autres régions.

Concrètement, une organisation peut affirmer, à juste titre, disposer d'un contenu d'interaction Copilot qualifiant stocké au repos au Canada — si son tenant et son abonnement respectent les conditions applicables. Elle ne devrait pas transformer cette affirmation en garantie que l'inférence se déroule déjà entièrement au pays.

Cette distinction est cruciale pour vos questionnaires fournisseurs. Un champ oui/non « les données restent-elles au Canada » est trop grossier pour produire une réponse défendable. La bonne réponse identifie la catégorie de donnée, la fonctionnalité produit, l'engagement au repos, la position actuelle sur le lieu de traitement, et vos mesures de sauvegarde en cas de transfert.

Le calendrier canadien de l'inférence locale reporté à 2027

En novembre 2025, Microsoft avait initialement placé le Canada dans un groupe de pays visés par une extension prévue en 2026. Une mise à jour ultérieure a modifié ce calendrier : la cible actuellement publiée est un déploiement de l'inférence locale au Canada en 2027.

Cette révision a deux conséquences pratiques :

• Ne bâtissez pas votre dossier de conformité sur une échéance 2026 devenue caduque. Une feuille de route n'est pas un contrôle disponible, et une cible 2027 n'équivaut pas à une date d'implémentation contractuelle pour votre tenant.
• Repousser toute préparation jusqu'à l'arrivée de l'inférence locale peut être contre-productif. Les risques les plus élevés dans la plupart des environnements Microsoft 365 — sur-partage, propriété floue des sites, sites inactifs, documents sensibles à accès large — existent dès aujourd'hui. L'inférence locale ne les résoudra pas.

Il existe un contre-argument raisonnable : lorsqu'une évaluation des risques conclut que le traitement à l'étranger de certaines informations est inacceptable, différer certains cas d'usage jusqu'à l'inférence locale peut être prudent. Le point clé est d'en faire une décision documentée et fondée sur la classification des données, pas une hypothèse implicite.

Loi 25 au Québec et LPRPDE : ce que la conformité exige réellement

Un engagement de service de Microsoft ne suffit pas, à lui seul, à établir qu'une organisation a rempli ses obligations en matière de vie privée. L'organisation doit évaluer ses propres données, ses finalités, son régime juridique, ses fournisseurs et son modèle d'exploitation.

Pour une entreprise privée québécoise qui communique des renseignements personnels hors Québec, la Loi 25 exige une évaluation des facteurs relatifs à la vie privée (EFVP) avant cette communication — y compris lorsqu'un tiers est chargé de traiter l'information. Le transfert doit en outre être encadré par une entente écrite qui reflète cette évaluation et les mesures qu'elle identifie.

Dans un contexte Copilot, cette évaluation ne doit pas s'arrêter à l'étiquette « Microsoft 365 ». Elle devrait identifier, au minimum :

• les renseignements personnels potentiellement présents dans SharePoint, OneDrive, Teams et Exchange ;
• les catégories d'utilisateurs pouvant interroger Copilot sur ce contenu ;
• l'arrangement de stockage au repos applicable au tenant réel ;
• la position documentée sur le lieu de traitement pour la fonctionnalité activée ;
• les mesures techniques et contractuelles pertinentes pour le flux identifié ;
• les restrictions et conditions d'approbation nécessaires pour le contenu à risque élevé.

Au niveau fédéral, la LPRPDE (Loi sur la protection des renseignements personnels et les documents électroniques) n'interdit pas catégoriquement un transfert vers une autre juridiction pour traitement. L'organisation demeure toutefois imputable : elle doit utiliser des moyens contractuels ou autres pour garantir un niveau de protection comparable pendant qu'un tiers traite l'information.

Toutes les organisations ne font pas face exactement à la même analyse : organismes publics québécois, organisations sous réglementation fédérale ou secteurs réglementés peuvent avoir des obligations additionnelles. Une configuration de licences Microsoft 365 ne peut jamais établir qu'une organisation a complété une évaluation requise ou négocié des conditions adéquates. Ce sont des décisions propres à chaque organisation, à valider avec le responsable de la protection des renseignements personnels et les conseillers juridiques.

Copilot amplifie les permissions existantes, il ne les remplace pas

Microsoft 365 Copilot fonctionne dans le cadre des permissions existantes de l'utilisateur : il ne fait remonter que le contenu que l'individu a au minimum la permission de consulter. C'est une frontière de sécurité importante, mais elle ne garantit pas que le résultat produit sera inoffensif.

Le risque pratique majeur est le sur-partage hérité (inherited oversharing). Un fichier à accès large, une équipe Teams avec une adhésion accidentelle, un site SharePoint sans propriétaire, ou un document sensible dans un dossier généralement accessible peuvent avoir été difficiles à découvrir via la navigation classique. Les invites conversationnelles rendent plus facile à localiser et à résumer une information qui était déjà accessible.

Pour les administrateurs, la bonne question n'est pas de savoir si Copilot contourne les permissions. C'est : que pourrait découvrir un employé typique si Copilot rendait interrogeable l'ensemble du matériel qu'il peut déjà consulter ? La réponse révèle souvent une dette d'accès aux données antérieure à l'IA.

Mise en œuvre : un programme de préparation en 5 étapes

Le chemin le plus crédible vers un déploiement défendable est un programme structuré qui réduit l'exposition avant l'activation large, en s'appuyant sur Microsoft Purview et SharePoint Advanced Management pour localiser les sites et fichiers sur-partagés, sans propriétaire, inactifs ou sensibles.

1. Cadrer précisément le périmètre

Documentez quel produit est activé, quels utilisateurs le recevront, quelles sources de données peuvent alimenter les réponses, et confirmez la géographie de provisionnement réelle du tenant. Ne généralisez jamais à partir d'un autre tenant du même groupe corporatif. Cartographiez aussi les connecteurs et agents envisagés : chacun a ses propres conditions de confidentialité.

2. Classifier les données à risque et corriger le sur-partage

Priorisez les dépôts contenant renseignements personnels, dossiers RH, matériel juridique, données financières ou plans sensibles. Le script suivant produit un rapport en lecture seule des sites SharePoint dont la capacité de partage dépasse un seuil acceptable :

1# Module requis : SharePoint Online Management Shell (Microsoft.Online.SharePoint.PowerShell)
2# Installation : Install-Module -Name Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser
3# Permission minimale : rôle SharePoint Administrator (lecture seule pour ce rapport)
4# Sortie : export CSV des sites dont la capacité de partage dépasse le seuil accepté
5 
6Connect-SPOService -Url "https://contoso-admin.sharepoint.com"
7 
8# Récupère tous les sites, hors OneDrive personnels
9$sites = Get-SPOSite -Limit All -IncludePersonalSite $false
10 
11# Filtre les sites dont le partage est ouvert aux utilisateurs externes ou invités
12$sitesARisque = $sites | Where-Object {
13    $_.SharingCapability -eq "ExternalUserAndGuestSharing" -or
14    $_.SharingCapability -eq "ExistingExternalUserSharingOnly"
15}
16 
17$sitesARisque |
18    Select-Object Url, Title, SharingCapability, StorageUsageCurrent, LastContentModifiedDate |
19    Export-Csv -Path ".\rapport-sites-a-risque.csv" -NoTypeInformation -Encoding UTF8
20 
21Write-Host "Rapport généré : $($sitesARisque.Count) site(s) à examiner avant l'activation de Copilot."

Ce script ne modifie rien : il produit un CSV à faire valider par les propriétaires métier. Une fois un site validé pour correction, la capacité de partage peut être resserrée individuellement :

1# Resserre la capacité de partage d'un site spécifique après validation métier
2# À exécuter site par site, jamais en boucle non supervisée sur l'ensemble du tenant
3Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/ProjetFinance" -SharingCapability Disabled

3. Appliquer les contrôles de protection avant le pilote

Configurez les contrôles de sensibilité et de prévention de perte de données (DLP) adaptés aux catégories de données de l'organisation, et testez-les avec de vrais flux de travail — pas seulement dans une console de stratégie. Pour les déploiements québécois, intégrez ces mesures dans l'analyse de l'EFVP et de l'entente écrite : elles constituent la preuve de la protection adéquate visée, pas de simples cases à cocher.

4. Piloter avec des groupes délimités

Commencez avec un groupe dont l'accès aux données est compris et dont les bénéfices peuvent être mesurés. Définissez scénarios autorisés, catégories exclues, voies d'escalade, et qui peut ajuster les permissions si le pilote révèle un sur-partage. Un pilote réussi produit des constats sur l'exposition des données et l'efficacité des politiques — pas seulement des gains de productivité anecdotiques.

5. Surveiller et réévaluer en continu

Utilisez les alertes de risque et les rapports de gouvernance disponibles pour repérer les problèmes émergents, et réexaminez chaque nouvelle fonctionnalité, agent ou connecteur avant activation. Ce travail reste nécessaire après l'arrivée de l'inférence locale canadienne : un changement de lieu de traitement améliore une posture géographique, il ne corrige pas un accès excessif ni ne remplace une EFVP à jour.

Dépannage : erreurs courantes

• Confondre résidence au repos et inférence locale : vérifiez la documentation de résidence actuellement publiée pour votre tenant plutôt qu'une communication marketing générale.
• Répondre « oui » à un questionnaire fournisseur sans préciser la catégorie de donnée : détaillez systématiquement stockage, traitement et périmètre.
• Activer Copilot avant un rapport de sur-partage à jour : si Get-SPOSite retourne un nombre élevé de sites en partage externe sans propriétaire actif, retardez l'activation pour ce périmètre.
• Traiter l'EFVP comme un document ponctuel : révisez-la à chaque changement significatif (nouvel agent, nouveau connecteur, changement de géographie d'inférence).
• Oublier l'entente écrite exigée par la Loi 25 : une évaluation sans entente formalisant les mesures identifiées n'est pas complète.

Ce qu'il faut retenir avant le déploiement

Le choix n'est pas simplement « déployer maintenant » contre « attendre 2027 ». La plupart des organisations peuvent suivre une voie intermédiaire : corriger le contenu, compléter l'évaluation juridique, appliquer des contrôles, et piloter des cas d'usage à risque plus faible tout en excluant les scénarios qui ne répondent pas à leur seuil de risque sous le modèle de traitement actuel.

La discipline centrale, c'est la précision : décrivez la résidence canadienne au repos comme une résidence au repos, pas comme une garantie d'inférence locale. Traitez les permissions comme la porte d'entrée qu'utilise Copilot, mais adressez le sur-partage comme un véritable multiplicateur d'exposition.

Concrètement, cette semaine : lancez le rapport de sur-partage SharePoint ci-dessus, faites valider par votre responsable de la protection des renseignements personnels la liste des points à couvrir dans l'EFVP, et fixez une date de revue pour le calendrier d'inférence locale — sans en faire une condition bloquante pour l'ensemble du programme de préparation.