Introduction aux principes et techniques du management de projet systeme d'information manuel de cours

Télécharger

Introduction aux principes et techniques du management de projet système d'information manuel de cours

3.1 LA CHARGE ET LA DURÉE

Avant de présenter les méthodes permettant d’estimer la charge d’un projet, nous allons préciser certaines notions, puis nous situerons les différents niveaux d’estimation, auxquels sont attachés des objectifs spécifiques.

Il convient de bien distinguer charge et durée.

La charge représente une quantité de travail nécessaire, indépendamment du nombre de personnes qui vont réaliser ce travail ; elle permet notamment d’obtenir un coût prévisionnel. Elle s’exprime en jour-personne, mois-personne ou année-personne. Un mois-personne représente l’équivalent du travail d’une personne pendant un mois, en général 20 jours.

Ainsi, un projet de 60 mois-personne représente l’équivalent du travail d’une personne pendant 60 mois. Si on évalue le coût complet du mois-personne à 50 K€ en moyenne, le projet sera estimé à 3 M€.

On mesure la taille des projets à leur charge. Les ordres de grandeur générale­ment retenus sont les suivants :

  • si la charge est inférieure à 6 mois-personne, c’est un très petit projet ;
  • si la charge est comprise entre 6 et 12 mois-personne, c’est un petit projet ;
  • si la charge est comprise entre 12 et 30 mois-personne, c’est un projet moyen ;
  • si la charge est comprise entre 30 et 100 mois-personne, c’est un grand projet ;
  • si la charge est supérieure à 100 mois-personne, c’est un très grand projet, souvent mesuré en années-personne.

La durée dépend du nombre de personnes. Soixante mois-personne, ce peut être aussi bien une personne pendant cinq ans, cinq personnes pendant un an, dix personnes pendant six mois ou soixante personnes pendant un mois. Cepen­dant, intuitivement on sent bien que l’on ne peut pas faire n’importe quoi. Certaines méthodes d’estimation proposent de respecter un rapport charge/durée. Nous le précisons plus loin.

3.2 LES DIFFÉRENTS BESOINS D’ESTIMATION

Les besoins d’estimation des charges se situent à différents niveaux. Prenons l’exemple du domaine Gestion de production par lots (figure 3.1).

Figure 3.1 — Exemples de niveaux d’estimation.

Un niveau correspond à un objectif. L’exigence de précision en est dépen­dante. Souvent le but visé par une évaluation est lié au stade d’avancement du projet. Pour souci de simplification, nous présentons les besoins d’estimation tels qu’on les rencontre aux différents stades du cycle de vie classique détaillé au chapitre précédent.

Au niveau projet, on veut estimer la charge du projet complet. L’ordre de gran­deur est le mois-personne ou l’année-personne. Il y a plusieurs raisons pour faire une telle estimation :

  • déterminer une enveloppe budgétaire;
  • voir ce que « pèse » le projet en termes d’effort;
  • faire une estimation de la rentabilité de l’investissement;
  • évaluer une durée vraisemblable du projet.

Au niveau phase, on cherche la charge d’une étape spécifique. L’ordre de gran­deur est le mois ou la semaine-personne. Les objectifs d’estimation à ce stade sont les suivants :

  • Ajuster le découpage. Si la charge est importante, on va chercher à la diviser en deux lots, gérés comme deux sous-projets, qui pourront éventuellement être livrés à des dates différentes.
  • Sous-traiter. Fournisseur et client font chacun une estimation. Celle-ci est indispensable au premier pour ne pas s’engager à travailler à perte. Mais de son côté, le client peut recevoir en réponse à un appel d’offres des proposi­tions dont les prix varient de un à dix. Retenir le « moins disant » peut constituer un risque réel. Il y a, à ce sujet, le cas célèbre d’un projet de l’US Air Force. Bien que l’estimation initiale fût de 1 500 K$, une société de services remporta le marché à 400 K$. Après développement d’un système incomplet, le fournisseur a négocié plusieurs avenants. Au final, le coût total fut de 3 700 K$, soit près de dix fois le montant du marché initial et plus du double de l’estimation par le client... Ce surcoût s’est accompagné de retards considérables sur le calendrier prévu.
  • Prévoir des délais pour planifier l’ordonnancement des étapes, ainsi que des opérations complémentaires comme la formation des utilisateurs.
  • Prévoir des ressources, pour planifier l’affectation d’intervenants (internes ou externes) sur le projet.

