Architecture

Identité d’une entité : aspect métier

Publié le : Auteur: Hugues VAN EYLEN Laisser un commentaire
carteIdentite

Le but de ce billet est de faire le point sur la notion d’identité que l’on utilise dans la modélisation d’un système d’information et, pour reprendre un principe évoqué par Michael Starbird dans son livre « Five Elements of Effective Thinking », de comprendre de manière approfondie ce concept perçu comme simple.

Posons le décor

Le domaine dans lequel nous nous plaçons pour explorer la notion d’identité est celui de la modélisation du métier en vue de construire un système informatique support à des cas d’usage effectués par des acteurs de ce système.
acteurEtSysteme
Construire un système informatique demande de commencer par exprimer le besoin que ce système devra couvrir. Vue d’une manière schématique, l’usage d’un système comporte des acteurs qui interagissent avec le système en échangeant des informations avec ce dernier.

Il découle de cette vision une nécessité de modéliser les informations échangées entre le système informatique et les acteurs. On utilise généralement un cadre de pensée à base d’entités, d’associations et d’attributs pour effectuer cette modélisation. La question se pose alors de l’identité d’une entité. Rien de plus simple, me direz-vous ! C’est ce qui permet de différencier les occurrences d’une entité sans ambiguïté. Approfondissons toutefois cette assertion :

  • Pour quels usages souhaite-t-on effectuer cette identification ?
  • Quelles sont les caractéristiques de l’identité d’une entité ?
  • Y-a-t-il plusieurs types d’identité ?

Usage de l’identité

On peut distinguer deux usages principaux

  • Reconnaître une entité : Un acteur indique au système qu’il veut obtenir les informations sur une entité dont il fournit l’identité. Le système peut alors retrouver cette entité et l’ensemble des données associées ou alors signaler que cette entité est inconnue. Par exemple, un agent d’assurance souhaite retrouver le contrat dont son client lui a donné un numéro.
  • Réaliser les liens entre les entités gérées dans le système : Par exemple, un client possède plusieurs contrats. Client et Contrat sont des entités et le système doit garder trace du lien entre les deux entités. Cela se réalise souvent en gardant dans le contrat l’identité du client ce qui permet par la suite au système de retrouver aussi le client quand un acteur souhaite consulter l’ensemble des données contrat / client.

porteeIdentite
On remarque que pour ces deux usages la portée de l’identité n’est pas la même :

  • La reconnaissance concerne les acteurs et le système ; l’identité doit être partagée.
  • En revanche, les liens réalisés au travers de référence d’identité entre entités est un choix interne au système informatique pour formaliser les associations entre les entités du métier.

Gardons cela à l’esprit et regardons maintenant les caractéristiques souvent associées à la notion d’identité :

  • Unicité : Une identité permet de désigner sans ambiguïté une entité. L’unicité s’entend alors ici comme la règle suivante : Il ne peut exister deux entités distinctes qui ont la même identité. A noter que l’inverse n’est pas interdit : une entité peut avoir plusieurs identités.
  • Obligatoire : Une entité dit obligatoirement avoir son identité pour exister dans le système.
  • Immuabilité : Une identité ne peut changer de valeur quelle que soit sa constitution. Changer une des valeurs qui constituent une identité revient à créer une nouvelle identité.

Cette dernière caractéristique nécessite clarification car, dans la vie réelle, des « modifications d’identité » peuvent survenir comme par exemple à l’issue d’un changement de sexe pour une personne. Si dans le système considéré, le sexe est une composante de l’identité, alors il faut considérer que la personne change d’identité. C’est-à-dire qu’elle en acquiert une nouvelle et non pas que son identité est modifiée. Par exemple, pour le système de sécurité sociale, elle changera de numéro et aura deux identités dont l’une est périmée. On peut changer d’identité mais on ne peut pas changer la valeur d’une identité. C’est l’identité qui est immuable pas la relation entre l’entité et son identité. Il faut toutefois s’assurer que même une identité périmée n’est pas réutilisée pour une autre entité.

Combinons maintenant ces réflexions avec les usages, ce qui amène aux questions suivantes :

  • Comment s’assurer de l’unicité, de l’immuabilité et du caractère obligatoire d’une identité utilisée dans le périmètre de la reconnaissance d’une entité auprès du système ?
  • Comment s’assurer de l’unicité, de l’immuabilité et du caractère obligatoire d’une identité utilisée pour réaliser des liens entre entités au sein du système informatique ?

