Master Contrôle de Gestion et Système D’information

Module : Audit informatique et opérationnel

Elaboré par ; Sous la direction de ;

Mohamed EL MOUATADIL Mr. BOURMA
(Professeur à la FSJES)
Promotion 2015 – 2016

0
AP : audit des projets

PAQ : Le plan assurance qualité

1
Liste des abréviations
Sommaire
INRODUCTION
Partie I : Le déroulement d’une mission d’audit du projet
I. La phase préliminaire ou la phase de préparation de la mission
1. Prendre connaissance des caractéristiques du projet
2. Identifier les risques
3. Préparer la phase suivante
II. La phase de réalisation de l’audit
1. Contrôler les risques afférents aux études d’avant-projet
2. Contrôler les risques liés à l’organisation, aux ressources et aux contrats de
prestations de service
3. Contrôler les risques liés au management des équipes
4. Contrôler les risques liés aux revues du projet
III. La phase de synthèse et de rédaction du rapport

Partie II : Les points de contrôle d’un audit du projet

I. OBJECTIFS ET ENJEUX DU PROJET
II. ÉTUDE D’OPPORTUNITE ET EXPRESSION DES BESOINS
III. PLANIFICATION
IV. INSTANCES DE PILOTAGE
V. METHODES ET OUTILS
VI. PLAN ASSURANCE QUALITE
VII. CONCEPTION GENERALE ET ANALYSE
VIII. CONCEPTION DETAILLEE
IX. DEVELOPPEMENT, REALISATION OU PARAMETRAGE
X. QUALIFICATION : TEST/RECETTE
XI. CONDUITE DU CHANGEMENT ET MISE EN OEUVRE
XII. DOCUMENTATION
XIII. ROLES ET RESPONSABILITES
XIV. GESTION DES EVOLUTIONS
XV. MISE EN PRODUCTION

Partie III : Etude de cas

I. Entreprise A
II. Entreprise B

CONCLUSION
BIBLIOGRAPHIE

2
Introduction
Alors que l’audit est un examen des informations relatives à la gestion de chaque
fonction d’une entité en vue d’exprimer une opinion responsable et indépendante,
par référence aux critères de régularité, de fiabilité et d’efficacité.

L’audit opérationnel est donc un examen des instruments dont dispose la direction
de l’entité pour la contrôler et la gérer. Les objectifs principaux de l’audit
opérationnel sont de s’assurer :
 Que les organisations sont efficaces,
 Que les instructions de la direction sont appliquées,
 Que les procédures mises en place comportent les sécurités suffisantes,
 Que les informations fournies à la direction sont sincères,
 Que les opérations réalisées sont régulières.

Il peut y avoir par conséquent autant d’audits qu’il existe de fonctions dans
l’entreprise. A titre d’exemple (et sans être exhaustif), on peut citer : l’audit
marketing, l’audit trésorerie, l’audit de informatique, l’audit de projet etc.
Et on va s’intéresser plus précisément à un audit très particulier C’est l’audit de
projet
On appelle projet l'ensemble des actions à entreprendre afin de répondre à un
besoin défini dans des délais fixés. Ainsi un projet étant une action temporaire avec
un début et une fin, mobilisant des ressources identifiées (humaines et matérielles)
durant sa réalisation, celui-ci possède également un coût et fait donc l'objet d'une
budgétisation de moyens et d'un bilan indépendant de celui de l'entreprise. On
appelle «livrables» les résultats attendus du projet.

La difficulté dans la conduite du projet réside en grande partie dans la multiplicité des
acteurs qu'il mobilise. En effet, contrairement aux projets personnels ou aux projets

3
internes à faible envergure pour lesquels le besoin et la réponse à ce besoin peuvent
être réalisés par la même personne ou par un nombre limité d'intervenants, dans un
projet au sens professionnel du terme, l'expression du besoin et la satisfaction de ce
besoin sont portés par des acteurs généralement distincts.

Le premier objet d’une mission d’audit de projet est d’évaluer la manière dont les
risques sont maîtrisés pour répondre de manière satisfaisante aux spécifications de
coûts, de délais et de performances techniques fixées par le commanditaire1. Les
caractéristiques de ces démarches d’exception contraignent l’auditeur à porter un
jugement sur une réalité mouvante, exercice délicat qui se démarque des missions de
contrôle des activités récurrentes de l’entreprise. Pour ce type d’audit, il convient en
effet de faire la part des choses entre les ajustements liés à des événements qui
n’étaient pas prévisibles – par exemple le lancement sur le marché d’une nouvelle
technologie ayant un impact sur la solution retenue pour le projet –, et les
ajustements qui relèvent de la seule responsabilité du management du projet – par
exemple la faiblesse des procédures de pilotage. La « méthodologie » de l’audit est le
cheminement simple mais rationnel qui aidera l’auditeur à conduire sa démarche de
contrôle.

 Question de recherche :

Comment peut-on auditer un Projet ? Et quelles sont les clés de contrôle

