Bonjour,
dans le cadre d’un projet avec ESS-france pour cartographier des structures nous réfléchissons à la mise en place d’un identifiant unique. Habituellement c’est le SIRET qui est utilisée mais plusieurs cas « problèmes » se présentent :
les associations qui n’ont pas de SIRET
un seul SIRET et plusieurs structures (cela semble le cas pour des structures de l’insertion)
La question se pose donc de créer un identifiant unique.
Auriez-vous des exemples, des idées, des suggestions, des attentions particulières à avoir, des ressources ?
Merci de vos lumières
PS : je précise (au cas où) que si je pose cela ici c’est parce qu’il y a de l’ouverture des données derrière cet identifiant unique
Est ce que potentiellement, il y a des structures qui pourraient avoir un numéro FINESS?
D’ailleurs le RNA, est-il actif en Alsace-Moselle? Je ne suis pas sûr.
Tout ceci serait tellement plus simple si TOUTES les asso avaient un SIREN/SIRET systématiquement attribué lors de leur création…
En fait toute personne morale devrait être dans SIRENE, comme toute personne physique est dans RNIPP (Répertoire National d’Identification des Personnes Physiques).
SIRENE deviendrait le RNIPM.
des structures de « l’économie circulaire », cela peut aller de structures d’insertion par le reemploi à des repair café, en passant par des entreprises de valorisations du papier !
Structures est sans doute réducteur car c’est plutôt le lieu d’une activité, nous affinons au fur et à mesure.
oui et c’est bien le fait de distinguer ces diverses structures qui est nécessaire.
peut-être mais trop anecdotique pour être un identifiant unique
une approche pourrait donc être de prendre SIRET ou RNA (quid effectivement des assos alsaciennes ? je ne sais pas) et d’y rajouter un numéro d’ordre sur deux positions (qui prendrait la valeur 01 pour tous les cas où il n’y a pas besoin de distinguer plusieurs activités)
oui nous avons envisagé cela avec aussi (siret et/ou rna) + mix latitude-longitude (assumant le fait que ce n’était pas au même endroit).
si les 2, on préfèrera le siret mais alors cela veut dire que l’association qui récupère un SIRET le jour où elle fait une demande de subv ou qu’elle embauche, alors son identifiant unique change (!).
ess-france ayant une mision régalienne, je m’interroge sur le fait de « simplement » le créer et d’assigner un numéro, numéro intangible (si la structure disparaît, on n’efface pas le numéro, on ne remplace pas). Ce numéro est seulement associé à un « siret, rna, nom, lat-long »
SIRET identifie un établissement, donc une activité sur un lieu donné.
Le SIREN ne change pas, c’est le SIRET qui peut évoluer quand l’asso déménage (nouvel établissement) ou qu’il y a un changement d’activité. Pour une demande de sub ou dès qu’elle embauche elle est forcément inscrite dans la base SIRENE (SIREN stable + au moins 1 SIRET pour le siège).
Il n’y a pas forcément de SIRET attribué à chaque lieu ou elle agit sur le terrain, on peut avoir une certain activité à un endroit sans y établir d’établissement. Cas typique: le camion à pizza a en général un établissement siège, mais pas d’établissements là où il s’installe temporairement.
Créer un identifiant « unique » de plus, sans s’appuyer sur ceux existant est à terme un handicap pour les échanges en dehors de sa sphère. C’est pour ça que les N° RNA sont au final une absurdité et que toute asso devrait avoir un SIREN+SIRET ce qui permettrait à tout le monde de savoir qu’on parle de la même structure.
Il faut donc identifier les rares cas où SIREN/SIRET et/ou RNA ne sont pas suffisants et trouver un paliatif, mais dans les autres cas utiliser ces identifiants provenant de 2 jeux de données du Service Public de la Donnée avec une préférence pour le plus large: SIREN/SIRET
yep, je suis favorable au SIRET et/ou RNA. Cependant cela semble poser « question » pour les raisons évoquées préalablement.
je n’ai pas creusé encore suffisamment en particulier le cas des ateliers et chantiers d’insertion qui semble avoir cette problématique (1 siret, plusieurs lieux).
une assoc RNA qui prendrait un SIREN, pour les raisons évoquées, garde son RNA.
Cela pourrait donc être RNA pour association et Siren/siret pour les entreprises.
Et pourquoi pas intégrer le siret quand présent et/ou le RNA, plus un numéro de structure interne.
C’est bien la personne morale qui met en place cette structure ESS et c’est bien elle qui en est garante et bénéficie de ses avantages.
Donc le Siren/siret et RNA ne me semble pas faux.
Après, il s’agit juste d’identifier la structure.
attention à e pas créer un nouvel identifiant … et je rejoins Christian sur le fait que les assocs devraient toutes être sirennées … (bien que le taux de turn over est bien plus important … )
Bonjour,
En matière de modélisation et de maintien opérationnel au cours du temps, choisir l’attribut d’un objet pour lui attribuer une ID unique est une très mauvaise pratique, et pour avoir parcouru rapidement ce fil, l’exemple code insee est révélateur. Utilisez un identifiant unique de type numérique généré par le système (typiquement un serial). Chaque objet créé est ainsi unique et ne fait pas dépendre l’objet (donc la logique du système) d’un de ses attributs susceptible d’évoluer au gré du producteur de la donnée, typiquement une administration. La fusion de commune est un exemple révélateur du choix « code insee ». voir ici : Forum GeoRezo / utilisation comme référentiel pivot du code Insee des communes
C’est le principe du plus grand dénominateur commun. Chaque entité est unique selon Id_Entitie après attribut SIRET no data value n’est pas interdit …
Quelque chose comme cela
La répétition du Id_personne_morale est volontaire c’est pour forcer le trait sur le fait que c’est toujours la même chose sous une autre forme. C’est la magie du polymorphisme
Sous l’angle base de données pour gérer les cas d’utilisations évoqués dans vos contributions, un objet géolocalisé qui peut évoluer au cours du temps, fusionner, se déplacer, être divisé ?
Ceci permet en matière de base de données de modéliser un graphe. C’est le cas il me semble pour vos cas d’utilisations non ?
Chaque personne morale possède au moins une image c’est la sienne.
A sa création elle a le statut de mère.
A chaque modification importante (fusion, déplacement etc …) un nouvel objet personne morale est créé en mode actif, il a le statut de fille, l’ascendant est désactivé mais persiste dans la base.
Une entrée est créée dans la table réflexive si l’ascendante était déjà une fille.
En matière d’intégration l’ajout d’un attribut « sourcededonnées » permet d’intégrer plusieurs sources dans la même base et d’utiliser SQL pour vérifier si l’objet est nouveau ou s’il existe déjà sur la base de règles métier, de type si mêmes siret, siren, géoloc alors même objet, donc inactivation et préservation des sources création d’une nouvelle entité active sources vérifiées sources X, Y Z.
Bonsoir,
Non l’identifiant c’est une clef numérique générée par un système. Celui de votre base de données par exemple. Ou un organisme fédérateur X
Un chiffre unique qui ne veut rien dire. Ensuite les identifiants existants dans les différentes sources de données sont ce que l’on appelle des attributs ou propriétés. Elles peuvent être unique dans la définition de leur producteur ou ne pas avoir de valeur peut importe, ce ne sont pas elles qui définissent l’identité et l’unicité de l’objet. Un produit opendata issu de données opendata pourrait parfaitement comporté ce genre de clef. Elle est générée par le système qui produit cette donnée.
Ensuite conserver l’historique, oui et plus. La table réflexive est un miroir de la table personne morale, elle permet de créer des liens entre deux personnes morales.
L’avantage de coder sous forme d’un entier généré par le système les clefs uniques et les clefs étrangères est de permettre la préservation de la logique du système, même en cas de changement imprévu du producteur de données. Il permet donc la donnée ouverte et en sus, le modèle ouvert.
ok "mon"identifiant unique est alors propre à « ma » base. Si je veux du partage avec d’autres bases par l’intermédiaire disons d’OpenStreetMap (au hasard ) il faut donc que je libère cet identifiant évidemment pour qu’éventuellement d’autres l’utilise.
Le schéma que vous décrivez fait penser à wikidata ? un lien ou une affabulation de mon esprit ?
Oui. Et quand j’utiliserai ces données, soit j’utilise ces clefs uniques telles que, ou je considérerai que c’est une propriété des objets utilisés, et je générerai mes propres identifiants uniques. J’aurai le choix des deux possibilités. Dans les deux cas j’ai à ma disposition la logique de la base de façon aisée. Il suffit pour rendre la lecture facile d’appliquer des règles de nommage. Pour tout objet (ou table de la BD), en début j’ai les colonnes de type serial ou entier, nommées id_mytable1 (Primary Key) et ensuite un ou plusieurs ptr_mytableN (Foreign Key) , ptr_ pour pointeur vers.
Il ne faut pas mélanger clé unique au sein d’une base de données pour assurer l’intégrité référentielle dans la base, et identifiant partagé avec l’extérieur.
Bonjour à tous,
pardon d’abord, car mon sujet dépasse un peu celui de l’économie sociale et solidaire : de façon un peu similaire aux structures de l’ESS, les Copropriétés sont des personnes morales « de fait » mais ne disposent d’un SIRET que dans de rares cas (présence de salarié par exemple).
Il existe bien un « Registre des Copropriétés » mais celui-ci est loin d’être complet (faute de pression, les syndics ne se bousculent pas pour le renseigner), géré par l’Agence Nationale de l’Amélioration de l’Habitat (ANAH) mais pas mis à dispo en Opendata.
De mon côté, j’ai mis en place une immatriculation « maison » sur la base du code INSEE de la Commune et d’un incrément… mais je crains que ce ne soit pas robuste (le cas des fusions de communes est un bon exemple) et surtout impossibnel de le partager avec quiconque.
J’avais pensé utilser l’ID BAN de l’adresse mais certaines Copropriétés comportent plusieurs immeubles à ces adresses distinctes (Résidences).
Merci par avance de vos suggestions…
Stéphane
