IA au Canada : Loi 25, LPRPDE et résidence des données

Imaginez un fabricant de 300 employés en Montérégie. Le directeur de l’exploitation veut un système d’IA qui lit les bons de commande entrants, les compare à l’inventaire et aux règles de prix, puis rédige la confirmation de commande. La démo du fournisseur était excellente. Elle tournait dans une région infonuagique américaine, l’interface était en anglais seulement, et à la question « où vont les données de nos clients? », le fournisseur a répondu par un lien vers sa page de confiance.

Rien de tout ça n’est inhabituel. La plupart des outils d’IA et des méthodes d’implantation sont conçus aux États-Unis, pour des acheteurs américains, selon des hypothèses américaines. Bon nombre de ces hypothèses ne tiennent pas au Canada. Au Québec, encore moins.

Cet article explique ce qui change quand on met de l’IA en production dans une entreprise canadienne. Vous trouverez à la fin une liste de vérification à apporter à votre prochaine réunion de planification.

Il s’agit d’information générale pour les gestionnaires, pas d’un avis juridique. Consultez votre conseiller en protection des renseignements personnels avant de prendre des décisions qui dépendent de la façon dont une règle s’applique à vous.

Quelles règles s’appliquent aux projets d’IA au Canada aujourd’hui?

Pour une entreprise de taille moyenne, l’essentiel vient du droit sur la protection des renseignements personnels déjà en vigueur, pas d’une loi propre à l’IA. Ça veut dire la LPRPDE au fédéral, la Loi 25 au Québec, et la Charte de la langue française pour tout ce que vos employés ou vos clients utilisent. On complique facilement la gouvernance de l’IA au Canada. Commencez par ces trois-là.

Qu’exige la LPRPDE d’un système d’IA?

La Loi sur la protection des renseignements personnels et les documents électroniques (LPRPDE) encadre la façon dont les organisations privées recueillent, utilisent et communiquent des renseignements personnels dans le cadre d’activités commerciales. Elle ne s’applique pas dans les provinces qui ont leur propre loi essentiellement similaire : le Québec, l’Alberta et la Colombie-Britannique ont chacun leur loi pour le secteur privé.

Deux principes de la LPRPDE font l’essentiel du travail dans un projet d’IA.

La responsabilité suit les données. Quand vous confiez des renseignements personnels à un tiers, y compris un fournisseur infonuagique ou une API de modèle, vous en restez responsable. Le Commissariat à la protection de la vie privée s’attend à ce que vous preniez des moyens contractuels ou autres pour que ce tiers les protège à un niveau comparable. « Le fournisseur s’occupe de la sécurité » n’est pas une position de conformité.

Les fins limitent toujours l’usage. Les données recueillies pour exécuter des commandes l’ont été à cette fin. Utiliser des années de correspondance client pour entraîner un assistant aux ventes, c’est un autre usage. Que ce soit permis dépend de ce que vous avez dit aux gens et de ce à quoi ils pouvaient raisonnablement s’attendre. Beaucoup de projets d’IA élargissent en douce la finalité de données qui dorment dans un CRM depuis dix ans.

La LPRPDE n’impose pas d’exigence générale de résidence des données. Elle exige toutefois de la transparence. Si des renseignements personnels sont traités hors du Canada, les gens doivent savoir qu’ils pourraient être accessibles aux tribunaux et aux autorités étrangères.

Pourquoi faut-il concevoir autour de la Loi 25 du Québec?

La Loi 25 (à l’origine le projet de loi 64) a modernisé la loi québécoise sur le secteur privé par étapes entre 2022 et 2024. C’est le régime le plus strict au pays. Si vous avez des clients, des employés ou des activités au Québec, c’est autour de lui que votre programme d’IA doit être conçu. Trois dispositions touchent directement les projets d’IA.

Une évaluation des facteurs relatifs à la vie privée pour les nouveaux systèmes. Tout projet d’acquisition, de développement ou de refonte d’un système d’information ou de prestation électronique de services qui implique des renseignements personnels exige une évaluation des facteurs relatifs à la vie privée (EFVP). Un système d’IA qui ingère des dossiers clients, des données d’employés ou des billets de soutien est presque toujours visé. L’EFVP a sa place au début du projet, là où elle peut orienter la conception. Ajoutée à la fin, elle devient un document qui décrit des décisions que personne ne peut plus renverser.