Au niveau étape (ou activité), l’estimation est nécessaire pour :

  • faire une planification précise ;
  • annoncer un calendrier de remise des différents résultats intermédiaires (entre les livrables de deux phases) ;
  • prévoir et effectuer un suivi du projet ou sous-projet, pour surveiller les écarts ;
  • prévoir l’affectation des ressources, car il peut y avoir une montée en charge ou une diminution d’une étape à l’autre.

Au niveau tâche, il s’agit d’évaluer chacune des tâches qui font généralement l’objet d’une affectation individuelle, par exemple la tâche d’élaboration du jeu d’essai Planification de production. L’ordre de grandeur est le jour-personne.

Entre le niveau du projet et celui de la tâche, la visibilité est croissante, ce qui fournit des éléments de plus en plus précis pour l’évaluation. C’est pourquoi on utili­sera des techniques différentes, selon le niveau où se situe le besoin d’estimation.

3.3 LES DIFFÉRENTES MÉTHODES D’ESTIMATION 3.3.1 Les non-méthodes

Citons tout d’abord des techniques parfois utilisées, que l’on peut cependant ranger dans la catégorie des « non-méthodes ».

La méthode dite de Parkinson n’a rien à voir avec la maladie du même nom : elle fait référence à un auteur, historien et militaire, qui a traduit des observa­tions récurrentes d’un dysfonctionnement administratif sous forme d’une « loi »1, stipulant que « le travail se dilate jusqu’à remplir le temps disponible ».

Supposons que, pour réaliser une tâche, on dispose d’une personne pendant trois mois. En l’absence d’estimation, la vitesse d’avancement est, dans la plupart des cas, spontanément ajustée à la durée de disponibilité des individus. Plus la taille de l’équipe est importante, plus cette « loi » se trouve vérifiée. L’estimation des charges est difficile, car elle ne résulte pas de la simple application d’une formule. Pour cette raison, certaines entreprises ne font guère d’estimation de leurs projets système d’information, considérant que « cela ne tombe jamais juste ». Cependant, la « loi » de Parkinson nous indique que, sans évaluation, on consomme en général beaucoup plus de temps, si l’on compare avec des projets analogues, et le travail s’achève difficilement.

La méthode du marché consiste à considérer que la charge correspond au prix à proposer pour remporter l’appel d’offres. L’exemple du projet de l’US Air Force cité plus haut montre les limites de cette méthode. Il ne s’agit pas de nier les contraintes commerciales dans un marché concurrentiel. Une société de services peut répondre à perte à un appel d’offres, dans l’espoir d’obtenir ultérieurement d’autres contrats dont la rentabilité compenserait la perte sur le premier. Cepen­dant, dans un tel cas, il est indispensable de faire parallèlement une évaluation réaliste, pour pouvoir planifier et organiser le projet sur des bases solides.

3.3.2 Les méthodes

Il existe cinq familles de méthodes d’estimation, qui ne sont pas forcément concurrentes, mais peuvent être utilisées simultanément, ou à des moments diffé­rents du cycle de vie du projet : le jugement d’expert, l’estimation par analogie, l’estimation ascendante, l’estimation paramétrique et l’estimation probabiliste.

  1. Le jugement d’expert

Certaines estimations sont basées sur le jugement d’expert. Les experts sont, dans le cas des projets système d’information, des consultants ou d’autres chefs de projet expérimentés, qui font appel à leurs connaissances explicites ou implicites, acquises au cours de leur vécu et leurs observations. La méthode Delphi, que nous présentons au paragraphe 3.4, a formalisé un processus de mise en commun d’expertise.

  1. L’estimation par analogie