nécessaire ?

4
Partie I : Le déroulement de la mission
d’audit
Elle se décompose généralement en trois phases :
• la phase d’étude préliminaire, qui comprend la prise de connaissance de l’entité à
contrôler, le dépistage des risques et l’orientation de la mission ;
• la phase de réalisation de l’audit à proprement parler (exécution des travaux de
contrôle) ;
• la phase de conclusion de la mission (synthèse, présentation orale et rédaction du
rapport).

I. La phase préliminaire ou la phase de préparation de la mission

La démarche commence par un ordre de mission dont la forme et le contenu varient
en fonction du contexte d’intervention. Il s’agit le plus souvent d’un document
sommaire informant les responsables concernés de l’objet, des circonstances et du
calendrier de l’intervention. L’ordre de mission est suivi d’un premier contact avec les
responsables du projet pour leur présenter la démarche projetée, mais surtout pour
obtenir de leur part le « passeport » nécessaire à la suite des opérations.
La détection des risques du projet passe par une phase de reconnaissance des
différents domaines doublée d’un examen critique de l’organisation, des procédures
et des processus mis en œuvre par les entités auditées. Les objectifs de pré-audit
pour un projet d’une importance significative sont les suivants :

1. Prendre connaissance des caractéristiques du projet

La présentation du projet doit logiquement constituer le thème central des premiers

échanges avec les responsables de l’entité auditée. En ce début de mission, il s’agit de
s’informer, à grands traits seulement, sur l’histoire, les caractéristiques générales et
techniques (choix de la solution), et l’état d’avancement du projet de façon à :

• Situer le projet dans son environnement pour en comprendre les enjeux

Les auditeurs vont s’interroger sur les origines du projet, lesquelles doivent pouvoir
se raccorder avec les objectifs généraux de l’entreprise. Pour les projets à dominante
stratégique (forts enjeux de développement ou d’organisation), ils seront amenés à
étudier le cadre de planification de l’entreprise.

5
 • Connaître l’organisation et les équipes

Les auditeurs se feront présenter la structure d’organisation du projet qui a été

retenue et les raisons de ce choix. S’agit-il d’une simple structure de coordination ou
d’une structure de direction à part entière ?

Ils se feront présenter la composition des équipes de maîtrise d’ouvrage et de

maîtrise d’œuvre et les fonctions assurées par leurs membres. Ils prendront la
mesure de l'importance de la sous-traitance.

• Connaître les phases et les domaines du projet

Les auditeurs vont devoir se familiariser avec l’architecture du projet (critères

techniques ayant déterminé les choix de découpage).

• Connaître le dispositif contractuel

Les auditeurs se feront préciser les moyens de la fonction juridique ainsi que la
réglementation propre au secteur d’intervention du projet (s’il en existe une) et les
règles applicables à la passation des marchés de prestations de service.

• Connaître les coûts, le budget et la rentabilité du projet

Les auditeurs demanderont communication des principaux éléments du programme

d’investissements, des prévisions budgétaires et de leur actualisation, ainsi que des
principaux éléments du dossier d’estimation de la rentabilité du projet (coûts
rapportés aux gains de productivité escomptés).

• Connaître les supports matériels du projet

Il s’agira de savoir si le projet bénéficie d’une organisation matérielle spécifique et,

dans l’affirmative, de se faire préciser les caractéristiques de cette organisation.

• Connaître le mode de management du projet

Les auditeurs vont chercher à apprécier les fonctions de pilotage opérationnel et de

gestion (système de planification des tâches et de contrôle d’avancement) au regard
des risques qu’elles font courir au projet.

• Connaître les caractéristiques du système de maîtrise des risques

Il conviendra de porter une première appréciation sur l’organisation et les

procédures de contrôle en se focalisant sur les éléments suivants :

6
- existence d’un plan d’organisation et de cahiers de procédures définissant les
champs d’intervention de chacun (système organisé de délégations de pouvoirs) et
les critères de séparation des tâches réputées les plus sensibles,
- permanence du système d’analyse des risques qui doit faire partie intégrante du
dispositif de management du projet,
- instauration d’un système de contrôle d’avancement rattaché au niveau du chef de
projet mais rapportant également à un autre échelon de l’entreprise (contrôle de
gestion central par exemple).

2. Identifier les risques

Cette première analyse des risques sert à définir les pistes d’exploration à partir
desquelles le véritable effort de diagnostic sera mis en œuvre.
L’attention et les moyens se concentreront alors sur les secteurs d’activité où les
risques de défaillance sont significatifs. L’enjeu doit en valoir la peine. Pour cette
raison, il est nécessaire de classer les risques par ordre d’importance.
Les auditeurs peuvent élaborer leur pré-diagnostic en s’appuyant sur des grilles
d’analyse des risques de défaillance du projet. Le tableau ci-dessous fait référence à
un projet informatique comportant de forts enjeux d’organisation (introduction d’une
gestion par processus par exemple).

