Guide Gestion des projets informatiques au sein de … · CP IT Rôle de chef de projet informatique IT-PM Gestion de projets informatiques

Département fédéral de l’environnement

des transports, de l’énergie et de la communication DETEC

Office fédéral des routes OFROU

Office fédéral des routes OFROU

Bruno Frey

Adresse postale : 3003 Berne

Emplacement : Mühlestrasse 2, 3063 Ittigen

Tél. +41 58 463 34 76

[email protected]

www.astra.admin.ch

Mühlestrasse 2, 3063 Ittigen Standortadresse: Mühlestrasse 2, 3063 Ittigen Postadresse:

Guide Gestion des projets informatiques au sein de l’OFROU Précisions et concrétisations sur HERMES 5

O383-1389 Information sur les documents

Date de création / date de révision : 17.02.2016

Etat : en cours de travail / en cours d’examen / terminé

Auteurs : membres permanents de l’OFROU B. Frey, C. Käser (mandant), D. Schreier (Stoupa & Partners AG)

Participants : M. Maeder, B. Joss, M. Jungo, T. Siegrist, L. Junker, comité SIP, Division N

Approbation : Chef de division DG + direction de l’OFROU

Nombre de pages : 53

Liste des modifications

Version Date Auteurs Remarques

1.0 25.08.2014 Frb Validation par la direction de l’OFROU

1.1 04.12.2014 Frb Modification de l’interlocuteur RM / QM

1.2 18.02.2015 Frb Modifications du système de rapport à l’aide du cockpit-TIC de la Confédération (suppression du rapport sur l’état du projet informatique), précision du rôle RM / QM, modifications des interlocuteurs et prise en compte de la nouvelle organisation de l’OFROU à partir du 1.1.2015

1.3 16.09.2015 Frb Nouvelles directives du Conseil fédéral pour les grands projets informatiques : évaluation préalable à l’approbation des grands projets informatiques.

1.4 17.02.2016 Frb Remplacement de la liste des résultats par le procès-verbal de vérification (projet HERMES 5), ajout du chapitre relatif à la gestion des exigences informatiques, adaptation du rôle de chef de projet conformément à la décision de la direction, remplacement du graphique relatif à la mise en place du système SIPD.

O383-1389 / Guide gestion des projets informatiques au sein de l'OFROU

2/53

But de ce document

Ce document sert de guide, d’ouvrage de référence et de document de base pour s’informer sur la gestion des projets informatiques au sein de l’Office fédéral des routes (OFROU). Le contenu de ce document n’est pas exhaustif et sera complété régulièrement.

Table des matières

1 Introduction

L’introduction décrit des aspects généraux comme le volume et le contenu, les objectifs, les directives et le champ d’action ainsi que les conditions régissant l’utilisation de ce guide.

2 Catégorisations et types de projets informatiques au sein de l’OFROU

Ce chapitre explique quels types de projets informatiques sont utilisés au sein de l’OFROU et de quelle manière ils sont catégorisés.

3 Gestion des projets informatiques au sein de l’OFROU

Ce chapitre explique les principaux concepts dans le cadre de la gestion des projets informatiques et montre le contexte de la gestion des projets informatiques. Ce chapitre contient la représentation des précisions et concrétisations de l’OFROU concernant HERMES 5. C’est le chapitre central de ce guide.

4 Thèmes voisins

La gestion de projets informatiques interagit toujours avec d’autres domaines voisins comme par exemple la gestion de l’architecture informatique, la gestion des exigences informatiques ou la gestion des risques informatiques. Ce chapitre donne des informations importantes sur la gestion de ces thèmes et renvoie à des informations et des outils complémentaires.

5 Interlocuteurs

Les principaux interlocuteurs dans le cadre de la gestion des projets informatiques et des thèmes voisins sont énumérés ici avec leurs coordonnées.

6 Informations complémentaires

Ce chapitre contient des renvois à des documents complémentaires et à des informations sur la dénomination des documents et la structure de stockage.

7 Annexe

L’annexe contient des documents sur les règles relatives à l’adaptation de projets informatiques en cours à la philosophie du présent guide et comprend les représentations des organisations de projet génériques pour les projets informatiques importants, moyens et petits.

8 Liste des sources

La liste des sources énumère les sources référencées dans ce guide.


3/53

Groupes cibles

Le présent document s’adresse à toutes les personnes participant aux projets informatiques de l’OFROU. Il est cependant principalement destiné au chef de projet.

Remarque préliminaire

Le présent guide Gestion des projets informatiques au sein de l’OFROU repose sur la méthode de gestion des projets informatiques HERMES 5 de l’UPIC (voir UPIC 2014, HERMES 5).

Pour que ce texte soit plus facile à lire, le guide utilise la forme masculine. La forme féminine est bien évidemment toujours incluse.


4/53

Table des matières

1. Introduction ............................................................................................................................... 8

1.1. Volume et contenu du guide ....................................................................................................... 8

1.2. Situation de départ et objectifs ................................................................................................... 8

1.3. Expériences ................................................................................................................................ 8

1.4. Directives et champ d’application ............................................................................................... 8 1.4.1. Directives de base ...................................................................................................................... 8 1.4.2. Directives du Conseil fédéral ...................................................................................................... 9 1.4.3. Directives du SG-DETEC ........................................................................................................... 9 1.4.4. Directives de la direction de l’OFROU ........................................................................................ 9

1.5. Conditions préalables à l’utilisation du guide ............................................................................. 9

1.6. Formations .................................................................................................................................. 9 1.6.1. Formation sur HERMES 5 et sur le guide de gestion des projets informatiques de l’OFROU .. 9 1.6.2. Offres de formation continue de l’OFPER et de l’UPIC ............................................................ 10

2. Catégorisations et types de projets informatiques au sein de l’OFROU .......................... 11

2.1. Catégorisation du projet ........................................................................................................... 11 2.1.1. But de la catégorisation des projets ......................................................................................... 11 2.1.2. Évaluation de la complexité du projet ....................................................................................... 11 2.1.3. Évaluation de l’importance du projet ........................................................................................ 11 2.1.4. Catégorisation du projet informatique ...................................................................................... 12

2.2. Types de projets informatiques au sein de l’OFROU ............................................................... 13

3. Gestion des projets informatiques au sein de l’OFROU .................................................... 14

3.1. Généralités sur la gestion des projets informatiques ............................................................... 14 3.1.1. Définition d’un projet informatique (projet IT) ........................................................................... 14 3.1.2. Contexte d’un projet informatique ............................................................................................ 14 3.1.3. Champ d’action de la gestion des projets informatiques .......................................................... 14 3.1.4. Cycle de vie d’un système informatique ................................................................................... 15 3.1.5. Modèle de phases .................................................................................................................... 15 3.1.6. Intégration d’un projet dans le portefeuille de projets .............................................................. 16

3.2. Organisation du projet .............................................................................................................. 16

3.3. Les rôles des projets informatiques .......................................................................................... 17 3.3.1. Introduction ............................................................................................................................... 17 3.3.2. Rôles pertinents pour le projet informatique dans l’organisation permanente ......................... 17 3.3.3. Rôles de l’organisation du projet .............................................................................................. 20

3.4. Facteurs de succès .................................................................................................................. 28

3.5. Jalons et « quality gates » ........................................................................................................ 29

3.6. Séances de lancement des phases ......................................................................................... 34

3.7. Modules .................................................................................................................................... 35

3.8. Gestion des scénarios au sein de l’OFROU ............................................................................. 36

3.9. Modèles et outils ....................................................................................................................... 36 3.9.1. Modèles HERMES spécialement modifiés pour l’OFROU ....................................................... 36 3.9.2. Modèles spécifiques à l’OFROU .............................................................................................. 36 3.9.3. Outils ......................................................................................................................................... 36

4. Thèmes connexes .................................................................................................................. 37

4.1. Contrôle de gestion (ICO) / Gestion des portefeuilles informatiques (IT-PPM) ....................... 37 4.1.1. Interfaces avec la gestion des portefeuilles-contrôle de gestion.............................................. 37 4.1.2. Données financières de l’informatique ..................................................................................... 37


5/53

4.1.3. Outils ......................................................................................................................................... 38

4.2. Gestion des risques informatiques ........................................................................................... 38 4.2.1. Outils ......................................................................................................................................... 38 4.2.2. Examens des risques ............................................................................................................... 38 4.2.3. Examen des opportunités ......................................................................................................... 38

4.3. Gestion de l’architecture informatique ...................................................................................... 38 4.3.1. Introduction ............................................................................................................................... 38 4.3.2. Informations et outils de l’OFROU ............................................................................................ 38 4.3.3. Modèles .................................................................................................................................... 38

4.4. Sécurité informatique et protection des données informatiques .............................................. 39 4.4.1. Principes ................................................................................................................................... 39 4.4.2. Informations et outils ................................................................................................................ 40 4.4.3. Modèles .................................................................................................................................... 40

4.5. Droit informatique et acquisitions informatiques ....................................................................... 40 4.5.1. Facteurs de succès critiques .................................................................................................... 40 4.5.2. Planification prévoyante des acquisitions sur l’ensemble du cycle de vie du système informatique ........................................................................................................................................... 41 4.5.3. Conception du contrat .............................................................................................................. 43 4.5.4. Informations et outils ................................................................................................................ 43 4.5.5. Modèles .................................................................................................................................... 44 4.5.6. Acquisition de connaissances .................................................................................................. 45

4.6. Exploitation informatique .......................................................................................................... 46 4.6.1. Réflexions fondamentales ........................................................................................................ 46 4.6.2. Modèles .................................................................................................................................... 46

4.7. Gestion des exigences informatiques ...................................................................................... 46

5. Interlocuteurs .......................................................................................................................... 47

5.1. Centre de compétences pour la gestion des projets informatiques de l’Office fédéral des routes OFROU....................................................................................................................................... 47

5.2. Controlling informatique ............................................................................................................ 47

5.3. Finances ................................................................................................................................... 47

5.4. Gestion de l’architecture informatique ...................................................................................... 48

5.5. Sécurité informatique ................................................................................................................ 48

5.6. Droit et acquisitions informatiques au sein de l’OFROU .......................................................... 48

5.7. Gestion des exigences informatiques ...................................................................................... 48

6. Informations complémentaires ............................................................................................. 49

6.1. Informations complémentaires de l’OFROU ............................................................................. 49

6.2. Marquage des documents ........................................................................................................ 49

6.3. Structure de classement ........................................................................................................... 49

7. Littérature et sources ............................................................................................................. 50

8. Annexe ..................................................................................................................................... 51

Annexe 1 : organisation générique du projet pour les petits projets informatiques .............................. 51

Annexe 2 : organisation générique du projet pour les projets informatiques moyens et importants .... 52

Annexe 3 : règles relatives à l’adaptation de projets informatiques en cours à la philosophie du présent guide 53


6/53

Index des illustrations

Illustration 1 : catégorisation du projet .................................................................................................. 12 Illustration 2 : du projet à l’application informatique .............................................................................. 14 Illustration 3 : champ d’action de la gestion des projets informatiques ................................................. 14 Illustration 4 : cycle de vie d’un système informatique .......................................................................... 15 Illustration 5 : modèle de phases pour les projets informatiques de l’OFROU ..................................... 15 Illustration 6 : vue d’ensemble de l’organisation permanente et de projet de l’OFROU ....................... 16 Illustration 7 : vue d’ensemble globale des rôles de l’organisation du projet au sein de l’OFROU ...... 20 Illustration 8 : récapitulatif global des phases, jalons, phases de lancement obligatoires .................... 29 Illustration 9 : lancements des phases obligatoires lors de la réalisation d’un projet informatique ...... 34 Illustration 10 : modules HERMES 5 ..................................................................................................... 35 Illustration 11 : différenciation entre le compte d’investissement et de résultat .................................... 37 Illustration 12 : processus de sécurité selon HERMES et P05 ............................................................. 39 Illustration 13 : processus d’analyse des besoins sécuritaires selon le DETEC ................................... 39 Illustration 14 : projet éléphantesque à l’objectif principal défini ........................................................... 42 Illustration 15 : projet éléphantesque divisé en objectifs partiels avec des packs de prestations ........ 42 Illustration 16 : acquisition de connaissances dans le domaine du droit et des marchés publics ........ 45

Index des tableaux

Tableau 1 : évaluation de la complexité du projet ................................................................................. 11 Tableau 2 : évaluation de l’importance du projet .................................................................................. 11 Tableau 3 : types de projets informatiques ........................................................................................... 12 Tableau 4 : types de projets informatiques ........................................................................................... 13 Tableau 5 : rôles pertinents pour le projet informatique dans l’organisation permanente .................... 17 Tableau 6 : examinateur spécifique à l’OFROU .................................................................................... 22 Tableau 7 : rôles de l’organisation de projet précisés et concrétisés concernant HERMES 5 ............. 22 Tableau 8 : nouveaux rôles définis par l’OFROU .................................................................................. 26 Tableau 9 : jalons et points de contrôle / quality gates de l’OFROU .................................................... 30 Tableau 10 : description des entretiens obligatoires de lancement des phases .................................. 34 Tableau 11 : précisions et concrétisations des modules ...................................................................... 35


7/53

Index des abréviations

