Retour : Gestion du risque et gestion de projets informatiques


Gestion du risque et gestion de projets informatiques


(Url : //phortail.org/webntic/Gestion-du-risque-et-gestion-de-projets-informatiques.html)
Mise en ligne : 16 décembre 2006 par km

Définition du risque

Le risque : position prise par rapport à une situation et qui permet de dégager des économies de faire, face au pari que la situation ne se réalisera pas.

Risque projet en phase de conception

En phase de conception, le risque peut être pris de réduire non pas le périmètre fonctionnel désiré mais la traduction de ce besoin dans le SI.

Gestion d’une rolls ou d’une 2C.V.

Le risque peut être grand de vouloir concevoir les fonctions d’une rolls alors que le SI n’en a pas réellement besoin, ni les moyens.
Tout paramétrer ou tout coder.
L’analyste peut avoir le choix de traduire les besoins métiers et d’y répondre par un niveau de paramétrage très élevé (tout est paramétré) ou très sommaire.
Le paramétrage très elevé offre par exemple la souplesse de coder les regles de gestions à l’extérieur du logiciel dans des tables de paramétrage. A l’inverse le paramétrage sommaire permet de coder l’essentiel dans les programmes et de n’externaliser en paramétrage que peu d’informations.
Entre souplesse liée à un paramétrage riche et donc complexe et rigidité liée à un paramétrage sommaire, une analyse de risque permet de faire des choix et d’étudier les coûts de développement, également les coûts de paramétrage, intégration, formation maintenance.

Risque projet en phase de recette

En phase de recette, le risque peut être une approche afin de ne tester que les fonctions vitales. Il n’est pas utile de recetter de fond en comble les fonctionnalités qui ne sont utilisées qu’une fois pas an et pour deux clients, alors qu’une procédure manuelle est en place. D’un autre coté les fonctionnalités, lancées mensuellement, et qui concernent les données quotidienne du SI doivent faire l’objet de tests fonctionnels adéquats.
L’analyse du risque permet de focaliser sa recette sur les phases ou modules essentiels. L’instruction d’une telle recette, par une approche risque, est essentielle, car permet de faire des économies, comme de mettre la recette et peut-être le démarrage en péril.

Risque projet en phase de maintenance

Maintenance corrective

C’est au niveau de la correction que le risque peut-être pris. Faut il corriger tout les programmes inadéquats. Peut on corriger avec des bouts de ficelles ou en respectant l’état de l’art, un mixte des deux ?

Le SI, avec toutes les corrections qu’il subit au fil des ans, ne doit il pas être refondu avec un nouveau modèle de donnée ? Autant de questions que le développeur responsable de la maintenance ne sera pas, a priori, à même de se poser.

Maintenance évolutive

C’est par exemple la mise en conformité du logiciel par rapport à un aspect réglementaire. Le logiciel ne respecte pas tel aspect, mais il est nécessaire d’apporter les corrections.
Un audit rapide ou une revue fonctionnelle du logiciel permet de voir l’étendue des modifications à apporter.

La risque peut être évalue en coût d’opportunité à ne pas faire, soit car le risque encouru est minime, soit car ne pas être en conformité coûte peu en terme de contrainte (amende, redressement) en regard de la population concernée.

D’un autre coté l’approche de correction se portera sur une étude de la population concernée (nombre de contrats, nombre de clients, nombre d’infractions), en regard de l’estimation de la contrainte, et du chiffrage de la mise en conformité.

L’analyse du risque, dans les différentes phases d’un projet, est un élément sensible, permettant de gagner du temps, de faire des économies, face à un tout informatique qui n’a pas de sens autre que la beauté d’un SI, qu’aucun DOI ne recherche. Pour autant, le risque doit être maîtrisé, et pour ce faire, il devrait être instruit.

Auteurs : km