Guide : vérifier la situation de votre site Web en lien avec la Loi 25

La Loi 25 modernise le cadre québécois de protection des renseignements personnels. Elle renforce notamment la transparence, le consentement, la sécurité et la responsabilité des organisations.

Les principales étapes sont entrées en vigueur en septembre 2022, septembre 2023 et septembre 2024. En 2022, plusieurs obligations immédiates liées aux incidents de confidentialité et à la gouvernance ont commencé à s'appliquer. En 2023, les organisations ont notamment dû rendre leur politique de confidentialité plus accessible, encadrer davantage les analyses d'impact et désigner clairement une personne responsable de la protection des renseignements personnels. En 2024, d'autres attentes se sont ajoutées, dont des mécanismes liés à la portabilité et à une meilleure circulation de l'information pour les personnes concernées.

En pratique, cela signifie qu'une organisation doit mieux documenter ses pratiques, expliquer ses traitements de données, encadrer ses fournisseurs et mettre en place des mesures de sécurité proportionnées. Les sanctions peuvent être importantes : selon les cas, des montants pouvant aller jusqu'à 25 millions de dollars ou 4 % du chiffre d'affaires mondial peuvent être évoqués dans le cadre prévu par la loi.

Le service s'adresse à toute organisation qui veut obtenir une lecture technique structurée de son site Web public : équipes TI, responsables de la protection des renseignements personnels, consultants ou directions. Pour une équipe TI, il peut servir à repérer rapidement les écarts techniques, les dépendances externes et les correctifs prioritaires. Pour une personne responsable de la protection des renseignements personnels, il fournit une base factuelle pour documenter les flux, les traceurs, l'hébergement et le contenu public affiché aux utilisateurs. Pour un consultant ou une direction, il aide à poser les bonnes questions, à prioriser les travaux et à suivre l'évolution d'un site au fil du temps.

Les résultats servent de base de discussion et d'orientation interne pour éclairer les échanges et les décisions au quotidien.

Après un scan, chaque catégorie affiche un pourcentage et une couleur : vert quand les contrôles observés sont globalement favorables, orange (ambre / jaune) quand certains points méritent attention, et rouge quand des écarts techniques marqués sont détectés.

Le pourcentage résume les éléments observables testés, pas une conformité légale complète. Un score élevé veut surtout dire que moins d'irritants techniques ont été vus sur les points testés; un score plus faible attire l'attention sur des problèmes concrets ou sur de l'information publique manquante.

Une lecture pratique consiste à prioriser ainsi : rouge d'abord (problèmes bloquants ou risqués), orange ensuite (durcissement, documentation, paramètres incomplets), vert enfin (maintenance et surveillance). Par exemple, un certificat expiré, une bannière absente avec des traceurs actifs dès l'arrivée, ou une politique introuvable devraient généralement passer avant une CSP seulement perfectible ou un DMARC encore en mode de surveillance. À l'inverse, un résultat vert n'élimine pas le besoin de suivi : un changement d'hébergeur, l'ajout d'un outil analytique ou une refonte du site peuvent faire bouger rapidement ces constats. Le rapport détaillé précise ce qui a été vu, donne souvent un exemple de résultat, et aide à distinguer ce qui demande une correction rapide de ce qui relève surtout de la documentation interne.

Ce groupe décrit l'infrastructure du nom de domaine : en clair, on regarde comment le site est repéré sur Internet, qui semble l'héberger et comment son courrier est protégé.

Ce qui est examiné :

• DNS — c'est un peu l'annuaire d'Internet : il relie le nom du site à des adresses techniques (A/AAAA, NS, CNAME) et permet de voir si la configuration paraît cohérente.
• Registre et réseau — WHOIS/RDAP montrent des informations publiques sur l'enregistrement du domaine, et l'ASN aide à voir quel réseau ou fournisseur semble opérer l'infrastructure.
• Courriel — MX indique quels serveurs reçoivent le courriel; SPF, DKIM et DMARC servent à réduire l'usurpation d'adresse; BIMI ajoute parfois un logo validé dans certains outils.

Pourquoi on le fait : le but est de documenter où le site semble être hébergé, quels partenaires techniques sont impliqués et si la protection du domaine contre l'usurpation paraît minimale, correcte ou à renforcer.

Exemples de résultats : adresses IP et pays associés, DMARC absent, SPF incomplet, ou utilisation d'un CDN international. On peut aussi voir qu'un domaine pointe vers plusieurs services, qu'un enregistrement paraît orphelin, ou qu'un fournisseur étranger intervient dans la chaîne technique.

Pour une personne non technique, un résultat orange ou rouge ici veut souvent dire : « il y a des dépendances ou des réglages à mieux comprendre et à mieux documenter », pas forcément « le site est illégal ».

Ces tests évaluent la connexion HTTPS entre le navigateur et le site. En mots simples, ils vérifient si la route entre le visiteur et le site est bien chiffrée et si ce chiffrement semble moderne ou dépassé.

Ce qui est examiné :

• Certificat — c'est la pièce d'identité du site en HTTPS; on vérifie qu'elle est valide, qu'elle correspond bien au domaine et qu'elle n'est pas expirée.
• Protocoles TLS — ce sont les versions du langage de sécurité utilisé entre le navigateur et le serveur; si des versions trop anciennes restent actives, le risque augmente.
• Suites cryptographiques — ce sont les méthodes concrètes utilisées pour chiffrer les échanges; certaines sont solides, d'autres sont vieillissantes ou déconseillées.
• Durcissement — on regarde aussi s'il existe des signes de configuration faible, d'anciennes vulnérabilités connues ou l'absence de protections attendues.

