Identifiants¶

L'utilisation d'identifiants cohérents est essentiel pour faciliter le croisement et le rassemblement des données ouvertes de la commande publique.

L'identifiant Open Contracting (ocid) est un identifiant mondialement unique utilisé pour joindre des données à chaque étape d'un processus de passation des marchés ;
Les identifiants d'organisation sont importants pour savoir qui est impliqué dans chaque contrat ;
Les identifiants des instances, des attributions et des contrats sont importants pour aider à croiser les informations.

Types d'identifiants¶

Dans OCDS, il y a deux types d'identifiants : ceux qui sont mondialement uniques et ceux qui sont locaux.

Les identifiants mondialement uniques¶

À travers tout l'écosystème des producteurs de données OCDS, ces identifiants doivent se référer à un processus de passation de marchés ou à une organisation unique.

Nous créons des identifiants mondialement uniques de processus de passation de marchés en ajoutant un préfixe aux identifiants internes détenus par les producteurs de données.

Worked Example

Deux producteurs de données publiques (ville A et ville B) numérotent leurs processus de passation de marché de 0 à la suite.

La ville A publie des informations sur un processus de passation de marchés pour construire une nouvelle route. En interne, ils savent que c'est le contrat 0005.

La ville B publie des informations sur un processus de passation des marchés pour acheter des manuels scolaires pour une école. En interne, ils le connaissant aussi sous l'identifiant 0005.

Quand ils publient leurs données OCDS, chaque administration ajoute un préfixe unique à leurs identifiants internes.

Maintenant, les processus de passation de marchés de la ville A ont l'ocid 'ocds-fh349f-0005' et ceux de la ville B ont l'ocid 'ocds-twb234-0005'.

Il n'est maintenant plus possible que ces identifiants soient confondus par un système qui importe les données des deux villes.

Enfin, si un groupe indépendant de la société civile en charge du suivi des marchés veut publier un rapport sur la mise en œuvre du projet de route de la ville A, ou sur le marché des manuels scolaires de la ville B, ils ont des identifiants distincts qu'ils peuvent utiliser dans leurs propres données pour y faire référence.

Le chapitre suivant décrit l'approche OCDS pour identifier les organisations.

Identifiants locaux¶

Tous les identifiants dans OCDS ne doivent pas nécessairement uniques dans l'absolu. La majorité des identifiants ne doit être unique que pour un même type d'objet 'à l'échelle d'un même processus de passation de marché. Par exemple :

Un identifiant d'instance doit être unique dans le processus de passation de marchés dont il fait partie ;
Les identifiants pour les avis d'attributions (award) et les contrats (contract) doivent être uniques au sein du processus de passation de marché dont ils font partie ;
Les identifiants d'un livrable (item), d'une étape (milestone) ou d'un document (document) doivent être uniques dans l'ensemble de données auquel ils appartiennent.

Les identifiants locaux doivent être utilisés de manière cohérente. Par exemple, si une attribution reçoit l'identifiant '22' dans une instance, la même attribution doit avoir le même identifiant (22) dans toutes les instances ultérieures qui s'y rapportent.

Identifiant de processus de passation de marché (ocid)¶

Un identifiant Open Contracting (ocid) est un identifiant mondialement unique de processus de passation de marché. Chaque instance OCDS possède son propre ocid.

Il peut être utilisé pour croiser des informations publiées à des moments différents et à des lieux différents.

La mise en place de l'ocid est habituellement un processus en deux étapes simples :

Identifier le meilleur identifiant interne avec lequel le processus de passation de marchés est enregistré ;
Se procurer un préfixe ocid à préfixer à cet identifiant interne auprès de l'assistance technique OCDS.

Dans certains cas, vous devrez peut-être envisager de modifier les systèmes existants pour veiller à ce que les différents systèmes de gestion de l'information sur vos processus de passation de marchés aient un identifiant interne commun.

Worked Example

Pour la ville de Mexico, chaque fois qu'un processus d'appel d'offres ou qu'un marché direct est lancé, le ministère responsable attribue un identifiant.

Ceux-ci sont constitués d'un identifiant pour le département responsable du marché, du numéro d'appel d'offres et de l'année.

Par exemple :

OM-DGRMSG-004-13

Cet identifiant interne peut être échangé et enregistré dans tous les autres systèmes qui traitent des informations sur ce processus de passation de marché. Par exemple, des systèmes de notification ou d'enregistrement des transactions de paiement des fournisseurs.

Mexico City then registered a prefix with the Data Support Team. They have been given the prefix ‘ocds-87sd3t’ which can be added to their unique process identifiers to give a globally unique ocid. E.g.