La transparence des décisions automatisées. Quand vous utilisez des renseignements personnels pour rendre une décision fondée exclusivement sur un traitement automatisé, vous devez en informer la personne. Sur demande, vous devez lui expliquer quels renseignements ont servi et les principales raisons et facteurs derrière la décision. La personne peut aussi présenter ses observations à quelqu’un de l’entreprise en mesure de réviser la décision. Pensez à un système qui refuse automatiquement des demandes de crédit, note des candidats ou décide quelles réclamations passent en traitement accéléré. Chacun a besoin d’un mécanisme de divulgation, d’une explication que vous pouvez réellement fournir et d’un humain capable d’intervenir.

Une évaluation avant que les données quittent le Québec. Avant de communiquer des renseignements personnels hors du Québec, y compris vers une région infonuagique en Ontario ou en Virginie, vous devez évaluer s’ils bénéficieront d’une protection adéquate. Cette évaluation tient compte de la sensibilité des renseignements, de la finalité, des mesures de protection et du cadre juridique à destination. Le transfert doit être encadré par une entente écrite.

La Loi 25 exige aussi un responsable de la protection des renseignements personnels (par défaut, la personne ayant la plus haute autorité, souvent le PDG), des paramètres de confidentialité les plus élevés par défaut, et une divulgation quand vous utilisez une technologie qui permet d’identifier, de localiser ou de profiler quelqu’un. Les sanctions sont lourdes. Les sanctions administratives pécuniaires peuvent atteindre 10 millions de dollars ou 2 % du chiffre d’affaires mondial, et les amendes pénales vont plus haut.

Pour une entreprise québécoise, l’effet concret est simple : on ne peut pas séparer la conception d’un système d’IA de sa gouvernance. L’EFVP, l’évaluation de transfert et la divulgation des décisions automatisées dépendent toutes de choix d’architecture faits dans les premières semaines.

Existe-t-il une loi fédérale sur l’IA au Canada?

Non. La Loi sur l’intelligence artificielle et les données (LIAD) a été déposée en 2022 dans le projet de loi C-27, avec une loi destinée à remplacer la LPRPDE. Le projet de loi C-27 est mort au Feuilleton lors de la prorogation du Parlement au début de 2025. La LIAD n’est donc jamais entrée en vigueur.

Le Canada n’a donc aucune loi fédérale qui encadre précisément les systèmes d’IA du secteur privé. Ottawa a publié un code de conduite volontaire sur l’IA générative en 2023 et répète que l’IA reste une priorité. La forme et le calendrier des futures règles fédérales restent incertains.

Deux conséquences. Si un fournisseur vous dit qu’il est « conforme à la LIAD », méfiez-vous : il n’y a rien à quoi se conformer. Et ne prenez pas ce vide comme une permission. Le droit sur la protection des renseignements personnels couvre déjà la majeure partie du risque d’un système d’IA qui touche des renseignements personnels. Les futures règles demanderont probablement ce qu’un système bien géré a déjà : une documentation de ce que fait le modèle, des registres de tests, une supervision humaine sur les décisions importantes et une façon d’expliquer les résultats. Mettez ça en place maintenant et les nouvelles règles deviendront de la paperasse, pas une reconstruction. Notre guide sur la gouvernance de l’IA pour les équipes produit explique comment s’y prendre.

Où vont réellement les données dans un système d’IA?

Plus loin que la plupart des équipes le pensent. « Nos données sont dans une région canadienne », c’est un bon point de départ, mais les discussions sur la résidence s’arrêtent souvent au stockage, alors qu’un système d’IA déplace les données bien plus qu’une application classique. Suivez le parcours d’une seule requête.

