Loi 25 pour les développeurs : ce que la loi demande à votre code.

Les numéros d’article sont ceux de la Loi sur la protection des renseignements personnels dans le secteur privé, telle que modifiée par la Loi 25, lue sur LégisQuébec le 2026-10-29. La conception de chaque élément est la nôtre : la loi fixe l’obligation, pas le schéma. Ce n’est pas un avis juridique.

Si votre produit a des paramètres de confidentialité, ils doivent assurer « par défaut » « le plus haut niveau de confidentialité, sans aucune intervention de la personne concernée ». Dans le code, c’est une valeur par défaut de colonne. Un profil public au départ, ou un partage activé d’office, est fautif dès le premier jour pour chaque utilisateur qui n’ouvre jamais la page des paramètres.

L’article 9.1 exclut les paramètres des témoins de connexion, qui relèvent d’autres règles. L’article 8.1 ajoute une règle voisine : si vous utilisez une technologie qui permet d’identifier, de localiser ou de profiler une personne, vous devez l’en informer au préalable et lui dire comment activer ces fonctions. Concevez la localisation et le profilage en adhésion volontaire.

Mettez les valeurs par défaut dans la base de données, pas seulement dans le formulaire, pour qu’un client d’API ou un script d’amorçage obtienne la même chose. Puis testez-les :

CREATE TABLE privacy_settings (
  user_id          bigint PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
  profile_public   boolean NOT NULL DEFAULT false,
  show_in_search   boolean NOT NULL DEFAULT false,
  share_location   boolean NOT NULL DEFAULT false,  -- art. 8.1 : sur adhésion
  personalized_ads boolean NOT NULL DEFAULT false   -- profilage : sur adhésion
);

-- test : un nouveau compte a les paramètres les plus protecteurs sans rien toucher
test("les nouveaux comptes sont privés (art. 9.1)", async () => {
  const user = await createUser({ email: "a@example.com" });
  const s = await db.one("SELECT * FROM privacy_settings WHERE user_id = $1", [user.id]);
  expect(s).toMatchObject({
    profile_public: false, show_in_search: false,
    share_location: false, personalized_ads: false,
  });
});

L’article 4 exige de déterminer les fins avant la collecte. L’article 5 permet de ne recueillir « que les renseignements nécessaires aux fins déterminées avant la collecte ». L’article 9 interdit de refuser un service parce qu’une personne refuse de fournir un renseignement dont le service n’a pas besoin, et précise qu’en cas de doute, un renseignement personnel est réputé non nécessaire.

Notez la fin à côté de chaque champ, rendez facultatif tout ce qui n’est pas strictement nécessaire et rejetez les champs que vous n’avez pas demandés au lieu de les enregistrer. Un schéma strict fait les trois :

import { z } from "zod";

export const Signup = z.object({
  email: z.string().email(),            // fin : connexion, avis de compte
  name:  z.string().min(1).max(100),    // fin : factures
  phone: z.string().max(30).optional(), // non nécessaire au service : jamais obligatoire (art. 9)
  // ni date de naissance ni adresse : rien de ce que nous faisons n'en a besoin (art. 5)
}).strict();                             // les champs inconnus sont rejetés, pas stockés

L’article 12 limite l’utilisation aux fins de la collecte, avec des exceptions comme une fin compatible ou la prévention de la fraude; la prospection commerciale n’est jamais une fin compatible. L’article 14 exige un consentement « donné à des fins spécifiques », « demandé à chacune de ces fins », présenté distinctement s’il est écrit, et valide seulement le temps nécessaire. L’article 8 donne le droit de le retirer.

Un seul booléen marketing_ok ne démontre rien de tout cela. Consignez chaque fin séparément, avec le libellé que la personne a vu et la date, et vérifiez l’enregistrement avant chaque utilisation :

