Nouvelles méthodologies en Microscopie Electronique 3D Et ...
Méthodologies de gestion de projet agiles et en...
Transcript of Méthodologies de gestion de projet agiles et en...
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
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
5 Table des matières
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
6 Table des matières
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 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].
14 Les méthodologies de gestion de projet
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.
15 Les méthodologies de gestion de projet
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].
16 Les méthodologies de gestion de projet
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].
17 Les méthodologies de gestion de projet
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.
18 Les méthodologies de gestion de projet
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.
19 Les méthodologies de gestion de projet
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
20 Les méthodologies de gestion de projet
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].
21 Les méthodologies de gestion de projet
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.
22 Les méthodologies de gestion de projet
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.
23 Les méthodologies de gestion de projet
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.
24 Les méthodologies de gestion de projet
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].
25 Les méthodologies de gestion de projet
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.
26 Les méthodologies de gestion de projet
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].
27 Les méthodologies de gestion de projet
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.
28 Les méthodologies de gestion de projet
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].
29 Les méthodologies de gestion de projet
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 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;
31 Systèmes d’information, soumissions publiques et règles de soumission
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.
32 Systèmes d’information, soumissions publiques et règles de soumission
- 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;
33 Systèmes d’information, soumissions publiques et règles de soumission
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].
34 Systèmes d’information, soumissions publiques et règles de soumission
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.
35 Systèmes d’information, soumissions publiques et règles de soumission
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.
36 Systèmes d’information, soumissions publiques et règles de soumission
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].
37 Systèmes d’information, soumissions publiques et règles de soumission
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
38 Systèmes d’information, soumissions publiques et règles de soumission
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
39 Systèmes d’information, soumissions publiques et règles de soumission
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´appel d´offres
Sous www.simap.ch Langues du dossier d´appel d´offres : 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].
40 Systèmes d’information, soumissions publiques et règles de soumission
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].
41 Systèmes d’information, soumissions publiques et règles de soumission
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.
42 Systèmes d’information, soumissions publiques et règles de soumission
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
43 Systèmes d’information, soumissions publiques et règles de soumission
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 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.
45 Combiner une méthode agile avec une méthode en cascade
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.
46 Combiner une méthode agile avec une méthode en cascade
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
47 Combiner une méthode agile avec une méthode en cascade
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.
48 Combiner une méthode agile avec une méthode en cascade
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.
49 Combiner une méthode agile avec une méthode en cascade
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.
62 A.2 Interview Hans Rüegsegger, responsable des demandes de ressources humaines à
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.
63 A.2 Interview Hans Rüegsegger, responsable des demandes de ressources humaines à
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
64 A.2 Interview Hans Rüegsegger, responsable des demandes de ressources humaines à
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