MEMOIRE La stabilisation de

La stabilisation de l’expression de besoin 1

MEMOIRE

La stabil isat ion de

L’expression de besoin

POURCHOT Jenna M1 MIAGE App


Remerciements En préambule à ce mémoire, je souhaite adresser mes remerciements à SANOFI qui me permet d’effectuer mon stage au sein de l’établissement de Massy. Cette expérience, dans un groupe à envergure internationale est pour moi plus que bénéfique, aussi bien sur le plan humain que professionnel. J’ai pu travailler dans un cadre particulièrement agréable, grâce à l’ensemble des membres de l’équipe SI ACHAT. Merci à eux de m’avoir accueillie et soutenue mais aussi pour leur bonne humeur. Cette année passée au sein SANOFI m’a permis de mettre en pratique les connaissances acquises tout au long de ma formation mais aussi de la compléter et de l’enrichir dans des domaines qui m’étaient jusque là inconnus. Je me sens plus à l’aise et intéressée dans la mission qui m’a été confiée cette année : celle-ci est en effet moins technique que les précédentes et les tâches sont d’autant plus intéressantes que variées. J’ai la chance d’avoir de nombreuses responsabilités et d’être devenue rapidement autonome grâce aux conseils de mon maitre d’apprentissage. J’ai donc choisis mon sujet de mémoire en corrélation avec le travail effectué au sein de Sanofi afin d’être plus efficace dans mes activités et à mon avis, c’est un sujet très intéressant qui n’est pas assez exploité. Ce travail n’aurait pu aboutir sans l’aide de certaines personnes, je pense en particulier à Selmin Nurcan, ma tutrice enseignante, pour ses conseils rigoureux, et cela malgré son emploi du temps chargé, et à l’ensemble de nos professeurs de Master pour leur apprentissage et leurs conseils avisés. J’aimerais adresser un remerciement particulier à mon maître d’apprentissage : Hervé Raffa qui m’a aidé et guidé tout au long de cette année. Je tiens à exprimer toute ma gratitude envers lui car il s'est toujours montré à l'écoute et très disponible tout au long de la réalisation de ce mémoire, ainsi que pour ses idées, son sens critique, l'aide et le temps qu'il a bien voulu me consacrer et sans qui ce mémoire n'aurait jamais vu le jour. Ces remerciements ne seraient pas complets sans une pensée à Nathalie Boché notre chargée de mission du CFA. Son organisation, sa disponibilité et ses encouragements m’ont été d’une aide précieuse.


SOMMAIRE Introduction .............................................................................................................. 4 I. L’Expression de besoin dans la Gestion de projet ................................................ 5

1. Contexte ........................................................................................................... 5 2. Enjeux et Complexité ........................................................................................ 7

II. Approches utilisées par les méthodes de Gestion de Projet .............................. 10 1. Méthodes Traditionnelles dites Prédictives .................................................... 10 2. Les Méthodes Agiles ...................................................................................... 14 3. Synthèse des différences entre les deux approches ...................................... 19

III. Synthèse des bonnes pratiques ........................................................................ 20 1. Comportementales ......................................................................................... 20

1.1 Du client ............................................................................................................... 20 1.2 Du chef de projet .................................................................................................. 21

2. Techniques ..................................................................................................... 22 2.1. De Recueil des besoins ...................................................................................... 22 2.2. De Formalisation du besoin ................................................................................ 23 2.4. De Vérification et de Validation ........................................................................... 29

IV. Etude de cas chez Sanofi ................................................................................. 31 1. La méthodologie SIMPLE ............................................................................... 31 2. La méthodologie PUMA .................................................................................. 32 4. Mon utilisation des bonnes pratiques chez Sanofi ......................................... 33

Conclusion ............................................................................................................. 37 Glossaire ................................................................................................................ 38 Les sources ............................................................................................................ 39 Annexe 1 : Projet Professionnel ............................................................................. 40 Annexe 2 : Mission MASTER 2 .............................................................................. 41


Introduction En gestion de projet, l’une des phases les plus importantes se situe au début du projet. Il ne faut pas la négliger sous peine de générer des échecs ou des dépassements de budget,… cette phase est celle de l’expression du besoin. Le besoin est la « nécessité ou le désir éprouvé par un utilisateur, exprimé en termes de finalité, sans référence aux solutions techniques susceptibles d’y répondre. »1 Le besoin est en constante évolution, c’est pourquoi il est impossible de le stabiliser. Néanmoins, le chef de projet doit s’efforcer d’en obtenir une expression stabilisée de la part du client. En effet, dans le modèle de gestion de projet en cascade, très utilisé dans les entreprises françaises, tout doit être prévu dès le début, et si des méthodologies projet récentes, dites adaptatives, existent, elles ne sont parfois pas applicables au modèle contractuel français. Comment accompagner l’utilisateur dans la stabilisation de l’expression de son besoin ? La stabilisation du besoin utilisateur est un sujet complexe car pour cela le chef de projet doit recueillir, analyser, et critiquer de manière constructive la formalisation du besoin effectuée par le client. Ainsi, dans une première partie, nous expliquerons la complexité liée à la stabilisation de l’expression du besoin. Dans un second temps, nous comparerons les méthodes traditionnelles de Gestion de Projet aux méthodes Agiles. Nous synthétiserons alors les bonnes pratiques d’un point de vue comportemental et technique. Enfin, nous aborderons les bonnes pratiques que j’essaye de mettre en place dans ma mission chez Sanofi.

1 Selon la définition Afnor,


I. L’Expression de besoin dans la Gestion de projet

1. Contexte

Un projet est « un ensemble finalisé d’activités et d’actions entreprises dans le but de répondre à un besoin défini, dans des délais fixés et respectant un budget alloué. »2 Le succès d’un projet peut se mesurer par la satisfaction du client mais aussi par sa réponse aux enjeux :

• Fonctionnels par le respect du besoin et des fonctionnalités, • Techniques par le respect des spécifications, • Organisationnels par le respect d'un mode de fonctionnement (rôles,

fonctions, culture, résistance au changement) de la structure cible, • De délais par le respect des échéances du planning, • De coûts par le respect du budget.

Pour atteindre les objectifs du projet, le chef de projet doit prendre en compte les trois contraintes (3C) suivantes : Coût, Calendrier et Contenu. Un projet est divisé en phases, dont chacune aboutit à des livrables. Un livrable désigne « tout composant matérialisant le résultat d'une prestation de réalisation »3. On nomme cycle de vie des logiciels ou de cycle de développement l’enchainement de ces phases. La première phase du projet – et l’une des plus critiques - est celle de l’expression et de l’analyse du besoin. Cette phase est décisive pour le reste du projet : le besoin doit y être défini, analysé, et formalisé. Dans ce contexte, le rôle de chacun des acteurs est essentiel pour aboutir à un résultat satisfaisant. Le rôle est une fonction temporaire, déconnectée de la place qu’occupe la personne dans l’entreprise4: La Maîtrise d'Ouvrage (MOA) est l'entité porteuse du besoin, c'est-à-dire le client. Elle maîtrise l'idée de base du projet, définit son calendrier et le budget consacré à ce projet. Elle représente les utilisateurs finaux à qui l'ouvrage est destiné.

Les Utilisateurs : une distinction est à réaliser entre les utilisateurs qui utiliseront le futur système, c'est-à-dire les utilisateurs finaux, et les opérationnels & décideurs qui n’ont pas le même point de vue sur le système.

2 Wikipédia 3 Wikipédia 4 Cours de Gestion de Projet de Selmin Nurcan


Lorsque le maître d'ouvrage ne possède pas d’expérience dans le pilotage du projet, il peut faire appel à l'Assistance à Maîtrise d'Ouvrage (AMOA) qui est chargée (1) d’assurer l'interface entre MOA/MOE pour aider le client à définir clairement ses besoins et (2) de vérifier auprès des développeurs si l'objectif est techniquement réalisable.

La Maîtrise d'Œuvre (MOE) est l'entité qui réalise l'ouvrage, conformément à un contrat. Elle est donc responsable des choix techniques pour réaliser le logiciel conformément aux exigences de la Maîtrise d'Ouvrage. Pour la réalisation de certaines tâches du projet, la MOE peut faire appel à une ou plusieurs entreprises externes. On parle alors de sous-traitance. Tout doit alors être spécifié par écrit dans dossier de spécifications – dérivé du cahier des charges - qui sera la base du contrat. Le contrat s’impose comme la référence en cas de litiges.