Les estimations s’appuient sur les consommations de projets similaires pour lesquels on a conservé une mémoire. Ces projets peuvent être internes ou externes à l’entreprise. Par exemple, on veut mettre en place une nouvelle Gestion des clients dans une banque A. On sait qu’un projet analogue mené par une banque B a coûté 500 mois-personne et un projet analogue dans une compagnie d’assurance a consommé 350 mois-personne. Ces deux estimations permettent d’avoir un ordre de grandeur. On va situer le projet à estimer par rapport aux deux projets connus, en déterminant si les caractéristiques du projet le rapprochent davantage de la banque B ou de la compagnie C.

On peut aussi se servir d’une référence interne, sur un autre domaine. On a déjà fait un projet Gestion de carte bancaire, qui a coûté 700 mois-personne, et un projet Gestion des crédits qui a coûté 1800 mois-personne. On estime que le domaine Dépôt-épargne est d’une complexité qui le situe entre les deux. On retiendra un chiffre d’environ 1200 mois-personne.

L’estimation basée sur l’analogie doit prendre en compte les facteurs d’environ­nement. Ainsi, une Gestion des clients dans une petite banque d’affaires coûtera en principe moins cher que dans une grande banque à réseau, notamment à cause des processus de décision et des procédures de qualification.

Nous détaillons au paragraphe 3.5 deux méthodes pouvant se rattacher à cette famille : la méthode de répartition proportionnelle, basée sur l’hypothèse que les différentes phases d’un cycle sont liés par une relation de proportionnalité ; la méthode des ratios qui s’appuie sur l’observation de pourcentages stables entre différentes activités.

  1. L’estimation ascendante

Le principe de cette famille de méthodes est d’estimer la charge d’éléments de travail (lot de travail, activité, tâche...) et de totaliser ces estimations élémen­taires. Elle requiert donc d’avoir réalisé une structure de découpage du projet suffisamment fine. Nous décrivons au paragraphe 3.6 la méthode d’évaluation analytique, qui est fréquemment utilisée.

L’estimation paramétrique

Certaines méthodes utilisent un modèle mathématique, issu d’analyses statis­tiques sur la relation entre un ou plusieurs paramètres, qui sont des variables caractéristiques du projet, et la charge prévisible.

L’estimation paramétrique est analogue à la technique des unités d’œuvre utilisée en comptabilité analytique pour répartir des coûts généraux de façon simple, facile à calculer, uniforme (la même règle s’applique à tous), et pas trop fausse dans le sens où le résultat n’est pas trop éloigné de celui que l’on obtien­drait si l’on se livrait à un calcul direct et détaillé. Par exemple, les coûts d’entretien d’un immeuble sont répartis entre les différents Départements proportionnelle­ment à la surface occupée ; l’unité d’œuvre est le mètre carré, la valorisation se fait à partir d’un coût standard du mètre carré. De même les coûts d’un Service approvisionnement qui travaille pour toute l’entreprise sont redistribués dans chaque service proportionnellement au nombre de commandes passées ; l’unité d’œuvre est la commande, pour laquelle on détermine un coût standard.

Pour utiliser cette technique, il faut déterminer une ou plusieurs unités d’œuvre pertinentes, affecter un coût unitaire standard à chaque unité d’œuvre (par exemple, en divisant un coût global précédemment mesuré par le nombre total d’unités d’œuvre) et pouvoir dénombrer les unités d’œuvre. Les méthodes basées sur un modèle proposent donc de repérer certains éléments simples, à partir desquels on calculera l’effort nécessaire. Nous allons présenter deux méthodes, diversement utilisées : le modèle Cocomo au paragraphe 3.7 et la méthode des points de fonction au paragraphe 3.8.

