1997- 2003 Designer un Système d'information / Air France & Orange

Considérer l’Information au sein du Système d’information

Mon expérience est celle du Pilotage du SI, structure créée dans les grandes entreprises pour équilibrer le pouvoir de la DSI. Pour être efficace, cette structure de pilotage doit être idéalement dirigée par la DG et les directions Métiers. L'existence de cette structure permet de valider les besoins en traitement d’information et diffusion d’information, de minimiser les effets des luttes de pouvoir et de distribuer les ressources vers les projets les plus pertinents. Ainsi, à Air France, positionné comme Pilote du SI, j'ai contribué à réorienter 3 Milliards de francs vers des petits projets SI très rentables.

Pourquoi la Direction du Système d’Information n’est-elle pas en mesure de piloter le Système d’Information ? Pourquoi cette distinction subtile entre le « pilotage » et la « direction ». Parce que la DSI est contrainte par l’infrastructure des systèmes moyens informatiques et télécoms (le « legacy » ). Je suggère de considérer la DSI comme prise dans des tensions difficile à combiner :
- tension entre les projets d'évolution et les contraintes techniques de la réalisation
- surtout tension entre l'évolution de l'infrastructure et la maintenance à l'identique de cette infrastructure pour minimiser les coûts

C'est pourquoi, à mon avis, la DSI est peu intéressée par les nouveaux besoins d'information. Dans le flot incessant des nouveautés technologiques, ce qui motive le plus la DSI, ce sont des techniques qui réduisent les coûts des systèmes et des outils, ou qui en externalise la gestion.

Voici un schéma qui illustre ma conception globale de la place des acteurs dans les évolutions du SI :

Esquisse d'une Gouvernance de l’Information

Il ne faut pas minimiser les contraintes historiques subies par les systèmes en place et l’enjeu de maîtrise des coûts. Mais, in fine, la clé des évolutions du SI réside dans des méthodes de qualification de l'information, afin que le Pilotage du SI puisse, à partir des besoins, bâtir des objectifs fiables et des cahiers des charges assortis de mesures après réalisation. Avec les Métiers de l’entreprise, le Pilotage du SI structure un dispositif de Gouvernance de l’Information. Comment gouverner l'information ?

La DSI ne peut pas gouverner l’information. Par contre, la DSI doit savoir travailler en transverse avec les autres directions, car service support, elle doit apporter ce support à l’ensemble des métiers.

- piloter à intervalles réguliers les évolutions du SI
- systématiser la relation Maitrise d'Ouvrage / Maitrise d'Œuvre
- promouvoir des communautés transverses à l'ensemble des métiers et de la DSI
- édicter des bibles de normalisation

Les dirigeants sont sceptiques : qu’est-ce que cette « information » qui mériterait un dispositif à part ? Une information, disent-ils, c’est le résultat d’une opération, d’un calcul. L’informatique optimise ces millions de calcul (efficacité sur le volume et fiabilité dans la répétition). Ce sont les machines qui calculent. Et les machines sont de la responsabilité de la DSI. Un topo possible de sensibilisation des dirigeants pourrait ressembler à ceci :

1/ L'enjeu : la qualité et la destination de l'information
- les nouveaux besoins : quelles informations et pour qui ?
- l'expérience de la qualité de l’information: les informations de la veille économique

2/ Pourquoi l'information est-elle en souffrance ?
- les problèmes sur les composantes de l'information (données, acteurs, infrastructures)
- les coûts de l'information défectueuse ou absente
- les coûts de l'information non contrôlée dans sa diffusion

3/ La gouvernance du SI
- déterminer quelles informations sont prioritaires
- qui porterait cette gouvernance ,
- quels principes pour gouverner le SI : concept de la donnée, cycle de vie de la donnée, référentiels partagés, règles de diffusion et d’accès, rôles des acteurs, ....

4/ La mise en œuvre de la gouvernance
- les acteurs de la gouvernance : les fabricants d'information, les MOA métiers utilisant l'information, les contrôleurs, les auditeurs
- comment la DSI se met au service de la gouvernance
- les dynamiques de la gouvernance : méthodes, démarches, pilotages des plans d action, alertes..

5/ Exemples de chantiers
- Information impossible
* pas de données clients : on ne gère que les données produits et les données de livraison
* impossibilité de fidéliser le client : surcoûts de opération de promotion
donc action d'identification client et de catégorisation des produits achetés pour connaître les préférences clients