L’équipe projet est composée de plusieurs acteurs : Le chef de projet est le responsable de l’avancement du projet. Il est le chef d’orchestre qui dirige, anime une équipe et contrôle le bon déroulement du projet. Les concepteurs sont les informaticiens, organisateurs ou gestionnaires. Ils conçoivent le futur système au début du projet (étude préalable et détaillée). Les développeurs sont des informaticiens qui programment le système sur la base des spécifications détaillées. Parmi les acteurs du projet, nous en distinguerons deux principaux : le client et le chef de projet L’ingénierie des besoins ou des exigences définit une démarche rationnelle pour recueillir efficacement le besoin et suivre son évolution tout au long du projet. Pour cela, les besoins doivent être :

• Précis : correctement délimités • Cohérents entre eux et avec l’environnement • Complets : tenant compte de tous les aspects • Traçables : permettant de suivre leur évolution dans le temps • Maintenables et flexibles

Cette phase d’expression et d’analyse est complexe et peut avoir des conséquences néfastes au projet si elle n’est pas réalisée correctement.


2. Enjeux et Complexité

Selon l’étude du Standish Group de 1995, la première cause d’échec d’un projet est le manque de clarté des besoins ou leur caractère incomplet. La seconde cause d’échec est l'évolution des spécifications en cours de réalisation. Le manque d’implication de l’utilisateur est aussi une cause d’échec significative. Tel que vu précédemment, l’expression du besoin est une phase fondamentale qui ne faut pas négliger car elle peut être la cause de bon nombre d’échecs, causant - lorsqu’elle est mal gérée - des retards, des dépassements de budget et la non-satisfaction des utilisateurs. Dans le graphique ci-dessous, le taux de projet “contesté” correspond aux projets terminés, mais en dépassement l’une des trois contraintes (coût, temps, objectif). Le taux de réussite des projets en 2009 (32%) est un peu moins bon qu’en 2006 (35%) mais nettement meilleur qu’en 1994 (16%). Le taux d’échec a particulièrement diminué depuis 1994, passant de 31% à 24%.

0%

10%

20%

30%

40%

50%

60%

1994 1996 1998 2000 2002 2004 2006 2009

RéussisContestéEchoué

5

Il apparaît donc que la gestion de projet s’est améliorée avec le temps, et ce grâce à une meilleure expérience des chefs de projet et à de meilleurs outils et techniques, en dépit d’une complexité accrue des projets et de l’environnement.

5 Selon les résultats projet de l’étude du Standish Group


En ce qui concerne les projets « contestés », nous constatons qu’en 1994 :

• 45% des projets ont un dépassement budgétaire de plus de la moitié du budget prévu (dont 11% de plus du triple). Cf. graphique ci-dessous.

Surcout

16%

11%

25%

39%

9%

succès

surcout >200 %

surcout de 101 à 200%

surcout de 51 à 100%

surcout < 50 %

6

• 57% des projets ont un retard de plus de 50%,

• 32% des projets terminés avec dépassement couvrent moins de la moitié des fonctionnalités attendues.

Pourquoi la phase de recueil des besoins génère-t-elle tant de problèmes ? L’étude montre que le problème principal est la communication entre les acteurs du projet : l’utilisateur et les concepteurs communiquent entre eux, mais avec des vocabulaires différents. En effet, le client spécifie en langage naturel, compréhensible par tous, mais qui peut générer ambiguïté, contradiction, sur-spécification, sous-spécification, répétition, interprétations,… Les utilisateurs – souvent étrangers à l’informatique - expriment parfois leurs attentes avec subjectivité et peuvent décrire leurs interactions avec le système en utilisant des termes imprécis. Selon une étude de l’université italienne7 en 2000 « 71.8% de ces documents sont écris en langage naturel, 15.69 % en langage naturel structuré, et seulement 5.3 % en langage formalisé ». Malheureusement, les spécifications en langage naturel peuvent induire de nombreuses incompréhensions : un même mot ne fait pas toujours référence au même concept chez deux locuteurs ou dans deux contextes différents. Un même concept peut être expliqué de plusieurs façons alors qu’un

6 Les dépassements de budget : Selon l’étude du Standish Group de 1995 7 eprints.biblio.unitn.it


langage formalisé, à l’aide de diagrammes, graphiques, tableaux, formules,.., générerait moins d’ambigüité. De plus, selon le type d’interlocuteur, différents points de vue sur le système peuvent être donnés. Ainsi, la difficulté pour l’utilisateur d’exprimer des besoins précis et réalistes nécessite souvent une personne extérieure pour faciliter la production d’un cahier des charges. Le développeur, quant à lui, parle parfois un jargon technique qui rend le dialogue difficile avec l’utilisateur. Un autre problème peut venir de la défaillance du client : indisponibilité, manque d’intérêt, de réalisme ou de formation pour exprimer ses besoins. La faible implication des utilisateurs est une cause d’échec fréquente. En outre, certaines difficultés dans le recueil des besoins résident dans la nature même de la relation entre les acteurs. Cette relation est contractuelle et forfaitaire dans la plupart des grandes sociétés, qui sous-traitent leurs développements de projets. Afin de protéger les parties prenantes du projet, la nécessité apparait de tout spécifier par écrit dans un cahier des charges. Un autre biais possible, la « sur-spécification » est également à surveiller : en effet, il est souvent demandé à l’utilisateur de décrire son besoin de la manière la plus exhaustive possible. Ainsi, l’utilisateur va préférer prendre le risque de sur-spécifier par crainte de ne plus pouvoir faire évoluer son produit. Il considère en effet, qu’il n’aura jamais ce qu’il n’a pas décrit dans l’expression de besoin initiale. En synthèse donc, le chef de projet doit aider l’utilisateur à stabiliser son expression de besoin et l’accompagner pour l’exprimer de façon claire et précise. Cela peut s’avérer difficile car, comme nous l’avons vu, la communication peut être plus ou moins bonne en fonction de l’implication de l’utilisateur dans le projet. Le but étant d’atteindre les objectifs fixés par le client et d’obtenir sa satisfaction. Mais si le besoin est difficile à stabiliser c’est aussi parce qu’il est en constante évolution. Ainsi, Barry Boehm8 constate que « 95% du code à réécrire provient de modifications destinées à satisfaire les changements de besoin du client et seulement 12% des erreurs totales proviennent du code ». Dans ce contexte, comment comprendre alors les attentes et les besoins des utilisateurs avant d’agir? Comment stabiliser au mieux l’expression de besoins du client? Pour tenter de répondre à ces questions, nous allons étudier deux approches différentes de gestion de projet, en comparant méthodes traditionnelles et méthodes agiles Sans s'opposer véritablement, ces deux types de méthodes diffèrent quant à leur gestion du changement dans l’expression de besoin.

8 Ingénieur Américain qui a conçu le modèle en spirale


II. Approches utilisées par les méthodes de Gestion de Projet Les méthodes de conduite de projet ont beaucoup évolué et l’on distingue aujourd’hui deux types de méthodes : les méthodes dites « prédictives » et les méthodes dites « itératives ».

1. Méthodes Traditionnelles dites Prédictives

Dans le modèle prédictif, comme son nom l’indique, tout est prédit ou prévu, organisé, programmé, planifié en début de projet. Un plan de travail est établit afin de définir les étapes nécessaires à la livraison du projet. Le modèle est donc basé sur un travail d’analyse conséquent en amont et de planification à long terme. Mais comment prévoir l’imprévu? Le modèle prévoit une mécanique de gestion des demandes de changements et généralement, celles-ci sont exécutées en fin de projet. Tout changement (correctif ou évolution) demande un ajustement de budget.

Cette approche fonctionne pour des projets, de courte durée (moins d’un an) et/ou réglementés : il sera plus facile de prévoir un plan de travail pour ce type de projet.

Depuis des années, les projets sont gérés avec une approche classique, souvent en cascade ou son adaptation en V. Ils sont basés sur des activités successives prédéfinies: recueil des besoins, définition du projet, développement, puis test avant la livraison au client. Le modèle cascade est un modèle de processus orienté activité. Le cycle en « cascade » se caractérise par des phases séquentielles qui se succèdent après la validation des livrables à chaque fin d’étape. Chacune des phases doit être terminée avant d’entamer la suivante, il n’y pas de retour possible à la phase précédente.


