Stratégie d'audit des projets informatiques : complémentarité des référentiels CobiT, PMBOK et CMMI

PROMOTION 2009, MBA : AUDIT, CONSEIL ET CONTROLE DE GESTION

STRATEGIE D'AUDIT DES PROJETS

INFORMATIQUES : COMPLEMENTARITE

DES REFERENTIELS COBIT, PMBOK ET

CMMI

THESE PROFESSIONNELLE

ENTREPRISE

PERIODE DE STAGE

06/04/2009 - 06/10/2009

AUTEUR TUTEUR

F. FAURE M. LIOTTIER

Remerciements

En préambule à cette thèse, je souhaiterais adresser toute ma gratitude aux personnes qui m'ont apporté leurs conseils, leur expertise et leur soutien au cours de mes recherches et qui ont ainsi contribué à son élaboration.

Tout d'abord, je souhaite exprimer ma reconnaissance envers la Banque de France, et plus particulièrement à Mme LE MAGUER, Mr AFRIAT, Mr LHUISSIER, Mr BORDES et Mr MAHE qui m'ont fourni de nombreuses informations et fait part de leur expertise dans les domaines de l'audit interne, de l'audit informatique et de la gestion de projet. Ils m'ont permis d'explorer de manière transversale et approfondie une problématique résolument actuelle en relation avec mon stage et mes projets professionnels.

Ce fut un véritable plaisir de travailler à leurs cotés tant pour leur niveau de compétence, et la richesse de leur enseignement que pour leur accueil et leur disponibilité.

Ma reconnaissance s'adresse également à mon directeur de recherche Mr LIOTTIER, professeur de l'ISC, qui m'a accompagné tout au long de la réalisation de cette thèse, et m'a permis d'orienter judicieusement mes axes de réflexion.

Enfin, je tiens à remercier l'ISC et son corps professoral, qui m'a enseigné les fondamentaux du métier d'auditeur interne. Cela m'a permis de m'intégrer facilement au sein des équipes de la Banque de France et de produire, en ma qualité de stagiaire, un travail efficace.

Cette expérience, très instructive, m'a permis d'apprendre tant sur les valeurs que sur le métier d'auditeur interne.

SYNTHESE INTRODUCTION			1 4
I.	AUDIT DES PROJETS INFORMATIQUES		6
	I.1.	SPECIFICITES DES PROJETS INFORMATIQUES	6
I.1.1.	Définition d'un projet	6
I.1.2.	Les grandes phases d'un projet informatique	6
I.1.3.	Acteurs et organisation d'un projet informatique	8
I.1.4.	Les risques sources de dérives et d'insuccès des projets informatiques	11
I.2.	LES AUDITS DES PROJETS INFORMATIQUES	14
	I.2.1.	Position de l'audit de projet informatique dans l'organisation	15
	I.2.2.	Déroulement d'une mission d'audit	18
	I.2.3.	Critères de sélection des projets à auditer	20
	I.2.4.	À quel stade de leur vie auditer les projets retenus ?	22
II.	STRATEGIE D'AUDIT DES PROJETS INFORMATIQUES		25
	II.1.	REFERENTIELS ET RECUEILS DE BONNES PRATIQUES	25
II.1.1.	Control Objectives for Information and related Technology (CobiT)	25
II.1.2.	Capability Maturity Model Integration (CMMI)	29
II.1.3.	Project Management Body Of Knowledge (PMBOK)	33
II.1.4.	Des référentiels peu utilisés dans les organisations	36
II.2.	COMPLEMENTARITE DES REFERENTIELS	38
	II.2.1.	Alignement du projet sur la stratégie métier de l'entreprise et sur les choix des technologies de

l'information 38

II.2.2. Qualité de la conduite de projet 40

II.2.3. Qualité du produit délivré par le projet 45

II.2.4. Vue d'ensemble 47

CONCLUSION 49

TABLES DES ILLUSTRATIONS 51

ANNEXES 52

GLOSSAIRE 55

BIBLIOGRAPHIE ET AUTRES SOURCES 56

1

Synthèse

Dans un environnement compétitif, maîtriser le système d'information est une clé essentielle du succès et de la survie d'une entreprise : ses processus métiers critiques dépendent de sa capacité à collecter et traiter de multiples informations et de disposer d'un outil souple et fortement évolutif afin de l'adapter aux changements organisationnels. Les projets informatiques visent à délivrer ou à faire évoluer le système d'information de l'entreprise pour qu'il soit plus efficace et mieux adapté à son environnement. De fait, la réussite des projets informatiques en termes de respect des délais, des coûts et de la qualité est aujourd'hui un enjeu important pour l'entreprise et la maîtrise des risques projets est un enjeu majeur pour garantir leur succès.

Un projet informatique est aujourd'hui, à l'instar d'un projet de BTP, un projet d'intégration qui requiert tout au long du cycle de vie de multiples compétences et expertises pour permettre l'assemblage de divers composants techniques.

Ainsi, un projet informatique comprend pour principales étapes :

· le développement du logiciel applicatif comme support aux processus opérationnels du métier ;

· la fourniture de l'infrastructure technique (serveurs, réseaux, flux de communication, dispositifs de sécurité, environnement de secours ...) ;

· l'intégration du logiciel applicatif dans l'infrastructure technique de l'entreprise pour constituer le système informatique ;

· l'intégration du logiciel applicatif dans le système d'information de l'entreprise avec la mise en place d'interfaces inter applicatives.

De toute évidence, les risques sont nombreux. Ils dépendent fortement de la capacité des différents acteurs à comprendre et définir les besoins, concevoir une solution adaptée, la réaliser et enfin la mettre en oeuvre.

Ces risques se traduisent par des dérives en termes :

· d'augmentation des charges ;

· d'allongement des délais ;

·

2

de mauvaise qualité du logiciel ou des services offerts aux utilisateurs ;

· de réduction du périmètre couvert.

Les risques sont certains, seul le moment où ils apparaissent et l'importance de leur impact est incertain. En effet, une étude publiée par le Système Européen des Banques Centrales (SEBC) affirme que 83% des grands projets informatiques analysés subissent des retards, 42% des surcoûts, et 25% ne couvrent que partiellement les attentes des utilisateurs.

En 1517, Nicolas de Machiavel dans Discours sur la première décade de Tite-Live écrivait : « Lorsqu'on s'aperçoit très tôt des maux naissants, ce qui n'est donné qu'au sage, on peut y remédier facilement. Cependant lorsque, faute de s'en être aperçu, on les laisse grossir assez longtemps pour qu'ils deviennent visibles à tous, il n'y a plus de remède possible. »

La gestion des risques est donc capitale sur un projet. Ainsi, l'objectif des audits de projets s'inscrit pleinement dans cette approche, à savoir être le levier d'action des projets en difficultés.

Confrontés à la complexité des projets, comment les auditeurs peuvent-ils dresser un état des lieux, préconiser des recommandations pour remédier aux faiblesses identifiées dans un délai restreint, sans pour autant être expert dans les différents domaines ?

Pour ce faire, l'audit de projet informatique s'appui de plus en plus sur un ensemble de normes, de référentiels, et de bonnes pratiques du domaine informatique, notamment sur:

· la gouvernance des systèmes d'informations ;

· les techniques d'ingénierie informatique : de développement, de sécurité, d'exploitation...

· le management des projets.

De par le caractère unique des projets informatiques, il n'existe pas un référentiel unique couvrant l'ensemble des spécificités des projets et l'objet de cette thèse est d'établir une démarche méthodologique visant à définir les thématiques essentielles à l'audit des projets informatiques à partir de la complémentarité des référentiels suivants :

· CobiT (Control Objectives for Information and related Technology) pour définir le cadre d'audit des projets informatiques ;

·

3

PMBOK (Project management body of knowledge) pour les aspects relatifs à de la gestion de projets ;

· CMMI (Capability Maturity Model Integration) pour les processus de développement de logiciels informatiques.

Cette approche globale de la complémentarité des référentiels cités conduit à définir trois axes essentiels à la réussite d'un projet informatique :

· alignement du projet sur la stratégie métier de l'entreprise et sur les choix des technologies de l'information ;

· qualité de la conduite de projet ;

· qualité du produit délivré par le projet.

Une étude plus approfondie de chaque axe autour des domaines de processus définis dans les référentiels permet d'établir un ensemble de points de contrôle à analyser durant les investigations. Elle doit être complétée par l'évaluation des risques établis par le projet ainsi que ceux du métier audité.

Les objectifs visés par un audit de projet sont de :

· proposer des pistes d'amélioration rapidement mises en oeuvre pour réorienter un projet, en particulier sur les faiblesses du management ;

· formuler des recommandations sur la stratégie de réalisation, en particulier sur l'adaptation, du cycle de vie projet, de l'organisation, du lotissement du périmètre fonctionnel afin de respecter au mieux les objectifs du projet.

L'approche de l'audit des projets informatiques développée dans cette thèse à travers la complémentarité des référentiels de gouvernance, de management et de développement mérite d'être complétée pour tenir compte du capital humain. En effet, l'aptitude des acteurs à résoudre un problème par la connaissance approfondie qu'ils possèdent d'un domaine doit être pris en compte. Ainsi la capitalisation des savoirs, la gestion des connaissances au sein de l'entreprise pourrait constituer un cinquième axe d'analyse.

4

Introduction

L'audit informatique est une activité indépendante et objective, qui, assure d'une part, l'entreprise sur le degré de maîtrise de son système d'information et des processus associés, et d'autre part, formule des recommandations afin d'en améliorer le fonctionnement et les performances.

L'audit des projets informatiques est une évaluation objective par un tiers, qui, par une série de constats et une identification des risques associés, permet de proposer des pistes d'amélioration afin de réorienter un projet en difficulté, en renforçant les pratiques d'ingénieries logicielles et en corrigeant les faiblesses du management.

Les projets informatiques sont des entités complexes et uniques, que ce soit en termes d'enjeu, de taille, de criticité pour l'entreprise, de technologies mises en oeuvre, ou de contextes de réalisation.

De ce fait, le cadre et le support des projets offerts par l'entreprise peuvent différer sur plusieurs plans :

· les règles et méthodes de conduite de projet définies dans l'entreprise ;

· le niveau de maturité de la direction informatique ;

· l'adhésion de l'entreprise aux objectifs du projet.

Confrontés à la complexité inhérente des projets informatiques et aux risques qui en découlent, comment les auditeurs peuvent-ils dresser un état des lieux, préconiser des recommandations pour remédier aux faiblesses identifiées dans un délai restreint, sans pour autant être expert dans les différents domaines ?

Pour cela, l'audit des projets informatiques peut s'appuyer sur de multiples normes, référentiels et guides informatiques tels que:

· CobiT et ValIT pour la gouvernance du système d'information ;

· PMBOK, SIXSIGMA et PRINCE2 pour les bonnes pratiques du management de projet;

· Agile, Scrum ou Merise pour les méthodes d'ingénierie logicielle ;

· CMMI ou ITIL pour la définition et l'amélioration des processus informatiques ;

· ISO 27001 et 27005 pour la sécurité de l'information ;

