Modèle de PIA pré-rempli, aligné sur la Directive sur l'évaluation des facteurs relatifs à la vie privée du SCT, à l'intention des ministères fédéraux canadiens qui déploient AccessPoint

Last updated: July 12, 2026 by Steve

Évaluation des facteurs relatifs à la vie privée du GC

Cette page constitue un résumé public de l'évaluation des facteurs relatifs à la vie privée (PIA) préparée par l'éditeur du logiciel (Realizer Services Inc.) pour AccessPoint, en conformité avec la Directive sur l'évaluation des facteurs relatifs à la vie privée du Secrétariat du Conseil du Trésor du Canada (SCT). Elle documente les fonds de renseignements personnels, les flux de renseignements, les risques pour la vie privée et les mesures de protection intégrées au produit.

Le PIA de l'éditeur couvre les sections techniques et architecturales et vise à aider les institutions fédérales canadiennes à compléter leur propre PIA. L'institution déployante complète les détails institutionnels (aperçu institutionnel, calendriers de conservation, ententes de partage de renseignements et approbation), puis soumet le PIA complété au SCT et au Commissariat à la protection de la vie privée du Canada (CPVP). Le PIA complet est offert aux clients sur demande — voir la remarque finale.

Pour l'architecture technique complète, consultez la page Architecture technique. Pour la correspondance des contrôles de sécurité ITSG-33, consultez la page Référence des contrôles de sécurité du GC.

Objet et portée

AccessPoint est une plateforme de gestion de l'accès à l'information et de la protection de la vie privée qui aide les institutions gouvernementales à administrer leurs programmes d'accès et de protection de la vie privée en conformité avec la Loi sur l'accès à l'information (ATIA), la Loi sur la protection des renseignements personnels et les régimes provinciaux ou internationaux équivalents. Sa fonction principale est la gestion des demandes d'accès des personnes concernées et des demandes d'accès à l'information — l'ensemble du cycle de vie, de la réception à l'assignation, en passant par la collecte de documents, l'examen, le caviardage et l'assemblage des réponses.

Au-delà du traitement des demandes, AccessPoint prend également en charge l'ensemble du programme de protection de la vie privée : les évaluations des facteurs relatifs à la vie privée (évaluations PIA/AIA/sécurité), la gestion des incidents et des atteintes à la vie privée (y compris les flux de travail de notification des atteintes), les plaintes et appels, un registre des risques liés à la vie privée et un registre des engagements, ainsi que le registre des activités de traitement (ROPA). Ces modules traitent des catégories additionnelles de renseignements personnels et sont couverts par les mêmes mesures de protection, rôles, registre d'audit et garanties de résidence des données que le cœur de la gestion des demandes.

Processus opérationnel : réception (un SAO crée la demande) → assignation (les détenteurs de dossiers reçoivent des instructions épurées, sans RPI du demandeur) → collecte de documents → examen et caviardage → assemblage de la réponse → clôture (le délai de rétention commence).

Personnes concernées : les demandeurs; les employés de l'institution (SAO, Administrator) dont les actions sont consignées dans la piste d'audit; les détenteurs de dossiers (Custodian) et les contributeurs (Contributor), qui n'ont pas accès aux RPI du demandeur; les tiers dont les RPI peuvent figurer dans les documents examinés; les personnes concernées décrites au niveau de la catégorie dans le ROPA et les évaluations; les personnes touchées par un incident de confidentialité; les plaignants et les parties à une plainte; ainsi que les personnes-ressources de consultation.