La seule et unique manière pour qu’un système s’assure de ces trois caractéristiques d’une identité est qu’il en soit le seul responsable et que par conséquent il la définisse et la gère lui-même.

Typologie d’identité

Bien me direz-vous … mais alors le numéro de sécurité social, la plaque d’immatriculation, etc. sont sous la responsabilité de systèmes étatiques et par conséquent mon système ne peut en être responsable. Quelles sont les conséquences d’utiliser ces numéro comme identité d’entité gérées au sein de mon système ?

  • Pour la reconnaissance d’une entité, ces données d’identification peuvent être utilisées comme d’autres critères de recherche. Pour certains, leur portée nationale les place même en tête des meilleurs critères de recherche.
  • Pour la réalisation des liens, c’est plus problématique car le jour où ces systèmes modifient leur vision de cette identité tous les liens internes sont à revoir sous peine de grave problème d’intégrité. Un système ne doit jamais mais alors jamais utiliser des identités provenant d’autres systèmes pour réaliser ses liens internes entre entités. A ce titre le numéro de sécurité sociale précédemment évoqué, encore appelé Numéro d’Inscription au Répertoire des Personnes Physiques (NIR), ne doit pas être utilisé pour effectuer de tels liens. Par ailleurs, la délibération n° 83-058 du 29 novembre 1983 de la CNIL recommande « que l’emploi du numéro d’inscription au répertoire comme identifiant des personnes dans les fichiers, ne soit ni systématique, ni généralisé » et « qu’en conséquence, les responsables de la conception d’applications informatiques se dotent d’identifiants diversifiés et adaptés à leurs besoins propres« .

Pour autant le vocable « identité » est souvent utilisé pour désigner ces fausses identités du point de vue de notre système. On peut alors établir une typologie des identités et énoncer quelques conseils :

  • Identité sous responsabilité du système

o   Identité interne privée : son périmètre est le système. C’est lui qui crée cette identité et l’associe à une entité. Cette identité est utilisée pour réaliser les liens entre entités. Le système ne doit jamais la communiquer à l’extérieur. En effet, fournir cette identité interne à l’extérieur est incohérent mais surtout peut entraîner des dépendances inverses. Les systèmes externes consommateurs des services de notre système bâtissent chez eux des liens sur cette identité et alors si notre système souhaite modifier celle-ci (pour une migration technique par exemple), il peut se trouver bloqué parce qu’un de ces consommateurs a besoin de cette identité. Cette identité est construite de manière à ne porter aucune signification métier.

o   Identité interne publique : son objet est de servir à la désignation d’une entité par un acteur. Le système en est maître mais n’a pas bâti de lien avec elle entre ses entités. C’est une donnée d’échanges et de communication fourni par le système à ses acteurs pour en faciliter l’usage. La constitution de cette identité peut donc être signifiante sur un plan métier. Par exemple, le numéro de contrat contient le mois et l’année de création du contrat et un code indiquant la nature du produit d’assurance (IARD, PJ, etc.) plus une partie calculée assurant l’unicité.

  • Identité partielle issue de l’environnement du système

o   Des identités externes publiques créées par des systèmes externes qui permettent une identification lors de la communication inter-systèmes. Elles sont symétriques aux identités internes publiques. Ces identités issues de systèmes externes ne doivent pas être considérées comme uniques, immuables ou obligatoires. Cela dépendra du protocole de communication accepté avec ces systèmes externes.

o   Des combinaisons de caractéristiques naturelles des entités que l’on décide de voir comme des identifiants mais sans avoir la caractéristique d’unicité ni en avoir la responsabilité. Par exemple une combinaison de nom, prénom, date de naissance peut être identifiant d’une personne mais rien ne garantit son unicité.

differentesCles

Le schéma ci-dessus positionne la portée et la provenance des trois types de clés. Le panneau d’interdiction met l’emphase sur le danger à reprendre une identité externe pour réaliser des liens internes.

Conclusion

En conclusion, l’identité d’une entité est une caractéristique fondamentale qu’il faut impérativement définir lors de la modélisation des données du métier. L’utilisation d’identifiants externes pour réaliser les liens internes ou l’exposition à l’extérieur d’identifiants internes constitue une transgression du principe d’encapsulation et demande de la vigilance. A ce titre, en appliquant une architecture SOA, il faut faire attention à ne jamais fournir d’identité interne au travers d’un contrat de service dans le cas des services postés aux frontières du système informatique. Le pas est vite franchi …