Urbanisation (informatique)

Un article de Wikipédia, l'encyclopédie libre.
(Redirigé depuis Urbanisme (informatique))
Aller à : navigation, rechercher

L'urbanisation du système d'information d'une entité ou organisation (une entreprise ou une administration) est une discipline d’ingénierie informatique consistant à faire évoluer son système d'information (SI) pour qu'il soutienne et accompagne de manière efficace et efficiente les missions de cette organisation et leurs transformations. L'urbanisation du SI ne fait pas table rase du passé mais tient compte de l'existant et doit permettre de mieux anticiper les évolutions ou contraintes internes et externes impactant le SI, et en s'appuyant le cas échéant sur des opportunités technologiques. Les concepts manipulés peuvent s'apparenter à ceux de l'urbanisation de l'habitat humain (organisation des villes, du territoire), concepts qui ont été réutilisés en informatique[1] pour formaliser ou modéliser la réingénierie du système d'information (SI)[2].

L'urbanisation SI est l'action d'urbaniser le SI : cette démarche prévoit des principes et règles ainsi qu'un cadre cohérent, stable et modulaire, auquel les différentes instances décisionnaires de l'organisation peuvent se référer pour toute décision d'investissement relative au management du système d'information.

L'urbanisation informatique est une des méthodologies d'architecture d'entreprise, qui sont toutefois parfois confondues dans la littérature française.

Enjeux de l'urbanisation du système d'information[modifier | modifier le code]

L'urbanisation facilite la transformation continue du système d’information.

Les évolutions des stratégies d'entreprise (regroupements et fusions, acquisitions, diversification des offres commerciales, e-commerce, gestion de la relation client, nouveaux modes ou canaux de distribution, partenariats, réorganisation, externalisation, redéploiement des fonctions de back et front office, etc.) impliquent des changements structurels importants et accroissent l’interdépendance (dépendance mutualisée) et l’imbrication des applications informatiques avec le risque de renforcer l’effet « sac de nœud» du système d'information ou SI.

Cette complexité croissante a des conséquences sur les coûts, les durées et les risques des projets d’évolution des SI.

Pour maîtriser progressivement l’évolution des SI avec la réactivité nécessaire et pour réduire les coûts informatiques, une réponse est apportée par la démarche d’urbanisation des systèmes d’information et par son prolongement au niveau de l’architecture des systèmes informatiques.

Cette démarche d'urbanisation vise un SI capable de soutenir et d’accompagner la stratégie d'entreprise dans le meilleur rapport coûts/qualité/délais.

Elle permet d’améliorer la réactivité et de n’investir que dans les produits et services générateurs de valeur ajoutée, tout en maîtrisant les charges informatiques et le retour sur investissement.

Les outils d'EAM favorisent cette démarche qui peut se mettre en œuvre :

  • de manière opportuniste : à l’occasion d’un projet de développement, de refonte ou de maintenance,
  • de manière plus volontariste : dans le cadre d’un chantier d’urbanisation.

On utilise le terme d'urbanisation plutôt que celui d'urbanisme pour mettre l'accent sur le travail progressif nécessaire pour faire évoluer le système d'information vers une cible correctement urbanisée.

Par ailleurs, cette démarche d'urbanisation rencontre une des préoccupations des maîtrises d'ouvrage : l'alignement stratégique du système d'information sur le métier.

Principe de l'urbanisation du SI[modifier | modifier le code]

L'urbanisation répond à deux règles de bases :

  • Une application doit appartenir -en cible- à un et un seul bloc (pour quelle raison ?).
  • Les dépendances doivent respecter les notions de Cohérence Forte / Couplage Faible
    • entre les applications,
    • au sein d'une application : entre les différents modules,
    • au sein d'un module : entre les différents composants.

Le terme -en cible- définit l'application que l'on cherche à avoir to be. Elle s'oppose à l'existant -la situation actuelle- As is. La méthode pour passer du as-is actuel au to-be souhaité est appelé la roadmap (ou feuille de route).

La notion de Cohérence Forte / Couplage Faible indique que deux applications doivent communiquer entre elles de façon simple et efficace, mais que la dépendance entre ces deux applications est minimale (idéalement inexistante). Cela permet donc de retirer un bloc pour le remplacer sans perturber le reste du SI.