CD Chef de division de l’OFROU OFROU Office fédéral des routes OFCL Office fédéral des constructions et de la logistique DG Division Affaires de la Direction CDF Contrôle fédéral des finances OFPER Office fédéral du personnel FBV Secteur Acquisitions et contrats de l’OFROU GEVER / Fabasoft Logiciel standard pour le traitement électronique des processus et dossiers dans l’administration publique GL Direction SG-DETEC Secrétariat général du Département fédéral de l’environnement, des

transports, de l’énergie et de la communication HERMES, HERMES 5 Méthode de gestion des projets pour l’informatique, les prestations, les services et l’organisation développée par l’administration fédérale suisse ICO Contrôle de gestion informatique UPIC Unité de pilotage informatique de la Confédération IT Technologie de l’information, informatique CP IT Rôle de chef de projet informatique IT-PM Gestion de projets informatiques IT-PPM Gestion de portefeuilles informatiques Système IT Système informatique CP Rôle de chef de projet QG Quality Gate SI Informatique stratégique OFROU Supp. Suppléant TBD to be defined (à définir) CSP Chef de sous-projet DETEC Département fédéral de l’environnement, des transports, de l’énergie et de la communication WIsB Directives du Conseil informatique de la Confédération relatives à la sécurité informatique au sein de l’administration fédérale


8/53

1. Introduction

L’introduction décrit le volume et le contenu, la situation de départ et les objectifs, les expériences faites, les directives et le champ d’application ainsi que les conditions pour l’application de la présente version du guide.

1.1. Volume et contenu du guide

Ce guide décrit les précisions et concrétisations de l’OFROU sur HERMES 5. Les contenus d’HERMES 5 eux-mêmes ne sont intégrés à ce guide que dans la mesure où ils sont nécessaires ou utiles pour comprendre lesdites précisions et concrétisations.

1.2. Situation de départ et objectifs

Depuis 2010, l’OFROU dispose de son propre guide consacré à la gestion des projets informatiques (IT-PM) pour concrétiser et préciser HERMES. La nouvelle version 5 d’HERMES a entraîné de profonds changements méthodologiques si bien que ce guide a dû être actualisé en conséquence. En guise d’exigence minimale, ce guide doit garantir une approche uniforme et assurer la qualité des résultats des projets informatiques. L’objectif de ce guide est de mettre à disposition un document d’aide pour appliquer les précisions et concrétisations de l’OFROU relatives à HERMES 5. Ce document vise à instaurer en permanence un langage commun dans le domaine de la gestion des projets informatiques.

1.3. Expériences

Le contenu de ce document repose principalement sur les expériences des collaborateurs de l’OFROU, de l’Office fédéral des constructions et de la logistique (OFCL), de l’Unité de pilotage informatique de la Confédération (UPIC) et sur les expériences de l’environnement informatique en général (notamment les conférences portant sur les achats informatiques de 2012 et 2013). Des interviews ont été réalisées avec des architectes, des chefs de projets, l’OFCL ainsi qu’avec des représentants de l’OFROU dans les domaines et thèmes suivants : Informatique stratégique (SI), secteur Acquisitions et contrats, finances informatiques, exploitation informatique et gestion des risques informatiques.

1.4. Directives et champ d’application

1.4.1. Directives de base

Ce guide doit être utilisé de manière contraignante avec HERMES 5 dans le cadre de la gestion des projets informatiques au sein de l’OFROU, selon la hiérarchie suivante :

1. Guide sur la gestion des projets informatiques au sein de l’OFROU ;

2. HERMES 5.

Les écarts doivent être clarifiés et harmonisés avec le centre de compétences de gestion des projets informatiques de l’OFROU (voir chap. 5.1) et officialisés avec le mandant (spécialisé et informatique) du projet informatique. Les précisions et concrétisations décrites dans ce guide sur HERMES 5 s’appliquent au niveau du « projet informatique ».


9/53

1.4.2. Directives du Conseil fédéral

Selon les nouvelles directives du 1er juillet, les projets informatiques dont les coûts totaux dépassent 5 millions de francs sont soumis à une évaluation avant d’être approuvés. Dans le cadre de cette évaluation, des experts indépendants examinent la qualité des composantes de gestion et les facteurs contextuels pertinents du projet. Il en découle des recommandations à l’intention de l’autorité qui approuve le projet, recommandations qui doivent permettre de prendre des mesures d’amélioration suffisamment tôt ou d’éviter les projets problématiques. Les évaluations de projet sont ordonnées de manière centralisée par l’Unité de pilotage informatique de la Confédération (UPIC). Les responsabilités en matière d’approbation et de déroulement du projet appartiennent exclusivement aux responsables du projet et à la hiérarchie compétente de l’unité administrative concernée.

1.4.3. Directives du SG-DETEC

Outre ce guide, il convient de suivre la directive du service informatique du département d’avril 2014 relative au contrôle et au suivi des projets informatiques (cf. D. Maurer et D. Kilcher, 2014). Le responsable de la sécurité informatique (ISBO) et le responsable du controlling informatique interviendront dans l’organisation du projet afin de veiller au respect de cette directive.

1.4.4. Directives de la direction de l’OFROU

Le 26.04.2015, la direction de l’OFROU a approuvé la réglementation des responsabilités dans le cadre de la gestion des TIC. La réglementation en question est prise en compte dans ce guide.

1.5. Conditions préalables à l’utilisation du guide

L’utilisation de ce guide nécessite des connaissances préalables d’HERMES 5 et de l’application des techniques de gestion des projets.

1.6. Formations

1.6.1. Formation sur HERMES 5 et sur le guide de gestion des projets informatiques de l’OFROU

La direction de l’OFROU a pris la décision suivante concernant la formation le 25.08.2014 :

Le chef de projet, le chef de projet spécialisé et le chef de projet informatique n’ayant pas suivi de cours HERMES doivent impérativement suivre le cours HERMES 5 Foundation (2 jours). Ce cours présuppose les connaissances transmises lors du cours consacré aux bases d’HERMES 5 (1 jour). La participation au cours consacré aux bases n’est pas un prérequis.

Le chef de projet, le chef de projet spécialisé et le chef de projet informatique déjà formés selon HERMES 2003/2005 doivent impérativement suivre le cours HERMES 5 de mise à jour (1 jour).

Les cours mentionnés sont proposés par l’Office fédéral du personnel (OFPER) et sont disponibles aussi bien en allemand qu’en français. En plus de l’offre de cours de l’OFPER, le chef de projet, le chef de projet spécialisé et le chef de projet informatique actifs dans le cadre de projets informatiques de l’OFROU doivent suivre des formations spécifiques au guide de gestion des projets informatiques de l’OFROU. Ce cours transmet les précisions et concrétisations de l’OFROU sur HERMES 5. Des connaissances d’HERMES conformément à ce qui est enseigné lors des cours de base, Foundation et de mise à jour susmentionnés sont un prérequis pour le cours consacré au guide sur la gestion des projets informatiques de l’OFROU (½ journée). Par conséquent, le besoin de formation minimum pour le chef de projet, le chef de projet spécialisé et le chef de projet informatique actifs dans le cadre de projets informatiques de l’OFROU est de 1,5 jour (cours de mise à jour HERMES 5 et cours sur le guide de gestion des projets informatiques de l’OFROU) ou de 2,5 jours (HERMES 5 Foundation et cours sur le guide de gestion des projets informatiques de l’OFROU).


10/53

Pour les mandants du projet, le cours HERMES 5 pour mandants (½ journée) est obligatoire. Il est recommandé que tous les autres collaborateurs du projet, y compris les spécialistes, participent au cours consacré aux bases d’HERMES 5 (1 jour).

1.6.2. Offres de formation continue de l’OFPER et de l’UPIC

Formation continue HERMES 5 : offre de l’Office fédéral du personnel (OFPER), site Internet

Offre de formation continue de l’Unité de pilotage informatique de la Confédération (UPIC), site Internet

http://www.epa.admin.ch/dienstleistungen/bildung/index.html?lang=de

http://www.isb.admin.ch/themen/methoden/01661/01664/index.html?lang=de

http://www.isb.admin.ch/themen/methoden/01661/01664/index.html?lang=de


11/53

2. Catégorisations et types de projets informatiques au sein de l’OFROU

Les paragraphes suivants décrivent le but et l’approche de la catégorisation des projets informatiques ainsi que les types eux-mêmes. Les types de projets informatiques utilisés au sein de l’OFROU seront ensuite présentés.

2.1. Catégorisation du projet

2.1.1. But de la catégorisation des projets

La catégorisation des projets doit indiquer au chef de projet la complexité et l’importance d’un projet informatique pour l’OFROU. A cet effet, le projet informatique est évalué en fonction de sa complexité et de son importance.

2.1.2. Évaluation de la complexité du projet

La complexité d’un projet informatique est évaluée sur la base de sa durée et de ses coûts de mise en œuvre. Ici, la complexité du projet est évaluée sur la base des critères « faible », « moyen » et « haut », selon les critères suivants :

Tableau 1 : évaluation de la complexité du projet

Critère Faible Moyen Haut

Durée de la mise en œuvre < 1 an 1 – 3 ans > 3 ans

Coûts de la mise en œuvre < CHF 200 000 < CHF 2 000 000 > CHF 2 000 000

Source : représentation propre

La catégorisation de la complexité du projet correspond à la cote la plus élevée des critères ci-dessus. Si la durée d’un projet informatique est par exemple inférieure à une année et les coûts sont de l’ordre de CHF 1 500 000, la complexité du projet entre dans la catégorie « Moyen ».

2.1.3. Évaluation de l’importance du projet

L’importance d’un projet est évaluée sur la base de l’analyse des risques / effets et de l’importance stratégique du projet informatique. Ici, l’importance du projet est évaluée sur la base des critères « faible », « moyen » et « haut », selon la classification suivante :

Tableau 2 : évaluation de l’importance du projet

Critère Faible Moyen Haut

Risques - Effets Au sein de la division OFROU A l’extérieur de l’OFROU

Importance stratégique Non présent dans l’accord sur les prestations

Présent dans l’accord sur les prestations*

Très pertinent sur le plan stratégique


* La version actuelle du contrat de prestations est disponible dans GEVER / Fabasoft sous le chemin d’accès suivant :


12/53

2 – 21 – 211 Convention de prestations DETEC Schéma directeur, convention de prestations et mandat de prestation DETEC-OFROU

Convention de prestations DETEC-OFROU (2005-04012) La catégorisation de l’importance du projet correspond à la cote la plus élevée des critères ci-dessus. Si l’impact des risques se limite à l’OFROU, alors que le projet informatique est d’une grande importance stratégique, l’importance du projet doit être classée dans la catégorie « haut ».

2.1.4. Catégorisation du projet informatique

Selon les critères et la classification de la complexité et de l’importance du projet, il est ensuite possible de définir la catégorie du projet informatique en utilisant la matrice suivante.

Illustration 1 : catégorisation du projet


Le tableau suivant décrit les catégories de projets selon le concept technique Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO). Le concept est repris pour les projets informatiques.

Tableau 3 : catégories de projets informatiques

Catégorie de projet

Description

Projet important La complexité et l’importance du projet sont moyennes ou hautes. Les projets TIC clés de la Confédération doivent toujours être gérés comme des projets importants indépendamment de leur classement.

Projet moyen

Le projet est hautement complexe et faiblement important ou inversement, ou moyennement complexe et moyennement important.

Petit projet

Le projet est faiblement ou moyennement complexe. Il est également faiblement ou moyennement important.

Source : sur la base de Käser (2014, Rapport Concept spécialisé Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO), p. 29)

Faible Moyen Haut

Complexité du projet

Faible

Moyen

Haut

Importance du projet

http://idm.astra.admin.ch/fsc/openmx.asp?mx=COO.2045.100.2.2073530&vd=0&name=Leistungsvereinbarung%20UVEK-ASTRA%20(2005-04012)

http://idm.astra.admin.ch/fsc/openmx.asp?mx=COO.2045.100.2.2073530&vd=0&name=Leistungsvereinbarung UVEK-ASTRA (2005-04012)


13/53

2.2. Types de projets informatiques au sein de l’OFROU

L’OFROU différencie trois types de projets informatiques reposant sur les principes décrits dans le concept technique Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO). Ces types sont décrits dans le tableau suivant.

Tableau 4 : types de projets informatiques

Type de projet informatique

Description

Premières mises en service

Développement et mise à disposition de l’infrastructure de base, des composants / produits standard ainsi que des développements individuels dans la première version productive = release 1.0

Introductions Il s’agit principalement de défis organisationnels qui sont conduits comme des projets propres lorsqu’un cercle d’utilisateurs important (à partir de 30 personnes) doit utiliser le système de manière opérationnelle sur différents sites et / ou dans différentes organisations.

Développements Extensions logicielles avec des fonctions, données ou services / interfaces supplémentaires. Des projets de développements sont mis en place en cas de releases impliquant un volume financier de plus de CHF 400 000, à partir d’une durée de mise en œuvre de plus de 12 mois, avec plus de deux interfaces avec les systèmes périphériques (dont au moins une interface avec des systèmes périphériques externes) ou lorsque sont effectuées des modifications pertinentes pour la sécurité.

Source : sur la base de Käser (2014, concept technique Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO), p. 29 s.)


14/53

3. Gestion des projets informatiques au sein de l’OFROU

Il s’agit du chapitre central du guide, dans la mesure où il décrit les précisions et concrétisations essentielles de l’OFROU sur HERMES 5. Le chapitre ci-après précise et explique les termes utilisés dans le contexte de gestion de projets informatiques.

3.1. Généralités sur la gestion des projets informatiques

3.1.1. Définition d’un projet informatique (projet IT)

