Un guide technique, pas un avis juridique
Cet article est rédigé par une équipe d'architectes Odoo, pas par des juristes. Nous décrivons comment Odoo peut supporter les exigences de la Loi 25, avec les configurations que nous déployons en production chez nos clients québécois. La conformité juridique finale dépend toutefois de votre contexte d'affaires, des données traitées et de votre interprétation du texte législatif. Validez toute décision structurante avec votre juriste ou avec la Commission d'accès à l'information (CAI) avant de vous appuyer sur la présente documentation.
Qu'est-ce que la Loi 25 et pourquoi elle redéfinit la conformité au Québec
La Loi 25 — officiellement la Loi modernisant des dispositions législatives en matière de protection des renseignements personnels — a été adoptée par l'Assemblée nationale du Québec en septembre 2021. Elle ne crée pas une nouvelle loi à part entière : elle amende en profondeur la Loi sur la protection des renseignements personnels dans le secteur privé (LPRPSP), en vigueur depuis 1994, ainsi que la Loi sur l'accès aux documents des organismes publics pour le secteur public.
Son déploiement s'est échelonné sur trois phases. La première vague d'obligations est entrée en vigueur en septembre 2022 : désignation d'un responsable de la protection des renseignements personnels, obligation de divulgation des incidents, encadrement des communications pour fins commerciales. La deuxième vague, la plus lourde opérationnellement, est entrée en vigueur en septembre 2023 : consentement granulaire, droits des personnes concernées, évaluations des facteurs relatifs à la vie privée (EFVP), registres de traitement. La troisième phase, concernant le droit à la portabilité des données, est arrivée en septembre 2024.
La Loi 25 s'applique à toute entreprise privée qui exerce une activité au Québec et qui recueille, détient, utilise ou communique des renseignements personnels concernant des personnes physiques — résidents du Québec ou non. Le critère déterminant n'est pas le siège social ni le lieu d'hébergement, mais le fait de traiter des renseignements personnels dans le cadre d'activités exercées au Québec. Une PME ontarienne qui vend en ligne au Québec, un SaaS américain avec des clients québécois, un cabinet comptable en Alberta qui paie la TPS/TVQ — tous doivent s'y conformer.
L'une des raisons pour lesquelles la Loi 25 a retenu l'attention bien au-delà du Québec, c'est son régime de sanctions. La Commission d'accès à l'information peut imposer des sanctions administratives pécuniaires allant jusqu'à 10 M $ CA ou 2 % du chiffre d'affaires mondial, selon le montant le plus élevé. En cas d'infraction pénale, les amendes grimpent à 25 M $ CA ou 4 % du chiffre d'affaires mondial. À titre de comparaison, c'est un régime nettement plus sévère que la LPRPDE fédérale et qui s'aligne sur le RGPD européen. S'ajoute à cela un droit d'action civil qui ouvre la porte à des recours collectifs pour les personnes concernées.
Pour une entreprise qui opère sur Odoo, l'enjeu est concret : les modules CRM, RH, comptabilité, site web et commerce électronique contiennent tous des renseignements personnels visés par la loi. Un déploiement Odoo mal paramétré — audit log désactivé, consentements agrégés, accès trop large aux employés — expose l'entreprise aussi bien à une plainte à la CAI qu'à un risque réputationnel en cas d'incident. Les sections suivantes décrivent, de façon aussi pratique que possible, comment nous configurons Odoo chez Octura pour refléter les exigences de la loi.
Les obligations principales de la Loi 25 à traduire dans votre ERP
La Loi 25 impose une dizaine d'obligations concrètes. Toutes ne sont pas techniques — certaines sont gouvernance pure, d'autres relèvent des politiques de l'entreprise. Mais la majorité finissent par laisser une trace dans l'ERP, parce que c'est là que vivent les données clients, employés, fournisseurs et prospects.
Désigner un responsable de la protection des renseignements personnels (RPRP)
Toute entreprise doit désigner un responsable de la protection des renseignements personnels. Par défaut, la fonction revient à la personne ayant la plus haute autorité au sein de l'organisation (souvent le président ou le directeur général), mais elle peut être déléguée par écrit à un cadre, à un employé ou même à un prestataire externe. Le nom et les coordonnées du RPRP doivent être publiés sur le site web de l'entreprise. La CAI consulte cette page en priorité lors d'une plainte.
Publier une politique de confidentialité claire et accessible
La politique de confidentialité doit être rédigée en termes simples et décrire : les catégories de renseignements recueillis, les finalités, les moyens utilisés, les tiers avec qui les renseignements sont partagés, la durée de conservation, les droits des personnes concernées et les coordonnées du RPRP. Elle doit être disponible sur votre site web avant toute collecte.
Procédures d'incident et notification obligatoire
En cas d'incident de confidentialité — accès non autorisé, utilisation ou communication non autorisée, perte de renseignements — l'entreprise doit évaluer si l'incident présente un risque de préjudice sérieux (au sens de la loi). Si oui, elle a l'obligation de notifier : (1) la Commission d'accès à l'information, (2) les personnes concernées, et (3) de tenir un registre des incidents, conservé cinq ans minimum. Le registre doit exister même pour les incidents qui ne déclenchent pas de notification.
Consentement granulaire, libre et éclairé
Le consentement doit être demandé à chaque finalité distincte. Une seule case à cocher « J'accepte la politique de confidentialité » est insuffisante dès qu'il y a plusieurs finalités (infolettre marketing, partage avec partenaires, analyses comportementales, etc.). Le consentement doit être présenté de façon distincte du reste des conditions générales, et il doit être aussi facile à retirer qu'à donner.
Droits d'accès, de rectification, de portabilité et d'effacement
Toute personne physique peut exercer, auprès de l'entreprise, quatre droits distincts : obtenir accès aux renseignements la concernant, en demander la rectification s'ils sont inexacts, exiger leur portabilité dans un format structuré et couramment utilisé, et dans certains cas demander la cessation de la diffusion ou l'effacement (le « droit à la déréférenciation »). L'entreprise a 30 jours pour répondre à la demande. Le traitement de ces demandes doit être documenté.
Évaluation des facteurs relatifs à la vie privée (EFVP)
Une EFVP est une analyse documentée obligatoire pour tout projet d'acquisition, de développement ou de refonte de système d'information impliquant des renseignements personnels. Une implantation Odoo chez un nouveau client, un changement de module RH, une intégration avec un CRM tiers — tous ces projets peuvent déclencher l'exigence. La CAI a publié un guide méthodologique que nous recommandons de suivre systématiquement, même pour les projets internes.
Communication hors Québec et transferts transfrontaliers
La Loi 25 ne prohibe pas les transferts de renseignements hors du Québec. Elle exige toutefois que l'entreprise, avant tout transfert, réalise une EFVP spécifique qui évalue le niveau de protection offert dans la juridiction de destination. Si le niveau est jugé insuffisant, l'entreprise doit mettre en place des mesures contractuelles ou techniques compensatoires. Cette obligation s'applique même aux transferts intra-groupes et aux prestataires infonuagiques. Pour un déploiement Odoo.sh, par exemple, la localisation du data center (Montréal, Francfort, Virginia) a des implications directes sur la documentation à produire.
L'erreur la plus fréquente dans nos audits de conformité : l'entreprise n'a pas de traces écrites de ses évaluations. Même quand l'analyse conclut qu'aucune notification n'est requise, il faut conserver la trace de l'évaluation elle-même. En cas de plainte, c'est ce registre qui démontre la diligence raisonnable. Un document Word daté, signé et archivé vaut mieux qu'aucun document.
Comment Odoo peut supporter vos obligations Loi 25
Odoo n'est pas « certifié Loi 25 » — aucun ERP ne l'est, et cette étiquette n'existe pas en droit québécois. Ce qui existe, c'est un ensemble de mécanismes techniques natifs, complétés par quelques modules OCA (Odoo Community Association), qui permettent à un client de documenter sa conformité de manière crédible. Voici comment nous utilisons ces mécanismes en production.
Gestion des consentements
Le module communautaire privacy_consent (maintenu par l'OCA) permet de créer des types de consentement par finalité, de les lier à des contacts (res.partner) et de suivre l'historique complet de chaque acceptation ou retrait, avec horodatage et adresse IP. Ce module couvre à la fois les consentements marketing et les consentements contractuels. Pour les sites web Odoo, le module website_gdpr et ses dérivés ajoutent une bannière de consentement configurable, avec catégorisation des cookies.
Journalisation et audit trail natif
Odoo journalise nativement toutes les modifications de champs tracked via le modèle mail.message et mail.tracking.value. Chaque changement produit une entrée horodatée, liée à l'utilisateur, visible dans le fil de discussion du document. Pour des besoins d'audit plus poussés, le module auditlog (OCA) étend la journalisation à toutes les opérations CRUD (create, read, write, unlink) sur les modèles de votre choix, avec conservation dans une table dédiée et indépendante du modèle source.
<odoo>
<data noupdate="1">
<!-- Audit sur res.partner (clients, fournisseurs, contacts) -->
<record id="rule_audit_partner" model="auditlog.rule">
<field name="name">Audit - res.partner</field>
<field name="model_id" ref="base.model_res_partner"/>
<field name="log_read" eval="True"/>
<field name="log_create" eval="True"/>
<field name="log_write" eval="True"/>
<field name="log_unlink" eval="True"/>
<field name="state">subscribed</field>
</record>
<!-- Audit sur hr.employee (dossiers employés) -->
<record id="rule_audit_employee" model="auditlog.rule">
<field name="name">Audit - hr.employee</field>
<field name="model_id" ref="hr.model_hr_employee"/>
<field name="log_read" eval="True"/>
<field name="log_create" eval="True"/>
<field name="log_write" eval="True"/>
<field name="log_unlink" eval="True"/>
<field name="state">subscribed</field>
</record>
<!-- Audit sur account.move (pièces comptables) -->
<record id="rule_audit_account_move" model="auditlog.rule">
<field name="name">Audit - account.move</field>
<field name="model_id" ref="account.model_account_move"/>
<field name="log_create" eval="True"/>
<field name="log_write" eval="True"/>
<field name="log_unlink" eval="True"/>
<field name="state">subscribed</field>
</record>
</data>
</odoo>Contrôle d'accès par rôles (RBAC)
Odoo implémente un modèle de sécurité à deux niveaux : les groupes d'accès (res.groups) qui définissent les permissions CRUD par modèle via ir.model.access, et les règles d'enregistrement (ir.rule) qui filtrent les lignes accessibles par une condition SQL. Combinés correctement, ces deux mécanismes permettent d'appliquer le principe de moindre privilège exigé par la Loi 25 : un commis à la facturation n'a pas à voir les salaires, un recruteur n'a pas à voir les comptes bancaires, un stagiaire marketing n'a pas à voir l'ensemble de la base clients.
Chiffrement au repos et en transit
Sur Odoo.sh et chez les hébergeurs professionnels, le trafic HTTP est terminé en TLS 1.3 avec HSTS activé. Au niveau base de données, PostgreSQL peut être configuré avec Transparent Data Encryption (TDE) soit via une solution de chiffrement disque (LUKS, dm-crypt) soit via des extensions comme pgcrypto pour les champs les plus sensibles. Les sauvegardes doivent également être chiffrées avant leur dépôt dans un stockage externe. Nous recommandons systématiquement de vérifier ces trois couches — transport, stockage et backup — dans le cadre de l'EFVP.
Masquage de champs et pseudonymisation
Le module field_security de l'OCA permet de masquer dynamiquement certains champs selon le groupe de l'utilisateur. Couplé à data_anonymization, il est possible de pseudonymiser les environnements de développement et de test — exigence forte de la Loi 25 qui considère les bases de test non anonymisées comme des environnements de production du point de vue des risques.
Politiques de rétention et suppression automatisée
La Loi 25 exige que les renseignements soient détruits ou anonymisés lorsque la finalité pour laquelle ils ont été recueillis est atteinte. Concrètement, cela signifie qu'un candidat non retenu à un poste ne devrait pas conserver son CV dans la base RH pendant dix ans. Odoo supporte cette exigence via les actions planifiées (ir.cron) qui peuvent exécuter du code de purge ou d'anonymisation à intervalle régulier.
from datetime import date, timedelta
def _cron_anonymize_old_applicants(env):
"""Anonymise les candidats refusés depuis plus de 2 ans.
Base juridique : finalité atteinte (processus de recrutement clos),
pas de consentement actif pour conservation prolongée.
"""
cutoff = date.today() - timedelta(days=730)
applicants = env['hr.applicant'].search([
('kanban_state', '=', 'blocked'), # refusés
('write_date', '<', cutoff),
('partner_id.active', '=', True),
])
for app in applicants:
app.partner_id.write({
'name': f'[Anonymisé-{app.id}]',
'email': False,
'phone': False,
'mobile': False,
'street': False,
'city': False,
'zip': False,
})
app.message_post(
body="Données personnelles anonymisées "
"(politique de rétention : 24 mois post-refus).",
)
return len(applicants)Flux de demandes d'accès (DSAR) via Helpdesk
Un client nous a demandé, en 2024, comment il pouvait démontrer à la CAI qu'il répondait aux demandes d'accès dans les 30 jours. Notre réponse : matérialiser le processus dans un pipeline Helpdesk dédié, avec des étapes standardisées (Réception → Vérification identité → Extraction → Révision RPRP → Réponse) et un SLA de 25 jours calendaires pour laisser une marge de sécurité. Chaque ticket devient un document de preuve en cas de contestation.
Configuration étape par étape dans Odoo
Voici la séquence d'actions concrète que nous exécutons lors d'un audit Loi 25 chez un client Odoo. Les temps indiqués sont des estimations pour un environnement de taille moyenne (20 à 100 utilisateurs, 3 à 5 modules actifs).
1. Activer l'authentification à deux facteurs (2FA) pour tous les utilisateurs
Dans Paramètres > Utilisateurs > Gestion des utilisateurs, activer la politique d'authentification à deux facteurs pour tous les utilisateurs internes, en particulier ceux ayant accès à des modules avec données personnelles (RH, CRM, Comptabilité). L'authentification peut utiliser TOTP (Google Authenticator, Authy) ou des clés matérielles U2F/WebAuthn pour les comptes administrateurs.
2. Configurer les groupes d'accès minimum
Faire l'inventaire des groupes d'utilisateurs et retirer les droits non strictement nécessaires. Le groupe base.group_user est souvent sur-permissif dans les installations non auditées — en particulier pour res.partner où il accorde par défaut la lecture de tous les contacts. Créer au besoin des ir.rule personnalisées pour restreindre les accès par équipe ou par département.
3. Activer l'audit log sur les modèles sensibles
Installer le module auditlog depuis l'OCA et activer les règles sur au minimum : res.partner, res.users, hr.employee, hr.contract, account.move, account.payment. La surcharge en performance est marginale (< 5 %) tant que l'on évite log_read=True sur des modèles à très fort volume de lecture.
4. Publier la politique de confidentialité et la page RPRP
Créer deux pages statiques sur le site Odoo : /politique-confidentialite et /responsable-protection-renseignements. La deuxième doit contenir le nom, la fonction et les coordonnées directes (courriel et téléphone) du RPRP. Lier ces deux pages depuis le pied de page du site et depuis toutes les bannières de consentement.
5. Mettre en place le pipeline Helpdesk pour les demandes DSAR
Dans le module Helpdesk, créer une équipe dédiée « Droits Loi 25 ». Configurer un formulaire web public avec champs : nature de la demande (accès, rectification, portabilité, effacement), identification de la personne, justificatifs. Ajouter un SLA de 25 jours. Assigner automatiquement les tickets au RPRP avec un escalation à 20 jours.
6. Programmer les actions de rétention
Créer les actions planifiées d'anonymisation et de purge pour chaque catégorie de données : candidats refusés (24 mois), prospects non convertis (36 mois), anciens employés (conformément aux obligations fiscales et aux Normes du travail — généralement 6 ans), logs d'audit eux-mêmes (5 ans pour les incidents, plus court pour les lectures de routine).
Un réflexe dangereux : purger les logs d'audit « pour gagner de l'espace disque ». Le registre des incidents doit être conservé cinq ans par la loi, et les journaux d'accès qui documentent un incident doivent être conservés aussi longtemps que le registre lui-même. Avant d'activer toute purge de logs, faites valider la durée par votre juriste et documentez-la dans votre politique de rétention.
Audit, preuves et rapports exportables
Démontrer la conformité, ce n'est pas seulement configurer : c'est produire des preuves à la demande. Voici les rapports que nous livrons à nos clients dans le cadre d'un audit annuel Loi 25, tous exportables depuis Odoo.
Rapport de consentements. Export CSV ou PDF de tous les consentements actifs et retirés, par finalité, avec date, canal (formulaire web, téléphone, signature contractuelle) et version de la politique alors en vigueur. Ce rapport se génère à partir du modèle privacy.consent via une vue de liste filtrée et l'action Exporter native.
Rapport des accès aux données sensibles. Export des entrées auditlog.log pour les modèles RH, comptables et CRM, filtré par période et par utilisateur. Ce rapport permet de répondre à une question courante de la CAI : « qui a consulté le dossier de monsieur X entre le 1er janvier et le 30 juin ? ». Sans audit log activé en amont, la question est impossible à répondre.
Registre des incidents. Nous créons un modèle personnalisé loi25.incident chez nos clients, avec les champs imposés par le Règlement sur les incidents de confidentialité : date de découverte, nature, catégories de renseignements touchés, nombre de personnes concernées, mesures prises, décision de notification (oui/non) avec motivation. Le registre est consultable par le RPRP et ses délégués uniquement, avec audit log activé.
Traces de demandes DSAR. Les tickets Helpdesk de l'équipe « Droits Loi 25 » constituent eux-mêmes la trace. Un rapport trimestriel sur le respect des SLA (pourcentage de tickets clos dans les 30 jours) devrait être produit automatiquement et soumis au RPRP.
Tous ces rapports peuvent être automatisés via des server actions programmées qui envoient un courriel au RPRP le premier lundi de chaque mois, avec les extractions en pièce jointe. Cette cadence mensuelle vaut documentation continue de la gouvernance et est fortement recommandée par le guide CAI pour les entreprises de plus de 50 employés.
Sanctions, risques financiers et risques réputationnels
Le régime de sanctions se décompose en trois volets. Les sanctions administratives pécuniaires (SAP), imposées directement par la CAI après enquête, peuvent atteindre 10 M $ CA ou 2 % du chiffre d'affaires mondial de l'exercice précédent, selon le montant le plus élevé. Les sanctions pénales, prononcées par les tribunaux, peuvent atteindre 25 M $ CA ou 4 % du chiffre d'affaires mondial. Les sanctions sont doublées en cas de récidive.
S'ajoute à cela un droit d'action civil pour les personnes concernées, avec la possibilité de recours collectifs. L'article 93.1 LPRPSP prévoit explicitement des dommages-intérêts punitifs minimaux en cas d'atteinte intentionnelle ou de faute lourde. Au-delà des amendes, l'exposition réputationnelle est majeure : la CAI publie certaines de ses décisions, et les incidents de confidentialité font presque systématiquement l'objet d'une couverture médiatique au Québec. Un client perdu en raison d'un incident mal géré peut valoir plus cher que l'amende elle-même.
Questions fréquentes sur la conformité Loi 25 avec Odoo
Si votre entreprise recueille, détient, utilise ou communique des renseignements personnels concernant des personnes physiques dans le cadre d'activités exercées au Québec, oui. Le siège social n'est pas déterminant : une entreprise ontarienne ou américaine avec des clients québécois y est assujettie. Consultez un juriste en cas de doute sur votre situation particulière.
Non — aucun ERP n'est « conforme par défaut ». Odoo fournit l'ensemble des mécanismes techniques requis (audit log, RBAC, chiffrement, consentement), mais la conformité dépend de leur configuration, des politiques internes et des processus humains qui les entourent. C'est l'équivalent d'une voiture avec ceinture de sécurité : l'outil existe, mais il faut l'utiliser.
Par défaut, la personne ayant la plus haute autorité au sein de l'organisation. Elle peut déléguer la fonction par écrit à un cadre, un employé ou un prestataire externe. Dans les PME, c'est souvent le président, le DAF ou le DG. Dans les grandes organisations, un responsable dédié (souvent rattaché au service juridique ou à la conformité) est recommandé.
Pour un déploiement Odoo existant de 20 à 100 utilisateurs, un audit initial et une mise à niveau couvrant audit log, RBAC, politique de rétention et pipeline DSAR représentent typiquement entre 8 000 $ et 25 000 $ CA en prestations externes, plus le temps interne du RPRP. C'est nettement inférieur au coût d'un seul incident mal géré.
C'est une loi québécoise qui s'applique aux activités exercées au Québec. Les autres provinces sont couvertes par la LPRPDE fédérale ou par leurs propres lois provinciales (BC-PIPA, AB-PIPA). Une entreprise pancanadienne doit donc généralement naviguer plusieurs régimes en parallèle. La Loi 25 étant la plus stricte, s'y conformer couvre souvent la majorité des exigences des autres provinces.
Oui, mais avec obligations. Tout transfert hors Québec doit faire l'objet d'une EFVP documentée qui évalue le niveau de protection de la juridiction de destination. Pour un déploiement Odoo.sh sur un data center hors Canada, nous recommandons fortement de choisir Montréal quand l'option est disponible, ou à défaut de mettre en place des clauses contractuelles et des mesures techniques compensatoires (chiffrement au repos avec clés détenues localement, par exemple).
La CAI a publié un guide méthodologique en ligne. L'EFVP doit au minimum : décrire le projet, cartographier les flux de données, identifier les risques, évaluer les mesures de mitigation, documenter les décisions. Pour un projet Odoo, nous utilisons un gabarit Confluence de 15 à 20 pages qui structure l'analyse par module. Il est important que l'EFVP soit datée, signée par le RPRP et archivée.
Trois réflexes dans les 72 heures : (1) contenir techniquement l'incident (isoler les systèmes, révoquer les accès), (2) consigner l'incident dans le registre avec toute l'information disponible, (3) évaluer avec le RPRP et votre juriste si le risque de préjudice sérieux déclenche l'obligation de notifier la CAI et les personnes concernées. N'attendez pas d'avoir toutes les réponses pour consigner : le registre doit refléter l'état de la connaissance à chaque étape.