Méthodologies de gestion de projet agiles et en cascade ... · Méthodologie de gestion de projet Méthodologies agiles Méthodologies en cascade Soumissions publiques Règles de

Université de Fribourg, Suisse

Département d’informatique

Systèmes d’information

Fribourg, mai 2011

Méthodologies de gestion de projet agiles et

en cascade : définition, combinaison et

application.

Cindy Zbinden

Village 100, 1532 Fétigny

[email protected]

Bachelor en gestion d’entreprise

08-213-878

Dr Stephan Hüsemann

1 Résumé

Résumé

Les méthodologies de gestion de projet sont aujourd’hui très utiles à la réalisation de projets

et amènent un support considérable et de meilleures chances de réussite.

Il est possible de dénombrer deux types de méthodologies: les méthodes dites en cascade et

les méthodes agiles.

Ce travail donne de plus amples informations sur ces méthodes et montre également qu’il

est possible de travailler avec elles d’une manière combinée, ce qui de prime abord semble

peu probable.

D’un autre côté, le travail détaille également le processus des soumissions publiques, leur

fonctionnement et les différentes lois fondamentales qui les régissent.

Des liens entre ces deux sujets sont enfin établis.

2 Mots-clés

Mots-clés

Méthodologie de gestion de projet

Méthodologies agiles

Méthodologies en cascade

Soumissions publiques

Règles de soumissions publiques

Combinaison méthode agile / en cascade

Glossaire

IT "Information Technology", regroupe les technologies

de l’information et de la communication en général.

Processus itératif / agile Qui est répété plusieurs fois.

Processus séquentiel Accès aux différentes phases se fait dans un ordre

précis et préétabli.

3 Remerciements

Remerciements

Je remercie toutes les personnes qui ont permis et contribué à la réalisation de mon travail

de Bachelor.

Je remercie particulièrement Monsieur Stefan Hüsemann pour avoir encadré mon travail

avec une grande disponibilité.

Je suis également très reconnaissante envers Monsieur Turabi Köse, Monsieur Hans

Rüegsegger et Monsieur Ludovic Chesaux qui ont gentiment accepté de répondre à quelques

questions lors d’interviews orales ou écrites et qui m’ont, grâce à leurs jugements de

professionnels, permis de compléter cette thèse.

4 Table des matières

Table des matières

Résumé ....................................................................................................................................... 1

Mots-clés .................................................................................................................................... 2

Glossaire ..................................................................................................................................... 2

Remerciements .......................................................................................................................... 3

Table des matières ..................................................................................................................... 4

I. Table des figures................................................................................................................. 7

II. Liste des abréviations ......................................................................................................... 8

III. Liste des tableaux ............................................................................................................... 9

1 Introduction ...................................................................................................................... 10

1.1 Choix du travail et motivation ................................................................................... 10

1.2 Objectifs ..................................................................................................................... 10

1.3 Questions ................................................................................................................... 10

1.4 Structure du travail .................................................................................................... 12

1.5 Conventions ............................................................................................................... 12

2 Les méthodologies de gestion de projet .......................................................................... 13

2.1 Introduction ............................................................................................................... 13

2.2 Définition ................................................................................................................... 13

2.3 Les méthodes en cascade .......................................................................................... 13

2.3.1 Merise® ............................................................................................................... 14

2.3.2 Hermes® ............................................................................................................. 16

2.3.3 Prince2® .............................................................................................................. 18

2.4 Les méthodes agiles ................................................................................................... 21

2.4.1 Le Rational Unified Process® .............................................................................. 22

2.4.2 Scrum® ................................................................................................................ 23


2.4.3 Extreme Programming® (XP) .............................................................................. 25

2.5 Le développement rapide d’applications .................................................................. 27

3 Systèmes d’information, soumissions publiques et règles de soumission ...................... 30

3.1 Introduction ............................................................................................................... 30

3.2 Définition ................................................................................................................... 30

3.3 Les différents types de soumissions publiques ......................................................... 31

3.4 Le processus de soumission d’un projet informatique ............................................. 32

3.4.1 Exemple et commentaire d’un appel d’offre ..................................................... 36

3.5 Les règles de soumission de l’OMC ........................................................................... 40

3.5.1 Description et buts ............................................................................................. 40

3.5.2 Avantages des règles de soumission pour l’adjudicateur et le soumissionnaire

41

3.5.3 Inconvénients des règles de soumission pour l’adjudicateur et le

soumissionnaire ............................................................................................................... 42

4 Combiner une méthode agile avec une méthode en cascade ......................................... 44

4.1 Introduction ............................................................................................................... 44

4.2 Motivations de l’entreprise à utiliser un tel procédé ................................................ 44

4.3 Avantages .................................................................................................................. 46

4.4 Inconvénients ............................................................................................................ 47

4.5 Le cas du projet Insieme® .......................................................................................... 47

4.5.1 Description du projet ......................................................................................... 47

4.5.2 La réalisation du projet ...................................................................................... 47

5 Conclusion ........................................................................................................................ 50

6. Bibliographie......................................................................................................................... 52

6.1 Livres .......................................................................................................................... 52

6.2 Sites internet.............................................................................................................. 53

6.3 Autres......................................................................................................................... 57


A. Annexe .............................................................................................................................. 58

A.1 Interview Turabi Köse, chef de programme e-dec à l’OFIT. .............................................. 58

A.2 Interview Hans Rüegsegger, responsable des demandes de ressources humaines à l’OFIT.

.................................................................................................................................................. 61

A.3 Interview Ludovic Chesaux, chef de projets informatiques, douane suisse. ..................... 65

7 Table des figures

I. Table des figures

Figure 1 : Le modèle de développement en cascade [Aguilera 2006]. .................................... 14

Figure 2 : Etapes d’un projet informatique selon la méthode Merise [Cybermed Jussieu

2011]. ........................................................................................................................................ 15

Figure 3 : Cycles Merise [IS NET 2005]. .................................................................................... 16

Figure 4 : Les trois perspectives d’un projet Hermes [Hermes 2010, lien 1]. .......................... 17

Figure 5 : Les phases de la méthode Hermes [Hermes 2010, lien 1]. ...................................... 17

Figure 6 : Le modèle des phases d’Hermes selon le type de projet [Hermes 2010, lien 1]. .... 18

Figure 7 : Le fonctionnement de Prince2 [Wikipedia 2011, lien 2]. ......................................... 20

Figure 8 : Le processus agile [Software-development-resource 2011]. .................................. 21

Figure 9 : Le RUP [IBM 2005]. ................................................................................................... 22

Figure 10 : Planification Scrum [Wikipedia 2011, lien 1]. ........................................................ 24

Figure 11 : Les sprints et leurs activités en parallèle [Aubry 2010 p.17]. ................................ 24

Figure 12 : Schéma global méthode Scrum® [Adyax 2010]. .................................................... 25

Figure 13 : Les treize pratiques d’Extreme Programming [Messager Rota 2010]. .................. 26

Figure 14 : Le "développement de versions" selon la méthode RAD [Hennebert 2011]. ....... 28

Figure 15 : Le "prototyping" selon la méthode RAD [Hennebert 2011]. ................................. 28

Figure 16 : Le "throwaway prototyping" selon la méthode RAD [Hennebert 2011]. .............. 29

Figure 17 : Plateforme électronique SIMAP, section « adjudicateur » [Simap 2011]. ............ 33

Figure 18 : Plateforme électronique SIMAP, login adjudicateur [Simap 2011]. ...................... 34

Figure 19 : Procédure d’inscription à un appel d’offre [Simap 2011]. ..................................... 36

Figure 20 : Exemple d’appel d’offre EVAM [Simap 2010, publication numéro 561197]. ........ 37

Figure 21 : Combinaison d’une méthode en cascade et d’une méthode itérative. ................ 45

Figure 22 : Combinaison Hermes / Scrum. ............................................................................... 48

Figure 23 : Le processus de combinaison des méthodes Hermes et Scrum [Hermes 2010, lien

2]. .............................................................................................................................................. 49

8 Liste des abréviations

II. Liste des abréviations

Abréviation Signification

AFC Administration Fédérale des Contributions

EVAM Etablissement Vaudois d’Accueil des

Migrants

IBM ® International Business Machines

IT Information Technology

OFIT Office fédéral de l’informatique et de la

télécommunication

OMC Organisation Mondiale du Commerce

OMP Ordonnance des marchés publics

RAD Rapid Application Development

RUP Rational Unified Process

SIMAP Système d’information sur les marchés

publics en Suisse

UML Unified Modeling Language

URL Uniform Resource Locator

XP Extreme Programming

Tableau 1 : Liste des abréviations.

9 Liste des tableaux

III. Liste des tableaux

Tableau 1 : Liste des abréviations. ........................................................................................... 5

Tableau 2 : Avantages des règles de soumissions publiques, pour l’adjudicateur et le

soumissionnaire. ..................................................................................................................... 25

Tableau 3 : Inconvénients des règles de soumission pour l’adjudicateur et le soumissionnaire.

................................................................................................................................................. 26

10 Introduction

1 Introduction

1.1 Choix du travail et motivation

Les méthodologies de gestion de projets sont aujourd’hui massivement utilisées par les

entreprises des quatre coins du monde et permettent de mener à bien un grand nombre de

projets aussi complexes soient-ils en y apportant un soutien sans faille et un appui précieux

dans leur réalisation. Elles sont donc très actuelles, certainement encore amenées à se

développer à l’avenir et font office de thème intéressant à développer dans le cadre de ce

travail.

1.2 Objectifs

Le premier but de ce travail est d’offrir une vue générale sur les méthodologies de gestion de

projet.

Il s’agira dans un second temps de comprendre l’utilisation effective de ces méthodologies

dans le cadre de systèmes d’information d’entreprises suisses ou étrangères ; pour cela,

quelques explications sur les diverses règles de soumission de l’OMC seront données.

Pour terminer, il s’agira de réussir à comprendre le fonctionnement de l’utilisation combinée

de méthodes itératives et en cascade ainsi que les motivations des entreprises à recourir à

un tel procédé ; un exemple concret sera donné avec le cas du projet Insieme.

Sur un plan plus personnel, ce travail a également pour objectif de développer une

autonomie de travail, la gestion d’un travail sur le long terme et l’aisance dans la rédaction

scientifique.

1.3 Questions

Le travail s’articule autour de plusieurs questions, notamment :

- Qu’est-ce qu’une méthodologie de gestion de projet ?

� Cette question constitue le point de départ du travail et est fondamentale pour la

compréhension de ce dernier.

- Quelles classifications existe-t-il ?

� Pour comprendre de manière optimale le sujet, il est nécessaire de comprendre non

seulement le fonctionnement de ces méthodes mais également les classifications

existantes (méthode itérative ou de développement en cascade).

11 Introduction

- Qu’est-ce qu’une méthode en cascade et comment fonctionne-t-elle ?

� A pour but d’expliciter et de décrire le fonctionnement d’une méthode en cascade.

- Qu’est-ce qu’une méthode agile et comment fonctionne-t-elle ?

� A pour but d’expliciter et de décrire le fonctionnement d’une méthode agile.

- Quelles sont les règles de soumission de la Confédération (OMC) ?

� Cette partie exposera les diverses règles de soumissions à observer dans le cadre de

projets informatiques.

- Pourquoi ces règles ont-elles été mises en place ? Quels en sont les avantages et les

inconvénients ?

� Il s’agira ici de développer les raisons qui ont motivé la mise en place de ces règles de

soumission ainsi que leur but, leurs avantages, inconvénients et limites.

- Quel est l’impact d’une soumission publique sur un projet IT ?

� Permettra de mesurer et d’évaluer l’impact concret d’une soumission publique sur un

projet informatique.

- Comment ces méthodes sont-elles concrètement utilisées dans les entreprises ?

� Permet de passer de la théorie à la pratique et de comprendre l’application effective

de ces méthodologies dans les entreprises suisses ou étrangères.

- Quelles raisons peuvent pousser une entreprise à utiliser et combiner une méthode

en cascade avec une méthode agile ?

� Vise à comprendre les motivations d’une entreprise à mélanger une méthode agile

avec une méthode en cascade.

- Comment combiner une méthodologie de gestion de projet en cascade avec une

méthodologie agile ?

� Cette question constitue un enjeu important du travail puisqu’il n’existe pas d’unique

méthode et que le procédé est à adapter au cas par cas. Après diverses voies de

réflexion, le travail tentera cependant d’y apporter une réponse.

- Quels sont les avantages et les inconvénients d’une telle combinaison ?

� Mettra en lumière les avantages et inconvénients ou limites de l’utilisation combinée

d’une méthode itérative et d’une méthode en cascade.

12 Introduction

1.4 Structure du travail

Ce travail est composé de trois principales parties.

Le chapitre deux traite tout d’abord des méthodologies de gestion de projet et explicite

cette notion en l’illustrant par le biais d’exemples de méthodologies.

Le chapitre trois traite, lui, principalement des soumissions informatiques et des diverses

règles à respecter dans un tel processus.

Pour terminer, le chapitre quatre met en lumière le procédé à suivre afin de combiner une

méthode en cascade avec une méthode agile. Le point 4.5, fait office de partie plus pratique

que théorique et vise à analyser un cas concret d’un projet suisse.

Enfin, le cinquième chapitre amène une conclusion à ce travail et résume les principaux

apports de celui-ci.

1.5 Conventions

- Les termes anglais seront cités entre crochets « … », en italique.

- Les liens entre les chapitres seront mentionnés dans le texte en question par des

renvois sous forme de liens hypertextes.

