SlideShare une entreprise Scribd logo
Le Référentiel e-Société

                                   Observatoire Technologique
                             Centre des Technologies de l’Information
                                République et Canton de Genève


                                             Version 0.9
                                           15 novembre 2002




Observatoire Technologique
Centre des technologies de l’information
République et Canton de Genève
78–82 route des Acacias
CP 149, 1211 Genève 8
Suisse
http://www.geneve.ch/ot/
ot@etat.ge.ch
Copyright c 2002–2004 CTI, Observatoire Technologique.

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

You are free:

    • to copy, distribute, display, and perform the work
    • to make derivative works

Under the following conditions:

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

    • For any reuse or distribution, you must make clear to others the license terms of this work.
    • Any of these conditions can be waived if you get permission from the author.

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

This is a human-readable summary of the Legal Code (the full license http://creativecommons.org/
licenses/by-nc-sa/2.0/legalcode).
Table des matières

I Introduction                                                                              4


II Référentiel e-Société                                                                  10

1 Projet                                                                                   11
  1.1 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       1.1.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  1.2 Efficacité économique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
       1.2.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
       1.2.2 Eléments de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  1.3 Impact sur la complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
       1.3.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       1.3.2 Identification, localisation, cohérence      . . . . . . . . . . . . . . . . . 24
  1.4 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
       1.4.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
       1.4.2 Orientation objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
       1.4.3 Ouverture des bases de données          . . . . . . . . . . . . . . . . . . . 30
       1.4.4 Qualification technique       . . . . . . . . . . . . . . . . . . . . . . . . . 31
       1.4.5 Réutilisation des applications . . . . . . . . . . . . . . . . . . . . . . 32
       1.4.6 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . 34
       1.4.7 Technologie de développement . . . . . . . . . . . . . . . . . . . . . 36
       1.4.8 Architecture applications . . . . . . . . . . . . . . . . . . . . . . . . . 37
       1.4.9 Standardisation des communication . . . . . . . . . . . . . . . . . . 38
  1.5 Politique d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
       1.5.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
       1.5.2 Acteurs, rôles et types d’échanges . . . . . . . . . . . . . . . . . . . 41


                                             1
Référentiel e-Société




2 Administration                                                                            46
   2.1 Gestion de la connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
         2.1.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
   2.2 Transversalité des processus . . . . . . . . . . . . . . . . . . . . . . . . . . 51
         2.2.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
         2.2.2 Degrés de transversalité (au niveau des processus) . . . . . . . . . 53
   2.3 Transversalité des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
         2.3.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
         2.3.2 Cadres légal, éthique et sociétal . . . . . . . . . . . . . . . . . . . . 57
         2.3.3 Organisation du système d’information . . . . . . . . . . . . . . . . . 58
         2.3.4 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
         2.3.5 Schémas et format de données . . . . . . . . . . . . . . . . . . . . . 58
         2.3.6 Métadonnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
   2.4 Interopérabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
         2.4.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
         2.4.2 Niveaux d’interopérabilité . . . . . . . . . . . . . . . . . . . . . . . . 63
         2.4.3 Respect du principe d’organisation (POCA) . . . . . . . . . . . . . . 66
         2.4.4 Registre des processus cyber-administratifs . . . . . . . . . . . . . . 68
         2.4.5 Classification des éléments d’information . . . . . . . . . . . . . . . 69
         2.4.6 Respect du modèle de communication . . . . . . . . . . . . . . . . . 69
         2.4.7 Signalisation des informations privées sensibles . . . . . . . . . . . 69
         2.4.8 Registres des personnes et des rôles . . . . . . . . . . . . . . . . . 70
   2.5 Service d’information et processus cyber-administratif . . . . . . . . . . . . 72
         2.5.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
         2.5.2 Exemple : accréditation de fournisseurs de l’Etat . . . . . . . . . . . 75
         2.5.3 Contextualisation dans le Référentiel . . . . . . . . . . . . . . . . . . 76

3 e-Société                                                                                 78
   3.1 Impact sur la cyber-inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 80
         3.1.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
         3.1.2 Attentes des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 83
         3.1.3 Accessibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
         3.1.4 Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


Observatoire Technologique                                                                    2
Référentiel e-Société




         3.1.5 Formation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 91
   3.2 Respect du cadre éthique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
         3.2.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
   3.3 Concept d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
         3.3.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
   3.4 Respect du cadre légal       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
         3.4.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
   3.5 Composante sociétale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
         3.5.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102




Observatoire Technologique                                                                     3
Première partie

Introduction




       4
Référentiel e-Société




Contexte

Faciliter et étendre l’accès du citoyen aux services de l’administration publique ; réduire
le cloisonnement entre services et les rendre plus transversaux ; réduire ainsi les coûts
et augmenter la cohérence des processus administratifs partout où les partenaires d’une
action commune doivent intervenir directement ; ce sont là quelques uns des thèmes que
tous les acteurs de la scène administrative publique cherchent à développer au travers de
la mise en place de la cyber-administration. Comme illustré par le schéma de la figure 1,
la cyber-administration recouvre une large problématique car elle concerne différentes
instances au niveau des administrations (Confédération, cantons et communes) tout en
reposant sur des échanges avec les différents acteurs que sont les citoyens, les entre-
prises et les institutions (économiques, culturelles, sociales, etc.).




     F IG . 1 – Niveaux de communication dans la cyber-administration selon l’USIC.


Pour suivre la terminologie utilisée par la Confédération on parle de relations :
– G-I : Government internal. Relations au sein de l’Etat (exécutif, législatif et administra-
  tion), au niveau de la Confédération, d’un canton ou d’une commune.
– G2G : Government to Government. Relations entre la Confédération, les cantons et
  les communes ainsi que celles qui sont établies avec les gouvernements étrangers et
  les organisations internationales.
– G2O : Government to Organisation. Relations que tissent la Confédération, les cantons
  et les communes avec les partenaires de l’économie privée et les organisations de droit
  public.
– G2C : Government to Citizen. Relations que les instances étatiques entretiennent avec
  le citoyen.
La cyber-administration présente une complexité qui ne caractérisait pas la plupart des


Observatoire Technologique                                                                   5
Référentiel e-Société




projets informatiques mis en place jusqu’ici à l’Etat de Genève. Cette complexité découle
de plusieurs facteurs. Le premier est que par essence la cyber-administration va influen-
cer fortement les structures transversales de l’administration. Le second est qu’elle dé-
passe largement le cadre purement technologique en raison notamment du rapport très
fort qu’elle entretient avec le citoyen en particulier et avec la société en général. Et le
troisième est que ses spécificités ne sont encore pas toutes définies. Pour toutes ces rai-
sons, il sera difficile voir impossible d’appréhender les objets de type cyber-administratifs
d’un seul bloc.
Dans cette optique, et avant que ne commence un développement d’envergure de la
cyber-administration à Genève, les responsables de la stratégie informatique de l’Etat de
Genève ont considéré qu’il serait utile d’approfondir la signification et l’impact de ces ca-
ractéristiques dans une approche holistique. C’est notamment cette démarche globale et
abstraite engageant des réflexions dans le domaine très large de la société électronique
qui nous a suggéré la dénomination “Référentiel e-Société”.
L’étude, réalisée par l’Observatoire Technologique (OT) du Centre des Technologies de
l’Information (CTI) entre septembre 2001 et juin 2002, constitue la base d’un Référen-
tiel de la cyber-administration, c’est à dire d’un instrument permettant d’identifier et de
mesurer les impacts de projets individuels sur l’objectif de modernisation et d’ouverture
de l’administration genevoise grâce aux Nouvelles Technologies de l’Information (NTIC).
Le référentiel fournit une quinzaine de dimensions individuelles et décrit la manière d’ap-
pliquer chacune d’entre elles à un projet (ou plus généralement à tout objet baignant
dans le contexte de la cyber-administration). Il fournit les instruments d’aide à la décision
et d’alignement de projets qui permettent de les insérer dans une stratégie générale et
de les placer sur une toile qui se transformera en un tableau cohérent. Sa conception
flexible permet d’adapter les démarches à l’évolution de l’environnement, de l’adminis-
tration et des besoins de la société genevoise. Grâce à la gestion de la connaissance et
des expériences, il garantit également une pérennité des acquis et une continuité dans
les développements futurs.
Le Référentiel e-Société présenté ici fournit les fondements solides à partir desquels il
sera possible de décliner en termes de concepts, d’architectures, puis de réalisations
individuelles, la volonté politique exprimée par le Grand conseil de lancer des projets de
cyber-administration dans le canton de Genève.



Guide d’utilisation

Le Référentiel se présente comme une collection de quinze dimensions constituant une
grille de lecture qui doit permettre à l’utilisateur d’appréhender et de mesurer la com-
plexité des objets de type cyber-administratifs qui lui sont soumis. Le nombre de ces
dimensions découle de leur nature même : une quantité suffisamment importante pour
prendre en compte les aspects essentiels des objets à étudier mais aussi suffisamment
restreinte pour ne pas se perdre dans la complexité de ces objets.
Les quinze dimensions ont été regroupées a posteriori en trois groupes de cinq dimen-
sions touchant plus particulièrement :
– Aux projets de type cyber-administratifs,
– A l’administration dans son ensemble,


Observatoire Technologique                                                                   6
Référentiel e-Société




– Et de façon beaucoup plus large, à l’e-Société.
Deux d’entre elles, en raison de leur ampleur, ont été déclinées en sous-dimensions. Ces
quinze dimensions sont schématisées dans la figure 2.




                       F IG . 2 – Dimensions du Référentiel e-Société.


En préambule au développement de chaque dimension ou sous-dimension, un tableau
synoptique synthétise 9 de ses caractéristiques importantes au travers des rubriques
suivantes :
  1. Description : brève description de la problématique que recouvre la dimension.
  2. Type d’objets : énumère les différents objets pouvant être jaugés au travers de la
     dimension (un projet informatique, la mise en place d’une nouvelle loi, etc.).
  3. Objets de référence : objet pouvant être mis en évidence en regard de la dimen-
     sion ; soit parce qu’il constitue un standard (même abstrait), soit parce qu’il constitue
     un point d’ancrage fort dans le domaine couvert par la dimension.
  4. Risques : énumération de risques majeurs pouvant affecter l’objet ou plus généra-
     lement la mise en œuvre de la cyber-administration si certaines conditions relatives
     à la dimension ne sont pas remplies.
  5. Mesure : dans l’optique d’utiliser le référentiel comme un outil de mesure des ob-
     jets qui lui sont soumis, notamment dans le cadre d’une aide à la décision, cette
     rubrique propose une mesure propre à chaque dimension. Cette mesure peut être
     qualitative ou quantitative (avec plus ou moins de finesse dans la mesure suivant le
     thème de la dimension).
  6. Aspect métier : décline les spécificités métiers liées à chaque dimension. Cette ru-
     brique s’étoffera au travers des retours d’expérience des projets métiers qui seront
     mis en œuvre.
  7. Niveau d’abstraction : sous-dimensions ou abstractions de la dimension considé-
     rée.

Observatoire Technologique                                                                    7
Référentiel e-Société




  8. Compétence : organe ou structure ayant les compétences requises pour définir la
     mesure à appliquer à la dimension considérée.
  9. Pré-requis : conditions nécessaires devant être présentes pour que l’on puisse
     prendre en compte la dimension considérée.



Scénarios et règles d’application

On peut distinguer sommairement quatre utilisations principales du Référentiel e-Société :
– la première consiste à évaluer l’impact d’un objet venant s’inscrire dans l’e-Société.
  Quelles sont les conséquences, par exemple, de la mise en application d’une nouvelle
  loi sur la protection des données ? Une évaluation de l’impact de cette loi sur cha-
  cune des dimensions permet d’obtenir une image globale du nouveau paysage de la
  cyber-administration qui en résulte. Dans ce cas de figure, cette nouvelle loi devrait
  naturellement être prise en compte par la suite dans le Référentiel.
– la deuxième consiste à utiliser le Référentiel pour mesurer, sur chaque dimension,
  l’écart entre un projet informatique et une situation idéale correspondant par exemple
  à une référence sur chacune des dimensions. Cette démarche permet d’utiliser le Ré-
  férentiel comme un outil de correction (voire d’alignement sur la stratégie de l’Etat)
  pour chaque projet pris indépendamment. Une fois un projet terminé, il devient un élé-
  ment du paysage de la cyber-administration. Il devrait être réintégré dans le référentiel
  en tant que point de repère et éventuellement en tant qu’élément de référence ou de
  standardisation sur une ou plusieurs dimensions.
– la troisième consiste à utiliser le Référentiel pour prioriser (en vue de la réalisation de
  certains d’entre eux) une série de projets informatiques qui lui sont présentés. Cette
  opération peut être mise en œuvre en appliquant une analyse multi-critères prenant
  en compte les poids associés à chaque dimension et, pour chaque objet de l’une ou
  de plusieurs des listes décrites ci-dessus, sa mesure propre pondérée par les poids
  considérés dans ce contexte d’application.
– une dernière utilisation est celle d’un outil de communication. Au travers du Référentiel,
  l’Etat peut communiquer sa stratégie (ou du moins une partie de celle-ci), que ce soit
  à ses fournisseurs, ou plus généralement au grand public.