Un projet informatique est caractérisé par les critères suivants au sein de l’OFROU. Il

possède des buts mesurables et clairement définis ainsi qu’un objectif principal ;

est limité tout du moins en termes de temps, de finances et de personnel ;

est unique de par ses tâches et conditions ;

comprend des travaux interdisciplinaires et communs à plusieurs organisations.

« Ne sont pas considérés comme projets les achats de licences ou de macros dans des programmes standard comme Excel ou Access dont les coûts totaux sont inférieurs à CHF 50 000 si la preuve probante est documentée de manière plausible lors de l’achat. » (Käser 2014, concept technique Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO), Bericht Fachkonzept IT-PPM/ICOp. 29)

3.1.2. Contexte d’un projet informatique

Les lignes suivantes expliquent comment les projets informatiques voient le jour et doivent être développés. On a au départ un avant-projet. Ce dernier peut donner naissance à un ou plusieurs projets (informatiques) qui, le cas échéant, débouchent sur une application informatique à exploiter. La représentation suivante montre sommairement ce développement. Illustration 2 : du projet à l’application informatique


3.1.3. Champ d’action de la gestion des projets informatiques

La gestion des projets informatiques intervient dans les projets informatiques selon l’illustration suivante. Illustration 3 : champ d’action de la gestion des projets informatiques

Avant projet(planification

financière)

Applicationinformatique

Projet(S) informatique(s)


financière)



Gestion des projetsinformatique


15/53


3.1.4. Cycle de vie d’un système informatique

Un système informatique : « Se compose de l’infrastructure de base, des produits / composants standard ainsi que des développements individuels. Il s’agit d’une vue d’ensemble des coûts sur le cycle de vie d’une seule application métier (couche 3), comprenant le projet et l’utilisation (exploitation, maintenance et assistance)» (Käser 2014, concept technique Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO), principe 3, p. 24). L’illustration suivante montre le cycle de vie d’un système informatique.

Illustration 4 : cycle de vie d’un système informatique


3.1.5. Modèle de phases

Le modèle de phases des projets informatiques de l’OFROU correspond à celui d’HERMES 5. Il est composé de quatre phases. L’illustration suivante montre le modèle de phases et les jalons aux bords des phases.

Illustration 5 : modèle de phases pour les projets informatiques de l’OFROU

Source : extrait des phases de l’UPIC (2014, HERMES 5, vues sur le projet)

Les projets informatiques du type « Déploiement » (voir chap. 2.2) commencent directement avec la phase Conception. Vous n’avez pas obligatoirement besoin de la phase de réalisation. La phase de déploiement peut être réduite en fonction des besoins.

« Chaque fin de phase est déterminée par un jalon qui met en évidence la décision concernant la suite des opérations. Les jalons correspondent à des quality gates, auxquelles l’état du projet et la qualité de sa planification et de son exécution sont vérifiés. Y est aussi effectuée la coordination avec les stratégies et objectifs généraux de l’organisation permanente. L’atteinte des jalons est vérifiée au moyen de listes de contrôle, qui sont complétées par des critères spécifiques au projet. En supplément aux jalons de fins de phase, il existe des jalons spécifiques au scénario qui agissent également comme quality gates, par ex. pour l’architecture et la sécurité. Le reporting est réalisé au fil des phases et des jalons, selon un contenu et une fréquence se conformant aux prescriptions de l’organisation permanente.


financière)



Cycle de vie d’un système informatique

Initialisation Conception Réalisation Déploiement


16/53

Le modèle de phases constitue aussi une base pour le pilotage financier du projet. Lors de l’approbation d’une phase, les moyens (finances, personnel, infrastructure) nécessaires pour la phase suivante sont débloqués par le mandant. » (UPIC 2014, HERMES 5, Phases et jalons)

3.1.6. Intégration d’un projet dans le portefeuille de projets

L’intégration d’un projet informatique dans le portefeuille de projets (Cockpit TIC de la Confédération) se fait au sein de l’OFROU pour les deux cas de figure suivants : - s’il s’agit d’une première mise en service, avec l’octroi du mandat d’initialisation du projet ;

- s’il s’agit d’une introduction ou d’un développement, avec l’octroi du mandat de projet (voir Käser 2014, concept technique Gestion des portefeuilles informatiques / contrôle de gestion (IT-PPM/ICO), p. 33)

3.2. Organisation du projet

L’organisation de projet est divisée en plusieurs niveaux : pilotage, conduite et exécution. Les principaux responsables au niveau du pilotage sont les mandants, les membres du comité de pilotage et l’organe de contrôle. Les responsables principaux au niveau de la conduite sont le chef de projet, le chef de projet spécialisé, le chef de projet informatique et les membres du comité spécialisé ; au niveau de l’exécution, il s’agit des spécialistes (techniques et informatiques). L’organisation permanente comprend d’une part la direction spécialisée et informatique, d’autre part les organes d’assistance et de prescription de l’OFROU en matière de contrôle de la gestion informatique, d’architecture informatique, de gestion de la qualité et des risques, de sécurité informatique, de gestion des exigences informatiques et dans le domaine des achats et des contrats. Le lien qui existe entre l’organisation de projet et l’organisation permanente est décisif. Les représentants de l’organisation permanente sont intégrés dans l’organisation de projet par l’organe de contrôle du projet. Illustration 6 : vue d’ensemble de l’organisation permanente et de projet de l’OFROU

Source : sur la base de l’UPIC (2014, HERMES 5, rôles)


17/53

3.3. Les rôles des projets informatiques

3.3.1. Introduction

Une distinction est faite entre les rôles de l’organisation de projet et ceux de l’organisation permanente. Ce guide ne décrit que les rôles qui sont pertinents dans le cadre des projets informatiques au sein de l’OFROU. Ce principe se rapporte à la responsabilité et aux compétences des rôles. Les tâches, compétences et responsabilités (répartition des rôles relatifs aux tâches et aux compétences) de l’organisation permanente s’appliquent conformément à la réglementation des signatures et des compétences. Les rôles peuvent être complétés en fonction des besoins spécifiques au sein du projet informatique. Chaque complément notable doit être consigné et justifié par écrit. Une personne peut en principe aussi assumer plusieurs rôles à la fois. Il faut garantir l’absence de conflits au niveau des rôles.

3.3.2. Rôles pertinents pour le projet informatique dans l’organisation permanente

Les rôles de l’organisation permanente ont notamment des tâches dépassant le champ d’application de la gestion des projets informatiques et qui ne sont pas abordées dans le présent guide. Les rôles de l’organisation permanente ne sont donc pas décrits complètement.

Le tableau suivant décrit les rôles de l’organisation permanente pertinents pour les projets informatiques et leur responsabilité dans le cadre du traitement des projets informatiques.

Tableau 5 : rôles pertinents pour le projet informatique dans l’organisation permanente

ORGANISATION PERMANENTE Rôles des organes d’assistance et de prescription de l’OFROU pertinents pour les projets

informatiques

Organes d’assistance et de prescription de l’OFROU

Rôles pertinents pour le projet informatique, représentants du service

Gestion des exigences informatiques

Experts en analyse métier ; les coordonnées figurent au chap. 5.7 « Gestion des exigences informatiques », à la page 48.

Architecture informatique Responsable de l’architecture informatique de l’office

Contrôle de la gestion informatique

Responsable du contrôle de la gestion informatique (RCIT)

Sécurité informatique Responsable de la sécurité informatique (RSIT)

Acquisitions / contrats Juriste du secteur Acquisitions et contrats, responsable de l’organisation (juriste spécialiste des acquisitions et contrats informatiques) C’est en général l’OFCL qui se charge des acquisitions informatiques. L’OFROU n’effectue lui-même les acquisitions qu’avec une délégation de l’OFCL.

Gestion des risques et de la qualité

Le secteur Gouvernance informatique élabore le cahier des charges pour le gestionnaire de la qualité et des risques selon HERMES 5. Si besoin, le domaine spécialisé officie comme suppléant du mandant pour assurer le rôle de mandant du projet.

http://uveks1670.uvek.intra.admin.ch/fsc/fscdav/READONLY?OBJ=COO.2045.100.7.1209524&ax=COO.1.1001.1.38249&name=/COO.2045.100.7.1209524.url

http://uveks1670.uvek.intra.admin.ch/fsc/fscdav/READONLY?OBJ=COO.2045.100.7.1209524&ax=COO.1.1001.1.38249&name=/COO.2045.100.7.1209524.url


18/53


informatiques

Responsable de l’architecture informatique de l’office

Description sommaire Le responsable de l’architecture informatique de l’office dirige le tableau de bord de l’architecture informatique de l’OFROU. Il remplace le rôle de l’actuel architecte informatique de l’OFROU. Il garantit notamment la coordination sur l’ensemble de l’office entre les architectes en charge dans les différents domaines. Le responsable de l’architecture informatique de l’office peut aussi assumer le rôle d’architecte principal. C’est l’interlocuteur pour les questions liées à l’architecture et à l’état des examens pour les projets, les applications et les domaines techniques si aucun architecte principal n’est connu ou n’a été défini pour ce thème.

Responsabilité au cours d’un projet informatique

Garantir l’accompagnement adéquat des projets au niveau de l’architecture informatique et faire appel, au besoin, à des ressources externes

Informer le public spécialisé et les services supérieurs des résultats du domaine d’activités

Responsable du contrôle de la gestion informatique (RCIT)

Description sommaire Le RCIT est responsable de l’exécution de la méthode de contrôle de la gestion informatique de la Confédération au niveau de l’office. Il accompagne et contrôle toujours les projets informatiques de l’OFROU.


Conseiller sur les questions méthodologiques dans le cadre de la gestion des projets informatiques

Assister et instruire les chefs de projets pour le rapport de l’état du projet dans le Cockpit TIC de la Confédération

Former et assister les participants aux projets informatiques dans le domaine de la gestion des projets informatiques de l’OFROU

Informer chaque semestre la direction de l’OFROU de l’état des projets informatiques

Contrôler les rapports de phases, les résultats finaux des phases, les jalons et l’organisation de projets informatiques

Contrôler le respect de la gestion des projets informatiques au sein de l’OFROU conformément à ce guide

Contrôler l’exhaustivité et la transparence des messages d’état dans le Cockpit TIC de la Confédération en prenant en considération les informations financières pertinentes selon le rapport de gestion des portefeuilles informatiques, et élaborer un récapitulatif pour la direction de l’OFROU

Faire des recommandations pour les questions méthodologiques concernant la gestion des projets informatiques et le choix du scénario

Élaborer les demandes à l’attention de la direction de l’OFROU en cas d’éventuelles mesures globales dans le contexte de la gestion des projets informatiques

Communiquer au chef de projet et au mandant les constatations critiques menaçant fortement le succès du projet

Garantir la bonne mise en œuvre de la directive relative à l’examen et à l’accompagnement de projets informatiques par le service informatique du département (cf. Maurer & Kilcher 2014)


19/53


informatiques

Responsable de la sécurité informatique (RSIT)

Description sommaire Le RSIT assume les tâches de sécurité de l’information et de protection des données dans l’entreprise. Tel un examinateur, il garantit le respect des directives supérieures en matière de sécurité informatique dans le projet informatique.


Déterminer, évaluer et montrer les risques sécuritaires dans le domaine informatique conformément aux directives (méthodes, procédures, mesures)

Surveiller la mise en œuvre, le respect et l’efficacité des mesures de sécurité liées aux TIC (la sécurité des TIC englobe aussi les questions de protection des informations et des données)

Evaluer / examiner la compatibilité des projets informatiques en matière de sécurité informatique

Organiser et participer à l’inventaire, à la classification et à l’analyse des risques des biens à protéger (analyse des besoins de protection)

Conseiller et participer à la mise en œuvre des mesures de sécurité

Participer au contrôle de la mise en œuvre, du respect et de l’efficacité des mesures de sécurité

Veiller à ce que les processus de sécurité informatique du DETEC soient respectés

Garantir que les directives du Conseil fédéral concernant la sécurité des TIC dans l’administration fédérale soient intégrées dans les concepts

Communiquer au chef de projet et au mandant les constatations critiques menaçant fortement le succès du projet

Former et sensibiliser les utilisateurs, exploitants, développeurs et responsables de projet en matière de sécurité informatique

Garantir la bonne mise en œuvre de la directive relative à l’examen et à l’accompagnement de projets informatiques par le service informatique du département (cf. Maurer & Kilcher 2014)

Juriste du secteur Acquisitions et contrats (juriste spécialiste des acquisitions et contrats informatiques)

Description sommaire Le juriste spécialiste des acquisitions et contrats informatiques accompagne en permanence le projet informatique (de manière proactive). Il aide les participants au projet, examine et garantit que tous les achats et contrats dudit projet informatique respectent le droit en vigueur.


Accompagner le projet de manière permanente, proactive et régulière en ce qui concerne les questions juridiques

Conseiller et déterminer la procédure d’attribution et la forme contractuelle

Conseiller et informer les collaborateurs informatiques sur des expériences pratiques dans l’utilisation de composants concrets en matière de contrats et d’acquisitions avec création et gestion d’un recueil de composants et modèles contractuels

Examen de l’ordre d’acquisition et de tous les documents ainsi que du document 023 Conditions / cahier des charges, documents de l’offre, texte de la publication Simap, etc. juste avant un appel d’offres et l’évaluation

Contrôler les quality gates spécifiques à l’OFROU (cf. chap. 3.5)

