Le système informatique instrumente le système d’information. Lors d’une réponse cohérente de l’organisation à des pressions externes de son environnement, l’urbanisation applicative doit être considérée comme une harmonisation des relations entre le système d’information et le système informatique.

Ce concept relativement nouveau dans son ampleur, prolonge et fait exploser les dimensions du classique plan directeur et d’architecture du SI. A l’origine de cette extension se trouve  le constat que toute évolution du système informatique s’inscrit dans un ensemble plus vaste. L’objectif est alors d’assurer dans un environnement en évolution la continuité et la cohérence des communications. Cette nécessité s’exprime généralement dans un contexte technique complexe, distribué, hétérogène et en évolution rapide.

Le métier d'architecte technique (ou de système informatique) existe depuis longtemps. Celui d'urbaniste, parfois nommé architecte d’entreprise (ou de système d’information), est en revanche beaucoup plus récent. Urbaniste et architecte sont aujourd'hui deux métiers complémentaires dont les rôles sont fondamentaux dans la conception, l'implantation et l’évolution de systèmes durables.

En synthèse, l’action de l’urbaniste s’oriente « système d’information » alors que celle de l’architecte se préoccupe du « système informatique ». Ensembles, l’architecte et l’urbaniste disposent d’une vision globale à la fois des processus, des informations et de leurs interdépendances.

A ces deux fonctions, il convient d’ajouter celle d'administrateur de référentiel dont l’objet est d'assurer une définition précise des règles de gestion et un propriétaire unique (dans le sens objet du principe) à chaque information manipulée par l’organisation. Un « métier » manipule généralement plusieurs dizaines d’informations clés auxquelles correspondent plusieurs centaines de termes. Parfois plus d’un millier, à l’échelle de grandes organisations, ce qui implique un sérieux travail de recensement et de définition consensuelle. En pratique, lors de l’analyse d’un vaste système impliquant de nombreux acteurs ou groupes d’acteurs, une recherche lexicale peut être conduite en parallèle aux entretiens de groupe.

Depuis ses débuts, la méthode RAD dans certaines occasions, instrumente d’ailleurs cette formalisation lors de ses « sessions de travail ». Cette activité nécessite un rapporteur supplémentaire qui réalise « en direct » la synthèse du discours utilisateur afin de recenser les termes ou expressions invoqués. Le principe se base sur le dénombrement des mots afin de réduire le discours à ses termes signifiants. L’étude de leur fréquence récurrente permet ensuite de définir un vocabulaire commun, de repérer les vocabulaires spécifiques et de normaliser un vocabulaire unifié. Le recensement dépasse le cadre du simple glossaire, où seule la terminologie serait prise en compte. Il englobe l’aspect sémantique et facilite ensuite la modélisation des procédés.

La maîtrise d’un vocabulaire métier unifié est à la base de l’amélioration du pilotage des processus de conduite de projet, d’ingénierie « métier » et de conduite du changement.

De plus, la notion d’ « utilisateurs » s’élargit jusqu’à englober les client et parfois les fournisseurs. L'évolution de la demande applicative, associée à la maturité accrue des systèmes informatiques, oriente alors le fonctionnement de la DSI vers la notion essentielle de fourniture de « services ». Et ce, dans un contexte de mise à disposition élargie pouvant franchir les frontières naturelles de l’organisation. L’action d’urbanisation acquiert alors une dimension stratégique.

Dans le cadre général de son action, l’urbaniste de système d’information se base sur les théories de la systémique et les principes de l’objet. Partant d’une architecture applicative souvent anarchique, il la découpe, clarifie et réglemente en blocs de bas niveaux dans le but de produire des ensembles fortement cohérents et faiblement couplés. Idéalement, selon C. Longépé, « un système urbanisé comporte des blocs de plus ou moins grosse maille, dont les frontières sont imperméables (encapsulation) et qui communiquent par échanges de messages ».

Figure 1.— Outil de modélisation de services et d’urbanisation

En pratique, l’urbaniste utilise de plus en plus souvent la notation UML (Unified Modeling Language). Pour la définition des besoins fonctionnels, il recourt plus spécifiquement aux cas d’utilisation. Les diagrammes de dépendances se montrent plus appropriés pour la mise en évidence des relations entre les objets intervenant dans les processus métiers. Au lieu de représenter les processus comme une série d'étapes, il est parfois utile de les organiser en « vues » spécifiques aux divers acteurs :

ú         le dirigeant, pour définir la stratégie de l’organisation,

ú         le cadre opérationnel, pour agir sur l'organisation,

ú         l'organisateur, pour structurer le processus métier,

ú         l’informaticien, pour déterminer les technologies adaptées.

Des outils spécialisés s’avèrent alors nécessaires pour modéliser ces représentations, et pour l’instant malheureusement, les logiciels de modélisation utilisés par les informaticiens ne répondent pas parfaitement à ce besoin. Une offre de logiciels spécialisés se développe en ce sens, mais il lui faudra pour être pérenne respecter les fondamentaux d’UML. L’exemple de la Figure 1 est une application répartie représentée avec le logiciel Amarco de Sysoft. Le diagramme (aboutissement graphique d’une méthode de modélisation orientée vers la description de services) décrit plusieurs modules interconnectés, certains internes à l'entreprise et d’autres externes. Le processus « métier » concerné est superposé sur l’organisation. Le schéma, dont une des particularités est de bénéficier d’une animation,  permet de visualiser dynamiquement les processus en action à travers leurs flux, principe renvoyant à deux notions indissociables : la transversalité et le mouvement.

