Non-exclusivité des données
Principes d’urbanisation pour un système d’information

Ce principe est en fait très similaire au principe d’asynchronisme (principe 6), avec une dimension supplémentaire liée à la complexité des données (figure 8).

• Dans les applications en mode cloisonné, la gestion des potentiels conflits d’accès entre plusieurs utilisateurs, sur une même donnée, est généralement faite via des mécanismes de réservation : l’utilisateur annonce son intention de travailler sur une donnée et l’application en interdit l’accès (au moins en modification) aux autres utilisateurs. Ce mécanisme de verrouillage des données est généralement mis en œuvre quand l’activité de l’utilisateur est relativement longue : de quelques heures à quelques jours.

• Dans le cas d’un système basé sur des référentiels transverses, une telle réservation impliquerait qu’aucun autre processus de l’ensemble du système ne puisse modifier cette donnée.

  Cette réservation, qui était voulue et acceptable sur une sous-partie du système d’information, prend une ampleur difficilement contrôlable quand elle s’applique sur l’ensemble du système. En effet, la sémantique de la réservation devient vite complexe à définir précisément et entraîne rapidement un couplage fort entre processus – couplage dont nous avons vu les inconvénients majeurs.

  Prenons l’exemple d’un contribuable dont on est en train de changer la situation fiscale. Cette modification peut prendre plusieurs minutes, voire plusieurs heures, en particulier si l’agent est interrompu (téléphone) ou si l’agent doit chercher des informations supplémentaires. On pourrait donc vouloir « réserver » les données du contribuable pour éviter que quelqu’un d’autre ne les modifie en même temps, ou n’applique des traitements sur ces données en cours de modifications.

  Mais où pourrait être stockée cette « réservation » ? Si elle était stockée dans le SF Pilote de l’activité qui...