Le Référentiel Nouvelles Plateformes Technologiques

1,238 views
1,091 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,238
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
39
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Le Référentiel Nouvelles Plateformes Technologiques

  1. 1. Le Référentiel Nouvelles Plateformes Technologiques Observatoire Technologique Centre des Technologies de l’Information République et Canton de Genève Version 0.9 16 novembre 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
  2. 2. 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
  3. 3. 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
  4. 4. Référentiel NPT 3.3.5 Tiers ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Troisième axe : les dimensions du système . . . . . . . . . . . . . . . . . . 19 3.4.1 Organisation en ensembles, dimensions et sous-dimensions . . . . 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
  5. 5. 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
  6. 6. Première partieIntroduction au Référentiel NPT 4
  7. 7. 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
  8. 8. 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
  9. 9. Référentiel NPT • à la Direction Générale du CTI ; • aux membres du comité de pilotage du projet NPT ; • au CAT ; • aux divisions du CTI (maîtrises d’œuvre).Dans un deuxième temps, il s’adresse également : • aux Départements de l’État de Genève (maîtrises d’ouvrage) ; • aux partenaires externes de l’État de Genève.Observatoire Technologique 7
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. Référentiel NPT • Les dépendances plus ou moins grandes entre les composants du système. Cette analyse permet par exemple de mettre en évidence des relations de dépendance vis à vis de certains fournisseurs. • La manière dont les divisions et les groupes du CTI se partagent l’expertise et la responsabilité par rapport à des parties du système informatique.Deuxième utilisation : Description et évaluation d’une application mé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
  14. 14. Référentiel NPT que la solution est indépendante par rapport aux couches basses (il est donc pos- sible de remplacer l’OS et le matériel) et par rapport au tiers ressources (il est donc possible de remplace la base de données). 3. Chaque solution est ensuite évaluée en regard des dimensions définie dans le ré- férentiel. En général, chaque dimension est évaluée par rapport à chaque couche et à chaque tiers. Il arrive néanmoins qu’une dimension ne soit applicable qu’à un sous-ensemble de la structure.Troisième utilisation : Description et évaluation d’une technologie ou d’un 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
  15. 15. Référentiel NPT F IG . 2.2 – Capture d’écran du logiciel Web-HIPRE.Observatoire Technologique 13
  16. 16. 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
  17. 17. Référentiel NPT F IG . 3.1 – Représentation d’un système en couches, en tiers et en dimensions.3.2 Premier axe : les couches du systè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
  18. 18. 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
  19. 19. 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
  20. 20. Référentiel NPT tiers de données, qui prend en charge le stockage des informations. Il faut relever que la documentation du Framework CTI fait référence à une architecture 3-tiers. • l’architecture 5-tiers, qui est particulièrement adapté à des applications Web et multi-canaux. Cette architecture est une extension de la précédente et intègre les tiers suivants : (1) le tiers client, (2) le tiers de présentation, (3) le tiers métier, (4) le tiers intégration et (5) le tiers ressources. Le référentiel NPT est conçu sur la base de ce modèle. Les tiers sont donc décrits en détails en les paragraphes suivants.La communication entre les tiers se fait également au travers d’interfaces. Idéalement,les composants déployés dans un tiers ne devraient communiquer qu’avec le tiers voisin.Par exemple (dans une architecture 3-tiers), un composant du tiers de présentation 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
  21. 21. 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
  22. 22. Référentiel NPT • sur le troisième niveau, chaque dimension est elle-même décomposée en sous- dimensions (si nécessaire).Le tableau suivant présente les ensembles, les dimensions et les sous-dimensions 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
  23. 23. Deuxième partieLe Référentiel NPT 21
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. Référentiel NPT • La réponse au problème posé est-elle nécessairement d’ordre technique ou tech- nologique ? • Une réorganistion ou une refonte des processus ne répondent-elles pas mieux au problème posé ?Aspects métierCompétence • Maîtrise d’ouvrage • Maîtrise d’oeuvre • Commission de Gestion du Portefeuille des Projets (CGPP)Observatoire Technologique 25
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. Référentiel NPT • Plateforme supérieure. Idem couche Application. • Plateforme inférieure. C’est au niveau de l’interface graphique du système d’exploi- tation que l’on va juger principalement de l’ergonomie de ce dernier. • Matériel. Dans cette couche, on s’intéresse à l’ergonomie du matériel en contact avec l’utilisateur (PC, périphériques, bornes interactives, etc.).Tiers concernés • Client. La notion d’ergonomie n’est pertinente qu’au niveau des tiers client et pré- sentation. Dans le tiers client, ce sont les interfaces utilisateurs des applications qui sont principalement concernés. La mise en place d’une charte graphique (en- semble de contraintes stylistiques et visuelles de l’interface) devrait être envisagée à ce niveau. • Présentation. Idem tiers client.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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. Référentiel NPT 2. La technologie ou le composant informatique considérés peuvent-ils être paramé- trés et configurés de manière à prendre en compte et à maîtriser correctement les aspects liés au respect du cadre éthique ? 3. Les conditions de travail des fournisseurs et/ou des sous-traitants répondent-elles à des critères de durabilité et d’éthique tel que recommandé dans l’Agenda21 du Canton de Genève ?Aspects mé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
  47. 47. 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
  48. 48. 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
  49. 49. Référentiel NPT • Plateforme supérieure. Les technologies mises en oeuvre dans cette couche sont susceptibles d’augmenter le degré d’évolutivité du système global. Ceci est pos- sible car la couche favorise l’intégration de systèmes hétérogènes, l’échange de messages entre ces systèmes, et la réutilisation de composants et services. • Plateforme inférieure. L’évolutivité du système d’exploitation doit être considérée dans la mesure où des dépendances fortes existent entre les couches Plateforme supérieure/Application et la couche système d’exploitation. Idéalement, une évolu- tion du système d’exploitation ne devrait pas avoir d’impact négatif sur les applica- tions, mais ce n’est pas toujours le cas. • Matériel. L’évolutivité d’un élément matériel est liée à sa capacité à devenir plus puissante après l’ajout de ressources supplémentaires (CPU, mémoire, etc).Tiers concernés • Client. Dans ce tiers, on s’intéresse à la capacité d’une application à évoluer au niveau de l’interface utilisateur. Il est important que cette évolutivité soit possible sans avoir d’impact sur les composants des autres tiers (le découplage des tiers est un objectif de l’architecture multi-tiers). • Présentation. Idem tiers Client. • Métier. L’évolutivité dans ce tiers est cruciale, puisqu’elle décrit la capacité de l’ap- plication à s’adapter au changement des règles métiers. Idéalement, le changement de règles métiers ne devrait pas nécessiter de codage, mais uniquement une para- métrisation de l’applicatif. • Intégration. La couche intégration joue un rôle important dans l’évolutivité d’un sys- tème, surtout si on considère les aspects tels que la performance, la montée en charge, la sécurité, la facilité de gestion. En effet, en faisant évoluer la qualité de service, il est possible que des composants dans la couche ressources doivent être remplacés (p.ex. remplacer la base de données). Faire en sorte que cette évolution soit possible sans affecter les couches amont (client, présentation, métier) est le rôle de la couche intégration. • Ressources. Comme expliqué dans le paragraphe précédent, l’évolutivité des com- posants dans la couche ressources est souvent associée à l’augmentation de la qualité de service désirée. Il faut noter que l’évolutivité au niveau fonctionnel est également souhaitable.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
  50. 50. 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
  51. 51. 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

×