Objet d’audit Nature Cause Impact Nature

du risque apparente probable du contrôle
Pilotage de la Les besoins Faiblesse Les recettes Vérifier :
phase de toutes les de la maîtrise fonctionnelles - le contenu du
de réalisation parties d’ouvrage ne couvrent cahier
et de tests du prenantes aux ayant abouti pas des charges,
projet. différents à une tous les - les échanges
processus insuffisance services entre la
ne semblent de cadrage concernés. maîtrise
pas du projet. d’œuvre et les
avoir été pris utilisateurs.
en compte.

3. Préparer la phase suivante

Lorsque les risques potentiels ont pu être identifiés et ont fait l’objet d’un début
d’analyse, il est alors possible de fixer la prochaine étape de la mission en définissant
les axes et les limites. Tel est l’objectif assigné à la note d’orientations des travaux de

7
contrôle. Après validation, ce document permet d’élaborer le programme de travail
de la phase de réalisation de l’audit.

II. La phase de réalisation de l’audit

Cette phase est l’occasion d’accumuler les preuves nécessaires à la crédibilité des
constats des auditeurs et de s’assurer du fondement des affirmations des personnes
interviewées. Le programme de vérifications comprend les points de contrôle et
d’examen détaillé ainsi que leurs modalités de mise en œuvre pour les activités
réputées sensibles du projet. Il formalise les engagements réciproques au sein de
l’équipe d’audit et permet d’élaborer le planning et le budget définitif de
l’intervention, ce qui revient à organiser la mission dans le temps jusqu’à la diffusion
du rapport.
À ce stade de la mission, les faiblesses révélées ne sont plus des « présomptions »,
mais de véritables constats dont il convient d’analyser les causes et les conséquences
dans une perspective de résolution du problème.
Le cadre imparti à cet article nous limite à une présentation schématique et
synthétique de quelques types de risque auxquels les auditeurs sont confrontés de
manière récurrente. La présentation ne prétend donc pas à l’exhaustivité. Notons
enfin que les risques peuvent concerner une seule phase, un seul domaine du projet
ou avoir des conséquences en chaîne sur les phases successives et les domaines
respectifs du projet. Lors de cette phase d’audit, les auditeurs devront :

1. Contrôler les risques afférents aux études d’avant-projet

La valeur des études conditionne le fondement des décisions prises lors des premiers
jalons, comme elle garantit la fiabilité des données de cadrage pour les phases
d’étude détaillée et de réalisation du projet.
C’est dire l’attention qu’il convient de leur porter. Pourtant, les projets informatiques
sont régulièrement confrontés à des difficultés qui proviennent d’une faiblesse de la
définition des besoins fonctionnels et des choix d’organisation et de moyens.

• Les risques de la phase d’étude d’opportunité

Le risque de devoir composer avec des données insuffisantes pour la phase suivante a
souvent pour origine une mauvaise appréciation de l’environnement du projet. Les
conséquences organisationnelles du choix stratégique que constitue un projet
informatique d’importance significative peuvent être mésestimées, alors que les
structures et les capacités actuelles de management de l’entreprise sont parvenues à
leurs limites.

8
La faiblesse des premières études peut avoir d’autres causes, par exemple : absence
de participation de certains services, absence de consensus autour des finalités
recherchées liées à une moindre implication du commanditaire, mauvaise définition
des besoins qui résulte d’une faiblesse de l’analyse fonctionnelle, maîtrise
insuffisante des prestataires (études réalisées en sous-traitance).

• Les risques de la phase d’étude préalable

Les manifestations d’études préalables qui n’ont pas été menées avec la rigueur ou
les moyens souhaitables se constatent à différents endroits : tâches mal identifiées et
non valorisées, aspects délaissés (fonctions supports notamment), date de fin de
projet qui ne se justifie pas sur un plan technique, budget estimé sur la base d’une
analyse insuffisante des coûts, spécifications fonctionnelles imprécises, solution
technique mal adaptée au système en place, etc.

2. Contrôler les risques liés à l’organisation, aux ressources et aux contrats de

prestations de service

L’organisation et les moyens de fonctionnement induisent un certain nombre de

risques dont certains sont spécifiques à la conduite des projets.

• La répartition des tâches

Une faiblesse de définition des rôles des intervenants peut entraîner des risques de
confusion entre les missions relevant de la maîtrise d’ouvrage, de la maîtrise d’œuvre
et des autres intervenants. Une confusion des rôles et notamment un empiétement
de la maîtrise d’ouvrage sur les tâches de la maîtrise d’œuvre augmente les risques
d’aboutir à des choix techniques inappropriés.
À l’inverse, un empiétement de la maîtrise d’œuvre sur la maîtrise d’ouvrage peut
faire dériver le projet loin de ses objectifs premiers et entraîner une inflation des
études et des coûts. Ces risques peuvent également engendrer des différends et
parfois même des contentieux si les fonctions évoquées impliquent plusieurs entités
juridiques distinctes.