Assister et définir les procédures d’attribution autorisées sur le plan juridique

Valider les documents de soumission et d’acquisition ainsi que la publication Simap

Participer aux négociations dans le cadre de la procédure d’attribution

Décider de l’exclusion d’un soumissionnaire des autres marchés

Valider le rapport d’évaluation et la publication d’adjudication dans Simap

Discuter et assister les éventuels débriefings pendant le délai de recours

Valider les contrats et les conventions pour signature

Participer à la prise de décision concernant la mise en soumission et à celle concernant l’adjudication dans le cadre du module « Acquisitions »


20/53

3.3.3. Rôles de l’organisation du projet

Les paragraphes suivants décrivent les rôles de l’organisation du projet. L’illustration suivante montre l’organisation de projet générique pour un projet informatique avec tous les rôles pouvant être occupés au sein de l’OFROU dans le cadre d’un projet informatique. Il faut veiller à garantir que les personnes occupant un rôle au sein de l’organe de contrôle du projet n’assument pas en même temps de rôle au niveau de l’exécution. Les rôles de gestionnaire de la qualité et des risques, d’architecte principal, de chef de projet informatique et de responsable SIPD peuvent au besoin être occupés par des personnes externes à l’OFROU sous la conduite de DG/Informatique. Tous les rôles obligatoires sont grisés. Les rôles entourés en gras non définis dans HERMES 5 sont les rôles spécifiques à l’OFROU. Les carrés de couleur situés dans le coin droit supérieur indiquent de quel point de vue du partenaire selon HERMES 5 (utilisateur, producteur, exploitant) les rôles peuvent être occupés. Certains rôles doivent impérativement être occupés par un collaborateur de l’OFROU. Ces derniers sont indiqués par la mention « OFROU » dans le coin supérieur droit. Illustration 7 : vue d’ensemble globale des rôles de l’organisation du projet au sein de l’OFROU


Les annexes 1 et 2 du présent document contiennent des représentations de l’organisation de projet générique pour les projets informatiques petits, moyens et importants.

Exécution

Conduite

Pilotage

Utilisateur Auteur Exploitant

Rôle spécifique à l’OFROU

(cadre en gras)

Mandant

Chef de projet

Chef de projet spécialisé

Spécialiste technique

Comité de pilotage

Membre du comité de pilotage

Spécialiste informatique

Assistance au projet

Comité spécialisé

Membre du comité spécialisé

Représentant des utilisateurs

Responsable d’application Business analyst

Développeur

Responsable de processus métier

Architecte informatique (architecte de la

solution)

Responsable SIPD

Responsable de test

Testeur

OFROU

Examinateur du projet

Gestionnaire de la qualité et des risques(rôle HERMES 5)

Architecte en charge

RCIT

Rôle obligatoire (grisé)

RSIT

Chef de projet informatique

Responsable d’exploitation(Chef de sousprojet Exploitation informatique)

Chef de projet Développement

Un rôle est affecté à l’un ou à plusieurs des partenaires de projet suivants:

Vue d’ensemble globale des rôles de l’organisation du projet au sein de l’OFROU

OFROU

OFROU

OFROU

Juriste Achats / contrats informatiques OFROU

OFROU

OFROU


21/53

Remarques relatives à la direction du projet dans les couches 3, 1 et 2 Projets informatiques de la couche 3 En ce qui concerne les projets de la couche 3, le rôle de chef de projet incombe à l’informatique et donc au chef de projet informatique. La suppléance du chef de projet est assumée par le chef de projet spécialisé. Projets informatiques des couches 1+2 Pour ce qui est des projets des couches 1+2 (poste de travail de la Confédération), la direction du projet est externe à l’OFROU. L’OFROU définit un chef de sous-projet issu du milieu informatique pour ses travaux.

Les listes suivantes montrent encore une fois les rôles définis par l’OFROU, les rôles d’HERMES 5 précisés ou concrétisés par l’OFROU et les rôles d’HERMES 5 également utilisés tels quels au sein de l’OFROU.

Rôles repris tels quels d’HERMES 5


Responsable d’application

Responsable de l’exploitation

Développeur


Responsable de processus de travail



Chef de sous-projet

Testeur

Responsable de test

Rôles d’HERMES 5 précisés ou concrétisés par l’OFROU

Mandant

Analyste métier

Responsable SIPD

Architecte informatique (architecte de la solution)

Chef de projet

Gestionnaire de la qualité et des risques

Nouveaux rôles définis par l’OFROU

Chef de projet spécialisé (est un chef de sous-projet)

RCIT

RSIT

Chef de projet informatique (est un chef de sous-projet)

Juriste spécialiste des acquisitions et contrats informatiques

Architecte principal (peut aussi être le responsable de l’architecture informatique de l’office si nécessaire)

Chef de projet en charge du développement (est un chef de sous-projet)


22/53

La suite du présent document décrit les rôles HERMES 5 précisés ou concrétisés par l’OFROU et les nouveaux rôles définis et décrits par l’OFROU. L’organe de contrôle spécifique à l’OFROU est également décrit.

Tableau 6 : organe de contrôle spécifique à l’OFROU

ORGANISATION DE PROJET Examinateur spécifique à l’OFROU

L’OFROU définit un organe de contrôle dans le cadre de l’organisation de projet. On y trouve les délégués de l’organisation permanente tels que le RSIT, le RCIT, etc. Il vérifie que les directives de l’organisation permanente ou du domaine spécialisé sont suffisantes dans le cadre du projet informatique.


Les rôles sont décrits intégralement pour plus de clarté, ce qui signifie que les descriptions contiennent les textes d’origine d’HERMES ainsi que les précisions et concrétisations de l’OFROU. Ces derniers éléments sont indiqués en bleu. Les noms des rôles HERMES 5 présentent une barre verte et ceux de l’OFROU une barre bleue.

Tableau 7 : rôles de l’organisation de projet précisés et concrétisés concernant HERMES 5

ORGANISATION DE PROJET Rôles précisés ou concrétisés spécifiques à l’OFROU

Mandant Rôle HERMES 5

Description sommaire Le mandant (ou donneur d’ordre) est responsable des résultats du projet et de l’atteinte des objectifs dans le respect des coûts fixés et des délais planifiés. Dans les petits projets informatiques, la responsabilité du pilotage et de la réception des résultats à livrer et des phases incombe au chef de division compétent. Dans les projets informatiques moyens et importants, le projet est représenté par le chef de division compétent au sein de la direction. La décision est toutefois du ressort de la direction de l’OFROU.

Responsabilité

Initier et piloter le projet informatique

Endosser la responsabilité générale du projet informatique et de l’atteinte des objectifs

Garantir que les objectifs du projet correspondent aux stratégies et aux prescriptions de l’organisation permanente

Mettre les ressources à disposition et en assurer une utilisation efficiente (finances, personnel, infrastructure)

Prendre en temps voulu les décisions concernant les propositions et les mesures

Désigner les membres du comité de pilotage et le diriger

Désigner le chef de projet

Désigner le gestionnaire de la qualité et des risques

Assurer une collaboration suffisante de l’unité spécialisée

Compétences

Compétence décisionnelle déléguée par l’organisation permanente

Octroi au projet de ressources humaines, financières et infrastructurelles

Communication des problèmes à l’organisation permanente

Approbation des demandes de projets pour tous les types de projet (première mise en service, introduction, développement) et examen des rapports périodiques d’avancement du projet dans le Cockpit TIC de la Confédération (conformément au calendrier de rapport et de contrôle de la gestion des TIC au niveau de la Confédération)


23/53

Analyste métier Rôle HERMES 5

Description sommaire L’analyste métier fait office d’interface entre l’utilisateur et l’auteur/l’exploitant. Il rassemble et priorise les exigences des utilisateurs sur la base des processus de travail, et les transforme en exigences pour le système. Elles servent de base à l’auteur et à l’exploitant pour la conception et l’exploitation du système informatique.

Responsabilité

Définir les processus de travail, rassembler l’ensemble des exigences et veiller à la participation des spécialistes, des représentants des utilisateurs ainsi que des responsables des processus de travail

Documenter systématiquement les résultats avec des méthodes adéquates

Communiquer les exigences aux services chargés de la suite des opérations

Assurer la gestion des exigences informatiques

Compétences

Peut accéder à toutes les informations nécessaires

Peut solliciter de l’aide auprès du secteur Gouvernance informatique si besoin est

Responsable SIPD Rôle HERMES 5

Description sommaire Le responsable de la sûreté et de la protection des données (SIPD) s’occupe des aspects de la sûreté de l’information et de la protection des données dans le projet.

Responsabilité

« Analyser et évaluer le besoin en matière de protection » (UPIC 2013, processus de sécurité)

« Élaborer et évaluer les mesures de protection » (UPIC 2013, processus de sécurité)

« Mettre en œuvre les mesures de protection dans la solution » (UPIC 2013, processus de sécurité)

« Réceptionner les mesures de protection » (UPIC, 2013, processus de sécurité)

Garantir la prise en compte et la mise en œuvre, dans le projet, des prescriptions de sûreté de l’information ainsi que des mesures de protection (contrôlé par le RSIT au sein de l’OFROU)

Favoriser la prise de conscience au sein du projet en matière de sûreté de l’information et de protection des données

Compétences

Peut accéder à toutes les informations du projet

Élaboration de prescriptions sécuritaires sur la gestion des données et des informations pendant le déroulement du projet

Architecte informatique (architecte de la solution) Rôle HERMES 5

Description sommaire L’architecte informatique développe l’architecture du système à réaliser. Il définit les composants du système et ses interfaces avec les systèmes périphériques.

Responsabilité

Il n’assume « pas » la responsabilité technique générale du projet informatique qui voit le jour. Ce rôle est assumé par le chef de projet informatique de l’OFROU.

Garantie de la conformité avec les normes et prescriptions architecturales, et réalisation de vérifications

Compétences

Compétence de donner des ordres


24/53

Chef de projet Rôle HERMES 5

Description sommaire Le chef de projet est chargé par le mandant de gérer le projet. Il est nommé et dirigé par celui-ci. Dans les projets informatiques de la couche 3 (voir. p. 24), le chef de projet est toujours le chef de projet informatique.

Responsabilité

Diriger le projet pour en atteindre les résultats avec les objectifs prévus (en termes de délais, de coûts et de qualité)

Assurer une utilisation efficiente et durable des moyens et des ressources

Gérer les rapports et informer, en fonction de la situation, l’organe de pilotage du projet de manière complète et régulière pour qu’il puisse assumer ses tâches de pilotage et de décision

Diriger les acteurs et garantir l’implication des parties prenantes autorisées

Assumer la gestion de la qualité et des risques

Impliquer à temps les organes de prescription et d’assistance pour satisfaire à leurs exigences

Définir les méthodes, pratiques et outils utilisés dans le projet en complément à HERMES et en assurer l’utilisation

Réaliser des acquisitions en tenant compte des prescriptions en vigueur

Exécuter les tâches de décision (aboutir à des décisions)

Exploiter la gestion des contrats afin de garantir la vue d’ensemble de l’état des contrats du projet à chaque instant

Exposer ou justifier par écrit les principaux changements dans l’organisation de projet ou au niveau des rôles, et, le cas échéant, obtenir l’approbation nécessaire auprès de la hiérarchie

Veiller à ce que les postes compris dans le programme d’acquisition du plan de gestion du projet soient harmonisés avec les données financières du domaine Informatique (rapport de gestion des portefeuilles informatiques / Cockpit TIC de la Confédération) (cf. chap. 4.1.2)

Élaborer des rapports d’état dans le Cockpit TIC de la Confédération selon les échéances du RCIT (conformément au calendrier de rapport et de contrôle des TIC au niveau de la Confédération)

Compléter et gérer les informations du projet dans le Cockpit TIC de la Confédération

Respecter les directives informatiques du département selon Maurer & Kilcher (2014), la directive relative à l’examen et à l’accompagnement de projets informatiques par le service informatique du département

Élaborer le mandat de projet

Élaborer tout au long du projet les demandes à la direction pour les rapports de phase pertinents en ce qui concerne les projets informatiques importants et moyens (demandes à l’attention du chef de division pour les petits projets informatiques)

Garantir le bon déroulement des quality gates spécifiques à l’OFROU

Communiquer les jalons à l’organe de contrôle quatre semaines avant l’examen et mettre à disposition les résultats à livrer (l’examen des quality gates dure deux semaines sauf si les résultats à livrer sont importants et nécessitent la remise de plus de 100 pages)

Compétences

Compétence budgétaire concernant l’utilisation des moyens octroyés pour la phase afin de remplir les activités qui lui ont été déléguées par le mandant (dans le respect du processus d’acquisition de l’OFROU)

Compétence décisionnelle dans le cadre défini avec le mandant

Compétence de donner des ordres (dans le cadre prescrit par le mandat de projet)

Division du projet en sous-projets en accord avec le mandant, désignation des chefs de sous-projet et délégation des tâches de direction


25/53

Gestionnaire de la qualité et des risques Rôle HERMES 5