La société électronique évolue constamment et le Référentiel doit prendre en compte
cette notion afin de rester un outil adapté à l’environnement qu’il prétend analyser. Dans
cette optique la notion de retours d’expériences des utilisateurs du Référentiel est es-
sentielle. Ce sont ces éléments qui, avec le travail de maintenance dévolu à l’OT, sont
garants de la pérennité et de la fiabilité de cet outil.
Le Référentiel e-Société développé par l’Observatoire Technologique du Centre des Tech-
nologies de l’Information de l’Etat de Genève se veut un document ouvert et évolutif. Dans
la première version publique de novembre 2002, nous présentons ce Référentiel qui n’est
encore que dans un état préliminaire. Toutes les dimensions ne sont pas au même niveau
de maturité et de développement. Il s’agit comme mentionné ci-dessus de l’enrichir et de
continuer à le développer de façon à construire des versions ultérieures plus complète et
plus achevées.
Dans cet esprit nous le proposons ici en accès libre sous une licence Creative Com-
mons (http://creativecommons.org/licenses/by-nc-sa/2.0/). Un feedback
sur l’utilisation du référentiel ou des commentaires sont les bienvenus à l’adresse e-mail


Observatoire Technologique                                                                   8
Référentiel e-Société




ot@etat.ge.ch.
Références
Unité de stratégie informatique de la Confédération (USIC), Département fédéral des fi-
nances DFF, L’activité gouvernementale à l’heure de la société de l’information : Stratégie
de la Confédération en matière de cyber-administration (e-government), 13 février 2002,
http://www.isb.admin.ch/egov/




Observatoire Technologique                                                                  9
Deuxième partie

Référentiel e-Société




         10
Chapitre 1

Projet




             11
Référentiel e-Société




Les dimensions suivantes :
– Efficacité économique
– Impact sur la complexité
– Politique d’information
– Sécurité
– Technologie
ont été regroupées sous l’étiquette commune “Projets”. Cela correspond au fait que le
domaine d’application de ces cinq dimensions touche essentiellement aux objets de type
projet cyber-administratif. Cela se comprend aisément pour les dimensions “Impact sur la
complexité” ou “Technologies”. La dimension “Sécurité” est développée à ce niveau car
il nous paraît essentiel de prendre en compte des aspects liés à la sécurité en amont de
tout projet, même si cela présuppose également l’existence d’une politique de sécurité au
niveau de l’Etat de Genève. La dimension “Politique d’information” décrit uniquement la
nécessité d’avoir une bonne politique d’information au niveau de tous les futurs projets de
cyber-administration. La dimension "Efficacité économique” finalement est conçue pour
étudier cette notion au niveau des projets uniquement. D’autres dimensions présentées
plus loin sous l’étiquette “Administration” se situent à la frontière du domaine “Projet”. Il
est clair que cette répartition est à ce niveau relativement arbitraire.




Observatoire Technologique                                                                  12
Référentiel e-Société




1.1    Sécurité

                     Description abrégée
 gpl                 Sécurité
 Description         Les objets liés à la mise en œuvre de la cyber-administration ont des
                     effets sur la sécurité du système d’information de l’Etat, ainsi que sur
                     celle des protagonistes de l’e-Société. L’information étant reconnue
                     comme un bien de valeur et une ressource fondamentale, il convient
                     de la protéger et d’assurer sa disponibilité.
 Types d’objet       Objets dont les instances sont immergés dans un contexte socio-
                     technique (applications, infrastructures, bases d’informations, sys-
                     tèmes d’information).
 Objets de réfé-     Effet positif. Objet construit selon les principes suivants :
 rence               – les bases d’information sont normalisées selon les règles de la
                       protection des données, et construites et gérées en conformité ;
                     – les systèmes d’information sont bâtis de manière à respecter la
                       politique de sécurité ;
                     – les projets traitent la sécurité comme partie intégrante lors de leur
                       conception ;
                     Effet négatif :
                     – le système d’information n’est pas prévu pour limiter la vulnérabi-
                       lité, est conçu avec une seule couche de sécurité et ne minimise
                       pas les éléments et ressources auxquels il peut faire confiance.
                     – les systèmes critiques ne sont pas suffisamment isolés et/ou ne
                       sont pas répliqués pour parer à des défaillances.

 Risques             Le manque de prise en compte des aspects de sécurité dans un
                     objet cyber-administratif peut mettre en péril tout ou une partie du
                     système d’information de l ’Etat.
                     Au niveau de l’e-Société, le risque de la divulgation ou de la modifi-
                     cation indue de d’informations peut affecter gravement les protago-
                     nistes de la cyber-administration. De plus, la confiance mise dans
                     l’Etat et son image de marque sont détériorées, en particulier lors
                     de l’introduction de la cyber-administration.
 Mesures             Non mesurable ordinal. L’effet est :
                     – Négatif, si l’existence ou l’introduction de l’objet a tendance à di-
                        minuer la sécurité du système d’information de l’Etat. Des me-
                        sures afin de contrôler et de maintenir le niveau souhaitable de
                        sécurité doivent être imposées.
                     – Positif, si l’existence ou l’introduction de l’objet dans le contexte
                        global de la cyber-administration ou de l’e-Société tend à mainte-
                        nir ou augmenter la sécurité ou encore faciliter sa mise en œuvre.
                     L’évaluation de la mesure peut prendre en compte différents critères
                     pour un seul objet ou différents critères selon les objets.
 Aspect métier       aucun




Observatoire Technologique                                                                    13
Référentiel e-Société




 Niveaux             aucun
 d’abstraction
 Compétence          Responsables de la sécurité des systèmes d’information ;
                     Ingénieurs et architectes des systèmes d’information.
 Pré-requis          Politique de sécurité définie et acceptée par l’unité responsable,
                     ainsi que par les organes officiels responsables de la sécurité gé-
                     nérale au niveau de l’Etat.


1.1.1   Explications

Une sécurité adéquate de l’information et des systèmes qui l’utilisent est une dimension
fondamentale pour des objets de type cyber-administratif dans un système d’information
complexe comme celui de l’Etat.
Les considérations concernant la sécurité doivent être prises en compte en amont du dé-
veloppement d’un projet. L’inclusion de ces éléments a posteriori devient non seulement
plus difficile, mais aussi souvent beaucoup plus coûteux.
Les protagonistes de la cyber-administration dans l’e-Société sont également touchés
par la sécurité, en particulier lorsque les données protégées les concernent directement.
Le Règlement concernant la protection des applications et des systèmes informatiques
dans l’administration cantonale B 1 15.01 du 5 avril 2000 et entré en vigueur le 13 avril
2000 stipule dans l’article 1 alinéas 1 et 2 :

        1. Lors de la planification, de la réalisation et de l’exploitation d’applications
           et de systèmes informatiques (ci-après : systèmes) dans l’administration
           cantonale, il faut s’assurer que ces applications et ces systèmes sont
           protégés contre les risques qui menacent leur disponibilité, leur intégrité
           et leur confidentialité.
        2. Tous les domaines du traitement des données doivent être protégés, no-
           tamment :
            (a) les lieux (immeubles, locaux, transport de supports de données) ;
            (b) les systèmes (matériels, logiciels, logistique) ;
            (c) l’utilisation des systèmes (exploitation, applications) ;
            (d) les communications (transport de données par câbles, réseaux télé-
                matiques et téléphoniques) ;
            (e) les données personnelles (protection des données) ;
             (f) les données ;
            (g) la documentation.

Il est indispensable de se référer aux documents préparés par le comité sécurité des
systèmes d’information qui sont la référence à ce sujet au sein de l’Etat de Genève.
La dimension sécurité touche en particulier :
– Les utilisateurs qui opèrent sur les systèmes d’information ou qui demandent ou éva-
  luent des réalisations fonctionnelles,

Observatoire Technologique                                                                    14
Référentiel e-Société




– Les ingénieurs système et les architectes système qui projettent, construisent ou
  modifient un système d’information, ceci tout au long des phases du cycle de vie du
  système,
– Les responsables de la sécurité des systèmes qui s’assurent que des mesures de
  sécurité sont prises en compte tout au long des phases du cycle de vie du système.
Quelques domaines de sécurité des systèmes et des réseaux visés sont : le contrôle des
accès et l’identification, l’attribution de privilèges, la maintenance de l’intégrité des fichiers
et du système de fichiers, les sauvegardes, le monitoring des processus, la maintenance
de fichiers de logs, l’audit, la protection des serveurs et des communications informa-
tiques, le contrôle des accès depuis des réseaux externes, la détection des interceptions
et des intrusions.
Il est important de noter que pour que la sécurité soit efficace, il faut considérer non seule-
ment l’implémentation technique, mais aussi les aspects de mise en œuvre politiques et
opérationnels, ainsi que la formation des utilisateurs. La sécurité physique est également
un point crucial, en particulier il faut savoir qui a accès aux locaux contenant des informa-
tions critiques. Si ces services sont trop onéreux pour une mise en application générale,
on peut se limiter aux postes et localisations les plus critiques.
La sécurité de l’information est souvent associée aux caractéristiques suivantes :
– Confidentialité : l’information n’est accessible qu’aux agents autorisés,
– Intégrité : l’information ne peut pas être modifiée (créée, changée ou détruite) par des
  agents non autorisés. La qualité de l’information est assurée.
– Disponibilité : l’information doit être disponible, ce qui implique que le système sous-
  jacent est opérationnel et fonctionnel.
Ces caractéristiques impliquent la mise en œuvre des éléments suivants :
– Identification : faire correspondre à un agent une identité logique.
– Authentification : s’assurer que l’agent est bien qui il prétend être et que les modifi-
  cations d’informations sont attribuables à un agent ; une information peut aussi être
  authentifiée par un agent si son utilisation nécessite une telle garantie,
– Non répudiation : une modification de l’information par un agent ne peut pas être niée,
– Traçabilité : un agent est responsable des modifications effectuées et celles-ci peuvent
  être, le cas échéant, retracées.
On peut distinguer six étapes essentielles afin de mettre en place d’une sécurité de qua-
lité :

  1. Définir une politique et des standards pour la sécurité
  2. Bâtir une architecture et des processus sécurisés
  3. Former et informer les collaborateurs sur la sécurité
  4. Evaluer et déployer des produits et technologies pour la sécurité
  5. Prévoir des audits, un monitoring et des enquêtes sur la sécurité
  6. Valider la sécurité mise en œuvre

Il faut donc identifier :
– Les éléments à protéger et leur valeur (celle de leur reconstruction),
– La probabilité de d’occurrence,

Observatoire Technologique                                                                     15
Référentiel e-Société




– Les coûts de protection.
En particulier, comme on peut le voir dans la figure 1.1, le niveau de sécurité est un
compromis entre le coût de reconstruction de l’information et celui de la mise en œuvre
de la sécurité des systèmes d’information. Il faut ajouter que la perte d’une information
peut également engendrer des conséquences quant à la confiance que les utilisateurs
ont dans le système d’information. Ceci est d’autant plus important si l’application se
tourne vers les des données touchant directement les citoyens.




                     F IG . 1.1 – Compromis entre la sécurité et le coût.




Observatoire Technologique                                                                    16
Référentiel e-Société




1.2    Efficacité économique

                     Description abrégée
 gpl                 Efficacité économique
 Description         Les objets liés à la mise en œuvre de la cyber-administration sont
                     évalués sur la base de leur efficacité économique. Un budget est
                     estimé pour la première année ainsi qu’un coût de fonctionnement
                     pour les années suivantes. Un plan de financement est établi afin
                     de déterminer les sources des fonds. Sur la base des coûts et des
                     bénéfices évalués ainsi que du montant à investir, le pourcentage
                     de retour sur investissement (ROI) est estimé. Le but n’est pas de
                     sélectionner le meilleur retour sur investissement mais de trouver
                     l’alternative la plus rationnelle économiquement.
 Types d’objet       Projets ou investissements envisagés en particulier dans des tech-
                     nologies de l’information et de la communication pour des projets de
                     cyber-administration.
 Objets de réfé-     Projets informatiques décrits d’après le modèle 3a de la CGPP (voir
 rence               plus bas) qui est complété pour tenir compte des bénéfices citoyen
                     et non quantifiables.
 Risques
                     – Le manque de prise en compte des aspects financiers dans un
                       projet cyber-administratif peut conduire à des investissements
                       sous optimaux au point de vue économique.
                     – Les éléments futurs sont parfois 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) ne 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 à dispo-
                       sition de locaux ne sont pas pris en compte ou sous estimés dans
                       l’analyse.

 Mesures             Mesurable en pour-cent (ROI) ou en termes absolus. Pour un ROI,
                     une valeur de 100% indique que les gains escomptés couvrent les
                     dépenses engagées.
                     Les bénéfices non tangibles monétairement sont évalués sur
                     l’échelle -2, -1, 0, +1, +2.
 Aspect métier       aucun
 Niveaux             aucun
 d’abstraction
 Compétence          Responsables budgétaires et financiers. Commission de gestion du
                     portefeuille de projets.
 Pré-requis          aucun



Observatoire Technologique                                                                   17
Référentiel e-Société




1.2.1   Explications

Dans une proposition de projet touchant à la cyber-administration il est important de
connaître le rapport du profit retiré par rapport à l’investissement engagé. Cette fraction
est appelée “retour sur investissement” et permet d’évaluer la pertinence d’attribution
de fonds d’un point de vue purement financier. Il est important de souligner que cette
dimension doit être comprise comme un moyen de mettre en évidence l’alternative la
plus efficace économiquement. Le but n’est pas nécessairement de dégager un profit ou
une diminution de coûts à tout prix par la mise en œuvre d’un objet cyber-administratif.
Le calcul du retour sur investissement se fonde sur les principes d’une analyse coût-
bénéfice (anglais cost-benefit analysis ou CBA). Le but d’une telle approche est d’amé-
liorer les décisions faites en terme d’allocation des ressources financières.
La période de temps sur laquelle porte le calcul correspond au cycle de vie du système
envisagé, 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 changements (statu
quo).
L’identification, la description et l’estimation des bénéfices et coûts doit être faite de la
façon la plus rigoureuse possible. Le niveau de détail de l’analyse dépend de l’objet
examiné : un grand projet, complexe et coûteux sera détaillé plus finement qu’un projet
de 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 évaluant
leur importance sur une décrite plus bas.
Les coûts déjà encourus dans le passé ou les bénéfices déjà réalisés ne doivent
en aucun cas être considérés.
De façon très simplifiée le retour sur investissement est défini pour une période don-
née comme la somme des profits actualisés du projet, c’est-à-dire les revenus moins les
coûts, divisé par les fonds investis dans le projet.
Les étapes d’une analyse coût-bénéfice qui conduira à calcul du retour sur investissement
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 les
     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 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


Observatoire Technologique                                                                 18
Référentiel e-Société




      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.
  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. 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é
     actuellement (juin 2002) à 1.5% en fonction notamment du taux d’intérêt du marché.
 10. 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.
 11. 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 le calcul du retour sur investissement. 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.




Observatoire Technologique                                                                19
Référentiel e-Société




1.2.2   Eléments de calcul

A l’aide des données du tableau 7 repris de la procédure CGPP (commission de gestion
du portefeuille de projets) ci-dessous et de la formule donnée au point 9 plus haut, calcu-
ler les bénéfices et les coûts annuels actualisés. Ceux-ci permettent de calculer le retour
sur investissement du projet considéré.

           Tableau du retour sur investissement
           (A) Bénéfices annuels actualisés
           (B) Coûts annuels actualisés
           Rapport bébéfices/coûts = A/B
           Retour sur investissement = (A-B)/Fonds        %
           demandés × 100
           Bénéfices non quantifiables

Dans les éléments bugétés pour les différentes alternatives il faut égalament tenir compte
des frais de formation des collaborateurs(-trices) et des locaux qui seront occupés s’ils
ne travaillent pas dans l’organisation.

           Tableau 7 CGPP — Synthèse des coûts et retour sur investissement
     Exercice :                    2002    2003    2004       2005   2006   2007     Total
     Coût du projet :
     Financement par la Confé-
     dération :
     Financement par d’autres
     partenaires publics :
     Financement privé :
     Coût net pour l’Etat :
     Coût de fonctionnement :
     Coût total :
     Recettes prévues (nou-
     velles/supplémentaires) :
     Economies prévues, ré-
     duction de charge :
     Dépenses évitées :
     Bénéfice citoyen :
     Total des économies :
     Bilan annuel :
     Bilan cumulé :

Bénéfice citoyen : décrire et quantifier la valeur annuelle estimée du projet pour les
citoyens. Ceci inclut la diminution des frais liés aux activités avec l’Etat de nature privée
ou professionnelle. Par exemple, les frais de transport, la diminution des temps d’attente,
la prise de temps sur l’activité professionnelle, l’affranchissement, etc.

Observatoire Technologique                                                                    20
Référentiel e-Société




Bénéfices non tangibles : décrire les bénéfices liés au projet qui ne peuvent pas être
chiffrés monétairement dans les rubriques précédentes. Evaluer l’importance de chacun
de ces bénéfices sur l’échelle -2, -1, 0, +1, +2.


                             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




Observatoire Technologique                                                              21
Référentiel e-Société




1.3    Impact sur la complexité

                     Description abrégée
 sdz                 Impact sur la complexité
 Description         Tout objet ayant un impact direct ou indirect sur la cyber-
                     administration ou l’e-Société peut avoir un impact sur la complexité
                     globale. Cet impact sur la complexité doit être mesuré.
                     S’il est négatif, l’existence ou l’introduction de l’objet a tendance à
                     augmenter la complexité globale. Ceci implique la recherche active
                     de mesures de correction ou de confinement.
                     S’il est positif, l’existence ou l’introduction de l’objet dans le contexte
                     global de la cyber-administration ou de l’e-Société tend à réduire
                     la complexité globale, Il doit alors être activement poursuivi et cette
                     caractéristique doit être prise en compte dans la priorisation des
                     projets.
 Types d’objet       aucun
 Objets de réfé-     (A) Impact positif. Application construite selon les principes sui-
 rence               vants :
                     – les bases d’information sont normalisées selon les règles de la
                        protection des données, et construites et gérées en conformité ;
                     – les systèmes d’information sont bâtis de manière à respecter la
                        politique de sécurité ;
                     – l’ensemble des objets techniques respectent des standards ou-
                        verts là où ils existent pour les caractéristiques des composants
                        du système considéré.
                     (A) Impact positif. Standard technique ouvert
                     (A) Impact négatif. “Legacy system” dont les drivers sont historiques
                     et politiques plutôt que techniques.
                     (B) Objet de type “Corps de métier”, corporation.
                     Point de référence pour un impact positif : corps de métier qui est or-
                     ganisé avec des organes représentatifs ou des partenaires attitrés
                     pouvant conduire de manière autorisée un dialogue avec le projet
                     Cyber@dmin. Exemple : chambre de commerce de l’industrie. As-
                     sociation des avocats. Société d’ingénieurs.
                     Point de référence pour un impact négatif : corps de métier pour
                     lequel il n’existe pas d’organe représentatif.
                     (B) Objet de type “Fournisseur de prestations de l’Etat”.
                     Point de référence pour un impact positif : entreprise ayant conclu
                     une convention avec un organe compétent de l’Etat qui engage les
                     partenaires de la convention à travailler ensemble à la réalisation
                     de leurs objectifs respectifs dans le but d’une collaboration à long
                     terme.
                     (B) Impact potentiellement négatif : objet de type “Unité administra-
                     tive” dont les processus sont normalisés par un acteur externe ou
                     indépendant (p. ex. Office fédéral).




Observatoire Technologique                                                                      22
Référentiel e-Société




 Risques             Les risques liés à la complexité sont de deux ordres :
                     – le projet de réalisation d’un nouvel objet ayant un impact négatif
                       sur la complexité est difficile à conduire, à intégrer et à mener à
                       son succès ;
                     – la réalisation d’un objet ayant un impact négatif sur la complexité
                       change les conditions cadre de toutes les réalisations en cours
                       ou futures. Par exemple, un projet de loi imposant de nouvelles
                       mesures contraignantes sur la gestion de l’information dans l’ad-
                       ministration.

 Mesures             Impact positif, neutre, négatif.
                     L’évaluation de la mesure peut prendre en compte différents critères
                     pour un seul objet ou différents critères selon les objets.
 Aspect métier       Il est important d’évaluer la complexité inhérente du métier (ou des
                     aspects du métier) dans lequel un objet s’insère, ainsi que le de-
                     gré d’imbrication du système d’information sous-jacent avec d’autres
                     métiers.
 Niveaux             Premier niveau d’abstraction : ensemble des objets, tous types
 d’abstraction       confondus.
                     Second niveau d’abstraction :
                     (A) objets dont les instances sont immergés dans un contexte socio-
                     technique (applications, infrastructures, bases d’informations, sys-
                     tèmes d’information) ;
                     (B) objets dont les instances sont issues d’un contexte socio-
                     politique (organisations ou assoications, organes de l’Etat, lois et
                     directives, processus, acteurs de la société).
 Compétence          (A) unité responsable administrativement de l’instance d’objet sou-
                     mis à la mesure.
                     (B) organe responsable politiquement de l’instance d’objet soumis à
                     la mesure.
 Pré-requis          (A) la responsabilité administrative doit être univoque. Ceci peut im-
                     pliquer une délégation de la compétence organisationnelle de la part
                     des autres acteurs qui emploient l’instance considérée.
                     (A) en matière de sécurité, les contraintes énoncées doivent être in-
                     tégrées dans une politique de sécurité définie et acceptée par l’unité
                     responsable, ainsi que par les organes officiels responsables de la
                     sécurité générale au niveau de l’Etat.


