Vous êtes sur la page 1sur 7

LES PROJETS INFORMATIQUES ET LES RISQUES DE LEUR

REALISATION ET IMPLEMENTATION
Melnic Andreia-Simona
Universitatea “George Bacovia”, Bacău, Facultatea de Economia Afacerilor, Strada Pictor Aman, nr.
96, Bacău, andramelnic@yahoo.com, tel/ fax 0234 516448

Because informatics projects are filled with risk, effective project management demands that solid risk
management perspectives be factored into the overall management effort. For the most part, the best way
to handle risks on projects is to carry out the project effort in accordance with good general management
practice. Thus, you should plan well, monitor the team’s performance carefully, communicate clearly, treat
your employes with respect, and so forth.
Keywords: informatic project, risk, management risk

Les risques apparaissent dans le cadre de toutes les activités socio-économiques, pour chaque d’entre eux
ayant des formes particulières, en fonction de leur type, mode de manifestation et intensité. Le risque
représente l’incertitude de l’apparition d’un phénomène qui, dans les conditions qu’il se produit, a un effet
positif ou négatif sur les objectifs d’un projet. Le risque exprime l’impact direct d’un événement dans le
futur sur les projets actuels et il exprime le degré d’écartement des objectifs proposés, des standards
proposés. Toutes les activités supposent connaître les risques et les assumer. Pour avoir du succès il est
nécessaire d’identifier tous les risques possibles, leur quantification, assumer les responsabilités tout au
long du déroulement de l’activité.
Le projet informatique représente un cas particulier du concept du projet. Pour tout projet il doit exister un
support financier propre pour permettre la mobilisation des ressources nécessaires à aboutir les buts
(ressources humaines, matérielles, informationnelles, informatiques). Pour chaque projet il doit exister une
équipe de gestion du projet, avec un gestionnaire du projet qui soit capable d’orienter ses actions selon les
fonctions de la gestion traditionnelle (planifier, organiser, diriger/coordonner, contrôler). Dans la mesure
dans laquelle il s’agit des actions spécifiques au domaine informatique d’une organisation, c’est a dire:
l’informatisation d’une fonction à l’intérieur, la modernisation d’un investissement informatique plus vieux
ou des activités qui ont comme but la réorganisation des procès du domaine informatique, nous pouvons
dire que le projet qui les réunit est un projet informatique.
Ce qui sépare le risque de projet d’autres types de risques est le fait que nous avons déjà une idée sur les
types des problèmes que les équipes engagées dans le projet puissent les rencontrer. Nous savons qu’il y
aura des sources prévisibles des problèmes organisationnels, des efforts inévitables pour gérer les besoins
et les demandes et des problèmes liés à la planification et le contrôle inadéquat. Nous savons aussi qu’une
source importante des problèmes peut être une estimation inadéquate. Ces problèmes sont universels et ils
tiennent de la nature des projets et leur gestion. Si on comprend les sources des risques du projet, la
possibilité que des événements défavorables pourraient apparaître, peut être réduite, et d’ici même leurs
effets. Parce que une grande partie des risques sont liés des problèmes organisationnels, l’attention devrait
être concertée sur l’identification de ces problèmes et sur le développement d’une stratégie pour leur
gestion. Par exemple, l’expérience nous montre qu’au moment où des ressources empruntées sont utilisées,
les gestionnaires rencontrent des difficultés dans leurs propres convictions de s’engager dans des efforts,
d’être plus responsables envers leur mission, envers le projet. Ainsi, ils rencontrent un risque prévisible -
celui dans lequel les membres de l’équipe du projet ne donnent pas toute leur attention au projet. C’est une
réalité inévitable et ils devraient développer plus d’acharnement par rapport au projet. Certaines techniques
de former une équipe, employées par les administrateurs s’appuient sur les systèmes de récompense et
l’utilisation d’une puissante note personnelle dans le travail avec les membres de l’équipe. Alors quand on
travaille avec des ressources empruntées on rencontre les risques d’un engagement réduit des efforts de
l’équipe. Pour tenir tête à ce risque, on doit s’impliquer pour parcourir certaines étapes explicites pour
développer l’engagement de l’équipe. La même logique s’applique / est valable pour deux domaines de
problèmes prévisibles du projet: la gestion des besoins et des demandes et la planification et le contrôle
adéquat. Par exemple, un problème besoins - demandes qui peut affecter tout le projet est celui de
l’ajustement, cet état où les nécessités se change pour se plier avec les échanges dans la demande qui vient
1435
de la part des clients, des managers et des membres de l’équipe du projet. Le résultat cumulatif de ces petits
changements peut être destructif. Cependant il est possible d’apparaître des dépassements des coûts et des
dérèglements dans le programme établit parce que le projet abandonne ses coûts et son plan initial. La
prédilection pour ajuster ou changer est universelle. La meilleure méthode pour tenir tête aux risques est
d’établir des puissants processus de contrôle du changement et de les appliquer dans le projet.
Le risque de rencontrer des problèmes à cause de la mauvaise planification ou contrôle peut être administré
par s’assurant que tous les projets suivent des principes efficaces en ce qui concerne la planification et le
contrôle doit utiliser des instruments adéquats. En dehors de ça, les membres de l’équipe doivent connaître
ces principes et instruments et doivent les utiliser constamment. Si les principes concernant le contrôle et la
planification sont bien utilisés, alors les problèmes produits par une mauvaise planification se réduisent
beaucoup.
La meilleure méthode pour administrer le risque du projet est de suivre les procédures standardisées de la
gestion des risques. Il faut planifier les efforts de la gestion des risques, identifier les risques, faire des
analyses qualitatives et quantitatives sur l’impact du risque, établir des stratégies de la gestion des risques
et surveiller et en même temps contrôler les risques dès le début du projet.
La gestion des risques comprend les méthodes et les moyens par lesquels l’incertitude peut être contrôlée
comme important support des facteurs du risque, ayant comme but l’acquisition des objectifs exprimés
dans le cadre du projet. La gestion du risque ne doit pas être regardé d’une seule perspective dans le
chapitre composant la gestion globale d’un projet, à cause de sa complexité, elle étant située dans la
catégorie des sciences de frontière qui nécessitent généralement la corroboration des informations des
plusieurs domaines: économiques, techniques, juridiques, statistiques et psychologiques. La gestion des
risques dans le projet informatique est un processus cyclique ayant plusieurs étapes distinctes:
a) L’identification du risque, c'est-à-dire chercher et localiser les risques avant qu’ils se manifestent.
Pour chaque risque identifié on rédige un plan de risque.
L’identification des risques associés à un projet informatique se réalise en utilisant plusieurs techniques: la
réalisation d’une liste avec des risques possibles, la réalisation d’un profil de risque, établir des risques
selon des expériences précédentes, comparer les risques avec ceux survenus dans le cadre des projets
similaires, établir les risques qui puissent se manifester au cours du déroulement de l’activité et établir le
budget.
La réalisation d’une liste avec des risques possibles est nécessaire pour consulter toutes les personnes
impliquées dans le déroulement du projet sur les facteurs qui puissent contribuer directement ou
indirectement à influencer d’une manière négative les activités ou les résultats des propos pour le
financement, les modalités principales de leur constitution étant les réunions de brainstorming, les
interviews et les questionnaires.
L’utilisation du profil de risque est utile en général dans le cas où les gestionnaires peuvent utiliser leur
expérience accumulée dans le cadre des projets précédents, pour identifier les facteurs de risque spécifiques
qui se retrouvent dans la nouvelle structure du projet, en réalisant une questionnaire qui s’adresse aux
principales zones d’incertitude existantes dans le cadre du projet: l’équipe du projet, les clients et la
technologie utilisée.
L’un des plus importants facteurs de prédiction pour les activités futures est d’employer l’expérience
acquise dans le déroulement des projets antérieures, un bon gestionnaire de risque ayant la possibilité de
s’en tirer des conclusions après avoir analysé les facteurs de risque qui ont été rencontrés avant.
La gestion de risque contribue à illustrer les activités planifiées ayant une opportunité d’identifier les
risques. Pour réaliser cette analyse en détail pour chaque activité composante, il est nécessaire de réaliser
une planification et une estimation du budget qui dans la plupart des situations est difficile à rédiger à
cause des facteurs d’incertitude.
Dans l’étape de l’identification du risque on mesure les potentiels dangers, les effets et les probabilités de
leur apparition pour décider quel risque doit être prévenu. Le processus d’identification des risques est
régulier et il doit tenir compte aussi des risques internes, que de ceux qui viennent de l’extérieur.
Les risques internes sont ceux qui apparaissent à la suite de l’activité organisationnelle et ils peuvent être
contrôlés par les gestionnaires par un règlement des activités. Les risques externes sont ceux qui ne
tiennent pas de l’activité de l’organisation, mais ils peuvent l’influencer. Ces risques ne peuvent pas être