- Les détails complets des sources sont indiqués à la fin du travail, dans la section 6.

Bibliographie ; les sources apparaîtront dans le texte sous forme de citation

simplifiée du type: [Nom Année].

- Les abréviations, si mentionnées telles quelles dans le texte, sont explicitées à la

section II, au début de ce travail.

- L’URL complet d’un site Web est référencée dans la partie 6. Bibliographie avec la

date de la dernière visite.

- Les figures sont répertoriées à la section I, selon leur ordre d’apparition dans le

travail.

- Les textes de lois seront cités en italique, en police Times de taille 10.

- Les notions techniques abstraites qui se verront définies dans le travail seront tout

d’abord inscrites en italique (ex : Un adjudicateur est …).

- Les noms de méthodologies, pouvant s’apparenter à des marques, seront

mentionnés soit en italique, soit avec apposition du signe ®.

13 Les méthodologies de gestion de projet


2.1 Introduction

Ce chapitre traite des méthodologies de gestion de projets informatiques ; le point 2.2

commencera par définir cette notion et fournira quelques explications utiles pour la bonne

compréhension du travail. Puis, les points 2.3 et 2.4 s’attacheront à décrire et expliciter le

fonctionnement des méthodes agiles et en cascade.

Pour chacune de ces catégories, trois différentes méthodes seront explicitées : Merise,

Hermes et Prince2 pour les projets de développement en cascade, le RUP, Scrum et Extreme

Programming pour les projets agiles.

Cette deuxième partie s’attache ainsi à répondre aux questions suivantes :

� Qu’est-ce qu’une méthodologie de gestion de projet ?

� Quelle classification existe-t-il ?

� Qu’est-ce qu’une méthode agile et comment fonctionne-t-elle ?

� Qu’est-ce qu’une méthode en cascade et comment fonctionne-t-elle ?

2.2 Définition

Les méthodologies de gestion de projet spécifient une démarche à suivre, un processus, afin

de mener à bien un projet [Hüsemann 2009-2010].

On dénombre deux types de méthodologies : les méthodes de développement en cascade et

les méthodes agiles. Ces dernières seront explicitées dans les points suivants.

Enfin, une brève parenthèse sur la méthode de développement rapide d’applications,

méthode « mixte », sera ouverte au point 2.5 qui fournira quelques informations à ce sujet.

2.3 Les méthodes en cascade

Les méthodes de développement en cascade s’orientent d’après la dimension « temps ». Le

projet est découpé en différentes phases qui ont un début et une fin bien établis. Ce type de

processus est un processus séquentiel et chaque phase doit donc être complétée avant de

passer à la suivante [Dantotsu PM 2009].


Comme le démontre la Figure 1 ci-dessous, ce processus compte six phases distinctes :

l’analyse des besoins, la conception, la réalisation du codage, les tests, le déploiement et la

maintenance [Aguilera 2006].

Figure 1 : Le modèle de développement en cascade [Aguilera 2006].

Procédé simple et pratique en apparence, cette manière d’opérer comporte cependant des

désavantages non négligeables comme l’impossibilité de redéfinir les besoins une fois le

processus commencé ou encore le moment tardif de la réalisation des tests, ce qui entraîne

bien souvent un échec complet et définitif du projet.

Les points suivants présentent trois différentes méthodologies s’appuyant sur ce processus :

La méthode Merise, Hermes et Prince2.

2.3.1 Merise®

La méthode Merise® est une méthode française qui fut mise au point durant les années

1978-1979, suite à la demande du ministère de l’Industrie, chargé à l’époque du Centre

Technique Informatique (CTI). Ce dernier lança en 1977 une large consultation pour

sélectionner plusieurs sociétés de service et de conseil en informatique ainsi qu’un centre

d’étude et de recherche, le Centre d’Etudes Techniques et de l’Equipement (CETE), afin de

concevoir une méthode de conception de systèmes d’information [Comment ça marche

2008, lien 1].

La méthode s’appuie sur un développement en cascade et comporte donc plusieurs étapes

qu’il faut compléter avant de poursuivre le projet ; à chaque fin d’étape, des résultats précis

sont donc attendus.


Les six principales étapes de Merise® sont les suivantes : le schéma directeur, l’étude

préalable, l’étude détaillée, la réalisation, la mise en œuvre et la maintenance [Dionisi 1997].

Durant la première étape correspondant à la définition d’un schéma directeur il s’agira de

définir les domaines du système d’information ainsi que leur architecture, de planifier le

développement de chaque domaine et de détailler les diverses applications qui devront être

réalisées [Tardieu / Rochfeld / Colletti 2000].

L’étude préalable vise à s’assurer que le projet est bel et bien réalisable, et ceci dans un

temps imparti et selon un budget donné ; en d’autres termes, il s’agit dans cette phase de

s’assurer que le projet remplira ses trois principales contraintes à savoir : le temps, le coût et

la qualité.

L’étude détaillée détermine, elle, les spécifications fonctionnelles, dans le respect des

solutions retenues à l’issue de l’étude préalable [Dionisi 1997].

La réalisation comporte d’une part une étude technique et la production de programmes en

fonction des spécifications préalablement définies [Tardieu / Rochfeld / Colletti 2000].

La mise en œuvre porte sur la préparation au lancement, la mise en place de l’organisation et

le lancement effectif du système [Tardieu / Rochfeld / Colletti 2000].

Puis, la maintenance du système consiste à faire évoluer les applications opérationnelles en

fonction des besoins des utilisateurs, de l’environnement et des progrès technologiques

[Tardieu / Rochfeld / Colletti 2000].

La Figure 2 illustre ces différentes étapes.

Figure 2 : Etapes d’un projet informatique selon la méthode Merise [Cybermed Jussieu 2011].


Notons que toutes ces étapes s’appuient sur trois différents cycles : le cycle de vie, le cycle

d’abstraction et le cycle de décision (voir Figure 3).

Figure 3 : Cycles Merise [IS NET 2005].

Le cycle de vie se situe sur une échelle de temps qui nous mène du point de départ à

l’exploitation du système, en passant par sa création, sa maturité et sa maintenance. Le cycle

de décision représente, lui, l’ensemble des choix qui doivent être faits durant le cycle de vie.

Enfin, le cycle d’abstraction s’organise en trois niveaux : un niveau conceptuel qui détermine

les divers choix de gestion, un niveau organisationnel qui détermine les choix d’organisation

et un niveau technique qui détermine les contraintes techniques [Dionisi 1997].

Le projet s’articulera autour de ces trois axes.

2.3.2 Hermes®

Hermes® est une méthode suisse de conduite et de déroulement de projet dans le domaine

des technologies de l’information et de la communication [Hermes 2010].

Elle est aujourd’hui massivement utilisée au sein de la Confédération, notamment par

l’administration fédérale, diverses administrations ou institutions cantonales,

administrations municipales, entreprises et plus récemment par le Centre des Technologies

Informatiques de l’Etat (CTIE) au Luxembourg.

La première version de la méthodologie fut publiée en 1975 et entièrement révisée depuis, à

deux reprises. Elle propose maintenant une solution globale pour la gestion de projet grâce à

un site internet attractif, des manuels HERMES disponibles en quatre langues et consultables

ou téléchargeables en ligne, des utilitaires détaillés ou encore des séances d’information

[Hermes 2010, lien 1].


Hermes® aborde les projets selon trois perspectives distinctes, à savoir : la perspective de

démarche, de résultat et de rôle [Hermes 2010, lien 1]. Il s’attache donc à exposer

l’application de la démarche à adopter, les résultats à produire ainsi que les rôles de chacun.

Ces diverses vues sont illustrées par la Figure 4 ci-dessous.

Figure 4 : Les trois perspectives d’un projet Hermes [Hermes 2010, lien 1].

Comme précédemment mentionné dans le point 2.3, Hermes® repose sur un modèle de

développement en cascade ; ainsi durant les diverses phases, des résultats précis sont à

obtenir et à la fin de chacune d’elles la décision de poursuivre ou non le projet doit être

rendue.

La méthode Hermes® compte six phases distinctes : l’initialisation, l’analyse préliminaire, la

conception, la réalisation, l’introduction et la finalisation [Hermes 2010, lien 1]. Les points de

décisions sont signalés par des ronds bleus, les résultats à produire sont quant à eux signalés

par des ronds blancs. La Figure 5 ci-après illustre ces diverses phases.

Figure 5 : Les phases de la méthode Hermes [Hermes 2010, lien 1].

Hermes® opère cependant une différence entre les projets de « développement de

systèmes » et les projets « d’adaptation de systèmes » [Hermes 2010, lien 1]. Dans ce

dernier cas, les phases sont quelque peu modifiées et des phases d’évaluation et

d’implémentation sont nécessaires. La Figure 6 illustre cette alternative.


Figure 6 : Le modèle des phases d’Hermes selon le type de projet [Hermes 2010, lien 1].

Les projets sont également différenciés selon leur importance, leur taille et leurs risques

respectifs plus ou moins élevés. Hermes® promet toutefois de s’adapter à chaque projet et

propose une structure détaillée pour chaque cas de figure.

2.3.3 Prince2®

Prince est une méthode de gestion de projet orientée processus [QRP International 2011].

Elle fut fondée par le Département du Commerce britannique en 1989, afin de remplacer la

méthode auparavant utilisée qui était devenue trop rigide et contraignante, Prompt. La

méthode fut par après réajustée et modernisée en 1996 et tira ainsi son nom, Prince2, pour

« deuxième version » [Wikipedia 2011, lien 2].

A la manière d’Hermes en Suisse, la méthodologie est très répandue en Angleterre et son

utilisation est préconisée pour les divers projets d’administrations publiques notamment

[Chef-de-projet 2011, lien 2].

La méthode Prince2 repose sur sept principes de base qu’il est nécessaire d’identifier afin de

vérifier la compatibilité de la méthode avec le projet, à savoir [Prince2 2011]:

� La justification continue pour l’entreprise

� Les leçons tirées de l’expérience

� Les rôles et responsabilités définis

� Le management par séquence

� Le management par exception

� La focalisation produit

� L’adaptation à l’environnement du projet.

La justification continue du projet pour l’entreprise implique la nécessité de vérifier sa réelle

utilité et sa réalisation possible de manière permanente.


Tout au long du projet, il est de plus souhaitable de prendre note de toutes les expériences

utiles qui pourraient être réutilisées dans de futurs projets.

Une structure claire et bien définie est de plus préconisée ; ainsi, chaque rôle et

responsabilité devra être formellement explicité.

Afin d’avoir plus de chances de succès, un projet Prince est toujours à diviser en plusieurs

séquences.

Le management par exception préconise lui de n’avertir les supérieurs hiérarchiques qu’en

cas de grave problème ou de déviation majeure du projet, ceci afin d’éviter les pertes de

temps inutiles.

La focalisation produit met le produit au centre du projet et met l’accent sur la qualité et les

résultats optimaux qui doivent être obtenus.

Pour terminer, il est indispensable d’adapter la méthodologie au type de projet, à son

ampleur et sa complexité plus ou moins grande [Prince2 2011].

La méthode Prince2 repose de plus sur sept différents thèmes qui décrivent les compétences

et procédures utilisées, à savoir : le cas d’affaire, l’organisation, la qualité, les plans, les

risques, les changements et la progression [Prince2 2011].

Le cas d’affaire documente tout le processus de réalisation de la justification économique du

projet, l’organisation clarifie les rôles et responsabilités de chacun des membres de l’équipe

du projet, la qualité comprend autant la définition de celle-ci que son contrôle, les plans

comprennent les détails et le contenu de ces derniers, les risques sont à analyser et des

mesures correctrices sont à définir, les changements sont à analyser et à apprivoiser et pour

terminer, la progression doit régulièrement être contrôlée afin de vérifier qu’il n’y ait pas

d’écart trop grand entre la réalisation effective et la planification préalablement établie

[Prince2 2011].

Enfin, la méthode Prince2 prévoit également huit différents processus qui vont rythmer la

réalisation du projet. La durée des processus diffère mais pour chacun d’entre eux des

activités sont à réaliser et des objectifs précis à remplir ; ainsi, la méthode s’organise comme

une méthode en cascade type, fournissant plusieurs phases définies avec pour chacune

d’entre elles un début et une fin bien établis. Les huit processus sont les suivants : élaborer

un projet, initialiser un projet, diriger un projet, contrôler une séquence, gérer la livraison

des produits, gérer les limites des séquences, clore un projet et planifier [Derdak 2011].

Afin d’avoir une meilleure vue d’ensemble, ces différentes étapes peuvent être regroupées

en quatre phases : une phase de démarrage qui comprend l’élaboration du projet, une phase

d’initialisation qui comprend la mise en route du projet, une phase d’exécution qui comporte


le contrôles des séquences, la gestion de la livraison des produits et la gestion des limites des

séquences, ainsi que pour terminer une phase de clôture. La direction ainsi que la

planification du projet s’appliquent tout au long des quatre phases [Wikipedia 2011, lien 2].

La Figure 7 ci-dessous montre le fonctionnement détaillé de la méthode.

Figure 7 : Le fonctionnement de Prince2 [Wikipedia 2011, lien 2].

Le point initial du projet est la commande du projet, qui est ici représenté par une ellipse

blanche. A partir de là les différents processus vont s’enchaîner. Notons à ce sujet que bien

que la méthode soit construite sur une base en cascade, la méthode propose toutefois

quelques aspects itératifs comme la possibilité de réaliser certaines tâches en parallèle ou la

livraison possible de « lots de travaux » [ITpedia 2010].


