Audit de projets informatiques

dossier :
Management
de projets
4
• La revue n° 76 - Juillet 2004
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ésu-
mons ci-dessous certains des
aspects essentiels de la publication
qui a couronné les travaux du
groupe.
Qu’est-ce qu’un projet ?
La norme ISO 10006 version 1997
présente un projet comme « un proces-
sus 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éci-
fiques, incluant les contraintes de délais,
de coût et de ressources ».Elle précise en
outre :
• qu’il est possible qu’un projet indi-
viduel fasse partie d’une structure
de projet plus large,
• que dans certains projets, les
objectifs sont affinés et les carac-
téristiques du produit détermi-
nées progressivement, à mesure
que le projet progresse,
• qu’un projet peut aboutir à une ou
plusieurs unités de produits,
• 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éci-
fiques, qui les distinguent intrinsèque-
ment des autres types de projets :
• forte obsolescence des compo-
sants : les versions des logiciels
intégrés et des composants
produits peuvent se succéder rapi-
dement 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 combina-
toire des algorithmes employés et
des structures de données mani-
pulé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 change-
ments d’organisation et à l’évolu-
tion 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
Les projets
Les projets informatiques
Audit de projets informatiques
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 mainte-
nir 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.

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éti-
tive.
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.
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 ressenti-
ments 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.
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 satis-
faire 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 mouve-
ment, 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 :
• 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’informa-
tions performant et innovant.
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 informa-
tiques, être en plus grand nombre que les développements
classiques, par exemple :
Cette liste de types de projets informatiques n’est pas exhaus-
tive, on pourrait aussi citer :
• les portages d’application,
• les projets d’externalisation,
• les déploiements,
• les projets d’expérimentation,
•…
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 succes-
sives du produit.
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 consulta-
tion et le choix du couple progiciel-intégrateur qui pren-
nent 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.
5
• La revue n° 76 - Juillet 2004
Managements de projets dossier
La diversité des projets informatiques

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 condi-
tionne le mode de gestion et les possibilités réelles d’un projet.
Les approches du type CMM (Capability Maturity Model) per-
mettent 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 :
• s’approprier les concepts qui sous-tendent la notion de
maturité dans une organisation,
• mieux cerner les spécificités d’un projet et les situer clai-
rement par rapport aux apports et contraintes de son
environnement.
Projets et risques
Les projets informatiques sont aussi, et certains diront surtout,
caractérisés par des risques.
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 :plan-
ning, monitoring, qualité…,
• risques liés à la solution mise en place :élaboration,déve-
loppement, test, migration, implémentation…,
• risques liés aux ressources humaines : gestion du chan-
gement, communication, formation…
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étermi-
niste d’identification des risques,lui permettant de les recenser
sur un projet.
L’auditeur est cependant amené à examiner les risques d’un pro-
jet 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 simi-
laires à celles qui sont recommandées par les différentes
approches de gestion des risques :
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
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.
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
dossier :Managements de projets
6
• La revue n° 76 - Juillet 2004
• 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.
Extrait du Modèle d'évolution des capacités logiciel
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.
É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
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
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
Deux caractéristiques essentielles
des projets informatiques

7
• La revue n° 76 - Juillet 2004
Managements de projets dossier
Objectifs Fin étude Fin spéc. Fin Fin
préalable Tech. Recette 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 * *** *
Qualité de la documentation fournie *** *
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 **
Conduite de projet
Opportunité du projet
(en phase préalable) *** *
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 **
Qualité du management de la
communication du projet **
Maîtrise des coûts par le projet **
Maîtrise des délais par le projet **
Qualité de la gestion
des risques sur le projet ***
Conformité des choix techniques
avec la stratégie informatique *** *
Maîtrise des technologies et outils
employés par ce projet **
Qualité du management des sous-
traitants 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 ***
à des expertises,puisqu’il ne pourra
probablement pas maîtriser seul
l’étendue des domaines tech-
niques ou métiers des projets
informatiques,
• influer aussi sur les règles et procé-
dures de l’audit : L’auditeur adap-
tera son savoir-faire et sa
démarche à la spécificité de
chaque cas rencontré.
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 appa-
raî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 pro-
jet décrits dans ce guide demeurent
identiques et pourront être appliqués
par l’auditeur quelle que soit la nature
du projet audité.
Conclusion
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.
* 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.