1436
contrôlés par l’équipe de gestion, mais ils peuvent être connus, analysés et on peut prendre une décision
pour minimaliser leurs effets ou même les éliminer.
Les risques internes d’une organisation peuvent être :
• Des risques dans le processus de la production (accident de travail, arrête de la production etc.);
• Des risques dans le processus de gestion (implémentation d’une décision, l’utilisation des certains
sources de financement);
• Des risques informationnels (inefficacité du système informationnel, l’utilisation des informations
incorrectes etc.).
Dans la catégorie des risques extérieurs on peut distinguer:
• Des risques législatifs (l’apparition d’une législation défavorable à l’organisation);
• Des risques survenus à la suite des modifications de milieu économique (modifications des intérêts,
inflation, monnaies d’échange etc.);
• Des risques technologiques à cause de l’apparition d’une technologie qui peut avoir des erreurs de
projection (l’apparition d’un virus);
• Des risques causés par la relation avec les syndicats (le risque de grève).
L’identification des risques de l’extérieur de l’organisation peut se réalisé par designer une personne
capable de participer à des réunions des associations professionnelles, à des conférences et qui puissent
suivre les publications dans le domaine, personne qui doit être continuellement informer sur les
modifications de milieu et des éventuelles apparitions des risques nouveaux.
b) L’analyse du risque signifie la transformation des données qui font référence au risque dans des
informations pour pouvoir prendre une décision. Cette étape comprend :
• Des analyses préliminaires: identifient les risques qui puissent intervenir dans le déroulement d’un
projet ou d’une activité;
• Estimations du risque: calculent la probabilité de l’apparition d’un risque;
• Evaluation du risque: établie l’impact qu’un phénomène de risque peut l’avoir sur le projet ou sur une
autre activité;
• Le control du risque: assure la correction des écarts de la planification du risque.
c) La réaction au risque et sa surveillance a comme but les stratégies suivantes:
• L’acceptation du risque regarde la modalité dans laquelle le gestionnaire d’un projet comprend le
risque, sa probabilité de se réaliser, les conséquences estimées qui en apparaissent et la décision de ne
pas actionner pour son écartement. Une telle stratégie est utilisée d’habitude, alors quand la probabilité
d’apparition d’une catégorie des risques est très petite et /ou les conséquences sur le projet ne sont pas
signifiantes.
• Eviter les risques représente une stratégie utilisé dans des certains conditions pour minimiser les
risques. La réduction des risques ne signifie pas éviter s’assumer des décisions de gestion ou
l’exclusion du risque dans le cadre du projet. Cette stratégie est utilisée en général dans la situation du
changement du but ou quand on annule une partie du projet;
• La diminution du risque représente un assemble des actions qui essaient de minimiser les effets
produits par l’apparition du risque jusqu'à son encadrement dans des limites acceptables pour les
gestionnaires du projet: la planification des activités, apprendre le personnel, ré projeter les activités;
• La répartition des risques est un instrument pour que les parties acceptent soit une part ou la
responsabilité entière en ce qui concerne les conséquences du risque. Ce processus est un transfert du
risque à une autre institution spécialisé pour assurer des compétences supérieures pour gérer et
contrôler le risque. Il y a des modalités de transfert indirect des risques, comme par exemple
l’embauchage d’un expert dans le cadre du projet pour évaluer ou surveiller le développement des
certaines activités, représentant aussi une forme de transfert du risque vers une autre personne que le
responsable du projet. On peut aussi utiliser dans le cadre du projet le contrat de service comme un
autre forme de transfert du risque. Ainsi, le risque technologique est transféré à la compagnie qui
assure contre remboursement des services pour le bon fonctionnement du système tout entier. Un
chapitre important dans la gestion du risque est constitué par les coûts remboursables. Ceux-ci se
1437
réfèrent aux payements de quelques travaux sous - contractés par d’autres sociétés commerciales ou
des matériaux utilisés dans le cadre du projet;
• La surveillance assure le renseignement continu sur les facteurs de risque;
• La feedback assure le transfert des informations dans le cas où le risque apparaît pour diminuer ses
effets.
Les questions auxquelles un gestionnaire doit répondre sont les suivantes:
• Quels sont les risques pour le projet;
• Quelles sont les pertes dans le projet rapportées au total des coûts;
• Quelles sont les pertes assumées du projet;
• Quelle est la gravité des pertes dans la situation où les prévisions les plus pessimistes pourraient
devenir réalité;
• Quelles sont les alternatives pour dépasser la situation de crise;
• Comment peut on éliminer ou réduire les pertes;
• Les alternatives décisionnelles acceptées conduiront-elles vers la supposition des risques plus grands ?
A la suite des réponses enregistrées aux toutes ces questions, on peut identifier dans une première forme les
principaux risques qui puissent conduire vers un échec ou vers des situations critiques. En réalisant une
analyse globale, les gestionnaires peuvent définir dans une forme primaire leur stratégie d’actionner dans le
cadre du projet. Le gestionnaire du projet va s’assumer seulement la partie des risques majeures, capable de
conduire à ne pas réaliser l’objectif du projet.
Le manager du projet, même s’il possède des qualités spéciales, il ne sera capable d’identifier tous les
facteurs de risque existants dans un projet et d’ici résultera son impossibilité de le gérer. Il est nécessaire
d’apercevoir et d’administrer les principaux facteurs de risque capables de conduire à la perturbation de la
finalisation des objectifs du projet, ou même à son échec. Pour pouvoir décider quels sont les facteurs du
risque majeur acceptables dans la sphère du normal, il faudra une connaissance a priori de ces facteurs et
de la gravité des conséquences.
Une source majeure du risque des projets informatique est liée des difficultés de pouvoir gérer les besoins
et les demandes. Si les besoins n’ont pas été identifiés correctement et si les demandes ne captent pas les
nécessités réelles, alors le projet est destiné à l’échec parce que ses résultats ne vont pas correspondre aux
besoins et aux désirs des consommateurs. Une gestion adéquate des besoins et des demandes est une
condition nécessaire pour le succès d’un projet.
Les problèmes commencent avec les essais d’identifier les besoins. Une difficulté assez souvent rencontré
est l’identification des consommateurs. Les utilisateurs sont les consommateurs, ils sont ceux qui
travailleront avec les résultats, les biens fournis par l’équipe du projet et leur satisfaction est importante.
Mais l’identification des besoins des consommateurs peut être difficile parce que les utilisateurs n’ont pas
une vision monolithique sur leurs besoins.
Un autre problème est la création d’une liaison entre les affaires et les solutions techniques nécessaires
pour s’adresser aux besoins. Le problème surgit au moment où les membres de l’équipe technique ont des
faibles connaissances sur l’affaire, et cependant les personnes impliquées dans le projet ne comprennent
pas la technologie nécessaire pour l’implémentation de leurs produits.
Si de point de vue formel il est important d’identifier les éléments de risque majeur, au niveau pratique,
une importance similaire doit être accordée à l’identification des solutions concrètes pour réduire et effacer
ces facteurs. De telles mesures peuvent être:
• L’identification des zones de risque et de leurs components pour chaque zone;
• La structuration des facteurs de risque impliques;
• La gestion optimale des ressources propres;
• L’identification et l’analyse des alternatives possibles pour réduire les facteurs de risque;
• La sélection des meilleures alternatives pour chaque facteur de risque;
• Obtenir un feed-back pour identifier les actions de succès.