1. Données sources. Où vivent les documents, les dossiers et les chiffriers que le système consulte? Sur place, dans une région infonuagique canadienne, dans un outil SaaS hébergé ailleurs?
2. Plongements et index. Si vous bâtissez une recherche sur vos documents internes, l’index vectoriel contient des représentations de ce contenu. Ce sont des données sensibles, et elles ont un emplacement.
3. Inférence. Quand le système appelle un modèle, la requête (qui contient souvent des renseignements personnels ou confidentiels) part là où ce modèle tourne. C’est l’étape que les équipes oublient le plus souvent.
4. Journaux et traces. Les outils d’observabilité capturent les requêtes et les réponses pour le débogage. Ils sont souvent hébergés par un tiers dans un autre pays.
5. Sous-traitants du fournisseur. Le fournisseur du modèle peut faire appel à ses propres sous-traitants pour la détection d’abus ou le soutien.

Peut-on utiliser les modèles les plus récents dans une région canadienne?

Parfois. AWS, Microsoft Azure et Google Cloud exploitent tous des régions canadiennes, et plusieurs y offrent maintenant l’inférence de modèles de fondation. La disponibilité par région change souvent, et les nouveaux modèles sortent généralement d’abord aux États-Unis. Le modèle le plus performant n’est donc pas toujours offert au Canada dès sa sortie, et celui qui l’est peut avoir une génération de retard.

Un système qui rédige des textes à partir de fiches produit publiques n’a pas besoin du même niveau de résidence qu’un système qui résume les évaluations de rendement des employés. Classez d’abord les données, puis choisissez le lieu d’inférence en conséquence. On approfondit ce compromis dans notre article sur la souveraineté des données en IA au Canada.

Une dernière nuance. Un fournisseur dont le siège est aux États-Unis reste soumis aux procédures judiciaires américaines, même dans sa région canadienne. Pour la plupart des charges de travail d’une entreprise de taille moyenne, c’est un risque gérable qu’on documente dans l’évaluation de transfert. Pour certains secteurs réglementés et certains contrats publics, c’est ce qui tranche. Sachez dans quel groupe vous êtes avant de signer.

Les outils d’IA internes doivent-ils fonctionner en français?

Oui, si vos équipes au Québec s’en servent. La Charte de la langue française, nettement renforcée par la loi 96 en 2022, fait du français la langue normale du travail et du commerce au Québec. Les méthodes américaines en tiennent rarement compte, et elle touche les systèmes d’IA à deux endroits.

Les systèmes destinés aux clients. Les communications commerciales, l’information sur les produits, les sites Web et le service à la clientèle doivent généralement être offerts en français, avec une place au moins équivalente au français. Un agent conversationnel, un assistant de soutien libre-service ou un flux de courriels automatisés qui ne fonctionne bien qu’en anglais pose à la fois un problème de conformité et un problème d’expérience client.

Les outils internes. La Charte couvre aussi le milieu de travail. Les employeurs doivent fournir les documents et les outils de travail en français, et la loi 96 a étendu les obligations de francisation à de plus petits employeurs qu’avant. Un assistant d’IA interne que votre équipe des opérations au Québec utilise chaque jour, c’est un outil de travail. S’il ne répond qu’en anglais, ou dans un français qui sent la mauvaise traduction automatique, vous aurez un problème d’adoption bien avant un problème juridique.

Qu’implique une livraison bilingue au-delà de la traduction?

Traduire l’interface, c’est la partie facile. En pratique, une livraison bilingue demande :

• Des jeux d’évaluation dans les deux langues. Un modèle qui obtient de bons résultats sur des cas de test en anglais peut faire nettement moins bien en français québécois, surtout avec le vocabulaire de l’industrie, les abréviations et les anglicismes qu’on trouve dans les vrais documents d’usine.
• Une recherche qui fonctionne d’une langue à l’autre. Les politiques peuvent exister en français, les devis techniques en anglais et les fils de courriels dans les deux. Le système doit trouver la bonne source, peu importe la langue de la question.
• Des requêtes et des garde-fous rédigés en français. Les requêtes, les garde-fous et les messages de refus s’écrivent en français dès le départ, pas traduits après coup.
• Une équipe de livraison qui travaille en français. Au Québec, les entrevues avec les opérateurs, les ateliers de cartographie des processus et les tests utilisateurs devraient se faire dans la langue que les gens utilisent au travail. Le savoir se perd dans la traduction, et le capter, c’est la moitié du travail. On en parle dans transformer le savoir institutionnel en systèmes de production.

