118
Le Référentiel Nouvelles Plateformes Technologiques Observatoire Technologique Centre des Technologies de l’Information République et Canton de Genève Version 0.9 16 novembre 2003 Observatoire Technologique Centre des technologies de l’information République et Canton de Genève 9 route des Acacias CP 149, 1211 Genève 8 Suisse http://www.geneve.ch/ot/ [email protected]

Le Référentiel Nouvelles Plateformes Technologiques

Embed Size (px)

DESCRIPTION

L’Observatoire technologique a élaboré un outil générique d’analyse et d’évaluation de technologie, de systèmes ou de composants informatiques. Il permet d’une part une description de l’objet étudié en terme d’architecture et d’autre part une évaluation fine de cet objet selon une série de critères déterminés.

Citation preview

Page 1: Le Référentiel Nouvelles Plateformes Technologiques

Le Référentiel Nouvelles Plateformes Technologiques

Observatoire TechnologiqueCentre des Technologies de l’Information

République et Canton de Genève

Version 0.916 novembre 2003

Observatoire TechnologiqueCentre des technologies de l’informationRépublique et Canton de Genève9 route des AcaciasCP 149, 1211 Genève 8Suissehttp://www.geneve.ch/ot/[email protected]

Page 2: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Copyright c© 2003–2004 CTI, Observatoire Technologique.

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To viewa copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a let-ter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

You are free:

• to copy, distribute, display, and perform the work

• to make derivative works

Under the following conditions:

Attribution. You must give the original author credit.Noncommercial. You may not use this work for commercial purposes.Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting

work only under a license identical to this one.

• For any reuse or distribution, you must make clear to others the license terms of this work.

• Any of these conditions can be waived if you get permission from the author.

Your fair use and other rights are in no way affected by the above.