Les méthodes d’estimation paramétriques s’inscrivent, totalement ou partiel­lement, dans un schéma général (figure 3.2) comportant les étapes suivantes :

  • faire une estimation de la taille du projet à l’aide d’une unité de mesure ;
  • convertir la taille en charge ;

Nous avons regroupé dans cette famille des approches utilisées conjointe­ment avec d’autres méthodes lorsque l’incertitude est élevée et que l’on cherche à réduire le risque d’une évaluation erronée. Nous présentons au paragraphe 3.9 l’estimation à trois points et la méthode de Monte-Carlo.

3.4 LE JUGEMENT D’EXPERT : LA MÉTHODE DELPHI

Les méthodes basées sur le jugement d’expert peuvent être utilisées à différents moments et à différents niveaux (pour un projet entier ou pour une activité). On y recourt généralement lorsque l’on dispose de peu d’éléments. Par exemple lors d’une étude de faisabilité ou d’opportunité, le jugement d’expert peut apporter une aide à la décision de poursuivre ou non le projet.

La méthode Delphi fut élaborée en 1948 par la Rand Corporation1, pour améliorer les prévisions économiques. C’est un domaine où l’avenir est générale­ment incertain ; les avis des experts, bien que parfois divergents, apportent des éclairages précieux. Le nom Delphi fait référence à la pythie de Delphes, à qui l’on posait des questions et qui, en rendant son oracle, se faisait l’interprète de la réponse des dieux. Sa parole était donc comme celle des experts empreinte d’une grande autorité.

Cette méthode propose une démarche pour mettre en commun des juge­ments d’experts. Elle est utilisée dans différents domaines, dont l’estimation des charges d’un projet système d’information. La démarche est la suivante :

  • Dans un premier temps, chaque expert propose une estimation en utilisant sa propre expérience.
  • Dans un second temps, tous les jugements sont rendus publics, mais restent anonymes. Chaque expert peut alors modifier sa propre estimation ou la confirmer. Chacun doit bien sûr considérer que tous les autres sont également des experts, ce qui le conduit à se poser des questions si ses propres estimations sont très éloignées de celles des autres.
  • Dans un troisième temps, les nouvelles estimations sont dévoilées et chacun peut justifier son propre jugement.
  • clip_image006.gifDans un dernier temps, chacun propose une révision de son estimation. Normalement, sans que l’on arrive toujours à un consensus, les résultats sont moins divergents qu’au premier tour. Dans tous les cas, cela permet de construire en commun une première analyse du projet.

Cette méthode, utilisée notamment dans les sociétés de services, peut compor­ter différentes variantes, selon le mode de communication entre experts (oral, écrit, rapproché ou à distance...), le nombre de cycles de prévision et la conduite de la discussion (avec ou sans animateur extérieur...). Bien que forte­ment dépendante de l’expérience des experts, elle permet de dépasser la dimen­sion strictement individuelle en organisant la confrontation collective des estimations. On considère, par ailleurs, qu’elle évite que certains exercent une trop grande influence sur les autres, ce qui biaiserait le résultat.

3.5 L’ESTIMATION PAR ANALOGIE

3.5.1 La méthode de répartition proportionnelle

La méthode de répartition proportionnelle est utilisée au niveau du projet ou d’un ensemble de phases. Elle est basée sur des observations de projets antérieurs : la charge de chaque phase d’un projet devrait correspondre, avec un certain intervalle de tolérance, à un pourcentage de la charge globale. Il existe plusieurs versions qui donnent des pourcentages indicatifs, chacune s’appuie sur un cycle de vie de référence. Cette méthode est utilisée de trois façons :

  • On a fait une estimation de la charge globale du projet, que l’on cherche à répartir dans le temps.
  • On a évalué l’une des phases, au moyen d’une autre méthode, et l’on veut en déduire la charge des autres étapes.
  • On est en cours de déroulement du projet, on a observé le temps déjà consommé et on veut estimer celui des phases à venir.