2.4 Les méthodes agiles

Les méthodes agiles ou également appelées méthodes itératives, s’opposent directement

aux méthodes en cascade.

Ces méthodes s’appuient sur un processus itératif qui est une séquence d’instructions

destinée à être exécutée plusieurs fois et autant de fois que l’on peut en avoir besoin

[Techno-science 2011, lien 1].

Figure 8 : Le processus agile [Software-development-resource 2011].

Le cycle représenté par la Figure 8 sera donc enchaîné autant de fois que nécessaire jusqu’à

l’achèvement complet du projet [Kroll / Kruchten 2003].

Dans cette manière de procéder, les parties du système ou de l’application seront livrées à

intervalles régulières et feront office de prototypes. Ces intervalles sont appelées

« itérations » et leur durée est fixée au début du projet.

Une itération est donc une succession d’activités couvrant l’analyse des besoins, la

conception des parties du système, leur implémentation ainsi que leurs tests qui aboutissent

à la livraison d’une ou de plusieurs fonctionnalités qui feront partie du produit final [Bellouti

2007].

Cette manière d’opérer est certes plus compliquée et contraignante que la méthode de

développement en cascade mais elle offre cependant une plus grande flexibilité, un contrôle

effectif de la qualité à la fin de chaque itération et par-dessus tout une plus grande fiabilité

et moins de risques grâce aux tests qui sont réalisés tout au long du projet et non pas

uniquement dans la phase finale de ce dernier.


2.4.1 Le Rational Unified Process®

Le Rational Unified Process® est une méthodologie de gestion de projet développée par

l’entreprise Rational® qui fut fondée par Ivar Jacobson, Grady Booch et James Rumbaugh, les

créateurs du langage UML ; cette dernière fut rachetée par IBM en 2003 [Hüsemann 2009-

2010].

Ce processus de développement logiciel est disponible et consultable en ligne, en anglais,

sous forme de pages web interactives et facilement accessibles. Le RUP offre une aide

permanente dans le développement de projet et apparaît comme un véritable guide tout au

long de la réalisation. On y retrouve foule d’informations, conseils et activités à remplir pour

mener à bien un projet informatique.

Toutes les informations se basent sur les « meilleures pratiques » du secteur et y sont

détaillées et développées chronologiquement [IBM 2011].

Les six « meilleures pratiques » sont les suivantes : Le développement du logiciel de façon

itérative, la gestion des exigences, l’utilisation des architectures à base de composants, la

modélisation graphique du logiciel, la vérification de la qualité du logiciel et le contrôle des

changements apportés au logiciel [Kruchten 2000].

Le RUP s’articule autour de deux dimensions : le temps sur l’axe horizontal et le contenu sur

l’axe vertical.

Figure 9 : Le RUP [IBM 2005].

Comme la Figure 9 l’indique, le RUP comporte d’une part quatre phases, elles-mêmes

subdivisées en itérations : le lancement, l’élaboration, la construction et la transition.


Dans la phase de lancement, il s’agit de déterminer ce que l’on veut construire, dans la

phase d’élaboration comment le construire. Durant la phase de construction, la construction

devient effective, puis la dernière phase de transition aboutit, elle, au déploiement du

produit fini.

D’autre part, neuf disciplines sont présentes : la modélisation de processus d’entreprise,

l’expression des exigences, l’analyse et conception, l’implémentation, les tests, le

déploiement, l’environnement de développement, la gestion de projet ainsi que la

configuration et gestion des modifications [Hüsemann 2009-2010].

Cette méthodologie étant une méthodologie itérative qui fonctionne selon le cycle décrit par

la Figure 8, les différentes disciplines sont exécutées en parallèle durant les différentes

phases du modèle tout en étant cependant d’intensités différentes selon les phases.

Pour exemple, prenons la modélisation de processus d’entreprise (Business Modeling) :

selon Figure 9, la discipline apparaît comme relativement importante durant la première

phase, à savoir le lancement puis diminue d’intensité pour devenir quasiment inexistante

dans la dernière phase de transition.

Cette manière d’opérer diminue les risques d’échec du projet et permet de découvrir et de

résoudre les éventuels problèmes dès leur apparition notamment grâce aux tests fréquents.

2.4.2 Scrum®

Scrum® est une méthodologie de gestion de projet agile orientée projet informatique dont

les ressources sont régulièrement actualisées. Elle est issue du travail de Ken Schwaber et

Jeff Sutherland qui en ont défini les grands principes dans les années nonante du siècle

dernier. Elle tire son nom du mot anglais « scrum » qui signifie « mêlée » en référence au

rugby. La « mêlée » est une phase de jeu décisive et permet au jeu de repartir sur d’autres

bases. Par analogie, la méthode Scrum® met ainsi en lumière sa capacité à toujours

réorienter le projet et à toujours être prête à rebondir au fil de l’avancement de ce dernier

[Chef-de-projet 2011, lien 1].

Chaque projet va être divisé en « sprints », périodes fixes d’un mois en théorie mais pouvant

en pratique s’étendre de deux à quatre semaines et en « releases » qui sont une somme de

sprints et qui permettent une visibilité plus globale. A la fin de chaque sprint, une livraison

d’un produit partiel fonctionnel est effectuée [Aubry 2010]. Ce procédé est illustré sur la

Figure 10 ci-dessous.


Figure 10 : Planification Scrum [Wikipedia 2011, lien 1].

La méthode Scrum® dénombre de plus quatre phases principales dans son cycle de

développement : La spécification fonctionnelle (S), l’architecture (A), le codage (C) et les

tests (T). Comme la méthode opère d’une manière agile, ces diverses activités vont être

effectuées en parallèle pendant le sprint [Aubry 2010]. La Figure 11 ci-dessous illustre ce

procédé.

Figure 11 : Les sprints et leurs activités en parallèle [Aubry 2010 p.17].

Scrum® définit également trois rôles principaux, qui vont être actifs tout au long du projet :

le Directeur de produit, le ScrumMaster et l’Equipe. Le Directeur de produit est là pour

représenter les clients et utilisateurs et prend les décisions majeures concernant

l’orientation du projet. L’Equipe s’autogère et collabore afin de rendre ses décisions au

Directeur de produit. Enfin, le ScrumMaster est chargé de « chapeauter » l’Equipe dans sa

prise de décision et de la protéger des éléments perturbateurs extérieurs ; il s’occupe

également des tâches non techniques [Techno-Science 2011, lien 2].

Il semble de plus nécessaire d’expliciter les notions de backlog de produit et de backlog de

sprint : le backlog de produit est constitué par une liste de fonctionnalités à réaliser, le

backlog de sprint comprend lui les diverses fonctionnalités de la liste qui seront

effectivement réalisées durant le sprint [Techno-Science 2011, lien 2].


Ainsi, le schéma global de la méthode apparaît comme explicité par la Figure 12.

Figure 12 : Schéma global méthode Scrum® [Adyax 2010].

2.4.3 Extreme Programming® (XP)

La méthode Extreme Programming est née de la collaboration de Ken Beck, Ron Jeffries et

Ward Cunningham et a officiellement vu le jour en 1999 lors la publication de l’ouvrage

Extreme Programming Explained par Kent Beck [Messager Rota 2010].

Comme son nom l’indique, la méthode tend à placer au centre de tout le projet les activités

de programmation qui apparaissent comme primordiales et comme pilier de la réussite du

projet.

Extreme Programming repose sur quatre valeurs principales : la communication, la

simplicité, la notion de feedback et pour terminer, le courage [Messager Rota 2010].

La communication doit se faire au sein de l’équipe tout d’abord mais également avec le

client qui devient lui aussi un acteur majeur du projet [Comment ça marche 2008, lien 2]. La

simplicité préconise de toujours réfléchir à la solution effective la plus simple possible, sans

bien sûr que cela n’engendre de perte de qualité. Le feedback ou autrement dit le retour

d’information apparaît lui aussi comme étant très important ; ainsi, grâce à des livraisons

régulières, le client peut donner son avis, émettre ses critiques et les changements à

apporter tout au long du projet. Pour terminer, du courage et de l’audace sont nécessaires

dans l’utilisation d’Extreme Programming ; il faut ainsi accepter de se lancer sans avoir

toutes les cartes en main dès le départ et en ne connaissant pas toutes les étapes du projet

ainsi qu’en étant prêt à communiquer de manière transparente et sans tabou avec le client

[Machado 2011].

Extreme Programming repose de plus sur treize pratiques principales, comme l’explicite la

Figure 13 ci-dessous.


Figure 13 : Les treize pratiques d’Extreme Programming [Messager Rota 2010].

Il est tout d’abord possible de dégager plusieurs pratiques relatives à la programmation, à

savoir : la conception simple, le développement piloté par les tests appelés « tests unitaires »

qui seront réalisés fréquemment tout au long du projet, un remaniement continu du code

qui sera retravaillé et amélioré au fil de l’avancement du projet ainsi que des tests de recette

qui permettent de démontrer aux clients le bon fonctionnement des applications et

d’obtenir leur accord pour la poursuite du projet [Messager Rota 2010].

Dans un second temps, il est possible de regrouper plusieurs pratiques relatives à la

collaboration, à savoir : la programmation en binômes qui permet de produire un code de

haute qualité, les règles de codage qui font office de standards et qu’il est nécessaire de

respecter pour pouvoir travailler par paires, la propriété collective du code sur lequel chacun

peut être amené à travailler même sans en être l’auteur original, la métaphore qui traduit le

fonctionnement d’un système informatique en une réalité compréhensible des personnes

sans connaissances informatiques et pour terminer, l’intégration continue qui prône

l’assemblage et les tests fréquents du système afin de détecter et de réparer au plus tôt les

erreurs et problèmes éventuels [Messager Rota 2010].

Pour terminer, il est possible d’isoler les différentes pratiques qui sont relatives à la gestion

de projet, à savoir : le client sur site qui met en évidence l’importance de ce dernier qui est

invité à travailler comme un membre de l’équipe à part entière, la séance de planification

qui permet de réaliser la planification de la réalisation des différentes fonctionnalités,

toujours en étroite collaboration avec le client, les livraisons fréquentes de versions

intermédiaires afin de s’assurer du bon fonctionnement du produit et de sa conformité avec

la demande du client, et finalement, le rythme soutenable [Messager Rota 2010].


La méthode XP propose donc un développement agile, au travers d’itérations très courtes

ainsi que de tests et livraisons fréquentes. La collaboration étroite avec le client permet une

grande réactivité et la possibilité d’immédiatement recentrer le projet si l’on venait à

s’écarter des besoins initiaux.

2.5 Le développement rapide d’applications

Le développement rapide d’applications, plus connu sous le nom de méthode RAD pour

« Rapid Application Development » fut introduit dans les années nonante du siècle dernier

[Hennebert 2011].

La méthode est à cheval entre les méthodes en cascade et les méthodes agiles et propose

une sorte de « développement mixte » [Hennebert 2011].

L’objectif de cette méthode est de développer rapidement des parties du système afin de les

présenter au client et d’obtenir son avis et ses commentaires.

Il existe trois différentes catégories de méthodes dites « RAD », à savoir :

� Le développement de versions

� Le « prototyping »

� Le « throwaway prototyping »

La première catégorie préconise de réaliser le système en plusieurs versions qu’il s’agira de

compléter à chaque fois un peu plus jusqu’à obtenir la version finale et définitive.

Une vue schématique est représentée à la Figure 14 ci-dessous.


Figure 14 : Le "développement de versions" selon la méthode RAD [Hennebert 2011].

Il s’agit donc de définir tout d’abord complètement la première phase de planification, puis

celle d’analyse dans ses grandes lignes ; cette dernière sera ensuite reprise et plus

amplement détaillée par après. Jusque-là, la méthode suit un développement en cascade

traditionnel. Puis, viennent les phases d’ « analyse détaillée », de design et

d’implémentation qui seront, elles, enchaînées à plusieurs reprises jusqu’à couvrir

l’ensemble du projet, à la manière des méthodes agiles. Ceci aboutit à la réalisation de

plusieurs versions du système qui seront présentées et rapidement évaluées par les

utilisateurs avant d’être validées et complétées.

La deuxième catégorie de méthode RAD, le prototyping, préconise la production du système

en passant par différents prototypes qu’il s’agit à chaque fois de faire valider par les

utilisateurs et clients avant de les implémenter effectivement [Hennebert 2011].

Le procédé est illustré par la Figure 15 ci-contre.

Figure 15 : Le "prototyping" selon la méthode RAD [Hennebert 2011].


Pour terminer, le « throwaway prototyping » qui pourrait être traduit par « construction de

prototypes jetables » se base sur le modèle du «prototyping » mais produit des prototypes

sous forme de maquettes où les fonctionnalités ne sont pas implémentées et qui permettent

à l’utilisateur de n’avoir qu’une simple « image » du système.

La Figure 16 présente le procédé.

Figure 16 : Le "throwaway prototyping" selon la méthode RAD [Hennebert 2011].

30 Systèmes d’information, soumissions publiques et règles de soumission


3.1 Introduction

Ce chapitre traite des systèmes d’information ainsi que des soumissions publiques et règles

en vigueur qui les régissent.

Le point 3.2 définit tout d’abord les termes de «soumission publique », d’ « adjudicateur » et

de « soumissionnaire » et les explicite afin de permettre la bonne compréhension de cette

troisième partie.

Le point 3.3 met en lumière les différents types de soumissions publiques existants.

Le point 3.4 précise le processus de soumission d’un projet informatique dans la pratique et

