SlideShare une entreprise Scribd logo
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/
ot@etat.ge.ch
Référentiel NPT




Copyright c 2003–2004 CTI, Observatoire Technologique.

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view
a 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
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
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
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
Première partie

Introduction au Référentiel NPT




                4
Chapitre 1

Introduction

1.1     Résumé

Le référentiel Nouvelles Plateformes Technologiques (NPT) est un outil élaboré par
l’Observatoire Technologique du CTI dans le but d’analyser une technologie, un
système ou un composant 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.
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 et
l’évaluation microscopique d’un composant du système informatique et (iii) la description
et l’évaluation d’une technologie ou d’un standard.
Le référentiel NPT est structuré selon trois axes et représenté graphiquement sous la
forme 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. Les
dimensions 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 et
l’évaluation des fournisseurs. Les qualités systémiques incluent l’évolutivité, les qualités
de service, l’exploitabilité, l’interopérabilité et la maturité du composant. Les dimensions
relatives à l’organisation incluent les coûts, les compétences et la formation. Enfin, les
dimensions relatives à la sécurité incluent la gestion de politiques d’accès, le contrôle et
   1
     Ce 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
Référentiel NPT




la confidentialité. Chacune des dimensions mentionnées est elle-même décomposée en
sous-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’analyse
et d’illustrer ces objectifs avec quelques cas d’utilisation envisagés. Les chapitres 2 et 3
sont 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 qui
devraient ê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ée
par rapport à chaque couche et à chaque tiers de l’architecture du système. La partie II
est 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 en
fonction des retours d’expérience. Par ailleurs, il est également prévu d’intégrer toute
nouvelle information externe ou interne qui permettra une amélioration du référentiel ou
de 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 pour
     des 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èvement
     décrite.
   • Le chapitre 3 décrit la structure tri-dimensionnelle du référentiel NPT. Les trois axes
     du référentiel, c’est-à-dire les couches, les tiers et les dimensions, sont décrits et
     illustré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 dimension
     est définie et analysée en regard des deux premiers axes (c’est-à-dire en regard
     des couches et des tiers).



1.4 A qui s’adresse ce document

Dans un premier temps, ce document s’adresse :

Observatoire Technologique                                                                  6
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
Chapitre 2

Définitions, objectifs et utilisation
du 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 sont
ensuite énoncés et illustrés à l’aide de trois cas d’utilisation. Finalement, l’instrumentation
du 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érentiel
est 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 plusieurs
dimensions. Cette approche est applicable aussi bien au niveau macroscopique (analyse
d’un système informatique global) qu’au niveau microscopique (analyse détaillée d’un
composant du système informatique).