L’exemple de répartition donné à la figure 3.3 fait référence au cycle RUP (§ 2.7.3) et distingue la répartition en charge et la répartition en durée. Notons qu’il est toutefois rare d’évaluer la charge de la phase de mise en œuvre au moyen d’un ratio. En effet, celle-ci comprend des activités diverses dont une partie est décrite au paragraphe traitant de la gestion du changement (5.4). Il faut donc comprendre ici la transition comme réduite à son aspect informatique de prépa­ration de l’exploitation.

Une autre répartition classique est donnée à la figure 3.4. Ces ratios sont issus d’expériences positives et négatives de projet. Ils doivent être considérés en partie comme des recommandations et en partie comme des règles. Ainsi, une étude préalable ne doit pas consommer plus de 10 % des ressources d’un projet ; ou bien on doit s’attendre à consommer deux fois plus en réalisation qu’en étude détaillée.

Figure 3.3 — Répartition d’après le cycle RUP.

Il s’agit donc moins de les appliquer de façon aveugle que de les prendre comme base, en comprenant les relations qui unissent les différentes phases.

Figure 3.4 — Répartition proportionnelle de la charge entre les phases du cycle classique.

Pour ce qui est de la charge de l’étude préalable, on utilise également une répartition proportionnelle entre les étapes (figure 3.5).

Figure 3.5 — Répartition proportionnelle entre les phases.

Par certains côtés, l’étude détaillée est la phase la plus difficile à évaluer, car il n’y a pas de relation constante entre étude préalable et étude détaillée. Deux facteurs principaux sont sources de variation : la couverture et la maille.

  • La couverture est la partie du domaine déjà étudiée par le sous-ensemble représentatif. Parfois, le nombre de variantes de traitement restant à étudier est élevé. À l’inverse, dans le cas de petits projets sans variante de procédure, étude préalable et étude détaillée sont confondues sans surcharge pour l’étude préalable.

L’utilisation des principes de l’analyse de la valeur en conception conduit à limiter la variété des procédures élaborées et à favoriser la réutilisation d’éléments de procédures déjà conçues ; ceci réduit la charge à la fois de l’étude détaillée et de la réalisation.

  • La maille d’étude mesure la précision de la description. Dans certains cas, le modèle conceptuel représentant les entités est presque complet, dans d’autres cas la structuration statique doit encore être affinée. De même les traitements peuvent-ils n’avoir été écrits que dans les grandes lignes.

La charge de l’étude technique est liée à la charge de réalisation, mais peut être augmentée par exemple en cas de particularité ou de nouveauté technique.

La charge de la phase de réalisation est liée à celle de l’étude détaillée. Le ratio Charge d’étude détaillée/charge de réalisation est basé sur l’idée qu’il y a une relation entre l’effort pour produire un cahier des charges et celui pour le réaliser. Le ratio est parfois utilisé à l’envers. On fait une estimation de la charge de réali­sation en utilisant une autre méthode et on divise par deux pour avoir la charge d’étude détaillée correspondante.

3.5.2 La méthode des ratios

La méthode des ratios est également une forme d’estimation par analogie, c’est une variante de la répartition proportionnelle qui vise la relation entre deux activités. Elle est souvent utilisée pour estimer des charges complémentaires au développement de l’application (figure 3.6). Il s’agit par exemple de l’encadre­ment du projet, de la recette et de l’élaboration de la documentation utilisateur.

Figure 3.6 — Répartition proportionnelle des charges complémentaires.

Pour ce qui est de la charge d’encadrement, le ratio est plus élevé à la phase de réalisation. En effet, classiquement, l’équipe de projet est la plus nombreuse à ce stade. La coordination assurée par le responsable augmente de façon significative.

La charge de recette dépend de la taille du logiciel. En effet, la recette est la procédure par laquelle le client maître d’ouvrage et le fournisseur maître d’œuvre constatent ensemble que le produit (logiciel) livré correspond aux spécifications.

