Pier-Luc Charbonneau

Dossiers de la DPJ, fiasco SAAQclic, Dossier santé numérique : le Québec protège-t-il vraiment nos données les plus sensibles?

Pier-Luc Charbonneau — Sun, 12 Apr 2026 01:11:53 GMT

Alors que le Dossier santé numérique s'apprête à centraliser les renseignements médicaux de millions de Québécois, un simple courriel suffit encore pour obtenir copie d'un dossier au CISSS de la Montérégie-Est — y compris ceux de vos enfants. Dans un État qui n'a toujours pas digéré le fiasco SAAQclic, la question mérite d'être posée : sommes-nous prêts?

Tout a commencé par une demande banale. Souhaitant consulter la journalisation de mon dossier au CISSS de la Montérégie-Est — c'est-à-dire le registre de qui a accédé à mes renseignements et quand — j'ai également demandé les dossiers de mes deux enfants. Le processus a été d'une simplicité qui m'a laissé perplexe : un formulaire à remplir, une signature, et c'était tout. Aucune pièce d'identité avec photo. Aucune photocopie de carte d'assurance maladie. Aucun code de vérification. J'ai obtenu l'intégralité de mon dossier ainsi que les dossiers complets de mes deux enfants — renseignements médicaux, notes d'intervenants, données personnelles — le tout sur la base d'un formulaire que personne n'avait les moyens d'authentifier. Car le CISSS de la Montérégie-Est, comme la très grande majorité des établissements du réseau, ne détient pas de spécimen de ma signature dans ses dossiers. Contrairement à une banque, qui conserve une signature de référence et peut la comparer, l'établissement qui a traité ma demande n'avait strictement aucun moyen de vérifier que le formulaire avait été signé par la bonne personne. N'importe qui, muni de mon nom et de nos dates de naissance, aurait pu signer ce formulaire à ma place.

L'expérience m'a amené à me poser une question : si c'est aussi simple au CISSS, qu'en est-il de la Direction de la protection de la jeunesse (DPJ), qui détient des renseignements encore plus sensibles — signalements, évaluations psychosociales, décisions judiciaires concernant des enfants?

C'était pire.

En contactant la DPJ de la Montérégie-Est par téléphone, on m'a confirmé la procédure : il suffit d'envoyer un courriel contenant les noms et dates de naissance des personnes concernées. Pas de pièce d'identité. Pas de signature. Pas de formulaire. Un courriel. C'est tout ce qui sépare les renseignements les plus confidentiels du réseau québécois d'un inconnu qui connaît votre date de naissance.

Et c'est dans ce contexte que le Québec s'apprête à centraliser les données médicales de l'ensemble de sa population.

Le Dossier santé numérique : l'heure de vérité

Le 9 mai prochain, le Québec franchira une étape déterminante dans la numérisation de son réseau de santé. Le Dossier santé numérique (DSN), un projet évalué à plus de 1,5 milliard de dollars sur 15 ans et confié à la firme américaine Epic Systems, sera déployé en projet pilote dans deux établissements — le CIUSSS du Nord-de-l'Île-de-Montréal et celui de la Mauricie-et-du-Centre-du-Québec. L'ambition est colossale : regrouper l'ensemble des données médicales des patients québécois en un seul endroit, accessible à travers tout le réseau.

Mais à moins d'un mois du lancement, c'est le chaos. Le ministre de la Cybersécurité et du Numérique, Éric Caire, devenu depuis le ministre Bélanger, craint ouvertement que le projet ne soit pas prêt. Les médecins spécialistes ont mis le DSN sur pause en raison d'une impasse avec Québec. Le personnel soignant des établissements pilotes est en panique, les lits seront fermés pour atténuer les impacts et les départements fonctionneront à capacité réduite. Geneviève Biron, présidente de Santé Québec, admet qu'il faut « s'attendre à de petits problèmes techniques » — un euphémisme qui résonne douloureusement après le fiasco SAAQclic. Le Parti québécois demande carrément la suspension du projet.

Et pour cause : un des artisans du désastre SAAQclic, Alain Généreux, se retrouve affecté au Dossier santé numérique. Le gouvernement caquiste le défend. L'opposition s'indigne. Le contribuable, lui, se souvient.

SAAQclic : les leçons qu'on refuse d'apprendre

Il est impossible de parler du Dossier santé numérique sans évoquer le spectre de SAAQclic, le virage numérique de la Société de l'assurance automobile du Québec qui a tourné au cauchemar national. Le rapport de la Commission Gallant, déposé le 16 février 2026, est accablant : la SAAQ a menti pendant des années sur l'état du projet. Le cabinet de François Legault savait dès 2023 que le projet dérapait. La facture, initialement estimée à quelques centaines de millions, a explosé au-delà de 1,1 milliard de dollars. L'UPAC a ouvert une enquête criminelle sur les conditions d'attribution des contrats.

Plus troublant encore : un ex-fonctionnaire de la SAAQ a été arrêté pour avoir consulté illégalement des dossiers et modifié les renseignements personnels d'automobilistes dans le système. François Dagenais, 54 ans, fait face à des accusations d'abus de confiance, d'utilisation non autorisée d'un ordinateur et de méfait à l'égard de données informatiques. Ce cas illustre une vérité fondamentale en sécurité informationnelle : la plus grande menace ne vient pas toujours de l'extérieur.

Parmi les 26 recommandations du rapport Gallant figure la nécessité d'une « base solide en gestion de données — structuration, provenance, appartenance — avant d'avancer ». Le commissaire plaide pour la création d'une entité centralisée spécialisée en projets de transformation numérique, afin de réduire la dépendance de l'État aux consultants privés. Ces recommandations sont sages. Mais elles arrivent alors que le Québec s'apprête à reproduire, dans le domaine de la santé, une opération d'une envergure sans précédent — avec des données infiniment plus sensibles.

Centraliser sans sécuriser?

Le DSN promet de « renforcer la confidentialité et la sécurité des données ». Or, plusieurs questions demeurent sans réponse satisfaisante.

La première concerne la souveraineté des données. Epic Systems est une entreprise américaine, assujettie au Cloud Act — une loi fédérale qui permet au gouvernement des États-Unis d'obtenir un mandat pour accéder aux données d'entreprises de nuage informatique américaines, même lorsque ces données sont hébergées hors du territoire américain. Les données du DSN seront logées à Toronto et à Montréal, mais le parapluie juridique américain s'étend bien au-delà des frontières physiques des serveurs. Dans le contexte géopolitique actuel, où les données sont devenues un levier de négociation commerciale entre États, la question n'est pas abstraite.

La seconde concerne l'accès au système lui-même. Le DSN centralisera les dossiers médicaux, les notes cliniques, les résultats de laboratoire, les prescriptions et les données psychosociales de millions de patients. Qui y aura accès? Selon quels protocoles d'authentification? Avec quels mécanismes de traçabilité? L'affaire Dagenais à la SAAQ démontre qu'un employé disposant d'accès légitimes peut détourner le système à des fins personnelles. À l'échelle du réseau de la santé québécois — des dizaines de milliers d'employés, de professionnels, de sous-traitants — le risque est d'un tout autre ordre de grandeur.

L'illusion de la vérification

Ce que j'ai vécu au CISSS de la Montérégie-Est et ce que la DPJ m'a confirmé au téléphone ne sont pas des anomalies locales. Une revue des pratiques en vigueur dans le réseau de la santé et des services sociaux révèle une mosaïque de procédures dont le niveau de rigueur varie considérablement d'un établissement à l'autre — mais dont aucune n'offre de véritable garantie.

Certains établissements affichent des exigences plus strictes, du moins en apparence. Le CISSS de Chaudière-Appalaches requiert une pièce d'identité avec photo pour la récupération de documents en personne. Le CISSS de l'Abitibi-Témiscamingue refuse toute demande par courriel non accompagnée d'une photocopie de la carte d'assurance maladie. Le Dossier santé Québec utilise une clé d'authentification numérique délivrée par la RAMQ, avec vérification en personne auprès d'un agent. Mais au CISSS de la Montérégie-Est, un simple formulaire signé a suffi pour trois dossiers complets. Et à la DPJ de la même région, on exige encore moins : un courriel avec noms et dates de naissance — sans signature, sans pièce d'identité, sans rien.

Même dans les établissements qui exigent un formulaire signé, la signature ne constitue pas un véritable mécanisme de sécurité. Aucun CISSS, CIUSSS ou direction de la DPJ ne conserve de spécimen de signature permettant de comparer celui reçu sur un formulaire. Un organisme du réseau de la santé qui reçoit un formulaire signé n'a strictement aucun moyen de vérifier que la signature est authentique. C'est un rituel bureaucratique qui donne l'apparence d'un contrôle sans en offrir la substance.

La chaîne de « vérification » dans le réseau se résume donc, au mieux, à trois éléments : un nom (information publique), une date de naissance (information publique ou compromise à grande échelle) et une signature (invérifiable). Au pire — comme à la DPJ de la Montérégie-Est — elle se résume à deux : un nom et une date de naissance, transmis par courriel. On vous enverra ensuite les documents sans encryption à cette même adresse courriel! En sécurité informationnelle, on parlerait d'un processus d'authentification reposant uniquement sur des informations que la personne déclare, sans aucun facteur indépendant confirmant ce qu'elle possède (pièce d'identité physique, téléphone pour un code de vérification) ou ce qu'elle est (donnée biométrique). C'est la forme la plus faible d'authentification qui existe — et elle protège les dossiers les plus sensibles du réseau! Tout les ordres professionnels au Québec ont émis des directives claires et strictes sur les demandes d'accès aux dossier sociaux et médicaux et déconseille l'envoi des données par courriel sans processus d'encryption.

Des scénarios qui n'ont rien de théorique

Les conséquences d'une vérification d'identité déficiente ne se mesurent pas en abstractions. Elles se mesurent en vies.

Prenons le scénario le plus immédiat. Une femme fuit un conjoint violent avec ses enfants. Elle se réfugie dans une maison d'hébergement. La DPJ est impliquée, un dossier est ouvert. Ce dossier contient, entre autres, l'adresse où se trouvent la mère et les enfants, les évaluations psychosociales, les mesures de protection ordonnées par le tribunal. Le conjoint violent connaît le nom complet de son ex-conjointe, sa date de naissance et celles de leurs enfants — ce sont des informations familiales élémentaires. Rien ne l'empêche d'envoyer un courriel à la DPJ en se faisant passer pour elle, en utilisant une adresse courriel similaire, et de demander copie du dossier. Si l'établissement se contente des mêmes vérifications sommaires — nom et date de naissance — le conjoint violent obtient l'adresse du refuge. Les conséquences peuvent être fatales. Ce n'est pas un scénario hypothétique : au Québec, selon les données du ministère de la Sécurité publique, les homicides liés à la violence conjugale représentent une proportion significative des homicides commis chaque année. Le système judiciaire impose le huis clos précisément pour empêcher ce type de situation. Mais le huis clos ne vaut rien si les mêmes renseignements peuvent être obtenus par un courriel de trois lignes.