• Les ressources humaines

Le risque majeur sur ce point est de ne pas pouvoir disposer des compétences
nécessaires au moment où il le faudrait. Ce risque menace tous les domaines du
projet. Il peut survenir à n’importe quel moment si la gestion des ressources
humaines n’est pas bien adaptée aux contraintes spécifiques du projet ou si le mode
de management du projet convient mal à l’équipe.

9
 • Les risques liés aux contrats du projet

On mentionnera uniquement l’absence d’assistance juridique qui aboutit notamment

à des faiblesses de rédaction : par exemple, les spécifications sont imprécises et
peuvent prêter à équivoque pour un cocontractant.

3. Contrôler les risques liés au management des équipes

Le premier facteur de risque en ce domaine est un chef de projet dont le profil n’est
pas adapté aux exigences qu’implique la conduite de ses équipiers. Les insuffisances
d’un mode de management en décalage par rapport à l’action et aux attentes des
membres de l’équipe engendre une incapacité de réaction collective (recherche de
solutions dans l’urgence) face à la survenance d’un dysfonctionnement ou à
l’indisponibilité d’une ressource.

4. Contrôler les risques liés aux revues du projet

Les facteurs de risques sont liés à la composition des instances d’évaluation et au

mode de fonctionnement des revues. Par exemple :
- le commanditaire et son maître d’ouvrage ne sont pas représentés au niveau de
délégation requis pour pouvoir prendre les décisions ; en fait, les décisions se
prennent ailleurs ;
- les chargés d’évaluation ne sont pas indépendants vis-à-vis des équipes de projet ;
- la définition des objectifs, l’organisation et le fonctionnement même des revues ne
sont pas satisfaisants.
Ceci entraîne notamment :
* la détection tardive des problèmes,
* l’incapacité à pouvoir arbitrer sur le fond les priorités du projet,
* l’opacité de la démarche pour les instances décisionnaires (faiblesse du reporting),
* le changement fréquent de cap.

III. La phase de synthèse et de rédaction du rapport

Il s’agit de la phase de conclusion de la mission : les notes prises en entretien, l’étude
de la documentation et des procédures recueillies, le contrôle des dossiers et des
systèmes d’informations ont permis de constituer un dossier dont le volume est
important.
Les auditeurs doivent à présent structurer leur réflexion. Il convient de classer les
idées et les faits, en fonction de leur importance, de les regrouper par thème et de
travailler à l’élaboration du plan détaillé du rapport d’audit.

10
  Méthodologie POISE :

Planifier O b t e n i r et Identifier les Suggérer un plan Évaluer la

EVALUER
SUGGERER
OBTENIR
PLANIFIER

IDENTIFIER
le vérifier d e s moyens de d’actions performance des
processus rapports e t des contrôle et les correctives actions
d’audit informations faiblesses correctives
comme étant des implantées
preuves écrites

11
Parti II : Les points de contrôle de l’audit de projet
En générale il existe 15 Points de contrôle si on parle de l’audit de projet quel que soit
la nature de projet on prend par exemple l’audit d’un projet informatique.

I. OBJECTIFS ET ENJEUX DU PROJET

Un projet est un ensemble de tâches interdépendantes concourant à la réalisation

d’un objectif prédéfini et mesurable, avec des spécifications, des contraintes, des
moyens humains, financiers et matériels, des délais (un début, une fin) et des risques.
Un projet informatique produit généralement de nouvelles applications et/ou
maintien des applications existantes. Il peut aussi s’agir d’un renouvellement
matériel majeur.

La conduite de projet est un ensemble de processus permettant de maîtriser la

réalisation d’un projet et de la mener à terme.

Cette maîtrise passe par un découpage du projet en processus, étapes, phases,

activités et tâches. Il est indispensable d’avoir une définition claire des entrées des
processus, des phases et étapes, des productions attendues et des conditions de
passage d’une phase à l’autre. Le rôle et les responsabilités des acteurs doivent être
clairement définis.

Il faut vérifier :
 Les objectifs et périmètres du projet sont définis, partagés et stabilisés.
 Les principales orientations du système cible ont été explicitées.
 Les principaux acteurs sont identifiés.
 Les coûts sont évalués.
 Les liens et impacts avec des projets connexes et les infrastructures (Datacenter, réseaux, etc.)
sont pris en compte.
 Etc.
Documents à récupérer
o étude de la valeur et d'opportunité,
o liste des processus impactés,
o manuel utilisateur,
o manuel d'exploitation,
o dossier d'organisation de la reprise des données,
o Etc.

II. ÉTUDE D’OPPORTUNITE ET EXPRESSION DES BESOINS

L’étude d’opportunité et l’expression des besoins sont les deux premières phases
d’un projet. Elles font émerger les motivations et les raisons de la mise en œuvre du
projet. L’étude d’opportunité est généralement suivie d’une étude d’impacts.