Les utilisateurs sont souvent impliqués dans la procédure, ce qui prépare le démarrage du futur système. Les tâches de recette comprennent :

  • l’élaboration des jeux d’essai de recette, qui doivent permettre de vérifier que le système fonctionne et réagit correctement ; on bâtit de préférence des cas simulant le traitement entier d’un événement de gestion. Les jeux d’essai de recette sont destinés à faire des tests de fonctionnalité et non de volume. Ces derniers ont pour objectif de vérifier que l’application supporte bien un volume important de données et de transactions simultanées ; ils ne sont pas toujours nécessaires ;
  • la préparation de l’environnement de recette : il faut extraire des parties de bases de données réelles pour tous les objets qui ne sont pas créés par l’application ;
  • l’exécution de la recette : il faut exécuter successivement les traitements par lots et pointer les résultats ; les traitements transactionnels sont testés en présence des deux parties, client et fournisseur. Un procès-verbal est dressé.

La charge d’élaboration de la documentation utilisateur est proportionnelle à la taille du logiciel. La plupart des logiciels développés ont des aides utilisateurs intégrées pour la partie transactionnelle. Il faut néanmoins généralement livrer un guide sur papier pour l’utilisateur de l’application.

La charge de la phase de mise en œuvre ne relève pas d’une estimation stan­dard. La mise en œuvre est le passage de l’ancien système au nouveau. L’effort est souvent proportionnel au nombre et à la complexité des programmes écrits, mais les évolutions organisationnelles (rôles, responsabilités, apprentissages...) sont déter­minantes pour évaluer la charge. Si le futur système est implanté sur plusieurs sites, il faut prévoir une charge additionnelle variant avec le nombre de sites.

On applique parfois un ratio de 40 % sur la charge de réalisation, ce qui indi­que une relation de proportionnalité avec la taille du logiciel. Mais cette estima­tion est en général affinée en fonction du nombre de sites et de leurs caractéristiques techniques, organisationnelles et humaines.

De plus, elle doit être complétée par les problèmes de basculement, c’est-à­dire de passage de l’ancien système au nouveau. La charge peut notamment varier en fonction de deux critères : la complexité et le scénario.

La complexité du passage situation avant/situation après se mesure par le nombre d’anciens fichiers (entités logiques) touchés et par le degré de restructuration des informations apportée par le nouveau système. Il faut en effet assurer ce qu’on appelle la « reprise » ou la « conversion », c’est-à-dire reprendre le contenu des anciens fichiers et les convertir selon les nouvelles structures de données.

6.1 LES RISQUES DANS LES PROJETS SYSTÈME D’INFORMATION

6.1.1 L’importance des risques dans les projets système d’information

Les risques liés aux projets informatiques sont fréquents et importants.

Le Standish Group a mené en 1994 une première étude statistique sur plus de 8 000 projets informatiques de toutes tailles et dans tous les secteurs d’activité, aux États-Unis. Le résultat a été publié sur Internet sous le titre « Chaos1 ». Il en ressort qu’un tiers des projets sont abandonnés avant la fin, plus des trois quarts ont dépassé leur budget et/ou délai et près de la moitié n’ont pas complètement atteint leur objectif ! D’autres études ont confirmé le taux d’échec particulière­ment élevé des projets système d’information.

KPMG, dans une étude récente menée auprès de plus de 600 organisations dans 22 pays du globe2, constate que dans les 12 derniers mois, 49 % des organi­sations interrogées ont subi au moins un échec de projet informatique. De plus, 86 % des organisations interrogées font état d’un bénéfice réel inférieur de 25 % par rapport à celui attendu, chiffre que les analystes trouvent optimiste.

Différents exemples témoignent des difficultés rencontrées. Citons notam­ment le célèbre système Socrate de la SNCF, dont les dysfonctionnements ont été longuement commentés, ou le Plan informatique du ministère de la Justice abandonné en 1994 alors que 850 millions de francs y avaient été consacrés, qui ont donné « des résultats très médiocres », selon le rapport de la Cour des comp­tes. Le projet Taurus de liaison informatique entre tous les acteurs financiers de la place de Londres est stoppé en 1993 après dix ans d’efforts et une dépense offi­ciellement évaluée à 400 millions de livres ; un projet analogue (projet Relit) à Paris a été livré avec trois ans de retard. En 1996, le distributeur de produits pharmaceutiques Fox-Meyer a fait faillite, suite aux dépenses considérables entraînées par la tentative d’installation du progiciel intégré SAP.