Cette définition met l’accent sur le concept d’architecture. Or, il n’existe pas de définition
unique 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 sont
proposées pour le concept d’architecture logicielle (software architecture). Elles peuvent
né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 .
  1
    http://www.sei.cmu.edu/architecture/definitions.html
  2
    Software Architecture in Practice, Addison-Wesley, 1997
  3
    The UML Modeling Language User Guide, Addison-Wesley, 1999


                                              8
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 structures
of the system, which comprise software components, the externally visible properties of
those components, and the relationships among them.
By “externally visible” properties, we are referring to those assumptions other components
can 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 a
software architecture must abstract away some information from the system (otherwise
there is no point looking at the architecture, we are simply viewing the entire system) and
yet provide enough information to be a basis for analysis, decision making, and hence
risk 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 software
system, the selection of the structural elements and their interfaces by which the system
is composed, together with their behavior as specified in the collaborations among those
elements, the composition of these structural and behavioral elements into progressively
larger subsystems, and the architectural style that guides this organization—these ele-
ments and their interfaces, their collaborations, and their composition (The UML Modeling
Language 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éfinis
de 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 de
mé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 ou
automatisés (par un système informatique).




Observatoire Technologique                                                               9
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 avec
des composants matériels et logiciels. Un système informatique permet d’automatiser
une 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’intention
d’une division particulière du CTI. Au contraire, il est suffisamment générique pour être
utile à l’ensemble des divisions du CTI ainsi qu’à d’autres entités internes ou partenaires
de 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-forme
maté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, la
maniè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 la
documentation.


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 de
l’É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ée
     par 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 Framework
     CTI peuvent être partagés par différentes applications.


Observatoire Technologique                                                                10
Référentiel NPT




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

   • La manière dont les divisions et les groupes du CTI se partagent l’expertise et la
     responsabilité 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’une
application métier, le référentiel permet de comparer et d’évaluer un ensemble d’alterna-
tives sur plusieurs dimensions.




              F IG . 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 est
la 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 la
     pré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/ou
     graphiquement. Un tableau à deux dimensions, représentant les couches verticale-
     ment et les tiers horizontalement, est souvent très utile. Un exemple est illustré par
     la figure 2.1. Ce tableau décrit l’architecture d’une application métier. Le périmètre
     couvert par l’architecture (par rapport à toutes les couches et à tous les tiers) est
     représenté par le rectangle jaune. Le schéma met également en évidence le fait


Observatoire Technologique                                                               11
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 donc
      possible 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 couche
     et à chaque tiers. Il arrive néanmoins qu’une dimension ne soit applicable qu’à un
     sous-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 technologie
ou 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 plus
transversal.
Dans ce cas, la première étape consiste à situer la technologie ou le standard étudié dans
le 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ée
par rapport aux deux axes, il est plus facile d’identifier les personnes qui, au CTI, sont le
plus à même de fournir des informations par rapport à la technologie.
Parfois, une technologie a également le potentiel de permettre une réorganisation du
système informatique global. Par exemple, des technologies d’intégration comme les
connecteurs JCA peuvent augmenter l’interopérabilité entre certaines applications mé-
tiers. De telles propriétés peuvent également être représentées graphiquement en tirant
parti 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 habitudes
seront prises graduellement et évolueront dans le temps, en fonction de l’adoption du
référentiel par différentes personnes.
Une des possibilités proposées aux utilisateurs du référentiel NPT est d’instrumenter le
référentiel avec un outil d’aide à la décision. Une telle instrumentation est particulièrement
intéressante lorsque le référentiel est utilisé pour choisir un composant parmi plusieurs
alternatives.
Par exemple, l’Observatoire Technologique a évalué et acquis des licences pour le logiciel
d’aide à la décision multi-critères Web-HIPRE. Ce logiciel permet la définition de critères
d’é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 et
peuvent manipulés interactivement. Un exemple d’écran du logiciel est représenté dans
la Figure 2.2.




Observatoire Technologique                                                                 12
Référentiel NPT




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




Observatoire Technologique                                                 13
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 par
trois types d’utilisation envisagés. La discussion a brièvement mentionné le fait que le
référentiel était structuré selon trois axes : celui des couches, celui des tiers et celui des
dimensions. 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é graphiquement
sous la forme d’un cube. Le premier axe est utilisé pour décomposer le système en
couches. Le deuxième axe est utilisé pour décomposer le système en tiers (dans le sens
d’une architecture multi-tiers). Le troisième axe est utilisé pour évaluer le système en
tenant 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 des
     tiers du référentiel. Cette étape permet donc de situer le système dans les limites
     du 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 orthogonales
     aux 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 tiers
     du 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
Référentiel NPT




      F IG . 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 couche
inférieure. Les couches sont indépendantes les unes des autres et communiquent au
travers 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. Plus
important, 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, il
est possible que seul un fournisseur fournisse une implémentation de la couche. Cette
situation crée une relation de dépendance vis à vis du fournisseur. En effet, remplacer
la couche revient à changer l’interface et oblige donc à modifier les composants de la
couche supérieure. Un exemple est une application développée directement au-dessus
du 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 et
les composants réseau.


Observatoire Technologique                                                              15
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 analyse
permet de mettre en évidence la variété plus ou moins grande des composants, aussi
bien 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ême
si 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 peuvent
se poser à ce niveau, par exemple :

   • Quels types de ressources sont-elles requises par la solution ? (par exemple quels
     sont 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 et
offre 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 de
pé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érielles
différentes. Par exemple, le même système d’exploitation peut être disponible sur des
architectures 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 de
cette 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 œuvre
au 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ème
d’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. Les
applications développées en Java sont portables de manière tout à fait transparente. Le


Observatoire Technologique                                                               16
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 logique
de présentation, de traitement et d’accès aux données pour les services déployés par
l’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. Une
bonne manière d’augmenter cette pérennité est de rendre la couche application la plus
indépendante possible des couches inférieures. Pour cela, la première règle à suivre est
de communiquer uniquement avec la couche directement inférieure (plate-forme supé-
rieure), et privilégier un standard ouvert pour cette couche (par exemple J2EE). Cela
garantit 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 le
serveur 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és
et 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 plusieurs
tiers, ce qui est particulièrement utile pour des applications distribuées (et donc pour
celles 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’est
pas une obligation. Ainsi, s’il est possible de déployer une application multi-tiers sur cinq
machines différentes, il est également possible de déployer la même application sur une
seule machine. L’architecture de l’application reste la même.
Le principe d’architecture multi-tiers est aujourd’hui largement accepté et a été rendu
populaire par des technologies telles que CORBA, J2EE et .NET. Néanmoins, il existe
plusieurs variantes de cette architecture, par exemple :

   • l’architecture 3-tiers, qui répartit les composants d’une application distribuées parmi
     les 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
Référentiel NPT




      tiers de données, qui prend en charge le stockage des informations. Il faut relever
      que 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 et
     multi-canaux. Cette architecture est une extension de la précédente et intègre les
     tiers suivants : (1) le tiers client, (2) le tiers de présentation, (3) le tiers métier, (4) le
     tiers intégration et (5) le tiers ressources. Le référentiel NPT est conçu sur la base
     de 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 ne
devrait 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 permet
en particulier de remplacer les composants d’un tiers sans avoir un impact sur tout le
système.


3.3.1 Tiers client

Le tiers client héberge les composants avec lesquels les utilisateurs ont une interaction
directe. 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 couche
du 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 Web
qui permet de consulter un annuaire).
La conception des composants du tiers client peut se faire avec une des deux approches
suivantes : celle dite du “client lourd” (c’est-à-dire les composants sont intégrés sous la
forme 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 navigateur
web).
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 plusieurs
canaux 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. Les
composants hébergés dans ce tiers génèrent l’interface utilisateur (typiquement dans un
langage 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éberge
sont 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 du
tiers client.




Observatoire Technologique                                                                       18
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 permet
d’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ées
par les services du tiers métier.
Dans ce contexte, le découplage entre les tiers ressources et métier permet de remplacer
une base de données par une autre, sans que les services applicatifs ne subissent un
impact.



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. Les
dimensions couvrent un spectre assez large et ne se limitent pas à des considération
techniques.


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 niveaux
hié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
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 de
manière synoptique :


 Ensembles                   Dimensions                       Sous-dimensions
 Facteurs Humains
                             Aspects utilisateurs             Valeur ajoutée
                                                              Respect des besoins fonctionnels
                                                              Ergonomie
                                                              Accessibilité
                             Aspects sociétaux                Composante sociétal
                                                              Cadre légal
                                                              Cadre éthique
 Qualités Systémiques
                             Evolutivité                      Scalabilité
                                                              Flexibilité
                                                              Portabilité
                                                              Maturité de la solution
                             Exploitabilité                   Maintenabilité
                                                              Contrôlabilité
                             Qualités de service              Stabilité
                                                              Disponibilité
                                                              Performance
                                                              Efficacité
                             Interopérabilité                 Ouverture
                                                              Standardisation
 Organisation
                             Aspects économiques
                             Formation et organisation        Utilisateurs
                                                              Informaticiens
 Sécurité
                             Gestion des politiques d’accès   Authentification
                                                              Autorisation
                             Contrôle                         Intégrité
                                                              Non-répudiation
                                                              Traçabilité
                             Confidentialité




Observatoire Technologique                                                                20
Deuxième partie

Le Référentiel NPT




        21
Chapitre 4

Dimensions relatives aux Facteurs
Humains

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 les
sous-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 domaines
sont souvent négligés lors de l’étude d’une technologie ou d’un composant informatique
alors qu’ils y jouent un rôle important en terme d’adoption et d’utilisation notamment.




                                           22
Référentiel NPT




4.1     Aspects utilisateurs

Révisions
 Version     Date / auteurs    Objet de la révision
   0.1      2003-10-03 / pge   Version initiale


Description

La dimension Aspects utilisateurs permet d’analyser les propriétés d’une technologie ou
d’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’un
système.


Sous-dimensions

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

   • Besoins fonctionnels : estime dans quelle mesure les besoins fonctionnels sont
     couverts.

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

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




Observatoire Technologique                                                             23
Référentiel NPT




4.1.1    Valeur ajoutée

Révisions
 Version     Date / auteurs      Objet de la révision
   0.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 les
différents acteurs impliqués.
La notion de valeur ajoutée ne fait naturellement pas ici référence à un quelconque gain
financier. Mais elle y est malgré tout fortement liée : outre les aspects techniques, il y
a en effet toujours lieu de mettre en balance la valeur ajoutée de la solution avec son
coût ainsi qu’avec les risques qui y sont associés (voir dimension Economie). La valeur
ajouté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 des
besoins en terme de finalité : on pense par exemple à la mise à disposition d’un service
supplémentaire, à la réduction du temps d’exécution d’une tâche ou à l’obtention d’un
ré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 tiers
concernés n’est pas faite ici.


Risques

Un projet de mise en oeuvre d’une technologique ou d’un composant informatique qui ne
peut pas faire preuve d’une réelle valeur ajoutée a peu de chances d’être accepté. On
risque également de s’engager dans une logique de fuite en avant technologique dans
laquelle la technologie est une fin en soi. A terme, le risque est de mettre en évidence une
productivité 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’un
     phé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
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 au
     problè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
Référentiel NPT




4.1.2    Respect des besoins fonctionnels

Révisions
 Version      Date / auteurs      Objet de la révision
   0.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 de
prendre en compte les besoins et les attentes des usagers le plus en amont possible
dans le processus de mise en oeuvre d’une technologie (dans le processus d’assurance
qualité 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 attentes
des usagers ne correspondent pas forcément à ce dont ils ont effectivement besoin, de
la même façon que ce qui leur est initialement proposé dans un projet ne concorde pas
né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 étapes
de validation du projet, ceci afin de traduire le plus efficacement possible leurs attentes
dans 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 et
           les 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 approche
           technico-économique, la solution qui sera retenue).




Observatoire Technologique                                                                 26
Référentiel NPT




Couches et tiers concernés

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


Risques

Une solution ne répondant pas aux besoins fonctionnels exprimés par les utilisateurs
risque 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 avril
2002 : http://www.adae.pm.gouv.fr/spip/article.php3?id_article=80




Observatoire Technologique                                                              27
Référentiel NPT




4.1.3    Ergonomie

Révisions
 Version     Date / auteurs       Objet de la révision
   0.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. Ce
dernier 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 les
notions 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 : une
fois les besoins fonctionnels identifiés, ils doivent être traduits dans l’essence même du
projet, 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 souhaitable
de pouvoir la prendre en compte en amont de la conduite de projet et d’y associer les
utilisateurs 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 il
     faut se préoccuper. Les notions de documentation et d’aide en ligne sont tout aussi
     primordiales.

Observatoire Technologique                                                                     28
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 contact
     avec 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 applications
     qui 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é des
utilisateurs. 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 utilisateurs
     ont-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 vaste
et qui peut être un métier en soit, on peut se référer avantageusement aux liens présentés
dans la section Références ci-dessous.

Observatoire Technologique                                                              29
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
Référentiel NPT




4.1.4    Accessibilité

Révisions
 Version     Date / auteurs     Objet de la révision
   0.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 de
la communication (TIC) met en avant les notions d’intégration et de cyber-inclusion. Cela
passe notamment par la prise en compte de l’accessibilité aux solutions informatiques
mises en oeuvre. Plusieurs raisons (juridiques, économiques, sociales et morales no-
tamment) militent en faveur d’un accès facilité aux TIC pour les personnes souffrant
d’un handicap. Les besoins de ces personnes ne sont souvent pas considérés lors de
la 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, en
amont de la mise en oeuvre d’une technologie.
On présente souvent la notion d’accessibilité comme une déclinaison particulière de la
notion d’ergonomie (voir sous-dimension correspondante) pour la catégorie particulière
d’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 la
lecture ou la langue en vigueur.
Les quatre principales catégories de handicap sont les handicaps visuels, auditifs, de
mobilité 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 par
     exemple pouvoir bénéficier de feuilles de style adaptées.

   • Handicaps auditifs. Les personnes sourdes devraient par exemple pouvoir utiliser
     les 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 certains
     dispositifs de stockage.

   • Handicaps cognitifs. Une conception consistante des interfaces utilisateurs et un
     langage 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éder
aux 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èmes
d’exploitation et des plateformes matérielles sous-jacents.
Dans ce contexte, l’accessibilité mesure la facilité d’accès à la technologie étudiée pour
les utilisateurs présentant un handicap quel qu’il soit.



Observatoire Technologique                                                                 31
Référentiel NPT




Couches concernées

   • Application. Dans cette couche, ce sont les interfaces utilisateurs des applications
     qui sont principalement concernés. L’accessibilité est ici d’autant plus importante
     qu’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 par
     exemple 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 applications
     qui sont principalement concernés. L’accessibilité est ici d’autant plus importante
     qu’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 permet
     une 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 un
systè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 éventail
d’utilisateurs ou de citoyens (système de messagerie, suite bureautique ou portail par
exemple).


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 projets
     tournés vers le citoyen ?




Observatoire Technologique                                                                32
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 sites
Web. 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 qui
permettent 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 projets
ainsi 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 UI
Access 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
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
Référentiel NPT




4.2     Aspects sociétaux

Révisions
 Version     Date / auteurs      Objet de la révision
   0.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 la
contribution à la synergie entre l’Etat, la société civile et le secteur privé. Un dernier but
est 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, aux
     citoyens, 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-dimensions
correspondantes.




Observatoire Technologique                                                                 35
Référentiel NPT




4.2.1    Composante sociétale

Révisions
 Version     Date / auteurs     Objet de la révision
   0.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 projet
informatique étudié. Il s’agit également de déterminer la contribution positive qui peut
ainsi ê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 gain
financier. 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 pour
autant la perdre de vue.
A titre d’exemple, on peut considérer que l’adoption à large échelle du logiciel libre au
sein 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 promouvoir
l’émergence d’une économie locale liée au développement de logiciels libres et d’autre
part 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 doit
justifier 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’action
publique 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 avec
     celui 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 de
faciliter la mise en oeuvre d’une technologie ou d’un composant informatique.




Observatoire Technologique                                                               36
Référentiel NPT




Couches et tiers concernés

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


Risques

Une mauvaise perception du contexte socio-politique peut ralentir, voir paralyser la mise
en 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 politique
     tel 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
Référentiel NPT




4.2.2    Cadre légal

Révisions
 Version     Date / auteurs       Objet de la révision
   0.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 que
ces applications et ces systèmes soient protégés contre les risques qui menacent leur
disponibilité, leur intégrité et leur confidentialité. Ce règlement est commun à toutes les
ré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é de
traitement de l’information numérique, la possibilité de croiser de l’information, de tracer
des requêtes et le fait que toute information soit potentiellement accessible à chacun
amè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, sous
son 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 ce
qui échappe au champ de la LPD, soit les fichiers détenus par les entités exclues de la
définition de personne privée ou d’organe fédéral, à savoir les collectivités publiques et
para-publiques autres que la Confédération et les services de son administration, ainsi
que les institutions qui en dépendent.
La quasi totalité des cantons a adopté une législation sur la protection des données
détenues par leur administration. Actuellement la loi en force à Genève est la LITAO (loi
cantonale B 4 35 du 17 décembre 1981 sur les informations traitées automatiquement par
ordinateur), 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 important
que les concepteurs de projets informatiques arrêtent leur politique de protection des
donné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
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 collecte
     et 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 est
     tenu de communiquer de par la loi ;

   • Concentration et centralisation des données : celles-ci ne doivent pas être accrues
     sous 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 les
     communiquer ; les éléments suivants doivent lui être communiqués lors de toute
     opé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ée
     de 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é dans
     ses recherches (notamment par son numéro IP ou des cookies) ; le recours aux
     pseudonymes, ainsi qu’aux technologies de la vie privée doit être encouragé toutes
     les fois que c’est possible ;

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

   • Communications et transactions : la confidentialité, l’intégrité et l’authentification de
     donné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 (LIPAD
A 2 08) a été votée. Elle est entrée en vigueur le 1er mars 2002. Elle garantit l’information
relative aux activités des institutions publiques et para-étatiques, dans toute la mesure
compatible avec les droits découlant de la protection de la sphère privée, en particulier
des 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 la
participation à la vie publique. Aucun règlement d’exécution n’a encore été édicté pour
cette 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 en
oeuvre problématique. C’est donc d’abord sur l’usage et la maîtrise de l’outil que doit se
porter la réflexion plutôt que sur la technologie elle-même. A un niveau plus technique, il
faut veiller à ce qu’une technologie offre toujours des possibilités de configuration et de
paramétrage propres à gérer et à maîtriser correctement ces aspects.




Observatoire Technologique                                                                39
Référentiel NPT




Propriété intellectuelle

Un dernier point concerne les contraintes légales relatives à la propriété intellectuelle et
plus spécialement à celui des licences d’utilisation. Obtenir une expertise légale dans ce
domaine peut constituer un défi non-négligeable car les licences d’utilisation imposent
parfois des contraintes légales fortes qu’il faut pouvoir évaluer et prendre en compte
correctement 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 logiciel
libre, 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 succinctement
ces 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’est
pas 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égissant
     son existence n’est pas encore clairement défini risque de voir sa mise en oeuvre
     retardé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 à la
     protection 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 comme
sensibles, les dispositions en vigueur aujourd’hui aux niveau fédéral et cantonal ne se
recoupent 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 les
abus d’utilisation. L’introduction de dossiers santé virtuels ne manquera donc pas de sou-
lever de nombreux problèmes juridiques.



Observatoire Technologique                                                               40
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
Référentiel NPT




4.2.3    Cadre éthique

Révisions
 Version     Date / auteurs     Objet de la révision
   0.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 et
des 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’emporter
sur 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 sont
mises en perspective avec la responsabilité de l’administration à l’égard de l’ensemble
des 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ère
les données se rapportant à des personnes morales.
Les technologies actuelles se montrent toujours plus performantes dans le domaine du
traitement 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 vigilance
soutenue 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 et
constitue une excellente référence dans ce domaine (voir également la sous-dimension
Cadre 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 en
oeuvre problématique. C’est donc d’abord sur l’usage et la maîtrise de l’outil que doit se
porter la réflexion plutôt que sur la technologie elle-même. Plus cette réflexion est menée
en amont du processus de mise en oeuvre de la technologie, plus il sera aisé de résoudre
les 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îtriser
correctement 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ôle
des 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 des
fournisseurs 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 (voir
Références).




Observatoire Technologique                                                               42
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 applications
     qui sont concernés. La véracité des informations saisies ou la pertinence de leur
     affichage sont importants.

   • Plateforme supérieure. Le fonctionnement de cette plateforme peut interférer avec
     les 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 des
     fournisseurs 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 qui
     sont 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ées
     au 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 telles
     données dans une base unique est à proscrire.


Risques

Le risque initial d’éluder les questions éthiques aux dépens de l’aspect technologique
est souvent bien réel. Dans ce contexte les groupes d’utilisateurs, les différents comités
d’é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’ont
pas été suffisamment pris en compte.


Mesures

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

  1. La mise en oeuvre de la technologie ou du composant informatique considérés
     est-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
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 les
     aspects 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 du
     Canton de Genève ?


Aspects métier

Les informations médicales sont des données sensibles par excellence. Le domaine de
la santé se retrouve ainsi naturellement aux avant-postes lorsque l’on évoque le respect
du cadre éthique. Le recours dans ce cas à la Commission de Contrôle de l’Informatique
de 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
Chapitre 5

Dimensions relatives aux Qualités
Systé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. Ces
dimensions, ainsi que les sous-dimensions correspondantes prennent en compte les as-
pects intrinsèques des technologies et des composants informatiques étudiés. Elles ne
dé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 comme
des qualités systémiques, sont développées dans une autre section.




                                           45
Référentiel NPT




5.1     Évolutivité

Révisions
 Version     Date / auteurs    Objet de la révision
   0.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ème
     d’information) : cette dimension mesure la capacité d’un sous-système à évoluer
     pour 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 nombre
     d’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èmes
     qui en tirent parti. Par exemple, un langage orienté-objet a un impact positif sur
     l’évolutivité des systèmes développés avec ce langage.


Sous-dimensions

   • Scalabilité : mesure la capacité d’un système à supporter une charge croissante
     grâ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 les
     volumé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
Référentiel NPT




   • Plateforme supérieure. Les technologies mises en oeuvre dans cette couche sont
     susceptibles 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 de
     messages 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ée
     dans la mesure où des dépendances fortes existent entre les couches Plateforme
     supé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 plus
     puissante 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 au
     niveau de l’interface utilisateur. Il est important que cette évolutivité soit possible
     sans avoir d’impact sur les composants des autres tiers (le découplage des tiers
     est 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 changement
     de 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 en
     charge, la sécurité, la facilité de gestion. En effet, en faisant évoluer la qualité de
     service, il est possible que des composants dans la couche ressources doivent être
     remplacés (p.ex. remplacer la base de données). Faire en sorte que cette évolution
     soit possible sans affecter les couches amont (client, présentation, métier) est le
     rô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 la
     qualité 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 ne
puisse pas répondre aux attentes des utilisateurs. Cela peut se produire s’il n’est pas
possible 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 les
qualités de services en fonction de leur évolution.



Observatoire Technologique                                                                 47
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 ? A
     quel coût ? Dans quelle mesure ?

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

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

   • Le système peut-il évoluer pour répondre à un changement des règles métiers ? A
     quel 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
Référentiel NPT




5.1.1    Scalabilité

Révisions
 Version     Date / auteurs    Objet de la révision
   0.1      2003-09-11 / oli   Version initiale


Description

La scalabilité mesure la capacité d’un système à supporter une charge croissante (nombre
total d’utilisateurs, nombre d’utilisateurs concurrents, nombre de requêtes, etc.) par l’ajout
successif de ressources (CPU, mémoire, etc.). Idéalement, le rapport entre la charge et
le 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 nombre
     d’utilisateurs (ainsi que les projections sur son accroissement), que le nombre de
     services ou de requêtes peuvent être spécifiés. Les couches sous-jacentes doivent
     ensuite permettre d’atteindre les niveaux souhaités.
   • Application. Au niveau de cette couche, c’est la scalabilité d’une partie du système
     d’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 recherche
     documentaire). L’architecture du service doit être conçue grâce aux mécanismes
     offert 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, il
     est par exemple possible d’appliquer le principe de répartition de charge au niveau
     des 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 qui
     permet de faire face à une évolution de leur nombre.
   • Plateforme inférieure. Au niveau de l’OS, la scalabilité est liée à la capacité à gérer
     un grand nombre de ressources. Certains systèmes d’exploitation ne peuvent gérer
     qu’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é de
     mémoire beaucoup plus grande qu’un système d’exploitation 32 bits. Il permet donc
     une 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 en
     termes 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 (ajout
     de composants relativement peu puissants sur lesquels sont répartis la charge),
     de la scalabilité verticale (ajout de ressources dans un composant qui devient très
     puissant).


Observatoire Technologique                                                                49
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques

Contenu connexe

Tendances

Conception et développement d’une place de marché B2C
Conception et développement d’une place de marché B2CConception et développement d’une place de marché B2C
Conception et développement d’une place de marché B2C
Nassim Bahri
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
Ben Ahmed Zohra
 
Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Deep Learning : Application à la reconnaissance d’objets de classes multiples...Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Haytam EL YOUSSFI
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
Donia Hammami
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Référentiel e-Société
Référentiel e-SociétéRéférentiel e-Société
Référentiel e-Société
Genève Lab
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
Glei Hadji
 
iRecruite
iRecruiteiRecruite
iRecruite
Donia Hammami
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
Codendi
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
Mohamed Arar
 
Rapport de sprint finale (All Project part)
Rapport de sprint finale (All Project part)Rapport de sprint finale (All Project part)
Rapport de sprint finale (All Project part)
Ghodbane Heni
 
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance d...
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance d...pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance d...
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance d...
Ben Messaoud Aymen
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
Donia Hammami
 
Guide latex.
Guide latex.Guide latex.
Guide latex.
AbdullahOmar64
 
Cours base données
Cours base donnéesCours base données
Cours base données
kerosina
 
Mise en-place-d-une-gestion-electronique-de-document
Mise en-place-d-une-gestion-electronique-de-documentMise en-place-d-une-gestion-electronique-de-document
Mise en-place-d-une-gestion-electronique-de-document
Cyrille Roméo Bakagna
 

Tendances (20)

Conception et développement d’une place de marché B2C
Conception et développement d’une place de marché B2CConception et développement d’une place de marché B2C
Conception et développement d’une place de marché B2C
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Algo
AlgoAlgo
Algo
 
Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Deep Learning : Application à la reconnaissance d’objets de classes multiples...Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Deep Learning : Application à la reconnaissance d’objets de classes multiples...
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Référentiel e-Société
Référentiel e-SociétéRéférentiel e-Société
Référentiel e-Société
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 
iRecruite
iRecruiteiRecruite
iRecruite
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 
Rapport de sprint finale (All Project part)
Rapport de sprint finale (All Project part)Rapport de sprint finale (All Project part)
Rapport de sprint finale (All Project part)
 
Nagios
NagiosNagios
Nagios
 
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance d...
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance d...pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance d...
pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance d...
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
Guide latex.
Guide latex.Guide latex.
Guide latex.
 
Cours base données
Cours base donnéesCours base données
Cours base données
 
Mise en-place-d-une-gestion-electronique-de-document
Mise en-place-d-une-gestion-electronique-de-documentMise en-place-d-une-gestion-electronique-de-document
Mise en-place-d-une-gestion-electronique-de-document
 
Ids
IdsIds
Ids
 

En vedette

Spb stella paillé la gestion des talents des pratiques gagnantes_2010_stellap...
Spb stella paillé la gestion des talents des pratiques gagnantes_2010_stellap...Spb stella paillé la gestion des talents des pratiques gagnantes_2010_stellap...
Spb stella paillé la gestion des talents des pratiques gagnantes_2010_stellap...
SPB Psychologie organisationnelle/SPB Organizational Psychology
 
Introduction à Uml
Introduction à UmlIntroduction à Uml
Introduction à Uml
Mireille Blay-Fornarino
 
RH en quête d'influence
RH en quête d'influenceRH en quête d'influence
Conférence marketing télécom
Conférence marketing télécomConférence marketing télécom
Conférence marketing télécom
Eric Pradel Lepage
 

En vedette (8)

Group pursuit survival
Group pursuit survivalGroup pursuit survival
Group pursuit survival
 
Carton Vert
Carton VertCarton Vert
Carton Vert
 
Carton Vert
Carton VertCarton Vert
Carton Vert
 
Leaders 2025
Leaders 2025Leaders 2025
Leaders 2025
 
Spb stella paillé la gestion des talents des pratiques gagnantes_2010_stellap...
Spb stella paillé la gestion des talents des pratiques gagnantes_2010_stellap...Spb stella paillé la gestion des talents des pratiques gagnantes_2010_stellap...
Spb stella paillé la gestion des talents des pratiques gagnantes_2010_stellap...
 
Introduction à Uml
Introduction à UmlIntroduction à Uml
Introduction à Uml
 
RH en quête d'influence
RH en quête d'influenceRH en quête d'influence
RH en quête d'influence
 
Conférence marketing télécom
Conférence marketing télécomConférence marketing télécom
Conférence marketing télécom
 

Similaire à Le Référentiel Nouvelles Plateformes Technologiques

Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
Mohamed Aziz Chetoui
 
Base-de-données.pdf
Base-de-données.pdfBase-de-données.pdf
Base-de-données.pdf
djallel2
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
nesrine haloui
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Alaaeddine Tlich
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
ichrafkhalfaoui
 
9783642290435 t1
9783642290435 t19783642290435 t1
9783642290435 t1
nenena1976
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
Adem Amen Allah Thabti
 
notes-de-cours-de-fouille-de-donnees.pdf
notes-de-cours-de-fouille-de-donnees.pdfnotes-de-cours-de-fouille-de-donnees.pdf
notes-de-cours-de-fouille-de-donnees.pdf
CoulibalyYoussoufngo
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
Taieb Kristou
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Mohamed Amine Mahmoudi
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
Université de Rennes 1
 
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM NortelConception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Tidiane Sylla
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
SafaAballagh
 

Similaire à Le Référentiel Nouvelles Plateformes Technologiques (20)

Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
Base-de-données.pdf
Base-de-données.pdfBase-de-données.pdf
Base-de-données.pdf
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Cbdsys 2
Cbdsys 2Cbdsys 2
Cbdsys 2
 
9783642290435 t1
9783642290435 t19783642290435 t1
9783642290435 t1
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Rapport
RapportRapport
Rapport
 
siem.pdf
siem.pdfsiem.pdf
siem.pdf
 
notes-de-cours-de-fouille-de-donnees.pdf
notes-de-cours-de-fouille-de-donnees.pdfnotes-de-cours-de-fouille-de-donnees.pdf
notes-de-cours-de-fouille-de-donnees.pdf
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM NortelConception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 

Plus de Genève Lab

L'innovation ouverte à l'ère du COVID
L'innovation ouverte à l'ère du COVIDL'innovation ouverte à l'ère du COVID
L'innovation ouverte à l'ère du COVID
Genève Lab
 
Open data - leçons en temps de crise
Open data - leçons en temps de criseOpen data - leçons en temps de crise
Open data - leçons en temps de crise
Genève Lab
 
COVID-19 - L'impact des données ouvertes dans la couverture médiatique
COVID-19 - L'impact des données ouvertes dans la couverture médiatiqueCOVID-19 - L'impact des données ouvertes dans la couverture médiatique
COVID-19 - L'impact des données ouvertes dans la couverture médiatique
Genève Lab
 
Reduction to practice: From DP3T to EN to SwissCovid
Reduction to practice: From DP3T to EN to SwissCovidReduction to practice: From DP3T to EN to SwissCovid
Reduction to practice: From DP3T to EN to SwissCovid
Genève Lab
 
Mobilising collective intelligence to tackle the COVID-19 threat
Mobilising collective intelligence to tackle the COVID-19 threatMobilising collective intelligence to tackle the COVID-19 threat
Mobilising collective intelligence to tackle the COVID-19 threat
Genève Lab
 
La littératie des données comme une pierre angulaire d'une nouvelle culture n...
La littératie des données comme une pierre angulaire d'une nouvelle culture n...La littératie des données comme une pierre angulaire d'une nouvelle culture n...
La littératie des données comme une pierre angulaire d'une nouvelle culture n...
Genève Lab
 
Les ingrédients de la créativité
Les ingrédients de la créativitéLes ingrédients de la créativité
Les ingrédients de la créativité
Genève Lab
 
Collective Intelligence: what is it and why is it good for cities?
Collective Intelligence: what is it and why is it good for cities?Collective Intelligence: what is it and why is it good for cities?
Collective Intelligence: what is it and why is it good for cities?
Genève Lab
 
Pluralisme des modes numériques de participation des habitants
Pluralisme des modes numériques de participation des habitantsPluralisme des modes numériques de participation des habitants
Pluralisme des modes numériques de participation des habitants
Genève Lab
 
Consul project : improving democracy through digital participation
Consul project : improving democracy through digital participationConsul project : improving democracy through digital participation
Consul project : improving democracy through digital participation
Genève Lab
 
L'art au service de l'innovation sociale
L'art au service de l'innovation socialeL'art au service de l'innovation sociale
L'art au service de l'innovation sociale
Genève Lab
 
Open Geneva
Open GenevaOpen Geneva
Open Geneva
Genève Lab
 
RGPD et citoyens : et si le mariage prenait ?
RGPD et citoyens : et si le mariage prenait ?RGPD et citoyens : et si le mariage prenait ?
RGPD et citoyens : et si le mariage prenait ?
Genève Lab
 
Plateforme de consultation et participation citoyenne Consul
Plateforme de consultation et participation citoyenne ConsulPlateforme de consultation et participation citoyenne Consul
Plateforme de consultation et participation citoyenne Consul
Genève Lab
 
Introduction à Linked Data
Introduction à Linked DataIntroduction à Linked Data
Introduction à Linked Data
Genève Lab
 
La question éthique à l'ère de la data economy, de l'intelligence artificiell...
La question éthique à l'ère de la data economy, de l'intelligence artificiell...La question éthique à l'ère de la data economy, de l'intelligence artificiell...
La question éthique à l'ère de la data economy, de l'intelligence artificiell...
Genève Lab
 
L'économie inclusive et les enjeux du numérique comme relais de croissance
L'économie inclusive et les enjeux du numérique comme relais de croissanceL'économie inclusive et les enjeux du numérique comme relais de croissance
L'économie inclusive et les enjeux du numérique comme relais de croissance
Genève Lab
 
Entreprise Numérisée : Ethique et GouvernanceS
Entreprise Numérisée : Ethique et GouvernanceSEntreprise Numérisée : Ethique et GouvernanceS
Entreprise Numérisée : Ethique et GouvernanceS
Genève Lab
 
Exponentail Ethics
Exponentail EthicsExponentail Ethics
Exponentail Ethics
Genève Lab
 
Notre avenir numérique
Notre avenir numérique  Notre avenir numérique
Notre avenir numérique
Genève Lab
 

Plus de Genève Lab (20)

L'innovation ouverte à l'ère du COVID
L'innovation ouverte à l'ère du COVIDL'innovation ouverte à l'ère du COVID
L'innovation ouverte à l'ère du COVID
 
Open data - leçons en temps de crise
Open data - leçons en temps de criseOpen data - leçons en temps de crise
Open data - leçons en temps de crise
 
COVID-19 - L'impact des données ouvertes dans la couverture médiatique
COVID-19 - L'impact des données ouvertes dans la couverture médiatiqueCOVID-19 - L'impact des données ouvertes dans la couverture médiatique
COVID-19 - L'impact des données ouvertes dans la couverture médiatique
 
Reduction to practice: From DP3T to EN to SwissCovid
Reduction to practice: From DP3T to EN to SwissCovidReduction to practice: From DP3T to EN to SwissCovid
Reduction to practice: From DP3T to EN to SwissCovid
 
Mobilising collective intelligence to tackle the COVID-19 threat
Mobilising collective intelligence to tackle the COVID-19 threatMobilising collective intelligence to tackle the COVID-19 threat
Mobilising collective intelligence to tackle the COVID-19 threat
 
La littératie des données comme une pierre angulaire d'une nouvelle culture n...
La littératie des données comme une pierre angulaire d'une nouvelle culture n...La littératie des données comme une pierre angulaire d'une nouvelle culture n...
La littératie des données comme une pierre angulaire d'une nouvelle culture n...
 
Les ingrédients de la créativité
Les ingrédients de la créativitéLes ingrédients de la créativité
Les ingrédients de la créativité
 
Collective Intelligence: what is it and why is it good for cities?
Collective Intelligence: what is it and why is it good for cities?Collective Intelligence: what is it and why is it good for cities?
Collective Intelligence: what is it and why is it good for cities?
 
Pluralisme des modes numériques de participation des habitants
Pluralisme des modes numériques de participation des habitantsPluralisme des modes numériques de participation des habitants
Pluralisme des modes numériques de participation des habitants
 
Consul project : improving democracy through digital participation
Consul project : improving democracy through digital participationConsul project : improving democracy through digital participation
Consul project : improving democracy through digital participation
 
L'art au service de l'innovation sociale
L'art au service de l'innovation socialeL'art au service de l'innovation sociale
L'art au service de l'innovation sociale
 
Open Geneva
Open GenevaOpen Geneva
Open Geneva
 
RGPD et citoyens : et si le mariage prenait ?
RGPD et citoyens : et si le mariage prenait ?RGPD et citoyens : et si le mariage prenait ?
RGPD et citoyens : et si le mariage prenait ?
 
Plateforme de consultation et participation citoyenne Consul
Plateforme de consultation et participation citoyenne ConsulPlateforme de consultation et participation citoyenne Consul
Plateforme de consultation et participation citoyenne Consul
 
Introduction à Linked Data
Introduction à Linked DataIntroduction à Linked Data
Introduction à Linked Data
 
La question éthique à l'ère de la data economy, de l'intelligence artificiell...
La question éthique à l'ère de la data economy, de l'intelligence artificiell...La question éthique à l'ère de la data economy, de l'intelligence artificiell...
La question éthique à l'ère de la data economy, de l'intelligence artificiell...
 
L'économie inclusive et les enjeux du numérique comme relais de croissance
L'économie inclusive et les enjeux du numérique comme relais de croissanceL'économie inclusive et les enjeux du numérique comme relais de croissance
L'économie inclusive et les enjeux du numérique comme relais de croissance
 
Entreprise Numérisée : Ethique et GouvernanceS
Entreprise Numérisée : Ethique et GouvernanceSEntreprise Numérisée : Ethique et GouvernanceS
Entreprise Numérisée : Ethique et GouvernanceS
 
Exponentail Ethics
Exponentail EthicsExponentail Ethics
Exponentail Ethics
 
Notre avenir numérique
Notre avenir numérique  Notre avenir numérique
Notre avenir numérique
 

Dernier

Cours d'Intelligence Artificielle et Apprentissage Automatique.pptx
Cours d'Intelligence Artificielle et Apprentissage Automatique.pptxCours d'Intelligence Artificielle et Apprentissage Automatique.pptx
Cours d'Intelligence Artificielle et Apprentissage Automatique.pptx
Jacques KIZA DIMANDJA
 
Introduction à Crossplane (Talk Devoxx 2023)
Introduction à Crossplane (Talk Devoxx 2023)Introduction à Crossplane (Talk Devoxx 2023)
Introduction à Crossplane (Talk Devoxx 2023)
Adrien Blind
 
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
InnovaSter-Trade Ltd.
 
Meetup LFUG : Cahier de vacances Liferay
Meetup LFUG : Cahier de vacances LiferayMeetup LFUG : Cahier de vacances Liferay
Meetup LFUG : Cahier de vacances Liferay
Sébastien Le Marchand
 
Lae-ac1-5_english-fraançais_qins italy.pdf
Lae-ac1-5_english-fraançais_qins italy.pdfLae-ac1-5_english-fraançais_qins italy.pdf
Lae-ac1-5_english-fraançais_qins italy.pdf
djelloulbra
 
Transformation Digitale - Initiez-vous à l'informatique et à l'utilisation de...
Transformation Digitale - Initiez-vous à l'informatique et à l'utilisation de...Transformation Digitale - Initiez-vous à l'informatique et à l'utilisation de...
Transformation Digitale - Initiez-vous à l'informatique et à l'utilisation de...
Maalik Jallo
 
procede de fabrication mecanique et industriel
procede de fabrication mecanique et industrielprocede de fabrication mecanique et industriel
procede de fabrication mecanique et industriel
saadbellaari
 

Dernier (7)

Cours d'Intelligence Artificielle et Apprentissage Automatique.pptx
Cours d'Intelligence Artificielle et Apprentissage Automatique.pptxCours d'Intelligence Artificielle et Apprentissage Automatique.pptx
Cours d'Intelligence Artificielle et Apprentissage Automatique.pptx
 
Introduction à Crossplane (Talk Devoxx 2023)
Introduction à Crossplane (Talk Devoxx 2023)Introduction à Crossplane (Talk Devoxx 2023)
Introduction à Crossplane (Talk Devoxx 2023)
 
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
 
Meetup LFUG : Cahier de vacances Liferay
Meetup LFUG : Cahier de vacances LiferayMeetup LFUG : Cahier de vacances Liferay
Meetup LFUG : Cahier de vacances Liferay
 
Lae-ac1-5_english-fraançais_qins italy.pdf
Lae-ac1-5_english-fraançais_qins italy.pdfLae-ac1-5_english-fraançais_qins italy.pdf
Lae-ac1-5_english-fraançais_qins italy.pdf
 
Transformation Digitale - Initiez-vous à l'informatique et à l'utilisation de...
Transformation Digitale - Initiez-vous à l'informatique et à l'utilisation de...Transformation Digitale - Initiez-vous à l'informatique et à l'utilisation de...
Transformation Digitale - Initiez-vous à l'informatique et à l'utilisation de...
 
procede de fabrication mecanique et industriel
procede de fabrication mecanique et industrielprocede de fabrication mecanique et industriel
procede de fabrication mecanique et industriel
 

Le Référentiel Nouvelles Plateformes Technologiques

  • 1. 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/ ot@etat.ge.ch
  • 2. Référentiel NPT Copyright c 2003–2004 CTI, Observatoire Technologique. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. Première partie Introduction au Référentiel NPT 4
  • 7. Chapitre 1 Introduction 1.1 Résumé Le référentiel Nouvelles Plateformes Technologiques (NPT) est un outil élaboré par l’Observatoire Technologique du CTI dans le but d’analyser une technologie, un système ou un composant 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. 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 et l’évaluation microscopique d’un composant du système informatique et (iii) la description et l’évaluation d’une technologie ou d’un standard. Le référentiel NPT est structuré selon trois axes et représenté graphiquement sous la forme 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. Les dimensions 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 et l’évaluation des fournisseurs. Les qualités systémiques incluent l’évolutivité, les qualités de service, l’exploitabilité, l’interopérabilité et la maturité du composant. Les dimensions relatives à l’organisation incluent les coûts, les compétences et la formation. Enfin, les dimensions relatives à la sécurité incluent la gestion de politiques d’accès, le contrôle et 1 Ce 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
  • 8. Référentiel NPT la confidentialité. Chacune des dimensions mentionnées est elle-même décomposée en sous-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’analyse et d’illustrer ces objectifs avec quelques cas d’utilisation envisagés. Les chapitres 2 et 3 sont 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 qui devraient ê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ée par rapport à chaque couche et à chaque tiers de l’architecture du système. La partie II est 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 en fonction des retours d’expérience. Par ailleurs, il est également prévu d’intégrer toute nouvelle information externe ou interne qui permettra une amélioration du référentiel ou de 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 pour des 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èvement décrite. • Le chapitre 3 décrit la structure tri-dimensionnelle du référentiel NPT. Les trois axes du référentiel, c’est-à-dire les couches, les tiers et les dimensions, sont décrits et illustré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 dimension est définie et analysée en regard des deux premiers axes (c’est-à-dire en regard des couches et des tiers). 1.4 A qui s’adresse ce document Dans un premier temps, ce document s’adresse : Observatoire Technologique 6
  • 9. 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
  • 10. Chapitre 2 Définitions, objectifs et utilisation du 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 sont ensuite énoncés et illustrés à l’aide de trois cas d’utilisation. Finalement, l’instrumentation du 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érentiel est 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 plusieurs dimensions. Cette approche est applicable aussi bien au niveau macroscopique (analyse d’un système informatique global) qu’au niveau microscopique (analyse détaillée d’un composant du système informatique). Cette définition met l’accent sur le concept d’architecture. Or, il n’existe pas de définition unique 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 sont proposées pour le concept d’architecture logicielle (software architecture). Elles peuvent né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 . 1 http://www.sei.cmu.edu/architecture/definitions.html 2 Software Architecture in Practice, Addison-Wesley, 1997 3 The UML Modeling Language User Guide, Addison-Wesley, 1999 8
  • 11. 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 structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. By “externally visible” properties, we are referring to those assumptions other components can 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 a software architecture must abstract away some information from the system (otherwise there is no point looking at the architecture, we are simply viewing the entire system) and yet provide enough information to be a basis for analysis, decision making, and hence risk 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 software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization—these ele- ments and their interfaces, their collaborations, and their composition (The UML Modeling Language 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éfinis de 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 de mé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 ou automatisés (par un système informatique). Observatoire Technologique 9
  • 12. 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 avec des composants matériels et logiciels. Un système informatique permet d’automatiser une 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’intention d’une division particulière du CTI. Au contraire, il est suffisamment générique pour être utile à l’ensemble des divisions du CTI ainsi qu’à d’autres entités internes ou partenaires de 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-forme maté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, la maniè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 la documentation. 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 de l’É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ée par 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 Framework CTI peuvent être partagés par différentes applications. Observatoire Technologique 10
  • 13. Référentiel NPT • Les dépendances plus ou moins grandes entre les composants du système. Cette analyse permet par exemple de mettre en évidence des relations de dépendance vis à vis de certains fournisseurs. • La manière dont les divisions et les groupes du CTI se partagent l’expertise et la responsabilité 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’une application métier, le référentiel permet de comparer et d’évaluer un ensemble d’alterna- tives sur plusieurs dimensions. F IG . 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 est la 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 la pré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/ou graphiquement. Un tableau à deux dimensions, représentant les couches verticale- ment et les tiers horizontalement, est souvent très utile. Un exemple est illustré par la figure 2.1. Ce tableau décrit l’architecture d’une application métier. Le périmètre couvert par l’architecture (par rapport à toutes les couches et à tous les tiers) est représenté par le rectangle jaune. Le schéma met également en évidence le fait Observatoire Technologique 11
  • 14. 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 donc possible 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 couche et à chaque tiers. Il arrive néanmoins qu’une dimension ne soit applicable qu’à un sous-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 technologie ou 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 plus transversal. Dans ce cas, la première étape consiste à situer la technologie ou le standard étudié dans le 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ée par rapport aux deux axes, il est plus facile d’identifier les personnes qui, au CTI, sont le plus à même de fournir des informations par rapport à la technologie. Parfois, une technologie a également le potentiel de permettre une réorganisation du système informatique global. Par exemple, des technologies d’intégration comme les connecteurs JCA peuvent augmenter l’interopérabilité entre certaines applications mé- tiers. De telles propriétés peuvent également être représentées graphiquement en tirant parti 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 habitudes seront prises graduellement et évolueront dans le temps, en fonction de l’adoption du référentiel par différentes personnes. Une des possibilités proposées aux utilisateurs du référentiel NPT est d’instrumenter le référentiel avec un outil d’aide à la décision. Une telle instrumentation est particulièrement intéressante lorsque le référentiel est utilisé pour choisir un composant parmi plusieurs alternatives. Par exemple, l’Observatoire Technologique a évalué et acquis des licences pour le logiciel d’aide à la décision multi-critères Web-HIPRE. Ce logiciel permet la définition de critères d’é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 et peuvent manipulés interactivement. Un exemple d’écran du logiciel est représenté dans la Figure 2.2. Observatoire Technologique 12
  • 15. Référentiel NPT F IG . 2.2 – Capture d’écran du logiciel Web-HIPRE. Observatoire Technologique 13
  • 16. 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 par trois types d’utilisation envisagés. La discussion a brièvement mentionné le fait que le référentiel était structuré selon trois axes : celui des couches, celui des tiers et celui des dimensions. 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é graphiquement sous la forme d’un cube. Le premier axe est utilisé pour décomposer le système en couches. Le deuxième axe est utilisé pour décomposer le système en tiers (dans le sens d’une architecture multi-tiers). Le troisième axe est utilisé pour évaluer le système en tenant 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 des tiers du référentiel. Cette étape permet donc de situer le système dans les limites du 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 orthogonales aux 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 tiers du 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
  • 17. Référentiel NPT F IG . 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 couche inférieure. Les couches sont indépendantes les unes des autres et communiquent au travers 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. Plus important, 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, il est possible que seul un fournisseur fournisse une implémentation de la couche. Cette situation crée une relation de dépendance vis à vis du fournisseur. En effet, remplacer la couche revient à changer l’interface et oblige donc à modifier les composants de la couche supérieure. Un exemple est une application développée directement au-dessus du 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 et les composants réseau. Observatoire Technologique 15
  • 18. 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 analyse permet de mettre en évidence la variété plus ou moins grande des composants, aussi bien 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ême si 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 peuvent se poser à ce niveau, par exemple : • Quels types de ressources sont-elles requises par la solution ? (par exemple quels sont 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 et offre 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 de pé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érielles différentes. Par exemple, le même système d’exploitation peut être disponible sur des architectures 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 de cette 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 œuvre au 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ème d’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. Les applications développées en Java sont portables de manière tout à fait transparente. Le Observatoire Technologique 16
  • 19. 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 logique de présentation, de traitement et d’accès aux données pour les services déployés par l’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. Une bonne manière d’augmenter cette pérennité est de rendre la couche application la plus indépendante possible des couches inférieures. Pour cela, la première règle à suivre est de communiquer uniquement avec la couche directement inférieure (plate-forme supé- rieure), et privilégier un standard ouvert pour cette couche (par exemple J2EE). Cela garantit 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 le serveur 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és et 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 plusieurs tiers, ce qui est particulièrement utile pour des applications distribuées (et donc pour celles 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’est pas une obligation. Ainsi, s’il est possible de déployer une application multi-tiers sur cinq machines différentes, il est également possible de déployer la même application sur une seule machine. L’architecture de l’application reste la même. Le principe d’architecture multi-tiers est aujourd’hui largement accepté et a été rendu populaire par des technologies telles que CORBA, J2EE et .NET. Néanmoins, il existe plusieurs variantes de cette architecture, par exemple : • l’architecture 3-tiers, qui répartit les composants d’une application distribuées parmi les 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
  • 20. Référentiel NPT tiers de données, qui prend en charge le stockage des informations. Il faut relever que 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 et multi-canaux. Cette architecture est une extension de la précédente et intègre les tiers suivants : (1) le tiers client, (2) le tiers de présentation, (3) le tiers métier, (4) le tiers intégration et (5) le tiers ressources. Le référentiel NPT est conçu sur la base de 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 ne devrait 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 permet en particulier de remplacer les composants d’un tiers sans avoir un impact sur tout le système. 3.3.1 Tiers client Le tiers client héberge les composants avec lesquels les utilisateurs ont une interaction directe. 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 couche du 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 Web qui permet de consulter un annuaire). La conception des composants du tiers client peut se faire avec une des deux approches suivantes : celle dite du “client lourd” (c’est-à-dire les composants sont intégrés sous la forme 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 navigateur web). 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 plusieurs canaux 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. Les composants hébergés dans ce tiers génèrent l’interface utilisateur (typiquement dans un langage 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éberge sont 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 du tiers client. Observatoire Technologique 18
  • 21. 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 permet d’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ées par les services du tiers métier. Dans ce contexte, le découplage entre les tiers ressources et métier permet de remplacer une base de données par une autre, sans que les services applicatifs ne subissent un impact. 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. Les dimensions couvrent un spectre assez large et ne se limitent pas à des considération techniques. 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 niveaux hié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
  • 22. 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 de manière synoptique : Ensembles Dimensions Sous-dimensions Facteurs Humains Aspects utilisateurs Valeur ajoutée Respect des besoins fonctionnels Ergonomie Accessibilité Aspects sociétaux Composante sociétal Cadre légal Cadre éthique Qualités Systémiques Evolutivité Scalabilité Flexibilité Portabilité Maturité de la solution Exploitabilité Maintenabilité Contrôlabilité Qualités de service Stabilité Disponibilité Performance Efficacité Interopérabilité Ouverture Standardisation Organisation Aspects économiques Formation et organisation Utilisateurs Informaticiens Sécurité Gestion des politiques d’accès Authentification Autorisation Contrôle Intégrité Non-répudiation Traçabilité Confidentialité Observatoire Technologique 20
  • 24. Chapitre 4 Dimensions relatives aux Facteurs Humains 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 les sous-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 domaines sont souvent négligés lors de l’étude d’une technologie ou d’un composant informatique alors qu’ils y jouent un rôle important en terme d’adoption et d’utilisation notamment. 22
  • 25. Référentiel NPT 4.1 Aspects utilisateurs Révisions Version Date / auteurs Objet de la révision 0.1 2003-10-03 / pge Version initiale Description La dimension Aspects utilisateurs permet d’analyser les propriétés d’une technologie ou d’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’un système. Sous-dimensions • Valeur ajoutée : mesure la valeur ajoutée pour l’utilisateur, pour le service ou pour l’institution concernés. • Besoins fonctionnels : estime dans quelle mesure les besoins fonctionnels sont couverts. • Ergonomie : estime dans quelle mesure l’ergonomie de la solution est satisfai- sante. • Accessibilité : mesure la facilité d’accès à une technologie pour les utilisateurs présentant un handicap. Observatoire Technologique 23
  • 26. Référentiel NPT 4.1.1 Valeur ajoutée Révisions Version Date / auteurs Objet de la révision 0.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 les différents acteurs impliqués. La notion de valeur ajoutée ne fait naturellement pas ici référence à un quelconque gain financier. Mais elle y est malgré tout fortement liée : outre les aspects techniques, il y a en effet toujours lieu de mettre en balance la valeur ajoutée de la solution avec son coût ainsi qu’avec les risques qui y sont associés (voir dimension Economie). La valeur ajouté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 des besoins en terme de finalité : on pense par exemple à la mise à disposition d’un service supplémentaire, à la réduction du temps d’exécution d’une tâche ou à l’obtention d’un ré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 tiers concernés n’est pas faite ici. Risques Un projet de mise en oeuvre d’une technologique ou d’un composant informatique qui ne peut pas faire preuve d’une réelle valeur ajoutée a peu de chances d’être accepté. On risque également de s’engager dans une logique de fuite en avant technologique dans laquelle la technologie est une fin en soi. A terme, le risque est de mettre en évidence une productivité 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’un phé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
  • 27. 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 au problè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
  • 28. Référentiel NPT 4.1.2 Respect des besoins fonctionnels Révisions Version Date / auteurs Objet de la révision 0.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 de prendre en compte les besoins et les attentes des usagers le plus en amont possible dans le processus de mise en oeuvre d’une technologie (dans le processus d’assurance qualité 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 attentes des usagers ne correspondent pas forcément à ce dont ils ont effectivement besoin, de la même façon que ce qui leur est initialement proposé dans un projet ne concorde pas né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 étapes de validation du projet, ceci afin de traduire le plus efficacement possible leurs attentes dans 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 et les 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 approche technico-économique, la solution qui sera retenue). Observatoire Technologique 26
  • 29. Référentiel NPT Couches et tiers concernés Une déclinaison de la prise en compte des besoins fonctionnels en fonction des couches ou des tiers concernés n’est pas faite ici. Risques Une solution ne répondant pas aux besoins fonctionnels exprimés par les utilisateurs risque 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 avril 2002 : http://www.adae.pm.gouv.fr/spip/article.php3?id_article=80 Observatoire Technologique 27
  • 30. Référentiel NPT 4.1.3 Ergonomie Révisions Version Date / auteurs Objet de la révision 0.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. Ce dernier 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 les notions 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 : une fois les besoins fonctionnels identifiés, ils doivent être traduits dans l’essence même du projet, 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 souhaitable de pouvoir la prendre en compte en amont de la conduite de projet et d’y associer les utilisateurs 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 il faut se préoccuper. Les notions de documentation et d’aide en ligne sont tout aussi primordiales. Observatoire Technologique 28
  • 31. 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 contact avec 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 applications qui 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é des utilisateurs. 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 utilisateurs ont-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 vaste et qui peut être un métier en soit, on peut se référer avantageusement aux liens présentés dans la section Références ci-dessous. Observatoire Technologique 29
  • 32. 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
  • 33. Référentiel NPT 4.1.4 Accessibilité Révisions Version Date / auteurs Objet de la révision 0.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 de la communication (TIC) met en avant les notions d’intégration et de cyber-inclusion. Cela passe notamment par la prise en compte de l’accessibilité aux solutions informatiques mises en oeuvre. Plusieurs raisons (juridiques, économiques, sociales et morales no- tamment) militent en faveur d’un accès facilité aux TIC pour les personnes souffrant d’un handicap. Les besoins de ces personnes ne sont souvent pas considérés lors de la 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, en amont de la mise en oeuvre d’une technologie. On présente souvent la notion d’accessibilité comme une déclinaison particulière de la notion d’ergonomie (voir sous-dimension correspondante) pour la catégorie particulière d’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 la lecture ou la langue en vigueur. Les quatre principales catégories de handicap sont les handicaps visuels, auditifs, de mobilité 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 par exemple pouvoir bénéficier de feuilles de style adaptées. • Handicaps auditifs. Les personnes sourdes devraient par exemple pouvoir utiliser les 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 certains dispositifs de stockage. • Handicaps cognitifs. Une conception consistante des interfaces utilisateurs et un langage 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éder aux 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èmes d’exploitation et des plateformes matérielles sous-jacents. Dans ce contexte, l’accessibilité mesure la facilité d’accès à la technologie étudiée pour les utilisateurs présentant un handicap quel qu’il soit. Observatoire Technologique 31
  • 34. Référentiel NPT Couches concernées • Application. Dans cette couche, ce sont les interfaces utilisateurs des applications qui sont principalement concernés. L’accessibilité est ici d’autant plus importante qu’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 par exemple 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 applications qui sont principalement concernés. L’accessibilité est ici d’autant plus importante qu’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 permet une 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 un systè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 éventail d’utilisateurs ou de citoyens (système de messagerie, suite bureautique ou portail par exemple). 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 projets tournés vers le citoyen ? Observatoire Technologique 32
  • 35. 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 sites Web. 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 qui permettent 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 projets ainsi 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 UI Access 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
  • 36. 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
  • 37. Référentiel NPT 4.2 Aspects sociétaux Révisions Version Date / auteurs Objet de la révision 0.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 la contribution à la synergie entre l’Etat, la société civile et le secteur privé. Un dernier but est 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, aux citoyens, 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-dimensions correspondantes. Observatoire Technologique 35
  • 38. Référentiel NPT 4.2.1 Composante sociétale Révisions Version Date / auteurs Objet de la révision 0.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 projet informatique étudié. Il s’agit également de déterminer la contribution positive qui peut ainsi ê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 gain financier. 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 pour autant la perdre de vue. A titre d’exemple, on peut considérer que l’adoption à large échelle du logiciel libre au sein 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 promouvoir l’émergence d’une économie locale liée au développement de logiciels libres et d’autre part 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 doit justifier 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’action publique 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 avec celui 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 de faciliter la mise en oeuvre d’une technologie ou d’un composant informatique. Observatoire Technologique 36
  • 39. Référentiel NPT Couches et tiers concernés Une déclinaison de la notion de composante sociétale en fonction des couches ou des tiers concernés n’a pas été faite ici. Risques Une mauvaise perception du contexte socio-politique peut ralentir, voir paralyser la mise en 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 politique tel 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
  • 40. Référentiel NPT 4.2.2 Cadre légal Révisions Version Date / auteurs Objet de la révision 0.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 que ces applications et ces systèmes soient protégés contre les risques qui menacent leur disponibilité, leur intégrité et leur confidentialité. Ce règlement est commun à toutes les ré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é de traitement de l’information numérique, la possibilité de croiser de l’information, de tracer des requêtes et le fait que toute information soit potentiellement accessible à chacun amè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, sous son 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 ce qui échappe au champ de la LPD, soit les fichiers détenus par les entités exclues de la définition de personne privée ou d’organe fédéral, à savoir les collectivités publiques et para-publiques autres que la Confédération et les services de son administration, ainsi que les institutions qui en dépendent. La quasi totalité des cantons a adopté une législation sur la protection des données détenues par leur administration. Actuellement la loi en force à Genève est la LITAO (loi cantonale B 4 35 du 17 décembre 1981 sur les informations traitées automatiquement par ordinateur), 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 important que les concepteurs de projets informatiques arrêtent leur politique de protection des donné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
  • 41. 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 collecte et 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 est tenu de communiquer de par la loi ; • Concentration et centralisation des données : celles-ci ne doivent pas être accrues sous 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 les communiquer ; les éléments suivants doivent lui être communiqués lors de toute opé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ée de 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é dans ses recherches (notamment par son numéro IP ou des cookies) ; le recours aux pseudonymes, ainsi qu’aux technologies de la vie privée doit être encouragé toutes les fois que c’est possible ; • Publication des données : toute publication relative à des données personnelles doit être licite ; • Communications et transactions : la confidentialité, l’intégrité et l’authentification de donné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 (LIPAD A 2 08) a été votée. Elle est entrée en vigueur le 1er mars 2002. Elle garantit l’information relative aux activités des institutions publiques et para-étatiques, dans toute la mesure compatible avec les droits découlant de la protection de la sphère privée, en particulier des 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 la participation à la vie publique. Aucun règlement d’exécution n’a encore été édicté pour cette 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 en oeuvre problématique. C’est donc d’abord sur l’usage et la maîtrise de l’outil que doit se porter la réflexion plutôt que sur la technologie elle-même. A un niveau plus technique, il faut veiller à ce qu’une technologie offre toujours des possibilités de configuration et de paramétrage propres à gérer et à maîtriser correctement ces aspects. Observatoire Technologique 39
  • 42. Référentiel NPT Propriété intellectuelle Un dernier point concerne les contraintes légales relatives à la propriété intellectuelle et plus spécialement à celui des licences d’utilisation. Obtenir une expertise légale dans ce domaine peut constituer un défi non-négligeable car les licences d’utilisation imposent parfois des contraintes légales fortes qu’il faut pouvoir évaluer et prendre en compte correctement 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 logiciel libre, 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 succinctement ces 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’est pas 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égissant son existence n’est pas encore clairement défini risque de voir sa mise en oeuvre retardé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 à la protection 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 comme sensibles, les dispositions en vigueur aujourd’hui aux niveau fédéral et cantonal ne se recoupent 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 les abus d’utilisation. L’introduction de dossiers santé virtuels ne manquera donc pas de sou- lever de nombreux problèmes juridiques. Observatoire Technologique 40
  • 43. 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
  • 44. Référentiel NPT 4.2.3 Cadre éthique Révisions Version Date / auteurs Objet de la révision 0.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 et des 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’emporter sur 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 sont mises en perspective avec la responsabilité de l’administration à l’égard de l’ensemble des 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ère les données se rapportant à des personnes morales. Les technologies actuelles se montrent toujours plus performantes dans le domaine du traitement 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 vigilance soutenue 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 et constitue une excellente référence dans ce domaine (voir également la sous-dimension Cadre 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 en oeuvre problématique. C’est donc d’abord sur l’usage et la maîtrise de l’outil que doit se porter la réflexion plutôt que sur la technologie elle-même. Plus cette réflexion est menée en amont du processus de mise en oeuvre de la technologie, plus il sera aisé de résoudre les 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îtriser correctement 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ôle des 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 des fournisseurs 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 (voir Références). Observatoire Technologique 42
  • 45. 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 applications qui sont concernés. La véracité des informations saisies ou la pertinence de leur affichage sont importants. • Plateforme supérieure. Le fonctionnement de cette plateforme peut interférer avec les 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 des fournisseurs 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 qui sont 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ées au 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 telles données dans une base unique est à proscrire. Risques Le risque initial d’éluder les questions éthiques aux dépens de l’aspect technologique est souvent bien réel. Dans ce contexte les groupes d’utilisateurs, les différents comités d’é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’ont pas été suffisamment pris en compte. Mesures Dans les cas où des données sensibles (soit directement, soit par recoupement) sont concernées : 1. La mise en oeuvre de la technologie ou du composant informatique considérés est-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
  • 46. 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 les aspects 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 du Canton de Genève ? Aspects métier Les informations médicales sont des données sensibles par excellence. Le domaine de la santé se retrouve ainsi naturellement aux avant-postes lorsque l’on évoque le respect du cadre éthique. Le recours dans ce cas à la Commission de Contrôle de l’Informatique de 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
  • 47. Chapitre 5 Dimensions relatives aux Qualités Systé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. Ces dimensions, ainsi que les sous-dimensions correspondantes prennent en compte les as- pects intrinsèques des technologies et des composants informatiques étudiés. Elles ne dé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 comme des qualités systémiques, sont développées dans une autre section. 45
  • 48. Référentiel NPT 5.1 Évolutivité Révisions Version Date / auteurs Objet de la révision 0.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ème d’information) : cette dimension mesure la capacité d’un sous-système à évoluer pour 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 nombre d’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èmes qui en tirent parti. Par exemple, un langage orienté-objet a un impact positif sur l’évolutivité des systèmes développés avec ce langage. Sous-dimensions • Scalabilité : mesure la capacité d’un système à supporter une charge croissante grâ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 les volumé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
  • 49. Référentiel NPT • Plateforme supérieure. Les technologies mises en oeuvre dans cette couche sont susceptibles 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 de messages 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ée dans la mesure où des dépendances fortes existent entre les couches Plateforme supé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 plus puissante 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 au niveau de l’interface utilisateur. Il est important que cette évolutivité soit possible sans avoir d’impact sur les composants des autres tiers (le découplage des tiers est 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 changement de 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 en charge, la sécurité, la facilité de gestion. En effet, en faisant évoluer la qualité de service, il est possible que des composants dans la couche ressources doivent être remplacés (p.ex. remplacer la base de données). Faire en sorte que cette évolution soit possible sans affecter les couches amont (client, présentation, métier) est le rô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 la qualité 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 ne puisse pas répondre aux attentes des utilisateurs. Cela peut se produire s’il n’est pas possible 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 les qualités de services en fonction de leur évolution. Observatoire Technologique 47
  • 50. 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 ? A quel coût ? Dans quelle mesure ? • Le système peut-il évoluer pour répondre à un besoin accru de performance ? A quel coût ? Dans quelle mesure ? • Le système peut-il évoluer pour répondre à un besoin accru de sécurité ? A quel coût ? Dans quelle mesure ? • Le système peut-il évoluer pour répondre à un changement des règles métiers ? A quel 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
  • 51. Référentiel NPT 5.1.1 Scalabilité Révisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initiale Description La scalabilité mesure la capacité d’un système à supporter une charge croissante (nombre total d’utilisateurs, nombre d’utilisateurs concurrents, nombre de requêtes, etc.) par l’ajout successif de ressources (CPU, mémoire, etc.). Idéalement, le rapport entre la charge et le 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 nombre d’utilisateurs (ainsi que les projections sur son accroissement), que le nombre de services ou de requêtes peuvent être spécifiés. Les couches sous-jacentes doivent ensuite permettre d’atteindre les niveaux souhaités. • Application. Au niveau de cette couche, c’est la scalabilité d’une partie du système d’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 recherche documentaire). L’architecture du service doit être conçue grâce aux mécanismes offert 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, il est par exemple possible d’appliquer le principe de répartition de charge au niveau des 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 qui permet de faire face à une évolution de leur nombre. • Plateforme inférieure. Au niveau de l’OS, la scalabilité est liée à la capacité à gérer un grand nombre de ressources. Certains systèmes d’exploitation ne peuvent gérer qu’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é de mémoire beaucoup plus grande qu’un système d’exploitation 32 bits. Il permet donc une 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 en termes 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 (ajout de composants relativement peu puissants sur lesquels sont répartis la charge), de la scalabilité verticale (ajout de ressources dans un composant qui devient très puissant). Observatoire Technologique 49