1438
L’un des plus importants aspects pour le manager du projet est la délimitation exacte des zones de risque.
Les principales zones de risque, liés aux projets informatiques concernent la projection, les données, les
coûts et le domaine d’opération des systèmes.
Le projet informatique peut être incompatible avec la structure, la culture et les objectifs organisationnels.
Les risques existent si le projet n’ait pas en vue que les besoins courants, sans être flexible aux besoins
futures de l’organisation.
Les données utilisées peuvent avoir un haut niveau d’imprécision ou inconsistance. Les informations
peuvent être erronées, équivoques ou présentées aux utilisateurs dans une manière inadéquate.
Les coûts du projet informatique peuvent, dans certains cas, dépasser les budgets établis initiaux; les frais
afférents ne peuvent pas être justifiés par la valeur que le projet l’apporte à l’entreprise.
Les informations ne sont pas fournit très vite pour être utiles, peuvent être dans un format impossible à
comprendre ou à utiliser ou contiennent des données incorrectes.
On a identifié trois dimensions qui peuvent influencer le niveau du risque: la grandeur du projet, sa
structure et son niveau technologique.
Les projets grands sont plus instables que les projets petits.
Les projets ayant des structures plus compliquées sont plus risquant que ceux pour des petites unités. Les
projets moins structurés s’appuient sur une implication signifiante des utilisateurs dans toutes les étapes de
leur réalisation.
Dans le cas des projets informatiques avec un haut degré de risque technologique, les membres de l’équipe
doivent avoir une expérience technologique plus solide et participer à l’établissement des objectifs et des
termes pour les réaliser. Le risque du projet va accroître si l’équipe qui établie le projet et les spécialistes
ont une manque d’expérience technique. Si l’équipe n’est pas familiarisée avec les équipements, le soft de
système, le soft d’applications ou le système de gérer les dates pour le projet, alors le risque peut accroître
considérablement. Dans la sélection du personnel engagé au projet il est nécessaire d’appliquer le principe
d’utiliser les personnes compétentes et non pas ceux disponibles. Les risques peuvent apparaître dans
toutes les phases de réalisation du projet informatique.
Les risques peuvent se manifester dans toutes les phases d’un projet informatique.
Dans la phase d’analyse du projet peut apparaître une série de risques déterminés par les aspects suivants:
• On n’a pas accordé des suffisants ressources, temps et argent pour étudier le problème; les objectifs
sont vagues;
• On n’a pas réservé le temps nécessaire pour une planification préliminaire; les standards n’existent
pas;
• Les demandes informationnelles sont obtenues à la suite d’une documentation faible, les utilisateurs
refusent s’impliquer a coté de l’équipe du projet, pour établir les demandes informationnelles;
• Le personnel du projet n’est pas bien sélectionné;
• Les spécialistes en informatique promettent des résultats impossibles à atteindre;
• Les analystes du projet ne peuvent pas interviewer les utilisateurs dans une manière adéquate.
Des risques peuvent apparaître dans l’étape de projection aussi: les spécifications fonctionnelles ont une
documentation inadéquate ou le projet n’est pas flexible aux besoins futures de l’organisation. Si les
utilisateurs finals ne sont pas impliqués dans l’équipe de réalisation du projet, il est possible que le projet
ne corresponde pas à la structure, aux activités, à la culture de l’organisation et aux priorités du
management.
Si le projet informatique concerne la réalisation d’un logiciel, les risques peuvent sortir dans l’étape de
programmation, c'est-à-dire le temps et l’argent nécessaires pour la réalisation du projet sont insuffisants,
les programmateurs ne reçoivent pas des spécifications complètes ou ne bénéficient pas de l’avantage des
technologies orientés objecte ou de celles de planification structurée.
Dans l’étape des tests pour le produit obtenu, les risques peuvent surgir parce que l’équipe n’a pas réalisé
un plan des tests correspondant, le temps et l’argent nécessaires pour la réalisation des tests sont sous-
estimés, le management ne fait pas la révision et n’accepte pas les résultats des tests ou les utilisateurs ne
sont pas assez impliqués dans les opérations des tests.

