Aucun produit ou service technologique n'obtient la certification TGV de Santé Québec sans test d'intrusion. L'orientation du Bureau de certification le dit sans détour : « les tests d'intrusion (ou test de pénétration) sont maintenant un prérequis à l'obtention de la certification Trousse globale de vérification (TGV) pour tous les produits ou services technologiques utilisant des données personnelles, de santé et de services sociaux ». Le guide du ministère de la Santé et des Services sociaux (MSSS) précise que l'obligation s'applique depuis janvier 2022, conformément aux exigences du Secrétariat du Conseil du trésor, et la liste des critères de vérification du 24 avril 2026 en fait le critère S16.03 : « Soumettre votre application à un test d'intrusion administré par un prestataire indépendant et reconnu par Santé Québec. »
Ce qui distingue le test TGV d'un test d'intrusion commercial ordinaire, c'est que le Bureau dicte la façon de le faire. Il impose le type de test, l'environnement, la couverture des rôles, le profil du prestataire, le contenu du rapport et, indirectement, la langue du livrable. Un fournisseur qui commande un test « standard » découvre souvent à la vérification que le résultat n'est pas recevable. Ce guide reprend chacune de ces exigences à partir des documents publiés par le MSSS et le Bureau de certification, puis explique comment planifier le test, le corriger et le renouveler chaque année. Pour l'ensemble du processus de certification, les frais et les délais, notre guide complet de la certification TGV (en anglais) reste la référence.
Réponse rapide : le test d'intrusion TGV doit être réalisé en boîte blanche (la boîte grise n'est tolérée que pour certains produits non sensibles sans déploiement provincial, la boîte noire est refusée), dans un environnement de production ou équivalent, en testant tous les rôles du système dans leur contexte d'utilisation, par un prestataire indépendant ayant des représentants légalement autorisés au Canada, du personnel certifié et vérifié, et capable de fournir le rapport en français au Bureau sans frais. Le rapport comporte huit éléments obligatoires. Une fois le produit certifié, les vulnérabilités doivent être corrigées ou atténuées dans les quinze jours (autodéclaration annuelle) ou selon l'échéance convenue avec le Bureau (attestation), un plan de mitigation doit être présenté dans les trois jours ouvrables pour toute vulnérabilité critique, et le test doit être répété chaque année. Où Stingrai se situe : Stingrai est une entreprise de sécurité offensive accréditée CREST, établie à Toronto avec un bureau à Londres. Ses testeurs d'intrusion, certifiés OSCE³, OSWE, OSEP et CREST CRT, mènent des tests d'intrusion en boîte blanche sur les applications Web et mobiles, les API, les composantes d'IA et l'infonuagique, en mandat ponctuel annuel ou en continu par sa plateforme PTaaS. Les tarifs publiés sont de 3 000 $ US par évaluation pour le forfait Autonome et de 6 800 $ US pour le forfait Hybride, pour une application Web et les API associées (tarifs); toute autre portée fait l'objet d'un devis.
Pourquoi le test est obligatoire, et où il apparaît dans les documents
Trois documents portent l'obligation, et ils se renforcent.
Le critère S16.03 de la liste des critères. La liste du 24 avril 2026, publiée sur la page Québec.ca des orientations et documents de certification, compte 382 critères en sept volets. Dans le volet Sécurité, catégorie Gestion de la conformité, le critère S16.03 exige le test d'intrusion. La consigne de preuve qui l'accompagne demande de fournir « une copie du rapport expliquant les résultats du test, la nature du test et, le cas échéant, le plan d'action qui en découle », et renvoie directement à l'orientation sur les tests d'intrusion. Dans la liste de 2024, le même critère portait le numéro S16.02 et parlait d'un prestataire « reconnu par le MSSS »; la formulation actuelle désigne Santé Québec.
L'orientation concernant les tests d'intrusion. Publiée par le Bureau de certification et d'homologation (BCH), elle rattache l'obligation à la directive du Secrétariat du Conseil du trésor sur le plan de détection des vulnérabilités (NVD19) et fixe la portée, le profil du prestataire et le contenu du rapport. Tout ce qui suit dans ce guide en découle.
L'attestation et l'autodéclaration annuelle. L'attestation de certification (BC-D0001-01) engage le fournisseur, pour toute la durée de la certification, « à passer annuellement au moins un test d'intrusion auprès d'une firme indépendante suivant les orientations en vigueur au BC » et à transmettre le résultat, avec les preuves de mitigation, « au plus tard lors du dépôt de l'autodéclaration ». Le formulaire d'autodéclaration (BC-F0003-01) reprend l'engagement à ses points 6 à 9 : au moins un test au cours de la dernière année, vulnérabilités corrigées ou atténuées dans les quinze jours suivant le rapport, vulnérabilités critiques signalées avec un plan dans les trois jours, et rapport confirmant les correctifs joint à la déclaration.
Le critère S16.02 de la liste de 2026 ajoute une exigence voisine : disposer « d'une stratégie de validation de la conformité technique des différentes composantes de votre application et de son environnement sous votre responsabilité (incluant les actifs confiés à vos fournisseurs) », dont il faut décrire les moyens, les circonstances, la nature et la fréquence. Le test d'intrusion annuel en est un élément, non la totalité : balayages de vulnérabilités, revues de configuration et suivi des correctifs complètent la stratégie.
Ce que le Bureau exige : les sept règles de portée
L'orientation énumère sept points de couverture. Chacun exclut une pratique courante.
Règle de l'orientation | Ce qu'elle impose en pratique |
|---|---|
1. Tests inspirés des standards reconnus : NVD, OWASP, OSSTMM, NIST | Une méthodologie documentée, nommée dans le rapport, et non une simple exécution d'outils |
2. Environnement de production ou équivalent à la production | Pas d'environnement de démonstration allégé; si un environnement de test est utilisé, il doit être équivalent (mêmes versions, mêmes configurations, mêmes contrôles) |
3. Tous les rôles (acteurs du système) identifiés et testés dans leur contexte d'utilisation prévue, accessibles depuis le Web ou non | Une matrice des rôles complète : cliniciens, personnel administratif, patients, administrateurs, comptes de service, intégrations; chaque rôle testé contre les autres |
4. Failles liées aux mises à jour logicielles non effectuées | Inventaire des composants et vérification des versions vulnérables, y compris les bibliothèques et les services gérés |
5. Vulnérabilités liées au mode de déploiement : installé chez le client, hébergé par le fournisseur ou infonuagique | Le test couvre l'hébergement réel : réseau du fournisseur, configuration et identités du compte infonuagique, ou poste client |
6. Vecteurs d'attaque selon la criticité du PST : plateforme Web, applications mobiles, infrastructures et réseaux | Scénarios de test construits sur les points d'entrée réels du produit, applications mobiles comprises |
7. Toute autre vérification jugée pertinente pour découvrir des vulnérabilités dans l'utilisation du PST | Une clause ouverte que le vérificateur peut invoquer; elle ne nomme pas l'IA, mais, selon notre lecture, les surfaces de modèle d'un produit avec une composante d'intelligence artificielle peuvent y entrer |
La règle 3 est celle qui transforme le test en exercice d'autorisation. Tester chaque rôle dans son contexte, y compris les rôles non accessibles depuis le Web, revient à vérifier qu'un utilisateur ne peut consulter ni modifier ce que son rôle ne l'autorise pas à toucher. C'est là que se logent les contrôles d'accès défaillants, les références directes à des objets non autorisées et les élévations de privilèges, les classes de vulnérabilités les plus fréquentes dans les applications de santé.
Boîte blanche, grise ou noire : ce que le Bureau accepte
L'orientation définit les trois types de test et se prononce sur chacun.
Type de test | Définition de l'orientation | Position du Bureau |
|---|---|---|
Boîte noire | Surface d'attaque accessible à n'importe quel attaquant externe : vérifier que les mécanismes en place fonctionnent et qu'aucune erreur évidente n'est présente | « non acceptée par le BCH, donc à éviter si on veut obtenir certification TGV » |
Boîte grise | Boîte noire, plus des tests avec les éléments disponibles aux clients, partenaires ou salariés | « acceptée seulement dans le cas de certains PST non sensibles et pour lesquels il n'est pas prévu un déploiement provincial » |
Boîte blanche | Boîte grise, plus une confirmation continue et cohérente, avec les mêmes accès qu'un administrateur du système | « acceptée dans tous les cas » |
Un produit qui traite des renseignements de santé est sensible par définition, et un produit qui vise plus d'un établissement vise un déploiement provincial. Pour la quasi-totalité des fournisseurs, la seule option sûre est donc la boîte blanche : accès administrateur, documentation d'architecture, et, idéalement, accès au code source. Commander un test en boîte noire est l'erreur la plus coûteuse du processus, parce que l'argent est dépensé et que le critère reste ouvert.
Le prestataire reconnu : six conditions
Le Bureau « acceptera les résultats des tests d'intrusion ou tests de pénétration provenant uniquement d'un prestataire de service répondant minimalement aux exigences suivantes » :
avoir des représentants légalement autorisés au Canada;
être minimalement spécialisé en cybersécurité et en protection des renseignements personnels, avec du personnel possédant des certifications reconnues en test d'intrusion ou de vulnérabilités;
être en mesure de fournir des preuves d'antécédents criminels pour le personnel effectuant les tests, parce qu'il accède à de l'information extrêmement sensible;
être responsable et imputable des résultats, qu'il utilise des sous-traitants ou non;
être en mesure, avec l'accord de son client, de fournir sans frais le rapport des tests en français au Bureau;
être en mesure de réaliser des tests dans un environnement de production ou équivalent, en tenant compte des risques ou enjeux d'affaires du client.
Deux de ces conditions éliminent tardivement des prestataires par ailleurs compétents. Une firme sans représentants légalement autorisés au Canada ne se qualifie pas, quelle que soit sa réputation. Une firme incapable de livrer le rapport en français au Bureau sans frais ne se qualifie pas non plus, et une traduction commandée après coup coûte plus cher et prend plus de temps qu'un livrable prévu au contrat.
Comment confirmer la reconnaissance. Il n'existe pas de liste publique de firmes reconnues. La reconnaissance s'apprécie à partir des six conditions. La démarche fiable consiste à transmettre au Bureau, avant de signer, les coordonnées de la firme, les certifications de ses testeurs, sa capacité de vérification des antécédents et sa capacité de livraison en français, puis à obtenir une confirmation écrite. Le Bureau est le point d'entrée unique du processus et répond à cette question à l'adresse certification@sante.quebec.
Le rapport : huit éléments obligatoires
Le rapport doit permettre au Bureau « d'appuyer ses décisions relatives à l'acceptation ou non du PST ». Il présente au minimum :
le contexte : objectifs et portée du test d'intrusion;
la méthodologie d'évaluation des risques et d'identification des vulnérabilités;
la description de chacun des tests effectués, concluants ou non, et les résultats obtenus;
la documentation détaillée de chaque vulnérabilité identifiée et des risques associés;
les forces et les faiblesses des mesures de sécurité examinées;
les vulnérabilités potentiellement présentes qui n'ont pu être exploitées;
des recommandations spécifiques aux vulnérabilités majeures ou critiques et des recommandations générales;
une synthèse de type sommaire de gestion, complète et d'interprétation facile, dans le rapport ou dans un document distinct.
Les éléments 3 et 6 séparent un rapport de certification d'un export d'outil. Le Bureau veut voir les tests qui n'ont pas abouti et les vulnérabilités soupçonnées mais non exploitables, parce que c'est ainsi qu'il distingue une couverture réelle d'une découverte fortuite. Un rapport qui ne liste que les failles trouvées ne démontre pas ce qui a été vérifié. Les rapports TGV de Stingrai sont structurés selon les huit éléments; pour une mise en page générale, voir notre exemple de rapport de test d'intrusion (en anglais).
Fraîcheur du test et périodicité
Le formulaire officiel de demande de certification pose la question : « Est-ce que le PST a fait l'objet d'un test d'intrusion récent (moins de six mois)? » Si oui, il demande la date du test, le nom de la firme, la portée, si les anomalies détectées ont été corrigées, s'il en reste, et si le fournisseur accepte de transmettre une copie du rapport. Six mois est donc la fenêtre pratique au moment de la demande. Un test dont le rapport ne peut être partagé, ou qui s'est conclu sur des anomalies non corrigées et sans plan, affaiblit le dossier plutôt qu'il ne le renforce.
Après la certification, l'obligation devient annuelle. Le certificat est valide cinq ans, mais son renouvellement tacite d'un an dépend chaque année de l'acceptation de l'autodéclaration, qui doit être déposée au moins quinze jours avant la date d'anniversaire de l'attestation, avec le rapport de test et les preuves de mitigation. Un test manqué une année met la certification en jeu, jusqu'au retrait.
Les trois délais de correction