This is a human-readable summary of the Legal Code (the full license http://creativecommons.org/licenses/by-nc-sa/1.0/legalcode).

Observatoire Technologique 2

Page 3: Le Référentiel Nouvelles Plateformes Technologiques

Table des matières

I Introduction au Référentiel NPT 4

1 Introduction 5

1.1 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Objectifs du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 A qui s’adresse ce document . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Définitions, objectifs et utilisation du référentiel 8

2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Objectifs du référentiel NPT . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Applications envisagées pour le référentiel NPT . . . . . . . . . . . 10

2.2.2 Instrumentation du référentiel avec un outil d’aide à la décision . . . 12

3 Structure du référentiel 14

3.1 Les trois axes du référentiel . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Premier axe : les couches du système . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 Couche matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.2 Couche plate-forme inférieure . . . . . . . . . . . . . . . . . . . . . 16

3.2.3 Couche plate-forme supérieure . . . . . . . . . . . . . . . . . . . . . 16

3.2.4 Couche applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.5 Couche système d’information . . . . . . . . . . . . . . . . . . . . . 17

3.3 Deuxième axe : les tiers du système . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 Tiers client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.2 Tiers présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.3 Tiers métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.4 Tiers intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1

Page 4: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

3.3.5 Tiers ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Troisième axe : les dimensions du système . . . . . . . . . . . . . . . . . . 19

3.4.1 Organisation en ensembles, dimensions et sous-dimensions . . . . 19

II Le Référentiel NPT 21

4 Dimensions relatives aux Facteurs Humains 22

4.1 Aspects utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Valeur ajoutée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.2 Respect des besoins fonctionnels . . . . . . . . . . . . . . . . . . . 26

4.1.3 Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.4 Accessibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Aspects sociétaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Composante sociétale . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 Cadre légal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.3 Cadre éthique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Dimensions relatives aux Qualités Systémiques 45

5.1 Évolutivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1.1 Scalabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.2 Flexibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1.3 Portabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.4 Maturité de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2 Exploitabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.1 Maintenabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2.2 Contrôlabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3 Qualités de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3.1 Stabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.2 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3.4 Efficacité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.4 Interopérabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.4.1 Ouverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Observatoire Technologique 2

Page 5: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.4.2 Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6 Dimensions relatives à l’Organisation 86

6.1 Aspects économiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 Formation et Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.2.1 Utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.2.2 Informaticiens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7 Dimensions relatives à la sécurité 101

7.1 Gestion des politiques d’accès . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.1.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.1.2 Autorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.2 Contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7.2.1 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7.2.2 Non-répudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.2.3 Traçabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.3 Confidentialité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Observatoire Technologique 3

Page 6: Le Référentiel Nouvelles Plateformes Technologiques

Première partie

Introduction au Référentiel NPT

4

Page 7: Le Référentiel Nouvelles Plateformes Technologiques

Chapitre 1

Introduction

1.1 Résumé

Le référentiel Nouvelles Plateformes Technologiques (NPT) est un outil élaboré parl’Observatoire Technologique du CTI dans le but d’analyser une technologie, unsystème ou un composant informatiques. Il permet d’une part une description del’objet étudié en terme d’architecture et d’autre part une évaluation fine de cet objetselon une série de critères déterminés.

Ce document définit et présente les objectifs du référentiel NPT. Il illustre également l’ap-plication prévue pour le référentiel avec trois cas d’utilisation : (i) la description et l’éva-luation macroscopique du système informatique de l’État de Genève, (ii) la description etl’évaluation microscopique d’un composant du système informatique et (iii) la descriptionet l’évaluation d’une technologie ou d’un standard.

Le référentiel NPT est structuré selon trois axes et représenté graphiquement sous laforme d’un cube.1

Le premier axe permet de décomposer le système analysé en plusieurs couches : maté-riel, plate-forme inférieure, plate-forme supérieure, application et système d’information.Chaque couche définit un niveau d’abstraction supérieur par rapport à la couche infé-rieure.

Le deuxième axe permet de décomposer le système analysé en plusieurs tiers : client,présentation, métier, intégration et ressources. Les tiers reflètent la distribution des com-posants et des services au travers du réseau.

Le troisième axe permet d’évaluer le système analysé selon plusieurs dimensions. Lesdimensions du référentiel sont regroupées en quatre sous-ensembles. Les qualités rela-tives au facteur humain incluent les besoins des utilisateurs, la composante sociétale etl’évaluation des fournisseurs. Les qualités systémiques incluent l’évolutivité, les qualitésde service, l’exploitabilité, l’interopérabilité et la maturité du composant. Les dimensionsrelatives à l’organisation incluent les coûts, les compétences et la formation. Enfin, lesdimensions relatives à la sécurité incluent la gestion de politiques d’accès, le contrôle et

1Ce type de modèle est fondé sur l’analyse proposée notamment dans l’article de Joseph Williams, “Cor-rectly Assessing the ‘ilities’ Requires More than Marketing Hype”, IT Professional, IEEE Computer Society,Vol. 2, No. 6, novembre/décembre 2000.

5

Page 8: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

la confidentialité. Chacune des dimensions mentionnées est elle-même décomposée ensous-dimensions.

1.2 Objectifs du document

Dans un premier temps, les objectifs de ce document sont de définir le référentiel NPT(ainsi qu’un ensemble de notions y relatives), de décrire les objectifs de cet outil d’analyseet d’illustrer ces objectifs avec quelques cas d’utilisation envisagés. Les chapitres 2 et 3sont dédiées à ces objectifs.

Dans un deuxième temps, l’objectif principal de ce document est de présenter le référen-tiel NPT à proprement parler. Ce document décrit donc un ensemble de dimensions quidevraient être considérées lors de l’évaluation de systèmes et de composants informa-tiques. Ce document explique également comment chaque dimension peut être évaluéepar rapport à chaque couche et à chaque tiers de l’architecture du système. La partie IIest dédiée à cet objectif.

Le référentiel NPT est conçu pour intégrer des évolutions dynamiques et des change-ments. Les éléments qui le composent actuellement seront évalués sur la base des ex-périences pratiques de ses utilisateurs et des modifications pourront être apportées enfonction des retours d’expérience. Par ailleurs, il est également prévu d’intégrer toutenouvelle information externe ou interne qui permettra une amélioration du référentiel oude sa mise en œuvre.

1.3 Structure

Le document est organisé de la manière suivante :

• Le chapitre 2 propose un ensemble de définitions pour le référentiel NPT et pourdes concepts qui lui sont associés. Ce chapitre décrit également les objectifs du ré-férentiel et illustre ceux-ci au moyen de trois cas d’utilisation envisagés. Finalement,la possibilité d’instrumenter le référentiel à l’aide d’un outil d’analyse est brièvementdécrite.

• Le chapitre 3 décrit la structure tri-dimensionnelle du référentiel NPT. Les trois axesdu référentiel, c’est-à-dire les couches, les tiers et les dimensions, sont décrits etillustrés à l’aide d’exemples.

• La partie II est dédiée au référentiel à proprement parler. Le troisième axe du ré-férentiel (c’est-à-dire l’axe des dimensions) est décrit en détail. Chaque dimensionest définie et analysée en regard des deux premiers axes (c’est-à-dire en regarddes couches et des tiers).

1.4 A qui s’adresse ce document

Dans un premier temps, ce document s’adresse :

Observatoire Technologique 6

Page 9: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• à la Direction Générale du CTI ;

• aux membres du comité de pilotage du projet NPT ;

• au CAT ;

• aux divisions du CTI (maîtrises d’œuvre).

Dans un deuxième temps, il s’adresse également :

• aux Départements de l’État de Genève (maîtrises d’ouvrage) ;

• aux partenaires externes de l’État de Genève.

Observatoire Technologique 7

Page 10: Le Référentiel Nouvelles Plateformes Technologiques

Chapitre 2

Définitions, objectifs et utilisationdu référentiel

Dans ce chapitre, quelques définitions sont d’abord proposées, aussi bien pour le réfé-rentiel NPT que pour des concepts qui lui sont associés. Les objectifs du référentiel sontensuite énoncés et illustrés à l’aide de trois cas d’utilisation. Finalement, l’instrumentationdu référentiel au moyen d’un outil d’aide à la décision est brièvement décrite.

2.1 Définitions

Le référentiel NPT est défini de la manière suivante :

Définition 1 (Référentiel NPT)Le référentiel NPT est un outil d’analyse qui permet de décrire et d’évaluer l’architec-ture de systèmes et de composants informatiques. Dans un premier temps, le référentielest utilisé pour décrire le système analysé en le décomposant en couches et en tiers.Dans un deuxième temps, il est utilisé pour évaluer le système en fonction de plusieursdimensions. Cette approche est applicable aussi bien au niveau macroscopique (analysed’un système informatique global) qu’au niveau microscopique (analyse détaillée d’uncomposant du système informatique).

Cette définition met l’accent sur le concept d’architecture. Or, il n’existe pas de définitionunique pour terme. Ainsi, plusieurs dizaines de définition ont été compilées par le Soft-ware Engineering Institute (SEI) à l’Université de Carnegie Mellon1. Ces définitions sontproposées pour le concept d’architecture logicielle (software architecture). Elles peuventnéanmoins souvent être généralisées pour s’appliquer au concept plus général d’archi-tecture informatique. Deux définitions intéressantes sont celles proposées par Bass, Cle-ments et Kazman2, respectivement par Booch, Rumbaugh et Jacobson3.

1http://www.sei.cmu.edu/architecture/definitions.html2Software Architecture in Practice, Addison-Wesley, 19973The UML Modeling Language User Guide, Addison-Wesley, 1999

8

Page 11: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Définition 2 (Software Architecture d’après Bass, Clements et Kazman)The software architecture of a program or computing system is the structure or structuresof the system, which comprise software components, the externally visible properties ofthose components, and the relationships among them.By “externally visible” properties, we are referring to those assumptions other componentscan make of a component, such as its provided services, performance characteristics,fault handling, shared resource usage, and so on. The intent of this definition is that asoftware architecture must abstract away some information from the system (otherwisethere is no point looking at the architecture, we are simply viewing the entire system) andyet provide enough information to be a basis for analysis, decision making, and hencerisk reduction.

Définition 3 (Software Architecture d’après Booch, Rumbaugh et Jacobson)An architecture is the set of significant decisions about the organization of a softwaresystem, the selection of the structural elements and their interfaces by which the systemis composed, together with their behavior as specified in the collaborations among thoseelements, the composition of these structural and behavioral elements into progressivelylarger subsystems, and the architectural style that guides this organization—these ele-ments and their interfaces, their collaborations, and their composition (The UML ModelingLanguage User Guide, Addison-Wesley, 1999).

Dans le contexte du référentiel NPT, la définition suivante est retenue :

Définition 4 (Architecture de système informatique)L’architecture d’un système informatique définit l’organisation structurelle des compo-sants du système, les propriétés de ces composants ainsi que la manière dont ils in-teragissent.

La définition du référentiel NPT fait également ressortir le terme de système informatique,que l’on peut associer au terme de système d’information. Ces deux concepts sont définisde la manière suivante :

Définition 5 (Système d’information)Un système d’information est un système composé de personnes, de machines et deméthodes. Il est organisé pour collecter, traiter, stocker et transmettre de l’information.Les processus définis dans le cadre d’un système d’information peuvent être manuels ouautomatisés (par un système informatique).

Observatoire Technologique 9

Page 12: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Définition 6 (Système informatique)Un système informatique est la réalisation d’une partie d’un système d’information avecdes composants matériels et logiciels. Un système informatique permet d’automatiserune partie des processus définis dans le cadre d’un système d’information.

2.2 Objectifs du référentiel NPT

L’objectif principal du référentiel NPT est de fournir un cadre et une méthode pour la des-cription et l’évaluation de systèmes informatiques. L’outil n’a pas été conçu à l’intentiond’une division particulière du CTI. Au contraire, il est suffisamment générique pour êtreutile à l’ensemble des divisions du CTI ainsi qu’à d’autres entités internes ou partenairesde l’État de Genève.

L’analyse de systèmes informatiques peut se faire dans différents contextes : cartogra-phie du système informatique, sélection d’une application métier, choix d’une plate-formematérielle, définition du poste de travail, etc. Un des objectifs du référentiel est de propo-ser une approche unifiée pour aborder l’ensemble de ce problèmes.

Dans la mesure où le référentiel NPT était adopté par les différentes divisions du CTI, lamanière de documenter l’architecture de systèmes et de composants deviendrait com-mune. Il devrait en résulter une plus grande homogénéité et une facilité d’utilisation de ladocumentation.

2.2.1 Applications envisagées pour le référentiel NPT

Première utilisation : Description et évaluation macroscopique d’un système infor-matique

La première utilisation du référentiel NPT consiste à décrire le système informatique del’État de Genève à un niveau macroscopique, c’est-à-dire dans son ensemble.

Dans ce cas, l’objectif est de décrire les principaux composants du système, leurs quali-tés et leurs interactions. Les composants étudiés à ce niveau sont aussi bien les applica-tions métiers (les piliers du système d’information de l’État de Genève) que les compo-sants transversaux (portail, framework, SAN).

Dans ce type d’utilisation, le référentiel permet de créer plusieurs vues du système infor-matique. Ces vues peuvent, par exemple, faire ressortir les éléments suivants :

• La vision stratégique du système informatique, telle qu’elle est conçue et présentéepar la Direction générale.

• Une cartographie du système informatique, avec l’ensemble des applications mé-tiers et la manière dont celles-ci sont intégrées. Cette utilisation est notamment in-téressante pour étudier la manière dont les services développés avec le FrameworkCTI peuvent être partagés par différentes applications.

Observatoire Technologique 10

Page 13: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Les dépendances plus ou moins grandes entre les composants du système. Cetteanalyse permet par exemple de mettre en évidence des relations de dépendancevis à vis de certains fournisseurs.

• La manière dont les divisions et les groupes du CTI se partagent l’expertise et laresponsabilité par rapport à des parties du système informatique.

Deuxième utilisation : Description et évaluation d’une application métier

La deuxième utilisation du référentiel NPT consiste à décrire en détails un des compo-sants du système informatique de l’État de Genève. Typiquement, lors du choix d’uneapplication métier, le référentiel permet de comparer et d’évaluer un ensemble d’alterna-tives sur plusieurs dimensions.

FIG. 2.1 – Représentation d’un système en couches et en tiers.

Dans ce cas, les utilisateurs du référentiel sont la ou les personnes qui ont la responsabi-lité du choix de l’application. La méthode recommandée pour appliquer le référentiel estla suivante :

1. Les éléments structurels de l’architecture de chaque solution sont analysés et dé-crits en utilisant la structure du référentiel. Pour cela, chaque solution est décom-posée en plusieurs couches (du matériel au logiciel) et en plusieurs tiers (de laprésentation aux données). La section 3.4 décrit la structure du référentiel en dé-tails et fournit la liste complète des couches et des tiers.

2. En fonction des besoins, l’architecture des solutions est décrite textuellement et/ougraphiquement. Un tableau à deux dimensions, représentant les couches verticale-ment et les tiers horizontalement, est souvent très utile. Un exemple est illustré parla figure 2.1. Ce tableau décrit l’architecture d’une application métier. Le périmètrecouvert par l’architecture (par rapport à toutes les couches et à tous les tiers) estreprésenté par le rectangle jaune. Le schéma met également en évidence le fait

Observatoire Technologique 11

Page 14: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

que la solution est indépendante par rapport aux couches basses (il est donc pos-sible de remplacer l’OS et le matériel) et par rapport au tiers ressources (il est doncpossible de remplace la base de données).

3. Chaque solution est ensuite évaluée en regard des dimensions définie dans le ré-férentiel. En général, chaque dimension est évaluée par rapport à chaque coucheet à chaque tiers. Il arrive néanmoins qu’une dimension ne soit applicable qu’à unsous-ensemble de la structure.

Troisième utilisation : Description et évaluation d’une technologie ou d’un standard

La troisième utilisation envisagée pour le référentiel est celle du choix d’une technologieou d’un standard. Alors que l’utilisation précédente découlait d’un besoin des utilisateurs(choix d’une application métier), cette utilisation découle généralement d’un besoin plustransversal.

Dans ce cas, la première étape consiste à situer la technologie ou le standard étudié dansle cadre général du référentiel. Dans quelle(s) couche(s) la technologie se situe-t-elle ?Sur quel(s) tiers a-t-elle un impact ? A nouveau, les répondes à ces questions peuventêtre représentées graphiquement sous forme d’un tableau. Une fois la technologie situéepar rapport aux deux axes, il est plus facile d’identifier les personnes qui, au CTI, sont leplus à même de fournir des informations par rapport à la technologie.

Parfois, une technologie a également le potentiel de permettre une réorganisation dusystème informatique global. Par exemple, des technologies d’intégration comme lesconnecteurs JCA peuvent augmenter l’interopérabilité entre certaines applications mé-tiers. De telles propriétés peuvent également être représentées graphiquement en tirantparti des deux premiers axes du référentiel.

2.2.2 Instrumentation du référentiel avec un outil d’aide à la décision

La manière d’utiliser et d’appliquer le référentiel n’est pas définie strictement. Les utili-sateurs ont la liberté d’adapter l’outil à leurs besoins. Il est probable que des habitudesseront prises graduellement et évolueront dans le temps, en fonction de l’adoption duréférentiel par différentes personnes.

Une des possibilités proposées aux utilisateurs du référentiel NPT est d’instrumenter leréférentiel avec un outil d’aide à la décision. Une telle instrumentation est particulièrementintéressante lorsque le référentiel est utilisé pour choisir un composant parmi plusieursalternatives.

Par exemple, l’Observatoire Technologique a évalué et acquis des licences pour le logicield’aide à la décision multi-critères Web-HIPRE. Ce logiciel permet la définition de critèresd’évaluation (qui pourraient correspondre aux dimensions du référentiel NPT) et la pon-dération de ces critères. Les modèles ainsi définis sont représentés graphiquement etpeuvent manipulés interactivement. Un exemple d’écran du logiciel est représenté dansla Figure 2.2.

Observatoire Technologique 12

Page 15: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

FIG. 2.2 – Capture d’écran du logiciel Web-HIPRE.

Observatoire Technologique 13

Page 16: Le Référentiel Nouvelles Plateformes Technologiques

Chapitre 3

Structure du référentiel

Dans le chapitre 2, les objectifs du référentiel NPT ont été présentés et illustrés partrois types d’utilisation envisagés. La discussion a brièvement mentionné le fait que leréférentiel était structuré selon trois axes : celui des couches, celui des tiers et celui desdimensions. Ce chapitre décrit la structure du référentiel et chacun des axes en détails.

3.1 Les trois axes du référentiel

Le référentiel NPT est organisé sur trois axes et peut donc être représenté graphiquementsous la forme d’un cube. Le premier axe est utilisé pour décomposer le système encouches. Le deuxième axe est utilisé pour décomposer le système en tiers (dans le sensd’une architecture multi-tiers). Le troisième axe est utilisé pour évaluer le système entenant compte d’un ensemble de dimensions.

Décrire et évaluer un système à l’aide du référentiel NPT se fait généralement en deuxétapes :

1. Au cours de la première étape, le système est décrit en fonction des couches et destiers du référentiel. Cette étape permet donc de situer le système dans les limitesdu cube représenté à la figure 3.1.

2. Au cours de la deuxième étape, le système est évalué en fonction des dimensionsénumérées sur le troisième axe du référentiel. Les dimensions sont orthogonalesaux couches et au tiers. Lorsqu’une dimension est évaluée, il convient par consé-quent d’analyser la manière dont elle s’appliquer à chaque couche et à chaque tiersdu système.

Les paragraphes suivants décrivent les couches, les tiers et les dimensions qui ont étéretenues lors de la conception du référentiel NPT.

14

Page 17: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

FIG. 3.1 – Représentation d’un système en couches, en tiers et en dimensions.

3.2 Premier axe : les couches du système

Le premier axe du référentiel permet de décomposer un système en couches. Il s’agit làd’une décomposition classique dans l’analyse et la conception de système informatiques.

Chaque couche introduit un niveau d’abstraction supplémentaire par rapport à la coucheinférieure. Les couches sont indépendantes les unes des autres et communiquent autravers d’interfaces.

Dans certains cas, les interfaces sont spécifiées par des standards ouverts (par exemple,la plate-forme J2EE est un standard ouvert pour la couche “plate-forme supérieure”).Dans ce cas, il est possible de choisir n’importe quelle implémentation du standard. Plusimportant, il est possible de remplacer ultérieurement cette implémentation par une autre,sans impact sur les composants des autres couches.

Dans d’autres cas, l’interface offerte par une couche est propriétaire. Dans ce cas, ilest possible que seul un fournisseur fournisse une implémentation de la couche. Cettesituation crée une relation de dépendance vis à vis du fournisseur. En effet, remplacerla couche revient à changer l’interface et oblige donc à modifier les composants de lacouche supérieure. Un exemple est une application développée directement au-dessusdu système d’exploitation, qui doit être réécrite si le système d’exploitation change.

3.2.1 Couche matériel

Dans la couche du matériel, on trouve les composants physiques tels que les serveurs etles composants réseau.

Observatoire Technologique 15

Page 18: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Lorsque le référentiel est utilisé pour décrire le système informatique dans son ensemble,cette couche est utilisée pour décrire le type de matériel qui est utilisé. Cette analysepermet de mettre en évidence la variété plus ou moins grande des composants, aussibien du côté client que du côté serveur.

Lorsque le référentiel est utilisé pour décrire une application métier particulière, et mêmesi cette application est exclusivement composée d’éléments logiciels, la couche du ma-tériel doit quand même être étudiée. En effet, plusieurs questions intéressantes peuventse poser à ce niveau, par exemple :

• Quels types de ressources sont-elles requises par la solution ? (par exemple quelssont les types de processeurs supportés ?)

• Ce type de ressources est-il en adéquation avec les standards définis par le CTI ?

• La solution considérée est-elle indépendante de la couche matérielle ou révèle-t-elle une situation de dépendance par rapport à un constructeur particulier ?

• Quels sont les besoins de la solution en termes quantitatifs ? (processeur, mémoire,bande passante)

3.2.2 Couche plate-forme inférieure

La couche de la plate-forme inférieure se situe au dessus de la couche du matériel etoffre un premier niveau d’abstraction.

Les composants qui se situent dans cette couche sont principalement le système d’ex-ploitation et les composants logiciels de bas niveau (par exemple pile TCP/IP, pilotes depériphériques).

Il est possible de concevoir des plate-formes inférieures équivalentes (c’est-à-dire of-frant la même interface aux couches supérieures) au dessus de couches matériellesdifférentes. Par exemple, le même système d’exploitation peut être disponible sur desarchitectures matérielles différentes.

3.2.3 Couche plate-forme supérieure

Au dessus de la plate-forme inférieure se trouve la plate-forme supérieure. L’objectif decette couche est d’augmenter la portabilité des composants en ajoutant un niveau d’abs-traction entre le système d’exploitation et les applications.

Deux implémentations de la même plate-forme supérieure peuvent être mises en œuvreau dessus de systèmes d’exploitation différents. Dans la mesure où les composants ap-plicatifs ne communiquent pas directement avec la plate-forme inférieure, mais unique-ment au travers de la plate-forme supérieure, il est possible de remplacer le systèmed’exploitation sans impact majeur.

Java est un bon exemple de plate-forme supérieure. Java spécifie en effet un environne-ment d’exécution (JVM et librairies) qui est indépendant du système d’exploitation. Lesapplications développées en Java sont portables de manière tout à fait transparente. Le

Observatoire Technologique 16

Page 19: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

concept de plate-forme supérieure s’applique aux trois éditions de la plate-forme Java 2(J2EE, J2SE, J2ME).

3.2.4 Couche applications

La couche des applications héberge les composants logiciels qui implémentent la logiquede présentation, de traitement et d’accès aux données pour les services déployés parl’organisation.

C’est dans cette couche que la connaissance métier est encapsulée dans des compo-sants logiciels. C’est donc dans cette couche que se situe la plus grande valeur du sys-tème informatique.

Pour cette raison, la pérennité des composants développés à ce niveau est cruciale. Unebonne manière d’augmenter cette pérennité est de rendre la couche application la plusindépendante possible des couches inférieures. Pour cela, la première règle à suivre estde communiquer uniquement avec la couche directement inférieure (plate-forme supé-rieure), et privilégier un standard ouvert pour cette couche (par exemple J2EE). Celagarantit une indépendance vis à vis de tout fournisseur et permet de continuer à utili-ser les composants applicatifs même lorsque le matériel, le système d’exploitation ou leserveur d’applications est remplacé.

3.2.5 Couche système d’information

La couche la plus abstraite du référentiel est appelée couche du système d’information.Dans cette couche, les services applicatifs fournis par la couche inférieure sont intégréset utilisés au travers d’un workflow.

3.3 Deuxième axe : les tiers du système

Le deuxième axe du référentiel NPT est utilisé pour décomposer un système en plusieurstiers, ce qui est particulièrement utile pour des applications distribuées (et donc pourcelles développées avec le Framework CTI).

Chaque tiers peut être hébergé par un nœud différent sur le réseau, mais cela n’estpas une obligation. Ainsi, s’il est possible de déployer une application multi-tiers sur cinqmachines différentes, il est également possible de déployer la même application sur uneseule machine. L’architecture de l’application reste la même.

Le principe d’architecture multi-tiers est aujourd’hui largement accepté et a été rendupopulaire par des technologies telles que CORBA, J2EE et .NET. Néanmoins, il existeplusieurs variantes de cette architecture, par exemple :

• l’architecture 3-tiers, qui répartit les composants d’une application distribuées parmiles tiers suivants : (1) le tiers de présentation, qui gère l’interface avec les utilisa-teurs, (2) le tiers de logique métier, qui encapsule des règles de gestion et (3) le

Observatoire Technologique 17

Page 20: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

tiers de données, qui prend en charge le stockage des informations. Il faut releverque la documentation du Framework CTI fait référence à une architecture 3-tiers.

• l’architecture 5-tiers, qui est particulièrement adapté à des applications Web etmulti-canaux. Cette architecture est une extension de la précédente et intègre lestiers suivants : (1) le tiers client, (2) le tiers de présentation, (3) le tiers métier, (4) letiers intégration et (5) le tiers ressources. Le référentiel NPT est conçu sur la basede ce modèle. Les tiers sont donc décrits en détails en les paragraphes suivants.

La communication entre les tiers se fait également au travers d’interfaces. Idéalement,les composants déployés dans un tiers ne devraient communiquer qu’avec le tiers voisin.Par exemple (dans une architecture 3-tiers), un composant du tiers de présentation nedevrait pas accéder directement à la base de données. Au contraire, il devrait obligatoire-ment passer par le tiers métier. Ce découplage présente plusieurs avantages et permeten particulier de remplacer les composants d’un tiers sans avoir un impact sur tout lesystème.

3.3.1 Tiers client

Le tiers client héberge les composants avec lesquels les utilisateurs ont une interactiondirecte. Comme les autres tiers, le tiers client est orthogonal aux couches du système.On trouve donc des composants qui sont à la fois dans le tiers client et dans la couchedu matériel (par exemple un ordinateur de bureau ou un téléphone), d’autres qui sont àla fois dans le tiers client et dans la couche des applications (par exemple une page Webqui permet de consulter un annuaire).

La conception des composants du tiers client peut se faire avec une des deux approchessuivantes : celle dite du “client lourd” (c’est-à-dire les composants sont intégrés sous laforme d’une application indépendante) et celle dit du “client léger” (c’est-à-dire les com-posants, en particulier les pages HTML, sont hébergés et présentés par un navigateurweb).

Il faut relever que pour le même service applicatif (par exemple un service d’accès àun annuaire), plusieurs interfaces peuvent être développées. La création de plusieurscanaux d’accès est facilitée par le découpage en tiers.

3.3.2 Tiers présentation

Le tiers de présentation est particulièrement pertinent pour les applications Web. Lescomposants hébergés dans ce tiers génèrent l’interface utilisateur (typiquement dans unlangage de markup) qui est transmise et affichée par les composants du tiers client.

Dans un contexte J2EE, un container Web ainsi que les servlets pages JSP qu’il hébergesont des composants du tiers de présentation. Suite à des requêtes HTTP, ces compo-sants génèrent un flux (HTML, XML, binaire, etc.) qui est transmis au navigateur Web dutiers client.

Observatoire Technologique 18

Page 21: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

3.3.3 Tiers métier

Le tiers métier héberge les composants qui encapsulent la logique métier, ainsi que leséléments qui offrent un environnement d’exécution aux composants métier.

Les composants développés dans ce tiers ont une très grande valeur, puisqu’ils implé-mentent la connaissance métier de l’organisation. A nouveau, pour garantir la pérennitéde ces composants, il est important de les rendre indépendants d’un mode de présen-tation et d’un mode de persistance particuliers. Le découplage entre les tiers permetd’atteindre cet objectif.

Dans un contexte J2EE, un container EJB ainsi que les EJB qu’il héberge sont des com-posants du tiers métier.

3.3.4 Tiers intégration

Le tiers d’intégration héberge des composants qui supportent l’interaction entre des com-posants métiers et des gestionnaires de ressources. Un middleware orienté messages,un driver JDBC ou un connecteur JCA sont des exemples de tels composants.

3.3.5 Tiers ressources

Le tiers ressources héberge les composants comme les bases de données, les an-nuaires, etc. Le rôle de ces composants est de gérer la persistance des données utiliséespar les services du tiers métier.

Dans ce contexte, le découplage entre les tiers ressources et métier permet de remplacerune base de données par une autre, sans que les services applicatifs ne subissent unimpact.

3.4 Troisième axe : les dimensions du système

Le troisième axe du référentiel est celui qui guide l’évaluation d’un système, préalable-ment décrit en fonction des deux premiers axes. Le troisième axe est constitué d’un en-semble de dimensions, qui déterminent les critères d’évaluation pour un système. Lesdimensions couvrent un spectre assez large et ne se limitent pas à des considérationtechniques.

3.4.1 Organisation en ensembles, dimensions et sous-dimensions

Pour faciliter l’utilisation du référentiel, les dimensions en été organisées sur trois niveauxhiérarchiques :

• sur le premier niveau, quatre grands ensembles de dimensions sont proposés ;

• sur le deuxième niveau, chaque ensemble est composé d’une liste de dimensions ;

Observatoire Technologique 19

Page 22: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• sur le troisième niveau, chaque dimension est elle-même décomposée en sous-dimensions (si nécessaire).

Le tableau suivant présente les ensembles, les dimensions et les sous-dimensions demanière synoptique :

Ensembles Dimensions Sous-dimensionsFacteurs Humains

Aspects utilisateurs Valeur ajoutéeRespect des besoins fonctionnelsErgonomieAccessibilité

Aspects sociétaux Composante sociétalCadre légalCadre éthique

Qualités SystémiquesEvolutivité Scalabilité

FlexibilitéPortabilitéMaturité de la solution

Exploitabilité MaintenabilitéContrôlabilité

Qualités de service StabilitéDisponibilitéPerformanceEfficacité

Interopérabilité OuvertureStandardisation

OrganisationAspects économiquesFormation et organisation Utilisateurs

InformaticiensSécurité

Gestion des politiques d’accès AuthentificationAutorisation

Contrôle IntégritéNon-répudiationTraçabilité

Confidentialité

Observatoire Technologique 20

Page 23: Le Référentiel Nouvelles Plateformes Technologiques

Deuxième partie

Le Référentiel NPT

21

Page 24: Le Référentiel Nouvelles Plateformes Technologiques

Chapitre 4

Dimensions relatives aux FacteursHumains

Les dimensions Aspects utilisateurs et Aspects sociétaux ont été regroupées sous le la-bel commun Dimensions relatives aux facteurs humains. Ces dimensions, ainsi que lessous-dimensions correspondantes prennent en compte les aspects touchant très direc-tement les utilisateurs et de manière plus générale l’e-Société. Certains de ces domainessont souvent négligés lors de l’étude d’une technologie ou d’un composant informatiquealors qu’ils y jouent un rôle important en terme d’adoption et d’utilisation notamment.

22

Page 25: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.1 Aspects utilisateurs

Révisions

Version Date / auteurs Objet de la révision0.1 2003-10-03 / pge Version initiale

Description

La dimension Aspects utilisateurs permet d’analyser les propriétés d’une technologie oud’un composant informatique en terme de valeur ajoutée, de besoins fonctionnels, d’er-gonomie et d’accessibilité. Elle mesure la prise en compte de la composante humaine,du point de vue utilisateur notamment, dans la conception et/ou la mise en œuvre d’unsystème.

Sous-dimensions

• Valeur ajoutée : mesure la valeur ajoutée pour l’utilisateur, pour le service ou pourl’institution concernés.

• Besoins fonctionnels : estime dans quelle mesure les besoins fonctionnels sontcouverts.

• Ergonomie : estime dans quelle mesure l’ergonomie de la solution est satisfai-sante.

• Accessibilité : mesure la facilité d’accès à une technologie pour les utilisateursprésentant un handicap.

Observatoire Technologique 23

Page 26: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.1.1 Valeur ajoutée

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-29 / pge Version initiale

Description

Cette dimension vise à estimer la valeur ajoutée, pour l’utilisateur, le service ou l’institu-tion concernés, par la technologie ou le composant informatique étudiés. Il s’agit égale-ment de déterminer la contribution positive pouvant être apportée à la synergie entre lesdifférents acteurs impliqués.

La notion de valeur ajoutée ne fait naturellement pas ici référence à un quelconque gainfinancier. Mais elle y est malgré tout fortement liée : outre les aspects techniques, il ya en effet toujours lieu de mettre en balance la valeur ajoutée de la solution avec soncoût ainsi qu’avec les risques qui y sont associés (voir dimension Economie). La valeurajoutée est difficile à mesurer et son estimation reste la plupart du temps qualitative.

Dans le cadre d’une administration, la valeur ajoutée correspond avant tout à l’identifica-tion d’un véritable bénéfice pour l’utilisateur et passe avant tout par une formulation desbesoins en terme de finalité : on pense par exemple à la mise à disposition d’un servicesupplémentaire, à la réduction du temps d’exécution d’une tâche ou à l’obtention d’unrésultat de qualité supérieure à l’existant.

Couches et tiers concernés

Une déclinaison de la notion de valeur ajoutée en fonction des couches ou des tiersconcernés n’est pas faite ici.

Risques

Un projet de mise en oeuvre d’une technologique ou d’un composant informatique qui nepeut pas faire preuve d’une réelle valeur ajoutée a peu de chances d’être accepté. Onrisque également de s’engager dans une logique de fuite en avant technologique danslaquelle la technologie est une fin en soi. A terme, le risque est de mettre en évidence uneproductivité faible pour des technologies ayant été en oeuvre sans réelle valeur ajoutée.

Mesures

• La solution envisagée répond-elle à un besoin avéré ou n’est-elle que le reflet d’unphénomène de mode ou d’une pression commerciale ?

• Cette solution offre-t-elle un service supplémentaire ou de qualité supérieure àl’existant ?

Observatoire Technologique 24

Page 27: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• La réponse au problème posé est-elle nécessairement d’ordre technique ou tech-nologique ?

• Une réorganistion ou une refonte des processus ne répondent-elles pas mieux auproblème posé ?

Aspects métier

Compétence

• Maîtrise d’ouvrage

• Maîtrise d’oeuvre

• Commission de Gestion du Portefeuille des Projets (CGPP)

Observatoire Technologique 25

Page 28: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.1.2 Respect des besoins fonctionnels

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-30 / pge Version initiale

Description

L’utilisateur final d’un système n’est satisfait que si celui-ci répond à des contraintes fonc-tionnelles et opérationnelles initialement fixées. Dans cette optique, il est impératif deprendre en compte les besoins et les attentes des usagers le plus en amont possibledans le processus de mise en oeuvre d’une technologie (dans le processus d’assurancequalité par exemple).

Mais cette démarche indispensable doit cependant veiller à différencier ce qui est sol-licité par les utilisateurs de ce qui leur est réellement nécessaire. En effet les attentesdes usagers ne correspondent pas forcément à ce dont ils ont effectivement besoin, dela même façon que ce qui leur est initialement proposé dans un projet ne concorde pasnécessairement avec leurs attentes. Le but de la démarche est donc de mettre en adé-quation ces deux ensembles. Cela exige d’associer les utilisateurs aux différentes étapesde validation du projet, ceci afin de traduire le plus efficacement possible leurs attentesdans le produit final.

L’Agence pour le Développement de l’Administration Electronqiue (ADAE - France) a pu-blié à ce sujet un guide méthodologique richement documenté et très instructif à l’inten-tion des maîtres d’ouvrage qui traite de tous les aspects du problème (voir Références).Les démarches suggérées sont schématisées dans le diagramme ci-dessous.

AFB : analyse fonctionnelle du besoin (sert à exprimer les attentes etles besoins de l’utilisateur). AFP : analyse fonctionnelle du produit (sertà définir une solution jugée la mieux adaptée à satisfaire les besoins ex-primés). AV : analyse de la valeur (sert à optimiser, selon une approchetechnico-économique, la solution qui sera retenue).

Observatoire Technologique 26

Page 29: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Couches et tiers concernés

Une déclinaison de la prise en compte des besoins fonctionnels en fonction des couchesou des tiers concernés n’est pas faite ici.

Risques

Une solution ne répondant pas aux besoins fonctionnels exprimés par les utilisateursrisque de compromettre la viabilité du projet.

Mesures

• La solution étudiée répond-elle aux besoins fonctionnels sollicités par les utilisa-teurs ?

• Les besoins fonctionnels sollicités ont-ils été pris en compte en amont du projet ?

• Un équilibre entre les besoins fonctionnels sollicités par les utilisateurs et les be-soins réellement nécessaires a-t-elle été mesurée ?

Aspects métier

Compétence

• Maîtrise d’ouvrage

• Maîtrise d’oeuvre

Références

Guide méthodologique pour les maîtres d’ouvrage de service en ligne, ADAE, 19 avril2002 : http://www.adae.pm.gouv.fr/spip/article.php3?id_article=80

Observatoire Technologique 27

Page 30: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.1.3 Ergonomie

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-30 / pge Version initiale

Description

Ergonomie : science du travail (du grec ergon (travail) et nomos (loi, règles))

L’ergonomie est la capacité d’un système à être utilisé par un individu. Elle est la re-cherche d’une meilleure adaptation possible entre fonction, matériel et utilisateurs. Cedernier attend en effet un outil qui lui permette d’accomplir la tâche souhaitée (correspon-dant aux besoins fonctionnels) de la manière la plus efficace et la plus agréable possible,garante d’un haut niveau de productivité.

Une bonne ergonomie est très importante pour l’utilisateur. Elle englobe à la fois lesnotions de performance dans la réalisation des tâches, de satisfaction que procure l’utili-sation du système et de facilité avec laquelle on apprend à s’en servir. L’ergonomie sertà poser la frontière entre l’utilité potentielle (idéale) et l’utilité réelle d’une solution : unefois les besoins fonctionnels identifiés, ils doivent être traduits dans l’essence même duprojet, mais également au travers de son interface utilisateur. L’ergonomie est un fac-teur important de productivité et de qualité de l’atmosphère de travail. Il est souhaitablede pouvoir la prendre en compte en amont de la conduite de projet et d’y associer lesutilisateurs dans la plus large mesure possible.

L’ergonomie fait généralement référence aux concepts suivants :

• Facilité d’apprentissage et d’utilisation.

• Efficacité d’utilisation (simple, intuitif, uniforme, prévisible).

• Facilité de mémorisation du fonctionnement du système.

• Utilisation sans erreurs.

• Satisfaction des utilisateurs.

On peut analyser l’ergonomie d’un système selon une série de variables mesurables(taux d’erreurs, durée d’exécution d’une tâche, facilité de rétention dans le temps, de-mandes d’aide, durée d’apprentissage, etc.) et subjectives (esthétique, confort, préfé-rences, etc.).

Le cas particulier de l’accessibilité est un domaine important lié à la notion d’ergonomie.Il est traité à part dans la sous-dimension correspondante.

Couches concernées

• Application. Dans cette couche, c’est de l’ergonomie de l’interface utilisateur dont ilfaut se préoccuper. Les notions de documentation et d’aide en ligne sont tout aussiprimordiales.

Observatoire Technologique 28

Page 31: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Plateforme supérieure. Idem couche Application.

• Plateforme inférieure. C’est au niveau de l’interface graphique du système d’exploi-tation que l’on va juger principalement de l’ergonomie de ce dernier.

• Matériel. Dans cette couche, on s’intéresse à l’ergonomie du matériel en contactavec l’utilisateur (PC, périphériques, bornes interactives, etc.).

Tiers concernés

• Client. La notion d’ergonomie n’est pertinente qu’au niveau des tiers client et pré-sentation. Dans le tiers client, ce sont les interfaces utilisateurs des applicationsqui sont principalement concernés. La mise en place d’une charte graphique (en-semble de contraintes stylistiques et visuelles de l’interface) devrait être envisagéeà ce niveau.

• Présentation. Idem tiers client.

Risques

Un système dont l’ergonomie est faible peut drastiquement réduire la productivité desutilisateurs. Dans les cas extrêmes on risque un rejet de la solution par les utilisateurs.

Mesures

• L’ergonomie a-t-elle été prise en compte dans les spécifications du système ?

• L’ergonomie de la solution étudiée est elle acceptable ?

• Les utilisateurs ont-ils été associées à la mise en oeuvre du projet étudié ?

• Des informations sur les caractéristiques et comportements des futurs utilisateursont-elles été recueillies ?

Aspects métier

Compétence

• DTD

• Maîtrise d’oeuvre

• Maîtrise d’ouvrage

Divers

Pour plus d’informations relatives à la notion d’ergonomie, qui est un domaine très vasteet qui peut être un métier en soit, on peut se référer avantageusement aux liens présentésdans la section Références ci-dessous.

Observatoire Technologique 29

Page 32: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Références

Apple. Directives de développement d’interfaces utilisateurs. http://developer.apple.com/documentation/UserExperience/

Usabilis. Méthodes de conception ergonomique. http://www.usabilis.com/pratique/methode.htm

Ergoline. Liens et définitions relatifs à l’ergonomie. http://membres.lycos.fr/ergoline/IHMWeb.htm

IHO. Associations, liens et définitions relatifs à l’ergonomie. http://charlie.dgrc.crc.ca/~sylvie/hf_f_links.html

David Manise. Introduction à l’ergonomie du Web. http://davidmanise.com/ergonomie/index.php

Usability First. Introduciton à l’ergonomie (en anglais). http://www.usabilityfirst.com/index.txl

Observatoire Technologique 30

Page 33: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.1.4 Accessibilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-27 / pge Version initiale

Description

La vision de l’Etat de Genève dans le domaine des technologies de l’information et dela communication (TIC) met en avant les notions d’intégration et de cyber-inclusion. Celapasse notamment par la prise en compte de l’accessibilité aux solutions informatiquesmises en oeuvre. Plusieurs raisons (juridiques, économiques, sociales et morales no-tamment) militent en faveur d’un accès facilité aux TIC pour les personnes souffrantd’un handicap. Les besoins de ces personnes ne sont souvent pas considérés lors dela conception de systèmes informatiques. Les problèmes d’accessibilité pourraient ce-pendant être résolus dans une large mesure grâce à une prise en compte appropriée, enamont de la mise en oeuvre d’une technologie.

On présente souvent la notion d’accessibilité comme une déclinaison particulière de lanotion d’ergonomie (voir sous-dimension correspondante) pour la catégorie particulièred’utilisateurs que sont les personnes handicapées. Il faut d’ailleurs étendre cette caté-gorie plus largement, par exemple aux personnes âgées ou à celles maîtrisant mal lalecture ou la langue en vigueur.

Les quatre principales catégories de handicap sont les handicaps visuels, auditifs, demobilité et cognitifs, qui présentent des besoins différents en terme d’accessibilité :

• Handicaps visuels. Les personnes aveugles ou malvoyantes doivent pouvoir ac-céder aux documents électroniques et aux applications avec les dispositifs d’as-sistance qu’elles utilisent habituellement. Les personnes daltoniennes doivent parexemple pouvoir bénéficier de feuilles de style adaptées.

• Handicaps auditifs. Les personnes sourdes devraient par exemple pouvoir utiliserles sous-titres des éléments audio d’un fichier multimédia.

• Handicaps de mobilité. Les personnes à mobilité réduite éprouvent des difficultésà utiliser certains dispositifs d’entrée/sortie (clavier, souris) ou à manipuler certainsdispositifs de stockage.

• Handicaps cognitifs. Une conception consistante des interfaces utilisateurs et unlangage simplifié favoriseraient l’utilisation des TIC pour ce type d’utilisateur.

Chaque personne handicapée rencontre donc des barrières lorsqu’elle désire accéderaux TIC. Ces barrières peuvent être éliminées ou minimisées au niveau du développe-ment des applications, du navigateur, des technologies d’assistance, ou des systèmesd’exploitation et des plateformes matérielles sous-jacents.

Dans ce contexte, l’accessibilité mesure la facilité d’accès à la technologie étudiée pourles utilisateurs présentant un handicap quel qu’il soit.

Observatoire Technologique 31

Page 34: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Couches concernées

• Application. Dans cette couche, ce sont les interfaces utilisateurs des applicationsqui sont principalement concernés. L’accessibilité est ici d’autant plus importantequ’elle concerne des applications Web mises à disposition des citoyens.

• Plateforme inférieure. C’est au niveau de l’interface graphique du système d’exploi-tation que l’on va surtout juger de l’accessibilité de ce dernier.

• Matériel. On s’intéresse ici aux technologies favorisant l’accessibilité comme parexemple les supports d’interfaces qui traduisent l’information visuelle en un mes-sage tactile (ligne braille) ou auditif (synthèse vocale). Certains constructeurs pro-posent des produits conçus avec un souci marqué d’accessibilité (écrans tactiles,souris, claviers, etc.).

Tiers concernés

• Client. La notion d’accessibilité n’est pertinente qu’au niveau des tiers client et pré-sentation. Dans le tiers client, ce sont les interfaces utilisateurs des applicationsqui sont principalement concernés. L’accessibilité est ici d’autant plus importantequ’elle concerne des applications Web mises à disposition des citoyens. Une sépa-ration claire entre le contenu, la structure et la présentation d’un document permetune prise en compte plus efficace de l’accessibilité.

• Présentation. Idem tiers client.

Risques

Si cette dimension n’est pas prise en compte, on risque de choisir ou de concevoir unsystème qui ne pourra pas être exploité valablement par tous les utilisateurs potentiels.Ceci est tout particulièrement vrai pour des systèmes au contact direct d’un large éventaild’utilisateurs ou de citoyens (système de messagerie, suite bureautique ou portail parexemple).

Mesures

• L’accessibilité a-t-elle été prise en compte dans les spécifications du système ?

• Les pages Web répondent-ils aux critères du WAI en terme d’accessibilité ?

• Les interfaces utilisateurs sont-ils accessibles aux personnes handicapées ?

• Le matériel choisi inclut-il ou supporte-t-il des dispositifs d’assistance aux per-sonnes handicapées ?

• Des personnes handicapées ont-elles été associées à la mise en oeuvre des projetstournés vers le citoyen ?

Observatoire Technologique 32

Page 35: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Aspects métier

Compétence

• DTD

• Maîtrise d’ouvrage

• Maîtrise d’oeuvre

Divers

Une bonne introduction à cette problématique est présentée sur le site de la Web Ac-cessibility Initiative (WAI), émanation du W3C pour une meilleure accessibilité aux sitesWeb. De nombreux fournisseurs informatiques et de communautés Open Source ontégalement intégré l’accessibilité aux technologies dans leurs réflexions. Les sites cor-respondants proposent des guides utiles sur la question (accessibilité applicative, Web,Java, matérielle, etc...). D’autre part il existe un certain nombre d’outils de validation quipermettent d’automatiser une partie du processus de tests d’un site Web en terme d’ac-cessibilité. La section Références propose plusieurs liens vers certains de ces projetsainsi que vers des institutions académiques et des associations oeuvrant dans ce do-maine. Mentionnons surtout les sites Trace Center de l’Université du Wisconsin et UIAccess qui couvrent très largement le sujet.

Références

Organismes de standardisation

Web Accessibility Initiative (WAI) : http://www.w3.org/WAI/

Checklist WAI : http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html

Références WAI : http://www.w3.org/WAI/References/

Directives W3C : http://www.w3.org/TR/WCAG/

Sites académiques et associatifs

Trace Center, Université du Wisconsin : http://www.tracecenter.org/

Usability SIG : http://www.stcsig.org/usability/

UI Access : http://www.uiaccess.com/index.html

Accès pour tous : http://www.access-for-all.ch/new/f_index.html

BrailleNet : http://www.braillenet.org/

Voir Plus : http://www.voirplus.net/

Web sourd : http://www.educ-pop.org/303

Projets d’accessibilité du monde Open Source

Observatoire Technologique 33

Page 36: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

KDE accessibility project : http://accessibility.kde.org/

GNOME accessibility project : http://developer.gnome.org/projects/gap/

Mozilla accessibility project : http://www.mozilla.org/projects/ui/accessibility/

Projets d’accessibilité des quelques grands fournisseurs informatiques

IBM : http://www-3.ibm.com/able/

Apple : http://developer.apple.com/documentation/Accessibility/Accessibility.html

Microsoft : http://www.microsoft.com/enable/

Sun Microsystems. http://www.sun.com/access/

Java-Sun : http://java.sun.com/products/jfc/accessibility.html

Outils de validation d’accessibilité

Service de validation CSS du W3C : http://jigsaw.w3.org/css-validator/

Bobby : http://bobby.watchfire.com/bobby/

Lynx : http://www.delorie.com/web/lynxview.html

Observatoire Technologique 34

Page 37: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.2 Aspects sociétaux

Révisions

Version Date / auteurs Objet de la révision0.1 2003-10-03 / pge Version initiale

Description

La dimension Aspects sociétaux vise à estimer la valeur ajoutée apportée à la sociétépar une technologie ou un composant informatique. Il s’agit également de déterminer lacontribution à la synergie entre l’Etat, la société civile et le secteur privé. Un dernier butest enfin d’estimer dans quelle mesure les cadres éthiques et légaux sont respectés.

Sous-dimensions

• Composante sociétale : estime la valeur ajoutée apportée à la société civile, auxcitoyens, au secteur privé ou aux différentes communautés d’intérêt par la techno-logie ou le projet informatique étudié.

• Cadre légal : estime dans quelle mesure la technologie ou le projet informatiqueétudiés respectent le cadre légal correspondant.

• Cadre éthique : estime dans quelle mesure la technologie ou le projet informatiqueétudiés respectent les critères éthiques correspondants.

Risques

Voir sous-dimensions correspondantes.

Mesures

La mesure de la dimension Société est une agrégation des mesures des sous-dimensionscorrespondantes.

Observatoire Technologique 35

Page 38: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.2.1 Composante sociétale

Révisions

Version Date / auteurs Objet de la révision0.1 2003-08-18 / pge version initiale

Description

Cette dimension vise à estimer la valeur ajoutée apportée à la société civile, aux citoyens,au secteur privé ou aux différentes communautés d’intérêt par la technologie ou le projetinformatique étudié. Il s’agit également de déterminer la contribution positive qui peutainsi être apportée à la synergie entre les différents acteurs ci-dessus.

La notion de valeur ajoutée ne fait naturellement pas ici référence à un quelconque gainfinancier. Elle correspond à un véritable bénéfice citoyen induit directement ou indirec-tement par la mise en oeuvre de la technologie ou du composant informatique étudiés.Cette notion de valeur ajoutée est naturellement très qualitative mais il ne faut pas pourautant la perdre de vue.

A titre d’exemple, on peut considérer que l’adoption à large échelle du logiciel libre ausein de l’administration peut apporter une valeur ajoutée appréciable à la société civile.Une orientation stratégique de ce type est en effet succeptible d’une part de promouvoirl’émergence d’une économie locale liée au développement de logiciels libres et d’autrepart de favoriser les notions de transparence et de droit à l’information pour les citoyens.

Les contraintes liées aux agendas politiques peuvent également avoir une influence no-table sur la mise en oeuvre ou non d’une technologie ou d’un composant informatique.Ces aspects sont particulièrement importants dans le cadre d’une administration qui doitjustifier ses choix au niveau politique.

On peut se réferrer notamment aux objectifs de l’Etat de Genève en matière de dévelop-pement durable (Agenda21 local, voir Références). L’article 1 de la loi 8365 sur l’actionpublique en vue d’un développement durable A 2 60 dit en effet (voir Références) :

1. L’ensemble des activités des pouvoirs publics s’inscrit dans la perspective d’un dé-veloppement de la société, à Genève et dans la région, qui soit compatible aveccelui de l’ensemble de la planète et qui préserve les facultés des générations fu-tures de satisfaire leurs propres besoins.

2. A cette fin, on recherchera la convergence et l’équilibre durable entre efficacitééconomique, solidarité sociale et responsabilité écologique.

Les aspects sociétaux doivent donc être considérés, selon leur contribution dans ce do-maine, comme des freins ou comme des accélérateurs susceptibles de ralentir ou defaciliter la mise en oeuvre d’une technologie ou d’un composant informatique.

Observatoire Technologique 36

Page 39: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Couches et tiers concernés

Une déclinaison de la notion de composante sociétale en fonction des couches ou destiers concernés n’a pas été faite ici.

Risques

Une mauvaise perception du contexte socio-politique peut ralentir, voir paralyser la miseen oeuvre d’une technologie (qui peut a contrario être favorisée si elle s’insère parfaite-ment dans ce même contexte).

Mesures

1. La technologie considérée apporte-t-elle une valeur ajoutée à la société ?

2. Contribue-t-elle à la réalisation des buts fixés dans le cadre d’un agenda politiquetel que l’Agenda21 local par exemple ?

Compétence

• Observatoire Technologique

Références

Agenda 21 du Canton de Genève. http://www.etat-ge.ch/agenda21

Article de loi correspondant. http://www.geneve.ch/legislation/rsg/f/rsg_a2_60.html

Observatoire Technologique 37

Page 40: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.2.2 Cadre légal

Révisions

Version Date / auteurs Objet de la révision0.1 2003-10-06 / pge Version initiale

Description

Protection des systèmes informatiques

La législation genevoise (voir Références) a réglementé, en date du 5 avril 2000 (règle-ment B 1 15.01), la protection des systèmes informatiques dans l’administration canto-nale. Elle stipule que lors de la planification, de la réalisation et de l’exploitation d’applica-tions et de systèmes informatiques dans l’administration cantonale, il faut s’assurer queces applications et ces systèmes soient protégés contre les risques qui menacent leurdisponibilité, leur intégrité et leur confidentialité. Ce règlement est commun à toutes lesréalisations informatiques mises en oeuvre dans le canton de Genève.

Protection de la personnalité

L’une des composantes importantes des technologies actuelles réside dans l’accès élec-tronique aux données. Ceci implique tout d’abord une plus grande transparence de l’ad-ministration et une meilleure accessibilité des informations publiques. Mais la rapidité detraitement de l’information numérique, la possibilité de croiser de l’information, de tracerdes requêtes et le fait que toute information soit potentiellement accessible à chacunamène également des préoccupations en matière de respect de la vie privée, de protec-tion des données personnelles ou de gestion des identités.

En Suisse, la protection de la personnalité relève essentiellement de la législation fédé-rale (voir Références), en particulier des articles 28 et ss du Code Civil Suisse et, sousson aspect de collection d’information, de la loi fédérale su la protection des données(LPD, RS 235.1 - 19 juin 1992). Les cantons ne conservent une compétence que pour cequi échappe au champ de la LPD, soit les fichiers détenus par les entités exclues de ladéfinition de personne privée ou d’organe fédéral, à savoir les collectivités publiques etpara-publiques autres que la Confédération et les services de son administration, ainsique les institutions qui en dépendent.

La quasi totalité des cantons a adopté une législation sur la protection des donnéesdétenues par leur administration. Actuellement la loi en force à Genève est la LITAO (loicantonale B 4 35 du 17 décembre 1981 sur les informations traitées automatiquement parordinateur), en vigueur depuis le 1er février 1983, ainsi que son règlement d’exécution(B 4 35.01). La refonte de cette loi est à l’étude.

Selon le Préposé fédéral à la protection des données (voir Références), il est importantque les concepteurs de projets informatiques arrêtent leur politique de protection desdonnées aussitôt que possible.

Toujours selon le Préposé fédéral à la protection des données, il devra être tenu compte,

Observatoire Technologique 38

Page 41: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

en particulier, des principes généraux de protection des données suivants :

• Proportionnalité et finalité : l’accès à l’information ne doit pas entraîner la collecteet le traitement de données personnelles supplémentaires à celles qui sont néces-saires pour répondre aux demandes de l’utilisateur ou à celles que ce dernier esttenu de communiquer de par la loi ;

• Concentration et centralisation des données : celles-ci ne doivent pas être accruessous prétexte de rationalisation et d’harmonisation ;

• Transparence : chaque fois que des données personnelles lui sont demandées,l’utilisateur doit pouvoir librement et de manière éclairée se déterminer avant de lescommuniquer ; les éléments suivants doivent lui être communiqués lors de touteopération : la finalité, les destinataires, les éléments facultatifs ou nécessaires (àsignaler de manière distincte), les coordonnées des maîtres de fichiers et la duréede conservation des données ;

• Droit d’accès : l’utilisateur doit pouvoir à tout moment contrôler les données enre-gistrées à son sujet, demander leur suppression ou leur rectification ;

• Accès anonyme : l’utilisateur qui le souhaite ne doit pas pouvoir être tracé dansses recherches (notamment par son numéro IP ou des cookies) ; le recours auxpseudonymes, ainsi qu’aux technologies de la vie privée doit être encouragé toutesles fois que c’est possible ;

• Publication des données : toute publication relative à des données personnellesdoit être licite ;

• Communications et transactions : la confidentialité, l’intégrité et l’authentification dedonnées doivent être garanties ; il conviendra de recourir aux dernières technolo-gies de cryptage, certificat et signature électronique.

Transparence

Le 5 octobre 2001, la loi sur l’information du public et l’accès aux documents (LIPADA 2 08) a été votée. Elle est entrée en vigueur le 1er mars 2002. Elle garantit l’informationrelative aux activités des institutions publiques et para-étatiques, dans toute la mesurecompatible avec les droits découlant de la protection de la sphère privée, en particulierdes données personnelles, et les limites d’accès aux procédures judiciaires et adminis-tratives. Elle a principalement pour but de favoriser la libre formation de l’opinion et laparticipation à la vie publique. Aucun règlement d’exécution n’a encore été édicté pourcette loi.

De manière générale, les technologies potentiellement sensibles dans les domaines évo-qués ci-dessus doivent être envisagées avec prudence au risque de rendre leur mise enoeuvre problématique. C’est donc d’abord sur l’usage et la maîtrise de l’outil que doit seporter la réflexion plutôt que sur la technologie elle-même. A un niveau plus technique, ilfaut veiller à ce qu’une technologie offre toujours des possibilités de configuration et deparamétrage propres à gérer et à maîtriser correctement ces aspects.

Observatoire Technologique 39

Page 42: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Propriété intellectuelle

Un dernier point concerne les contraintes légales relatives à la propriété intellectuelle etplus spécialement à celui des licences d’utilisation. Obtenir une expertise légale dans cedomaine peut constituer un défi non-négligeable car les licences d’utilisation imposentparfois des contraintes légales fortes qu’il faut pouvoir évaluer et prendre en comptecorrectement dans le choix d’une technologie.

Ceci est également valable dans le cas du logiciel libre dont les différents types de li-cences imposent des contraintes parfois fortes qu’il ne faut pas sous-évaluer. Le logiciellibre, comme son nom ne l’indique pas, est en effet protégé par le code de la propriété in-tellectuelle. Le document Licences Open Source cité ci-dessous présente succinctementces aspects ainsi que des liens pertinents relatifs à cette problématique.

Couches et tiers concernés

Une déclinaison de cette dimension en fonction des couches ou des tiers concernés n’estpas faite ici.

Risques

• La mise en oeuvre d’une technologie ou d’un composant informatique ne s’inscri-vant pas dans le cadre légal existant risque d’en compromettre sa viabilité.

• Une technologie ou un un composant informatique dont le cadre légal régissantson existence n’est pas encore clairement défini risque de voir sa mise en oeuvreretardée.

Mesures

• Le contrat de licence d’utilisation du logiciel a-t-il été bien évalué ?

• La solution étudiée répond-elle aux exigences édictées par le Préposé fédéral à laprotection des données et plus généralement au cadre légal en vigueur ?

• La technologie considérée peut-elle être paramétrée et configurée de manière àgérer et à maîtriser correctement les aspects liés à la protection des données ?

Aspects métier

Dans le cas des données relatives à la santé d’un patient qui sont considérées commesensibles, les dispositions en vigueur aujourd’hui aux niveau fédéral et cantonal ne serecoupent que partiellement. Elles sont par ailleurs exemptes de directives pratiques àadopter pour garantir concrètement la sécurité des données numérisées et prévenir lesabus d’utilisation. L’introduction de dossiers santé virtuels ne manquera donc pas de sou-lever de nombreux problèmes juridiques.

Observatoire Technologique 40

Page 43: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Compétence

• Service juridique compétent

Références

Recueil systématique du droit fédéral. http://www.admin.ch/ch/f/rs/rs.html

Préposé fédéral à la protection des données (PFPD). http://www.edsb.ch/f/

Législation genevoise. http://www.geneve.ch/legislation/

Licences Open Source, Observatoire Technologique (CTI), 2003, ftp://ftp.geneve.ch/obstech/annexe-licences-open-source.pdf

Observatoire Technologique 41

Page 44: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

4.2.3 Cadre éthique

Révisions

Version Date / auteurs Objet de la révision0.1 2003-08-12 / pge Version initiale

Description

Ethique : science de la morale (du grec êthikos, moral et êthos, moeurs)

D’une manière générale, on entend par éthique l’ensemble des principes, des normes etdes valeurs d’ordre moral régissant une société ou un groupe social.

Les avantages que peut apporter une nouvelle technologie ne doivent pas l’emportersur la liberté et le bien-être de la personne. Ainsi la possibilité de rassembler des infor-mations croisées sur le citoyen, la confidentialité des données confiées aux organismesétatiques ou la protection de la sphère privée sont des questions qui, lorsqu’elles sontmises en perspective avec la responsabilité de l’administration à l’égard de l’ensembledes citoyens, soulèvent des réflexions sociologiques et éthiques qui vont souvent au-delàdu cadre légal. Les mêmes remarques sont également valables lorsque l’on considèreles données se rapportant à des personnes morales.

Les technologies actuelles se montrent toujours plus performantes dans le domaine dutraitement et de l’exploitation des données (statistiques, data mining, archivage, etc.)ou dans celui de la traçabilité des requêtes. Ces potentialités requièrent une vigilancesoutenue afin d’éviter des dérapages toujours possibles. Le site Web du Préposé fédéralà la protection des données (voir Références) illustre un certain nombre de ces points etconstitue une excellente référence dans ce domaine (voir également la sous-dimensionCadre légal).

A un niveau global, les technologies potentiellement sensibles dans les domaines évo-qués ci-dessus doivent être envisagées avec prudence au risque de rendre leur mise enoeuvre problématique. C’est donc d’abord sur l’usage et la maîtrise de l’outil que doit seporter la réflexion plutôt que sur la technologie elle-même. Plus cette réflexion est menéeen amont du processus de mise en oeuvre de la technologie, plus il sera aisé de résoudreles problèmes potentiels.

A un niveau plus technique, il faut veiller à ce qu’une technologie offre toujours des pos-sibilités de configuration et de paramétrage propres à prendre en compte et à maîtrisercorrectement les aspects liés au respect du cadre éthique.

Un dernier point soulevé par l’Agenda 21 du canton de Genève concerne le contrôledes fournisseurs impliqués dans le choix d’une technologie ou d’un projet de dévelop-pement : l’Agenda 21 recommande à ce sujet de s’assurer des conditions de travail desfournisseurs et des sous-traitants, et de vérifier dans quelle mesure ceux-ci répondent àdes critères de durabilité (dans le sens d’un développement durable) ou d’éthique (voirRéférences).

Observatoire Technologique 42

Page 45: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Couches concernées

• Système d’information Les processus et les règles métiers sont définis à ce niveau.C’est ici que les questions fondamentales du point de vue éthique doivent être po-sées.

• Application. Dans cette couche, ce sont les interfaces utilisateurs des applicationsqui sont concernés. La véracité des informations saisies ou la pertinence de leuraffichage sont importants.

• Plateforme supérieure. Le fonctionnement de cette plateforme peut interférer avecles notions de sphère privée et de protection de la personnalité (gestion des co-okies, rapatriement d’informations vers l’éditeur du logiciel par exemple).

• Plateforme inférieure. Idem plateforme supérieure.

• Matériel. Idem plateforme supérieure. Les aspects liés aux conditions de travail desfournisseurs et/ou des sous-traitants doivent également être vérifiés ici.

Tiers concernés

• Client. Dans cette couche, ce sont les interfaces utilisateurs des applications quisont concernés. La véracité des informations saisies ou la pertinence de leur affi-chage sont importants.

• Métier. Les questions fondamentales du point de vue éthique doivent être poséesau niveau de la logique métier.

• Ressources. La gestion des données sensibles (soit directement, soit par recou-pement) doit être correctement réglée à ce niveau : une concentration de tellesdonnées dans une base unique est à proscrire.

Risques

Le risque initial d’éluder les questions éthiques aux dépens de l’aspect technologiqueest souvent bien réel. Dans ce contexte les groupes d’utilisateurs, les différents comitésd’éthique, associations corporatives ou simples citoyens peuvent constituer un frein ma-jeur à la mise en œuvre d’une solution informatique lorsque les aspects éthiques n’ontpas été suffisamment pris en compte.

Mesures

Dans les cas où des données sensibles (soit directement, soit par recoupement) sontconcernées :

1. La mise en oeuvre de la technologie ou du composant informatique considérésest-elle susceptible de ne pas recevoir l’aval de la Commission de Contrôle de l’In-formatique de l’Etat de Genève ou d’un comité d’éthique autorisé ?

Observatoire Technologique 43

Page 46: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

2. La technologie ou le composant informatique considérés peuvent-ils être paramé-trés et configurés de manière à prendre en compte et à maîtriser correctement lesaspects liés au respect du cadre éthique ?

3. Les conditions de travail des fournisseurs et/ou des sous-traitants répondent-ellesà des critères de durabilité et d’éthique tel que recommandé dans l’Agenda21 duCanton de Genève ?

Aspects métier

Les informations médicales sont des données sensibles par excellence. Le domaine dela santé se retrouve ainsi naturellement aux avant-postes lorsque l’on évoque le respectdu cadre éthique. Le recours dans ce cas à la Commission de Contrôle de l’Informatiquede l’Etat est indispensable.

Compétence

• Commission de Contrôle de l’Informatique de l’Etat

• Comité(s) d’éthique.

Références

Agenda 21 du Canton de Genève. http://www.etat-ge.ch/agenda21

Site du Préposé fédéral à la protection des données. http://www.edsb.ch/f/service/sitemap.htm

Observatoire Technologique 44

Page 47: Le Référentiel Nouvelles Plateformes Technologiques

Chapitre 5

Dimensions relatives aux QualitésSystémiques

Les dimensions Evolutivité, Qualité de service, Exploitabilité et Interopérabilité ont étéregroupées sous le label commun Dimensions relatives aux qualités systémiques. Cesdimensions, ainsi que les sous-dimensions correspondantes prennent en compte les as-pects intrinsèques des technologies et des composants informatiques étudiés. Elles nedépendent ni de facteurs humains, ni de facteurs organisationnels. Les qualités systé-miques sont orientées "contraintes" et sont fortement liées à la complexité de la solutionétudiée. Les dimensions relatives à la sécurité, qui peuvent également être vues commedes qualités systémiques, sont développées dans une autre section.

45

Page 48: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.1 Évolutivité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La dimension évolutivité peut être abordée selon deux points de vue distincts :

• Premier point de vue (évaluation d’une solution métier à intégrer dans le systèmed’information) : cette dimension mesure la capacité d’un sous-système à évoluerpour répondre à de nouveaux besoins. Il peut s’agir aussi bien de nouveaux be-soins fonctionnels que de nouveaux besoins non-fonctionnels (p.ex. besoin d’accé-der au système par un nouveau canal, besoin de supporter un plus grand nombred’utilisateurs, etc.).

• Deuxième point de vue (évaluation d’une technologie d’intégration) : cette dimen-sion mesure le degré avec lequel la technologie facilite l’évolutivité des systèmesqui en tirent parti. Par exemple, un langage orienté-objet a un impact positif surl’évolutivité des systèmes développés avec ce langage.

Sous-dimensions

• Scalabilité : mesure la capacité d’un système à supporter une charge croissantegrâce à un ajout de ressources.

• Flexibilité : mesure la facilité avec laquelle un système peut s’adpater à de nou-veaux besoins, à de nouvelles contraintes.

• Portabilité : mesure la capacité d’un composant à pouvoir fonctionner dans diffé-rents environnements d’exécution.

• Maturité : mesure le degré avec lequel le système a été utilisé, éprouvé et graduel-lement amélioré.

Couches concernées

• Système d’information. C’est dans cette couche qu’on peut mesurer le degré d’évo-lutivité global du système d’information. Les règles métiers, les contraintes et lesvolumétries sont en effet exprimées à ce niveau. La rapidité avec laquelle le sys-tème d’information peut évoluer (qui dépend de l’évolutivité des architectures sous-jacentes) est une mesure pour cette dimension.

• Application. Dans cette couche, on va mesure l’évolutivité d’un sous-système parti-culier du système d’information. Ce sont les choix faits lors de la conception de l’ap-plication (modélisation, choix de technologies) qui vont déterminer le degré d’évo-lutivité de l’application.

Observatoire Technologique 46

Page 49: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Plateforme supérieure. Les technologies mises en oeuvre dans cette couche sontsusceptibles d’augmenter le degré d’évolutivité du système global. Ceci est pos-sible car la couche favorise l’intégration de systèmes hétérogènes, l’échange demessages entre ces systèmes, et la réutilisation de composants et services.

• Plateforme inférieure. L’évolutivité du système d’exploitation doit être considéréedans la mesure où des dépendances fortes existent entre les couches Plateformesupérieure/Application et la couche système d’exploitation. Idéalement, une évolu-tion du système d’exploitation ne devrait pas avoir d’impact négatif sur les applica-tions, mais ce n’est pas toujours le cas.

• Matériel. L’évolutivité d’un élément matériel est liée à sa capacité à devenir pluspuissante après l’ajout de ressources supplémentaires (CPU, mémoire, etc).

Tiers concernés

• Client. Dans ce tiers, on s’intéresse à la capacité d’une application à évoluer auniveau de l’interface utilisateur. Il est important que cette évolutivité soit possiblesans avoir d’impact sur les composants des autres tiers (le découplage des tiersest un objectif de l’architecture multi-tiers).

• Présentation. Idem tiers Client.

• Métier. L’évolutivité dans ce tiers est cruciale, puisqu’elle décrit la capacité de l’ap-plication à s’adapter au changement des règles métiers. Idéalement, le changementde règles métiers ne devrait pas nécessiter de codage, mais uniquement une para-métrisation de l’applicatif.

• Intégration. La couche intégration joue un rôle important dans l’évolutivité d’un sys-tème, surtout si on considère les aspects tels que la performance, la montée encharge, la sécurité, la facilité de gestion. En effet, en faisant évoluer la qualité deservice, il est possible que des composants dans la couche ressources doivent êtreremplacés (p.ex. remplacer la base de données). Faire en sorte que cette évolutionsoit possible sans affecter les couches amont (client, présentation, métier) est lerôle de la couche intégration.

• Ressources. Comme expliqué dans le paragraphe précédent, l’évolutivité des com-posants dans la couche ressources est souvent associée à l’augmentation de laqualité de service désirée. Il faut noter que l’évolutivité au niveau fonctionnel estégalement souhaitable.

Risques

Si cette dimension est négligée, le risque est d’obtenir un système d’information qui nepuisse pas répondre aux attentes des utilisateurs. Cela peut se produire s’il n’est paspossible de prendre en compte l’ensemble des règles du domaine d’application (ou alorsà un coût élevé). Cela peut également se produire s’il n’est pas possible de satisfaire lesqualités de services en fonction de leur évolution.

Observatoire Technologique 47

Page 50: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Mesures

Mesurer l’évolutivité d’un système demande une analyse de son architecture.

• Le système peut-il évoluer pour répondre à un nombre croissant d’utilisateurs ? Aquel coût ? Dans quelle mesure ?

• Le système peut-il évoluer pour répondre à un besoin accru de performance ? Aquel coût ? Dans quelle mesure ?

• Le système peut-il évoluer pour répondre à un besoin accru de sécurité ? A quelcoût ? Dans quelle mesure ?

• Le système peut-il évoluer pour répondre à un changement des règles métiers ? Aquel coût ? Dans quelle mesure ?

• L’organisation a-t-elle accès au code du système, et est-elle en mesure de faireévoluer ce code ?

Observatoire Technologique 48

Page 51: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.1.1 Scalabilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La scalabilité mesure la capacité d’un système à supporter une charge croissante (nombretotal d’utilisateurs, nombre d’utilisateurs concurrents, nombre de requêtes, etc.) par l’ajoutsuccessif de ressources (CPU, mémoire, etc.). Idéalement, le rapport entre la charge etle coût des ressources devrait être linéaire.

Couches concernées

• Système d’information. C’est au niveau de cette couche que le besoin de scalabi-lité est exprimé. En effet, c’est au niveau du système d’information que le nombred’utilisateurs (ainsi que les projections sur son accroissement), que le nombre deservices ou de requêtes peuvent être spécifiés. Les couches sous-jacentes doiventensuite permettre d’atteindre les niveaux souhaités.

• Application. Au niveau de cette couche, c’est la scalabilité d’une partie du systèmed’information qui est analysée. Souvent, plutôt que de parler d’application, on par-lera de service (par exemple, un service d’authentification, un service de recherchedocumentaire). L’architecture du service doit être conçue grâce aux mécanismesoffert dans la couche Plateforme supérieure.

• Plateforme supérieure. Cette couche offre des mécanismes qui permettent de réa-liser des services "scalables". Dans le cas particulier d’architectures distribuées, ilest par exemple possible d’appliquer le principe de répartition de charge au niveaudes composants logiciels. En d’autres termes, plusieurs instances du même ser-vice peuvent être créées (et hébergées par des serveurs d’applications différents).Les requêtes peuvent ensuite être réparties entre ces différentes instances, ce quipermet de faire face à une évolution de leur nombre.

• Plateforme inférieure. Au niveau de l’OS, la scalabilité est liée à la capacité à gérerun grand nombre de ressources. Certains systèmes d’exploitation ne peuvent gérerqu’un nombre limité de CPUs, d’autres peuvent en gérer un très grand nombre.De même, un système d’exploitation 64 bits permet d’adresser une quantité demémoire beaucoup plus grande qu’un système d’exploitation 32 bits. Il permet doncune plus grande scalabilité.

• Matériel. Au niveau de cette couche, la scalabilité se mesure par la capacité deséquipements à accepter une charge croissante. Cela se traduit par exemple entermes d’accroissement de bande passante pour le réseau. Cela se traduit égale-ment par l’ajout de serveurs. A ce sujet, on distingue la scalabilité horizontale (ajoutde composants relativement peu puissants sur lesquels sont répartis la charge),de la scalabilité verticale (ajout de ressources dans un composant qui devient trèspuissant).

Observatoire Technologique 49

Page 52: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Tiers concernés

• Client. On trouve une problématique de scalabilité dans ce tiers dans le cas par-ticulier d’applications métiers dont les composants sont hébergés par le poste detravail client, et qui consomment une grande quantité de ressources. Un exempleparticulier est une application de visualisation scientifique. Si une telle applicationest scalable, alors il devrait être possible de lui imposer une charge plus importante(complexité des calculs par exemple) en ajoutant des ressources (mémoire, CPUs).

• Présentation. Dans le cas d’une application Web, les pages HTML sont généréesdans le tier de présentation. Dans un monde J2EE, ce sont des composants commedes servlets et des JSPs qui assurent cette tâche. Un mécanisme commun pourassurer la scalabilité dans ce tiers est d’utiliser un load balancer placé en amontd’une batterie de serveurs relativement peu puissants. Chacun de ces serveurshéberge un container Web, dans lequel sont déployés les mêmes servlets et JSPs.Le load balancer répartit la charge entre les différents serveurs. Dans la plupart descas, il est important d’implémenter un mécanisme d’affinité de session, pour quetoutes les requêtes émises par le même utilisateur (pendant une session de travail)soit routées vers le même serveur. Cela évite aux serveurs de devoir partager unétat commun.

• Métier. C’est dans ce tiers qu’on trouve la logique métier des services qui implé-mentent les besoins fonctionnels du système d’information. Pour certains servicesutilisés par un grand nombre d’utilisateurs, la scalabilité est évidemment très im-portante. Dans un mode J2EE, ce sont des composants comme les EJBs qui im-plémentent la logique métier. Les serveurs d’application dans lesquels les EJBssont hébergés offrent un environnement d’exécution scalable, puisqu’ils offrent desmécanismes de duplication et de répartition de charge.

• Intégration. Dans ce tiers on trouve entre autres les technologies de middlewareorientées messages (MOM). Ces technologies facilitent la conception de systèmesscalables puisqu’elles permettent de découpler les différents composants d’un sys-tème. Il devient ainsi plus facile de rajouter des noeuds fonctionnellement équiva-lents pour faire face à une augmentation de la charge.

• Ressources. Dans ce tiers, il faut par exemple faire en sorte que les bases de don-nées ou les annuaires puissent faire face à des charges importantes. Il est fréquentde privilégier une scalabilité verticale, c’est à dire d’utiliser des serveurs très puis-sants, au sein desquels on rajoute des ressources au cours du temps.

Risques

Si cette dimension n’est pas prise en compte, le risque est de ne pas pouvoir faire faceà une augmentation de la charge. Ce risque est particulièrement important dans le casde services publiés sur le Web, puisque le nombre d’utilisateurs peut croître dans degrandes proportions et très rapidement. Lorsqu’un système devient populaire, la chargequ’il subit augmente rapidement. Si la scalabilité du système est médiocre, les perfor-mances se dégradent très vite. La perception du système est alors négative et beaucoupd’utilisateurs risquent de ne plus l’utiliser.

Observatoire Technologique 50

Page 53: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Mesures

Pour mesurer la scalabilité d’un système, on peut se poser les questions suivantes :

• Dans quelle mesure le système peut-il évoluer pour répondre à une augmentationde la charge (i.e. augmentation du nombre d’utilisateurs et/ou de l’activité des utili-sateurs) ?

• Lors d’une augmentation de la charge, l’architecture du système doit-elle être mo-difiée ?

• Lors d’une augmentation de la charge, est-il suffisant de rajouter des ressources(serveurs, mémoire, CPUs) ?

• Lors d’une augmentation de la charge, quel est le temps nécessaire pour redimen-sioner et reconfigurer le système ?

• La consommation des ressources est-elle proportionnelle à la charge (évolutionlinéaire, non exponentielle) ?

Observatoire Technologique 51

Page 54: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.1.2 Flexibilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La flexibilité d’un système mesure la facilité avec laquelle il peut s’adpater à de nouveauxbesoins, à de nouvelles contraintes. Il peut s’agir aussi bien de besoins fonctionnels (ty-piquement l’ajout ou la modification de fonctions utilisateurs), que de besoins non fonc-tionnels (p.ex. le renforcement de la sécurité ou le support pour un nouveau type declient).

Couches concernées

• Système d’information. C’est dans cette couche que la modification des besoins estexprimée. L’informatisation de nouveaux processus métier, par exemple, génère unensemble de besoins fonctionnels qui doivent être intégrés au système informatiséexistant. Dans la mesure où ce système présente un haut degré de flexibilité, celane pose pas de problèmes majeurs.

• Application. La conception des composants qui se situent dans cette couche a unimpact déterminant sur la flexibilité du système, surtout d’un point de vue fonction-nel. L’ajout ou la modification de fonctionnalités implique avant tout un travail à ceniveau.

• Plateforme supérieure. Les choix opérés dans cette couche participent à la défini-tion de l’architecture du système. Le choix d’un middleware qui permet un dévelop-pement orienté "objet", "services" et "composants" favorise la modularisation et laréutilisation, ce qui a un impact positif sur la flexibilité du système.

• Plateforme inférieure. Cette couche a un impact sur la flexibilité par rapport à denouveaux besoins non fonctionnels. Par exemple, la facilité avec laquelle des mé-canismes de haute disponibilité peuvent être introduits est différente d’un systèmed’exploitation à l’autre.

• Matériel. De la même manière, le matériel choisi a un impact sur la facilité aveclaquelle de nouveaux besoins non fonctionnels peuvent être incorporés.

Tiers concernés

• Client. Dans ce tiers, la facilité avec laquelle l’interface utilisateur peut s’adapterau changement des règles métier (dans le tiers métier) donne une mesure de laflexibilité. La capacité à satisfaire des besoins particuliers, en terme d’ergonomieou d’accessibilité par exemple en donne une autre.

Observatoire Technologique 52

Page 55: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Présentation. Dans ce tiers, une mesure typique de la flexibilité est la facilité aveclaquelle le système peut supporter un nouveau type de client (p.ex. un terminalmobile).

• Métier. La dimension flexibilité est essentielle lors de la conception relative à cetiers. C’est en effet ici que sont implémentées les règles métiers, qui sont suscep-tibles d’évoluer fréquemment dans le temps. Etre capable d’incorporer de nouvellesrègles métiers dans le système est extrêmement important.

• Ressources. Dans ce tiers, la flexibilité mesure par exemple la facilité avec laquelleun fournisseur de ressources peut faire face à une augementation de la charge.

Risques

Si cette dimension est négligée, le risque est de rendre la modification du système, parrapport à de nouveaux besoins, très longue et coûteuse. Pour l’organisation, le risque quien découle est de ne pas pouvoir faire face à l’évolution des besoins, ce qui peut s’avérerdommageable.

Mesures

Pour mesurer la flexibilité d’un système, on peut se poser les questions suivantes :

• Le système permet-il la modification et/ou la redéfinition des règles de gestion ?

• Une modification des règles de gestion demande-t-elle une modification du code,ou uniquement de la paramétrisation du système ?

• Quel est le temps nécessaire à la modification d’une règle de gestion ?

• Le système offre-t-il des interfaces qui permettent d’accéder à ses fonctionalités ?Quelle est la nature de ces interfaces ?

Observatoire Technologique 53

Page 56: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.1.3 Portabilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La portabilité mesure la capacité d’un composant à pouvoir fonctionner dans différentsenvironnements d’exécution. Elle reflète l’indépendance entre les différentes couches dusystème.

Couches concernées

• Application. Idéalement, les applications et les services développés dans cettecouche devraient être portables sur différentes instances de la plateforme supé-rieure. C’est le cas dans le monde J2EE, puisque le même servlet, ou le mêmeEJB, peuvent être déployés dans des containers différents (qu’il s’agisse de pro-duits commerciaux, comme le serveur d’application de Borland, ou de produits opensource comme JBoss).

• Plateforme supérieure. Un composant de cette couche est portable lorsqu’il peutêtre exécuté au-dessus de différents systèmes d’exploitation. C’est le cas lorsquele composant (p.ex. un serveur d’application ou un serveur Web) est lui-même écriten Java.

• Plateforme inférieure. La portabilité des composants appartenant à cette couche(en particulier le système d’exploitation) reflète leur capacité à fonctionner sur desarchitectures matérielles différentes (x86, SPARC, PowerPC).

Tiers concernés

• Client. Dans ce tiers, la portabilité d’un composant offre la possibilité de le fairefonctionner sur différents postes utilisateurs. Par exemple, un client lourd développéen Swing est portable dans différents environnements.

• Présentation. Dans ce tiers, la portabilité signifie que les composants qui génèrentl’interface utilisateur peuvent être déployés dans différents environnements. Parexemple, le même servlet peut être déployé dans différents containers Web, eux-mêmes installés sur différents systèmes d’exploitation et/ou architectures maté-rielles.

• Métier. Dans ce tiers, la portabilité signifie que les composants qui implémentent lalogique métier peuvent être déployés dans différents environnements. Par exemple,le même EJB peut être déployé dans différents containers EJB, eux-mêmes instal-lés sur différents systèmes d’exploitation et/ou architectures matérielles.

Observatoire Technologique 54

Page 57: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Ressources. Dans ce tiers, la portabilité signifie que les composants qui gèrent lesressources (p.ex. bases de données) peuvent être installés dans différents envi-ronnements. Dans certains cas cela veut dire que le même composant peut êtreexécuté dans différents environnements (p.ex. un annuaire écrit en Java). Dansd’autres cas, cela signifie que le même produit existe en plusieurs versions, exécu-tables dans différents environnements (p.ex. l’annuaire d’un constructeur X, qui estdisponible pour Solaris, pour Linux et pour Windows). Dans d’autres cas enfin, celaveut dire qu’il est possible de trouver un produit qui implémente la même normedans d’autres environnements et qu’il sera donc possible de gérer les mêmes res-sources dans ces environnements (p.ex. un annuaire qui implémente la normeLDAP).

Risques

Si cette dimension n’est pas prise en compte, le risque principal est de créer une dé-pendance par rapport à un produit et un fournisseur particulier. Si une application estdéveloppée au-dessus d’une plateforme propriétaire, et qu’elle n’est pas portable, il n’estplus possible de remplacer la plateforme en question sans avoir à ré-écrire l’application.

Mesures

• L’application peut-elle fonctionner sur des systèmes d’exploitations et/ou des archi-tectures matérielles différentes ?

• Le service peut-il être déployé dans différents serveurs d’applications, ou utilise-t-ildes fonctions propriétaires d’un serveur particulier ?

• Quel est le degré de portabilité, i.e. quel est l’effort nécessaire pour porter le com-posant vers un autre environnement ?

• le composant fonctionne tel quel (p.ex. parce que du bytecode et des machinesvirtuelles sont utilisées)

• le composant doit être recompilé (parce que les environnements n’offrent pasde compatibilité binaire)

• le composant doit être partiellement ré-écrit (parce que les environnementsn’utilisent pas les mêmes librairies de développement)

Aspects métier

Compétence

• La DTD, qui définit les best practices au niveau de la conception de services appli-catifs.

• Le CAT pour l’évolutivité de l’architecture du système global.

Observatoire Technologique 55

Page 58: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Divers

Exemples :

• Le framework CTI : le framework CTI permet le développement de services por-tables puisqu’il est fondé sur les technologies J2EE. Les services sont portablessur des serveurs d’applications différents, sur des systèmes d’exploitation différentset sur des architectures matérielles différentes (car on trouve des containers J2EEpour différents OS/matériels).

Contre-exemples :

• Application MS Access : Une application développée avec MS Access fonctionneuniquement sur Windows et n’est pas portable.

Standards :

• Java (portabilité du bytecode sur différents OS et différentes architectures maté-rielles)

• J2EE (portabilité des composants métiers sur différents containers)

Observatoire Technologique 56

Page 59: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.1.4 Maturité de la solution

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La maturité d’un système mesure le degré avec lequel le système a été utilisé, éprouvé etgraduellement amélioré. Après une phase de développement initiale, un système est misen production, à disposition des utilisateurs. Le cycle de vie du système inclut ensuitedes activités de maintenance corrective et évolutive. Au fil des itérations, la qualité dusystème et sa maturité devraient évoluer de manière positive.

Dans le cas de développements qui ne sont pas spécifiques à une organisation (logicielscommerciaux et logiciels libres), l’utilisation par un grand nombre de clients, le retourd’expérience et l’amélioration intrinsèque du produit font progresser le degré de maturité.

Dans le cas particulier de frameworks de développement, leur utilisation dans le cadrede différents projets et leur amélioration (refactoring) par rapport au retour d’expérienceaugmentent leur maturité. Une idée largement répandue est qu’un "système orienté ob-jet" doit être ré-utilisé au moins trois fois (dans des contextes différents) avant d’êtresuffisamment mûr pour devenir un framework à proprement parler.

Couches et tiers concernés

Une déclinaison de la dimension en fonction des couches ou des tiers concernés n’estpas faite ici.

Risques

Lorsque cette dimension est sous-estimée, que ce soit lors du choix d’une solution métier,d’un outil de développement ou encore d’un produit middleware, le risque est de rencon-trer des problèmes ou des limitations qui n’ont pas encore été identifiés par le fournisseurde la solution. En évaluant la couverture fonctionnelle et l’architecture technique d’unesolution, il est donc important d’évaluer la maturité de celle-ci.

Mesures

• De combien de temps date la première version de la solution ?

• Quelle est la version courante de la solution ?

• La solution est-elle utilisée par de nombreuses organisations ? Quelles sont lesréférences disponibles ?

Observatoire Technologique 57

Page 60: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Quelle est la position de la solution dans le marché, par rapport à des solutionséquivalentes ?

• Existe-t-il une grande communauté d’utilisateurs pour la solution ? Beaucoup d’in-formation est-elle échangée au sein de cette communauté ?

Observatoire Technologique 58

Page 61: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.2 Exploitabilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

L’exploitabilité d’un système mesure la facilité avec laquelle il peut être géré, contrôlé etmaintenu opérationnel dans un environnement de production. L’exploitabilité d’un sys-tème mesure également la facilité avec laquelle des opérations de maintenance (cor-rective et/ou évolutive) peuvent être réalisées sur le système, avec des interruptions deservice minimes.

Sous-dimensions

• Maintenabilité : mesure la facilité avec laquelle un système peut être modifié dansle but de corriger des défauts, d’ajouter des fonctions, d’améliorer des performances,de s’adapter à des modifications de l’environnement.

• Contrôlabilité : mesure le degré avec lequel le fonctionnement d’un système peutêtre contrôlé (de manière continue et automatique), avec lequel des incidents peuventêtre détectés et notifiés et avec lequel des statistiques d’usage peuvent être obte-nues.

Couches concernées

• Système d’information. A ce niveau, l’exploitabilité mesure la facilité avec laquellele système informatisé peut être maintenu dans un état qui permet de répondre auxbesoins des utilisateurs. Ces besoins évoluant, l’exploitabilité du système dépenddonc de la facilité avec laquelle des nouvelles fonctions peuvent être incorporées.

• Application. A ce niveau, on notera qu’il est souhaitable non seulement d’avoir unbon niveau d’exploitabilité pour les différentes applications et services, mais égale-ment d’avoir une cohérence globable. En d’autres termes, le choix et l’applicationtransversale de mécanismes appropriés (monitoring, logging, gestion du change-ment) est vivement recommandée.

• Plateforme supérieure. L’exploitabilité des composants de cette couche est trèsimporante. Conceptuellement, les serveurs d’applications sont censés libérer lesdéveloppeurs "métier" de considérations techniques (distribution, persistence, sé-curité, etc.). Ils offrent ainsi un environnement d’exécution, qui doit avoir un hautniveau d’exploitabilité pour être utile.

• Plateforme inférieure. Au niveau du système d’exploitation, l’exploitabilité est as-sociée à des outils de surveillance, à des mécanismes de gestion des évolutions(patch), etc.

Observatoire Technologique 59

Page 62: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Matériel. A ce niveau, l’exploitabilité mesure la manière, plus ou moins facile, aveclaquelle le personnel peut assurer la maintenance des composants matériels. Desserveurs qui intègrent un système de surveillance et de notification des incidents,des serveurs qui permettent le remplacement de pièces défectueuses "à chaud"ont un degré d’exploitabilité élevé.

Tiers concernés

• Client. L’exploitabilité des composants déployés dans la couche client est délicate.Intégrer des outils de surveillance et de notification des incidents, gérer l’évolutiondes versions et leur distribution sont des questions à considérer.

• Présentation. L’exploitabilité des composants du tiers présentation dépend d’unecollaboration entre les équipes de développement (pour les composants applicatifs)et les équipes d’exploitation (pour les composants middleware).

• Métier. Même remarque que pour le tiers précédent.

• Intégration. Dans le tiers d’intégration, l’exploitabilité est le plus souvent associée àdes composants techniques (bus de messages asynchrones, connecteurs, etc.) etimpacte surtout les équipes d’exploitation.

• Ressources. Dans le tiers des ressources, l’exploitabilité est importante, puisqu’ellea un impact sur l’ensemble des services et applications du système. En effet, denombreuses architectures sont conçues de façon à ce qu’un ensemble de servicesdistribués accèdent au même fournisseur de ressources (SGBD, annuaire). En casde panne au niveau des ressources, c’est donc l’ensemble des services qui devientindisponible.

Risques

Si l’exploitabilité d’un système est négligée lors de son choix ou de sa conception, lepremier risque est de voir les coûts exploser durant sa mise en production. Le deuxièmerisque est de ne pas pouvoir garantir un degré de disponibilité suffisant pour le serviceen raison du temps nécessaire à la détection des incidents et du temps nécessaire à leurréparation. Ces risques ont un impact direct sur les utilisateurs du système.

Mesures

Pour mesurer l’exploitabilité d’un système, il faut l’étudier du point de vue des personnesqui ont la responsabilité de le maintenir en état de fonctionner, en respectant les niveauxde disponibilité et de performance spécifiés. A titre d’exemple, les questions suivantespeuvent être citées :

• Des procédures de gestion des incidents et de gestion du changement sont-ellesdéfinies par rapport au système ?

• Le personnel qui gère le système en production dispose-t-il d’outils de surveillancedu système ?

Observatoire Technologique 60

Page 63: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.2.1 Maintenabilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La maintenabilité mesure la facilité avec laquelle un système peut être modifié dans lebut de corriger des défauts, d’ajouter des fonctions, d’améliorer des performances, des’adapter à des modifications dans l’environnement. Dans certains environnements, lesopérations de maintenance doivent pouvoir être réalisées sans interruption de service.Cette problématique a un impact au niveau de la conception du système, mais égalementau niveau des procédures de gestion définies par rapport au système. La maintenabilitéd’un composant est liée à la qualité de la documentation fournie. En effet, pour pouvoirfaire évoluer un composant, mais également pour pouvoir le faire évoluer, il est indispen-sable de connaître sont ses fonctions, son architecture interne, ses interfaces. Dans lecas d’un système, la documentation de l’architecture globale joue également un rôle pré-dominant dans la maintenabilité du système. Par exemple, le fait que les dépendancesentre les composants soient répertoriées est un facteur déterminant.

Couches concernées

• Système d’information. La maintenabilité du système d’information peut être vuecomme la "facilité" avec laquelle des acteurs, des composants et des processuspeuvent être ajoutés, modifiés ou supprimés. La "facilité" est mesurée en termed’impact sur le reste du système. Si la modification d’une partie du système n’aqu’un impact limité, le système continue à fonctionner dans son ensemble. Le coûtlié à l’opération de maintenance est donc réduit. Au contraire, si l’ensemble dusystème est paralysé par chaque modification, le coût de la maintenance est élevé.

• Application. La maintenabilité de cette couche est très importante pour l’organisa-tion, puisque c’est à ce niveau que les règles métier sont définies. Dans le cas dedéveloppements spécifiques, c’est l’organisation elle même qui assume les opé-rations de maintenance corrective et évolutive. La maintenabilité d’un système dé-pend de la qualité de son architecture, de son code et de sa documentation. Elle estégalement liée à la définition et à l’application de processus de gestion du change-ment. Une approche systématique par rapport aux tests des composants est éga-lement déterminante (la disponibilité d’un ensemble de tests automatisés réduit parexemple sensiblement le coût des opérations de maintenance).

• Plateforme supérieure. A ce niveau, la plupart des organisations n’assument pas lamaintenance du code des composants. Au contraire, ce sont les fournisseurs descomposants qui assument cette responsabilité. Néanmoins, lorsque de nouvellesversions sont livrées par les fournisseurs, l’organisation doit gérer la problématiquede déploiement et de migration, qui n’est pas triviale. Ici également une approchesystématique de la gestion du changement et des tests est indispensable.

Observatoire Technologique 61

Page 64: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Plateforme inférieure. La même remarque s’applique à cette couche.

• Matériel. Au niveau du matériel, certains constructeurs proposent des serveurs dontles composants défecteux peuvent être remplacés "à chaud", c’est à dire sans êtremis hors tension. ces serveurs offrent donc un haut degré de maintenabilité.

Tiers concernés

• Client. La maintenabilité des composants du tiers client est associée à la probléma-tique du déploiement. En effet, à la suite d’opérations de maintenance correctiveet/ou évolutive, il est nécessaire d’installer la nouvelle version des composants surle poste de travail des utilisateurs. Des technologies peuvent rendre ce processusplus facile (par exemple Java WebStart).

• Présentation. La maintenabilité des composants du tiers de présentation soulèvela question de l’interruption de service. Si des composants de ce tiers doivent êtreremplacés, le service qu’ils assument peut devenir indisponible durant la périodede migration. Si cela n’est pas acceptable (besoin de haute disponibilité forte), il estalors nécessaire de bénéficier d’une architecture redondante et d’implémenter desprocessus de migration échelonnés. De tels processus peuvent être relativementcomplexes à mettre en oeuvre.

• Métier. Au niveau métier, la même problématique se pose mais avec un impact plusimportant. En effet, les services métiers peuvent être utilisés par plusieurs servicesde présentation. Rendre un service métier indisponible a donc pour conséquencede rendre indisponibles plusieurs applications ou autres services. D’autre part, l’in-terface offerte par les services métiers est souvent plus riche que celle offerte parles services de présentation. Dans le cas où l’interface est modifiée au cours d’uneopération de maintenance, la gestion des dépendances et la gestion des versionsest critique.

• Intégration. Dans le tiers d’intégration, la maintenabilité des composants est im-portante, puisqu’elle a un impact sur de nombreux services et applications. Uncomposant défecteux ou indisponible dans ce tiers impacte donc un grand nombred’utilisateurs. D’autre part, le tiers d’intégration est par définition un tiers dont lescomposants ont des interactions avec beaucoup d’autres systèmes et composants.Garantir que la nouvelle version d’un composant fonctionne avec tous les compo-sants en place est donc important.

• Ressources. Dans les architectures multi-tiers, où les données sont souvent gé-rées sur des serveurs dédiés, la maintenabilité des composants du tiers ressourcesest cruciale. A nouveau, un gestionnaire de ressources qui devient indisponible oùdéfecteux aura un impact lourd sur un grand nombre d’utilisateurs.

Risques

Un système qui a un faible degré de maintenabilité présente un risque important pourl’organisation. Si cette dimension est négligée, le coût induit par les modifications dusystème (que celles-ci soient dues à des défauts ou à une évolution des besoins) peut

Observatoire Technologique 62

Page 65: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

devenir très élevé. Certains coûts sont directs (activités nécessaires pour identifier lesmodifications requises et pour les réaliser). D’autres sont indirects (indisponibilité du sys-tème pendant certaines activités de maintenance). Un système qui a un faible degré demaintenabilité a souvent un faible degré de stabilité, et donc d’utilisabilité. Il y a donc unimpact visible par les utilisateurs finaux.

Mesures

La qualité de la documentation, la description de processus pour gestion des évolutions,les interfaces de surveillances sont des éléments qui indiquent un certain degré de main-tenabilité pour un composant. Au niveau de l’architecture d’un système, un couplagefaible entre les composants est également un signe positif.

Les questions suivantes permettent d’évaluer quelques aspects de la maintenabilité d’unsystème :

• Des opérations de maintenance peuvent-elles être réalisées sans que le servicefourni par le système devienne indisponible ?

• Des procédures sont-elles clairement définies pour traiter les incidents survenantdans le contexte du système (détection, notification, lignes de support, etc.)

Observatoire Technologique 63

Page 66: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.2.2 Contrôlabilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La contrôlabilité mesure le degré avec lequel le fonctionnement d’un système peut êtrecontrôlé (de manière continue et automatique), avec lequel des incidents peuvent êtredétectés et notifiés ou avec lequel des statistiques d’usage peuvent être obtenues.

Couches concernées

• Système d’information. Au niveau du système d’information, la contrôlabilité im-plique qu’un ensemble de règles et de processus sont appliqués par certains ac-teurs du système. Ces processus peuvent être ou ne pas être informatisés. Parexemple, un audit réalisé dans une optique d’assurance de qualité et sous la formed’entretiens personnels peut être vu comme un mécanisme de contrôlabilité.

• Application. En étudiant la contrôlabilité de la couche applicative, on peut considérerdeux types d’événements. Premièrement, les événements et incidents techniques,qui sont liés à la qualité du code et à l’environnement d’exécution. Deuxièmement,les événements et incidents métier, qui sont liés à la logique applicative. Un admi-nistrateur qui doit assurer la production d’un système sera plutôt intéressé par lesévénements techniques, alors qu’un analyste métier ou un contrôleur seront plusconcernés par les événements métier.

• Plateforme supérieure. La plateforme supérieure constitue l’environnement opéra-tionnel dans lequel les composants applicatifs sont déployés. Les événements quisurviennent dans cette couche sont donc d’ordre technique. A titre d’exemples, onpeut citer les événements et les incidents suivants : "soumission d’une requête","début d’une session", "expiration d’une session", "échec lors de la connection à labase de données", etc.

• Plateforme inférieure. La plateforme inférieure est également une source d’événe-ments qui est utile pour le contrôle d’un système. Le système d’exploitation peut parexemple remonter des alertes lorsque le taux d’utilisation du CPU ou la quantité demémoire disponible atteignent des niveaux critiques.

• Matériel. Des incidents au niveau du matériel peuvent également être détectés etnotifiés (au travers du système d’exploitation). Le degré de contôlabilité est un fac-teur de différenciation pour certains constructeurs.

Tiers concernés

En ce qui concerne la contrôlabilité, il n’y a pas de différence fondamentale entre lesdifférents tiers du système. Dans tous les cas, les mêmes mécanismes peuvent être

Observatoire Technologique 64

Page 67: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

appliqués pour définir, notifier et traiter des événements (aussi bien techniques que fonc-tionnels). La mise en oeuvre de ces mécanismes dépend cependant des technologiesutilisées pour développer les composants (et de l’ouverture de ces composants).

Par contre, la consolidation des informations est une problématique particulière à cettesous-dimension. En effet, certains des événements qui se produisent dans les différentstiers du système doivent pouvoir être monitorés et traités de manière centralisée. Le per-sonnel assurant le fonctionnement d’une application doit pouvoir être alerté d’incidentssurvenants sur l’ensemble des tiers, et idéalement au travers de la même interface denotification. Les systèmes qui offrent un haut niveau de contrôlabilité intègrent des mé-canismes pour gérer les problèmes liés à la distribution des composants.

Risques

Un système qui a un faible degré de contrôlabilité demandera une attention particulière,soutenue et constante de la part du personnel assurant son fonctionnement. S’il n’estpas possible de recevoir des alertes lors d’incidents, alors un opérateur devra s’assurer"manuellement" et régulièrement que le système fonctionne correctement.

Mesures

Les éléments suivants donnent une idée de la contrôlabilité d’un système :

• Les interfaces utilisateurs dédiées au monitoring (consoles, graphes, etc.)

• Le nombre et le contenu des fichiers de log

• La disponibilité d’agents pour des solutions de monitoring du marché (p.ex. BMCPatrol)

• L’étendue des interfaces (APIs) qui permettent de souscrire à des types d’événe-ments et par la suite de recevoir des notifications.

Observatoire Technologique 65

Page 68: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.3 Qualités de service

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La dimension des qualités de service permet d’analyser les propriétés d’un système endehors de son cadre purement fonctionnel. Ces propriétés déterminent la manière dontles utilisateurs (utilisateurs finaux, mais également administrateurs) perçoivent la qualitédu système (ou plus exactement du service rendu par le système).

Sous-dimensions

• Stabilité : mesure la fréquence, de la sévérité et de la prédictabilité des pannesauxquelles il est sujet.

• Disponibilité : mesure la proportion de temps avec laquelle il est capable d’accep-ter et de traiter des requêtes soumises par les utilisateurs.

• Performance : mesure la vitesse avec laquelle les tâches qui lui sont soumisessont traitées.

• Efficacité : mesure le rapport entre les performances d’un système et la quantitéde ressources lui étant allouée. A fonctions équivalentes et à ressources égales, unsystème plus efficace aura de meilleures performances.

Risques

Si cette dimension n’est pas prise en compte, le risque est de choisir ou de concevoir unsystème qui répond aux besoins fonctionnels des utilisateurs, mais qui ne permet pas deleur offrir un service utilisable en pratique (par exemple parce que les temps de réponsesont trop longs ou parce que le service est trop souvent inaccessible).

Observatoire Technologique 66

Page 69: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.3.1 Stabilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La stabilité d’un composant est fonction de la fréquence, de la sévérité et de la prédicta-bilité des pannes auxquelles il est sujet.

Couches concernées

• Système d’information. Si les systèmes informatiques et les outils qui sont utiliséspour la réalisation du système d’information ne sont pas stables, l’exécution desprocessus est affectée. C’est donc dans cette couche qu’on peut mesurer l’impactde la stabilité des composants du système.

• Application. Dans cette couche, la stabilité de l’application dépend de la qualité ducode produit par les développeurs métiers (mais elle dépend également de la stabi-lité des couches inférieures). Un grand avantage de l’organisation d’un système encouches est de séparer les aspects métiers des aspects techniques. Souvent, lesproblèmes de stabilité sont liés à des problèmes techniques, parfois complexes.

• Plateforme supérieure. Dans cette couche, c’est la stabilité des environnementsd’exécution de haut niveau (p.ex. les containers J2EE) qui est en cause. La stabilitédes composants qui vivent dans cette couche est cruciale, puisqu’elle a un impactsur l’ensemble des applications hébergées.

• Plateforme inférieure. Dans cette couche, c’est la stabilité du système d’exploitationet des librairies de bas niveau qui est mesurée. A nouveau, la stabilité est trèsimportante puisqu’elle impacte la stabilité de toutes les couches supérieures.

• Matériel. Dans cette couche, c’est la stabilité du matériel qui est mesurée.

Tiers concernés

• Client. Si les composants du tiers client ne sont pas stables, l’interaction utilisateuren sera grandement affectée. Par contre, si différents types de clients sont utiliséspour accéder aux mêmes services, il est possible que les problèmes soient canton-nés à un seul type de client (par exemple, il possible qu’un client lourd particuliersoit instable, alors que le client léger équivalent soit stable). D’autre part, il est pos-sible que le même client lourd soit stable sur certaines plateformes et instable surd’autres.

• Présentation. La stabilité dans le tiers de présentation a un impact supérieur, puis-qu’il affecte tous les composants clients qui lui adressent des requêtes. Ainsi, si le

Observatoire Technologique 67

Page 70: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

serveur physique sur lequel un serveur Web est installé est sujet à de nombreusespannes, l’ensemble de tous les clients sera bloqué régulièrement.

• Métier. La stabilité dans le tiers métier est également très importante puisque cedernier affecte tous les composants clients. Etant donné que certains composantsclients adressent parfois des requêtes directement au tiers métier (p.ex. un clientlourd qui contacte un EJB directement), l’impact se fait sentir sur un nombre decomposants encore plus grand.

• Ressources. La stabilité des composants du tiers ressources est absolument cru-ciale puisque lorsque ceux-ci sont indispensables au fonctionnement de l’ensembledes applications.

Risques

Si cette dimension n’est pas prise en compte, le risque est de choisir des composants quicausent un nombre élevé de pannes, avec des conséquences parfois lourdes ainsi qu’unefrustration des utilisateurs et des administrateurs. L’instabilité des composants se ressentau niveau du système d’information et a un impact sur la productivité des utilisateurs.

Mesures

• Quelle est la fréquence des pannes ? Les pannes sont-elles prédictibles ?

• Quel est l’impact des pannes (et quelles sont les personnes et processus affectés) ?

Aspects métier

Compétence

• La DTD, qui choisit et/ou développe les produits et composants standards

• Le développement, qui construit des applications sur cette base

• La production, qui choisit et configure les produits d’infrastructure (ce qui a un im-pact sur leur stabilité)

Divers

Exemples :

• Le choix d’un container J2EE. Lors du choix d’un container J2EE, il est importantde mesurer sa stabilité. En effet, cette stabilité a un impact direct sur la stabilité desapplications déployées dans le container.

Contre-exemples :

Observatoire Technologique 68

Page 71: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Une application métier. Une application métier qui demande à l’utilisateur de rem-plir des formulaires et qui faillit inopinément et de façon régulière, avec pour consé-quence la perte de toutes les informations saisies.

Observatoire Technologique 69

Page 72: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.3.2 Disponibilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La disponibilité d’un composant mesure la proportion de temps durant laquelle il est ca-pable d’accepter et de traiter des requêtes. La disponibilité est souvent exprimée parun pourcentage. Il convient de faire la différence entre les périodes d’indisponibilité pla-nifiées (certains systèmes sont arrêtés volontairement toutes les nuits) et les périodesd’indisponibilité non planifiées (conséquences de pannes et d’incidents).

Couches concernées

• Système d’information. Si les systèmes informatiques et les outils qui sont utiliséspour la réalisation du système d’information ne sont pas disponibles, l’exécution desprocessus est affectée. C’est donc dans cette couche qu’on peut mesurer l’impactde la disponibilité des composants du système.

• Application. Dans cette couche, une question intéressante est de spécifier et mesu-rer la disponibilité d’un service particulier. Tous les services ne présentent pas lesmêmes contraintes. Certains services sont utilisés uniquement pendant les heuresde bureau et par une population réduite. D’autres services sont utilisés en 24/7 etpar une population très importante.

• Plateforme supérieure. Les composants de la plateforme supérieure ont un impactsur la disponibilité des applications à plusieurs points de vue. D’une part, si ilssont indisponibles (à la suite d’une panne), les applications le deviennent égale-ment. D’autres part, ils offrent des mécanismes (p.ex. clustering) qui permettentd’augmenter la disponibilité du système. Les contraintes de disponibilité (au niveauapplicatif) ont un impact sur le choix du container (les containers offrent des méca-nismes plus ou moins sophistiqués de haute disponibilité).

• Plateforme inférieure. Dans cette couche, la disponibilité est fonction de la stabi-lité du système d’exploitation. Des pannes imputables au système d’exploitationpeuvent rendre le système indisponible. D’autre part, certains systèmes d’exploita-tion offrent des mécanismes de haute disponibilité (p.ex. clustering).

• Matériel. La fréquence des pannes imputables au matériel a un impact sur la dis-ponibilité du système.

Tiers concernés

• Client. Les composants du tiers client ne sont pas vraiment concernés par les as-pects de disponibilité, puisque ce sont les composants qui contactent des serviceset leur soumettent des requêtes.

Observatoire Technologique 70

Page 73: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Présentation. La disponibilité d’un composant du tiers de présentation a un impactsur tous les clients qui lui soumettent des requêtes. Pour augmenter cette dispo-nibilité, on utilise souvent un mécanisme de réplication, i.e. on déploie le mêmecomposant (p.ex. un servlet) dans plusieurs containers organisés en batterie (der-rière un répartisseur de charge). Dans le cas où une panne survient sur un descontainers, les requêtes sont automatiquement routées vers un autre container.

• Métier. La disponibilité d’un composant du tiers métier a un impact sur tous les com-posants qui lui soumettent des requêtes (qu’ils soient situés dans le tiers client oudans le tiers présentation). Pour augmenter la disponibilité, on a souvent recoursà un mécanisme de clustering au niveau de la plateforme supérieure. Il faut no-ter que l’augmentation de la disponibilité se fait généralement au détriment de laperformance.

• Ressources. La disponibilité des ressources conditionne la disponibilité de tous lescomposants du système et est donc très importante. Pour augmenter cette dis-ponibilité, on utilise souvent un mécanisme de clustering au niveau du systèmed’exploitation.

Risques

Si cette dimension n’est pas prise en compte, le risque est de construire un systèmequi soit parfois inaccessible alors qu’il devrait l’être. Les conséquences se ressentent auniveau des utilisateurs qui sont dans l’incapacité de réaliser leurs tâches.

Mesures

• Quelle est la durée d’indisponibilité acceptable sur un/une journée/semaine/mois/année ?

• Quelle sont la fréquence et la durée des interruptions de services volontaires ?

• Quelle sont la fréquence et la durée estimées des interruptions de services involon-taires ?

Aspects métier

Compétence

• La DTD, qui propose des mécanisme de haute disponibilité dans les couches Ap-plication et Plateforme supérieure.

• La maîtrise d’ouvrage, qui spécifie les besoins en termes de disponibilité.

• La production, qui choisit les mécanismes de haute disponibilité dans les couchesPlateforme inférieure et Matériel.

Observatoire Technologique 71

Page 74: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Divers

Exemples :

• Cluster. Au CTI, certaines bases de données sont mises en cluster.

Contre-exemples :

• Une base de données Access utilisée pour générer un site Web dynamique. Cer-taines pages du site geneve.ch sont générées sur la base de scripts ASP et d’unebase données Access, qui est régulièrement indisponible.

Observatoire Technologique 72

Page 75: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.3.3 Performance

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La performance d’un système mesure la vitesse avec laquelle les tâches qui lui sont sou-mises sont traitées. Dans certaines situations, la mesure la plus importante est le débit(nombre de tâches effectuées pendant une unité de temps). Dans d’autres situations,c’est le temps de réponse individuel qui est plus important. Il faut également prendre encompte la notion de performance perçue. En effet, même si le temps de réponse est lemême, deux interfaces peuvent donner une impression différente aux utilisateurs (p.ex.lorsque des barres de progression sont utilisées).

Couches concernées

• Système d’information. La performance des composants du système a un impactsensible au niveau du système d’information. Les processus définis dans cettecouche impliquent en effet l’utilisation de services par les utilisateurs. Si les per-formances de ces services sont insuffisantes, la producitivité des utilisateurs en estaffectée.

• Application. Dans cette couche, c’est la performance d’un service particulier quidoit être spécifiée et mesurée. Dans le cas de services batch, c’est généralement ledébit qui est optimisé. Dans le cas de services interactifs, c’est le temps de réponsequi est optimisé. La conception de l’interface utilisateur doit également être prise encompte, puisqu’elle a un impact sur la performance telle qu’elle est perçue par lesutilisateurs.

• Plateforme supérieure. Dans cette couche, les composants ont un impact sur laperformance des services construits au niveau supérieur. Dans le cas de J2EE, parexemple, les performances d’un container Web particulier on un impact sur les per-formances des servlets qu’il héberge. D’autre part, les mécanismes de répartitionde charge offerts à ce niveau permettent de conserver un niveau de performancemalgré une augmentation de la charge (scalabilité).

• Plateforme inférieure. Dans cette couche, la performance du système d’exploitationet des librairies de bas niveau ont un impact sur les composants des couches supé-rieures. Par exemple, différentes implémentations de la pile TCP/IP peuvent avoirdes performances très différentes.

• Matériel. Le choix du matériel a évidemment un impact considérable sur les perfor-mances du système. Augmenter les ressources (CPU, mémoire, cartes d’E/S, etc.)d’un serveur permet souvent d’améliorer les performances d’un service. De plus,les coûts des ressources matérielles diminuant, il s’agit là d’une approche souventavantageuse.

Observatoire Technologique 73

Page 76: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Tiers concernés

• Client. Le tiers client est particulièrement concerné par la performance perçue, puis-qu’il héberge l’interface utilisateur. Dans le cas d’interfaces complexes (p.ex. logicielde visualisation scientifique), la performance est une dimension à considérer à partentière dans ce tiers.

• Présentation. Dans ce tiers, c’est la performance des services de présentation quiest étudiée. Dans le monde J2EE, c’est typiquement les performances des serv-lets/JSPs et des containers les hébergeant qui est intéressante. De ce fait, ce sontaussi bien les développeurs de servlets, que les fournisseurs du container qui af-fectent les performances. D’autre part, le nombre et les caractéristiques des ser-veurs se répartissant la charge ont un impact sur les performances du système.

• Métier. Dans ce tiers, c’est la performance des services encapsulant la logiquemétier qui est analysée. Dans le monde J2EE, ce sont donc les performancesdes EJBs et des containers les hébergeant qui sont concernées. Dans ce tiers,la conception du système distribué (p.ex. la stratégie de distribution, le choix d’in-terfaces locales ou distantes) ont un impact considérable sur les performances dusystème.

• Ressources. Dans ce tiers, ce sont les performances des bases de données, desannuaires et d’autres systèmes qui sont concernées. Ces performances dépendentaussi bien de la qualité de l’implémentation des éléments logiciels, que des res-sources matérielles affectées aux serveurs les hébergeant.

Risques

Si cette dimension n’est pas prise en compte, le risque est de réaliser un ensemble deservices qui ne permettent pas d’absorber la charge de travail souhaitée. Dans le cas oùle débit n’est pas assuré, le risque est de ne pas pouvoir fournir les résultats dans le délaisouhaité. Dans le cas où les temps de réponse sont trop longs, le risque est d’affecter letravail des utilisateurs, de réduire leur productivité et d’augmenter leur frustration.

Mesures

• Combien de tâches peuvent être traitées par le système en une seconde/minute/heure/journée ?

• Quels sont les temps de réponse moyen et maximaux souhaités et/ou mesurés ?

• Quelle est la perception des utilisateurs par rapport aux performances du système ?

Aspects métier

Compétence

• La DTD, qui propose un ensemble de bonnes pratiques pour obtenir de bonnesperformances au niveau applicatif

Observatoire Technologique 74

Page 77: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• La maîtrise d’ouvrage, qui spécifie les besoins en termes de performance

• La production, qui choisit les éléments des couches Matériel et Plateforme infé-rieure et prend en charge la configuration de ces composants.

Divers

Exemples :

• Affichage de l’état d’avancement : Lorsqu’une opération prend un certain temps (i.e.le temps de réponse est relativement long), il est important de donner une indicationde la progression à l’utilisateur. Le mécanisme le plus commun est d’utiliser unebarre de progression.

Observatoire Technologique 75

Page 78: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.3.4 Efficacité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

L’efficacité d’un système mesure le rapport entre les performances d’un système et laquantité de ressources qui lui est allouée. A fonctions équivalentes et à ressourceségales, un système plus efficace aura de meilleures performances.

Couches concernées

• Système d’information. Dans cette couche, l’efficacité peut se mesurer en termeshumains. Un système efficace permettra d’obtenir les mêmes résultats avec moinsd’effort. Par exemple, l’automatisation de processus permet d’améliorer l’efficacitédu système d’information.

• Application. Dans cette couche, on peut être intéressé par les gains en efficacitéqu’une certaine application permet d’obtenir (au sens décrit dans la couche sys-tème d’information). D’un autre point de vue, on peut être intéressé par la manièreplus ou moins efficace selon laquelle une certaine application a été réalisée (i.e. enanalysant le nombre de ressources qu’elle consomme par rapport à ses caractéris-tiques).

• Plateforme supérieure. Dans cette couche, c’est l’efficacité de composants tels queles serveurs d’application qui est étudiée. Dans le cas de la plateforme J2EE, lescontainers proposés par différents constructeurs demandent des quantités de res-sources différentes.

• Plateforme inférieure.

• Matériel. La mesure de la performance dans cette couche demande une certaineattention. Certaines mesures, comme la fréquence des CPUs, ne reflètent que par-tiellement la puissance d’un serveur.

Tiers concernés

• Client. Dans le tiers client, l’efficacité d’un composant affecte le choix du postede travail des utilisateurs. En effet, si un composant a un degré d’efficacité faible, ilsera nécessaire de compenser cette faiblesse par des ressources matérielles (CPU,mémoire, etc.). Ceci aura donc un coût directement mesurable. Dans le cas où laconfiguration matérielle n’est pas modifiée, c’est la performance du composant quiest affectée. Si cette performance se dégrade trop, c’est ensuite l’utilisabilité ducomposant qui est atteinte.

Observatoire Technologique 76

Page 79: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Présentation. Dans le tiers de présentation, l’efficacité des composants a un impactsur les ressources matérielles du côté "serveur". En effet, beaucoup de systèmesmulti-tiers incluent une "ferme" de serveurs placés en parallèle et se partageant lacharge des requêtes utilisateurs. Bien qu’il soit possible rajouter des serveurs dansla "ferme" pour faire face à une augmentation de la charge (scalabilité), un faibledegré d’efficacité se traduira par un coût élevé en termes de ressource matérielles.

• Métier. La même remarque est valable pour le tiers métiers : des composants quin’ont pas été optimisés et ne sont pas très efficace devront être compensés par desressources matérielles.

• Ressources. La même remarque est valable pour le tiers ressources. On notera(c’est le cas pour les autres tiers également) que l’efficacité d’un composant ne dé-pend pas uniquement de sa conception (e.g. algorithmes, structures de données)mais également son paramétrage. La configuration d’un système de gestion debase de données, par exemple, peut être relativement complexe. En faisant variercertains paramètres, il est possible de mettre en oeuvre un environnement plus oumoins efficace. L’importance du "tuning" et de l’optimisation est donc très impor-tante.

Risques

Dans le cas où un composant a un faible degré d’efficacité, le risque est de devoir com-penser cette faiblesse par des ressources matérielles, ce qui engendre un coût sup-plémentaire. Un autre risque, dans le cas où des ressources matérielles ne sont pasajoutées, est d’avoir un faible niveau de performance.

Mesures

La mesure de l’efficacité peut se faire en termes très concrets, typiquement durant lesphases d’optimisation (que ce soit pendant le développement ou pendant le déploie-ment). Des mesures de temps de réponse, de débit, de nombre de clients supportéssont souvent faites et mises en relation avec des quantités de ressources (nombre deserveurs, architecture des serveurs, quantité de mémoire, etc.).

Compétence

Différents groupes et personnes ont une influence sur le système informatique et sescomposants. D’une part, les équipes de développement ont évidemment un impact déter-minant sur l’efficacité intrinsèque des composants. Le choix d’algorithmes et de structurede données appropriés et la mise en pratique de bonnes techniques de programmation(programmation distribuée, entrées/sorties, routines graphiques) jouent un rôle important.D’autre part, les équipes qui gèrent l’environnement d’exploitation ont un impact sur l’effi-cacité du système "en exécution". Ils peuvent faire varier le niveau d’efficacité du systèmeen configurant les composants (e.g. varier la taille d’une mémoire tampon interne), maiségalement en configurant leur environnement (e.g. varier des paramètres du systèmed’exploitation).

Observatoire Technologique 77

Page 80: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.4 Interopérabilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

L’interopérabilité peut être abordée selon deux points de vue :

• Premier point de vue (évaluation d’une solution métier à intégrer dans le systèmed’information) : cette dimension mesure la capacité d’un sous-système à interagiravec d’autres sous-systèmes qui ont été conçus indépendamment les uns desautres.

• Deuxième point de vue (évaluation d’une technologie d’intégration) : cette dimen-sion mesure le degré avec lequel, par exemple, la mise en oeuvre d’un bus demessages facilite l’interopérabilité entre les différents sous-systèmes du systèmed’information.

Sous-dimensions

• Ouverture : mesure l’étendue des interfaces publiques (et idéalement conformes àdes standards ouverts) qui donnent accès à ses fonctions.

• Standardisation : mesure le degré avec lequel il intègre des standards dans saconception, dans ses interfaces et dans sa documentation.

Couches concernées

• Système d’information. C’est dans cette couche qu’on peut mesurer le degré d’in-teropérabilité global du système d’information. Si les informations sont efficacementpartagées entre les différents sous-systèmes, si les flux d’information sont harmo-nieux, cela montre que les sous-systèmes sont interopérables.

• Application. C’est dans cette couche qu’on peut analyser le degré d’interopérabi-lité d’un sous-système particulier. Une analyse de l’architecture du sous-systèmepermet de mettre en évidence les interfaces (qu’ils s’agisse de services en ligne,d’APIs, de conventions d’échange d’information).

• Plateforme supérieure. Cette couche a un impact important sur la dimension. Eneffet, le choix de technologies appropriées dans cette couche est une façon d’aug-menter l’interopérabilité des systèmes. Cette couche offre par exemple des méca-nismes pour rendre la logique métier accessible sous la forme de services en ligne.

• Plateforme inférieure. Aujourd’hui, cette couche n’a plus un impact déterminant surl’interopérabilité des systèmes. L’hétérogénéité des systèmes d’exploitation n’estplus un obstacle à l’interopérabilité des applications.

Observatoire Technologique 78

Page 81: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Matériel. Aujourd’hui, cette couche n’a plus un impact déterminant sur l’interopéra-bilité des systèmes, à partir du moment ou des standards ont été adoptés dans lescouches supérieures, pour l’ensemble des plateformes matérielles.

Tiers concernés

• Client. L’interopérabilité dans le tiers client prend plusieurs aspects. Premièrement,on peut considérer l’interopérabilité entre la couche client d’un applicatif et la coucheclient d’un autre applicatif. Ceci permet des interactions, des échanges de donnéesentre plusieurs sous-systèmes au niveau de l’interface utilisateur. Deuxièmement,on peut considérer l’interopérabilité entre les différentes couches d’un seul et mêmeapplicatif. Le fait qu’une application soit accessible au travers de différents canaux(i.e. au travers de différentes couches client/présentation) démontre un certain de-gré d’interopérabilité.

• Présentation.

• Métier. Dans le tiers métier, l’interopérabilité permet de réaliser des workflows demanière transversale à plusieurs applicatifs. C’est dans ce tiers qu’on va pouvoirmesurer le degré d’interopérabilité d’un applicatif.

• Intégration. Le tiers intégration est fortement lié à la dimension d’interopérabilité.En effet, son rôle est de découpler la couche métier de la couche ressources, pourpermettre de modifier l’une sans affecter l’autre.

• Ressources. Lors du choix d’un composant dans le tiers ressources (par exempleune base de données, un annuaire), il est important de vérifier que ce composantoffre des interfaces standards, qui permettront une intégration dans l’architecturemulti-tiers, au travers de la couche intégration.

Risques

Si cette dimension est négligée, le risque est de construire un système d’informationqui n’ait pas une grande cohérence, avec des sous-systèmes isolés (silos) au traversdesquels il n’est pas possible de définir des workflows transversaux.

Mesures

L’interopérabilité d’un sous-système peut se mesurer en fonction des interfaces qu’il offre.En analysant ces interfaces, il convient de considérer plusieurs aspects comme :

• La couverture fonctionnelle des interfaces. Est-ce que les interfaces permettentune interaction avec l’ensemble de la logique métier, ou uniquement avec un sous-ensemble de celle-ci ?

• Le type d’échange supporté. Dans le même ordre d’idées, examiner le fait queles interfaces permettent uniquement de récupérer de l’information dans le sous-système (lecture) ou également de modifier de l’information (lecture et écriture)

Observatoire Technologique 79

Page 82: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• L’utilisation de standards. Examiner le fait que les interfaces soient construites surla base de méchanismes standards reconnus et adoptés (qu’il s’agisse d’APIs, deprotocoles, de formats de fichiers)

Aspects métier

Compétence

• Division technique de développement (CTI)

• Comité d’architecture technique (CTI)

Divers

Exemples :

• Le framework CTI : le framework CTI permettra une interopérabilité entre les ser-vices et les applications développées sur celui-ci.

• Les connecteurs implémentant la norme J2EE Connector Architecture

Standards

• Les architectures multi-tiers

• La standardisation et la publication des APIs

• Les technologies middleware : serveurs d’application, bus d’échange de messages

Observatoire Technologique 80

Page 83: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.4.1 Ouverture

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

L’ouverture d’un système mesure l’étendue des interfaces (APIs) publiques qui donnentaccès à ses fonctions. Idéalement, ces interfaces publiques implémentent des standards,spécifiés, publiés et adoptés par l’industrie. L’ouverture d’un système est un facteur d’in-teropérabilité très important, puisqu’elle permet à d’autres systèmes (et pas seulementaux utilisateurs) d’accéder aux fonctions du système.

Couches concernées

• Application. L’ouverture de cette couche est la plus importante, puisque c’est elle quidétermine dans quel degré les fonctions métier du système peuvent être utiliséespar d’autres systèmes informatisés.

• Plateforme supérieure. L’ouverture de la plateforme supérieure est un élément àconsidérer dans le cadre de l’administration et de la surveillance du système infor-matique. A ce niveau, l’ouverture d’un composant ne permet pas d’accéder à desfonctions métier, mais à des fonctions techniques. Par exemple, un serveur d’ap-plications peut offrir une interface qui permet à des clients de s’enregistrer et derecevoir des événements du système informatique (requêtes, erreurs, etc.).

• Plateforme inférieure. Le mécanisme décrit dans la couche précédente s’appliqueégalement à cette couche.

• Matériel. Au niveau du matériel, la notion d’ouverture veut dire que l’architectureet les interfaces des composants sont publiées. Ceci permet par exemple à desfournisseurs tiers de développer des composants qui s’intègrent à un composant"maître". Par exemple, un ordinateur personnel qui a une interface USB est "ouvert",dans le sens où des fournisseurs tiers peuvent développer des périphériques quis’intègrent à l’ordinateur.

Tiers concernés

• Client. Le tiers client permet souvent de mesurer le degré d’ouverture d’un sys-tème. Lorsque le système est ouvert, il est possible de développer un nouveauclient (par exemple sur un client mobile) sans avoir accès au code des composantsserveurs. Une organisation qui déploie un système ouvert bénéficie d’une grandesouplesse, puisqu’elle peut à tout moment décider de développer un nouveau canald’accès aux services fournis par le système. Une autre perspective sur le tiers clientconsiste à considérer les clients lourds. Certaines applications de ce type offrent unmécanisme de plugs-in, qui permet aux développeurs d’étendre les fonctions de

Observatoire Technologique 81

Page 84: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

l’application en implémentant des modules conformes à une API spécifiée. Le faitque cette API soit publique est un signe d’ouverture.

• Présentation. Dans certains systèmes, le tiers de présentation représente le “pointd’ouverture”, dans le sens où il offre le point d’accès aux fonctions du système.C’est par exemple le cas avec les technologies des web services.

• Métier. C’est dans ce tiers que le degré d’ouverture est véritablement défini. Eneffet, l’interface qui permet d’accéder aux fonctions du système (API) et son degréde visibilité (les services sont-ils privés ou publics ?) est définie ici.

• Intégration. L’existence d’un tiers d’intégration indique en général un certain degréd’ouverture pour le tiers des ressources. En effet, pour qu’il soit possible d’accéderà des fournisseurs de ressources depuis le tiers métier, il faut que ces fournisseursde ressources offrent des interfaces publiques.

• Ressources. Dans le cas d’architecture multi-tiers modernes, les composants dutiers ressources sont généralement ouvertes. C’est typiquement le cas pour lessystèmes de gestion de base de données, qui peuvent être accédées au moyen deprotocoles publics et standardisés. Néanmoins, certaines applications (on peut ci-ter le cas d’applications “lourdes” déployées sur un poste de travail) stoquent leursdonnées d’une manière qui n’est pas documentée. Dans ce cas, il peut ne pas êtrepossible d’accéder aux données depuis d’autres composants (services et applica-tions).

Risques

L’ouverture est aujourd’hui reconnue commé étant une qualité très importante des sys-tèmes informatiques. Une organisation qui opte pour un système fermé risque de rencon-trer des problèmes lors de l’intégration de ce système dans son infrastructure existante.Même lorsque cette intégration est réalisable, l’organisation risque de subir un manquede souplesse et des difficultés d’adaptation lors de l’évolution du système d’informationglobal.

Mesures

L’étendue des interfaces de programmation (APIs) et la documentation de ces interfacesest une bonne mesure de l’ouverture d’un système. Le fait que le système ait adopté desstandards ouverts lors de la conception de ces interfaces en est une autre.

Observatoire Technologique 82

Page 85: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

5.4.2 Standardisation

Révisions

Version Date / auteurs Objet de la révision0.1 2003-09-11 / oli Version initiale

Description

La standardisation d’un système mesure le degré avec lequel il intègre des standardsdans sa conception (standards architecturaux, standards techniques, standards métiers),dans ses interfaces (standards au niveau de l’interface utilisateur, standards de fichiers,standards d’intégration, standards de contrôle et d’administration), dans sa documenta-tion.

Les standards auquels un système se conforme peuvent être aussi bien des standardsinternes à l’organisation, que des standards propriétaires ou des standards ouverts.

Couches concernées

• Système d’information. Au niveau du système d’information, la notion de standar-disation est associée à la notion d’urbanisation. A ce niveau, l’enjeu est en effetde rendre le système d’information cohérent en appliquant un ensemble de règleset de mécanismes au travers de tout le système. Dans ce cas, les standards sontdéfinis par les concepteurs du système (i.e. par l’organisation).

• Application. Dans cette couche, plusieurs types de standards peuvent être consi-dérés. Le premier type de standards est lié au développement des composants.Il existe des standards de méthodologie (p.ex. Unified Process), de modélisation(p.ex. Unified Modeling Language), de conception (p.ex. les design patterns) ou en-core de codage. Le deuxième type de standards est lié à des problèmes techniquesparticuliers (gestion de l’interface utilisateur, accès à une base de données, notifi-cation asynchrone). Dans ce cas, c’est souvent la couche Plateforme supérieurequi met à disposition une implémentation des standards. Cette implémentation estutilisée par les composants de la couche Application.

• Plateforme supérieure. C’est dans cette couche que beaucoup de standards tech-niques sont choisis et implémentés. A ce niveau l’organisation peut faire le choixentre une plateforme de développement ouverte (p.ex. Java 2 Enterprise Edition)ou propriétaire (p.ex. Microsoft .Net). Le respect des standards dans cette coucheest très important, puisqu’il permet à l’organisation de garder son indépendancepar rapport à un fournisseur particulier. En effet, en développant son système au-dessus d’une plateforme basée sur des standards ouverts, l’organisation peut à toutmoment remplacer le ou les produits implémentant ces standards (e.g. remplacer leserveur d’applications du fournisseur X par un serveur d’applications du fournisseurY).

• Plateforme inférieure.

• Matériel.

Observatoire Technologique 83

Page 86: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Tiers concernés

• Client.

• Présentation. Le choix de technologies standards dans ce tiers facilite l’accès auxservices par des clients existants. Par exemple, une application qui offre une in-terface développée au dessus de HTTP/HTML est accessible au travers de tousles navigateurs Web. Cette approche est à opposer avec une application client-serveur qui offrirait une interface non-standard et qui demanderait l’implémentationde clients spécifiques. Les technologies de Web services sont à prendre en comptedans ce contexte.

• Métier. Standards métiers.

• Intégration. Les standards définis dans ce tiers mettent en avant le découplageentre le tier "métier" et le tier "ressources". Les technologies d’intégration per-mettent aux composants applicatifs d’accéder à des données (par exemple, uncomposant "contrôle des habitants" accède aux données "citoyen" grâce à la tech-nologie JDBC). En choisissant une technologie d’intégration standard, l’organisa-tion se donne la possibilité de choisir le produit implémentant ce standard, sansse lier à son fournisseur. Par exemple, en utilisant le standard JDBC, l’organisationpeut stocker ses données dans n’importe quelle base de données offrant un piloteJDBC. Le principe est le même que pour la couche Plateforme supérieure.

• Ressources.

Risques

En intégrant des composants qui n’adhèrent pas aux standards adoptés par l’industrie,une organisation risque de se placer dans une situation de dépendance par rapport auxfournisseurs de ces composants (il lui sera en effet beaucoup plus difficile de rempla-cer ces composants). L’intégration de composants propriétaires avec les autres élémentsdu système sera également plus coûteuse puisqu’elle demandera beaucoup de dévelop-pements spécifiques (au lieu d’outils "prêts à l’emploi" souvent disponibles lorsque destechnologies standards sont adoptées).

Sur un autre plan, si une organisation néglige la standardisation de ses principes archi-tecturaux, de ses méthodes de développement, de sa documentation, elle s’expose à unmanque de cohérence de l’ensemble du système, à des problèmes de maintenance etd’évolution. Le coût associé peut alors être très important.

Mesures

Les questions suivantes permettent d’évaluer quelques aspects liés à cette dimension :

• Le système offre-t-il des interfaces (formats de fichiers, APIs, technologies distri-buées, interfaces physiques, etc.) qui implémentent des standards adoptés par l’in-dustrie ?

Observatoire Technologique 84

Page 87: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Le système est-il constitué de composants qui sont conformes aux standards spé-cifiés par l’organisation ?

• Le système est-il constitué de composants qui sont conformes à des standardsouverts ?

• Le système a-t-il été implémenté en suivant des standards d’architecture, de concep-tion et d’implémentation (que ceux-ci soient définis par l’organisation ou par unecommunauté plus large) ?

• Le système peut-il être mis en production, administré et maintenu d’une manièrequi soit cohérente avec l’ensemble du système informatisé de l’organisation ?

Aspects métier

Compétence

• Comité d’Architecture Technique (CTI)

Références

Normes et standards ouverts, Annexe au rapport final du projet NPT, Observatoire Tech-nologique 2003, http://www.geneve.ch/obstech/referentiel/referentiels.html

Observatoire Technologique 85

Page 88: Le Référentiel Nouvelles Plateformes Technologiques

Chapitre 6

Dimensions relatives àl’Organisation

Les dimensions Facteurs économiques et Formation et organisation ont été regroupéessous le label commun Dimensions relatives à l’organisation. Ces dimensions, ainsi queles sous-dimensions correspondantes prennent en compte les aspects touchant très di-rectement à l’organisation nécessaire à la mise en oeuvre d’une technologie ou d’uncomposant informatique.

86

Page 89: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

6.1 Aspects économiques

Révisions

Version Date / auteurs Objet de la révision0.1 2003-08-18 / gpl Première version0.2 2003-08-19 / gpl Intégration en une seule dimensions des as-

pects économiques ; notion d’externalité.0.3 2003-10-09 / gpl Introduction des options réelles

Description

La complexité des décisions d’investissement dans les TIC ne peuvent pas être cap-turées par une seule métrique telle que le Total Cost of Ownership ou une analysecoûts/bénéfices. Une approche globale telle que celle préconisée dans ce référentiel,où la dimension économique joue un rôle important mais pas unique, est à privilégier.Dans le secteur public, des notions qualitatives seront aussi nécessaires pour jauger lavaleur d’un investissement informatique.

Evaluer la valeur d’un projet informatique est une tâche difficile principalement pour deuxraisons. La première est que l’environnement informatique est rarement vierge et les nou-veaux projets dépendent des autres technologies existantes, notamment de leur qualitéssystémiques et de leur intégration. La seconde raison tient au fait que les investissementinformatiques sont rarement effectués pour une raison purement technique : ils font engénéral partie d’un cadre plus large, demandant une vision des aspect liés aux métiersou à l’organisation interne.

Ces difficultés rendent l’évaluation économique d’un projet informatique délicate et laprécision de l’évaluation est en général faible.

La plupart des organisations sont confrontées à deux grandes catégories de projets liésaux TIC :

1. les projets visant à une réduction des coûts,

2. les projets qui permettent de créer de nouvelles perspectives.

Dans le premier cas, une approche “classique” d’évaluation économique est préconisée :les incertitudes sont faibles et les calculs de ROI ou de valeur actualisée sont pertinents.Pour cette approche on se rapportera à la section “Analyse côuts / bénéfices”.

Dans le second, en revanche, le facteur temps est une variable beaucoup plus impor-tante. Le but est d’intégrer non seulement les métiers et la technologie, mais aussi lesacteurs et les étapes dans une vision unique. Les décisions dans ce type de projet sontsouvent séquentielles : l’arrêt ou la continuation du projet dépendent d’informations ré-coltées au cours des étapes précédentes et sont aussi influencés par un futur incertain.Ce cas demande une approche plus fine et sophistiquée intégrant la dynamique des évé-nements. L’analyse des options réelles propose une méthodologie tenant compte de cesaspects et est présentée dans la section “Options réelles” ci-dessous.

Observatoire Technologique 87

Page 90: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Analyse coûts / bénéfices

Les investissements informatiques envisagés sont évalués par rapport à leur efficacitééconomique. Un budget est estimé pour la première année ainsi qu’un coût de fonction-nement pour les années suivantes. Le tableau ci-dessous résume les grandes catégoriesde coûts dont il faut tenir compte lors de l’analyse. Les sources de financement n’in-fluencent pas directement l’efficacité économique du projet envisagé, mais peuvent avoirun rôle quant à la disponibilité des ressources prévues au budget.

La période de temps sur laquelle porte le calcul correspond au cycle de vie du systèmeenvisagé, en particulier les étapes : Etude de plausibilité, Conception, Développement,Réalisation, Mise en œuvre et Maintenance.

L’analyse doit également considérer plusieurs alternatives (trois au moins) pour l’obten-tion des objectifs du projet, l’une de celles-ci étant de continuer sans changement (statuquo).

L’identification, la description et l’estimation des bénéfices et des coûts doit être faite dela façon la plus rigoureuse possible. Le niveau de détail de l’analyse dépend de l’objetexaminé : un grand projet, complexe et coûteux sera détaillé plus finement qu’un projetde plus petite envergure.

Les estimations doivent être explicites quant aux hypothèses faites pour aboutir aux va-leurs présentées. Les valeurs non tangibles doivent également être incluses en évaluantleur importance.

Les effets indirects, aussi appelés externalités, sont des bénéfices ou des coûts qui nesont pas pris en compte dans le projet courant. Ces externalités sont typiques dans lesbiens ou services publics, notamment pour les investissements d’infrastructure, qui pro-fitent à un ensemble d’acteurs, mais dont aucun ne veut supporter le coût. Une “inter-nalisation” des coûts (ou des bénéfices) est nécessaire pour éviter une distorsion del’analyse.

Par ailleurs, les propriétés de non-rivalité (une unité consommée par un agent peut aussiêtre consommée par un autre sans diminution de satisfaction) et de non-exclusion (onne peut pas en restreindre facilement la consommation à un agent ou à un groupe) ca-ractérisent les biens publics. Ceux-ci ne répondent pas aux mêmes mécanismes que lesbiens habituels dont les échanges (les prix et les quantités) sont régulés optimalementpar un marché concurrentiel et doivent en conséquence être traités de façon différente.

Le but n’est pas de sélectionner le portefeuille d’investissements informatiques unique-ment sur des aspects financiers, mais de trouver l’alternative la plus rationnelle économi-quement.

Les coûts déjà encourus dans le passé ou les bénéfices déjà réalisés ne doiventen aucun cas être considérés.

Les grandes étapes d’une analyse économique sont les suivantes :

1. Définir les objectifs. Les objectifs du projet et les autres informations pertinentessur l’environnement de celui-ci doivent être incluses de façon à permettre à unepersonne externe au projet de comprendre ses buts.

2. Documenter l’existant. La ligne de base pour l’analyse sont les systèmes et les

Observatoire Technologique 88

Page 91: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

processus existants. C’est à partir des informations concernant ces éléments quede nouvelles alternatives sont considérées. Les domaines principaux à documentersont : les services utilisateur, les capacités du système, l’architecture technique etles coûts (et éventuellement les revenus) du système.

3. Estimer les besoins futurs. Les besoins déterminent les capacités et l’architec-ture des systèmes, qui à leur tour influencent les coûts et les bénéfices. Il est trèsimportant d’estimer avec le plus de précision possible les besoins futurs. Les deuxéléments clé dont il faut tenir compte sont le cycle de vie du système et la demandede pointe que le système devra absorber.

4. Recueillir les données. Afin d’estimer les coûts et les bénéfices de chaque alter-native, il est nécessaire d’apprécier les quantités demandées à l’aide des donnéeshistoriques de l’organisation, des coûts du système actuel, des analyses de mar-ché, d’informations publiées, de jugements d’analystes et d’études spécifiquementdemandées.

5. Décrire au moins trois alternatives. L’analyse doit présenter au moins trois al-ternatives. L’une de celles-ci doit être la continuation du service sans modifica-tion. Chaque approche technique viable peut représenter une alternative différente.Cette contrainte ne peut être levée que si le coût du projet est suffisamment faiblepour pouvoir le justifier.

6. Documenter les hypothèses. Il est important de spécifier clairement les hypo-thèses sous-jacentes à l’analyse qui est faite et de les justifier sur la base d’expé-riences ou des données réelles. Cette partie permet également d’expliquer pour-quoi certaines alternatives n’ont pas été inclues dans l’analyse.

7. Estimer les coûts. Plusieurs facteurs doivent être pris en compte lors de l’évalua-tion des coûts comme par exemple le matériel, le logiciel, les ressources humaines,la formation, les infrastructures nécessaires. Tous ces coûts supportés au cours ducycle de vie doivent être inclus. On peut citer notamment :

• les coûts d’acquisition,• les coûts de développement,• les coûts de déploiement,• les coûts de maintenance,• les coûts de substitution (reprise de l’existant),• les coûts de personnel (interne et externe),• les coûts de modification de processus (souvent négligé).

8. Estimer les bénéfices. Estimer les bénéfices est probablement la partie la plusdélicate de l’analyse. Ces bénéfices doivent être identifiables comme par exemplela réduction de temps d’exécution d’une tâche ou l’amélioration de la qualité durésultat. Des bénéfices globaux comme la flexibilité, l’organisation stratégique, lagestion du risque de l’unité peuvent également entrer dans le calcul. La notionde bénéfice citoyen expliquée dans les éléments en annexe est également trèsimportante.

9. Décrire les bénéfices ou les coûts non tangibles. Certains bénéfices liés auprojet ne peuvent pas être chiffrés monétairement dans les rubriques précédentes.Evaluer l’importance de chacun de ceux-ci sur l’échelle -2, -1, 0, +1, +2.

Observatoire Technologique 89

Page 92: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Produit des bénéfices élevés : +2Produit des bénéfices : +1Ne produit ni coûts ni bénéfices : 0Produit des coûts : -1Produits des coûts élevés : -2

10. Actualiser les coûts et les bénéfices. Après que les coûts et bénéfices aientété identifiés et quantifiés, il faut les traduire en unités monétaires de la périodecourante. Pour ce faire on calcule une valeur actuelle actualisée dans le temps àl’aide de la formule P = F/(1 + i)n où P est la valeur actuelle, F la valeur future, ile taux d’actualisation et n le nombre d’années. Le taux d’actualisation est fixé enfonction notamment du taux d’intérêt du marché.

11. Evaluer les différentes alternatives. Effectuer les estimations et calculs pour lesalternatives proposées. L’exercice est important pour pouvoir déterminer quelle al-ternative semble la plus rentable. Néanmoins, des facteurs tels que la taille du bud-get ou que les bénéfices non quantifiables entrent aussi largement en compte lorsde l’évaluation d’un projet.

12. Effectuer une analyse de sensibilité. La fiabilité des résultats doit être testéepour s’assurer de la qualité des résultats obtenus. Lors de la prise de décision, ilest probable que le réviseur de l’analyse demande l’impact qu’une variation d’unparamètre aurait sur l’analyse. Les paramètres qui sont les plus susceptibles devarier sont les demandes de pointe du système, les coûts en ressources humaines,les bénéfices estimés et le taux d’actualisation.

Options réelles

La plupart des projets informatiques stratégiques contiennent plusieurs sources de risqueet d’incertitude. Ces éléments doivent être reconnus et gérés. L’une des manières de lescontrôler est d’investir séquentiellement et redimensionner le projet au fur et à mesureque les incertitudes s’effacent.

La théorie des options réelles permet de tenir compte de ces incertitudes et de poser desjalons pour intégrer de nouveaux éléments d’information dans le processus de décision.

De façon simplifiée, une option est une assurance qui permet, lorsqu’on l’acquiert, de seprotéger en la faisant intervenir le cas échéant.

La notion d’option est d’abord apparue dans le monde de la finance. Savoir quel prixfixer à ce type de “contrat d’assurance” a longtemps été étudié et débattu. En 1973, leschercheurs Black, Scholes et Merton ont trouvé une formule permettant de déterminer lavaleur d’une option financière, ce qui leur a valu le prix Nobel en 1997.

Une option en finance est un contrat conférant le droit d’acheter (option d’achat, “call” )ou de vendre (option de vente, “put” ) une quantité spécifiée d’un actif (sous-jacent del’option), à un prix déterminé d’avance (prix d’exercice), à une échéance donnée (optioneuropéenne) ou tout au long d’un intervalle de temps spécifié (option américaine).

Les options réelles se fondent sur un concept similaire aux options financières, mais ontpour objet l’étude des investissements des entreprises. Alors que les options financières

Observatoire Technologique 90

Page 93: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

sont des contrats détaillés et traités sur des marchés organisés ou de gré à gré, lesoptions réelles sont plus difficiles à identifier et à spécifier. Elles existent de manièrenaturelle au sein d’un projet risqué, lorsque celui-ci offre des flexibilités opérationnelles oustratégiques, c’est-à-dire lorsque les décideurs ont des choix alternatifs dans la gestionde l’investissement ou simplement lorsque l’on peut attendre avant d’investir.

Quatre conditions sont nécessaires pour qu’un projet possède une option réelle.

Tout d’abord, le projet doit contenir une composante irréversible (au moins partielle-ment), car sans cette modalité les dépenses peuvent toujours être récupérées, ce quirend l’analyse inutile.

Ensuite le projet comportera une part de risque. Si la valeur du projet n’est pas affectéepar les événements et les états différents de la nature, l’incertitude n’existe pas et lavaleur d’option est nulle.

De plus, les décideurs doivent avoir une liberté d’action sur le projet. Le projet doit doncposséder une certaine flexibilité. Les options, qui permettent de valoriser les marges demanœuvre existantes, ne peuvent prendre un sens que si la possibilité d’influencer lecours du projet existe réellement.

Finalement, le dernier élément essentiel est l’horizon temps. Un laps de temps doit êtreprésent pour permettre l’exercice (ou non) de l’option. Plus ce temps est court, plus lavaleur de l’option est faible et, à la limite, lorsque celui-ci est inexistant, la valeur devientnulle.

L’analyse traditionnelle de l’analyse coûts/bénéfices et les critères tels que la va-leur actuelle nette ou le ROI possèdent un inconvénient majeur. Ils n’intègrent pasla possibilité d’adopter une démarche active dans la gestion, par exemple en mo-difiant l’échéancier ou l’évolution du projet.

La littérature des options réelles distingue généralement sept catégories. Elles sont briè-vement présentées ci-dessous dans un ordre croissant de complexité.

1. L’option de reporter. Reporter un investissement est sans doute l’option la plussimple (le terme anglais pour cette option est “option to delay” ). La flexibilité intro-duite est donnée par la possibilité d’obtenir plus d’informations pertinentes concer-nant, par exemple, les coûts, les conditions du marché ou l’évolution d’un produitentrant dans le projet avant de le faire démarrer.

2. L’option d’abandonner. Cette option permet de renoncer complètement à l’inves-tissement (“abandonment option” ). Elle annule les coûts associés au maintien duprojet et permet de réaffecter les ressources libérées. Lorsque le projet exige desdépenses continuelles pour être maintenu en vie, les économies réalisées par unabandon sont substantielles.

Cette option permet aussi de mettre en évidence les aspects positifs souvent igno-rés par le détenteur de l’option, comme le savoir-faire technologique ou les compé-tences organisationnelles acquises au cours du projet.

Dans une approche plus classique, l’abandon est considéré comme un échec, alorsque ses caractéristiques positives peuvent être mises en valeur par cette approche.

3. L’option de renoncer à l’investissement en cours. Les projets, ainsi que les in-vestissements liés à ceux-ci, procèdent souvent par phases successives (“time to

Observatoire Technologique 91

Page 94: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

build option” ). L’option de renoncer en cours de réalisation, souligne la flexibilité quirésulte de l’alternative se présentant à chaque étape : consentir à continuer le projetsi les informations et l’environnement sont favorables, ou renoncer à le poursuivredans le cas contraire.

Cette option est en quelque sorte une généralisation du cas de l’option d’abandon-ner : un grand projet est découpé séquentiellement, et à chaque étape une optiond’abandon est analysée, le coût d’opportunité du projet étant ré-évalué.

Ce type d’option est beaucoup plus complexe à mesurer que la précédente catégo-rie, car les options sont imbriquées à chaque étape.

Le prototypage (sites pilotes) peut être facilement inclus dans ce type d’options, entenant compte du fait que le projet possède des coûts et des revenus à chaquejalon, mais que l’information retirée et l’écoulement du temps amènent une valeurd’option au projet.

4. Les options de modifier l’intensité. Dans ce type d’options on considère la pos-sibilité d’augmenter, de diminuer ou même d’arrêter momentanément les investis-sements (“options to alter operating scale” ). Ce cas se présente plutôt dans lesprojets d’exploitation. Ces options sont utiles pour faire face à une demande ou uneoffre variables. Le coût permettant de bénéficier de cette flexibilité est celui de pré-voir une technologie permettant de s’adapter. Ceci peut aussi être assuré par descontrats externes permettant de faire face à une demande accrue ou au contrairepour externaliser les coûts.

5. Les options d’échange. Elles permettent de modifier les sources à partir des-quelles la production finale est bâtie ou, inversement, les résultats de la productionen gardant les mêmes inputs (“options to switch use” ).

Cette option est intégrée dans les projets lorsque, par exemple, ceux-ci utilisent destechnologies reposant sur des standards qui permettent facilement de changer deséléments indépendamment les uns des autres.

6. Les options de croissance. Ces options (“growth options” ) sont utilisées dansune optique de stratégie à long terme. Elles regroupent des caractéristiques desoptions d’abandon en cours de réalisation, des options d’échange et des optionsde modifier l’intensité. Elles offrent un cadre conceptuel pour analyser une stratégiede développement global d’une organisation ou les relations de partenariat avecd’autres entreprises.

7. Les options multiples interactives. La réunion de plusieurs options et leur inter-relations donne lieu à cette catégorie (“multiple interacting options” ). Par exemple,elles émergent naturellement lorsque l’on considère l’ensemble des options quiapparaissent dans différents projets. Elles sont qualifiées d’interactives car ellespeuvent avoir des influences les unes sur les autres et, de ce fait, leur agrégationpeut devenir complexe.

L’analogie entre options financières et options réelles permet d’identifier les facteurs quiinfluencent la valeur de ces dernières. En adaptant les notions, ces facteurs sont : lesflux de revenus futurs et de dépenses à consentir, la variabilité de ceux-ci, l’échéance àla laquelle l’opportunité d’investissement disparaît ainsi que le niveau et la volatilité dutaux d’intérêt hors risque.

Observatoire Technologique 92

Page 95: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Le caractère asymétrique d’une option introduit un effet positif dans le projet auquel elleest attachée : la valeur de l’option ne pouvant être que positive ou nulle, la distributiondes gains nets décalée vers les grandeurs positives. Ainsi, l’introduction d’options dansun projet ne peut qu’en augmenter la valeur. L’un des aspects intéressants est que cettevaleur augmente avec le niveau d’incertitude, puisque l’on possède le moyen de s’enprotéger.

La valorisation des options réelles reste un sujet délicat et difficile à mettre en œuvre. Lalogique introduite reste néanmoins importante et apporte au moins deux avantages. Pre-mièrement, celle-ci incite les acteurs à modifier leur comportement par rapport à l’incerti-tude en prenant en compte les avantages potentiels : la possibilité d’obtenir des résultatstrès positifs associés à des projets risqués. Deuxièmement, les options permettent devaloriser la flexibilité introduite dans un projet et à identifier des opportunités qui n’étaientpas mises en évidence auparavant. Il faut à nouveau souligner que l’incertitude valo-rise les projets intégrant des options réelles, alors qu’elle dévalorise les projetsstatiques.

On peut donc considérer les options réelles comme une cadre conceptuel important pouramener des notions de dynamique, de synchronisation et de risque dans les projets in-formatiques.

Couches concernées

Les aspects économiques peuvent se décliner sur les différentes couches concernéesselon les éléments qui sont touchés par le projet envisagé. La redéfinition de processuset de structures organisationnelles vient naturellement s’inscrire dans la couche du sys-tème d’information. Les logiciels acquis pour mettre en œuvre la solution sont comptabili-sés sous les couches application, plateforme supérieure, plateforme inférieure selon leurcaractéristiques. La couche matériel contiendra les dépenses afférentes aux serveurs,stations de travail et autres éléments physiques.

Tiers concernés

La distinction entre les différents tiers ne s’applique pas à cette dimension. Toutefois, laprise en compte d’une architecture par tiers permet d’introduire une flexibilité qui doit êtrevalorisée en termes d’options possibles.

Risques

• Le manque de prise en compte des aspects financiers dans un projet peut conduireà des investissements sous optimaux au point de vue économique.

• Les éléments futurs sont difficiles à estimer, bien qu’il soit indispensable de lesenvisager.

• Une vérification a posteriori afin d’éviter des abus n’est pas mise en œuvre. Dessolutions alternatives simples (p.ex. le statu quo ou une technologie très simple) ne

Observatoire Technologique 93

Page 96: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

sont pas incluses et comparées dans l’analyse parce qu’elles ne permettent pas dejustifier une dépense.

• Des éléments tels que les coûts de formation ou de mise à disposition de locaux nesont pas pris en compte ou sous-estimés dans l’analyse.

• Les effets indirects ou externalités ne sont pas considérés bien qu’il représententun impact important.

• Les coûts ou bénéfices déjà encourus dans le passé sont à nouveau considérés.

• Les aspect économiques et financiers prennent le dessus sur l’analyse plus globale,car ils sont quantifiables et permettent une comparaison facile des alternatives.

• Les notions d’incertitude et de risque sont uniquement perçus comme négatifs etne sont pas valorisés en termes d’options.

• La flexibilité du projet n’est pas reconnue et une approche “classique” d’évaluation(return on investement, valeur actuelle nette, etc.) pénalise le projet.

Mesures

Les éléments mise en évidence par une analyse coûts / bénéfices peuvent être utiliséspour calculer une valeur actualisée nette, un retour sur investissement, un taux de ren-dement interne, une période de repaiement ou un retour sur investissement.

La valeur d’option du projet doit être évaluée et intégrée, le cas échéant, à la mesureéconomique du projet.

Le projet vise-t-il une réduction des coûts ou une exploration de nouvelles perspectives ?

A-t-on évalué différentes alternatives du projet ?

Le projet contient-il des options qui permettent une flexibilité ? Par exemple, contient-ilune phase de prototypage ?

Compétence

• Responsables budgétaires et financiers.

• Commission de gestion du portefeuille de projets (CGPP).

• Maîtrise d’ouvrage.

• Maîtrise d’œuvre.

Références

Observatoire Technologique, Le Référentiel e-Société, CTI, Etat de Genève, juin 2003.[En ligne] août 2003 URL document HTML http://www.geneve.ch/obstech/referentiel/ref-e-soc/ref-e-soc.html et URL document PDF ftp://ftp.geneve.ch/obstech/ref-e-soc.pdf

Observatoire Technologique 94

Page 97: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Intergovernmental Advisory Board, High Payoff in Electronic Governement : Measuringthe Return on E-Government Investments, U.S. General Services Administration, Gou-vernement américain, mai 2003. [En ligne] août 2003 URL www.gsa.gov/intergov/.

National Office for the Information Economy, E-Government Benefits Study, Gouverne-ment australien, avril 2003. [En ligne] août 2003 URL http://www.noie.gov.au/publications/.

Di Maio, A., Value for Money Is Not Enough in the Public Sector IT Projects, GartnerGroup, 25 juin 2003. [En ligne payant] URL http://www.gartner.com/.

CGPP, Documents de la Commission de Gestion du Portefeuille de Projets, Etat de Ge-nève. [En ligne] août 2003 URL http://obstech.etat-ge.ch/cgpp.nsf.

Lautier, D., Les options réelles : Une idée séduisante, un concept utile et multiforme, uninstrument facile à créer, mais difficile à valoriser, Cahiers du CREG no 2002.05, 2002.[En ligne] octobre 2003 URL http://www.dauphine.fr/cereg/Cahiers/200205.pdf.

Benaroch, M., Managing Information Technology Investment Risk : A Real Options Pers-pective, Journal of Management Information Systems, Vol. 19, No. 2, pp. 43-84, Fall 2002.[En ligne] octobre 2003 URL http://sominfo.syr.edu/facstaff/mbenaroc/PAPERS/jmis/jmis-1.pdf.

Amram, M., Kulatilaka, N., Real Options : Managing Strategic Invetsment in an UncertainWorld, Harvard Business School Press, Boston, 1999.

Observatoire Technologique 95

Page 98: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

6.2 Formation et Organisation

Révisions

Version Date / auteurs Objet de la révision0.1 2003-08-20 / gpl Version initiale0.2 2003-10-06 / gpl

Description

Les choix technologiques peuvent avoir un impact important sur les modes de fonction-nement et l’organisation du travail.

Par ailleurs, il est souhaitable que les choix organisationnels soient indépendants desmoyens de traitement et des données sur lesquelles le travail est effectué.

Pour cette dimension, les nouvelles formations et les redéfinitions de processus sont lesdeux aspects les plus souvent touchés par l’introduction de nouvelles technologies.

La formation doit être perçue comme une construction de la connaissance et pas unique-ment une activité d’enregistrement ou d’absorption de techniques. Les personnes uti-lisent en grande partie les connaissances déjà acquises pour en assimiler de nouvelles.La formation doit donc être inclue suffisamment tôt dans les réflexions et être adpatéeaux situations présentes pour être profitable. Il faut aussi noter que la motivation person-nelle joue un rôle important par rapport aux problèmes cognitifs dans l’apprentissage denouvelles technologies ou de nouvelles connaissances en général.

L’objectif visé est de rendre les utilisateurs et les techniciens autonomes dans l’accomplis-sement des tâches qui leur incombent et capables de s’adapter à des situations de travailvariées découlant de l’évolution technologique et des changements dans l’organisationdu travail.

Sous-dimensions

• Organisation et formation des utilisateurs

• Organisation et formation des informaticiens

Observatoire Technologique 96

Page 99: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

6.2.1 Utilisateurs

Révisions

Version Date / auteurs Objet de la révision0.1 2003-08-20 / gpl Version initiale0.2 2003-10-06 / gpl

Description

La formation et l’information aux utilisateurs sont deux aspects cruciaux lors de l’introduc-tion d’une nouvelle technologie. Les technologies principalement concernées sont cellestouchant les tiers du client, de présentation et du métier. Les modifications impliquant lescouches du système d’information et des applications sont vraisemblablement celles quidemandent une réorganisation ou une formation supplémentaire auprès des utilisateurs.

Le rôle des utilisateurs doit être intégré comme un aspect actif du déploiement d’unenouvelle technologie. En particulier, l’information mise à disposition de utilisateurs leurpermet de se documenter sur les nouveautés et de mieux cibler ses demandes. Idéale-ment l’utilisateur devrait :

• pouvoir déterminer de quelle information il a besoin,

• savoir où et comment la trouver,

• pouvoir la lire et la comprendre,

• pouvoir la critiquer et évaluer si elle répond à son besoin,

• savoir l’utiliser et la gérer,

• pouvoir l’exploiter pour développer sa connaissance.

Par exemple, le rôle d’une bonne documentation et de groupes d’experts ou d’utilisateurspouvant partager leur expériences dans un espace collaboratif éléctronique permettentde favoriser les point précédents.

Couches concernées

• Système d’information. L’introduction d’une nouvelle technologies demande un ré-organisation en profondeur touchant les processus de travail et demandant uneréorganisation de ceux-ci.

• Application. Une nouvelle application peut demander la mise en œuvre d’une nou-velle organisation ou formation spécifique.

• Plateforme supérieure Cette couche peut avoir un impact sur l’organisation et laformation seulement si les applications sont intimement imbriquées au systèmed’exploitation. Dans ce cas, changer de plateforme implique un changement auniveau de la couche Application.

Observatoire Technologique 97

Page 100: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Plateforme inférieure Idem Plateforme supérieure.

• Matériel. En principe transparent pour l’utilisateur, à moins que la plateforme et/oules autres couches supérieures ne doivent être significativement modifiées.

Tiers concernés

• Client. Une introduction de nouveaux éléments ou un changement d’ergonomiesont très fortement ressentis par l’utilisateur final. Un changement significatif de-mande tout au moins une bonne information, voire une formation si cela est oppor-tun.

• Présentation. La gestion de la présentation devrait permettre un “rendu” similaireou adpaté à l’environnement de l’utilisateur, ce qui permet de diminuer l’impact surla formation.

• Métier. Un changement des régles métiers nécessite en général une formation del’utilisateur afin qu’il sache utiliser correctement les éléments modifiés.

• Intégration. En principe transparent pour l’utilisateur.

• Ressources. En principe transparent pour l’utilisateur.

Risques

Les utilisateurs ne sont pas préparés à l’introduction d’une nouvelle technologie et larejettent plus facilement.

Les changements, même s’ils présentent des avantages, sont souvent mal ressentis s’ilsne sont pas accompagnés.

Mesures

Les besoins des utilisateurs concernant la formation et l’information sont-ils considérésdans le projet ?

Les formations et documentations nécessaires à l’introduction d’une nouvelle technologieont-elles été préparées ?

L’information préparant au changement technologique a-t-elle été communiquée ?

Compétence

• Centre de formation

• Chefs de projets dont les projets ont un impact sur les utilisateurs

• Utilisateurs concernés et leur hiérarchie

Observatoire Technologique 98

Page 101: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

6.2.2 Informaticiens

Révisions

Version Date / auteurs Objet de la révision0.1 2003-08-21 / gpl Version initiale0.2 2003-10-06 / gpl

Description

La formation et l’organisation des informaticiens et des ingénieurs joue un rôle importantlors de l’introduction d’une nouvelle technologie. Les effets doivent être maîtrisés afinque le service offert par les équipes techniques soit de niveau élevé aussi rapidementque possible.

La notion d’apprentissage tout au long de la vie (“life-long learning” ) doit être assimiléepar les personnes en particulier dans les métiers liés aux technologies de l’informationqui sont fortement sujets aux changements et aux innovations.

Dans ce cadre, il s’agit de donner aux techniciens en informatique une formation tech-nique et humaine, théorique et pratique qui les rend aptes à exercer convenablementleur profession d’informaticiens. L’accent devra être mis notamment sur la polyvalence endéveloppant les connaissances et les habiletés nécessaires, non seulement à accomplirles tâches actuelles, mais aussi à pouvoir intégrer des concepts portables d’un environ-nement technologique à un autre.

D’autre part, la notion de gestion de projet permet d’intégrer des notion importantes quantà l’exécution des tâches et des missions de chaque équipe. Dans toute structure, lesmoyens alloués pour une réalisation sont accompagnés de processus qui encadrent ladémarche et permettent d’en assurer la qualité. Une organisation et une gestion de pro-jet définis clairement permettent, d’une part, une meilleure allocation des ressources,des compétences et des délais et, d’autre part, une capitalisation des connaissances dechacun. Par ailleurs, les collaborations avec d’autres projets doivent aussi être favoriséesafin d’éviter les redondances et d’augmenter les synergies.

Un point important à souligner est le niveau existant de compétences soit interne à lastructure, soit sur le marché local. En effet, l’introduction d’une nouvelle technologie doitêtre accompagnée par la mise à disposition de ressources humaines. D’un côté, la forma-tion peut compléter les connaissances des personnes en interne et, de l’autre, le marchélocal doit aussi permettre de compléter les compétences manquantes. Il est donc impor-tant d’évaluer la niveau de compétences existant dans ces deux “marchés” du travail.

Couches concernées

Les différentes couches sont couvertes par un structure organisationnelle : les serveurssont gérés par un service, les aspects liés aux système d’exploitation et aux applicationspar d’autres. Un changement de technologie peut donc avoir un impact non négligeablesur les aspects organisationnels.

Observatoire Technologique 99

Page 102: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Tiers concernés

Une déclinaison par tiers n’est pas faite ici.

Risques

La non prise en compte de la formation des ingénieurs et techniciens suite à l’introductiond’une nouvelle technologie conduit à des lacunes dans leur connaissances et des inef-ficacités dans le travail exécuté. Le manque de maîtrise de la technologie peut ralentirl’adoption d’une nouvelle technologie ou aller jusqu’à mettre en difficulté la production.

Une organisation non adaptée ne permet pas de répondre dans un délai suffisammentcourt et avec une qualité suffisamment élevée aux demandes.

Mesures

Les formations nécessaires aux informaticiens sont-elles prévues dans l’échéancier duprojet ?

Les formations mettent-elles en valeur la portabilité des connaissances indépendammentde la technologie ?

L’introduction d’une nouvelle technologie modifie-t-elle l’organisation des services ?

Les compétences liées à une nouvelle technologie existent-elles en interne ? Peut-onenvisager une formation ?

Le marché du travail permet-il d’engager des personnes compétentes ?

Compétence

• Centre de formation

• Ressources humaines

• Maîtrise d’œuvre

• Maîtrise d’ouvrage

Observatoire Technologique 100

Page 103: Le Référentiel Nouvelles Plateformes Technologiques

Chapitre 7

Dimensions relatives à la sécurité

Les dimensions Gestion des politiques d’accès, Contrôle et Confidentialité ont été regrou-pées sous le label commun Dimensions relatives à la sécurité. Ces dimensions, ainsi queles sous-dimensions correspondantes prennent en compte les aspects touchant à la sé-curité des données, des applications et des infrastructures. La prise en compte de lasécurité en amont de toute réflexion est essentielle si l’on veut bâtir un système d’infor-mation sûr, fiable et pérenne. C’est pour cette raison que ces dimensions ont été misesen exergue ici.

101

Page 104: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

7.1 Gestion des politiques d’accès

Révisions

Version Date / auteurs Objet de la révision0.1 2003-10-06 / gpl,pge Version initiale

Description

La dimension Gestion des politiques d’accès permet d’analyser la capacité de la tech-nologie ou du composant informatique étudiés à gérer d’une part l’authentification desutilisateurs et des processus et d’autre part les autorisations correspondantes.

Sous-dimensions

• Authentification : mesure la capacité du système étudié à identifier un utilisateurou un processus.

• Autorisation : mesure la capacité du système à gérer les droits des utilisateurset/ou des processus autorisés.

Mesures

La mesure de la dimension Gestion des politiques d’accès est une agrégation des me-sures des sous-dimensions correspondantes.

Observatoire Technologique 102

Page 105: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

7.1.1 Authentification

Révisions

Version Date / auteurs Objet de la révision0.1 2003-11-20 / pge Version initiale

Description

L’authentification garantit l’identification d’un utilisateur ou d’un composant matériel afinde certifier qu’il est bien qui il prétend être et lui permettre ainsi d’obtenir certains droitsd’accès dans le système informatique. Elle est cruciale pour le contrôle de l’accès auxressources d’une organisation.

Une procédure d’authentification comporte trois phases distinctes :

1. L’identification qui consiste à fournir l’une de ses identités (elles peuvent être eneffet multiples).

2. L’authentification proprement dite qui consiste à prouver que nous sommes biendétenteurs de l’identité annoncée.

3. La transmission de son profil qui consiste à fournir certaines informations atta-chées à l’identité annoncée (état civil, adresse, coordonnées bancaires, informa-tions médicales, etc.).

Il existe trois façons de s’authentifier :

• Par ce que l’on sait : en donnant une information uniquement connue par la per-sonne disposant de cette identité (par exemple un mot de passe).

• Par ce que l’on possède : par exemple une calculette, un badge ou un certificat.

• Par ce que l’on est : en utilisant une caractéristique physique de la personne commepar exemple les empreintes digitales ou rétiniennes (on parle alors de biométrie).

De nombreuses technologies sont basées sur ces trois types d’authentification. Priseséparément, chacune d’elles présente cependant des failles de sécurité plus ou moinsimportantes. On parle alors d’authentification faible. En les combinant, on obtient ce-pendant des solutions qui sont plus difficiles à contourner. On considère que l’on a dansces cas une authentification forte.

Le degré d’authentification nécessaire dépend à la fois du lieu d’où on accède à l’infor-mation (réseau interne ou externe) et de la sensibilité de cette dernière.

La procédure d’authentification peut se faire à deux niveaux :

1. Au niveau des applications ou du système d’exploitation (accès par identification del’utilisateur accompagnée d’un jeton et/ou d’un certificat).

2. Au niveau du réseau (systèmes d’exclusion de gammes d’adresses IP).

Observatoire Technologique 103

Page 106: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Les technologies et les composants informatiques doivent pouvoir prendre en comptecorrectement la notion d’authentification, notamment lorsque des données sensibles sontconcernées.

Couches concernées

• Système d’information. Au niveau du système d’information, l’authentification doitêtre prévue comme une partie intégrante des règles et des processus appliquésaux acteurs du système. Dans cette couche on mesurera donc la capacité de latechnologie ou du composant informatique étudiés à s’y conformer.

• Application. Dans cette couche mesure la qualité de l’authentification en fonction dela sensibilité des informations et du lieu d’où on y accède. Les standards d’authenti-fication du CTI doivent pouvoir être pris en compte (la compatibilité avec la sécuritéau niveau des autres couches doit notamment être préservée tout en évitant les re-dondances). Les fonctionnalités d’authentification et d’autorisation doivent pouvoirêtre obtenues au travers des annuaires de l’organisation. Elles doivent égalementprendre en compte correctement les directives de l’organisation relatives à la ges-tion des mots de passe (taille, durée de validité, etc.).

• Plateforme inférieure. Dans cette couche on se préoccupera de la capacité dusystème d’exploitation à authentifier l’utilisateur et à être intégré au système d’an-nuaires de l’organisation.

• Matériel. Dans cette couche on va déterminer dans quelle mesure le matériel peutêtre protégé d’une utilisation abusive via un mécanisme d’authentification propre(indépendant de la plateforme inférieure). Ceci est particulièrement important pourle matériel nomade (ordinateurs portables, PDA, etc...).

La distinction sur les tiers n’est pas pertinente ici.

Risques

• Si cette dimension n’est pas prise en compte correctement, on risque de compro-mettre gravement la sécurité du système informatique de l’Etat.

• Certaines technologies d’authentification risquent, suivant leur cadre d’utilisation,de poser problème en regard des cadres juridique ou éthique en vigueur (manquede bases légales notamment).

Mesures

• La technologie ou le composant informatique étudiés garantissent-ils un degré d’au-thentification suffisant ?

• Peuvent-ils être intégrés aux services d’annuaires de l’organisation ?

• Peuvent-ils être suffisamment bien intégrés au système informatisé de l’organisa-tion de manière à réduire ou à éliminer les redondances dans ce domaine ?

Observatoire Technologique 104

Page 107: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Aspects métier

Compétence

• Cellule sécurité des systèmes d’information de l’Etat de Genève

• Responsable sécurité du CTI

• Division technique de développement (CTI)

• Division Réseaux et télécoms (CTI)

Divers

La notion d’authentification prend une importance toute particulière lorsque l’on désireaccéder au système informatique de l’Etat depuis l’extérieur de celui-ci.

Observatoire Technologique 105

Page 108: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

7.1.2 Autorisation

Révisions

Version Date / auteurs Objet de la révision0.1 2003-11-20 / gpl,pge Version initiale

Description

L’autorisation permet à un utilisateur ou à un processus correctement authentifié d’ac-céder aux ressources du système informatique pour lesquelles leur propriétaire leur adonné un certain nombre de droits.

La granularité permet de determiner jusqu’à quel niveau les autorisations sont gérées.Par exemple un utilisateur avec un rôle spécifique peut avoir un accès général au sys-tème, mais pas à des portions particulières.

L’annuaire est le composant qui permet de rassembler et gérer les autorisations. Il devientde ce fait un élément central de la sécurité. Les accès aux données et aux processusformant le système d’information sont gérés en fonction des rôles, des responsabilités etde la protection des individus.

Les notion de délégation des droits permet également une gestion facilitée des autorisa-tions en ne compromettant pas les éléments de base de la sécurité.

Couches concernées

• Système d’information. Les processus définis déterminent les autorisations néces-saires à l’exécution des tâches et leur granularité est adaptée à la mise en œuvre.Dans cette couche on mesurera donc la capacité de la technologie ou du compo-sant informatique étudiés à s’y adapter ou s’y conformer.

• Application. Les applications requièrent les autorisations nécessaires pour les effec-tuer les actions ou pour accéder aux informations selon la granularité déterminée.Les applications font appel à un annuaire pour stocker et gérer ces droits.

• Plateforme supérieure. Voir plateforme inférieure.

• Plateforme inférieure. Le système d’exploitation permet une distinction de niveauxentre les utilisateurs, groupes d’utilisateurs et les administrateurs.

• Matériel.

La distinction sur les tiers n’est pas pertinente ici.

Risques

• Si cette dimension n’est pas prise en compte correctement, on risque de compro-mettre gravement la sécurité du système informatique de l’Etat.

Observatoire Technologique 106

Page 109: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Mesures

• Les rôles et les responsabilités sont-ils définis ?

• Les autorisations et les processus sont-ils adaptés ? Leur granularité permet-elleun bonne adéquation ?

• Les applications peuvent-elles être reliées à un annuaire ? Peut-on gérer une délé-gation des droits ?

• Le système permet-il de gérer de façon adéquate des niveaux entre utilisateurs,groupes et administrateurs ?

Aspects métier

Compétence

• Cellule sécurité des systèmes d’information de l’Etat de Genève

• Responsable sécurité du CTI

• Division technique de développement (CTI)

• Division Réseaux et télécoms (CTI)

Divers

La notion d’autorisation prend une importance toute particulière lorsque l’on désire accé-der au système informatique de l’Etat depuis l’extérieur de celui-ci.

Observatoire Technologique 107

Page 110: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

7.2 Contrôle

Révisions

Version Date / auteurs Objet de la révision0.1 2003-10-06 / gpl,pge Version initiale

Description

La dimension Contrôle permet d’analyser la capacité de la technologie ou du composantinformatique étudiés à gérer la sécurité des données au travers des mécanismes decontrôle ci-dessous.

Sous-dimensions

• Intégrité : mesure la capacité du système étudié à certifier le fait que les donnéesn’ont pas été altérées ou détruites de manière frauduleuse.

• Non-répudiation : mesure la faculté du système étudié à garantir le fait que lesdeux parties d’une transaction ne puissent nier l’avoir effectuée.

• Traçabilité : mesure l’aptitude à retrouver l’historique, l’utilisation ou la localisationd’un produit ou d’un processus de délivrance d’un service au moyen d’identificationsenregistrées.

Mesures

La mesure de la dimension Contrôle est une agrégation des mesures des sous-dimensionscorrespondantes.

Observatoire Technologique 108

Page 111: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

7.2.1 Intégrité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-11-20 / gpl,pge Version initiale

Description

L’intégrité est définie comme la qualité de données qui n’ont pas été altérées ou détruitesde manière frauduleuse (ISO 7498-2).

L’intégrité est une fonction essentielle à mettre en œuvre au sein d’un système d’informa-tion si l’on veut pouvoir disposer d’une information fiable.

Les exigences d’intégrité impliquent notamment :

• Des système de fichiers avec contrôle d’accès permettant de cloisonner les don-nées.

• Un contrôle à partir d’éléments calculés sur les données qui doivent rester inchan-gées (contrôles cycliques, signatures numériques).

• L’utilisation du back-up.

• L’authentification des intervenants.

• Des contrôles de cohérence.

Risques

• L’impossibilité de garantir l’intégrité des données peut amener à une perte de confiancedes utilisateurs et à un rejet de la solution envisagée.

• Les technologies ou les composants informatiques mis en œuvre dans le cadre deservices en ligne traitant des données personnelles ou sensibles doivent impéra-tivement pouvoir garantir l’intégrité de l’information au risque d’être rejetés par lescitoyens.

Mesures

• La technologie ou le composant informatique étudiés garantissent-ils une intégritésuffisante de l’information ?

Compétence

• Cellule sécurité des systèmes d’information de l’Etat de Genève

• Responsable sécurité du CTI

• Division technique de développement (CTI)

Observatoire Technologique 109

Page 112: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Références

• ISO 9797 - Data integrity mechanisms

• ISO 10118 1 à 4 - Hash functions

• ISO 10181-6 - Integrity framework

Observatoire Technologique 110

Page 113: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

7.2.2 Non-répudiation

Révisions

Version Date / auteurs Objet de la révision0.1 2003-11-20 / gpl,pge Version initiale

Description

Pour de nombreux types d’échange d’information, il est important que ni l’émetteur nile destinataire ne puissent nier le fait que l’information a été envoyée et reçue. C’est lerôle des service de non-répudiation qui sont des service de sécurité dont l’objectif est degénérer, récolter, maintenir, rendre disponible et valider l’évidence (information utiliséepour établir une preuve) concernant un évènement ou une action revendiquée afin derésoudre les possibles disputes sur l’occurrence ou non de l’évènement ou de l’action(dérivé de ISO/IEC DIS 13888-1).

Le but de la non-répudiation, en conformité avec les spécifications ISO/IEC 13888 (voirréférences), est de fournir une preuve vérifiable, basée sur des valeur de contrôle cryp-tographiques de :

• L’approbation. Un service de non-répudiation d’approbation fournit la preuve quel’émetteur du message a approuvé son contenu.

• L’émission. Un service de non-répudiation d’émission certifie l’identité de celui quia émis le message.

• L’origine. Un service de non-répudiation d’origine est une combinaison des servicesd’approbation et d’émission.

• La soumission. Un service de non-répudiation de soumission apporte la preuvequ’une autorité de livraison a accepté de transmettre un message.

• Le transport. Un service de non-répudiation de transport apporte la preuve, pourl’émetteur d’un message, que l’autorité de livraison a délivré le message au desti-nataire prévu.

• La réception. Un service de non-répudiation de réception apporte la preuve que ledestinataire a reçu le message.

• La reconnaissance. Un service de non-répudiation de reconnaissance apporte lapreuve que le destinataire a reconnu le contenu du message reçu.

• La livraison. Un service de non-répudiation de livraison est une combinaison desservices de réception et de livraison. Il fournit la preuve que le destinataire a reçuet reconnu le contenu du message reçu.

Couches concernées

• Système d’information.

Observatoire Technologique 111

Page 114: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

• Application. Dans cette couche on vérifie que les applications gérant des transac-tions intègrent correctement un ou des services de non-répudiation. Ces servicessont notamment requis dans le cas de la messagerie électronique afin que l’origineou la livraison des messages puisse être prouvée par une tierce partie.

La distinction sur les tiers n’est pas pertinente ici.

Risques

• L’impossibilité de garantir la non-répudiation des transactions peut amener à uneperte de confiance des utilisateurs et à un rejet de la solution envisagée. Des pro-blèmes légaux peuvent également être envisagés dans ce cas.

• Les technologies ou les composants informatiques mis en œuvre dans le cadre deservices en ligne traitant des données personnelles ou sensibles doivent impérati-vement pouvoir gérer la notion de non-répudiation au risque d’être rejetés par lescitoyens.

Mesures

• La technologie ou le composant informatique étudiés offrent-ils des mécanismes denon-répudiation suffisants ?

Compétence

• Cellule sécurité des systèmes d’information de l’Etat de Genève

• Responsable sécurité du CTI

• Division technique de développement (CTI)

• Division Réseaux et télécoms (CTI)

Références

• Non-repudiation in the digital environment, A. Mc Cullagh et W. Caelli, 2003, http://www.firstmonday.dk/issues/issue5_8/mccullagh/

• ISO/IEC 10181-4 : 1997 : Information technology - Open Systems Interconnection- Security frameworks for open systems : Non-repudiation framework.

• ISO/IEC 13888-1 :1997 : Information technology - Security techniques - Non-repudiation- Part 1 : General

• ISO/IEC 13888-2 :1998 : Information technology - Security techniques - Non-repudiation- Part 2 : Mechanisms using symmetric techniques

• ISO/IEC 13888-3 :1997 : Information technology - Security techniques - Non-repudiation- Part 3 : Mechanisms using asymmetric techniques

Observatoire Technologique 112

Page 115: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

7.2.3 Traçabilité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-11-20 / gpl,pge Version initiale

Description

La définition donnée par la norme ISO 8402 pour la traçabilité est : Aptitude à retrouverl’historique, l’utilisation ou la localisation d’un produit ou d’un processus de délivranced’un service au moyen d’identifications enregistrées.

Il est crucial pour la sécurité de suivre le parcours des utilisateurs en environnementmulti-applicatif.

Les fichiers de log produits par les firewalls, les routeurs et les systèmes fournissent unebase d’analyse qui permet de retracer certains parcours.

La traçabilité doit impérativement être respectueuse de la sphère privée des personnes.Cet aspect est notamment lié au cadre légal et au cadre éthique.

Couches concernées

• Système d’information. Les processus et les données appartiennent à un proprié-taire identifié. La modification du contenu ou le changement de propriétaire estenregistré. Ceci permet de retracer toutes les étapes le cas échéant.

• Application. Les applications permettent de stocker les informations pertinentespour la traçabilité. Les accès au fichiers de log sont sécurisés pour éviter la mo-dification mais aussi pour protéger la sphère privée.

• Plateforme supérieure.

• Plateforme inférieure.

• Matériel.

Tiers concernés

La distinction sur les tiers n’est pas pertinente ici.

Risques

• Des modifications non désirables effectuées sur les données ne peuvent pas êtreretracées pour modifier les processus nécessaires au bon fonctionnement du sys-tème.

• En cas d’intrusion, les données ou applications touchées ne peuvent pas être iden-tifiées et le cas échéant corrigées.

Observatoire Technologique 113

Page 116: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Mesures

• Les applications permettent-elles de stocker les informations nécessaires à la tra-çabilité ?

• Les processus et les données ont-ils des propriétaires et leur modifications sont-elles traçables ?

• La sphère privée est-elle respectée dans la mise en œuvre de la traçabilité ?

Aspects métier

Compétence

• Cellule sécurité des systèmes d’information de l’Etat de Genève

• Responsable sécurité du CTI

• Division technique de développement (CTI)

• Division Réseaux et télécoms (CTI)

Observatoire Technologique 114

Page 117: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

7.3 Confidentialité

Révisions

Version Date / auteurs Objet de la révision0.1 2003-11-20 / gpl,pge Version initiale

Description

La confidentialité est définie comme la propriété qui assure que l’information n’est pasrendue disponible, ni révélée à des personnes, entités ou processus non autorisés. Ellequalifie d’une manière générale tout moyen visant à ne pas autoriser la diffusion d’uneinformation définie comme sensible (information ayant une valeur ; donnée stratégique ;obligations : légales, contractuelles, déontologiques). La confidentialité d’une donnée oud’un programme est à rapprocher des risques induits par sa divulgation.

La notion de confidentialité est liée à une authentification plus ou moins forte selon la sen-sibilité des données échangées. Le chiffrement des données constitue la meilleure mé-thode de sécurisation de la confidentialité des échanges électroniques déployés sur unréseau. Ce chiffrement permet d’une part de rendre une information inintelligible à toutepersonne non autorisée à en prendre connaissance. D’autre part il permet de restituerl’information dans son état initial à l’attention des personnes autorisées (déchiffrement).On citera par exemple les protocoles SSL (Secure Sockets Layer ) et TLS (TransportLayer Security Standard).

Couches concernées

• Système d’information. Au niveau du système d’information, la confidentialité del’information sensible doit être prévue comme une partie intégrante des règles dusystème. Dans cette couche on mesurera donc la capacité de la technologie ou ducomposant informatique étudiés à s’y conformer.

• Application. Dans cette couche on va mesurer la qualité de la prise en compte dela confidentialité en fonction de la sensibilité des informations transitant à travers leréseau. Les standards de chiffrement du CTI doivent pouvoir être pris en compte.

• Plateforme supérieure.

• Plateforme inférieure. Dans cette couche on se préoccupera de la capacité du sys-tème d’exploitation à chiffrer des fichiers ou des répertoires dans les cas où desdonnées sensibles sont concernées.

• Matériel.

La distinction sur les tiers n’est pas pertinente ici.

Observatoire Technologique 115

Page 118: Le Référentiel Nouvelles Plateformes Technologiques

Référentiel NPT

Risques

• L’impossibilité de garantir un niveau de confidentialité suffisant peut, suivant le de-gré de sensibilité des informations concernées, amener à une perte de confiancedes utilisateurs et à un rejet de la solution envisagée.

• Les technologies ou les composants informatiques mis en œuvre dans le cadre deservices en ligne traitant des données personnelles ou sensibles doivent impérati-vement pouvoir intégrer la notion de confidentialité au risque d’être rejetés par lescitoyens.

Mesures

• La technologie ou le composant informatique étudiés garantissent-ils une confiden-tialité suffisante de l’information ?

• Les applications requièrent-elles un chiffrement des données en transit à travers leréseau ?

• Le système d’exploitation est-il capable de chiffrer des fichiers ou des répertoires ?

Aspects métier

Compétence

• Cellule sécurité des systèmes d’information de l’Etat de Genève

• Responsable sécurité du CTI

• Division technique de développement (CTI)

Divers

La notion de confidentialité prend une importance toute particulière lorsque l’on désireaccéder au système informatique de l’Etat depuis l’extérieur de celui-ci.

Observatoire Technologique 116