Ces quelques exemples ne sont pas des cas isolés, on en retrouve dans diffé­rents pays et secteurs d’activité, dans des entreprises ou des institutions réputées par ailleurs pour leur professionnalisme. Des enquêtes récentes ont montré des améliorations1, mais des progrès restent à accomplir. Le management des risques est donc de la plus grande actualité.

6.1.2 La définition du risque

Les assureurs définissent le risque par les conséquences financières d’un événe­ment redouté et sa fréquence probable :

Risque = Coût des conséquences d’un événement ¥ fréquence de cet événement

Si, par exemple, les conséquences sont de 500 € et que l’événement a une certaine probabilité de se produire trois fois tous les 5 ans, on dira que le risque est de :

500 € ¥ 3/5 = 300 € /an

Cette définition n’est pas retenue dans le management des projets, où l’on s’attache moins à quantifier les risques qu’à en faire une analyse fine.

C’est pourquoi on préfère définir le risque comme la possibilité qu’un projet ne s’exécute pas conformément aux prévisions de dates d’achèvement, de coût et de spéci­fications, ces écarts par rapport aux prévisions étant considérés comme difficilement acceptables voire inacceptables [AFITEP, 2000].

Le PMBOK le considère comme une menace dont la concrétisation, incer­taine, aurait un impact positif ou négatif sur au moins un objectif du projet tel que les délais, le coût, le contenu ou la qualité [PMI, 2003].

Le risque prend, en général, soit la forme d’un événement (départ d’une ressource-clé, changement dans la réglementation...), soit celle d’une situation dans laquelle le projet se retrouve (parties prenantes divisées, équipe démotivée, perte de la maîtrise du contenu du projet...). La réalisation des risques peut porter sur le processus ou sur le résultat.

Dans le premier cas, il s’agit, par exemple, des cas de figure suivants : le projet n’aboutit pas ; il a consommé trop de ressources ; il a duré trop longtemps...

Dans le deuxième cas, on peut donner comme exemples : le système ne remplit pas la fonction attendue ; il n’est pas accepté par l’utilisateur ; son fonc­tionnement est trop coûteux.

6.1.3 Le management des risques

Le risque résulte de l’incertitude attachée au projet, d’imprévus ou d’aléas. L’incer­titude correspond à une « insuffisance d’information » qui empêche de prendre des décisions de façon assurée. Les imprévus sont des "événements qui n’ont pas été envisagés" [AFITEP, 2000]. notamment lors de l’analyse de risques. Les aléas sont des événements « imprévisibles » ayant des conséquences négatives sur les délais et/ ou les coûts.

Le management des risques consiste d’une part à réduire l’incertitude par une analyse plus approfondie des caractéristiques internes et environnementales du projet, d’autre part à élaborer des stratégies pour faire face aux risques les plus graves et/ou les plus probables.

L’origine des risques étant l’incertitude, celle-ci peut aussi bien apporter des éléments favorables que des éléments défavorables. Cependant, dans la plupart des cas, on va s’attacher à éliminer ou à réduire les probabilités d’apparition d’éléments négatifs et/ou à atténuer leurs conséquences possibles sur le projet.

La démarche générale de management des risques1 comprend cinq étapes :

  1. identifier les risques ;
  2. évaluer leur impact possible sur les coûts, le délai et la qualité ;
  3. définir des actions ou prendre des dispositions aptes à réduire les risques jugés inacceptables ;
  4. suivre les actions ou la mise en œuvre des dispositions, et surveiller régu­lièrement l’état des risques ;
  5. capitaliser l’expérience.

