Pseudonymisation, anonymisation, chiffrement : ce qu’un notaire doit savoir

Trois mots circulent dans les démonstrations de logiciels dotés d’intelligence artificielle, et ils ne disent pas la même chose. Pseudonymiser, c’est remplacer les éléments identifiants par des jetons tout en conservant, ailleurs, de quoi revenir en arrière : la donnée reste une donnée à caractère personnel au sens du RGPD. Anonymiser, c’est rendre la réidentification raisonnablement impossible pour quiconque : la donnée sort alors du champ du règlement, et le seuil est bien plus haut qu’on ne le croit. Chiffrer, ce n’est ni l’un ni l’autre : c’est une mesure de sécurité, pas un changement de nature juridique. La conséquence pratique tient en une phrase : un prestataire qui reçoit des données pseudonymisées reste un sous-traitant ultérieur, soumis à un accord conclu sur le fondement de l’article 28 du RGPD.

Cette distinction n’est pas une subtilité d’universitaire. Elle commande la qualification du fournisseur, le contenu du contrat, l’analyse d’impact, la mention au registre des traitements et, le jour venu, la réponse au client qui demande où sont passées ses données.

Pseudonymisation, anonymisation, chiffrement : la différence en une lecture

	Ce que la mesure fait	Réidentification	Statut RGPD
Pseudonymisation	remplace les identifiants par des jetons ; la correspondance existe et est conservée séparément	possible pour celui qui détient la clé de correspondance	donnée à caractère personnel — le RGPD s’applique intégralement
Anonymisation	détruit le lien avec la personne, de manière irréversible pour tout le monde	raisonnablement impossible, y compris par recoupement	hors champ du RGPD, si le résultat est réellement atteint
Chiffrement	rend le contenu illisible sans la clé, sans en modifier la substance	immédiate pour qui détient la clé	donnée à caractère personnel — mesure de sécurité de l’article 32

La colonne qui compte est la dernière. Deux des trois mesures laissent le traitement entièrement soumis au règlement. Une seule l’en fait sortir, et elle est la plus difficile à atteindre.

Pourquoi une donnée pseudonymisée reste une donnée à caractère personnel

L’article 4(5) du RGPD définit la pseudonymisation comme le traitement qui fait qu’on ne peut plus attribuer les données à une personne précise « sans avoir recours à des informations supplémentaires » — ces informations étant conservées séparément et protégées. Le texte dit donc lui-même que la clé existe quelque part. C’est exactement ce qui empêche la donnée de devenir anonyme.

Le considérant 26 ferme la porte de manière explicite : les données pseudonymisées, susceptibles d’être attribuées à une personne par le recours à des informations supplémentaires, doivent être considérées comme des informations concernant une personne physique identifiable. Le même considérant précise le critère de l’anonymat : il faut tenir compte de « l’ensemble des moyens raisonnablement susceptibles d’être utilisés » pour réidentifier, par le responsable du traitement ou par un tiers.

Pour une étude, cela veut dire trois choses concrètes :

• Le traitement pseudonymisé figure au registre des traitements comme n’importe quel autre. Il n’y a rien à retrancher.
• L’information des personnes concernées, les droits d’accès, de rectification et d’effacement, les durées de conservation : tout continue de s’appliquer.
• La pseudonymisation reste néanmoins une mesure de sécurité expressément valorisée par les articles 25 et 32, et elle pèse dans l’appréciation du risque. Elle ne dispense pas ; elle protège.

Pourquoi l’anonymisation est rarement atteinte sur un dossier notarial

Un acte notarial est, par construction, un document singulier. Une vente d’immeuble comporte une adresse, une date, une superficie, un prix. Retirer les noms d’un tel document ne l’anonymise pas : la parcelle, la date et le montant suffisent souvent à désigner une seule transaction, et donc une seule famille. La doctrine appelle cela le risque de singularisation — la donnée reste unique dans l’ensemble, même dépouillée de son étiquette nominative.

Ajoutez-y la corrélation (rapprocher deux jeux de données pour retrouver la personne) et l’inférence (déduire une information manquante d’un ensemble d’autres) et vous obtenez les trois risques qu’un procédé doit neutraliser simultanément pour prétendre à l’anonymat. Sur des dossiers de succession, de donation ou de crédit hypothécaire, cette neutralisation détruit en pratique l’utilité du document.

Retenez donc la règle de prudence : si un fournisseur qualifie d’anonymes les données qu’il reçoit, demandez-lui d’en faire la démonstration. Une donnée véritablement anonyme est une donnée que personne ne peut plus rattacher à un client de l’étude — pas même l’étude elle-même.