comprend également un exemple et commentaire d’une soumission publique.

Pour terminer, le point 3.5 explicite les diverses règles de soumission de l’OMC ainsi que

leurs buts, avantages et inconvénients.

Ce chapitre répond ainsi à plusieurs questions de recherche précédemment mentionnées

dans l’introduction du travail, à savoir :

� Qu’est-ce qu’une soumission publique ?

� Quelles sont les règles de soumission de la Confédération, selon l’OMC?

� Pourquoi ces règles ont-elles été mises en place ?

� Quels en sont les avantages et les inconvénients ?

� Quel est l’impact d’une soumission publique sur un projet IT ?

3.2 Définition

Un adjudicateur est un membre chargé d’une adjudication [Mediadico 2010]. Dans un

contexte tel que celui des marchés publics, il s’agit de l’entité qui va décider de l’attribution

de la réalisation d’un projet à une institution. La notion est définie dans l’article 2a alinéa 1

de l’ordonnance des marchés publics [OMP 2010] comme suit :

Art. 2a11 Adjudicateurs et activités soumis à la loi

1 Sont soumis à la loi fédérale sur les marchés publics, les adjudicateurs suivants:

a. les organisations de droit public ou de droit privé sous l’influence dominante de la Confédération, notamment les organisations dont la Confédération détient la majorité du capital ou des actions ou dont plus de la moitié des membres de la direction ou de l’organe de surveillance sont des représentants de la Confédération;


b. les organisations de droit privé assurant un service public sur l’ensemble du territoire suisse et bénéficiant de droits exclusifs ou spéciaux délivrés par une autorité compétente.

Ainsi, en Suisse, dans le contexte des soumissions publiques, un adjudicateur est soit une

organisation de droit public ou de droit privé sous l’influence dominante de la

Confédération, soit une organisation de droit privé assurant un service public. Ces entités

vont pouvoir lancer des appels d’offres afin de mener à bien un projet ; ces appels d’offres

sont appelées soumissions publiques.

Les soumissionnaires représentent quant à eux, les entités, entreprises qui vont décider de

participer à une soumission et répondre à l’appel d’offre des adjudicateurs.

3.3 Les différents types de soumissions publiques

Il existe trois différents types de soumissions publiques : la demande de prestation à prix

fixe, la demande de services et pour terminer la demande de ressources humaines.

Ces différents types de soumissions n’apparaissent cependant qu’en pratique et ne sont pas

mentionnés comme tels dans les lois générales qui règlementent la procédure des

soumissions publiques [Köse 2011]. On retrouve cependant quelques renseignements dans

le Code des obligations suisse en ce qui concerne la demande de prestation à prix fixe ainsi

que la demande de services ; pour la demande de ressources humaines, il faut se référer au

Code du travail suisse [Rüegsegger 2011].

Ces différents types de soumissions vont cependant avoir une influence sur le choix de la

méthodologie de gestion de projet à utiliser:

- Dans le cas de la demande de prestation à prix fixe, le critère déterminant est le prix ;

les offreurs vont ainsi déterminer dès le départ le prix auquel ils sont capables d’offrir

la prestation. Le choix de la méthode est donc dans ce cas secondaire et revient aux

soumissionnaires qui pourront eux-mêmes décider du type de méthode à utiliser, à

moins que le type de méthode ne soit explicitement mentionné dans le cahier des

charges publié par l’adjudicateur. Les fonctionnalités à développer étant déjà

préalablement déterminées dans le cahier des charges publié par l’entité

adjudicatrice, à la manière des méthodes en cascade, les soumissionnaires choisiront

donc soit de poursuivre de la sorte, soit de continuer avec une méthode de type

agile.

- Dans le cas de la demande de services, le soumissionnaire pourra s’organiser comme

bon lui semble du moment qu’il reste dans les conditions cadres fixées par

l’adjudicateur.


- Enfin, dans le cas de la demande de ressources humaines, le choix de la méthode

revient à l’adjudicateur qui pourra ainsi choisir le procédé de réalisation du projet ; la

ou les personne (s) engagée(s) se plieront à cette décision.

3.4 Le processus de soumission d’un projet informatique

Le processus de soumission d’un projet informatique est un processus plus ou moins long

selon les projets, jalonné de différentes étapes qui seront explicitées ci-dessous. Notons que

toute la procédure est régie par plusieurs lois strictes sur les marchés publics,

notamment par: La loi fédérale sur les marchés publics (LMP), l’Ordonnance sur les marchés

publics (OMP) et l’Accord sur les marchés publics en vigueur en Suisse depuis le 1er

janvier

1996. Ces règles seront plus amplement détaillées à la section 3.5.

Il est possible de dénombrer trois principaux types de procédures : la procédure ouverte, la

procédure sélective et la procédure de gré à gré qui ne peut être utilisée par l’adjudicateur

qu’uniquement sous certaines conditions. Lors d’une procédure ouverte, l’adjudicateur

lance un appel d’offre auquel chaque soumissionnaire peut présenter une offre ; lors d’une

procédure sélective, chaque soumissionnaire peut présenter une demande de participation,

il advient ensuite à l’adjudicateur d’accepter ou de refuser la participation des

soumissionnaires ; pour terminer, lors d’une procédure de gré à gré, l’adjudicateur adjuge le

marché directement à un soumissionnaire, sans procéder à un appel d’offre. Notons que

cette dernière procédure n’est que rarement applicable dans le cadre de soumissions

publiques informatiques sans violer le principe d’ouverture, de transparence, de libre

concurrence et de non-discrimination [LMP 2010, articles 13 à 16].

La première étape consiste en la réalisation d’un cahier des charges par l’adjudicateur. Ainsi,

toutes les modalités et réquisitions du projet pourront être définies. Le cahier des charges

précise notamment où faire parvenir son offre, la nature de l’adjudicateur, le délai de clôture

pour le dépôt des offres, l’objet du marché, la description des tâches à accomplir ou encore

les conditions générales du marché. La liste complète des renseignements nécessaires et

obligatoires à mentionner dans les documents relatifs à l’appel d’offre sont disponibles à

l’article XII de l’Accord sur les marchés publics :

Art. XII Documentation relative à l’appel d’offres 1. Si, dans des procédures d’appel d’offres, une entité autorise la présentation des soumissions en plusieurs langues, l’une de ces langues sera une des langues officielles de l’OMC. 2. La documentation relative à l’appel d’offres remise aux fournisseurs contiendra tous les renseignements nécessaires pour qu’ils puissent présenter des soumissions valables, notamment les renseignements qui doivent être publiés dans l’avis de marché envisagé, à l’exception de ceux qui sont mentionnés au par. 6 g) de l’art. IX, ainsi que les renseignements suivants: a) l’adresse de l’entité à qui les soumissions devraient être envoyées; b) l’adresse où les demandes d’information complémentaire devraient être envoyées; c) la ou les langues à employer pour la présentation des soumissions et documents d’accompagnement; d) la date limite et le délai de réception des soumissions, ainsi que la période pendant laquelle toute soumission devrait pouvoir être acceptée; e) les personnes admises à assister à l’ouverture des soumissions et la date, l’heure et le lieu de cette ouverture;


f) les conditions de caractère économique et technique, les garanties financières et les renseignements ou pièces, exigés des fournisseurs; g) la description complète des produits ou services demandés ou de toutes exigences, y compris les spécifications techniques et la certification de conformité, auxquelles il faut satisfaire, et les plans, dessins et instructions nécessaires; h) les critères d’adjudication, y compris tous les éléments, autres que le prix, qui seront pris en considération lors de l’évaluation des soumissions, et les éléments des coûts à prendre en compte pour l’évaluation des prix de soumission, tels que frais de transport, d’assurance et d’inspection et, dans le cas de produits ou services d’autres Parties, droits de douane et autres impositions à l’importation, taxes et monnaie du paiement; i) les modalités de paiement; j) toutes autres modalités et conditions; k) conformément à l’art. XVII, les modalités et conditions, s’il en existe, suivant lesquelles les soumissions émanant de pays qui ne sont pas Parties au présent accord, mais qui appliquent les procédures prévues à cet article, seront admises.

Ce cahier des charges va ensuite être publié sur un site spécialisé afin de faire un appel

d’offres public. Pour ce faire, l’adjudicateur suisse se rend sur la plateforme des marchés

publics SIMAP.ch, se logue en tant qu’adjudicateur après s’être préalablement inscrit en tant

que tel et publie son offre qui sera ainsi visible de tous [OMP 2010, art.8 al.1]. La Figure 17

et la Figure 18 ci-dessous illustrent ce procédé.

Figure 17 : Plateforme électronique SIMAP, section « adjudicateur » [Simap 2011].


Figure 18 : Plateforme électronique SIMAP, login adjudicateur [Simap 2011].

Suite à cette publication, les soumissionnaires intéressés pourront s’inscrire, répondre à

l’appel d’offres et faire parvenir leur offre à l’adjudicateur dans les délais impartis, à savoir

au minimum 40 jours à partir de la publication lors d’une procédure ouverte, respectivement

25 jours à partir de la publication pour présenter une offre et 40 jours à partir de l'invitation

à soumettre une offre dans le cas d’une procédure sélective [OMP 2010, art.19 al.3].

Une fois le délai de transmission d’offres passé, l’adjudicateur se charge d’accorder le

marché à un des soumissionnaires selon divers critères d’adjudication. Les critères

d’adjudication principaux sont fixés par l’article 21 de la Loi sur les marchés publics, à savoir

comme suit :

Art. 21 Critères d’adjudication 1 Le marché est adjugé au soumissionnaire ayant présenté l’offre la plus avantageuse économiquement. Celle-ci est évaluée en fonction de différents critères, notamment le délai de livraison, la qualité, le prix, la rentabilité, les coûts d’exploitation, le service après-vente, l’adéquation de la prestation, le caractère esthétique, le caractère écologique et la valeur technique. 2 Les critères d’adjudication doivent figurer par ordre d’importance dans les documents concernant l’appel d’offres. 3 L’adjudication pour des biens largement standardisés peut se faire exclusivement selon le critère du prix le plus bas.

Ainsi, les critères d’adjudication doivent être préalablement mentionnés dans les documents

selon leur ordre d’importance, varient d’un projet à un autre et peuvent concerner divers

aspects à savoir notamment : le délai de livraison, la qualité, le prix, la rentabilité ou encore

les coûts d’exploitation.


Le soumissionnaire sélectionné s’acquittera ensuite de la réalisation du projet comme

convenu, selon les critères définis dans le cahier des charges et les délais accordés.


3.4.1 Exemple et commentaire d’un appel d’offre

Afin de jouir d’une vue plus concrète et plus réaliste des procédures de soumissions

publiques, un exemple d’appel d’offre simple et qui donne une bonne vue d’ensemble,

publié selon la procédure habituelle sur la plateforme SIMAP ® est ici fourni et commenté.

Cet exemple concerne l’Etablissement Vaudois d’Accueil des Migrants (EVAM) qui souhaite,

par cet appel d’offre, la mise en place d’un nouvel environnement informatique et la sous-

traitance de son exploitation informatique.

Toutes les informations de base, réparties en quatre chapitres distincts y sont mentionnées.

Un premier chapitre concerne le pouvoir adjudicateur, à savoir dans ce cas présent,

l’Association Vaudoise d’Accueil des Migrants ; on y retrouve notamment les références et

coordonnées de l’entité adjudicatrice, les délais à respecter, le type de procédure, le genre

de marché ou encore le rattachement ou non rattachement au respect des règles de

soumission de l’OMC. La deuxième section traite, elle, de l’objet du marché et explicite

brièvement la prestation demandée et les termes de l’accord. Le troisième chapitre formule

les diverses conditions cadres de l’exécution. Pour terminer, la quatrième section traite des

diverses "autres informations" ; dans ce cas-ci, nous y retrouvons quelques informations sur

la procédure de recours.

Toutes ces informations sont des informations de base, visibles de tous, et permettent

d’avoir une vue d’ensemble sur les tâches à accomplir et la demande de l’adjudicateur. Il est

ensuite possible de s’ "inscrire" en tant que soumissionnaire afin d’avoir accès à un dossier

plus complet comprenant notamment le cahier des charges. La Figure 19 ci-dessous illustre

ce procédé.

Figure 19 : Procédure d’inscription à un appel d’offre [Simap 2011].


L’appel d’offre lancé par EVAM est visible en entier sur la Figure 20 ci-dessous.

1. Pouvoir adjudicateur

1.1 Nom officiel et adresse du pouvoir adjudicateur

Service d'achat/Entité adjudicatrice : Etablissement Vaudois d'Accueil des Migrants Service organisateur/Entité organisatrice : Etablissement Vaudois d'Accueil des Migrants, à l'attention de Alain Misson, Avenue de Sévelin , 40, 1004 Lausanne, Suisse, Téléphone: 021'557'06'00, Fax: 021'557'06'09, E-mail: [email protected], URL www.evam.ch

1.2 Les offres sont à envoyer à l'adresse suivante

Etablissement Vaudois d'Accueil des Migrants, à l'attention de Alain Misson, Avenue de Sévelin , 40, 1004 Lausanne, Suisse, Téléphone: 021'557'06'00, Fax: 021'557'06'09, E-mail: [email protected]

1.3 Délai souhaité pour poser des questions par écrit

17.12.2010

1.4 Délai de clôture pour le dépôt des offres

Date : 07.02.2011 Heure: 12:00

1.5 Genre de pouvoir adjudicateur

Autres collectivités assumant des tâches cantonales

1.6 Mode de procédure choisi

Procédure ouverte