1.3.1   Explications

Dans une administration publique, tout système d’information a (ou devrait avoir) au
moins deux caractéristiques : (I) il est intégré à un environnement socio-technique (ceci
s’applique à tout système d’informations) ; et (II) l’ensemble minimal des contraintes qui
le définissent est issu d’un ensemble de directives et d’ordonnances que l’on doit pouvoir
tracer directement au cadre légal en vigueur.
A ceci s’ajoute une troisième caractéristique dont la portée varie selon le système, à


Observatoire Technologique                                                                  23
Référentiel e-Société




savoir, (III) le métier auquel s’applique le système d’informations (santé, instruction pu-
blique, sécurité, fiscalité, gestion du territoire, etc.).
Les caractéristiques (II) et (III) définissent la complexité intrinsèque, ou la complexité
inhérente non réductible, du système d’information considéré.
A cette complexité s’ajoutent encore la complexité due à l’organisation des processus
que supporte dans l’administration le système d’information considéré (par exemple la
séparation des pouvoirs ou l’organisation des processus administratifs selon un orga-
nigramme plus ou moins arbitraire issu de considérations politiques générales ou de
politique interne de l’administration), ainsi que la complexité due aux méthodes et à la
technologie employée pour mettre en œuvre le système et respecter ses contraintes
non-fonctionnelles.
Comme dans toute entreprise humaine, la contribution personnelle des concepteurs et
des réalisateurs ajoute, à travers leur vision, leurs compétences, leur volonté, leur entente
et leur discipline, une touche finale à la complexité du système d’information.
La cyber-administration agit sur l’organisation et la vision. L’impact sur la complexité d’un
objet cyber-administratif doit donc être mesuré en relation avec ces deux éléments. Ceci
définit une dimension du Référentiel de la cyber-administration.
D’autres dimensions mesurent l’impact sur la complexité de la technologie (qui peut être
réduit par un effort de standardisation) ; des compétences et de la volonté (qui concernent
la politique d’information) ; de la discipline (mesures relatives à la qualité, en particulier
au niveau des concepts d’information).


1.3.2   Identification, localisation, cohérence

Avant de pouvoir appliquer une mesure, conformément à une dimension, il faut identifier
le sujet (objet ou projet) que l’on désire mesurer.
Il peut s’agir : d’un système d’information, d’une application ou d’un registre de données ;
d’une loi ou d’une directive ; d’une organisation, d’un organe ou d’un groupe de per-
sonnes ; d’une infrastructure ou d’une architecture ; etc. De plus, il faut (faudra) identifier
les responsabilités liées au sujet et évaluer les aptitudes existantes (organisation, qualifi-
cation, connaissances, maîtrise, etc.) à résoudre les problèmes primaires et secondaires
qui sont liés à l’environnement du sujet. Ces informations sont des données qualitatives
objectives.
En outre, il faut pouvoir localiser le sujet en termes de temps/énergie et de flexibilité, c’est
à dire d’un côté savoir où il se trouve dans son cycle de vie (existant vivant, existant en
fin de vie, projet sans dotation, projet doté de ressources) ; et savoir dans quelle me-
sure il s’appuie sur un besoin justifié et/ou sur une volonté politique ayant le pouvoir de
s’imposer. Ces informations sont des données quantitatives objectives.
Finalement, il faut mesurer la cohérence de son environnement et la contribution du sujet
à cette cohérence, en termes de distance relative et de corrélations avec d’autres sujets
du même type dans le même environnement. Ces données peuvent être subjectives.
La figure 1.2 décrit le positionnement sur un cadran mettant en rapport la distance et les
corrélations.


Observatoire Technologique                                                                    24
Référentiel e-Société




                         F IG . 1.2 – Cadran Distance / Corrélations.


Une fois le sujet identifié et localisé, considérons comme dimension l’impact de d’un objet
correspondant sur la complexité. Le sujet peut être complexe de manière inhérente. Ceci
aura un impact local et limité sur la complexité globale, dans la mesure où la complexité
globale dépend d’une part de la contribution du sujet à la cohérence globale, d’autre part
et si la cohérence est élevée, de la faculté de l’objet à partager ses propriétés avec, et à
recycler ses propriétés envers, d’autres sujets de son environnement.
Ces deux propriétés (partage et recyclage) n’ont pas forcément de contribution à la com-
plexité inhérente du sujet, et inversement. On peut donc définir l’impact sur la complexité
comme la position du sujet dans le cadran de la figure 1.3.




                             F IG . 1.3 – Cadran Recyclage / Partage.


Etant bien entendu que la réduction de la complexité est une priorité absolue dans tout
développement technique de grande envergure.



Observatoire Technologique                                                                 25
Référentiel e-Société




1.4     Technologies

                     Description abrégée
                     Technologies
 Description
 Types d’objet       Voir sous-dimensions
 Objets de réfé-     Voir sous-dimensions
 rence
 Risques             Voir sous-dimensions
 Mesures             Maturité, Intégration, Appropriation et compétences, Développe-
                     ment des applications, Standards et méthodologies.
 Aspect métier       Voir sous-dimensions
 Niveaux             Orientation objet, Ouverture des base de données, Qualifica-
 d’abstraction       tion technique, Réutilisation/intégration des applications existantes,
                     Méthodologie de développement, Technologie de développement,
                     Standardisation architecture application (n-tiers), Standardisation
                     communication informatique.
 Compétence          Voir sous-dimensions
 Pré-requis          Voir sous-dimensions


1.4.1   Explications

L’administration dispose d’un patrimoine d’applications et d’infrastructures informatiques
nombreuses, les unes récentes, les autres plus anciennes. Ce patrimoine, stratégique
quant aux activités de l’administration, a une valeur économique considérable. Il a été
bâti progressivement en s’appuyant sur des technologies hétérogènes, développées pour
des besoins spécifiques, à des périodes et par des équipes différentes. Cela a conduit au
système d’information actuel, constitué de différentes strates logicielles et architecturales
avec des îlots métiers qui ne sont pas toujours capables de communiquer.
Ce système d’information est inéluctablement amené à évoluer de part les modifications
des technologies, des métiers de l’informatique et de l’environnement socio-économique.
La mise en œuvre de la cyber-administration sera l’un de ces facteurs d’évolution. Pour
des raisons de continuité, de coût, de temps et de complexité, il n’est toutefois pas en-
visageable de rebâtir dans son ensemble le système d’information et de repartir sur des
bases neuves et cohérentes. Il faut donc impérativement s’accommoder de cette hétéro-
généité de façon durable et réaliser une intégration des différents composants présents
et à venir sans toucher au coeur du dispositif métier de chacun d’eux.
Le développement de la cyber-administration imposera de plus en plus le besoin de faire
communiquer un grand nombre d’applications entre elles et donc de réaliser une intégra-
tion des différentes briques logicielles et matérielles existantes. Mais le choix d’une tech-
nologie dépasse largement ces considérations purement techniques, même si ces der-
nières sont souvent essentielles. D’autres problématiques doivent être prises en compte
dont nous livrons ici quelques idées force qui ne constituent que des pistes de réflexion.
Elles font l’objet de l’étude que mène actuellement l’OT dans ce domaine et seront incor-


Observatoire Technologique                                                                  26
Référentiel e-Société




porées au Référentiel e-Société au fur et à mesure de leur complétude. Ces probléma-
tiques sont les suivantes :

  1. Maturité. La prise en compte du niveau de maturité d’une technologie est un fac-
     teur de choix important. Jean-Michel Cornu dans son essai sur les technologies de
     demain décrit l’influence du degré de maturité sur la stratégie à aborder :
           “Les jeunes technologies innovantes sont imprévisibles, on ne peut que
           favoriser leur abondance. Les technologies en plein essor passent par
           des degrés d’ouverture variés. L’important est de savoir les situer. Si le
           passage d’une étape à l’autre est souvent imprévisible, on peut cepen-
           dant définir des stratégies pour chacune d’elles. Les technologies ma-
           tures présentent une évolution plus prévisible qui permet d’anticiper jus-
           qu’à un certain point des seuils d’usages.”
     Le degré de maturité est étroitement liée à la notion de cycle de vie. La connais-
     sance du cycle de vie d’une technologie permet de prendre en compte certains
     paramètres qui peuvent se révéler critiques lors du choix de celle-ci : niveau d’adop-
     tion, seuils d’usage, obsolescence, etc.
  2. Intégration. Comme mentionné dans le préambule, l’intégration des briques logi-
     cielles et matérielles au sein d’un système d’information est un aspect essentiel
     d’une technologie, spécialement lorsque celle-ci est amenée à jouer un rôle trans-
     versal au sein du système. Quel est le degré d’intégration de la technologie envisa-
     gée avec celles déjà mises en oeuvre ? Cette technologie pourra-t-elle bénéficier à
     d’autres projets ? Quelles possibilités d’ouverture offre-t-elle ? Est-elle sensible aux
     facteurs d’échelle ? Les réponses à toutes ces questions devraient être prises en
     compte lors de toute réflexion préalable.
  3. Appropriation et compétences. Le déploiement d’une technologie passe natu-
     rellement par la prise en compte des problématiques liées aux personnes respon-
     sables de leur mise en œuvre et de leur maintenance. Les questions qui sont rela-
     tives à ces problématiques sont à prendre en compte dans tous les cas :
     – Quelles sont les compétences disponibles en interne pour cette technologie ?
     – Une formation du personnel de développement et/ou d’exploitation est-elle né-
        cessaire ?
     – Risque-t-on d’être confrontés à la réticence de ce même personnel à changer
        ses habitudes en cas d’adoption d’une nouvelle technologie ?
     Toutes ces problématiques méritent d’être exposées plus en détails. Mais nous
     n’avons pour l’instant développé dans le Référentiel e-Société que celles touchant
     au développement de projets informatiques, aux standards et aux méthodologies :
  4. Développement des applications. De part la nature très transversale de la cyber-
     administration, le développement d’applications, notamment au niveau des briques
     de base pourra dans bien des cas réutiliser les composants développés. Les projets
     de développement doivent donc obéir à un certains nombre de critères permettant
     une réutilisation optimale de ces composants.
  5. Standards et méthodologies. Une condition essentielle pour la mise en place
     de la cyber-administration est une prise en compte de la transversalité au niveau
     des données et des processus (voir dimensions “transversalité des données” et
     “transversalité des processus”). Il y a deux démarches possibles pour le réaliser :
     – Par l’utilisation de standards ouverts. L’inconvénient des standards ouverts est
        qu’ils ne sont pas toujours largement utilisés et/ou implémentés dans les produits
        commerciaux. Cette solution reste cependant la plus flexible.

Observatoire Technologique                                                                  27
Référentiel e-Société




      – Par l’adoption d’un standard commun au sein de l’Etat. Cette variante as-
        sure une meilleure compatibilité entre les différentes entités mais elle est plus
        contraignante. Le standard commun peut être, bien sûr, un standard ouvert. La
        connectivité ne s’appuie cependant pas sur son ouverture mais sur sa généra-
        lisation au sein de l’Etat. Son ouverture permet une meilleure connectivité avec
        l’extérieur de l’Etat.
      Le choix effectué doit être renforcé par une méthodologie adéquate. Le problème
      est qu’actuellement l’administration n’a pas mis en place tous les standards et
      toutes les méthodologies souhaitables. Il n’a pas mis en place non plus de sys-
      tème d’assurance qualité pour vérifier leur application.
      Concrètement, en ce qui concerne la cyber-administration, il y aura donc deux
      phases dans son développement à moyen terme :
      – Transition - Choix méthodologique et standardisation. Pendant cette période
        il faudra orienter les standards et les méthodologies vers une ouverture sur les
        nombreux partenaires externes de l’administration. De même il faudra évaluer
        les projets existants et les projets qui vont démarrer pendant cette période. Les
        dimensions vont porter sur les projets - les dimensions de transition.
      – Fonctionnement selon les méthodologies et standards fixés ci-dessus. Pen-
        dant cette phase les choix seront effectués au niveau de la standardisation et de
        la méthodologie non pas pour chaque projet mais de façon globale en utilisant le
        Référentiel (sous-dimensions méthodologie et standards).

Les sous-dimensions développées jusqu’ici sont regroupées en deux classes :
– Dimensions de transition (pour les projets) :
    1. L’orientation objet.
    2. Ouverture des base de données (SGBD ouvert ou propriétaire).
    3. Qualification technique (QoS : Quality of Service).
    4. Réutilisation/intégration des applications existantes.
– Dimensions sur méthodologie et standards :
    5. La méthodologie de développement.
    6. La technologie de développement.
    7. Standardisation architecture application (n-tiers).
    8. Standardisation communication informatique (selon standards internationaux).
Références
Jean-Michel Cornu, Internet, tome 1 : Les technologies de demain, 2002. En ligne URL
http://www.fing.org/index.php?rubrique=cahiers.




Observatoire Technologique                                                               28
Référentiel e-Société




1.4.2   Orientation objet

                     Description abrégée
 tju                 Orientation objet
 Description         Les projets de développement doivent utiliser une technologie orien-
                     tée objet.
 Types d’objet       Projet de développement
 Objets de réfé-     Dans l’ordre croissant des préférences :
 rence                  1. Aucune encapsulation
                        2. Modulaire avec la possibilité d’encapsulation des traitements
                        3. Modulaire avec type des données complexes ; encapsulation
                           soit pour les traitements soit pour les données mais pas les
                           deux dans la même entité
                        4. Objet ; encapsulation des données et traitements dans la
                           même entité.

 Risques             Complexité. C’est un risque seulement après un certain niveau, il
                     est lié à la capacité humaine d’appréhender cette complexité.
 Mesures             Axe ordinal sur lequel on propose une pondération selon le schéma
                     suivant pour souligner l’avantage de la 3e et 4e option : 1 pour le
                     type 1 (Aucune encapsulation) ; 2 pour le type 2 ; 4 pour le type 3 ; 6
                     pour le type 4 (Objet).
                     A revoir avec le bénéficiaire du référentiel.

 Aspect métier       aucun
 Niveaux             Bas niveau. Le niveau "supérieur" porte sur le standard de dévelop-
 d’abstraction       pement.
 Compétence          Chef de projet
 Pré-requis          aucun




Observatoire Technologique                                                                   29
Référentiel e-Société




1.4.3   Ouverture des bases de données

                     Description abrégée
 tju                 Ouverture des bases de données
 Description         Ouverture des bases de données
 Types d’objet       Projet informatique
 Objets de réfé-     Dans l’ordre croissant des préférences :
 rence                  1. Fichier propriétaire, accès seulement par une application
                        2. Base de données ouverte
                        3. Base de données ouverte avec documentation

 Risques
 Mesures             C’est un axe ordinal mais on peut imaginer une mesure pondérée
 Aspect métier       aucun
 Niveaux             Niveau bas, seulement pour les projets informatiques
 d’abstraction
 Compétence          Chef de projet
 Pré-requis          aucun


Explications

L’ouverture des bases de données implique un accès facile à la base avec une séman-
tique attachée. On ne doit pas oublier l’accès du point de vue de la sécurité (mot de
passe administrateur) et une documentation de la base sans laquelle les données sont
très difficiles à exploiter (interpréter, importer etc.).




Observatoire Technologique                                                                 30
Référentiel e-Société




1.4.4   Qualification technique

                     Description abrégée
 tju                 Qualification technique
 Description         Chaque modification SI doit passer par une qualification technique y
                     compris une analyse qualité de service (QdS) pour garder la priorité
                     des systèmes critiques
 Types d’objet       Tout projet SI
 Objets de réfé-     Dans l’ordre croissant des préférences :
 rence                  1. Sans une qualification technique et une analyse QdS
                        2. Avec une qualification technique et une analyse QdS

 Risques             Congestion des ressources
 Mesures             Dimension booléenne
 Aspect métier       Chef de projet
 Niveaux             aucun
 d’abstraction
 Compétence
 Pré-requis          Système d’implémentation de la QdS


Explications

La qualification technique et la qualité de service (QdS) sont des notions vitales dans un
réseau complexe comme celui de l’Etat. Dans un tel réseau on peut facilement surcharger
le trafic sur un switch, sur un router ou sur un serveur à cause des différentes applications
qui sollicitent en même temps ces ressources. L’impossibilité de prévoir et de concevoir
un réseau complexe parfaitement adapté impose un contrôle qui peut être implémenté
avec un système QdS.
Une analyse du point de vue QdS fait l’inventaire des applications demandeuses et des
ressources. Elle établit également une priorité dans le cas d’une concurrence sur les
mêmes ressources. Par exemple, pendant une votation, l’application “votation on-line”
doit avoir une priorité de traitement plus grande que les applications “office de la navi-
gation” pour les inscriptions ou les radiations des bateaux on-line pour le transport des
données sur le réseau cantonal.
Les possibilités de quantification sont les suivantes :
– A sans = -1 et avec = 1,
– sans = 0 et avec = 1.
Pour les projets qui présentent une modularité et pour lesquelles ont peut appliquer une
analyse par module on peut aussi imaginer que la mesure pour le projet est une somme
pondérée des mesures de chacun des modules, les pondérations étant attribuées en
fonction de l’importance de chaque module.