CREATE TABLE consents (
  id            bigserial PRIMARY KEY,
  user_id       bigint NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  purpose       text   NOT NULL,       -- 'infolettre', 'partage_partenaire_x'
  text_version  text   NOT NULL,       -- le libellé accepté
  granted_at    timestamptz NOT NULL DEFAULT now(),
  expires_at    timestamptz,           -- art. 14 : seulement le temps nécessaire
  withdrawn_at  timestamptz            -- art. 8 : un retrait est une mise à jour, pas une suppression
);

-- avant d'envoyer l'infolettre
SELECT u.email
FROM users u
JOIN consents c ON c.user_id = u.id
WHERE c.purpose = 'infolettre'
  AND c.withdrawn_at IS NULL
  AND (c.expires_at IS NULL OR c.expires_at > now());

Article 23 : lorsque les fins sont accomplies, l’entreprise « doit le détruire ou l’anonymiser », sous réserve d’un délai de conservation prévu par une autre loi (les dossiers fiscaux, par exemple). L’article 3.2 exige des politiques de gouvernance qui encadrent la conservation et la destruction des renseignements. Écrivez le délai dans la politique, puis faites-le appliquer par une tâche.

« Anonymisé » a un sens strict à l’article 23 : il doit être raisonnable de prévoir que le renseignement « ne permet plus, de façon irréversible, d’identifier directement ou indirectement » la personne, selon des critères fixés par règlement. Remplacer un courriel par son empreinte SHA-256 n’y arrive pas : quiconque a le courriel peut recalculer la même empreinte. Dans le doute, supprimez.

Les sauvegardes gardent les lignes supprimées jusqu’à leur propre expiration : leur rétention fait donc partie de votre délai de destruction. Chez Canner, vous réglez l’intervalle et la durée de conservation de chaque sauvegarde (canner db backup-policy <name> --enable --every 24 --keep 7), chaque sauvegarde est chiffrée avec sa propre clé, et supprimer une sauvegarde détruit cette clé sur-le-champ. Une requête planifiée peut faire la purge chaque nuit :

-- chaque nuit; politique : 24 mois après la dernière connexion, sauf conservation légale
DELETE FROM users
WHERE last_seen_at < now() - interval '24 months'
  AND legal_hold = false;
-- les lignes liées (privacy_settings, consents, orders.user_id) utilisent ON DELETE CASCADE
-- ou sont gardées avec user_id à NULL quand une autre loi exige le document

L’article 27 donne à la personne le droit d’obtenir une copie de ses renseignements. Son troisième alinéa, en vigueur depuis septembre 2024, ajoute qu’un renseignement informatisé « recueilli auprès du requérant, et non pas créé ou inféré » à partir de ses renseignements, lui est communiqué sur demande « dans un format technologique structuré et couramment utilisé », à moins de difficultés pratiques sérieuses. L’article 3.3 exige que les nouveaux systèmes le permettent. L’article 32 vous donne 30 jours pour répondre.

La loi ne nomme aucun format : JSON ou CSV conviennent. Attention à la portée : ce que la personne vous a fourni (profil, messages, fichiers, commandes), pas vos cotes ou segments inférés. Ceux-ci restent visés par le droit d’accès général du premier alinéa, mais pas par la règle du format.

app.get("/account/export", requireUser, async (req, res) => {
  const id = req.user.id;
  const [profile, orders, consents] = await Promise.all([
    db.one("SELECT email, name, phone, created_at FROM users WHERE id = $1", [id]),
    db.any("SELECT id, placed_at, items, total FROM orders WHERE user_id = $1", [id]),
    db.any("SELECT purpose, text_version, granted_at, withdrawn_at FROM consents WHERE user_id = $1", [id]),
  ]);
  res.setHeader("Content-Disposition", 'attachment; filename="mes-donnees.json"');
  res.json({ exported_at: new Date().toISOString(), profile, orders, consents });
});

L’article 3.6 définit l’incident de confidentialité : l’accès, l’utilisation ou la communication non autorisés par la loi, ou la perte d’un renseignement personnel ou toute autre atteinte à sa protection. Un agent de soutien qui ouvre un dossier sans raison, c’en est un. Un compartiment laissé public aussi.