ocds-87sd3t-OM-DGRMSG-004-13

Le préfixe ocid lui-même est composé de deux parties: un préfixe identifiant l'agence (actuellement seulement 'OCDS' est utilisé) et une chaîne alphanumérique à six caractères généré de manière aléatoire pour chaque producteur de données.

Le champ ocid est sensible aux majuscules et minuscules. La casse doit être utilisée de manière régulière quand il s'agit d'un ocid.

Préfixes enregistrés¶

Chaque producteur de données doit réclamer et enregistrer un préfixe ocid. Consultez les pages d'inscription pour vous informer sur la façon d'obtenir votre préfixes ocid.

Prefix are randomly generated lowercase alphanumeric strings. A prefix is assigned to each organization that holds the existing internal identifier for a Contracting Processes.

A l'heure actuelle, seule l'Open Contracting Partnership délivre des préfixes valides. À l'avenir, d'autres organisations pourraient être en mesure d'émettre des préfixes, avec leurs propres préfixes d'identifiants d'agence.

Vous pouvez trouver ici la liste des préfixes ainsi que le formulaire d'inscription pour la demande de nouveaux préfixes.

Les préfixes enregistrés ne sont pas destinés à porter une sémantique ; leur seul but est de transformer les identifiants internes en identifiants mondialement uniques qui peuvent être croisés entre les systèmes.

Espace de noms du producteur de données¶

Les versions antérieures de cette documentation imposait un modèle plus strict sur la façon dont les identifiants internes devaient être combinés avec le préfixe ocid, avec l'exigence d'ajouter des espaces de noms locaux. Cette exigence a été assouplie dans la pratique et doit être considérée comme dépréciée.

Cependant, les producteurs de données sont encouragés à vérifier qu'il n'y a pas de risque de conflit entre les identifiants locaux (par exemple, la possibilité que deux entités au sein du producteur puissent utiliser le même identifiant pour différents processus de passation de marchés) et de prévoir d'harmoniser leurs propres modèles pour générer leur ocid.

Identifiants de l'organisation¶

Pouvoir identifier de manière fiable les personnes morales impliquées dans un processus de passation des marchés est vital pour la transparence et la responsabilité, et pour réaliser des analyses qui permettront d'améliorer la commande publique et la gestion des contrats.

Les producteurs de données devraient chercher à collecter et à enregistrer les identifiants juridiques issus d'un registre officiel de toutes les organisations impliquées dans un processus de passation des marchés (y compris les acheteurs, les soumissionnaires et les titulaires), et devraient les inclure dans leurs fichiers OCDS.

Il y a deux composantes de l'identifiant d'une organisation dans les données ouvertes sur la commande publique.

Un préfixe de registre identifiant un registre dans lequel l'organisation est identifiée.
L'identifiant existant de l'organisation prévu dans ce registre public

Worked Example

Le préfixe de registre d’organisations pour la UK Companies House, l'organisme en charge du registre du commerce au Royaume-Uni, est GB-COH. L'organisation Development Initiatives a obtenu le numéro d'entreprise '06368740' par Companies House. L'identifiant mondialement unique de l'organisation Development Initiatives peut alors être exprimé ainsi :

{
  "scheme": "GB-COH",
  "id": "06368740",
  "uri": "http://data.companieshouse.gov.uk/doc/company/06368740",
  "legalName": "Development Initiatives Poverty Research Limited"
}

