Certaines directions financières, ou meme application dans le médico social, envisagent d’utiliser le numéro d’inscription au répertoire national d’identification des personnes physiques (NIR) comme clé technique pour identifier et supprimer les doublons dans leurs logiciels. L’usage du NIR comme outil de détection des doublons ? L’idée paraît séduisante : un identifiant unique, fiable et universel. Mais le droit français encadre ce recours de façon très stricte.
Un identifiant très particulier
Le NIR n’est pas un simple numéro. Il porte en lui des informations signifiantes (date et lieu de naissance, sexe) et son emploi a toujours été considéré comme sensible. C’est pourquoi le législateur a limité ses usages à des cas précis, définis par décret, afin d’éviter sa généralisation et tout risque d’interconnexion de fichiers.
Ce que prévoit le décret de 2019
Le décret n° 2019-341 du 19 avril 2019 fixe la liste des acteurs et des finalités autorisés à traiter le NIR. Parmi eux, la direction générale des finances publiques (DGFiP) et la direction générale des douanes peuvent s’en servir pour vérifier l’exactitude des données liées à l’assiette, au contrôle et au recouvrement des impôts, taxes et amendes. En revanche, un usage interne consistant à exploiter ce numéro pour gérer des doublons sort de ce périmètre : ce serait un détournement de finalité.
Les principes du RGPD toujours en toile de fond
Même lorsqu’un traitement est permis par la loi, il doit encore respecter les fondements du RGPD :
- Nécessité et proportionnalité : ne collecter que les données indispensables.
- Minimisation : privilégier des solutions moins intrusives quand elles existent.
- Finalité déterminée : n’utiliser une donnée que pour les usages prévus initialement.
Dans le cas présent, utiliser le NIR comme clé anti-doublon n’apparaît ni indispensable, ni conforme au principe de proportionnalité.
Quelles alternatives privilégier ?
Pour limiter les doublons ou résoudre des problèmes d’homonymie, des combinaisons de données moins sensibles suffisent généralement :
- nom et prénoms,
- date et lieu de naissance,
- éventuellement un identifiant interne généré par le logiciel.
- a la fin de l’article une proposition de methode.
Ces méthodes respectent davantage la minimisation des données et réduisent le risque juridique.
Le NIR ne peut être employé que dans des situations expressément prévues par la loi. En dehors du champ strict de la DGFiP et des Douanes, son utilisation pour éliminer des doublons serait considérée comme illégale et disproportionnée. Les responsables de traitement doivent donc mettre en œuvre d’autres solutions d’identification, compatibles avec le RGPD et conformes aux principes de protection des données. Voici une méthode anti doublon compatible avec le RGPD :
L’usage du NIR comme outil de détection des doublons : Voici plusieurs propositions robustes, pratiques et conformes pour générer une clé antidoublon sûre, déterministe pour le rapprochement et respectueuse des principes de protection des données. je fournis une solution recommandée (production), des alternatives, et les points de conformité à documenter.
Principe recommandé (production)
générer un hash HMAC-SHA-256 déterministe sur un ensemble de champs normalisés (champ1|champ2|…) avec une clé secrète (pepper) stockée dans un coffre (kms). tronquer le résultat à 128 bits (16 octets) et l’encoder en base32/base64url pour obtenir une clé courte, fixe et quasi-unique.
avantages :
- déterministe (même personne → même clé), difficilement réversible sans la clé, collisions astronomiquement improbables si on garde 128 bits.
- champs d’entrée (normalisation obligatoire) nom (normalisé : enlever accents, ligatures, apostrophes, traits d’union, majuscules → minuscules, trim).
- prénom (même normalisation).
- date de naissance (format ISO YYYYMMDD).
- lieu de naissance ou code INSEE si disponible (optionnel).
- éventuellement suffixe métier (ex : numéro interne court) si vous voulez distinguer contextes.
construction de la chaîne : nom|prénom|YYYYMMDD|lieu (séparateur fixe |).
alternatives et compléments pratiques
UUIDv4 comme clé primaire interne + matching_key HMAC pour rapprochement ; UUIDv4 évite toute dépendance aux champs personnels pour l’index primaire.
clé composite : hachage + petit compteur d’anti-collision (si collision détectée, append
:1) — utile pour garantir unicité immédiate.approche probabiliste : Bloom filter pour détection rapide de doublons à grande échelle (rapide, mais false positives possibles).
matching flou : utiliser le hachage déterministe comme signal initial, puis fuzzy matching (Jaro-Winkler, Levenshtein) et revue humaine pour les cas ambigus.
estimation du risque de collision
128 bits → espace ≈ 3,4×10^38. seuil 50 % par anniversaire ≈ 1,177×2^64 ≈ 2,17×10^19 enregistrements. pour toute base pratique (≤ quelques milliards), risque négligeable.
si vous tronquez à 64 bits, le risque augmente fortement (n50 ≈ 1,7×10^10). éviter < 128 bits sauf contrainte forte.
considérations RGPD / sécurité opérationnelle
pseudonymisation : le HMAC avec clé secrète rend la clé non réversible sans la clé ; il s’agit de pseudonymisation, pas d’anonymisation. cela reste une donnée personnelle si les champs d’origine existent.
clé secrète (pepper) : stocker dans KMS ou vault, accès restreint, rotation planifiée et journalisée. ne pas stocker la clé dans le code ni dans la base.
minimisation : ne pas stocker plus de champs sensibles que nécessaire ; conservez uniquement ce qui sert au traitement.
registre : documenter l’algorithme, la liste des champs, la clé KMS, la période de rétention, les accès et justifier la base légale.
analyse d’impact (AIPD) : si le traitement est à risque élevé (volume, sensibilité), prévoir une AIPD.
mesures techniques : chiffrement au repos, séparation des environnements, contrôle d’accès RBAC, syslog des accès aux clés.
Solution proposée par notre application DPO-FRANCE