Basé sur une forme d’instrumentation conceptuelle appliquée à l’optimisation des flux et des process, le travail de l'urbaniste représente donc une œuvre de fond dont le but est de permettre aux systèmes d’information de perdurer, tout en évoluant par osmose avec les nouvelles technologies.

Pour sa part, l’architecture technique définit les divers composants et les conditions techniques de leur mise en œuvre :

ú         infrastructure de communication,

ú         répartition des données et des services,

ú         nature des applications systèmes et base de données,

ú         nature des outils et langages de développement et de documentation,

ú         nature des outils de l’utilisateur final,

ú         règles de communication avec les entités externes à l'organisation,

ú         procédures de sélection et d'agrément des fournisseurs et des produits,

ú         exigences de qualité et durée de vie des composants,

ú         flexibilité  ou évolutivité minimale des composants.

Le travail de l'architecte est également fondamental, même s'il se limite à un système particulier ou à un aspect spécifique de l'édifice à construire.

Urbaniser les systèmes d’informations et d’informatique est une chose, mais réagir à l’entropie et optimiser les processus en conséquence en est une autre.

L’objet doit beaucoup de remerciements à la systémique, car modéliser un système complexe passe par la modélisation d’un système d’actions. La caractérisation d’une action passant par la notion de processus, la complémentarité de l’objet avec le BPR  est évidente.

L’expérience le démontre régulièrement, il ne saurait suffire pour optimiser un système, d’optimiser l’une ou l’autre des parties sans tenir compte des interdépendances et des interactions. L’efficacité implique la nécessité d’optimiser l’ensemble et l'architecture des parties entre elles. Se limiter à automatiser par une d’application aussi utile soit-elle est insuffisant, si l’organisation sous-jacente est imparfaite. Cette théorie trouve une application pratique évidente avec le diagramme de dépendances ci-dessous (Figure 2).

A l’impression, ce diagramme ne sera ni très colorié ni très lisible, mais son intérêt se situe dans la vision d’ensemble qu’il permet d’acquérir. Le système étudié, très simple au demeurant, se trouve néanmoins au cœur d’un ensemble plus vaste

Une explication s’impose quant aux nuances de teintes appliquées aux objets, des packages en l’occurrence. Le but de ce diagramme est de répertorier les dépendances des divers composants d’un système. La Figure 3 est un agrandissement permettant de faciliter la compréhension du diagramme complet, car sa légende est lisible. En résumé : si le sous-système « étudié » se réduit à trois des éléments, la description des objets de quatre autres sous-systèmes doit être « abordée » en relation de dépendances fortes ainsi que 11 sous-systèmes « hors périmètre » par rapport à l’étude en cours, mais toujours en relation de dépendance à un degré moindre.

Dans le cas d’une action de maintenance ultérieure, par exemple, cette cartographie met en évidence tous les objets directement impliqués et ceux qui subiront éventuellement un impact.

Ce principe d’urbanisme représente les bases indispensables de de l’agilité applicative.

Figure 2 . —  Diagramme de dépendances

Plus subtil à mettre en œuvre, le concept de stabilité est un élément de stratégie d’évolution essentiel à l’informaticien comme à l’organisateur. Une conception efficace, quels que soient la méthode ou le formalisme, s’appuie sur la complémentarité de trois axes de modélisation  distincts : l’axe statique  fixe la structure des données, l’axe dynamique  définit les processus, l’axe fonctionnel  détaille les traitements. La notion d’adaptation est la cible visée dans la maîtrise de ces axes. L’axe statique est le plus stable. Par définition, il faut pour l’atteindre dans ses bases, un changement majeur du métier de l’entreprise. L’axe dynamique colle à l’aspect organisationnel. Seule une réorganisation des acteurs et des processus  doit avoir un impact sur sa définition. Les autres changements superficiels, dans la manière de traiter les produits ou les services offerts, se limitent à une redéfinition des traitements à travers l’axe fonctionnel.

Lors d’un développement de SI, dans le cas où une stratégie de planification  par thème, n’est pas imposée, un chef de projet compétent utilise cette théorie pour planifier son développement en fonction de la stabilité des composants ainsi mise en évidence.

Figure 3 . — Agrandissement du diagramme

Fonctions de démarche qualité et support

---

Extrait de l'ouvrage

Systèmes d'information et processus Agiles

Systèmes d’information et processus Agiles a pour objectif de former les ressources (maîtrise d'ouvrage comme maîtrise d'œuvre), engagées dans un projet d’organisation et/ou de système d’information.

Systèmes d’information et processus Agiles décrit d'abord les aspects stratégiques de l'Agilité puis en détaille les concepts opérationnels. Il s'adresse aux dirigeants et à tous les cadres de l'organisation, dont évidemment, les DSI et chefs de projets "informatiques" ou "utilisateurs". Outil de compréhension de l'agilité organisationnelle et support de sa mise en œuvre technique, l'ouvrage afin d'offrir une réponse appropriée aux intérêts de chaque acteur du projet, est organisé en 3 sections : Organisation et Urbanisation Communications et ressources humaines Agilité en conduite de projet

---