Les futurs identifiants uniques “Nano-ID” dans la BDNB

Depuis 2021, la Base de Données Nationale des Bâtiments (BDNB ) est diffusée en données ouvertes sur data.gouv.fr . Courant 2023, un service d'API est arrivé avec différents périmètres de données et d’accès. Enfin, les applications GoRenove (GoRenove Particulier , GoRenove Bailleur ) utilisent la BDNB depuis leurs mises en ligne.

Le contexte

Pour parvenir à référencer l’ensemble des bâtiments en France, la BDNB manipule de nombreux objets métiers. Par exemple : des bâtiments (constructions physiques ou regroupement de locaux fiscaux), des groupes de bâtiments, des parcelles cadastrales, des unités foncières (regroupement de parcelles adjacentes appartenant à une même personne morale ou physique), des adresses postales…

Une partie de ces objets provient de jeux de données sources, non altérés par la BDNB. Ces jeux de données sources publient les données avec, pour chacun d’eux, des identifiants uniques - plus ou moins stable dans le temps - ou des clés d’interopérabilité. Dans ces situations, les identifiants uniques sources sont conservés, en l’état, dans la BDNB (par exemple l’identifiant cleab pour la BDTopo de l’IGN, ou la clé d’interopérabilité, renommée cle_interop_ban, de la Base d'Adresse Nationale ).

Pour les données sources altérées ou les objets nouveaux créés pour les besoins de la BDNB (par exemple les objets des tables [batiment_construction], [batiment_groupe] et [parcelle_unifiee]), des identifiants uniques sont générés.

Les limites sur les identifiants BDNB générés jusqu’à fin 2023

Riche de retours d’expérience depuis 2021, l’équipe BDNB a compilé auprès de ses utilisateurs et partenaires, un ensemble d’arguments visant à améliorer la gestion des identifiants uniques des tables [parcelle_unifiee], [batiment_construction] et [batiment_groupe].

Contexte sur la confidentialité des identifiants non-publics

Une problématique est apparue avec la publication des versions v06 etv07 de la BDNB en OpenData. En effet, bien que la table [parcelle_unifiee] ne soit pas publiée en libre accès (car elle contient des regroupements de parcelles cadastrales appartenant à des mêmes personnes morales ou physiques), l’identifiant batiment_groupe_id de la table [batiment_groupe] est composé du préfixe parcelle_unifiee_id. La diffusion de cette information, bien que non-critique et non-signifiante, ne peut pas perdurer dans le temps. Il convient alors de générer des identifiants uniques n’ayant aucun lien avec des identifiants considérés comme non-diffusable au grand public.

Il en va de même pour les identifiants de la table [batiment_construction] pour les géométries fictives. L’identifiant associé à ces géométries fictives est construit en concaténant l’identifiant de la parcelle unifiée qui la porte avec le suffixe “-geom_fictive”. Pour les même raisons que pour le paragraphe précédent, il est nécessaire de générer de nouveaux identifiants.

Gestion de la stabilité dans le temps des identifiants BDNB

Les identifiants uniques signifiants sont à proscrire. Ces derniers sont souvent composés d’une concaténation d’informations telle que le numéro de département ou le code commune INSEE. Mais qui peut assurer que d’ici 10, 20 ou 50 ans il n’y aura pas de redécoupages administratifs rendant caduques ou faux ces informations signifiantes à un instant donné ? Les discussions du CSTB avec le CNIG et la communauté des géocommuns , dans le cadre du projet RNB ont poussées vers un abandon de tout identifiant signifiant pour les bâtiments et les objets qui leurs sont associés : https://github.com/fab-geocommuns/BatID/issues/24 .

Les identifiants à base de GeoHash , telle que la fonction PostGIS ST_GeoHash() , sont également à écarter pour deux principales raisons.

1. En l’espace de 50 ans, il est possible qu’une construction évolue (changement d’usage, rénovation lourde avec extension(s), destruction/reconstruction) et que l’axiome visant à faire confiance à la stabilité de sa géométrie (emprise au sol, point sur l’emprise au sol) fausse une analyse.
2. Les algorithmes de GeoHash produisent des identifiants non signifiant, mais ils sont longs et complexes à recopier à la main.

Les retours d’expérience du CSTB, de l’IGN, du CEREMA, des membres du CNIG et d’autres partenaires nous poussent à adopter, comme identifiant unique, un identifiant non signifiant. Cela afin de garantir une certaine pérennité dans le temps ainsi. Tout en ayant aucune adhérence avec des éléments d’information potentiellement mutables.

Afin d’être facile à recopier, saisir, il convient également que ces identifiants uniques soient le plus court possible. Tout en limitant le risque de collision. Cela exclut également des GuuID qui sont généralement trop longs.

Enfin, la génération de ces identifiants doit être décentralisée dans la mesure du possible. C’est à dire que la création de l’identifiant n’est pas confiée à une autorité unique qui centralise la génération.

Proposition conjointe de la mise en œuvre de l’algorithme Nano-ID par l’équipe-projet RNB et le CNIG

Les discussions publiques du CNIG, du CSTB, de l’équipe-projet RNB et du portail des Géocommuns ont poussées l’équipe BDNB à adopter l’algorithme Nano-ID pour la génération décentralisée d’identifiants uniques non signifiants. Il en va de même avec le projet RNB. Les identifiants des deux bases (BDNB et RNB) partageront à court terme les mêmes identifiants basés sur la solution Nano-ID.

Principe de fonctionnement des Nano-ID

Le principe de génération d’un Nano-ID provient du dépôt public de code suivant : https://github.com/ai/nanoid . Il consiste à proposer un algorithme permettant de générer des identifiants uniques non signifiants courts, de manière décentralisée.

• Court : Afin de limiter des erreurs de saisie et limiter de nombre d’octets nécessaire au stockage informatique des identifiants
• Sûr/Décentralisé : Son fonctionnement utilise un “hardware random generator”. C’est à dire qu’il y a une empreinte machine qui permet d’assurer que plusieurs générations d’identifiants simultanées, sur différents ordinateurs, ne génèrent pas deux fois le même identifiant.
• Portable : L’algorithme a été porté dans plus de 20 langages de programmations. Python et PostgreSQL inclus.

Pour le besoin spécifique d’identifiants des objets relatifs aux bâtiments. L’équipe RNB, qui vise à créer un Référentiel National de Bâtiment (RNB ) et le CSTB, ont proposé d’utiliser un identifiant alphanumérique composé de 3 séquences de 4 caractères (exemple fictif : 5RHY-E89P-AB51). Les caractères alphanumériques à utiliser sont exclusivement des majuscules ou des numéros puisés dans la liste suivante 123456789ABCDEFGHJKLMNPQRSTUVWXYZ. Les caractères “0” et “o”/“O” ont été supprimés de l’algorithme de génération des Nano-ID afin de limiter des erreurs de saisie lors de la recopie manuelle des identifiants. Il en va de mettre pour les caractères “i”/“I”.

Note : Cela nous laisse un dictionnaire de 33 caractères alphanumériques utilisables. Pour un identifiant composé de 3 séquences de 4 caractères, cela donne un stock théorique de (3*4)^33 combinaisons. Soit 1 667 889 514 952 984 961 possibilités.

Le code mis en place pour générer les nanoid de la BDNB est grandement inspiré de celui implémenté en Python par l’équipe RNB pour prototyper le Référentiel National de Bâtiment (RNB ). Il repose lui-même sur un “fork” du dépôt de code PostgreSQL suivant : https://github.com/viascom/nanoid-postgres . Merci aux auteurs de ces codes.

Le générateur de nanoid utilisé renvoie une chaîne aléatoire unique de 12 caractères. Pour la suite, côté BDNB, deux modifications sont réalisées afin d’obtenir les nouveaux identifiants uniques externes non signifiants des tables [parcelle_unifiee], [batiment_construction] et [batiment_groupe] :

1. Les 12 caractères sont fragmentés en 3 séquences de 4 caractères séparés par le délimiteur “-”. Cela afin de facilité la lecture et la réécriture des identifiants.
2. L’ajout de préfixe à ces identifiants afin d’évacuer tout risque de confondre des identifiants Nano-ID des différentes tables BDNB utilisant ce type d’identifiants.
   • La table [batiment_construction], pour son futur identifiant batiment_construction_id, utilise le préfixe bdnb-bc-
   • La table [batiment_groupe], pour son futur identifiant batiment_groupe_id, utilise le préfixe bdnb-bg-

Note : Le choix d’adopter un format 3 fois 4 caractères provient d’un alignement de formalisme des identifiants, entre l’équipe BDNB du CSTB, l’équipe RNB et le CNIG.

Tables de filiation

Les nouveaux identifiants Nano-ID vont progressivement venir remplacer les anciens. Des tables de filiation entre les anciens identifiants et les nouveaux seront disponibles sur demande. Les nouveaux identifiants viendront alimenter les colonnes batiment_construction_id et batiment_groupe_id de respectivement les tables [batiment_construction] et [batiment_groupe]. Les anciens modes de génération des “anciens” identifiants seront conservés pour générer des colonnes internes à la BDNB appelées respectivement batiment_construction_interne_id et batiment_groupe_interne_id.

Exemple de table de filiation pour les identifiants “anciens” et “Nano-ID”

L’exemple ci-dessous présente deux colonnes d’identifiants de la table [batiment_construction]. Chaque ligne correspond à 1 objet (i.e. une entrée).

batiment_construction_id	batiment_construction_interne_id
bdnb-bc-7SQG-XF1Y-X9TP	BATIMENT0000000008739001-0
bdnb-bc-WRTG-FQ1X-27R4	BATIMENT0000000008739003-0
bdnb-bc-QSCM-8QN7-CZ7B	BATIMENT0000000008739025-0
bdnb-bc-SJGD-ZJYV-X78Q	BATIMENT0000000008739034-0
bdnb-bc-8FMA-BRPD-DCSC	BATIMENT0000000008739044-0
bdnb-bc-XQL5-7DGQ-Z2US	BATIMENT0000000008739050-1
bdnb-bc-K7Q7-LB8P-JJSG	BATIMENT0000000008739051-0
bdnb-bc-E18V-X73S-S74Y	BATIMENT0000000008739065-0
bdnb-bc-CTDK-TH5E-8PDK	BATIMENT0000000008739068-0
bdnb-bc-ZNPJ-9GY9-LV39	BATIMENT0000000008739077-0
bdnb-bc-UFMV-69W8-PE29	BATIMENT0000000008739080-0
bdnb-bc-DHZY-LRKT-URTW	BATIMENT0000000008739129-0
bdnb-bc-ANTE-X9PD-2VQY	BATIMENT0000000008739132-0
bdnb-bc-5EXH-KHW9-13ET	BATIMENT0000000008739147-0
bdnb-bc-2D28-HRNA-TYGC	BATIMENT0000000008739149-0