Vous êtes sur la page 1sur 9

Gestion du risque des projets SI

Gestion du risque des projets SI

Faculté
Faculté d'économie et de management

Département
Services généraux GSEM

Professeur(s)
Jolita Ralyte[1]

Cours
Gestion de projet

Lectures

Sommaire
 1 Gestion du risque
 2 Définitions du risque
 3 Démarche de gestion du risque
o 3.1 Principaux facteurs de risque
 3.1.1 La taille du projet
 3.1.2 La difficulté technique
 3.1.3 Le degré d'intégration
 3.1.4 La configuration organisationnelle
 3.1.5 Le changement
 3.1.6 L'instabilité de l'équipe de projet
o 3.2 Évaluation du degré de risque
 4 Les stratégies de gestion du risque
 5 Solutions pour chaque facteur
o 5.1 La taille du projet
o 5.2 La difficulté technique
o 5.3 Le degré d'intégration
o 5.4 La configuration organisationnelle
o 5.5 Le changement
o 5.6 L'instabilité de l'équipe de projet
 6 Conclusion
o 6.1 Le top 10 des facteurs de risque
 7 Annexes
 8 Références

Gestion du risque[modifier | modifier le wikicode]


La gestion du risque est d'une importance primordiale dans le
développement des SI. C'est un ensemble des principes et des pratiques
ayant comme objectif identifier, analyser, et traiter les facteurs de
risque afin d'améliorer les chances d'obtenir avec succès le résultat
attendu du projet.
 Avant le projet : identification et évaluation du risque
 Pendant le projet : suivi et contrôle du risque
 Après le projet : capitalisation de l'expérience
Exemples de risque dans les projets SI
 Le projet ne débouche pas sur un résultat attendu
 Le projet consomme trop de ressources
 Le projet dure trop longtemps
 Le système ne remplit pas la fonction attendue
 Les utilisateurs n'acceptent pas le système
 Le fonctionnement du système est trop coûteux
"Le taux élevé d'échec s'explique par le fait que les gestionnaires ne
prennent pas des mesures afin d'évaluer et de gérer les risques impliqués
dans le projet" (Keil et al., 1998)
"Les post-mortem des projets échoués indiquent que les problèmes
auraient pu être évités s'il y avait eu une identification et une résolution
rapide des éléments à hauts risques." (Boehm, 1991)
La gestion du risque permet d'éviter le désastre ainsi que le travail
superflu, de régler et équilibrer les efforts et de stimuler les situations
"win-win".
La plupart des projets SI sont à l'origine des changements
organisationnels. Leur succès peut donc être crucial pour la réalisation des
objectifs économiques de l'organisation.

Définitions du risque[modifier | modifier le
wikicode]

Le risque est une exposition aux facteurs spécifiques qui présentent une


menace pour obtenir les résultats attendus du projet. (Bannerman, 2008)
C'est une mesure de la probabilité et de l'impact de non réalisation de
l'objectif du projet.
 R=PxI
R = exposition à un facteur particulier du risque. P = probabilité qu'un
événement indésirable arrive. I = impact ou ampleur des pertes si
l'événement arrive.
Selon la définition probabilistique :
 tous les facteurs potentiels du risque doivent être identifiés au début
du projet
 l'exposition au risque est estimée pour chaque facteur
 les facteurs sont classés en fonction de leur priorité afin d'identifier
les facteurs les plus menaçants
 focalisation sur les facteurs à haut risque pour minimiser leur
probabilité d'occurrence ou l'ampleur de leur impact
Limitations de la définition probabilistique :
 il est difficile d'estimer la probabilité et l'impact de plusieurs facteurs
 il est plus facile d'évaluer le risque sur une échelle simple (ex. : bas,
moyen, haut) que de calculer sa probabilité
 couplage fort entre l'événement et les conséquences du risque sans
prendre en considération la vulnérabilité et les capacités de
l'organisation à répondre à la menace
 la définition n'inclut que les menaces connues

Démarche de gestion du
risque[modifier | modifier le wikicode]
 Identifier les risques -> facteurs de risque
 Évaluer l'impact des risques sur les coûts, le délai, et la
qualité -> profil du risque, matrice de probabilité/impact
 Identifier et mettre en place les actions aptes à réduire les
risques inacceptables -> stratégies de gestion du risque
 Suivre les actions et contrôler l'état des risques
 Capitaliser l'expérience