Pourquoi on le fait : le but n'est pas seulement de voir si le cadenas du navigateur s'affiche, mais de comprendre si la protection en transit est suffisante pour un site qui peut traiter ou afficher des renseignements personnels.

Exemples de résultats : certificat expirant bientôt, TLS 1.0 encore actif, ou configuration moderne limitée à TLS 1.2 et 1.3. Le rapport peut aussi signaler que le certificat est valide mais que la configuration générale reste perfectible.

Pour une personne non technique, un mauvais résultat ici veut souvent dire : « la connexion existe, mais elle pourrait être plus sûre », ou dans les cas rouges : « il faut corriger rapidement parce que la protection de la connexion est faible ou brisée ».

Ces tests lisent les en-têtes HTTP de sécurité. En pratique, ce sont de petites consignes envoyées par le site au navigateur pour lui dire comment se comporter de façon plus prudente.

En mots simples, voici ce que veulent dire les principaux termes :

• CSP — dit au navigateur d'où il a le droit de charger du code, des images ou des styles, afin d'éviter qu'un contenu malveillant se glisse plus facilement.
• HSTS — dit au navigateur de toujours revenir en version sécurisée HTTPS et d'éviter la version non chiffrée HTTP.
• X-Frame-Options — aide à empêcher qu'un autre site affiche votre page dans un cadre invisible ou trompeur.
• X-Content-Type-Options — demande au navigateur de ne pas deviner le type d'un fichier si le serveur lui a déjà dit ce que c'est.
• Referrer-Policy — limite les informations sur la page précédente qui sont envoyées quand un visiteur clique vers un autre site.
• Permissions-Policy — permet de limiter l'accès à des fonctions du navigateur comme la caméra, le micro ou la géolocalisation.
• Indices de technologies ou de versions — ce sont des traces qui peuvent révéler quel CMS, serveur ou framework semble utilisé, parfois même avec un numéro de version.

Pourquoi on le fait : le but est de voir si le site donne au navigateur des règles de sécurité de base pour réduire certaines attaques courantes, et s'il expose inutilement des détails techniques.

Exemples de résultats : HSTS absent, CSP trop permissive, ou tableau montrant quels en-têtes sont présents, absents ou à renforcer. Ce sont souvent des ajustements ciblés, mais ils peuvent améliorer concrètement la protection du site.

Ce volet observe les traceurs déposés dans le navigateur et simule une première visite pour voir ce qui se passe avant et après un choix de consentement.

En mots simples :

• Cookie de première partie — il vient directement du site visité.
• Cookie tiers — il vient d'un service externe, par exemple un outil analytique, publicitaire ou un réseau social.
• Secure — le cookie ne devrait circuler qu'en HTTPS.
• HttpOnly — le cookie est moins accessible au code exécuté dans la page.
• SameSite — limite certains usages du cookie quand la navigation vient d'un autre site.

Ce qui est examiné :

• les cookies et stockages visibles au chargement;
• la présence d'une bannière ou d'un centre de préférences;
• le dépôt de traceurs non essentiels avant consentement, puis après un refus ou une acceptation;
• la persistance du refus lorsqu'on navigue ou qu'on revient dans le parcours.

Pourquoi on le fait : le but est de voir non seulement s'il y a des cookies, mais surtout à quel moment ils apparaissent, si le choix de l'utilisateur semble respecté et si le site laisse une vraie possibilité d'accepter, de refuser ou de revenir sur sa décision.

Exemples de résultats : bannière absente, cookies analytiques présents dès l'arrivée, comparaison du nombre de cookies avant et après « Tout refuser », ou maintien de seuls cookies essentiels après un refus. Pour une personne non technique, cela répond à une question simple : « est-ce que le site semble demander l'autorisation avant de déposer des traceurs qui ne sont pas strictement nécessaires ? »

Ce test cherche une politique de confidentialité, extrait le texte détecté et compare son contenu à une grille de thèmes souvent associés à la Loi 25. Une partie du repérage est assistée par un modèle de langage, mais l'objectif reste de relire ce que le site publie réellement.

Ce qui est examiné :

• présence d'une page dédiée ou d'un lien clair;
• mentions sur les finalités, les droits, les coordonnées, la personne responsable, les tiers impliqués et les transferts hors Québec;
• clarté générale du texte, dates importantes et éléments non repérés dans la politique analysée.

Pourquoi on le fait : le but est d'aider une équipe à voir rapidement si la politique semble complète, compréhensible et assez concrète pour répondre aux attentes de transparence, sans prétendre remplacer une lecture juridique détaillée.

Exemples de résultats : URL trouvée, thèmes couverts ou absents, courts extraits servant d'appui. Le rapport peut aussi signaler qu'aucune politique n'a été détectée, qu'une page existe mais reste trop vague, ou qu'un thème important est mentionné sans coordonnées pratiques ni explication utile.

Pour une personne non technique, cette section répond surtout à la question : « le site explique-t-il clairement ce qu'il fait avec les renseignements personnels, et comment les gens peuvent obtenir de l'aide ou exercer leurs droits ? »