Remarque Ce rôle doit obligatoirement être pourvu pour les projets importants (coûts totaux > CHF 5 millions) et pour les projets clés de la Confédération. Dans tous les autres types de projet, c’est le mandant qui décide de l’occupation du rôle. L’organe de contrôle du projet, l’architecte principal, le RSIT et RCIT couvrent une partie essentielle des tâches du gestionnaire de la qualité et des risques décrites selon HERMES 5 dans le cadre de leur fonction. Selon la directive du Conseil fédéral concernant le portefeuille et les projets des TIC dans l’administration fédérale, il n’est pas obligatoire de pourvoir le rôle de gestionnaire de la qualité et des risques pour les petits projets (coûts totaux < CHF 400 000 et coûts annuels < CHF 250 000) et pour les projets standard (coûts totaux < CHF 5 000 000). Lors de la décision par le mandant d’occuper ou non ce poste, il faut cependant prendre en considération le fait que l’organe de contrôle des projets de l’OFROU ne couvre pas toutes les tâches. La responsabilité de l’évaluation de l’état du projet et des prévisions ne peut notamment pas être assumée par l’organe de contrôle.



26/53

Tableau 8 : nouveaux rôles définis par l’OFROU

ORGANISATION DE PROJET Nouveaux rôles définis par l’OFROU

RCIT

Remarque Le RCIT est un rôle de l’organisation permanente qui est représenté dans l’organisation de projet en tant que membre de l’organe de contrôle du projet. Ce rôle est décrit dans le cadre des rôles pertinents pour les projets informatiques des organes de prescription et d’assistance de l’OFROU (cf. page Fehler! Textmarke nicht definiert.).

RSIT

Remarque Le RSIT est un rôle de l’organisation permanente qui est représenté dans l’organisation de projet en tant que membre de l’organe de contrôle du projet. Ce rôle est décrit dans le cadre des rôles pertinents pour les projets informatiques des organes de prescription et d’assistance de l’OFROU (cf. page Fehler! Textmarke nicht definiert.).

Chef de projet spécialisé (chef de projet suppléant) Rôle OFROU

Description sommaire Dans les projets informatiques, le chef de projet spécialisé veille à ce que le projet soit correctement mis en œuvre. Il est également le chef de projet suppléant.

Responsabilité

Assumer la responsabilité de l’exactitude et de l’exhaustivité des exigences techniques

Informer les services de coordination et de contrôle compétents au niveau technique, garantir leur intégration dans le projet

Élaborer le plan de projet avec le chef de projet en faisant participer les parties prenantes des domaines spécialisés

Piloter et coordonner les ressources spécialisées de l’office, des partenaires et prestataires

Acquérir les prestations spécialisées avec l’aide du responsable du projet informatique et assister le responsable du projet informatique lors de l’acquisition des prestations spécialisées

Analyser, contrôler et approuver les spécifications d’un point de vue technique

Définir les priorités techniques de la mise en œuvre

Optimiser et concrétiser les coûts et les avantages lors de l’acceptation des exigences

Contrôler et approuver les rapports de phase HERMES et les résultats du point de vue technique

Initier et conduire les processus internes et externes requis pour clarifier les objectifs spécialisés, les intérêts, les exigences et les conditions cadres

Assumer la responsabilité de l’implication des utilisateurs et de la conduite des groupes de suivi

Compétences

Compétence de direction spécialisée

Compétence de donner des ordres spécialisés (dans le cadre prescrit par le mandat de projet)

Chef de projet informatique Rôle OFROU

Description sommaire Dans les projets informatiques, le chef de projet informatique (anciennement « Chef de projet Développement informatique ») veille à ce que le projet soit correctement mis en œuvre sur le plan technique. Il est également le chef de projet. Il est en outre l’interlocuteur principal des membres de l’organe de contrôle des projets dans le domaine technique (à savoir RSIT et architecte principal).

Responsabilité

Assumer la responsabilité technique globale (à la place de l’architecte informatique selon HERMES)

Informer les services de coordination et de contrôle compétents au niveau informatique, garantir leur intégration dans le projet


27/53


Élaborer le plan de projet avec le chef de projet en tenant compte des conditions cadres informatiques

Piloter et coordonner les ressources informatiques de l’office, des partenaires et des prestataires

Acquérir les prestations informatiques avec l’aide du chef de projet spécialisé et assister le chef de projet spécialisé lors de l’acquisition des prestations spécialisées

Analyser les solutions et les contrôler sous l’angle de l’intégration dans l’architecture existante

Analyser, contrôler et approuver les spécifications d’un point de vue informatique

Définir les priorités techniques de la mise en œuvre

Optimiser et concrétiser les coûts et les avantages lors du choix de la solution informatique

Contrôler et approuver les rapports de phase HERMES et les résultats du point de vue informatique

Diriger sur le plan technique le développement de l’application métier

Diriger et élaborer les résultats HERMES dans la phase HERMES de déploiement

Négocier les accords de projet et les accords sur les prestations avec l’exploitant pour l’introduction des applications métier ainsi que l’accord de niveau de service pour l’exploitation en faisant participer le chef de projet spécialisé

Commander les infrastructures nécessaires puis surveiller la structure, la réalisation du mandat ainsi que le contrôle qualité de l’exploitant

Diriger les réceptions et réceptionner la documentation d’exploitation

Négocier les contrats d’assistance et de maintenance des logiciels avec les développeurs des applications métier

Garantir le passage correct des quality gates spécifiques à l’OFROU dans le domaine technique et méthodologique en impliquant le chef de projet spécialisé

Régler la cession en bonne et due forme à l’exploitation informatique et à la gestion des versions informatiques

Solliciter le concours de l’architecte principal pour les questions liées à l’architecture du système

Mettre en œuvre les directives et garantir le respect des consignes de l’organe de contrôle

Compétences

Compétence en gestion méthodologique et en technique informatique

Compétence de donner des ordres relevant de la technique informatique (dans le cadre prescrit par le mandat de projet)

Décisions pour une intégration optimale au niveau de l’exploitation de concert avec l’architecte principal

Juriste spécialiste des acquisitions et contrats informatiques Rôle OFROU

Remarque Le juriste spécialiste des acquisitions et contrats informatiques est un rôle de l’organisation permanente qui est représenté dans l’organisation de projet en tant que membre de l’organe de contrôle du projet. Ce rôle est décrit dans le cadre des rôles pertinents pour les projets informatiques des organes de prescription / d’assistance de l’OFROU (cf. page Fehler! Textmarke nicht definiert.).

Architecte principal Rôle OFROU

Description sommaire L’architecte principal vérifie que les directives des niveaux hiérarchiques supérieurs, notamment celles de l’organisation permanente de l’OFROU, sont respectées en ce qui concerne l’architecture informatique dans le projet informatique. Ce rôle doit être occupé dans tous les projets informatiques. Il est assumé par un architecte de l’office membre du comité en charge de l’architecture informatique de l’OFROU.

Responsabilité

Accompagner les projets affectés pour toutes les questions liées à l’architecture informatique

Si besoin est, élaborer / participer à la conception d’éléments de l’architecture du système

Superviser la mise en œuvre des architectures informatiques et des normes

Adapter les domaines attribués à la stratégie informatique de l’office

Adapter les architectures aux exigences

Si besoin est, identifier des exigences en fonction de la situation


28/53


Assumer potentiellement un rôle d’expert et de responsable dans différents domaines (SIG, IAM, systèmes en temps réel, systèmes de gestion, SAP, DWH/BI, SOA…)

Solliciter le concours d’experts (voir ci-dessus) lors des vérifications

Communiquer au mandant les constatations critiques menaçant fortement le succès du projet

Compétences

Imposer les directives (lois, Confédération, département, office, domaine) au moyen des processus de mise en conformité de l’architecture dans les projets concernés

Chef de projet Développement (est un chef de sous-projet) Rôle OFROU

Description sommaire Ce rôle peut être rattaché au mandataire ou au prestataire de service. Il s’agit d’un chef de sous-projet.


3.4. Facteurs de succès

Les facteurs de succès suivants sont essentiels pour la réussite d’un projet informatique non seulement à l’OFROU en ce qui concerne le pilotage, la conduite et l’exécution, mais aussi dans le cadre des actions des organes de prescription et des examinateurs de l’OFROU. Ils sont contraignants :

Pilotage - Toutes les ressources internes et tous les utilisateurs d’un projet informatique sont connus par leur

nom au moment de l’approbation du mandat d’initialisation du projet et du mandat de projet. L’engagement en temps voulu des ressources spécialisées désignées pour la prochaine phase doit être coordonné avec les personnes concernées et approuvé par écrit par l’organisation hiérarchique.

- Dans l’organisation de maintenance future, les structures, les processus ainsi que la responsabilité et les compétences des rôles pour l’exploitation de la solution à implémenter sont convenus entre l’organisation hiérarchique et le chef de projet avant la mise en exploitation. L’organisation chargée de la maintenance est formée à l’exploitation informatique de la nouvelle solution.

Conduite

- La planification des ressources et des moyens financiers est toujours actuelle et reflète l’état actuel du projet.

- La planification de chaque projet informatique de l’OFROU repose sur ce guide. Les écarts doivent être harmonisés au préalable avec le centre de compétences de gestion des projets informatiques de l’OFROU.

- La liste des objets livrables est disponible sous forme écrite. Le volume et le contenu des objets livrables à créer dans le cadre du projet informatique doivent être approuvés par le donneur d’ordre (ou par un responsable technique).

- Le niveau de détail de la structuration des phases de travail a été convenu entre le chef de projet / chef de projet spécialisé / le chef de projet informatique / le chef de sous-projet et le responsable technique.

- L’avancement de chaque phase de travail est présenté dans les rapports en cours conformément au niveau de détail défini lors de la planification.

Exécution - Les directives relatives aux délais, aux coûts, à la qualité, à la performance, au résultat et aux

risques sont satisfaites. - Les parties prenantes s’entendent sur la situation initiale, les conditions-cadre, les objectifs, le

contexte système et les exigences.


29/53

Organes de prescriptions et de contrôle - Les membres de l’organe de contrôle du projet ne se conçoivent pas seulement comme des

contrôleurs mais aussi comme des conseillers. - Les membres de l’organe de contrôle du projet se mettent d’accord dans les domaines connexes

et échangent leurs expériences.

3.5. Jalons et « quality gates »

Le guide de gestion des projets informatiques de l’OFROU repose sur les jalons du scénario « Système IT » d’HERMES 5.

L’illustration suivante montre les jalons à respecter dans le cadre des projets informatiques et les séances de lancement à réaliser. Le jalon Concept SIPD est regroupé avec le jalon Architecture du système au sein de l’OFROU. On trouve également le jalon Étude spécialisée. L’illustration montre par ailleurs le moment d’achèvement du résultat Mandat de projet. Les points symbolisent les séances de lancement devant obligatoirement être réalisés et un atelier.

Illustration 8 : récapitulatif global des phases, jalons, séances de lancement obligatoires

Source : sur la base de l’UPIC (2014, HERMES 5, scénario système IT)

Le degré de conformité des résultats à livrer est examiné aux différents jalons. Les « quality gates » sont les points de contrôle des jalons. Les points de contrôle spécifiques à l’OFROU sont complétés dans les listes de contrôle d’HERMES 5 relatives aux jalons. Les points de contrôle de l’organe de contrôle sont définis pour chaque phase.

Les listes de contrôle adaptées aux exigences de l’OFROU représentent l’outil central de contrôle aux jalons.

Le tableau suivant donne une vue d’ensemble des jalons et « quality gates ». Les précisions et concrétisations de l’OFROU sont toujours représentées en bleu dans le tableau.


30/53

Tableau 9 : jalons et points de contrôle / « quality gates » de l’OFROU

Initialisation

N° Tâche (responsabilité de la tâche)

Résultat du point de contrôle / quality gate OFROU (auteur du résultat)

Outils

1 Mandat d’initialisation du projet

1.1 Mandater et piloter l’initialisation (mandant)

selon HERMES 5

1.2 Décision concernant la pertinence de l’architecture du système (architecte principal)

Processus de mise en conformité de l’architecture (PDF)

1.3 Rapport d’examen des risques du mandat d’initialisation du projet (gestionnaire de la qualité et des risques)

Outil d’application Gestion opérationnelle des risques / projets informatiques (Excel)

1.4 Rapport d’examen du mandat d’initialisation (RCIT)

Procès-verbal de vérification du projet informatique (Excel)

2 Étude spécialisée

2.1 Rapport d’examen de l’étude spécialisée (RCIT et direction spécialisée)


2.2 Approbation du rapport de l’étude spécialisée (mandant)

Modèle de rapport d’étude spécialisée (Word)

3 Choix des variantes

3.1 Décision concernant la première évaluation des variantes architecturales (architecte principal)


3.2 Rapport d’examen des risques relatifs au choix de la variante (gestionnaire de la qualité et des risques)


3.3 Prendre la décision concernant le choix d’une variante (chef de projet)

selon HERMES 5

4 Approbation du projet

4.1 Rapport d’examen de l’analyse des besoins de protection (Schuban) (architecte principal, RSIT)

Processus de conformité architecturale (PDF)

Procès-verbal de vérification du projet (Excel)

Processus de sécurité selon HERMES et P05

4.2 Rapport d’examen de l’architecture informatique du mandat de projet (architecte principal)



4.3 Rapport d’examen du programme d’acquisition dans le mandat de projet (juriste spécialiste des acquisitions et contrats informatiques)


4.4 Rapport d’examen de la méthodologie de gestion des projets informatiques (RCIT)


4.5 Rapport d’examen des risques relatifs au mandat de projet (gestionnaire de la qualité et des risques)



31/53

4.6 Prendre la décision concernant l’approbation du projet (mandant)

selon HERMES 5

Conception



Outils

5 Développement agile

5.1 Prendre la décision concernant le développement agile avec SCRUM (chef de projet)