Pourquoi les méthodes américaines d’IA ne se transposent-elles pas bien au Canada?

Parce que leurs réglages par défaut ont été pensés pour un autre cadre juridique et un plus gros marché. Ce n’est pas une critique des fournisseurs ou des conseillers américains. Plusieurs sont excellents. Le problème est structurel.

Les réglages par défaut supposent le droit américain. L’entente de traitement des données standard d’un fournisseur américain, sa région par défaut, sa configuration de journalisation et son choix de modèle reflètent le droit et la clientèle des États-Unis. Il faut vérifier chacun de ces éléments, et souvent les changer. Si votre partenaire traite les exigences canadiennes comme des cas d’exception, c’est vous qui les découvrirez.

La taille du marché façonne le produit. Pour une entreprise SaaS américaine, le Québec est un petit marché. Le soutien en français arrive tard et est traité comme une simple tâche de localisation.

Les documents de gouvernance sont différents. Un cadre américain de gouvernance de l’IA, bâti autour des lignes directrices fédérales sectorielles et des lois des États, ne produira ni une EFVP conforme à la Loi 25 ni une évaluation de transfert transfrontalier. Il vous faut des documents qui correspondent aux règles auxquelles vous êtes réellement soumis.

La solution : concevoir en fonction des contraintes canadiennes dès le premier atelier, avec les décisions de gouvernance et d’architecture prises dans la même pièce. Répartissez-les entre une firme de stratégie, une boîte de développement et un consultant en conformité, et chacun refile un problème aux autres.

Que faut-il vérifier avant et pendant un projet d’IA au Canada?

Utilisez cette liste avant de lancer un projet d’IA, ou pour auditer un projet déjà en cours. Elle n’est pas exhaustive. Elle couvre les questions qu’on saute le plus souvent.

Avant de bâtir

• Cartographiez les données. Dressez la liste de toutes les sources que le système va toucher. Indiquez lesquelles contiennent des renseignements personnels, et de qui (clients, employés, fournisseurs).
• Confirmez la finalité. Pour chaque source, vérifiez si l’usage par l’IA correspond à la fin pour laquelle les données ont été recueillies. Sinon, décidez s’il vous faut un nouveau consentement ou une autre approche.
• Lancez l’EFVP. Si la Loi 25 s’applique, elle est obligatoire pour la plupart des systèmes d’IA qui traitent des renseignements personnels. Même quand elle ne l’est pas, l’exercice en vaut la peine.
• Repérez les décisions automatisées. Le système prend-il, ou prend-il dans les faits, des décisions sur des personnes? Si oui, concevez dès maintenant la divulgation, l’explication et le mécanisme de révision humaine.
• Nommez un responsable. Une seule personne imputable de la gouvernance du système. Pas un comité.

Architecture

• Tracez le parcours complet d’une requête. Source, index, inférence, journaux, sous-traitants. Notez où se trouve chacun.
• Associez le lieu d’inférence à la sensibilité des données. Décidez quelles charges de travail doivent rester au Canada et lesquelles peuvent utiliser des modèles hébergés ailleurs, et écrivez pourquoi.
• Réalisez les évaluations de transfert pour tout renseignement personnel qui quitte le Québec ou le Canada, avec des ententes écrites en place.
• Contrôlez la journalisation. Décidez ce qui est journalisé, où, pour combien de temps et qui peut le consulter. Les journaux de requêtes contiennent souvent plus de données sensibles que les journaux du système source.
• Gardez la propriété claire. Votre entreprise devrait posséder le code, les requêtes, les jeux d’évaluation et la configuration. Si un fournisseur détient tout ça, votre gouvernance dépend de la sienne.

Langue et adoption

• Définissez l’exigence linguistique pour chaque interface. Les systèmes destinés aux clients, les outils internes et les systèmes administratifs peuvent avoir des besoins différents.
• Bâtissez des jeux d’évaluation bilingues à partir de vrais documents et de vraies formulations des deux communautés linguistiques de votre entreprise.
• Testez avec des utilisateurs francophones avant le lancement, pas après les plaintes.