· Mehari, ERM ou RiskIT pour gérer les risques ;

· des référentiels internes propres à l'entreprise : Mélodic et Amaris à la Banque de France ou Deliver à Capgemini.

De par les spécificités des projets informatiques, il n'existe pas de référentiel unique, et l'objet de cette thèse est de définir une démarche méthodologique visant à établir les thématiques essentielles à l'audit des projets informatiques à travers la complémentarité des référentiels CobiT, PMBOK, et CMMI.

5

6

I. Audit des projets informatiques

I.1. Spécificités des projets informatiques

I.1.1. Définition d'un projet

La norme ISO 10006 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 ».

La norme ISO 10006 précise en outre :

· qu'il est possible qu'un projet individuel fasse partie d'une structure de projet plus large (intégration du projet dans le système d'information) ;

· que dans certains projets, les objectifs sont affinés et les caractéristiques du produit déterminées progressivement, à mesure que le projet avance ;

· 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.

I.1.2. Les grandes phases d'un projet informatique

Un projet, qu'il soit informatique ou non, est divisé en un ensemble de phases qui relient le début d'un projet à sa fin. L'ensemble de ces phases est connu sous le nom de cycle de vie du projet. De manière générale, le cycle de vie d'un projet peut se résumer à huit phases décrites ci-dessous (le cycle de vie d'un projet informatique à la Banque de France est détaillé en annexe 1).

I.1.2.1. Lancement

Le lancement d'un projet est officialisé par la diffusion d'une note de lancement. Elle définit les principales caractéristiques du projet telles que les objectifs, l'enveloppe budgétaire, les délais et les équipes projet.

7

I.1.2.2. Étude préalable

L'étude préalable a pour objet de mieux cerner et situer le projet afin d'en confirmer le contour, les objectifs, les moyens et les délais qui ont été définis dans la note de lancement. Elle comprend d'une part, l'étude critique de l'existant et le recueil des besoins et orientations exprimés par les utilisateurs (cahier des charges), et d'autre part, la définition de différentes solutions pour répondre à ces besoins et leur comparaison (dossier de choix de solution).

I.1.2.3. Conception d'ensemble

La conception d'ensemble consiste à modéliser le futur système d'un point de vue fonctionnel et organisationnel et à décrire de manière globale les grandes phases de traitement.

I.1.2.4. Spécifications fonctionnelles

À partir des résultats de conception d'ensemble, la phase de spécification fonctionnelle consiste à décrire pour chaque phase de traitement à développer : les données, les écrans, les états et les traitements informatiques de manière exhaustive et précise.

I.1.2.5. Conception technique

La phase de conception technique définit le cadre technique du projet informatique en précisant :

· la structure du logiciel à développer (découpage en programmes, modules, classes, méthodes, transactions, chaînes...) ;

· le modèle physique de la base de données ;

· l'architecture du réseau, l'intégration dans le système d'information, et d'autres éléments techniques.

I.1.2.6. Réalisation et tests

La réalisation a pour but de fabriquer les différents composants logiciels de la solution à partir des spécifications fonctionnelles et techniques.

Les tests ont pour but de vérifier la cohérence et la validité de l'ensemble de ces éléments par rapport aux spécifications.

I.1.2.7. Recette

L'objectif de la phase de recette est de vérifier la conformité de l'application par rapport aux spécifications fonctionnelles et techniques. Ces tests sont effectués dans un environnement dit d'intégration, c'est-à-dire identique à celui de production.

8

I.1.2.8. Démarrage

La phase de démarrage, appelée aussi mise en production, consiste à insérer l'application dans l'environnement réel et à démarrer son exploitation et son utilisation opérationnelle.

Le démarrage se conclut par un PV de recette définitive. Le projet est terminé : on ne travaille plus en mode projet, mais en mode maintenance. Ce passage est marqué par un transfert de responsabilités de l'équipe projet vers les acteurs métier, selon les modalités définies dans le contrat.

I.1.3. Acteurs et organisation d'un projet informatique

La réalisation d'un projet informatique fait intervenir de nombreux acteurs appartenant à différents niveaux hiérarchiques.

Les deux principaux acteurs sont la maîtrise d'ouvrage et la maîtrise d'oeuvre.

I.1.3.1. La maîtrise d'ouvrage

On appelle la maîtrise d'ouvrage (MOA) le commanditaire du projet, c'est-à-dire l'entité porteuse du besoin, définissant l'objectif, le calendrier et les budgets consacrés au projet. La MOA représente également les utilisateurs finaux du produit.

D'une manière opérationnelle, la MOA :

· exprime les besoins du projet, et les objectifs associés ;

· maîtrise la description et le diagnostic de l'existant ;

· maîtrise les impacts sur les métiers ;

· définit les facteurs qualité ;

· fixe les grandes échéances ;

· définit le produit répondant aux objectifs (spécifications fonctionnelles) ;

· lance la réalisation ;

· pilote et suit les actions de l'éventuelle sous-traitance ;

· contrôle la réalisation et prononce la recette ;

· assure l'exploitation du produit fini.

I.1.3.2. La maîtrise d'oeuvre

Selon l'AFNOR (norme P030061), « la maîtrise d'oeuvre (MOE) est la personne (physique ou morale) qui, pour sa compétence technique, est chargée par la MOA, de diriger et de contrôler les travaux et de proposer la réception et leur règlement ».

D'une manière opérationnelle, la MOE :

· est responsable de la réalisation des travaux confiés par la MOA ;

· assure l'organisation en planifiant les tâches à réaliser ;

· détermine les moyens humains et matériels nécessaires à la conduite du projet ;

· anime l'équipe projet ;

· réalise ou supervise (en cas de sous-traitance) les travaux d'étude et de réalisation ;

· fournit à la MOA le produit conforme aux spécifications validées, dans des conditions de coûts, délais et qualité fixées ;

· rend compte fréquemment à la MOA de l'avancement des travaux.

I.1.3.3. Echanges MOA / MOE

Le déroulement du projet informatique se traduit par un ensemble d'échanges entre ses protagonistes :

Figure 1 : principaux échanges entre MOA et MOE

9

10

I.1.3.4. Organisation

L'organisation d'un projet informatique est complexe à cause du nombre d'acteurs, mais aussi par rapport à leurs responsabilités et positions hiérarchiques vis-à-vis du projet et dans l'organisation.

Figure 2 : organisation des principaux acteurs du projet

Les interactions entre les différents acteurs du projet se font au travers de réunions formalisées.

Voici les principales :

· le comité de pilotage (COPIL) est présidé par le responsable métier du projet. Les décisions majeures relatives au projet y sont prises. Il arbitre et entérine les validations effectuées par les autres intervenants de la MOA. Il est informé sur la situation du projet par une note de pilotage, élaborée par les chefs de projet. Il suit les risques du projet et prend les mesures nécessaires pour les maîtriser ;

· le comité de suivi (CS) se réunit régulièrement pour contrôler le bon déroulement du projet. Il veille à la disponibilité des moyens, prend les mesures correctives nécessaires et, en cas de besoin, demande la convocation du comité de pilotage. Participent à ce comité, le directeur de projet, les représentants de la maîtrise

11

d'ouvrage (chef de projet MOA, correspondants sous-projets) et le chef de projet MOE ;

· le comité de suivi technique (CST) a pour rôle le suivi des travaux d'intégration en production et la coordination des acteurs qui en sont chargés. Les CST sont des réunions de suivi d'avancement, de prise de décision à caractère technique et d'affichage d'engagements mutuels entre les participants. Il est présidé par la chef de projet MOE et y participent les représentants de la direction du SI et le responsable de la sécurité informatique ;

· un comité de suivi fournisseur (CSF), animé par la MOE est mis en place pour suivre l'exécution du contrat : respect des engagements contractuels (livraisons, délais, moyens mis en oeuvre), suivi de la facturation, suivi des risques, résolution de problèmes et décision de plan d'action, décisions ou propositions d'arbitrages en cas de modifications du périmètre contractuel ;

· un groupe de travail se réunit sur un thème particulier, préliminaire à certaines phases de l'étude ou connexe au projet. Les participants sont les membres de la MOE et de la MOA concernés par le thème abordé dans le groupe de travail.

I.1.4. Les risques sources de dérives et d'insuccès des projets informatiques

Un risque se définit comme un événement, pouvant survenir pendant le cycle de vie d'un projet, susceptible de remettre en cause la réalisation des objectifs en termes de coût, de qualité et de délai.

Le but de la gestion des risques n'est pas d'éviter des projets à risques, mais de minimiser l'impact des risques sur les projets qui sont menés.

Ainsi, gérer les risques, c'est :

· anticiper continuellement les problèmes futurs et non attendre leur survenance pour les gérer ;

· refuser la gestion des crises dans l'urgence, mais prévoir leur apparition et s'y préparer.

Ainsi les principaux risques (détails en annexe 2) sources d'échec des projets sont :

· l'inexpérience du chef de projet ;

·

12

la faiblesse de la MOA ;

· une mauvaise gestion contractuelle ;

· des objectifs non alignées sur la stratégie de l'entreprise.

I.1.4.1. L'inexpérience du chef de projet

De nombreux projets dérapent de façon importante en termes de délai, de coût et de qualité. Les écueils à l'origine de ces échecs sont multiples, mais on peut retenir en premier lieu l'inexpérience du chef de projet ou son incapacité à conduire son projet. Ensuite, il y a l'imprécision du cahier des charges, le manque de maturité du client, le manque de maîtrise des processus d'ingénierie logiciel ou les mauvaises estimations de charge du projet. Mais, il y a concomitance des facteurs. En effet, un chef de projet expérimenté qui maîtrise les techniques d'estimation de charges, identifiera des imprécisions du périmètre fonctionnel et posera les questions adéquates. L'imprécision du cahier des charges donne dans certains cas au client l'illusion de disposer de plus de temps pour mieux préciser ses besoins encore flous et peut-être d'en avoir plus pour le même prix. Quant au prestataire, il peut aussi y trouver une porte ouverte à la signature de nouveaux avenants. En plus des connaissances du métier client et du référentiel méthodologique propre à l'entreprise, le chef de projet se doit de maîtriser les processus clé de la gestion de projet, mais aussi de connaître les référentiels de bonne pratique pouvant l'aider à appréhender de la bonne manière des situations qui lui sont inédites.

I.1.4.2. Faiblesse de la MOA

Dans les grandes entreprises, la maîtrise d'ouvrage a pris plus d'assurance. Elle n'hésite pas à se faire accompagner d'une assistance interne ou externe (AMOA : assistance à la maîtrise d'ouvrage) pour pallier à son indisponibilité ou à son manque de compétence.

Lorsqu'on se penche sur les origines des dérives des projets, on identifie souvent les mêmes maux résultant en partie de la maîtrise d'ouvrage : un cahier des charges insuffisamment précis qui est figé lors du lancement du projet alors qu'il devrait évoluer et s'adapter au rythme de l'avancement du projet parce que les systèmes informatiques sont aujourd'hui en constante évolution et trop complexes pour pouvoir être totalement prédéfinis plusieurs mois ou années à l'avance.

La réussite d'un projet se bâtit par le partenariat, ce qui implique une maturité du client comme du prestataire qu'il soit ou non intégrateur, mais surtout par la professionnalisation de la MOA. Dans cette situation, la maîtrise d'ouvrage est à même de comprendre la

13

préoccupation du prestataire qui souhaite restreindre parfois certaines exigences fonctionnelles ou techniques. La MOA a en contrepartie, l'assurance du respect de la livraison d'une version plus restreinte, mais opérationnelle.

I.1.4.3. Un contrat non exhaustif

Dans de nombreux projets ayant dérivés jusqu'au contentieux, le contrat était soit incomplet soit confus ou encore déséquilibré au détriment de l'une ou l'autre des parties. Traditionnellement, un contrat spécifie notamment l'objet et la durée du projet. Il fournit une définition globale de la prestation à réaliser. Enfin, il aborde les questions de prix, des pénalités de retard, ainsi que les conditions de paiement, d'assurance et de résiliation. En effet, si par exemple le cycle de validation des livrables est dissocié de celui des échéances de paiement, le fournisseur pourra exiger le paiement, peu importe si le résultat produit est conforme aux attentes du client. Le client ne peut admettre que l'échéancier des paiements reste immuable alors que le projet dérive et que les livrables ne lui sont pas fournis. Les procédures indispensables au bon déroulement des projets tel que la conduite du projet, le suivi des évolutions, la gestion du planning, des recettes, gestion du changement ainsi que les attentes précises du client doivent avoir été prévues contractuellement, faute de quoi elles peuvent être écartées par l'un des partenaires. Si ces procédures ont été prévues dans le contrat ou dans le plan d'assurance qualité associé, elles favoriseront le succès du projet.

I.1.4.4. Des objectifs non alignés sur la stratégie

Un des principaux facteurs d'échec d'un projet réside dans le non-alignement du projet informatique sur la stratégie de l'entreprise ou du service dans lequel il est mis en oeuvre.

Pour la réussite d'un projet, il est essentiel que celui-ci s'inscrive dans une vision portée par la direction de l'entreprise. En effet, les projets accompagnent 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 réorganisation des processus parfois non maîtrisée et mal déterminée par la direction.

Enfin, un projet informatique complexe aura de grandes difficultés à réussir dans une organisation ou les procédures qualité ne sont pas maîtrisées.

14

I.1.4.5. Constat de dérives et d'insuccès

La non-prise en compte des risques projets entraîne de nombreuses difficultés comme celles relevées par une étude du SEBC parue en 2005:

· difficultés liées à la technologie utilisée : 67 % ;

· manque de coordination entre la MOA et MOE: 67 % ;

· mauvaise gestion du projet : 50 % ;

· insuffisance des contrôles : 17 %. Qui se traduisent par :

· retards : 83 % ;

· surcoûts : 42 % ;

· non-qualité (décalage avec les demandes des utilisateurs) : 25 %.

I.2. Les audits des projets informatiques

Que disent les anciens :

· SENEQUE, lettre 71 à Lucilius : qu'il n'y a de bien que ce qui est honnête. Différents degrés de sagesse, 62 après J.C « Pour qui ignore à quel port se rendre, aucun vent n'est propice. »

· MACHIAVEL N, Discours sur la première décade de Tite-Live, 1517: « Lorsqu'on s'aperçoit très tôt des maux naissants, ce qui n'est donné qu'au sage, on peut y remédier facilement. Cependant lorsque, faute de s'en être aperçu, on les laisse grossir assez longtemps pour qu'ils deviennent visibles à tous, il n'y a plus de remède possible. »

Face à ces constats d'échecs l'audit de projet informatique à l'image des dires de MACHIAVEL souhaite se positionner en sage pour identifier, l'origine, la cause profonde, des problèmes rencontrés sur les phases critiques du projet.

L'appel à l'audit doit alors être le moyen connu et le levier d'action pour redresser les projets informatiques en difficultés. En effet, attendre que la situation ne devienne irréversible ou qu'elle provoque des conflits définitifs ne permettra à l'audit que de dresser un état des lieux et non d'être un outil de maîtrise et de redressement des projets.

15

Pour cela, l'audit de projet informatique va consister à évaluer trois domaines :

· l'intégration du projet dans la stratégie de l'organisation ;

· la qualité de la conduite de projet ;

· la qualité du produit délivré par le projet. En analysant principalement les phases :

· étude préalable ;

· spécifications ;

· recette.

I.2.1. Position de l'audit de projet informatique dans l'organisation

L'informatique est aujourd'hui un outil central du fonctionnement d'une organisation. On n'automatise plus des tâches manuelles à l'identique, mais on tire parti des possibilités de l'informatique (performances, traitement de masse, capacités de mémorisation, contrôles continus, traçabilité des opérations, ...) pour organiser et exécuter autrement les processus Métier. Modifier l'outil de travail est donc d'abord un projet du Métier, dans lequel s'inscrit un projet informatique délivrant un nouveau système d'information plus efficace et mieux adapté à la réalité de l'organisation.

Il est intéressant de revenir sur la définition du système d'information : « Un système d'information peut être défini comme un réseau complexe de relations structurées entre des hommes, des machines, des procédures et des processus. Le système d'information a pour but d'engendrer des flux d'informations générées par les applications informatiques ayant des sources d'informations internes et externes à l'organisation. Ces flux d'informations sont organisés de façons pertinentes afin de constituer un aide à la décision ».

Pour identifier la position de l'audit de projet informatique par rapport au système d'information et par rapport à l'organisation, il faut comprendre les différentes strates qui les composent.

En effet, le système d'information a pour socle une infrastructure technique qui se compose de serveurs, de composants réseau et de bases de données. Les applications informatiques

16

constituent la deuxième strate du système d'information, elles reposent sur l'infrastructure technique, on dénomme cet ensemble le système informatique.

Le système informatique répond à un ensemble de règles, de procédures et d'opérations définies par les processus métier. Cet ensemble est le coeur du système d'information.

En outre, il faut considérer le système d'information comme un ensemble permettant de recevoir des informations dont les origines sont les processus métiers, qui reçoivent eux-mêmes les informations d'acteurs internes ou externes à l'organisation. Ces informations sont traitées afin d'être enrichies, organisées et épurées afin de restituer ces informations aux processus métiers, mais aussi de fournir une information complète et exacte afin d'alimenter les processus d'aide à la décision.

À ce titre, l'audit de projet informatique ne vise ni à auditer le système d'information ni les applications en production, mais va analyser les différentes phases composant le cycle de vie d'un projet (§I.1.2) au travers des trois domaines d'investigation. Les objectifs principaux sont d'évaluer le niveau de risque et détecter une éventuelle fuite en avant, mais aussi de diminuer le niveau de risque ou de définir des recommandations permettant de stabiliser le projet.

Le schéma suivant représente la position du système d'information par rapport à l'organisation et l'audit de projet informatique par rapport au cycle de vie d'une application.

Figure 3 : Système d'information et audit de projet informatique

17

18

I.2.2. Déroulement d'une mission d'audit

Une mission d'audit se résume en quatre phases successives :

· la lettre de mission qui officialise la mission et ses objectifs ;

· la préparation de la mission ;

· la réalisation de la mission ;

· la restitution.

I.2.2.1. La lettre de mission

La lettre de mission signée par le mandataire permet d'informer l'ensemble des responsables concernés par la mission d'audit sur différents points :

· identification du mandataire ;

· identification des auditeurs ;

· objet de la mission : projets concernés et objectif assigné à la mission ;

· date de début et de fin de la mission ;

· conditions de réalisation : attribution des moyens, autorisation d'investigation ;

· niveau d'exigence en matière de preuve.

I.2.2.2. Préparation

La phase de préparation se compose de trois étapes successives :

· La prise de connaissance vise à acquérir au travers de la documentation projet (contrat, cahier des charges, spécifications, cv des acteurs ...) une vision d'ensemble du projet :

§ compréhension des enjeux et objectifs du projet ;

§ identification des principaux acteurs du projet ;

§ analyse des principaux éléments chiffrables : planning, durée des phases, coûts des principales phases, dimensionnement des équipes projet

§ immersion dans la culture du projet : terminologie employée, technologies utilisées ...

· Identification des zones de risques potentiels, cette étape consiste à identifier les zones de risques les plus dommageables où les risques sont les plus susceptibles de se produire. Pour cela les auditeurs peuvent se baser sur :

§ l'étape de prise de connaissance ;

§

19

les demandes spécifiques du mandataire ;

§ leur expérience.

· Définition des objectifs détaillés, cette étape permet de :

§ définir les axes à analyser et les points de contrôle à vérifier ;

§ définir l'organisation et l'attribution des tâches à effectuer.

I.2.2.3. Réalisation

La phase de réalisation se déroule en trois étapes :

· La prise de contact marque le commencement des opérations d'audit sur le terrain. À l'issue de cette étape, plusieurs éléments sont définis :

§ planification des rendez-vous avec les audités ;

§ liste des documents projet dont souhaitent disposer les auditeurs.

· L'interview permet à l'auditeur d'obtenir ou de valider des informations sur des points précis. Pour mener une bonne interview, il faut :

§ envoyer aux audités l'ordre du jour de l'interview ;

§ évoquer en priorité les points critiques (difficultés, points faibles, anomalies...) ;

§ demander à l'interviewé les documents permettant de justifier ses dires ;

§ considérer l'audité comme son égale dans la conduite du dialogue ;

§ utiliser la reformulation pour confirmer les propos de l'audité.

· D'autres sources d'information sont parfois nécessaires :

§ la documentation bien que déjà utilisé dans la phase de préparation est utile, suite à une interview, pour creuser ou confirmer certains points;

§ le benchmarking est utilisé pour comparer le projet informatique audité avec d'autre projet et donc de rationaliser les constats ;

§ les essais sont utilisés pour étayer une hypothèse ou valider une déduction ;

§ les états de configurations : liste des livrables réalisés et à venir, liste des jeux de tests, liste des environnements...

20

I.2.2.4. Restitution La rédaction du rapport d'audit prend la forme convenue avec le mandataire ou se plie aux usages de l'organisation. On y retrouve forcément les constats, les risques associés ainsi que les recommandations. Les recommandations sont le fruit de l'analyse et de la synthèse faites à l'issue du travail d'interviews et de recueils d'informations. La réunion de restitution permet à l'équipe d'audit de présenter, argumenter et commenter leurs analyses, recommandations et conclusion au mandataire de la mission. Les audités peuvent également participer à la réunion de restitution sur la volonté des auditeurs et l'accord du mandataire.

Figure 4: déroulement d'une mission d'audit

I.2.3. Critères de sélection des projets à auditer

Chaque entreprise conduit en parallèle de nombreux projets. À la Banque de France plus de 60 projets informatiques sont actuellement en cours. Étant donné le nombre conséquent de projets informatiques conduit par les grandes organisations, sur quels critères doit-on sélectionner les projets à auditer ?

I.2.3.1. Tous les projets

Une entreprise peut choisir d'auditer l'ensemble de ses projets, mais pour cela il faut qu'elle s'en donne les moyens. Un dimensionnement des équipes d'audit est nécessaire pour couvrir l'ensemble des projets ou bien l'organisation peut faire appel à la sous-traitance pour un besoin ponctuel.

Dans ce cas, l'entreprise dispose d'une vision globale de la maîtrise ou non des projets et peut éventuellement les réorienter.

21

I.2.3.2. Les projets stratégiques

L'IFACI (Institut Français de l'Audit et du Contrôle Interne) distingue cinq familles de projets stratégiques dont les enjeux sont importants pour l'entreprise :

· projets avec un engagement budgétaire élevé ;

· projets à objectif stratégique (lancement de nouveaux produits, respect de contraintes extérieures, fort retour sur investissement...) ;

· projets liés à l'organisation interne de l'entreprise (réorganisation des processus métiers, mise en place d'un ERP ...) ;

· projets liés à un changement de structure (fusion avec une autre entité, regroupement d'activités...) ;

· projets liés à de nouvelles technologies ou à des développements correspondant aux activités spécifiques de l'entreprise.

I.2.3.3. Les projets en difficultés

Les projets en difficultés sont identifiés sur la base d'alertes remontées par différents acteurs du projet (MOE, MOA, Direction informatique...) ou bien à l'aide d'indicateurs d'alertes (dépassement des délais, dépassement du budget, augmentation des ressources, nombre d'incidents...) portant sur chaque phase du projet.

I.2.3.4. Position des banques centrales européennes et banques centrales du G8

Dans une étude menée par le SEBC publiée en 2007, on constate que la majorité des banques centrales mènent des audits de projet informatique sur les projets stratégiques ou sensibles. On constate cependant que deux banques centrales (Japon et Suède) ne pratiquent pas d'audit de projet informatique.

^{Positionnement de l'audit informatique des BCN du G8 et des BCN du SEBC en 2007}

^{Projets strategiques ou}

^sensibles

^{Projets en difficulté}

^{Tous les projets}

^{Aucun projet}

^{0 2 4 6 8 10 12 14 16 18}

²

²

³

¹⁷

22

Figure 5 : Particularité des projets cibles d'audit I.2.4. À quel stade de leur vie auditer les projets retenus ?

Les projets une fois identifiés, il reste à déterminer le moment le plus opportun pour les auditer. Plusieurs options sont envisageables.

I.2.4.1. En permanence

L'audit permanent est peu pratiqué en entreprise. En effet, la présence de l'auditeur dans les instances de pilotage des projets est problématique et oblige l'auditeur à ne pas s'impliquer dans la gestion des projets afin de préserver son indépendance.

Un audit de projet suppose que l'auditeur ne dépende d'aucuns acteur ou structure du projet, mais également qu'il s'interdise d'assurer une fonction décisionnelle ou de prendre part aux spécifications ou réalisations au sein du projet. Ce n'est qu'à ces conditions qu'il pourra réaliser des travaux de contrôle et en rendre compte dans une situation de totale impartialité.

I.2.4.2. Lors des principales phases de la vie du projet

Les risques et dérives peuvent certes apparaître tout au long de la vie d'un projet, mais il est possible de distinguer un certain nombre de phases clés. Une intervention de l'audit à ces

23

moments clés permet de mieux cerner les risques auxquels les projets sont exposés afin de les réduire au mieux.

Étude préalable :

Les grandes orientations des projets sont prises en phase d'étude préalable, en effet les instances de pilotage décident :

· si on réalise le projet ou non : GO / NOGO ;

· définition générale de la solution (développement spécifique, progiciel) ;

· définition du scénario du projet (planning, sous-traitance...).

L'objectif d'un audit en phase d'étude préalable est d'être certain que les décisions seront prises sur de bonnes bases. Les recommandations peuvent mettre en évidence des manquements ou des risques qui se profilent.

Spécifications :

L'audit en phase de spécification peut porter sur la conduite de projet ou sur la qualité des livrables. Il analysera plus particulièrement les éléments qui sont susceptibles d'impacter les objectifs du projet :

· périmètre fonctionnel ;

· dossier de choix de solution ;

· planning, coûts et organisation.

Les résultats des audits peuvent amener à une réorientation du projet voire à l'arrêt si les dérives sont trop importante.

Recette :

Le projet est sur le point d'être mis en production. Il est donc terminé pour la MOE, mais pour la MOA une phase très sensible est sur le point de démarrer : l'intégration du produit dans le système informatique et l'interfaçage avec les autres applications de l'entreprise.

L'audit vérifiera que :

· toutes les conditions d'une mise en production réussie sont remplies ;

· le produit répond aux exigences fonctionnelles ;

·

24

les contrats d'interfaces avec les autres applications sont définis ;

· le plan de formation des utilisateurs est adéquat.

I.2.4.3. Le projet est terminé

L'audit du projet ne peut pas avoir de conséquences sur le projet puisqu'il est fini. Par définition, un projet est unique, l'objectif de l'audit est donc ailleurs.

· Si l'audit porte sur le projet et son déroulement, ses conclusions peuvent servir à l'amélioration de la méthode de gestion des projets, à un remaniement de l'organisation, à la décision d'externaliser les développements.

· Si l'audit porte sur le produit, les recommandations peuvent déboucher sur des actions de maintenances ou d'évolutions du système informatique, voire sur le démarrage d'un nouveau projet.

L'audit peut être déclenché dans les 3 à 6 mois après la fin du projet. Le travail est alors réalisé sur la documentation et complété par des interviews avec les anciennes équipes MOE et MOA ainsi que les actuels utilisateurs du produit.

L'audit d'un projet terminé est un retour d'expérience sur les des difficultés rencontrées ou sur les bonnes pratiques mises en place. L'audit permet ainsi à l'entreprise de capitaliser son expérience.

25

II. Stratégie d'audit des projets informatiques

II.1. Référentiels et recueils de bonnes pratiques

Afin d'aborder les différentes problématiques des projets informatiques, il existe une multitude de savoir-faire : des normes, des référentiels, des méthodes, des guides de bonne pratique, des corpus de connaissance, des livres blancs...

Pour mener définir la stratégie générique d'audit de projet informatique, nous allons analyser trois savoir-faire :

· CobiT (Control Objectives for Information and related Technology) pour identifier et gérer les risques et bénéfices des systèmes d'informations ;

· CMMI (Capability Maturity Model Integration) pour le développement de logiciels ;

· PMBOK (Project Management Body of Knowledge) pour la gestion de projets.

II.1.1. Control Objectives for Information and related Technology (CobiT)

II.1.1.1. Présentation du CobiT

CobiT est mis au point en 1998 par l'ISACA (Information System Audit & Control Association) et édité par l'ITGI (IT Governance Institute). CobiT est un référentiel qui établit les bonnes pratiques de contrôle interne liées à la maîtrise de l'information et des systèmes d'information

CobiT en version 4.1 paru en 2007, se compose de 4 publications :

· Executive summary : vue d'ensemble de la méthodologie CobiT. Cette synthèse présente les domaines, les objectifs de contrôles généraux (appelés processus) et le cadre de référence ;

· Framework : cadre de référence explicatif de la méthode, des domaines et des processus. Il se compose de 4 domaines, 34 processus et 210 objectifs de contrôle détaillés ;

· Control objectives : 210 objectifs de contrôle directement orientés vers le management et les équipes en charge du système d'information des services informatiques ;

·

26

« Management Guidelines » : le guide du management dispose d'un modèle de maturité pour évaluer, sur une échelle de cinq degrés, le niveau de maîtrise de chacun des processus de l'organisation.

CobiT a vocation d'être utilisé par :

· la direction pour laquelle il aide à peser les risques et contrôler les investissements dans un environnement informatique souvent difficile à prévoir. CobiT constitue un moyen d'aide à la décision ;

· les utilisateurs pour lesquels il permet d'obtenir des garanties concernant la sécurité et les contrôles des services informatiques fournies en interne ou par des tiers ;

· les auditeurs pour lesquels il permet de justifier leur opinion et d'appuyer leurs recommandations.

En effet, CobiT leur offre :

· le moyen d'évaluer les 34 processus des Technologies de l'Information (TI) par rapport aux meilleures pratiques du marché. À chaque processus on associe un modèle de maturité permettant de déterminer le niveau sur une échelle de 0 (inexistant) à 5 (optimisé). À chaque niveau on associe des facteurs clés de succès correspondant aux actions à prendre afin de s'améliorer ;

· des indicateurs clés afin de mettre en oeuvre de tableaux de bord pertinents. Il existe au sein de CobiT deux catégories d'indicateurs :

§ les indicateurs clés de succès (Key Goal Indicators) pour vérifier que les objectifs sont atteints. Ces indicateurs sont à utiliser par les dirigeants des TI ;

§ les indicateurs clés de performance (Key Performance Indicators) pour le suivi de la qualité des opérations. Ces indicateurs sont à surveiller par les équipes opérationnelles.

27

II.1.1.2. Architecture du CobiT

CobiT repose sur l'idée centrale que l'entreprise, pour réaliser ses objectifs, a besoin d'informations. Ces informations sont fournies par des ressources informatiques, qui doivent être gérées par un ensemble de processus naturellement regroupés.

CobiT regroupe 34 processus TI organisés en quatre domaines :

· le domaine « Planification et organisation » : 10 processus couvrant tout ce qui concerne la stratégie et les tactiques. Ils identifient les moyens permettant à l'informatique de contribuer le plus efficacement à la réalisation des objectifs de l'entreprise ;

· le domaine « Acquisition et implémentation » : 7 processus concernant la réalisation de la stratégie informatique, l'identification, l'acquisition, le développement, l'installation des solutions informatiques et leur intégration dans des processus de l'organisation ;

· le domaine « Distribution et support » : 13 processus regroupant la livraison des prestations informatiques exigées (l'exploitation, la sécurité, les plans d'urgences et la formation) ;

· le domaine « Surveillance » : 4 processus permettant à la direction d'évaluer la qualité et la conformité des processus du système d'information.

Figure 6 : Architecture du CobiT¹

28

À ces 34 processus correspondent 210 objectifs de contrôle pour lesquels des pratiques de contrôle détaillées ont été identifiées. CobiT décrit les éléments nécessaires à la bonne compréhension de chaque processus, précise les contrôles à effectuer, fournit des éléments pour évaluer la conformité aux bonnes pratiques et évaluer les risques associés.

1 Source www.afai.asso.fr CobiT version 4.1

29

II.1.2. Capability Maturity Model Integration (CMMI)

II.1.2.1. Présentation du CMMI

L'industrie logicielle a bien souvent été pointée du doigt pour son manque de fiabilité tant sur le plan du respect des délais que de la qualité des produits livrés. À tel point qu'au milieu des années 80, le département de la défense américain a lancé un appel d'offres pour l'élaboration d'un référentiel permettant d'évaluer la capacité de ses fournisseurs. L'université Carnegie Mellon, reconnue à l'époque pour l'excellence de son département informatique fût désignée pour mener ce travail et développa plusieurs modèles :

· SE-CMM (Systems Engineering) : ingénierie système ;

· SW-CMM (SoftWare) : développement logiciel ;

· SS-CMM (Supplier Sourcing) : gestion des fournisseurs ;

· SA-CMM (Software Acquisition) : méthodes d'acquisition des logiciels ;

· P-CMM (People) : processus de gestion du personnel.

En 2000, la version 1.0 du CMMI est publiée par le Software Engineering Institute (SEI) de Carnegie Mellon, cette première version consolide l'ensemble des modèles décrit si dessus. Aujourd'hui CMMI version 1.2 est un modèle de bonnes pratiques qui repose sur le principe de l'amélioration continue des processus de développement informatique de l'entreprise. Le modèle CMMI a pour objectif la maîtrise de la qualité des produits et des services, et par conséquent, la maîtrise des processus associés.

Pour cela, CMMI se compose de 22 domaines de processus (PA) qui contiennent chacun :

· des pratiques génériques permettant d'industrialiser les processus ;

· des pratiques spécifiques qui sont des buts à atteindre en termes d'organisation et qui se définissent par des résultats observables.

II.1.2.2. Architecture du CMMI

Les 22 PA décrits par le CMMI ont pour fonction d'initier un travail de réflexion et d'actions sur les processus organisationnels d'un projet informatique ou d'une organisation. Ces 22 domaines de processus sont regroupés au travers de 5 niveaux de maturité allant de 1 à 5, permettant d'évaluer le niveau de maîtrise des processus.

30

CMMI parle de représentation étagée des processus. La représentation étagée exprime l'évolution des pratiques de développement en fonction d'une vue organisationnelle. Chacun des niveaux est associé à la maîtrise, par tout le projet ou l'organisation, d'un ensemble de domaines de processus. Les niveaux de maturité vont du niveau 1 au niveau 5 avec un niveau

1 correspondant à l'état initial de l'organisation et un niveau 5 à celui d'une organisation optimisée. Pour qu'une organisation monte d'un niveau, il est nécessaire que l'ensemble des domaines de processus associés au niveau de maturité soit maîtrisé.

Figure 7 : Niveaux de maturité du CMMI²

Si l'organisation se dirige vers une meilleure maîtrise de ces processus de développement elle peut alors prétendre atteindre le niveau 2 dit « Discipliné ». Ensuite si l'organisation souhaite capitaliser sur les expériences précédentes en vue de s'améliorer alors elle rentre dans le cadre du niveau 3 dit « Ajusté ». Le niveau 4 suggère que l'organisation mette en oeuvre une approche de gestion quantitative pour tous ces projets de développement, cette approche est basée sur des analyses qui permettent de prévoir les performances de l'organisation. Enfin, le

2 Source CHRISSIS MB, KONRARD M, SHRUM S, CMMI 2ème édition, Pearson Education 2008

31

niveau 5 dit « optimisé » sous-entend que l'organisation est capable de s'améliorer continuellement.

Voici les niveaux de maturité auxquels sont associés les 22 domaines de processus du CMMI et leur description :

Niveau de maturité 2	Nom du PA Gestion de configuration		Description Établir et maintenir l'intégrité des produits de travail en utilisant l'identification de configuration, un contrôle de configuration, un registre des statuts de configuration, et des audits de configuration.	2
Mesure et analyse	Développer les possibilités de mesure qui sont employées pour soutenir les besoins de la gestion de l'information.		2
Surveillance et contrôle de projet	Fournir une analyse du progrès du projet de sorte que des modalités de reprise appropriées puissent être prises quand l'exécution du projet dévie de manière significative du plan.		2
Planification de projet	Établir et maintenir les plans qui définissent les activités du projet.		2
Assurance qualité produit et processus	Fournir au personnel et aux managers une vision objective sur les processus et produits de travail associés.		2
Gestion des exigences	Contrôler les exigences des produits du projet et de ses composants et identifier les contradictions entre ces conditions et les plans du projet et produits du travail.		2
Gestion des accords avec les fournisseurs	Contrôler l'acquisition des produits des fournisseurs pour lesquels il existe un accord formel.		3
Analyse et prise de décision	Étudier, selon des critères définis et selon un processus d'évaluation formel, plusieurs solutions possibles en vue d'une prise de décision.		3
Gestion de projet intégrée	L'intention de la gestion de projet intégrée est d'établir et maintenir le projet et l'implication des parties prenantes concernées en accord avec un processus intégré et ajusté qui est dérivé d'un ensemble de processus standards au niveau de l'organisation.		3
Définition du processus organisationnel	Définir et maintenir le référentiel de l'organisation.		3
Focalisation sur le processus organisationnel	Définir et mettre en oeuvre les améliorations du processus de l'organisation à partir de l'analyse des forces et des faiblesses des processus de l'organisation.		3
Formation organisationnelle	Développer les compétences des personnes pour leur permettre d'exercer leur mission avec efficacité.		3
Intégration du produit	Intégrer les composants produits, tester et livrer la solution.

32

Niveau de maturité 3	Nom du PA Développement exigences		Description Analyser et produire les exigences client, et celles induites sur le produit et ses composants.	3
Gestion des Risques	Identifier les problèmes potentiels avant qu'ils ne surviennent et prendre les actions préventives appropriées.		3
Solution Technique	Concevoir et développer la solution.		3
Validation	Démontrer que le produit ou composant, placé dans son environnement cible, répond aux exigences.		3
Vérification	Vérifier que les produits élémentaires sélectionnés sont conformes à leurs spécifications.		4
Performances du processus organisationnel	Mesurer les performances des processus de l'organisation et les analyser par rapport aux objectifs.		4
Gestion de projet quantitative	Gérer quantitativement les processus définis du projet pour atteindre la qualité voulue et les objectifs de performance.		5
Résolution et Analyse Causale	Identifier et supprimer les causes des défauts et problèmes pour éviter leur réapparition dans le futur.		5
Innovation et déploiement organisationnel	Sélectionner et mettre en oeuvre les améliorations et innovations qui impactent de façon mesurable les processus et technologies, et permettent à l'organisation d'atteindre ses objectifs de qualité et de performance.

II.1.2.3. Bénéfices apportés par la mise en place du CMMI

Le SEI a publié en 2007 une étude décrivant les avantages obtenus en termes de respect des délais et maîtrise des coûts par les entreprises ayant mis en place une démarche CMMI. En voici quelques exemples :

· Siemens Information Systems a réduit ses coûts de non-qualité de 45 % sur une période de trois ans pendant que l'organisation s'est déplacée du niveau de maturité 5 du SW-CMM vers le niveau de maturité 5 du CMMI ;

· Boeing a obtenu 3 % d'augmentation dans la réutilisation de codes sources et la réutilisation de matériels lorsque l'organisation a atteint le niveau de maturité 5 du CMMI ;

· la livraison dans les délais des projets IBM est passée de à 90 % à 99 % lorsque l'organisation s'est déplacée du niveau de maturité 3 du CMMI au niveau de maturité 5 du CMMI ;

·

33

chez Reuters, le décalage de planning des projets a été réduit approximativement de 15 % à 25 % pendant que l'organisation se déplaçait du niveau de maturité 3 du CMMI vers le niveau de maturité 5 du CMMI ;

· JP Morgan a réduit de 70 % à 80 % le décalage moyen des dates de livraison de projet lorsque l'organisation a atteint le niveau de maturité 2 du CMMI.

Cette étude présente les bénéfices obtenus par les organisations ayant mis en oeuvre une démarche CMMI en termes de coûts, de délais, de productivité, de qualité et de retour sur investissement. Voici les résultats compilés des 35 entreprises analysées par le SEI.

Figure 8 : bénéfices obtenus en mettant en oeuvre une démarche CMMI II.1.3. Project Management Body Of Knowledge (PMBOK)

II.1.3.1. Présentation du PMBOK

Le Project Management Body of Knowledge ou PMBOK, est élaboré par le PMI (Project Management Institute), il décrit l'ensemble des pratiques et techniques intervenant dans la gestion de projet.

La première édition est publiée en 1996 avec pour principal objectif de documenter et standardiser les informations et les pratiques de gestion de projet. La seconde édition est publiée en 2000 et la troisième, version actuelle, est publiée en 2004.

34

PMBOK est un standard reconnu internationalement (IEEE Std 1490-2003). PMBOK fournit les fondamentaux de la gestion de projet s'appliquant à une large portée de projets incluant le logiciel, mais aussi la construction, l'ingénierie et l'industrie ...

Le PMBOK sert également de support à la certification de chef de projet PMP (Project Management Professional). Il est actuellement décerné à plus de 180 000 chefs de projet dans près de 175 pays à travers le monde.

II.1.3.2. Architecture du PMBOK

Le corpus de connaissance PMBOK est élaboré sur la base des meilleures pratiques et des techniques avancées en gestion de projet. Il fournit un référentiel commun avec une terminologie précise et unifiée des phases, livrables et compétences nécessaires à la bonne gestion des projets.

Tous les aspects de la gestion de projet y sont traités avec une approche par processus qui permet de systématiser les meilleures pratiques et donc, de s'inscrire dans une logique d'amélioration continue.

Le guide PMBOK catégorise les processus en cinq groupes cohérents : « Démarrage », « Planification », « Réalisation », « Contrôle », et « Clôture ». Ces groupes se répètent dans chacune des phases du projet et leur mise en place est indispensable pour la réussite du projet. PMBOK traite tous les aspects de la gestion de projet à travers 44 processus regroupés dans 9 domaines de processus :

· le domaine « gestion de l'intégration » du projet décrit les processus et activités nécessaires à l'identification, la définition, la combinaison, l'unification et la coordination des divers processus et activités. Ce domaine est indispensable pour interfacer des processus qui sont en interaction avec d'autres processus ;

· le domaine « gestion du périmètre » du projet comprend les processus nécessaires pour garantir que le projet contienne les tâches nécessaires à sa réalisation et uniquement ces tâches là. Il se concentre essentiellement sur la définition et la maîtrise de ce qui fait partie ou non du projet ;

· le domaine « gestion des délais » du projet décrit les processus nécessaires pour assurer la réalisation du projet en temps voulu ;

·

35

le domaine « gestion des coûts » du projet décrit les processus de planification, d'estimation, de budgétisation et de maîtrise des coûts nécessaires pour s'assurer que le projet soit réalisé en respectant le budget alloué ;

· le domaine « gestion de la qualité » du projet décrit tous les processus et activités de l'entreprise réalisatrice qui déterminent la politique interne, les objectifs et les responsabilités en matière de qualité, afin que le projet réponde aux besoins et exigences exprimés par le client ;

· le domaine « gestion des ressources humaines » du projet décrit les processus nécessaires pour diriger et organiser l'équipe de projet ;

· le domaine « gestion de la communication » du projet décrit les processus nécessaires pour assurer en temps voulu et de façon appropriée la génération, la collecte, la diffusion, le stockage et le traitement des informations du projet. Ce domaine de processus apporte les liens indispensables entre les personnes et les informations ;

· le domaine « gestion des risques » du projet décrit les processus liés à la gestion des risques dans le cadre d'un projet. L'objectif de ce domaine est d'augmenter la probabilité et l'impact des événements positifs et de diminuer la probabilité et l'impact des événements défavorables au projet ;

· le domaine « gestion des approvisionnements » du projet décrit l'ensemble des processus nécessaires à l'acquisition de produits ou services, et les processus de gestion des contrats associés.

Figure 9 : domaines de processus et processus du PMBOK³

36

II.1.4. Des référentiels peu utilisés dans les organisations

La société de service informatique OSIATIS, dans une étude parue en 2005, analyse le taux de pénétration des référentiels, recueil de bonnes pratiques et normes de développement dans 176 entreprises françaises développant des logiciels pour un besoin interne ou en tant que prestataire de service.

3 Source : PMI Project Management Institute, PMBOK Guide Third Edition, Project Management Institute 2004

^{Méthodes internes}

^{Conduite de projet}

^{ISO 9001}

^Aucun

^Autre

^CMMI

^ITIL

^{0% 10% 20% 30% 40% 50% 60%}

^2%

^4%

^8%

^13%

^16%

^24%

^56%

37

Figure 10 : Utilisation des référentiels dans les entreprises

On constate que la majorité des entreprises en 2005 s'appuyaient encore sur une méthodologie de développement interne. Aujourd'hui, on assiste à une forte progression des référentiels dans les entreprises. Actuellement à la Banque de France, un projet majeur consiste en la refonte de la méthode interne de gestion de projet en s'appuyant sur la démarche CMMI de niveau 2 et 3. Cette tendance s'explique par le niveau de maturité atteint par ces référentiels, mais aussi par leur reconnaissance internationale. Les référentiels ont su démontrer leur efficacité grâce à la standardisation et l'industrialisation des processus, ainsi les retours d'expériences positifs et les gains de performance obtenus par les organisations favorisent une fois de plus leur adoption.

38

II.2. Complémentarité des référentiels

Parce qu'un référentiel ne couvre pas à lui seul les nombreuses spécificités d'un projet informatique, ou au contraire dépasse son périmètre, il est essentiel d'établir une démarche méthodologique visant à définir les thématiques indispensables à l'audit des projets informatiques à partir de la complémentarité des processus des référentiels CobiT, CMMI et PMBOK. Cette stratégie d'audit générique vise à définir un ensemble de points de contrôle permettant d'auditer exhaustivement et efficacement un projet informatique.

Nous utiliserons :

· CobiT pour définir le cadre d'audit des projets informatiques ;

· CMMI pour analyser les processus d'ingénierie logiciel ;

· PMBOK pour les meilleures pratiques de management de projets ;

L'analyse de la cartographie des risques des projets informatiques (cf annexe 2) et l'étude du domaine CobiT « Planification et organisation » permet de dégager trois axes essentiels à la réussite d'un projet informatique :

· alignement du projet sur la stratégie métier de l'entreprise et sur les choix des technologies de l'information ;

· qualité de la conduite de projet ;

· qualité du produit délivré par le projet.

II.2.1. Alignement du projet sur la stratégie métier de l'entreprise et sur les choix des technologies de l'information

II.2.1.1. Alignement du projet sur la stratégie Métier

L'opportunité du projet informatique pour l'organisation est un facteur clé de succès. En effet, comme abordé dans le chapitre I.1.4 « dérives et insuccès des projets informatiques », le projet doit avant tout être aligné sur la stratégie de l'entreprise et par conséquent être porté par un projet Métier. Le processus « PO1 définir un plan informatique stratégique » du CobiT traite des possibilités offertes par les TI et le besoin en TI de l'organisation.

L'étude de ce processus permet de définir les points de contrôle suivants :

·

39

justification fonctionnelle ou métier du projet informatique;

· bénéfices attendus par le produit délivré par le projet : prise en compte d'un nouveau besoin, augmentation de la capacité de traitement, diminution des ressources nécessaires ... ;

· alignement du projet informatique sur la stratégie organisationnelle de l'entreprise ;

· évaluation du niveau de compétences de la MOA du projet au regard des besoins métiers.

L'audit analysera ces points de contrôle durant la phase d'étude préalable afin de s'assurer de l'opportunité du projet pour l'organisation.

II.2.1.2. Alignement du projet sur la stratégie technologique

Les entreprises, face à la complexité croissante de leur système d'information et à l'augmentation exponentielle du volume d'information à traiter, mettent en place deux types de plans :

· plan d'urbanisation du système d'information, afin d'augmenter la cohérence et l'efficacité du SI ;

· plan stratégie informatique, afin d'aligner la stratégie informatique sur la stratégie de l'organisation, mais aussi pour rationaliser les technologies utilisées dans un objectif de réduction des coûts de maintenance.

Pour s'intégrer dans l'organisation, les projets informatiques doivent impérativement s'inscrire dans le cadre technologique défini par ces plans.

Grâce à l'étude du domaine de processus CobiT « PO3 déterminer l'orientation technologique » l'audit définit les points de contrôle suivants :

· l'alignement des technologies et les outils employés par le projet sur la stratégie informatique de l'organisation ;

· l'évaluation des technologies employées par le projet informatique en termes de maturité, pérennité, compatibilité et performance voulues ;

· les difficultés induites sur le projet par les choix des techniques imposés : contrainte de conformité à la stratégie informatique ;

· le niveau de compétence de la MOE sur les technologies sélectionnées par le projet et détections des besoins en formation.

40

Grâce à l'analyse de ces points de contrôle durant la phase d'étude préalable, l'audit s'assurera que le projet informatique est aligné sur la stratégie technologique de l'organisation.

A titre d'exemple, pour assurer la phase de réalisation du projet MIGTT2 (infrastructure d'accès au nouveau système de paiement de montants élevés du SEBC : TARGET2) reposant sur la technologie SWIFTNET (système international d'automatisation de traitement des opérations financières) la Banque de France a émis un appel d'offres pour sélectionner une SSII qui aura en charge cette phase. Lors du dépouillement des candidatures, la maîtrise de la technologie SWIFTNET ne figurait pas comme critère majeur pour la sélection du fournisseur.

De fait, le fournisseur retenu (SQLi) ne connaissait pas SWIFTNET, et sa nécessaire montée en compétences dans ce domaine a perturbé le démarrage de la prestation, avec, notamment, la livraison de premières versions qui présentaient de nombreuses anomalies.

L'appel à l'audit sur ce projet aurait permis de réorienter l'appel d'offres ou simplement de détecter avant le démarrage de la phase de réalisation le besoin en formation du fournisseur.

II.2.2. Qualité de la conduite de projet

La conduite de projet permet de mener un projet à son terme en prenant en compte ses contraintes et en faisant face aux imprévus. Les trois aspects représentés par le « triangle projet » (coûts, qualité, délais) doivent être mis sous contrôle. Chacun faisant l'objet d'une gestion spécifique qui prend en compte l'existence des deux autres.

Figure 11 : Triangle projet

L'analyse de la qualité de la conduite du projet par l'audit

vise à s'assurer de la maîtrise des objectifs, des moyens et des délais. L'audit étudiera si la conduite de projet est conforme à la méthodologie d'entreprise, à des normes internationales ou à l'état de l'art.

41

II.2.2.1. Maîtrise de la définition des exigences par le projet

La notion d'exigences désigne l'ensemble des besoins et contraintes exprimés par les différentes parties prenantes du projet. Les exigences portent sur les besoins des utilisateurs, y compris ceux relatifs aux critères de qualité du produit délivrée par le projet (sécurité, fiabilité, maintenabilité ...).

La gestion des exigences vise à assurer tout au long du projet que les exigences sont définies de manière précise, complète et cohérente, puis correctement prises en compte dans les travaux.

Pour s'assurer de la maîtrise de la gestion des exigences, l'audit durant les phases d'étude préalable et de spécifications fonctionnelles va analyser les points de contrôle suivants définis grâce à l'étude des domaines de processus « développement des exigences » CMMI niveau 3, « gestion des exigences » CMMI niveau 2 et « gestion du périmètre du projet » PMBOK :

· qualité des procédures de définition et de formalisme des exigences ;

· qualité des procédures de validation et vérification des exigences ;

· niveau de couverture fonctionnelle par les exigences (identification des exigences hors périmètre ou absente du périmètre du projet) ;

· qualité de la définition des interfaces entre les applications ;

· niveau de connaissance des exigences par les équipes projets ;

· qualité des procédés de traçabilité des exigences (mécanisme pour affecter les exigences aux composants du projet) ;

· qualité des procédures de gestions des évolutions (définition, étude d'impact, validation, gestion et prise en compte dans le planning projet) ;

II.2.2.2. Maîtrise des coûts du projet

Selon le domaine de processus « gestion des coûts » du PMBOK, la maîtrise des coûts repose sur trois processus :

· estimation des coûts : pour déterminer le coût approximatif des activités nécessaires à l'achèvement du projet ;

· budgétisation : pour agréger les estimations des coûts des activités du projet afin de fixer une base de référence ;

· maîtrise des coûts : pour maîtriser les modifications de budget du projet et influencer les facteurs générateurs d'écarts de coûts.

42

L'étude de ces processus permet de définir un ensemble de thèmes que l'audit analysera afin de s'assurer de la maîtrise des coûts :

· efficacité et précision des procédures d'estimation des coûts : étude des modèles utilisés, analyse comparative des modèles, analyse de la fréquence et de la qualité des ré-estimations ;

· réalisme du budget affecté ainsi que sa répartition entre les activités du projet ;

· qualité des indicateurs et des procédures de suivi budgétaire ;

· niveau de détail du suivi budgétaire, notion de : coûts estimés, coûts budgétés, coûts consommés ;

· identification des zones de dérives potentielles ;

· qualité de l'estimation du coût total du projet informatique.

II.2.2.3. Maîtrise des délais du projet

Le respect des délais, bien qu'intrinsèquement lié à la définition des coûts et à la maîtrise de la qualité, est un facteur clé de la réussite des projets informatiques, car la date de mise en production est soumise à des contraintes de temps qui bien souvent ne sont pas ajustables. Il convient donc de s'assurer de la précision de la procédure d'estimation des charges.

Pour s'assurer de la réalisation du projet en temps voulu, l'audit analysera durant les phases de spécifications, de réalisation et de recette les points suivants :

· efficacité et précision des procédures d'estimation de la durée des tâches : étude des modèles utilisés, analyse comparative (benchmark), fréquence et qualité des ré-estimations ;

· pertinence du cycle de vie du projet défini (principaux PLC en annexe 3) ;

· qualité du planning : les tâches prévues sont-elles en adéquation avec les objectifs du projet ? Le planning est-il complet ? est-il utilisable ?

· qualité du suivi du planning : le planning est-il utilisé comme un moyen de pilotage et d'anticipation ou simplement comme moyen de constat ;

· l'estimation des ressources est elle en adéquation avec les délais du projet ;

· qualité de l'estimation de la durée totale du projet informatique, identification des zones de dérives potentielles.

Ces points de contrôle sont définis grâce à l'analyse des domaines de processus CMMI de niveau 2 « surveillance et contrôle du projet » et « planification du projet ».

43

II.2.2.4. Qualité de la gestion des ressources humaines du projet

Gérer les ressources humaines à l'échelle d'un projet informatique consiste à recruter et conserver des collaborateurs compétents et motivés afin de travailler dans un but commun : la réussite du projet.

Les domaines de processus « gestion des ressources humaines » du PMBOK et « PO7 : gérer les ressources humaines de l'informatique » du CobiT permettent de définir les points de contrôle suivants :

· la qualité de la définition et l'attribution des rôles dans le projet ;

· l'adéquation des ressources humaines aux rôles et compétences nécessaire au projet et la nécessité de procéder à des formations ;

· la qualité de la planification des variations des ressources en fonction des phases du projet ;

· la qualité du processus de définition des objectifs, d'évaluation des performances et d'établissement des perspectives d'évolution des collaborateurs du projet.

L'audit analysera la gestion des ressources humaines à travers ces points de contrôle durant les phases de spécification et de recette afin de s'assurer de la gestion adéquate des ressources humaines.

II.2.2.5. Qualité de la gestion contractuelle avec les fournisseurs

Un contrat, pour être pleinement efficace, doit être équilibré. Il doit traduire l'esprit de collaboration dans lequel les parties cherchent à s'engager. Identifier clairement les zones de risques des relations contractuelles avec les fournisseurs est une préoccupation forte et connaître les moyens de s'en prémunir est une vraie nécessité pour les projets.

Grâce à l'étude des domaines de processus CMMI de niveau 2 « Gestion des accords avec les fournisseurs » et PMBOK « gestion des approvisionnements du projet », l'audit analysera en fin d'étude préalable les points de contrôle suivants :

· qualité du processus d'appel d'offres pour tout ou partie du projet ;

· pertinence et qualité des critères de sélection des fournisseurs ;

· qualité de l'administration contractuelle (vérifier l'application des engagements contractuels par le fournisseur, vérifier les clauses de pénalités, de garantie, de réversibilité...) ;

· qualité de la méthodologie de sous-traitance des projets informatiques au forfait ;

·

44

qualité du processus de gestion des prestataires intervenant sur le projet ;

· qualité des conditions d'acceptation des livrables du fournisseur ;

· qualité du critère d'évaluation du fournisseur en fin de projet.

II.2.2.6. Qualité de la gestion des risques du projet informatique

La maîtrise des risques constitue un facteur clé de succès des projets. En effet, un projet doit être en mesure d'identifier des problèmes potentiels avant qu'ils ne surviennent, de telle sorte que les activités pour les traiter puissent être planifiées et déclenchées au besoin tout au long du cycle de vie du projet afin que les impacts nuisibles à l'atteinte des objectifs soient atténués.

À travers l'analyse des domaines de processus :

· « PO9 : évaluer les risques » du CobitT ;

· « gestion des risques projet » du PMBOK ;

· « gestion des risques » du CMMI niveau 3.

Les points de contrôle suivants devront être analysés durant les principales phases du projet :

· qualité de la cartographie des risques ;

· qualité du processus de gestion des risques : complétude de la procédure (évaluer, catégoriser, et prioriser les risques), affectation des ressources, mise en place de procédures d'alerte et de prise de décision rapide ;

· efficacité du processus de gestion des risques et de la stratégie de réduction des risques : analyse des risques effectivement identifiés et gérés par rapport aux difficultés rencontrées sur le projet ;

· qualité du processus de surveillance des risques : suivre les risques identifiés, surveiller les risques résiduels, identifier les nouveaux risques.

II.2.2.7. Qualité de la communication sur le projet

La multiplicité des parties prenantes (cf : §I.1.3.4) sur un projet informatique doit s'accompagner de la maîtrise des canaux de communication. Il est essentiel d'avoir une vision commune des besoins et des attentes, mais surtout de pouvoir répondre à la question de qui a besoin de quelles informations, quand, comment les lui transmettre et qui les transmet ?

45

L'étude approfondie du domaine « gestion de la communication » du PMBOK et des processus associés permet d'établir les points de contrôle suivants que l'audit analysera principalement durant la phase de réalisation :

· planification de la communication : pour déterminer les besoins de communication et d'information des parties prenantes du projet ;

· qualité et efficacité des outils de communications utilisés par le projet : l'information nécessaire est-elle à disposition des parties prenantes du projet en temps voulu ?

· vérification du niveau de compréhension des objectifs communs du projet par l'ensemble des acteurs.

Le projet NExT, commandité par France Telecom et réalisé conjointement par Capgemini et Bull est un bel exemple sur les conséquences d'une communication projet non maîtrisée. En effet, sur le projet NExT, une mauvaise communication du commanditaire a entraîné plusieurs semaines de retard lors de la phase d'intégration. En effet, ce retard est dû aux changements apportés sur les modalités d'interfaçages entre les modules Capgemini et Bull qui n'ont été communiqués qu'à une des deux parties prenantes.

II.2.3. Qualité du produit délivré par le projet

L'audit de la qualité du produit délivré par le projet a pour objectif de vérifier l'adéquation entre les besoins des utilisateurs et le produit à livrer. L'audit peut porter sur les choix techniques, la sécurité de la future application, la pertinence de la démarche qualité mise en place par le projet, la qualité des développements, la qualité des processus de test et de validation...

II.2.3.1. Maîtrise de la démarche qualité du projet

À travers l'analyse des domaines de processus « assurance qualité processus et produit » CMMI niveau 2 et « gestion de la qualité du projet » du PMBOK et plus particulièrement des processus « planification de la qualité », « mettre en oeuvre l'assurance qualité » et « mettre en oeuvre le contrôle qualité », l'audit étudiera la démarche qualité mise en place par le projet. Pour cela, l'audit contrôlera, à partir de la phase d'étude préalable, les points suivants :

· pertinence du plan d'assurance qualité ;

· maîtrise des indicateurs qualité ;

· 46

maîtrise des procédures de contrôle qualité.

II.2.3.2. Qualité des processus de test et de validation

Les domaines de processus « vérification » et « validation » du CMMI de niveau 3 on pour objectif de s'assurer d'une part que le produit issu du projet répond aux spécifications définies, et d'autre part de démontrer que le produit une fois en production répond à l'utilisation prévue.

À ce titre l'audit analysera durant la phase de recette les points de contrôle suivants :

· qualité de la conception technique ;

· traçabilité et complétude entre les besoins et les spécifications fonctionnelles ;

· dimensionnement du plan de test : est ce que le projet a des moyens humains (planification des ressources, formation des ressources) et techniques (environnement de test, outils de test) adaptés pour vérifier et valider le projet ?

· couverture fonctionnelle et technique du plan de test : est-ce que le plan de test couvre les aspects fonctionnels, techniques, de performance, de maintenance et de sécurité du projet ?

· qualité des procédures de vérification : nombre d'anomalies projet, nombre d'incidents de production ;

· mise en place d'une base de connaissance des anomalies rencontrées afin de favoriser l'analyse causale.

Le projet EVCLI (système d'information de tenue des comptes du Trésor et de la clientèle conventionnée), commandité par la Banque de France et réalisé par le groupement Thales Temenos, a subi d'importants problèmes de performance, sans que leurs origines ne soient identifiées. Ce n'est que plusieurs mois après la mise en production du projet, lors de l'audit de l'application, que l'origine du problème a été identifiée. En effet, l'architecture technique du produit s'est avérée non conforme à la proposition contractuelle (la solution n'intègre pas nativement le SGBD Oracle contrairement à ce qui est indiqué dans la proposition commerciale).

L'audit du projet, et notamment le rapprochement du schéma d'architecture technique (SAT) avec l'architecture applicative proposée par le groupement lors de l'appel d'offres, aurait

47

permis d'identifier cette non-conformité et d'éviter l'abandon (pour cette raison ainsi que d'autres) d'une application qui aura coûté plus de 60 millions d'euros à la Banque de France.

II.2.3.3. Qualité de l'intégration du produit délivré par le projet

L'étude des domaines de processus « intégration de produit » CMMI niveau 3 et dans une moindre mesure « gestion de l'intégration du projet » PMBOK permet de définir un ensemble de points de contrôle permettant à l'audit de vérifier la capacité du produit délivré par le projet à fonctionner dans le système d'information de l'organisation.

L'audit pourra durant les principales phases (étude préalable, spécifications et recette) du projet à analyser :

· qualité de la planification de l'intégration ;

· qualité des procédures d'intégration du produit dans l'infrastructure technique ;

· qualité des procédures d'intégration du produit dans le système d'information ;

· maîtrise de l'interfaçage inter applicatif.

II.2.3.4. Qualité de la solution technique délivrée par le projet

L'audit en s'appuyant sur le domaine de processus CMMI de niveau 3 « solution technique » va s'assurer de la qualité des développements en contrôlant que la conception, la construction et l'implémentation du produit est conforme aux exigences préalablement définies.

Pour cela l'audit va analyser les points de contrôle suivants :

· robustesse de la solution : capacité de tolérances aux erreurs d'utilisation et aux défaillances du système ;

· fiabilité et disponibilité du produit ;

· évolutivité et maintenabilité du produit ;

· exploitabilité et administrabilité du produit ;

· performances du produit avec la volumétrie réelle ;

· qualité de la documentation : est-elle complète ? Est-elle à jour par rapport à l'état d'avancement du projet ? est-elle utilisable et compréhensible par les acteurs cibles ?

II.2.4. Vue d'ensemble

L'étude de la complémentarité des référentiels CobiT, PMBOK, CMMI nous permet de standardiser le programme d'audit de projet informatique de la manière suivante :

Thématiques d'audit Référentiels Phase projet

48

Alignement du projet sur la stratégie métier de l'entreprise et sur les choix des technologies de l'information

Alignement du projet sur la stratégie Métier
CobiT : PO1 définir un plan informatique stratégique	Etude préalable	Alignement du projet sur la stratégie technologique de l'organisation
CobiT : PO3 déterminer l'orientation technologique	Etude préalable
Qualité de la conduite de projet
Maîtrise de la définition des exigences par le projet
CMMI niveau 3 : développement des exigences CMMI niveau 2 : gestion des exigences PMBOK : gestion du périmètre du projet	Etude préalable, Spécifications	Maîtrise des coûts du projet
PMBOK : gestion des coûts	Etude préalable, Recette	Maîtrise des délais du projet
CMMI niveau 2 : planification du projet PMBOK : gestion des délais du projet	Etude préalable et Réalisation	Qualité de la gestion des ressources humaines du projet
PMBOK : gestion des ressources humaines CobiT PO7 : gérer les ressources humaines de l'informatique	Spécifications et Recette	Qualité de la gestion contractuelle avec les fournisseurs
CMMI niveau 2 : Gestion des accords avec les fournisseurs PMBOK : gestion des approvisionnements du projet	Etude préalable	Qualité de la gestion des risques du projet informatique
CobitT PO9 : évaluer les risques PMBOK : gestion des risques projets CMMI niveau 3 : gestion des risques	tout au long du cycle de vie du projet	Qualité de la communication sur le projet
PMBOK : gestion de la communication	tout au long du cycle de vie du projet
Qualité du produit délivré par le projet
Maîtrise de la démarche qualité du projet
CMMI niveau 2 : gestion de la qualité du projet PMBOK : gestion de la qualité du projet	Etude préalable	Qualité des processus de vérification et de validation
CMMI niveau 3 : vérification CMMI niveau 3 : validation	Recette	Qualité de l'intégration du produit délivré par le projet
CMMI niveau 3 : intégration de produit PMBOK : gestion de l'intégration du projet	Etude préalable, Spécifications, Recette	Qualité de la solution technique délivrée par le projet
CMMI niveau 3 : solution technique	Recette

Cette synthèse nous permet de mettre en évidence que le moment le plus opportun pour mener un audit de projet informatique est durant la phase d'étude préalable. En effet, les objectifs du projet et les moyens pour y parvenir sont alors clairement définis, et les réorientations faisant suite aux recommandations de l'audit sont toujours possibles.

49

Conclusion

Réaliser des audits de projets informatiques est primordial pour les entreprises dotées d'un système d'information complexe, évoluant dans un environnement de forte compétition économique, où les projets informatiques ont un enjeu stratégique.

En effet, l'audit permet de réorienter judicieusement un projet informatique à la dérive en :

· proposant des pistes d'amélioration rapidement implémentable afin de réorienter les faiblesses du management ;

· formulant des recommandations sur la stratégie de réalisation, en particulier sur l'adaptation du cycle de vie projet, le mode d'organisation, le découpage en lots fonctionnels du projet, afin de respecter au mieux les objectifs du projet.

Pour appréhender la complexité inhérente aux projets informatiques, la stratégie d'audit doit être bâtie autour d'un référentiel couvrant l'ensemble du périmètre, tout en prenant en compte les spécificités propres à chaque projet. Cependant, il n'existe pas de référentiel parfait, et tout l'enjeu réside dans la compréhension de la complémentarité qui peut exister entre tous les standards du marché.

L'étude de la complémentarité des référentiels CobiT, PMBOK et CMMI a permis de définir un ensemble de points de contrôle organisés autour de trois grands axes d'audit :

· alignement du projet sur la stratégie métier de l'entreprise et sur les choix des technologies de l'information ;

· qualité de la conduite de projet ;

· qualité du produit délivré par le projet.

L'analyse approfondie de ces axes d'audit au travers des processus des référentiels étudiés a permis de définir un ensemble de points de contrôle appropriés aux enjeux du projet et de l'organisation qui seront analysés durant la phase de réalisation de la mission.

L'audit des projets informatiques a pour mission de réorienter un projet à la dérive. Au delà de cet objectif apparent, la finalité profonde de l'audit de projet informatique est de constituer un réel outil de progression dans les organisations à travers l'optimisation des processus de développement et de conduite de projet.

50

Néanmoins, au regard des publications et des pratiques du domaine de l'audit, un élément pourtant essentiel à la réussite des projets n'est pas pris en compte : la compétence des acteurs du projet.

En effet, l'aptitude d'une personne à résoudre un problème, par la connaissance approfondie qu'elle possède dans un domaine constitue une compétence. Cette aptitude provient d'un ensemble de savoirs, d'attitudes et de capacités à agir qui ne sont pas mesurables au travers des référentiels étudiés.

En effet, deux projets s'inscrivant dans une même stratégie organisationnelle, ayant les mêmes processus de conduite de projet et de développement, peuvent obtenir des résultats significativement différents. Cela ne tient pas aux différences cognitives des personnes, mais à toute la valeur du patrimoine intangible de compétences qu'elles ont acquises au travers de leurs expériences.

Ainsi, pour couvrir en totalité la complexité d'un projet informatique, un nouvel axe d'audit peut être défini : la gestion des connaissances.

La gestion des connaissances est l'ensemble des méthodes et des techniques permettant de percevoir, d'identifier, d'analyser, d'organiser, de mémoriser, et de partager des connaissances entre les membres de l'organisation.

La volonté d'une organisation pour qu'un individu augmente son savoir et son expérience, ou encore développe de nouveaux talents et de nouvelles aptitudes, signifie avant tout s'inscrire dans une démarche d'amélioration continue et se traduit pour l'organisation en gain de productivité, en une meilleure maîtrise des décisions et des choix stratégiques, en vue d'atteindre les objectifs fixés.

51

Tables des illustrations

FIGURE 1 : PRINCIPAUX ECHANGES ENTRE MOA ET MOE 9

FIGURE 2 : ORGANISATION DES PRINCIPAUX ACTEURS DU PROJET 10

FIGURE 3 : SYSTEME D'INFORMATION ET AUDIT DE PROJET INFORMATIQUE 17

FIGURE 4: DEROULEMENT D'UNE MISSION D'AUDIT 20

FIGURE 5 : PARTICULARITE DES PROJETS CIBLES D'AUDIT 22

FIGURE 6 : ARCHITECTURE DU COBIT 28

FIGURE 7 : NIVEAUX DE MATURITE DU CMMI 30

FIGURE 8 : BENEFICES OBTENUS EN METTANT EN OEUVRE UNE DEMARCHE CMMI 33

FIGURE 9 : DOMAINES DE PROCESSUS ET PROCESSUS DU PMBOK 36

FIGURE 10 : UTILISATION DES REFERENTIELS DANS LES ENTREPRISES 37

FIGURE 11 : TRIANGLE PROJET 40

52

Annexes

Annexe 1 : cycle de vie d'un projet informatique à la Banque de France

53

Annexe 2 : liste des principaux risques des projets informatiques

Facteurs humains :

· mauvaise affectation des tâches ;

· non-définition précise du rôle des acteurs ;

· manque de motivation ;

· manque de communication ;

· conflits de personnes ;

· rétention d'informations ;

· règlement de compte ;

· indétermination du décideur financier du projet ;

· indétermination des acteurs du projet ;

· jalousies ;

· prises de décisions sans consultation du chef de projet ;

· vouloir faire plaisir à tout prix ;

· chef de projet inexpérimenté ;

· vouloir faire un chef-d'oeuvre.

Mauvais suivi du projet :

· glissement non maîtrisé à temps ;

· chemin critique non optimisé ;

· manque de réunions de validations ;

· trop de sous-traitance ;

· manque de date de validation des phases et des paiements.

Mauvaises spécifications :

· règles de gestion vagues, incomplètes, instables ;

· mauvaise analyse du besoin. ;

· mauvaise définition de la charte graphique ;

· mauvaise compréhension du système d'information ;

· obsolescence rapide du besoin (temps de retour sur investissement) ;

· cahier des charges incomplet.

Mauvaise réalisation :

· techniciens incompétents ;

· développement non optimisé ;

· tests partiels ;

· pas de groupe utilisateurs ;

· chef de projet toujours indisponible ;

· manque de moyens matériel ou logiciel ;

· contraintes négligées, mauvaise organisation des phases et étapes ;

· peu ou pas de documentation décrivant le fonctionnement du système informatique ;

· programmeurs inexpérimentés (formation sur le tas).

Mauvaise estimation :

· imprécisions en terme financier (sous évaluation) ;

·

54

délai imprécis ;

· sous évaluation du BFR (besoin en fonds de roulement) ;

· oublis des charges comme les communications, les fournitures, les déplacements, restaurants.

Annexe 3 : Liste des principaux cycles de vie des projets informatiques4

4 Source : CHARVAT J, Project Management Methodologies, Wiley 2003

55

Glossaire

BCN		Banque Centrale Nationale.	CMMI
Capability Maturity Model Integration.		CobiT
Control Objectives for Information and related Technology.		DOSI
Direction de l'Organisation et des Systèmes d'Information		IEEE
Institute of Electrical and Electronics Engineers.		ISO
International Organization for Standardization		MOA
Maitrise d'ouvrage.		MOE
Maitrise d'oeuvre.		PA
Process Area.		P-CMM
People Capability Maturity Model.		PLC
Project Life Cycle.		PMBOK
Project management body of knowledge.		PMI
Project Management Institute.		PMP
Project Management Professional.		Procédé
Désigne une méthode utilisée en vue d'obtenir un résultat déterminé.		Procédure
Désigne un ensemble de règles auxquelles il faut se soumettre, dans une situation déterminée.		Processus
Désigne un ensemble d'opérations successives, organisées en vue d'un résultat déterminé.		SAT
Schéma d'Architecture Technique.		SEBC
Système Européen de Banque Centrale.		SEI
Software Engineering Institute.		SGBD
Système de Gestion de Base de Données.		SI
Système d'Information.		SSII
Société de Service en Ingénierie Informatique.		TI
Technologie de l'Information.

56

Bibliographie et autres sources

Ouvrages :

· PERSSE J, Process Improvement Essentials, O'Reilly 2006.

· MORLEY C, HUGUES J, LEBLANC B, HUGUES O, Processus métiers et systèmes d'information, Dunod, 2004.

· GEORGEL F, IT Gouvernance : maîtrise d'un système d'information, Dunod 2005.

· CHARVAT J, Project Management Methodologies, Wiley 2003.

· AIM R, La Gestion de Projet Introduction historique - Concept de projet - Méthodes de gestion - Structure organisationnelle - Communication, Gualino 2007.

· BOUTINET JP, Psychologie des conduites à projet, PUF, 1993.

· BOUTINET JP, Anthropologie du projet, PUF, 2005.

· CHRISSIS MB, KONRARD M, SHRUM S, CMMI 2ème édition, Pearson Education 2008.

· SCAMPI Upgrade Team, Standard CMMI Appraisal Method for Process Improvement, SEI 2006

· PMI Project Management Institute, PMBOK Guide Third Edition, Project Management Institute 2004.

· IT governance Institute, CobiT v 4.1, IT governance institute 2007.

· IT governance Institute, Mapping of CMMI v1.2 and CobiT 4.0, IT governance institute 2006.

· BALMISSE G, Guide des outils du Knowledge management, Broché 2004

· LEVY A, La gouvernance des savoirs, Broché 2003

Sites internet :

· www.theiia.org Institute of Internal Auditors.

· www.ifaci.com Institut Français de l'Audit et du Contrôle Interne.

· www.isaca.org Internal Systems Audit and Control Association.

· www.afai.asso.fr Association française de l'audit et du conseil informatique.

· www.itgi.org IT Governance Institute

· www.sei.cmu.edu Software Engineering Institute.

· www.cigref.fr Club informatique des grandes entreprises françaises.

·

57

www.pmi.org Projet Management Institute

· www.pmi-fr.org Partie française du Project Management Institute.

· www.ogc.gov.uk Ensemble d'ouvrages ITIL.

Documentation interne à la Banque de France:

· Méthodologie interne (Melodic).

· Support de formation (audit de projet informatique).

· Bilan missions d'audit.

Documentation interne à l'entreprise Capgemini :

· Méthodologie interne (Deliver).

· Support de formation (gestion de projet informatique).

Cours :

· ISC Paris, Audit interne et ingénierie des organisations, Mr Liottier

· EPSI, Gestion de projet, Mr Goy