À plus grande échelle, la centralisation des données de santé dans le DSN ouvre la porte à des menaces géopolitiques que le Québec n'a jamais eu à considérer auparavant. Aux États-Unis, les agences de renseignement tirent la sonnette d'alarme depuis des années. Le FBI et le département de la Justice ont documenté comment des États étrangers — la Chine en tête — exploitent les données médicales volées à des fins d'espionnage et de chantage. En combinant les données de la fuite d'Anthem (assureur santé, 2015), du piratage de l'Office of Personnel Management (dossiers de fonctionnaires fédéraux, 2015) et de la brèche d'Equifax (2017), les services de renseignement chinois ont constitué ce que les documents de contre-espionnage américains décrivent comme de « vastes opportunités pour cibler avec précision des individus dans les gouvernements étrangers ». L'ancien procureur général Merrick Garland a été sans ambiguïté : « Nos adversaires exploitent les données personnelles sensibles des Américains pour menacer notre sécurité nationale. Ils achètent ces données pour les utiliser à des fins de chantage et de surveillance. »

Le Québec n'est pas à l'abri de cette logique. Imaginons un haut fonctionnaire québécois, un juge, un élu, dont le dossier médical — ou celui de ses enfants suivis par la DPJ — tombe entre les mains d'un"state actor" hostile. Des antécédents psychiatriques, un diagnostic de dépendance, un signalement à la DPJ : autant de leviers de chantage potentiels qui pourraient être utilisés pour influencer des décisions politiques ou obtenir des renseignements stratégiques. Le Cloud Act, auquel est soumise Epic Systems, ajoute une couche de vulnérabilité : le gouvernement américain pourrait légalement exiger l'accès aux données hébergées par la firme, même sur des serveurs situés à Montréal ou à Toronto.

Le paradoxe du huis clos

L'incohérence est d'autant plus frappante que le législateur québécois a pris soin d'entourer les dossiers de protection de la jeunesse des protections les plus strictes. La Loi sur la protection de la jeunesse impose la confidentialité par défaut de tous les renseignements recueillis sur un enfant et ses parents. Les audiences à la Chambre de la jeunesse de la Cour du Québec se tiennent à huis clos — sans la présence du public. Les conférences de règlement ne sont pas enregistrées. Les notes du juge sont détruites à la fin de chaque séance. Les procès en Cour du Québec ou en Cour supérieure concernant des enfants font l'objet d'ordonnances de non-publication rigoureuses.

Tout ce dispositif juridique repose sur une prémisse : que les renseignements protégés le demeurent. Mais cette prémisse s'effondre lorsque le processus administratif qui en contrôle l'accès repose sur des informations publiques et des signatures invérifiables. Le huis clos judiciaire et le formulaire par courriel ne peuvent pas coexister. L'un ou l'autre est de trop — et ce n'est certainement pas le huis clos.

La Loi 25 : un cadre ambitieux, une application inégale

Le Québec ne manque pas de lois. La Loi 25, pleinement en vigueur depuis septembre 2024, a considérablement rehaussé les exigences en matière de protection des renseignements personnels. Elle impose des politiques de gouvernance claires, un registre des incidents de confidentialité, l'obligation de signaler à la Commission d'accès à l'information (CAI) tout incident présentant un risque de préjudice sérieux. Pour les enfants de moins de 14 ans, elle exige le consentement du titulaire de l'autorité parentale. Mais encore faut-il s'assurer que la personne qui formule une demande d'accès est véritablement ce titulaire — et non quelqu'un qui se fait passer pour tel.

La CAI elle-même recommande que le demandeur établisse son identité de manière fiable. La Sûreté du Québec exige systématiquement une pièce d'identité gouvernementale avec photo et signature. Pourquoi la DPJ, qui détient des renseignements parmi les plus sensibles de l'appareil étatique, se contenterait-elle de moins?

La Commission Laurent : un angle mort

En 2021, la Commission spéciale sur les droits des enfants et la protection de la jeunesse, présidée par Régine Laurent, a déposé ses 65 recommandations. Elles ont mené à une révision importante de la Loi sur la protection de la jeunesse en avril 2022, assouplissant les règles de confidentialité pour permettre un meilleur partage d'information entre professionnels — un objectif légitime et nécessaire.

Mais ni la Commission Laurent, ni les modifications législatives subséquentes n'ont abordé la sécurité des processus d'accès aux dossiers par les citoyens. Le verrou d'entrée — la vérification de l'identité du demandeur — est resté dans un angle mort. C'est comme si l'on avait rénové l'intérieur de la maison en oubliant de verrouiller la porte d'entrée.

Un État numérique bâti sur des fondations de papier

Le portrait d'ensemble est préoccupant. D'un côté, le Québec investit des milliards pour centraliser les données de santé les plus intimes de ses citoyens dans un système numérique développé par une firme américaine soumise au Cloud Act, déployé dans l'urgence malgré les avertissements du ministre responsable, du personnel soignant et de l'opposition, et confié en partie aux mêmes gestionnaires qui ont présidé au fiasco SAAQclic.

De l'autre, les processus existants pour accéder aux dossiers les plus sensibles — ceux des enfants, des familles, des patients — reposent encore sur des courriels, des dates de naissance et des signatures que personne ne peut vérifier. J'en ai fait l'expérience directe : trois dossiers complets obtenus au CISSS de la Montérégie-Est avec un formulaire signé que l'établissement n'avait aucun moyen d'authentifier. Et la DPJ de la même région m'a confirmé qu'elle exige encore moins.

La question qui se pose est simple : si le Québec n'arrive pas à sécuriser adéquatement l'accès à des dossiers papier ou à des fichiers transmis par courriel, comment peut-il prétendre protéger une base de données centralisée contenant les renseignements médicaux de l'ensemble de sa population?

Le rapport Gallant recommandait une « base solide en gestion de données » avant d'avancer dans la transformation numérique de l'État. Les pratiques actuelles de la DPJ et du CISSS de la Montérégie-Est — et vraisemblablement de plusieurs autres établissements du réseau — démontrent que cette base solide reste à construire. On ne résout pas un problème de fondation en ajoutant des étages.

Des solutions à portée de main

La modernisation des processus de vérification d'identité ne relève pas de la science-fiction. Le réseau de la santé québécois dispose déjà de mécanismes plus robustes dans d'autres contextes : le Dossier santé Québec utilise une clé d'authentification numérique délivrée par la RAMQ, avec vérification en personne auprès d'un agent; Carnet santé Québec emploie l'authentification multifacteur.

Plusieurs mesures pourraient être mises en oeuvre rapidement : l'exigence systématique d'une pièce d'identité gouvernementale avec photo pour toute demande d'accès, quelle que soit la modalité de transmission; l'authentification à deux facteurs pour les demandes à distance; la création d'un portail sécurisé intégré à l'infrastructure d'authentification gouvernementale; l'adoption d'un protocole uniforme à l'échelle provinciale, éliminant les disparités entre établissements. Ces mesures devraient être déployées avant la centralisation des données, pas après.

Le vrai test de la transformation numérique

Le Québec se trouve à un carrefour. Le Dossier santé numérique pourrait effectivement révolutionner la prestation des soins de santé dans la province, réduire les erreurs médicales et sauver des vies. Mais le fiasco SAAQclic a démontré ce qui arrive lorsqu'on précipite un virage numérique sans les assises nécessaires. Le rapport Gallant a documenté les mensonges, les dépassements de coûts et l'absence de reddition de comptes. L'affaire Dagenais a illustré la vulnérabilité des systèmes face aux menaces internes.

Pendant ce temps, au CISSS de la Montérégie-Est, j'ai obtenu trois dossiers complets — le mien et ceux de mes deux enfants — sans jamais avoir à prouver mon identité autrement que par un formulaire portant une signature que personne ne pouvait vérifier. Et à la DPJ de la même région, on m'a confirmé qu'un simple courriel avec des dates de naissance aurait suffi.

Les enfants protégés par la DPJ méritent que la sécurité de leurs renseignements personnels soit à la hauteur de la confidentialité que les tribunaux leur accordent. Les patients dont les données seront bientôt centralisées dans le DSN méritent l'assurance que les erreurs de SAAQclic ne seront pas répétées à une échelle encore plus dommageable. Et les citoyens québécois, dont les données personnelles ont déjà été massivement compromises, méritent un État qui apprend de ses erreurs avant d'en commettre de nouvelles.

Préparez-vous, comme le titrait le Journal de Montréal. L'enjeu n'est plus seulement technique. Il est fondamentalement démocratique.

L'auteur de cet article n'est pas juriste. Les références aux lois québécoises, notamment la Loi sur la protection de la jeunesse (P-34.1), la Loi sur l'accès aux documents des organismes publics et sur la protection des renseignements personnels (A-2.1) et la Loi 25, sont fondées sur les informations publiquement disponibles au moment de la rédaction et ne constituent pas une analyse juridique. Pour obtenir un avis sur la portée exacte de ces lois et sur vos droits en matière d'accès aux dossiers, consultez un avocat spécialisé en droit de la vie privée ou en droit de la jeunesse. Les constats relatifs aux processus de vérification d'identité reposent sur l'expérience directe de l'auteur auprès du CISSS et de la DPJ de la Montérégie-Est ainsi que sur les informations rendues publiques par divers établissements du réseau de la santé et des services sociaux.

J'ai écrit mon propre OS en 2006. En 2026, tu devrais écrire ton propre LLM

Pier-Luc Charbonneau — Sat, 11 Apr 2026 21:45:16 GMT

De MINIX aux LLMs : pourquoi les gens en cybersécurité doivent comprendre ce qu'ils défendent

En 2006, je compilais mon propre noyau Linux. Je lisais Operating Systems: Design and Implementation de Tanenbaum et Woodhull, la 3e édition, celle qui venait avec le code source complet de MINIX 3 sur CD-ROM. J'écrivais mon propre système d'exploitation. Je faisais de la recherche sur les vulnérabilités, j'étudiais les shellcodes, je désassemblais des binaires pour comprendre exactement ce qui se passait entre le processeur et la mémoire quand un buffer overflow permettait d'exécuter du code arbitraire.

À cette époque, si tu travaillais en sécurité informatique, c'était un passage obligé. Tu ne pouvais pas prétendre défendre des systèmes que tu ne comprenais pas. Personne ne prenait au sérieux un analyste qui n'avait jamais regardé ce qui se passait au-delà de l'interface graphique. Tanenbaum t'apprenait comment un OS orchestrait ses processus, sa mémoire et ses interruptions. Erickson, avec Hacking: The Art of Exploitation, t'apprenait comment exploiter ces mêmes mécanismes en assembleur x86. Le Shellcoder's Handbook de Chris Anley et son équipe t'emmenait encore plus loin : stack overflows, heap overflows, format strings, shellcoding sur Linux, Windows, Solaris et SPARC.

La logique était simple : pour sécuriser quelque chose, il faut d'abord savoir comment ça fonctionne, puis comment ça casse.

2026 : les LLMs sont le nouveau système d'exploitation

Vingt ans plus tard, les Large Language Models occupent une place dans nos infrastructures qui rivalise avec celle qu'occupaient les systèmes d'exploitation en 2006. Depuis 2023, les LLMs sont partout. Pas seulement dans les laboratoires de recherche : dans les entreprises, dans les flux de travail quotidiens, dans les produits que nos clients utilisent. Certaines personnes organisent littéralement toute leur vie autour de ces systèmes (gestion de tâches, rédaction, recherche, prise de décisions). On parle de « Life OS » pour décrire cette dépendance croissante.

