Pseudonymisation des données clients : ce que dit la nLPD

Une fiduciaire de Saxon veut confier à un assistant d’IA le tri des pièces de ses mandants. Une régie de Grandson aimerait qu’un prestataire analyse ses baux. Quelqu’un propose de « pseudonymiser » d’abord, et la direction en conclut que la LPD ne s’applique plus.

Je tiens ce raccourci pour faux. La loi suisse ne contient même pas le mot ; tout part de la personne identifiable. Le cadre général est dans notre guide de la nLPD appliquée à l’IA ; ici, on parle codes, tables et juges.

Différence entre pseudonymisation et anonymisation : une fiche, trois états

Pseudonymiser, c’est remplacer ce qui désigne quelqu’un par un code et ranger à part le moyen de revenir en arrière : une table, ou une clé secrète. Anonymiser, c’est faire en sorte que plus personne, vous compris, ne puisse raisonnablement retrouver la personne.

Tout se résume à une question : reste-t-il, quelque part, un chemin vers le nom ? Si oui, vous pseudonymisez, même quand ce chemin dort dans un coffre. Ce qui identifie dans un texte est recensé dans notre liste des données à retirer avant l’IA.

Dans un contrat de prestataire, le mot « anonymisé » ne me rassure que si quelqu’un sait dire où est passée la table.

Pseudonymisation dans la LPD : un mot absent du texte

Nous avons cherché le mot dans le texte de la LPD publié sur Fedlex (état au 7 juillet 2025) et dans celui de l’OPDo (état au 1er décembre 2025) : aucune occurrence. L’anonymisation, elle, apparaît dans quatre articles de la loi.

Tout repose sur l’art. 5 let. a : une donnée personnelle concerne une personne « identifiée ou identifiable ». Un code rend identifiable dès qu’on peut le relier à un nom. Les catégories protégées sont dans notre fiche sur les données sensibles.

Ce silence du législateur ne me dérange pas : il oblige à se demander qui reçoit le texte, au lieu de se reposer sur le nom d’une technique.

Personne identifiable : l’arrêt Logistep et l’approche relative

En 2010, dans l’affaire Logistep (ATF 136 II 508), le Tribunal fédéral a posé la règle encore citée aujourd’hui. Une possibilité théorique ne suffit pas : si l’effort est tel que, selon l’expérience générale, aucun intéressé ne l’entreprendra, la personne n’est pas identifiable.

Le consid. 3.4 ajoute ce qui intéresse une fiduciaire : la question s’apprécie du point de vue de chaque détenteur de l’information. Si le destinataire peut identifier, cela suffit, et la loi s’applique aussi à celui qui lui a transmis les données.

Une phrase codée peut donc être une donnée personnelle chez vous et pas chez un fournisseur d’IA. J’y vois une souplesse utile, pas un passe-droit. Ce que le fournisseur conserve est une autre affaire : ce que ChatGPT garde des échanges depuis la Suisse.

Arrêt 4A_365/2017 : une liste « pseudonymisée » qui identifiait encore

Le 26 février 2018, le Tribunal fédéral a rejeté le recours d’une banque qui voulait remettre au Département de la justice américain une liste de clients partis, sans leurs noms. Les clients avaient obtenu l’interdiction devant le Tribunal de commerce de Zurich.

Pseudonymiser, rappelle-t-il, c’est déjà traiter des données personnelles, et la banque doit prouver l’efficacité des mesures qu’elle a prises elle-même. Un numéro de contrôle interne remplace utilement un numéro de compte. Mais le nom du gestionnaire restait sur la liste.

J’y lis une consigne de relecture plus qu’une leçon de droit : le nom du client part rarement seul, celui de son conseiller l’accompagne souvent. Pour un établissement, la suite se joue côté banques et gestion de fortune.

Position du PFPDT : guide TOM, hachage et clé secrète

Le guide TOM du PFPDT, du 15 janvier 2024, tient les données pseudonymisées pour « toujours » personnelles, parce que le risque de réidentification demeure. C’est plus strict que l’approche relative du Tribunal fédéral. Un guide oriente la pratique ; il ne lie pas un juge.

Il ajoute deux mises en garde. Détruire la table ne rend pas les données anonymes. Un nom haché avec une fonction publique comme SHA256 se retrouve en essayant la liste des noms possibles : il faut y mêler une clé secrète.

Le guide ne parle pas du numéro AVS ; la suite est notre déduction. Son format étant public, on peut hacher tous les numéros possibles et comparer. Pour un fichier clients, je me range à la lecture du Préposé : si un juge s’en écarte, ce sera vers plus de souplesse.

Recherche et statistique : art. 31 al. 2 let. e et art. 39 LPD

La LPD fait de l’anonymisation la condition d’un motif justificatif : les traitements « à des fins ne se rapportant pas à des personnes », comme la statistique. Pour une entreprise, c’est l’art. 31 al. 2 let. e ; pour un organe fédéral, l’art. 39.

Le privé qui s’en prévaut anonymise dès que la finalité le permet ; si c’est impossible ou disproportionné, il prend des mesures pour empêcher l’identification. Les données sensibles ne passent en principe à des tiers que sous une forme non identifiante, et les résultats se publient de même.