Pour un fournisseur certifié, trois horloges distinctes tournent après la réception du rapport; il est prudent de s'y conformer dès le premier test.
Le délai contractuel de quinze jours. L'autodéclaration annuelle atteste que « toutes les vulnérabilités détectées lors des tests d'intrusion ont été corrigées ou bien des mesures de mitigation ont été mises en place dans les quinze jours suivant le rapport de test ». Le guide MSSS de 2024 parlait de quinze jours ouvrables; l'attestation la plus récente remplace la fenêtre fixe par une échéance « convenue avec le BC ». Convenez donc explicitement de la vôtre, mais planifiez sur quinze jours.
Le délai de trois jours ouvrables pour une vulnérabilité critique. Le fournisseur « doit informer le BC de toute vulnérabilité critique dès qu'il en a été informé et il doit présenter un plan d'instauration des mesures de mitigation dans les trois jours ouvrables suivants ».
La matrice gouvernementale de remédiation. Le Bureau publie, « à titre indicatif », les délais établis par le ministère de la Cybersécurité et du Numérique en vertu de la Loi sur les ressources informationnelles : pour un actif exposé à Internet avec un correctif ou une mesure de contournement disponible, de 2 jours (impact et probabilité très élevés) à 60 jours (impact faible); pour un actif exposé à Internet sans correctif disponible, de 8 à 90 jours; pour un actif non exposé à Internet, de 8 à 90 jours. L'orientation souligne que ces délais « sont exprimés en jours civils et non en jours ouvrables » et qu'il « demeure essentiel de discuter et de convenir des échéances précises avec le BC ».
Une vulnérabilité critique sur un actif exposé à Internet avec correctif disponible se corrige donc en deux jours civils. C'est le chiffre autour duquel construire le processus de mise en production, et la raison pour laquelle le test doit précéder la vérification de plusieurs mois plutôt que de quelques semaines.
Calendrier : où placer le test par rapport à la vérification

