La question à laquelle personne ne s’attend
Une enquête interne pour fuite de données. La sécurisation est proprement documentée, les valeurs de hachage concordent, la revue est terminée. Puis, dans la procédure, survient une question à laquelle personne n’est préparé : Qui avait accès à la plateforme de revue pendant l’enquête ?
Il s’avère qu’un supérieur hiérarchique de la personne concernée pouvait tout lire en tant qu’« interlocuteur de la mandante » – le même supérieur dont le propre rôle dans l’affaire sera ensuite mis en cause. Deux réviseurs externes disposaient encore d’un compte actif après la fin du projet. Et un compte administrateur était partagé par trois personnes.
Rien n’a changé dans les données. Mais la crédibilité de l’enquête est entamée. Une chaîne de conservation qui prouve le parcours des données, mais pas qui pouvait les voir, n’est fermée qu’à moitié.
La seconde moitié de la chaîne de conservation
La chaîne de conservation répond à la question de savoir d’où provient une preuve et qu’elle est inchangée. Dès que les données se trouvent sur une plateforme de revue, une seconde question s’ajoute : qui pouvait les consulter, les commenter, les taguer, les exporter ou les supprimer – et cette personne y était-elle autorisée ?
Pour le traitement des preuves numériques, la norme ISO/IEC 27037 exige que chaque action puisse être retracée par un tiers qualifié [1]. Cela ne vaut pas seulement pour la sécurisation. Cela vaut tout autant pour la phase durant laquelle des dizaines de personnes travaillent avec les données.
L’accès compte pour quatre raisons :
- Intégrité : quiconque pouvait écrire, taguer ou supprimer aurait pu influencer le résultat.
- Confidentialité : les données d’enquête contiennent souvent de la correspondance d’avocats, des données de clients bancaires ou des secrets d’affaires. Le secret professionnel et le secret bancaire [2][3] montrent à quel point le cercle des personnes autorisées doit être restreint.
- Protection des données : les données concernent des collaborateurs, des clients et des tiers – souvent aussi des données personnelles sensibles.
- Indépendance : les personnes susceptibles d’être elles-mêmes visées par l’enquête ne doivent pas pouvoir lire. Dans les études d’avocats s’ajoutent les murailles de Chine entre mandats.
Le cadre juridique et normatif
Suisse : la traçabilité
En Suisse, la loi sur la protection des données et l’ordonnance sur la protection des données sont particulièrement pertinentes. Elles traitent d’une sécurité des données adaptée au risque et de la traçabilité des traitements, journalisation comprise [4][5].
Le Préposé fédéral à la protection des données et à la transparence (PFPDT) a publié des recommandations techniques sur la journalisation [6]. Elles sont éclairantes en pratique : même la simple lecture devrait être traçable, les journaux devraient être conservés séparément et protégés contre toute manipulation, et un concept de journalisation comprend des objectifs, des rôles et un contrôle régulier. Un point souvent négligé dans le quotidien des enquêtes mérite d’être relevé : les journaux servent la traçabilité, et non la surveillance du comportement des personnes qui travaillent avec les données [6].
Les obligations applicables à votre cas concret relèvent de l’appréciation de votre étude d’avocats.
International : l’accès comme objectif de contrôle
La norme ISO/IEC 27001:2022 fait de l’accès un thème de contrôle à part entière : règles de contrôle d’accès (A.5.15), attribution, revue et retrait des droits d’accès (A.5.18) ainsi que journalisation des activités (A.8.15) [7]. Aligner son environnement de revue sur ces contrôles, c’est parler la langue que comprennent réviseurs, autorités de surveillance et parties adverses internationales.
Pour les enquêtes ayant un lien avec l’UE – par exemple impliquant des collaborateurs ou des sociétés du groupe en Allemagne –, le RGPD et ses exigences en matière de sécurité du traitement peuvent également être pertinents [8].
Un journal que personne ne lit ne protège rien. Seul un contrôle régulier transforme des données d’accès en preuve.
Là où le bât blesse en pratique
| Point faible | Risque | Contre-mesure |
|---|---|---|
| Comptes encore actifs après la fin du projet ou du mandat | Accès non autorisé à des données confidentielles | Date d’expiration par compte, contrôle à chaque clôture de projet |
| Comptes partagés (« Admin », « Équipe de revue ») | Les actions ne sont attribuables à personne | Comptes personnels, authentification à deux facteurs |
| Rôles attribués trop largement | Les réviseurs peuvent exporter ou supprimer | Rôles selon le besoin d’en connaître, droits d’export et de suppression séparés |
| Représentants de la mandante avec accès complet | Indépendance de l’enquête contestable | Accès aux résultats plutôt qu’aux données brutes, vérification des conflits d’intérêts |
| Autorisations vérifiées seulement à l’ouverture | Élargissement progressif du cercle | Revue périodique des accès avec validation |
| Plusieurs espaces de travail, équipes différentes | Perte de vue d’ensemble, murailles de Chine lacunaires | Vue transversale par personne et par rôle |
| Journaux uniquement dans le système lui-même | La preuve tombe avec le système | Exporter les journaux et les conserver séparément |
Du journal à la preuve
Toute plateforme de revue sérieuse gère des utilisateurs, des rôles et des activités. Le problème est rarement que les données manquent. Le problème est qu’elles sont dispersées : par espace de travail, par liste d’utilisateurs, par modèle de rôles. Or un tribunal, une autorité de surveillance ou un conseil d’administration veut une réponse simple : qui avait quel accès à quelles données, et quand – et qui l’a approuvé ?
Une preuve d’accès exploitable présente donc trois qualités :
- Complète : elle couvre tous les espaces de travail, tous les utilisateurs et tous les rôles – pas seulement le projet en cours.
- Datée : elle montre l’état à un moment donné et peut être répétée, de sorte que les changements deviennent visibles.
- Lisible : une juriste sans connaissances techniques la comprend sans explication.
Chez Prism Discovery, nous extrayons automatiquement, via l’interface de programmation, les espaces de travail, utilisateurs et autorisations de notre plateforme de revue Farsight et les condensons dans un rapport d’audit. Celui-ci montre, par espace de travail, qui y a accès et avec quel rôle et, par personne, à quels espaces elle peut accéder. Complété par des données d’utilisation et de stockage, il alimente un tableau de bord qui rend l’état visible en continu. Le rapport est établi à la clôture du projet et périodiquement, puis archivé avec le projet – comme partie de la documentation, et non comme reconstitution après coup.
Conclusion : cinq questions à poser à tout environnement de revue
- Chaque personne dispose-t-elle de son propre compte, et chaque action est-elle attribuable à une personne ?
- Les rôles respectent-ils le principe du besoin d’en connaître – en particulier pour les droits d’export et de suppression ?
- Est-il garanti que personne n’a accès qui pourrait être lui-même visé par l’enquête ?
- Les autorisations sont-elles revues périodiquement et retirées à la fin du projet ?
- L’état des accès peut-il être prouvé à tout moment – séparément du système qui contient les données ?
Là où l’une de ces questions reste ouverte, ce n’est pas le contenu qui est contestable, mais l’environnement dans lequel il a été examiné. La chaîne de conservation ne s’arrête pas au téléversement. Elle s’étend jusqu’au dernier compte qui a encore accès.
Cet article est fourni à titre d’information générale et ne constitue pas un conseil juridique. Pour l’appréciation juridique de votre cas, veuillez vous adresser à une étude d’avocats.
Sources
[1] ISO/IEC 27037:2012 – Guidelines for identification, collection, acquisition and preservation of digital evidence – https://www.iso.org/standard/44381.html
[2] Code pénal suisse (CP), RS 311.0 – https://www.fedlex.admin.ch/eli/cc/54/757_781_799/fr
[3] Loi fédérale sur les banques et les caisses d’épargne (Loi sur les banques, LB), RS 952.0 – https://www.fedlex.admin.ch/eli/cc/51/117_121_129/fr
[4] Loi fédérale sur la protection des données (LPD), RS 235.1 – https://www.fedlex.admin.ch/eli/cc/2022/491/fr
[5] Ordonnance sur la protection des données (OPDo), RS 235.11 – https://www.fedlex.admin.ch/eli/cc/2022/568/fr
[6] Préposé fédéral à la protection des données et à la transparence (PFPDT/EDÖB) : Technische Empfehlungen für die Protokollierung gemäss Art. 4 DSV, version 1.0, 15 septembre 2023 – https://www.edoeb.admin.ch
[7] ISO/IEC 27001:2022 – Information security, cybersecurity and privacy protection – Information security management systems – Requirements, annexe A – https://www.iso.org/standard/27001
[8] Règlement (UE) 2016/679 (règlement général sur la protection des données, RGPD) – https://eur-lex.europa.eu/eli/reg/2016/679/oj