Méthodologies de gestion de projet agiles et en cascade : définition, combinaison et application.

Transcription

1 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 cindy.zbinden@unifr.ch Bachelor en gestion d entreprise Dr Stephan Hüsemann

2 Résumé 1 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.

3 Mots-clés 2 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 Processus itératif / agile Processus séquentiel "Information Technology", regroupe les technologies de l information et de la communication en général. Qui est répété plusieurs fois. Accès aux différentes phases se fait dans un ordre précis et préétabli.

4 Remerciements 3 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.

5 Table des matières 4 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 Introduction Choix du travail et motivation Objectifs Questions Structure du travail Conventions Les méthodologies de gestion de projet Introduction Définition Les méthodes en cascade Merise Hermes Prince Les méthodes agiles Le Rational Unified Process Scrum... 23

6 Table des matières Extreme Programming (XP) Le développement rapide d applications Systèmes d information, soumissions publiques et règles de soumission Introduction Définition Les différents types de soumissions publiques Le processus de soumission d un projet informatique Exemple et commentaire d un appel d offre Les règles de soumission de l OMC Description et buts Avantages des règles de soumission pour l adjudicateur et le soumissionnaire Inconvénients des règles de soumission pour l adjudicateur et le soumissionnaire Combiner une méthode agile avec une méthode en cascade Introduction Motivations de l entreprise à utiliser un tel procédé Avantages Inconvénients Le cas du projet Insieme Description du projet La réalisation du projet Conclusion Bibliographie Livres Sites internet Autres... 57

7 Table des matières 6 A. Annexe A.1 Interview Turabi Köse, chef de programme e-dec à l OFIT A.2 Interview Hans Rüegsegger, responsable des demandes de ressources humaines à l OFIT A.3 Interview Ludovic Chesaux, chef de projets informatiques, douane suisse

8 Table des figures 7 I. Table des figures Figure 1 : Le modèle de développement en cascade [Aguilera 2006] Figure 2 : Etapes d un projet informatique selon la méthode Merise [Cybermed Jussieu 2011] Figure 3 : Cycles Merise [IS NET 2005] Figure 4 : Les trois perspectives d un projet Hermes [Hermes 2010, lien 1] Figure 5 : Les phases de la méthode Hermes [Hermes 2010, lien 1] Figure 6 : Le modèle des phases d Hermes selon le type de projet [Hermes 2010, lien 1] Figure 7 : Le fonctionnement de Prince2 [Wikipedia 2011, lien 2] Figure 8 : Le processus agile [Software-development-resource 2011] Figure 9 : Le RUP [IBM 2005] Figure 10 : Planification Scrum [Wikipedia 2011, lien 1] Figure 11 : Les sprints et leurs activités en parallèle [Aubry 2010 p.17] Figure 12 : Schéma global méthode Scrum [Adyax 2010] Figure 13 : Les treize pratiques d Extreme Programming [Messager Rota 2010] Figure 14 : Le "développement de versions" selon la méthode RAD [Hennebert 2011] Figure 15 : Le "prototyping" selon la méthode RAD [Hennebert 2011] Figure 16 : Le "throwaway prototyping" selon la méthode RAD [Hennebert 2011] Figure 17 : Plateforme électronique SIMAP, section «adjudicateur» [Simap 2011] Figure 18 : Plateforme électronique SIMAP, login adjudicateur [Simap 2011] Figure 19 : Procédure d inscription à un appel d offre [Simap 2011] Figure 20 : Exemple d appel d offre EVAM [Simap 2010, publication numéro ] Figure 21 : Combinaison d une méthode en cascade et d une méthode itérative Figure 22 : Combinaison Hermes / Scrum Figure 23 : Le processus de combinaison des méthodes Hermes et Scrum [Hermes 2010, lien 2]