12
Il s’agit d’analyser les dysfonctionnements du système actuel pour, au final, disposer
d’une description unique et partagée par tous, de la description de l’ensemble des
besoins à satisfaire (évolutions de l’existant ou nouveaux besoins). Les différents
scénarios de solution ainsi que des fourchettes de coûts associés doivent être
élaborés.

Il faut vérifier :
 Le cahier des charges préconise une solution fonctionnellement et techniquement pertinente
au regard des besoins exprimés.
 Les exigences utilisateurs, les populations ciblées, les options et principes de gestion retenus
sont précisés et priorisés.
 Le projet est cohérent avec le plan directeur informatique.
 Le projet est cohérent avec le SI actuel ou futur.
 La direction est bien impliquée dans le projet.
 Les acteurs de l'équipe projet et leurs responsabilités sont bien identifiés.
 Les compétences du personnel sont en adéquation avec les tâches.
 Une étude d'opportunité est validée.
 Ce document comprend les objectifs du projet.
 Etc.

III. PLANIFICATION

L’organisation doit être en mesure d’évaluer, d’organiser et de planifier la

réalisation des travaux à venir. La mutualisation des ressources, tant au sein
de la DSI que pour les entités métiers, est devenue une nécessité.

Il est nécessaire de contrôler si l’organisation est en mesure de planifier de manière

cohérente l’utilisation de ses ressources.

Il faut vérifier :
 Il existe un planning directeur commun à tout le projet.
 Il existe un plan de projet initial.
 Ce plan de projet a été révisé.
 Il existe des plans détaillés.
 Ces plans ont été révisés.
 Les plans intègrent une gestion optimale des ressources.
 Il existe une évaluation des risques liés à la nature du projet.
 Il existe une évaluation des risques liés à la technologie utilisée.
 Il existe une évaluation des risques liés aux projets en cours.
 Il existe une évaluation des risques liés aux délais.
 Il existe une évaluation des risques liés à la synchronisation des
activités.
Documents à récupérer
o macro planning du projet,
o plan de projet détaillé,
o documents de suivi des risques.

13
IV. INSTANCES DE PILOTAGE

Différentes instances de pilotage sont mises en place pour accompagner un

projet. Le choix des indicateurs et le formalisme du reporting jouent un rôle
important lors des prises de décision. Les comités de suivi de projet sont
généralement au nombre de trois comités :

 Comité de pilotage (parfois appelé comité directeur) :

Instance de décision et de pilotage stratégique du projet (lancement, suivi du
développement de la solution, conduite du changement et mise en œuvre,
management du projet, arbitrage, allocation de ressources…) ;

 Comité de projet (parfois appelé comité de pilotage) :

Instance de pilotage opérationnel du projet agissant pour le compte du comité
de pilotage, comprenant des représentants de la maîtrise d'œuvre (y compris
prestataires) ;

 Comité des utilisateurs :

instance chargée de l'expression détaillée des besoins et des règles de
gestion,

de la validation des dossiers de conception présentés par l'équipe projet,

de la participation aux tests du système, à l'élaboration de la

documentation « utilisateurs », aux actions de formation,

de la réception définitive du logiciel.

Il faut vérifier :
 La structure de pilotage est formalisée et connue de tous les acteurs.
 Les différentes instances de pilotage connaissent leurs niveaux de délégation.
 Les objectifs des délégations sont atteints.
 Il existe un comité de pilotage.
 Il existe un comité de projet.
 Il existe un comité des utilisateurs ou, a minima, une participation des utilisateurs.
 Les participants aux différents comités sont représentatifs et ont le bon niveau de décision.
 Il existe des indicateurs de suivi du projet.
 Etc.
Documents à récupérer
o liste des instances de pilotage,
o liste des participants avec leurs fonctions,
o tableaux de bord ou indicateurs du projet.

14
 V. METHODES ET OUTILS

L’utilisation d’une méthode précise, connue et partagée impose un découpage

du processus de développement en sous-ensembles maîtrisables, identifie les
tâches et produits associés ainsi que les points de contrôle et, enfin, fournit un
vocabulaire commun pour l’ensemble des parties prenantes.

L’auditeur doit veiller à l’utilisation par l’équipe projet d’un cadre de référence
méthodologique. Les principales difficultés rencontrées sont le manque
d’homogénéité des livrables, la difficulté d’utilisation de la méthode et
l’incompatibilité des outils en place avec la méthode.

Il faut vérifier :
 Il existe une méthode de conduite de projet et celle-ci est appliquée.
 La méthode repose sur un découpage des projets en tâches.
 La méthode repose sur une identification précise des points de contrôle et des livrables.
 La méthode repose sur un reporting des temps à travers une feuille de temps.
 Les outils de suivi des délais et des coûts sont adaptés.
 Le plan général du projet est suffisamment précis.
 Les tâches identifiées constituent des unités gérables.
 Etc.
Documents à récupérer
o manuel de la méthode appliquée ;
o liste des outils utilisés.