Tous les besoins sont exprimés et recueillis lors de la première phase, les besoins sont formalisés par écrit puis validés avant le démarrage des développements. On demande au chef de projet de s’engager sur un planning détaillant chaque phase et jalon. A chaque fin de phase, la vérification ou les tests sont essentiels et permettent d’éviter les retours arrière. Un plan est un outil de pilotage et d’aide à la décision. Le plan initial permet de détailler les activités, leur séquencement, leur durée, leur coût. Le succès se mesure donc à la conformité du résultat au plan initial. Le modèle en cascade est un des plus utilisés, nous allons donc étudier les avantages et les inconvénients de ce cycle de développement, dans le cadre de la stabilisation de l’expression de besoin. Les avantages du modèle en cascade sont :

• La simplicité du modèle c'est-à-dire que le modèle est simple à utiliser, à suivre, à expliquer et à justifier aux dirigeants d’entreprises

• La facilité de planification des étapes et des délais • La facilité de contrôle qualité à chaque fin de phase • La documentation, preuve de l’avancement du projet

Les inconvénients de cette approche sont : • La rigidité, c’est à dire l’absence de flexibilité et l’incapacité de revenir en

arrière • La nécessité d’une phase de conception parfaite • L’effet tunnel : entre l’analyse des besoins et la livraison du produit, le client

ne voit le résultat qu’à la fin. Cela cause donc un problème de transparence et d’implication du client durant la phase de développement.

• La levée tardive des facteurs de risques : les tests (intégration et performance) sont réalisés à la fin du développement. « Plus une anomalie est détectée tardivement, plus le retour arrière est complexe, et plus sa correction coûtera cher. »9

• L’abondance de la documentation. A chaque étape, un ou plusieurs livrables sont demandés. La documentation rassure, et apporte la preuve de l’avancement, mais peut s’avérer pléthorique.

• La difficulté de changer les besoins en cours de projet. Ces changements sont considérés comme des correctifs ou évolutions, réalisés à l’aide d’un budget complémentaire.

9 Gestion de projet Agile, Véronique Messager Rota


Evolution du modèle en Cascade : Le Modèle en Cascade Modifié permet un retour sur la phase précédente (backtracking). Par exemple, si une erreur est détectée dans la phase de conception de haut niveau alors on peut revenir à la phase précédente : les spécifications. Ce qui rend moins rigide le modèle en cascade.

Le Modèle en V a été imaginé suite au problème de réactivité du modèle en cascade. Il permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Chaque phase possède une phase de test ce qui permet de savoir progressivement si on s'approche de ce que le client désire.


Modèle en W : reprend le modèle en V en ajoutant des étapes d’élaboration de maquettes validant la conception. Le modèle en cascade ne cesse de s’améliorer au fur à mesure des évolutions du modèle.

Tous ces cycles de vie de logiciel mettent l’accent sur les phases amont du projet tel que l’analyse des besoins et les spécifications, car les besoins nécessitent d’être bien définis, écrits dans un cahier des charges et validés dès le début du projet. Depuis des décennies, les projets sont gérés avec les méthodes traditionnelles dites prédictives car tout doit être prévu au début du projet. Néanmoins, pour pallier à la rigidité de ces méthodes, d’autres, plus souples face aux besoins d’adaptation sont apparues. Les méthodes Agiles.


2. Les Méthodes Agiles

Présentation : Dans les années 1990 arrivent les méthodes Agiles qui sont adaptatives, itératives, incrémentales et plus pragmatiques que les méthodes traditionnelles. La notion de « méthodes Agiles » a été officialisée en 2001 par un document, le Manifeste Agile10. « Une méthode Agile propose une approche itérative et incrémentale, menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle a pour objectif de générer un produit de haute qualité tout en prenant en compte l’évolution des besoins du client. »11 Le principe du développement itératif consiste à découper le projet en plusieurs étapes de courte durée, par exemple quelques semaines. Chaque itération est un mini-projet qui intègre toutes les activités liées développement, menées, en parallèle : analyse, conception, codage et test. Le produit de chaque itération est soumis au client pour validation. Il n’y a plus de planification détaillée au début du projet mais un macro-planning initial qui fixe les grandes échéances et les jalons principaux du projet. La liste des besoins est définie avec le client, puis pour chaque besoin, un micro-planning est établi pour les activités liées au développement. Les quatre valeurs fondamentales du Manifeste sont:

• Les individus et leurs interactions avant les processus et les outils : la communication est privilégiée entre les acteurs et la cohésion dans l’équipe. Tous travaillent dans un esprit collaboratif.

• Les fonctionnalités opérationnelles avant la documentation : dans les méthodes Agiles, la qualité du produit est privilégiée au détriment de la documentation. Un formalisme léger permet de se concentrer davantage sur la qualité du produit.

• La collaboration avec le client plutôt que la contractualisation des relations : le client est impliqué dans le développement et tout au long du projet, son feedback est donc continu. Le client a donc un rôle primordial dans le projet.

• L’acceptation du changement plutôt que la conformité aux plans: être ouvert aux changements, flexible pour les évolutions et éviter les pertes de temps et d’énergie associées aux refus du changement.

10 Agile Manifesto 11 D’après La Gestion de projet AGILE :


Les méthodes Agiles sont également fondées sur douze principes :

• Livrer tôt et régulièrement des logiciels opérationnels; • Accepter le changement, même tardivement; • Livrer fréquemment; • Faire collaborer quotidiennement le métier et les développeurs; • Avoir une équipe motivée et produire du travail de qualité; • Communiquer en face à face : transparence des échanges; • Mesurer la progression du projet par la plus-value fonctionnelle réalisée; • Promouvoir un rythme de développement constant et soutenable; • Apporter une attention continue à la technique et à la qualité de la

conception; • Privilégier la simplicité, réduire le travail inutile; • Croire en la responsabilité des équipes qui s’auto-organisent; • Adapter sa façon de travailler en fonction des résultats précédents.

Dans une approche Agile, le projet est envisagé comme une évolution permanente face aux incertitudes et au feedback du client. Le chef de projet doit accepter cette incertitude ainsi que le fait de ne pas pouvoir tout prévoir : on avance au fur et à mesure et on ne planifie que l’étape en cours. En fonction des résultats obtenus, on planifie l’étape suivante.

Les avantages et inconvénients des méthodes Agiles : Les avantages sont :

• un apport en Valeur Ajoutée. Le client hiérarchise ses exigences en fonction de la valeur ajoutée attendue. L’équipe de développement livre les fonctionnalités les plus fondamentales au client.

• une communication de meilleure qualité car le client est impliqué tout au long du projet afin de clarifier les exigences si besoin.

• une adaptabilité à l’évolution des exigences grâce aux retours des clients après chaque itération.

• une meilleure visibilité pour le client qui constate les résultats au fil de l’eau c'est-à-dire à la fin de chaque itération.

• une réduction des risques car ceux-ci sont détectés très tôt. • une qualité logicielle optimisée car les tests sont effectués à chaque

itération. Les inconvénients sont :

• une forte participation des utilisateurs, qui doivent être disponibles tout au long du projet.

• une difficulté à connaitre le nombre d’itérations à l’avance : le projet est donc difficile à planifier.

• une agilité parfois difficile à appliquer en entreprise. La plupart des grandes sociétés sous-traite le développement de leurs projets, souvent sur une base contractuelle forfaitaire. Or il est difficile de mener au forfait un projet Agile sous-traité puisque dans un contrat au forfait, le client définit dès le


début ses attentes sous la forme d’un cahier des charges. Avec une méthode Agile, il est impossible de tout spécifier dès le début du projet. L’acceptation du changement, devient impraticable. Le contrat au forfait s’avère donc incompatible avec le développement agile.

Quelques Méthodes Agiles :

La méthode RAD (Développement Rapide d’Applications) est à l’origine des méthodes Agiles. C’est historiquement la première approche itérative favorisant la communication. Le cycle de développement est en rupture fondamentale par rapport aux méthodes antérieures dites en cascade. Le cycle est court et sécurisant. La méthode RAD est basée sur le concept de planification adaptative, matérialisé par le fait de jouer sur un des trois cotés du triangle de gestion de projet (durée, coût, périmètre) en fonction du besoin immédiat de l’utilisateur. La phase spécification/conception est remplacée par une phase de prototypage menée avec le client. Après deux courtes phases de formalisation structurée de l'expression des besoins (Analyse) et de définition globale de l'architecture technique (Quick Design), la phase de développement permet de réaliser un prototype à chaque itération. Lorsque le prototype est validé et testé, il pourra être mis en production. L'objectif de la méthode, qui implique activement l'utilisateur final dans un principe de validation permanente, est d'obtenir un logiciel en adéquation avec les besoins réels.