1.7 Genre de marché

Marché de services

1.8 Soumis à l'accord GATT/OMC, respectivement aux accords internationaux

Oui


2. Objet du marché

2.1 Genre du marché de services

Autres services Catégorie de services CPC: [7] Traitement des données et activités apparentées

2.2 Titre du projet du marché

Sous-traitance de l'exploitation informatique d’EVAM

2.3 Référence / numéro de projet

Sous-traitance de l'exploitation informatique EVAM

2.4 Vocabulaire commun des marchés publics

CPV: 72000000 - Services de technologies de l'information, conseil, développement de logiciels, internet et appui

2.5 Description détaillée des tâches

Prestations d'exploitation informatique (service desk, gestion de l'infrastructure, des plateformes et des applications métiers, postes de travail et imprimantes, réseau). Mise en place du nouvel environnement informatique.

2.6 Lieu de la fourniture du service

Sites de l'EVAM répartis dans le canton de Vaud

2.7 Marché divisé en lots?

Non

2.8 Des variantes sont-elles admises?

Non

2.9 Des offres partielles sont-elles admises?

Non

2.10 Délai d'exécution

10 Jours depuis la signature du contrat


3. Conditions

3.1 Critères d'aptitude

Conformément aux critères cités dans les documents

3.2 Justificatifs requis

Conformément aux justificatifs requis dans le dossier

3.3 Critères d'adjudication:

Conformément aux critères cités dans les documents

3.4 Conditions à l'obtention du dossier d'appel d'offres

Prix: aucuns

3.5 Langues acceptées pour les offres

Français

3.6 Obtention du dossier dáppel dóffres

Sous www.simap.ch Langues du dossier dáppel dóffres : Français

4. Autres informations

4.1 Indication des voies de recours

Le présent appel d’offres peut faire l’objet d’un recours à la Cour de droit administratif et public du Tribunal cantonal, Av. Eugène-Rambert 15, 1014 Lausanne, déposé dans les dix jours dès la publication ; il doit être signé et indiquer les conclusions et motifs du recours. La décision attaquée est jointe au recours.

Figure 20: Appel d’offre EVAM [Simap 2011, publication numéro 561197].


3.5 Les règles de soumission de l’OMC

Les soumissions publiques sont strictement régies par plusieurs groupes de lois et accords.

Ces derniers sont détaillés dans le point 3.5.1 ci-après.

3.5.1 Description et buts

La loi fédérale sur les marchés publics (LMP), loi pionnière dans le domaine, en vigueur

depuis 1994, se charge de régler les processus de soumissions publiques et compte quatre

principaux buts, résumés à l’article 1 de la loi, comme suit:

Art. 1 1 Par la présente loi, la Confédération entend: a. régler les procédures d’adjudication des marchés publics de fournitures, de services et de construction et en assurer la transparence; b. renforcer la concurrence entre les soumissionnaires; c. favoriser l’utilisation économique des fonds publics. 2 Elle entend aussi garantir l’égalité de traitement de tous les soumissionnaires.

La présente loi s’assure ainsi de régler les procédures d’adjudication en général, de renforcer

la concurrence entre les soumissionnaires, de favoriser l’utilisation économique des fonds

publics et de garantir l’équité entre les soumissionnaires.

L’Ordonnance sur les marchés publics (OMP) est, elle, entrée en vigueur en 1996,

complétant ainsi la LMP. Cette ordonnance réglemente spécifiquement l’adjudication des

marchés publics selon la loi, les autres marchés de la Confédération ainsi que le concours de

projets et le concours portant sur les études et la réalisation [OMP 2011, art 1].

Pour terminer, l’Accord plurilatéral sur les marchés publics (AMP) a été conclu à Marrakech

en 1994 et est entré en vigueur en Suisse le 1er

janvier 1996 [OMC 2011]. Actuellement une

quarantaine de pays dont les vingt-sept Etats membres de l’Union européenne sont

signataires. Cet Accord porte spécifiquement sur les marchés publics et les régit en se basant

sur les principes d’ouverture, de non-discrimination et de transparence. Ainsi, le principe

d’ouverture permet de « réaliser l’expansion et une libération plus large du commerce

mondial et d’améliorer le cadre international qui régit le commerce mondial ». Le principe

de non-discrimination veille à la parfaite équité entre les fournisseurs nationaux et étrangers

[AMP 2010, art.III] et pour terminer, le principe de transparence vise à assurer une parfaite

transparence des lois, règlements, procédures et pratiques en matière de marchés publics

[AMP 2010, p.1]. S’ajoute à ces trois principes de base celui de la libre concurrence. Ainsi, les

entités adjudicatrices « ne devront pas donner à un fournisseur des informations concernant

un marché déterminé d’une manière qui aurait pour effet d’empêcher la libre concurrence »

[AMP 2010, art. 7 al.2].


3.5.2 Avantages des règles de soumission pour l’adjudicateur et le

soumissionnaire

Les lois présentées au point 3.5.1 encadrent et veillent au bon déroulement des soumissions

publiques ; de ce fait, autant les soumissionnaires que les adjudicateurs peuvent en tirer

parti.

Tout d’abord, du côté des adjudicateurs, ces règles encadrant toute la procédure, à savoir de

la réalisation du cahier des charges à la sélection, leur fournissent un fil conducteur utile.

Elles assurent également à l’adjudicateur de recevoir des soumissions d’organismes certes

motivés et désireux de s’investir dans le projet puisque ces derniers ne seront bien souvent

rémunérés que s’ils viennent à être sélectionnés pour la réalisation définitive du projet et ne

toucheront rien dans le cas contraire, bien qu’une indemnité peut être versée dans de rares

cas [OMP 2011, art.23] ; les soumissionnaires vont donc se surpasser dans l’espoir de

décrocher le contrat et réaliser ainsi des documents de qualité. L’adjudicateur recevra ainsi

plusieurs offres et pourra faire son choix parmi celles-ci sans être tenu de rémunérer la

participation de tous les soumissionnaires. De plus, l’imposition de cette procédure permet à

l’adjudicateur de transférer ses risques et responsabilités aux soumissionnaires et ainsi de

s’en affranchir partiellement.

Du côté des soumissionnaires, ces règles de soumission offrent également de nombreux

avantages. Tout d’abord, elles garantissent à tous les soumissionnaires une égalité de

traitement et permettent autant aux grandes entreprises disposant de grands moyens

financiers qu’à de plus petites entreprises de postuler. La procédure de soumission étant

rigide, similaire pour tous les soumissionnaires et anonyme dans le cas de la mise au

concours de projets [OMP 2011, art.48], la non-discrimination, non-corruption, la libre

participation et concurrence sont de mise.

Ces avantages sont résumés dans le Tableau 2 ci-après :

Avantages pour l’adjudicateur Avantages pour le soumissionnaire

+ Fournissent un fil conducteur + Egalité de traitement pour tous

+ Réception de documents de qualité,

provenant d’organismes motivés

+ Garantit la non-discrimination

+ Choix parmi plusieurs offres + Evite la corruption

+ Rémunération de l’offre sélectionnée

uniquement

+ Principe de libre concurrence

+ Transfert de risques et de

responsabilités

+ Liberté de participation

Tableau 2 : Avantages des règles de soumissions publiques, pour l’adjudicateur et le soumissionnaire.


Nous pouvons donc ici constater que cette procédure confère bel et bien plusieurs

avantages et cela autant aux adjudicateurs qu’aux soumissionnaires. Au niveau des

adjudicateurs le principal atout de la procédure réside dans le transfert de risques et dans

l’obligation de ne rémunérer que la soumission choisie pour la réalisation du projet. Du côté

des soumissionnaires, le principal avantage se situe dans la liberté de participation et

l’égalité de traitement.

3.5.3 Inconvénients des règles de soumission pour l’adjudicateur et le

soumissionnaire

Malgré les nombreux avantages que présente l’institution des règles de soumission, ces

dernières peuvent également présenter quelques inconvénients.

Dans un premier temps, du côté des adjudicateurs, ces règles strictes peuvent parfois

représenter un cadre contraignant et trop rigide. De plus, ces règles fournissent une marche

à suivre précise et réduisent ainsi la liberté d’action des adjudicateurs et imposent de

surcroît un supplément de documents administratifs et de procédures à gérer. Le fait de

devoir passer par une soumission publique peut également être vu comme une « perte de

temps » puisque toute la procédure aura un impact significatif sur les délais de réalisation du

projet qui seront de ce fait rallongés.

Du côté des soumissionnaires, ces règles peuvent également être vues comme trop strictes

et contraignantes. De plus, en soumettant une offre, ces derniers n’ont aucune garantie de

rémunération et peuvent au final avoir réalisé des investissements autant temporels que

financiers dans le vide, si leur offre n’est pas sélectionnée par l’adjudicateur pour la

réalisation du projet.

D’un point de vue plus technique, comme l’a explicité Monsieur Turabi Köse lors de son

interview, les « unités IT » ont plutôt toujours tendance à penser de manière agile, ceci

contrairement aux entités dites « business » qui pensent, elles, à la manière des méthodes

en cascade et apprécient particulièrement la planification clairement établie et très précise

dès le départ du projet ainsi que les étapes formellement délimitées. De ce fait, les

processus de soumission impliquent bien souvent la combinaison de méthodes en cascade

et itératives ; la première phase d’analyse des besoins étant déjà complètement définie dans

le cahier des charges réalisé par l’adjudicateur, le soumissionnaire enchaînera cependant

bien souvent avec une méthode agile qui présente moins de risques. Ce procédé pouvant

parfois s’avérer plutôt compliqué, sera plus amplement détaillé dans le chapitre 4 de ce

travail.

Un autre inconvénient pour les soumissionnaires est « l’endossement des risques ». Ainsi,

autant lors de la demande de prestation à prix fixe ou de services que dans le cas de la

demande de ressources humaines, dès la signature du contrat, le fournisseur de la


prestation devient responsable de la réalisation du projet selon le cahier des charges et va

de ce fait endosser les risques. Pour exemple, un dépassement du prix fixé au préalable dans

le cahier de charges ne sera pas pris en compte par l’adjudicateur et sera entièrement à

charge du soumissionnaire qui fait donc seul face à des risques de pertes [Köse 2011].

Ces inconvénients sont résumés dans le Tableau 3 ci-dessous :

Inconvénients pour l’adjudicateur Inconvénients pour le soumissionnaire

- Cadre strict et contraignant - Cadre strict et contraignant

- Peu de liberté d’action - Aucune garantie de rémunération

- Rallongement des délais - Combinaison de méthodes en

cascade et itératives contraignante

- Perte de temps - Endossement des responsabilités et

des risques

- Gestion administrative

supplémentaire

- Risque de perte

Tableau 3 : Inconvénients des règles de soumission pour l’adjudicateur et le soumissionnaire.

Nous remarquons donc que les inconvénients sont également partagés entre les

adjudicateurs et soumissionnaires. Du côté des adjudicateurs l’inconvénient majeur est sans

doute le rallongement des délais. Du côté des soumissionnaires, les désagréments les plus

importants sont l’endossement des responsabilités et les risques de pertes.

L’analyse des avantages et des inconvénients de la procédure de soumission publique

réalisée aux points 3.5.2 et 3.5.3 permet de tirer plusieurs conclusions. Tout d’abord, bien

que l’étude ne soit que sommaire et non exhaustive, il est cependant possible d’en dégager

la tendance principale et de remarquer ainsi qu’avantages et inconvénients existent autant

pour les adjudicateurs que pour les soumissionnaires. Ensuite, nous pouvons observer que

les adjudicateurs vont pouvoir bénéficier des avantages de l’imposition de la procédure de

soumission mais n’auront pas grands moyens à disposition pour pallier les inconvénients de

cette dernière puisque la procédure est obligatoire dans de nombreux cas. Les

soumissionnaires, eux, pourront par contre, sur la base de ces avantages et inconvénients

existants, prendre la décision de répondre à un appel d’offre ou au contraire de ne pas y

prendre part s’ils jugent que les risques sont trop importants.

44 Combiner une méthode agile avec une méthode en cascade


4.1 Introduction

Les méthodes de gestion de projet en cascade et itératives semblent à priori antagonistes et

incompatibles. Dans la pratique cependant, il existe plusieurs situations dans lesquelles ces

méthodes peuvent se compléter et être simultanément utilisées dans un même projet ; ceci

arrive fréquemment dans le contexte des soumissions publiques.

Ce chapitre vise tout d’abord à expliquer les motivations de l’entreprise à utiliser un tel

procédé. Le point 4.3 tentera, lui, de mettre en lumière les principaux avantages de

l’utilisation combinée des méthodologies en cascade et itératives. Le point 4.4 démontrera

les inconvénients majeurs de la combinaison de méthodes en cascade et agiles.

Pour terminer, un cas plus concret sera étudié au point 4.5.

Par ces divers points, le chapitre répond aux questions initiales du travail suivantes :

� Quelles raisons peuvent pousser une entreprise à combiner une méthode en cascade

avec une méthode agile ?

� Comment combiner une méthodologie de gestion de projet en cascade avec une

méthode agile ?

� Quels sont les avantages et inconvénients d’une telle combinaison ?

4.2 Motivations de l’entreprise à utiliser un tel procédé

Ce travail étant principalement axé sur l’utilisation des méthodologies de gestion de projet

dans le cadre des soumissions publiques, ce point se limitera à l’analyse des motivations des

entreprises à combiner méthodes en cascade et itératives dans ce même contexte.

Ainsi, pour commencer, il convient tout d’abord de rappeler que lors d’une soumission

