Documentation · Modèle de données

Identifiants et déduplication

Chaque fiche de nos données possède un ID, et les fiches que nous estimons décrire la même partie portent un ID d’entité commun. Cette page explique les deux, la façon dont le regroupement est effectué actuellement et ses limites, ainsi que la manière de garder à jour les références dans vos propres systèmes.

En bref

• ID de fiche crown-<number> : une inscription d’une partie dans un registre, par exemple crown-379759982. C’est la valeur id dans nos fichiers et id dans /api/entity?id= (sans le préfixe).
• ID d’entité crown-e-<uuid> : le groupe de fiches que nous estimons décrire la même partie d’un registre à l’autre. C’est canonical_id dans nos fichiers et entity_id dans l’API. Toutes les fiches n’en possèdent pas.
• Les référents, une liste d’anciens ID de la même entité, font partie du format, mais sont toujours vides actuellement.
• Conservez l’ID de fiche de chaque correspondance sur laquelle vous agissez, et l’ID d’entité à ses côtés lorsqu’il y en a un.

Conserver des références dans votre propre système

Lorsqu’une correspondance de vérification mène à une décision, conservez :

1. l’ID de fiche, qui indique précisément quelle inscription vous avez consultée;
2. l’ID d’entité, s’il est présent, afin de retrouver plus tard les autres inscriptions de la même partie (/api/entity?entity_id=<uuid> dans l’API);
3. le nom du registre et la date de votre vérification, car la fiche de l’éditeur fait foi.

À chaque actualisation, relancez la recherche de vos ID de fiche conservés. Une fiche qui n’est plus retournée a été retirée par son éditeur ou retirée par nos soins. Le guide de l’API en traite plus en détail à la section garder les ID conservés à jour.

Durée de validité des ID retirés

Les ID de fiche sont des numéros de ligne de notre registre. Lorsqu’un éditeur retire une inscription, la fiche est conservée avec sa date de retrait, mais elle n’est plus servie par la recherche ni dans les fichiers en vrac (voir Corrections et radiation de la liste).

Comment les changements apparaissent dans les fichiers delta

Les fichiers delta comparent chaque fiche à la version précédente. Lorsque des fiches sont regroupées sous un nouvel ID d’entité, ou déplacées vers un autre, la valeur canonical_id de chaque fiche change; chacune apparaît donc comme une entrée MOD. Une fiche retirée par son éditeur apparaît comme DEL. Les ID de fiche eux-mêmes ne changent pas lorsque le regroupement change. Voir Fichiers delta.

ID de fiche et sources

Nos ID de fiche sont des numéros issus de notre propre registre, et non la référence de l’éditeur. Le numéro seul n’indique pas la source; c’est le champ datasets qui le fait, et la référence propre à l’éditeur, lorsqu’elle est fournie, se trouve dans notes (par exemple Ref: RUS0251 pour la liste du Royaume-Uni). Les ID de fiche sont identiques dans toutes les collections et dans les téléchargements par registre : une fiche a donc un seul ID, peu importe où vous la trouvez.

Comment les fiches sont fusionnées actuellement

Nous regroupons des fiches en une entité lorsqu’elles ont le même nom nettoyé et la même date de naissance. Les noms sont comparés après suppression de la ponctuation, des espaces et de la casse. C’est la seule méthode utilisée : toutes les entités de notre registre ont été formées ainsi, et la méthode est consignée avec chaque entité.

Exemple : SULTAN AZIZ AZAM, désigné par l’UN Security Council (référence QDi.435), figure sur de nombreuses listes nationales. Sept fiches qui indiquent le même nom et l’année de naissance 1985 partagent un même ID d’entité :

Fiches de la même personne qui n’ont pas été regroupées, issues de la même version :

Cela montre clairement les limites de la méthode :

• Les fiches sans date de naissance ne sont jamais regroupées. Cela exclut presque toutes les sociétés, les navires et les organisations, ainsi que la plupart des personnes politiquement vulnérables (PPV).
• Un ordre des mots différent (AZAM, SULTAN AZIZ) ou une écriture différente empêche le regroupement.
• Deux personnes différentes portant le même nom et la même année de naissance peuvent être regroupées, surtout dans le cas de noms d’un seul mot accompagnés d’une année seulement.

Pour cette raison, nos chiffres sur les « entités distinctes » comptent les fiches qui partagent un nom et une date de naissance. Il s’agit d’une mesure approximative, et non d’un dénombrement des parties réelles. Le registre compte actuellement 286,047 entités regroupées.

Moment d’exécution du regroupement

Les nouvelles fiches sont consultables dès que leur source a été chargée. Le regroupement est une étape distincte; une nouvelle fiche peut donc apparaître sans ID d’entité jusqu’à sa prochaine exécution.

Comment les fiches regroupées sont combinées

Nous ne construisons pas de profil combiné unique à partir d’un groupe. Chaque fiche conserve ses propres noms, dates et inscription tels que son registre les a publiés; l’ID d’entité ne fait que les relier. Les résultats de recherche et les pages de fiche présentent les autres fiches de la même entité comme des inscriptions distinctes. Des règles pour choisir le meilleur nom ou la date la plus précise au sein d’un groupe accompagneraient l’amélioration du regroupement décrite ci-dessus.

Provenance au niveau des champs

Dans statements.csv, entity_id correspond à la fiche et canonical_id à l’entité, ce qui vous permet de regrouper ou de dissocier les valeurs vous-même. Voir Modèle de données des énoncés.

Pages sources des registres de l’exemple et d’autres : Sanctions autonomes consolidées du Canada, OFAC SDN, Sanctions financières consolidées de l’EU, Liste consolidée de l’UN Security Council.

Dernière mise à jour : 2026-10-04