Principaux facteurs de risque[modifier|modifier le


wikicode]

 La taille du projet
 La difficulté technique
 Le degré d'intégration
 La configuration organisationnelle
 Le changement
 L'instabilité de l'équipe de projet

La taille du projet[modifier | modifier le wikicode]

 Le risque est lié aux limites de l'individu


o Un grand projet signifie une large étendue du domaine couvert
et impose un partage du travail entre un nombre important de
personnes
 Il est difficile à gérer le processus de la production et l'intégration
des travaux de plusieurs équipes
Critères
 Durée du projet (en mois)
 Charge du projet (en mois/personne)
 Couverture fonctionnelle (nombre de processus)
Facteur Degré

Durée du projet 1

Charge du projet 1

Couverture fonctionnelle 1

La difficulté technique[modifier | modifier le wikicode]

 Le risque correspond à une nouveauté technologique ou une


difficulté technique provenant des contraintes imposées au projet.
o Ex. : contraintes de performance, de langage,
d'architecture, ...
 Le risque est l'absence de compétences techniques nécessaires, qui
pénalise la production
Critères
 Expérience de l'entreprise sur les techniques à utiliser (nombre de
projets)
o Expérience sur l'architecture, le langage de programmation, le
SGBD
 Expérience du marché sur les techniques à utiliser (nombre de
références)
o Expérience sur l'architecture, le langage de programmation, le
SGBD
 Contrainte de performance (de 0 à très élevée)
 Responsabilité de la direction informatique (degré de responsabilité)

Le degré d'intégration[modifier | modifier le wikicode]

 Le degré d'intégration mesure le degré de dépendance ou


d'autonomie du futur SI
o Plus le SI en construction doit collaborer avec d'autres
systèmes de l'entreprise, plus il est difficile d'identifier clairement
l'impact de choix de conception
o D'autres entités, d'autres équipes, d'autres projets de
développement peuvent être concernés, ce qui augmente le
nombre d'acteurs du projet
Critères
 Nombre de flux avec des applications connexes
 Nombre d'applications connexes en évolution

La configuration organisationnelle[modifier | modifier le
wikicode]

 Ce facteur correspond à l'étendue de l'entreprise qui est touchée par


le projet
o Le risque provient de la lourdeur des procédures de
participation et de décision quand plusieurs grandes entités de
l'entreprise (les directions) sont parties prenantes du projet. La
production en est ralentie.
 Éventuels conflits politiques et organisationnels peuvent bloquer les
prises de décision et ralentir le processus de développement
Critères
 Nombre de directions assurant la MOA
 Existence et implication d'un sponsor
 Pérennité du sponsor
 Appui de la direction générale

Le changement[modifier | modifier le wikicode]

 Le risque de mauvaise définition du futur système à cause d'un


changement métier ou organisationnel
o Le changement visé par le projet signifie que le système de
gestion et/ou d'organisation existants ne peuvent pas être pris
comme référence stable et que l'effort de conception et
d'innovation va être important.
Critères
 Degré d'évolution organisationnelle (écart par rapport à l'existant)
 Degré d'évolution fonctionnelle (écart par rapport à l'existant)
 Degré d'évolution technique (écart par rapport à l'existant)
 Impact social (conséquences sur effectif et salaire)
 Nombre de sites concernés

L'instabilité de l'équipe de projet[modifier | modifier le


wikicode]

 Le risque est lié au départ de certains membres de