- Information incomplète
* le calcul du coût complet d'un service oublie une partie des fournisseurs contribuant à ce service, car cette partie ne figure pas dans le périmètre de la comptabilité : le prix du service est mal calculé
donc action de redéfinition du périmètre de valeur;

* la non production ou la perte de documents techniques juridiques ou le non respect du délai entrainent des pénalités ou des amendes
donc action de contrôle des documents [Document Control en ingénierie]

- Information aux mauvais destinataires
* documents qui tombent entre les mains des concurrents des analystes financiers ou de la Justice ..
donc action de maitrise des accès aux données avec le RSSI;

- information non finalisée
* toutes les données d'échanges entre collaborateurs apportent de l'information mais celle-ci n'est pas capitalisée
donc action de maitrise des échanges de mails;

Cependant, une fois connus les besoins en information, il faut structurer cette information

Qualité de l’information et structuration des données

Imaginons une entreprise qui organise toutes ses données autour du produit.

Le produit est décliné en différents volets de données :

- le produit agrège des composants, aussi les données composants sont dépendantes des noms commerciaux des produits figurant au Catalogue

- le produit est stocke et distribue : les données de stockage et de distribution sont dépendantes des contrats commerciaux sur tel ou tel produit et leur nature varie selon les contrats

- le produit est vendu par le réseau de distribution a des clients dont le nom et l'adresse restent inconnus, soit par Internet, et dans ce cas, il ya connaissance du nom et de l'adresse client.

Les objets Composants, Client, Distributeur;,Logistique n'existent pas. Aussi, leurs attributs spécifiques ne peuvent pas être identifiés et donc ne peuvent faire l'objet d'un recueil de données. Il y a beaucoup d'informations sur les produits, mais elles sont inexploitables.

Pour caricaturer, l'informatique de beaucoup d'entreprises se résument aux trois actions basiques d'un forain : argumenter le produit sur l'étal, faire payer et rendre la monnaie, faire les comptes de retour à la maison. Pourtant, un forain se pose d'autres questions : qui fréquente le marché ? Quels produits seront demandés ? Qui sont mes concurrents ? Comment créer la fidélité ? Le forain accumule des informations sur la Ville, le Marché de gros, les Marchés de détail, les Tendances. Pourquoi les informatiques des entreprises ne sont-elles pas capables de faire ce que fait un forain ?

Les trois grands volets de l'information et leurs objets

Selon moi, il y a trois grands volets de l'information, qui sont transverses a l'entreprise :

- il y a les objets et les données qui les décrivent : objet client ou fournisseur, objet collaborateur, objet actif (machine, bâtiment..), objet processus , objet produit ou service ; ces données ont un cycle de vie : acquisition, fiabilisation, évolution, destruction ; selon les objets, elles ont des maladies spécifiques quand un objet s'impose sur un autre [ex : les données sur les actifs sont uniquement comptables ; les données sur les clients sont dépendantes des produits ou des services ]

- il y a les documents : les faire et les savoir-faire avec ces objets [qui sont modélisables par des nœuds entre ces objets] ; problématique de gestion des documents au sens de classement, droits d'action, archivage juridique, etc..

- il y a les échanges d'interaction : alerter sur un problème, demander une coopération, promouvoir une idée ; l'interaction peut se faire n'importe où, à l'aéroport, à la maison, etc. et par des canaux divers (réseaux sociaux, blogs..)

L'informatique comme une ville

Aujourd'hui, les systèmes informatiques - ce que l'on appelle le Système d'information - sont devenus les lieux de rencontre par excellence. L'espace d'une entreprise devient une enveloppe qui englobe, via les données informatiques, ses clients, ses fournisseurs, ses distributeurs, ses partenaires, et bien sûr ses collaborateurs. L'entreprise se redéfinit par les règles qu'elle impose aux différentes modalités de rencontre (rencontre d'achat d'un produit par un client, rencontre d'achat d'un produit a un fournisseur, etc.) et d'autre part, selon les différents niveaux d'accès des acteurs aux bases de données qu'elle constitue.

Il existe des dispositifs informatiques dits place de marche ou communauté qui facilitent les rencontres et les transactions résultant de ces rencontres. La société qui gère une place de marche, sans même avoir de produits en propre, impose ses propres règles; l'ensemble de ses pratiquants et constitue une masse d'information qui est distribuée sélectivement. Par contre, on notera qu'elle garde la propriété de la consolidation de cette information.. Voici la carte Internet de ces places de marche en 2007 :