Le chiffrement protège la donnée, il ne la fait pas changer de nature

Le chiffrement est une excellente mesure, et il est attendu, en transit comme au repos, avec une gestion des clés qui ne laisse pas le prestataire lire ce qu’il stocke. Mais un fichier chiffré reste une donnée à caractère personnel : il redevient lisible dès qu’on applique la clé, et le détenteur de la clé est en position de le faire.

Deux conséquences pratiques :

1. Chiffrer ne dispense jamais de conclure un accord de sous-traitance avec celui qui héberge ou traite les données.
2. En cas d’incident de sécurité, le chiffrement bien mis en œuvre peut réduire le risque pour les personnes concernées et, partant, l’obligation de les informer — mais la notification à l’autorité de contrôle, elle, s’apprécie dans les délais légaux et ne disparaît pas d’office.

Ce que cela change pour le fournisseur d’inférence

Voici le point qui décide de tout le reste. Lorsqu’un logiciel envoie un texte pseudonymisé à un modèle de langage hébergé chez un tiers, ce tiers traite des données à caractère personnel pour le compte du responsable du traitement. Il est donc un sous-traitant ultérieur, au sens de l’article 28.4 du RGPD. Il ne peut être engagé qu’avec l’autorisation du responsable, il doit être lié par des obligations contractuelles au moins équivalentes à celles du sous-traitant principal, et son intervention doit être documentée.

Ce qu’un notaire est fondé à exiger de l’éditeur de son logiciel :

• La chaîne complète des sous-traitants ultérieurs, communiquée par écrit, avec notification préalable de tout changement et droit d’objection.
• La localisation des traitements et, si un transfert hors Espace économique européen existe, la base juridique invoquée au titre des articles 44 et suivants.
• L’absence de rétention des données transmises au modèle, et l’interdiction contractuelle de les réutiliser pour un entraînement.
• La journalisation de chaque appel : qui, quand, sur quel dossier, avec quel résultat — et les refus, qui sont la partie la plus instructive du journal.
• Le sort des données sensibles au sens des articles 9 et 10 : santé, infractions, décisions judiciaires. Sur ces catégories, le refus de traiter vaut mieux que le masquage.

Un éditeur qui répond à ces cinq questions par écrit vous permet de tenir votre propre registre. Un éditeur qui répond « les données sont anonymisées, donc le RGPD ne s’applique pas » vous expose : c’est vous, et non lui, qui restez responsable du traitement à l’égard de vos clients.

Comment le vérifier avant de signer

Trois vérifications tiennent en une réunion, et elles ne demandent aucune compétence technique :

1. Demandez à voir ce qui sort réellement. Faites afficher, à l’écran, le texte tel qu’il est transmis au modèle. Un fournisseur qui pseudonymise sérieusement peut montrer la substitution en direct.
2. Demandez où vit la table de correspondance, qui y a accès, et quand elle est détruite. C’est elle qui fait la différence entre un jeton et un nom.
3. Demandez l’accord de traitement des données avant la démonstration, pas après. Un contrat qu’on ne peut pas lire à froid n’est pas un contrat qu’on signe à chaud.

Le choix d’architecture retenu par Nota

Nota applique cette lecture sans détour : aucune donnée nominative ne part vers un modèle, parce que Veil™ substitue les identifiants en amont de chaque appel, et qu’aucun appel ne peut emprunter un autre chemin. La qualification juridique qui en découle est assumée, et écrite telle quelle dans notre documentation contractuelle :

Nous aurions pu écrire « données anonymisées » : la formule rassure et se vend mieux. Elle serait fausse, et c’est le notaire qui en porterait la responsabilité devant ses clients. Le détail de cette architecture est exposé sur la page souveraineté ; les engagements contractuels et la chaîne de sous-traitance figurent sur la page confiance ; le fonctionnement du produit et les conditions tarifaires sont publiés, comme la mise en route. Les questions les plus fréquentes sur ces sujets sont rassemblées dans la foire aux questions.

---

Que vous choisissiez Nota ou un autre outil, gardez la grille : pseudonymisé n’est pas anonyme, chiffré n’est pas anonyme, et un fournisseur qui reçoit des données pseudonymisées est un sous-traitant ultérieur qu’il faut encadrer par écrit. Le reste en découle.

Pour voir la substitution s’opérer sur un cas réel, à l’écran : demander une démonstration.