VI. PLAN ASSURANCE QUALITE

Le plan assurance qualité (PAQ) est un document décrivant les dispositions

spécifiques prises en matière d’assurance de la qualité par un organisme pour
répondre aux exigences relatives à un produit et/ou service particulier.

Il faut vérifier :
 Il existe un dispositif d'assurance qualité documenté.
 Il existe un manuel d'assurance qualité de l'entité.
 Il existe un plan d'assurance qualité du projet.
 Les objectives qualités du produit et du service attendu sont formalisées.
 Le groupe assurance qualité est indépendant des équipes de développement du projet.
 Une procédure de suivi des revues d'assurance qualité est formalisée.
 Il existe un audit de la qualité du projet par une personne extérieure.
 Etc.
Documents à récupérer
o manuel d’assurance qualité,
o plan d’assurance qualité,
o procédure de suivi des revues qualité.

15
 VII. CONCEPTION GENERALE ET ANALYSE

Le dossier de conception générale informatique définit les scénarios

d’évolution du système d’information avec :

 Une description générale de la solution conceptuelle des flux/traitement

et des données,
 Une description générale de la solution organisationnelle,
 Une description générale de l’architecture technique de la solution
(centralisé, décentralisé, …),
 Et une orientation générale des actions de conduite du changement et
de mise en œuvre.

Il fournit les éléments nécessaires à la prise de décision en termes d’architecture, de

lotissement, de coûts, de risques et de délais.

Il faut vérifier :
 Il existe une analyse des différents scénarios possibles en termes de solution retenue.
 Les contraintes liées aux technologies (besoins en matériels, en formation, en RH,
contraintes juridiques, faisabilité opérationnelle, …) ont été prises en compte.
 Une analyse économique (bénéfices attendus, coûts de développement, de formation, de
maintenance, …) a été intégrée au choix de la solution.
 Une analyse des risques a été mise en place pour chaque alternative.
 Les aspects de contrôle interne et de sécurité ont été pris en compte dans le cahier des
charges.
 Les contrôles d'exploitation ont été identifiés.
 Les besoins spécifiques en matière de contrôles ont été pris en considération.
 Les études de faisabilité ont été revues par les membres du comité adéquat.
 Les différentes solutions possibles ont été présentées au comité adéquat.
 La poursuite du projet a été approuvée par écrit par une personne compétente.
 Etc.
Documents à récupérer
o comparaison des différentes solutions,
o liste des contrôles d'exploitation.
VIII. CONCEPTION DETAILLEE

La phase de conception détaillée est ponctuée par un dossier de conception détaillée

informatique. Ce dossier spécifie de façon détaillée (architecture et modèles
informatiques) les composants logiciels à mettre en œuvre ainsi que les interfaces,
selon le scénario, les « modalités » et la « route » de développement retenus.

Il faut vérifier :
 Il existe une méthode d'analyse et de conception.
 Cette méthode est correctement utilisée.
 Cette méthode est maîtrisée par l'équipe projet.
 Les spécifications détaillées sont exhaustives par rapport au cahier des charges.
 Le responsable de la sécurité est impliqué dans le projet.

16
  Il existe des pistes d'audit permettant de suivre la totalité des transactions.
 Etc.
Documents à récupérer
o dossier de spécifications détaillées (ou de conception détaillée),
o manuel utilisateur,
o manuel d'exploitation,
o dossier d'organisation de la reprise des données,
o bilan de qualité logiciel,
o bilan de la satisfaction des utilisateurs.

IX. DEVELOPPEMENT, REALISATION OU PARAMETRAGE

La phase de réalisation consiste à produire un ensemble de codes exécutables

(programmes) structuré et documenté correspondant aux spécifications et
respectant les dispositions du plan d’assurance qualité à partir du dossier de
spécifications détaillées et des normes et standards de production du logiciel.

Cette phase inclut le développement des interfaces internes et externes, la

spécification des tests et l’élaboration des scénarios de reprise des données.

On distingue deux cas de figure lors de la phase de réalisation : soit il existe déjà sur
le marché une solution répondant au besoin (progiciel) qu’il faut alors paramétrer,
soit il faut développer une solution sur mesure. Paramétrer consiste à adapter un
progiciel au contexte organisationnel et technique cible pour répondre aux besoins
exprimés par les utilisateurs.

Il faut vérifier :
 Il existe une méthode de développement.
 Cette méthode est correctement utilisée.
 Les développements sont bien documentés.
 La documentation est revue par le responsable du service des études.
 Il existe un programme général de tests formalisé.
 Il existe un plan de mise en place.
 Le plan de mise en place définit la nature des travaux à réaliser et leur ordonnancement.
 Le plan de mise en place définit les charges de travail correspondantes et la durée de
travaux.
 Le plan de mise en place définit les rôles et les responsabilités des acteurs.
 Il existe un plan de migration.
 Les procédures de contrôle en matière de passage en production sont respectées.
 Etc.