Et pourtant, la majorité des professionnels en sécurité informatique ne savent pas comment un LLM fonctionne. Pas au niveau superficiel (ça, tout le monde a vu un diagramme de transformer dans une présentation PowerPoint). Je parle du niveau fondamental. Comment un tokenizer découpe le texte en sous-mots. Comment les embeddings projettent ces tokens dans un espace vectoriel de haute dimension. Comment le mécanisme d'attention (le cœur de l'architecture transformer) calcule les relations entre chaque token et tous les autres dans une séquence. Comment la fonction softmax transforme des scores bruts en distributions de probabilité. Comment le pré-entraînement sur des milliards de tokens crée des représentations internes du langage, et comment le fine-tuning et le RLHF alignent ces représentations sur des comportements spécifiques.

C'est exactement le même angle mort qu'en 2006, transposé à une nouvelle couche de la stack technologique.

Les deux ressources que tout professionnel en cybersécurité devrait connaître

Sebastian Raschka, Build a Large Language Model (From Scratch) (Manning, 2024)

Le livre s'inspire du principe attribué à Richard Feynman : « Je ne comprends rien de ce que je ne peux pas construire. » Raschka, chercheur en ingénierie LLM avec plus d'une décennie d'expérience en IA, guide le lecteur à travers la construction complète d'un LLM de style GPT, étape par étape. Sans s'appuyer sur des bibliothèques LLM existantes, on code un modèle de base, on le transforme en classificateur de texte, puis en chatbot capable de suivre des instructions conversationnelles.

La table des matières couvre les fondamentaux des LLMs, le traitement des données textuelles, le codage des mécanismes d'attention, l'implémentation d'un modèle GPT depuis zéro, le pré-entraînement sur des données non étiquetées, le fine-tuning pour la classification et le fine-tuning pour suivre des instructions. Le livre inclut même une annexe sur le fine-tuning efficace en paramètres avec LoRA.

Ce qui rend ce livre particulièrement pertinent pour la cybersécurité : quand tu as codé toi-même chaque composante (le tokenizer, les couches d'attention, la boucle d'entraînement), tu comprends intuitivement où se trouvent les surfaces d'attaque. Les prompt injections ne sont plus des curiosités abstraites; elles deviennent des conséquences logiques de l'architecture. Le data poisoning devient compréhensible quand tu as toi-même préparé un dataset d'entraînement. Le model extraction prend sens quand tu as toi-même chargé et inspecté des poids pré-entraînés.

Andrej Karpathy, nanochat (GitHub, 2025)

Si le livre de Raschka est le Tanenbaum des LLMs, nanochat est le MINIX. nanochat est le harness expérimental le plus simple pour entraîner des LLMs, conçu pour tourner sur un seul nœud GPU, avec un code minimal et hackable couvrant toutes les étapes majeures : tokenisation, pré-entraînement, fine-tuning, évaluation, inférence et interface web de chat.

La promesse est spectaculaire : on peut entraîner son propre LLM de niveau GPT-2 (un modèle qui coûtait environ 43 000 $ USD à entraîner en 2019) pour seulement 73 $ USD (environ 3 heures sur un nœud de 8 GPU H100). Et ensuite, on peut lui parler via une interface web à la ChatGPT.

