Loi 25 et PIPEDA : ce que la conformité exige de votre système d’identité

La Loi 25 est maintenant pleinement en vigueur, avec des sanctions qui peuvent atteindre 25 millions de dollars ou 4 % du chiffre d’affaires mondial. La LPRPDE (PIPEDA) continue de s’appliquer au fédéral. Résultat : la question « où sont exactement nos données d’utilisateurs » n’est plus une note de bas de page dans le questionnaire de sécurité. C’est devenu ce qui bloque les contrats.

Si vous utilisez Keycloak, la bonne nouvelle est que la plupart des exigences techniques sont déjà dans le produit. Encore faut-il savoir quels réglages comptent, parce que plusieurs sont désactivés par défaut.

Qu’exigent la Loi 25 et la LPRPDE d’un système de gestion des identités ?

Les deux lois exigent de savoir quels renseignements personnels vous détenez, de ne les conserver que le temps nécessaire, de les supprimer sur demande, de déclarer les incidents de confidentialité et de pouvoir remettre à une personne ses propres renseignements. La Loi 25 ajoute des règles de consentement explicites, une évaluation des facteurs relatifs à la vie privée (EFVP) avant toute communication de renseignements personnels à l’extérieur du Québec, et un droit à la portabilité. Pour un fournisseur d’identité comme Keycloak, cela se traduit par des durées de conservation, une journalisation d’audit, des mécanismes de suppression, une capacité d’exportation et une réponse claire sur l’emplacement physique de la base de données.

À retenir

• La Loi 25 et la LPRPDE portent surtout sur le processus et la preuve, pas sur une technologie exotique. Keycloak couvre déjà le volet technique.
• L’exigence la plus difficile n’est pas la suppression, c’est de savoir où vivent vos données et de pouvoir le démontrer. C’est une décision d’infrastructure, pas un réglage Keycloak.
• L’EFVP se déclenche à la sortie du Québec, pas du Canada. Héberger à Toronto la déclenche quand même.
• La journalisation des événements Keycloak est désactivée par défaut. Sans elle, vous ne pouvez rien démontrer.

Précision sur la nature de ce texte : il s’agit d’un guide pratique écrit par des gens qui exploitent Keycloak au quotidien. Ce n’est pas un avis juridique, et la Loi 25 comporte des nuances qui dépendent de votre secteur et de votre façon de recueillir le consentement. Consultez un avocat en protection des renseignements personnels pour vos obligations. Revenez ici pour la mise en œuvre.

Où résident réellement vos données d’identité ?

Commencez par là, parce que tout le reste en découle.

La Loi 25 n’interdit pas de communiquer des renseignements personnels à l’extérieur du Québec. Elle exige de réaliser une EFVP au préalable et de confirmer que le territoire destinataire assure une protection adéquate.

Lisez attentivement : le déclencheur est la communication à l’extérieur du Québec, pas à l’extérieur du Canada. Héberger en Ontario ou en Colombie-Britannique déclenche l’évaluation. Elle est généralement facile à satisfaire entre provinces canadiennes, mais elle est déclenchée, et les équipes passent régulièrement à côté parce qu’elles supposent que « au Canada » suffit.

C’est là que la couche d’identité devient délicate. Si votre authentification tourne chez un fournisseur SaaS dont le siège est aux États-Unis, votre table d’utilisateurs, vos sessions, votre journal d’audit et vos empreintes de mots de passe relèvent tous de la juridiction de ce fournisseur, peu importe la région choisie dans sa console.

Liste de vérification concrète :

• Connaissez la région physique de votre base de données Keycloak, pas seulement de l’application.
• Sachez où vont les sauvegardes. Des sauvegardes qui traversent une frontière, c’est le détail le plus souvent oublié.
• Sachez où vont les journaux. Expédier des événements d’audit chez un fournisseur d’observabilité américain réexporte les données que vous veniez de localiser.
• Mettez-le par écrit. Les deux lois récompensent les organisations capables de démontrer leur démarche.

Posez ces deux questions sur les sauvegardes et les journaux à tout fournisseur que vous évaluez, y compris nous. Une réponse vague est une réponse.

Suppression et conservation dans Keycloak

Keycloak supprime proprement les utilisateurs via l’API REST d’administration, et c’est la partie facile. C’est la conservation qui piège les équipes.