1439
Au cas où il s’agit de la réorganisation ou la modernisation d’une fonction informatique; il peut se dégager
des activités de conversion même, des conversions de données spécialement. En ce cas on peut surgir des
risques au sujet de l’allocation des fonds, ou sommes d’argent insuffisantes pour soutenir ces opérations.
De même, si la maintenance est inadéquate, il y a moins de personnes instruites pour assurer la
maintenance du produit obtenu ou pour tenir tête aux changements nécessaires.
En présent l’accent ne se met plus sur l’écriture du code, mais sur les étapes qui précèdent ou qui suivent
l’écriture de code. La qualité d’une application réside dans la qualité de la technologie des spécifications,
de l’analyse du projet et de son projection, de contrôle, documentation et de la manière de le dirigé.
L’habilité de collecter des spécifications de plus en plus complètes des clients, et en même temps de
déterminer le client voir la fonctionnalité du futur produit, va se refléter dans la satisfaction ultérieure du
client envers le produit. L’analyse et la projection sont considérées aujourd’hui les étapes clés d’un projet
et elles devraient couvrir 40% de la durée totale du projet. Pour cela on a développé des méthodologies
d’analyse RAD (Rapid Application Developement) ou OO (Object-Oriented) et des instruments CASE
(Computer Aided Software Developement).
Les risques pour réaliser des projets informatiques sont liés aussi de la partie financière. Pour calculer
correctement le budget d’un projet, il est important que chaque partenaire connaisse la somme qui doit être
investie pour le financement correct du projet. Le principe fondamental qui se trouve à la base d’une
décision de financement est de trouver les heureuses combinaisons entre la source de financement et la
modalité d’utiliser l’argent.