Un système informatique peut être considéré comme une ville. Sur les entrelacs des réseaux techniques s'ajoutent les réseaux de contractualisation entre acteurs. Puis s'y ajoutent les réseaux éphémères constitués à l’ occasion d'une transaction ou d'un échange. Enfin, des réseaux de consolidation de l'information apparaissent pour traiter l'historique de ces réseaux éphémères. Internet est devenue telle une Ville Globale, ou se sont créés des places, des quartiers, des avenues, des rues et enfin des édifices.

Vous êtes le Directeur d'une entreprise. Lorsque vous considérez votre informatique, les frontières sont difficiles à tracer. Ou finit l'édifice entreprise et commencela rue ? Dans cette rue qui mène à une place de marché qui côtoyez-vous ? Vous avez du mal à positionner ce qui vous est propre :

- dans les diverses communautés ou vous proposez vos produits et ou vous achetez vos composants

- dans les services communs qui, par exemple, indiquent l'éligibilité d'une personne à payer par carte bleue, ou font les intermédiaires de paiement

- dans vos publicités qui s'activent dans les moteurs de recherche

- dans les publicités des communautés qui drainent les prospects vers vos produits.

Avec cette révolution, le constat s'impose d'un retard culturel de beaucoup de dirigeants. L'informatique est toujours considérée comme une application qui automatise des tâches, afin d'augmenter la productivité. Les questions suivantes sont rarement posées :

- quels sont les standards et protocoles de réseau et de traitement de l'information que mon réseau informatique interne doit partager ?

- quelles sont les places de marché ou les communautés où mon entreprise doit apparaître ?

- quels sont les services communs à utiliser, afin de sécuriser mes échanges et mes transactions ?

- quelles sont mes apparitions, et selon quelle fréquence, sur les moteurs de recherche et les medias ?

- comment puis-je récupérer l'information constituée par l'ensemble des recherches, des transactions et des avis des clients où mon entreprise est impliquée ?

- comment organiser les différents niveaux d'accès aux données considérées comme données de l'entreprise

Surtout, ce qui est la ressource fondamentale, les données Produits, Clients, Fournisseurs, Distributeurs, Partenaires, Consultations, Transactions, Achats, Opinions .. et leur historique est ignorée. Les données existent de façon éparse, mais il n'est pas possible de les consolider en une série continue, de leur appliquer des critères communs de tri, de scorer la densité de leur maillage.

L'exemple de la structuration des données d'un club de football

Les données sont des variables d'un attribut. Comment identifier les attributs ? Un attribut va caractériser un Objet. La structuration des données consiste a identifier les Objets élémentaires et leurs attributs spécifiques. Par exemple, les Objets élémentaires du football sont les Entraineurs, Les Sponsors, les différentes Compétitions, les Règles de Carton, les Contrats des Joueurs. On peut visualiser comment les autres Objets se construisent en incluant des jointures avec ces Objets élémentaires.

Ainsi par jointures successives, ces Objets élémentaires seront articules dans des Objets composites. Nous voyons que l'Objet le plus composite est le Récit du match.

Le projet informatique assimilé à une prise de risque qu'il faut minimiser

La comparaison des traders aux chefs de chef de projet est pertinente dans la mesure où il est question du traitement des risques.

Un projet d'évolution du Système d'information est un investissement qui présente intrinsèquement un risque. Plus précisément, j’identifie quatre familles de risques :

• le risque de difficultés techniques inattendues
• le risque de déphasage avec les normes de l’environnement de l’innovation
• le risque d’assèchement des ressources
• le risque de rejet par les futurs utilisateurs de l’innovation

Par rapport à ces risques, le chef de projet va avoir deux comportements :

1. une organisation interne des actions et des délais du projet afin de réduire au maximum les risques ;
2. une prise de couverture des différents risques, l’amenant à mobiliser des ressources qui ne font pas intrinsèquement partie du projet.

Par exemple, il fera une veille sur les évolutions des technologies proches au cas où. Il développera des relations étroites, sinon amicales avec les acteurs influents de l’environnement. Il augmentera son périmètre fonctionnel de façon à apparaître comme un budget important, ce qui lui permettra de se faire sponsoriser par un membre de la Direction. Il familiarisera et préparera ses futurs utilisateurs par des annonces et des expérimentations sur des aspects rassurants ou prometteurs de l’innovation.