L’article 3.5 exige des mesures raisonnables pour diminuer les risques et, s’il y a un risque de préjudice sérieux, un avis avec diligence à la Commission d’accès à l’information et aux personnes concernées. L’article 3.8 exige un registre de tous les incidents, sérieux ou non, dont une copie est transmise à la Commission sur demande. Un règlement peut déterminer la teneur du registre; consultez-le avant de fixer les colonnes. Une table est un bon point de départ :

CREATE TABLE confidentiality_incidents (
  id                 bigserial PRIMARY KEY,
  detected_at        timestamptz NOT NULL,
  occurred_from      timestamptz,
  occurred_to        timestamptz,
  description        text NOT NULL,         -- ce qui s'est passé, comment on l'a découvert
  info_types         text[] NOT NULL,       -- '{courriel,historique_commandes}'
  persons_affected   integer,
  serious_injury_risk boolean NOT NULL,     -- art. 3.7 : sensibilité, conséquences, probabilité
  cai_notified_at    timestamptz,           -- art. 3.5, si sérieux
  persons_notified_at timestamptz,
  measures_taken     text NOT NULL,
  recorded_by        text NOT NULL
);

Les journaux sont des renseignements personnels que vous conservez, souvent plus longtemps et avec un accès plus large que la base de données. L’article 10 exige des mesures de sécurité raisonnables selon la sensibilité et la quantité des renseignements; l’article 5, de ne recueillir que le nécessaire. Journalisez un identifiant d’utilisateur, pas le nom ni le courriel, et jamais le corps des requêtes ni les en-têtes d’autorisation.

Gardez aussi les renseignements personnels hors des URL : une chaîne de requête comme ?email= se retrouve dans chaque journal d’accès en chemin. Chez Canner, le journal des requêtes consigne la méthode, le chemin, le statut et la durée, sans adresse IP du client, sans en-têtes ni corps. Avant toute écriture, les valeurs qui ressemblent à des identifiants de connexion, les valeurs des variables d’environnement sensibles, les adresses courriel et les adresses IP publiques sont retirées. Les journaux de requêtes et de l’appli sont conservés 7 jours, les échantillons d’erreurs 90 jours (documentation des journaux). Ce filtre ne reconnaît pas un nom ou un diagnostic que votre appli écrit : masquez à la source.

import pino from "pino";

export const log = pino({
  redact: {
    paths: [
      "req.headers.authorization", "req.headers.cookie",
      "user.email", "user.name", "user.phone", "body",
    ],
    censor: "[masqué]",
  },
});

log.info({ userId: user.id, action: "export_requested" }); // un identifiant, pas la personne

L’article 17 exige une EFVP et une entente écrite avant de communiquer un renseignement personnel à l’extérieur du Québec, et son troisième alinéa applique la même règle quand un fournisseur hors Québec le recueille, l’utilise ou le conserve pour vous. Le critère, c’est le Québec, pas le Canada : une région à Toronto compte.

L’hébergeur est rarement la seule copie. Le suivi des erreurs, le service de courriel, l’analytique, les API d’IA et les sauvegardes hors site gardent chacun quelque chose. Tenez une carte des données dans le dépôt, à côté du code qui ajoute les intégrations, pour qu’une demande de tirage qui ajoute une destination mette aussi la carte à jour :

// privacy/data-map.ts — revue à chaque nouvelle intégration
export const DATA_MAP = [
  { system: "Postgres + sauvegardes", holds: "toutes les données de compte", where: "Montréal (Canner)",          s17: "non requise" },
  { system: "Copie hors site",        holds: "vidages chiffrés",             where: "compartiment de votre choix", s17: "requise si hors Québec" },
  { system: "Courriel transactionnel", holds: "courriel, nom",               where: "vérifier le fournisseur",     s17: "évaluer" },
  { system: "Suivi des erreurs",      holds: "traces de pile",               where: "vérifier le fournisseur",     s17: "évaluer; masquer les RP avant" },
] as const;