6 Concept SIPD et architecture du système

6.1 Rapport d’examen des risques relatifs à l’approbation du concept SIPD (gestionnaire de la qualité et des risques)


6.2 Rapport d’examen du concept SIPD (architecte principal, RSIT)



Processus de sécurité selon HERMES et P05

6.3 Approbation de l’architecture du système (architecte principal)


Architecture du système (Word)

6.4 Rapport d’examen des risques relatifs à l’architecture du projet (gestionnaire de la qualité et des risques)


6.5 Prendre la décision concernant l’architecture du système (chef de projet)

selon HERMES 5

7 Approbation de la phase

7.1 Rapport d’examen de l’architecture informatique Approbation de la phase (architecte principal)

Processus de mise en conformité de l’architecture (PDF) Procès-verbal de vérification du projet informatique (Excel)

7.2 Rapport d’examen du chapitre « Bases légales » du rapport de phase (juriste spécialiste des acquisitions et contrats informatiques)


7.3 Rapport d’examen du programme d’acquisition dans le plan de gestion de projet (juriste spécialiste des acquisitions et contrats informatiques)




7.5 Rapport d’examen des risques relatifs à l’approbation de la phase (gestionnaire de la qualité et des risques)


7.6 Prendre la décision concernant l’approbation de la phase (mandant)

selon HERMES 5


32/53

RÉALISATION



Outils

8 Réception provisoire

8.1 Rapport d’examen des risques relatifs à la réception provisoire (gestionnaire de la qualité et des risques)


8.2 Prendre la décision concernant la réception provisoire (chef de projet)

selon HERMES 5

9 Approbation de la phase

9.1 Rapport d’examen de l’architecture informatique Approbation de la phase (architecte principal)





9.3 Rapport d’examen des risques relatifs à l’approbation de la phase (gestionnaire de la qualité et des risques)


9.4 Prendre la décision concernant l’approbation de la phase (mandant)

selon HERMES 5

DÉPLOIEMENT



Outils

10 Réception de la migration

10.1 Rapport d’examen des risques relatifs à la réception de la migration (gestionnaire de la qualité et des risques)


10.2 Prendre la décision concernant la réception de la migration (chef de projet)

selon HERMES 5

11 Mise en service

11.1 Rapport d’examen des risques relatifs à la mise en service (gestionnaire de la qualité et des risques)


11.2 Prendre la décision concernant la mise en service (mandant)

selon HERMES 5

12 Réception

12.1 Rapport d’examen de l’architecture informatique Réception finale (architecte principal)


12.2 Rapport d’examen de la réception (juriste spécialiste des acquisitions et contrats informatiques)


12.3 Rapport d’examen des risques liés à la réception (gestionnaire de la qualité et des risques)



33/53

12.4 Prendre la décision concernant la réception (chef de projet)

selon HERMES 5

13 Clôture du projet



13.2 Rapport d’examen des risques (gestionnaire de la qualité et des risques)


Examen de l’évaluation de la clôture du projet (RCIT)


13.3 Prendre la décision de clore le projet (mandant)

selon HERMES 5

Source : représentation propre, contient les jalons et tâches de l’UPIC (2014, HERMES 5)

Les jalons doivent être communiqués à temps par le chef de projet (cf. page Fehler! Textmarke nicht definiert.) (chef de projet spécialisé ou chef de projet informatique (cf. page 26) à l’organe de contrôle. Les résultats doivent être livrés suffisamment à l’avance.


34/53

3.6. Séances de lancement des phases

L’OFROU définit des séances de lancement obligatoires pour les phases (lancements de phases) dans le cadre de la réalisation d’un projet informatique. Il s’agit de discussions pour le coup d’envoi d’une nouvelle phase.

En plus des lancements de phases, un atelier avec le RCIT, le RSIT, l’office responsable de l’architecture informatique et le juriste spécialiste des acquisitions et contrats informatiques doit être organisé avant la phase d’initialisation. Cet atelier doit aider à bien positionner le projet informatique dès le début avant que la direction ne décide d’un mandat et n’exige les objets devant impérativement être livrés au bon moment.

L’illustration suivante montre quand ont lieu les lancements de phases et l’atelier initial.

Illustration 9 : lancements des phases obligatoires lors de la réalisation d’un projet informatique

Source : sur la base de l’UPIC (2014, HERMES 5, phases et jalons)

Le tableau suivant explique rapidement ces lancements de phases.

Tableau 10 : description des séances obligatoires de lancement de phases

N° Date Type et but du lancement de phases Participants

1 Début de la phase Initialisation

Cette première discussion autour du projet peut être regroupée avec la réunion de lancement. Les participants au projet doivent être familiarisés avec les caractéristiques centrales du projet et les aspects primordiaux. Cette réunion sert à bien informer les participants au projet occupant un rôle obligatoire (architecte principal, juriste spécialiste des acquisitions et contrats informatiques, etc.). Les participants doivent par ailleurs s’engager proactivement dans leur domaine spécialisé et exprimer leurs attentes.

Mandant, gestionnaire de la qualité et des risques, architecte principal, RSIT, RCIT, chef de projet, juriste spécialiste des acquisitions et contrats informatiques, chef de projet informatique, responsable SPID, responsable d’application, analyste métier et, le cas échéant, représentant du comité de pilotage.

2 - 4 Début des phases Conception, Réalisation, Déploiement

Discussion au début d’une nouvelle phase, à partir de la phase Conception. Échange entre les participants et clarification des principaux points au commencement de la nouvelle phase.

Mandant, gestionnaire de la qualité et des risques, architecte principal, RSIT, RCIT, chef de projet, juriste spécialiste des acquisitions et contrats informatiques, chef de projet informatique, responsable d’exploitation (chef de sous-projet Exploitation informatique), chef de projet Développement, responsable SIPD, responsable d’application, responsable de test, analyste métier et, le cas échéant, représentant du comité de pilotage.


35/53


3.7. Modules

La représentation suivante montre les modules HERMES (sauf Produit et Développement agile) et indique les modules concrétisés / précisés par l’OFROU. Le module Produit n’est actuellement pas pertinent pour l’OFROU ; le module Développement agile n’a pour le moment pas été examiné dans le cadre de ce guide.

Illustration 10 : modules HERMES 5


Pilotage du projet

Conduite du projet

Bases du projet Structures organisationelles

Systeme informatique

Achat

Test

Organisation du déploiement

Migration informatique

Exploitation informatique

Sureté de l’information et protection des donnés

Le module contient des concrétisations / précisations spécifiques à l’OFROU

Module utilisé selon HERMES 5

Module selon UPIC (2013, processus de sécurité selon HERMES et P05)

Source : sur la base de l’UPIC (2014, HERMES 5, scénario système IT)

Le tableau suivant cite les précisions et concrétisations de l’OFROU apportées aux modules.

Tableau 11 : précisions et concrétisations des modules

Phase Module


Achat Le juriste spécialiste des acquisitions et contrats informatiques participe de manière déterminante.

Exploitation informatique

Élaborer la documentation d’exploitation :

Manuel de l’utilisateur

Manuel de saisie des données

Identification de la configuration

Manuel d’organisation

Release Notes

Manuel de support

SIPD Selon l’UPIC (2013, processus de sécurité selon HERMES et P05) (cf. chapitre 4.4)

Système informatique

Tâche : réaliser un croquis d’architecture, auteur du croquis d’architecture : architecte informatique, responsable de la


36/53

tâche : architecte principal, outils : processus de mise en conformité de l’architecture


De plus, le détenteur du rôle de chef de projet informatique prend en charge la partie technique du rôle de chef de projet (responsabilité et compétences) et participe aux tâches « Élaborer le programme d’acquisition » et « Élaborer des accords » du module « Acquisition ». De plus amples informations sont disponibles dans les descriptifs des rôles (cf. chap. 3.3.3).

3.8. Gestion des scénarios au sein de l’OFROU

Les scénarios suivants sont autorisés pour les projets informatiques au sein de l’OFROU :

Système IT

Système IT agile

Système IT standard

Système IT existant Cela signifie en termes concrets que les scénarios susmentionnés sont applicables pour toutes les premières mises en service, toutes les introductions et tous les développements comme projet informatique important, moyen ou petit. Les écarts doivent être clarifiés et harmonisés avec le centre de compétences de gestion des projets informatiques de l’OFROU (cf. chap. 5.1).

3.9. Modèles et outils

3.9.1. Modèles HERMES spécialement modifiés pour l’OFROU

Le rapport d’état du projet HERMES n’est pas utilisé l’état est noté dans le Cockpit TIC de la Confédération.

Liste de contrôle Jalons

3.9.2. Modèles spécifiques à l’OFROU

Rapport sur l’étude spécialisée

3.9.3. Outils

Diagramme de résultats relatif au scénario Système IT (PDF)


37/53

4. Thèmes connexes

Les chapitres suivants décrivent les précisions et concrétisations de l’OFROU sur HERMES 5 se rapportant à des thèmes connexes à la gestion des projets informatiques. Les thèmes relatifs à la gestion des applications informatiques et aux tests informatiques sont prévus pour plus tard.

4.1. Contrôle de gestion (ICO) / Gestion des portefeuilles informatiques (IT-PPM)

4.1.1. Interfaces avec la gestion des portefeuilles-contrôle de gestion

Les interfaces du contrôle de la gestion du portefeuille informatique avec la gestion des projets informatiques sont décrites dans Käser (2014, Concept spécialisé Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO), chap. 4.5, p. 50 et suivante). Les principes des documents pertinents de gestion des projets ont notamment été formulés pour la gestion des portefeuilles informatiques Contrôle de gestion. On y trouve aussi une description des principes importants concernant l’archivage des documents pour les justificatifs et le passage d’un projet dans une nouvelle phase ainsi que la clôture du projet.

4.1.2. Données financières de l’informatique

« Les données financières de l’informatique reposent sur la planification de détail (année en cours), le devis estimatif (budget de l’année suivante) et le plan financier (années suivantes 2 - 4). » Käser (2014, rapport Concept spécialisé Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO), p. 22) L’illustration suivante montre la différence entre le compte des investissements et de résultats pour la gestion financière des projets informatiques.

Illustration 11 : différenciation entre le compte des investissements et de résultats

Source : OFROU (sans année, extrait du plan comptable commenté de l’OFROU)


38/53

4.1.3. Outils

Le rapport Concept spécialisé Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO) contient entre autres des informations sur le système informatique / la couche du système global du contrôle de gestion informatique (ICO).

4.2. Gestion des risques informatiques

4.2.1. Outils

On dispose pour ce faire de l’outil standardisé suivant pour la gestion opérationnelle des risques dans le cadre des projets informatiques au sein de l’OFROU :

Gestion opérationnelle des risques pour les projets informatiques Outil d’application (Excel), téléchargement de GEVER Aide à l’application (Excel), téléchargement de GEVER

4.2.2. Examens des risques

Les examens des risques sont effectués :

avant l’élaboration du mandat d’initialisation et de projet,

avant la décision d’approbation d’un jalon,

avant une décision du comité de pilotage, et

dans le cadre de l’élaboration de l’état du projet dans le Cockpit TIC de la Confédération. L’évaluation et l’examen des risques sont effectués à l’aide du fichier Excel « Gestion opérationnelle des risques pour les projets informatiques » (cf. chap. 4.2.1). Les informations élaborées à l’aide de ce tableau Excel sont décisives et remplacent le chapitre Gestion des risques du plan de gestion de projet d’HERMES 5. Les résultats du tableau Excel doivent être insérés dans le plan de gestion de projet comme capture d’écran.

4.2.3. Examen des opportunités

Après l’examen des risques, il faut également identifier les opportunités qui en découlent.

4.3. Gestion de l’architecture informatique

4.3.1. Introduction

On a surtout des précisions et concrétisations dans le cadre de la gestion de l’architecture informatique par la gestion des projets informatiques dans le domaine des quality gates (cf. chap. 3.5) et des rôles (cf. chap. 3.2). Le module Système informatique est par ailleurs précisé (cf. chap. 3.7).

4.3.2. Informations et outils de l’OFROU

Croquis d’architecture standardisés (PDF)

Gabarit pour les croquis d’architecture (Visio)

Application métier Croquis d’architecture (Visio)


4.3.3. Modèles

Modèles HERMES spécialement modifiés pour l’OFROU

Architecture du système

Modèles spécifiques à l’OFROU

Application métier Conformité de l’architecture

http://idm.astra.admin.ch/fsc/openmx.asp?mx=COO.2045.100.7.3756399&vd=0&name=Oper%20RM%20IT-Projekte%20-%20Tool%20V%20d002

http://idm.astra.admin.ch/fsc/openmx.asp?mx=COO.2045.100.7.3762044&vd=0&name=Operatives%20Risikomanagement%20Projekte%20Anwendungshilfe%20V%201.0d%20(M511-0346)


39/53

4.4. Sécurité informatique et protection des données informatiques

4.4.1. Principes

La procédure concernant la sécurité informatique et les mesures de protection requises repose au sein de l’OFROU sur les directives de l’UPIC (2013, processus de sécurité selon HERMES et P05) et selon le DETEC.

Illustration 12 : procédure de sécurité selon HERMES et P05

Source : UPIC (07.01.2016, processus de sécurité selon HERMES et P05)

Illustration 13 : processus d’analyse des besoins de protection selon le DETEC

Initialisation Conception Réalisation DéploiementHERMES

Compétent

Activité

Résultats

ProcessusTIC