On définit parfois un rôle spécifique : le manager des risques, mais en général les responsabilités sont réparties au sein de l’équipe de projet.

Nous allons présenter le management des risques en nous focalisant sur deux aspects majeurs : l’analyse des risques (qui correspond aux étapes 1 et 2) et le contrôle des risques (qui correspond aux étapes 3 et 4). L’étape 5 sera abordée de façon plus large au chapitre 7 (paragraphe 7.6).

6.2 L’ANALYSE DES RISQUES

6.2.1 Les différentes approches d’analyse des risques

Dans le domaine des systèmes d’information, on a longtemps cru que le strict respect de dispositions méthodologiques permettrait de mener les projets avec succès. C’était mal comprendre les particularités de ces projets.

Les trois principales sources d’échec sont la définition des besoins, l’estimation des charges et la possibilité de nombreux aléas dans le déroulement du projet. En effet, la plupart du temps les objectifs sont loin d’être clairs et ce que l’on attend du futur système se clarifie progressivement ; or, parfois, au lieu de converger vers des spéci­fications de plus en plus précises, on repart sur de nouvelles pistes ; ou bien l’on se retrouve dans l’incapacité d’assembler des éléments de solution élaborés séparé­ment et d’en faire un tout cohérent et répondant à l’objectif visé. Par ailleurs, l’estimation des charges n’est pas une science exacte : les écarts de productivité individuelle peuvent être importants et de nombreux facteurs peuvent conduire à un dépassement de charge. De plus, divers événements imprévus ou imprévisibles peuvent également avoir une incidence sur le déroulement du projet.

Pour repérer et prévenir ces difficultés, différentes approches d’analyse des risques ont été proposées.

Nous allons d’abord présenter une approche généralisée d’identification des risques. Puis nous donnerons une deuxième approche basée sur une liste de risques particuliers correspondant à des caractéristiques de projet. Ensuite, nous développerons l’approche par le profil de risque du projet.

6.2.2 L’approche généralisée

Il s’agit de produire une liste de risques la plus large possible, et ensuite de sélectionner ceux qui semblent les plus sérieux.

Différentes techniques de stimulation des idées peuvent être utilisées :

  • des entretiens ou des séances de remue-méninges avec les parties prenantes du projet ;
  • la méthode Delphi, en faisant appel à des personnes expérimentées ;
  • l’analyse du projet selon une grille FFOM (forces, faiblesses, opportunités, menaces).

On peut éventuellement utiliser un diagramme cause-effet, dit d’Ishikawa, pour rechercher les sources d’un effet redouté (figure 6.1).

Figure 6.1 — Utilisation d’un diagramme cause-effet pour l’identification des risques

Ensuite, on peut classer les risques en catégories à l’aide d’une matrice, parfois appelée matrice de Pareto, selon leur probabilité d’occurrence et les impacts prévisibles sur le projet (figure 6.2).

Figure 6.2 — Matrice de probabilité/impact

6.2.3 L’approche par les types de risques recensés

Des listes de risques ont parfois été établies. Nous allons donner deux exemples de recensement raisonné de risques propres aux projets informatiques.

Le premier a été proposé par Eurométhode, dont nous présentons le cadre au chapitre 16 consacré aux associations professionnelles et aux normes. Le second résulte d’un travail mené au sein de l’AFITEP.

Eurométhode considère que les risques du projet peuvent provenir de diffé­rentes sources (figure 6.3). Dans les phases amont, les spécifications peuvent être difficiles à élaborer (système d’information) pour différentes raisons. Ensuite, on peut buter sur des obstacles dans la construction du système informatique. Diffé­rentes activités du projet peuvent être entachées d’incertitude. Les liens structurels du projet avec d’autres ou entre les parties prenantes présentent parfois des caractéristiques difficiles à gérer. Enfin la taille et la compétence de l’équipe de projet, ainsi que les caractéristiques des outils mis en œuvre dans le projet sont également des causes de difficultés.

15