Cette couverture des risques dans le projet s’apparente à la prise de couverture d’un vendeur sur un prix dans un délai J+1 ans.

Maintenant, considérons l’ensemble des chefs de projet d’une grande entreprise. Ils se retrouvent en compétition entre eux par rapport à des ressources limitées. Une entreprise ne peut maintenir longtemps plusieurs lignes de veille sur des technos différentes. Les acteurs de l’environnement ne peuvent pas être amis avec tous les chefs de projet. Un gros budget est forcement taillable. Les futurs utilisateurs n’ont que peu de temps d’attention à consacrer à un futur encore hypothétique.

Le chef de projet doit alors ouvrir une couche supplémentaire d’action en misant sur une couverture de risque plutôt qu’une autre. Symétriquement, les acteurs qui servent de couverture vont privilégier certains chefs de projet plutôt que d’autres. Ils vont spontanément privilégier les chefs de projet qui facilitent leur rôle de couverture. Par exemple, un Directeur financier sponsorisera de préférence un projet dont la rentabilité est facile à argumenter. Finalement, comme les couvertures sont apportées par les pouvoirs en place de l’organisation existante, on devine que les investissements les moins innovants seront privilégiés.

L’effet global obtenu est un classement selon une rangée de couvertures décroissantes des investissements d’innovation et des chefs de projet. Certains chefs de projets apparaissent comme des champions en termes de couverture de risque. D’autres chefs de projets apparaitront comme des perdants potentiels.

On arrive donc à deux paradoxes :

1. Plus une grande entreprise lance de projets, moins elle va innover ;

2. plus il y a des projets, plus il y aura apparition de chefs de projets déclarés insécurisant ou incompétents, ce qui entraîne une rotation rapide des chefs de projet.

Donnons nous comme objectif d’approcher une alternative à ce mode de couverture du risque. Le problème central est la rareté des ressources de couverture du risque. Cette rareté fonctionne comme un calibre qui induit un calibre sélectionnant un petit nombre de chefs de projet comme champion.

Ma préconisation est double :

• Plutôt que d’avoir un chef de projet-trader, il faut privilégier des équipes d’apprentissage où l’ensemble de l’équipe possède les compétences requises : les acteurs-couvertures apportent des couvertures de risque plus précises et plus localisées à un grand nombre de compétences ce qui diminue l’effet de rareté ; l’apprentissage interne à l’équipe améliore la maîtrise du risque et l’articulation des couvertures
• Pour échapper a l’effet de correspondance entre le risque d’un projet et â une couverture, il faut installer un plan transverse entre l’ensemble des risques des projet et l’ensemble des couvertures. La transversalité à la fois sur les risques et leurs couvertures fait apparaître des enjeux de coopération entre les chefs de projet.

Ces deux actions de suppression de l’effet rareté et de l’effet de facilité de couverture par l’organisation ouvrent un espace de réussite pour un projet d’investissement dans une innovation.

Réduire les risques d'un projet par son calibrage économique

La problématique économique

L'évaluation économique des projets poursuit plusieurs objectifs :

- Faire apparaitre un différentiel pour le métier

- Mesurer le projet, mais surtout l'ouvrage (Coûts, gains, rentabilité)

- Affecter judicieusement les ressources (humaines, financières) et rationaliser ce choix.

- Vers les projets qui ramènent le plus d'argent (VAN maximum).

- Vers les projets qui rentabilisent le mieux chaque franc dépensé (TRI maximum).Pour que les 'petits' projets très rentables puissent passer !

- Vers les projets qui ramènent le plus vite de l'argent (Pay Back mini). On minimise ainsi le risque dans une situation très évolutive ! La concurrence peut se placer entre des projets de natures différentes : lancer une campagne de pub, réaménager une réception client ou réaliser un logiciel.

- Rechercher au travers de l'affectation budgétaire l'adéquation besoins/ressources. Optimiser l'emploi des n ressources disponibles et anticiper leur évolution en + ou -. Cet exercice peut influer sur la faisabilité du projet, ou sur son économie.

- Créer les conditions d'un double engagement (couts, résultats).