Documents à récupérer
o programme général de tests,
o plan de mise en place des tests,
o plan de migration/reprise des données,
o dossier de spécification de paramétrage.

17
 X. QUALIFICATION : TEST/RECETTE

Toute application informatique doit être testée avant de passer en production, dans
un premier temps par la maîtrise d’œuvre, puis par la maîtrise d’ouvrage (test
utilisateur).
Une procédure formalisée encadre l’acceptation ou le rejet d’une livraison.

Un procès-verbal doit systématiquement être dressé en fin de recette (période de

test).
La qualité de la reprise des données peut être incluse dans cette phase de test.
Il faut vérifier :
 Des tests utilisateurs sont réalisés.
 Les tests portent sur l'acceptation technique du projet (ergonomie, performance, qualité
des entrées/sorties,…).
 Il existe des tests de pré-exploitation.
 Ces tests s'assurent de la bonne intégration du projet dans l'environnement.
 Etc.
Documents à récupérer
o plan de tests,
o comptes-rendus des tests,
o manuel utilisateur,
o manuel d'exploitation.

XI. CONDUITE DU CHANGEMENT ET MISE EN OEUVRE

Enjeu capital dans la réussite ou l’échec d’un projet, le changement vécu par les
organisations lors d’une évolution du système d’information doit être maîtrisé et géré
comme un processus à part entière.

Il s’agit de l’ensemble de moyens, ressources, méthodes pour transférer la

connaissance de l’application de l’équipe projet vers les utilisateurs et les exploitants
de l’application.

Ce processus doit aboutir à une réelle appropriation du nouveau système

d’information par tous les utilisateurs dès la phase de démarrage. La démarche de
conduite du changement/mise en œuvre est habituellement structurée en 6 phases :

- Identification et évaluation des changements,

- Plan de communication,
- Plan de formation,
- Elaboration définitive de la documentation,
- Organisation du soutien,
- dans les cas simples, la reprise des données peut être incluse dans cette phase.

18
Il faut vérifier :
 Il existe une synthèse de l'évaluation des changements.
 L'évaluation des changements a été validée.
 Les entretiens réalisés sont représentatifs.
 Les utilisateurs participent à l'évaluation des changements.
 Il existe un plan de communication complet.
 Les messages sont clairs et simples.
 La communication évolue et progresse par rapport au développement du projet.
 Il existe un plan de formation.
 La hiérarchie des personnes à former est impliquée.
 Les objectifs de chaque formation sont identifiés et affichés.
 Les sessions de formations sont évaluées et repensées selon l'évaluation.
 Le planning de formation est cohérent avec le planning du projet.
Documents à récupérer
o plan de communication.
o plan de formation.
o planning de formation avec liste des formés.

XII. DOCUMENTATION

Pour que l’application soit pérenne et puisse évoluer, il est important de produire de
la documentation. Ces documents contribuent à la transmission du savoir pour
maintenir, faire évoluer et utiliser l’application.

Il faut vérifier :
 Il existe un manuel d'utilisation.
 Le manuel utilisateur est conforme aux normes en vigueur.
 Le manuel utilisateur est disponible et compréhensible par l'ensemble des utilisateurs.
 Le manuel utilisateur comprend les objets du système et la description des dessins d'écran
et des commandes disponibles.
 Le manuel utilisateur comprend les responsables concernant le redressement des erreurs
ou anomalies.
 Le manuel utilisateur comprend la description des sorties et leur mode de diffusion.
 Le manuel utilisateur fait l'objet d'une procédure de mise à jour.
 Il existe un manuel d'exploitation.
 Le manuel d'exploitation est accessible et compréhensible pour les opérateurs.
Documents à récupérer
o liste des indicateurs.
o tableau de bord.
o manuel utilisateur.
o manuel d'exploitation.

19
XIII. ROLES ET RESPONSABILITES

Il est important de définir les rôles et les responsabilités de l’ensemble des parties
prenantes lors de la conduite d’un projet, et ce, pour l’ensemble des phases de son
existence (de l’étude d’opportunité au retrait de service).

Il faut vérifier :
 Les rôles et les responsabilités respectifs de la MOA et de la MOE sont clairement définis.
 Les prérogatives du chef de projet sont clairement définies.
 Le chef de projet dispose de l'autorité suffisante pour résoudre les éventuels conflits.
 La MOA et la MOE disposent des compétences et des ressources managériales, techniques et
fonctionnelles suffisantes.
 Les principales décisions et orientations du projet sont prises par le niveau de management
adéquat.
 Les principaux intervenants sur le projet sont 100% dédiés au projet avec suppression,
pendant la durée du projet, des anciens liens hiérarchiques.
 La MOA ou la MOE ont bénéficié d'une assistance extérieure au cours du projet.
 La consultation et l'implication des utilisateurs a été suffisante au cours des différentes
phases du projet.
Documents à récupérer
o Organigramme du projet avec définition des fonctions,
o Contrats d'assistance, de sous-traitance, d'infogérance.