Outils

Responsable SIPDAssistance par le

préposé à la sêcuritéinformatique

Analyser et évaluer les besoins en matière de

protection

Elaborer et approuverl’analyse des besoins en matière de protection

P05.01/02Initialiser le projet,

propositions de solutions

P05.03Concevoir la solution

P05.04Réaliser la solution

P05.05Introduire le concept

Analyse des besoins en matière de protection(Schuban)

Concept SIPDCapitres 1-6

Concept SIPDCapitres 5-8

Concept SIPDCapitres 9, 10, 11

Responsable SIPDAssistance par le


Elaborer et évaluer les mesures de sécurité

Actualiser le conceptSIPD

Responsable SIPD Assistance par le


Responsable SIPD Assistance par le


Actualiser le conceptSIPD

Mettre en oeuvre les mesures de protection

dans la solution

Réception des mesuresde protection

Approuver le conceptSIPD (signatures):

prise en charge des risques


40/53

Source : Maurer (2014, 2e processus d’analyse des besoins de protection selon le DETEC)

4.4.2. Informations et outils

Informations et outils de l’UPIC

Mise en œuvre de mesures de protection de base des TIC dans l’administration fédérale (PDF)

Matrice d’accès Authentification, cryptage et signature (PDF)

Analyse des besoins de protection : directives de l’UPIC sur la base des Directives du Conseil fédéral concernant la sécurité des TIC dans l’administration fédérale du 14.08.13, ch. 3.2

Informations et outils de l’OFROU

Processus d’analyse des besoins de protection (Visio)

Vue d’ensemble des documents de sécurité de l’architecture (PDF)


4.4.3. Modèles

Modèles spécifiques au DETEC

Analyse des besoins de protection (version DETEC)


Application métier Analyse des besoins de protection

Application métier Conformité de l’architecture

Application métier Rapport final SIPD

Application métier Concept SIPD Confédération

4.5. Droit et acquisitions informatiques

Les sections suivantes décrivent des aspects importants de l’interaction entre la gestion des projets informatiques et le droit ainsi que les acquisitions dans le cadre d’un projet informatique au sein de l’OFROU.

4.5.1. Facteurs de succès critiques

Voici les facteurs de succès critiques pour une acquisition dans les règles et une bonne conception des contrats qui en découlent au sein de l’OFROU :

1. Un accompagnement juridique permanent et une sécurisation du projet par le secteur Acquisitions et contrats de l’OFROU, afin que les projets informatiques de l’OFROU puissent être sécurisés sur le plan juridique quasiment à tout moment ;

2. Définir clairement les responsabilités en ce qui concerne les aspects juridiques ;

3. Ne pas considérer un projet informatique de manière isolée mais agir avec anticipation en tenant compte de l’ensemble du cycle de vie du système informatique concerné. Cela comprend aussi l’intégration d’interfaces avec les projets et systèmes connexes. Le troisième facteur de succès est notamment très important pour estimer le cadre financier.

Les principaux facteurs de succès critiques dans le domaine du droit informatique et des achats informatiques sont la sécurisation juridique permanente par le secteur Acquisitions et contrats. Les mesures suivantes sont prises pour garantir les facteurs de succès critiques :

Introduction des séances de lancements de phases (cf. chap. 35)

Règlementation claire des responsabilités en créant le nouveau rôle de juriste spécialiste des acquisitions et contrats informatiques et en complétant les responsabilités et compétences du rôle de chef de projet prévu dans HERMES 5

Incitations à réfléchir dans le cadre de la planification prévoyante des acquisitions sur l’ensemble du cycle de vie du système informatique concerné par le projet informatique


41/53

4.5.2. Planification prévoyante des acquisitions sur l’ensemble du cycle de vie du système informatique

De projets éléphantesques à des ensembles de prestations abordables Les paragraphes suivants montrent des incitations pour acheter des prestations et fournitures (acquisitions) dans le respect de la loi et concevoir des contrats soutenant les projets. On montre notamment des idées pour transformer les gros projets, dits « éléphantesques », en des ensembles de prestations acceptables et raisonnables en termes d’acquisitions. Dans ce contexte, les principes applicables dans le cadre de la considération des coûts, des projets et de la rentabilité sont également évoqués.

Étendue des prestations Il est tout d’abord primordial de comprendre les prestations et fournitures (quoi ?) à prendre en compte dans le cadre de l’acquisition. Il faut considérer le « Quoi ? » en dépassant le cadre du projet car le Contrôle fédéral des finances (CDF) évalue les coûts du système informatique concerné au-delà de son cycle de vie. Le cycle et la durée de vie du système informatique doivent être connus et considérés avec prévoyance afin de pouvoir déceler la « véritable » valeur du mandat dans le cadre d’une future acquisition, ce qui constitue à son tour la base du choix d’une procédure de marché adaptée. En effet, lorsqu’une acquisition est déclenchée dans le cadre d’un projet informatique, le cadre financier concernant l’application résultant du projet informatique et ses charges en matière de maintenance, d’assistance, d’exploitation, de migrations, de développements, d’interfaces avec les projets et systèmes connexes, etc. doivent également être pris en compte. On pourrait par exemple avoir une technologie moins onéreuse aux coûts de maintenance élevés ou l’inverse, ce qui se répercute de manière déterminante sur les coûts totaux.

Une planification financière prévoyante Une considération prévoyante de l’ensemble du cycle de vie garantit une planification financière solide et en fin de compte aussi le respect des exigences légales dans le cadre des acquisitions.

De projets éléphantesques à des objectifs partiels Des projets éléphantesques voient parfois le jour dans la pratique. Ils augmentent les charges de contrôle du volume ainsi que les coûts et sont de ce fait difficilement assimilables. Il faut donc garantir dans un premier temps la définition d’une vision principale / d’objectifs principaux (orientation à long terme) afin de pouvoir axer les décisions sur ces objectifs principaux en cas de doute. Ces objectifs doivent être axés en fin de compte sur le soutien des processus administratifs et la réalisation des objectifs administratifs conformément à l’accord sur les prestations conclu avec le département.


42/53

Pour que le projet devienne raisonnable, il faut trouver des objectifs partiels clairs ayant un intérêt reconnaissable pour l’OFROU et axés sur la réalisation de l’objectif principal.

Illustration 14 : projet éléphantesque avec un objectif principal défini


Des objectifs partiels vers des ensembles de prestations raisonnables Une fois que les objectifs partiels ont été trouvés, il est possible de déterminer les prestations spécialisées, techniques et organisationnelles requises pour les atteindre. Il faut ce faisant aussi prendre en compte la durée d’utilisation et de vie probable des prestations devant être mises en œuvre concrètement. Il ne faut pas que ces durées aillent trop loin dans l’avenir, car de nouvelles conditions cadres pourraient changer un projet de manière déterminante (par ex. par de nouveaux progrès techniques, de nouvelles exigences des utilisateurs, de nouvelles dispositions légales, etc.). Les objectifs partiels doivent être réduits jusqu’à ce qu’il soit possible de trouver des prestations et des fournitures convenables pour chaque objectif partiel. Les prestations à fournir doivent être formulées afin qu’elles soient les plus durables et rentables possibles. Elles doivent ensuite être combinées en des ensembles de prestations pouvant être affectées clairement aux différentes phases du système informatique. C’est en effet un point important pour le contrôle de la gestion informatique. D’autre part, il est ainsi possible de séparer de nombreux contrats lors de la conception. Il convient de renvoyer dans ce contexte à la délimitation entre les premières mises en service, les introductions et les développements (cf. chap. 2.2).

Illustration 15 : projet éléphantesque divisé en objectifs partiels avec des ensembles de prestations


On a probablement toute une série d’objectifs partiels pour lesquels il est difficile de saisir le type et l’étendue des fournitures et prestations à apporter. Dans un tel cas, il faut clarifier avec le juriste spécialiste des acquisitions et contrats informatiques dans quelle mesure ces éléments peuvent être

Objectif principal défini ?


43/53

pris en compte et quand. Le cas échéant, on peut aussi acheter des ressources personnelles en fonction des besoins.

Des ensembles de prestations vers des ensembles abordables Afin de pouvoir composer des ensembles abordables à partir d’ensembles de prestations raisonnables, il est important de connaître les capacités nécessaires pour apporter les différentes prestations afin de pouvoir trouver de solides prestataires et des produits / technologies efficaces. Cela présuppose à nouveau une bonne connaissance du marché en matière de technologies, de prestations et de combinaisons, etc. Un autre élément fondamental dans ce contexte est la décision relative aux prestations à apporter en interne et en externe. Des réflexions sur la sécurisation de la durabilité jouent également un rôle dans ce domaine. Le juriste spécialiste des acquisitions et contrats informatiques doit être impliqué en permanence pour le groupement des ensembles d’achat et participer à la dernière détermination et la valider.

Résumé On peut résumer ainsi la planification des achats :

1. Obtention d’une vue d’ensemble de ce qu’il faut acheter (Quoi) et de la valeur du contrat en prenant en compte avec prévoyance le cycle de vie du système informatique concerné et les interfaces avec d’autres outils / projets informatiques ;

2. Planification prévoyante sur l’ensemble du cycle de vie du système informatique concerné et examen de l’existence d’un objectif principal pour le projet informatique ;

3. Détermination d’objectifs partiels avec des ensembles de prestations clairs et raisonnables pouvant être affectés aux différentes phases du cycle de vie ;

4. Détermination des objectifs partiels avec des prestations et des fournitures requises difficiles à saisir (type / étendue) et de leur gestion ;

5. Groupement des ensembles d’achat en prenant en considération la décision d’adjudication interne ou externe du marché au niveau du soumissionnaire et l’état de la technologie, etc.

4.5.3. Conception du contrat

Les premiers projets de contrat peuvent être élaborés sur la base des ensembles d’achat. L’élaboration des contrats doit être effectuée en étroite collaboration avec un juriste spécialiste des acquisitions et contrats informatiques.

4.5.4. Informations et outils

Informations et outils de l’OFROU

Modèles de l’OFROU et modèles pour les acquisitions et les contrats, site Internet

Manuel sur les marchés publics Routes nationales OFROU, site Internet

Bref récapitulatif de la demande d’acquisition (processus afférent de la centrale)

Informations complémentaires de différentes institutions

OFCL – Acquisitions Vers le site Internet

Loi fédérale sur les marchés publics (LMP) Vers le site Internet

CDF, Recommandations des contrôles des finances à l’égard des projets informatiques Site Internet, à télécharger en PDF

GIMAP - plateforme d’information des marchés publics de la Confédération, Vers le site Internet

Conférence sur les acquisitions et marchés publics TIC 2014 Vers le site Internet

Ordonnance fédérale sur les marchés publics (OMP) Vers le site Internet

http://www.astra.admin.ch/dokumentation/04139/04143/index.html?lang=de

http://www.astra.admin.ch/dokumentation/04139/04143/index.html?lang=de&download=NHzLpZeg7t,lnp6I0NTU042l2Z6ln1acy4Zn4Z2qZpnO2Yuq2Z6gpJCDd4F7gmym162epYbg2c_JjKbNoKSn6A--

http://www.bbl.admin.ch/themen/beschaffungswesen/

http://www.admin.ch/opc/de/classified-compilation/19940432/index.html

http://www.efk.admin.ch/index.php?option=com_content&view=article&id=177&Itemid=174&lang=de

http://www.efk.admin.ch/images/stories/efk_dokumente/publikationen/audit_letters/Broschuere_IKS_d.pdf

http://www.gimap.admin.ch/d/index.htm

http://www.ch-open.ch/it-beschaffungskonferenz

http://www.admin.ch/opc/de/classified-compilation/19950538/index.html


44/53

4.5.5. Modèles


001 Achats

010 Planification du calendrier pour la procédure d’attribution

020 Masque SIMAP Appel d’offre en cours

021 Masque SIMAP Appel d’offre résumé en cours

023 Conditions / cahier des charges (document principal)

024 Documents de l’offre à soumettre

030 Dispositions relatives à la procédure d’adjudication (procédure par invitation)

031 Lettre d’invitation à la procédure par invitation

040 Lettre de confirmation d’entrée

041 Procès-verbal d’ouverture

042 Examen officiel des offres soumises

043 Rapport d’évaluation

044 Tableau d’évaluation

045 Masque SIMAP Adjudication

046 Acceptation de l’appel d’offres SIMAP

047 Refus de l’appel d’offres SIMAP (normal)

048 Refus de l’appel d’offres SIMAP (exclusion)

050 Acceptation de la procédure par invitation

051 Refus de la procédure par invitation (normal)

052 Refus de la procédure par invitation (exclusion)

060 Informations concernant le contractant / l’entrepreneur

070 Lettre accompagnant le contrat

110 Exigences minimales en matière de facturations de tiers

Modèles contractuels spécifiques à l’OFROU

101 Commande jusqu’à CHF 10 000.— (confirmation de commande)

102 Informatique : logiciels individuels et gestion logicielle

103 Informatique : cycle de vie (maintenance matérielle, gestion logicielle, assistance technique, etc.)

104 Informatique : prestation (conseil, assistance du chef de projet, etc.)

106 Accord administratif

107 Avenant


Cahier des charges Le cahier des charges d’HERMES 5 doit être remplacé par les modèles susmentionnés spécifiques à l’OFROU.

Catalogue de critères Le catalogue de critères d’HERMES 5 doit être remplacé par le document 044 Tableau d’évaluation susmentionné spécifique à l’OFROU.