Une régie qui fait analyser l’évolution de ses loyers entre dans ce cadre, comme un cabinet qui tire des statistiques de ses comptes rendus médicaux. Pour ce genre d’analyse, j’écarte l’envoi des baux un par un : un export agrégé suffit presque toujours.

Fiduciaire, régie, étude : envoyer des données clients à un prestataire

Tant que vous gardez la table, ce que vous envoyez reste pour vous une donnée personnelle. L’art. 9 LPD sur la sous-traitance vaut donc pour le prestataire, et l’art. 16 pour un envoi hors de Suisse, même si le texte ne porte que des codes.

L’art. 321 CP vise, à côté des avocats et des médecins, les « contrôleurs astreints au secret professionnel en vertu du code des obligations ». Une fiduciaire n’y entre que comme organe de révision, pas pour la tenue des comptes. Les autres métiers sont passés en revue face aux assistants d’IA.

Une régie n’a pas de secret pénal, mais ses locataires ne font pas la différence : je donnerais à leurs poursuites et à leurs garanties de loyer le même soin que si elle en avait un.

Clé gardée ou clé détruite : pseudonymiser ou anonymiser en pratique

Le choix suit l’usage. Si la réponse doit revenir à une personne, relance ou décompte, il faut pouvoir recoller le nom : vous pseudonymisez. Si vous cherchez une tendance, la table ne sert plus à rien et devient un risque.

L’ASB recommande aux banques un accès à la table limité au besoin d’en connaître, avec journalisation ; l’ORH veut un code gardé par une personne extérieure au projet. Pour un PDF ou un tableur entier, nos outils en ligne remplacent les données fichier par fichier.

Une table gardée « au cas où » pour une simple statistique, c’est la première chose que je supprime.

LLM local ou proxy devant l’API : qui détient la table de correspondance

Pour les flux automatiques, deux architectures gardent les noms au bureau. Un LLM local tourne sur vos machines : aucun fournisseur de modèle ne lit le texte, mais il faut des serveurs à GPU et quelqu’un pour choisir, tester et mettre à jour le modèle.

Un proxy placé devant l’API d’un grand fournisseur remplace les données avant l’envoi et les remet au retour ; la table ne quitte pas votre réseau. Le principe est expliqué dans notre guide sur l’AI gateway.

Nonimo Gateway tourne ainsi dans un conteneur sur vos serveurs, devant l’API d’OpenAI ou une API compatible. Une donnée garde son marqueur sur toute la conversation ; en cas de panne, la requête ne part pas. Pour une fiduciaire de dix personnes, je n’installerais pas de LLM local : le chantier dépasse le besoin.

Données clients et IA : la table reste au bureau, le texte part codé

Je ramène tout cela à une règle : le fournisseur d’IA reçoit le travail, pas le client. Les codes protègent le nom ; la relecture protège le contexte, comme le gestionnaire de l’arrêt de 2018 l’a rappelé à une banque.

Pour l’e-mail d’un mandant collé dans un assistant, Nonimo remplace sur l’ordinateur les données de vos clients par des étiquettes avant l’envoi et montre ce qu’il a remplacé. La correspondance reste sur le poste, chez vous ; la réponse revient au nom de Raphaël Fellay.

Le commerce de vins à Fully n’a pas de format qui le trahisse : à vous de le reformuler ou de le masquer, comme une commune ou un numéro de dossier. Le numéro IDE de la société du mandant, en revanche, part sous étiquette.

Nous lisons ici des lois et deux arrêts ; pour votre mandat, demandez un avis signé.

Sources

• Loi fédérale sur la protection des données (LPD, RS 235.1) : art. 5 let. a, 6 al. 4, 9, 16, 31 al. 2 let. e, 38 et 39 ; aucune occurrence de « pseudonymisation ».
• Ordonnance relative à la recherche sur l’être humain (ORH, RS 810.301) : art. 25 (anonymisation) et 26 (codage).
• Tribunal fédéral, ATF 136 II 508 (Logistep) : consid. 3.2 et 3.4, personne identifiable et point de vue de chaque détenteur.
• Tribunal fédéral, arrêt 4A_365/2017 du 26 février 2018 : liste bancaire pseudonymisée, charge de la preuve, nom du gestionnaire.
• PFPDT, guide relatif aux mesures techniques et organisationnelles (TOM), 15 janvier 2024 : ch. 5.2 pseudonymisation, ch. 5.3 anonymisation.
• PFPDT, accès de l’OFSP aux données visualisées de Swisscom, 3 avril 2020 : pseudonymisation, puis agrégation.
• Association suisse des banquiers, guide « cloud », 3e édition : ch. 40, accès à la table de concordance et journalisation.
• OFS, appariement externe de données : pseudonymisation avec une clé propre à chaque projet.
• PPDT Genève, fiche info « Introduction à l’anonymisation et à la pseudonymisation », 13 septembre 2021 : table de correspondance, clé secrète, hachage.

Consulté le 9 novembre 2026.