9 Liste des abréviations 8 II. Liste des abréviations Abréviation Signification AFC EVAM IBM IT OFIT OMC OMP RAD RUP SIMAP UML URL XP Administration Fédérale des Contributions Etablissement Vaudois d Accueil des Migrants International Business Machines Information Technology Office fédéral de l informatique et de la télécommunication Organisation Mondiale du Commerce Ordonnance des marchés publics Rapid Application Development Rational Unified Process Système d information sur les marchés publics en Suisse Unified Modeling Language Uniform Resource Locator Extreme Programming Tableau 1 : Liste des abréviations.

10 Liste des tableaux 9 III. Liste des tableaux Tableau 1 : Liste des abréviations Tableau 2 : Avantages des règles de soumissions publiques, pour l adjudicateur et le soumissionnaire Tableau 3 : Inconvénients des règles de soumission pour l adjudicateur et le soumissionnaire

11 Introduction 10 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).

12 Introduction 11 - 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.

13 Introduction 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 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.

14 Les méthodologies de gestion de projet 13 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 ]. 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].

15 Les méthodologies de gestion de projet 14 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 Prince Merise La méthode Merise est une méthode française qui fut mise au point durant les années , 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.

16 Les méthodologies de gestion de projet 15 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].

17 Les méthodologies de gestion de projet 16 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 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].

18 Les méthodologies de gestion de projet 17 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.

19 Les méthodologies de gestion de projet 18 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 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.

20 Les méthodologies de gestion de projet 19 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

21 Les méthodologies de gestion de projet 20 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].

22 Les méthodologies de gestion de projet 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.

23 Les méthodologies de gestion de projet 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 ]. 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.

24 Les méthodologies de gestion de projet 23 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 ]. 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 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.

25 Les méthodologies de gestion de projet 24 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].

26 Les méthodologies de gestion de projet 25 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] 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.

27 Les méthodologies de gestion de projet 26 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].

28 Les méthodologies de gestion de projet 27 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.

29 Les méthodologies de gestion de projet 28 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].

30 Les méthodologies de gestion de projet 29 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].

31 Systèmes d information, soumissions publiques et règles de soumission 30 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;

32 Systèmes d information, soumissions publiques et règles de soumission 31 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.

33 Systèmes d information, soumissions publiques et règles de soumission 32 - 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 1 er janvier 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;

34 Systèmes d information, soumissions publiques et règles de soumission 33 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].

35 Systèmes d information, soumissions publiques et règles de soumission 34 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.

36 Systèmes d information, soumissions publiques et règles de soumission 35 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.

37 Systèmes d information, soumissions publiques et règles de soumission 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 soustraitance 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].

38 Systèmes d information, soumissions publiques et règles de soumission 37 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, alain.misson@evam.ch, URL 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, alain.misson@evam.ch 1.3 Délai souhaité pour poser des questions par écrit Délai de clôture pour le dépôt des offres Date : Heure: 12: 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

39 Systèmes d information, soumissions publiques et règles de soumission 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: 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

40 Systèmes d information, soumissions publiques et règles de soumission 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 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 ].

41 Systèmes d information, soumissions publiques et règles de soumission 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 ci-après 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 1 er 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].

42 Systèmes d information, soumissions publiques et règles de soumission Avantages des règles de soumission pour l adjudicateur et le soumissionnaire Les lois présentées au point 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 + Transfert de risques et de responsabilités + Principe de libre concurrence + Liberté de participation Tableau 2 : Avantages des règles de soumissions publiques, pour l adjudicateur et le soumissionnaire.

43 Systèmes d information, soumissions publiques et règles de soumission 42 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 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

44 Systèmes d information, soumissions publiques et règles de soumission 43 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 et 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.

45 Combiner une méthode agile avec une méthode en cascade 44 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.

46 Combiner une méthode agile avec une méthode en cascade 45 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 ellesmê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.

47 Combiner une méthode agile avec une méthode en cascade 46 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

48 Combiner une méthode agile avec une méthode en cascade 47 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 Description du projet Insieme est un projet informatique suisse qui a été lancé par l Administration fédérale des contributions (AFC) en 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 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.

49 Combiner une méthode agile avec une méthode en cascade 48 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.