l'équipe durant le projet
o Problème du transfert de connaissances : les concepteurs
engrangent un ensemble de connaissances implicites sur le projet
et son domaine que des modèles formalisés ne suffissent pas à
transmettre
o Risque de mauvaise interprétation de la conception faite par
d'autres personnes, ce qui peut avoir des conséquences sur les
délais et la cohérence de la réalisation.
Critères
 Durée du projet (en mois
 Sous-traitance de MOA (en %)
 Mobilité dans l'entreprise (degré)
 Relation MOA - MOE (niveau de relations)
 Techniques attrayantes (niveau d'attractivité)
 Marché de l'emploi (niveau de difficulté)
 Image du projet (degré de valorisation)

Évaluation du degré de risque[modifier|modifier le


wikicode]

Le degré de risque de chaque facteur est calculé avec la formule :


Degré de risque d'un facteur = Somme (degré de chaque
critère*pondération) / somme des pondérations.
Une pondération peut être définie pour majorer l'importance d'un critère
dans le facteur étudié.
Le profil du risque permet ainsi de faire apparaître les risques majeurs qui
présentent un degré élevé (si la moyenne des risques dépasse 3 sur 4,
l'échec est inévitable).

Les stratégies de gestion du


risque[modifier | modifier le wikicode]
 Fuite
Recherche des moyens pour éviter l'effet négatif du risque sur le
projet.
Exemple : modification de la solution conceptuelle du projet - élimination
ou modification de certaines fonctionnalités et/ou propriétés.
 Transfert
Déplacement de la responsabilité du risque à un tiers; n'élimine pas
la menace mais délègue la responsabilité de sa gestion à quelqu'un
d'autre.
Exemple : assurance, contrat de sous-traitance, outsourcing.
 Mitigation
Réduction de la menace en réduisant la probabilité et/ou l'impact du
risque.
Exemple : amélioration de la participation des utilisateurs, formation des
développeurs, choix des méthodes, etc.
 Acceptation passive ou active
Passive : quand la menace n'est pas importante et/ou la source du risque
est externe au projet.
Active : quand la menace est réelle mais qu'il n'y a rien à faire avant son
apparition; un plan de contingence peut être prévu.
Exemple : budget et/ou ressources supplémentaires, plan d'action, etc.

Solutions pour chaque


facteur[modifier | modifier le wikicode]
La taille du projet[modifier|modifier le wikicode]
 Découper le projet en sous-projets
 Choisir un modèle de développement évolutif et incrémental.
Exemple : le modèle de la Spirale où chaque cycle permet l'analyse
du risque et la redéfinition des objectifs.
 Choisir un dispositif de coordination formel pour gérer l'avancement
d'une équipe importante

La difficulté technique[modifier|modifier le wikicode]


 Différer l'introduction d'une ou plusieurs innovations
 Rechercher les compétences nécessaires
 Si les besoins sont stables, le risque majeur est lié à la
programmation, alors les modèles de
type Cascade ou RAD permettent de se focaliser sur la
programmation
 Sinon, choisir le modèle en W qui insiste sur les tests
systématiques

Le degré d'intégration[modifier|modifier le wikicode]


 Intégrer dans le projet les acteurs qui connaissent bien les autres
systèmes avec lesquels le SI doit s'intégrer
 Les modèles en V et W facilitent l'intégration modulaire

La configuration organisationnelle[modifier|
modifier le wikicode]

 Limiter le champ de participation de chaque membre exécutif


 Privilégier le développement évolutif et incrémental

Le changement[modifier|modifier le wikicode]
 Réduire l'incertitude en modifiant le champ du projet ou ses
caractéristiques
 Intégrer des acteurs qui ont le pouvoir de prendre les décisions
stratégiques
 Utiliser les techniques facilitant la créativité et l'exploration
 Les modèles de développement évolutif et RUP permettent de
gérer les besoins qui s'éclaircissent en cours du projet.

L'instabilité de l'équipe de projet[modifier|modifier


le wikicode]

 Obliger la documentation détaillée de chaque produit et activité du


projet - un système d'information sur le futur système (documentation
du projet)
 Superviser les personnes à risque, ce qui favorise la transmission
des connaissances

Conclusion[modifier | modifier le wikicode]
 La gestion du risque s'attaque en premier lieu aux facteurs
humains et non techniques : il n'y a pas de recette miracle, il faut
avant tout beaucoup de jugement.
(Boehm, 1991)
 La gestion du risque doit devenir une part entière de la
méthodologie de développement et non pas une activité
séparée
(Kwak & Stoddard, 2002)
 Implantation progressive dans les organisations
(Boehm, 1991)

Le top 10 des facteurs de risque[modifier|modifier le


wikicode]
Selon Boehm, 1991 :
 Manque de personnel compétent
 Budgets et échéances irréalistes
 Mauvaises fonctionnalités développées
 Mauvaise interface développée
 Gold plating (addition de plus de fonctionnalités/propriétés que ce
qu'il est nécessaire)
 Demandes de changement continuelles
 Pénurie de composantes acquises à l'externe
 Problèmes au niveau des tâches confiées à l'externe
 Problèmes de performance en temps réel
 Limite des capacités informatiques

Annexes[modifier | modifier le wikicode]
Références[modifier | modifier le wikicode]
1. ↑ Page personnelle de Jolita Ralyte sur le site du CUI
 La dernière modification de cette page a été faite le 10 août 2018 à 17:56.
 Le contenu est disponible sous licence Creative Commons Attribution-ShareAlike sauf
mention contraire.
 Politique de confidentialité
 À propos de Baripedia
 Avertissements
 Hosted by Infomaniak