Autorité légale : la collecte et l'utilisation reposent principalement sur l'ATIA (art. 4, 6, 9 et 19) et sur la Loi sur la protection des renseignements personnels (art. 4, 5, 7, 8(2)(m), ainsi que le droit d'accès de la personne concernée).

Inventaire des renseignements personnels

Renseignements personnels recueillis et traités

Élément de données Sensibilité Source Objectif Stocké dans
Nom complet du demandeur Moyenne Demandeur (via la réception) Identifier le demandeur, correspondance Azure SQL
Adresse courriel du demandeur Moyenne Demandeur Correspondance par courriel Azure SQL
Adresse postale du demandeur Moyenne Demandeur Livraison de la réponse par la poste Azure SQL
Numéro de téléphone du demandeur Faible-Moyenne Demandeur Correspondance téléphonique Azure SQL
Organisation du demandeur Faible Demandeur Rapports statistiques Azure SQL
Description de la demande Moyenne Demandeur Définir la portée de la recherche Azure SQL
Nom du sujet Moyenne-Élevée Demandeur (via la réception) Identifier le sujet de la demande (peut différer du demandeur) Azure SQL
Date de naissance du sujet Élevée Demandeur (via la réception) Vérification d'identité pour les demandes de protection des renseignements personnels Azure SQL
Noms, courriels et ID d'objet Entra des employés Faible Entra ID Identification des utilisateurs, notifications, authentification, audit Azure SQL
Piste d'audit (actions des utilisateurs) Faible-Moyenne Généré par le système Responsabilisation, conformité Azure SQL
Documents en cours d'examen Potentiellement élevée Dossiers de l'institution Préparation de la réponse ATIA Azure Blob Storage
Versions caviardées des documents Moyenne Généré par le système Assemblage de la réponse Azure Blob Storage
Dossiers d'attestation et signatures électroniques (nom tapé) Faible-Moyenne Custodian Approbation formelle de l'exhaustivité Azure SQL
Adresses IP et chaînes user agent (attestation, accès aux documents) Faible-Moyenne Capturé par le système Audit judiciaire du contexte de signature ou d'accès Azure SQL
Communications du demandeur Moyenne Personnel SAO Dossiers de correspondance (sens, méthode, date, notes) Azure SQL
Dossiers de délégation Faible-Moyenne SAO/Administrator Délégation de responsabilité d'agent Azure SQL
Dossiers de consultation et répertoire de contacts Faible-Moyenne Personnel SAO Consultation interministérielle ou externe Azure SQL
Répertoire de contacts des demandeurs Moyenne Demandeur / personnel de réception Identité de demandeur réutilisable; la demande est liée à un contact plutôt que de stocker les RPI directement Azure SQL
Détails des RPI touchés par un incident Potentiellement élevée Personnel de la protection de la vie privée/ATIP Faits relatifs à l'incident, catégories de RPI touchés, évaluation du préjudice, suivi de la notification des atteintes Azure SQL
Parties à la plainte et correspondance Moyenne Personnel de la protection de la vie privée/ATIP Identité du plaignant ou de la partie et traitement de la plainte Azure SQL
Catégories du registre des activités de traitement (ROPA) Faible-Moyenne Personnel de la protection de la vie privée Descriptions conformes à GDPR Article 30, par catégorie de personne concernée ou de destinataire — pas de dossiers individuels Azure SQL
Réponses aux questionnaires d'évaluation Faible-Moyenne Personnel de la protection de la vie privée / délégués Contenu PIA/AIA/sécurité; peut décrire les RPI traités par un programme Azure SQL
Dossiers capturés depuis Microsoft 365 (activation facultative) Potentiellement élevée Les propres données M365 du détenteur de dossiers Courriels, calendrier, OneNote, discussions Teams ou interactions Copilot capturés par le détenteur de dossiers à titre de document pertinent Azure Blob Storage (PDF convertis)
Registre d'audit chaîné par hachage Faible-Moyenne Généré par le système Registre inviolable et à ajout seul des actions de tous les modules Azure SQL

Renseignements personnels NON recueillis

AccessPoint ne recueille ni ne traite : les numéros d'assurance sociale; les renseignements financiers (comptes bancaires, cartes de crédit); les dossiers médicaux ou de santé en tant que données structurées (ils peuvent toutefois figurer dans les documents examinés); les données biométriques; les renseignements sur le casier judiciaire; les données de localisation; ou les témoins de connexion et identifiants de suivi.

Remarque : les adresses IP et les chaînes user agent ne sont capturées que dans des contextes limités (signature d'attestation et journalisation de l'accès aux documents) à des fins d'audit judiciaire, comme indiqué ci-dessus. Le comportement de navigation général et l'empreinte numérique des appareils ne sont pas recueillis.

Renseignements personnels sensibles dans les documents

Les documents recueillis dans le cadre du processus ATIA peuvent contenir toute catégorie de renseignements personnels, y compris des RPI sensibles concernant des tiers. AccessPoint n'analyse ni n'indexe le contenu des documents — il les stocke, les prévisualise et facilite leur caviardage. La classification et l'exemption des RPI contenus dans les documents sont effectuées par des SAO formés, à l'aide des outils d'examen intégrés.

Capture de dossiers Microsoft 365 (activation facultative, contrôlée par une bascule de fonctionnalité) : un Custodian peut capturer ses propres dossiers Microsoft 365 — courriels Outlook, calendrier Outlook, OneNote, discussions Teams, listes Microsoft ou historique d'interactions Copilot — à titre de document pertinent. La capture utilise toujours la propre identité déléguée de l'utilisateur connecté et se limite aux données de cet utilisateur (la récupération Copilot est de type application uniquement, puisqu'aucune permission Graph déléguée n'existe pour cette fonction, mais elle est toujours limitée côté serveur à l'ID d'objet Entra propre de l'utilisateur connecté — jamais à l'ensemble du locataire). Le contenu capturé est converti en PDF et intègre le flux normal d'examen et de caviardage. La capture du calendrier exclut par défaut les éléments marqués Privé/Personnel/Confidentiel.

Analyse des flux de renseignements personnels

Étape Résumé
Collecte Les RPI sont recueillis en vertu de l'art. 6 de l'ATIA (la soumission d'une demande exige le nom et l'adresse) et de l'art. 4 de la Loi sur la protection des renseignements personnels (collecte liée à un programme opérationnel). Seuls les RPI nécessaires au traitement de la demande sont recueillis, directement auprès du demandeur, et saisis par le personnel SAO. Les champs sont configurables par l'institution.
Utilisation Les RPI du demandeur sont utilisés uniquement pour traiter la demande ATIA/Loi sur la protection des renseignements personnels. Seuls les rôles Administrator, SAO et Reviewer peuvent voir les RPI du demandeur — les Custodian et Contributor ne les voient jamais (application côté serveur par l'intergiciel de filtrage des RPI). Aucune prise de décision automatisée, aucun profilage ni traitement algorithmique n'a lieu; toutes les décisions sont prises par du personnel formé. Les rapports statistiques sont uniquement agrégés.
Communication Le dossier de réponse est fourni au demandeur (art. 7 de l'ATIA). La communication interne au personnel SAO/Reviewer est contrôlée par les rôles; les Custodian/Contributor ne reçoivent que des instructions épurées. Les notifications par courriel et Teams destinées aux Custodian/Contributor ne contiennent aucun RPI du demandeur. L'éditeur ne reçoit que l'ID du locataire (validation de licence), les métadonnées de notification (ID utilisateur du destinataire, type d'activité, nom d'affichage de l'acteur, numéro de demande, texte d'aperçu ou de sujet, référence au dossier associé) et les rapports d'installation des packs de configuration — aucun RPI du demandeur. Microsoft traite les données à titre de sous-traitant au sein du locataire propre de l'institution.
Rétention et élimination Une fonction intégrée de révision de la rétention applique des périodes de rétention configurables par type de demande. La purge supprime définitivement les dossiers de demandes, documents, assignations, tâches, attestations et l'historique d'audit, et est consignée dans la table RetentionPurgeLog. Les sauvegardes automatisées Azure SQL conservent les données pendant 7 à 35 jours selon le niveau (rétention à long terme configurable).
Exactitude Les RPI du demandeur sont saisis à partir du formulaire de demande original; les RPI des employés proviennent d'Entra ID et sont actualisés à chaque connexion. Les RPI sont stockés tels que saisis — le système ne les transforme pas, ne les déduit pas et n'en dérive pas d'autres.

Le parcours des notifications illustre le contrôle « aucun RPI du demandeur transmis à l'éditeur » :

Event (e.g., assignment created)
        │
        ▼
  API Notification Dispatch Service
        │
        ├── PII Filter: strips requestor PI for Custodian/Contributor templates
        │
        ├──► Email: Graph Mail.Send → Institution's shared mailbox → Recipient
        │    (via managed identity or institution's app registration)
        │
        └──► Teams: API → Realizer Platform API → Graph TeamsActivity.Send → Recipient
             (sends: user ID, activity type, actor name, request number, preview text — NO requestor PI)

Évaluation des risques pour la vie privée

Risque Probabilité Impact Atténuation Risque résiduel
Accès non autorisé aux RPI du demandeur Faible Moyen RBAC à six niveaux avec application côté serveur; Custodian/Contributor architecturalement exclus des RPI; AMF Entra ID; vérification des rôles à chaque demande. Faible
Atteinte aux RPI par exposition de documents Faible-Moyenne Moyen-Élevé Chiffrement au repos (TDE, AES-256); autorisation basée sur les rôles; aucun accès public aux documents; les outils de caviardage retirent les RPI avant l'assemblage de la réponse. Faible-Moyen
RPI dans les notifications Très faible Faible Les modèles Custodian/Contributor suppriment automatiquement les RPI; les notifications SAO comprennent le numéro de demande mais pas l'identité du demandeur; les notifications Teams ne contiennent que le type de notification, le numéro de demande et le nom de la tâche ou de l'assignation. Très faible
Transmission de RPI à l'éditeur Très faible Faible L'éditeur ne reçoit que l'ID du locataire (licence) et les métadonnées de notification — aucun RPI, document ou détail de demande — et n'a aucun accès permanent aux ressources Azure de l'institution. Très faible
RPI hors de la juridiction canadienne Selon la configuration Moyen Les données sont stockées dans l'abonnement Azure de l'institution, dans la région qu'elle sélectionne (Canada Centre/Est recommandé); l'entente Microsoft Cloud Agreement traite de la résidence des données. À évaluer par l'institution
Rétention/élimination inadéquate Faible-Moyenne Moyen Révision de la rétention intégrée avec périodes configurables et journalisation des purges; l'institution harmonise ses calendriers de conservation avec les autorités de disposition de Bibliothèque et Archives Canada. Faible (avec une configuration appropriée)
Menace interne (utilisation abusive par un utilisateur autorisé) Faible Moyen Piste d'audit complète avec attribution à l'utilisateur et horodatage; l'accès basé sur les rôles limite l'exposition; les Administrator contrôlent les attributions de rôles. Faible

Scores par domaine de risque

Selon le cadre normalisé du SCT :

Domaine de risque Score Justification
Type de programme ou d'activité 2 Administration d'un programme ou d'une activité (administration de l'ATIA)
Type de renseignements personnels 3 Coordonnées et dossiers potentiellement sensibles dans les documents
Partenaires du programme 2 Microsoft (sous-traitant); Realizer (aucun accès aux RPI)
Durée du programme 4 Obligation légale à long terme ou continue
Population du programme 3 Personnes externes exerçant des droits prévus par la loi
Transmission de renseignements personnels 2 Infrastructure infonuagique chiffrée au sein de la juridiction canadienne
Technologie et vie privée 2 Application Web standard — aucune IA, surveillance ou biométrie
Impact potentiel sur la personne 2-3 Embarras possible ou atteinte à la réputation en cas de divulgation de l'identité du demandeur

Niveau de risque global : modéré — un niveau standard pour un programme administratif traitant les RPI de personnes externes, atténué par des contrôles techniques robustes (chiffrement, RBAC, filtrage des RPI, souveraineté des données).

Mesures de protection techniques et administratives

Authentification et contrôle d'accès

Mesure de protection Mise en œuvre
Authentification Microsoft Entra ID avec jetons porteurs JWT. Aucun compte utilisateur ni mot de passe local.
Authentification multifacteur Appliquée par les politiques d'accès conditionnel Entra ID de l'institution.
Évaluation continue de l'accès Prise en charge — la validation des jetons a lieu à chaque demande API.
Contrôle d'accès basé sur les rôles Six rôles appliqués côté serveur sur tous les points de terminaison de l'API.
Filtrage des RPI Un intergiciel côté serveur retire les RPI du demandeur des réponses destinées aux rôles Custodian, Contributor et Reader; il ne peut être contourné par le client.
Gestion des sessions Basée sur des jetons; la durée de vie est régie par les politiques Entra ID.
Amorçage du premier utilisateur Le premier utilisateur se voit attribuer les rôles Administrator et SAO. Aucun identifiant par défaut ou partagé n'existe.

Chiffrement

Couche Mise en œuvre
En transit TLS 1.3 minimum en périphérie de l'App Service; TLS 1.2 ou supérieur sur Azure SQL et Blob Storage; FTPS désactivé.
Au repos — base de données Azure SQL Transparent Data Encryption (TDE) avec des clés gérées par Microsoft.
Au repos — documents Chiffrement AES-256 d'Azure Blob Storage; clés gérées par le client (CMK) offertes.
Au repos — secrets Azure Key Vault, accessible via une identité managée.

Sécurité réseau

Mesure de protection Mise en œuvre
HTTPS uniquement Tout le trafic HTTP est rejeté; HTTP/2 activé.
CORS Restreint au domaine SharePoint de l'institution.
Limitation du débit 600 demandes par minute par utilisateur authentifié.
En-têtes de sécurité X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy.
Plan de gestion Authentification de base SCM/FTP désactivée; gestion via le portail Azure avec Entra ID et AMF uniquement.

Surveillance et audit

Mesure de protection Mise en œuvre
Piste d'audit de l'application Toutes les actions de création, de mise à jour et de suppression sont consignées avec l'ID de l'utilisateur, l'horodatage, le champ modifié et les anciennes et nouvelles valeurs.
Registre d'audit inviolable Un registre chaîné par hachage (SHA-256) et à ajout seul enregistre les actions de tous les modules; son intégrité est vérifiable côté serveur, et un dossier de preuves prêt pour un tribunal peut être exporté pour une demande.
Journal d'accès aux documents Les événements d'aperçu et de téléchargement sont consignés avec l'ID de l'utilisateur, l'horodatage, l'adresse IP et le user agent. En insertion seule.
Journal de purge de rétention Toutes les opérations de purge sont consignées avec attribution à l'utilisateur.
Surveillance de l'application Azure Application Insights capture les requêtes HTTP, les exceptions et les appels de dépendances (rétention de 90 jours).
Règles d'alerte Alertes métriques configurables pour les erreurs HTTP 5xx et la latence élevée.
Log Analytics Stockage centralisé des journaux avec capacité de requêtes KQL pour les enquêtes de sécurité.

Mesures de protection administratives

Les Administrator attribuent les rôles via les Paramètres; les changements de rôle prennent effet immédiatement. Une politique d'accès aux applications restreint Mail.Send à la seule boîte aux lettres partagée désignée. Les changements de configuration sont appliqués via des packs de configuration versionnés, avec journalisation d'audit des installations. La formation du personnel, la politique d'utilisation acceptable et les procédures d'intervention en cas d'atteinte sont déterminées par l'institution.

Services tiers et partage de données

Service Rôle RPI reçus Emplacement des données
Microsoft Azure Sous-traitant (IaaS : App Service, SQL, Blob, Key Vault, Application Insights) Toutes les données de l'application Région Azure de l'institution
Microsoft 365 Sous-traitant (Graph Mail.Send, flux d'activité Teams) et, en option, source des dossiers capturés par le détenteur de dossiers Contenu des notifications par courriel/Teams; pour la capture facultative, le contenu M365 propre à ce détenteur de dossiers Locataire M365 de l'institution
Realizer Services (éditeur) Éditeur du logiciel — aucun rôle de sous-traitant à l'égard des RPI des clients Aucun — uniquement l'ID du locataire, les métadonnées de notification et les rapports d'installation des packs de configuration Azure de l'éditeur (Canada)
Syncfusion Bibliothèque intégrée (pas un service) Aucun — la conversion s'effectue dans l'App Service de l'institution App Service de l'institution

Point clé : aucun RPI du demandeur, contenu de document ou détail de demande n'est transmis à Realizer Services ou à toute autre partie externe. Tout le traitement des documents (conversion, caviardage) s'effectue dans l'App Service propre de l'institution.

Fichiers de renseignements personnels applicables

FRP Numéro d'enregistrement Description
Demandes en vertu de la Loi sur l'accès à l'information et de la Loi sur la protection des renseignements personnels PSU 901 Dossiers liés aux demandes ATIP
Dossiers du personnel des employés PSE 901 Noms et rôles des employés dans la piste d'audit

Les institutions doivent confirmer les FRP applicables et déterminer si de nouveaux FRP sont requis pour leur déploiement particulier.

Disponibilité du PIA complet

L'évaluation complète des facteurs relatifs à la vie privée — y compris l'inventaire complet des renseignements personnels, l'analyse détaillée de la collecte, de l'utilisation, de la communication, de la rétention et de l'exactitude, les autorités légales et les diagrammes de flux de données — est offerte aux clients et clients potentiels sur demande. Les institutions déployantes s'en servent comme fondement technique et architectural pour leur propre PIA, en complétant l'aperçu institutionnel, les calendriers de conservation, les ententes de partage de renseignements et l'approbation, avant de le soumettre au SCT et au Commissariat à la protection de la vie privée.