Loi 25 : ce que vos outils internes doivent respecter
La Loi 25 ne vise pas que votre site web. Vos outils internes détiennent des renseignements personnels, et voici ce qui s'applique à eux.
Le journal d'audit paraît inutile jusqu'au jour où quelqu'un doit expliquer qui a modifié quoi.
La plupart des entreprises ont traité la Loi 25 comme un exercice de bannière de témoins sur leur site web. Pendant ce temps, leur CRM, leur système de paie et leur outil de répartition détiennent des renseignements personnels bien plus sensibles, sans qu'aucune de ces obligations n'y ait été appliquée.
Ce que la Loi 25 couvre réellement
La loi vise le renseignement personnel, peu importe où il se trouve. Un nom, une adresse, un numéro de téléphone, une évaluation de rendement, une plainte de client, une photo prise sur un chantier : tout cela entre dans le périmètre, que ce soit dans un site public ou dans un outil auquel seuls vos employés ont accès.
La loi ne fait pas de distinction entre un formulaire public et un tableau de bord interne. Le renseignement est le même.
Un système interne concentre souvent davantage de renseignements sensibles qu'un site web n'en verra jamais. C'est précisément pour cette raison qu'il mérite le même sérieux.
Les cinq obligations qui touchent un outil interne
Sans entrer dans le texte juridique, voici ce qui se traduit concrètement dans la construction d'un logiciel.
- Une finalité déclarée par champ. Vous devez savoir pourquoi chaque renseignement est recueilli. Un champ qui n'a pas de raison d'être ne devrait pas exister.
- Le consentement là où il est requis. Il n'est pas exigé partout, mais lorsqu'il l'est, il doit être clair, distinct et documenté.
- Des règles de conservation et de destruction. Un renseignement ne se garde pas indéfiniment « au cas où ». Il faut une durée, et une destruction qui s'exécute vraiment.
- Un droit d'accès et de rectification. Une personne peut demander ce que vous détenez sur elle, et faire corriger une erreur. Cette demande doit pouvoir être traitée sans mobiliser un développeur.
- Une procédure d'incident. En cas d'incident de confidentialité présentant un risque sérieux, il faut être en mesure de réagir, de consigner et d'aviser.
Ce que cela change dans la construction
Ces obligations ne s'ajoutent pas à la fin d'un projet, elles en façonnent la structure. Concrètement, cela se traduit par des décisions techniques précises.
L'accès par rôle vient en premier. Chaque utilisateur voit ce que sa fonction exige et rien de plus. Nous définissons les rôles avec le client avant la conception du premier écran, parce que des permissions ajoutées après coup finissent toujours par laisser passer quelque chose.
Le journal d'audit vient ensuite. Qui a modifié quoi, quand, et depuis où. Cette table paraît sans intérêt pendant deux ans, puis devient la plus précieuse de la base le jour où un renseignement a disparu ou qu'un client conteste ce qui avait été convenu.
Vient enfin la minimisation, qui est la mesure la plus efficace et la moins appliquée. La donnée la moins coûteuse à protéger, et la seule qui ne peut ni fuir ni être saisie, est celle qui n'a jamais été conservée. Nous recommandons régulièrement de retirer des champs d'un formulaire existant. Le détail de nos pratiques est décrit dans la section sécurité de notre site.
Où se situe la responsabilité avec un logiciel loué
Cette question revient à chaque appel. Avec un abonnement, vous demeurez responsable des renseignements que vous recueillez, même s'ils sont hébergés chez un fournisseur. La loi ne transfère pas cette responsabilité.
Trois points méritent alors d'être vérifiés dans votre contrat actuel : où les données sont physiquement hébergées, ce que le fournisseur s'autorise à en faire, et ce qui se passe à la résiliation. La troisième réponse est souvent la plus dérangeante, parce que la destruction complète est rarement garantie.
Avec un système que vous possédez, ces trois réponses vous appartiennent. Vous choisissez la région d'hébergement, personne d'autre n'exploite les données, et la destruction est une opération que vous exécutez vous-même.
Par où commencer si rien n'a été fait
Un inventaire, avant toute chose. Listez vos outils, et pour chacun, ce qu'il détient comme renseignements personnels. Cet exercice prend une demi-journée et révèle presque toujours deux ou trois systèmes dont personne ne se souvenait.
Ensuite seulement, priorisez. Le système qui détient les dossiers d'employés passe avant celui qui garde les adresses de livraison. Et si un outil ne détient rien de personnel, il ne demande aucun travail : le dire clairement fait aussi partie du travail.
Ce que la Loi 25 ne demande pas
Autant nommer aussi ce qui relève du mythe, parce que la peur fait vendre des services inutiles.
La Loi 25 n'exige pas que vos données soient hébergées au Québec. Elle exige que vous sachiez où elles sont et que la protection y soit équivalente. L'hébergement canadien est un choix prudent et souvent souhaitable, pas une obligation.
Elle n'exige pas non plus une certification, un audit externe annuel ou un logiciel spécialisé. Pour une PME, l'essentiel du travail est de savoir ce qu'on détient, pourquoi, pendant combien de temps, et qui peut y accéder. Un outil bien conçu répond à ces quatre questions sans effort supplémentaire.
Enfin, elle ne s'applique pas à une donnée anonymisée correctement. C'est une piste souvent ignorée : certaines analyses n'ont pas besoin d'identifier qui que ce soit, et le simple fait de retirer l'identifiant fait sortir la donnée du périmètre.
Un système bâti conforme dès la conception
Accès par rôle, journal d'audit, règles de conservation et procédure d'incident, intégrés au moment de la construction plutôt qu'ajoutés après coup.
Voir la section sécurité →À retenir
- La Loi 25 vise le renseignement personnel partout où il se trouve, y compris dans un outil interne auquel le public n'a jamais accès.
- Cinq obligations touchent directement la construction : finalité par champ, consentement, conservation, droit d'accès et procédure d'incident.
- L'accès par rôle et le journal d'audit doivent être conçus dès le premier écran, jamais ajoutés à la fin d'un projet.
- Avec un logiciel loué, la responsabilité demeure la vôtre. Vérifiez l'hébergement, l'usage que le fournisseur se réserve et ce qui arrive à la résiliation.
- Commencez par un inventaire de vos outils et des renseignements qu'ils détiennent. Une demi-journée suffit et révèle presque toujours des systèmes oubliés.
Questions fréquentes
La Loi 25 s'applique-t-elle à un logiciel interne que le public ne voit jamais ?
Oui. La loi vise le renseignement personnel lui-même, pas l'endroit où il se trouve. Un CRM, un système de paie ou un outil de répartition qui détient des noms, des coordonnées ou des dossiers d'employés est soumis aux mêmes obligations qu'un formulaire public.
Sommes-nous responsables si nos données sont chez un fournisseur SaaS ?
Oui, la responsabilité demeure celle de l'entreprise qui recueille les renseignements. L'hébergement chez un tiers ne la transfère pas. Vérifiez dans votre contrat où les données sont hébergées, ce que le fournisseur s'autorise à en faire, et ce qui se passe à la résiliation.
Qu'est-ce qu'un journal d'audit et pourquoi est-il nécessaire ?
C'est un registre qui consigne qui a modifié quoi, quand et depuis où. Il permet de répondre à une demande d'accès, de retracer une modification contestée et de documenter un incident de confidentialité. Sans lui, vous ne pouvez ni prouver ni infirmer ce qui s'est produit.
Combien coûte la mise en conformité d'un outil existant ?
Cela dépend de ce qui manque. L'ajout d'un journal d'audit et d'un accès par rôle à un système déjà bâti représente généralement quelques jours de travail. Reprendre un modèle de données qui mélange tout dans une seule table coûte beaucoup plus cher, ce qui est l'argument principal pour y penser dès la conception.