45/53

4.5.6. Acquisition de connaissances

Un échange régulier et cohérent des participants au projet avec le secteur Acquisitions et contrats doit permettre de développer les connaissances pratiques dans le domaine du droit et des marchés publics. Ces connaissances sont mises à disposition sous forme d’un recueil de modules et modèles. Il incombe au secteur Acquisitions et contrats de développer et de gérer les modules contractuels et les modèles afférents. Tous les autres participants aux projets informatiques, notamment le chef de projet, collectent les thèmes techniques pour lesquels ils souhaitent une assurance juridique. L’illustration suivante montre encore une fois graphiquement ce contenu.

Illustration 16 : acquisition de connaissances dans le domaine du droit et des marchés publics



46/53

4.6. Exploitation informatique

4.6.1. Réflexions fondamentales

Les réflexions fondamentales suivantes sont importantes dans le cadre de la préparation de l’exploitation informatique :

La « maintenance de base » et la « maintenance des développements » doivent être compatibles. Les entreprises participantes doivent bien s’harmoniser dans ce domaine.

Le juriste spécialiste des acquisitions et contrats informatiques doit aider à clarifier les problèmes liés aux remises d’exploitation comme par exemple les droits de propriété et les licences logicielles.

Lorsque le chef de projet informatique n’est pas la même personne que le futur responsable de la maintenance (application informatique) et que cet élément est connu au moment du projet informatique, le responsable de la maintenance doit être impliqué dès la phase de conception du projet informatique.

4.6.2. Modèles


Manuel d’exploitation


Manuel de l’utilisateur

Manuel de saisie des données

Identification de la configuration

Manuel d’organisation

Release Notes

Manuel de support

4.7. Gestion des exigences informatiques

Pour assurer la réussite ultérieure du projet, il est primordial que les parties prenantes soient sur la même

longueur d’ondes au sujet de la situation initiale, des conditions-cadre, des objectifs, du contexte système et

des exigences lors de la phase d’initialisation. La gestion des exigences informatiques consiste à identifier, préciser et valider (y c. hiérarchiser) les exigences et à les gérer durant toute la durée de vie du projet (gestion de l’évolution des exigences, mise à jour et documentation des spécifications).

Identification des exigences : Identification de l’origine des exigences, puis sollicitation des parties prenantes afin de connaître et de comprendre leurs souhaits et leurs besoins.

Précision des exigences : Formulation des exigences sur la base des interdépendances identifiées lors de l’analyse. Les exigences sont consignées par écrit et documentées.

Validation des exigences : Assurance d’une compréhension correcte. Toutes les exigences sont acceptées formellement par les parties prenantes. Les divergences sont éliminées et, le cas échéant, les exigences sont précisées et hiérarchisées.

Dans un premier temps, les exigences peuvent être hiérarchisées sur la base des avantages qu’elles sont susceptibles de procurer lors de leur mise en œuvre. Décider de concrétiser ou non une exigence revient à prendre une décision en termes de coûts, de ressources, de temps et de risques. L’objectif de la hiérarchisation consiste à parvenir à une utilisation aussi efficace que possible des moyens disponibles. La comparaison directe des avantages et des coûts de mise en œuvre permet de prioriser les exigences et de formuler des recommandations. Des directives méthodologiques relatives à la gestion des exigences informatiques dans les projets peuvent être obtenues auprès du secteur Gouvernance informatique. Il est également possible de solliciter si nécessaire une aide méthodologique pour la mise en œuvre de ces directives.


47/53

5. Interlocuteurs

Ce chapitre recense les interlocuteurs centraux et les coordonnées pour la gestion des projets informatiques au sein de l’OFROU et dans les thèmes apparentés.

5.1. Centre de compétences pour la gestion des projets informatiques de l’Office fédéral des routes OFROU

Office fédéral des routes OFROU Mühlestrasse 2 3063 Ittigen, adresse postale : 3003 Berne Site Internet : www.it-pm-astra.ch Le centre de compétences pour la gestion des projets informatiques de l’OFROU est l’organe responsable pour le respect et la prise en charge de la gestion des projets informatiques et ce guide : Office fédéral des routes OFROU Division Affaires de la direction Informatique OFROU Gouvernance informatique Gestion des projets informatiques Monsieur Bruno Frey Courriel : [email protected] Téléphone : +41 58 463 34 76

5.2. Controlling informatique

Office fédéral des routes OFROU Division Affaires de la direction Informatique OFROU Gouvernance informatique Controlling informatique Monsieur Bruno Frey Courriel : [email protected] Téléphone : +41 58 463 34 76

5.3. Finances

Office fédéral des routes OFROU Gestion et finances Finances et controlling Madame Rosemarie Reist Courriel : [email protected] Téléphone : +41 58 462 94 69 Office fédéral des routes OFROU Gestion et finances Finances et controlling Comptabilité financière Madame Patrizia Hubler Courriel : [email protected] Téléphone : +41 58 465 30 49

http://www.it-pm-astra.ch/

mailto:[email protected]





48/53

5.4. Gestion de l’architecture informatique

Office fédéral des routes OFROU Division Affaires de la direction Informatique OFROU Gouvernance informatique Gestion de l’architecture informatique Monsieur Markus Maeder Courriel : [email protected] Téléphone : +41 58 463 26 50

5.5. Sécurité informatique

Office fédéral des routes OFROU Division Affaires de la direction Informatique OFROU Responsable de la sécurité informatique (RSIT) Monsieur Wolfgang Hoffmann Courriel : [email protected] Téléphone : +41 58 463 45 30

5.6. Droit et acquisitions informatiques au sein de l’OFROU

Office fédéral des routes OFROU Division Affaires de la direction Service juridique et acquisition de terrain Secteur Acquisitions et contrats Monsieur Beat Joss Courriel : [email protected] Téléphone : +41 58 465 78 64

5.7. Gestion des exigences informatiques

Office fédéral des routes OFROU Division Affaires de la direction Informatique OFROU Gouvernance informatique Gestion des exigences informatiques Monsieur Martin Bartlome Courriel : [email protected] Téléphone : +41 58 465 32 25






49/53

6. Informations complémentaires

Les informations complémentaires fournies dans ce chapitre couvrent les liens vers des informations plus détaillées ainsi que des informations relatives au marquage des documents et à la structure de classement.

6.1. Informations complémentaires de l’OFROU

Jungo, M., 2015, Réglementation des responsabilités dans le cadre de la gestion des TIC pour le développement et l’exploitation selon la décision de la direction de l’OFROU du 26.04.2015.

6.2. Marquage des documents

À l’OFROU, il n’existe aucune exigence ni directive relative au marquage des documents. Le choix du type de marquage est donc entièrement de la responsabilité du chef de projet et doit être réglementé dans le plan de gestion du projet / le manuel de projet. Deux options de marquage des documents sont possibles : sigle du projet_date_type de doc_nom du document_<L>_versionxx.yy Exemple : KUBA_20111025_PH_Pflichtenheft-KUBA6_d_V01.00 type de document_sigle du projet_nom du document_L_date_versionxx.yy Exemple : PH_KUBA_Pflichtenheft-KUBA6_d_20111025_V01.00 Décomposition : Date : date d’édition (aaaammjj = année/mois/jour) Versionxx.yy : version de l’édition, la version d’une ébauche porte l’initiale X et une

version approuvée porte l’initiale V Langue : Langue d, f, i, e) Type de document : BE = rapport, PR = présentation, AK = note d’accompagnement, A

document de travail, BF = lettre, HB = manuel, PH = cahier des charges, PK = procès-verbal, ZE = dessin

Des informations et conseils supplémentaires relatifs au marquage des documents peuvent être obtenus auprès du service Controlling informatique / Gestion des projets informatiques de l’OFROU.

6.3. Structure de classement

Des informations et conseils supplémentaires relatifs au classement des documents peuvent être obtenus auprès du centre de compétences pour la gestion des projets informatiques de l’OFROU. Les documents suivants contiennent des informations sur les directives organisationnelles :

Directives d’organisation GEVER OFROU (Partie 1 Processus de prestations)

Directives d’organisation GEVER OFROU (Partie 2 Processus d’assistance)

http://idm.astra.admin.ch/fsc/openmx.asp?mx=COO.2045.100.7.132579&vd=0&name=GEVER-Organisationsvorschriften%20ASTRA%20(Teil%201%20Leistungsprozesse)

http://idm.astra.admin.ch/fsc/openmx.asp?mx=COO.2045.100.7.132585&vd=0&name=GEVER-Organisationsvorschriften%20ASTRA%20(Teil%202%20Unterstuetzungsprozesse)

http://idm.astra.admin.ch/fsc/openmx.asp?mx=COO.2045.100.7.132579&vd=0&name=GEVER-Organisationsvorschriften ASTRA (Teil 1 Leistungsprozesse)

http://idm.astra.admin.ch/fsc/openmx.asp?mx=COO.2045.100.7.132585&vd=0&name=GEVER-Organisationsvorschriften ASTRA (Teil 2 Unterstuetzungsprozesse)


50/53

7. Littérature et sources

Office fédéral des routes (OFROU), sans année. Extrait du Plan comptable commenté de l’OFROU, Berne : OFROU Office fédéral des routes (OFROU). Réglementation des responsabilités dans le cadre de la gestion des TIC selon la décision de la direction du 26.04.2015, Berne : OFROU Office fédéral des routes (OFROU), 2014. Vue d’ensemble des principales responsabilités de gestion des portefeuilles informatiques / contrôle de gestion (état : 14.04.14). Gestion du portefeuille (projets, applications) et contrôle de gestion informatique de la Confédération, Berne : OFROU Unité de pilotage informatique de la Confédération (UPIC), 2014. HERMES 5. En ligne : http://www.hermes.admin.ch/ (22.05.2014) Unité de pilotage informatique de la Confédération (UPIC), 2014. HERMES 5. Phases et jalons. Introduction. En ligne : http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=kategorie_phasen_und_meilensteine.html (19.05.2014) Unité de pilotage informatique de la Confédération (UPIC), 2014. HERMES 5. Rôles. Introduction. En ligne : http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=kategorie_rollen.html (09.04.2014) Unité de pilotage informatique de la Confédération (UPIC), 2014. HERMES 5. Vues sur le projet. En ligne : http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=supportingmaterial_sichten_auf_das_projekt.html (26.05.2014) Unité de pilotage informatique de la Confédération (UPIC), 2013. Sécurité. Outils de projet. Processus de sécurité selon HERMES et P05. En ligne : http://www.isb.admin.ch/themen/sicherheit/00151/index.html?lang=de (26.05.2014) Unité de pilotage informatique de la Confédération (UPIC), 2014. HERMES 5. Scénarios. Scénario système IT. En ligne : http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=supportingmaterial_szenario_it_individualanwendung.html (09.04.2014) Käser C., 2014. Rapport Concept spécialisé Gestion des portefeuilles de projets informatiques / contrôle de gestion (IT-PPM / ICO). Version 1.0. OFROU, Berne : OFROU Maurer, U., 2014. 2e processus d’analyse des besoins de protection selon le DETEC. Version 1.0, Berne : DETEC Maurer, U., Kilcher, R., 2014. Directive relative à l’examen et à l’accompagnement de projets informatiques par le service informatique du département. 2 juin 2014, V1-0, Berne : service informatique du Secrétariat général (SG-DETEC) Réglementation des signatures et des compétences (publiée sur le système de gestion [FS])

http://www.hermes.admin.ch/


51/53

8. Annexe

Annexe 1 : organisation générique du projet pour les petits projets informatiques

L’illustration suivante montre l’organisation générique du projet pour les petits projets informatiques. Cette dernière peut être modifiée en fonction des besoins d’un projet informatique spécifique.


Exécution

Conduite

Pilotage Mandant

Chef de projet


Comité de pilotage


Spécialiste informatique





Développeur



solution)

Responsable SIPD

Responsable de test

Testeur

Examinateur du projetGestionnaire de la qualité et des risques(rôle HERMES 5)


RCIT

Rôle obligatoire

RSIT


Responsable d’exploitation (Chef de sous-

projet Exploitation informatique)


Juriste Achats / contrats informatiques

Organisation générique pour les petits projets informatiques au sein de l’OFROU



52/53

Annexe 2 : organisation générique du projet pour les projets informatiques moyens et importants

L’illustration suivante montre l’organisation générique du projet pour les projets informatiques moyens et importants. Cette dernière peut être modifiée en fonction des besoins d’un projet informatique spécifique.


Exécution

Conduite

Pilotage Mandant

Chef de projet



Comité de pilotage


IT-Spezialist






Développeur



solution)

Responsable SIPD

Responsable de test

Testeur

Examinateur du projet

Gestionnaire de la qualité et des risques(rôle HERMES 5)


RCIT

Rôle obligatoire

RSIT


Responsable d’exploitation (Chef de sous-

projet Exploitation informatique)


Juriste Achats / contrats informatiques

Organisation générique du projet pour les projets informatiques moyens et importants


53/53

Annexe 3 : règles relatives à l’adaptation de projets informatiques en cours à la philosophie du présent guide

L’adaptation de projets informatiques en cours aux principes du présent guide et d’HERMES 5 doit se faire à la fin d’une phase ou au début d’une nouvelle phase. Ce principe s’applique jusqu’à la phase de réalisation. Les projets informatiques déjà en phase de réalisation ne seront pas adaptés. La clôture du projet est effectuée selon HERMES 5 pour tous les projets informatiques.