L'évaluation économique des projets permet d'aller vers une logique de portefeuille de projets visant à repartir les risques.

Quand évaluer un projet ?

L'évaluation économique du projet s'effectue :

- En début de projet, afin d'en permettre le lancement

- A chaque Comite d'Investissement et chaque Revue budgétaire

- En fin de projet, au moment où l'équipe projet se dissout : re actualisation des couts

- Par sondage, après un certain temps d'exploitation de l'ouvrage : réactualisation des charges et recettes différentielles

Objectifs induits

Identifier clairement les gains et les couts d'un projet donne l'occasion :

- De se poser des questions qui feront avancer la définition de ce que l'on veut obtenir. On pourra ainsi élaguer et prioriser les demandes. En particulier, on éliminera tôt les demandes peu utiles qui coutent cher.

- D'enrichir la liste des conséquences d'un projet et apporter des ordres de grandeur.

- D'impliquer concrètement les responsables, qui seront amenés à prendre la mesure des éléments sur lesquels ils s'engagent.

Présentation d'une méthode et d'un outil de calibrage économique d'un projet

Téléchargez la présentation préparée par Francis Jacq et Patrick Mac Gregor : Evaluation économique des projets SI a Air France

L'urbanisation du système d'information

Dans ce contexte, l'urbanisation du système d'information donne lieu à deux paradoxes. Alors qu'elle devrait être une gestion clé du système d'information puisque l'informatique fonctionne comme Ville, elle est soit méconnue, soit ignorée. Secundo, parce qu'elle structure une vision globale des échanges et des données, les dirigeants et les informaticiens méconnaissent que l'urbanisation est un art de la petite evolution.

En effet, que se passe-t-il quand une ville possède un Plan d'urbanisation ? Un édifice est construit. Certes, c'est une évolution qui vient modifier la physionomie d'une rue ou d'un quartier et les flux des ressources dans les réseaux urbains. Mais c'est une évolution qui reste minime, car, au global, la ville préserve ses régulations globales.

Dans les paragraphes qui suivent, nous esquissons quelques propositions de démarches d'urbanisation du Système d'information qui concrétisent notre approche. On y verra que l'application perd sa place centrale. Trois innovations :

1/ La notion de processus est mise en avant, non pas "pour subordonner la technique au fonctionnel", mais comme méthode pour identifier les éléments du système. L'élément processus est identifié par rapport à un enjeu de valeur ajoutée.

2/ La délimitation des frontières se fait via un Bus de gestion des messages disposant d'une carte des processus, de règles sur les messages et d'un annuaire des droits d'accès des acteurs.

3/ Les données sont structurées, fiabilisées et localisées de façon à faire l'objet de traitements spécifiques dégageant des informations utiles à l'entreprise (ou à une agence publique)..

L'urbanisation : structurer pour faciliter les évolutions et l'amélioration des performances

La démarche de l'urbanisme est de faciliter les évolutions d’un système urbain, et par analogie d’un système informatique. Cela veut dire que le système préserve globalement sa structure et son fonctionnement d’ensemble, bien qu’un ou plusieurs éléments du système soient modifiés. 

Un système doit être décomposé en éléments, car ce sont les éléments que l’on fait évoluer.

Cependant, il faut distinguer deux parts dans l’élément une partie stable et une partie évolutive. Du point de vue de la structure du système, l’évolution de la partie d’un élément sera minimisée si cette évolution s’effectue au sein d’une « boite stable »;. C’est ce que l’on appelle « l’effet boite noire »;, car l’évolution au sein de la « boite »; n’est pas perceptible par la vue « structure statique »;.

Par exemple, l’évolution d’une application sera délimitée au sein d’un processus construisant une nature de valeur ajoutée. L’évolution se fait rapidement et à faible coût du moment que l’application respecte, pour réaliser ses échanges de message avec des applications dans d’autres processus, les Règles de mise en relation entre processus;.

Ces règles de mise en relation sont aujourd’hui implémentées dans un outil de dialogue entre applications, appelé MOM [Message Oriented Middleware]. ;Il est possible d’aller plus loin en concevant un Bus qui, structure stable, gèrera en son sein les évolutions dans les messageries de données. Grâce à; un tel Bus, des messages entre cette application et les autres applications auront une source et une destination définies de façon non technique. Cf. un exemple de spécification d'un tel Bus : Architecture d'un Bus de gestion de message

 