Le projet est configuré avec un seul paramètre de complexité : --depth, le nombre de couches dans le transformer. Tous les autres hyperparamètres (largeur du transformer, nombre de têtes d'attention, taux d'apprentissage, horizon d'entraînement) sont calculés automatiquement de manière optimale. Pour les professionnels en sécurité, c'est idéal : le code est lisible, minimal, et chaque composante est exposée. Pas de frameworks gigantesques qui obscurcissent la logique. Un seul fichier cohérent qu'on peut lire, modifier et comprendre.

Le code est sur GitHub: https://github.com/karpathy/nanochat

Le parallèle n'est pas une métaphore

En 2006, Tanenbaum te donnait MINIX pour que tu puisses voir le code d'un vrai OS, le compiler, le modifier et observer les conséquences. En 2025, Raschka et Karpathy offrent exactement la même chose pour les LLMs.

En 2006, The Shellcoder's Handbook et Hacking: The Art of Exploitation t'apprenaient comment les systèmes que tu défendais pouvaient être subvertis au niveau le plus bas. Aujourd'hui, comprendre comment les tokens traversent les couches d'attention, comment les poids encodent des biais, comment le fine-tuning peut être manipulé : c'est l'équivalent exact de comprendre comment un buffer overflow détourne le pointeur d'instruction.

Si tu es en cybersécurité en 2026 et que tu ne comprends pas comment un transformer fonctionne, tu es dans la même position que quelqu'un qui défendait des serveurs en 2006 sans avoir jamais ouvert un désassembleur. Les outils ont changé. L'exigence fondamentale, elle, n'a pas changé du tout : comprends ce que tu défends, ou quelqu'un d'autre le fera à ta place (et pas dans ton intérêt).

Lis Raschka. Clone nanochat. Entraîne un modèle. Regarde ce qui se passe à l'intérieur. C'est comme ça qu'on faisait en 2006. C'est comme ça qu'on devrait encore faire aujourd'hui.

Risques légaux et éthique de l'usage de LLM dans le système de santé Québécois

Pier-Luc Charbonneau — Sat, 11 Apr 2026 10:31:07 GMT

À l'attention des directions des technologies de l'information, des responsables de la protection des renseignements personnels et des équipes de sécurité des CES, CLSC, CISSS, CIUSSS et établissements de santé du Québec. Aussi utile pour les travailleurs sociaux, psychologues, médecins qui travaillent dans le système de la santé.

Sommaire exécutif

Récemment nous avons beaucoup entendu parler du dossier santé numérique au Québec. Par contre, dans tout le débat sur l'usage des outils en milieu hospitalier on semble oublier un risque présent depuis de nombreuses années.

L'intelligence artificielle générative (GenAI) transforme la pratique clinique, la recherche et l'administration dans le réseau de la santé québécois. Cette transformation s'opère dans un contexte où le cadre réglementaire (la Loi 25, la Loi sur les renseignements de santé et de services sociaux (LRSSS), le Règlement sur l'anonymisation et l'Énoncé de politique des trois conseils (ÉPTC 2)) impose des obligations de protection des données de santé parmi les plus strictes au Canada.

Les outils de sécurité traditionnels n'ont pas été conçus pour les risques propres aux grands modèles de langage (LLM). La fuite de données sensibles vers des outils GenAI commerciaux (parfois en chine!), l'extraction de données d'entraînement, les attaques par injection de prompt et l'absence de traçabilité des interactions avec les modèles créent un décalage croissant entre les obligations légales et les capacités de contrôle des établissements.

Cet article démontre comment Prompt Security (un "pare-feu pour LLM" de SentinelOne) adresse ces risques de manière technique et opérationnelle, dans le respect du cadre réglementaire québécois et canadien.

1. Le paysage des risques GenAI en santé

1.1 L'ampleur de l'adoption

Selon les données de l'industrie, 80 % des hôpitaux utilisent désormais l'IA pour les soins aux patients et l'efficacité opérationnelle. Cette adoption s'accélère dans le réseau québécois: résumés automatiques de notes cliniques, aide à la rédaction de rapports, analyse de données de recherche, triage assisté. Or, une part significative de cette adoption se fait de manière informelle. Des cliniciens, des chercheurs et des employés administratifs qui utilisent ChatGPT, Claude, Gemini ou Copilot dans leur navigateur, sans supervision ou formation.

1.2 Les risques spécifiques aux LLM

Les risques liés à l'IA générative en contexte de santé diffèrent fondamentalement des risques informatiques plus traditionnels. Ils se classent en six catégories :

Fuite de données vers des LLM externes (Shadow AI). Un employé qui colle un extrait de dossier patient dans ChatGPT pour obtenir un résumé transmet ces données aux serveurs d'OpenAI. Ces données peuvent être utilisées pour l'entraînement du modèle, stockées dans des logs, ou accessibles à des tiers. La recherche a démontré que des modèles comme GPT-4 atteignent une précision de 84 à 95 % pour inférer des attributs personnels sensibles (âge, sexe, localisation, état de santé) à partir de texte apparemment anodin. La "déidentification classique" ne suffit plus face à ces capacités d'inférence.

L'illusion de l'anonymisation face aux LLM. Un chercheur ou un clinicien qui anonymise consciencieusement un dossier patient avant de le soumettre à un LLM pose un geste de bonne foi mais il s'agit d'un geste qui repose sur des hypothèses obsolètes. L'anonymisation traditionnelle opère par retrait d'identifiants directs : on supprime le nom, le numéro d'assurance maladie, la date de naissance exacte. Mais un grand modèle de langage ne raisonne pas en identifiants isolés. Il raisonne en corrélations massives entre des corpus hétérogènes.

Le mécanisme est le suivant : les LLM commerciaux sont entraînés sur des volumes considérables de données publiquement accessibles — publications sur les réseaux sociaux (Facebook, Instagram, X), forums de patients, profils LinkedIn, articles de journaux locaux, avis de décès, registres publics. Lorsqu'un texte clinique « anonymisé » est soumis au modèle, celui-ci ne le traite pas en vase clos. Il l'intègre dans un espace de représentation où coexistent déjà des milliards de fragments d'information provenant de ces sources externes. Un diagnostic rare combiné à un groupe d'âge, un code postal et une mention de comorbidité peut suffire au modèle pour établir une correspondance probabiliste avec un individu identifiable dans ses données d'entraînement: un profil Facebook mentionnant une hospitalisation, un article communautaire nommant une personne, un commentaire sur un forum de patients. Par exemple, il est en mesure d'utiliser des données provenant de facebook, instagram, etc. pour déduire que le patient qui est arrivé à l'hôpital Maisonneuve avec une maladie rare le 3 avril est Jean Tremblay car il aura fait la corrélation avec la photo posté sur instagram par Jean qui explique quand il est arrivé et sorti de l'hôpital.

Ce risque de réidentification par corrélation croisée n'est pas théorique. Il repose sur le fonctionnement même des architectures de type transformer : le modèle apprend des représentations vectorielles de concepts et de relations qui traversent les frontières entre les jeux de données. Un texte hospitalier « anonymisé » et un post Instagram de la même personne partagent des caractéristiques sémantiques que le modèle peut rapprocher... même si aucun identifiant direct ne figure dans le texte clinique.

Le problème s'aggrave lorsque ces données « anonymisées » sont utilisées pour l'affinage (fine-tuning) d'un modèle. L'affinage intensifie la mémorisation: le modèle apprend des associations plus fortes et plus spécifiques entre les données du corpus clinique. Des recherches ont démontré que plus de 50 % d'un jeu de données d'affinage peut être extrait verbatim dans certaines configurations. Le texte qu'un chercheur croyait avoir anonymisé se retrouve potentiellement reconstructible, non pas parce que l'anonymisation était mal faite, mais parce que le modèle dispose de suffisamment de contexte externe pour la contourner.

En d'autres termes : l'anonymisation protège contre un lecteur humain qui regarde un dossier isolé. Elle ne protège pas contre un système qui a lu des milliards de documents et qui peut recouper un texte clinique avec l'ensemble du web. Le bouclier a été conçu pour un adversaire qui n'existe plus.

Extraction de données d'entraînement. Lorsqu'un modèle est affiné sur des données cliniques, il peut mémoriser et restituer des séquences textuelles mot pour mot — incluant des noms, des diagnostics, des numéros d'identification. Des recherches ont montré que plus de 50 % d'un jeu de données d'affinage peut être extrait verbatim dans certaines configurations. Des gigaoctets de données peuvent être extraits de modèles récents par des techniques d'attaque ciblées.

Tests d'appartenance (membership inference). Il est possible de déterminer si le dossier d'un patient spécifique faisait partie des données d'entraînement d'un modèle, avec des taux de précision atteignant 0,9 dans certains contextes cliniques. Cette capacité crée un risque de réidentification même lorsque les données ont été anonymisées.

Injection de prompt et jailbreak. Un utilisateur malveillant peut manipuler un LLM médical pour contourner ses garde-fous, extraire des informations confidentielles ou produire du contenu inapproprié. Les modèles spécialisés en médecine affichent une vulnérabilité plus élevée aux requêtes malveillantes que les modèles généralistes — la spécialisation amplifie les risques de sécurité.

Inversion de modèle. Il est techniquement possible de reconstruire des données d'origine — y compris des images médicales — à partir des réponses d'un modèle, par des techniques d'attaque sophistiquées.

Biais algorithmique. Un algorithme utilisé par des hôpitaux américains pour prioriser les soins a présenté un biais racial systématique : à niveau de maladie égal, les patients noirs recevaient des scores de risque inférieurs, reproduisant mécaniquement les inégalités d'accès aux soins.

1.3 L'impact financier

Le coût moyen d'une brèche de données en santé est de 10,1 millions USD (environ 14 millions CAD au taux actuel). En contexte québécois, la Loi 25 prévoit des sanctions administratives pouvant atteindre 25 millions de dollars. Trente-neuf pour cent des brèches de données en santé sont attribuables à des menaces internes — c'est-à-dire des employés, souvent sans intention malveillante, qui exposent des données par négligence ou méconnaissance des risques.

2. Le cadre réglementaire québécois et ses exigences

2.1 La Loi 25 (Loi modernisant des dispositions législatives en matière de protection des renseignements personnels)

Depuis septembre 2024, la Loi 25 impose aux organismes publics et aux entreprises du Québec des obligations renforcées en matière de protection des données personnelles :

Évaluations des facteurs relatifs à la vie privée (EFVP) obligatoires pour tout projet impliquant des données sensibles, y compris les projets d'IA.
Notification obligatoire des incidents de confidentialité à la Commission d'accès à l'information (CAI) et aux personnes concernées.
Sanctions administratives pouvant atteindre 10 millions de dollars ou 2 % du chiffre d'affaires mondial.
Responsable de la protection des renseignements personnels obligatoire dans chaque organisme.
Transparence sur l'utilisation des technologies de décision automatisée.

Pour un CISSS ou un CIUSSS, toute utilisation d'IA générative qui touche aux données de santé tombe sous le périmètre de la Loi 25. L'absence de mécanisme de surveillance des interactions GenAI constitue un risque de non-conformité direct.

2.2 La LRSSS (Loi sur les renseignements de santé et de services sociaux)

La LRISP crée un cadre juridique spécifique à la circulation des données de santé au Québec. Elle introduit un consentement pouvant être implicite pour certaines utilisations liées à la recherche en santé — mais la question de savoir si ce consentement couvre l'utilisation secondaire des données pour entraîner un modèle d'IA n'est pas tranchée. Cette zone grise juridique expose les établissements à un risque d'interprétation judiciaire adverse.

La LRISP impose également des exigences de traçabilité : qui a accédé à quels renseignements, quand et pourquoi. Or, lorsqu'un employé soumet des données de santé à un LLM commercial, cette traçabilité est perdue. Le modèle absorbe l'information de manière diffuse et irréversible — il n'y a plus de « consultation » à tracer au sens du droit actuel.

2.3 Le Règlement sur l'anonymisation

Entré en vigueur en mai 2024, le Règlement sur l'anonymisation fait du Québec le premier territoire au Canada à encadrer spécifiquement les pratiques d'anonymisation. Il impose de démontrer que les risques résiduels de réidentification sont « très faibles ». Mais ce seuil n'est pas calibré par rapport aux capacités computationnelles des LLM. En 1997, trois variables (date de naissance, sexe, code postal) suffisaient à réidentifier 87 % de la population américaine. En 2026, un LLM peut analyser des centaines de variables simultanément avec une précision documentée de 84 à 95 %.

La CAI a commencé à intégrer les risques computationnels dans ses évaluations, mais les gabarits d'EFVP ne couvrent pas encore les vecteurs d'attaque spécifiques aux LLM : extraction de données d'entraînement, tests d'appartenance, inversion de modèle.

2.4 L'ÉPTC 2 et les comités d'éthique de la recherche

L'Énoncé de politique des trois conseils (ÉPTC 2, version 2022) encadre l'éthique de la recherche au Canada. Il ne contient aucune mention de l'intelligence artificielle, de l'apprentissage automatique ou de la cybersécurité. Les comités d'éthique de la recherche (CER) des établissements de santé évaluent des protocoles impliquant l'IA sans disposer des compétences techniques pour mesurer les risques computationnels. La formation FER-2022, recommandée par les trois organismes subventionnaires fédéraux, ne comprend aucun module sur l'IA.

2.5 Le vide fédéral

Le projet de loi C-27 (Loi sur l'intelligence artificielle et les données) est mort au feuilleton en janvier 2025. En avril 2026, le Canada n'a toujours pas de loi fédérale spécifique à l'IA. Le Québec dispose d'une marge de manœuvre provinciale importante en matière de santé, mais les établissements naviguent dans une mosaïque de lois générales dont aucune n'a été conçue pour encadrer les interactions avec les grands modèles de langage.

2.6 Jurisprudence pertinente

La jurisprudence québécoise récente confirme trois principes directement transposables à l'IA en santé :

Proportionnalité de l'accès : le Tribunal administratif du travail a conclu qu'un employeur qui s'était approprié un dossier médical complet avait utilisé un moyen disproportionné (Cardinal c. CSSMB, 2026 QCTAT 436). Si le droit exige la minimisation pour un seul dossier, l'exigence devrait être décuplée pour un modèle entraîné sur des millions.
Encadrement strict des technologies intrusives : un arbitre a imposé six conditions cumulatives pour autoriser un simple GPS sur des véhicules de travail — finalité étroite, intrusion minimale, absence de conservation des traces, accès restreint, politique écrite, interdiction d'usage disciplinaire (Valero, 2014 QCTA 78). En 2026, aucune exigence comparable n'encadre un LLM entraîné sur des dossiers médicaux.
Difficulté de réparation des atteintes informationnelles : la jurisprudence en matière de fuites de données (Li c. Equifax, Lévy c. Nissan, Zuckerman c. Target) montre que le « risque informationnel pur » — la simple détention non autorisée de données — ne constitue pas nécessairement un préjudice indemnisable. Or, l'IA transforme ce risque en capacité concrète d'exploitation.

3. Architecture de Prompt Security : vue d'ensemble

3.1 Positionnement dans l'écosystème

Prompt Security (acquis par SentinelOne en août 2025 pour environ 250 millions USD) est un pare-feu GenAI qui se positionne comme couche de sécurité entre les utilisateurs, les applications et les modèles de langage. Il ne remplace pas les contrôles de sécurité existants — il les complète en adressant spécifiquement les vecteurs de risque propres à l'IA générative.

3.2 Les trois vecteurs de protection

La plateforme opère sur trois axes simultanés :

3.3 Flux de données

Le principe fondamental est l'interception : toute interaction entre un utilisateur (ou une application) et un modèle de langage transite par Prompt Security, qui inspecte, filtre et journalise en temps réel.

Flux employé (extension navigateur) :

L'employé interagit avec un outil GenAI (ChatGPT, Claude, Gemini, etc.)
L'extension navigateur intercepte le contenu avant envoi
Prompt Security analyse le contenu contre les politiques configurées
Si des données sensibles sont détectées → masquage automatique ou blocage
L'interaction est journalisée dans le système d'audit
L'employé reçoit, si configuré, une explication du risque associé

Flux application interne (API/Gateway) :

L'application envoie une requête au domaine Prompt Security (au lieu du LLM directement)
Le système analyse le prompt et le system prompt contre les politiques
La requête nettoyée est transmise au fournisseur LLM
La réponse du LLM est interceptée et filtrée (données sensibles, prompt leak, contenu toxique)
La réponse filtrée est retournée à l'application
L'ensemble de l'interaction est journalisé

4. Protection des employés : contrôle de l'utilisation GenAI

4.1 Détection du Shadow AI

Le Shadow AI — l'utilisation non autorisée ou non surveillée d'outils d'IA par les employés — est le risque le plus immédiat dans le réseau de la santé. Un infirmier qui utilise ChatGPT pour résumer des notes cliniques, un chercheur qui colle des données patient dans Claude pour les analyser, un administrateur qui utilise Gemini pour rédiger un rapport contenant des informations confidentielles : autant de scénarios où des données de santé quittent le périmètre institutionnel sans contrôle.

Prompt Security détecte et cartographie l'utilisation de plus de 250 outils GenAI à travers l'organisation. Le déploiement s'effectue par extension navigateur compatible avec les méthodes de distribution d'entreprise :

Méthode de déploiement	Plateforme	Cas d'usage typique
Jamf	macOS	Postes cliniques Mac, postes de recherche
Kandji	macOS	Alternative à Jamf pour les déploiements Mac
Intune	Windows	Postes administratifs, postes de bureau
SCCM	Windows	Grands parcs Windows (réseau hospitalier)
MDM générique	Multi-plateforme	Déploiements mixtes
RemoteOps scripts	Multi-plateforme	Déploiements automatisés personnalisés

4.2 Politiques granulaires par rôle et département

Le système permet de configurer des politiques différenciées selon le rôle de l'employé dans l'organisation. Pour chaque outil GenAI détecté (ChatGPT, Claude, Gemini, Microsoft Copilot, Perplexity, et plus de 250 autres), trois niveaux de contrôle sont disponibles :

Autoriser : l'employé peut utiliser l'outil, avec surveillance et filtrage des données sensibles actifs.
Bloquer le téléversement de fichiers uniquement : l'employé peut interagir avec l'outil mais ne peut pas y envoyer de fichiers (prévient la fuite de documents cliniques, de rapports, de fichiers Excel contenant des données patient).
Bloquer complètement : l'accès à l'outil est bloqué pour ce rôle.

Un CISSS pourrait, par exemple, configurer les politiques suivantes :

Rôle	ChatGPT	Claude	Copilot	Gemini
Personnel clinique	Bloquer fichiers	Bloquer fichiers	Autoriser (avec DLP)	Bloquer
Chercheurs	Autoriser (avec DLP)	Autoriser (avec DLP)	Autoriser (avec DLP)	Autoriser (avec DLP)
Administration	Bloquer fichiers	Bloquer fichiers	Autoriser (avec DLP)	Bloquer fichiers
TI / Sécurité	Autoriser (avec DLP)	Autoriser (avec DLP)	Autoriser (avec DLP)	Autoriser (avec DLP)
Direction	Autoriser (avec DLP)	Autoriser (avec DLP)	Autoriser (avec DLP)	Autoriser (avec DLP)

Le contrôle s'étend aux comptes personnels : Prompt Security peut détecter et bloquer l'accès aux outils GenAI via les comptes personnels des employés (par opposition à leurs comptes institutionnels), empêchant le contournement des politiques organisationnelles.

4.3 Sensibilisation des employés

Lorsqu'une interaction est bloquée ou modifiée, le système peut afficher un message contextuel personnalisable expliquant le risque associé. Cette fonctionnalité est critique dans un contexte de santé où la résistance au changement est un facteur réel : plutôt que de simplement bloquer, le système éduque.

5. Protection des applications LLM internes

5.1 Le contexte québécois

Le Plan directeur sur l'IA en santé 2024-2027 du MSSS encourage le développement d'applications d'IA au sein du réseau. Les universités québécoises (Université de Montréal, McGill, Laval), les centres de recherche hospitaliers et les CISSS développent des modèles spécialisés ou intègrent des LLM commerciaux dans des applications cliniques. Ces applications — aide au diagnostic, triage, résumé automatique de dossiers, analyse d'imagerie — manipulent directement des données de santé sensibles.

5.2 Intégration par API

L'API Prompt Security (POST /api/protect) s'intègre dans le pipeline de toute application LLM. Elle inspecte séparément les prompts entrants et les réponses sortantes :

Requête API :
POST /api/protect
Headers :
  APP-ID: <clé API de l'application>
  Content-Type: application/json

Corps :
{
  "system_prompt": "Vous êtes un assistant médical...",
  "prompt": "<texte soumis par l'utilisateur>",
  "response": "<réponse du LLM à inspecter>"
}

Paramètres avancés :
  "policy_name": "politique-cisss-clinique"
  "policy": { <objet JSON de politique personnalisée> }
  "monitor_only": true/false

L'API supporte un mode monitor_only particulièrement pertinent pour la phase pilote : les interactions sont journalisées et analysées sans être bloquées, permettant de calibrer les politiques avant de les appliquer en production.

5.3 Intégration par AI Gateway (reverse proxy)

Pour les applications existantes, l'AI Gateway offre une intégration avec un changement minimal de code. L'application envoie ses requêtes au domaine Prompt Security plutôt qu'au fournisseur LLM directement :

Avant (connexion directe) :
  base_url = "https://api.openai.com/v1"

Après (via Prompt Security) :
  base_url = "https://<region>.prompt.security/"

Le mapping de proxy se configure dans le portail ou par programmation via des en-têtes HTTP (ps-app-id, forward-domain). Les 23+ fournisseurs LLM supportés incluent OpenAI, Anthropic (Claude), Azure OpenAI, Amazon Bedrock, Google Vertex AI, Cohere, Mistral, HuggingFace, Ollama, DeepSeek, et d'autres — couvrant la totalité des scénarios de déploiement réalistes dans le réseau de la santé.

5.4 Comparaison des deux méthodes

Critère	API	AI Gateway
Effort d'intégration	Modéré (appels à intégrer dans le code)	Minimal (changement d'URL)
Granularité du contrôle	Maximale (politique par appel)	Politique par application
Gestion programmatique des politiques	Oui	Non
Latence en mode monitor	Zéro (exécution parallèle)	Standard
Fournisseurs LLM supportés	Tous (agnostique)	23+ fournisseurs supportés
Cas d'usage recommandé	Applications critiques, recherche	Déploiement rapide, applications existantes

6. Détection et prévention de la fuite de données de santé

6.1 DLP sémantique : au-delà du pattern matching

La prévention de fuite de données (DLP) de Prompt Security va au-delà de la détection par expressions régulières (regex). Le système utilise une analyse linguistique contextuelle (NLP) pour identifier les données sensibles en fonction de leur signification, pas seulement de leur format.

Cela signifie que le système peut détecter :

Un numéro d'assurance maladie RAMQ même s'il est formaté de manière non standard
Une combinaison de quasi-identifiants (code postal + date de naissance + sexe) qui, ensemble, permettent la réidentification — exactement le scénario démontré par la chercheuse du MIT en 1997
Des descriptions cliniques contenant des informations identifiantes implicites (« le patient de 73 ans du CHSLD de Rivière-du-Loup avec un diagnostic de... »)
Des données de santé protégées (PHI) enfouies dans du texte narratif

6.2 Types de données détectés

Données personnelles identifiantes (PII) :

Numéros d'assurance sociale
Numéros de cartes de crédit
Numéros de passeport
Numéros de permis de conduire
Adresses courriel et numéros de téléphone

Données de santé protégées (PHI) :

Numéros de dossiers médicaux
Informations d'assurance maladie
Diagnostics et traitements
Résultats d'examens
Notes cliniques contenant des informations identifiantes

Données confidentielles organisationnelles :

Secrets commerciaux et données propriétaires
Informations confidentielles internes
Données contractuelles et ententes

6.3 Configuration de types de données personnalisés

Le système permet de définir des types de données sensibles spécifiques à l'organisation — une capacité critique pour le réseau de santé québécois dont les formats de données diffèrent des standards américains :

Numéros d'assurance maladie RAMQ (format québécois spécifique)
Identifiants de dossier patient propres à chaque établissement
Codes d'établissement MSSS
Terminologie clinique sensible dans le contexte institutionnel
Noms de programmes, de projets de recherche ou de protocoles confidentiels

Le blocage par mots-clés (« Blocking or Grouping Specific Keywords ») ajoute une couche supplémentaire permettant de filtrer des termes ou des expressions spécifiques à l'organisation.

6.4 Modes d'action

Lorsqu'une donnée sensible est détectée, le système offre plusieurs réponses configurables :

Masquage (redaction) : la donnée sensible est remplacée par un token avant d'atteindre le LLM, préservant le contexte de la requête tout en protégeant l'information
Blocage complet : l'interaction est stoppée et l'utilisateur est informé
Alerte : l'interaction est autorisée mais une alerte est envoyée à l'équipe de sécurité
Journalisation : l'événement est consigné sans intervention (mode surveillance)

La latence de détection est inférieure à 200 millisecondes — imperceptible pour l'utilisateur.

7. Défense contre les attaques sur les modèles

7.1 Moteur de détection d'injection de prompt

L'injection de prompt est le vecteur d'attaque le plus courant contre les applications LLM. Un attaquant insère des instructions malveillantes dans le prompt pour manipuler le comportement du modèle — exfiltrer des données, contourner les garde-fous, exécuter des commandes non autorisées.

Le moteur de Prompt Security détecte les tentatives d'injection en temps réel, avant qu'elles n'atteignent le modèle. La détection couvre :

L'injection directe (instructions malveillantes dans le prompt utilisateur)
L'injection indirecte (instructions cachées dans des documents ou des données que le modèle traite)
Les techniques d'encodage et d'obfuscation visant à contourner les filtres

7.2 Détection de jailbreak

Le détecteur de jailbreak identifie les tentatives de contourner les restrictions et les garde-fous du modèle. Ceci est particulièrement critique pour les modèles médicaux, car la recherche a démontré que les modèles spécialisés en médecine sont plus vulnérables aux requêtes malveillantes que les modèles généralistes.

7.3 Détection de fuite de prompt (Prompt Leak)

Le détecteur de fuite de prompt empêche le modèle de révéler ses instructions système, sa logique interne ou ses politiques de configuration. Dans un contexte de santé, les instructions système d'un modèle clinique peuvent contenir des règles métier, des protocoles de triage, des seuils d'alerte — des informations propriétaires dont la divulgation pourrait compromettre le système.

7.4 Durcissement des prompts (Prompt Hardening)

Le système offre des capacités de renforcement proactif des prompts système, rendant les applications LLM plus résistantes aux attaques. Un outil open-source complémentaire — Prompt Fuzzer — permet de tester et durcir les prompts système avant le déploiement.

7.5 Contrôle du débit de tokens (Token Rate Limiting)

Le contrôle du débit de tokens protège contre les attaques de type « Denial of Wallet/Service » — où un attaquant engage excessivement un modèle pour causer une surconsommation de ressources et des coûts financiers élevés. Cette protection assure l'intégrité et la disponibilité des applications.

7.6 Modération de contenu

Le système comprend des capacités de modération de contenu qui détectent et filtrent :

Le contenu toxique, biaisé ou discriminatoire
Le contenu inapproprié ou hors sujet
Les écarts de sentiment (réponses négatives ou alarmistes dans un contexte clinique)
Les sujets hors périmètre (détecteur de sujets)

Cette capacité adresse directement le risque de biais algorithmique documenté dans la jurisprudence (Beaulieu c. Facebook, 2022 QCCA 1736) et les précédents américains sur les algorithmes discriminatoires en santé.

8. Conformité, audit et preuve de diligence raisonnable

8.1 L'enjeu de la diligence raisonnable sous la Loi 25

La Loi 25 impose aux organismes de mettre en place des « mesures de sécurité raisonnables ». En cas d'incident impliquant l'IA générative, la capacité d'un établissement à démontrer qu'il avait déployé des contrôles spécifiques aux LLM sera déterminante — tant pour les sanctions de la CAI que pour la responsabilité civile.

Un établissement sans pare-feu GenAI qui subit une fuite de données via un outil d'IA sera dans une position de défense considérablement plus faible qu'un établissement qui peut démontrer :

Une cartographie complète de l'utilisation GenAI dans l'organisation
Des politiques de protection actives et documentées
Une journalisation exhaustive des interactions
Des alertes et des actions correctives en temps réel

8.2 Système d'audit de Prompt Security

Le système d'audit capture les événements par catégorie :

Événements de connecteur : création, modification et suppression des connecteurs (applications surveillées). Chaque changement de configuration est tracé avec horodatage, auteur et détail de la modification.

Événements de configuration : toute modification aux politiques de sécurité, aux paramètres de l'extension navigateur, aux règles de filtrage. Cela constitue une trace d'audit conforme aux exigences de la Loi 25 sur la documentation des mesures de sécurité.

Événements d'application GenAI : processus d'intégration, changements de règles, modifications de paramètres de sécurité, modifications des rôles utilisateurs, modifications des paramètres globaux.

Événements d'intégration : modifications aux intégrations avec les systèmes externes (Microsoft Entra, Okta, Google Workspace, Slack, Splunk, etc.).

8.3 Intégrations d'exportation de logs

Les logs d'audit peuvent être exportés vers les systèmes d'information de sécurité existants :

Destination	Type	Cas d'usage
Splunk	SIEM	Corrélation avec les événements de sécurité globaux
Kafka	Streaming	Ingestion en temps réel dans un pipeline de données
S3 (AWS)	Stockage objet	Archivage à long terme pour conformité
Webhook générique	HTTP	Intégration avec tout système de notification
Singularity (SentinelOne)	XDR	Corrélation avec la plateforme de sécurité endpoint
OpenAI Compliance API	API	Conformité spécifique aux modèles OpenAI
Slack	Messagerie	Alertes en temps réel aux équipes de sécurité

8.4 Contrôle d'accès basé sur les rôles (RBAC)

Le portail de gestion implémente trois niveaux de rôles :

Administrateur : accès complet — gestion des utilisateurs, configuration des politiques, visualisation de tous les logs. Destiné aux responsables TI et aux CISO.

Éditeur : gestion des configurations, des politiques et des intégrations, accès au terrain de test des politiques (playground). Ne peut pas gérer les comptes utilisateurs. Destiné aux analystes de sécurité.

Visualiseur : accès en lecture seule à la plupart des sections, accès au playground de test. Ne peut pas modifier les configurations. Destiné aux auditeurs, aux responsables de la protection des renseignements personnels, aux membres de CER.

Les intégrations SSO supportées (Microsoft Entra ID, Google Workspace, Okta) permettent l'intégration avec les annuaires existants du réseau de la santé.

8.5 Alignement avec les gabarits d'EFVP

Les rapports générés par Prompt Security peuvent alimenter directement les sections suivantes des EFVP :

Inventaire des flux de données : cartographie des outils GenAI utilisés, des types de données échangées et des volumes
Analyse des risques : incidents détectés, tentatives de fuite bloquées, attaques interceptées
Mesures d'atténuation : politiques en place, taux de blocage, couverture de surveillance
Traçabilité : logs complets des interactions avec horodatage et identification des utilisateurs

9. Déploiement souverain : options on-premise et auto-hébergé

9.1 Pourquoi le déploiement on-premise est critique en santé

La souveraineté des données est un enjeu non négociable pour le réseau de la santé québécois. L'affaire DeepMind/NHS (accès aux données de 1,6 million de patients sans consentement adéquat), le cas Sidewalk Labs à Toronto et la jurisprudence Royer c. Capital One (fuite de données via un sous-traitant) illustrent les risques de dépendance aux tiers technologiques.

Prompt Security offre un déploiement entièrement on-premise où aucune donnée de santé ne quitte l'infrastructure de l'établissement.

9.2 Architecture on-premise

Le déploiement s'effectue via Helm Charts sur Kubernetes, avec support pour :

AWS EKS (Elastic Kubernetes Service)
Azure AKS (Azure Kubernetes Service)
Google GKE (Google Kubernetes Engine)
Kubernetes on-premise auto-géré
Red Hat OpenShift

L'architecture comprend plus de 20 microservices répartis en quatre catégories :

Services de base : frontend, backend, passerelle API, services d'administration.

Services de protection : détection de données sensibles, sanitisation de fichiers, détection de secrets, jugement par LLM — ce sont les composants qui effectuent l'analyse en temps réel.

Services d'intégration : proxy OpenAI, traitement des logs, intégration SIEM.

Services stateful : PostgreSQL (configuration et politiques — critique), OpenSearch (logs d'activité), Kafka (file d'attente d'événements), Redis (cache).

9.3 Exigences d'infrastructure

Composant	Spécification minimale
Version Kubernetes	1.30+
Nœuds CPU	3 minimum, 16+ cœurs, 32 Go RAM, 50 Go stockage chacun
Nœuds GPU	1-2 NVIDIA A10/A10G/L4/T4, 16-24 Go VRAM
Stockage Redis	1 Go
Stockage PostgreSQL	1 Go
Stockage Kafka	10 Go
Stockage OpenSearch	120 Go+ (logs)
Réseau	Liens internes haute vitesse, faible latence

Ces exigences sont réalistes pour un CISSS ou un CIUSSS disposant d'une infrastructure Kubernetes existante ou en cours de modernisation.

9.4 Modes de déploiement

Mode services externes : utilise des services managés (base de données, cache, etc.), réduisant la charge d'infrastructure locale. Recommandé pour les déploiements hybrides.

Mode auto-contenu : déploie tous les services stateful à l'intérieur du Helm Chart. Nécessite un StorageClass Kubernetes. Recommandé pour les environnements isolés.

9.5 Registre d'images privé

Pour les environnements air-gapped ou fortement restreints, un script automatisé permet de télécharger les images de conteneurs depuis le registre Prompt Security (ghcr.io), de les pousser vers un registre privé interne, puis de configurer le déploiement pour utiliser ce registre local. Cela garantit que l'installation peut se faire sans accès Internet continu.

9.6 Connectivité minimale requise

Même en déploiement on-premise, deux connexions externes sont nécessaires :

global.prompt.security : accès au portail de gestion (interface web d'administration)
auth.prompt.security : authentification des utilisateurs du portail

Ces connexions ne transportent pas de données de santé — elles servent uniquement à la gestion de la plateforme. Les interactions entre les employés, les applications et les LLM sont traitées localement.

10. Scénarios d'implantation dans le réseau québécois

10.1 Scénario 1 — CISSS : cartographier le Shadow AI (phase pilote)

Contexte : Un CISSS souhaite comprendre l'étendue de l'utilisation non autorisée d'outils GenAI par ses employés avant de définir une politique.

Déploiement : Extension navigateur déployée via Intune (Windows) et Jamf (Mac) sur l'ensemble du parc. Configuration en mode surveillance uniquement (monitor-only) pendant 90 jours.

Résultats attendus :

Inventaire complet des outils GenAI utilisés (nombre d'outils, fréquence, départements)
Identification des cas de fuite de données sensibles (PHI, PII) vers des LLM commerciaux
Rapport de risque documenté alimentant l'EFVP obligatoire sous la Loi 25
Base factuelle pour l'élaboration d'une politique institutionnelle d'utilisation de l'IA

Effort : Déploiement en quelques jours. Aucune modification de l'infrastructure existante.

10.2 Scénario 2 — Centre de recherche universitaire : sécuriser un protocole LLM

Contexte : Un centre de recherche hospitalier universitaire développe un modèle de langage affiné sur des données cliniques. Le protocole est soumis au CER.

Déploiement : API Prompt Security intégrée dans le pipeline de données du projet de recherche. Le CER exige le déploiement comme condition d'approbation du protocole.

Configuration :

Filtrage des outputs du modèle pour détecter la restitution de données d'entraînement (extraction verbatim)
Protection contre les attaques d'injection de prompt sur le modèle en développement
Détection de fuite de prompt système
Mode monitor-only en phase de développement, puis blocage actif avant le déploiement clinique
Logs d'audit exportés vers le système de gestion de la recherche

Valeur pour le CER : Un rapport technique documenté montrant que les risques d'extraction de données d'entraînement sont contrôlés — compensant le déficit de compétence en sécurité des modèles au sein du comité.

10.3 Scénario 3 — CIUSSS : protéger une application d'aide au diagnostic

Contexte : Un CIUSSS déploie une application d'aide au diagnostic utilisant un LLM commercial (via Azure OpenAI) alimenté par des données cliniques.

Déploiement : AI Gateway (reverse proxy) intégré entre l'application et Azure OpenAI. Changement d'une seule ligne de configuration (URL de base).

Protections actives :

DLP sémantique sur les requêtes envoyées au modèle (masquage des PHI avant envoi)
Filtrage des réponses pour détecter le contenu biaisé, toxique ou cliniquement inapproprié
Protection contre les injections de prompt par les utilisateurs
Limitation du débit de tokens (protection contre le Denial of Wallet)
Journalisation complète pour audit de conformité

Alignement réglementaire : Les logs de Prompt Security documentent chaque interaction avec le LLM, rétablissant la traçabilité exigée par la LRISP pour les renseignements de santé.

10.4 Scénario 4 — MSSS : cadre de gouvernance provincial

Contexte : Le MSSS souhaite, dans le cadre de son Plan directeur sur l'IA en santé 2024-2027, établir un cadre de gouvernance technique pour l'utilisation de l'IA générative dans le réseau.

Approche : Prompt Security est déployé comme couche de sécurité standardisée à l'échelle du réseau, avec des politiques centralisées et une visibilité agrégée.

Composantes :

Politiques de sécurité GenAI standardisées pour l'ensemble du réseau
Tableau de bord centralisé pour le suivi de la conformité
Exigence de déploiement intégrée dans les gabarits d'EFVP révisés de la CAI
Exigence de déploiement comme condition d'approbation des CER pour les protocoles IA
Rapports de conformité agrégés pour la reddition de comptes

11. Conclusion : combler le décalage avant l'incident

Le réseau de la santé québécois dispose de fondations juridiques et éthiques solides pour la protection des données de santé. La Loi 25, la LRISP, le Règlement sur l'anonymisation et les travaux de la CAI constituent un dispositif parmi les plus avancés au Canada.

Mais ces fondations ont été bâties pour un monde où les menaces étaient ponctuelles, individuelles et traçables. L'IA générative a changé la nature du risque : les données ne sont plus seulement consultées — elles sont apprises, corrélées, mémorisées et potentiellement restituées par des modèles dont le fonctionnement interne échappe aux contrôles traditionnels.

Le décalage entre les obligations légales et les capacités de contrôle technique des établissements crée une vulnérabilité structurelle. Ce n'est pas un problème théorique : les risques d'extraction de données d'entraînement, d'inférence d'attributs personnels et de fuite de données vers des LLM commerciaux sont documentés dans la littérature scientifique avec des niveaux de précision qui devraient préoccuper tout responsable de la protection des renseignements personnels.

Prompt Security adresse ce décalage en fournissant une couche de sécurité spécifiquement conçue pour les risques GenAI — DLP sémantique, détection du Shadow AI, protection des applications LLM internes, audit complet — dans un modèle de déploiement compatible avec les exigences de souveraineté des données du réseau de la santé.

La question n'est plus de savoir si les établissements de santé ont besoin d'un pare-feu GenAI. La question est de savoir combien de temps ils peuvent se permettre de ne pas en avoir — alors que la Loi 25 est en vigueur, que les outils GenAI sont déjà utilisés par leurs employés, et que le premier incident documenté au Québec n'est qu'une question de temps.

Annexe A — Références réglementaires

Texte	Entrée en vigueur	Pertinence IA
Loi 25 (protection des renseignements personnels)	Septembre 2024 (dernière phase)	EFVP obligatoires, sanctions de 25M$, notification d'incidents
LRISP (renseignements de santé)	Progressive	Traçabilité des accès, consentement, circulation des données
Règlement sur l'anonymisation	Mai 2024	Seuil de « risque très faible » de réidentification
ÉPTC 2 (éthique de la recherche)	2022	Cadre des CER — aucune mention de l'IA
Formation FER-2022	2022	Formation des CER — aucun module IA
Plan directeur IA en santé MSSS	2024-2027	Gouvernance responsable de l'IA en santé
Projet de loi C-27	Mort au feuilleton (jan. 2025)	Vide fédéral en matière d'IA

Annexe B — Jurisprudence citée

Cardinal c. CSSMB, 2026 QCTAT 436 — captation disproportionnée d'un dossier médical
Énergie Valero, 2014 QCTA 78 — six conditions cumulatives pour la surveillance GPS
CISSS de la Gaspésie, 2022 QCTA 190 — consultation illicite de dossiers médicaux
CISSS de Lanaudière, 2022 QCTA 397 et 2023 QCTA 473 — consultation illicite
CIUSSS Mauricie–Centre-du-Québec, 2022 QCTA 499 — consultation illicite
Beaulieu c. Facebook, 2022 QCCA 1736 — biais algorithmiques
Royer c. Capital One, 2025 QCCA 217 — fuite de données et tiers technologiques
Li c. Equifax, 2019 QCCS 4340 — fuites de renseignements personnels
Lévy c. Nissan, 2019 QCCS 3957 — fuites de renseignements personnels
Zuckerman c. Target, 2017 QCCS 110 — fuites de renseignements personnels

Ce document est fourni à titre informatif. Il ne constitue pas un avis juridique. Les établissements sont invités à consulter leurs conseillers juridiques pour l'interprétation des obligations réglementaires applicables à leur contexte.

Au Québec, les gardiens de nos données de santé sont-ils outillés pour l'ère de l'IA ?

Pier-Luc Charbonneau — Wed, 08 Apr 2026 00:37:48 GMT

Le Québec a bâti l'un des dispositifs de protection des données les plus avancés au Canada. Mais face aux capacités des grands modèles de langage, ce dispositif repose sur des hypothèses que la technologie a déjà invalidées.

Quelque part au Québec, un comité d'éthique de la recherche examine un protocole. Un chercheur propose d'affiner un grand modèle de langage à partir de dizaines de milliers de dossiers cliniques. Le comité compte cinq membres : une bioéthicienne, un juriste spécialisé en droit de la santé, une médecin, un chercheur en sciences infirmières et un représentant communautaire. Cinq personnes compétentes, consciencieuses, animées par la volonté de protéger les patients.

Aucune d'entre elles n'a de formation en apprentissage automatique, en sécurité des modèles ou en cybersécurité computationnelle. Aucun texte normatif ne l'exige. Aucune formation recommandée ne l'offre.

Elles approuvent le protocole. Elles ont fait leur travail. La question est de savoir si ce travail, tel qu'il est défini aujourd'hui, suffit encore.

Le système tel qu'il est : des fondations solides pour un autre monde

Il existe au Québec un contrat social implicite autour des données de santé. Quand vous consultez un médecin, passez une IRM, recevez un diagnostic, vous confiez des informations parmi les plus intimes qui soient à un système qui promet de les protéger. Et ce système existe. Il est structuré, il est encadré, et il a produit des avancées réelles.

L'Énoncé de politique des trois conseils — l'ÉPTC 2, dans sa version de 2022 — constitue le cadre normatif central pour l'éthique de la recherche au Canada. Il régit les comités d'éthique de la recherche (CER) et impose des principes puissants : proportionnalité des risques, minimisation, consentement éclairé. Ces principes sont génériques par conception — ils visent à couvrir l'ensemble des méthodologies de recherche, y compris celles qui n'existaient pas au moment de la rédaction. En théorie, un CER peut invoquer la proportionnalité pour exiger qu'un chercheur démontre que son modèle d'IA ne mémorisera pas de séquences identifiantes. En théorie.

Le Québec a complété cet édifice par un arsenal législatif récent et, sur plusieurs plans, pionnier au Canada. La Loi 25, en vigueur depuis septembre 2024, a renforcé considérablement la gouvernance des données personnelles : transparence accrue, sanctions pouvant atteindre 25 millions de dollars. La Loi sur les renseignements de santé et de services sociaux (LRSSS) a créé un cadre juridique spécifique à la circulation des données de santé. Le Règlement sur l'anonymisation, en vigueur depuis mai 2024, fait du Québec le premier territoire au Canada à encadrer spécifiquement ces pratiques. Les évaluations des facteurs relatifs à la vie privée (EFVP) sont obligatoires pour les projets impliquant des données sensibles.

Les choses bougent aussi du côté institutionnel. Le MSSS a publié un Plan directeur sur l'IA en santé 2024-2027 qui reconnaît l'importance de la gouvernance responsable. La Commission d'accès à l'information (CAI) a commencé à intégrer, dans ses évaluations, une analyse des risques d'inférence par capacités computationnelles. Certains CER québécois, de leur propre initiative, ont commencé à inviter des experts en informatique à titre consultatif pour les protocoles impliquant l'IA.

Ce n'est pas de l'inaction. C'est un système en transition. La question — la vraie question — est de savoir si cette transition est assez rapide face à ce que la technologie est devenue.

Ce que l'IA a changé : quand le risque mute

Pour comprendre l'urgence, il faut mesurer l'ampleur du décalage. Ce n'est pas une question d'ajustements à la marge. C'est un changement de nature du risque.

Un clinicien qui consulte un dossier patient agit sur des données isolées, dans un contexte défini, avec une mémoire humaine limitée. Un grand modèle de langage entraîné sur des millions de dossiers ne consulte pas : il apprend. Il établit des corrélations transversales entre des variables que personne n'aurait pensé à croiser. Cette différence n'est pas quantitative — elle est qualitative.

Les chiffres sont sans appel. GPT-4 atteint une précision de 84 % — et jusqu'à 95 % dans ses trois meilleures hypothèses — pour déterminer des attributs personnels sensibles (âge, sexe, localisation, état de santé) à partir de texte apparemment anodin. Dans certaines configurations, plus de 50 % d'un jeu de données utilisé pour affiner un modèle peut être extrait verbatim. La déidentification protégeait les patients quand les outils de réidentification étaient primitifs. Le bouclier est resté le même ; l'arme a changé.

Une taxonomie entière de nouvelles menaces s'est développée. On peut désormais déterminer si le dossier d'un patient spécifique faisait partie des données d'entraînement d'un modèle — c'est ce qu'on appelle un test d'appartenance, avec des taux de précision atteignant 0,9 dans certains contextes cliniques. On peut reconstruire des données d'origine — y compris des images médicales — à partir des réponses du modèle, par une technique dite d'inversion. On peut extraire des séquences textuelles mot pour mot, incluant des noms, des diagnostics, des numéros d'identification.

Un fait particulièrement contre-intuitif : les modèles spécialisés en médecine affichent une vulnérabilité plus élevée aux requêtes malveillantes que les modèles généralistes. La spécialisation censée améliorer la pertinence clinique amplifie simultanément les risques de sécurité — probablement parce que le modèle apprend des corrélations plus fortes et plus spécifiques dans son domaine.

Certains répondront — et ils n'ont pas entièrement tort — que ces risques sont démontrés en laboratoire, sur des modèles génériques, et que la transposition directe aux modèles médicaux développés en contexte réglementé est plus nuancée. Le volume de données cliniques est souvent plus restreint, les mesures de sécurité plus avancées que celles des modèles grand public. C'est vrai. Mais la trajectoire est claire : ce qui était difficile — impossible, croyait-on — devient trivial. Ce qui était coûteux devient accessible. Ce qui était improbable devient systématique. Attendre qu'un incident québécois documenté confirme le risque, c'est confondre la preuve et la prudence.

Les gardiens : quand le texte normatif ne suit plus

L'ÉPTC 2 ne contient pas un seul mot sur l'intelligence artificielle, l'apprentissage automatique ou la cybersécurité. C'est le texte qui encadre la recherche sur l'IA en santé au Canada.

Ses défenseurs rétorqueront que c'est par conception : l'ÉPTC 2 est écrit en principes généraux (proportionnalité, minimisation, consentement) qui s'appliquent à toute méthodologie de recherche, y compris l'IA. C'est un argument qui se vaut. Mais un principe général ne remplace pas une compétence spécifique. La proportionnalité permet en théorie de refuser un projet mal conçu. Encore faut-il que les évaluateurs sachent identifier qu'il est mal conçu. Quand un chercheur soumet un protocole impliquant l'affinage d'un modèle de langage sur des données cliniques, la question n'est pas de savoir si le principe de proportionnalité existe. La question est de savoir si les personnes autour de la table ont les compétences pour évaluer si une technique d'anonymisation résiste aux attaques par inférence, si l'architecture du système introduit des canaux de fuite, ou si le modèle risque de mémoriser des séquences identifiantes.

La formation ne comble pas cette lacune. La formation FER-2022, recommandée par les trois organismes subventionnaires fédéraux, comprend environ quatre heures de contenu en ligne. Aucun module ne traite de l'IA, des modèles de langage, de la cybersécurité ou des risques d'inférence computationnelle. Cette formation n'est d'ailleurs pas obligatoire pour les membres des CER eux-mêmes.

La comparaison internationale est éclairante. Aucune juridiction majeure n'a encore mandaté formellement l'inclusion d'experts en IA dans les comités d'éthique. Le retard est partagé. Mais des initiatives émergent. Aux États-Unis, un sous-comité fédéral a publié des recommandations reconnaissant que les comités d'éthique manquent de compétences techniques pour évaluer les projets d'IA. Des universités développent des suppléments spécifiques. En Europe, des projets financés développent des formations ciblées. Au Canada, au niveau fédéral, aucune action formelle comparable n'a été documentée — même si, au Québec, des universités comme l'Université de Montréal et McGill ont commencé, depuis 2024, à développer leurs propres suppléments IA pour les demandes aux CER. Ce mouvement est réel, mais il est informel, inégal, et dépend de la bonne volonté locale.

Les précédents : une chronologie de la confiance mal placée

L'histoire de l'IA en santé est jalonnée d'épisodes où des institutions ont fait confiance à des systèmes qu'elles ne comprenaient pas pleinement. Ce ne sont pas des fables dystopiques. Ce sont des faits.

En 1997, une chercheuse du MIT a démontré que 87 % de la population américaine pouvait être identifiée de manière unique par trois variables seulement : date de naissance, sexe et code postal. Elle a réidentifié le gouverneur du Massachusetts à partir de données de santé prétendument anonymisées. Si trois variables suffisaient en 1997, que faut-il attendre d'un modèle capable d'en analyser des centaines simultanément ?

En 2015, Google DeepMind a obtenu l'accès aux données de 1,6 million de patients du système de santé britannique sans consentement adéquat. Le commissaire à l'information a conclu que l'hôpital partenaire avait violé la législation. Le cas illustre le glissement de périmètre : un projet de recherche initial qui se transforme en accès massif à des données non liées au périmètre annoncé.

En 2019, une étude publiée dans Science a révélé qu'un algorithme utilisé par des hôpitaux américains pour prioriser les soins présentait un biais racial systématique : à niveau de maladie égal, les patients noirs recevaient des scores de risque significativement inférieurs. L'algorithme utilisait les coûts de santé passés comme indicateur de la gravité future, reproduisant mécaniquement les inégalités d'accès aux soins.

Plus récemment, des chercheurs de Google Brain et de l'ETH Zurich ont démontré qu'il était possible d'extraire des centaines de séquences textuelles mot pour mot à partir de grands modèles de langage, incluant des noms, des numéros de téléphone, des adresses. Des gigaoctets de données peuvent être extraits de modèles récents.

Le fil conducteur n'est pas la malveillance. C'est la confiance — la confiance d'institutions qui ont approuvé, déployé ou toléré des systèmes dont elles ne mesuraient pas les risques. Ce pattern se reproduit aujourd'hui dans un contexte où les enjeux sont plus élevés.

Ce que nos tribunaux ont compris — et ce qu'ils n'ont pas encore vu venir

La jurisprudence québécoise révèle un système juridique qui a développé des réflexes solides face aux intrusions dans les données sensibles. Ces réflexes sont précieux. Mais ils ont été façonnés par un monde où les menaces étaient ponctuelles, individuelles et traçables.

En 2026, le Tribunal administratif du travail a conclu qu'un employeur s'était approprié un dossier médical complet qui ne lui était pas destiné. Le tribunal a souligné qu'il existait des moyens moins intrusifs — un résumé par le médecin-conseil plutôt que la captation du dossier complet. C'est exactement la logique de minimisation qu'il faudrait transposer à l'IA. Si le droit exige la minimisation pour un employeur qui consulte un seul dossier, quelle exigence devrait s'appliquer à un modèle entraîné sur des millions ?

En 2014, un arbitre québécois a accepté des outils de surveillance GPS sur des véhicules de travail — mais seulement en imposant six conditions cumulatives : finalité étroite, intrusion minimale, absence de conservation des traces, accès restreint, politique écrite, interdiction d'usage disciplinaire. Six conditions pour un GPS. En 2026, aucune exigence comparable n'encadre un modèle de langage entraîné sur des millions de dossiers médicaux.

Plusieurs décisions arbitrales récentes illustrent le traitement de la consultation illicite de dossiers médicaux par des employés du réseau de la santé. Le système sait penser en termes de personne fautive qui ouvre un dossier sans droit, découverte par journalisation informatique. Mais un grand modèle de langage change l'échelle : il ne « regarde » pas un dossier par curiosité — il absorbe des régularités sur des milliers de dossiers simultanément. Le droit de la vie privée au Québec repose sur une architecture de la traçabilité : qui a consulté quoi, quand, pourquoi. Et encore, les systèmes actuellement en place pour s'assurer de la journalisation ne garde aucune trace du pourquoi. On assume que le professionnel était de bonne foie et avait le droit d'accéder. Quand un modèle absorbe des régularités à travers un corpus entier, il n'y a plus de « consultation » à tracer. Il y a un apprentissage diffus, massif et irréversible.

La Cour d'appel du Québec, dans l'affaire Beaulieu c. Facebook, a soulevé la question de la responsabilité des biais algorithmiques — signal que les tribunaux voient déjà le problème. L'affaire Royer c. Capital One illustre le risque de dépendance aux tiers technologiques : une faille chez un sous-traitant a permis l'accès à des données confidentielles. Dans un monde où des modèles d'IA en santé sont souvent développés ou hébergés par des entreprises privées, ce précédent résonne.

La jurisprudence en matière de fuites de données révèle une autre difficulté structurelle : le « risque informationnel pur » — la simple détention non autorisée de données — ne constitue pas nécessairement un préjudice indemnisable. Or, l'IA transforme précisément ce risque en capacité concrète d'exploitation. Le droit répare mal un préjudice qu'il peine encore à nommer.

Ces trois principes traversent le corpus : l'accès à des renseignements médicaux doit être proportionné ; les technologies intrusives doivent être strictement finalisées et gouvernées ; les atteintes informationnelles sont difficiles à réparer. Ce sont d'excellents principes. Ils devraient s'appliquer avec une rigueur redoublée aux systèmes d'IA en santé. Le problème est qu'ils n'ont jamais été mis à l'épreuve du changement d'échelle que représentent les grands modèles de langage.

Les zones grises réglementaires : quand chaque texte est solide et que l'ensemble ne tient plus

Le Règlement sur l'anonymisation impose de démontrer que les risques résiduels de réidentification sont « très faibles ». Mais très faible par rapport aux capacités de 2020 ou à celles de 2026 ? Le texte ne le dit pas. La CAI a commencé à intégrer les risques computationnels dans ses évaluations — c'est un mouvement encourageant. Mais le Règlement lui-même ne fournit aucune guidance spécifique sur les techniques d'inférence propres aux grands modèles de langage.

La LRSSS introduit un consentement pouvant être implicite pour la recherche en santé. La question juridique qui en découle est vertigineuse : le consentement implicite du patient pour un soin médical couvre-t-il l'utilisation secondaire de ses données pour entraîner un modèle d'IA ? La loi ne tranche pas. Et il faut le reconnaître : cette zone grise pourrait aussi bien être interprétée de manière restrictive — le consentement au soin ne suffit pas pour l'IA — que de manière permissive. Une cour n'a pas encore tranché. Le silence est un risque pour tout le monde.

Les gabarits d'EFVP de la CAI n'intègrent pas encore les vecteurs d'attaque spécifiques aux grands modèles de langage : extraction de données d'entraînement, tests d'appartenance, inversion de modèle. L'outil préventif existe ; son calibrage est en retard sur la menace.

Et au-dessus de tout cela, le vide fédéral. Le projet de loi C-27 est mort au feuilleton en janvier 2025. En avril 2026, le Canada n'a toujours pas de loi fédérale spécifique à l'IA. Le Québec a une marge de manœuvre provinciale importante en matière de santé — il n'est pas obligé d'attendre Ottawa pour agir. Mais les organisations qui développent l'IA opèrent dans une mosaïque de lois générales dont aucune n'a été conçue pour encadrer l'entraînement de modèles de langage à partir de données cliniques.

Ce n'est pas un seul maillon qui est défaillant. C'est la chaîne entière qui n'a pas encore été recalibrée.

L'asymétrie d'expertise : quand le privé sait et le public encadre

Il y a un problème structurel que personne ne semble vouloir nommer : une concentration significative des experts en sécurité de l'IA travaille pour les entreprises qui développent les modèles, pas pour les institutions qui les autorisent.

Le Québec n'est pas un désert en IA — loin de là. MILA, l'Université de Montréal, McGill comptent des chercheurs de renommée mondiale. Mais l'expertise en sécurité des modèles, en attaques adverses, en extraction de données d'entraînement — cette expertise de pointe est massivement concentrée dans les laboratoires d'Anthropic, d'OpenAI, de Google DeepMind, de Meta AI. Les institutions publiques québécoises — universités, hôpitaux, ministères, organismes de régulation — ne jouent pas dans la même ligue en termes de recrutement sur ce créneau spécifique.

Certains objecteront que les projets de recherche québécois en IA santé sont menés par des chercheurs académiques, pas par les géants technologiques, et que la dynamique de dépendance est donc différente. C'est en partie vrai. Mais à mesure que des systèmes d'IA commerciaux sont déployés dans les hôpitaux — pour le diagnostic, le triage, l'aide à la décision —, la question devient incontournable : les institutions qui autorisent ces déploiements ont-elles l'expertise pour en évaluer les risques de manière indépendante ?

L'épisode de Sidewalk Labs à Toronto a illustré cette dynamique : un quartier « intelligent » proposé par Alphabet, abandonné après des préoccupations majeures sur la gouvernance des données par un acteur privé. L'affaire DeepMind/NHS montre le même pattern. Quand l'expertise est concentrée du côté de celui qui développe, et que celui qui encadre en dépend pour évaluer le risque, la régulation risque de devenir une formalité plutôt qu'un contre-pouvoir.

Ce qu'il faudrait faire : cinq chantiers urgents

Ce texte n'est pas un réquisitoire. C'est un appel à l'accélération. Le Québec a les fondations. Il a les principes juridiques, les institutions et — chose rare — une culture de protection des données qui fait l'envie du reste du Canada. Mais les fondations ne suffisent plus si l'édifice n'est pas mis à jour. Voici cinq chantiers qui pourraient être engagés rapidement.

Premièrement, intégrer l'IA dans les cadres normatifs. L'ÉPTC 2 doit être complété par une guidance spécifique sur l'évaluation des risques liés aux grands modèles de langage. Des universités américaines ont développé des suppléments IA pour les demandes aux comités d'éthique. Des institutions québécoises ont commencé à faire de même, mais de manière informelle. Il faut formaliser ce mouvement et le rendre obligatoire.

Deuxièmement, renforcer les CER. Pas en remplaçant les bioéthiciens et les juristes — leur expertise reste indispensable — mais en mandatant l'accès à une expertise en sécurité des modèles pour tout protocole impliquant l'IA. Cela pourrait prendre la forme d'un consultant externe, d'un expert invité ou d'un réseau mutualisé entre institutions.

Troisièmement, mettre à jour la formation. La formation FER doit intégrer, avant la fin de 2026, un module substantiel sur les risques computationnels de l'IA en santé : mémorisation, inférence, extraction, opacité. Quatre heures sans un mot sur l'IA, en 2026, c'est un anachronisme.

Quatrièmement, clarifier les zones grises juridiques. La LRSSS doit trancher la question du consentement pour l'entraînement de modèles d'IA. Le Règlement sur l'anonymisation doit calibrer son seuil de « risque très faible » à la lumière des capacités computationnelles actuelles. Les gabarits d'EFVP doivent intégrer les vecteurs d'attaque propres aux grands modèles de langage. Mieux vaut que le gouvernement clarifie ces points que d'attendre qu'un tribunal soit forcé de le faire dans l'urgence d'un litige.

Cinquièmement, accélérer les travaux en cours. Le groupe de travail interministériel sur l'IA responsable, le Plan directeur du MSSS, les travaux de la CAI — ces initiatives existent et méritent d'être reconnues. Mais elles doivent déboucher sur des règles contraignantes, pas seulement sur des réflexions. La question est simple : à quelle vitesse ces réflexions se traduiront-elles en obligations ?

Ce que cela signifie : entre la fausse assurance et l'action

Rassemblons les pièces.

Des comités d'éthique dont aucun texte n'exige qu'ils comprennent l'IA, même si certains s'adaptent. Des lois pionnières mais calibrées sur les risques d'une époque antérieure. Des gabarits d'évaluation en cours de révision mais pas encore à jour. Un vide fédéral béant. Une concentration de l'expertise en sécurité du côté de ceux qui développent les modèles. Et, en face, des modèles capables d'inférer des attributs personnels avec 84 à 95 % de précision, de mémoriser et restituer des données d'entraînement, de reconstituer des images médicales à partir de leurs propres sorties.

Il n'y a pas, à ce jour, de cas documenté public où un grand modèle de langage entraîné sur des données de santé québécoises a causé une fuite de données patient. Le risque est démontré en laboratoire et dans d'autres contextes ; l'extrapolation au Québec est raisonnable mais reste une extrapolation. C'est précisément pour cela qu'il faut agir maintenant — avant que la preuve ne se fasse aux dépens d'un patient.

Si les évaluateurs ne comprennent pas les risques, leur approbation ne protège personne — elle rassure. L'approbation éthique devait être un garde-fou. Quand l'évaluateur ne comprend pas le risque, elle devient un dispositif de légitimation. Le tampon n'est pas vide — les CER font un travail rigoureux dans leur domaine de compétence. Mais ce domaine s'est élargi au-delà de ce que les textes et les formations leur permettent d'évaluer.

Il ne s'agit pas de jeter la pierre à quiconque. Les membres des CER ne sont pas négligents. Le gouvernement n'est pas inerte. Le Québec n'est pas en retard par laxisme — il est en transition. Mais une transition à la vitesse des cycles de révision institutionnels ne suffit pas quand la technologie évolue par cycles de mois. Le Québec a les outils, les principes et l'expertise pour devenir un leader en gouvernance éthique de l'IA en santé. Il ne lui manque que l'urgence.

Le problème n'est pas que nos institutions soient incompétentes. Le problème est que le risque a changé de nature — et que le système qui nous protège n'a pas encore fini de s'en rendre compte. La bonne nouvelle, c'est qu'il a commencé. La mauvaise, c'est que l'IA, elle, n'attend pas.

Jurisprudence citée :

Cardinal c. Centre de services scolaire Marguerite-Bourgeoys, 2026 QCTAT 436 (AZ-52189463) — captation disproportionnée d'un dossier médical
Travailleurs québécois de la pétrochimie, section locale 194 c. Énergie Valero, 2014 QCTA 78 (AZ-51045904) — encadrement strict des technologies de surveillance (GPS)
Syndicat des infirmières… c. CISSS de la Gaspésie, 2022 QCTA 190 — consultation illicite de dossiers médicaux
Syndicat des travailleuses et travailleurs… c. CISSS de Lanaudière, 2022 QCTA 397 — consultation illicite de dossiers médicaux
APTS c. CIUSSS Mauricie–Centre-du-Québec, 2022 QCTA 499 — consultation illicite de dossiers médicaux
Syndicat… c. CISSS de Lanaudière, 2023 QCTA 473 — consultation illicite de dossiers médicaux
Beaulieu c. Facebook inc., 2022 QCCA 1736 — responsabilité des biais algorithmiques
Royer c. Capital One Bank (Canada Branch), 2025 QCCA 217 (AZ-52099741) — fuite de données et dépendance aux tiers technologiques
Li c. Equifax inc., 2019 QCCS 4340 — fuites de renseignements personnels
Lévy c. Nissan Canada inc., 2019 QCCS 3957 — fuites de renseignements personnels
Zuckerman c. Target, 2017 QCCS 110 — fuites de renseignements personnels.