12 Les deux méthodes Agiles connues en France sont Scrum et la méthode XP (eXtreme Programming). Nous allons en donner un bref aperçu.

12 Cycle de développement RAD (http://www.ramsoft.com.au)


SCRUM est un terme anglais emprunter au rugby et qui signifie la « mêlée »; il fait référence à l’esprit d’équipe et à l’effort collectif. Les réunions quotidiennes, appelées Daily Scrums, permettent à l’équipe projet d’échanger et de faire le point sur le travail réalisé chaque jour. Les acteurs d’un projet SCRUM sont : - le Product Owner (ou le responsable du produit), qui représente le client, - le SCRUM Master, animateur et garant du respect des principes SCRUM, - l’équipe, à effectif réduit.

13 Le cycle de vie de Scrum est rythmé par des itérations courtes, appelé Sprints. Le référentiel réalisé en collaboration entre les acteurs est le Product Backlog, qui liste les exigences du produit avec un ordre de priorité. Le Sprint Backlog représente les exigences du sprint en cours. Le Burndown Chart est une version graphique et simplifiée du planning du sprint courant14. A la fin de chaque itération, le Sprint Review Meeting permet de réaliser une démonstration au client des derniers développements. Le client est donc impliqué dans le projet et n’a pas à attendre la fin du projet pour en voir les résultats.

13 Le cycle de développement de la méthode Scrum (Wikipédia) 14 http://www.computure.net


XP : eXtreme Programming : Les activités de programmation sont centrales, les itérations sont courtes et les pratiques sont « extrêmes ». Les pratiques propres à la méthode XP :

• La communication entre les intervenants : le client est intégré à l’équipe projet, il définit les besoins et arbitre les priorités à chaque itération.

• Un retour d’information (feedback) fréquent suite aux tests réalisés : les tests sont écrits en amont des développements.

• Une volonté de simplicité de la solution, privilégiant une conception simple • Le Pair Programming, ou programmation en binôme • Le respect des règles de codage définies par l’équipe • La métaphore, c’est-à-dire la description du système et des fonctionnalités

par une figure de style d’analogie : la métaphore.

15 Les méthodes Agiles possèdent de nombreux avantages, mais également des inconvénients : il est donc intéressant de comparer l’approche Agile à l’approche Traditionnelle.

15 Le cycle de développement de la méthode eXtreme Programming (Wikipédia)


3. Synthèse des différences entre les deux approches

Thèmes Approche traditionnelle Approche Agile Cycle de vie En cascade ou en V, avec

phases séquentielles Itératif et incrémental

Planification Prédictive : détaillé et stable au début du projet

Adaptative avec plusieurs niveaux de planification et ajustement si changements survenus

Documentation Volumineuse, utilisée comme support de communication, de validation et de contractualisation

Minimum voire Insuffisante dans relation contractuelle au forfait

Equipe Une équipe avec des ressources spécialisées, dirigée par un chef de projet

Une équipe responsabilisée où la communication sont privilégiées et soutenue par un chef de projet

Qualité Contrôle réalisé à la fin du développement, quand le client découvre le produit

Contrôle continu: le client visualise les résultats tôt et fréquemment.

Changement Résistance au changement en cours de projet. Processus de gestion des changements, imposant un haut niveau de traçabilité.

Favorable au changement, intégré dans le processus

Suivi de l’avancement

Mesure de conformité aux plans initiaux. Analyse des écarts.

Un seul indicateur d’avancement : le nombre de fonctionnalités implémentées et le travail qui reste à faire.

Gestion des risques

Processus distinct, rigoureux de gestion des risques

Intégré dans le processus global, avec responsabilisation de chacun dans l’identification et résolution des risques

Mesure du succès

Respect des engagements initiaux (coûts, délais et qualité du produit)

Satisfaction du client par la livraison de valeur ajoutée


III. Synthèse des Bonnes Pratiques Dans cette partie, nous allons synthétiser les bonnes pratiques comportementales et techniques communes aux approches Agile et Traditionnelle.

1. Comportementales

Une bonne collaboration entre les membres de l’équipe projet est primordiale pour la réussite du projet. Pour améliorer la qualité des échanges entre toutes les parties prenantes, voici les savoirs faire et savoirs être de chacun.

1.1 Client Le client est l’utilisateur final ou le représentant du besoin des utilisateurs. Pour exprimer efficacement son besoin, il doit posséder des compétences à fois « techniques » d’expression et de recueil des besoins, mais aussi des compétences comportementales qui favoriseront la collaboration. L’analyste du besoin doit être capable :

• d’abstraction et de structuration. Il clarifier le besoin lorsque nécessaire et en faire supprimer les éventuelles contradictions.

• de connaitre et d’anticiper le processus de développement, • de recul sans se perdre dans les détails.

Il doit savoir communiquer une vision, constituée d’objectifs clairs et ambitieux. Il doit pouvoir fournir une description des fonctionnalités suffisamment détaillée pour une bonne compréhension globale par les développeurs. Il doit être capable d’arbitrer la priorité des besoins en tenant compte des contraintes techniques. Il doit savoir travailler en collaboration, c'est-à-dire participer activement aux réunions et être partie prenante de l’équipe projet. Il doit être exigeant avec l’équipe de réalisation et disponible pour tester et donner son feedback. Enfin, l’analyste doit savoir soutenir l’équipe projet et être reconnaissant du travail accompli, à chaque étape cruciale du projet. En adoptant un comportement collaboratif, le client obtiendra de meilleurs résultats. Le partenariat entre fonctionnel et technique est un équilibre profitable à tous.


1.2 Chef de projet Le métier de Chef de projet est complexe. En effet, le chef de projet se doit d’être multi-compétent et d’avoir des compétences techniques (informatiques, fonctionnelles et technologiques) sans obligatoirement être expert. Cela lui permet d’avoir une vue globale du projet et de challenger les solutions proposées. Il pourra d’avantage communiquer avec son équipe sur des points techniques. Les compétences comportementales attendues du chef de projet sont donc de :

• Maitriser les techniques de gestion de projet : les neuf domaines de connaissance PMBOK16.

o Management de l’intégration du projet o Management du contenu du projet o Management des délais du projet o Management des coûts du projet o Management de la qualité o Management des ressources humaines o Management des communications o Management des risques o Management des approvisionnements

• Comprendre l’environnement de chaque projet : o le contexte particulier du projet (social, économique, fonctionnel,

national ou international, politique, historique, ..) o les différents acteurs : l’équipe projet, le client, les sous-traitants, les

fournisseurs,… o L’organisation dans laquelle s’inscrit le projet, caractérisée par une

culture, un organigramme, des procédures, une méthodologie, les moyens mis à disposition.

• Manager les hommes : le chef de projet a vu son rôle évoluer avec le temps. Son style de management a changé passant de leader à animateur ou facilitateur. Il doit en effet faire preuve de :

o Tolérance et ouverture d’esprit : pour faciliter l’adaptation de l’équipe à la méthodologie de projet

o Leadership et de capacité à communiquer pour favoriser l’adhésion et la collaboration entre tous les acteurs

o D’aptitude à gagner la confiance de tous les membres de l’équipe projet.

• Accepter l’incertitude pour mieux la maitriser : en comprenant que tout n’est pas prévisible, on accepte alors l’idée du changement et on s’adapte aux imprévus.

• S’adapter et anticiper : dans un environnement changeant, le chef de projet doit parfois repenser sa stratégie de développement et s’adapter :

o En sachant apprendre de l’échec, la capacité à anticiper est améliorée. Ainsi, un chef de projet avec une longue expérience peut d’avantage prévoir et envisager les divers scénarios possibles.

16 PMBOK : Project Management Body Of Knowledge


o En anticipant, on met en place une stratégie de gestion des risques : identifier, analyser et suivre les risques, prévoir un plan d’actions pour atténuer ou éliminer l’effet des risques

• Faire preuve de qualité de communication Le chef de projet doit donc adopter une démarche qui aide le client à faire émerger ses besoins progressivement en recensant l’explicite et l’implicite. Outre, les compétences comportementales, les parties prenantes du projet se doivent de connaitre des techniques de recueil, d’analyse, de formalisation, de hiérarchisation, de rédaction et de validation du besoin.

2. Techniques

Recueillir, analyser et exprimer les exigences est une tâche complexe : de nombreux outils et techniques existent afin de faire ressortir les besoins, les expliciter et les formaliser. La nécessité de partager ces techniques permettra d’améliorer la collaboration entre l’utilisateur et le chef de projet. Le chef de projet sera alors à même de mettre en place sa propre méthodologie de projet.

2.1. De Recueil des besoins Les techniques suivantes sont utilisées afin de recueillir efficacement les besoins17: - Le Brainstorming ou « remue-méninges » est une réunion entre toutes les parties prenantes du projet afin de déterminer les enjeux de l’application, permettant aussi de faire jaillir des nouvelles idées. - L’Extraction de connaissance est un exercice difficile qui doit être préparé : il faut prévoir des questions précises, ciblées et concrètes et rester ouvert d’esprit et à l’écoute de son interlocuteur. Une discussion sur un sujet concret est souvent plus productive qu’une discussion sur des notions abstraites. - Le Scénario décrit les interactions de l’utilisateur avec le système. Cela facilite la projection de l’interlocuteur comme utilisateur du futur système. Le scénario peut inclure une description :

• du contexte dans lequel le scénario démarre,

• du flot normal des évènements d’interaction,

• de ce qui peut mal se dérouler (erreur, panne, incomplétude,…),

• de la façon dont se passe la résolution du problème,

• des informations sur les activités récurrentes,

17 Selon, le livre Gestion de projet AGILE de Véronique Messager Rota et sur le site web d’Yves Constantinidis sur l’Ingénierie des besoins,


• de l’état du système à la fin du scénario. - Le Benchmark analyse la concurrence pour permettre à l’entreprise de découvrir ses propres besoins, en comparant les solutions concurrentes et en en mesurant les avantages et les inconvénients. - L’Interview et le Questionnaire permettent de recueillir rapidement les avis et opinions de plusieurs utilisateurs de l’application sur quelques points, sous réserve de poser les bonnes questions. - L’Atelier, les forums d’échanges ou les groupes de travail sont des groupes de personnes qui se réunissent pour discuter et comparer leurs idées sur un point précis. - L’Observation du comportement de l’utilisateur « en situation » et/ou l’immersion dans la réalité de l’environnement d’utilisation du système renseigne parfois beaucoup plus que des discussions organisées pour comprendre comment le client travaille réellement et quels sont ses besoins. - L’Analyse de l’existant peut simplement faire émerger un besoin, en évaluant les forces et faiblesses des applications existantes, et en imaginant comment les améliorer. Il n’y a pas de technique meilleure que les autres ; chacune est utile en fonction des situations. C’est le rôle du chef de projet de trouver la technique adaptée au contexte du client. Une fois recueillis, les besoins doivent être formalisés à l’aide de différentes techniques.

2.2. De Formalisation du besoin Lors de l’analyse et de la formalisation des exigences, les besoins « bruts » seront affinés, en éliminant les ambigüités, incohérences, redondances,… à l’aide d’outils18. Les spécifications sont souvent réalisées en langage naturel. Pourtant, il existe des méthodologies qui permettent d’éviter toute ambigüité, imprécision ou dénaturation du besoin exprimé. Afin de suivre les besoins, la traçabilité et l’historique des besoins s’avère utile. Un référentiel est un langage commun entre les divers acteurs du projet. - La norme IEEE830-1998, concernant les « pratiques recommandées pour la spécification des exigences logicielles » définit un document de spécification des exigences essentielles. Chaque fonctionnalité est une exigence et l’ensemble constitue le référentiel commun utilisé par les parties prenantes du projet. - Le langage naturel structuré : la structure de l’objet informatique (sa syntaxe) est donnée dans un formalisme précis (UML, modèle conceptuel, langage de classe...). 18 Les techniques sont reprises des Cours sur Expression et analyse du besoin par Anne Marie HUGUES et du livre de gestion de projet Agile de V. Messager Rota.


- Le Product Backlog est le référentiel des méthodes Agiles qui regroupe les exigences ou livrables. Les fonctionnalités sont hiérarchisées par le client en fonction de leur Valeur Ajoutée. Chaque composant de la liste est appelé PBI (Product Backlog Items), et décrit les fonctionnalités (user story ou use case). - Le User story est une brève description d’une fonctionnalité du système formulée dans le langage de l’utilisateur. Ce sont des pense-bêtes qui facilitent la communication et l’échange entre l’utilisateur et les développeurs. - Le langage UML (Unified Modeling Language): il ne peut être efficace que si l'expression de besoin est pertinente, sobre et cohérente. L'élaboration du modèle permet de repérer les défauts de cohérence et d'exprimer l'exigence de sobriété. Elle contribue donc à la qualité de l'expression du besoin. - Le Dictionnaire des données contenant les noms des objets utilisés dans l’ordre alphabétique, permet de structurer de façon claire les données dans un tableau. - La Table de Décisions définit les valeurs de sortie d’un processus en fonction de ses valeurs d’entrée et de leurs combinaisons. - La Table de Transitions est un automate modélisant la dynamique du système. - La Description Algorithmique est un langage de programmation abstrait et formalisé qui donne une vision opérationnelle du système. - La Notation Graphique à l’aide de diagrammes ou de graphiques annotés généralement en langage structuré, permet de fournir une vue d’ensemble du système :

• Le modèle entité-associations représente les données d’un système et les relations entre ces données.

• Les diagrammes de flots de données montrent comment chaque processus transforme ses entrées en sorties.

• Les diagrammes états-transitions matérialisent les événements sur le comportement du système et les actions à effectuer.

• Le Use case UML est une technique de formalisation pour décrire les exigences fonctionnelle qui se base sur les scénarios. Souvent utilisée pour spécifier les systèmes à l’aide d’un modèle « objets », ce diagramme explicite les acteurs du système et les interactions avec celui-ci.

• Le réseau de Pétri/ Grafcet étudie l’ordonnancement des activités, modélise et simule des systèmes parallèles à événements discrets.

- La Spécification de l’interface intervient très tôt dans le cycle de vie et donne lieu à de nombreuses discussions avec l’utilisateur puisqu’elle permet de trouver les fonctionnalités du logiciel. La production d’une maquette pour valider l’interface est un moyen efficace pour discuter profitablement avec l’utilisateur. On essayera de


spécifier les menus (fixes, déroulant, pop-up), les boutons, les boites de dialogue, les cases à cocher, les icônes,… - Le Maquettage et le Prototypage permettent de préciser certains points entre l’utilisateur et le développeur, et apparaissent donc comme indispensables lors de la description de l’interface utilisateur et de ses fonctionnalités. Cela permet de mettre en évidence les incompréhensions développeur-utilisateur, de détecter les oublis de spécifications, de découvrir les contradictions et d’évaluer la faisabilité. La maquette permet aux acteurs de se mettre d’accord sur la nature du produit à réaliser. 2.3. De Priorisation des besoins Après les avoir explicités et, avant de les documenter, il faut classer et organiser les besoins afin de définir leur priorité. Il est en effet essentiel d’expliciter les besoins les plus importants afin de ne pas oublier une fonctionnalité fondamentale qui mettrait en cause la compréhension du système dans son ensemble. L’absence de hiérarchisation des besoins peut devenir une cause d’échec du projet. Dans l’approche traditionnelle, en cas de retard, on fait l’impasse sur certaines fonctionnalités peut être plus cruciales pour le client que celles déjà développées. Si toutes les fonctionnalités ne peuvent être implémentées, il est préférable d’implémenter en priorité les plus significatives. Pour hiérarchiser les besoins, il faut par exemple évaluer le bénéfice financier attendu, le coût de développement estimé, le risque de développement, la valeur ajoutée apportée, le degré de satisfaction du client,… La complexité, la valeur et le risque :

La priorité d’un cas d'utilisation peut être établie à partir de beaucoup de critères. Nous retenons dans la suite les critères de valeur ajoutée, de risque et de complexité. A l’aide de ces trois critères et d’un calcul simple, les besoins pourront être hiérarchisés. La valeur ajoutée pour l’utilisateur :

1. souhaitable, 2. utile, 3. important, 4. indispensable

Le risque associé : 1. pas ou peu risqué, 2. moyennement risqué, 3. très risqué, 4. critique


Plus une fonctionnalité est complexe, plus elle sera coûteuse à implémenter. La complexité de l’exigence peut être :

1. triviale, 2. simple, 3. complexe, 4. très complexe.

Pour chaque exigence, il suffit donc de calculer la priorité et de développer les exigences ayant les résultats les plus élevés :

Priorité = valeur ajoutée x (risque + complexité) La valeur ajoutée et les risques de développement : Il est essentiel de savoir quelles fonctionnalités implémenter en premier en prenant compte le risque et la valeur ajoutée associés.

19 Les fonctionnalités ayant une forte valeur ajoutée sont prioritaires : parmi celles-ci, les plus risquées sont développées avant les autres. Une fonctionnalité avec peu de valeur et très risquée sera développée à la fin ou non livrée. (« A éviter »)

19 Selon Mike Cohn, Agile estimating and planning, Prentice hall, 2004


Le degré de Satisfaction du client : Il est primordial de connaitre ce qui est considéré comme satisfaisant pour le client La méthode Kano consiste à regrouper les caractéristiques d’un produit en fonction du degré de satisfaction qu’elles apportent aux utilisateurs. Il faut tout d’abord classifier les exigences en trois catégories :

• Eléments de performance : le besoin a été exprimé par le client, sa satisfaction est proportionnelle au niveau de performance de la fonctionnalité.

• Eléments basiques : doivent être satisfaites afin d’éviter une frustration et un mécontentement chez le client, mais nul besoin d’en améliorer la qualité ou la performance.

• Eléments attractifs : bonnes surprises ou besoins émergeants qui génèrent une forte satisfaction sans pour autant manquer lorsqu’ils sont absents, car ils n’ont pas été exprimés.

Il faut ensuite mesurer la corrélation de la réalisation des attentes avec la satisfaction du client.

20 La priorité porte donc sur les exigences obligatoires dites basiques puis sur les éléments de performance et enfin sur certaines exigences attractives.

20 D’après http://www.definition-marketing.com et le livre de Gestion de projet Agile


Pour déterminer le type de chaque exigence, il est conseillé de mener une enquête auprès des utilisateurs afin de savoir quelle fonctionnalité est plus considérable que d’autres ou simplement le définir avec le représentant des utilisateurs. La méthode des Poids Relatifs 21de Karl Wiegers est une autre méthode de priorisation des exigences. Le principe est d’évaluer pour chaque exigence, sur une échelle de 1 à 9, le bénéfice et le préjudice relatif. En additionnant ces deux valeurs, on obtient la valeur de l’exigence. Chaque exigence a donc un poids dans la valeur globale du produit. C’est pourquoi on calcul le pourcentage de la valeur de chaque exigence, puis on fait de même pour le coût. La priorité de l’exigence est la valeur divisée par le coût. Exemple :

Exigences Bénéfice relatif

Préjudice relatif Valeur % Valeur Coût

estimé % Coût Priorité

calcul Exigence A 5 2

7=5+2 22,58= 7/31*100 20

27,8= 20/72*100

0,81= 22,58/27,78

Exigence A 7 22,58 27,78 0,81

Exigence B 8 9 17 55 45 62,50 0,88

Exigence C 1 6 7 22,58 7 9,72 2,32

Total 14 17 31 100 72 100 -

La méthode MOSCOW21 propose une échelle de hiérarchisation des besoins où chaque lettre a une signification : M pour «Must have » (Indispensable) : ce sont les exigences fondamentales du produit, S pour « Should have » (Souhaitable) : ce sont les besoins importants mais non fondamentaux, C pour « Could have » (Possible) : ce sont les besoins considérés comme un confort supplémentaire apporté par le système, W pour « Want to have but Won’t have » (Souhaité mais non réalisable pour le moment donc Eliminé) : ce sont les besoins non prioritaires, Les O sont des objets de liaison. Pour faciliter les arbitrages, il convient au chef de projet de choisir sa méthode de valorisation et de hiérarchisation des exigences parmi les techniques présentées.

21 Livre Gestion de projet AGILE de véronique Messager Rota EYROLLES


2.4. De Vérification et de Validation Pour assurer la Qualité du projet, il est décisif de valider et vérifier en permanence toutes les phases du projet et de se poser les questions suivantes :

• Validation : sommes nous en train de faire le bon produit ? • Vérification : est ce que nous faisons le produit correctement ?22

Ainsi, après analyse et rédaction des besoins, il convient de vérifier et de valider les documents écrits. Les exigences devront être vérifiées puis validées par toutes les parties prenantes du projet. C’est pourquoi, le cahier des charges doit être systématiquement relu par un ou plusieurs tiers. L’étape de relecture est primordiale et permet au vérificateur de procéder aux contrôles suivants :

• vérifier la validité : l’utilisateur peut revenir sur ses déclarations de besoins et ré exprimer ses besoins différemment. Le chef de projet doit donc s’assurer de la validité du besoin.

• vérifier la cohérence : les besoins exprimés ne doivent pas être contradictoires.

• vérifier la complétude : tous les besoins du client doivent être présents dans le cahier des charges.

• vérifier le réalisme : les besoins doivent être satisfaits et réalisables à l’aide de la technologie existante et en respectant le budget et les délais

• vérifier la fiabilité : les besoins doivent être exprimés sous une forme vérifiable et sans ambigüité de façon à ce que le document puisse faire office de contrat.

La validation permet donc de débusquer les erreurs dans le cahier des charges : « plus tôt une erreur est détectée et moins elle coûte »23. En effet, le coût de correction d'une erreur croît exponentiellement avec le temps : si une erreur est découverte à la fin du projet, il faut alors repasser par toutes les phases du projet pour la corriger.

La mise en place d’inspections et de revues permet de valider et vérifier les besoins. L’inspection consiste en une lecture critique d’un document visant à en améliorer la qualité. La revue est une réunion permettant de valider le cahier des charges et les spécifications.

22 Cours d’Anne Marie Hugues, Maître de conférences Polytech'Nice Sophia 23 Cours Diderot : http://www.pps.jussieu.fr/


A chaque règle de gestion doit correspondre un cas de test : cela permet de se rendre compte de la bonne rédaction des spécifications. Un prototype est « une version incomplète d'un logiciel ou d'un site web, conçu pour tester son fonctionnement avant la phase de programmation informatique24. » L’écriture d’un prototype ou d’une maquette 25 permet la validation des spécifications par expérimentation : « je saurais ce que je veux lorsque je le verrai ».

24 Selon Wikipédia, 25 Selon Anne-Marie Hugues, dans son cours de génie logiciel,


IV. Etude de cas chez Sanofi Dans les grands groupes et grandes entreprises, une méthodologie projet est mise en place afin que tous les salariés puissent travailler ensemble et de façon cohérente sur des projets. Ainsi, tous les acteurs du projet doivent utiliser la méthodologie définie par la société, mais le chef de projet peut toujours – en fonction du contexte projet - utiliser les diverses techniques évoquées précédemment. Chez Sanofi, le service Qualité SI s’occupe de concevoir, de mettre en œuvre et de continuellement améliorer l’approche qualité de la Fonction SI. Plusieurs Directions Informatiques existent chez Sanofi (Pasteur, R&D, Groupe, Affaires industrielles,..). Jusqu’à récemment, plusieurs méthodologies étaient utilisées chez Sanofi. Ainsi, Sanofi Groupe utilisait la méthodologie SIMPLe. Depuis janvier 2012, toutes les entités du groupe doivent utiliser la méthodologie PUMA (Project Unified Methodology Approach), méthodologie Qualité transverse et harmonisée.

1. La méthodologie SIMPLE

Toujours utilisée sur certains projets anciens, SIMPLe est facile à comprendre et à utiliser, d’où son nom. Elle est constituée d’un cycle de vie de sept phases, jalonnées à chaque fin de phase:

1. Initiation de l’organisation du projet et analyse de la demande ; 2. Définition du besoin : identifier, consolider, et valider les besoins ; 3. Définition de la solution : définir la solution applicative, la solution

technique et les services opérationnels. Finaliser l’organisation du projet ; 4. Spécification de la solution : spécifier la solution applicative, la solution

technique et organiser les tests et la mise en production ; 5. Réalisation et test : développer et implémenter l’environnement de recette,

puis réaliser les tests d’intégration du système, enfin préparer à l’utilisation du système (formation,..) ;

6. Acceptation : réaliser la recette utilisateur et implémenter l’environnement de production ;

7. Mise en production : gérer la transition, effectuer le go-live, gérer la période post démarrage, et clôturer le projet.


2. La méthodologie PUMA

La méthodologie PUMA permet de répondre aux besoins exprimés par les utilisateurs en les impliquant tout au long du projet. Les six phases de cette méthodologie sont :

1. Initiation de l’organisation projet et analyse de la demande ; 2. Définition du besoin : analyse du besoin, de la solution applicative et

technique, rédaction du cahier des charges ; 3. Conception : spécification et organisation des tests ; 4. Réalisation : développement et tests d’intégration, préparation de la

recette utilisateur et à l’utilisation du système (formation,..) ; 5. Acceptation : recette utilisateur et validation ; 6. Mise en production : déploiement, maintenance et clôture du projet.

Intéressons nous ici aux étapes de la phase de recueil et d’analyse des besoins dans PUMA. On peut voir que cette phase est particulièrement détaillée car critique.

1. Identifier, comprendre et documenter les processus Métier ; 2. Analyser le système actuel d’un point de vue fonctionnel ; 3. Organiser les ateliers « expression des besoins » ; 4. Identifier les besoins et les contraintes (besoins fonctionnels et non

fonctionnels : contraintes réglementaires et légales, interfaces, acteurs, contraintes budgétaires, échéances, contraintes sécurité,...) ;

5. Enregistrer les besoins identifiés (initialisation du cahier des charges) 6. Consolider et concilier les besoins ; 7. Affecter un niveau de priorité métier à chaque besoin ; 8. Affecter une classification risque métier au système et à chaque besoin ; 9. Rédiger le cahier des charges ; 10. Effectuer une revue (Utilisateur et Informatique) pour vérifier et

approuver l’expression de besoins. Cycle de vie des méthodologies : Les méthodologies SIMPLe et PUMA ont un cycle de développement en Cascade. En effet, les phases de la méthodologie se succèdent sans retour arrière possible et la documentation est très présente. Cependant PUMA se veut plus Agile que SIMPLe car conçue pour être plus flexible. L’intégralité de la charte documentaire n’est pas systématiquement produite pour tous les projets. L’identification des livrables documentaires est faite par le chef de projet et le responsable Qualité nommé sur le projet. SANOFI, grand groupe pharmaceutique, sous-traite la plupart des développements. Aussi, afin de protéger les parties prenantes du projet, le cahier de charges est considéré comme la base du contrat. Comme nous l’avons expliqué précédemment, il est difficile de mener un projet Agile sous-traité puisque


dans un contrat au forfait, le cahier des charges est définit dès le début du projet par le client. Dans les méthodes Agiles, il y a peu de documentation et donc pas de cahier des charges bien défini mais plutôt un référentiel de toutes les fonctionnalités prioritaires. Chez Sanofi, la documentation est obligatoire pour tous les projets. Certains projets - dits GxP - sont réglementés par des bonnes pratiques (comme la Bonne Pratique Clinique, la Bonne Pratique de Laboratoire, etc.) ou un autre règlement applicable et lié à la santé publique. Ces projets impliquent plus de livrables obligatoires, à faire valider par des personnes spécifiques. Tout doit donc être défini dès le début du projet et l’intégration de changement tardifs dans l’expression de besoins devient impraticable. Il est donc impossible d’utiliser une approche Agile dans un groupe pharmaceutique tel que Sanofi car il existe trop de contraintes réglementaires. Toutefois, certaines « bonnes pratiques » Agiles peuvent être utilisées, tel que l’implication de l’utilisateur et les itérations, afin de stabiliser efficacement l’expression du besoin.

4. Mon utilisation des bonnes pratiques chez Sanofi

Chez Sanofi, je suis située dans le département Solutions d’Entreprise de la direction des Systèmes d’Information. Je suis rattachée au service SI Achats, qui gère toutes les solutions Achat et leur support. Mon projet principal est l’application SAVE, logiciel développement spécifique qui permet l’analyse des performances achats et la gestion du budget achats. SAVE permet :

• aux acheteurs de saisir leurs fiches de négociation et d’établir leur prévisions de couverture de négociation, et leurs prévisions de « savings »26 Achats.

• aux administrateurs et approbateurs de contrôler et valider les résultats de négociation

Présentation des acteurs : Maitrise d’Ouvrage : les Achats, c'est-à-dire un client Interne à Sanofi. Des responsables représentent les utilisateurs. Maitrise d’Œuvre : le CoS27 représenté par le chef de projet technique en lien avec l’équipe de développement. Sous-traitance : la Factory située à l’ile Maurice, développe l’application. Assistance à Maitrise d’Ouvrage : Hervé Raffa, mon maitre d’apprentissage et moi, faisons le lien entre la MOA et la MOE c'est-à-dire que nous aidons le client à définir les fonctionnalités de l’application et vérifions auprès des développeurs si l'objectif est techniquement réalisable.

26 Savings : terme anglais désignant les économies réalisées lors de la négociation avec le fournisseur 27 CoS : Centers of Services : partenaire technique des entités de SANOFI


Méthodologie : Jusqu’ici, j’ai principalement travaillé avec la méthodologie SIMPLe sur des évolutions de SAVE et je serai amenée pour les futurs projets à travailler avec la méthodologie PUMA. Déroulement d’un projet ou évolution : Le client produit le Cahier des charges. Toutefois certains clients n’en ont jamais écrit. En tant qu’AMOA, je suis présente pour aider le client à clarifier son besoin, l’aider à ne pas oublier de fonctionnalités, mais aussi lui montrer comment rédiger le document à l’aide du template du livrable de la méthodologie. Pour cela, des réunions, des conférences téléphoniques, ou de simples sessions téléphoniques permettent d’identifier les besoins réels et de les formaliser sans interprétation possible. L’expression des besoins peut être réalisée sous la forme de réunions « brainstorming ». Ces réunions permettent de définir les niveaux de classification des fonctionnalités de l’application par groupe d’informations tel qu’un besoin fonctionnel, un processus métier ou une fonctionnalité de l’application. A cette étape précise de recueil de besoin, il est essentiel que l’AMOA soit disponible pour le client et puisse répondre à ses questions ou interrogations.

Le service SI ACHAT fait le lien entre le métier et l’équipe de développement. Nous sommes donc le moteur de la communication, et nous devons comprendre les besoins réels de l’utilisateur afin de les retranscrire aux équipes de développement. Beaucoup d’acteurs sont présents sur le projet, il faut donc s’assurer que l’ensemble de l’équipe est au même niveau de compréhension du sujet, en clarifiant les possibles confusions ou interprétations. Je mets donc en œuvre une communication simple et évite tout jargon technique avec le client. Je retranscris ensuite de façon plus technique pour les développeurs.

J’ai dû dans un premier temps comprendre le vocabulaire Métier des achats (en Français et en Anglais) afin d’assimiler les fonctionnalités existantes de l’application SAVE. Une réunion a été organisée suite à la première version du cahier des charges afin de clarifier certains points. Le cahier des charges a été modifié par le client et c’est cette version modifiée que j’ai retranscrite dans les spécifications générales (qui se veulent beaucoup plus précises). J’ai en effet été chargée de rédiger les spécifications fonctionnelles générales en fonction du cahier des charges fournit par le client. J’ai donc formalisé le besoin en langage naturel mais aussi avec des techniques structurées (tableaux, impressions écran ou maquettes), des notations graphiques, des diagrammes de flux, des use case et des algorithmiques (exemple : si case vide alors erreur sinon validation).


Ces méthodes simplifient la lecture pour les développeurs qui ne connaissent pas le vocabulaire métier. Le client et le COS sont les approbateurs du document de spécification. La relecture et la vérification sont essentielles afin de stabiliser le document. Un devis est établi par le CoS sur la base des spécifications fonctionnelles. Après validation du devis par le client, la phase de spécification détaillée et de développements peut commencer. Le chef de projet technique du COS rédige les spécifications détaillées et techniques sur la base des spécifications fonctionnelles : il peut nous poser des questions s’il n’a pas bien compris certains points. Des comités de suivi sont planifiés régulièrement afin de fournir au client un point d’avancement sur le projet : où nous en sommes comparativement au planning validé, et quand le client devra intervenir (pour ses tests). L’implication du métier est primordiale : certains clients n’ont jamais réalisé de recette utilisateur : il faut donc les accompagner en leur donnant des conseils et astuces. Mais le client, c'est-à-dire les achats, a un métier qui lui prend du temps ils ne peut donc pas être 100% disponible pour le projet. La disponibilité du client est donc une contrainte à prendre en compte lors de l’établissement du planning projet. En charge du support niveau 3 relatif aux fonctionnalités de l’application, je me suis aperçue que certains besoins avaient mal été définis en phase projet, et nous avons dû implémenter des évolutions pour remédier à ce problème. Les outils : Il existe des outils qui permettent de suivre les évolutions d’une application, tels que QC (Quality Center). Quality Center de HP possède un module permettant de gérer les exigences. QC est utilisé chez Sanofi pour réaliser les tests et remonter les problèmes détectés durant ces tests. Néanmoins, il serait intéressant de bénéficier d’un outil qui regroupe les diverses techniques abordées en partie III, afin d’analyser, recueillir, formaliser et classer les besoins des utilisateurs. Un tel outil serait une solution pour faciliter la stabilisation de l’expression du besoin. En amont des outils, un formulaire poserait des questions sur la nature, le contexte, le type de projet à réaliser et en fonction des critères sélectionnés, l’application proposerait à chaque étape les techniques appropriées. Par exemple : A l’étape de recueil des besoins, l’application donnerait la possibilité d’effectuer un brainstorming, de réaliser facilement un questionnaire ou interview, de prendre des notes lors de l’Observation du comportement de l’utilisateur, d’aider à la réalisation de scénarios. A l’étape de formalisation du besoin, l’application permettrait de modéliser le système grâce aux diagrammes UML, de réaliser des maquettes et même un référentiel Product Backlog.


Pour hiérarchiser les besoins, l’application proposerait au chef de projet un choix de plusieurs méthodes de priorisation des besoins (La méthode des Poids Relatifs, Kano ou MOSCOW). Une telle application ne pourrait cependant pas vraiment apporter d’aide pour la dernière étape de vérification et de validation car c’est aux acteurs du projet de relire plusieurs fois la documentation afin de s’apercevoir d’un éventuel oubli. Cependant, cette application pourrait rappeler les points de vérification vus précédemment, ou aider à la réalisation des cas de tests correspondant à l’exigence. Enfin, cette application donnerait la possibilité de :

• gérer et suivre les exigences définies en début de projet, • vérifier si le besoin a correctement été développé, • constater le niveau de satisfaction du client, • tracer les évolutions du besoin.

Ces outils existent déjà et j’ai conscience que cette solution n’est pas révolutionnaire. Cependant, le fait de tous les regrouper dans une seule et même application. La concentration de tous les outils indispensables à la bonne gestion du projet permettrait au chef de projet d’aider le client à bien définir ses exigences et donc de l’accompagner dans la stabilisation de l’expression de son besoin.


Conclusion Une bonne expression des besoins est essentielle à la réussite du projet. Toutefois c’est un exercice complexe. De nombreux problèmes peuvent apparaître liés à une mauvaise communication, un manque d’implication du client, une évolution des besoins ou la nature des relations entre les acteurs. L’expression du besoin doit donc être stabilisée, et pour cela, le chef de projet devra accompagner l’utilisateur dans cette démarche. Malgré les nombreux avantages des méthodes Agiles, celles-ci ne peuvent pas être appliquées dans toutes les entreprises. C’est pourquoi il convient de conserver les méthodes traditionnelles dites prédictives en adoptant certaines bonnes pratiques agiles. Le chef de projet et les utilisateurs doivent être disponibles, impliqués et collaborer pour la réussite du projet. En fonction du contexte et de la nature du projet, il convient au chef de projet d’utiliser les techniques existantes à chaque étape (recueil, formalisation, priorisation, vérification et validation) afin d’accompagner le client dans sa définition de besoin et, ce faisant, dans la stabilisation de ce dernier. Chez Sanofi, il existe de nombreuses bonnes pratiques empruntées aux deux approches et j’essaye, autant que faire ce peut, de les appliquer et d’en utiliser d’autres découvertes grâce à ce mémoire. Un outil regroupant l’ensemble de ces techniques permettrait au chef de projet d’accompagner le client dans la stabilisation de son besoin, mais à quel prix ?


Glossaire PMBOK: Project Management Body Of Knowledge GxP : good x Practice : réglementation légale liée à la Santé Publique QC : Quality Center est une solution web permettant de gérer la quasi-intégralité des activités de tests au travers de différents modules qui, bien évidemment, sont tous liés entre eux, offrant des possibilités de reporting très puissantes VIE : volontariat international en entreprise MOA : Maîtrise d'Ouvrage MOE : Maîtrise d'Œuvre AMOA : Assistance à maîtrise d'ouvrage RAD : Développement Rapide d’Applications IEEE : Institut des ingénieurs électriciens et électroniciens est une association professionnelle qui a pour but de promouvoir la connaissance dans le domaine de l’ingénierie électrique. Vocabulaires propres à Sanofi : COS : Center of Services, représente l’équipe technique Savings : terme anglais désignant les économies réalisées lors de la négociation avec le fournisseur SAVE : logiciel d’analyse des performances achats et la gestion du budget achats PUMA : Project Unified Methodology Approach SIMPLe : ancienne méthodologie de Sanofi


Les sources Définitions : Wikipédia Citations : De Robert Blondin dans le Bonheur Possible Etude bibliographique pour l’état de l’art: Livre Gestion de projet AGILE de Véronique Messager Rota EYROLLES http://generationagile.com Méthodologies chez SANOFI -Documentation sur l’intranet de SANOFI -Informations pendant la formation PUMA -Interview du responsable qualité PUMA de Solutions Entreprise Cours : Cours de Gestion de Projet de Selmin Nurcan http://cyril.haller.free.fr : cours gestion de projet à l’université Lille1 Cours d’Anne Marie Hugues, Maître de conférences Polytech'Nice Sophia Cours Diderot : http://www.pps.jussieu.fr/


Annexe 1 : Projet Professionnel Avec l’obtention du double Master MIAGE (IKSEM ou SIC), je souhaite réaliser un VIE : volontariat international en entreprise avec Sanofi ou une autre société. Je souhaite travailler à l’étranger, aux Etat Unis, Australie ou autres pays anglophones afin d’améliorer mon niveau d’anglais et d’acquérir de l’expérience dans un domaine qui me plait : l’informatique de gestion et/ou le management. Ainsi, je pourrai diversifier mes compétences. J’aimerais pouvoir rester par la suite à l’étranger et découvrir d’autres cultures. J’espère devenir bilingue en anglais puis revenir en France avec un emploi plus intéressant et mieux rémunéré. L’avantage est que l’informatique est indispensable à chaque entreprise, en France comme à l’étranger. Les métiers que je souhaite exercer sont Chef de projet ou Maitre d’ouvrage. En effet, ma mission actuelle chez Sanofi est en adéquation avec mes attentes. Cette mission est moins technique que mes missions précédentes. Je joue le rôle d’interface entre le métier (client interne chez Sanofi) et l’équipe de développement. Je dois donc maîtriser les aspects techniques et comprendre les enjeux fonctionnels relatifs aux achats. Ce que j’aime particulièrement, c’est le contact avec les clients, les aider à définir leurs besoins et les formaliser afin de bien préparer le travail des développeurs. J’apprécie également accompagner les clients dans leur recette utilisateurs et rédiger des documents de spécifications et procédures. Je souhaite pouvoir, après quelques années d’expérience, gérer le budget, établir le planning du projet et diriger une équipe. Je pense donc que le Master MIAGE en apprentissage à la Sorbonne est pour moi la manière la plus efficace de compléter ma formation et consolider mes connaissances afin de réaliser mon projet professionnel.


Annexe 2 : Mission MASTER 2 La mission qui me sera confiée l’année prochaine reste celle de cette année, c'est-à-dire assistant à maitrise d’ouvrage dans le service des Achats sur le logiciel SAVE. Je serai en charge de la gestion et du suivi des correctifs et évolutions, ainsi que du support niveau 3 sur l’application. De plus, je serai amenée à travailler sur le support de l’application NEXTS, solution groupe de gestion des achats non stockés. Pour pallier au manque de communication interne entre tous les acteurs locaux et globaux du projet, un espace collaboratif de travail SharePoint devra être mis en place afin de permettre le partage de connaissances et la transparence du support NEXTS. Enfin, je pourrai également être amenée à travailler sur une application de gestion des appels d'offres fournisseurs. En somme, de nombreuses tâches diverses et variées me seront confiées et je pourrai approfondir et consolider mes connaissances et compétences.

MEMOIRE La stabilisation de

Documents

Transcript of MEMOIRE La stabilisation de