Le système d'information peut donc être comparé au quartier d'une ville : si ce dernier est bien bâti et bien urbanisé, il est possible de raser un bâtiment au cœur du quartier sans mettre en péril tout le secteur, et de le remplacer par ou de reconstruire un autre bâtiment, en raccordant ce nouveau bâtiment aux différents réseaux d'échanges : voirie d'accès, électricité, évacuation des eaux usées, etc. L'urbanisation consiste donc à créer un SI agile, modulable et évolutif.

Application des concepts d'urbanisation[modifier | modifier le code]

L’urbanisation SI est une démarche d'aide à la transformation, rationalisation, simplification et amélioration du SI. Certains auteurs comparent le système d'information à l’image d’une ville, c'est-à-dire réfléchie, structurée, durable. Dans le prolongement de cette analogie - qui a toutefois des limites -, l'urbanisation du SI consiste à planifier des refontes structurantes pour optimiser, les échanges, les services, la flexibilité, la modularité ... et d'une façon plus générale à répondre à la stratégie SI de l'entreprise en parallèle de l'évolution du métier.

Le plan d'urbanisme SI ou Plan d'Occupation des Sols (POS)[modifier | modifier le code]

Pour faciliter les planifications au regard des évolutions du SI, l'urbanisation s'appuie sur un plan d'urbanisme souvent appelé POS, en analogie avec l'urbanisme civil.

Le POS consiste à représenter le SI en s"appuyant sur une cartographie fonctionnelle du SI et un découpage en capacités autonomes, de description de plus en plus fine :

  • les zones,
  • les quartiers,
  • les îlots,
  • et enfin les blocs fonctionnels ou encore les briques

Le POS doit faciliter la construction d'une architecture optimisée du point de vue fonctionnel du SI qui est le point de vue pivot entre le point de vue du métier et le point de vue informatique.

Plus particulièrement, l’urbanisation vise :

  • à renforcer la capacité à construire et à intégrer des sous-systèmes d'origines diverses,
  • à renforcer la capacité à faire interagir les sous-systèmes du SI et les faire interagir avec d’autres SI (interopérabilité),
  • à renforcer la capacité à pouvoir remplacer certains de ces sous-systèmes (interchangeabilité).

et de manière générale pour le SI à :

  • favoriser son évolutivité, sa pérennité et son indépendance,
  • renforcer sa capacité à intégrer des solutions hétérogènes (progiciels, éléments de différentes plates-formes, etc.).

Exemple de règles de découpage du SI[modifier | modifier le code]

  • Règle 1 : Séparation du Back-office du Front-office.
  • Règle 2 : Découpage par processus et par métier. On crée ainsi les zones Décisionnel, Support et Métier.

NB : La zone Métier peut être découpée en plusieurs blocs.

  • Règle 3 : Séparation des canaux technologiques d'accès et de communication (site Web, notification SMS, ...) des canaux du métier 'Relation Client' (CRM, Marketing). On inscrit deux nouvelles zones dans le Front-Office : Acquisition/Restitution et Relation avec les tiers.
  • Règle 4 : Il faut isoler ce qui est partagé par le Back-office et le Front-office ainsi que ce qui les intègre. On définit donc les zones Intégration et Données Partagées.

Les différents types de zones[modifier | modifier le code]

Dans le découpage d'un SI on distingue habituellement différents types de zones :

  • Les zones des activités opérationnelles : gestion des opérations bancaires, gestion des opérations commerciales, gestion des opérations logistiques internes, etc. ;
  • Les zones de gestion des gisements de données : ensemble des informations produites quotidiennement, communes à l'ensemble du SI (données de production, etc.) ;

Dans le cas de très grandes entreprises, il est matériellement impossible d'urbaniser la totalité du SI dans un même mouvement. Cela explique que l'on découpe le SI de l'entreprise en périmètres autonomes ; par exemple : par grandes directions. Chaque périmètre est alors considéré comme un SI autonome qui est urbanisé individuellement. Sa zone d'échange gère ainsi aussi bien les flux extra-entreprises "SI ⇔ SI extérieurs" que les flux intra-entreprises "SI ⇔ autres SI de l'entreprise".

Exemple de découpage et d’énoncé de capacité fonctionnelle[modifier | modifier le code]

À titre d'illustration, une partie du découpage du système d'information d'une banque :

    • zone (capacité métier de) production bancaire
      • quartier (capacité de) vente de crédits
        • îlot (capacité de) proposition de crédits
          • bloc fonctionnel (capacité de) suivi (CRUD) d'une demande/proposition de crédit

