La Loi 25 a modernisé le cadre québécois de protection des renseignements personnels. Pour un site web, le chantier ne se limite pas à afficher une bannière ou à publier une politique de confidentialité. Il faut rapprocher trois réalités : ce que le site collecte, ce que son interface explique et ce que ses fournisseurs traitent effectivement.

Cette page propose une méthode d’audit technique et documentaire. Elle ne constitue pas un avis juridique et ne permet pas d’affirmer qu’un site est « entièrement conforme ». Le périmètre, les exceptions et les obligations applicables doivent être validés selon l’organisation et ses activités.

Commencer par l’inventaire réel, pas par la politique

Une politique peut mentionner quatre fournisseurs alors que le navigateur en contacte six. Un formulaire peut demander une entreprise, une priorité ou une URL sans que la finalité soit expliquée. Le premier contrôle consiste donc à observer le fonctionnement réel.

L’inventaire devrait couvrir :

  • les formulaires et les champs transmis;
  • les témoins et le stockage local;
  • les scripts chargés dans le navigateur;
  • les API appelées par le site;
  • les bases de données et stockages de secours;
  • les outils de CRM, d’infolettre, d’analytique et de support;
  • les journaux techniques contenant une adresse IP ou un identifiant;
  • les transferts à des fournisseurs situés hors du Québec.

Chaque élément doit être associé à une finalité, un responsable, une durée de conservation et une règle de suppression. Lorsqu’une information manque, l’audit doit écrire « à valider » au lieu d’inventer une réponse.

Bloquer les témoins non essentiels avant le choix

Le contrôle le plus facile à tester est chronologique : que se passe-t-il avant que la personne accepte?

Ouvre le site dans un nouveau profil de navigateur, refuse les témoins, puis vérifie l’onglet Réseau et le stockage. Les outils de mesure d’audience, de suivi comportemental ou de publicité ne devraient pas être chargés simplement parce que la bannière est visible.

Un mécanisme de consentement robuste permet :

  1. d’accepter les finalités proposées;
  2. de les refuser avec un effort comparable;
  3. de personnaliser les choix par finalité réellement utilisée;
  4. de retirer le consentement plus tard;
  5. de conserver une preuve du choix et de la version de politique;
  6. de supprimer, dans la mesure techniquement possible, les témoins devenus inutiles.

Une catégorie « marketing » ne devrait pas être affichée seulement en prévision d’un futur pixel. Les catégories doivent refléter les technologies présentes au moment du choix.

Relier chaque formulaire à une finalité précise

Le consentement à une infolettre ne doit pas être déduit d’un formulaire de contact. Une personne qui demande un audit ou transmet une question n’accepte pas automatiquement de recevoir des communications promotionnelles.

Pour chaque formulaire, vérifie :

  • que les champs sont nécessaires à la demande;
  • que la finalité est annoncée près du bouton d’envoi;
  • que l’infolettre possède son propre choix explicite;
  • que l’API refuse une inscription sans ce choix;
  • que la preuve de consentement enregistre la date et la version de politique;
  • que le désabonnement est transmis à tous les systèmes concernés.

Le contrôle côté serveur est indispensable. Une case obligatoire dans le navigateur peut être contournée si l’API accepte quand même la requête.

Aligner la politique de confidentialité avec le code

La politique publique doit pouvoir être rapprochée de l’inventaire. Elle devrait identifier les catégories de renseignements, les finalités, les destinataires ou catégories de destinataires, les durées ou critères de conservation, les droits et la personne responsable de la protection des renseignements personnels.

Une durée affichée n’est pas une règle de suppression. Il faut également pouvoir montrer le mécanisme opérationnel : tâche planifiée, procédure manuelle, automatisation chez le fournisseur ou contrôle périodique documenté.

Les noms exacts des témoins méritent la même rigueur. Si le code écrit cookie_consent et preferred_language, une politique qui annonce uniquement des noms génériques ou anciens n’est plus synchronisée avec le site.

Examiner les fournisseurs et les transferts

Les outils d’hébergement, d’analytique, de CRM et d’infolettre peuvent traiter des renseignements dans plusieurs territoires. L’audit technique repère les destinations, mais il ne remplace pas l’examen des contrats, des paramètres de compte et des évaluations requises.

Pour chaque fournisseur, documente au minimum :

  • le service réellement activé;
  • les données transmises;
  • les régions de traitement connues;
  • les sous-traitants pertinents;
  • la durée configurée;
  • les possibilités d’accès et de suppression;
  • la personne qui peut modifier le compte;
  • la date de la dernière vérification.

Réduire les données techniques

Les journaux de sécurité peuvent être utiles, mais leur collecte doit rester proportionnée. Une adresse IP complète, une empreinte d’adresse IP ou un identifiant persistant ne devrait pas être conservé « au cas où » sans finalité documentée.

Lorsque seule une région est nécessaire au routage linguistique, le serveur peut utiliser les en-têtes géographiques fournis par l’infrastructure sans enregistrer une position précise ni demander l’accès GPS. Pour la prévention des abus, une limite de requêtes de courte durée peut parfois suffire sans construire un historique permanent des visiteurs.

Tester le parcours de retrait de bout en bout

Le retrait n’est pas terminé quand un interrupteur change d’état dans la bannière. Il faut vérifier que les scripts cessent de fonctionner, que les témoins concernés sont supprimés, que les préférences sont mémorisées et que les systèmes externes reçoivent les demandes appropriées.

Un scénario de test minimal comprend :

  1. première visite sans choix;
  2. refus de toutes les finalités non essentielles;
  3. acceptation de l’analytique seulement;
  4. retrait depuis le pied de page;
  5. nouvelle visite après retrait;
  6. inscription et désinscription à l’infolettre;
  7. demande d’accès ou de suppression testée avec une donnée fictive.

Les livrables utiles d’un audit

Un audit exploitable produit davantage qu’une note générale. Il fournit un inventaire des traitements, une matrice des écarts, un classement par priorité, les corrections techniques réalisées, les décisions à prendre et les éléments réservés à la validation juridique.

La formulation compte : « script analytique bloqué avant consentement » est une observation vérifiable. « Site conforme à la Loi 25 » est une conclusion juridique globale que le code seul ne peut pas établir.

Sources officielles pour la validation

Ces sources doivent être revérifiées au moment de la publication et de la validation juridique finale.

Ce qu’il faut retenir

La qualité d’un chantier Loi 25 se mesure à la cohérence entre le navigateur, les API, les fournisseurs et les documents publics. Commence par l’inventaire réel, bloque les technologies non essentielles avant le choix, sépare les finalités, documente les durées et teste le retrait jusqu’aux systèmes externes.

FAQ

Une bannière de témoins suffit-elle pour rapprocher un site des exigences de la Loi 25 ?

Non. Il faut aussi vérifier que les scripts non essentiels restent bloqués avant le choix, que le retrait fonctionne réellement et que les documents publics décrivent les traitements observés.

Que faut-il contrôler en priorité dans un audit technique ?

Commence par l’inventaire des scripts, formulaires, fournisseurs et données transmises. Vérifie ensuite le consentement par finalité, la minimisation, les durées et le parcours de retrait.

Un audit technique peut-il certifier la conformité juridique ?

Non. Il peut documenter des contrôles et des écarts observables. La conclusion juridique dépend du contexte de l’organisation et d’une validation professionnelle distincte.