Suppression d’un utilisateur. DELETE /admin/realms/{realm}/users/{id} supprime l’utilisateur, ses identifiants, ses consentements et ses liens d’identité fédérée. Les événements d’audit le concernant, eux, demeurent. Décidez délibérément si c’est ce que vous voulez : supprimer la preuve que vous avez supprimé quelqu’un est rarement ce qu’un vérificateur souhaite voir.

Conservation des événements. Keycloak stocke les événements de connexion et d’administration en base, avec une expiration configurable. Fixez une valeur défendable plutôt que de la laisser illimitée :

# Activer les événements et plafonner la conservation des événements de CONNEXION à 180 jours
kcadm.sh update events/config -r monrealm 
  -s eventsEnabled=true 
  -s adminEventsEnabled=true 
  -s adminEventsDetailsEnabled=true 
  -s 'eventsExpiration=15552000'

eventsExpiration est en secondes. 15552000 correspond à 180 jours.

Attention à ce point : eventsExpiration ne gouverne que les événements de connexion. La conservation des événements d’administration passe par un attribut de realm distinct, adminEventsExpiration, qui ne fait pas partie de la représentation events/config. Si vous ne le définissez jamais, vos événements d’administration n’expirent jamais, soit l’inverse de ce que votre politique affirme probablement. Définissez-le explicitement :

# Les événements d'administration expirent séparément.
kcadm.sh update realms/monrealm 
  -s 'attributes.adminEventsExpiration=31536000'

Sessions hors ligne. Les sessions hors ligne survivent aux redémarrages et peuvent conserver des données d’identité bien plus longtemps que prévu. Revoyez Offline Session Idle et Offline Session Max en même temps que votre politique de conservation.

La piste d’audit

La journalisation des événements de Keycloak est désactivée par défaut. C’est l’écart le plus fréquent que nous voyons. Un realm en service depuis deux ans avec les événements désactivés ne peut pas démontrer qui a accédé à quoi, et aucune documentation de politique ne corrige cela rétroactivement.

Activez les deux types :

• Les événements de connexion capturent l’authentification, les échecs, l’émission de jetons et les changements de mot de passe.
• Les événements d’administration capturent les changements de configuration, ce qui vous dit si quelqu’un a discrètement désactivé un réglage de sécurité.

Activez aussi adminEventsDetailsEnabled. Sans lui, vous savez qu’un changement a eu lieu, mais pas vers quoi, ce qui est presque inutile en enquête.

Au-delà d’une conservation courte, exportez les événements vers votre SIEM. La base de données de Keycloak n’est pas conçue comme entrepôt de journaux à long terme.

Accès et portabilité

Les deux lois accordent un droit d’accès, et la Loi 25 ajoute la portabilité : les données doivent être remises dans un format technologique structuré et couramment utilisé.

L’API REST d’administration vous mène presque au bout. GET /admin/realms/{realm}/users/{id} retourne le profil, et des points de terminaison connexes retournent les groupes, les rôles, les consentements et les identités fédérées. La sortie est en JSON, ce qui satisfait « structuré et couramment utilisé ».

L’écart habituel, c’est que personne n’a construit le processus. L’API existe, mais si répondre à une demande implique qu’un ingénieur assemble manuellement quatre appels sous un délai légal, vous n’avez pas vraiment de processus. Scriptez-le avant d’en avoir besoin.

Consentement

La Loi 25 a resserré le consentement : il doit être clair, libre, éclairé et donné à des fins spécifiques, distinctement de toute autre information. L’écran de consentement de Keycloak gère la mécanique pour les clients OAuth, en enregistrant quels scopes ont été approuvés et quand.

Deux points à connaître :

• Le consentement se configure par client, et Consent Required est désactivé par défaut sur les nouveaux clients. Si vous comptez sur Keycloak pour la preuve de consentement, il faut l’activer délibérément.
• Le retrait du consentement est enregistré, et l’utilisateur peut le retirer depuis la console de compte. Ce chemin de retrait est lui-même une exigence de la Loi 25.

Incidents de confidentialité

Les deux lois exigent d’aviser l’autorité et les personnes concernées, mais les seuils sont formulés différemment et ne sont pas interchangeables. La LPRPDE parle d’un « risque réel de préjudice grave ». La Loi 25 parle d’un « risque de préjudice sérieux ». Les deux exigent aussi de tenir un registre des incidents, y compris ceux que vous jugez non déclarables.

