Audit de projets informatiques

dossier :
Management
de projets
Audit de projets informatiques
Daniel Mahé,
Manager ASK Conseil
Daniel Mahé est un expert du
pilotage de projet. Il a participé
aux travaux européens en prélude
à la rédaction de Riskman sur la
prévention des risques projet dans
les années 1990. En 2002-2003,
Daniel Mahé a animé un groupe
de travail * sur le thème " audit des
projets informatiques ". Nous résumons ci-dessous certains des
aspects essentiels de la publication
qui a couronné les travaux du
groupe.
Lors d’un récent petit-déjeuner organisé par l’AFAI et 01 Informatique sur
ce sujet, il était rapidement apparu une fracture entre deux conceptions de
l’audit. Les auditeurs faisaient en général prévaloir la nécessité de maintenir une distance entre les deux fonctions, l’audit et la conduite de projet
elle-même. Ceci peut être mal interprété par l’équipe de projet qui privilégierait au contraire une attitude participative, voire une intégration de la
dimension audit dans leurs pratiques, un peu comme une gestion des
risques. Nous avons tenté de trancher ce dilemme en proposant plusieurs
options et sans éliminer celle qui intégrerait des auditeurs dans l’équipe de
projet.
Les projets informatiques
Les projets
Qu’est-ce qu’un projet ?
La norme ISO 10006 version 1997
présente un projet comme « un processus unique qui consiste en un ensemble
d’activités coordonnées et maîtrisées
comportant des dates de début et de
fin, entrepris dans le but d’atteindre un
objectif conforme à des exigences spécifiques, incluant les contraintes de délais,
de coût et de ressources ». Elle précise en
outre :
• qu’il est possible qu’un projet individuel fasse partie d’une structure
de projet plus large,
• que dans certains projets, les
objectifs sont affinés et les caractéristiques du produit déterminées progressivement, à mesure
que le projet progresse,
• La revue n° 76 - Juillet 2004
• qu’un projet peut aboutir à une ou
plusieurs unités de produits,
4
• qu’une organisation est déployée
temporairement sur la durée du
projet,
• que les interactions entre activités
au sein du projet peuvent être
complexes.
Un projet n’est ni une activité répétitive,
ni une mission permanente. Cependant
cette approche s’applique également à
toute évolution des produits issus des
projets dès lors qu’elle est conduite en
mode projet en identifiant comme le
précise la définition ci-dessus objectifs,
contraintes de délais, de coûts et de
ressources.
Constat sur les projets informatiques
Les projets de systèmes d’information
possèdent des caractéristiques spécifiques, qui les distinguent intrinsèquement des autres types de projets :
• forte obsolescence des composants : les versions des logiciels
intégrés et des composants
produits peuvent se succéder rapidement au cours même du projet,
• logiciels non fiables : nous
sommes en ce domaine très loin
du zéro défaut et les techniques
de prévention et de contrôle des
défauts sont très inégalement
maîtrisées,
• complexité récursive et combinatoire des algorithmes employés et
des structures de données manipulées,
• interposition de l’informaticien
entre le métier et l’utilisateur, ce
qui peut entraîner un problème de
légitimité voire de pouvoir,
• fluctuations des interfaces et des
fonctionnalités dues aux changements d’organisation et à l’évolution des systèmes qui environnent
le produit.
Un projet informatique est souvent vécu
par ses acteurs principaux comme un
cas inédit en raison des innovations
Managements de projets dossier
dans les technologies, de la nouveauté (partielle) du sujet
abordé et des changements du mode d’organisation ou du
contexte. Aussi, les références ou procédures standard ne sont
pas toujours employées ; développer un logiciel s'apparente
alors plus à une activité de recherche qu'à une fonction répétitive.
Le cahier des charges n'est presque jamais complet et figé au
lancement du projet : il s'élabore et s'adapte à mesure de
l'avancement du projet parce que les systèmes informatiques
sont aujourd’hui trop complexes pour pouvoir être totalement
prédéfinis et parce que les réalités et les contraintes des
technologies informatiques ne peuvent être complètement
maîtrisées par les décideurs et maîtres d’ouvrage.
Les projets itératifs
À la différence des développements classiques en V ou incrémentaux, les projets de type IAD (Interactive Application
Developement ) veulent produire rapidement des résultats,
mêmes partiels, sous forme de modules ou de versions successives du produit.
En matière de projets informatiques, un constat s’est imposé à
tous : il ne suffit pas de mettre de l'argent et de la technique ;
plus qu'ailleurs la qualité et la motivation des hommes sont
prépondérantes. De plus, les projets accompagnent souvent ou
provoquent des réorganisations et changements dans les
processus métiers. De ce fait, en cas de difficultés, les ressentiments se cristallisent sur la partie visible du changement, le
projet informatique, alors qu’il n’est que la conséquence d’une
décision stratégique.
• les bénéfices et gains réels apportés aux utilisateurs par
l’emploi du logiciel,
• la contribution directe à l’efficacité et à la valeur de
l’entreprise que peut représenter un système d’informations performant et innovant.
La diversité des projets informatiques
Par projet informatique, on entend communément les deux
grands classiques du métier :
• les développements purs de logiciels complets ou de
composants,
• les évolutions importantes des projets de maintenance.
Mais, aujourd’hui, d’autres types de projets apparaissent, qui
peuvent souvent, dans les directions et les services informatiques, être en plus grand nombre que les développements
classiques, par exemple :
Cette liste de types de projets informatiques n’est pas exhaustive, on pourrait aussi citer :
• les portages d’application,
• les projets d’externalisation,
• les déploiements,
• les projets d’expérimentation,
• …
Différents contextes peuvent induire ce besoin : un impératif
de délai pour une partie du système, des incertitudes au
démarrage du projet portant sur des exigences fonctionnelles,
sur une partie de l’environnement utilisateur, sur des solutions
techniques…
Les projets de mise en place de progiciel
Dans un projet à base de progiciel, le sens donné aux différentes phases et leur contenu sont différents de ceux des
projets de développements spécifiques :
• l’orientation vers une solution à base de progiciel est
d’ordre stratégique. Sa faisabilité est confirmée en phase
d’avant-projet,
• la conception générale prend un sens différent dans la
mesure où le produit est pré-conçu : ce sont la consultation et le choix du couple progiciel-intégrateur qui prennent le pas,
• la réalisation correspond au paramétrage du produit et
au développement des outils périphériques. Elle s’appuie
sur la méthodologie d’implémentation du progiciel et sa
mise en pratique par l’intégrateur.
Les projets d’infrastructure
Dans un projet d’infrastructure, la difficulté consiste à bien
identifier le commanditaire qui ne représente pas toujours les
utilisateurs terminaux. En outre le déploiement est souvent
une opération particulièrement délicate.
Le cas particulier des grands programmes
La notion de programme est habituellement employée pour
caractériser un niveau de complexité supérieur à celui des
projets courants : un programme n’est pas seulement un projet
particulièrement important ou complexe, mais relève d’un
développement de l’entreprise qui entraîne des changements
dans les processus métier, des évolutions du périmètre initial,
et dont l’ampleur traverse plusieurs frontières de filières métier.
L’audit des programmes en tant que tel ne sera pas abordé
dans cet ouvrage.
• La revue n° 76 - Juillet 2004
Il est donc aujourd’hui facile de ne considérer les projets qu’à
travers les résultats d’enquêtes qui en montrent, chaque
année, les dérives et les insuccès. L’auditeur ne pourra se satisfaire de ces constats généraux et se posera continuellement la
problématique de la définition des critères de succès d’un
projet informatique. La tenue d’objectifs de délais, de coûts et
de qualité en est-elle le seul garant, alors que les méthodes et
techniques de fixation d’objectifs en ce domaine (estimation
prévisionnelle des développements) sont connues comme peu
précises et difficiles d’emploi sur des technologies en mouvement, et alors que l’environnement de réalisation des projets
est souvent instable. L’auditeur peut aussi considérer deux
critères essentiels de succès d’un projet :
5
dossier :Managements de projets
Deux caractéristiques essentielles
des projets informatiques
Projets et risques
Les projets informatiques sont aussi, et certains diront surtout,
caractérisés par des risques.
Projets et maturité des organisations
Au-delà du type de projet mené, l’auditeur tiendra également
compte du degré de maturité de l’organisation qui conditionne le mode de gestion et les possibilités réelles d’un projet.
Un risque projet est un événement dont l'apparition
n'est pas certaine et dont la manifestation
est susceptible d'engendrer des dommages
sur le projet ou en dehors du projet.
Les risques sont nombreux et peuvent être classés en grandes
catégories :
• risques liés à l’environnement du projet,
• risques liés à l’alignement des objectifs du projet sur la
stratégie de l’entreprise,
• risques liés à la méthodologie de gestion de projet : planning, monitoring, qualité…,
• risques liés à la solution mise en place : élaboration, développement, test, migration, implémentation…,
• risques liés aux ressources humaines : gestion du changement, communication, formation…
• Niveau initial : Le processus est caractérisé par la
prédominance d'interventions ponctuelles, voire
chaotiques. Peu de procédures sont définies et la réussite
dépend de l'effort individuel.
• Niveau reproductible : Une gestion de projet élémentaire
est définie pour assurer le suivi des coûts, des délais et des
fonctionnalités du produit. Une discipline minimale sur les
processus est en place permettant de capitaliser les
réussites de projets d'un même domaine d'application.
• Niveau défini : Les processus de gestion et d'ingénierie
sont documentés, normalisés et intégrés dans le processus
standard de l'organisation. Tout nouveau projet de
développement ou de maintenance fait intervenir une
version adaptée et approuvée du processus standard de
l'organisation.
• Niveau maîtrisé : Des mesures détaillées sont faites en ce
qui concerne le déroulement du projet et la qualité des
produits. Le processus et le niveau de qualité des produits
sont connus et contrôlés quantitativement.
• Niveau d'optimisation : Une amélioration continue du
processus est mise en œuvre par une rétroaction
quantitative émanant du processus lui-même et par
l'application d'idées et de technologies innovatrices.
• La revue n° 76 - Juillet 2004
Extrait du Modèle d'évolution des capacités logiciel
6
Les approches du type CMM (Capability Maturity Model) permettent d’évaluer et de situer le cadre d’exécution d’un projet,
parmi cinq niveaux.
L’auditeur peut tirer profit de la lecture, voire de la maîtrise du
« Questionnaire sur la maturité du processus logiciel » diffusé par
le Software Engineering Institute, pour :
Il est impossible d’établir a priori une liste exhaustive des
risques potentiels que l’auditeur doit surveiller ou contrôler, il
n’existe pas non plus d’approche ou de technique déterministe d’identification des risques, lui permettant de les recenser
sur un projet.
L’auditeur est cependant amené à examiner les risques d’un projet et les moyens employés pour les maîtriser. Il n’appartient pas
à la mission d’audit, le plus couramment, de refaire une analyse
contradictoire des risques, mais plutôt d’examiner la qualité de la
gestion des risques. Il aura alors à réaliser des tâches très similaires à celles qui sont recommandées par les différentes
approches de gestion des risques :
Identification du risque
Recherche des risques et identification de ses causes
(facteurs) et conséquences
L’audit valide ou construit le portefeuille de risques du projet
Évaluation du risque
Estimation de sa criticité : importance en termes de
probabilité d’apparition et d’impact
(financiers, délais, qualité, …)
L’audit expertise ou calcule la criticité relative ou absolue
de chaque risque
Recherche des moyens de réduction
Solutions de prévention, contournements, transfert
et de surveillance.
L’audit examine ou émet les recommandations proposant une
solution optimale dans le contexte du projet
L’audit de projet est, pour l’organisation, un moyen de s’assurer
que les risques liés à un projet sont maîtrisés. Le cas échéant, les
recommandations d’audit permettent de sécuriser le projet.
En bref
• s’approprier les concepts qui sous-tendent la notion de
maturité dans une organisation,
L’auditeur peut, au cours de sa carrière, être confronté à des
projets très dissemblables, chacun d’eux étant unique par son
objet, les procédures et méthodes utilisées ainsi que son
contexte et environnement.
• mieux cerner les spécificités d’un projet et les situer clairement par rapport aux apports et contraintes de son
environnement.
Cette diversité de projets peut :
• entraîner des besoins en compétences ponctuelles lors
d’un audit. L’auditeur peut donc être amené à faire appel
Managements de projets dossier
Fin étude Fin spéc.
préalable
Tech.
Fin
Recette
Fin
Projet
Qualité du produit
Qualité de l’expression des besoins
(Cahier des charges)
***
Conformité de la définition de
la solution (Spécifications) par rapport
aux besoins exprimés
Complétude des livrables du projet
par rapport aux besoins
***
Adéquation des choix techniques
par rapport aux besoins
*
Qualité de la solution technique
Maîtrise de l’intégration dans
l’ensemble du SI
*
*
*
***
*
***
*
***
*
*
*
*
*
Utilisabilité de la solution
***
Adéquation des dispositifs
Sécurité prévus
• influer aussi sur les règles et procédures de l’audit : L’auditeur adaptera son savoir-faire et sa
démarche à la spécificité de
chaque cas rencontré.
***
Qualité de la documentation fournie
*
*
***
Conformité des processus projet aux
procédures et standards applicables
Qualité du management du projet
Qualité du management des ressources
humaines dans le projet
Qualité de la maîtrise du besoin
par le projet
*
Conclusion
*
*
*
*
*
*
*
*
*
Maîtrise des coûts par le projet
*
*
Maîtrise des délais par le projet
*
*
*
*
*
***
*
Conformité des choix techniques
avec la stratégie informatique
L’ouvrage traite de multiples autres
facettes dont il est impossible de rendre
compte ici, comme, par exemple,
l’organisation de l’audit, les modèles de
mesure, les compétences nécessaires
aux auditeurs. Une très volumineuse
bibliographie servira les lecteurs dans le
dédale des publications autour des
projets informatiques et des standards.
*
Qualité du management de la
communication du projet
Qualité de la gestion
des risques sur le projet
Le tableau ci-contre représente les
objectifs possibles de l’audit en fonction
de l’état d’avancement du projet (entre *
facultatif et *** indispensable). Il apparaît ainsi que certaines phases du projet
nécessitent impérativement un audit ou
au moins la prise de conscience que, en
passant outre, on décide implicitement
du GO/NOGO qui serait un des résultats
de l’audit.
Mais les grands principes d’audit de projet décrits dans ce guide demeurent
identiques et pourront être appliqués
par l’auditeur quelle que soit la nature
du projet audité.
*
Conduite de projet
Opportunité du projet
(en phase préalable)
à des expertises, puisqu’il ne pourra
probablement pas maîtriser seul
l’étendue des domaines techniques ou métiers des projets
informatiques,
Maîtrise des technologies et outils
employés par ce projet
*
Qualité du management des soustraitants et des approvisionnements
*
*
Maîtrise des processus de
Vérification & Validation
*
Maîtrise du produit par le projet
*
Maîtrise du déploiement par le projet
***
Qualité de la communication du projet
*
Maîtrise de la conduite du
changement par le projet
***
Qualité des dispositifs prévus pour
prendre en charge la fin du projet
***
Adéquation des compétences affectées
*
***
Maîtrise des conditions de
succès par le projet
*
*
* Composition du groupe de travail AFAI "
audit des projets informatiques " : Annick
Cavalin, Christian Masson, Frédéric
Fichot, Frédéric Vert, Michel Le Goff,
Jean-Michel Sarda, Sébastien Albert.
*
• La revue n° 76 - Juillet 2004
Objectifs
7