Degré de risque Le type de projet


Bas Une expansion d’échelle Le même produit et le même
Des produits fortement associés marché
La même clientèle
Des connaissances en ce qui
concerne la technologie existante
Moyen Expansion d’échelle Produit nouveau ou marché
Canal de distribution différent nouveau
Clientèle différente
Technologie vérifiée, mais pas
aucune expérience ou
connaissance dans la technologie
respective
Grand Projet de recherche- Produit nouveau ou marché
développement nouveau
Dépendance de la technologie non
vérifiée dans la pratique
Table no.1. Classification des projets en fonction du degré de risque financière
Le succès d’un projet dépend dans une grande mesure des options qu’un manager les fait au moment où il
adopte des décisions qui concernent les risques que celui-ci soit disposé d’accepter.

1440
Conclusions
Dans le cas de chaque projet informatique il faut qu’on ait de l’intuition pour prévoir les hypothèses
concernant le futur, tout en analysant le milieu interne et celui externe de l’implémentation. Après avoir
identifier les hypothèses on va évaluer le risque associer à chaque activité. Le risque signifie la probabilité
d’apparition d’un obstacle qui va bloquer le succès de l’activité. Une activité qui a une grande probabilité
d’échouer est soumise à un grand risque. Les types de risque auxquels sont soumis les projets sont: les
défections techniques, l’insuccès sur le marché, les difficultés de réalisation, l’impossibilité de les finalisé à
temps, ne pas finaliser le plan de recherche, une évolution inattendue, des chutes dans la projection ou dans
la fabrication, des obstacles techniques insurmontables, des résultats imprévisibles, des incertitudes
normatives et législatives, des événements imprévisibles, un know-how inadéquat.
Un bon gestionnaire de projet doit connaître et gérer les facteurs critiques qui puissent transformer le projet
dans un succès: relations de collaboration étroite entre les membres de l’équipe de projet, clients et gestion,
plan du projet et la direction à suivre, des responsabilités claires et indicateurs spécifiques pour mesurer le
progrès dans l’exécution du projet, communication constante et efficace entre tous ceux impliqués dans le
projet, le contrôle des compétences.

Bibliographie
1. Davidson Frame, J., Managing risk in organization, Jossey-Bass, San Francisco, 2003
2. Opran C. (coord.), Managementul proiectelor, Note de curs, Editura comunicare.ro, Bucureúti,
2002
3. Oprea, D., Managementul proiectelor, Teorie úi cazuri practice, Editura Sedcom Libris, Iaúi, 2001

1441