Du point de vue dynamique des relations, l’évolution sera perceptible car elle modifiera la performance de l’interaction entre les éléments. Par exemple, si une donnée est fournie en 0,01seconde au lieu de 0,1 seconde avec une qualité régulière et une fiabilité intrinsèque, la performance s’exprimera en rapidité de debit.

Les impacts des evolutions sur le système porteront sur la globalité du système : ses performances (capacité, vitesse..), sa lisibilité, ses facilites de contrôle et de maintenance, son économie (coûts récurrents, investissement).

Structurer par les processus d'ajout de valeur

La réalité d’une entreprise ou d’une administration est très loin de se présenter comme un système d’ensemble où les composants structurels et leurs relations mutuelles se laissent lire du premier coup d’oeil.

Etape 1 : L’urbanisation dégage progressivement les composants structurels et leurs relations mutuelles avec les dirigeants de l'entreprise (ou de l'agence publique)de façon à faire apparaître le système.

Ces composants seront à identifier par rapport aux potentiels d’évolution. Là où il y a à progresser, c’est dans la construction de valeur par rapport à un type de client ou la maîtrise d’une ressource stratégique. C’est pourquoi, la pratique préconise de se centrer sur l’identification des grands processus d'ajout de valeur.

Un processus est un enchaînement structuré d'ajout de valeur dont le résultat présente une valeur ajoutée globale. Au fur et à mesure que les ajouts sont mises en œuvre, la valeur d'un produit, d'un service ou d’une ressource se construit jusqu'à obtention du niveau du résultat final attendu.

Principe : Un processus doit être en boucle. Un événement déclencheur aboutit à un résultat effectif, correspondant aux exigences de l'événement déclencheur.

Règle : L’exécution de toutes les tâches doit être vérifiable et vérifiée de la première à la dernière.

Le résultat du compte rendu d’une tâche élémentaire, s’il n’est pas OK provoque la remontée d’un avis de problème vers un acteur responsable bien identifié.

Règle : un processus doit être supervise

Pour détecter tout écart par rapport au fonctionnement nominal, les différentes performances (qui font sens par rapport aux enjeux directs et indirects du processus et aux différents acteurs) sont mesurées. Un historique des déroulements du processus est constitué et archivé. Les différentes mesures, par niveaux de consolidation, sont diffusées aux différents acteurs.

Règle : Un processus doit être piloté

Lorsque son fonctionnement s'écarte du nominal, un processus doit être pilote par un acteur pour le ramener dans le fonctionnement nominal, ce pilotage à chaud agissant directement sur les instances de processus en cours d'exécution. C'est par rapport à ce pilotage que l'entreprise ou l'agence publique détermine sa frontière juridique de responsabilité propre.

Urbanistes et architectes

Dans le système informatique, l’urbanisme précède l’architecture comme dans une ville où les urbanistes travaillent avant les architectes afin de tracer les route, décident des canalisations (les flux dans le Système), des natures d’approvisionnement (eau, électricité, fibre optique, ADSL, ..) et aussi des infrastructures communes (les hôpitaux, les stades, la mairie ..) Ces infrastructures communes correspondent dans le Système aux référentiels et aux modules communs fournissant des services.

Les architectes eux travaillent en général à la construction des bâtiments (les applications) qui se raccordent au système d’approvisionnement et aux services communs définis par les urbanistes.

Alors que l'architecture tend à autonomiser les éléments avant de les articuler dans un système, l'urbaniste considère l'impact d'un élément dans les chaînes d'interdépendances de ce Système. L'urbaniste recherche d'atteinte d'une série de qualités d'usages :

• L'exhaustivité et la fiabilité des informations
• La disponibilité et l'ergonomie des outils
• La gestion des accès au système et la sécurité par rapport aux attaques
• Les meilleurs coûts et délais pour satisfaire un nouveau besoin

Etape 2 : A partir des qualités d'usage souhaitées, des exigences d'évolutivité et d'économie, les urbanistes produisent des règles d'architecture pour la conception des futurs éléments et l’assemblage des « édifices » et des réseaux de transport.

Ces règles aboutissent, à l'occasion d'un besoin exprimé par une catégorie d’utilisateur, à la mise au point d'une architecture fonctionnelle qui apporte :