publique, toutes les tâches relatives à l’exécution du projet sont explicitées dans le cahier

des charges publié, en Suisse, sur la plateforme SIMAP ® (voir point 3.4). Le corps du travail à

exécuter est donc déjà établi et explicité dans ce document ; pour cette raison, il est

judicieux de considérer que toute la recherche dite d’ « avant-projet » et la phase d’analyse

sont quasiment déjà complétées avant la publication de la soumission. Ainsi, le démarrage

du projet est bien souvent fait à la manière des méthodes en cascade, la phase d’analyse

étant entièrement complétée avant de passer aux phases suivantes.


Les entreprises soumissionnaires ont donc deux options face à ces faits établis : soit

poursuivre à la manière en cascade, en complétant chaque phase avant de passer à la

suivante, soit poursuivre en changeant de procédé et en utilisant une méthode dite « agile ».

Dans la pratique, bien que la combinaison d’une méthode en cascade et itérative soit plus ou

moins compliquée, plusieurs entreprises optent pour ce choix. Comme précédemment

discuté plus haut au point 2.3, les méthodes en cascade sont plus faciles d’utilisation et

pratiques mais elles comportent également plusieurs désavantages importants comme la

réalisation très tardive des tests qui peut bien souvent faire échouer le projet

définitivement, et cela seulement dans la phase finale de ce dernier, alors que beaucoup de

moyens autant financiers que temporels ont déjà été déployés pour la réalisation des

premières phases.

Pour cette raison principalement, les entreprises qui optent pour la poursuite du projet à

l’aide de méthodes agiles, font face à moins de risques, bénéficient d’un meilleur suivi du

projet ainsi que d’une meilleure flexibilité et de plus grandes chances d’aboutissement grâce

aux tests récurrents notamment qui sont effectués tout au long de la réalisation du projet.

Pour mieux comprendre la réalité de ces faits, il est possible d’illustrer le phénomène par un

schéma, comme suit :

Figure 21 : Combinaison d’une méthode en cascade et d’une méthode itérative.

L’appellation des différentes phases d’un projet informatique varie autant entre les

méthodes dites en cascade et celles qui sont itératives qu’entre les méthodologies elles-

mêmes, pourtant toutes ces méthodes couvrent une même réalité.

Ainsi, les phases ci-dessus reprennent les phases typiques d’un projet dit en cascade mais

peuvent également couvrir la réalité des phases des méthodes agiles.


Nous y retrouvons donc, six principales phases, à savoir : une première phase d’analyse des

besoins, une phase de conception, la réalisation, les tests, le déploiement et la maintenance.

A ces six phases traditionnelles, précède souvent une phase dite d’ "avant-projet" qui

comprend l’analyse préalable nécessaire à la réalisation du projet. On y retrouve une étude

d’opportunité qui évalue la demande et explique l’idée générale du projet, une étude de

faisabilité qui comprend principalement une estimation des coûts, une étude détaillée qui

approfondit l’analyse et permet la réalisation d’un cahier des charges et pour terminer, une

étude technique qui se focalise sur les aspects techniques et le fonctionnement du projet [Le

Journal du Net 2008].

La Figure 21 illustre en vert les phases fixes, déjà déterminées et réalisées par l’entité

adjudicatrice avant la publication de la soumission : la première phase d’avant-projet et la

phase d’analyse des besoins. En bleu, les diverses phases qui doivent être complétées par les

partenaires ou sous-traitants à savoir les soumissionnaires et qui peuvent possiblement être

réalisées d’une manière agile, donc en étant enchaînées les unes après les autres jusqu’à

l’achèvement du projet.

Ceci démontre donc qu’une combinaison de ces types de méthodes plutôt opposées de

prime abord est bel et bien possible, à condition d’une délimitation claire des phases

réalisées selon un procédé en cascade et des phases à réaliser d’une manière itérative ainsi

que d’une organisation rigoureuse [Chesaux 2011].

4.3 Avantages

La combinaison d’une méthode en cascade et d’une méthode agile comprend plusieurs

avantages bien qu’elle soit parfois laborieuse et compliquée.

Comme l’a mentionné lors de son interview Monsieur Turabi Köse, chef de programme e-dec

à l’OFIT, les informaticiens ont toujours tendance à penser à la façon des méthodes

itératives, simplement car ils ont conscience des risques et tentent par ce biais de les

diminuer. Pour cette raison, naturellement ils se tourneront vers des méthodes agiles si le

choix leur revient, comme dans le cadre des soumissions publiques. La combinaison de ces

deux types de méthodes permet donc également la combinaison et la satisfaction de deux

« mondes » opposés : l’IT et le business.

L’utilisation de méthodes agiles permet également de réaliser des prototypes ou des

versions bêtas qu’il est ainsi possible de tester durant l’avancement du projet et de rectifier

selon les besoins.

Enfin, un développement agile permet de remettre en question et de modifier les besoins et

exigences du système durant sa réalisation, ce qui s’avère très difficile dans un

développement en cascade puisque ces diverses exigences sont fixées dès le départ du


projet. En ce sens, l’utilisation combinée confère un réel avantage pour les différents acteurs

du projet qui pourront désormais retravailler et modifier les exigences de base au besoin.

4.4 Inconvénients

Malgré les avantages, la combinaison méthode en cascade – agile a également plusieurs

inconvénients.

Tout d’abord, cette combinaison implique une rigueur de travail et la découpe parfaite des

phases à réaliser en cascade et celles à réaliser de manière itérative. Il faut donc une parfaite

entente et coordination au sein de l’équipe de réalisation.

Ensuite, le fait de ne pas « aller au bout » de l’approche agile peut également être vu comme

un inconvénient puisque certaines phases seront à garder en cascade.

Du côté des managers ou du business en général, cette utilisation combinée peut être

déroutante et compliquée à intégrer ; il sera ainsi plus difficile de connaître exactement

l’avancement du projet à un « moment T » précis ou les tâches restant encore à réaliser.

4.5 Le cas du projet Insieme®

4.5.1 Description du projet

Insieme est un projet informatique suisse qui a été lancé par l’Administration fédérale des

contributions (AFC) en 2005. Il s’agissait par le biais de ce projet de remplacer en intégralité

les anciens systèmes informatiques de l’AFC et de mettre sur pieds une plateforme

électronique qui faciliterait l’accès en ligne des contribuables et qui permettrait également

une exécution claire et rapide des affaires [EFD Admin 2011].

Tout ceci devait conduire à des économies significatives, plus d’efficience et de performance

ainsi qu’une qualité accrue. Or, ce projet de grande envergure a connu plusieurs difficultés

et a même été arrêté avant d’être relancé en 2010 après l’accord du Conseil Fédéral pour la

demande d’un crédit d’engagement supplémentaire [EFD Admin 2011].

Pour ces diverses raisons, les informations sur le projet restent maintenant assez

confidentielles et les responsables préfèrent ne pas s’exprimer sur le sujet. L’analyse se fera

donc sur la base des informations disponibles et les hypothèses qu’il sera possible d’en tirer.

4.5.2 La réalisation du projet

Le procédé de réalisation d’Insieme s’appuie sur la combinaison des méthodes Hermes et

Scrum [Puzzle ITC Blog 2010]. En ce sens, le projet combine donc une méthode en cascade et

une méthode agile et constitue un cas pratique intéressant à étudier.


Comme explicité plus haut au point 2.3.2, la méthode Hermes fonctionne sur un modèle de

développement en cascade et comporte six principales phases, à savoir : l’initialisation,

l’analyse préliminaire, la conception, la réalisation, l’introduction et la finalisation [Hermes

2010, lien 1].

Comme également présenté précédemment dans le travail, la principale force d’Hermes

réside dans sa structure solide, très complète et de qualité, qui documente l’intégralité d’un

projet. Le principal atout de la méthode Scrum réside lui dans son développement agile ainsi

que dans sa structure adaptative très actuelle et qui diminue considérablement les risques

du projet.

Pour ces raisons, lors de la combinaison de ces deux méthodes, il semble judicieux de

conserver comme base la méthode Hermes et d’y insérer la méthode Scrum dans les phases

de « construction » du projet à proprement parler.

La première phase d’initialisation est ainsi à garder selon un développement en cascade tout

comme la première partie de l’analyse préliminaire qu’il semble judicieux de définir au

départ mais qui pourra tout de même être révisée par la suite si le besoin se présentait. Les

phases suivantes de conception, de réalisation et d’introduction sont, elles, particulièrement

adaptées à un développement itératif ; ainsi, des livraisons et tests fréquents pourront être

réalisés afin de s’assurer du bon fonctionnement du système à construire et de rectifier le tir

instantanément dans le cas contraire. Pour terminer, la dernière phase de finalisation

intervient dès l’achèvement complet du projet et peut de ce fait être réalisée selon les

méthodes classiques, à la manière du développement en cascade.

La Figure 22 ci-dessous illustre ce procédé.

Figure 22 : Combinaison Hermes / Scrum.

Hermes documente de plus désormais cette combinaison "Hermes-Scrum" dans une

présentation disponible sur internet gratuitement. Nous y retrouvons foule d’informations

sur le sujet et notamment sur le fonctionnement concret du processus de combinaison des

méthodes qui y est explicité par un schéma, repris ici à la Figure 23 ci-dessous.


Nous retrouvons tout d’abord les différentes phases traditionnelles de la méthode Hermes.

Dans un second temps, nous remarquons l’utilisation de Scrum particulièrement dans les

phases de construction pure du projet, à savoir : la phase de conception, de réalisation et

d’introduction. Ces phases seront enchaînées à la manière des méthodes itératives et ce

jusqu'à l’achèvement complet du projet ; les différents "sprints" vont donc être enchaînés

jusqu’à la couverture complète des tâches à réaliser.

Les traits rouges, orange et verts sur l’image sont à lire verticalement et représentent les

exigences du projet. Un trait rouge indique une exigence planifiée et donc à réaliser

prochainement, un trait orange représente une exigence en cours d’implémentation et pour

terminer, un trait vert représente une exigence implémentée de manière complète [Hermes

2010, lien 2]. A la fin de la phase d’introduction, toutes les exigences sont implémentées et

la phase ultime de finalisation peut débuter.

Cette manière de faire est vraisemblablement celle qui fut effectivement utilisée dans le

projet Insieme.

Figure 23 : Le processus de combinaison des méthodes Hermes et Scrum [Hermes 2010, lien 2].

50 Conclusion

5 Conclusion

Ce travail s’est tout d’abord attaché à démontrer la division qu’il existe entre les méthodes

en cascade et les méthodes agiles. Nous avons pu constater à ce sujet qu’il existe de

nombreuses méthodes qui ont, à chaque fois, une manière de faire et un fonctionnement

propre. Une brève description des "méthodes RAD" a également exposé que la scission

entre les méthodes dites en cascade et les méthodes fonctionnant de manière itérative n’est

en réalité pas si claire et qu’il existe diverses méthodes qui se situent « à cheval » entre ces

deux catégories.

La thèse s’est ensuite attelée à définir et expliciter le processus des soumissions publiques,

notamment par le biais de la présentation des diverses lois qui régissent ce domaine mais

également par un exemple concret de soumission, tiré de la plateforme SIMAP®, plateforme

informatique accessible en ligne, où sont déposées les divers appels d’offres ou soumissions

en Suisse. A ce sujet, nous remarquons que toute la procédure des soumissions est très

réglementée et cela non seulement au niveau de la Confédération mais également à

l’échelle européenne. Toutes ces lois confèrent un cadre très rigide auquel il faut se plier;

ceci amène au final autant d’avantages que d’inconvénients que ce soit pour les

adjudicateurs ou les soumissionnaires qui vont répondre à un appel d’offre.

Dans un troisième temps, nous nous sommes concentrés sur la combinaison des méthodes

en cascade et des méthodes agiles. Grâce à l’opinion de différents spécialistes ainsi que

l’étude du cas concret du projet suisse Insieme, nous pouvons conclure qu’une combinaison

de ces deux types de méthodes est bel est bien possible. A condition de faire preuve d’une

rigoureuse organisation et d’une bonne communication, le procédé amène bon nombre

d’avantages comme notamment un important gain de flexibilité, une meilleure adaptabilité

et une diminution des risques. Pour cela, lors de soumissions publiques, les soumissionnaires

répondant à un appel d’offre pourront décider de procéder de la sorte.

Nous remarquons également qu’en Suisse, ce procédé tend à se démocratiser. Hermes®

propose désormais diverses documentations qui expliquent comment combiner la méthode

avec d’autres méthodes agiles comme le RUP® ou encore Scrum®. La méthode a ainsi trouvé

un moyen de résister face au nouveau "trend" de l’utilisation des méthodes agiles et de

palier ses faiblesses et va certainement continuer à se développer dans ce sens à l’avenir.

Ceci permettra à Hermes® de rester sur le devant de la scène en Suisse tout en satisfaisant

un peu plus les unités informatiques qui, bien que lui reconnaissant une documentation sans

faille et très complète, lui reprochaient son manque d’agilité et sa structure trop rigide.

Il serait donc intéressant de rester attentif au développement futur de la méthode suisse et

de constater son évolution effective dans quelques années.

51 Conclusion

Sur un plan plus personnel, la réalisation de ce travail m’a permis d’approfondir mes

connaissances des méthodologies de gestion de projet, de découvrir le fonctionnement des

soumissions publiques et de développer une meilleure aisance dans la rédaction scientifique.

Malgré la recherche d’informations qui fut parfois compliquée, ce travail fut intéressant à