Observatoire Technologique                                                                 31
Référentiel e-Société




1.4.5   Réutilisation des applications

                     Description abrégée
 tju                 Réutilisation des applications
 Description         Les nouvelles applications doivent intégrer au maximum les fonc-
                     tionnalités viables déjà existantes.
 Types d’objet       Projets informatiques
 Objets de réfé-     Seuls les extrêmes sont faciles à préciser :
 rence               – Sans aucune intégration
                     – Application type “wraper”
                     Cette dimension étant assez “continue” du point de vue des valeurs,
                     il est difficile d’imaginer d’autres objets de référence.
 Risques             Le risque essentiel est lié au manque de fiabilité des applications dû
                     aux problèmes potentiels de compatibilité. En principe ce risque est
                     directement proportionnel au degré de réutilisabilité. C’est un coût
                     qu’on doit payer pour récupérer les anciennes applications.
 Mesures             La mesure sur cet axe est continue. Elle est proportionnelle au de-
                     gré d’intégration des applications déjà existantes. On peut ainsi dé-
                     finir un pourcentage calculé comme le rapport des fonctionnalités
                     contenues dans les anciennes applications par celles nouvellement
                     développées.
                     Il faut préciser qu’il n’y a pas de valeur 100% intégration : il y aura
                     toujours une valeur ajoutée par la nouvelle application. Par contre
                     on peut très bien avoir une valeur de 0%.
 Aspect métier       aucun
 Niveaux             Bas niveau. Il peut être appliqué pour un objet générique pour me-
 d’abstraction       surer le degré dans lequel il s’appuie sur des autres éléments déjà
                     existants.
 Compétence          Chef de projet
 Pré-requis          aucun


Explications

Les applications existantes sont très nombreuses dans l’administration genevoise et une
grande partie apportent des gains élevés de productivité. Ces applications sont souvent
bien maîtrisées par les utilisateurs qui en apprécient les fonctionnalités. Leur réutilisa-
tion permet parfois de réduire les coûts de développement si le coût d’intégration est
suffisamment réduit.
La mesure s’appuie sur la liste, pondérée ou non, des fonctionnalités du nouveau sys-
tème. Dans cette liste on prend en compte les fonctionnalités qui sont encore assurées
par les vielles applications intégrées dans le nouveau système. Le pourcentage final P
peut être calculé avec la formule
                                             m            n
                                      P =          pk /         pi
                                             k=1          i=1



Observatoire Technologique                                                                   32
Référentiel e-Société




où m le nombre des fonctionnalités assuré par les anciennes applications intégrées, pk
pondération, n le nombre des fonctionnalités, pi pondération.
Si on considère les fonctionnalités également importantes toutes les pondérations sont
égales et la formule devient
                                       P = m/n
avec m et n comme ci-dessus.




Observatoire Technologique                                                             33
Référentiel e-Société




1.4.6   Méthodologie de développement

                     Description abrégée
 tju                 Méthodologie de développement
 Description         Tout projet doit être conforme avec la méthodologie SI de l’Etat de
                     Genève
 Types d’objet       (A) Tout projet SI.
                     (B) Tout autre objet.
 Objets de réfé-     (A) Dans l’ordre croissant des préférences :
 rence                  1. SI conçu sans méthodologie
                        2. SI conçu avec une méthodologie “propriétaire” mais documen-
                           tée
                        3. SI conçu avec une méthodologie connue, sur le plan global
                           mais pas adopté par l’Etat de Genève
                        4. SI conçu avec la méthodologie de l’Etat de Genève
                     Un peut aussi envisager d’introduire entre les deux derniers cas des
                     méthodologies d’organismes partenaires (confédération, UE).
                     (B) Dans l’ordre croissant des préférences :
                        1. Objet conçu sans standard
                        2. Objet conçu d’après un standard “propriétaire” mais docu-
                           menté
                        3. Objet conçu d’après un standard connu, sur le plan global mais
                           pas adopté par l’Etat de Genève
                        4. Objet conçu d’après un standard de l’Etat de Genève
                     La même remarque que plus haut s’applique.
 Risques             Diminution du contrôle sur le projet/produit, spécialement au cours
                     du temps
 Mesures             (A), (B) C’est un axe ordinal mais on peut imaginer une pondération.
 Aspect métier       aucun
 Niveaux             (A) Niveau bas. Ce principe peut être appliqué dans d’autres do-
 d’abstraction       maines.
                     (B) En plus on peut envisager le respect pour les standards de l’Etat
                     en général (cas B).
 Compétence          Chef de projet
 Pré-requis          (A) Une méthodologie SI à l’Etat de Genève. Sans son existence,
                     on ne peut utiliser que les trois premiers objets de référence.
                     (B) L’existence de standards à l’Etat de Genève.


Explications

La méthodologie représente le savoir-faire formalisé qui assure une approche uniforme
pour différents thèmes. Elle doit être perçue comme utile et efficace dans la communauté


Observatoire Technologique                                                                  34
Référentiel e-Société




qui doit l’utiliser pour être acceptée.
Pour les systèmes informationnels (SI) la méthodologie ne doit pas être confondue avec
le langage de spécification technique/fonctionnelle ou avec la technologie.
L’avantage essentiel est le “langage commun” établi entre les acteurs et dans le temps
(voir maintenance, développement). Il ne faut pas oublier aussi l’expérience incorporée
dans la méthodologie.
Pour tenter de mesurer cet aspect on différencies les deux objets suivants.
– (A) Le cas du projet SI. Pour un projet SI la mesure est l’attribution de la valeur selon
  le cas (voir le tableau partie (A)).
– (B) Le cas de l’objet générique. Les standards, en général peuvent être appliqués
  à des problèmes très pointus. Un objet complexe peut donc facilement impliquer diffé-
  rents standards pour les parties qui le composent. Un objet O à mesurer doit être dé-
  composé en plusieurs sous-objets Oi auxquels on applique des standards différents.
  Cette décomposition doit déterminer le poids pi de chaque sous-objet par rapport à
  l’objet. L’attribution pour chaque sous-objet auquel un seul standard s’applique est me-
  suré par l’attribution d’une valeur selon le tableau ci-dessus (cas (B)). Pour trouver la
  valeur V (O) pour l’objet O on applique la formule suivante :
                                                  n
                                      V (O) =          V (Oi ) · pi
                                                 i=1

  où n est le nombre des sous-objets dans l’objet.
  Dans le cas des objets/sous-objets qui doivent respecter plusieurs standards en même
  temps, on peut aussi imaginer une pondération de chaque standard à respecter psk
                                          n                      ni
                               V (O) =          V (Oi ) · pi ·         psk
                                          i=1                    k=1

  où n est le nombre des sous-objets dans l’objet, ni le nombre de standards à respecter
  pour le sous-objet Oi , psk = 0 si le standard k n’est pas respecté.
  Selon la politique définie par le CTI les valeurs 1, 3, 5, 6 peuvent être modifiées pour
  marquer une différence plus nette entre un objet qui respecte un standard de l’Etat
  de Genève et un objet qui ne respecte aucun standard, par exemple. Les valeurs sont
  donc une proposition à évaluer par le bénéficiaire du modèle, selon ses besoins.




Observatoire Technologique                                                                     35
Référentiel e-Société




1.4.7   Technologie de développement

                     Description abrégée
 tju                 Technologie de développement
 Description         La nécessité de diviser les problèmes complexes afin de pouvoir les
                     gérer correctement doit être prise en compte par la technologie de
                     développement qui doit inclure le concept d”’isolation de problème”.
 Types d’objet       Technologie standard
 Objets de réfé-     Dans l’ordre croissant des préférences :
 rence                  1. Aucune encapsulation
                        2. Modulaire avec la possibilité d’encapsulation des traitements
                        3. Modulaire avec type des données complexes ; encapsulation
                           soit pour les traitements soit pour les données mais pas les
                           deux dans la même entité
                        4. Objet ; encapsulation des données et traitements dans la
                           même entité

 Risques             Complexité trop importante et impossible à prendre en compte.
 Mesures             Axe ordinal sur lequel on propose une pondération pour souligner
                     l’avantage de la 3e et 4e option : 1 pour le type 1 (Aucune encapsu-
                     lation) ; 2 pour 2 ; 4 pour 3 ; 6 pour 4 (Objet).
 Aspect métier       aucun
 Niveaux             aucun
 d’abstraction
 Compétence          Comité de méthodologie et de standardisation
 Pré-requis          aucun


Explications

Vu la complexité, au sein de l’administration, des problèmes concernant le développe-
ment et l’environnement des applications, la nécessité de diviser les problèmes com-
plexes afin de pouvoir les gérer correctement est évidente. La technologie de dévelop-
pement doit donc inclure le concept d”’isolation de problème”. Cette isolation peut se
faire au niveau des données, au niveau des traitements ou aux deux niveaux à la fois.
Historiquement, le développement a commencé à mettre à disposition une isolation pour
les traitements (modularité des programmes), puis une isolation pour les données (types
complexes des données) et finalement une isolation pour les données et les traitement
simultanément (les objets).
La technologie choisie doit offrir la dernière variante, conçue pour la solution “objet” ou
similaire, l’important étant d’offrir le concept d’encapsulation (données et traitements).
Une fois cette technologie choisie, il faut prévoir des mécanismes pour contrôler son
application dans les projets, habituellement au travers d’un plan d’assurance qualité.




Observatoire Technologique                                                                 36
Référentiel e-Société




1.4.8   Architecture applications

                     Description abrégée
 tju                 Architecture applications
 Description         Tout changement de standard de développement doit imposer une
                     architecture par couches.
 Types d’objet       Standard de développement
 Objets de réfé-     Dans l’ordre croissant des préférences :
 rence                  1. 1 tiers : pas de concept serveur
                        2. 2 tiers : client/serveur
                        3. n tiers : (p. ex. présentation/serveur application/serveur don-
                           nées)

 Risques             Coût de la maintenance/développement, indépendance des fournis-
                     seurs du framework des différentes couches.
 Mesures             Axe ordinal mais on peut imaginer une pondération.
 Aspect métier       aucun
 Niveaux             Niveau bas, seulement pour les standards développement.
 d’abstraction
 Compétence          Comité de standardisation
 Pré-requis          aucun


Explications

La stratification des architectures d’application concourt, en premier lieu à l’indépendance
vis-à-vis des fournisseurs de serveurs, framework ou autre, ainsi qu’à l’efficience du trai-
tement des données (spécialisation comme serveur base de données pour stockage des
données, serveur application pour la logique métier ou buisiness logic).
Prenons le cas d’une architecture 3-tiers : Client / Logique métier (serveur d’application)
/ Base de données (serveur de base de données). Un changement de serveur de base
de données de MS SQL Server vers DB2 n’est pas ressenti par le client, mais unique-
ment par la partie du serveur application qui assure la connexion avec ORACLE. Aucun
changement ne se fait du coté client.
Pour les standards qui présentent une modularité et pour lesquels ont peut appliquer une
analyse par module on peut aussi imaginer que la valeur du standard est une somme
pondérée des valeurs de ses modules, les pondérations étant attribuées en fonction de
l’importance du chaque module.




Observatoire Technologique                                                                  37
Référentiel e-Société




1.4.9   Standardisation des communication

                     Description abrégée
 tju                 Standardisation des communication
 Description         Tout changement de standard de communication doit tenir compte
                     des standards de communication suisses et internationaux.
 Types d’objet       Standard de communication informatique
 Objets de réfé-     Dans l’ordre croissant des préférences :
 rence                  1. Standard propriétaire (exemple NetBEUI)
                        2. Standard Confédération
                        3. Standard international (IEEE)

 Risques             Exclusion dans le cas d’un seul protocole ou coût pour paquet des
                     protocoles alternatifs.
 Mesures             Axe ordinal, mais on peut imaginer une pondération.
 Aspect métier       aucun
 Niveaux             Niveau bas
 d’abstraction
 Compétence          Comité de standardisation
 Pré-requis          aucun


Explications

L’interopérabilité est la clé de chaque système informationnel. Une bonne interopérabi-
lité des SI passe par la communication des données. La complexité de la communica-
tion dans l’administration genevoise consiste dans la multitude des acteurs avec pour
beaucoup d’entre eux des configurations particulières (hardware, protocoles, progiciels,
langues, etc.).


               Agent X                                                   Agent Y
              Langue XY                 niveau sensible                 Langue XY
             Application X                                             Application Y
 Protocole communication données XY     niveau sensible    Protocole communication données XY
              Materiel X                                                Materiel X


Selon les éléments ci-dessus on voit les deux niveaux sensibles où la compatibilité est
requise :
  1. les protocoles de communication,
  2. la langue de communication.
  3.
Du point de vue technologique le protocole de communication est très important pour
assurer l’interopérabilité. La variété des agents oblige l’Etat de Genève à offrir :

Observatoire Technologique                                                                  38
Référentiel e-Société




  1. Un protocole de communication très répandu (TCP/IP par exemple),
  2. Plusieurs protocoles de communication en même temps pour assurer la compa-
     tibilité avec les interlocuteurs (IPsec, PPTP, L2TP par exemple). Dans ce cas les
     différents protocoles offrent la même fonctionnalité au même niveau mais ils sont
     mis à disposition pour des raisons de compatibilité.
La deuxième variante est plus coûteuse (coût de maintenance, sécurité) mais plus ou-
verte tandis que la première est moins chère mais plus restrictive.
Pour les standards qui présentent une modularité et pour lesquels ont peut appliquer une
analyse par module on peut imaginer que la valeur du standard est une somme pondéré
des valeurs de ses modules, les pondérations étant attribuées en fonction de l’importance
du chaque module.
Selon la politique définie par le CTI les pondérations peuvent être modifiées pour dimi-
nuer la différence entre un standard suisse et un standard international en fonction des
objectives du bénéficiaire. Les valeurs sont donc une proposition à évaluer par le bénéfi-
ciaire du modèle, selon ses besoins.




Observatoire Technologique                                                               39
Référentiel e-Société




1.5     Politique d’information

                     Description abrégée
 sdz                 Politique d’information
 Description         Mesurer la contribution d’un projet au processus de conduite de la
                     cyber-administration dans le domaine de régulation et de coordina-
                     tion, en se basant sur son aptitude à communiquer.
 Types d’objet       Projets métier
 Objets de réfé-     aucun
 rence
 Risques             Difficulté ou volonté à réorganiser le processus de production en
                     fonction des besoins et des ressources globales de l’environnement.
 Mesures             Note de 0 à 8 décomposée selon les quatre aspects du processus
                     d’information global :
                     – politique d’information générale du projet métier (0 à 2 points) ;
                     – informer globalement (0 à 2 points) ;
                     – s’informer globalement (0 à 2 points) ;
                     – intégrer l’information (0 à 2 points).

 Aspect métier       S’applique à tous les métiers.
 Niveaux             aucun
 d’abstraction
 Compétence          Service d’information du CTI ; OT
 Pré-requis          Ressources et organisation de l’environnement (déploiement du
                     sous-modèle CA dans l’organisation de projet et au niveau supérieur
                     aux projets) pour l’accompagnement des projets métiers en matière
                     de politique d’information globale.


1.5.1   Explications

Le développement de la cyber-administration à Genève se fera à travers deux processus.
D’une part, le processus de conduite, au niveau stratégique, définira les lignes directrices
et les priorités. D’autre part le processus de développement sera constitué de multiples
projets topiques situés pour la plupart dans les départements et les unités de l’adminis-
tration.
Afin d’accomplir des objectifs globaux, des mécanismes de régulation et de coordination
seront mis en place, dont le référentiel fait partie. La régulation et la coordination reposent
cependant tous les deux sur une communication et une information adaptées aux besoins
du projet global dans son environnement.
L’aptitude des projets et de leurs responsables à s’informer, à informer et à intégrer les
informations reçues dans un processus de développement adapté aux besoins globaux,
deviendra un facteur critique de réussite de la cyber-administration.




Observatoire Technologique                                                                    40
Référentiel e-Société




1.5.2   Acteurs, rôles et types d’échanges

Considérons un projet métier en cours de réalisation et immergeons le dans le contexte
de la cyber-administration. Du point de vue de l’administration, les acteurs sont répartis
dans la partie hachurée de la figure 1.4.




               F IG . 1.4 – Principe d’organisation de la cyber-administration.


L’ensemble des acteurs directement ou indirectement concernés, ainsi que leurs relations
sont représentés dans le tableau ci-dessous.




Observatoire Technologique                                                                   41
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société
Référentiel e-Société

Contenu connexe

Tendances

Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008
Digimind
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
Université de Rennes 1
 
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborativeMémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
Messaoud Hatri
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
SafaAballagh
 
Cours gestion-de-production
Cours gestion-de-productionCours gestion-de-production
Cours gestion-de-production
Rachid Rachido
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
Donia Hammami
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
ALALSYSE
 
Les serious games - Mémoire de master en Sc. Educ de Bernard Lamailloux
Les serious games - Mémoire de master en Sc. Educ de Bernard LamaillouxLes serious games - Mémoire de master en Sc. Educ de Bernard Lamailloux
Les serious games - Mémoire de master en Sc. Educ de Bernard Lamailloux
Bernard Lamailloux
 
These
TheseThese
Cours base données
Cours base donnéesCours base données
Cours base données
kerosina
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
ahmed oumezzine
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Benjamin Vidal
 
Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Le logiciel libre dans le secteur public, un état des lieux en juin 2013Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Benjamin Vidal
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
Donia Hammami
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Ghodbane Heni
 