• la fourniture de services satisfaisant le besoin
• une simplification de l'existant
• une amélioration de la flexibilité par le découplage entre la vue logique (stable) et la vue opérationnelle (évolutive)

tout en respectant le pragmatisme de la démarche de projet et de mise en exploitation (clarté du besoin et de son périmètre, maîtrise des coûts, tenue des délais, qualité de l'œuvre, économie de l'ouvrage final).

Les réponses des urbanistes

Voici quatre grandes règles de conception que les urbanistes proposent aux architectes :

• Chaque élément doit pouvoir profiter de la disponibilité de services communs. Les services communs sont conçus de façon à anticiper une série d'évolutions sectorielles.
• Chaque élément spécialisé doit pouvoir offrir des services (services prives ou publics, génériques ou spécifiques) à n'importe quelle partie du système.
• La qualité des données (assurée par les référentiels) et leur mise en format commun (format pivot) ou leur structuration en Objet, permet leur disponibilité dans chaque partie du système
• Les éléments sont regroupés et normalisés de façon à favoriser les évolutions, leur réutilisation et éviter les redondances.

Voici le schéma cible indiquant les composants techniques dont la disponibilité annoncée fait rêver les urbanistes.

 

Etape 3 : Sur la base de ce cadre général l'urbaniste produit des règles d'urbanisme orientant les évolutions du Système d'Information (l'urbaniste conseille l'architecte mais ne construit rien par lui-même):

• règles d'échanges entre les composants de l'architecture du Système interne et avec les Systèmes externes (fournisseurs, partenaires, clients) via des réseaux prives ou public (liaisons prives, Internet)
• règles de construction des processus et de distrisbiution des droits d'acc&es dans les processus
• règles de gestion des messages entre processus
• règles de construction, de stockage et de cycle de vie des donnees et des documents
• règles d'utilisation des donnees et des documents dans les processus
• règles de construction des architectures en lien avec les processus et l'existant informatique : interface utilisateur, applications, structuration des données, accès aux données
• règles de construction de l'architectures des services, du système d'échanges de message et des annuaires associes
• règles de gestion de la sécurité contre les attaques et des groupes de gestion de droits d'accès

L'urbaniste coopère avec les architectes informatiques pour :

• Formaliser les processus et les qualités d'usage demandées au Système, qui sont à considérer comme le Cahier des Charges de l'architecture technique.
• Fournir des critères de regroupement ou d'éclatement des applications.
• Mettre ces applications dans un statut de service, via un ou plusieurs annuaires
• Superviser les choix de standards et protocoles réseaux, de produits d'infrastructure et de production de logiciels de manière à ce que ceux-ci satisfassent aux règles d'urbanisme.
• En particulier, l'urbaniste veille à ce que la structure des processus et les caractéristiques techniques permettent aux utilisateurs et aux concepteurs de disposer naturellement et constamment des degrés de liberté nécessaires aux évolutions à venir du système.

et surtout :

Etape 4 : Structurer les données (dans un Référentiel des données, ou en les structurant dans des Objets) en les rendant indépendantes des procédures de traitement localisées dans les processus.

Une donnée doit pouvoir être utilisée avec la même sémantique dans toutes les applications du Système d'Information.

Voici, par exemple, une architecture urbanisée qu'il est possible aujourd'hui de mettre en place, étant donné l'Etat de l'art technique :

Les qualités de cette architecture d'ensemble peuvent être décrites comme :

• Un Système ouvert dont les évolutions sont maîtrisées, plus rapides et moins onéreuses.
• Adoptant un modèle architectural ouvert base sur les protocoles standards des technologies Internet, ce qui facilite son ouverture à de nouveaux réseaux de fourniture et de distribution de services.
• Accessible par tous les medias (internet, mobile, réseau local) et par tous les acteurs (clients, distributeurs, fournisseurs, collaborateurs ..) ce qui démultiplie les accès aux données, tout en assurant leur sécurité et leur fiabilité.
• Orienté Utilisateur, offrant une vision multi-usages : Documents spécifiques à chaque processus et à chaque valeur ajoutée.
• Dont le coût de fonctionnement propre est minimisé par un découplage des applications via un Bus de gestion de messages, par des services communs et des données normalisées valables en tout point du système.
• Développant une architecture de services (gestion d’un Annuaire centralise des services communs, Annuaires des droits d'accès), ce qui permet une introduction plus rapide des nouveaux services.

Le 2 octobre 2010