Le Bureau publie deux durées : de 1 à 6 semaines de préparation, selon la maturité du produit et de l'organisation, puis 30 jours ouvrables de vérification par la firme externe. Son document Planification des vérifications TGV détaille cette seconde phase jour par jour, à partir de la réunion de démarrage (J0) :
Étape | Échéance | Qui |
|---|---|---|
Envoi des documents préliminaires (grille ajustée des critères, plan de présentation, proposition de date) | Au moins 3 jours avant J0 | Bureau et auditeur |
Réunion de démarrage | J0 | Tous |
Envoi de la grille finale et de la planification | J0+1 | Auditeur |
Premier dépôt de la grille et des documents de support (itération 1) | J+9 | Fournisseur |
Analyse et retour des demandes complémentaires | J+13 | Auditeur |
Deuxième dépôt (itération 2) | J+17 | Fournisseur |
Analyse de la grille finale | J+20 | Auditeur |
Plan d'audit en ligne | J+21 | Auditeur |
Audit en ligne (une demi-journée à un jour) | J+22 | Auditeur et fournisseur |
Rapport de vérification envoyé pour commentaires | J+25 | Auditeur |
Retour du rapport commenté | J+27 | Fournisseur |
Dépôt officiel au Bureau | J+28 | Auditeur |
Décision : certifié ou non certifié | J+29 | Bureau |
Le premier dépôt de preuves arrive donc à J+9, huit jours après la réception des documents finaux (J+1), soit neuf jours après la réunion de démarrage. Le rapport de test d'intrusion, le plan d'action et les preuves de correction doivent être prêts à ce moment. En comptant le délai de quinze jours pour les correctifs, le retest, et la fenêtre pratique de six mois au moment de la demande, la fenêtre raisonnable pour réaliser le test se situe trois à quatre mois avant le début prévu de la vérification : assez tôt pour corriger, assez tard pour rester dans les six mois.
En cas de refus, le fournisseur peut présenter une nouvelle demande, à ses frais, après un délai minimal de trois mois et une fois les correctifs attendus apportés. Un test placé trop tard coûte donc, au pire, un trimestre entier.
Ce qui a changé en 2026
Trois publications récentes modifient la préparation du test.
La liste des critères du 24 avril 2026. Elle passe de 254 critères en six volets à 382 critères en sept volets, avec un nouveau volet Intelligence artificielle de 69 critères. Le critère IA12 exige, pour toute solution utilisant l'IA générative, « un rapport décrivant des tests d'injection de requêtes malveillantes », le critère IA40 interdit toute communication de renseignements personnels à l'extérieur du Québec par une composante d'IA, y compris les appels à des modèles génératifs, sans consentement explicite, et les critères IA49 et IA50 exigent que les accès à la solution d'IA respectent le rôle de l'utilisateur. L'orientation sur les tests d'intrusion ne nomme pas l'IA; selon notre lecture, le test d'une solution avec une composante d'IA couvre ces surfaces, et le rapport d'injection d'IA12 peut être produit dans le même mandat. La section suivante détaille cette couverture. Notre guide TGV Certification for AI Health Tools in Quebec (2026) (en anglais) détaille les 69 critères.
L'orientation sur l'authentification à facteurs multiples (19 décembre 2025). Elle fixe le niveau d'assurance AU3 comme « niveau minimal exigé pour tout PST traitant des renseignements de santé ou de services sociaux ou arrimé avec un actif informationnel d'intérêt commun », et précise qu'un seul facteur (AU1) « n'est pas jugé adéquat pour passer le processus de certification ». Le test d'intrusion vérifie l'implantation réelle du deuxième facteur, y compris ses contournements.
Les critères technologiques T17, T24 et T25. Hébergement dans les espaces de Santé Québec ou dans un espace infonuagique approuvé par le ministère de la Cybersécurité et du Numérique, priorité à l'infonuagique, et environnements de développement, de test, de préproduction et de production distincts et isolés. L'isolation entre ces environnements fait partie de ce qu'un test en boîte blanche vérifie.
Produits avec une composante d'IA (SARIA) : ce que le test d'intrusion doit couvrir
La liste des critères du 24 avril 2026 consacre un volet entier à l'intelligence artificielle : 69 critères, numérotés de IA1 à IA69 et répartis en neuf catégories. La plupart portent sur la documentation, la gouvernance et la conception du produit, un travail qui revient au fournisseur. Une poignée d'entre eux décident pourtant de ce que le test d'intrusion doit atteindre. Le critère S16.03 demande de soumettre « votre application » à un test d'intrusion, sans distinguer de composante. L'orientation du Bureau ne mentionne pas l'IA, mais elle n'exclut aucune surface : chaque rôle est testé dans son contexte (règle 3) et les vecteurs d'attaque sont identifiés selon la criticité du produit (règle 6, qui cite en exemple la plateforme Web, les applications mobiles, les infrastructures et les réseaux). Selon notre lecture, pour une solution qui intègre de l'IA, la couche d'IA entre donc dans la portée au même titre que le Web, les API et l'hébergement.
Votre produit est-il une SARIA? (IA1 et IA18)
Le critère IA1 pose la définition : « Si votre solution fait appel à une composante en intelligence artificielle [...], ceci doit être clairement mentionné dans la documentation de la SARIA », la SARIA étant une « solution ayant recours à l'intelligence artificielle ». Le critère IA18 exige ensuite que la documentation nomme le ou les types d'IA en cause « (symbolique, apprentissage automatique ou générative ou autres) ». La définition est large : un outil de transcription ou de rédaction de notes cliniques, un modèle qui résume un dossier, un agent conversationnel dans un portail patient ou un modèle d'apprentissage automatique en imagerie sont tous des SARIA. Pour le testeur, cette déclaration et la description d'architecture qu'exige le critère IA24 (les composantes de la SARIA, leurs interactions, les approches et techniques utilisées) sont les documents qui délimitent la portée.
Les essais avant certification : IA8 à IA12
La catégorie Processus de développement réunit cinq critères. Quatre relèvent de l'évaluation du modèle par le fournisseur, et non du test d'intrusion : un processus d'essais pour identifier les différences de comportement de la SARIA selon les conditions ou les groupes sociaux de son contexte d'utilisation (IA8), un processus d'essais pour établir son adéquation à l'utilisation envisagée (IA9), une stratégie d'évaluation des résultats du modèle avec les métriques et les résultats positifs, négatifs, faux positifs et faux négatifs (IA10) et, pour l'IA générative, un rapport décrivant le degré de variabilité des résultats pour une même situation (IA11). Leur consigne commune demande de présenter le processus de développement « de façon à permettre à l'acquéreur d'établir le potentiel de la SARIA, des attentes par rapport à sa performance et à la gestion des risques la concernant ».
Le cinquième critère est un livrable de test de sécurité. IA12 : « Dans le cas de l'utilisation de l'IA générative pour la production de résultats, un rapport décrivant des tests d'injection de requêtes malveillantes doit permettre à l'acquéreur d'établir le risque inhérent à la conception de requêtes de la SARIA et le besoin de contrôle, formation et explicabilité liés à la formulation des requêtes dans la SARIA. » Il correspond à la catégorie LLM01:2026 Prompt Injection de l'OWASP Top 10 for LLM Applications.
Le critère ne fixe pas de gabarit. Pour que l'acquéreur puisse réellement établir le risque, un rapport utile décrit les familles de techniques essayées, directes et indirectes, pour chaque voie d'entrée (texte saisi, documents téléversés, dossiers récupérés, sorties d'outils), le comportement observé du modèle, les tentatives qui ont échoué autant que celles qui ont réussi, puis les contrôles, la formation et l'explicabilité qui en découlent. C'est la logique des éléments 3 et 6 du rapport exigé par l'orientation : les tests « concluants ou non » et les vulnérabilités « qui n'ont pu être exploitées ». Le même mandat peut donc produire le rapport S16.03 et le rapport IA12, à condition que le contrat le prévoie.
Aucune communication hors du Québec : IA40
Le critère IA40 modifie souvent l'architecture : « Aucune communication de renseignements personnels, qu'ils soient d'usagers ou d'utilisateurs, ne sera faite par aucune composante de la SARIA (y compris les appels à des modèles d'IA générative) à l'extérieur du territoire du Québec. Si c'est le cas, la personne dont le renseignement personnel sera communiqué doit y consentir de façon informée, explicite et inéquivoque. » Pour un testeur, c'est une affirmation vérifiable : vers quelles destinations partent réellement les appels de modèle, que contient chaque requête, et un utilisateur moins privilégié ou une intégration compromise peut-il déclencher ou rediriger un appel? Le critère IA45, qui exige que l'acquéreur puisse inhiber l'appel à un, plusieurs ou tous les modèles, se vérifie dans le même exercice.
L'accès selon le rôle : IA49 et IA50
Les accès à la SARIA doivent être sécurisés « de façon à ce que l'utilisateur ne puisse pas consulter des données, des informations ou des documents auxquels il n'a pas l'autorisation d'accéder en raison de son emploi ou de son rôle » (IA49), et de façon qu'il ne puisse pas « réaliser de tâches pour lesquelles il n'a pas l'autorisation de le faire en raison de son emploi ou de son rôle » (IA50). C'est la règle 3 de l'orientation appliquée à la couche d'IA. Un assistant qui répond à la question d'un clinicien à partir du dossier d'un autre patient, ou un outil de notes dont l'API laisse un professionnel récupérer les brouillons d'un collègue, échoue à IA49 par la fonction d'IA, même si le dossier sous-jacent applique correctement les accès. Chaque rôle de la matrice est donc testé contre les points de terminaison d'IA et contre les données que l'IA peut atteindre, pas seulement contre les écrans.
Les sept règles de l'orientation appliquées à une SARIA
Règle de l'orientation | Ce qu'elle signifie pour un produit avec une composante d'IA |
|---|---|
1. Standards reconnus (NVD, OWASP, OSSTMM, NIST) | L'OWASP Top 10 for LLM Applications (2026) s'ajoute aux référentiels Web et API pour la couche d'IA |
2. Environnement de production ou équivalent | Le modèle, la couche de récupération et les intégrations que le réseau utilisera réellement, pas une version simulée; les contraintes propres à la production sont consignées dans les règles d'engagement |
3. Tous les rôles testés dans leur contexte; boîte blanche acceptée dans tous les cas | Chaque rôle clinique, administratif, patient et de compte de service exercé contre les points de terminaison d'IA (IA49, IA50); les testeurs reçoivent l'architecture (IA24), les invites système, les définitions d'outils et la configuration de récupération |
4. Failles liées aux mises à jour non effectuées | Serveurs d'inférence, bases de données vectorielles et cadriciels d'orchestration sont des logiciels qui ont leurs propres vulnérabilités publiées |
5. Mode de déploiement : chez le client, chez le fournisseur ou infonuagique | Où s'exécute le modèle, où se trouve l'index de récupération, quelles API de modèles externes sont appelées, y compris le chemin de sortie qu'encadre IA40 |
6. Vecteurs d'attaque selon la criticité du PST | S'ajoutent les surfaces propres au modèle : requêtes, documents téléversés, dossiers récupérés, sorties d'outils et actions d'agents |
7. Toute autre vérification pertinente | Les tests d'injection de requêtes qui alimentent le rapport IA12 et, si la SARIA utilise des agents autonomes, leurs contrôles (IA30, IA65) |
Les cas de test qui en découlent, rattachés aux catégories de l'OWASP :
Critère TGV | Ce que le test vérifie | OWASP Top 10 for LLM Applications (2026) |
|---|---|---|
IA12 | Injection de requêtes directe et indirecte par la saisie, les fichiers téléversés, les dossiers récupérés et les sorties d'outils; contournement des consignes du modèle | LLM01:2026 Prompt Injection |
IA49, IA50 | Exposition de données entre patients et entre rôles par l'assistant, la couche de récupération et les API d'IA; fuite de l'invite système | LLM02:2026 Sensitive Information Disclosure; LLM08:2026 Hidden Context Exposure (anciennement System Prompt Leakage); LLM09:2026 Vector and Embedding Weaknesses |
IA40, IA45 | Destination et contenu de chaque appel de modèle; efficacité de l'inhibition des appels et possibilité de la contourner | LLM02:2026 Sensitive Information Disclosure; LLM03:2026 Excessive Agency |
IA30, IA65, IA66 | Abus d'outils par un agent, élévation de privilèges par les appels d'outils, comportement en cas de défaillance d'une composante externe | LLM03:2026 Excessive Agency |
Le test ne remplace pas le reste du volet : les essais IA8 à IA11 et les 20 critères de documentation restent le travail du fournisseur. Il apporte la preuve technique pour S16.03 et IA12, et un test indépendant des contrôles qu'exigent IA40, IA49 et IA50. Notre guide en anglais, TGV Certification for AI Health Tools in Quebec (2026), passe en revue les 69 critères par catégorie. Chez Stingrai, la couche d'IA est testée par les testeurs d'intrusion, dans le même mandat en boîte blanche que l'application Web et les API associées, et les constats d'injection sont rédigés sous la forme que décrit IA12.
Combien coûte le test d'intrusion TGV
Le test est un coût distinct des frais de certification. L'entente type de Santé Québec fixe ces derniers à 15 000 $ hors taxes pour l'étape de vérification, payables dans les 30 jours de la facture; ils ne sont pas remboursables et varient selon la complexité du produit et les objectifs d'interopérabilité. Le test, lui, est payé à la firme et revient chaque année.
Ce qui fait varier son prix :
le nombre de rôles, puisque chaque rôle doit être testé dans son contexte et contre les autres; c'est le premier facteur de coût et de couverture;
le nombre d'applications et d'API dans la portée, y compris les points d'intégration avec les actifs d'intérêt commun;
les clients mobiles, s'ils existent;
l'environnement infonuagique, lorsque la configuration et le modèle d'identités du compte d'hébergement font partie de la portée, ce que la règle 5 de l'orientation implique;
les composantes d'intelligence artificielle, qui ajoutent des surfaces et le rapport d'injection du critère IA12;
le livrable en français, à prévoir au contrat plutôt qu'en traduction après coup;
le retest, indispensable avec une fenêtre de correction de quinze jours.
Les tarifs publiés de Stingrai sont de 3 000 $ US par évaluation pour le forfait Autonome et de 6 800 $ US pour le forfait Hybride, chacun couvrant exactement une application Web et les API associées. Les portées TGV qui ajoutent des clients mobiles, un environnement infonuagique, plusieurs applications ou une composante d'IA font l'objet d'un devis. Notre calculateur de coût (en anglais) donne une fourchette en quelques minutes.
Les erreurs qui font échouer le critère
Commander un test en boîte noire. Le résultat n'est pas accepté; l'argent est dépensé; le critère reste ouvert.
Choisir une firme qui ne remplit pas les six conditions. Sans représentants au Canada, sans vérification des antécédents ou sans rapport en français, les résultats sont irrecevables, quelle que soit leur qualité.
Tester trop tard. Un test terminé la semaine du démarrage ne laisse ni les quinze jours de correction, ni les deux jours civils exigés pour une vulnérabilité critique exposée à Internet.
Tester une partie des rôles. L'orientation exige tous les rôles, accessibles depuis le Web ou non; une couverture partielle est une lacune que le vérificateur repère.
Tester un environnement non équivalent à la production. La règle est explicite et facile à vérifier.
Livrer un rapport sans les tests non concluants ni les vulnérabilités non exploitées. Les éléments 3 et 6 manquent, et le Bureau ne peut pas mesurer la couverture.
Oublier le retest et la preuve de mitigation. L'autodéclaration exige le rapport « confirmant les correctifs ou la mise en place des mesures de mitigation ».
Laisser passer l'anniversaire. Le test annuel et l'autodéclaration sont dus au moins quinze jours avant la date d'anniversaire; un manquement peut mener au non-renouvellement, à la publication d'une non-conformité, à une vérification ciblée ou au retrait.
Liste de contrôle
Avant la demande :
[ ] Écrire la matrice des rôles : chaque acteur, son contexte d'utilisation, accessible depuis le Web ou non.
[ ] Décrire le mode de déploiement et l'architecture, y compris l'hébergement infonuagique et les intégrations.
[ ] Confirmer par écrit auprès du Bureau que la firme retenue remplit les six conditions.
[ ] Exiger au contrat : boîte blanche, environnement de production ou équivalent, tous les rôles, rapport à huit éléments, livrable en français sans frais pour le Bureau, retest inclus.
[ ] Réaliser le test trois à quatre mois avant la vérification.
[ ] Corriger dans les quinze jours, présenter un plan dans les trois jours ouvrables pour toute vulnérabilité critique, retester, conserver les preuves.
[ ] Vérifier que le test a moins de six mois au dépôt du formulaire de demande.
Après la certification :
[ ] Réserver le test de l'année suivante au moins trois mois avant l'anniversaire.
[ ] Déposer l'autodéclaration au moins quinze jours avant l'anniversaire, avec le rapport et les preuves de mitigation.
[ ] Soumettre tout changement majeur au Bureau avant sa mise en production, dans le délai applicable (quinze jours dans l'attestation actuelle, vingt jours sur la page des applications certifiées; confirmer le vôtre).
[ ] Refaire le test après tout changement majeur qui modifie la surface d'attaque, même si l'année n'est pas écoulée.
Comment Stingrai réalise un test d'intrusion TGV
Stingrai est un prestataire de tests d'intrusion accrédité CREST au niveau de la firme, fondé en 2021, établi à Toronto, qui sert des clients au Canada, aux États-Unis et en Europe. Stingrai ne fait que de la sécurité offensive, et ses tests d'intrusion soutiennent les programmes TGV, Loi 25, SOC 2, ISO 27001, HIPAA et PCI DSS de ses clients avec les preuves que ces programmes exigent. Stingrai a réalisé le test d'intrusion à portée TGV de Bia Education, une plateforme québécoise en santé, dans le cadre de sa certification.
Les mandats sont cadrés sur les exigences du Bureau : livraison depuis le Canada, deux testeurs nommés, issus d'une équipe titulaire des certifications OSCE³, OSWE, OSEP, CREST CRT et CISSP, dont les antécédents peuvent être vérifiés, test en boîte blanche dans un environnement de production ou équivalent, couverture complète de la matrice des rôles, et rapport structuré selon les huit éléments de l'orientation, fourni en français au Bureau sans frais avec l'accord du client. Les constats sont publiés dans le portail PTaaS au fur et à mesure de leur confirmation, avec les étapes de reproduction et les recommandations de correction, ce qui permet de démarrer les correctifs pendant le test plutôt qu'après. Le retest est inclus, et le mandat se conclut par une lettre d'attestation signée qui précise la portée, la méthodologie et les résultats du retest. La reconnaissance de la firme est confirmée par le fournisseur auprès du Bureau avant le début du mandat, et Stingrai fournit tout ce que le Bureau demande pour appuyer cette confirmation.
Stingrai réalise des tests d'intrusion annuels ponctuels, ce que l'obligation TGV exige, et des programmes de tests en continu. Pour les applications Web, Snipe, l'agent d'IA autonome de Stingrai pour les tests d'intrusion d'applications Web, travaille en même temps que les testeurs, qui dirigent son attention et prolongent ses chemins d'attaque; il est conçu pour traquer les défauts d'autorisation et de logique d'affaires que la règle des rôles met en évidence. Toute autre portée, réseau, infonuagique, mobile, composantes d'IA, est menée par les testeurs. Les forfaits publiés et ce qu'ils comprennent sont sur la page des tarifs; les portées TGV plus larges passent par le formulaire Get a Quote.
FAQ sur le test d'intrusion TGV
Le test d'intrusion est-il obligatoire pour la certification TGV?
Oui. Le critère S16.03 de la liste des critères du 24 avril 2026 exige de soumettre l'application à un test d'intrusion administré par un prestataire indépendant et reconnu par Santé Québec. L'orientation du Bureau de certification en fait un prérequis pour tout produit ou service utilisant des données personnelles, de santé et de services sociaux, en application de la directive NVD19 du Secrétariat du Conseil du trésor, et le guide du MSSS date l'obligation de janvier 2022. L'attestation de certification exige ensuite au moins un test par année.
Quel type de test d'intrusion le Bureau accepte-t-il?
La boîte blanche est acceptée dans tous les cas. La boîte grise est acceptée seulement pour certains produits non sensibles pour lesquels aucun déploiement provincial n'est prévu. La boîte noire n'est pas acceptée par le Bureau, qui recommande de l'éviter si l'on veut obtenir la certification. Le test doit aussi être réalisé dans un environnement de production ou équivalent, couvrir tous les rôles dans leur contexte d'utilisation, et s'inspirer de standards reconnus comme NVD, OWASP, OSSTMM et NIST.
Qu'est-ce qu'un prestataire indépendant et reconnu?
Le Bureau accepte uniquement les résultats d'un prestataire qui remplit six conditions : des représentants légalement autorisés au Canada; une spécialisation en cybersécurité et en protection des renseignements personnels avec du personnel certifié en test d'intrusion; la capacité de fournir des preuves d'antécédents criminels pour les testeurs; l'imputabilité des résultats, sous-traitants compris; la capacité, avec l'accord du client, de fournir sans frais le rapport en français au Bureau; et la capacité de tester en production ou dans un environnement équivalent. Il n'existe pas de liste publique : confirmez la reconnaissance par écrit auprès du Bureau avant de signer.
Le rapport doit-il être en français?
La firme doit être en mesure, avec l'accord de son client, de fournir sans frais le rapport en français au Bureau. Un prestataire qui ne peut pas le faire ne remplit pas les conditions de reconnaissance. Prévoyez le livrable en français au contrat plutôt qu'une traduction après la rédaction.
Que doit contenir le rapport de test d'intrusion?
Huit éléments : le contexte (objectifs et portée); la méthodologie d'évaluation des risques et d'identification des vulnérabilités; la description de chaque test effectué, concluant ou non, et ses résultats; la documentation détaillée de chaque vulnérabilité et des risques associés; les forces et faiblesses des mesures de sécurité examinées; les vulnérabilités potentiellement présentes non exploitées; des recommandations spécifiques aux vulnérabilités majeures ou critiques et des recommandations générales; et un sommaire de gestion complet et facile à interpréter.
Dans quel délai faut-il corriger les vulnérabilités?
Une fois le produit certifié, l'autodéclaration annuelle atteste que les vulnérabilités ont été corrigées ou atténuées dans les quinze jours suivant le rapport, l'attestation la plus récente renvoyant à une échéance convenue avec le Bureau. Toute vulnérabilité critique doit être signalée au Bureau dès qu'elle est connue, avec un plan de mitigation dans les trois jours ouvrables. La matrice gouvernementale publiée à titre indicatif va de 2 jours civils, pour un actif exposé à Internet avec correctif disponible et un impact très élevé, à 90 jours civils.
Le test doit-il dater de moins de six mois?
Le formulaire de demande de certification demande si le produit a fait l'objet d'un test d'intrusion récent, de moins de six mois, puis la date, la firme, la portée, l'état des corrections et l'accord pour transmettre le rapport. Six mois est donc la fenêtre pratique au moment de la demande; après la certification, l'obligation devient annuelle.
Le test d'intrusion TGV doit-il couvrir les composantes d'intelligence artificielle?
Oui. Le critère S16.03 exige un test d'intrusion de l'application. L'orientation du Bureau ne mentionne pas l'IA, mais n'exclut aucune composante : chaque rôle est testé dans son contexte et les vecteurs d'attaque sont identifiés selon la criticité du produit. Selon notre lecture, la portée comprend donc les points de terminaison d'IA, la couche de récupération et les appels à des modèles externes. Depuis la liste du 24 avril 2026, une solution qui utilise l'IA générative pour produire des résultats doit aussi fournir un rapport décrivant des tests d'injection de requêtes malveillantes (critère IA12). Les critères IA49 et IA50 exigent que l'accès à la SARIA respecte l'emploi ou le rôle de l'utilisateur, et le critère IA40 interdit toute communication de renseignements personnels à l'extérieur du Québec par une composante de la SARIA, y compris les appels à des modèles d'IA générative, sans consentement informé, explicite et inéquivoque. Un même mandat peut produire le rapport S16.03 et le rapport IA12; les essais IA8 à IA11 restent le travail du fournisseur.
Combien coûte un test d'intrusion TGV?
Le coût dépend du nombre de rôles, du nombre d'applications et d'API, de la présence de clients mobiles, de l'inclusion de l'environnement infonuagique, des composantes d'intelligence artificielle, du livrable en français et du retest. Il s'ajoute aux frais de certification de 15 000 $ hors taxes prévus à l'entente type de Santé Québec. Les tarifs publiés de Stingrai sont de 3 000 $ US (forfait Autonome) et de 6 800 $ US (forfait Hybride) par évaluation pour une application Web et les API associées; toute autre portée fait l'objet d'un devis.
Quand faut-il faire le test par rapport à la vérification?
Trois à quatre mois avant le début prévu de la vérification. Le premier dépôt de preuves est attendu à J+9 après la réunion de démarrage, les correctifs doivent être en place dans les quinze jours suivant le rapport, un retest doit confirmer les corrections, et le formulaire de demande demande si le produit a fait l'objet d'un test de moins de six mois.
Que se passe-t-il si le test annuel est manqué après la certification?
Le respect des engagements, dont le test annuel et le dépôt de l'autodéclaration au moins quinze jours avant l'anniversaire, est « une condition essentielle au maintien et au renouvellement annuel de la certification TGV, malgré sa durée de validité de cinq ans ». Un manquement peut entraîner le non-renouvellement, la publication d'une non-conformité sur le site du Bureau, une vérification ciblée, une réévaluation du statut ou le retrait de la certification.
Lectures connexes
TGV Certification in Quebec (2026): What It Is, the Penetration Testing Requirement, Timeline, Evidence and Cost, le guide complet en anglais.
TGV Certification for AI Health Tools in Quebec (2026), les 69 critères d'intelligence artificielle de la liste de 2026.
Quebec Law 25 penetration testing requirements (2026), pour les obligations de la Loi 25.
Penetration testing companies in Montreal (2026) et Top penetration testing companies in Canada (2026).
Web application penetration testing et AI and LLM penetration testing.
Parlez à Stingrai
Cadrer un test d'intrusion TGV prend une courte conversation : matrice des rôles, mode de déploiement, intégrations, composantes d'IA et calendrier de vérification. Stingrai est une entreprise de sécurité offensive accréditée CREST, établie à Toronto avec un bureau à Londres. Ses testeurs d'intrusion, certifiés OSCE³, OSWE, OSEP et CREST CRT, mènent des tests d'intrusion en boîte blanche sur les applications Web et mobiles, les API, les composantes d'IA et l'infonuagique, en mandat ponctuel annuel ou en continu par sa plateforme PTaaS, avec des constats documentés, des recommandations de correction et le retest inclus. Réservez un appel de cadrage gratuit, demandez un devis ou consultez les tarifs publiés.
Références
Bureau de certification. Orientation concernant les tests d'intrusion. https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/orientation-tests-intrusion.pdf. Les sept règles de portée, les trois types de test, les six conditions du prestataire et les huit éléments du rapport.
Ministère de la Santé et des Services sociaux. Critères de vérification de la TGV, version 2026-04-24. https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/liste-criteres-TGV_v2026-04-24.xls. La liste en vigueur, dont les critères S16.02, S16.03 et le volet Intelligence artificielle (IA1 à IA69).
Ministère de la Santé et des Services sociaux. Certification : Trousse globale de vérification (TGV). Publication 24-715-38W, 2024. https://publications.msss.gouv.qc.ca/msss/document-003757/. Le guide officiel, dont la mention de l'obligation depuis janvier 2022.
Bureau de certification. Orientation sur le délai de remédiation des vulnérabilités. https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/orientation-delai-remediation-vulnerabilites.pdf. La matrice gouvernementale en jours civils.
Bureau de certification. Planification des vérifications TGV (24-715-53W). https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/planification-verifications-tgv.pdf. Le calendrier de J0 à J+29.
Bureau de certification de Santé Québec. Attestation, certification TGV (BC-D0001-01). https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/BC_TGV_ATTESTATION.pdf. Les neuf engagements annuels, dont le test d'intrusion.
Bureau de certification. Autodéclaration, suivi et évaluation annuelle des engagements (BC-F0003-01). https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/gabarit-formulaire-autodeclaration-annuelle.pdf. Les points 6 à 9 sur le test, les correctifs et le rapport.
Bureau de certification. Formulaire pour une demande de certification TGV. https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/Formulaire-demande-certification-tgv.xlsm. La question du test de moins de six mois.
Santé Québec. Entente, certification TGV (BC-D0002-01). https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/BC_TGV_ENTENTE_SQ_Fournisseur.pdf. Les frais de certification de 15 000 $ hors taxes.
Bureau de certification. Orientation sur l'authentification à facteurs multiples (MFA). 19 décembre 2025. https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Professionnels/certification-produits-services-technologiques/orientation-authentification-facteurs-multiples_mfa.pdf. Le niveau AU3 minimal.
Gouvernement du Québec. Certification des produits et services technologiques en santé et services sociaux. https://www.quebec.ca/sante/professionnels/certification-produits-services-technologiques/a-propos. Les durées publiées de préparation et de vérification, la validité de cinq ans.
Gouvernement du Québec. Orientations, procédures et documents pour la certification des produits et services technologiques. https://www.quebec.ca/sante/professionnels/certification-produits-services-technologiques/orientations-procedures-documents-certification. La page qui publie la liste des critères en vigueur, les orientations et les formulaires.
OWASP GenAI Security Project. OWASP Top 10 for LLM Applications 2026. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/. Les catégories LLM01:2026 à LLM10:2026 utilisées pour rattacher les critères d'IA aux cas de test.