Atelier tapisserie-entreprise
Atelier tapisserie-entrepriseAtelier tapisserie-entreprise
Atelier tapisserie-entreprise
Ahmed BEN DAHMEN
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
safwenbenfredj
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
Oussama Djerba
 
Etude des effets de l'instauration de la loi concernant le droit à l'intégrat...
Etude des effets de l'instauration de la loi concernant le droit à l'intégrat...Etude des effets de l'instauration de la loi concernant le droit à l'intégrat...
Etude des effets de l'instauration de la loi concernant le droit à l'intégrat...
POD Maatschappelijke Integratie - SPP Intégration Sociale
 

Tendances (20)

Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborativeMémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
Cours gestion-de-production
Cours gestion-de-productionCours gestion-de-production
Cours gestion-de-production
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
 
Les serious games - Mémoire de master en Sc. Educ de Bernard Lamailloux
Les serious games - Mémoire de master en Sc. Educ de Bernard LamaillouxLes serious games - Mémoire de master en Sc. Educ de Bernard Lamailloux
Les serious games - Mémoire de master en Sc. Educ de Bernard Lamailloux
 
These
TheseThese
These
 
Cours base données
Cours base donnéesCours base données
Cours base données
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
 
Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Le logiciel libre dans le secteur public, un état des lieux en juin 2013Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Le logiciel libre dans le secteur public, un état des lieux en juin 2013
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
 
Atelier tapisserie-entreprise
Atelier tapisserie-entrepriseAtelier tapisserie-entreprise
Atelier tapisserie-entreprise
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Etude des effets de l'instauration de la loi concernant le droit à l'intégrat...
Etude des effets de l'instauration de la loi concernant le droit à l'intégrat...Etude des effets de l'instauration de la loi concernant le droit à l'intégrat...
Etude des effets de l'instauration de la loi concernant le droit à l'intégrat...
 

En vedette

L'agrément, un outil digne de confiance
L'agrément, un outil digne de confianceL'agrément, un outil digne de confiance
L'agrément, un outil digne de confiance
Genève Lab
 
Société de l'information
Société de l'informationSociété de l'information
Société de l'information
Genève Lab
 
Opportunités et défis de la confiance numérique
Opportunités et défis de la confiance numériqueOpportunités et défis de la confiance numérique
Opportunités et défis de la confiance numérique
Genève Lab
 
Politique d’utilisation des médias sociaux: modèle et exemples
Politique d’utilisation des médias sociaux: modèle et exemplesPolitique d’utilisation des médias sociaux: modèle et exemples
Politique d’utilisation des médias sociaux: modèle et exemples
Genève Lab
 
Frank Grozel - Unctad 10 principes de simplification des procedures administr...
Frank Grozel - Unctad 10 principes de simplification des procedures administr...Frank Grozel - Unctad 10 principes de simplification des procedures administr...
Frank Grozel - Unctad 10 principes de simplification des procedures administr...
Genève Lab
 
Vers un écosysteme d'information ouvert
Vers un écosysteme d'information ouvertVers un écosysteme d'information ouvert
Vers un écosysteme d'information ouvert
Genève Lab
 
La confiance à l'ère du numérique
La confiance à l'ère du numériqueLa confiance à l'ère du numérique
La confiance à l'ère du numérique
Genève Lab
 
L'économie collaborative
L'économie collaborativeL'économie collaborative
L'économie collaborative
Genève Lab
 

En vedette (8)

L'agrément, un outil digne de confiance
L'agrément, un outil digne de confianceL'agrément, un outil digne de confiance
L'agrément, un outil digne de confiance
 
Société de l'information
Société de l'informationSociété de l'information
Société de l'information
 
Opportunités et défis de la confiance numérique
Opportunités et défis de la confiance numériqueOpportunités et défis de la confiance numérique
Opportunités et défis de la confiance numérique
 
Politique d’utilisation des médias sociaux: modèle et exemples
Politique d’utilisation des médias sociaux: modèle et exemplesPolitique d’utilisation des médias sociaux: modèle et exemples
Politique d’utilisation des médias sociaux: modèle et exemples
 
Frank Grozel - Unctad 10 principes de simplification des procedures administr...
Frank Grozel - Unctad 10 principes de simplification des procedures administr...Frank Grozel - Unctad 10 principes de simplification des procedures administr...
Frank Grozel - Unctad 10 principes de simplification des procedures administr...
 
Vers un écosysteme d'information ouvert
Vers un écosysteme d'information ouvertVers un écosysteme d'information ouvert
Vers un écosysteme d'information ouvert
 
La confiance à l'ère du numérique
La confiance à l'ère du numériqueLa confiance à l'ère du numérique
La confiance à l'ère du numérique
 
L'économie collaborative
L'économie collaborativeL'économie collaborative
L'économie collaborative
 

Similaire à Référentiel e-Société

Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
Mohamed Boubaya
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
Adem Amen Allah Thabti
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
nuntiis
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
Hosni Mansour
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Mohamed Amine Mahmoudi
 
Report Master
Report MasterReport Master
Report Master
Bilel Trabelsi
 
anssi-guide-passerelle_internet_securisee-v3.pdf
anssi-guide-passerelle_internet_securisee-v3.pdfanssi-guide-passerelle_internet_securisee-v3.pdf
anssi-guide-passerelle_internet_securisee-v3.pdf
Badr Belhajja
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Alaaeddine Tlich
 
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM NortelConception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Tidiane Sylla
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
Mohamed Boubaya
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Yosra ADDALI
 
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdfRapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
JihenBenfredj
 
Guide étude sectorielle
Guide étude sectorielleGuide étude sectorielle
Guide étude sectorielle
Philippe Porta
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Nawres Farhat
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
Ilyas CHAOUA
 

Similaire à Référentiel e-Société (20)

siem.pdf
siem.pdfsiem.pdf
siem.pdf
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
Report Master
Report MasterReport Master
Report Master
 
anssi-guide-passerelle_internet_securisee-v3.pdf
anssi-guide-passerelle_internet_securisee-v3.pdfanssi-guide-passerelle_internet_securisee-v3.pdf
anssi-guide-passerelle_internet_securisee-v3.pdf
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
 
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM NortelConception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdfRapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
 
Guide étude sectorielle
Guide étude sectorielleGuide étude sectorielle
Guide étude sectorielle
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 

Plus de Genève Lab

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

Plus de Genève Lab (20)

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