En continu

• Surveillez la qualité par segment. Suivez la performance séparément pour les entrées en français et en anglais, et pour chaque grand groupe d’utilisateurs.
• Faites une revue annuelle en fonction des règles en vigueur. Le portrait fédéral va changer. La documentation de votre système doit permettre de montrer facilement ce qu’il fait et comment il a été testé.
• Conservez les traces. Versions de modèles, changements de requêtes, résultats d’évaluation, incidents. Ça vous prépare aux futures règles sur l’IA et ça appuie vos demandes de RS&DE (recherche scientifique et développement expérimental) pour le travail expérimental. Voir comment les travaux de transformation IA peuvent être admissibles à la RS&DE.

À quoi ressemble un projet d’IA prêt pour le Canada?

Revenons au fabricant. Une version de ce projet de bons de commande conçue pour le Canada est différente de la démo, même si ça paraît peu en surface.

Les données de commandes et l’index vectoriel sont dans une région canadienne. Le modèle tourne aussi dans une région canadienne, parce que les bons de commande contiennent les coordonnées des clients et que l’équipe a choisi de garder les renseignements personnels au pays. Quand un modèle plus performant n’était offert qu’aux États-Unis, l’équipe l’a testé sur des documents dépersonnalisés et a documenté pourquoi le modèle hébergé au Canada suffisait pour cette charge de travail. L’EFVP a été rédigée la première semaine et mise à jour à mesure que la conception évoluait. Les confirmations partent dans la langue du client. L’équipe des ventes internes à Longueuil utilise l’interface de révision en français, et le jeu d’évaluation inclut les vraies abréviations, en français et en anglais, que les clients écrivent sur leurs bons de commande.

Le système ne prend pas de décisions automatisées sur des personnes, donc les obligations de la Loi 25 sur les décisions automatisées ne s’appliquent pas. Quelqu’un l’a vérifié et l’a mis par écrit.

Les premières semaines ont été plus réfléchies. En échange, le système est entré en production sans qu’une revue de gouvernance l’arrête à la ligne d’arrivée. C’est là que beaucoup de projets d’IA s’enlisent. Les autres raisons sont dans pourquoi les projets pilotes d’IA stagnent.

Questions fréquentes

La LPRPDE exige-t-elle que les données d’IA restent au Canada?

Non. La LPRPDE n’impose pas d’exigence générale de résidence des données. Elle vous oblige toutefois à rester responsable des données confiées à des tiers et à informer les gens quand leurs renseignements personnels peuvent être traités hors du Canada. La Loi 25 du Québec va plus loin et exige une évaluation documentée avant que des renseignements personnels quittent la province.

La Loi 25 du Québec s’applique-t-elle aux systèmes d’IA?

Oui, dès que le système traite des renseignements personnels de personnes au Québec. La plupart des nouveaux systèmes d’IA qui touchent des données de clients ou d’employés exigent une EFVP, et toute décision fondée exclusivement sur un traitement automatisé doit être divulguée, expliquée sur demande et pouvoir être révisée par un humain.

La LIAD est-elle en vigueur au Canada?

Non. La Loi sur l’intelligence artificielle et les données faisait partie du projet de loi C-27, mort lors de la prorogation du Parlement au début de 2025. Il n’existe actuellement aucune loi fédérale propre à l’IA pour le secteur privé, et c’est le droit sur la protection des renseignements personnels qui couvre la majeure partie du risque.

Travailler avec Chrono Innovation

Chrono Innovation est une équipe canadienne qui bâtit des systèmes d’IA pour les entreprises de taille moyenne. La gouvernance, l’infrastructure et l’adoption sont prises en charge par les mêmes personnes qui écrivent le code. On livre en français et en anglais, et vous travaillez directement avec des gens d’expérience. La plupart des mandats commencent par un projet à portée fixe sur un ou deux problèmes opérationnels, construit selon les standards de production et qui vous appartient. Si vous planifiez un projet d’IA et voulez valider les questions de gouvernance et de résidence avant de vous engager, prenez rendez-vous avec nous.