In OCDS, the organization register prefix is included in the scheme field of an identifier block, with the existing organization id placed in the id field. If there is a recognized public URI that uniquely identifies this organization (for example, drawn from the UK's Company House register, or from Open Corporates) this can also be given in the uri field.

Choisir un identifiant¶

Le préfixe du registre d'organisations est utilisé pour désigner un registre à partir duquel l'identifiant d'organisation est conçu. Il existe une gamme de différents types de listes d'organisations :

Registres primaires - tels que les registres nationaux des sociétés. Un identifiant émis par ces organismes a un sens juridique spécifique. Il y a une équivalence univoque entre l'identifiant et une entité juridique d'une forme particulière dans une juridiction donnée. L'identifiant est créé en même temps que l'organisation est officiellement constituée, et les modifications du statut de l'organisation sont enregistrées par rapport à cet identifiant dans un registre officiel. L'utilisation d'identifiants issus d'un registre primaire sont fortement recommandés dans OCDS.
Secondary registers - which record a particular property of an organization, such as being registered for VAT, or registered as an employer. An organization's identifier in such a registry might change without the organization itself changing in nature. For example, in some jurisdictions, an organization might de-register from VAT, and then re-register, gaining a new number in the process; or different branches of the same legal entity might register for different VAT numbers.
Bases de données tierces - qui compilent une liste des organisations, et parfois de leurs sous-unités, sur demande. Ces bases de données ne confèrent aucun statut juridique ou propriété spéciale aux organisations, mais peuvent enregistrer une correspondance entre leurs propres identifiants et d'autres identifiants de l'organisation issus de registres primaires ou secondaires. Un exemple typique est l'identifiant propriétaire Dun&Bradstreet. Le système OCDS d'identification des organisations accepte les identifiants issus de bases de données tierces, mais préfère fortement ceux tirés de bases de données non-propriétaires qui permettent aux utilisateurs de rechercher des informations d'identification.
Listes locales - Certains producteurs de données n'établissent pas de concordance entre leurs données et des identifiants externes. Ils maintiennent à la place une liste locale des producteurs. Dans ces cas, le producteur de données peut utiliser ses identifiants internes et adopter sa propre liste de préfixes. Lorsque c'est possible, le producteur de données devrait également fournir sa liste locale sur le Web avec autant de données supplémentaires que possible sur chaque producteur afin de maximiser les chances que les utilisateurs de données établissent des correspondances avec un registre plus fiable.

Voir l'exemple opérationnel pour plus d'informations sur l'implémentation d'identifiants à partir de ces différents types de listes d'organisations.

Si vous souhaitez divulguer des identifiants de personnes physiques, consultez le guide sur les identifiants personnels.

Identifiant d'instance¶

Un identifiant d'instance doit être unique dans le cadre du processus de passation de marché dont il fait partie. En d'autres termes, dans toutes les versions d'OCDS ayant le même ocid, chaque identifiant d'instance fait référence à une seule instance ; aucune autre instance n'utilise le même identifiant.

Un identifiant d'instance doit également être cohérent dans ce périmètre. Par exemple, si l'id d'une instance est" 12345" dans un paquet d'instances, alors l'id de la même instance dans un autre paquet d'instances doit également être "12345".

Identifiants d'attribution et de contrat¶

Les identifiants d'attribution (Award) et de contrat (Contract) doivent être uniques dans le cadre du processus de passation de marché dont ils font partie. En d'autres termes, dans toutes les instances d'OCDS ayant la même valeur ocid, chaque identifiant de contrat fait référence à un seul contrat ; aucun autre contrat n'utilise le même identifiant.

Les identifiants d'attribution et de contrat doivent être utilisés de manière cohérente. Par exemple, si une attribution reçoit l'identifiant '22' dans une instance, la même attribution doit avoir le même identifiant (22) dans toutes les instances ultérieures qui s'y rapportent.

Les contrats doivent toujours être liés à l'attribution (en utilisant le champ awardID), afin que les informations clés sur les titulaires puissent figurer dans l'attribution liée. Plusieurs contrats peuvent se référer à la même attribution, par exemple dans le cas d'un accord-cadre, où plusieurs contrats sont créés en lien avec une seule attribution.

Identifiants de livrables, de documents et d'étapes¶

L'identifiant (id) d'un livrable, d'un document ou d'une étape doivent être uniques au sein une même liste (array) et doivent être employés de manière uniforme parmi toutes les instances d'un même processus de passation de marché.

Le même identifiant peut être réutilisé dans une autre liste au sein d'une même instance, et aucune référence croisée entre ces identifiants n'est implicite.

L'utilisation d'un identifiant signifie que les versions ultérieures peuvent mettre à jour les livrables, documents ou étapes identifiés auparavant sans avoir besoin de republier tous les livrables, documents ou étapes.

Par exemple :

Une première instance définit les livrables (items) à acheter dans tender/items et les livrables attribués dans une attribution dans awards/0/items :
- tender/items contient trois livrables, avec des champs id dont les valeurs sont "1", "2", et "3"
- awards/0/items contient deux livrables avec des champs id dont les valeurs sont "3" et "4"

Il n'y a aucune relation entre le livrable à acquérir avec l'identifiant "3" et le livrable attribué avec l'identifiant "3". Ceux-ci peuvent être des livrables différents. Continuons l'exemple :

Une deuxième instance met à jour les livrables attribués dans awards/0/items :
- awards/0/items contient trois livrables avec des champs id dont les valeurs sont "3", "4" et "5"

Ici, il existe bien une relation entre les livrables attribués avec id "3" et "4" dans la première instance, et les id "3" et "4" dans la deuxième instance. La deuxième instance doit être interprétée comme une mise à jour des livrables identifiés "3" et "4" pré-existants, et l'ajout d'un nouveau livrable, dont l'identifiant est "5".