réaliser. La rencontre avec les divers spécialistes, qui se sont montrés très disponibles, ainsi

que l’étude du projet Insieme furent très enrichissantes et m’ont permis de compléter la vue

théorique qui ressortait de la première partie du travail d’une vue plus pratique.

52 6. Bibliographie

6. Bibliographie

6.1 Livres

[Aubry 2010] Aubry, Claude : Scrum : Le guide pratique de la méthode agile la plus populaire,

InfoPro, Paris, 2010.

[Dionisi 1997] Dionisi, Dominique : L’essentiel sur Merise, Eyrolles, Paris, 1998.

[Kruchten 2000] Kruchten, Philippe : Introduction au Rational Unified Process, Eyrolles,

Marsat, 2000.

[Kroll/ Kruchten 2003] Kroll, Per et Kruchten, Philippe: Guide pratique du RUP, CampusPress,

Paris, 2003.

[Messager Rota 2010] Messager Rota, Véronique : Gestion de projet agile, Eyrolles, Paris,

2010.

[Tardieu / Rochfeld / Colletti 2000] Tardieu, Hubert, Rochfeld, Arnold et Colletti, René : La

méthode Merise : principes et outils, Editions d’Organisation, Paris 2000.

53 6. Bibliographie

6.2 Sites internet

[Adyax 2010] "Méthodes de développement agiles (SCRUM) : Sprints et Releases"

http://www.adyax.com/methodes-de-developpement-agiles-scrum-sprints-et-releases,

consulté le 1er février 2011.

[Aguilera 2006]

http://vaguilera.free.fr/sysin06/s5/s5-6.pdf, consulté le 27 janvier 2011.

[AMP 2010]

http://www.admin.ch/ch/f/rs/1/172.056.1.fr.pdf, consulté le 8 février 2011.

[Bellouti 2007] " Le développement itératif"

http://bellouti.wordpress.com/2007/09/24/le-developpement-iteratif/, consulté le 22

janvier 2011.

[Chef-de-projet 2011, lien 1] " Scrum méthode de développement agile"

http://www.chef-de-projet.org/methode/scrum.htm, consulté le 30 janvier 2011.

[Chef-de-projet 2011, lien 2] "Qu’est-ce que Prince2 ? Méthode de management de projet"

http://www.chef-de-projet.org/methode/prince2.htm, consulté le 14 avril 2011.

[Comment ça marche 2008, lien 1] " Merise ".

http://www.commentcamarche.net/contents/merise/concintro.php3, consulté le 22 février

2011.

[Comment ça marche 2008, lien 2] " Méthodes agiles ".

http://www.commentcamarche.net/contents/genie-logiciel/methodes-agiles.php3, consulté

le 22 janvier 2011.

[Cybermed Jussieu 2011]

http://www.cybermed.jussieu.fr/Broussais/InforMed/LIVRES/TraitInfo/Fic/Chapitre2/Chap2.

html, consulté le 25 janvier 2011.

[Dantotsu PM 2009] " En cascade + RUP + agile : complémentarité plutôt qu’opposition "

http://dantotsupm.com/2010/01/28/en-cascade-rup-agile-complementarite-plutot-

quopposition/, consulté le 24 janvier 2011.

54 6. Bibliographie

[Derdak 2011] "Management de projets, levier stratégique pour les organisations"

http://derdak.blogspot.com/2009/01/prince2-management-de-projets-selon.html, consulté

le 15 avril 2011.

[EFD Admin 2011]

http://www.efd.admin.ch/dokumentation/medieninformationen/00467/index.html?lang=fr

&msg-id=33787, consulté le 19 avril 2011.

[Hermes 2010, lien 1]

http://www.hermes.admin.ch/welcome?set_language=fr&cl=fr, consulté le 20 janvier 2011.

[Hermes 2010, lien 2] "HERMES et l’agilité"

http://www.hermes.admin.ch/services/utilitaires/gestion-de-projet-en-general/hermes-et-l-

agilite-exemplifie-avec-scrum?set_language=fr&cl=fr, consulté le 24 avril 2011.

[IBM 2005] "RUP in the dialogue with Scrum”

http://www.ibm.com/developerworks/rational/library/feb05/krebs/, consulté le 22 avril

2011.

[IBM 2011] "Rational Unified Process (RUP)"

http://www-01.ibm.com/software/awdtools/rup/, consulté le 25 janvier 2011.

[IS NET 2005]

http://lgl.isnetne.ch/isnet72/Phase7/diffusion.htm, consulté le 27 janvier 2011.

[ITpedia 2010] "Prince2 : la méthode de A à Z"

http://itpedia-fr.com/2010/04/24/la-methode-de-a-a-z/, consulté le 15 avril 2011.

[Le Journal du Net 2008] "Les dossiers techniques en gestion de projet informatique –

Journal du Net Développeurs"

http://www.journaldunet.com/developpeur/algo-methodes/analyse/les-dossiers-

techniques-en-gestion-de-projet-informatique.shtml, consulté le 10 mars 2011.

[LMP 2010] "Loi fédérale sur les marchés publics"

http://www.admin.ch/ch/f/rs/1/172.056.1.fr.pdfhttp://www.admin.ch/ch/f/rs/1/172.056.1.

fr.pdf, consulté le 6 février 2011.

[Machado 2011] "Extreme Programming"

http://extremeprogramming.free.fr/page.php?page=fondements, consulté le 12 avril 2011.

55 6. Bibliographie

[Mediadico 2010] "Adjudicateur : définition et synonyme de adjudicateur dans le

dictionnaire MEDIADICO"

http://www.mediadico.com/dictionnaire/definition/adjudicateur/1, consulté le 7 février

2011.

[OMC 2011] Organisation Mondiale du commerce : " Accord sur les marchés publics ".

http://www.wto.org/french/tratop_f/gproc_f/gpa_overview_f.htm, consulté le 7 février

2011.

[OMP 2011] "Ordonnance sur les marchés publics"

http://www.admin.ch/ch/f/rs/1/172.056.11.fr.pdf, consulté le 7 février 2011.

[Prince2 2011]

http://www.prince2.ch/fr/prince2_tm/, consulté le 10 avril 2011.

[Puzzle ITC Blog 2010] "Puzzle unterstützt BIT und ESTV in Java Grossprojekt "

http://www.puzzle.ch/blog/articles/2010/07/19/puzzle-unterstuetzt-bit-und-estv-in-java-

grossprojekt/, consulté le 20 avril 2011.

[QRP International 2011] "Qu’est-ce que Prince2 ?"

http://www.qrpinternational.fr/index/prince-2/what-is-prince2, consulté le 14 avril 2011.

[Simap 2011] Système d’information sur les marchés publics en Suisse.

https://www.simap.ch/shabforms/COMMON/application/applicationGrid.jsp?template=1&v

iew=1&page=/MULTILANGUAGE/simap/content/start.jsp&language=FR, consulté le 15

février 2011.

[Software-development-resource 2011] “Agile Software Development Process”

http://www.software-development-resource.com/software-process-types.html, consulté le

25 janvier 2011.

[Techno-Science 2011, lien 1] " Processus itératif – Définition"

http://www.techno-science.net/?onglet=glossaire&definition=11411, consulté le 22 janvier

2011.

[Techno-Science 2011, lien 2] "Scrum-définition"

http://www.techno-science.net/?onglet=glossaire&definition=797, consulté le 1er

février

2011.

56 6. Bibliographie

[Wikipedia 2011, lien 1] " Scrum "

http://fr.wikipedia.org/wiki/Scrum_(m%C3%A9thode), consulté le 22 janvier 2011.

[Wikipedia 2011, lien 2]

http://fr.wikipedia.org/wiki/PRINCE2, consulté le 12 avril 2011.

57 6. Bibliographie

6.3 Autres

[Chesaux 2011]

Chesaux Ludovic : Interview sur la gestion de projet, avril 2011 (voir annexe A.3).

[Hüsemann 2009-2010]

Hüsemann Stefan : cours de « Systèmes d’information », Université de Fribourg, 2009-2010.

[Hennebert 2011]

Hennebert Jean : cours d’ "IT Project Management", Université de Fribourg, SP 2011. [Köse 2011]

Köse Turabi : Interview sur la gestion de projet, Berne, avril 2011 (voir annexe A.1).

[Rüegsegger 2011]

Rüegsegger Hans : Interview sur les soumissions publiques, Berne, avril 2011 (voir annexe

A.2).

58 Annexe

A. Annexe

A.1 Interview Turabi Köse, chef de programme e-dec à l’OFIT.

1) Méthodologies de gestion de projet

- Quelles raisons peuvent pousser une entreprise à combiner une méthodologie agile

avec une méthodologie en cascade ?

T.K : L’informatique est une science compliquée. De manière générale on retrouve une

scission entre la pensée « business » qui pense en cascade et qui souhaite avoir un

planning précis et prédéfini de toutes les opérations et la pensée IT qui est de manière

générale beaucoup plus orientée vers l’agilité. Pour cette raison notamment une

combinaison entre une méthode en cascade et une méthode agile peut être mise en

pratique.

- Quels sont les avantages et inconvénients majeurs d’une telle combinaison ?

T.K : Utiliser une méthode itérative permet de diminuer les risques. Si on compare un

projet informatique à la construction d’un tunnel, il s’agirait de « sonder la

montagne » avant de poursuivre la construction et cela afin de diminuer les risques et

de les connaître à l’avance.

- Avez-vous plutôt l’habitude de travailler avec des méthodologies de type Waterfall

ou itératives ? Pour quelles raisons ?

T.K : Au niveau de la Confédération, l’utilisation de la méthode Hermes est obligatoire.

Pour cette raison, nous travaillons avec cette méthodologie en cascade. Il est

cependant possible d’utiliser cette méthode en y ajoutant un côté agile, en réalisant

plusieurs phases d’une manière itérative… Il est ainsi possible de faire une partie de la

programmation et de livrer des prototypes au client.

- Le nouveau « trend » de l’utilisation des méthodes agiles est-il justifié ? Est-ce selon

vous une tendance passagère ou va-t-il durablement s’inscrire ?

T.K : L’IT en général pense toujours de manière itérative, il n’est pas possible de faire

autrement. Si une erreur est trouvée, la réparer coûte peu cher si elle est découverte

assez tôt mais très cher s’il s’agit de la résoudre seulement à la fin, comme dans les

méthodologies en cascade dans lesquelles le coût du changement est ainsi très élevé.

Pour cela, les méthodes itératives vont certainement encore se développer dans le

futur.

- Pensez-vous que la méthodologie Hermes utilisée par la Confédération a encore de

beaux jours devant elle ou un changement est à prévoir pour peut-être aller vers une

méthode plus agile ?

59 A.1 Interview Turabi Köse, chef de programme e-dec à l’OFIT.

T.K : La méthode Hermes est faite pour que tout le monde puisse comprendre le

déroulement du projet, y compris les personnes sans connaissances informatiques, en

particulier les managers. Elle permet une vue claire et structurée du projet,

compréhensible de tous et est donc intéressante de ce point de vue.

A mon sens cependant, cette méthodologie ne survivra pas encore longtemps.

L’aspect formel pourrait cependant être conservé tout en allant dans une direction

plus itérative ou en la combinant presque systématiquement avec des méthodologies

plus agiles, type "RUP" ou "Scrum".

2) Soumissions publiques

- Quel est l’impact d’une soumission publique sur un projet IT ?

T.K : Une soumission publique a un grand impact sur un projet informatique. Hermes

convient particulièrement aux publications, car tout y est clairement décrit. De plus,

dans le cas de la "demande de prestation à prix fixe", cela permet à l’entreprise de se

couvrir en s’assurant d’avoir au final sa prestation au prix qu’elle a fixé dès le départ

et de transmettre ainsi le risque à l’externe, puisque dans le cas d’un dépassement du

prix par le soumissionnaire, l’entreprise n’en sera pas responsable et n’aura donc pas

à en assumer les conséquences. D’un autre côté, ces procédures coûtent énormément

en temps et en argent.

- Quel pourcentage de projets passe-t-il par des soumissions ? Pour quelles raisons

certains projets passent-ils à côté du processus de soumission habituel ?

T.K : Il est difficile de donner un pourcentage précis. En théorie tous les projets doivent

être soumis publiquement si leur valeur dépasse 263'000 CHF (voir Loi sur les marchés

publics, article 6). Il existe cependant des exceptions et des parades qu’il est possible

de trouver pour échapper à la procédure de soumission habituelle. Ainsi, par exemple,

la rareté des offreurs d’une prestation permettrait de soumettre le projet directement

à l’offreur capable de réaliser la prestation souhaitée et cela sans passer par une

soumission publique.

- Des contrôles du respect de l’Accord sur les marchés publics sont-ils effectués ?

T.K : Oui, divers contrôles sont effectués par différentes entités, comme par exemple

le GS-EFD (Fédération de contrôle financier).

- Il existe apparemment trois différents types de contrats dans le cadre des

soumissions publiques : la demande de prestation à prix fixe déterminé par les

offreurs, la demande de services et la demande de ressources humaines. Ces

différents types de contrats sont-ils réglés légalement ou apparaissent-ils seulement

dans la pratique ?

60 A.1 Interview Turabi Köse, chef de programme e-dec à l’OFIT.

T.K : Il existe bel et bien trois différents types de contrats. Cependant ces derniers ne

sont pas mentionnés tels quels dans la loi et n’apparaissent que dans la pratique. Ceci

certainement pour ne pas entrer dans trop de détails techniques et afin que la loi

reste compréhensible de tous.

