À 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.
