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.