Référentiel e-Société

  • 1. Le Référentiel e-Société Observatoire Technologique Centre des Technologies de l’Information République et Canton de Genève Version 0.9 15 novembre 2002 Observatoire Technologique Centre des technologies de l’information République et Canton de Genève 78–82 route des Acacias CP 149, 1211 Genève 8 Suisse http://www.geneve.ch/ot/ ot@etat.ge.ch
  • 2. Copyright c 2002–2004 CTI, Observatoire Technologique. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/2.0/ or send a let- ter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. You are free: • to copy, distribute, display, and perform the work • to make derivative works Under the following conditions: Attribution. You must give the original author credit. Noncommercial. You may not use this work for commercial purposes. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the author. Your fair use and other rights are in no way affected by the above. This is a human-readable summary of the Legal Code (the full license http://creativecommons.org/ licenses/by-nc-sa/2.0/legalcode).
  • 3. Table des matières I Introduction 4 II Référentiel e-Société 10 1 Projet 11 1.1 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2 Efficacité économique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.2 Eléments de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3 Impact sur la complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.3.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.3.2 Identification, localisation, cohérence . . . . . . . . . . . . . . . . . 24 1.4 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.4.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.4.2 Orientation objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.4.3 Ouverture des bases de données . . . . . . . . . . . . . . . . . . . 30 1.4.4 Qualification technique . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.4.5 Réutilisation des applications . . . . . . . . . . . . . . . . . . . . . . 32 1.4.6 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . 34 1.4.7 Technologie de développement . . . . . . . . . . . . . . . . . . . . . 36 1.4.8 Architecture applications . . . . . . . . . . . . . . . . . . . . . . . . . 37 1.4.9 Standardisation des communication . . . . . . . . . . . . . . . . . . 38 1.5 Politique d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 1.5.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 1.5.2 Acteurs, rôles et types d’échanges . . . . . . . . . . . . . . . . . . . 41 1
  • 4. Référentiel e-Société 2 Administration 46 2.1 Gestion de la connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.1.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.2 Transversalité des processus . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.2.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.2.2 Degrés de transversalité (au niveau des processus) . . . . . . . . . 53 2.3 Transversalité des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.3.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.3.2 Cadres légal, éthique et sociétal . . . . . . . . . . . . . . . . . . . . 57 2.3.3 Organisation du système d’information . . . . . . . . . . . . . . . . . 58 2.3.4 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.3.5 Schémas et format de données . . . . . . . . . . . . . . . . . . . . . 58 2.3.6 Métadonnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.4 Interopérabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.4.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.4.2 Niveaux d’interopérabilité . . . . . . . . . . . . . . . . . . . . . . . . 63 2.4.3 Respect du principe d’organisation (POCA) . . . . . . . . . . . . . . 66 2.4.4 Registre des processus cyber-administratifs . . . . . . . . . . . . . . 68 2.4.5 Classification des éléments d’information . . . . . . . . . . . . . . . 69 2.4.6 Respect du modèle de communication . . . . . . . . . . . . . . . . . 69 2.4.7 Signalisation des informations privées sensibles . . . . . . . . . . . 69 2.4.8 Registres des personnes et des rôles . . . . . . . . . . . . . . . . . 70 2.5 Service d’information et processus cyber-administratif . . . . . . . . . . . . 72 2.5.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.5.2 Exemple : accréditation de fournisseurs de l’Etat . . . . . . . . . . . 75 2.5.3 Contextualisation dans le Référentiel . . . . . . . . . . . . . . . . . . 76 3 e-Société 78 3.1 Impact sur la cyber-inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.1.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.1.2 Attentes des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 83 3.1.3 Accessibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.1.4 Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Observatoire Technologique 2
  • 5. Référentiel e-Société 3.1.5 Formation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 91 3.2 Respect du cadre éthique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 3.2.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 3.3 Concept d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.3.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.4 Respect du cadre légal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 3.4.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.5 Composante sociétale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.5.1 Explications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Observatoire Technologique 3
  • 7. Référentiel e-Société Contexte Faciliter et étendre l’accès du citoyen aux services de l’administration publique ; réduire le cloisonnement entre services et les rendre plus transversaux ; réduire ainsi les coûts et augmenter la cohérence des processus administratifs partout où les partenaires d’une action commune doivent intervenir directement ; ce sont là quelques uns des thèmes que tous les acteurs de la scène administrative publique cherchent à développer au travers de la mise en place de la cyber-administration. Comme illustré par le schéma de la figure 1, la cyber-administration recouvre une large problématique car elle concerne différentes instances au niveau des administrations (Confédération, cantons et communes) tout en reposant sur des échanges avec les différents acteurs que sont les citoyens, les entre- prises et les institutions (économiques, culturelles, sociales, etc.). F IG . 1 – Niveaux de communication dans la cyber-administration selon l’USIC. Pour suivre la terminologie utilisée par la Confédération on parle de relations : – G-I : Government internal. Relations au sein de l’Etat (exécutif, législatif et administra- tion), au niveau de la Confédération, d’un canton ou d’une commune. – G2G : Government to Government. Relations entre la Confédération, les cantons et les communes ainsi que celles qui sont établies avec les gouvernements étrangers et les organisations internationales. – G2O : Government to Organisation. Relations que tissent la Confédération, les cantons et les communes avec les partenaires de l’économie privée et les organisations de droit public. – G2C : Government to Citizen. Relations que les instances étatiques entretiennent avec le citoyen. La cyber-administration présente une complexité qui ne caractérisait pas la plupart des Observatoire Technologique 5
  • 8. Référentiel e-Société projets informatiques mis en place jusqu’ici à l’Etat de Genève. Cette complexité découle de plusieurs facteurs. Le premier est que par essence la cyber-administration va influen- cer fortement les structures transversales de l’administration. Le second est qu’elle dé- passe largement le cadre purement technologique en raison notamment du rapport très fort qu’elle entretient avec le citoyen en particulier et avec la société en général. Et le troisième est que ses spécificités ne sont encore pas toutes définies. Pour toutes ces rai- sons, il sera difficile voir impossible d’appréhender les objets de type cyber-administratifs d’un seul bloc. Dans cette optique, et avant que ne commence un développement d’envergure de la cyber-administration à Genève, les responsables de la stratégie informatique de l’Etat de Genève ont considéré qu’il serait utile d’approfondir la signification et l’impact de ces ca- ractéristiques dans une approche holistique. C’est notamment cette démarche globale et abstraite engageant des réflexions dans le domaine très large de la société électronique qui nous a suggéré la dénomination “Référentiel e-Société”. L’étude, réalisée par l’Observatoire Technologique (OT) du Centre des Technologies de l’Information (CTI) entre septembre 2001 et juin 2002, constitue la base d’un Référen- tiel de la cyber-administration, c’est à dire d’un instrument permettant d’identifier et de mesurer les impacts de projets individuels sur l’objectif de modernisation et d’ouverture de l’administration genevoise grâce aux Nouvelles Technologies de l’Information (NTIC). Le référentiel fournit une quinzaine de dimensions individuelles et décrit la manière d’ap- pliquer chacune d’entre elles à un projet (ou plus généralement à tout objet baignant dans le contexte de la cyber-administration). Il fournit les instruments d’aide à la décision et d’alignement de projets qui permettent de les insérer dans une stratégie générale et de les placer sur une toile qui se transformera en un tableau cohérent. Sa conception flexible permet d’adapter les démarches à l’évolution de l’environnement, de l’adminis- tration et des besoins de la société genevoise. Grâce à la gestion de la connaissance et des expériences, il garantit également une pérennité des acquis et une continuité dans les développements futurs. Le Référentiel e-Société présenté ici fournit les fondements solides à partir desquels il sera possible de décliner en termes de concepts, d’architectures, puis de réalisations individuelles, la volonté politique exprimée par le Grand conseil de lancer des projets de cyber-administration dans le canton de Genève. Guide d’utilisation Le Référentiel se présente comme une collection de quinze dimensions constituant une grille de lecture qui doit permettre à l’utilisateur d’appréhender et de mesurer la com- plexité des objets de type cyber-administratifs qui lui sont soumis. Le nombre de ces dimensions découle de leur nature même : une quantité suffisamment importante pour prendre en compte les aspects essentiels des objets à étudier mais aussi suffisamment restreinte pour ne pas se perdre dans la complexité de ces objets. Les quinze dimensions ont été regroupées a posteriori en trois groupes de cinq dimen- sions touchant plus particulièrement : – Aux projets de type cyber-administratifs, – A l’administration dans son ensemble, Observatoire Technologique 6
  • 9. Référentiel e-Société – Et de façon beaucoup plus large, à l’e-Société. Deux d’entre elles, en raison de leur ampleur, ont été déclinées en sous-dimensions. Ces quinze dimensions sont schématisées dans la figure 2. F IG . 2 – Dimensions du Référentiel e-Société. En préambule au développement de chaque dimension ou sous-dimension, un tableau synoptique synthétise 9 de ses caractéristiques importantes au travers des rubriques suivantes : 1. Description : brève description de la problématique que recouvre la dimension. 2. Type d’objets : énumère les différents objets pouvant être jaugés au travers de la dimension (un projet informatique, la mise en place d’une nouvelle loi, etc.). 3. Objets de référence : objet pouvant être mis en évidence en regard de la dimen- sion ; soit parce qu’il constitue un standard (même abstrait), soit parce qu’il constitue un point d’ancrage fort dans le domaine couvert par la dimension. 4. Risques : énumération de risques majeurs pouvant affecter l’objet ou plus généra- lement la mise en œuvre de la cyber-administration si certaines conditions relatives à la dimension ne sont pas remplies. 5. Mesure : dans l’optique d’utiliser le référentiel comme un outil de mesure des ob- jets qui lui sont soumis, notamment dans le cadre d’une aide à la décision, cette rubrique propose une mesure propre à chaque dimension. Cette mesure peut être qualitative ou quantitative (avec plus ou moins de finesse dans la mesure suivant le thème de la dimension). 6. Aspect métier : décline les spécificités métiers liées à chaque dimension. Cette ru- brique s’étoffera au travers des retours d’expérience des projets métiers qui seront mis en œuvre. 7. Niveau d’abstraction : sous-dimensions ou abstractions de la dimension considé- rée. Observatoire Technologique 7
  • 10. Référentiel e-Société 8. Compétence : organe ou structure ayant les compétences requises pour définir la mesure à appliquer à la dimension considérée. 9. Pré-requis : conditions nécessaires devant être présentes pour que l’on puisse prendre en compte la dimension considérée. Scénarios et règles d’application On peut distinguer sommairement quatre utilisations principales du Référentiel e-Société : – la première consiste à évaluer l’impact d’un objet venant s’inscrire dans l’e-Société. Quelles sont les conséquences, par exemple, de la mise en application d’une nouvelle loi sur la protection des données ? Une évaluation de l’impact de cette loi sur cha- cune des dimensions permet d’obtenir une image globale du nouveau paysage de la cyber-administration qui en résulte. Dans ce cas de figure, cette nouvelle loi devrait naturellement être prise en compte par la suite dans le Référentiel. – la deuxième consiste à utiliser le Référentiel pour mesurer, sur chaque dimension, l’écart entre un projet informatique et une situation idéale correspondant par exemple à une référence sur chacune des dimensions. Cette démarche permet d’utiliser le Ré- férentiel comme un outil de correction (voire d’alignement sur la stratégie de l’Etat) pour chaque projet pris indépendamment. Une fois un projet terminé, il devient un élé- ment du paysage de la cyber-administration. Il devrait être réintégré dans le référentiel en tant que point de repère et éventuellement en tant qu’élément de référence ou de standardisation sur une ou plusieurs dimensions. – la troisième consiste à utiliser le Référentiel pour prioriser (en vue de la réalisation de certains d’entre eux) une série de projets informatiques qui lui sont présentés. Cette opération peut être mise en œuvre en appliquant une analyse multi-critères prenant en compte les poids associés à chaque dimension et, pour chaque objet de l’une ou de plusieurs des listes décrites ci-dessus, sa mesure propre pondérée par les poids considérés dans ce contexte d’application. – une dernière utilisation est celle d’un outil de communication. Au travers du Référentiel, l’Etat peut communiquer sa stratégie (ou du moins une partie de celle-ci), que ce soit à ses fournisseurs, ou plus généralement au grand public. La société électronique évolue constamment et le Référentiel doit prendre en compte cette notion afin de rester un outil adapté à l’environnement qu’il prétend analyser. Dans cette optique la notion de retours d’expériences des utilisateurs du Référentiel est es- sentielle. Ce sont ces éléments qui, avec le travail de maintenance dévolu à l’OT, sont garants de la pérennité et de la fiabilité de cet outil. Le Référentiel e-Société développé par l’Observatoire Technologique du Centre des Tech- nologies de l’Information de l’Etat de Genève se veut un document ouvert et évolutif. Dans la première version publique de novembre 2002, nous présentons ce Référentiel qui n’est encore que dans un état préliminaire. Toutes les dimensions ne sont pas au même niveau de maturité et de développement. Il s’agit comme mentionné ci-dessus de l’enrichir et de continuer à le développer de façon à construire des versions ultérieures plus complète et plus achevées. Dans cet esprit nous le proposons ici en accès libre sous une licence Creative Com- mons (http://creativecommons.org/licenses/by-nc-sa/2.0/). Un feedback sur l’utilisation du référentiel ou des commentaires sont les bienvenus à l’adresse e-mail Observatoire Technologique 8
  • 11. Référentiel e-Société ot@etat.ge.ch. Références Unité de stratégie informatique de la Confédération (USIC), Département fédéral des fi- nances DFF, L’activité gouvernementale à l’heure de la société de l’information : Stratégie de la Confédération en matière de cyber-administration (e-government), 13 février 2002, http://www.isb.admin.ch/egov/ Observatoire Technologique 9
  • 14. Référentiel e-Société Les dimensions suivantes : – Efficacité économique – Impact sur la complexité – Politique d’information – Sécurité – Technologie ont été regroupées sous l’étiquette commune “Projets”. Cela correspond au fait que le domaine d’application de ces cinq dimensions touche essentiellement aux objets de type projet cyber-administratif. Cela se comprend aisément pour les dimensions “Impact sur la complexité” ou “Technologies”. La dimension “Sécurité” est développée à ce niveau car il nous paraît essentiel de prendre en compte des aspects liés à la sécurité en amont de tout projet, même si cela présuppose également l’existence d’une politique de sécurité au niveau de l’Etat de Genève. La dimension “Politique d’information” décrit uniquement la nécessité d’avoir une bonne politique d’information au niveau de tous les futurs projets de cyber-administration. La dimension "Efficacité économique” finalement est conçue pour étudier cette notion au niveau des projets uniquement. D’autres dimensions présentées plus loin sous l’étiquette “Administration” se situent à la frontière du domaine “Projet”. Il est clair que cette répartition est à ce niveau relativement arbitraire. Observatoire Technologique 12
  • 15. Référentiel e-Société 1.1 Sécurité Description abrégée gpl Sécurité Description Les objets liés à la mise en œuvre de la cyber-administration ont des effets sur la sécurité du système d’information de l’Etat, ainsi que sur celle des protagonistes de l’e-Société. L’information étant reconnue comme un bien de valeur et une ressource fondamentale, il convient de la protéger et d’assurer sa disponibilité. Types d’objet Objets dont les instances sont immergés dans un contexte socio- technique (applications, infrastructures, bases d’informations, sys- tèmes d’information). Objets de réfé- Effet positif. Objet construit selon les principes suivants : rence – les bases d’information sont normalisées selon les règles de la protection des données, et construites et gérées en conformité ; – les systèmes d’information sont bâtis de manière à respecter la politique de sécurité ; – les projets traitent la sécurité comme partie intégrante lors de leur conception ; Effet négatif : – le système d’information n’est pas prévu pour limiter la vulnérabi- lité, est conçu avec une seule couche de sécurité et ne minimise pas les éléments et ressources auxquels il peut faire confiance. – les systèmes critiques ne sont pas suffisamment isolés et/ou ne sont pas répliqués pour parer à des défaillances. Risques Le manque de prise en compte des aspects de sécurité dans un objet cyber-administratif peut mettre en péril tout ou une partie du système d’information de l ’Etat. Au niveau de l’e-Société, le risque de la divulgation ou de la modifi- cation indue de d’informations peut affecter gravement les protago- nistes de la cyber-administration. De plus, la confiance mise dans l’Etat et son image de marque sont détériorées, en particulier lors de l’introduction de la cyber-administration. Mesures Non mesurable ordinal. L’effet est : – Négatif, si l’existence ou l’introduction de l’objet a tendance à di- minuer la sécurité du système d’information de l’Etat. Des me- sures afin de contrôler et de maintenir le niveau souhaitable de sécurité doivent être imposées. – Positif, si l’existence ou l’introduction de l’objet dans le contexte global de la cyber-administration ou de l’e-Société tend à mainte- nir ou augmenter la sécurité ou encore faciliter sa mise en œuvre. L’évaluation de la mesure peut prendre en compte différents critères pour un seul objet ou différents critères selon les objets. Aspect métier aucun Observatoire Technologique 13
  • 16. Référentiel e-Société Niveaux aucun d’abstraction Compétence Responsables de la sécurité des systèmes d’information ; Ingénieurs et architectes des systèmes d’information. Pré-requis Politique de sécurité définie et acceptée par l’unité responsable, ainsi que par les organes officiels responsables de la sécurité gé- nérale au niveau de l’Etat. 1.1.1 Explications Une sécurité adéquate de l’information et des systèmes qui l’utilisent est une dimension fondamentale pour des objets de type cyber-administratif dans un système d’information complexe comme celui de l’Etat. Les considérations concernant la sécurité doivent être prises en compte en amont du dé- veloppement d’un projet. L’inclusion de ces éléments a posteriori devient non seulement plus difficile, mais aussi souvent beaucoup plus coûteux. Les protagonistes de la cyber-administration dans l’e-Société sont également touchés par la sécurité, en particulier lorsque les données protégées les concernent directement. Le Règlement concernant la protection des applications et des systèmes informatiques dans l’administration cantonale B 1 15.01 du 5 avril 2000 et entré en vigueur le 13 avril 2000 stipule dans l’article 1 alinéas 1 et 2 : 1. Lors de la planification, de la réalisation et de l’exploitation d’applications et de systèmes informatiques (ci-après : systèmes) dans l’administration cantonale, il faut s’assurer que ces applications et ces systèmes sont protégés contre les risques qui menacent leur disponibilité, leur intégrité et leur confidentialité. 2. Tous les domaines du traitement des données doivent être protégés, no- tamment : (a) les lieux (immeubles, locaux, transport de supports de données) ; (b) les systèmes (matériels, logiciels, logistique) ; (c) l’utilisation des systèmes (exploitation, applications) ; (d) les communications (transport de données par câbles, réseaux télé- matiques et téléphoniques) ; (e) les données personnelles (protection des données) ; (f) les données ; (g) la documentation. Il est indispensable de se référer aux documents préparés par le comité sécurité des systèmes d’information qui sont la référence à ce sujet au sein de l’Etat de Genève. La dimension sécurité touche en particulier : – Les utilisateurs qui opèrent sur les systèmes d’information ou qui demandent ou éva- luent des réalisations fonctionnelles, Observatoire Technologique 14
  • 17. Référentiel e-Société – Les ingénieurs système et les architectes système qui projettent, construisent ou modifient un système d’information, ceci tout au long des phases du cycle de vie du système, – Les responsables de la sécurité des systèmes qui s’assurent que des mesures de sécurité sont prises en compte tout au long des phases du cycle de vie du système. Quelques domaines de sécurité des systèmes et des réseaux visés sont : le contrôle des accès et l’identification, l’attribution de privilèges, la maintenance de l’intégrité des fichiers et du système de fichiers, les sauvegardes, le monitoring des processus, la maintenance de fichiers de logs, l’audit, la protection des serveurs et des communications informa- tiques, le contrôle des accès depuis des réseaux externes, la détection des interceptions et des intrusions. Il est important de noter que pour que la sécurité soit efficace, il faut considérer non seule- ment l’implémentation technique, mais aussi les aspects de mise en œuvre politiques et opérationnels, ainsi que la formation des utilisateurs. La sécurité physique est également un point crucial, en particulier il faut savoir qui a accès aux locaux contenant des informa- tions critiques. Si ces services sont trop onéreux pour une mise en application générale, on peut se limiter aux postes et localisations les plus critiques. La sécurité de l’information est souvent associée aux caractéristiques suivantes : – Confidentialité : l’information n’est accessible qu’aux agents autorisés, – Intégrité : l’information ne peut pas être modifiée (créée, changée ou détruite) par des agents non autorisés. La qualité de l’information est assurée. – Disponibilité : l’information doit être disponible, ce qui implique que le système sous- jacent est opérationnel et fonctionnel. Ces caractéristiques impliquent la mise en œuvre des éléments suivants : – Identification : faire correspondre à un agent une identité logique. – Authentification : s’assurer que l’agent est bien qui il prétend être et que les modifi- cations d’informations sont attribuables à un agent ; une information peut aussi être authentifiée par un agent si son utilisation nécessite une telle garantie, – Non répudiation : une modification de l’information par un agent ne peut pas être niée, – Traçabilité : un agent est responsable des modifications effectuées et celles-ci peuvent être, le cas échéant, retracées. On peut distinguer six étapes essentielles afin de mettre en place d’une sécurité de qua- lité : 1. Définir une politique et des standards pour la sécurité 2. Bâtir une architecture et des processus sécurisés 3. Former et informer les collaborateurs sur la sécurité 4. Evaluer et déployer des produits et technologies pour la sécurité 5. Prévoir des audits, un monitoring et des enquêtes sur la sécurité 6. Valider la sécurité mise en œuvre Il faut donc identifier : – Les éléments à protéger et leur valeur (celle de leur reconstruction), – La probabilité de d’occurrence, Observatoire Technologique 15
  • 18. Référentiel e-Société – Les coûts de protection. En particulier, comme on peut le voir dans la figure 1.1, le niveau de sécurité est un compromis entre le coût de reconstruction de l’information et celui de la mise en œuvre de la sécurité des systèmes d’information. Il faut ajouter que la perte d’une information peut également engendrer des conséquences quant à la confiance que les utilisateurs ont dans le système d’information. Ceci est d’autant plus important si l’application se tourne vers les des données touchant directement les citoyens. F IG . 1.1 – Compromis entre la sécurité et le coût. Observatoire Technologique 16
  • 19. Référentiel e-Société 1.2 Efficacité économique Description abrégée gpl Efficacité économique Description Les objets liés à la mise en œuvre de la cyber-administration sont évalués sur la base de leur efficacité économique. Un budget est estimé pour la première année ainsi qu’un coût de fonctionnement pour les années suivantes. Un plan de financement est établi afin de déterminer les sources des fonds. Sur la base des coûts et des bénéfices évalués ainsi que du montant à investir, le pourcentage de retour sur investissement (ROI) est estimé. Le but n’est pas de sélectionner le meilleur retour sur investissement mais de trouver l’alternative la plus rationnelle économiquement. Types d’objet Projets ou investissements envisagés en particulier dans des tech- nologies de l’information et de la communication pour des projets de cyber-administration. Objets de réfé- Projets informatiques décrits d’après le modèle 3a de la CGPP (voir rence plus bas) qui est complété pour tenir compte des bénéfices citoyen et non quantifiables. Risques – Le manque de prise en compte des aspects financiers dans un projet cyber-administratif peut conduire à des investissements sous optimaux au point de vue économique. – Les éléments futurs sont parfois 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) ne 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 à dispo- sition de locaux ne sont pas pris en compte ou sous estimés dans l’analyse. Mesures Mesurable en pour-cent (ROI) ou en termes absolus. Pour un ROI, une valeur de 100% indique que les gains escomptés couvrent les dépenses engagées. Les bénéfices non tangibles monétairement sont évalués sur l’échelle -2, -1, 0, +1, +2. Aspect métier aucun Niveaux aucun d’abstraction Compétence Responsables budgétaires et financiers. Commission de gestion du portefeuille de projets. Pré-requis aucun Observatoire Technologique 17
  • 20. Référentiel e-Société 1.2.1 Explications Dans une proposition de projet touchant à la cyber-administration il est important de connaître le rapport du profit retiré par rapport à l’investissement engagé. Cette fraction est appelée “retour sur investissement” et permet d’évaluer la pertinence d’attribution de fonds d’un point de vue purement financier. Il est important de souligner que cette dimension doit être comprise comme un moyen de mettre en évidence l’alternative la plus efficace économiquement. Le but n’est pas nécessairement de dégager un profit ou une diminution de coûts à tout prix par la mise en œuvre d’un objet cyber-administratif. Le calcul du retour sur investissement se fonde sur les principes d’une analyse coût- bénéfice (anglais cost-benefit analysis ou CBA). Le but d’une telle approche est d’amé- liorer les décisions faites en terme d’allocation des ressources financières. La période de temps sur laquelle porte le calcul correspond au cycle de vie du système envisagé, 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 changements (statu quo). L’identification, la description et l’estimation des bénéfices et coûts doit être faite de la façon la plus rigoureuse possible. Le niveau de détail de l’analyse dépend de l’objet examiné : un grand projet, complexe et coûteux sera détaillé plus finement qu’un projet de 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 évaluant leur importance sur une décrite plus bas. Les coûts déjà encourus dans le passé ou les bénéfices déjà réalisés ne doivent en aucun cas être considérés. De façon très simplifiée le retour sur investissement est défini pour une période don- née comme la somme des profits actualisés du projet, c’est-à-dire les revenus moins les coûts, divisé par les fonds investis dans le projet. Les étapes d’une analyse coût-bénéfice qui conduira à calcul du retour sur investissement 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 les 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 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 Observatoire Technologique 18
  • 21. Référentiel e-Société 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. 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. 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é actuellement (juin 2002) à 1.5% en fonction notamment du taux d’intérêt du marché. 10. 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. 11. 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 le calcul du retour sur investissement. 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. Observatoire Technologique 19
  • 22. Référentiel e-Société 1.2.2 Eléments de calcul A l’aide des données du tableau 7 repris de la procédure CGPP (commission de gestion du portefeuille de projets) ci-dessous et de la formule donnée au point 9 plus haut, calcu- ler les bénéfices et les coûts annuels actualisés. Ceux-ci permettent de calculer le retour sur investissement du projet considéré. Tableau du retour sur investissement (A) Bénéfices annuels actualisés (B) Coûts annuels actualisés Rapport bébéfices/coûts = A/B Retour sur investissement = (A-B)/Fonds % demandés × 100 Bénéfices non quantifiables Dans les éléments bugétés pour les différentes alternatives il faut égalament tenir compte des frais de formation des collaborateurs(-trices) et des locaux qui seront occupés s’ils ne travaillent pas dans l’organisation. Tableau 7 CGPP — Synthèse des coûts et retour sur investissement Exercice : 2002 2003 2004 2005 2006 2007 Total Coût du projet : Financement par la Confé- dération : Financement par d’autres partenaires publics : Financement privé : Coût net pour l’Etat : Coût de fonctionnement : Coût total : Recettes prévues (nou- velles/supplémentaires) : Economies prévues, ré- duction de charge : Dépenses évitées : Bénéfice citoyen : Total des économies : Bilan annuel : Bilan cumulé : Bénéfice citoyen : décrire et quantifier la valeur annuelle estimée du projet pour les citoyens. Ceci inclut la diminution des frais liés aux activités avec l’Etat de nature privée ou professionnelle. Par exemple, les frais de transport, la diminution des temps d’attente, la prise de temps sur l’activité professionnelle, l’affranchissement, etc. Observatoire Technologique 20
  • 23. Référentiel e-Société Bénéfices non tangibles : décrire les bénéfices liés au projet qui ne peuvent pas être chiffrés monétairement dans les rubriques précédentes. Evaluer l’importance de chacun de ces bénéfices sur l’échelle -2, -1, 0, +1, +2. 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 Observatoire Technologique 21
  • 24. Référentiel e-Société 1.3 Impact sur la complexité Description abrégée sdz Impact sur la complexité Description Tout objet ayant un impact direct ou indirect sur la cyber- administration ou l’e-Société peut avoir un impact sur la complexité globale. Cet impact sur la complexité doit être mesuré. S’il est négatif, l’existence ou l’introduction de l’objet a tendance à augmenter la complexité globale. Ceci implique la recherche active de mesures de correction ou de confinement. S’il est positif, l’existence ou l’introduction de l’objet dans le contexte global de la cyber-administration ou de l’e-Société tend à réduire la complexité globale, Il doit alors être activement poursuivi et cette caractéristique doit être prise en compte dans la priorisation des projets. Types d’objet aucun Objets de réfé- (A) Impact positif. Application construite selon les principes sui- rence vants : – les bases d’information sont normalisées selon les règles de la protection des données, et construites et gérées en conformité ; – les systèmes d’information sont bâtis de manière à respecter la politique de sécurité ; – l’ensemble des objets techniques respectent des standards ou- verts là où ils existent pour les caractéristiques des composants du système considéré. (A) Impact positif. Standard technique ouvert (A) Impact négatif. “Legacy system” dont les drivers sont historiques et politiques plutôt que techniques. (B) Objet de type “Corps de métier”, corporation. Point de référence pour un impact positif : corps de métier qui est or- ganisé avec des organes représentatifs ou des partenaires attitrés pouvant conduire de manière autorisée un dialogue avec le projet Cyber@dmin. Exemple : chambre de commerce de l’industrie. As- sociation des avocats. Société d’ingénieurs. Point de référence pour un impact négatif : corps de métier pour lequel il n’existe pas d’organe représentatif. (B) Objet de type “Fournisseur de prestations de l’Etat”. Point de référence pour un impact positif : entreprise ayant conclu une convention avec un organe compétent de l’Etat qui engage les partenaires de la convention à travailler ensemble à la réalisation de leurs objectifs respectifs dans le but d’une collaboration à long terme. (B) Impact potentiellement négatif : objet de type “Unité administra- tive” dont les processus sont normalisés par un acteur externe ou indépendant (p. ex. Office fédéral). Observatoire Technologique 22
  • 25. Référentiel e-Société Risques Les risques liés à la complexité sont de deux ordres : – le projet de réalisation d’un nouvel objet ayant un impact négatif sur la complexité est difficile à conduire, à intégrer et à mener à son succès ; – la réalisation d’un objet ayant un impact négatif sur la complexité change les conditions cadre de toutes les réalisations en cours ou futures. Par exemple, un projet de loi imposant de nouvelles mesures contraignantes sur la gestion de l’information dans l’ad- ministration. Mesures Impact positif, neutre, négatif. L’évaluation de la mesure peut prendre en compte différents critères pour un seul objet ou différents critères selon les objets. Aspect métier Il est important d’évaluer la complexité inhérente du métier (ou des aspects du métier) dans lequel un objet s’insère, ainsi que le de- gré d’imbrication du système d’information sous-jacent avec d’autres métiers. Niveaux Premier niveau d’abstraction : ensemble des objets, tous types d’abstraction confondus. Second niveau d’abstraction : (A) objets dont les instances sont immergés dans un contexte socio- technique (applications, infrastructures, bases d’informations, sys- tèmes d’information) ; (B) objets dont les instances sont issues d’un contexte socio- politique (organisations ou assoications, organes de l’Etat, lois et directives, processus, acteurs de la société). Compétence (A) unité responsable administrativement de l’instance d’objet sou- mis à la mesure. (B) organe responsable politiquement de l’instance d’objet soumis à la mesure. Pré-requis (A) la responsabilité administrative doit être univoque. Ceci peut im- pliquer une délégation de la compétence organisationnelle de la part des autres acteurs qui emploient l’instance considérée. (A) en matière de sécurité, les contraintes énoncées doivent être in- tégrées dans une politique de sécurité définie et acceptée par l’unité responsable, ainsi que par les organes officiels responsables de la sécurité générale au niveau de l’Etat. 1.3.1 Explications Dans une administration publique, tout système d’information a (ou devrait avoir) au moins deux caractéristiques : (I) il est intégré à un environnement socio-technique (ceci s’applique à tout système d’informations) ; et (II) l’ensemble minimal des contraintes qui le définissent est issu d’un ensemble de directives et d’ordonnances que l’on doit pouvoir tracer directement au cadre légal en vigueur. A ceci s’ajoute une troisième caractéristique dont la portée varie selon le système, à Observatoire Technologique 23
  • 26. Référentiel e-Société savoir, (III) le métier auquel s’applique le système d’informations (santé, instruction pu- blique, sécurité, fiscalité, gestion du territoire, etc.). Les caractéristiques (II) et (III) définissent la complexité intrinsèque, ou la complexité inhérente non réductible, du système d’information considéré. A cette complexité s’ajoutent encore la complexité due à l’organisation des processus que supporte dans l’administration le système d’information considéré (par exemple la séparation des pouvoirs ou l’organisation des processus administratifs selon un orga- nigramme plus ou moins arbitraire issu de considérations politiques générales ou de politique interne de l’administration), ainsi que la complexité due aux méthodes et à la technologie employée pour mettre en œuvre le système et respecter ses contraintes non-fonctionnelles. Comme dans toute entreprise humaine, la contribution personnelle des concepteurs et des réalisateurs ajoute, à travers leur vision, leurs compétences, leur volonté, leur entente et leur discipline, une touche finale à la complexité du système d’information. La cyber-administration agit sur l’organisation et la vision. L’impact sur la complexité d’un objet cyber-administratif doit donc être mesuré en relation avec ces deux éléments. Ceci définit une dimension du Référentiel de la cyber-administration. D’autres dimensions mesurent l’impact sur la complexité de la technologie (qui peut être réduit par un effort de standardisation) ; des compétences et de la volonté (qui concernent la politique d’information) ; de la discipline (mesures relatives à la qualité, en particulier au niveau des concepts d’information). 1.3.2 Identification, localisation, cohérence Avant de pouvoir appliquer une mesure, conformément à une dimension, il faut identifier le sujet (objet ou projet) que l’on désire mesurer. Il peut s’agir : d’un système d’information, d’une application ou d’un registre de données ; d’une loi ou d’une directive ; d’une organisation, d’un organe ou d’un groupe de per- sonnes ; d’une infrastructure ou d’une architecture ; etc. De plus, il faut (faudra) identifier les responsabilités liées au sujet et évaluer les aptitudes existantes (organisation, qualifi- cation, connaissances, maîtrise, etc.) à résoudre les problèmes primaires et secondaires qui sont liés à l’environnement du sujet. Ces informations sont des données qualitatives objectives. En outre, il faut pouvoir localiser le sujet en termes de temps/énergie et de flexibilité, c’est à dire d’un côté savoir où il se trouve dans son cycle de vie (existant vivant, existant en fin de vie, projet sans dotation, projet doté de ressources) ; et savoir dans quelle me- sure il s’appuie sur un besoin justifié et/ou sur une volonté politique ayant le pouvoir de s’imposer. Ces informations sont des données quantitatives objectives. Finalement, il faut mesurer la cohérence de son environnement et la contribution du sujet à cette cohérence, en termes de distance relative et de corrélations avec d’autres sujets du même type dans le même environnement. Ces données peuvent être subjectives. La figure 1.2 décrit le positionnement sur un cadran mettant en rapport la distance et les corrélations. Observatoire Technologique 24
  • 27. Référentiel e-Société F IG . 1.2 – Cadran Distance / Corrélations. Une fois le sujet identifié et localisé, considérons comme dimension l’impact de d’un objet correspondant sur la complexité. Le sujet peut être complexe de manière inhérente. Ceci aura un impact local et limité sur la complexité globale, dans la mesure où la complexité globale dépend d’une part de la contribution du sujet à la cohérence globale, d’autre part et si la cohérence est élevée, de la faculté de l’objet à partager ses propriétés avec, et à recycler ses propriétés envers, d’autres sujets de son environnement. Ces deux propriétés (partage et recyclage) n’ont pas forcément de contribution à la com- plexité inhérente du sujet, et inversement. On peut donc définir l’impact sur la complexité comme la position du sujet dans le cadran de la figure 1.3. F IG . 1.3 – Cadran Recyclage / Partage. Etant bien entendu que la réduction de la complexité est une priorité absolue dans tout développement technique de grande envergure. Observatoire Technologique 25
  • 28. Référentiel e-Société 1.4 Technologies Description abrégée Technologies Description Types d’objet Voir sous-dimensions Objets de réfé- Voir sous-dimensions rence Risques Voir sous-dimensions Mesures Maturité, Intégration, Appropriation et compétences, Développe- ment des applications, Standards et méthodologies. Aspect métier Voir sous-dimensions Niveaux Orientation objet, Ouverture des base de données, Qualifica- d’abstraction tion technique, Réutilisation/intégration des applications existantes, Méthodologie de développement, Technologie de développement, Standardisation architecture application (n-tiers), Standardisation communication informatique. Compétence Voir sous-dimensions Pré-requis Voir sous-dimensions 1.4.1 Explications L’administration dispose d’un patrimoine d’applications et d’infrastructures informatiques nombreuses, les unes récentes, les autres plus anciennes. Ce patrimoine, stratégique quant aux activités de l’administration, a une valeur économique considérable. Il a été bâti progressivement en s’appuyant sur des technologies hétérogènes, développées pour des besoins spécifiques, à des périodes et par des équipes différentes. Cela a conduit au système d’information actuel, constitué de différentes strates logicielles et architecturales avec des îlots métiers qui ne sont pas toujours capables de communiquer. Ce système d’information est inéluctablement amené à évoluer de part les modifications des technologies, des métiers de l’informatique et de l’environnement socio-économique. La mise en œuvre de la cyber-administration sera l’un de ces facteurs d’évolution. Pour des raisons de continuité, de coût, de temps et de complexité, il n’est toutefois pas en- visageable de rebâtir dans son ensemble le système d’information et de repartir sur des bases neuves et cohérentes. Il faut donc impérativement s’accommoder de cette hétéro- généité de façon durable et réaliser une intégration des différents composants présents et à venir sans toucher au coeur du dispositif métier de chacun d’eux. Le développement de la cyber-administration imposera de plus en plus le besoin de faire communiquer un grand nombre d’applications entre elles et donc de réaliser une intégra- tion des différentes briques logicielles et matérielles existantes. Mais le choix d’une tech- nologie dépasse largement ces considérations purement techniques, même si ces der- nières sont souvent essentielles. D’autres problématiques doivent être prises en compte dont nous livrons ici quelques idées force qui ne constituent que des pistes de réflexion. Elles font l’objet de l’étude que mène actuellement l’OT dans ce domaine et seront incor- Observatoire Technologique 26
  • 29. Référentiel e-Société porées au Référentiel e-Société au fur et à mesure de leur complétude. Ces probléma- tiques sont les suivantes : 1. Maturité. La prise en compte du niveau de maturité d’une technologie est un fac- teur de choix important. Jean-Michel Cornu dans son essai sur les technologies de demain décrit l’influence du degré de maturité sur la stratégie à aborder : “Les jeunes technologies innovantes sont imprévisibles, on ne peut que favoriser leur abondance. Les technologies en plein essor passent par des degrés d’ouverture variés. L’important est de savoir les situer. Si le passage d’une étape à l’autre est souvent imprévisible, on peut cepen- dant définir des stratégies pour chacune d’elles. Les technologies ma- tures présentent une évolution plus prévisible qui permet d’anticiper jus- qu’à un certain point des seuils d’usages.” Le degré de maturité est étroitement liée à la notion de cycle de vie. La connais- sance du cycle de vie d’une technologie permet de prendre en compte certains paramètres qui peuvent se révéler critiques lors du choix de celle-ci : niveau d’adop- tion, seuils d’usage, obsolescence, etc. 2. Intégration. Comme mentionné dans le préambule, l’intégration des briques logi- cielles et matérielles au sein d’un système d’information est un aspect essentiel d’une technologie, spécialement lorsque celle-ci est amenée à jouer un rôle trans- versal au sein du système. Quel est le degré d’intégration de la technologie envisa- gée avec celles déjà mises en oeuvre ? Cette technologie pourra-t-elle bénéficier à d’autres projets ? Quelles possibilités d’ouverture offre-t-elle ? Est-elle sensible aux facteurs d’échelle ? Les réponses à toutes ces questions devraient être prises en compte lors de toute réflexion préalable. 3. Appropriation et compétences. Le déploiement d’une technologie passe natu- rellement par la prise en compte des problématiques liées aux personnes respon- sables de leur mise en œuvre et de leur maintenance. Les questions qui sont rela- tives à ces problématiques sont à prendre en compte dans tous les cas : – Quelles sont les compétences disponibles en interne pour cette technologie ? – Une formation du personnel de développement et/ou d’exploitation est-elle né- cessaire ? – Risque-t-on d’être confrontés à la réticence de ce même personnel à changer ses habitudes en cas d’adoption d’une nouvelle technologie ? Toutes ces problématiques méritent d’être exposées plus en détails. Mais nous n’avons pour l’instant développé dans le Référentiel e-Société que celles touchant au développement de projets informatiques, aux standards et aux méthodologies : 4. Développement des applications. De part la nature très transversale de la cyber- administration, le développement d’applications, notamment au niveau des briques de base pourra dans bien des cas réutiliser les composants développés. Les projets de développement doivent donc obéir à un certains nombre de critères permettant une réutilisation optimale de ces composants. 5. Standards et méthodologies. Une condition essentielle pour la mise en place de la cyber-administration est une prise en compte de la transversalité au niveau des données et des processus (voir dimensions “transversalité des données” et “transversalité des processus”). Il y a deux démarches possibles pour le réaliser : – Par l’utilisation de standards ouverts. L’inconvénient des standards ouverts est qu’ils ne sont pas toujours largement utilisés et/ou implémentés dans les produits commerciaux. Cette solution reste cependant la plus flexible. Observatoire Technologique 27
  • 30. Référentiel e-Société – Par l’adoption d’un standard commun au sein de l’Etat. Cette variante as- sure une meilleure compatibilité entre les différentes entités mais elle est plus contraignante. Le standard commun peut être, bien sûr, un standard ouvert. La connectivité ne s’appuie cependant pas sur son ouverture mais sur sa généra- lisation au sein de l’Etat. Son ouverture permet une meilleure connectivité avec l’extérieur de l’Etat. Le choix effectué doit être renforcé par une méthodologie adéquate. Le problème est qu’actuellement l’administration n’a pas mis en place tous les standards et toutes les méthodologies souhaitables. Il n’a pas mis en place non plus de sys- tème d’assurance qualité pour vérifier leur application. Concrètement, en ce qui concerne la cyber-administration, il y aura donc deux phases dans son développement à moyen terme : – Transition - Choix méthodologique et standardisation. Pendant cette période il faudra orienter les standards et les méthodologies vers une ouverture sur les nombreux partenaires externes de l’administration. De même il faudra évaluer les projets existants et les projets qui vont démarrer pendant cette période. Les dimensions vont porter sur les projets - les dimensions de transition. – Fonctionnement selon les méthodologies et standards fixés ci-dessus. Pen- dant cette phase les choix seront effectués au niveau de la standardisation et de la méthodologie non pas pour chaque projet mais de façon globale en utilisant le Référentiel (sous-dimensions méthodologie et standards). Les sous-dimensions développées jusqu’ici sont regroupées en deux classes : – Dimensions de transition (pour les projets) : 1. L’orientation objet. 2. Ouverture des base de données (SGBD ouvert ou propriétaire). 3. Qualification technique (QoS : Quality of Service). 4. Réutilisation/intégration des applications existantes. – Dimensions sur méthodologie et standards : 5. La méthodologie de développement. 6. La technologie de développement. 7. Standardisation architecture application (n-tiers). 8. Standardisation communication informatique (selon standards internationaux). Références Jean-Michel Cornu, Internet, tome 1 : Les technologies de demain, 2002. En ligne URL http://www.fing.org/index.php?rubrique=cahiers. Observatoire Technologique 28
  • 31. Référentiel e-Société 1.4.2 Orientation objet Description abrégée tju Orientation objet Description Les projets de développement doivent utiliser une technologie orien- tée objet. Types d’objet Projet de développement Objets de réfé- Dans l’ordre croissant des préférences : rence 1. Aucune encapsulation 2. Modulaire avec la possibilité d’encapsulation des traitements 3. Modulaire avec type des données complexes ; encapsulation soit pour les traitements soit pour les données mais pas les deux dans la même entité 4. Objet ; encapsulation des données et traitements dans la même entité. Risques Complexité. C’est un risque seulement après un certain niveau, il est lié à la capacité humaine d’appréhender cette complexité. Mesures Axe ordinal sur lequel on propose une pondération selon le schéma suivant pour souligner l’avantage de la 3e et 4e option : 1 pour le type 1 (Aucune encapsulation) ; 2 pour le type 2 ; 4 pour le type 3 ; 6 pour le type 4 (Objet). A revoir avec le bénéficiaire du référentiel. Aspect métier aucun Niveaux Bas niveau. Le niveau "supérieur" porte sur le standard de dévelop- d’abstraction pement. Compétence Chef de projet Pré-requis aucun Observatoire Technologique 29
  • 32. Référentiel e-Société 1.4.3 Ouverture des bases de données Description abrégée tju Ouverture des bases de données Description Ouverture des bases de données Types d’objet Projet informatique Objets de réfé- Dans l’ordre croissant des préférences : rence 1. Fichier propriétaire, accès seulement par une application 2. Base de données ouverte 3. Base de données ouverte avec documentation Risques Mesures C’est un axe ordinal mais on peut imaginer une mesure pondérée Aspect métier aucun Niveaux Niveau bas, seulement pour les projets informatiques d’abstraction Compétence Chef de projet Pré-requis aucun Explications L’ouverture des bases de données implique un accès facile à la base avec une séman- tique attachée. On ne doit pas oublier l’accès du point de vue de la sécurité (mot de passe administrateur) et une documentation de la base sans laquelle les données sont très difficiles à exploiter (interpréter, importer etc.). Observatoire Technologique 30
  • 33. Référentiel e-Société 1.4.4 Qualification technique Description abrégée tju Qualification technique Description Chaque modification SI doit passer par une qualification technique y compris une analyse qualité de service (QdS) pour garder la priorité des systèmes critiques Types d’objet Tout projet SI Objets de réfé- Dans l’ordre croissant des préférences : rence 1. Sans une qualification technique et une analyse QdS 2. Avec une qualification technique et une analyse QdS Risques Congestion des ressources Mesures Dimension booléenne Aspect métier Chef de projet Niveaux aucun d’abstraction Compétence Pré-requis Système d’implémentation de la QdS Explications La qualification technique et la qualité de service (QdS) sont des notions vitales dans un réseau complexe comme celui de l’Etat. Dans un tel réseau on peut facilement surcharger le trafic sur un switch, sur un router ou sur un serveur à cause des différentes applications qui sollicitent en même temps ces ressources. L’impossibilité de prévoir et de concevoir un réseau complexe parfaitement adapté impose un contrôle qui peut être implémenté avec un système QdS. Une analyse du point de vue QdS fait l’inventaire des applications demandeuses et des ressources. Elle établit également une priorité dans le cas d’une concurrence sur les mêmes ressources. Par exemple, pendant une votation, l’application “votation on-line” doit avoir une priorité de traitement plus grande que les applications “office de la navi- gation” pour les inscriptions ou les radiations des bateaux on-line pour le transport des données sur le réseau cantonal. Les possibilités de quantification sont les suivantes : – A sans = -1 et avec = 1, – sans = 0 et avec = 1. Pour les projets qui présentent une modularité et pour lesquelles ont peut appliquer une analyse par module on peut aussi imaginer que la mesure pour le projet est une somme pondérée des mesures de chacun des modules, les pondérations étant attribuées en fonction de l’importance de chaque module. Observatoire Technologique 31
  • 34. Référentiel e-Société 1.4.5 Réutilisation des applications Description abrégée tju Réutilisation des applications Description Les nouvelles applications doivent intégrer au maximum les fonc- tionnalités viables déjà existantes. Types d’objet Projets informatiques Objets de réfé- Seuls les extrêmes sont faciles à préciser : rence – Sans aucune intégration – Application type “wraper” Cette dimension étant assez “continue” du point de vue des valeurs, il est difficile d’imaginer d’autres objets de référence. Risques Le risque essentiel est lié au manque de fiabilité des applications dû aux problèmes potentiels de compatibilité. En principe ce risque est directement proportionnel au degré de réutilisabilité. C’est un coût qu’on doit payer pour récupérer les anciennes applications. Mesures La mesure sur cet axe est continue. Elle est proportionnelle au de- gré d’intégration des applications déjà existantes. On peut ainsi dé- finir un pourcentage calculé comme le rapport des fonctionnalités contenues dans les anciennes applications par celles nouvellement développées. Il faut préciser qu’il n’y a pas de valeur 100% intégration : il y aura toujours une valeur ajoutée par la nouvelle application. Par contre on peut très bien avoir une valeur de 0%. Aspect métier aucun Niveaux Bas niveau. Il peut être appliqué pour un objet générique pour me- d’abstraction surer le degré dans lequel il s’appuie sur des autres éléments déjà existants. Compétence Chef de projet Pré-requis aucun Explications Les applications existantes sont très nombreuses dans l’administration genevoise et une grande partie apportent des gains élevés de productivité. Ces applications sont souvent bien maîtrisées par les utilisateurs qui en apprécient les fonctionnalités. Leur réutilisa- tion permet parfois de réduire les coûts de développement si le coût d’intégration est suffisamment réduit. La mesure s’appuie sur la liste, pondérée ou non, des fonctionnalités du nouveau sys- tème. Dans cette liste on prend en compte les fonctionnalités qui sont encore assurées par les vielles applications intégrées dans le nouveau système. Le pourcentage final P peut être calculé avec la formule m n P = pk / pi k=1 i=1 Observatoire Technologique 32
  • 35. Référentiel e-Société où m le nombre des fonctionnalités assuré par les anciennes applications intégrées, pk pondération, n le nombre des fonctionnalités, pi pondération. Si on considère les fonctionnalités également importantes toutes les pondérations sont égales et la formule devient P = m/n avec m et n comme ci-dessus. Observatoire Technologique 33
  • 36. Référentiel e-Société 1.4.6 Méthodologie de développement Description abrégée tju Méthodologie de développement Description Tout projet doit être conforme avec la méthodologie SI de l’Etat de Genève Types d’objet (A) Tout projet SI. (B) Tout autre objet. Objets de réfé- (A) Dans l’ordre croissant des préférences : rence 1. SI conçu sans méthodologie 2. SI conçu avec une méthodologie “propriétaire” mais documen- tée 3. SI conçu avec une méthodologie connue, sur le plan global mais pas adopté par l’Etat de Genève 4. SI conçu avec la méthodologie de l’Etat de Genève Un peut aussi envisager d’introduire entre les deux derniers cas des méthodologies d’organismes partenaires (confédération, UE). (B) Dans l’ordre croissant des préférences : 1. Objet conçu sans standard 2. Objet conçu d’après un standard “propriétaire” mais docu- menté 3. Objet conçu d’après un standard connu, sur le plan global mais pas adopté par l’Etat de Genève 4. Objet conçu d’après un standard de l’Etat de Genève La même remarque que plus haut s’applique. Risques Diminution du contrôle sur le projet/produit, spécialement au cours du temps Mesures (A), (B) C’est un axe ordinal mais on peut imaginer une pondération. Aspect métier aucun Niveaux (A) Niveau bas. Ce principe peut être appliqué dans d’autres do- d’abstraction maines. (B) En plus on peut envisager le respect pour les standards de l’Etat en général (cas B). Compétence Chef de projet Pré-requis (A) Une méthodologie SI à l’Etat de Genève. Sans son existence, on ne peut utiliser que les trois premiers objets de référence. (B) L’existence de standards à l’Etat de Genève. Explications La méthodologie représente le savoir-faire formalisé qui assure une approche uniforme pour différents thèmes. Elle doit être perçue comme utile et efficace dans la communauté Observatoire Technologique 34
  • 37. Référentiel e-Société qui doit l’utiliser pour être acceptée. Pour les systèmes informationnels (SI) la méthodologie ne doit pas être confondue avec le langage de spécification technique/fonctionnelle ou avec la technologie. L’avantage essentiel est le “langage commun” établi entre les acteurs et dans le temps (voir maintenance, développement). Il ne faut pas oublier aussi l’expérience incorporée dans la méthodologie. Pour tenter de mesurer cet aspect on différencies les deux objets suivants. – (A) Le cas du projet SI. Pour un projet SI la mesure est l’attribution de la valeur selon le cas (voir le tableau partie (A)). – (B) Le cas de l’objet générique. Les standards, en général peuvent être appliqués à des problèmes très pointus. Un objet complexe peut donc facilement impliquer diffé- rents standards pour les parties qui le composent. Un objet O à mesurer doit être dé- composé en plusieurs sous-objets Oi auxquels on applique des standards différents. Cette décomposition doit déterminer le poids pi de chaque sous-objet par rapport à l’objet. L’attribution pour chaque sous-objet auquel un seul standard s’applique est me- suré par l’attribution d’une valeur selon le tableau ci-dessus (cas (B)). Pour trouver la valeur V (O) pour l’objet O on applique la formule suivante : n V (O) = V (Oi ) · pi i=1 où n est le nombre des sous-objets dans l’objet. Dans le cas des objets/sous-objets qui doivent respecter plusieurs standards en même temps, on peut aussi imaginer une pondération de chaque standard à respecter psk n ni V (O) = V (Oi ) · pi · psk i=1 k=1 où n est le nombre des sous-objets dans l’objet, ni le nombre de standards à respecter pour le sous-objet Oi , psk = 0 si le standard k n’est pas respecté. Selon la politique définie par le CTI les valeurs 1, 3, 5, 6 peuvent être modifiées pour marquer une différence plus nette entre un objet qui respecte un standard de l’Etat de Genève et un objet qui ne respecte aucun standard, par exemple. Les valeurs sont donc une proposition à évaluer par le bénéficiaire du modèle, selon ses besoins. Observatoire Technologique 35
  • 38. Référentiel e-Société 1.4.7 Technologie de développement Description abrégée tju Technologie de développement Description La nécessité de diviser les problèmes complexes afin de pouvoir les gérer correctement doit être prise en compte par la technologie de développement qui doit inclure le concept d”’isolation de problème”. Types d’objet Technologie standard Objets de réfé- Dans l’ordre croissant des préférences : rence 1. Aucune encapsulation 2. Modulaire avec la possibilité d’encapsulation des traitements 3. Modulaire avec type des données complexes ; encapsulation soit pour les traitements soit pour les données mais pas les deux dans la même entité 4. Objet ; encapsulation des données et traitements dans la même entité Risques Complexité trop importante et impossible à prendre en compte. Mesures Axe ordinal sur lequel on propose une pondération pour souligner l’avantage de la 3e et 4e option : 1 pour le type 1 (Aucune encapsu- lation) ; 2 pour 2 ; 4 pour 3 ; 6 pour 4 (Objet). Aspect métier aucun Niveaux aucun d’abstraction Compétence Comité de méthodologie et de standardisation Pré-requis aucun Explications Vu la complexité, au sein de l’administration, des problèmes concernant le développe- ment et l’environnement des applications, la nécessité de diviser les problèmes com- plexes afin de pouvoir les gérer correctement est évidente. La technologie de dévelop- pement doit donc inclure le concept d”’isolation de problème”. Cette isolation peut se faire au niveau des données, au niveau des traitements ou aux deux niveaux à la fois. Historiquement, le développement a commencé à mettre à disposition une isolation pour les traitements (modularité des programmes), puis une isolation pour les données (types complexes des données) et finalement une isolation pour les données et les traitement simultanément (les objets). La technologie choisie doit offrir la dernière variante, conçue pour la solution “objet” ou similaire, l’important étant d’offrir le concept d’encapsulation (données et traitements). Une fois cette technologie choisie, il faut prévoir des mécanismes pour contrôler son application dans les projets, habituellement au travers d’un plan d’assurance qualité. Observatoire Technologique 36
  • 39. Référentiel e-Société 1.4.8 Architecture applications Description abrégée tju Architecture applications Description Tout changement de standard de développement doit imposer une architecture par couches. Types d’objet Standard de développement Objets de réfé- Dans l’ordre croissant des préférences : rence 1. 1 tiers : pas de concept serveur 2. 2 tiers : client/serveur 3. n tiers : (p. ex. présentation/serveur application/serveur don- nées) Risques Coût de la maintenance/développement, indépendance des fournis- seurs du framework des différentes couches. Mesures Axe ordinal mais on peut imaginer une pondération. Aspect métier aucun Niveaux Niveau bas, seulement pour les standards développement. d’abstraction Compétence Comité de standardisation Pré-requis aucun Explications La stratification des architectures d’application concourt, en premier lieu à l’indépendance vis-à-vis des fournisseurs de serveurs, framework ou autre, ainsi qu’à l’efficience du trai- tement des données (spécialisation comme serveur base de données pour stockage des données, serveur application pour la logique métier ou buisiness logic). Prenons le cas d’une architecture 3-tiers : Client / Logique métier (serveur d’application) / Base de données (serveur de base de données). Un changement de serveur de base de données de MS SQL Server vers DB2 n’est pas ressenti par le client, mais unique- ment par la partie du serveur application qui assure la connexion avec ORACLE. Aucun changement ne se fait du coté client. Pour les standards qui présentent une modularité et pour lesquels ont peut appliquer une analyse par module on peut aussi imaginer que la valeur du standard est une somme pondérée des valeurs de ses modules, les pondérations étant attribuées en fonction de l’importance du chaque module. Observatoire Technologique 37
  • 40. Référentiel e-Société 1.4.9 Standardisation des communication Description abrégée tju Standardisation des communication Description Tout changement de standard de communication doit tenir compte des standards de communication suisses et internationaux. Types d’objet Standard de communication informatique Objets de réfé- Dans l’ordre croissant des préférences : rence 1. Standard propriétaire (exemple NetBEUI) 2. Standard Confédération 3. Standard international (IEEE) Risques Exclusion dans le cas d’un seul protocole ou coût pour paquet des protocoles alternatifs. Mesures Axe ordinal, mais on peut imaginer une pondération. Aspect métier aucun Niveaux Niveau bas d’abstraction Compétence Comité de standardisation Pré-requis aucun Explications L’interopérabilité est la clé de chaque système informationnel. Une bonne interopérabi- lité des SI passe par la communication des données. La complexité de la communica- tion dans l’administration genevoise consiste dans la multitude des acteurs avec pour beaucoup d’entre eux des configurations particulières (hardware, protocoles, progiciels, langues, etc.). Agent X Agent Y Langue XY niveau sensible Langue XY Application X Application Y Protocole communication données XY niveau sensible Protocole communication données XY Materiel X Materiel X Selon les éléments ci-dessus on voit les deux niveaux sensibles où la compatibilité est requise : 1. les protocoles de communication, 2. la langue de communication. 3. Du point de vue technologique le protocole de communication est très important pour assurer l’interopérabilité. La variété des agents oblige l’Etat de Genève à offrir : Observatoire Technologique 38
  • 41. Référentiel e-Société 1. Un protocole de communication très répandu (TCP/IP par exemple), 2. Plusieurs protocoles de communication en même temps pour assurer la compa- tibilité avec les interlocuteurs (IPsec, PPTP, L2TP par exemple). Dans ce cas les différents protocoles offrent la même fonctionnalité au même niveau mais ils sont mis à disposition pour des raisons de compatibilité. La deuxième variante est plus coûteuse (coût de maintenance, sécurité) mais plus ou- verte tandis que la première est moins chère mais plus restrictive. Pour les standards qui présentent une modularité et pour lesquels ont peut appliquer une analyse par module on peut imaginer que la valeur du standard est une somme pondéré des valeurs de ses modules, les pondérations étant attribuées en fonction de l’importance du chaque module. Selon la politique définie par le CTI les pondérations peuvent être modifiées pour dimi- nuer la différence entre un standard suisse et un standard international en fonction des objectives du bénéficiaire. Les valeurs sont donc une proposition à évaluer par le bénéfi- ciaire du modèle, selon ses besoins. Observatoire Technologique 39
  • 42. Référentiel e-Société 1.5 Politique d’information Description abrégée sdz Politique d’information Description Mesurer la contribution d’un projet au processus de conduite de la cyber-administration dans le domaine de régulation et de coordina- tion, en se basant sur son aptitude à communiquer. Types d’objet Projets métier Objets de réfé- aucun rence Risques Difficulté ou volonté à réorganiser le processus de production en fonction des besoins et des ressources globales de l’environnement. Mesures Note de 0 à 8 décomposée selon les quatre aspects du processus d’information global : – politique d’information générale du projet métier (0 à 2 points) ; – informer globalement (0 à 2 points) ; – s’informer globalement (0 à 2 points) ; – intégrer l’information (0 à 2 points). Aspect métier S’applique à tous les métiers. Niveaux aucun d’abstraction Compétence Service d’information du CTI ; OT Pré-requis Ressources et organisation de l’environnement (déploiement du sous-modèle CA dans l’organisation de projet et au niveau supérieur aux projets) pour l’accompagnement des projets métiers en matière de politique d’information globale. 1.5.1 Explications Le développement de la cyber-administration à Genève se fera à travers deux processus. D’une part, le processus de conduite, au niveau stratégique, définira les lignes directrices et les priorités. D’autre part le processus de développement sera constitué de multiples projets topiques situés pour la plupart dans les départements et les unités de l’adminis- tration. Afin d’accomplir des objectifs globaux, des mécanismes de régulation et de coordination seront mis en place, dont le référentiel fait partie. La régulation et la coordination reposent cependant tous les deux sur une communication et une information adaptées aux besoins du projet global dans son environnement. L’aptitude des projets et de leurs responsables à s’informer, à informer et à intégrer les informations reçues dans un processus de développement adapté aux besoins globaux, deviendra un facteur critique de réussite de la cyber-administration. Observatoire Technologique 40
  • 43. Référentiel e-Société 1.5.2 Acteurs, rôles et types d’échanges Considérons un projet métier en cours de réalisation et immergeons le dans le contexte de la cyber-administration. Du point de vue de l’administration, les acteurs sont répartis dans la partie hachurée de la figure 1.4. F IG . 1.4 – Principe d’organisation de la cyber-administration. L’ensemble des acteurs directement ou indirectement concernés, ainsi que leurs relations sont représentés dans le tableau ci-dessous. Observatoire Technologique 41