Le Référentiel Nouvelles Plateformes Technologiques
Upcoming SlideShare
Loading in...5
×
 

Le Référentiel Nouvelles Plateformes Technologiques

on

  • 1,003 views

L’Observatoire technologique a élaboré un outil générique d’analyse et d’évaluation de technologie, de systèmes ou de composants informatiques. Il permet d’une part une description de ...

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

Statistics

Views

Total Views
1,003
Views on SlideShare
1,003
Embed Views
0

Actions

Likes
0
Downloads
27
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Le Référentiel Nouvelles Plateformes Technologiques Le Référentiel Nouvelles Plateformes Technologiques Document Transcript

  • 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 2003Observatoire TechnologiqueCentre des technologies de l’informationRépublique et Canton de Genève9 route des AcaciasCP 149, 1211 Genève 8Suissehttp://www.geneve.ch/ot/ot@etat.ge.ch
  • Référentiel NPTCopyright c 2003–2004 CTI, Observatoire Technologique.This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To viewa copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a let-ter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.You are free: • to copy, distribute, display, and perform the work • to make derivative worksUnder 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èresI Introduction au Référentiel NPT 41 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 62 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 . . . 123 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 . . . . 19II Le Référentiel NPT 214 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Observatoire Technologique 2
  • Référentiel NPT 5.4.2 Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997 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é . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Observatoire Technologique 3
  • Première partieIntroduction au Référentiel NPT 4
  • Chapitre 1Introduction1.1 RésuméLe référentiel Nouvelles Plateformes Technologiques (NPT) est un outil élaboré parl’Observatoire Technologique du CTI dans le but d’analyser une technologie, unsystème ou un composant informatiques. Il permet d’une part une description del’objet étudié en terme d’architecture et d’autre part une évaluation fine de cet objetselon une série de critères déterminés.Ce document définit et présente les objectifs du référentiel NPT. Il illustre également l’ap-plication prévue pour le référentiel avec trois cas d’utilisation : (i) la description et l’éva-luation macroscopique du système informatique de l’État de Genève, (ii) la description etl’évaluation microscopique d’un composant du système informatique et (iii) la descriptionet l’évaluation d’une technologie ou d’un standard.Le référentiel NPT est structuré selon trois axes et représenté graphiquement sous laforme d’un cube.1Le premier axe permet de décomposer le système analysé en plusieurs couches : maté-riel, plate-forme inférieure, plate-forme supérieure, application et système d’information.Chaque couche définit un niveau d’abstraction supérieur par rapport à la couche infé-rieure.Le deuxième axe permet de décomposer le système analysé en plusieurs tiers : client,présentation, métier, intégration et ressources. Les tiers reflètent la distribution des com-posants et des services au travers du réseau.Le troisième axe permet d’évaluer le système analysé selon plusieurs dimensions. Lesdimensions du référentiel sont regroupées en quatre sous-ensembles. Les qualités rela-tives au facteur humain incluent les besoins des utilisateurs, la composante sociétale etl’évaluation des fournisseurs. Les qualités systémiques incluent l’évolutivité, les qualitésde service, l’exploitabilité, l’interopérabilité et la maturité du composant. Les dimensionsrelatives à l’organisation incluent les coûts, les compétences et la formation. Enfin, lesdimensions relatives à la sécurité incluent la gestion de politiques d’accès, le contrôle et 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 NPTla confidentialité. Chacune des dimensions mentionnées est elle-même décomposée ensous-dimensions.1.2 Objectifs du documentDans un premier temps, les objectifs de ce document sont de définir le référentiel NPT(ainsi qu’un ensemble de notions y relatives), de décrire les objectifs de cet outil d’analyseet d’illustrer ces objectifs avec quelques cas d’utilisation envisagés. Les chapitres 2 et 3sont dédiées à ces objectifs.Dans un deuxième temps, l’objectif principal de ce document est de présenter le référen-tiel NPT à proprement parler. Ce document décrit donc un ensemble de dimensions quidevraient être considérées lors de l’évaluation de systèmes et de composants informa-tiques. Ce document explique également comment chaque dimension peut être évaluéepar rapport à chaque couche et à chaque tiers de l’architecture du système. La partie IIest dédiée à cet objectif.Le référentiel NPT est conçu pour intégrer des évolutions dynamiques et des change-ments. Les éléments qui le composent actuellement seront évalués sur la base des ex-périences pratiques de ses utilisateurs et des modifications pourront être apportées enfonction des retours d’expérience. Par ailleurs, il est également prévu d’intégrer toutenouvelle information externe ou interne qui permettra une amélioration du référentiel oude sa mise en œuvre.1.3 StructureLe 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 documentDans 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 2Définitions, objectifs et utilisationdu référentielDans ce chapitre, quelques définitions sont d’abord proposées, aussi bien pour le réfé-rentiel NPT que pour des concepts qui lui sont associés. Les objectifs du référentiel sontensuite énoncés et illustrés à l’aide de trois cas d’utilisation. Finalement, l’instrumentationdu référentiel au moyen d’un outil d’aide à la décision est brièvement décrite.2.1 DéfinitionsLe référentiel NPT est défini de la manière suivante :Définition 1 (Référentiel NPT)Le référentiel NPT est un outil d’analyse qui permet de décrire et d’évaluer l’architec-ture de systèmes et de composants informatiques. Dans un premier temps, le référentielest utilisé pour décrire le système analysé en le décomposant en couches et en tiers.Dans un deuxième temps, il est utilisé pour évaluer le système en fonction de plusieursdimensions. Cette approche est applicable aussi bien au niveau macroscopique (analysed’un système informatique global) qu’au niveau microscopique (analyse détaillée d’uncomposant du système informatique).Cette définition met l’accent sur le concept d’architecture. Or, il n’existe pas de définitionunique pour terme. Ainsi, plusieurs dizaines de définition ont été compilées par le Soft-ware Engineering Institute (SEI) à l’Université de Carnegie Mellon1 . Ces définitions sontproposées pour le concept d’architecture logicielle (software architecture). Elles peuventnéanmoins souvent être généralisées pour s’appliquer au concept plus général d’archi-tecture informatique. Deux définitions intéressantes sont celles proposées par Bass, Cle-ments et Kazman2 , respectivement par Booch, Rumbaugh et Jacobson3 . 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 NPTDéfinition 2 (Software Architecture d’après Bass, Clements et Kazman)The software architecture of a program or computing system is the structure or structuresof the system, which comprise software components, the externally visible properties ofthose components, and the relationships among them.By “externally visible” properties, we are referring to those assumptions other componentscan make of a component, such as its provided services, performance characteristics,fault handling, shared resource usage, and so on. The intent of this definition is that asoftware architecture must abstract away some information from the system (otherwisethere is no point looking at the architecture, we are simply viewing the entire system) andyet provide enough information to be a basis for analysis, decision making, and hencerisk reduction.Définition 3 (Software Architecture d’après Booch, Rumbaugh et Jacobson)An architecture is the set of significant decisions about the organization of a softwaresystem, the selection of the structural elements and their interfaces by which the systemis composed, together with their behavior as specified in the collaborations among thoseelements, the composition of these structural and behavioral elements into progressivelylarger subsystems, and the architectural style that guides this organization—these ele-ments and their interfaces, their collaborations, and their composition (The UML ModelingLanguage User Guide, Addison-Wesley, 1999).Dans le contexte du référentiel NPT, la définition suivante est retenue :Définition 4 (Architecture de système informatique)L’architecture d’un système informatique définit l’organisation structurelle des compo-sants du système, les propriétés de ces composants ainsi que la manière dont ils in-teragissent.La définition du référentiel NPT fait également ressortir le terme de système informatique,que l’on peut associer au terme de système d’information. Ces deux concepts sont définisde la manière suivante :Définition 5 (Système d’information)Un système d’information est un système composé de personnes, de machines et deméthodes. Il est organisé pour collecter, traiter, stocker et transmettre de l’information.Les processus définis dans le cadre d’un système d’information peuvent être manuels ouautomatisés (par un système informatique).Observatoire Technologique 9
  • Référentiel NPTDéfinition 6 (Système informatique)Un système informatique est la réalisation d’une partie d’un système d’information avecdes composants matériels et logiciels. Un système informatique permet d’automatiserune partie des processus définis dans le cadre d’un système d’information.2.2 Objectifs du référentiel NPTL’objectif principal du référentiel NPT est de fournir un cadre et une méthode pour la des-cription et l’évaluation de systèmes informatiques. L’outil n’a pas été conçu à l’intentiond’une division particulière du CTI. Au contraire, il est suffisamment générique pour êtreutile à l’ensemble des divisions du CTI ainsi qu’à d’autres entités internes ou partenairesde l’État de Genève.L’analyse de systèmes informatiques peut se faire dans différents contextes : cartogra-phie du système informatique, sélection d’une application métier, choix d’une plate-formematérielle, définition du poste de travail, etc. Un des objectifs du référentiel est de propo-ser une approche unifiée pour aborder l’ensemble de ce problèmes.Dans la mesure où le référentiel NPT était adopté par les différentes divisions du CTI, lamanière de documenter l’architecture de systèmes et de composants deviendrait com-mune. Il devrait en résulter une plus grande homogénéité et une facilité d’utilisation de ladocumentation.2.2.1 Applications envisagées pour le référentiel NPTPremière utilisation : Description et évaluation macroscopique d’un système infor-matiqueLa première utilisation du référentiel NPT consiste à décrire le système informatique del’État de Genève à un niveau macroscopique, c’est-à-dire dans son ensemble.Dans ce cas, l’objectif est de décrire les principaux composants du système, leurs quali-tés et leurs interactions. Les composants étudiés à ce niveau sont aussi bien les applica-tions métiers (les piliers du système d’information de l’État de Genève) que les compo-sants transversaux (portail, framework, SAN).Dans ce type d’utilisation, le référentiel permet de créer plusieurs vues du système infor-matique. Ces vues peuvent, par exemple, faire ressortir les éléments suivants : • La vision stratégique du système informatique, telle qu’elle est conçue et présenté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étierLa deuxième utilisation du référentiel NPT consiste à décrire en détails un des compo-sants du système informatique de l’État de Genève. Typiquement, lors du choix d’uneapplication métier, le référentiel permet de comparer et d’évaluer un ensemble d’alterna-tives sur plusieurs dimensions. 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 estla suivante : 1. Les éléments structurels de l’architecture de chaque solution sont analysés et dé- crits en utilisant la structure du référentiel. Pour cela, chaque solution est décom- posée en plusieurs couches (du matériel au logiciel) et en plusieurs tiers (de 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 faitObservatoire 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 standardLa troisième utilisation envisagée pour le référentiel est celle du choix d’une technologieou d’un standard. Alors que l’utilisation précédente découlait d’un besoin des utilisateurs(choix d’une application métier), cette utilisation découle généralement d’un besoin plustransversal.Dans ce cas, la première étape consiste à situer la technologie ou le standard étudié dansle cadre général du référentiel. Dans quelle(s) couche(s) la technologie se situe-t-elle ?Sur quel(s) tiers a-t-elle un impact ? A nouveau, les répondes à ces questions peuventêtre représentées graphiquement sous forme d’un tableau. Une fois la technologie situéepar rapport aux deux axes, il est plus facile d’identifier les personnes qui, au CTI, sont leplus à même de fournir des informations par rapport à la technologie.Parfois, une technologie a également le potentiel de permettre une réorganisation dusystème informatique global. Par exemple, des technologies d’intégration comme lesconnecteurs JCA peuvent augmenter l’interopérabilité entre certaines applications mé-tiers. De telles propriétés peuvent également être représentées graphiquement en tirantparti des deux premiers axes du référentiel.2.2.2 Instrumentation du référentiel avec un outil d’aide à la décisionLa manière d’utiliser et d’appliquer le référentiel n’est pas définie strictement. Les utili-sateurs ont la liberté d’adapter l’outil à leurs besoins. Il est probable que des habitudesseront prises graduellement et évolueront dans le temps, en fonction de l’adoption duréférentiel par différentes personnes.Une des possibilités proposées aux utilisateurs du référentiel NPT est d’instrumenter leréférentiel avec un outil d’aide à la décision. Une telle instrumentation est particulièrementintéressante lorsque le référentiel est utilisé pour choisir un composant parmi plusieursalternatives.Par exemple, l’Observatoire Technologique a évalué et acquis des licences pour le logicield’aide à la décision multi-critères Web-HIPRE. Ce logiciel permet la définition de critèresd’évaluation (qui pourraient correspondre aux dimensions du référentiel NPT) et la pon-dération de ces critères. Les modèles ainsi définis sont représentés graphiquement etpeuvent manipulés interactivement. Un exemple d’écran du logiciel est représenté dansla Figure 2.2.Observatoire Technologique 12
  • Référentiel NPT F IG . 2.2 – Capture d’écran du logiciel Web-HIPRE.Observatoire Technologique 13
  • Chapitre 3Structure du référentielDans le chapitre 2, les objectifs du référentiel NPT ont été présentés et illustrés partrois types d’utilisation envisagés. La discussion a brièvement mentionné le fait que leréférentiel était structuré selon trois axes : celui des couches, celui des tiers et celui desdimensions. Ce chapitre décrit la structure du référentiel et chacun des axes en détails.3.1 Les trois axes du référentielLe référentiel NPT est organisé sur trois axes et peut donc être représenté graphiquementsous la forme d’un cube. Le premier axe est utilisé pour décomposer le système encouches. Le deuxième axe est utilisé pour décomposer le système en tiers (dans le sensd’une architecture multi-tiers). Le troisième axe est utilisé pour évaluer le système entenant compte d’un ensemble de dimensions.Décrire et évaluer un système à l’aide du référentiel NPT se fait généralement en deuxétapes : 1. Au cours de la première étape, le système est décrit en fonction des couches et 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èmeLe premier axe du référentiel permet de décomposer un système en couches. Il s’agit làd’une décomposition classique dans l’analyse et la conception de système informatiques.Chaque couche introduit un niveau d’abstraction supplémentaire par rapport à la coucheinférieure. Les couches sont indépendantes les unes des autres et communiquent autravers d’interfaces.Dans certains cas, les interfaces sont spécifiées par des standards ouverts (par exemple,la plate-forme J2EE est un standard ouvert pour la couche “plate-forme supérieure”).Dans ce cas, il est possible de choisir n’importe quelle implémentation du standard. Plusimportant, il est possible de remplacer ultérieurement cette implémentation par une autre,sans impact sur les composants des autres couches.Dans d’autres cas, l’interface offerte par une couche est propriétaire. Dans ce cas, ilest possible que seul un fournisseur fournisse une implémentation de la couche. Cettesituation crée une relation de dépendance vis à vis du fournisseur. En effet, remplacerla couche revient à changer l’interface et oblige donc à modifier les composants de lacouche supérieure. Un exemple est une application développée directement au-dessusdu système d’exploitation, qui doit être réécrite si le système d’exploitation change.3.2.1 Couche matérielDans la couche du matériel, on trouve les composants physiques tels que les serveurs etles composants réseau.Observatoire Technologique 15
  • Référentiel NPTLorsque le référentiel est utilisé pour décrire le système informatique dans son ensemble,cette couche est utilisée pour décrire le type de matériel qui est utilisé. Cette analysepermet de mettre en évidence la variété plus ou moins grande des composants, aussibien du côté client que du côté serveur.Lorsque le référentiel est utilisé pour décrire une application métier particulière, et mêmesi cette application est exclusivement composée d’éléments logiciels, la couche du ma-tériel doit quand même être étudiée. En effet, plusieurs questions intéressantes peuventse poser à ce niveau, par exemple : • Quels types de ressources sont-elles requises par la solution ? (par exemple 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érieureLa couche de la plate-forme inférieure se situe au dessus de la couche du matériel etoffre un premier niveau d’abstraction.Les composants qui se situent dans cette couche sont principalement le système d’ex-ploitation et les composants logiciels de bas niveau (par exemple pile TCP/IP, pilotes depériphériques).Il est possible de concevoir des plate-formes inférieures équivalentes (c’est-à-dire of-frant la même interface aux couches supérieures) au dessus de couches matériellesdifférentes. Par exemple, le même système d’exploitation peut être disponible sur desarchitectures matérielles différentes.3.2.3 Couche plate-forme supérieureAu dessus de la plate-forme inférieure se trouve la plate-forme supérieure. L’objectif decette couche est d’augmenter la portabilité des composants en ajoutant un niveau d’abs-traction entre le système d’exploitation et les applications.Deux implémentations de la même plate-forme supérieure peuvent être mises en œuvreau dessus de systèmes d’exploitation différents. Dans la mesure où les composants ap-plicatifs ne communiquent pas directement avec la plate-forme inférieure, mais unique-ment au travers de la plate-forme supérieure, il est possible de remplacer le systèmed’exploitation sans impact majeur.Java est un bon exemple de plate-forme supérieure. Java spécifie en effet un environne-ment d’exécution (JVM et librairies) qui est indépendant du système d’exploitation. Lesapplications développées en Java sont portables de manière tout à fait transparente. LeObservatoire Technologique 16
  • Référentiel NPTconcept de plate-forme supérieure s’applique aux trois éditions de la plate-forme Java 2(J2EE, J2SE, J2ME).3.2.4 Couche applicationsLa couche des applications héberge les composants logiciels qui implémentent la logiquede présentation, de traitement et d’accès aux données pour les services déployés parl’organisation.C’est dans cette couche que la connaissance métier est encapsulée dans des compo-sants logiciels. C’est donc dans cette couche que se situe la plus grande valeur du sys-tème informatique.Pour cette raison, la pérennité des composants développés à ce niveau est cruciale. Unebonne manière d’augmenter cette pérennité est de rendre la couche application la plusindépendante possible des couches inférieures. Pour cela, la première règle à suivre estde communiquer uniquement avec la couche directement inférieure (plate-forme supé-rieure), et privilégier un standard ouvert pour cette couche (par exemple J2EE). Celagarantit une indépendance vis à vis de tout fournisseur et permet de continuer à utili-ser les composants applicatifs même lorsque le matériel, le système d’exploitation ou leserveur d’applications est remplacé.3.2.5 Couche système d’informationLa couche la plus abstraite du référentiel est appelée couche du système d’information.Dans cette couche, les services applicatifs fournis par la couche inférieure sont intégréset utilisés au travers d’un workflow.3.3 Deuxième axe : les tiers du systèmeLe deuxième axe du référentiel NPT est utilisé pour décomposer un système en plusieurstiers, ce qui est particulièrement utile pour des applications distribuées (et donc pourcelles développées avec le Framework CTI).Chaque tiers peut être hébergé par un nœud différent sur le réseau, mais cela n’estpas une obligation. Ainsi, s’il est possible de déployer une application multi-tiers sur cinqmachines différentes, il est également possible de déployer la même application sur uneseule machine. L’architecture de l’application reste la même.Le principe d’architecture multi-tiers est aujourd’hui largement accepté et a été rendupopulaire par des technologies telles que CORBA, J2EE et .NET. Néanmoins, il existeplusieurs variantes de cette architecture, par exemple : • l’architecture 3-tiers, qui répartit les composants d’une application distribuées 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) leObservatoire 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 nedevrait pas accéder directement à la base de données. Au contraire, il devrait obligatoire-ment passer par le tiers métier. Ce découplage présente plusieurs avantages et permeten particulier de remplacer les composants d’un tiers sans avoir un impact sur tout lesystème.3.3.1 Tiers clientLe tiers client héberge les composants avec lesquels les utilisateurs ont une interactiondirecte. Comme les autres tiers, le tiers client est orthogonal aux couches du système.On trouve donc des composants qui sont à la fois dans le tiers client et dans la couchedu matériel (par exemple un ordinateur de bureau ou un téléphone), d’autres qui sont àla fois dans le tiers client et dans la couche des applications (par exemple une page Webqui permet de consulter un annuaire).La conception des composants du tiers client peut se faire avec une des deux approchessuivantes : celle dite du “client lourd” (c’est-à-dire les composants sont intégrés sous laforme d’une application indépendante) et celle dit du “client léger” (c’est-à-dire les com-posants, en particulier les pages HTML, sont hébergés et présentés par un navigateurweb).Il faut relever que pour le même service applicatif (par exemple un service d’accès àun annuaire), plusieurs interfaces peuvent être développées. La création de plusieurscanaux d’accès est facilitée par le découpage en tiers.3.3.2 Tiers présentationLe tiers de présentation est particulièrement pertinent pour les applications Web. Lescomposants hébergés dans ce tiers génèrent l’interface utilisateur (typiquement dans unlangage de markup) qui est transmise et affichée par les composants du tiers client.Dans un contexte J2EE, un container Web ainsi que les servlets pages JSP qu’il hébergesont des composants du tiers de présentation. Suite à des requêtes HTTP, ces compo-sants génèrent un flux (HTML, XML, binaire, etc.) qui est transmis au navigateur Web dutiers client.Observatoire Technologique 18
  • Référentiel NPT3.3.3 Tiers métierLe tiers métier héberge les composants qui encapsulent la logique métier, ainsi que leséléments qui offrent un environnement d’exécution aux composants métier.Les composants développés dans ce tiers ont une très grande valeur, puisqu’ils implé-mentent la connaissance métier de l’organisation. A nouveau, pour garantir la pérennitéde ces composants, il est important de les rendre indépendants d’un mode de présen-tation et d’un mode de persistance particuliers. Le découplage entre les tiers permetd’atteindre cet objectif.Dans un contexte J2EE, un container EJB ainsi que les EJB qu’il héberge sont des com-posants du tiers métier.3.3.4 Tiers intégrationLe 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 ressourcesLe tiers ressources héberge les composants comme les bases de données, les an-nuaires, etc. Le rôle de ces composants est de gérer la persistance des données utiliséespar les services du tiers métier.Dans ce contexte, le découplage entre les tiers ressources et métier permet de remplacerune base de données par une autre, sans que les services applicatifs ne subissent unimpact.3.4 Troisième axe : les dimensions du systèmeLe troisième axe du référentiel est celui qui guide l’évaluation d’un système, préalable-ment décrit en fonction des deux premiers axes. Le troisième axe est constitué d’un en-semble de dimensions, qui déterminent les critères d’évaluation pour un système. Lesdimensions couvrent un spectre assez large et ne se limitent pas à des considérationtechniques.3.4.1 Organisation en ensembles, dimensions et sous-dimensionsPour faciliter l’utilisation du référentiel, les dimensions en été organisées sur trois niveauxhiérarchiques : • sur le premier niveau, quatre grands ensembles de dimensions sont proposés ; • sur le deuxième niveau, chaque ensemble est composé d’une liste de dimensions ;Observatoire Technologique 19
  • Référentiel NPT • sur le troisième niveau, chaque dimension est elle-même décomposée en sous- dimensions (si nécessaire).Le tableau suivant présente les ensembles, les dimensions et les sous-dimensions demanière synoptique : Ensembles Dimensions Sous-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 partieLe Référentiel NPT 21
  • Chapitre 4Dimensions relatives aux FacteursHumainsLes dimensions Aspects utilisateurs et Aspects sociétaux ont été regroupées sous le la-bel commun Dimensions relatives aux facteurs humains. Ces dimensions, ainsi que lessous-dimensions correspondantes prennent en compte les aspects touchant très direc-tement les utilisateurs et de manière plus générale l’e-Société. Certains de ces domainessont souvent négligés lors de l’étude d’une technologie ou d’un composant informatiquealors qu’ils y jouent un rôle important en terme d’adoption et d’utilisation notamment. 22
  • Référentiel NPT4.1 Aspects utilisateursRévisions Version Date / auteurs Objet de la révision 0.1 2003-10-03 / pge Version initialeDescriptionLa dimension Aspects utilisateurs permet d’analyser les propriétés d’une technologie oud’un composant informatique en terme de valeur ajoutée, de besoins fonctionnels, d’er-gonomie et d’accessibilité. Elle mesure la prise en compte de la composante humaine,du point de vue utilisateur notamment, dans la conception et/ou la mise en œuvre d’unsystème.Sous-dimensions • Valeur ajoutée : mesure la valeur ajoutée pour l’utilisateur, pour le service ou 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 NPT4.1.1 Valeur ajoutéeRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-29 / pge Version initialeDescriptionCette dimension vise à estimer la valeur ajoutée, pour l’utilisateur, le service ou l’institu-tion concernés, par la technologie ou le composant informatique étudiés. Il s’agit égale-ment de déterminer la contribution positive pouvant être apportée à la synergie entre lesdifférents acteurs impliqués.La notion de valeur ajoutée ne fait naturellement pas ici référence à un quelconque gainfinancier. Mais elle y est malgré tout fortement liée : outre les aspects techniques, il ya en effet toujours lieu de mettre en balance la valeur ajoutée de la solution avec soncoût ainsi qu’avec les risques qui y sont associés (voir dimension Economie). La valeurajoutée est difficile à mesurer et son estimation reste la plupart du temps qualitative.Dans le cadre d’une administration, la valeur ajoutée correspond avant tout à l’identifica-tion d’un véritable bénéfice pour l’utilisateur et passe avant tout par une formulation desbesoins en terme de finalité : on pense par exemple à la mise à disposition d’un servicesupplémentaire, à la réduction du temps d’exécution d’une tâche ou à l’obtention d’unrésultat de qualité supérieure à l’existant.Couches et tiers concernésUne déclinaison de la notion de valeur ajoutée en fonction des couches ou des tiersconcernés n’est pas faite ici.RisquesUn projet de mise en oeuvre d’une technologique ou d’un composant informatique qui nepeut pas faire preuve d’une réelle valeur ajoutée a peu de chances d’être accepté. Onrisque également de s’engager dans une logique de fuite en avant technologique danslaquelle la technologie est une fin en soi. A terme, le risque est de mettre en évidence uneproductivité faible pour des technologies ayant été en oeuvre sans réelle valeur ajoutée.Mesures • La solution envisagée répond-elle à un besoin avéré ou n’est-elle que le reflet d’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étierCompétence • Maîtrise d’ouvrage • Maîtrise d’oeuvre • Commission de Gestion du Portefeuille des Projets (CGPP)Observatoire Technologique 25
  • Référentiel NPT4.1.2 Respect des besoins fonctionnelsRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-30 / pge Version initialeDescriptionL’utilisateur final d’un système n’est satisfait que si celui-ci répond à des contraintes fonc-tionnelles et opérationnelles initialement fixées. Dans cette optique, il est impératif deprendre en compte les besoins et les attentes des usagers le plus en amont possibledans le processus de mise en oeuvre d’une technologie (dans le processus d’assurancequalité par exemple).Mais cette démarche indispensable doit cependant veiller à différencier ce qui est sol-licité par les utilisateurs de ce qui leur est réellement nécessaire. En effet les attentesdes usagers ne correspondent pas forcément à ce dont ils ont effectivement besoin, dela même façon que ce qui leur est initialement proposé dans un projet ne concorde pasnécessairement avec leurs attentes. Le but de la démarche est donc de mettre en adé-quation ces deux ensembles. Cela exige d’associer les utilisateurs aux différentes étapesde validation du projet, ceci afin de traduire le plus efficacement possible leurs attentesdans le produit final.L’Agence pour le Développement de l’Administration Electronqiue (ADAE - France) a pu-blié à ce sujet un guide méthodologique richement documenté et très instructif à l’inten-tion des maîtres d’ouvrage qui traite de tous les aspects du problème (voir Références).Les démarches suggérées sont schématisées dans le diagramme ci-dessous. AFB : analyse fonctionnelle du besoin (sert à exprimer les attentes 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 NPTCouches et tiers concernésUne déclinaison de la prise en compte des besoins fonctionnels en fonction des couchesou des tiers concernés n’est pas faite ici.RisquesUne solution ne répondant pas aux besoins fonctionnels exprimés par les utilisateursrisque de compromettre la viabilité du projet.Mesures • La solution étudiée répond-elle aux besoins fonctionnels sollicités par les utilisa- teurs ? • Les besoins fonctionnels sollicités ont-ils été pris en compte en amont du projet ? • Un équilibre entre les besoins fonctionnels sollicités par les utilisateurs et les be- soins réellement nécessaires a-t-elle été mesurée ?Aspects métierCompétence • Maîtrise d’ouvrage • Maîtrise d’oeuvreRéférencesGuide méthodologique pour les maîtres d’ouvrage de service en ligne, ADAE, 19 avril2002 : http://www.adae.pm.gouv.fr/spip/article.php3?id_article=80Observatoire Technologique 27
  • Référentiel NPT4.1.3 ErgonomieRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-30 / pge Version initialeDescriptionErgonomie : science du travail (du grec ergon (travail) et nomos (loi, règles))L’ergonomie est la capacité d’un système à être utilisé par un individu. Elle est la re-cherche d’une meilleure adaptation possible entre fonction, matériel et utilisateurs. Cedernier attend en effet un outil qui lui permette d’accomplir la tâche souhaitée (correspon-dant aux besoins fonctionnels) de la manière la plus efficace et la plus agréable possible,garante d’un haut niveau de productivité.Une bonne ergonomie est très importante pour l’utilisateur. Elle englobe à la fois lesnotions de performance dans la réalisation des tâches, de satisfaction que procure l’utili-sation du système et de facilité avec laquelle on apprend à s’en servir. L’ergonomie sertà poser la frontière entre l’utilité potentielle (idéale) et l’utilité réelle d’une solution : unefois les besoins fonctionnels identifiés, ils doivent être traduits dans l’essence même duprojet, mais également au travers de son interface utilisateur. L’ergonomie est un fac-teur important de productivité et de qualité de l’atmosphère de travail. Il est souhaitablede pouvoir la prendre en compte en amont de la conduite de projet et d’y associer lesutilisateurs dans la plus large mesure possible.L’ergonomie fait généralement référence aux concepts suivants : • Facilité d’apprentissage et d’utilisation. • Efficacité d’utilisation (simple, intuitif, uniforme, prévisible). • Facilité de mémorisation du fonctionnement du système. • Utilisation sans erreurs. • Satisfaction des utilisateurs.On peut analyser l’ergonomie d’un système selon une série de variables mesurables(taux d’erreurs, durée d’exécution d’une tâche, facilité de rétention dans le temps, de-mandes d’aide, durée d’apprentissage, etc.) et subjectives (esthétique, confort, préfé-rences, etc.).Le cas particulier de l’accessibilité est un domaine important lié à la notion d’ergonomie.Il est traité à part dans la sous-dimension correspondante.Couches concernées • Application. Dans cette couche, c’est de l’ergonomie de l’interface utilisateur dont 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.RisquesUn système dont l’ergonomie est faible peut drastiquement réduire la productivité desutilisateurs. Dans les cas extrêmes on risque un rejet de la solution par les utilisateurs.Mesures • L’ergonomie a-t-elle été prise en compte dans les spécifications du système ? • L’ergonomie de la solution étudiée est elle acceptable ? • Les utilisateurs ont-ils été associées à la mise en oeuvre du projet étudié ? • Des informations sur les caractéristiques et comportements des futurs utilisateurs ont-elles été recueillies ?Aspects métierCompétence • DTD • Maîtrise d’oeuvre • Maîtrise d’ouvrageDiversPour plus d’informations relatives à la notion d’ergonomie, qui est un domaine très vasteet qui peut être un métier en soit, on peut se référer avantageusement aux liens présentésdans la section Références ci-dessous.Observatoire Technologique 29
  • Référentiel NPTRéférencesApple. 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.htmErgoline. Liens et définitions relatifs à l’ergonomie. http://membres.lycos.fr/ergoline/IHMWeb.htmIHO. Associations, liens et définitions relatifs à l’ergonomie. http://charlie.dgrc.crc.ca/~sylvie/hf_f_links.htmlDavid Manise. Introduction à l’ergonomie du Web. http://davidmanise.com/ergonomie/index.phpUsability First. Introduciton à l’ergonomie (en anglais). http://www.usabilityfirst.com/index.txlObservatoire Technologique 30
  • Référentiel NPT4.1.4 AccessibilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-27 / pge Version initialeDescriptionLa vision de l’Etat de Genève dans le domaine des technologies de l’information et dela communication (TIC) met en avant les notions d’intégration et de cyber-inclusion. Celapasse notamment par la prise en compte de l’accessibilité aux solutions informatiquesmises en oeuvre. Plusieurs raisons (juridiques, économiques, sociales et morales no-tamment) militent en faveur d’un accès facilité aux TIC pour les personnes souffrantd’un handicap. Les besoins de ces personnes ne sont souvent pas considérés lors dela conception de systèmes informatiques. Les problèmes d’accessibilité pourraient ce-pendant être résolus dans une large mesure grâce à une prise en compte appropriée, enamont de la mise en oeuvre d’une technologie.On présente souvent la notion d’accessibilité comme une déclinaison particulière de lanotion d’ergonomie (voir sous-dimension correspondante) pour la catégorie particulièred’utilisateurs que sont les personnes handicapées. Il faut d’ailleurs étendre cette caté-gorie plus largement, par exemple aux personnes âgées ou à celles maîtrisant mal lalecture ou la langue en vigueur.Les quatre principales catégories de handicap sont les handicaps visuels, auditifs, demobilité et cognitifs, qui présentent des besoins différents en terme d’accessibilité : • Handicaps visuels. Les personnes aveugles ou malvoyantes doivent pouvoir ac- céder aux documents électroniques et aux applications avec les dispositifs d’as- sistance qu’elles utilisent habituellement. Les personnes daltoniennes doivent 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éderaux TIC. Ces barrières peuvent être éliminées ou minimisées au niveau du développe-ment des applications, du navigateur, des technologies d’assistance, ou des systèmesd’exploitation et des plateformes matérielles sous-jacents.Dans ce contexte, l’accessibilité mesure la facilité d’accès à la technologie étudiée pourles utilisateurs présentant un handicap quel qu’il soit.Observatoire Technologique 31
  • Référentiel NPTCouches 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.RisquesSi cette dimension n’est pas prise en compte, on risque de choisir ou de concevoir unsystème qui ne pourra pas être exploité valablement par tous les utilisateurs potentiels.Ceci est tout particulièrement vrai pour des systèmes au contact direct d’un large éventaild’utilisateurs ou de citoyens (système de messagerie, suite bureautique ou portail parexemple).Mesures • L’accessibilité a-t-elle été prise en compte dans les spécifications du système ? • Les pages Web répondent-ils aux critères du WAI en terme d’accessibilité ? • Les interfaces utilisateurs sont-ils accessibles aux personnes handicapées ? • Le matériel choisi inclut-il ou supporte-t-il des dispositifs d’assistance aux per- sonnes handicapées ? • Des personnes handicapées ont-elles été associées à la mise en oeuvre des projets tournés vers le citoyen ?Observatoire Technologique 32
  • Référentiel NPTAspects métierCompétence • DTD • Maîtrise d’ouvrage • Maîtrise d’oeuvreDiversUne bonne introduction à cette problématique est présentée sur le site de la Web Ac-cessibility Initiative (WAI), émanation du W3C pour une meilleure accessibilité aux sitesWeb. De nombreux fournisseurs informatiques et de communautés Open Source ontégalement intégré l’accessibilité aux technologies dans leurs réflexions. Les sites cor-respondants proposent des guides utiles sur la question (accessibilité applicative, Web,Java, matérielle, etc...). D’autre part il existe un certain nombre d’outils de validation quipermettent d’automatiser une partie du processus de tests d’un site Web en terme d’ac-cessibilité. La section Références propose plusieurs liens vers certains de ces projetsainsi que vers des institutions académiques et des associations oeuvrant dans ce do-maine. Mentionnons surtout les sites Trace Center de l’Université du Wisconsin et UIAccess qui couvrent très largement le sujet.RéférencesOrganismes de standardisationWeb Accessibility Initiative (WAI) : http://www.w3.org/WAI/Checklist WAI : http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.htmlRéférences WAI : http://www.w3.org/WAI/References/Directives W3C : http://www.w3.org/TR/WCAG/Sites académiques et associatifsTrace Center, Université du Wisconsin : http://www.tracecenter.org/Usability SIG : http://www.stcsig.org/usability/UI Access : http://www.uiaccess.com/index.htmlAccès pour tous : http://www.access-for-all.ch/new/f_index.htmlBrailleNet : http://www.braillenet.org/Voir Plus : http://www.voirplus.net/Web sourd : http://www.educ-pop.org/303Projets d’accessibilité du monde Open SourceObservatoire Technologique 33
  • Référentiel NPTKDE 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 informatiquesIBM : http://www-3.ibm.com/able/Apple : http://developer.apple.com/documentation/Accessibility/Accessibility.htmlMicrosoft : http://www.microsoft.com/enable/Sun Microsystems. http://www.sun.com/access/Java-Sun : http://java.sun.com/products/jfc/accessibility.htmlOutils 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.htmlObservatoire Technologique 34
  • Référentiel NPT4.2 Aspects sociétauxRévisions Version Date / auteurs Objet de la révision 0.1 2003-10-03 / pge Version initialeDescriptionLa dimension Aspects sociétaux vise à estimer la valeur ajoutée apportée à la sociétépar une technologie ou un composant informatique. Il s’agit également de déterminer lacontribution à la synergie entre l’Etat, la société civile et le secteur privé. Un dernier butest enfin d’estimer dans quelle mesure les cadres éthiques et légaux sont respectés.Sous-dimensions • Composante sociétale : estime la valeur ajoutée apportée à la société civile, 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.RisquesVoir sous-dimensions correspondantes.MesuresLa mesure de la dimension Société est une agrégation des mesures des sous-dimensionscorrespondantes.Observatoire Technologique 35
  • Référentiel NPT4.2.1 Composante sociétaleRévisions Version Date / auteurs Objet de la révision 0.1 2003-08-18 / pge version initialeDescriptionCette dimension vise à estimer la valeur ajoutée apportée à la société civile, aux citoyens,au secteur privé ou aux différentes communautés d’intérêt par la technologie ou le projetinformatique étudié. Il s’agit également de déterminer la contribution positive qui peutainsi être apportée à la synergie entre les différents acteurs ci-dessus.La notion de valeur ajoutée ne fait naturellement pas ici référence à un quelconque gainfinancier. Elle correspond à un véritable bénéfice citoyen induit directement ou indirec-tement par la mise en oeuvre de la technologie ou du composant informatique étudiés.Cette notion de valeur ajoutée est naturellement très qualitative mais il ne faut pas pourautant la perdre de vue.A titre d’exemple, on peut considérer que l’adoption à large échelle du logiciel libre ausein de l’administration peut apporter une valeur ajoutée appréciable à la société civile.Une orientation stratégique de ce type est en effet succeptible d’une part de promouvoirl’émergence d’une économie locale liée au développement de logiciels libres et d’autrepart de favoriser les notions de transparence et de droit à l’information pour les citoyens.Les contraintes liées aux agendas politiques peuvent également avoir une influence no-table sur la mise en oeuvre ou non d’une technologie ou d’un composant informatique.Ces aspects sont particulièrement importants dans le cadre d’une administration qui doitjustifier ses choix au niveau politique.On peut se réferrer notamment aux objectifs de l’Etat de Genève en matière de dévelop-pement durable (Agenda21 local, voir Références). L’article 1 de la loi 8365 sur l’actionpublique en vue d’un développement durable A 2 60 dit en effet (voir Références) : 1. L’ensemble des activités des pouvoirs publics s’inscrit dans la perspective d’un dé- veloppement de la société, à Genève et dans la région, qui soit compatible 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 defaciliter la mise en oeuvre d’une technologie ou d’un composant informatique.Observatoire Technologique 36
  • Référentiel NPTCouches et tiers concernésUne déclinaison de la notion de composante sociétale en fonction des couches ou destiers concernés n’a pas été faite ici.RisquesUne mauvaise perception du contexte socio-politique peut ralentir, voir paralyser la miseen oeuvre d’une technologie (qui peut a contrario être favorisée si elle s’insère parfaite-ment dans ce même contexte).Mesures 1. La technologie considérée apporte-t-elle une valeur ajoutée à la société ? 2. Contribue-t-elle à la réalisation des buts fixés dans le cadre d’un agenda politique tel que l’Agenda21 local par exemple ?Compétence • Observatoire TechnologiqueRéférencesAgenda 21 du Canton de Genève. http://www.etat-ge.ch/agenda21Article de loi correspondant. http://www.geneve.ch/legislation/rsg/f/rsg_a2_60.htmlObservatoire Technologique 37
  • Référentiel NPT4.2.2 Cadre légalRévisions Version Date / auteurs Objet de la révision 0.1 2003-10-06 / pge Version initialeDescriptionProtection des systèmes informatiquesLa législation genevoise (voir Références) a réglementé, en date du 5 avril 2000 (règle-ment B 1 15.01), la protection des systèmes informatiques dans l’administration canto-nale. Elle stipule que lors de la planification, de la réalisation et de l’exploitation d’applica-tions et de systèmes informatiques dans l’administration cantonale, il faut s’assurer queces applications et ces systèmes soient protégés contre les risques qui menacent leurdisponibilité, leur intégrité et leur confidentialité. Ce règlement est commun à toutes lesréalisations informatiques mises en oeuvre dans le canton de Genève.Protection de la personnalitéL’une des composantes importantes des technologies actuelles réside dans l’accès élec-tronique aux données. Ceci implique tout d’abord une plus grande transparence de l’ad-ministration et une meilleure accessibilité des informations publiques. Mais la rapidité detraitement de l’information numérique, la possibilité de croiser de l’information, de tracerdes requêtes et le fait que toute information soit potentiellement accessible à chacunamène également des préoccupations en matière de respect de la vie privée, de protec-tion des données personnelles ou de gestion des identités.En Suisse, la protection de la personnalité relève essentiellement de la législation fédé-rale (voir Références), en particulier des articles 28 et ss du Code Civil Suisse et, sousson aspect de collection d’information, de la loi fédérale su la protection des données(LPD, RS 235.1 - 19 juin 1992). Les cantons ne conservent une compétence que pour cequi échappe au champ de la LPD, soit les fichiers détenus par les entités exclues de ladéfinition de personne privée ou d’organe fédéral, à savoir les collectivités publiques etpara-publiques autres que la Confédération et les services de son administration, ainsique les institutions qui en dépendent.La quasi totalité des cantons a adopté une législation sur la protection des donnéesdétenues par leur administration. Actuellement la loi en force à Genève est la LITAO (loicantonale B 4 35 du 17 décembre 1981 sur les informations traitées automatiquement parordinateur), en vigueur depuis le 1er février 1983, ainsi que son règlement d’exécution(B 4 35.01). La refonte de cette loi est à l’étude.Selon le Préposé fédéral à la protection des données (voir Références), il est importantque les concepteurs de projets informatiques arrêtent leur politique de protection desdonnées aussitôt que possible.Toujours selon le Préposé fédéral à la protection des données, il devra être tenu compte,Observatoire Technologique 38
  • Référentiel NPTen 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.TransparenceLe 5 octobre 2001, la loi sur l’information du public et l’accès aux documents (LIPADA 2 08) a été votée. Elle est entrée en vigueur le 1er mars 2002. Elle garantit l’informationrelative aux activités des institutions publiques et para-étatiques, dans toute la mesurecompatible avec les droits découlant de la protection de la sphère privée, en particulierdes données personnelles, et les limites d’accès aux procédures judiciaires et adminis-tratives. Elle a principalement pour but de favoriser la libre formation de l’opinion et laparticipation à la vie publique. Aucun règlement d’exécution n’a encore été édicté pourcette loi.De manière générale, les technologies potentiellement sensibles dans les domaines évo-qués ci-dessus doivent être envisagées avec prudence au risque de rendre leur mise enoeuvre problématique. C’est donc d’abord sur l’usage et la maîtrise de l’outil que doit seporter la réflexion plutôt que sur la technologie elle-même. A un niveau plus technique, ilfaut veiller à ce qu’une technologie offre toujours des possibilités de configuration et deparamétrage propres à gérer et à maîtriser correctement ces aspects.Observatoire Technologique 39
  • Référentiel NPTPropriété intellectuelleUn dernier point concerne les contraintes légales relatives à la propriété intellectuelle etplus spécialement à celui des licences d’utilisation. Obtenir une expertise légale dans cedomaine peut constituer un défi non-négligeable car les licences d’utilisation imposentparfois des contraintes légales fortes qu’il faut pouvoir évaluer et prendre en comptecorrectement dans le choix d’une technologie.Ceci est également valable dans le cas du logiciel libre dont les différents types de li-cences imposent des contraintes parfois fortes qu’il ne faut pas sous-évaluer. Le logiciellibre, comme son nom ne l’indique pas, est en effet protégé par le code de la propriété in-tellectuelle. Le document Licences Open Source cité ci-dessous présente succinctementces aspects ainsi que des liens pertinents relatifs à cette problématique.Couches et tiers concernésUne déclinaison de cette dimension en fonction des couches ou des tiers concernés n’estpas faite ici.Risques • La mise en oeuvre d’une technologie ou d’un composant informatique ne s’inscri- vant pas dans le cadre légal existant risque d’en compromettre sa viabilité. • Une technologie ou un un composant informatique dont le cadre légal ré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étierDans le cas des données relatives à la santé d’un patient qui sont considérées commesensibles, les dispositions en vigueur aujourd’hui aux niveau fédéral et cantonal ne serecoupent que partiellement. Elles sont par ailleurs exemptes de directives pratiques àadopter pour garantir concrètement la sécurité des données numérisées et prévenir lesabus d’utilisation. L’introduction de dossiers santé virtuels ne manquera donc pas de sou-lever de nombreux problèmes juridiques.Observatoire Technologique 40
  • Référentiel NPTCompétence • Service juridique compétentRéférencesRecueil systématique du droit fédéral. http://www.admin.ch/ch/f/rs/rs.htmlPré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.pdfObservatoire Technologique 41
  • Référentiel NPT4.2.3 Cadre éthiqueRévisions Version Date / auteurs Objet de la révision 0.1 2003-08-12 / pge Version initialeDescriptionEthique : science de la morale (du grec êthikos, moral et êthos, moeurs)D’une manière générale, on entend par éthique l’ensemble des principes, des normes etdes valeurs d’ordre moral régissant une société ou un groupe social.Les avantages que peut apporter une nouvelle technologie ne doivent pas l’emportersur la liberté et le bien-être de la personne. Ainsi la possibilité de rassembler des infor-mations croisées sur le citoyen, la confidentialité des données confiées aux organismesétatiques ou la protection de la sphère privée sont des questions qui, lorsqu’elles sontmises en perspective avec la responsabilité de l’administration à l’égard de l’ensembledes citoyens, soulèvent des réflexions sociologiques et éthiques qui vont souvent au-delàdu cadre légal. Les mêmes remarques sont également valables lorsque l’on considèreles données se rapportant à des personnes morales.Les technologies actuelles se montrent toujours plus performantes dans le domaine dutraitement et de l’exploitation des données (statistiques, data mining, archivage, etc.)ou dans celui de la traçabilité des requêtes. Ces potentialités requièrent une vigilancesoutenue afin d’éviter des dérapages toujours possibles. Le site Web du Préposé fédéralà la protection des données (voir Références) illustre un certain nombre de ces points etconstitue une excellente référence dans ce domaine (voir également la sous-dimensionCadre légal).A un niveau global, les technologies potentiellement sensibles dans les domaines évo-qués ci-dessus doivent être envisagées avec prudence au risque de rendre leur mise enoeuvre problématique. C’est donc d’abord sur l’usage et la maîtrise de l’outil que doit seporter la réflexion plutôt que sur la technologie elle-même. Plus cette réflexion est menéeen amont du processus de mise en oeuvre de la technologie, plus il sera aisé de résoudreles problèmes potentiels.A un niveau plus technique, il faut veiller à ce qu’une technologie offre toujours des pos-sibilités de configuration et de paramétrage propres à prendre en compte et à maîtrisercorrectement les aspects liés au respect du cadre éthique.Un dernier point soulevé par l’Agenda 21 du canton de Genève concerne le contrôledes fournisseurs impliqués dans le choix d’une technologie ou d’un projet de dévelop-pement : l’Agenda 21 recommande à ce sujet de s’assurer des conditions de travail desfournisseurs et des sous-traitants, et de vérifier dans quelle mesure ceux-ci répondent àdes critères de durabilité (dans le sens d’un développement durable) ou d’éthique (voirRéférences).Observatoire Technologique 42
  • Référentiel NPTCouches 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.RisquesLe risque initial d’éluder les questions éthiques aux dépens de l’aspect technologiqueest souvent bien réel. Dans ce contexte les groupes d’utilisateurs, les différents comitésd’éthique, associations corporatives ou simples citoyens peuvent constituer un frein ma-jeur à la mise en œuvre d’une solution informatique lorsque les aspects éthiques n’ontpas été suffisamment pris en compte.MesuresDans les cas où des données sensibles (soit directement, soit par recoupement) sontconcernées : 1. La mise en oeuvre de la technologie ou du composant informatique considéré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étierLes informations médicales sont des données sensibles par excellence. Le domaine dela santé se retrouve ainsi naturellement aux avant-postes lorsque l’on évoque le respectdu cadre éthique. Le recours dans ce cas à la Commission de Contrôle de l’Informatiquede l’Etat est indispensable.Compétence • Commission de Contrôle de l’Informatique de l’Etat • Comité(s) d’éthique.RéférencesAgenda 21 du Canton de Genève. http://www.etat-ge.ch/agenda21Site du Préposé fédéral à la protection des données. http://www.edsb.ch/f/service/sitemap.htmObservatoire Technologique 44
  • Chapitre 5Dimensions relatives aux QualitésSystémiquesLes dimensions Evolutivité, Qualité de service, Exploitabilité et Interopérabilité ont étéregroupées sous le label commun Dimensions relatives aux qualités systémiques. Cesdimensions, ainsi que les sous-dimensions correspondantes prennent en compte les as-pects intrinsèques des technologies et des composants informatiques étudiés. Elles nedépendent ni de facteurs humains, ni de facteurs organisationnels. Les qualités systé-miques sont orientées "contraintes" et sont fortement liées à la complexité de la solutionétudiée. Les dimensions relatives à la sécurité, qui peuvent également être vues commedes qualités systémiques, sont développées dans une autre section. 45
  • Référentiel NPT5.1 ÉvolutivitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa 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.RisquesSi cette dimension est négligée, le risque est d’obtenir un système d’information qui nepuisse pas répondre aux attentes des utilisateurs. Cela peut se produire s’il n’est paspossible de prendre en compte l’ensemble des règles du domaine d’application (ou alorsà un coût élevé). Cela peut également se produire s’il n’est pas possible de satisfaire lesqualités de services en fonction de leur évolution.Observatoire Technologique 47
  • Référentiel NPTMesuresMesurer 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 NPT5.1.1 ScalabilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa scalabilité mesure la capacité d’un système à supporter une charge croissante (nombretotal d’utilisateurs, nombre d’utilisateurs concurrents, nombre de requêtes, etc.) par l’ajoutsuccessif de ressources (CPU, mémoire, etc.). Idéalement, le rapport entre la charge etle coût des ressources devrait être linéaire.Couches concernées • Système d’information. C’est au niveau de cette couche que le besoin de scalabi- lité est exprimé. En effet, c’est au niveau du système d’information que le 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
  • Référentiel NPTTiers concernés • Client. On trouve une problématique de scalabilité dans ce tiers dans le cas par- ticulier d’applications métiers dont les composants sont hébergés par le poste de travail client, et qui consomment une grande quantité de ressources. Un exemple particulier est une application de visualisation scientifique. Si une telle application est scalable, alors il devrait être possible de lui imposer une charge plus importante (complexité des calculs par exemple) en ajoutant des ressources (mémoire, CPUs). • Présentation. Dans le cas d’une application Web, les pages HTML sont générées dans le tier de présentation. Dans un monde J2EE, ce sont des composants comme des servlets et des JSPs qui assurent cette tâche. Un mécanisme commun pour assurer la scalabilité dans ce tiers est d’utiliser un load balancer placé en amont d’une batterie de serveurs relativement peu puissants. Chacun de ces serveurs héberge un container Web, dans lequel sont déployés les mêmes servlets et JSPs. Le load balancer répartit la charge entre les différents serveurs. Dans la plupart des cas, il est important d’implémenter un mécanisme d’affinité de session, pour que toutes les requêtes émises par le même utilisateur (pendant une session de travail) soit routées vers le même serveur. Cela évite aux serveurs de devoir partager un état commun. • Métier. C’est dans ce tiers qu’on trouve la logique métier des services qui implé- mentent les besoins fonctionnels du système d’information. Pour certains services utilisés par un grand nombre d’utilisateurs, la scalabilité est évidemment très im- portante. Dans un mode J2EE, ce sont des composants comme les EJBs qui im- plémentent la logique métier. Les serveurs d’application dans lesquels les EJBs sont hébergés offrent un environnement d’exécution scalable, puisqu’ils offrent des mécanismes de duplication et de répartition de charge. • Intégration. Dans ce tiers on trouve entre autres les technologies de middleware orientées messages (MOM). Ces technologies facilitent la conception de systèmes scalables puisqu’elles permettent de découpler les différents composants d’un sys- tème. Il devient ainsi plus facile de rajouter des noeuds fonctionnellement équiva- lents pour faire face à une augmentation de la charge. • Ressources. Dans ce tiers, il faut par exemple faire en sorte que les bases de don- nées ou les annuaires puissent faire face à des charges importantes. Il est fréquent de privilégier une scalabilité verticale, c’est à dire d’utiliser des serveurs très puis- sants, au sein desquels on rajoute des ressources au cours du temps.RisquesSi cette dimension n’est pas prise en compte, le risque est de ne pas pouvoir faire faceà une augmentation de la charge. Ce risque est particulièrement important dans le casde services publiés sur le Web, puisque le nombre d’utilisateurs peut croître dans degrandes proportions et très rapidement. Lorsqu’un système devient populaire, la chargequ’il subit augmente rapidement. Si la scalabilité du système est médiocre, les perfor-mances se dégradent très vite. La perception du système est alors négative et beaucoupd’utilisateurs risquent de ne plus l’utiliser.Observatoire Technologique 50
  • Référentiel NPTMesuresPour mesurer la scalabilité d’un système, on peut se poser les questions suivantes : • Dans quelle mesure le système peut-il évoluer pour répondre à une augmentation de la charge (i.e. augmentation du nombre d’utilisateurs et/ou de l’activité des utili- sateurs) ? • Lors d’une augmentation de la charge, l’architecture du système doit-elle être mo- difiée ? • Lors d’une augmentation de la charge, est-il suffisant de rajouter des ressources (serveurs, mémoire, CPUs) ? • Lors d’une augmentation de la charge, quel est le temps nécessaire pour redimen- sioner et reconfigurer le système ? • La consommation des ressources est-elle proportionnelle à la charge (évolution linéaire, non exponentielle) ?Observatoire Technologique 51
  • Référentiel NPT5.1.2 FlexibilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa flexibilité d’un système mesure la facilité avec laquelle il peut s’adpater à de nouveauxbesoins, à de nouvelles contraintes. Il peut s’agir aussi bien de besoins fonctionnels (ty-piquement l’ajout ou la modification de fonctions utilisateurs), que de besoins non fonc-tionnels (p.ex. le renforcement de la sécurité ou le support pour un nouveau type declient).Couches concernées • Système d’information. C’est dans cette couche que la modification des besoins est exprimée. L’informatisation de nouveaux processus métier, par exemple, génère un ensemble de besoins fonctionnels qui doivent être intégrés au système informatisé existant. Dans la mesure où ce système présente un haut degré de flexibilité, cela ne pose pas de problèmes majeurs. • Application. La conception des composants qui se situent dans cette couche a un impact déterminant sur la flexibilité du système, surtout d’un point de vue fonction- nel. L’ajout ou la modification de fonctionnalités implique avant tout un travail à ce niveau. • Plateforme supérieure. Les choix opérés dans cette couche participent à la défini- tion de l’architecture du système. Le choix d’un middleware qui permet un dévelop- pement orienté "objet", "services" et "composants" favorise la modularisation et la réutilisation, ce qui a un impact positif sur la flexibilité du système. • Plateforme inférieure. Cette couche a un impact sur la flexibilité par rapport à de nouveaux besoins non fonctionnels. Par exemple, la facilité avec laquelle des mé- canismes de haute disponibilité peuvent être introduits est différente d’un système d’exploitation à l’autre. • Matériel. De la même manière, le matériel choisi a un impact sur la facilité avec laquelle de nouveaux besoins non fonctionnels peuvent être incorporés.Tiers concernés • Client. Dans ce tiers, la facilité avec laquelle l’interface utilisateur peut s’adapter au changement des règles métier (dans le tiers métier) donne une mesure de la flexibilité. La capacité à satisfaire des besoins particuliers, en terme d’ergonomie ou d’accessibilité par exemple en donne une autre.Observatoire Technologique 52
  • Référentiel NPT • Présentation. Dans ce tiers, une mesure typique de la flexibilité est la facilité avec laquelle le système peut supporter un nouveau type de client (p.ex. un terminal mobile). • Métier. La dimension flexibilité est essentielle lors de la conception relative à ce tiers. C’est en effet ici que sont implémentées les règles métiers, qui sont suscep- tibles d’évoluer fréquemment dans le temps. Etre capable d’incorporer de nouvelles règles métiers dans le système est extrêmement important. • Ressources. Dans ce tiers, la flexibilité mesure par exemple la facilité avec laquelle un fournisseur de ressources peut faire face à une augementation de la charge.RisquesSi cette dimension est négligée, le risque est de rendre la modification du système, parrapport à de nouveaux besoins, très longue et coûteuse. Pour l’organisation, le risque quien découle est de ne pas pouvoir faire face à l’évolution des besoins, ce qui peut s’avérerdommageable.MesuresPour mesurer la flexibilité d’un système, on peut se poser les questions suivantes : • Le système permet-il la modification et/ou la redéfinition des règles de gestion ? • Une modification des règles de gestion demande-t-elle une modification du code, ou uniquement de la paramétrisation du système ? • Quel est le temps nécessaire à la modification d’une règle de gestion ? • Le système offre-t-il des interfaces qui permettent d’accéder à ses fonctionalités ? Quelle est la nature de ces interfaces ?Observatoire Technologique 53
  • Référentiel NPT5.1.3 PortabilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa portabilité mesure la capacité d’un composant à pouvoir fonctionner dans différentsenvironnements d’exécution. Elle reflète l’indépendance entre les différentes couches dusystème.Couches concernées • Application. Idéalement, les applications et les services développés dans cette couche devraient être portables sur différentes instances de la plateforme supé- rieure. C’est le cas dans le monde J2EE, puisque le même servlet, ou le même EJB, peuvent être déployés dans des containers différents (qu’il s’agisse de pro- duits commerciaux, comme le serveur d’application de Borland, ou de produits open source comme JBoss). • Plateforme supérieure. Un composant de cette couche est portable lorsqu’il peut être exécuté au-dessus de différents systèmes d’exploitation. C’est le cas lorsque le composant (p.ex. un serveur d’application ou un serveur Web) est lui-même écrit en Java. • Plateforme inférieure. La portabilité des composants appartenant à cette couche (en particulier le système d’exploitation) reflète leur capacité à fonctionner sur des architectures matérielles différentes (x86, SPARC, PowerPC).Tiers concernés • Client. Dans ce tiers, la portabilité d’un composant offre la possibilité de le faire fonctionner sur différents postes utilisateurs. Par exemple, un client lourd développé en Swing est portable dans différents environnements. • Présentation. Dans ce tiers, la portabilité signifie que les composants qui génèrent l’interface utilisateur peuvent être déployés dans différents environnements. Par exemple, le même servlet peut être déployé dans différents containers Web, eux- mêmes installés sur différents systèmes d’exploitation et/ou architectures maté- rielles. • Métier. Dans ce tiers, la portabilité signifie que les composants qui implémentent la logique métier peuvent être déployés dans différents environnements. Par exemple, le même EJB peut être déployé dans différents containers EJB, eux-mêmes instal- lés sur différents systèmes d’exploitation et/ou architectures matérielles.Observatoire Technologique 54
  • Référentiel NPT • Ressources. Dans ce tiers, la portabilité signifie que les composants qui gèrent les ressources (p.ex. bases de données) peuvent être installés dans différents envi- ronnements. Dans certains cas cela veut dire que le même composant peut être exécuté dans différents environnements (p.ex. un annuaire écrit en Java). Dans d’autres cas, cela signifie que le même produit existe en plusieurs versions, exécu- tables dans différents environnements (p.ex. l’annuaire d’un constructeur X, qui est disponible pour Solaris, pour Linux et pour Windows). Dans d’autres cas enfin, cela veut dire qu’il est possible de trouver un produit qui implémente la même norme dans d’autres environnements et qu’il sera donc possible de gérer les mêmes res- sources dans ces environnements (p.ex. un annuaire qui implémente la norme LDAP).RisquesSi cette dimension n’est pas prise en compte, le risque principal est de créer une dé-pendance par rapport à un produit et un fournisseur particulier. Si une application estdéveloppée au-dessus d’une plateforme propriétaire, et qu’elle n’est pas portable, il n’estplus possible de remplacer la plateforme en question sans avoir à ré-écrire l’application.Mesures • L’application peut-elle fonctionner sur des systèmes d’exploitations et/ou des archi- tectures matérielles différentes ? • Le service peut-il être déployé dans différents serveurs d’applications, ou utilise-t-il des fonctions propriétaires d’un serveur particulier ? • Quel est le degré de portabilité, i.e. quel est l’effort nécessaire pour porter le com- posant vers un autre environnement ? • le composant fonctionne tel quel (p.ex. parce que du bytecode et des machines virtuelles sont utilisées) • le composant doit être recompilé (parce que les environnements n’offrent pas de compatibilité binaire) • le composant doit être partiellement ré-écrit (parce que les environnements n’utilisent pas les mêmes librairies de développement)Aspects métierCompétence • La DTD, qui définit les best practices au niveau de la conception de services appli- catifs. • Le CAT pour l’évolutivité de l’architecture du système global.Observatoire Technologique 55
  • Référentiel NPTDiversExemples : • Le framework CTI : le framework CTI permet le développement de services por- tables puisqu’il est fondé sur les technologies J2EE. Les services sont portables sur des serveurs d’applications différents, sur des systèmes d’exploitation différents et sur des architectures matérielles différentes (car on trouve des containers J2EE pour différents OS/matériels).Contre-exemples : • Application MS Access : Une application développée avec MS Access fonctionne uniquement sur Windows et n’est pas portable.Standards : • Java (portabilité du bytecode sur différents OS et différentes architectures maté- rielles) • J2EE (portabilité des composants métiers sur différents containers)Observatoire Technologique 56
  • Référentiel NPT5.1.4 Maturité de la solutionRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa maturité d’un système mesure le degré avec lequel le système a été utilisé, éprouvé etgraduellement amélioré. Après une phase de développement initiale, un système est misen production, à disposition des utilisateurs. Le cycle de vie du système inclut ensuitedes activités de maintenance corrective et évolutive. Au fil des itérations, la qualité dusystème et sa maturité devraient évoluer de manière positive.Dans le cas de développements qui ne sont pas spécifiques à une organisation (logicielscommerciaux et logiciels libres), l’utilisation par un grand nombre de clients, le retourd’expérience et l’amélioration intrinsèque du produit font progresser le degré de maturité.Dans le cas particulier de frameworks de développement, leur utilisation dans le cadrede différents projets et leur amélioration (refactoring) par rapport au retour d’expérienceaugmentent leur maturité. Une idée largement répandue est qu’un "système orienté ob-jet" doit être ré-utilisé au moins trois fois (dans des contextes différents) avant d’êtresuffisamment mûr pour devenir un framework à proprement parler.Couches et tiers concernésUne déclinaison de la dimension en fonction des couches ou des tiers concernés n’estpas faite ici.RisquesLorsque cette dimension est sous-estimée, que ce soit lors du choix d’une solution métier,d’un outil de développement ou encore d’un produit middleware, le risque est de rencon-trer des problèmes ou des limitations qui n’ont pas encore été identifiés par le fournisseurde la solution. En évaluant la couverture fonctionnelle et l’architecture technique d’unesolution, il est donc important d’évaluer la maturité de celle-ci.Mesures • De combien de temps date la première version de la solution ? • Quelle est la version courante de la solution ? • La solution est-elle utilisée par de nombreuses organisations ? Quelles sont les références disponibles ?Observatoire Technologique 57
  • Référentiel NPT • Quelle est la position de la solution dans le marché, par rapport à des solutions équivalentes ? • Existe-t-il une grande communauté d’utilisateurs pour la solution ? Beaucoup d’in- formation est-elle échangée au sein de cette communauté ?Observatoire Technologique 58
  • Référentiel NPT5.2 ExploitabilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionL’exploitabilité d’un système mesure la facilité avec laquelle il peut être géré, contrôlé etmaintenu opérationnel dans un environnement de production. L’exploitabilité d’un sys-tème mesure également la facilité avec laquelle des opérations de maintenance (cor-rective et/ou évolutive) peuvent être réalisées sur le système, avec des interruptions deservice minimes.Sous-dimensions • Maintenabilité : mesure la facilité avec laquelle un système peut être modifié dans le but de corriger des défauts, d’ajouter des fonctions, d’améliorer des performances, de s’adapter à des modifications de l’environnement. • Contrôlabilité : mesure le degré avec lequel le fonctionnement d’un système peut être contrôlé (de manière continue et automatique), avec lequel des incidents peuvent être détectés et notifiés et avec lequel des statistiques d’usage peuvent être obte- nues.Couches concernées • Système d’information. A ce niveau, l’exploitabilité mesure la facilité avec laquelle le système informatisé peut être maintenu dans un état qui permet de répondre aux besoins des utilisateurs. Ces besoins évoluant, l’exploitabilité du système dépend donc de la facilité avec laquelle des nouvelles fonctions peuvent être incorporées. • Application. A ce niveau, on notera qu’il est souhaitable non seulement d’avoir un bon niveau d’exploitabilité pour les différentes applications et services, mais égale- ment d’avoir une cohérence globable. En d’autres termes, le choix et l’application transversale de mécanismes appropriés (monitoring, logging, gestion du change- ment) est vivement recommandée. • Plateforme supérieure. L’exploitabilité des composants de cette couche est très imporante. Conceptuellement, les serveurs d’applications sont censés libérer les développeurs "métier" de considérations techniques (distribution, persistence, sé- curité, etc.). Ils offrent ainsi un environnement d’exécution, qui doit avoir un haut niveau d’exploitabilité pour être utile. • Plateforme inférieure. Au niveau du système d’exploitation, l’exploitabilité est as- sociée à des outils de surveillance, à des mécanismes de gestion des évolutions (patch), etc.Observatoire Technologique 59
  • Référentiel NPT • Matériel. A ce niveau, l’exploitabilité mesure la manière, plus ou moins facile, avec laquelle le personnel peut assurer la maintenance des composants matériels. Des serveurs qui intègrent un système de surveillance et de notification des incidents, des serveurs qui permettent le remplacement de pièces défectueuses "à chaud" ont un degré d’exploitabilité élevé.Tiers concernés • Client. L’exploitabilité des composants déployés dans la couche client est délicate. Intégrer des outils de surveillance et de notification des incidents, gérer l’évolution des versions et leur distribution sont des questions à considérer. • Présentation. L’exploitabilité des composants du tiers présentation dépend d’une collaboration entre les équipes de développement (pour les composants applicatifs) et les équipes d’exploitation (pour les composants middleware). • Métier. Même remarque que pour le tiers précédent. • Intégration. Dans le tiers d’intégration, l’exploitabilité est le plus souvent associée à des composants techniques (bus de messages asynchrones, connecteurs, etc.) et impacte surtout les équipes d’exploitation. • Ressources. Dans le tiers des ressources, l’exploitabilité est importante, puisqu’elle a un impact sur l’ensemble des services et applications du système. En effet, de nombreuses architectures sont conçues de façon à ce qu’un ensemble de services distribués accèdent au même fournisseur de ressources (SGBD, annuaire). En cas de panne au niveau des ressources, c’est donc l’ensemble des services qui devient indisponible.RisquesSi l’exploitabilité d’un système est négligée lors de son choix ou de sa conception, lepremier risque est de voir les coûts exploser durant sa mise en production. Le deuxièmerisque est de ne pas pouvoir garantir un degré de disponibilité suffisant pour le serviceen raison du temps nécessaire à la détection des incidents et du temps nécessaire à leurréparation. Ces risques ont un impact direct sur les utilisateurs du système.MesuresPour mesurer l’exploitabilité d’un système, il faut l’étudier du point de vue des personnesqui ont la responsabilité de le maintenir en état de fonctionner, en respectant les niveauxde disponibilité et de performance spécifiés. A titre d’exemple, les questions suivantespeuvent être citées : • Des procédures de gestion des incidents et de gestion du changement sont-elles définies par rapport au système ? • Le personnel qui gère le système en production dispose-t-il d’outils de surveillance du système ?Observatoire Technologique 60
  • Référentiel NPT5.2.1 MaintenabilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa maintenabilité mesure la facilité avec laquelle un système peut être modifié dans lebut de corriger des défauts, d’ajouter des fonctions, d’améliorer des performances, des’adapter à des modifications dans l’environnement. Dans certains environnements, lesopérations de maintenance doivent pouvoir être réalisées sans interruption de service.Cette problématique a un impact au niveau de la conception du système, mais égalementau niveau des procédures de gestion définies par rapport au système. La maintenabilitéd’un composant est liée à la qualité de la documentation fournie. En effet, pour pouvoirfaire évoluer un composant, mais également pour pouvoir le faire évoluer, il est indispen-sable de connaître sont ses fonctions, son architecture interne, ses interfaces. Dans lecas d’un système, la documentation de l’architecture globale joue également un rôle pré-dominant dans la maintenabilité du système. Par exemple, le fait que les dépendancesentre les composants soient répertoriées est un facteur déterminant.Couches concernées • Système d’information. La maintenabilité du système d’information peut être vue comme la "facilité" avec laquelle des acteurs, des composants et des processus peuvent être ajoutés, modifiés ou supprimés. La "facilité" est mesurée en terme d’impact sur le reste du système. Si la modification d’une partie du système n’a qu’un impact limité, le système continue à fonctionner dans son ensemble. Le coût lié à l’opération de maintenance est donc réduit. Au contraire, si l’ensemble du système est paralysé par chaque modification, le coût de la maintenance est élevé. • Application. La maintenabilité de cette couche est très importante pour l’organisa- tion, puisque c’est à ce niveau que les règles métier sont définies. Dans le cas de développements spécifiques, c’est l’organisation elle même qui assume les opé- rations de maintenance corrective et évolutive. La maintenabilité d’un système dé- pend de la qualité de son architecture, de son code et de sa documentation. Elle est également liée à la définition et à l’application de processus de gestion du change- ment. Une approche systématique par rapport aux tests des composants est éga- lement déterminante (la disponibilité d’un ensemble de tests automatisés réduit par exemple sensiblement le coût des opérations de maintenance). • Plateforme supérieure. A ce niveau, la plupart des organisations n’assument pas la maintenance du code des composants. Au contraire, ce sont les fournisseurs des composants qui assument cette responsabilité. Néanmoins, lorsque de nouvelles versions sont livrées par les fournisseurs, l’organisation doit gérer la problématique de déploiement et de migration, qui n’est pas triviale. Ici également une approche systématique de la gestion du changement et des tests est indispensable.Observatoire Technologique 61
  • Référentiel NPT • Plateforme inférieure. La même remarque s’applique à cette couche. • Matériel. Au niveau du matériel, certains constructeurs proposent des serveurs dont les composants défecteux peuvent être remplacés "à chaud", c’est à dire sans être mis hors tension. ces serveurs offrent donc un haut degré de maintenabilité.Tiers concernés • Client. La maintenabilité des composants du tiers client est associée à la probléma- tique du déploiement. En effet, à la suite d’opérations de maintenance corrective et/ou évolutive, il est nécessaire d’installer la nouvelle version des composants sur le poste de travail des utilisateurs. Des technologies peuvent rendre ce processus plus facile (par exemple Java WebStart). • Présentation. La maintenabilité des composants du tiers de présentation soulève la question de l’interruption de service. Si des composants de ce tiers doivent être remplacés, le service qu’ils assument peut devenir indisponible durant la période de migration. Si cela n’est pas acceptable (besoin de haute disponibilité forte), il est alors nécessaire de bénéficier d’une architecture redondante et d’implémenter des processus de migration échelonnés. De tels processus peuvent être relativement complexes à mettre en oeuvre. • Métier. Au niveau métier, la même problématique se pose mais avec un impact plus important. En effet, les services métiers peuvent être utilisés par plusieurs services de présentation. Rendre un service métier indisponible a donc pour conséquence de rendre indisponibles plusieurs applications ou autres services. D’autre part, l’in- terface offerte par les services métiers est souvent plus riche que celle offerte par les services de présentation. Dans le cas où l’interface est modifiée au cours d’une opération de maintenance, la gestion des dépendances et la gestion des versions est critique. • Intégration. Dans le tiers d’intégration, la maintenabilité des composants est im- portante, puisqu’elle a un impact sur de nombreux services et applications. Un composant défecteux ou indisponible dans ce tiers impacte donc un grand nombre d’utilisateurs. D’autre part, le tiers d’intégration est par définition un tiers dont les composants ont des interactions avec beaucoup d’autres systèmes et composants. Garantir que la nouvelle version d’un composant fonctionne avec tous les compo- sants en place est donc important. • Ressources. Dans les architectures multi-tiers, où les données sont souvent gé- rées sur des serveurs dédiés, la maintenabilité des composants du tiers ressources est cruciale. A nouveau, un gestionnaire de ressources qui devient indisponible où défecteux aura un impact lourd sur un grand nombre d’utilisateurs.RisquesUn système qui a un faible degré de maintenabilité présente un risque important pourl’organisation. Si cette dimension est négligée, le coût induit par les modifications dusystème (que celles-ci soient dues à des défauts ou à une évolution des besoins) peutObservatoire Technologique 62
  • Référentiel NPTdevenir très élevé. Certains coûts sont directs (activités nécessaires pour identifier lesmodifications requises et pour les réaliser). D’autres sont indirects (indisponibilité du sys-tème pendant certaines activités de maintenance). Un système qui a un faible degré demaintenabilité a souvent un faible degré de stabilité, et donc d’utilisabilité. Il y a donc unimpact visible par les utilisateurs finaux.MesuresLa qualité de la documentation, la description de processus pour gestion des évolutions,les interfaces de surveillances sont des éléments qui indiquent un certain degré de main-tenabilité pour un composant. Au niveau de l’architecture d’un système, un couplagefaible entre les composants est également un signe positif.Les questions suivantes permettent d’évaluer quelques aspects de la maintenabilité d’unsystème : • Des opérations de maintenance peuvent-elles être réalisées sans que le service fourni par le système devienne indisponible ? • Des procédures sont-elles clairement définies pour traiter les incidents survenant dans le contexte du système (détection, notification, lignes de support, etc.)Observatoire Technologique 63
  • Référentiel NPT5.2.2 ContrôlabilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa contrôlabilité mesure le degré avec lequel le fonctionnement d’un système peut êtrecontrôlé (de manière continue et automatique), avec lequel des incidents peuvent êtredétectés et notifiés ou avec lequel des statistiques d’usage peuvent être obtenues.Couches concernées • Système d’information. Au niveau du système d’information, la contrôlabilité im- plique qu’un ensemble de règles et de processus sont appliqués par certains ac- teurs du système. Ces processus peuvent être ou ne pas être informatisés. Par exemple, un audit réalisé dans une optique d’assurance de qualité et sous la forme d’entretiens personnels peut être vu comme un mécanisme de contrôlabilité. • Application. En étudiant la contrôlabilité de la couche applicative, on peut considérer deux types d’événements. Premièrement, les événements et incidents techniques, qui sont liés à la qualité du code et à l’environnement d’exécution. Deuxièmement, les événements et incidents métier, qui sont liés à la logique applicative. Un admi- nistrateur qui doit assurer la production d’un système sera plutôt intéressé par les événements techniques, alors qu’un analyste métier ou un contrôleur seront plus concernés par les événements métier. • Plateforme supérieure. La plateforme supérieure constitue l’environnement opéra- tionnel dans lequel les composants applicatifs sont déployés. Les événements qui surviennent dans cette couche sont donc d’ordre technique. A titre d’exemples, on peut citer les événements et les incidents suivants : "soumission d’une requête", "début d’une session", "expiration d’une session", "échec lors de la connection à la base de données", etc. • Plateforme inférieure. La plateforme inférieure est également une source d’événe- ments qui est utile pour le contrôle d’un système. Le système d’exploitation peut par exemple remonter des alertes lorsque le taux d’utilisation du CPU ou la quantité de mémoire disponible atteignent des niveaux critiques. • Matériel. Des incidents au niveau du matériel peuvent également être détectés et notifiés (au travers du système d’exploitation). Le degré de contôlabilité est un fac- teur de différenciation pour certains constructeurs.Tiers concernésEn ce qui concerne la contrôlabilité, il n’y a pas de différence fondamentale entre lesdifférents tiers du système. Dans tous les cas, les mêmes mécanismes peuvent êtreObservatoire Technologique 64
  • Référentiel NPTappliqués pour définir, notifier et traiter des événements (aussi bien techniques que fonc-tionnels). La mise en oeuvre de ces mécanismes dépend cependant des technologiesutilisées pour développer les composants (et de l’ouverture de ces composants).Par contre, la consolidation des informations est une problématique particulière à cettesous-dimension. En effet, certains des événements qui se produisent dans les différentstiers du système doivent pouvoir être monitorés et traités de manière centralisée. Le per-sonnel assurant le fonctionnement d’une application doit pouvoir être alerté d’incidentssurvenants sur l’ensemble des tiers, et idéalement au travers de la même interface denotification. Les systèmes qui offrent un haut niveau de contrôlabilité intègrent des mé-canismes pour gérer les problèmes liés à la distribution des composants.RisquesUn système qui a un faible degré de contrôlabilité demandera une attention particulière,soutenue et constante de la part du personnel assurant son fonctionnement. S’il n’estpas possible de recevoir des alertes lors d’incidents, alors un opérateur devra s’assurer"manuellement" et régulièrement que le système fonctionne correctement.MesuresLes éléments suivants donnent une idée de la contrôlabilité d’un système : • Les interfaces utilisateurs dédiées au monitoring (consoles, graphes, etc.) • Le nombre et le contenu des fichiers de log • La disponibilité d’agents pour des solutions de monitoring du marché (p.ex. BMC Patrol) • L’étendue des interfaces (APIs) qui permettent de souscrire à des types d’événe- ments et par la suite de recevoir des notifications.Observatoire Technologique 65
  • Référentiel NPT5.3 Qualités de serviceRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa dimension des qualités de service permet d’analyser les propriétés d’un système endehors de son cadre purement fonctionnel. Ces propriétés déterminent la manière dontles utilisateurs (utilisateurs finaux, mais également administrateurs) perçoivent la qualitédu système (ou plus exactement du service rendu par le système).Sous-dimensions • Stabilité : mesure la fréquence, de la sévérité et de la prédictabilité des pannes auxquelles il est sujet. • Disponibilité : mesure la proportion de temps avec laquelle il est capable d’accep- ter et de traiter des requêtes soumises par les utilisateurs. • Performance : mesure la vitesse avec laquelle les tâches qui lui sont soumises sont traitées. • Efficacité : mesure le rapport entre les performances d’un système et la quantité de ressources lui étant allouée. A fonctions équivalentes et à ressources égales, un système plus efficace aura de meilleures performances.RisquesSi cette dimension n’est pas prise en compte, le risque est de choisir ou de concevoir unsystème qui répond aux besoins fonctionnels des utilisateurs, mais qui ne permet pas deleur offrir un service utilisable en pratique (par exemple parce que les temps de réponsesont trop longs ou parce que le service est trop souvent inaccessible).Observatoire Technologique 66
  • Référentiel NPT5.3.1 StabilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa stabilité d’un composant est fonction de la fréquence, de la sévérité et de la prédicta-bilité des pannes auxquelles il est sujet.Couches concernées • Système d’information. Si les systèmes informatiques et les outils qui sont utilisés pour la réalisation du système d’information ne sont pas stables, l’exécution des processus est affectée. C’est donc dans cette couche qu’on peut mesurer l’impact de la stabilité des composants du système. • Application. Dans cette couche, la stabilité de l’application dépend de la qualité du code produit par les développeurs métiers (mais elle dépend également de la stabi- lité des couches inférieures). Un grand avantage de l’organisation d’un système en couches est de séparer les aspects métiers des aspects techniques. Souvent, les problèmes de stabilité sont liés à des problèmes techniques, parfois complexes. • Plateforme supérieure. Dans cette couche, c’est la stabilité des environnements d’exécution de haut niveau (p.ex. les containers J2EE) qui est en cause. La stabilité des composants qui vivent dans cette couche est cruciale, puisqu’elle a un impact sur l’ensemble des applications hébergées. • Plateforme inférieure. Dans cette couche, c’est la stabilité du système d’exploitation et des librairies de bas niveau qui est mesurée. A nouveau, la stabilité est très importante puisqu’elle impacte la stabilité de toutes les couches supérieures. • Matériel. Dans cette couche, c’est la stabilité du matériel qui est mesurée.Tiers concernés • Client. Si les composants du tiers client ne sont pas stables, l’interaction utilisateur en sera grandement affectée. Par contre, si différents types de clients sont utilisés pour accéder aux mêmes services, il est possible que les problèmes soient canton- nés à un seul type de client (par exemple, il possible qu’un client lourd particulier soit instable, alors que le client léger équivalent soit stable). D’autre part, il est pos- sible que le même client lourd soit stable sur certaines plateformes et instable sur d’autres. • Présentation. La stabilité dans le tiers de présentation a un impact supérieur, puis- qu’il affecte tous les composants clients qui lui adressent des requêtes. Ainsi, si leObservatoire Technologique 67
  • Référentiel NPT serveur physique sur lequel un serveur Web est installé est sujet à de nombreuses pannes, l’ensemble de tous les clients sera bloqué régulièrement. • Métier. La stabilité dans le tiers métier est également très importante puisque ce dernier affecte tous les composants clients. Etant donné que certains composants clients adressent parfois des requêtes directement au tiers métier (p.ex. un client lourd qui contacte un EJB directement), l’impact se fait sentir sur un nombre de composants encore plus grand. • Ressources. La stabilité des composants du tiers ressources est absolument cru- ciale puisque lorsque ceux-ci sont indispensables au fonctionnement de l’ensemble des applications.RisquesSi cette dimension n’est pas prise en compte, le risque est de choisir des composants quicausent un nombre élevé de pannes, avec des conséquences parfois lourdes ainsi qu’unefrustration des utilisateurs et des administrateurs. L’instabilité des composants se ressentau niveau du système d’information et a un impact sur la productivité des utilisateurs.Mesures • Quelle est la fréquence des pannes ? Les pannes sont-elles prédictibles ? • Quel est l’impact des pannes (et quelles sont les personnes et processus affectés) ?Aspects métierCompétence • La DTD, qui choisit et/ou développe les produits et composants standards • Le développement, qui construit des applications sur cette base • La production, qui choisit et configure les produits d’infrastructure (ce qui a un im- pact sur leur stabilité)DiversExemples : • Le choix d’un container J2EE. Lors du choix d’un container J2EE, il est important de mesurer sa stabilité. En effet, cette stabilité a un impact direct sur la stabilité des applications déployées dans le container.Contre-exemples :Observatoire Technologique 68
  • Référentiel NPT • Une application métier. Une application métier qui demande à l’utilisateur de rem- plir des formulaires et qui faillit inopinément et de façon régulière, avec pour consé- quence la perte de toutes les informations saisies.Observatoire Technologique 69
  • Référentiel NPT5.3.2 DisponibilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa disponibilité d’un composant mesure la proportion de temps durant laquelle il est ca-pable d’accepter et de traiter des requêtes. La disponibilité est souvent exprimée parun pourcentage. Il convient de faire la différence entre les périodes d’indisponibilité pla-nifiées (certains systèmes sont arrêtés volontairement toutes les nuits) et les périodesd’indisponibilité non planifiées (conséquences de pannes et d’incidents).Couches concernées • Système d’information. Si les systèmes informatiques et les outils qui sont utilisés pour la réalisation du système d’information ne sont pas disponibles, l’exécution des processus est affectée. C’est donc dans cette couche qu’on peut mesurer l’impact de la disponibilité des composants du système. • Application. Dans cette couche, une question intéressante est de spécifier et mesu- rer la disponibilité d’un service particulier. Tous les services ne présentent pas les mêmes contraintes. Certains services sont utilisés uniquement pendant les heures de bureau et par une population réduite. D’autres services sont utilisés en 24/7 et par une population très importante. • Plateforme supérieure. Les composants de la plateforme supérieure ont un impact sur la disponibilité des applications à plusieurs points de vue. D’une part, si ils sont indisponibles (à la suite d’une panne), les applications le deviennent égale- ment. D’autres part, ils offrent des mécanismes (p.ex. clustering) qui permettent d’augmenter la disponibilité du système. Les contraintes de disponibilité (au niveau applicatif) ont un impact sur le choix du container (les containers offrent des méca- nismes plus ou moins sophistiqués de haute disponibilité). • Plateforme inférieure. Dans cette couche, la disponibilité est fonction de la stabi- lité du système d’exploitation. Des pannes imputables au système d’exploitation peuvent rendre le système indisponible. D’autre part, certains systèmes d’exploita- tion offrent des mécanismes de haute disponibilité (p.ex. clustering). • Matériel. La fréquence des pannes imputables au matériel a un impact sur la dis- ponibilité du système.Tiers concernés • Client. Les composants du tiers client ne sont pas vraiment concernés par les as- pects de disponibilité, puisque ce sont les composants qui contactent des services et leur soumettent des requêtes.Observatoire Technologique 70
  • Référentiel NPT • Présentation. La disponibilité d’un composant du tiers de présentation a un impact sur tous les clients qui lui soumettent des requêtes. Pour augmenter cette dispo- nibilité, on utilise souvent un mécanisme de réplication, i.e. on déploie le même composant (p.ex. un servlet) dans plusieurs containers organisés en batterie (der- rière un répartisseur de charge). Dans le cas où une panne survient sur un des containers, les requêtes sont automatiquement routées vers un autre container. • Métier. La disponibilité d’un composant du tiers métier a un impact sur tous les com- posants qui lui soumettent des requêtes (qu’ils soient situés dans le tiers client ou dans le tiers présentation). Pour augmenter la disponibilité, on a souvent recours à un mécanisme de clustering au niveau de la plateforme supérieure. Il faut no- ter que l’augmentation de la disponibilité se fait généralement au détriment de la performance. • Ressources. La disponibilité des ressources conditionne la disponibilité de tous les composants du système et est donc très importante. Pour augmenter cette dis- ponibilité, on utilise souvent un mécanisme de clustering au niveau du système d’exploitation.RisquesSi cette dimension n’est pas prise en compte, le risque est de construire un systèmequi soit parfois inaccessible alors qu’il devrait l’être. Les conséquences se ressentent auniveau des utilisateurs qui sont dans l’incapacité de réaliser leurs tâches.Mesures • Quelle est la durée d’indisponibilité acceptable sur un/une journée/semaine/mois/année ? • Quelle sont la fréquence et la durée des interruptions de services volontaires ? • Quelle sont la fréquence et la durée estimées des interruptions de services involon- taires ?Aspects métierCompétence • La DTD, qui propose des mécanisme de haute disponibilité dans les couches Ap- plication et Plateforme supérieure. • La maîtrise d’ouvrage, qui spécifie les besoins en termes de disponibilité. • La production, qui choisit les mécanismes de haute disponibilité dans les couches Plateforme inférieure et Matériel.Observatoire Technologique 71
  • Référentiel NPTDiversExemples : • Cluster. Au CTI, certaines bases de données sont mises en cluster.Contre-exemples : • Une base de données Access utilisée pour générer un site Web dynamique. Cer- taines pages du site geneve.ch sont générées sur la base de scripts ASP et d’une base données Access, qui est régulièrement indisponible.Observatoire Technologique 72
  • Référentiel NPT5.3.3 PerformanceRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa performance d’un système mesure la vitesse avec laquelle les tâches qui lui sont sou-mises sont traitées. Dans certaines situations, la mesure la plus importante est le débit(nombre de tâches effectuées pendant une unité de temps). Dans d’autres situations,c’est le temps de réponse individuel qui est plus important. Il faut également prendre encompte la notion de performance perçue. En effet, même si le temps de réponse est lemême, deux interfaces peuvent donner une impression différente aux utilisateurs (p.ex.lorsque des barres de progression sont utilisées).Couches concernées • Système d’information. La performance des composants du système a un impact sensible au niveau du système d’information. Les processus définis dans cette couche impliquent en effet l’utilisation de services par les utilisateurs. Si les per- formances de ces services sont insuffisantes, la producitivité des utilisateurs en est affectée. • Application. Dans cette couche, c’est la performance d’un service particulier qui doit être spécifiée et mesurée. Dans le cas de services batch, c’est généralement le débit qui est optimisé. Dans le cas de services interactifs, c’est le temps de réponse qui est optimisé. La conception de l’interface utilisateur doit également être prise en compte, puisqu’elle a un impact sur la performance telle qu’elle est perçue par les utilisateurs. • Plateforme supérieure. Dans cette couche, les composants ont un impact sur la performance des services construits au niveau supérieur. Dans le cas de J2EE, par exemple, les performances d’un container Web particulier on un impact sur les per- formances des servlets qu’il héberge. D’autre part, les mécanismes de répartition de charge offerts à ce niveau permettent de conserver un niveau de performance malgré une augmentation de la charge (scalabilité). • Plateforme inférieure. Dans cette couche, la performance du système d’exploitation et des librairies de bas niveau ont un impact sur les composants des couches supé- rieures. Par exemple, différentes implémentations de la pile TCP/IP peuvent avoir des performances très différentes. • Matériel. Le choix du matériel a évidemment un impact considérable sur les perfor- mances du système. Augmenter les ressources (CPU, mémoire, cartes d’E/S, etc.) d’un serveur permet souvent d’améliorer les performances d’un service. De plus, les coûts des ressources matérielles diminuant, il s’agit là d’une approche souvent avantageuse.Observatoire Technologique 73
  • Référentiel NPTTiers concernés • Client. Le tiers client est particulièrement concerné par la performance perçue, puis- qu’il héberge l’interface utilisateur. Dans le cas d’interfaces complexes (p.ex. logiciel de visualisation scientifique), la performance est une dimension à considérer à part entière dans ce tiers. • Présentation. Dans ce tiers, c’est la performance des services de présentation qui est étudiée. Dans le monde J2EE, c’est typiquement les performances des serv- lets/JSPs et des containers les hébergeant qui est intéressante. De ce fait, ce sont aussi bien les développeurs de servlets, que les fournisseurs du container qui af- fectent les performances. D’autre part, le nombre et les caractéristiques des ser- veurs se répartissant la charge ont un impact sur les performances du système. • Métier. Dans ce tiers, c’est la performance des services encapsulant la logique métier qui est analysée. Dans le monde J2EE, ce sont donc les performances des EJBs et des containers les hébergeant qui sont concernées. Dans ce tiers, la conception du système distribué (p.ex. la stratégie de distribution, le choix d’in- terfaces locales ou distantes) ont un impact considérable sur les performances du système. • Ressources. Dans ce tiers, ce sont les performances des bases de données, des annuaires et d’autres systèmes qui sont concernées. Ces performances dépendent aussi bien de la qualité de l’implémentation des éléments logiciels, que des res- sources matérielles affectées aux serveurs les hébergeant.RisquesSi cette dimension n’est pas prise en compte, le risque est de réaliser un ensemble deservices qui ne permettent pas d’absorber la charge de travail souhaitée. Dans le cas oùle débit n’est pas assuré, le risque est de ne pas pouvoir fournir les résultats dans le délaisouhaité. Dans le cas où les temps de réponse sont trop longs, le risque est d’affecter letravail des utilisateurs, de réduire leur productivité et d’augmenter leur frustration.Mesures • Combien de tâches peuvent être traitées par le système en une seconde/minute/heure/journée ? • Quels sont les temps de réponse moyen et maximaux souhaités et/ou mesurés ? • Quelle est la perception des utilisateurs par rapport aux performances du système ?Aspects métierCompétence • La DTD, qui propose un ensemble de bonnes pratiques pour obtenir de bonnes performances au niveau applicatifObservatoire Technologique 74
  • Référentiel NPT • La maîtrise d’ouvrage, qui spécifie les besoins en termes de performance • La production, qui choisit les éléments des couches Matériel et Plateforme infé- rieure et prend en charge la configuration de ces composants.DiversExemples : • Affichage de l’état d’avancement : Lorsqu’une opération prend un certain temps (i.e. le temps de réponse est relativement long), il est important de donner une indication de la progression à l’utilisateur. Le mécanisme le plus commun est d’utiliser une barre de progression.Observatoire Technologique 75
  • Référentiel NPT5.3.4 EfficacitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionL’efficacité d’un système mesure le rapport entre les performances d’un système et laquantité de ressources qui lui est allouée. A fonctions équivalentes et à ressourceségales, un système plus efficace aura de meilleures performances.Couches concernées • Système d’information. Dans cette couche, l’efficacité peut se mesurer en termes humains. Un système efficace permettra d’obtenir les mêmes résultats avec moins d’effort. Par exemple, l’automatisation de processus permet d’améliorer l’efficacité du système d’information. • Application. Dans cette couche, on peut être intéressé par les gains en efficacité qu’une certaine application permet d’obtenir (au sens décrit dans la couche sys- tème d’information). D’un autre point de vue, on peut être intéressé par la manière plus ou moins efficace selon laquelle une certaine application a été réalisée (i.e. en analysant le nombre de ressources qu’elle consomme par rapport à ses caractéris- tiques). • Plateforme supérieure. Dans cette couche, c’est l’efficacité de composants tels que les serveurs d’application qui est étudiée. Dans le cas de la plateforme J2EE, les containers proposés par différents constructeurs demandent des quantités de res- sources différentes. • Plateforme inférieure. • Matériel. La mesure de la performance dans cette couche demande une certaine attention. Certaines mesures, comme la fréquence des CPUs, ne reflètent que par- tiellement la puissance d’un serveur.Tiers concernés • Client. Dans le tiers client, l’efficacité d’un composant affecte le choix du poste de travail des utilisateurs. En effet, si un composant a un degré d’efficacité faible, il sera nécessaire de compenser cette faiblesse par des ressources matérielles (CPU, mémoire, etc.). Ceci aura donc un coût directement mesurable. Dans le cas où la configuration matérielle n’est pas modifiée, c’est la performance du composant qui est affectée. Si cette performance se dégrade trop, c’est ensuite l’utilisabilité du composant qui est atteinte.Observatoire Technologique 76
  • Référentiel NPT • Présentation. Dans le tiers de présentation, l’efficacité des composants a un impact sur les ressources matérielles du côté "serveur". En effet, beaucoup de systèmes multi-tiers incluent une "ferme" de serveurs placés en parallèle et se partageant la charge des requêtes utilisateurs. Bien qu’il soit possible rajouter des serveurs dans la "ferme" pour faire face à une augmentation de la charge (scalabilité), un faible degré d’efficacité se traduira par un coût élevé en termes de ressource matérielles. • Métier. La même remarque est valable pour le tiers métiers : des composants qui n’ont pas été optimisés et ne sont pas très efficace devront être compensés par des ressources matérielles. • Ressources. La même remarque est valable pour le tiers ressources. On notera (c’est le cas pour les autres tiers également) que l’efficacité d’un composant ne dé- pend pas uniquement de sa conception (e.g. algorithmes, structures de données) mais également son paramétrage. La configuration d’un système de gestion de base de données, par exemple, peut être relativement complexe. En faisant varier certains paramètres, il est possible de mettre en oeuvre un environnement plus ou moins efficace. L’importance du "tuning" et de l’optimisation est donc très impor- tante.RisquesDans le cas où un composant a un faible degré d’efficacité, le risque est de devoir com-penser cette faiblesse par des ressources matérielles, ce qui engendre un coût sup-plémentaire. Un autre risque, dans le cas où des ressources matérielles ne sont pasajoutées, est d’avoir un faible niveau de performance.MesuresLa mesure de l’efficacité peut se faire en termes très concrets, typiquement durant lesphases d’optimisation (que ce soit pendant le développement ou pendant le déploie-ment). Des mesures de temps de réponse, de débit, de nombre de clients supportéssont souvent faites et mises en relation avec des quantités de ressources (nombre deserveurs, architecture des serveurs, quantité de mémoire, etc.).CompétenceDifférents groupes et personnes ont une influence sur le système informatique et sescomposants. D’une part, les équipes de développement ont évidemment un impact déter-minant sur l’efficacité intrinsèque des composants. Le choix d’algorithmes et de structurede données appropriés et la mise en pratique de bonnes techniques de programmation(programmation distribuée, entrées/sorties, routines graphiques) jouent un rôle important.D’autre part, les équipes qui gèrent l’environnement d’exploitation ont un impact sur l’effi-cacité du système "en exécution". Ils peuvent faire varier le niveau d’efficacité du systèmeen configurant les composants (e.g. varier la taille d’une mémoire tampon interne), maiségalement en configurant leur environnement (e.g. varier des paramètres du systèmed’exploitation).Observatoire Technologique 77
  • Référentiel NPT5.4 InteropérabilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionL’interopérabilité peut être abordée selon deux points de vue : • Premier point de vue (évaluation d’une solution métier à intégrer dans le système d’information) : cette dimension mesure la capacité d’un sous-système à interagir avec d’autres sous-systèmes qui ont été conçus indépendamment les uns des autres. • Deuxième point de vue (évaluation d’une technologie d’intégration) : cette dimen- sion mesure le degré avec lequel, par exemple, la mise en oeuvre d’un bus de messages facilite l’interopérabilité entre les différents sous-systèmes du système d’information.Sous-dimensions • Ouverture : mesure l’étendue des interfaces publiques (et idéalement conformes à des standards ouverts) qui donnent accès à ses fonctions. • Standardisation : mesure le degré avec lequel il intègre des standards dans sa conception, dans ses interfaces et dans sa documentation.Couches concernées • Système d’information. C’est dans cette couche qu’on peut mesurer le degré d’in- teropérabilité global du système d’information. Si les informations sont efficacement partagées entre les différents sous-systèmes, si les flux d’information sont harmo- nieux, cela montre que les sous-systèmes sont interopérables. • Application. C’est dans cette couche qu’on peut analyser le degré d’interopérabi- lité d’un sous-système particulier. Une analyse de l’architecture du sous-système permet de mettre en évidence les interfaces (qu’ils s’agisse de services en ligne, d’APIs, de conventions d’échange d’information). • Plateforme supérieure. Cette couche a un impact important sur la dimension. En effet, le choix de technologies appropriées dans cette couche est une façon d’aug- menter l’interopérabilité des systèmes. Cette couche offre par exemple des méca- nismes pour rendre la logique métier accessible sous la forme de services en ligne. • Plateforme inférieure. Aujourd’hui, cette couche n’a plus un impact déterminant sur l’interopérabilité des systèmes. L’hétérogénéité des systèmes d’exploitation n’est plus un obstacle à l’interopérabilité des applications.Observatoire Technologique 78
  • Référentiel NPT • Matériel. Aujourd’hui, cette couche n’a plus un impact déterminant sur l’interopéra- bilité des systèmes, à partir du moment ou des standards ont été adoptés dans les couches supérieures, pour l’ensemble des plateformes matérielles.Tiers concernés • Client. L’interopérabilité dans le tiers client prend plusieurs aspects. Premièrement, on peut considérer l’interopérabilité entre la couche client d’un applicatif et la couche client d’un autre applicatif. Ceci permet des interactions, des échanges de données entre plusieurs sous-systèmes au niveau de l’interface utilisateur. Deuxièmement, on peut considérer l’interopérabilité entre les différentes couches d’un seul et même applicatif. Le fait qu’une application soit accessible au travers de différents canaux (i.e. au travers de différentes couches client/présentation) démontre un certain de- gré d’interopérabilité. • Présentation. • Métier. Dans le tiers métier, l’interopérabilité permet de réaliser des workflows de manière transversale à plusieurs applicatifs. C’est dans ce tiers qu’on va pouvoir mesurer le degré d’interopérabilité d’un applicatif. • Intégration. Le tiers intégration est fortement lié à la dimension d’interopérabilité. En effet, son rôle est de découpler la couche métier de la couche ressources, pour permettre de modifier l’une sans affecter l’autre. • Ressources. Lors du choix d’un composant dans le tiers ressources (par exemple une base de données, un annuaire), il est important de vérifier que ce composant offre des interfaces standards, qui permettront une intégration dans l’architecture multi-tiers, au travers de la couche intégration.RisquesSi cette dimension est négligée, le risque est de construire un système d’informationqui n’ait pas une grande cohérence, avec des sous-systèmes isolés (silos) au traversdesquels il n’est pas possible de définir des workflows transversaux.MesuresL’interopérabilité d’un sous-système peut se mesurer en fonction des interfaces qu’il offre.En analysant ces interfaces, il convient de considérer plusieurs aspects comme : • La couverture fonctionnelle des interfaces. Est-ce que les interfaces permettent une interaction avec l’ensemble de la logique métier, ou uniquement avec un sous- ensemble de celle-ci ? • Le type d’échange supporté. Dans le même ordre d’idées, examiner le fait que les interfaces permettent uniquement de récupérer de l’information dans le sous- système (lecture) ou également de modifier de l’information (lecture et écriture)Observatoire Technologique 79
  • Référentiel NPT • L’utilisation de standards. Examiner le fait que les interfaces soient construites sur la base de méchanismes standards reconnus et adoptés (qu’il s’agisse d’APIs, de protocoles, de formats de fichiers)Aspects métierCompétence • Division technique de développement (CTI) • Comité d’architecture technique (CTI)DiversExemples : • Le framework CTI : le framework CTI permettra une interopérabilité entre les ser- vices et les applications développées sur celui-ci. • Les connecteurs implémentant la norme J2EE Connector ArchitectureStandards • Les architectures multi-tiers • La standardisation et la publication des APIs • Les technologies middleware : serveurs d’application, bus d’échange de messagesObservatoire Technologique 80
  • Référentiel NPT5.4.1 OuvertureRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionL’ouverture d’un système mesure l’étendue des interfaces (APIs) publiques qui donnentaccès à ses fonctions. Idéalement, ces interfaces publiques implémentent des standards,spécifiés, publiés et adoptés par l’industrie. L’ouverture d’un système est un facteur d’in-teropérabilité très important, puisqu’elle permet à d’autres systèmes (et pas seulementaux utilisateurs) d’accéder aux fonctions du système.Couches concernées • Application. L’ouverture de cette couche est la plus importante, puisque c’est elle qui détermine dans quel degré les fonctions métier du système peuvent être utilisées par d’autres systèmes informatisés. • Plateforme supérieure. L’ouverture de la plateforme supérieure est un élément à considérer dans le cadre de l’administration et de la surveillance du système infor- matique. A ce niveau, l’ouverture d’un composant ne permet pas d’accéder à des fonctions métier, mais à des fonctions techniques. Par exemple, un serveur d’ap- plications peut offrir une interface qui permet à des clients de s’enregistrer et de recevoir des événements du système informatique (requêtes, erreurs, etc.). • Plateforme inférieure. Le mécanisme décrit dans la couche précédente s’applique également à cette couche. • Matériel. Au niveau du matériel, la notion d’ouverture veut dire que l’architecture et les interfaces des composants sont publiées. Ceci permet par exemple à des fournisseurs tiers de développer des composants qui s’intègrent à un composant "maître". Par exemple, un ordinateur personnel qui a une interface USB est "ouvert", dans le sens où des fournisseurs tiers peuvent développer des périphériques qui s’intègrent à l’ordinateur.Tiers concernés • Client. Le tiers client permet souvent de mesurer le degré d’ouverture d’un sys- tème. Lorsque le système est ouvert, il est possible de développer un nouveau client (par exemple sur un client mobile) sans avoir accès au code des composants serveurs. Une organisation qui déploie un système ouvert bénéficie d’une grande souplesse, puisqu’elle peut à tout moment décider de développer un nouveau canal d’accès aux services fournis par le système. Une autre perspective sur le tiers client consiste à considérer les clients lourds. Certaines applications de ce type offrent un mécanisme de plugs-in, qui permet aux développeurs d’étendre les fonctions deObservatoire Technologique 81
  • Référentiel NPT l’application en implémentant des modules conformes à une API spécifiée. Le fait que cette API soit publique est un signe d’ouverture. • Présentation. Dans certains systèmes, le tiers de présentation représente le “point d’ouverture”, dans le sens où il offre le point d’accès aux fonctions du système. C’est par exemple le cas avec les technologies des web services. • Métier. C’est dans ce tiers que le degré d’ouverture est véritablement défini. En effet, l’interface qui permet d’accéder aux fonctions du système (API) et son degré de visibilité (les services sont-ils privés ou publics ?) est définie ici. • Intégration. L’existence d’un tiers d’intégration indique en général un certain degré d’ouverture pour le tiers des ressources. En effet, pour qu’il soit possible d’accéder à des fournisseurs de ressources depuis le tiers métier, il faut que ces fournisseurs de ressources offrent des interfaces publiques. • Ressources. Dans le cas d’architecture multi-tiers modernes, les composants du tiers ressources sont généralement ouvertes. C’est typiquement le cas pour les systèmes de gestion de base de données, qui peuvent être accédées au moyen de protocoles publics et standardisés. Néanmoins, certaines applications (on peut ci- ter le cas d’applications “lourdes” déployées sur un poste de travail) stoquent leurs données d’une manière qui n’est pas documentée. Dans ce cas, il peut ne pas être possible d’accéder aux données depuis d’autres composants (services et applica- tions).RisquesL’ouverture est aujourd’hui reconnue commé étant une qualité très importante des sys-tèmes informatiques. Une organisation qui opte pour un système fermé risque de rencon-trer des problèmes lors de l’intégration de ce système dans son infrastructure existante.Même lorsque cette intégration est réalisable, l’organisation risque de subir un manquede souplesse et des difficultés d’adaptation lors de l’évolution du système d’informationglobal.MesuresL’étendue des interfaces de programmation (APIs) et la documentation de ces interfacesest une bonne mesure de l’ouverture d’un système. Le fait que le système ait adopté desstandards ouverts lors de la conception de ces interfaces en est une autre.Observatoire Technologique 82
  • Référentiel NPT5.4.2 StandardisationRévisions Version Date / auteurs Objet de la révision 0.1 2003-09-11 / oli Version initialeDescriptionLa standardisation d’un système mesure le degré avec lequel il intègre des standardsdans sa conception (standards architecturaux, standards techniques, standards métiers),dans ses interfaces (standards au niveau de l’interface utilisateur, standards de fichiers,standards d’intégration, standards de contrôle et d’administration), dans sa documenta-tion.Les standards auquels un système se conforme peuvent être aussi bien des standardsinternes à l’organisation, que des standards propriétaires ou des standards ouverts.Couches concernées • Système d’information. Au niveau du système d’information, la notion de standar- disation est associée à la notion d’urbanisation. A ce niveau, l’enjeu est en effet de rendre le système d’information cohérent en appliquant un ensemble de règles et de mécanismes au travers de tout le système. Dans ce cas, les standards sont définis par les concepteurs du système (i.e. par l’organisation). • Application. Dans cette couche, plusieurs types de standards peuvent être consi- dérés. Le premier type de standards est lié au développement des composants. Il existe des standards de méthodologie (p.ex. Unified Process), de modélisation (p.ex. Unified Modeling Language), de conception (p.ex. les design patterns) ou en- core de codage. Le deuxième type de standards est lié à des problèmes techniques particuliers (gestion de l’interface utilisateur, accès à une base de données, notifi- cation asynchrone). Dans ce cas, c’est souvent la couche Plateforme supérieure qui met à disposition une implémentation des standards. Cette implémentation est utilisée par les composants de la couche Application. • Plateforme supérieure. C’est dans cette couche que beaucoup de standards tech- niques sont choisis et implémentés. A ce niveau l’organisation peut faire le choix entre une plateforme de développement ouverte (p.ex. Java 2 Enterprise Edition) ou propriétaire (p.ex. Microsoft .Net). Le respect des standards dans cette couche est très important, puisqu’il permet à l’organisation de garder son indépendance par rapport à un fournisseur particulier. En effet, en développant son système au- dessus d’une plateforme basée sur des standards ouverts, l’organisation peut à tout moment remplacer le ou les produits implémentant ces standards (e.g. remplacer le serveur d’applications du fournisseur X par un serveur d’applications du fournisseur Y). • Plateforme inférieure. • Matériel.Observatoire Technologique 83
  • Référentiel NPTTiers concernés • Client. • Présentation. Le choix de technologies standards dans ce tiers facilite l’accès aux services par des clients existants. Par exemple, une application qui offre une in- terface développée au dessus de HTTP/HTML est accessible au travers de tous les navigateurs Web. Cette approche est à opposer avec une application client- serveur qui offrirait une interface non-standard et qui demanderait l’implémentation de clients spécifiques. Les technologies de Web services sont à prendre en compte dans ce contexte. • Métier. Standards métiers. • Intégration. Les standards définis dans ce tiers mettent en avant le découplage entre le tier "métier" et le tier "ressources". Les technologies d’intégration per- mettent aux composants applicatifs d’accéder à des données (par exemple, un composant "contrôle des habitants" accède aux données "citoyen" grâce à la tech- nologie JDBC). En choisissant une technologie d’intégration standard, l’organisa- tion se donne la possibilité de choisir le produit implémentant ce standard, sans se lier à son fournisseur. Par exemple, en utilisant le standard JDBC, l’organisation peut stocker ses données dans n’importe quelle base de données offrant un pilote JDBC. Le principe est le même que pour la couche Plateforme supérieure. • Ressources.RisquesEn intégrant des composants qui n’adhèrent pas aux standards adoptés par l’industrie,une organisation risque de se placer dans une situation de dépendance par rapport auxfournisseurs de ces composants (il lui sera en effet beaucoup plus difficile de rempla-cer ces composants). L’intégration de composants propriétaires avec les autres élémentsdu système sera également plus coûteuse puisqu’elle demandera beaucoup de dévelop-pements spécifiques (au lieu d’outils "prêts à l’emploi" souvent disponibles lorsque destechnologies standards sont adoptées).Sur un autre plan, si une organisation néglige la standardisation de ses principes archi-tecturaux, de ses méthodes de développement, de sa documentation, elle s’expose à unmanque de cohérence de l’ensemble du système, à des problèmes de maintenance etd’évolution. Le coût associé peut alors être très important.MesuresLes questions suivantes permettent d’évaluer quelques aspects liés à cette dimension : • Le système offre-t-il des interfaces (formats de fichiers, APIs, technologies distri- buées, interfaces physiques, etc.) qui implémentent des standards adoptés par l’in- dustrie ?Observatoire Technologique 84
  • Référentiel NPT • Le système est-il constitué de composants qui sont conformes aux standards spé- cifiés par l’organisation ? • Le système est-il constitué de composants qui sont conformes à des standards ouverts ? • Le système a-t-il été implémenté en suivant des standards d’architecture, de concep- tion et d’implémentation (que ceux-ci soient définis par l’organisation ou par une communauté plus large) ? • Le système peut-il être mis en production, administré et maintenu d’une manière qui soit cohérente avec l’ensemble du système informatisé de l’organisation ?Aspects métierCompétence • Comité d’Architecture Technique (CTI)RéférencesNormes et standards ouverts, Annexe au rapport final du projet NPT, Observatoire Tech-nologique 2003, http://www.geneve.ch/obstech/referentiel/referentiels.htmlObservatoire Technologique 85
  • Chapitre 6Dimensions relatives àl’OrganisationLes dimensions Facteurs économiques et Formation et organisation ont été regroupéessous le label commun Dimensions relatives à l’organisation. Ces dimensions, ainsi queles sous-dimensions correspondantes prennent en compte les aspects touchant très di-rectement à l’organisation nécessaire à la mise en oeuvre d’une technologie ou d’uncomposant informatique. 86
  • Référentiel NPT6.1 Aspects économiquesRévisions Version Date / auteurs Objet de la révision 0.1 2003-08-18 / gpl Première version 0.2 2003-08-19 / gpl Intégration en une seule dimensions des as- pects économiques ; notion d’externalité. 0.3 2003-10-09 / gpl Introduction des options réellesDescriptionLa complexité des décisions d’investissement dans les TIC ne peuvent pas être cap-turées par une seule métrique telle que le Total Cost of Ownership ou une analysecoûts/bénéfices. Une approche globale telle que celle préconisée dans ce référentiel,où la dimension économique joue un rôle important mais pas unique, est à privilégier.Dans le secteur public, des notions qualitatives seront aussi nécessaires pour jauger lavaleur d’un investissement informatique.Evaluer la valeur d’un projet informatique est une tâche difficile principalement pour deuxraisons. La première est que l’environnement informatique est rarement vierge et les nou-veaux projets dépendent des autres technologies existantes, notamment de leur qualitéssystémiques et de leur intégration. La seconde raison tient au fait que les investissementinformatiques sont rarement effectués pour une raison purement technique : ils font engénéral partie d’un cadre plus large, demandant une vision des aspect liés aux métiersou à l’organisation interne.Ces difficultés rendent l’évaluation économique d’un projet informatique délicate et laprécision de l’évaluation est en général faible.La plupart des organisations sont confrontées à deux grandes catégories de projets liésaux TIC : 1. les projets visant à une réduction des coûts, 2. les projets qui permettent de créer de nouvelles perspectives.Dans le premier cas, une approche “classique” d’évaluation économique est préconisée :les incertitudes sont faibles et les calculs de ROI ou de valeur actualisée sont pertinents.Pour cette approche on se rapportera à la section “Analyse côuts / bénéfices”.Dans le second, en revanche, le facteur temps est une variable beaucoup plus impor-tante. Le but est d’intégrer non seulement les métiers et la technologie, mais aussi lesacteurs et les étapes dans une vision unique. Les décisions dans ce type de projet sontsouvent séquentielles : l’arrêt ou la continuation du projet dépendent d’informations ré-coltées au cours des étapes précédentes et sont aussi influencés par un futur incertain.Ce cas demande une approche plus fine et sophistiquée intégrant la dynamique des évé-nements. L’analyse des options réelles propose une méthodologie tenant compte de cesaspects et est présentée dans la section “Options réelles” ci-dessous.Observatoire Technologique 87
  • Référentiel NPTAnalyse coûts / bénéficesLes investissements informatiques envisagés sont évalués par rapport à leur efficacitééconomique. Un budget est estimé pour la première année ainsi qu’un coût de fonction-nement pour les années suivantes. Le tableau ci-dessous résume les grandes catégoriesde coûts dont il faut tenir compte lors de l’analyse. Les sources de financement n’in-fluencent pas directement l’efficacité économique du projet envisagé, mais peuvent avoirun rôle quant à la disponibilité des ressources prévues au budget.La période de temps sur laquelle porte le calcul correspond au cycle de vie du systèmeenvisagé, en particulier les étapes : Etude de plausibilité, Conception, Développement,Réalisation, Mise en œuvre et Maintenance.L’analyse doit également considérer plusieurs alternatives (trois au moins) pour l’obten-tion des objectifs du projet, l’une de celles-ci étant de continuer sans changement (statuquo).L’identification, la description et l’estimation des bénéfices et des coûts doit être faite dela façon la plus rigoureuse possible. Le niveau de détail de l’analyse dépend de l’objetexaminé : un grand projet, complexe et coûteux sera détaillé plus finement qu’un projetde plus petite envergure.Les estimations doivent être explicites quant aux hypothèses faites pour aboutir aux va-leurs présentées. Les valeurs non tangibles doivent également être incluses en évaluantleur importance.Les effets indirects, aussi appelés externalités, sont des bénéfices ou des coûts qui nesont pas pris en compte dans le projet courant. Ces externalités sont typiques dans lesbiens ou services publics, notamment pour les investissements d’infrastructure, qui pro-fitent à un ensemble d’acteurs, mais dont aucun ne veut supporter le coût. Une “inter-nalisation” des coûts (ou des bénéfices) est nécessaire pour éviter une distorsion del’analyse.Par ailleurs, les propriétés de non-rivalité (une unité consommée par un agent peut aussiêtre consommée par un autre sans diminution de satisfaction) et de non-exclusion (onne peut pas en restreindre facilement la consommation à un agent ou à un groupe) ca-ractérisent les biens publics. Ceux-ci ne répondent pas aux mêmes mécanismes que lesbiens habituels dont les échanges (les prix et les quantités) sont régulés optimalementpar un marché concurrentiel et doivent en conséquence être traités de façon différente.Le but n’est pas de sélectionner le portefeuille d’investissements informatiques unique-ment sur des aspects financiers, mais de trouver l’alternative la plus rationnelle économi-quement.Les coûts déjà encourus dans le passé ou les bénéfices déjà réalisés ne doiventen aucun cas être considérés.Les grandes étapes d’une analyse économique sont les suivantes : 1. Définir les objectifs. Les objectifs du projet et les autres informations pertinentes sur l’environnement de celui-ci doivent être incluses de façon à permettre à une personne externe au projet de comprendre ses buts. 2. Documenter l’existant. La ligne de base pour l’analyse sont les systèmes et lesObservatoire Technologique 88
  • Référentiel NPT processus existants. C’est à partir des informations concernant ces éléments que de nouvelles alternatives sont considérées. Les domaines principaux à documenter sont : les services utilisateur, les capacités du système, l’architecture technique et les coûts (et éventuellement les revenus) du système. 3. Estimer les besoins futurs. Les besoins déterminent les capacités et l’architec- ture des systèmes, qui à leur tour influencent les coûts et les bénéfices. Il est très important d’estimer avec le plus de précision possible les besoins futurs. Les deux éléments clé dont il faut tenir compte sont le cycle de vie du système et la demande de pointe que le système devra absorber. 4. Recueillir les données. Afin d’estimer les coûts et les bénéfices de chaque alter- native, il est nécessaire d’apprécier les quantités demandées à l’aide des données historiques de l’organisation, des coûts du système actuel, des analyses de mar- ché, d’informations publiées, de jugements d’analystes et d’études spécifiquement demandées. 5. Décrire au moins trois alternatives. L’analyse doit présenter au moins trois al- ternatives. L’une de celles-ci doit être la continuation du service sans modifica- tion. Chaque approche technique viable peut représenter une alternative différente. Cette contrainte ne peut être levée que si le coût du projet est suffisamment faible pour pouvoir le justifier. 6. Documenter les hypothèses. Il est important de spécifier clairement les hypo- thèses sous-jacentes à l’analyse qui est faite et de les justifier sur la base d’expé- riences ou des données réelles. Cette partie permet également d’expliquer pour- quoi certaines alternatives n’ont pas été inclues dans l’analyse. 7. Estimer les coûts. Plusieurs facteurs doivent être pris en compte lors de l’évalua- tion des coûts comme par exemple le matériel, le logiciel, les ressources humaines, la formation, les infrastructures nécessaires. Tous ces coûts supportés au cours du cycle de vie doivent être inclus. On peut citer notamment : • les coûts d’acquisition, • les coûts de développement, • les coûts de déploiement, • les coûts de maintenance, • les coûts de substitution (reprise de l’existant), • les coûts de personnel (interne et externe), • les coûts de modification de processus (souvent négligé). 8. Estimer les bénéfices. Estimer les bénéfices est probablement la partie la plus délicate de l’analyse. Ces bénéfices doivent être identifiables comme par exemple la réduction de temps d’exécution d’une tâche ou l’amélioration de la qualité du résultat. Des bénéfices globaux comme la flexibilité, l’organisation stratégique, la gestion du risque de l’unité peuvent également entrer dans le calcul. La notion de bénéfice citoyen expliquée dans les éléments en annexe est également très importante. 9. Décrire les bénéfices ou les coûts non tangibles. Certains bénéfices liés au projet ne peuvent pas être chiffrés monétairement dans les rubriques précédentes. Evaluer l’importance de chacun de ceux-ci sur l’échelle -2, -1, 0, +1, +2.Observatoire Technologique 89
  • Référentiel NPT Produit des bénéfices élevés : +2 Produit des bénéfices : +1 Ne produit ni coûts ni bénéfices : 0 Produit des coûts : -1 Produits des coûts élevés : -2 10. Actualiser les coûts et les bénéfices. Après que les coûts et bénéfices aient été identifiés et quantifiés, il faut les traduire en unités monétaires de la période courante. Pour ce faire on calcule une valeur actuelle actualisée dans le temps à l’aide de la formule P = F/(1 + i)n où P est la valeur actuelle, F la valeur future, i le taux d’actualisation et n le nombre d’années. Le taux d’actualisation est fixé en fonction notamment du taux d’intérêt du marché. 11. Evaluer les différentes alternatives. Effectuer les estimations et calculs pour les alternatives proposées. L’exercice est important pour pouvoir déterminer quelle al- ternative semble la plus rentable. Néanmoins, des facteurs tels que la taille du bud- get ou que les bénéfices non quantifiables entrent aussi largement en compte lors de l’évaluation d’un projet. 12. Effectuer une analyse de sensibilité. La fiabilité des résultats doit être testée pour s’assurer de la qualité des résultats obtenus. Lors de la prise de décision, il est probable que le réviseur de l’analyse demande l’impact qu’une variation d’un paramètre aurait sur l’analyse. Les paramètres qui sont les plus susceptibles de varier sont les demandes de pointe du système, les coûts en ressources humaines, les bénéfices estimés et le taux d’actualisation.Options réellesLa plupart des projets informatiques stratégiques contiennent plusieurs sources de risqueet d’incertitude. Ces éléments doivent être reconnus et gérés. L’une des manières de lescontrôler est d’investir séquentiellement et redimensionner le projet au fur et à mesureque les incertitudes s’effacent.La théorie des options réelles permet de tenir compte de ces incertitudes et de poser desjalons pour intégrer de nouveaux éléments d’information dans le processus de décision.De façon simplifiée, une option est une assurance qui permet, lorsqu’on l’acquiert, de seprotéger en la faisant intervenir le cas échéant.La notion d’option est d’abord apparue dans le monde de la finance. Savoir quel prixfixer à ce type de “contrat d’assurance” a longtemps été étudié et débattu. En 1973, leschercheurs Black, Scholes et Merton ont trouvé une formule permettant de déterminer lavaleur d’une option financière, ce qui leur a valu le prix Nobel en 1997.Une option en finance est un contrat conférant le droit d’acheter (option d’achat, “call” )ou de vendre (option de vente, “put” ) une quantité spécifiée d’un actif (sous-jacent del’option), à un prix déterminé d’avance (prix d’exercice), à une échéance donnée (optioneuropéenne) ou tout au long d’un intervalle de temps spécifié (option américaine).Les options réelles se fondent sur un concept similaire aux options financières, mais ontpour objet l’étude des investissements des entreprises. Alors que les options financièresObservatoire Technologique 90
  • Référentiel NPTsont des contrats détaillés et traités sur des marchés organisés ou de gré à gré, lesoptions réelles sont plus difficiles à identifier et à spécifier. Elles existent de manièrenaturelle au sein d’un projet risqué, lorsque celui-ci offre des flexibilités opérationnelles oustratégiques, c’est-à-dire lorsque les décideurs ont des choix alternatifs dans la gestionde l’investissement ou simplement lorsque l’on peut attendre avant d’investir.Quatre conditions sont nécessaires pour qu’un projet possède une option réelle.Tout d’abord, le projet doit contenir une composante irréversible (au moins partielle-ment), car sans cette modalité les dépenses peuvent toujours être récupérées, ce quirend l’analyse inutile.Ensuite le projet comportera une part de risque. Si la valeur du projet n’est pas affectéepar les événements et les états différents de la nature, l’incertitude n’existe pas et lavaleur d’option est nulle.De plus, les décideurs doivent avoir une liberté d’action sur le projet. Le projet doit doncposséder une certaine flexibilité. Les options, qui permettent de valoriser les marges demanœuvre existantes, ne peuvent prendre un sens que si la possibilité d’influencer lecours du projet existe réellement.Finalement, le dernier élément essentiel est l’horizon temps. Un laps de temps doit êtreprésent pour permettre l’exercice (ou non) de l’option. Plus ce temps est court, plus lavaleur de l’option est faible et, à la limite, lorsque celui-ci est inexistant, la valeur devientnulle.L’analyse traditionnelle de l’analyse coûts/bénéfices et les critères tels que la va-leur actuelle nette ou le ROI possèdent un inconvénient majeur. Ils n’intègrent pasla possibilité d’adopter une démarche active dans la gestion, par exemple en mo-difiant l’échéancier ou l’évolution du projet.La littérature des options réelles distingue généralement sept catégories. Elles sont briè-vement présentées ci-dessous dans un ordre croissant de complexité. 1. L’option de reporter. Reporter un investissement est sans doute l’option la plus simple (le terme anglais pour cette option est “option to delay” ). La flexibilité intro- duite est donnée par la possibilité d’obtenir plus d’informations pertinentes concer- nant, par exemple, les coûts, les conditions du marché ou l’évolution d’un produit entrant dans le projet avant de le faire démarrer. 2. L’option d’abandonner. Cette option permet de renoncer complètement à l’inves- tissement (“abandonment option” ). Elle annule les coûts associés au maintien du projet et permet de réaffecter les ressources libérées. Lorsque le projet exige des dépenses continuelles pour être maintenu en vie, les économies réalisées par un abandon sont substantielles. Cette option permet aussi de mettre en évidence les aspects positifs souvent igno- rés par le détenteur de l’option, comme le savoir-faire technologique ou les compé- tences organisationnelles acquises au cours du projet. Dans une approche plus classique, l’abandon est considéré comme un échec, alors que ses caractéristiques positives peuvent être mises en valeur par cette approche. 3. L’option de renoncer à l’investissement en cours. Les projets, ainsi que les in- vestissements liés à ceux-ci, procèdent souvent par phases successives (“time toObservatoire Technologique 91
  • Référentiel NPT build option” ). L’option de renoncer en cours de réalisation, souligne la flexibilité qui résulte de l’alternative se présentant à chaque étape : consentir à continuer le projet si les informations et l’environnement sont favorables, ou renoncer à le poursuivre dans le cas contraire. Cette option est en quelque sorte une généralisation du cas de l’option d’abandon- ner : un grand projet est découpé séquentiellement, et à chaque étape une option d’abandon est analysée, le coût d’opportunité du projet étant ré-évalué. Ce type d’option est beaucoup plus complexe à mesurer que la précédente catégo- rie, car les options sont imbriquées à chaque étape. Le prototypage (sites pilotes) peut être facilement inclus dans ce type d’options, en tenant compte du fait que le projet possède des coûts et des revenus à chaque jalon, mais que l’information retirée et l’écoulement du temps amènent une valeur d’option au projet. 4. Les options de modifier l’intensité. Dans ce type d’options on considère la pos- sibilité d’augmenter, de diminuer ou même d’arrêter momentanément les investis- sements (“options to alter operating scale” ). Ce cas se présente plutôt dans les projets d’exploitation. Ces options sont utiles pour faire face à une demande ou une offre variables. Le coût permettant de bénéficier de cette flexibilité est celui de pré- voir une technologie permettant de s’adapter. Ceci peut aussi être assuré par des contrats externes permettant de faire face à une demande accrue ou au contraire pour externaliser les coûts. 5. Les options d’échange. Elles permettent de modifier les sources à partir des- quelles la production finale est bâtie ou, inversement, les résultats de la production en gardant les mêmes inputs (“options to switch use” ). Cette option est intégrée dans les projets lorsque, par exemple, ceux-ci utilisent des technologies reposant sur des standards qui permettent facilement de changer des éléments indépendamment les uns des autres. 6. Les options de croissance. Ces options (“growth options” ) sont utilisées dans une optique de stratégie à long terme. Elles regroupent des caractéristiques des options d’abandon en cours de réalisation, des options d’échange et des options de modifier l’intensité. Elles offrent un cadre conceptuel pour analyser une stratégie de développement global d’une organisation ou les relations de partenariat avec d’autres entreprises. 7. Les options multiples interactives. La réunion de plusieurs options et leur inter- relations donne lieu à cette catégorie (“multiple interacting options” ). Par exemple, elles émergent naturellement lorsque l’on considère l’ensemble des options qui apparaissent dans différents projets. Elles sont qualifiées d’interactives car elles peuvent avoir des influences les unes sur les autres et, de ce fait, leur agrégation peut devenir complexe.L’analogie entre options financières et options réelles permet d’identifier les facteurs quiinfluencent la valeur de ces dernières. En adaptant les notions, ces facteurs sont : lesflux de revenus futurs et de dépenses à consentir, la variabilité de ceux-ci, l’échéance àla laquelle l’opportunité d’investissement disparaît ainsi que le niveau et la volatilité dutaux d’intérêt hors risque.Observatoire Technologique 92
  • Référentiel NPTLe caractère asymétrique d’une option introduit un effet positif dans le projet auquel elleest attachée : la valeur de l’option ne pouvant être que positive ou nulle, la distributiondes gains nets décalée vers les grandeurs positives. Ainsi, l’introduction d’options dansun projet ne peut qu’en augmenter la valeur. L’un des aspects intéressants est que cettevaleur augmente avec le niveau d’incertitude, puisque l’on possède le moyen de s’enprotéger.La valorisation des options réelles reste un sujet délicat et difficile à mettre en œuvre. Lalogique introduite reste néanmoins importante et apporte au moins deux avantages. Pre-mièrement, celle-ci incite les acteurs à modifier leur comportement par rapport à l’incerti-tude en prenant en compte les avantages potentiels : la possibilité d’obtenir des résultatstrès positifs associés à des projets risqués. Deuxièmement, les options permettent devaloriser la flexibilité introduite dans un projet et à identifier des opportunités qui n’étaientpas mises en évidence auparavant. Il faut à nouveau souligner que l’incertitude valo-rise les projets intégrant des options réelles, alors qu’elle dévalorise les projetsstatiques.On peut donc considérer les options réelles comme une cadre conceptuel important pouramener des notions de dynamique, de synchronisation et de risque dans les projets in-formatiques.Couches concernéesLes aspects économiques peuvent se décliner sur les différentes couches concernéesselon les éléments qui sont touchés par le projet envisagé. La redéfinition de processuset de structures organisationnelles vient naturellement s’inscrire dans la couche du sys-tème d’information. Les logiciels acquis pour mettre en œuvre la solution sont comptabili-sés sous les couches application, plateforme supérieure, plateforme inférieure selon leurcaractéristiques. La couche matériel contiendra les dépenses afférentes aux serveurs,stations de travail et autres éléments physiques.Tiers concernésLa distinction entre les différents tiers ne s’applique pas à cette dimension. Toutefois, laprise en compte d’une architecture par tiers permet d’introduire une flexibilité qui doit êtrevalorisée en termes d’options possibles.Risques • Le manque de prise en compte des aspects financiers dans un projet peut conduire à des investissements sous optimaux au point de vue économique. • Les éléments futurs sont difficiles à estimer, bien qu’il soit indispensable de les envisager. • Une vérification a posteriori afin d’éviter des abus n’est pas mise en œuvre. Des solutions alternatives simples (p.ex. le statu quo ou une technologie très simple) neObservatoire Technologique 93
  • Référentiel NPT sont pas incluses et comparées dans l’analyse parce qu’elles ne permettent pas de justifier une dépense. • Des éléments tels que les coûts de formation ou de mise à disposition de locaux ne sont pas pris en compte ou sous-estimés dans l’analyse. • Les effets indirects ou externalités ne sont pas considérés bien qu’il représentent un impact important. • Les coûts ou bénéfices déjà encourus dans le passé sont à nouveau considérés. • Les aspect économiques et financiers prennent le dessus sur l’analyse plus globale, car ils sont quantifiables et permettent une comparaison facile des alternatives. • Les notions d’incertitude et de risque sont uniquement perçus comme négatifs et ne sont pas valorisés en termes d’options. • La flexibilité du projet n’est pas reconnue et une approche “classique” d’évaluation (return on investement, valeur actuelle nette, etc.) pénalise le projet.MesuresLes éléments mise en évidence par une analyse coûts / bénéfices peuvent être utiliséspour calculer une valeur actualisée nette, un retour sur investissement, un taux de ren-dement interne, une période de repaiement ou un retour sur investissement.La valeur d’option du projet doit être évaluée et intégrée, le cas échéant, à la mesureéconomique du projet.Le projet vise-t-il une réduction des coûts ou une exploration de nouvelles perspectives ?A-t-on évalué différentes alternatives du projet ?Le projet contient-il des options qui permettent une flexibilité ? Par exemple, contient-ilune phase de prototypage ?Compétence • Responsables budgétaires et financiers. • Commission de gestion du portefeuille de projets (CGPP). • Maîtrise d’ouvrage. • Maîtrise d’œuvre.RéférencesObservatoire Technologique, Le Référentiel e-Société, CTI, Etat de Genève, juin 2003.[En ligne] août 2003 URL document HTML http://www.geneve.ch/obstech/referentiel/ref-e-soc/ref-e-soc.html et URL document PDF ftp://ftp.geneve.ch/obstech/ref-e-soc.pdfObservatoire Technologique 94
  • Référentiel NPTIntergovernmental Advisory Board, High Payoff in Electronic Governement : Measuringthe Return on E-Government Investments, U.S. General Services Administration, Gou-vernement américain, mai 2003. [En ligne] août 2003 URL www.gsa.gov/intergov/.National Office for the Information Economy, E-Government Benefits Study, Gouverne-ment australien, avril 2003. [En ligne] août 2003 URL http://www.noie.gov.au/publications/.Di Maio, A., Value for Money Is Not Enough in the Public Sector IT Projects, GartnerGroup, 25 juin 2003. [En ligne payant] URL http://www.gartner.com/.CGPP, Documents de la Commission de Gestion du Portefeuille de Projets, Etat de Ge-nève. [En ligne] août 2003 URL http://obstech.etat-ge.ch/cgpp.nsf.Lautier, D., Les options réelles : Une idée séduisante, un concept utile et multiforme, uninstrument facile à créer, mais difficile à valoriser, Cahiers du CREG no 2002.05, 2002.[En ligne] octobre 2003 URL http://www.dauphine.fr/cereg/Cahiers/200205.pdf.Benaroch, M., Managing Information Technology Investment Risk : A Real Options Pers-pective, Journal of Management Information Systems, Vol. 19, No. 2, pp. 43-84, Fall 2002.[En ligne] octobre 2003 URL http://sominfo.syr.edu/facstaff/mbenaroc/PAPERS/jmis/jmis-1.pdf.Amram, M., Kulatilaka, N., Real Options : Managing Strategic Invetsment in an UncertainWorld, Harvard Business School Press, Boston, 1999.Observatoire Technologique 95
  • Référentiel NPT6.2 Formation et OrganisationRévisions Version Date / auteurs Objet de la révision 0.1 2003-08-20 / gpl Version initiale 0.2 2003-10-06 / gplDescriptionLes choix technologiques peuvent avoir un impact important sur les modes de fonction-nement et l’organisation du travail.Par ailleurs, il est souhaitable que les choix organisationnels soient indépendants desmoyens de traitement et des données sur lesquelles le travail est effectué.Pour cette dimension, les nouvelles formations et les redéfinitions de processus sont lesdeux aspects les plus souvent touchés par l’introduction de nouvelles technologies.La formation doit être perçue comme une construction de la connaissance et pas unique-ment une activité d’enregistrement ou d’absorption de techniques. Les personnes uti-lisent en grande partie les connaissances déjà acquises pour en assimiler de nouvelles.La formation doit donc être inclue suffisamment tôt dans les réflexions et être adpatéeaux situations présentes pour être profitable. Il faut aussi noter que la motivation person-nelle joue un rôle important par rapport aux problèmes cognitifs dans l’apprentissage denouvelles technologies ou de nouvelles connaissances en général.L’objectif visé est de rendre les utilisateurs et les techniciens autonomes dans l’accomplis-sement des tâches qui leur incombent et capables de s’adapter à des situations de travailvariées découlant de l’évolution technologique et des changements dans l’organisationdu travail.Sous-dimensions • Organisation et formation des utilisateurs • Organisation et formation des informaticiensObservatoire Technologique 96
  • Référentiel NPT6.2.1 UtilisateursRévisions Version Date / auteurs Objet de la révision 0.1 2003-08-20 / gpl Version initiale 0.2 2003-10-06 / gplDescriptionLa formation et l’information aux utilisateurs sont deux aspects cruciaux lors de l’introduc-tion d’une nouvelle technologie. Les technologies principalement concernées sont cellestouchant les tiers du client, de présentation et du métier. Les modifications impliquant lescouches du système d’information et des applications sont vraisemblablement celles quidemandent une réorganisation ou une formation supplémentaire auprès des utilisateurs.Le rôle des utilisateurs doit être intégré comme un aspect actif du déploiement d’unenouvelle technologie. En particulier, l’information mise à disposition de utilisateurs leurpermet de se documenter sur les nouveautés et de mieux cibler ses demandes. Idéale-ment l’utilisateur devrait : • pouvoir déterminer de quelle information il a besoin, • savoir où et comment la trouver, • pouvoir la lire et la comprendre, • pouvoir la critiquer et évaluer si elle répond à son besoin, • savoir l’utiliser et la gérer, • pouvoir l’exploiter pour développer sa connaissance.Par exemple, le rôle d’une bonne documentation et de groupes d’experts ou d’utilisateurspouvant partager leur expériences dans un espace collaboratif éléctronique permettentde favoriser les point précédents.Couches concernées • Système d’information. L’introduction d’une nouvelle technologies demande un ré- organisation en profondeur touchant les processus de travail et demandant une réorganisation de ceux-ci. • Application. Une nouvelle application peut demander la mise en œuvre d’une nou- velle organisation ou formation spécifique. • Plateforme supérieure Cette couche peut avoir un impact sur l’organisation et la formation seulement si les applications sont intimement imbriquées au système d’exploitation. Dans ce cas, changer de plateforme implique un changement au niveau de la couche Application.Observatoire Technologique 97
  • Référentiel NPT • Plateforme inférieure Idem Plateforme supérieure. • Matériel. En principe transparent pour l’utilisateur, à moins que la plateforme et/ou les autres couches supérieures ne doivent être significativement modifiées.Tiers concernés • Client. Une introduction de nouveaux éléments ou un changement d’ergonomie sont très fortement ressentis par l’utilisateur final. Un changement significatif de- mande tout au moins une bonne information, voire une formation si cela est oppor- tun. • Présentation. La gestion de la présentation devrait permettre un “rendu” similaire ou adpaté à l’environnement de l’utilisateur, ce qui permet de diminuer l’impact sur la formation. • Métier. Un changement des régles métiers nécessite en général une formation de l’utilisateur afin qu’il sache utiliser correctement les éléments modifiés. • Intégration. En principe transparent pour l’utilisateur. • Ressources. En principe transparent pour l’utilisateur.RisquesLes utilisateurs ne sont pas préparés à l’introduction d’une nouvelle technologie et larejettent plus facilement.Les changements, même s’ils présentent des avantages, sont souvent mal ressentis s’ilsne sont pas accompagnés.MesuresLes besoins des utilisateurs concernant la formation et l’information sont-ils considérésdans le projet ?Les formations et documentations nécessaires à l’introduction d’une nouvelle technologieont-elles été préparées ?L’information préparant au changement technologique a-t-elle été communiquée ?Compétence • Centre de formation • Chefs de projets dont les projets ont un impact sur les utilisateurs • Utilisateurs concernés et leur hiérarchieObservatoire Technologique 98
  • Référentiel NPT6.2.2 InformaticiensRévisions Version Date / auteurs Objet de la révision 0.1 2003-08-21 / gpl Version initiale 0.2 2003-10-06 / gplDescriptionLa formation et l’organisation des informaticiens et des ingénieurs joue un rôle importantlors de l’introduction d’une nouvelle technologie. Les effets doivent être maîtrisés afinque le service offert par les équipes techniques soit de niveau élevé aussi rapidementque possible.La notion d’apprentissage tout au long de la vie (“life-long learning” ) doit être assimiléepar les personnes en particulier dans les métiers liés aux technologies de l’informationqui sont fortement sujets aux changements et aux innovations.Dans ce cadre, il s’agit de donner aux techniciens en informatique une formation tech-nique et humaine, théorique et pratique qui les rend aptes à exercer convenablementleur profession d’informaticiens. L’accent devra être mis notamment sur la polyvalence endéveloppant les connaissances et les habiletés nécessaires, non seulement à accomplirles tâches actuelles, mais aussi à pouvoir intégrer des concepts portables d’un environ-nement technologique à un autre.D’autre part, la notion de gestion de projet permet d’intégrer des notion importantes quantà l’exécution des tâches et des missions de chaque équipe. Dans toute structure, lesmoyens alloués pour une réalisation sont accompagnés de processus qui encadrent ladémarche et permettent d’en assurer la qualité. Une organisation et une gestion de pro-jet définis clairement permettent, d’une part, une meilleure allocation des ressources,des compétences et des délais et, d’autre part, une capitalisation des connaissances dechacun. Par ailleurs, les collaborations avec d’autres projets doivent aussi être favoriséesafin d’éviter les redondances et d’augmenter les synergies.Un point important à souligner est le niveau existant de compétences soit interne à lastructure, soit sur le marché local. En effet, l’introduction d’une nouvelle technologie doitêtre accompagnée par la mise à disposition de ressources humaines. D’un côté, la forma-tion peut compléter les connaissances des personnes en interne et, de l’autre, le marchélocal doit aussi permettre de compléter les compétences manquantes. Il est donc impor-tant d’évaluer la niveau de compétences existant dans ces deux “marchés” du travail.Couches concernéesLes différentes couches sont couvertes par un structure organisationnelle : les serveurssont gérés par un service, les aspects liés aux système d’exploitation et aux applicationspar d’autres. Un changement de technologie peut donc avoir un impact non négligeablesur les aspects organisationnels.Observatoire Technologique 99
  • Référentiel NPTTiers concernésUne déclinaison par tiers n’est pas faite ici.RisquesLa non prise en compte de la formation des ingénieurs et techniciens suite à l’introductiond’une nouvelle technologie conduit à des lacunes dans leur connaissances et des inef-ficacités dans le travail exécuté. Le manque de maîtrise de la technologie peut ralentirl’adoption d’une nouvelle technologie ou aller jusqu’à mettre en difficulté la production.Une organisation non adaptée ne permet pas de répondre dans un délai suffisammentcourt et avec une qualité suffisamment élevée aux demandes.MesuresLes formations nécessaires aux informaticiens sont-elles prévues dans l’échéancier duprojet ?Les formations mettent-elles en valeur la portabilité des connaissances indépendammentde la technologie ?L’introduction d’une nouvelle technologie modifie-t-elle l’organisation des services ?Les compétences liées à une nouvelle technologie existent-elles en interne ? Peut-onenvisager une formation ?Le marché du travail permet-il d’engager des personnes compétentes ?Compétence • Centre de formation • Ressources humaines • Maîtrise d’œuvre • Maîtrise d’ouvrageObservatoire Technologique 100
  • Chapitre 7Dimensions relatives à la sécuritéLes dimensions Gestion des politiques d’accès, Contrôle et Confidentialité ont été regrou-pées sous le label commun Dimensions relatives à la sécurité. Ces dimensions, ainsi queles sous-dimensions correspondantes prennent en compte les aspects touchant à la sé-curité des données, des applications et des infrastructures. La prise en compte de lasécurité en amont de toute réflexion est essentielle si l’on veut bâtir un système d’infor-mation sûr, fiable et pérenne. C’est pour cette raison que ces dimensions ont été misesen exergue ici. 101
  • Référentiel NPT7.1 Gestion des politiques d’accèsRévisions Version Date / auteurs Objet de la révision 0.1 2003-10-06 / gpl,pge Version initialeDescriptionLa dimension Gestion des politiques d’accès permet d’analyser la capacité de la tech-nologie ou du composant informatique étudiés à gérer d’une part l’authentification desutilisateurs et des processus et d’autre part les autorisations correspondantes.Sous-dimensions • Authentification : mesure la capacité du système étudié à identifier un utilisateur ou un processus. • Autorisation : mesure la capacité du système à gérer les droits des utilisateurs et/ou des processus autorisés.MesuresLa mesure de la dimension Gestion des politiques d’accès est une agrégation des me-sures des sous-dimensions correspondantes.Observatoire Technologique 102
  • Référentiel NPT7.1.1 AuthentificationRévisions Version Date / auteurs Objet de la révision 0.1 2003-11-20 / pge Version initialeDescriptionL’authentification garantit l’identification d’un utilisateur ou d’un composant matériel afinde certifier qu’il est bien qui il prétend être et lui permettre ainsi d’obtenir certains droitsd’accès dans le système informatique. Elle est cruciale pour le contrôle de l’accès auxressources d’une organisation.Une procédure d’authentification comporte trois phases distinctes : 1. L’identification qui consiste à fournir l’une de ses identités (elles peuvent être en effet multiples). 2. L’authentification proprement dite qui consiste à prouver que nous sommes bien détenteurs de l’identité annoncée. 3. La transmission de son profil qui consiste à fournir certaines informations atta- chées à l’identité annoncée (état civil, adresse, coordonnées bancaires, informa- tions médicales, etc.).Il existe trois façons de s’authentifier : • Par ce que l’on sait : en donnant une information uniquement connue par la per- sonne disposant de cette identité (par exemple un mot de passe). • Par ce que l’on possède : par exemple une calculette, un badge ou un certificat. • Par ce que l’on est : en utilisant une caractéristique physique de la personne comme par exemple les empreintes digitales ou rétiniennes (on parle alors de biométrie).De nombreuses technologies sont basées sur ces trois types d’authentification. Priseséparément, chacune d’elles présente cependant des failles de sécurité plus ou moinsimportantes. On parle alors d’authentification faible. En les combinant, on obtient ce-pendant des solutions qui sont plus difficiles à contourner. On considère que l’on a dansces cas une authentification forte.Le degré d’authentification nécessaire dépend à la fois du lieu d’où on accède à l’infor-mation (réseau interne ou externe) et de la sensibilité de cette dernière.La procédure d’authentification peut se faire à deux niveaux : 1. Au niveau des applications ou du système d’exploitation (accès par identification de l’utilisateur accompagnée d’un jeton et/ou d’un certificat). 2. Au niveau du réseau (systèmes d’exclusion de gammes d’adresses IP).Observatoire Technologique 103
  • Référentiel NPTLes technologies et les composants informatiques doivent pouvoir prendre en comptecorrectement la notion d’authentification, notamment lorsque des données sensibles sontconcernées.Couches concernées • Système d’information. Au niveau du système d’information, l’authentification doit être prévue comme une partie intégrante des règles et des processus appliqués aux acteurs du système. Dans cette couche on mesurera donc la capacité de la technologie ou du composant informatique étudiés à s’y conformer. • Application. Dans cette couche mesure la qualité de l’authentification en fonction de la sensibilité des informations et du lieu d’où on y accède. Les standards d’authenti- fication du CTI doivent pouvoir être pris en compte (la compatibilité avec la sécurité au niveau des autres couches doit notamment être préservée tout en évitant les re- dondances). Les fonctionnalités d’authentification et d’autorisation doivent pouvoir être obtenues au travers des annuaires de l’organisation. Elles doivent également prendre en compte correctement les directives de l’organisation relatives à la ges- tion des mots de passe (taille, durée de validité, etc.). • Plateforme inférieure. Dans cette couche on se préoccupera de la capacité du système d’exploitation à authentifier l’utilisateur et à être intégré au système d’an- nuaires de l’organisation. • Matériel. Dans cette couche on va déterminer dans quelle mesure le matériel peut être protégé d’une utilisation abusive via un mécanisme d’authentification propre (indépendant de la plateforme inférieure). Ceci est particulièrement important pour le matériel nomade (ordinateurs portables, PDA, etc...).La distinction sur les tiers n’est pas pertinente ici.Risques • Si cette dimension n’est pas prise en compte correctement, on risque de compro- mettre gravement la sécurité du système informatique de l’Etat. • Certaines technologies d’authentification risquent, suivant leur cadre d’utilisation, de poser problème en regard des cadres juridique ou éthique en vigueur (manque de bases légales notamment).Mesures • La technologie ou le composant informatique étudiés garantissent-ils un degré d’au- thentification suffisant ? • Peuvent-ils être intégrés aux services d’annuaires de l’organisation ? • Peuvent-ils être suffisamment bien intégrés au système informatisé de l’organisa- tion de manière à réduire ou à éliminer les redondances dans ce domaine ?Observatoire Technologique 104
  • Référentiel NPTAspects métierCompétence • Cellule sécurité des systèmes d’information de l’Etat de Genève • Responsable sécurité du CTI • Division technique de développement (CTI) • Division Réseaux et télécoms (CTI)DiversLa notion d’authentification prend une importance toute particulière lorsque l’on désireaccéder au système informatique de l’Etat depuis l’extérieur de celui-ci.Observatoire Technologique 105
  • Référentiel NPT7.1.2 AutorisationRévisions Version Date / auteurs Objet de la révision 0.1 2003-11-20 / gpl,pge Version initialeDescriptionL’autorisation permet à un utilisateur ou à un processus correctement authentifié d’ac-céder aux ressources du système informatique pour lesquelles leur propriétaire leur adonné un certain nombre de droits.La granularité permet de determiner jusqu’à quel niveau les autorisations sont gérées.Par exemple un utilisateur avec un rôle spécifique peut avoir un accès général au sys-tème, mais pas à des portions particulières.L’annuaire est le composant qui permet de rassembler et gérer les autorisations. Il devientde ce fait un élément central de la sécurité. Les accès aux données et aux processusformant le système d’information sont gérés en fonction des rôles, des responsabilités etde la protection des individus.Les notion de délégation des droits permet également une gestion facilitée des autorisa-tions en ne compromettant pas les éléments de base de la sécurité.Couches concernées • Système d’information. Les processus définis déterminent les autorisations néces- saires à l’exécution des tâches et leur granularité est adaptée à la mise en œuvre. Dans cette couche on mesurera donc la capacité de la technologie ou du compo- sant informatique étudiés à s’y adapter ou s’y conformer. • Application. Les applications requièrent les autorisations nécessaires pour les effec- tuer les actions ou pour accéder aux informations selon la granularité déterminée. Les applications font appel à un annuaire pour stocker et gérer ces droits. • Plateforme supérieure. Voir plateforme inférieure. • Plateforme inférieure. Le système d’exploitation permet une distinction de niveaux entre les utilisateurs, groupes d’utilisateurs et les administrateurs. • Matériel.La distinction sur les tiers n’est pas pertinente ici.Risques • Si cette dimension n’est pas prise en compte correctement, on risque de compro- mettre gravement la sécurité du système informatique de l’Etat.Observatoire Technologique 106
  • Référentiel NPTMesures • Les rôles et les responsabilités sont-ils définis ? • Les autorisations et les processus sont-ils adaptés ? Leur granularité permet-elle un bonne adéquation ? • Les applications peuvent-elles être reliées à un annuaire ? Peut-on gérer une délé- gation des droits ? • Le système permet-il de gérer de façon adéquate des niveaux entre utilisateurs, groupes et administrateurs ?Aspects métierCompétence • Cellule sécurité des systèmes d’information de l’Etat de Genève • Responsable sécurité du CTI • Division technique de développement (CTI) • Division Réseaux et télécoms (CTI)DiversLa notion d’autorisation prend une importance toute particulière lorsque l’on désire accé-der au système informatique de l’Etat depuis l’extérieur de celui-ci.Observatoire Technologique 107
  • Référentiel NPT7.2 ContrôleRévisions Version Date / auteurs Objet de la révision 0.1 2003-10-06 / gpl,pge Version initialeDescriptionLa dimension Contrôle permet d’analyser la capacité de la technologie ou du composantinformatique étudiés à gérer la sécurité des données au travers des mécanismes decontrôle ci-dessous.Sous-dimensions • Intégrité : mesure la capacité du système étudié à certifier le fait que les données n’ont pas été altérées ou détruites de manière frauduleuse. • Non-répudiation : mesure la faculté du système étudié à garantir le fait que les deux parties d’une transaction ne puissent nier l’avoir effectuée. • Traçabilité : mesure l’aptitude à retrouver l’historique, l’utilisation ou la localisation d’un produit ou d’un processus de délivrance d’un service au moyen d’identifications enregistrées.MesuresLa mesure de la dimension Contrôle est une agrégation des mesures des sous-dimensionscorrespondantes.Observatoire Technologique 108
  • Référentiel NPT7.2.1 IntégritéRévisions Version Date / auteurs Objet de la révision 0.1 2003-11-20 / gpl,pge Version initialeDescriptionL’intégrité est définie comme la qualité de données qui n’ont pas été altérées ou détruitesde manière frauduleuse (ISO 7498-2).L’intégrité est une fonction essentielle à mettre en œuvre au sein d’un système d’informa-tion si l’on veut pouvoir disposer d’une information fiable.Les exigences d’intégrité impliquent notamment : • Des système de fichiers avec contrôle d’accès permettant de cloisonner les don- nées. • Un contrôle à partir d’éléments calculés sur les données qui doivent rester inchan- gées (contrôles cycliques, signatures numériques). • L’utilisation du back-up. • L’authentification des intervenants. • Des contrôles de cohérence.Risques • L’impossibilité de garantir l’intégrité des données peut amener à une perte de confiance des utilisateurs et à un rejet de la solution envisagée. • Les technologies ou les composants informatiques mis en œuvre dans le cadre de services en ligne traitant des données personnelles ou sensibles doivent impéra- tivement pouvoir garantir l’intégrité de l’information au risque d’être rejetés par les citoyens.Mesures • La technologie ou le composant informatique étudiés garantissent-ils une intégrité suffisante de l’information ?Compétence • Cellule sécurité des systèmes d’information de l’Etat de Genève • Responsable sécurité du CTI • Division technique de développement (CTI)Observatoire Technologique 109
  • Référentiel NPTRéférences • ISO 9797 - Data integrity mechanisms • ISO 10118 1 à 4 - Hash functions • ISO 10181-6 - Integrity frameworkObservatoire Technologique 110
  • Référentiel NPT7.2.2 Non-répudiationRévisions Version Date / auteurs Objet de la révision 0.1 2003-11-20 / gpl,pge Version initialeDescriptionPour de nombreux types d’échange d’information, il est important que ni l’émetteur nile destinataire ne puissent nier le fait que l’information a été envoyée et reçue. C’est lerôle des service de non-répudiation qui sont des service de sécurité dont l’objectif est degénérer, récolter, maintenir, rendre disponible et valider l’évidence (information utiliséepour établir une preuve) concernant un évènement ou une action revendiquée afin derésoudre les possibles disputes sur l’occurrence ou non de l’évènement ou de l’action(dérivé de ISO/IEC DIS 13888-1).Le but de la non-répudiation, en conformité avec les spécifications ISO/IEC 13888 (voirréférences), est de fournir une preuve vérifiable, basée sur des valeur de contrôle cryp-tographiques de : • L’approbation. Un service de non-répudiation d’approbation fournit la preuve que l’émetteur du message a approuvé son contenu. • L’émission. Un service de non-répudiation d’émission certifie l’identité de celui qui a émis le message. • L’origine. Un service de non-répudiation d’origine est une combinaison des services d’approbation et d’émission. • La soumission. Un service de non-répudiation de soumission apporte la preuve qu’une autorité de livraison a accepté de transmettre un message. • Le transport. Un service de non-répudiation de transport apporte la preuve, pour l’émetteur d’un message, que l’autorité de livraison a délivré le message au desti- nataire prévu. • La réception. Un service de non-répudiation de réception apporte la preuve que le destinataire a reçu le message. • La reconnaissance. Un service de non-répudiation de reconnaissance apporte la preuve que le destinataire a reconnu le contenu du message reçu. • La livraison. Un service de non-répudiation de livraison est une combinaison des services de réception et de livraison. Il fournit la preuve que le destinataire a reçu et reconnu le contenu du message reçu.Couches concernées • Système d’information.Observatoire Technologique 111
  • Référentiel NPT • Application. Dans cette couche on vérifie que les applications gérant des transac- tions intègrent correctement un ou des services de non-répudiation. Ces services sont notamment requis dans le cas de la messagerie électronique afin que l’origine ou la livraison des messages puisse être prouvée par une tierce partie.La distinction sur les tiers n’est pas pertinente ici.Risques • L’impossibilité de garantir la non-répudiation des transactions peut amener à une perte de confiance des utilisateurs et à un rejet de la solution envisagée. Des pro- blèmes légaux peuvent également être envisagés dans ce cas. • Les technologies ou les composants informatiques mis en œuvre dans le cadre de services en ligne traitant des données personnelles ou sensibles doivent impérati- vement pouvoir gérer la notion de non-répudiation au risque d’être rejetés par les citoyens.Mesures • La technologie ou le composant informatique étudiés offrent-ils des mécanismes de non-répudiation suffisants ?Compétence • Cellule sécurité des systèmes d’information de l’Etat de Genève • Responsable sécurité du CTI • Division technique de développement (CTI) • Division Réseaux et télécoms (CTI)Références • Non-repudiation in the digital environment, A. Mc Cullagh et W. Caelli, 2003, http: //www.firstmonday.dk/issues/issue5_8/mccullagh/ • ISO/IEC 10181-4 : 1997 : Information technology - Open Systems Interconnection - Security frameworks for open systems : Non-repudiation framework. • ISO/IEC 13888-1 :1997 : Information technology - Security techniques - Non-repudiation - Part 1 : General • ISO/IEC 13888-2 :1998 : Information technology - Security techniques - Non-repudiation - Part 2 : Mechanisms using symmetric techniques • ISO/IEC 13888-3 :1997 : Information technology - Security techniques - Non-repudiation - Part 3 : Mechanisms using asymmetric techniquesObservatoire Technologique 112
  • Référentiel NPT7.2.3 TraçabilitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-11-20 / gpl,pge Version initialeDescriptionLa définition donnée par la norme ISO 8402 pour la traçabilité est : Aptitude à retrouverl’historique, l’utilisation ou la localisation d’un produit ou d’un processus de délivranced’un service au moyen d’identifications enregistrées.Il est crucial pour la sécurité de suivre le parcours des utilisateurs en environnementmulti-applicatif.Les fichiers de log produits par les firewalls, les routeurs et les systèmes fournissent unebase d’analyse qui permet de retracer certains parcours.La traçabilité doit impérativement être respectueuse de la sphère privée des personnes.Cet aspect est notamment lié au cadre légal et au cadre éthique.Couches concernées • Système d’information. Les processus et les données appartiennent à un proprié- taire identifié. La modification du contenu ou le changement de propriétaire est enregistré. Ceci permet de retracer toutes les étapes le cas échéant. • Application. Les applications permettent de stocker les informations pertinentes pour la traçabilité. Les accès au fichiers de log sont sécurisés pour éviter la mo- dification mais aussi pour protéger la sphère privée. • Plateforme supérieure. • Plateforme inférieure. • Matériel.Tiers concernésLa distinction sur les tiers n’est pas pertinente ici.Risques • Des modifications non désirables effectuées sur les données ne peuvent pas être retracées pour modifier les processus nécessaires au bon fonctionnement du sys- tème. • En cas d’intrusion, les données ou applications touchées ne peuvent pas être iden- tifiées et le cas échéant corrigées.Observatoire Technologique 113
  • Référentiel NPTMesures • Les applications permettent-elles de stocker les informations nécessaires à la tra- çabilité ? • Les processus et les données ont-ils des propriétaires et leur modifications sont- elles traçables ? • La sphère privée est-elle respectée dans la mise en œuvre de la traçabilité ?Aspects métierCompétence • Cellule sécurité des systèmes d’information de l’Etat de Genève • Responsable sécurité du CTI • Division technique de développement (CTI) • Division Réseaux et télécoms (CTI)Observatoire Technologique 114
  • Référentiel NPT7.3 ConfidentialitéRévisions Version Date / auteurs Objet de la révision 0.1 2003-11-20 / gpl,pge Version initialeDescriptionLa confidentialité est définie comme la propriété qui assure que l’information n’est pasrendue disponible, ni révélée à des personnes, entités ou processus non autorisés. Ellequalifie d’une manière générale tout moyen visant à ne pas autoriser la diffusion d’uneinformation définie comme sensible (information ayant une valeur ; donnée stratégique ;obligations : légales, contractuelles, déontologiques). La confidentialité d’une donnée oud’un programme est à rapprocher des risques induits par sa divulgation.La notion de confidentialité est liée à une authentification plus ou moins forte selon la sen-sibilité des données échangées. Le chiffrement des données constitue la meilleure mé-thode de sécurisation de la confidentialité des échanges électroniques déployés sur unréseau. Ce chiffrement permet d’une part de rendre une information inintelligible à toutepersonne non autorisée à en prendre connaissance. D’autre part il permet de restituerl’information dans son état initial à l’attention des personnes autorisées (déchiffrement).On citera par exemple les protocoles SSL (Secure Sockets Layer ) et TLS (TransportLayer Security Standard).Couches concernées • Système d’information. Au niveau du système d’information, la confidentialité de l’information sensible doit être prévue comme une partie intégrante des règles du système. Dans cette couche on mesurera donc la capacité de la technologie ou du composant informatique étudiés à s’y conformer. • Application. Dans cette couche on va mesurer la qualité de la prise en compte de la confidentialité en fonction de la sensibilité des informations transitant à travers le réseau. Les standards de chiffrement du CTI doivent pouvoir être pris en compte. • Plateforme supérieure. • Plateforme inférieure. Dans cette couche on se préoccupera de la capacité du sys- tème d’exploitation à chiffrer des fichiers ou des répertoires dans les cas où des données sensibles sont concernées. • Matériel.La distinction sur les tiers n’est pas pertinente ici.Observatoire Technologique 115
  • Référentiel NPTRisques • L’impossibilité de garantir un niveau de confidentialité suffisant peut, suivant le de- gré de sensibilité des informations concernées, amener à une perte de confiance des utilisateurs et à un rejet de la solution envisagée. • Les technologies ou les composants informatiques mis en œuvre dans le cadre de services en ligne traitant des données personnelles ou sensibles doivent impérati- vement pouvoir intégrer la notion de confidentialité au risque d’être rejetés par les citoyens.Mesures • La technologie ou le composant informatique étudiés garantissent-ils une confiden- tialité suffisante de l’information ? • Les applications requièrent-elles un chiffrement des données en transit à travers le réseau ? • Le système d’exploitation est-il capable de chiffrer des fichiers ou des répertoires ?Aspects métierCompétence • Cellule sécurité des systèmes d’information de l’Etat de Genève • Responsable sécurité du CTI • Division technique de développement (CTI)DiversLa notion de confidentialité prend une importance toute particulière lorsque l’on désireaccéder au système informatique de l’Etat depuis l’extérieur de celui-ci.Observatoire Technologique 116