XIV. GESTION DES EVOLUTIONS

Le terme « évolution » désigne les modifications apportées à un système après sa

mise en service. La gestion des évolutions doit faire l’objet d’une organisation et de
procédures clairement définies.

Il faut vérifier :
 Les demandes d'évolution du périmètre sont fréquentes.
 Les demandes d'évolutions sont formalisées.
 Il existe une procédure de gestion des évolutions du périmètre.
 Une mesure d'impact est effectuée.
 Les décisions sont prises avec un délai satisfaisant.
 Le manuel utilisateur fait l'objet d'une procédure de mise à jour.
 Le manuel d'exploitation fait l'objet d'une procédure de mise à jour.
 Les différents niveaux de soutien restent coordonnés et cohérents.
 Il existe un bilan de qualité de l’évolution du projet.
 L’évolution est conforme aux besoins fonctionnels exprimés par le cahier des charges.
Documents à récupérer
o procédure de demande d'évolution du périmètre.
o liste des demandes d'évolution.
o manuel utilisateur.
o manuel d'exploitation.
o bilan de qualité logiciel.
o bilan de la satisfaction des utilisateurs.

20
XV. MISE EN PRODUCTION

La phase de mise en production est celle de la mise à disposition des utilisateurs. Elle
doit se faire de manière ordonnée, en respectant strictement les procédures internes
lors de la bascule de responsabilité entre la direction chargée des projets et la
direction chargée de la production.

Cette étape soulève souvent des problèmes que les environnements de tests n’ont
pas pu simuler. Il est donc primordial d’assurer la reprise d’activité le plus rapidement
possible après la mise en production de l’application, pour ne pas gaspiller la période
de garantie.

Il faut vérifier :
 Les responsabilités respectives des directions des projets et de la production sont clairement
établies et les périmètres décrits respectent les principes de séparation des tâches.
 Il existe un document décrivant les responsabilités respectives des projets et de la
production lors d’une mise en production.
 Les équipes projet et de production connaissent et respectent ce document.
 Les opérations de mise en production sont tracées et conformes.
 Les obligations respectives de l’organisation et de ses fournisseurs lors de la mise en
production sont clairement indiquées dans les documents contractuels.
 Les membres de l’organisation et les fournisseurs respectent leurs obligations lors de la mise
en production.
 La bascule de la garantie vers la maintenance est organisée à travers des documents
contractuels clairs.
Documents à récupérer
o dossier d'organisation de la direction informatique.
o procédure de mise en production.

21
Partie III : Etude de Cas
I. Entreprise A
 Démarche d’audit

 Rencontres avec les joueurs clés

 Questions structurées selon les 4 piliers de la GP

 Processus
 Outils et techniques

 Système d’information
 Personnel
 Compte-rendu distribué pour validation

 Rapport final remis à la Haute Direction

 Présentation des résultats au comité exécutif

 Constats
Quelques exemples de constats

 Besoin de définir un projet via un lexique

 Besoin de bien définir qui est le porteur de dossier

 Développer une méthodologie unique et personnalisée

 S’assurer d’une compréhension commune du projet dès le départ

 Identifier et impliquer dès le début du projet les différents intervenants

 Identifier clairement les risques associés au projet

22
 II. Entreprise B
 Démarche
 Rencontre des joueurs clés relié aux projets audités
 Questions structurées selon les 5 groupes de processus ainsi que les 9 domaines
de connaissance
 Rapport final remis au directeur exécutif
 Présentation des résultats aux différents comités

 Constat pour un projet

23
  Constats global et recommandations

 Quelques exemples de questions…

• Quels critères sont utilisés pour assigner un gestionnaire de projet à un projet?

• Les parties prenantes sont-elles impliquées dès le début des projets dans la direction à
donner aux projets?

• Les projets sont-ils classés par catégorie de projets semblables?

• Les projets retenus sont-ils priorisés les uns par rapport aux autres?

• Quels outils sont utilisés pour surveiller la performance des projets?

24
 Conclusion
Bien que l’audit de projet ne soit pas une méthode de gestion couramment utilisée,
elle peut être une source intéressante d’apprentissage et d’amélioration des
opérations de gestion de projet. L’ingénieur doit considérer l’audit comme une façon
d’améliorer les méthodes de gestion de projet et de formation du personnel
travaillant quotidiennement sur ledit projet.

25
 LES REFERENCES BIBLIOGRAPHIQUES

 GENEST, B.A., et NGUYEN, Tho Han, « Principes et techniques de la gestion

de projets », 3e édition, Éditions Sigma Delta, 2002.
 GRAY, C.F., et LARSON, E.W., « Management de projet » (adaptation
française : Yves Langevin), Éditions Chenelière McGraw-Hill, 2007.
 MEREDITH, J.R., et MANTEL, S.J., « Project Management – a managerial
approach», Éditions Wiley, 2006

 www.cours-de-droit.net
 www.droit-ntic.com

26