Le rôle du système d’identité ici, c’est la détection et la preuve :

• Journalisation des connexions activée, pour établir la portée et la chronologie.
• Détection de force brute activée, pour que le bourrage d’identifiants soit capté et consigné.
• Événements d’administration activés, pour savoir si un attaquant a modifié la configuration.

Liste de vérification

Parlez-en avec un ingénieur Keycloak

Si vous travaillez sur une revue Loi 25 ou LPRPDE et souhaitez un deuxième avis sur votre configuration, réservez un appel avec un ingénieur Keycloak. Skycloak est une entreprise canadienne et notre région canadienne se trouve au Québec, ce qui simplifie la question du transfert hors Québec. Dans tous les cas, vous repartirez avec une idée plus claire de ce que votre installation actuelle peut démontrer, et de ce qu’elle ne peut pas.

Foire aux questions

La Loi 25 exige-t-elle que les données restent au Québec ?

Non. Elle exige une EFVP avant toute communication de renseignements personnels à l’extérieur du Québec, et la confirmation que la destination assure une protection adéquate. Comme le déclencheur est la sortie du Québec, héberger dans une autre province canadienne exige quand même l’évaluation, même si elle est habituellement simple à satisfaire.

Keycloak est-il conforme à la LPRPDE par défaut ?

Aucun produit n’est conforme en soi, puisque la conformité dépend de la configuration et de l’exploitation. Keycloak fournit les capacités techniques attendues (suppression, accès, journalisation, consentement), mais plusieurs sont désactivées par défaut, la journalisation des événements en particulier.

Combien de temps conserver les événements Keycloak ?

Il n’y a pas de durée légale fixe. Choisissez une période défendable au regard de vos besoins de sécurité, inscrivez-la dans votre politique, puis réglez eventsExpiration pour les connexions et l’attribut adminEventsExpiration pour l’administration. Ce sont deux réglages distincts. Beaucoup d’organisations se situent entre 90 et 365 jours.

Utiliser une région infonuagique américaine contrevient-il à la Loi 25 ?

Pas automatiquement, mais cela déclenche l’exigence d’EFVP pour les transferts hors Québec, et signifie que vos données peuvent être assujetties à des procédures judiciaires étrangères. C’est le risque que les organisations soupèsent quand elles demandent une résidence canadienne.

Keycloak peut-il exporter les données d’une personne pour une demande de portabilité ?

Oui. L’API REST d’administration retourne le profil, les groupes, les rôles, les consentements et les identités fédérées en JSON, ce qui répond au critère « format technologique structuré et couramment utilisé ». Prévoyez de scripter l’assemblage de ces appels avant qu’une demande n’arrive.

En bref

La Loi 25 et la LPRPDE demandent cinq choses à votre système d’identité : savoir ce que vous détenez, ne le garder que le temps nécessaire, le supprimer sur demande, prouver ce qui s’est passé, et être clair sur l’endroit où il réside. Keycloak sait faire les cinq, mais la journalisation est désactivée par défaut et la conservation est illimitée tant que vous ne la fixez pas. Un realm laissé tel quel échoue au test de la preuve même quand la technologie en est capable.

Ce que Keycloak ne peut pas régler pour vous, c’est la juridiction. Elle est déterminée par l’endroit où vous l’exploitez, et rappelez-vous que l’évaluation se déclenche à la sortie du Québec, pas du Canada.

Voyez notre hébergement Keycloak infogéré, ou parlez à un ingénieur Keycloak. La version anglaise de ce guide se trouve ici : Keycloak, Quebec Law 25 and PIPEDA.

Sources

• Commission d’accès à l’information du Québec, encadrement de la Loi 25, consulté le 2026-08-21, https://www.cai.gouv.qc.ca/
• Commissariat à la protection de la vie privée du Canada, LPRPDE en bref, consulté le 2026-08-21, https://www.priv.gc.ca/fr/sujets-lies-a-la-protection-de-la-vie-privee/lois-sur-la-protection-des-renseignements-personnels-au-canada/la-loi-sur-la-protection-des-renseignements-personnels-et-les-documents-electroniques-lprpde/pipeda_brief/
• Keycloak, Server Administration Guide, configuration des événements, consulté le 2026-08-21, https://www.keycloak.org/docs/latest/server_admin/