1 septembre 2025
Introduction
Un flux de signature intègre la cybersécurité et la vie privée dès la conception lorsque chaque donnée, finalité, menace, contrôle, test et règle de changement possède un propriétaire.
La protection de la vie privée ne s’ajoute pas à un flux de signature après son déploiement. Elle influence dès le départ les données recueillies, les personnes autorisées, les copies créées et la durée pendant laquelle chaque élément reste accessible.
La cybersécurité répond à des questions complémentaires : comment limiter l’accès, protéger les échanges, détecter une anomalie et rétablir le service? Réunir les deux disciplines ne signifie pas les confondre. La finalité des données et les contrôles techniques gardent leurs propriétaires et leurs preuves.
Une conception approuvée relie chaque donnée à son usage, à son chemin dans l’architecture et aux contrôles qui s’appliquent. Elle couvre aussi les scénarios d’échec, les exports et les systèmes connectés, pas seulement la signature réussie.
Nota Sign prend en charge les parcours de signature électronique sécurisée fédérale et les flux québécois qui maintiennent le lien avec un document technologique intègre. L’organisation peut intégrer ce parcours à son architecture, tester les accès et les scénarios d’échec, puis conserver les preuves de contrôle. Pour passer du schéma au pilote, intégrez Nota Sign à votre conception sécurisée.
Définir le flux, les données et les menaces
La revue commence par un schéma du parcours réel : système qui crée le document, personnes qui le préparent, Nota Sign, destinataires, système de classement et outils d’export ou d’analyse. Chaque transfert indique les données, le protocole ou mécanisme approuvé et le propriétaire.
L’équipe décrit ensuite les événements qu’elle veut prévenir ou détecter : envoi au mauvais destinataire, accès trop large, lien réutilisé, document remplacé, export non contrôlé ou compte administrateur compromis. Le contrôle se rattache à un scénario précis plutôt qu’à un libellé générique « sécurité ».
Le document, les coordonnées, les rôles, les données de vérification et la piste technique sont inventoriés séparément. Cette séparation révèle les données sensibles qui n’ont pas besoin de traverser tout le flux.
Relier chaque donnée à une finalité
Une donnée entre dans le parcours seulement lorsqu’une finalité explique son utilisation. L’adresse de courriel sert à l’acheminement; une référence de dossier sert au classement; un événement technique sert à la reconstitution ou à la détection selon le contrôle défini.
La finalité précise aussi les personnes qui utilisent la donnée et le moment où elle cesse d’être nécessaire. Un champ recueilli « au cas où » ne fournit ni limite d’accès ni règle de suppression.
Lorsque la finalité change, la conception repasse en revue. Une donnée recueillie pour livrer une demande ne devient pas automatiquement une donnée d’analyse ou d’entraînement. La nouvelle utilisation exige sa propre autorisation et ses propres contrôles.
Attribuer un propriétaire à chaque contrôle
Les contrôles techniques couvrent notamment l’accès, la protection des communications, la gestion des comptes, la journalisation, la conservation et la reprise. L’organisation choisit les mécanismes selon son architecture et vérifie leur fonctionnement dans le flux réel.
Chaque contrôle possède un propriétaire, une configuration attendue, une méthode de test et une preuve datée. Une option activée dans une interface n’est pas un résultat de test. L’équipe confirme le comportement observé, y compris dans les systèmes en amont et en aval.
Les responsabilités du fournisseur et celles de l’organisation sont documentées séparément. L’intégration, la gestion des utilisateurs, le classement et les exports restent sous le contrôle des équipes qui les configurent, même lorsque le service de signature exécute une partie du parcours.
Réduire l’exposition du document et de la preuve
Le contenu sensible n’apparaît pas dans le nom du fichier, l’objet du courriel ou une notification visible sans authentification. Le destinataire reçoit le contexte nécessaire pour reconnaître l’action, sans divulgation superflue.
Les droits distinguent le document, la piste et les données de vérification. Une personne du soutien peut voir l’état d’un flux sans lire le contrat. Une administratrice peut gérer un compte sans recevoir une copie de chaque fichier signé.
Les téléchargements et exports suivent la même gouvernance. Leur emplacement, leur propriétaire et leur date de suppression sont définis avant le déploiement. Sans cette étape, l’architecture protège le système principal tout en laissant les copies hors contrôle.
Tester le parcours et les scénarios d’échec
Le test commence avec une version représentative et des données protégées. Il vérifie l’accès du destinataire, l’ordre des actions, la version finale, la piste produite et le classement dans le bon dossier.
Les scénarios d’échec couvrent au minimum l’erreur de destinataire, le changement de signataire, l’expiration, l’annulation, la modification du document et l’export par une personne non autorisée. L’équipe observe les journaux et les alertes réellement disponibles au lieu de présumer leur contenu.
Un résultat de test indique la date, la configuration, la personne responsable et la conclusion. Une correction reçoit un nouveau test; elle n’efface pas le résultat antérieur.
Préparer la conservation, l’incident et le changement
La conception indique la durée du document, de la piste, des journaux et des données d’identité selon les règles applicables. Ces éléments ne partagent pas automatiquement la même durée.
Le plan d’incident précise qui limite l’accès, préserve les références nécessaires à l’enquête, évalue l’exposition et autorise la reprise. Il évite de créer des copies supplémentaires du document sous prétexte de préserver la preuve.
Un changement de fournisseur, d’intégration, de finalité, de rôle ou de règle de conservation rouvre la revue. La version approuvée de l’architecture reste datée, avec les preuves des contrôles qui existaient à ce moment.
Situer les règles de signature dans leur juste périmètre
La partie 2 de la Loi sur la protection des renseignements personnels et les documents électroniques définit, pour son périmètre, la signature électronique et la signature électronique sécurisée. Le Règlement sur les signatures électroniques sécurisées, DORS/2005-30, prescrit le procédé de signature numérique qui correspond à cette seconde définition.
Au Québec, la Loi concernant le cadre juridique des technologies de l’information établit notamment des règles de valeur juridique et d’intégrité pour les documents technologiques. Son article 39 vise la signature apposée à un document technologique dont l’intégrité est assurée.
Ces dispositions éclairent la méthode de signature et l’intégrité du document dans leur champ d’application. Elles ne constituent pas une architecture complète de cybersécurité ou de protection de la vie privée. L’organisation analyse séparément les règles de renseignements personnels, les exigences sectorielles, le document, les participants et les juridictions concernées.
La revue finale rassemble le schéma du flux, l’inventaire des données, les finalités, la matrice d’accès, les contrôles, les résultats de test, la conservation et le plan de changement. Chaque élément possède un propriétaire.
L’approbation interne constate la conception examinée; elle ne garantit pas l’absence d’incident ni une conformité universelle. Une prochaine revue est déclenchée par un changement défini ou par la date prévue dans la gouvernance de l’organisation.