Une mauvaise pratique courante consiste à utiliser "gestion de" qui porte à confusion avec la gestion d'un point de vue activité d'un processus. Une bonne pratique consiste à énoncer la capacité précise à faire dans le SI...

Dans cet exemple, la capacité à outiller est le suivi du cycle de vie d'un objet métier "proposition de crédit".

Principaux niveaux de préoccupation[modifier | modifier le code]

Les niveaux de préoccupation constituent ce qu'on appelle le méta-modèle d’urbanisme : c'est-à-dire le modèle conceptuel de description du Système d'Information.

Les objectifs stratégiques du SI[modifier | modifier le code]

Ce niveau de préoccupation du SI est constituée par la description :

Ces objectifs peuvent être modélisés

Ces objectifs se déclinent en exigences métier ou SI, fonctionnelle ou non. La liste de thématiques métier et/ou fonctionnelle peut être obtenue par l'analyse des exigences du système.

Le point de vue du métier ou affaires[modifier | modifier le code]

Le système d'information d'un point de vue métier ou affaires (c'est-à-dire de l’ensemble des métiers) est constitué

La définition de la stratégie de l'entreprise conduit à répertorier :

  • les métiers stratégiques qu’elle exerce vis-à-vis de son marché et autour desquels elle structure ses activités et son organisation - un métier stratégique (exemples : octroi de crédit, courtage d'assurance, ligne de fabrication, etc.) correspond à une combinaison de :
  • les métiers opérationnels qu’elle exerce dans le cadre de chacun des métiers stratégiques (exemples : production, marketing, gestion des risques, etc.)

Les activités exercées par l'entreprise, sont de plusieurs types :

  • les activités opérationnelles qui contribuent à la fabrication des produits vendus ou à l’élaboration des services rendus aux clients,

L'analyse du système métier peut s'appuyer sur les techniques de BPM (Business Process Management ou Business Process Modeling ou Gestion des processus métier) qui visent à :

L'un des objectifs du BPM est de porter un diagnostic sur les processus de l'entreprise et de déterminer ainsi dans quels secteurs les évolutions du SI offriront le meilleur retour sur investissement.

Le point de vue fonctionnel[modifier | modifier le code]

Article détaillé : système d'information.

Le système d'information (SI) d'un point de vue fonctionnel est constitué de l’ensemble :

  • des fonctions, c'est-à-dire des capacités du SI,
  • des objets métiers, c'est-à-dire de l'information (issue des processus) structurée en entités ou objets.

L'analyse fonctionnelle constitue "la pierre angulaire" de la démarche d'urbanisme car ce point de vue est le "levier" principal d'urbanisation du SI. C'est aussi le point de vue du SI le plus difficile à appréhender correctement ; la littérature peine à expliciter ce qu'est une fonction et les sources de confusion sont nombreuses :

  • confusion avec l'activité
  • confusion avec le use case
  • confusion avec le rôle ou le poste d'un acteur
  • confusion avec un module d'application...

Le recensement des fonctions du SI nécessite une capacité d'abstraction qui peut dérouter les néophytes : une fonction est la capacité sous-jacente nécessaire à la réalisation d'une ou plusieurs activités, mais ce n'est pas l'activité. Par exemple, pour l'activité "planter un clou", la fonction sous-jacente est "frappe". Ainsi la fonction "frappe" sert à d'autres activités d'un point de vue métier, et peut être outillée par différent outils d'un point de vue applicatif. Étant donné, la problématique de granularité des fonctions, dans le point de vue fonctionnel, on parle aussi de blocs fonctionnels (qui regroupe les fonctions de bases concourantes à la même capacité du SI). Par exemple, le bloc "Enregistrement du client" comprend les fonctions de type CRUD (Création, Recherche/lecture, Mise à jour, Effacement).

Un SI urbanisé doit pouvoir découpler facilement les sous-systèmes d’information supportant différents métiers et pouvant évoluer à terme vers des systèmes d’information autonomes. Par exemple, une entreprise peut vouloir se donner à terme la possibilité de séparer ses métiers de distribution (vente) de ses métiers de production (gestion des produits) dans des unités organisationnelles distinctes.

L'urbanisation d’un SI combine :

  • la volonté de pouvoir isoler certaines de ses parties pour pouvoir les faire évoluer facilement
  • et l'objectif de mutualiser (mettre en commun avec des SI d'autres partenaires) ou d'externaliser d’autres parties plus stables, moins stratégiques, pour réaliser des économies.

Pour ce faire, l’architecture fonctionnelle recense à l’intérieur de chaque zone, quartier et îlot, les blocs fonctionnels qui entrent dans la composition du SI pour qu’il supporte les processus métiers de l'entreprise.

Le bloc fonctionnel assure :

  • une cohésion forte, cohésion entre les objets qu’il gère et les fonctions qu’il assure,
  • un couplage faible, soit un nombre limité d’échanges avec les autres blocs du SI.

La granularité du bloc fonctionnel (le niveau de maille du découpage) doit :

  • faciliter sa réutilisation dans différents processus et renforcer la modularité du SI
  • favoriser son remplacement par un bloc offrant des fonctionnalités équivalentes.

Le bloc fonctionnel constitue l’unité fonctionnelle à outiller de façon interchangeable. Un bloc fonctionnel est défini par :

  • les objets métier qu’il gère pour le compte du SI,
  • les "services fonctionnels, interfaces permettant d’échanger avec les autres blocs du SI, cela inclut les flux qu'il prend en charge et ceux qu'il produit,
  • les fonctions qu'il regroupe (fonctions liées aux objets métier), et les règles de production des données qu’il communique.

Le point de vue informatique[modifier | modifier le code]

Article détaillé : système informatique.

Le système d'information d'un point de vue informatique est constitué d'un ensemble structuré :

permettant d’automatiser tout ou partie d’un système d'information, et dont l’administration et l’exploitation sont assurées par une même entité organisationnelle (unité d’administration et d’exploitation).

Cette vue globalisante utile pour les non-informaticiens se découpe traditionnellement en différents points de vue bien distincts en informatique :

  • le point de vue applicatif qui se focalise sur les applications du SI indépendamment des plate-formes qui les hébergent
  • le point de vue technique qui se découpe lui-même en :
    • point de vue logiciel (qui décrit l'architecture logicielle d'une application ou d'une plate-forme qui l'héberge)
    • le point de vue infrastructure technique (qui décrit l'architecture réseau)
    • point de vue physique ou matériel (qui décrit l'architecture matériel)

Dans l'étude de l'existant, il faut prendre en compte ces différents types d'architecture, afin d'évaluer les vulnérabilités des sous-ensembles, ce qui ne peut être fait qu'en prenant en compte les niveaux technique et physique. Pour la définition de l’architecture cible, on peut se limiter à l'architecture applicative.

L'architecture applicative définit l’ensemble des applications constituant la partie automatisée d’un système d’information ainsi que leurs modalités d’assemblage et de communication.

Elle est une instanciation de l’architecture fonctionnelle d’un SI dans un environnement technique et d’exploitation donné : on parlera alors non plus de fonction dans la vue applicative mais de fonctionnalité d'un application (c'est dire d'une fonction instanciée).

Le bloc applicatif est un ensemble de composants logiciels qui présentent une cohérence

  • fonctionnelle : données et traitement sur les mêmes objets métiers,
  • technique : implémentation globale mono-plateforme

Le bloc applicatif est autonome dans la mesure où son fonctionnement doit être indépendant du chemin que l'information aura suivi en amont et poursuivra en aval.

Le bloc applicatif est décrit en termes de :

  • structures de données qu’il gère,
  • procédures fonctionnelles qu’il exécute,
  • services applicatifs qu’il met à disposition d'autres blocs ou des utilisateurs
  • messages qu’il reçoit (les événements qu’il traite) et qu’il publie (les comptes-rendus d’événements ou d'opérations qu’il produit).

Les constituants du bloc applicatif (données et services) peuvent être publics (le bloc en donne la visibilité pour permettre à d’autres blocs de les utiliser) ou privés (pour les besoins internes du bloc).

Un bloc applicatif est un objet logiciel concret qui, dans un contexte technique donné, offre à l’ensemble du SI, l'implémentation des fonctionnalités des prises définies par le bloc fonctionnel correspondant. Un bloc applicatif communique avec les autres blocs par échange de messages et par appel de services.

Méthodologie d’urbanisation[modifier | modifier le code]

La démarche d’urbanisation s’articule sur 3 axes clés qui s’alimentent mutuellement :

  • la modélisation de la stratégie
  • la cartographie des systèmes existants (métier, fonctionnels, applicatifs, techniques)
  • la détermination des systèmes cibles (métier, fonctionnels, applicatifs, techniques)

La distinction forte entre existant et cible est un facteur de clarification essentiel.

La démarche d’urbanisation du SI consiste notamment à :

  • définir un SI cible, aligné sur la stratégie de l’entreprise,
  • déterminer la trajectoire à suivre pour atteindre ce SI cible.

Indépendamment des différentes approches qui, selon le contexte de l'entreprise et les options méthodologiques, peuvent être préconisées les activités d'urbanisations se classent en cinq grands domaines :

  • Le "cœur" des processus d'urbanisme,
    • Définir et maintenir le cadre d'urbanisme : plans d’urbanisme (cibles et scénarios de migration), règles, …,
    • Réaliser et maintenir l'infrastructure fonctionnelle du SI : référentiels d’entreprise, dispositifs mutualisés d’échanges inter-applicatifs, …,
    • Développer les relations avec les projets : cadrage, études amont, accompagnement des projets, …
  • Les processus de support : notamment « Maintenir et diffuser les cartographies ».
  • Et les processus de pilotage de l'urbanisation et de participation à l'arbitrage des projets.

Notes et références[modifier | modifier le code]

  1. notamment par Jacques Sassoon dans les années 1990 dans le secteur bancaire
  2. Définition proposée par le Club Urba-EA : Urbaniser, c'est organiser la transformation progressive et continue du système d’information visant à le simplifier, à optimiser sa valeur ajoutée (quelle est la définition de la valeur ajoutée d'un SI ?) et à le rendre plus réactif et flexible vis-à-vis des évolutions stratégiques de l'entreprise, tout en s'appuyant sur les opportunités technologiques du marché.

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • Jacques Sassoon, Urbanisation des systèmes d'information, Hermès Coll. Management et Informatique, 1998
  • Christophe Longépé, Le projet d'urbanisation du S.I. 2e édition, Dunod, Paris, 2004, ISBN 2-10-007376-1
  • Bernard Le Roux, Luc Desbertrand, Pascal Guérif, Xavier Tang, Julien Tixier, Pierre Verger, Urbanisation et modernisation du SI, Lavoisier, Paris, 2004, ISBN 2-7462-0885-7
  • Yves Caseau, Urbanisation et BPM, Le point de vue d’un DSI 2e édition, Dunod, Paris, 2006
  • Pierre Pezziardi, Une Politique pour le Système d'Information - Descartes, Wittgenstein, "XML", OCTO, 2006 ISBN 978-2-9525895-0-5
  • Club URBA-SI, Pratiques de l'urbanisme des systèmes d'information en entreprises, Publibook, 2003, ISBN 2-7483-2942-2
  • Jean-Christophe Bonne, Aldo Maddaloni, Convaincre pour urbaniser le SI, Lavoisier, Paris, 2004, ISBN 2-7462-0977-2
  • Bernard Le Roux, Joseph Paumier, La gouvernance de l'évolution du SI, Lavoisier, Paris, 2006, ISBN 2-7462-1293-5
  • René Mandel, De la stratégie business aux systèmes d'information: l'entreprise et son écosystème, Lavoisier, Paris, 2006, ISBN 2-7462-1297-8
  • Club URBA-EA (ex Club URBA-SI), Urbanisme des SI et gouvernance : Retours d'expériences et bonnes pratiques, Dunod, Paris, 2006, ISBN 2-10-049678-6
  • Michel Volle, De l'informatique : savoir vivre avec l'automate, Economica, Paris, 2006, ISBN 2-7178-5219-0
  • Bernard Le Roux La transformation stratégique du système d'information, Lavoisier, Paris, 2009
  • Jérome Capirossi, Architecture d'entreprise, Hermes Science Lavoisier, 2011, ISBN 9782746229808
  • Jean-Claude Jacquiot, L'architecture d'entreprise intégrée, cahier technique CASE France 2011
  • Ludwig von Bertalanfy : Théorie générale des systèmes
  • Jean-Louis Le Moigne : La théorie du système général
  • Jacques Mélèse : Approches théoriques des organisations
  • C.E. Shannon & W. Weaver : The mathematical theory of communication
  • CARNOT : Deuxième principe de thermodynamique
  • Ferdinand de Saussure : Cours de linguistique générale
  • Luc Boyer et Noël Equilbey : Organisation, théories et applications

Liens externes[modifier | modifier le code]