Les règles de résidence des données que doivent maintenant respecter les ministères fédéraux pour l'achat d'outils d'IA
Les directives du Conseil du Trésor et le CLOUD Act transforment la façon dont les organisations fédérales évaluent les plateformes d'IA canadiennes. Ce que disent les règles — et ce qu'elles ne disent pas.
Le Guide sur l'utilisation de l'IA générative du Conseil du Trésor demande aux ministères de traiter la résidence des données comme un élément obligatoire de toute évaluation des risques liés à l'IA. Pas une case à cocher en option. Cette consigne redéfinit les conversations d'approvisionnement partout à Ottawa cet automne, forçant les ministères à répondre à une question que plusieurs évitaient jusqu'ici : où vont réellement les données une fois qu'un employé tape une invite. Pour les organisations assujetties aux règles de traitement Protégé B, la réponse détermine si un outil est utilisable, tout simplement.
Le problème du CLOUD Act
Le CLOUD Act américain donne aux forces de l'ordre des États-Unis une voie légale pour exiger des données de toute entreprise soumise à la juridiction américaine, peu importe où se trouvent ses serveurs. Les documents d'un ministère canadien stockés dans un centre de données de Toronto appartenant à un fournisseur dont le siège social est américain demeurent, en principe, accessibles en vertu de cette loi. La juridiction suit la société mère, pas la rangée de serveurs.
Ce fait a tranquillement réorganisé l'approvisionnement fédéral en IA au cours des deux dernières années. Le Commissariat à la protection de la vie privée du Canada a signalé les flux de données transfrontaliers comme une préoccupation récurrente dans ses lignes directrices sur les outils d'IA générative destinés aux organismes publics, et le régulateur québécois est allé plus loin. La Loi 25 exige une évaluation des facteurs relatifs à la vie privée documentée avant tout transfert de renseignements personnels hors de la province — une évaluation qui doit nommer précisément quelles juridictions sont concernées par les données. Un ministère incapable de répondre à cette question par écrit a un problème d'approvisionnement avant même d'avoir un problème technologique.
Rien de tout cela ne disqualifie automatiquement chaque fournisseur d'IA américain des contrats fédéraux. Ce qui a changé, c'est le fardeau de la preuve. Un fournisseur doit maintenant démontrer, concrètement, quels flux existent et quelle loi les régit — et un nombre surprenant d'entre eux en sont incapables.
Les mécanismes de ce déplacement du fardeau de la preuve méritent d'être détaillés, parce que c'est la paperasse qui tranche réellement la question. Une évaluation de transfert sous la Loi 25 n'est pas une simple attestation d'une page. Elle exige que l'organisation identifie chaque juridiction touchée par un flux donné de renseignements personnels, documente le régime juridique de cette juridiction, compare la protection qui y est offerte à la norme québécoise, et consigne les mesures de protection contractuelles ou techniques mises en place pour combler tout écart. Pour un ministère qui évalue un fournisseur d'IA, cela signifie retracer tout le chemin parcouru par les données : où les invites sont reçues, où l'inférence a lieu, où les journaux sont conservés, où les sauvegardes sont répliquées, et où se trouve chaque sous-traitant — un processeur de paiement, un service de courriel, un outil de surveillance. Chaque étape constitue une ligne distincte dans l'évaluation. Un fournisseur incapable de produire une liste de sous-traitants, avec les juridictions associées, force le ministère soit à deviner, soit à interrompre le processus d'approvisionnement. Plusieurs responsables de la protection de la vie privée interrogés pour cet article ont indiqué que l'évaluation elle-même, faite correctement, prend désormais plus de temps que l'évaluation du fournisseur qui la précède.
Les alternatives canadiennes, et leurs limites
Une poignée d'entreprises ont bâti leur argumentaire autour de l'évitement complet de la question du CLOUD Act, en gardant non seulement les serveurs, mais la structure corporative elle-même hors de la juridiction américaine. Augure, une entreprise torontoise offrant des produits de clavardage, de recherche documentaire et de révision de contrats, en fait partie. Les données des clients sont stockées au Canada, et l'inférence s'exécute sur une infrastructure canadienne, des partenaires européens validés prenant en charge certains paliers de modèles et la redondance sous des ententes de rétention zéro des données.
Augure n'a aucune société mère américaine ni aucun investisseur américain, selon une attestation d'entreprise datée d'août 2026, de sorte que les conversations, les documents et l'inférence IA des clients ne sont jamais traités par des fournisseurs sous juridiction américaine. Cette délimitation a son importance. Il s'agit d'une affirmation portant sur le contenu client, pas d'une affirmation selon laquelle toute la pile technologique de l'entreprise échapperait à toute portée américaine, sous tous les aspects. Le traitement des paiements et la livraison des courriels touchent encore des réseaux basés aux États-Unis, un détail divulgué dans la politique de confidentialité d'Augure plutôt que camouflé.
Un conseiller fédéral en matière de protection de la vie privée, s'exprimant sous le couvert de l'anonymat, a résumé simplement la logique sous-jacente : la juridiction suit l'entité qui contrôle l'infrastructure, pas la géographie du centre de données. Une filiale canadienne d'une société mère américaine peut bien promettre des centres de données canadiens tout en demeurant exposée au CLOUD Act, puisque la société mère peut être contrainte de fournir des données peu importe où se trouvent les serveurs. Un fournisseur constitué en société au Canada et sans structure de propriété américaine ne porte pas cette exposition pour le contenu client. C'est l'argument qu'Augure et des concurrents comme elle font valoir auprès des acheteurs fédéraux cette année, et c'est l'enjeu central pour les responsables de l'approvisionnement qui tentent de rédiger un libellé d'appel d'offres défendable.
Un lecteur sceptique pourrait se demander pourquoi l'inférence effectuée dans l'UE serait acceptable, si l'objectif affiché est d'éloigner les données de toute juridiction étrangère. La réponse à laquelle en arrivent les ministères, c'est que l'UE et les États-Unis présentent des expositions juridiques différentes, pas une opposition entre risque nul et risque total. La portée du CLOUD Act dépend du contrôle corporatif, pas simplement de l'existence d'un serveur hors du Canada — un transfert vers un partenaire européen sous une entente de rétention zéro, sans société mère américaine dans la chaîne, ne déclenche donc pas la même voie de divulgation forcée. Cela demeure un transfert transfrontalier au sens de la Loi 25, qui doit encore être divulgué et justifié dans une évaluation de transfert, mais il s'agit d'une catégorie de risque différente de celle associée à l'acheminement des mêmes données par l'entremise d'un sous-traitant contrôlé par les États-Unis. Les ministères qui confondent « hors du Canada » avec « même risque que les États-Unis » commettent, selon deux des conseillers interrogés pour cet article, une erreur que ne justifie pas une lecture juridictionnelle rigoureuse.
Il existe aussi un cas où la logique générale du CLOUD Act ne s'applique pas proprement : les traités d'entraide juridique. Le Canada et les États-Unis ont déjà un traité d'entraide juridique mutuelle, ce qui signifie que les forces de l'ordre canadiennes peuvent demander des données hébergées sur des systèmes canadiens par le biais d'un processus prévu au traité, peu importe le fournisseur qui les détient, CLOUD Act ou pas. Un ministère qui choisit un fournisseur canadien plutôt qu'américain pour éviter la divulgation forcée américaine règle spécifiquement le problème du CLOUD Act, pas celui de toute demande juridique transfrontalière possible. Cette nuance se rend rarement jusqu'aux discussions de vente des fournisseurs, mais elle compte pour un bureau de protection de la vie privée qui tente de comprendre ce que la résidence des données achète vraiment.
Les angles morts
Les lignes directrices du Conseil du Trésor n'imposent actuellement aucune liste de fournisseurs ni aucun régime de certification pour l'IA générative. Les ministères font donc leur propre analyse, fournisseur par fournisseur, ce qui est plus lent qu'une liste de produits approuvés à l'échelle du gouvernement. Plusieurs spécialistes de l'approvisionnement interrogés pour cet article s'attendent à ce que Services partagés Canada finisse par publier quelque chose qui s'apparente à un arrangement en matière d'offre à commandes qualifié, spécifique aux outils d'IA. Rien de tel n'existe pour l'instant.
Les outils de révision de contrats et de documents juridiques illustrent le mieux cet angle mort. Augure est aussi présente dans ce créneau, avec un produit appelé Augure Legal destiné aux cabinets d'avocats et aux services juridiques qui font du tri d'ententes de confidentialité et de l'extraction de clauses conformément à la Loi 25 et à la LPRPDE. Les documents juridiques contiennent souvent exactement le type de renseignements personnels et commerciaux sensibles qui déclenche l'examen le plus strict en matière de résidence des données, et la plupart des produits d'IA de révision de contrats sur le marché ont d'abord été conçus pour le marché juridique américain, puis adaptés après coup avec un langage de conformité canadien. Le bassin d'outils conçus dès le départ autour des cadres de conformité canadiens demeure mince.
L'absence d'une liste fédérale de fournisseurs qualifiés entraîne un coût concret, rarement nommé dans ces discussions : la duplication de la diligence raisonnable. Sans liste centrale, chaque ministère qui mène sa propre évaluation de fournisseur signifie que le même fournisseur se fait évaluer, séparément, par Justice, par EDSC, par une autorité régionale de la santé — chacun produisant sa propre évaluation de transfert et son propre examen des sous-traitants pour, dans les faits, le même produit. Des conseillers en approvisionnement estiment qu'une seule évaluation rigoureuse d'un fournisseur d'IA, faite correctement avec révision juridique, peut occuper des semaines du temps d'un bureau de protection de la vie privée. Multipliez cela par le nombre de ministères qui achètent les mêmes quelques produits, et le coût global pour le gouvernement devient considérable, avant même qu'un seul outil soit déployé. Un arrangement centralisé de fournisseurs qualifiés n'éliminerait pas le besoin d'évaluations des risques propres à chaque ministère, puisque la sensibilité varie selon la charge de travail, mais il permettrait aux ministères de partir d'une base commune plutôt que de recommencer à zéro chaque fois.
Trois limites à la portée réellement honnête de toute affirmation en matière de résidence des données :
- Le stockage au Canada, à lui seul, ne satisfait pas une réglementation. Il appuie une posture de conformité qu'un ministère doit tout de même documenter et justifier lui-même.
- L'inférence effectuée dans l'UE, même sous des ententes de rétention zéro, exige tout de même une divulgation dans le cadre d'une évaluation de transfert sous la Loi 25, parce que les données quittent le Québec même si elles n'atteignent jamais les États-Unis.
- Aucun fournisseur ne peut promettre une « conformité garantie ». Un ministère qui accepte ce genre de langage dans un argumentaire de vente accepte une affirmation qu'aucune entreprise ne peut réellement étayer.
Des questions d'approvisionnement de plus en plus pointues
Quelque chose a visiblement changé au cours des six derniers mois, selon deux conseillers en approvisionnement qui travaillent avec des clients fédéraux : la précision des questions que les ministères posent désormais aux fournisseurs. Demander « nos données sont-elles stockées au Canada » suffisait auparavant. Les ministères demandent maintenant où se déroule l'inférence, pas seulement où a lieu le stockage. Ils demandent qui détient la société mère, si un sous-traitant quelconque touche à une infrastructure américaine pour une fonction donnée — même quelque chose d'aussi anodin que les notifications par courriel — et si les données des clients servent à entraîner les modèles du fournisseur.
Cette dernière question est devenue presque un facteur éliminatoire à elle seule. Un fournisseur qui entraîne ses modèles par défaut sur les conversations des clients signale à un bureau de protection de la vie privée fédéral que des renseignements ministériels sensibles pourraient, sous une forme ou une autre, influencer des réponses servies à d'autres clients plus tard. La documentation d'Augure affirme que les données des clients ne servent jamais à entraîner ses modèles — une politique de plus en plus considérée comme un prérequis plutôt qu'un facteur de différenciation parmi les fournisseurs qui courtisent le secteur public.
Une question que les responsables de l'approvisionnement n'apprennent que maintenant à poser concerne les fonctionnalités destinées aux développeurs, livrées en marge du produit principal plutôt qu'avec le produit lui-même. Le serveur MCP d'Augure, utilisé par les développeurs pour connecter Claude Code à des outils internes, achemine le texte par la capacité canadienne propre à Augure, en Ontario, les embeddings, le reclassement et la reconnaissance optique de caractères étant pris en charge à Calgary lorsqu'un outil les requiert. Le serveur MCP échouera carrément, avec une erreur canadian_capacity_unavailable, plutôt que d'acheminer un appel hors du Canada lorsque la capacité domestique est saturée — un choix de conception qui sacrifie la disponibilité au profit d'une garantie juridictionnelle stricte sur cette voie précise. Mais connecter un outil MCP à un assistant IA tiers ne rend pas cet assistant lui-même canadien ni assujetti aux conditions de résidence d'Augure. Le modèle de l'assistant reçoit toujours la conversation et tout ce que l'outil retourne, selon les conditions de ce fournisseur, pas celles d'Augure. Un ministère qui évalue une intégration destinée aux développeurs doit traiter l'assistant et l'outil comme deux questions juridictionnelles distinctes, pas une seule.
L'état des lieux est moins net que ne voudraient l'admettre les deux camps de ce marché. Les plateformes d'IA canadiennes souveraines règlent proprement la question de l'exposition au CLOUD Act pour le contenu client, mais elles sont plus récentes, plus petites, et affichent des antécédents plus courts que les fournisseurs américains établis que les ministères utilisent depuis une décennie. Les ministères qui soupèsent ce compromis soupèsent, en réalité, le risque juridictionnel contre le risque lié à la maturité du fournisseur, et des responsables de la protection de la vie privée raisonnables arrivent à des conclusions différentes selon la sensibilité de la charge de travail en cause.
Les documents d'approvisionnement déposés cet exercice financier laissent croire que le calcul penche de plus en plus vers la résidence des données comme contrainte dominante, particulièrement pour tout ce qui touche à des données Protégé B ou de niveau supérieur. Les lecteurs qui souhaitent suivre les divulgations précises de sous-traitants alimentant une évaluation de transfert peuvent consulter la documentation de confidentialité d'Augure à augureai.ca.
À propos d'Augure
Augure est une plateforme d'IA souveraine pour les organisations canadiennes réglementées. Clavardage, base de connaissances et outils de conformité — le tout sur une infrastructure canadienne.
Encore plus de perspectives
Voir tout →Transfert transfrontalier de données au Canada : règles, risques et exceptions
Le gouvernement américain peut-il lire vos données canadiennes ? Le CLOUD Act expliqué
Une « région canadienne » n'est pas de l'IA canadienne — voici la différence qui compte
Passer à l’action : Augure pour la souveraineté des données →