- Quels sont les avantages de la demande de ressources humaines qui est de plus en

plus fréquente ? Cela comporte-t-il des risques (mauvaise intégration au sein de

l’équipe, manque de connaissances du projet, façon de travailler inadéquate…) ?

T.K : La demande de ressources humaines comprend de nombreux avantages et

relativement peu de risques. Si la personne envoyée ne convient pas, la firme qui a

fourni cette personne doit la remplacer par une autre, plus compétente et plus

adaptée.

Turabi Köse

Bern, 12. April 2011.

61 A.2 Interview Hans Rüegsegger, responsable des demandes de ressources humaines à

l’OFIT.

A.2 Interview Hans Rüegsegger, responsable des demandes de ressources

humaines à l’OFIT.

- Welches sind die Auswirkungen einer öffentlichen Submission auf ein IT-Projekt?

H.R: Das Vergabeverfahren ist immer ein massgeblicher Teil eines IT-Projekts und

wird deshalb oft als Teilprojekt definiert und in der Gesamtplanung berücksichtigt.

Es gibt grundsätzlich drei Vergabeverfahren

� Öffentliche Ausschreibung

� Einladungsverfahren

� Freihändiges Verfahren

Diese haben in terminlicher Hinsicht unterschiedlich starke Auswirkungen. Eine

öffentliche Ausschreibung z.B. nimmt zwischen 6-9 Monaten in Anspruch. Diese Zeit

muss in der Projektplanung zwingend berücksichtigt werden.

- Welcher Prozentsatz von Projekten läuft über Submissionen? Aus welchem Grund

gehen bestimmte Projekte neben dem üblichen Submissionsvorgang vorbei?

H.R: Die Regeln des öffentlichen Beschaffungswesens werden im BIT in jedem

Vergabeverfahren angewendet.

Folgende Kriterien sind für die Wahl des entsprechenden Vergabeverfahrens

entscheidend:

� Beschaffungsgegenstand

� Auftragsvolumen

� Marktsituation

Bei einer mutmasslichen Übertretung des Schwellenwerts von CHF 230‘000.- (exkl.

MWST) erfolgt gemäss dem Bundesgesetz über das öffentliche Beschaffungswesen

(BöB, SR172.056.1) in der Regel eine öffentliche WTO-Ausschreibung. Nur wenn eine

Ausnahmesituation vorliegt, bspw. Wenn nur ein einziger Anbieter auf der Welt die

entsprechende Dienstleistung erbringen kann, erfolgt eine freihändige Vergabe,

welche publiziert wird. Diese Ausnahmen sind in Art. 13 VöB geregelt.

Falls der Schwellenwert nicht übertreten wird, erfolgt gemäss der Verordnung über

das öffentliche Beschaffungswesen (VöB; SR172.056.11) ein Einladungsverfahren, in

welchem 3 Anbieter eingeladen werden, eine Offerte zu erstellen. Unter den

Voraussetzungen gemäss Art. 13 und Art. 36 VöB wird in Ausnahmefällen das

freihändige Verfahren angewendet.


l’OFIT.

Im Bundesamt für Informatik und Telekommunikation BIT werden sämtliche

Beschaffungen über diese gesetzlich vorgeschriebenen Verfahren abgewickelt. Alle

obgenannten Angaben beziehen sich immer auf den Beschaffungsgegenstand

Dienstleistungen.

- Welches sind die Hauptvorteile und Nachteile der verschiedenen öffentlichen

Submissionsregeln (Abkommen über das Beschaffungswesen usw.)?

H.R: Das BIT als Verwaltungseinheit des Bundes untersteht dem WTO-

Beschaffungsabkommen und dem daraus resultierenden Bundesgesetz über das

öffentliche Beschaffungswesen (BöB) und der dazugehörigen Verordnung (VöB). Das

BIT kann sich nicht zu anderen Submissionsregeln (bspw. Von Kantonen) äussern.

- Werden Kontrollen zur Einhaltung des Abkommens über das Beschaffungswesen

durchgeführt? Hat es bereits Sanktionen gegeben?

H.R: Die Umsetzung und Einhaltung der Verfahren werden durch verschiedene Organe

und Institutionen überwacht und beaufsichtigt. Die Zuständigkeiten werden u.a. in der

Verordnung über die Organisation des öffentlichen Beschaffungswesens des Bundes

(Org-VöB, SR172.056.15) geregelt. Zentrale Beschaffungsstelle des Bundes ist das

Bundesamt für Bauten und Logistik BBL.

Weitere Kontrollorgane und Gremien sind die die Beschaffungskommission des

Bundes BKB, das Generalsekretariat des Eidgenössischen Finanzdepartements GS-EFD

sowie die Eidgenössische Finanzkontrolle. Letztere nimmt regelmässig Kontrollen vor

und statuiert Empfehlungen.

- Es gibt offensichtlich drei verschiedene Arten von Verträgen im Rahmen von

öffentlichen Submissionen: Leistungen zum Festpreis, der von den Anbietern

bestimmt wird(Werkvertrag), die Nachfrage nach Diensten (Dienstleistungen) und

Humanressourcen (Personalverleih). Werden diese verschiedenen Arten von

Verträgen offiziell reguliert oder entstammen sie aus der Praxis?

H.R: Die in der Frage genannten Vertragsarten werden im BIT im Bereich der

Dienstleistungen angewendet. Es handelt sich hierbei um gesetzlich geregelte Formen

von Vertragsverhältnissen:

� Die Vertragsarten Werkvertrag (OR363ff) und Dienstleistung (Auftrag;

OR394ff) stammen per Definition aus dem Schweizerischen Obligationenrecht OR und

werden dort im Detail geregelt.


l’OFIT.

� Die Vertragsart Personalverleih wird im Schweizerischen

Arbeitsvermittlungsgesetz geregelt.

- Erlaubt eine Submission genügend Freiheiten, um ein IT-Projekt in jeder dieser drei

Vertragsarten rasch zu realisieren?

H.R: Das hängt stark vom Komplexitätsgrad des Beschaffungsgegenstands ab.

Generell ist die Definition und Ausarbeitung eines Werks am anspruchsvollsten. In

einer öffentlichen WTO-Ausschreibung ist es oft schwierig, alle Anforderungen an das

Werk vollständig im Voraus definieren zu können. Man muss bedenken, dass

nachträgliche wesentliche Änderungen am Werk massgeblichen Einfluss auf das

Verfahren nehmen und sich beispielsweise der Kreis der Anbieter dadurch vollständig

verändern würde. In einem solchen Fall muss die Ausschreibung abgebrochen und

eine neue Ausschreibung lanciert werden.

Der Personalverleih, weist von all drei Vertragsarten die geringste Komplexität auf

und ist daher tendenziell am schnellsten realisierbar. Auf eine öffentliche

Ausschreibung bezogen, liegt das Hauptproblem im Personalverleih bei weichen

Faktoren, welche in einem Pesonalselektionsprozess grundsätzlich ausschlaggebend

für eine Anstellung sind und welche bspw. bei einem Vorstellungsgespräch überprüft

werden können. In einer WTO-Ausschreibung ist das nicht möglich. Die Evaluation

muss aufgrund der Nachweisbarkeit und dem Diskriminierungsverbot auf harte

Fakten abgestützt werden. Das kann dazu führen, dass eine Person aufgrund Ihres

Curriculums als bestens geeignet erscheint, die Integration in ein Team jedoch

fehlschlägt.

Eine Dienstleistung hat einen weniger anspruchsvollen Anforderungskatalog und

einen weniger ausgeprägten Personenbezug. Die Dienstleistung eignet sich oft für

eine öffentliche Ausschreibung.

Die Wahl der Vertragsart hängt von verschiedensten Faktoren ab und nicht generell

davon, ob das Verfahren mit der einen Vertragsart einfacher durchzuführen wäre.

- Welches sind die Vorteile eines Bezugs von Humanressourcen, welche immer

häufiger sind? Was sind die Risiken (schlechte Integration in ein Team, Mangel an

Kenntnissen über das Projekt, Arbeitsweise unzulänglich …)?

H.R: In Bezug auf eine öffentliche Ausschreibung bietet ein Personalverleih

(Beschaffung von Humanressourcen) den Vorteil, dass die Anforderungen rasch


l’OFIT.

definiert sind und die Evaluation der Offerten mit Systemunterstützung schnell

durchgeführt ist.

Weitere Vorteile: Mit dem Personalverleih können temporäre Spitzen in der

Auslastung des Personalbestands geglättet werden (Flexibilität). So können auch

ganze Teams für ein spezifisches Vorhaben temporär rekrutiert werden. Der

Personalverleih erlaubt es zudem, zielgerichtet Personal mit bestimmten Fähigkeiten

(Skills) für ein spezifisches Einsatzgebiet zu beschaffen, welches so nicht in der

Unternehmung verfügbar ist. Der Personalverleih macht bspw. immer dann Sinn,

wenn kein internes Personal zur Verfügung steht, kein internes Personal aufgebaut

werden kann und es sich um einen Bereich der Kernkompetenzen handelt, welcher

nicht „outgesourct“ werden darf.

Nachteile: Gegenüber Dienstleistung und Werk, setzt der Personalverleih die

vollständige Weisung und Führung des ausgeliehenen Personal voraus und die

Bereitstellung von eigener Infrastruktur (bspw. Arbeitsplatz, Nutzung von

Ressourcen). Es entsteht somit gegenüber den anderen Formen zusätzlicher Aufwand

(koordinativ und monetär). Verglichen mit einem internen Mitarbeiter, liegt ein

weiterer Nachteil bei den höheren Kosten für externes Personal.

Hans Rüegsegger

Bern, 14. April 2011

65 A.3 Interview Ludovic Chesaux, chef de projets informatiques, douane suisse.

A.3 Interview Ludovic Chesaux, chef de projets informatiques, douane suisse.

Méthodologie de gestion de projet

- Quelles raisons peuvent pousser une entreprise à combiner une méthodologie agile

avec une méthodologie en cascade ? Est-ce un procédé compliqué ? Est-ce souvent

utilisé en pratique ou plutôt rarement ? Pourquoi ?

L.C : La Confédération impose l’utilisation de la méthodologie Hermes. La

méthodologie est particulièrement adaptée aux divers projets qui requièrent des

spécifications importantes et permet de définir les différentes tâches à accomplir

durant chacune des différentes phases du projet.

L’utilisation d’Hermes peut cependant également se faire de manière combinée avec

d’autres méthodologies agiles, notamment la méthode du Rational Unified Process

qui peut être utilisée essentiellement dans la phase de construction. Ce procédé

permet certes d’ « agiliser » Hermes et de travailler de manière plus performante

mais n’est cependant pas officiellement reconnu et accepté par la Confédération et

peut être mal perçu en interne.

La procédure de combinaison n’est pas si compliquée si les phases sont bien définies

et si l’on se met d’accord sur le moment précis où l’on va basculer sur une autre

méthode.

- Quels sont les avantages et inconvénients majeurs d’une telle combinaison ?

L.C : Les principaux avantages sont le gain de flexibilité, la possibilité de rajouter des

fonctionnalités supplémentaires en contrôlant que la base fonctionne. Cela permet

également de combiner les divers points forts des méthodes. Dans le cas de la

combinaison Hermes-RUP, Hermes amène une unicité, un langage connu et standard

en Suisse tandis que le RUP amène la flexibilité.

Du côté de désavantages, on peut citer pour la Suisse, une certaine perte de temps

due au manque de connaissances des méthodes agiles.

- Avez-vous plutôt l’habitude de travailler avec des méthodologies de type Waterfall

ou itératives ? Pour quelles raisons ?

L.C : La douane travaille essentiellement avec Hermes qui est imposée par la

Confédération en Suisse. Cependant comme précédemment discuté, la méthode est

parfois combinée à d’autres méthodes plus agiles qui peuvent être utilisée dans la

phase de construction en particulier.

66 A.3 Interview Ludovic Chesaux, chef de projets informatiques, douane suisse.

- Le nouveau « trend » de l’utilisation des méthodes agiles est-il justifié ? Est-ce selon

vous une tendance passagère ou va-t-il durablement s’inscrire ?

L.C : Les entreprises se tournent désormais vers des solutions plus agiles quand elles

en ont le choix et que cela se prête au projet, il est vrai. On observe cependant

également une vague d’ «agilisation » des méthodes classiques dont on garde la base

en tentant de procéder de manière itérative dans la phase de construction

particulièrement. Les méthodes en cascade ne sont donc pas définitivement à rayer

mais plutôt à compléter avec quelques aspects plus agiles.

- Pensez-vous que la méthodologie Hermes utilisée par la Confédération a encore de

beaux jours devant elle ou un changement est à prévoir pour peut-être aller vers une

méthode plus agile ?

L.C : Il reste tout de même bon nombre d’entreprises qui travaillent avec Hermes et ce

même à l’étranger. La méthode s’est beaucoup améliorée et a un grand potentiel, à

mon sens. La méthode subit actuellement quelques transformations et mises à jour et

tente de « s’agiliser » ; il existe maintenant deux livres à disposition des utilisateurs au

lieu d’un seul lors du lancement de la méthode. Hermes a donc fait un grand travail

sur elle-même et risque de s’imposer définitivement comme la méthode de référence

en Suisse avec quelques améliorations la rendant plus agile tout de même.

Ludovic Chesaux

20 avril 2011

Documents

Méthodologies de gestion de projet agiles et en cascade ... · Méthodologie de gestion de projet Méthodologies agiles Méthodologies en cascade Soumissions publiques Règles de