SlideShare une entreprise Scribd logo
Cycle de Préparation au C.I.S.A

Système de développement
d’application, acquisition,
implémentation et maintenance
Mohamed SAÂD

I.T.M et consultant en Systèmes d’Information

1
SOMMAIRE
 I- Développement d’applications informatiques
 Approche traditionnelle SDLC
 Rôles et responsabilités des groupes et des individus
 Risques associés au développement logiciel
 Utilisation des techniques d’analyse, de conception et de
développement
 Description des phases du SDLC
 Méthodologies de développement du logiciel
Systèmes de développement Orientés Objet
 Prototypage
 RAD
 AGILE
 Reengineering
 Reverse Engineering


 II- Pratiques de maintenance des systèmes d’information
 Gestion du changement
 Management de la configuration
 Contrôle de la librairie logicielle
 III- Pratiques de management des projets
2
SOMMAIRE
 IV- Pratiques d’amélioration des processus de développement du
logiciel





ISO 9126
SPICE
CMM
CMMI

 V- Audit des systèmes de développement, de l’acquisition et de la
maintenance










Gestion des projets
Étude de faisabilité
Expression des besoins
Processus d’acquisition logiciel
Étude détaillé et les phases de développement
Phase de tests
Phase implémentation
Revue de l’implémentation
Procédures de changement et processus de migration
3
I- La gestion de projets


Gérer c’est:










Organiser
Planifier
Contrôler
Coordonner
Diriger
Communiquer
Décider
Déléguer
Négocier

4
I- La gestion de projets


Ensemble de processus permettant de maîtriser la
réalisation d’un projet et de la mener à terme :






Découpage et description du projet en :
 processus,
 phases,
 étapes.
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.
Répartition claire du rôle et des responsabilités des acteurs

5
Caractéristiques d’un projet







Implique le changement.
Possède un début et une fin.
Requiert des activités.
Implique des individus.
Fait dans un but précis.
Destiné à un ou plusieurs clients

6
Caractéristiques d’un projet



Gérer un projet:
 C'est gérer le changement

7
Facile ?






« Il n ’y a rien de plus risqué, de plus difficile à
planifier et de plus dangereux à gérer que
l’implantation d ’un nouveau système ! »
Résistance acharnée de tous ceux qui auraient
quelque chose à perdre par l ’implantation du
nouveau système
Soutien mitigé de tous ceux qui auraient quelque
chose à gagner

8
Les différents points de vue


Différents besoins et points de vue :






Le client,
Les utilisateurs,
L’équipe,

Le chef de projet doit les comprendre et essayer de
les satisfaire

9
Les différents points de vue


Client :






Livraison rapide
Peu coûteux
Fonctions nécessaires

Utilisateurs :





Beaucoup de fonctions
Convivialité
Fiabilité
Performance

10
Les différents points de vue


L’équipe :




Les responsables :
 haute qualité
 respect des délais
 respect des budgets
 aucune surprise
Les développeurs :
 travail motivant
 analyse seulement
 plan de carrière

11
Les différents points de vue


L’équipe :


les opérateurs de maintenance :
 facilité d’opération,
 facilité de maintenance,
 fiabilité,
 documentation,
 respect des standards.

12
La confrontation




Perceptions
Attentes
Réalités

13
Les principaux apports de la gestion de projets






Suivi de projets plus efficace
Prise en compte des risques au plus tôt
Mise en évidence des bénéfices
Gestion des points en suspens
Gestion des demandes de changement

14
Les enjeux de la gestion de projets


Le succès, l’échec d ’un projet repose sur :








La compréhension des processus de l’activité
Une définition claire du périmètre
Un contrôle permanent des résultats attendus et une vision
globale du «comment le projet est réalisé»
Une bonne anticipation et gestion des risques
Une gestion rigoureuse des changements
Une structure clairement définie : gestion, décision,
communication

15
Impacts







Les coûts
Les délais
La qualité
L’image de l’Entreprise
La compétitivité
Les ressources humaines

16
Les processus et
les activités

17
Les Processus
Processus de lancement

Processus d’évolution du système d’information
Processus d’évolution du système informatique

1
Organisation

2
Opportunité
Et
Lancement
Du projet

3
Élaboration
D’une solution
-Solution avec progiciel
-Solution spécifique

Intégration et
Industrialisation
Du système
informatique

4
Mise en oeuvre

5 Conduite du changement

6 Management de l’équipe projet et Gestion de projet

7 Assurance et maîtrise de la Qualité

8 Urbanisme du Système d’Information
18
Activités supports







Suivi de projet : ensemble des moyens et des actions
qui permettent de mesurer ce qui a été fait et
d’évaluer ce qui reste à faire
Rédaction et suivi des contrats, relation avec les
utilisateurs
Estimation des charges, planification
Organisation des équipes

19
Activités supports


Gestion de la qualité :




Spécifications des caractéristiques de qualité
Dispositions préventives
Procédures de contrôle

20
Activités supports


Gestion de la documentation :






Gestion de la configuration :




Conception et mise à jour des règles :
 identification
 structuration
Production et diffusion.
Identification et gestion des composants et des
configurations :
 constitution de versions sur la base des composants
 bibliothécaire de projet

Maîtrise des modifications

21
Activités supports


Vérification :






Revue de fin de phase
Tests d’intégration
Inspection de code

Validation :



Cycle de validation
Recette définitive

22
Les projets

23
Différentes tailles de projets


Petits projets :






Quelques personnes
Moins de 30 mois/homme
Environnement familier

Moyens projets :



5 à 10 personnes en pointe
De 30 à 100 mois/homme

24
Différentes tailles de projets


Grands projets :







Plus d'une dizaine de personnes en pointe,
Plus d’un niveau hiérarchique,
Accent mis sur la gestion de projet,
De 100 à 1000 mois/hommes.

Très gros projets :





Au moins 40 personnes en pointe,
Plus de 1000 mois/hommes,
Accent mis sur l’assurance qualité,
Plus le projet est important, plus les exigences en matière de
pilotage et de qualité seront fortes.

25
Différents types de projet





Projet de gestion
Projet système
Développement d’un progiciel
Projet de maintenance…

26
Différents types de projet


Différences :






Corps de métier
Répartition du temps par phase
Répartition des activités

Identique :



Problèmes humains
Processus supports

27
La maîtrise d’ouvrage








Donne son accord sur l’opportunité du projet,
S'assure du financement du projet,
Met en place les structures de pilotage,
Définit les objectifs du projet et les besoins
fonctionnels en regard de ces objectifs,
Fixe le cadre des travaux confiés au maître d'œuvre,
Effectue la recette définitive des prestations fournies
par le maître d'œuvre

28
La maîtrise d’ouvrage


Pilote la conduite du changement :






Organiser et suivre les actions de communication
formation, et production de la documentation
Et y participer le cas échéant

Pilote les actions de sous-traitance
NB : Certaines tâches peuvent être sous-traitées par
la maîtrise d'ouvrage : aide à la rédaction de la
définition des besoins et à la rédaction du cahier des
charges; assistance à la réception du produit;
pilotage des actions de conduite du changement, de
communication et de formation
29
La maîtrise d’œuvre


Responsable de la réalisation des travaux qui lui ont
été confiés par la maîtrise d ’ouvrage

30
La maîtrise d’œuvre








Constitue l’équipe projet et désigne le chef de projet,
Assure la gestion de projet (ordonnancement,
estimation, planification des tâches, gestion des
risques et suivi du projet)
Participe à la synthèse des besoins et réalise les
travaux d'étude
Réalise l'intégration du système (tests unitaires et
d'intégration),
Gère le contrôle qualité
Rend compte à la maîtrise d'ouvrage de l'avancement
du projet et lui soumet les éléments de choix relevant
de sa compétence
31
Points importants

32
La méthode



Tout développement de projet nécessite une méthode
Le suivi opérationnel des projets s’appuie sur la
méthode

33
La méthode


Elle recouvre deux aspects :




Une démarche de développement (cycle de vie et cycle de
décision) :
 phases
 étapes
 livrables
Une technique de conception.
 modélisation

34
La méthode


Trois grandes approches de développement:






Une approche spécifique pour les développements sur
mesure
Une approche progiciel comprenant deux étapes
successives:
 évaluation, sélection et conception de l'intégration dans
l'environnement fonctionnel et technique de l'entreprise
 installation, adaptation, paramétrage, réalisation et mise en
œuvre
Le développement itératif pour satisfaire un besoin mal
connu et/ou peu formalisé. Démarche cyclique de
prototypage, validation et mise en œuvre

35
Panorama des méthodes


Exemples:







Merise (Sema)
Axial (IBM)
RAD (James Martin)
SDM/S (CEGELOG/AGS Management Systems Inc.)
MCP (Warnier)
Méthodes objets : UML

36
Comparaison des phases selon les méthodes
MERISE

AXIAL

SDM/S

MCP

Schéma Directeur

Diagnostic

Détermination des besoins

Exp. Des besoins

Étude préalable

Schéma directeur

Chois d’architecture système

Étude d’opportunité

Étude détaillée

Conception Fnelle

Spécif Externes

Étude du S.I

Étude technique

Conception Technique

Spécif Interne

Élaboration du C.des charges

Réalisation

Étude de migration

Programmation

Étude du S.I

Mise en oeuvre

Plan de mise en oeuvre

Tests

Programmation et essais

Évaluation économique

Intégration

Réception provisoire

Conception détaillée

Recette

Lancement sous contrôle

Réalisation et tests

Généralisation

Évaluation de l’application

Mise en production

Maintenance

Évaluation du projet
37
Les méthodes: quelques recommandations


Adopter une démarche et s’y tenir :








Choisir un cadre de référence (méthodes du marché et
méthodes "maisons"
Définir processus, activités, tâches, documentation,rôles et
acteurs
Avoir la volonté d’appliquer la démarche

Pas de règle miracle :



Pragmatisme
Bon sens

38
Méthodes
d’estimation des
charges

39
Estimation des charges


Répond à un besoin de prévision de durée, du coût et
de la répartition de l’effort à fournir (j/h) et permet de :





Faire une estimation de la rentabilité de l’investissement
Évaluer une durée vraisemblable du projet
Prévoir l’ordonnancement des étapes
Prévoir les ressources (affectation des personnes)

40
Estimation des charges


Besoins d’estimation à différents niveaux :







Projet : durée, budget, rentabilité
Phase : ajuster le découpage, décision de soustraiter,prévoir les délais, les ressources
Étape : planification, suivi du projet pour surveiller les
écarts, affecter les ressources
Tâche : planification fine pour suivre les équipes

41
Différentes
méthodes
d’estimation

42
Familles de méthodes


Il existe plusieurs familles de méthodes d'estimation:






Modèles algorithmiques (coût fonction de variables)
Jugement d'experts
Analogie (référence à d'autres projets similaires)
Estimation globale puis décomposition
Décomposition (estimation individuelle détaillée puis
agrégation)

43
Estimations: Modèles algorithmiques


Principe




Avantages :







Objectif,
Reproductible,
Simple,
Expérimental.

Inconvénients :






Consiste à estimer à l'aide de fonctions mathématiques des
variables jugées significatives.

Entrées subjectives,
Prise en compte des cas exceptionnels,
Il existe de nombreux

Modèles, lequel choisir ?
44
Estimations: Jugement d’experts


Principe




Avantages :




Estimation par des experts :
 Soit individuellement,
 Soit en groupe avec une méthode de consensus.
Prise en compte globale du contexte et des situations
exceptionnelles.

Inconvénients :



Estimation subjective en fonction des experts,
Non reproductible.

45
Estimations: Analogie


Principe :




Basé sur les résultats de projets comparables
Mise en évidence des différences
Évaluation des écarts

46
Estimations: Analogie


Avantages :






Capitalisation sur l'expérience
Bonne prise en compte du contexte
Réutilisation possible de composants

Inconvénients :



Degré de signification des projets passés
Prise en compte des situations exceptionnelles

47
Estimations: Globale


Principe :






Avantages :




Estimation globale partir des propriétés globales du
processus et du produit
Obtention d'une catégorie de projet parmi n à partir des
propriétés globales (Matrice des familles de projet en charge
et délai)
On n'oublie pas les éléments communs

Inconvénients :


Ne met pas en évidence les problèmes de détail

48
Estimations: Décomposition


Principe de la décomposition analytique






Avantages :






Estimation individuelle de chacun des éléments analytiques
(par activité et tâche) à partir de barèmes
Agrégation et ajout des coûts communs
Analyse plus approfondie
Répartition des risques
Permet l'itération

Inconvénients :



Plus long,
Ne regroupe pas les tâches similaires

49
Estimations: Décomposition



La décomposition nécessite des barèmes
Exemples de barèmes:






Compte-rendu d'interview et vérifications : 0,5 personne-jour
par interview
Interview: 0,5 personne-jour+déplacement
Rédaction de rapport : 10 à 20 pages par personne - jour
Codage et test unitaire d'un IHM simple : 0,5 personne-jour

50
Quelques principes




Pas de modèle universel.
Mais nécessité d'une démarche formalisée.
Analyser en priorité :








Les particularités du projet
L’identification des tâches
Les contraintes

Faire plusieurs estimations si nécessaire.
Savoir justifier.
Une bonne estimation repose sur la capitalisation.

51
Outils de gestion
de projets

52
Outils de gestion de projets



Existence de nombreux logiciels de gestion de projet.
Permettent de :







Planifier le projet,
Créer des tâches,
Affecter des ressources aux tâches,
Indiquer le coût des ressources,
Calculer le chemin critique,
Faire des simulations (pour constater les impacts d'un retard
par exemple).

53
Outils de gestion de projets


Composants essentiels :




Réseau PERT :
 se présente sous forme graphique et ressemble à un
organigramme informatique horizontal montrant les liens
entre les tâches
 renseigne surtout sur le "chemin critique"
Diagramme de GANTT :
 orienté sur la gestion du temps
 indique les dates de début et de fin des tâches
 permet de planifier les tâches et réduire la date de fin du
projet

54
Outils de gestion de projets




Il existe de nombreux progiciels (plus de 80 dans le
catalogue du CXP)
Quelques exemples de produits:


MS Project, PMW, PSN 8, On Target, Artemis, Primavera,
Plantrac TM, Harvard, Time Line, WINGS, Pertmaster,
Etc...

55
Quelques produits


MS PROJECT pour Windows (Microsoft)







Mise au point de planning,
Présentations graphiques de PERT, GANTT et calendrier,
Suivi des délais, gestion des coûts simple,
Outil simple à manipuler, public non spécialiste de la gestion
de projet.

On Target (Symantec Corporation)






Gère jusque 1500 tâches par projet,
Gère un nombre illimité de ressources par tâche,
Possibilité d'établir des liens graphiques temps/ressources
avec la souris,
Utilisation facile
56
Quelques produits


PSN 8 (Scitor Corporation)










Outil généraliste de planification de tâches et de gestion de
ressources (individuelles ou en groupes) au sein d'un
département
Permet de réaliser des simulations en temps réel, des
analyses et des synthèses
Sait gérer plusieurs projets
Gère 2000 activités par projet et 500 ressources par table,
Produit des états de taille réglable

PMW (ABT Corporation)



Outil orienté gestion des ressources
S'adresse à un public connaissant bien la gestion de projet
57
Constats généraux

58
Constats généraux







De nombreux projets «avortent».
Retard dans la livraison.
Dépassement de budget.
Problèmes d’exploitation et de maintenance.
Résistance aux changements.
Manque de compétences des gestionnaires.

59
Lois, règles et légendes








L'effort nécessaire à fournir pour atteindre les
objectifs prévus croît géométriquement avec le temps
Les projets progressent rapidement jusqu’à ce qu’ils
soient terminés à 90% puis, restent à 90%
Lorsque les choses vont bien, quelque chose ne va
pas
Lorsque les choses ne peuvent pas être pires, elles le
deviendront encore davantage

60
Lois, règles et légendes








Si on tolère le changement, le rythme de changement
dépassera le rythme de développement
En moyenne, les grands projets finissent un an en
retard, coûtent deux fois plus que l’évaluation initiale
Un projet mal planifié prendra trois fois plus de temps
à réaliser que prévu alors qu'un projet bien planifié ne
prendra que deux fois plus de temps
Aucun grand projet informatique n'est achevé dans
les délais, dans les limites budgétaires prévues à
l'origine et avec les mêmes responsables qu'à son
initialisation
61
Constats généraux: quelques statistiques




Dans la mesure où les dérives sur les projets de
grande taille sont très fréquentes, il convient de ne
pas sous-estimer les coûts, qui peuvent se révéler à
terme beaucoup plus élevés
A titre d'information, quelques statistiques sur la
tenue des délais dans des moyens (30 à 100
mois/hommes) et grands projets (100 à 1000
mois/hommes) (source Carper-Jones) :






Projets annulés : 13%
Projets en retard de plus de 12 mois : 12%
Projets en retard de plus de 6 mois : 35%
Projets approximativement à l'heure : 37%
Projets terminés plus tôt que prévu : 3%
62
Déroulement d’une
mission d’audit

63
Déroulement d’une mission d’audit


5 phases :






Lancement du projet et compréhension du contexte
Recueil de l’existant
Analyse de l'existant
Recommandations
Présentation finale

64
Déroulement d’une mission d’audit


Phase de lancement :


Précision du champ de la mission et définition des objectifs
associés :
 éléments à l ’origine de la mission justifiant son opportunité,
ses objectifs et les enjeux correspondants
 définition du champ de l ’étude et éventuellement des
ambiguïtés subsistant sur le champ de la mission
 identification des différents services concernés
 évolutions prévisibles à prendre en compte

65
Déroulement d’une mission d’audit


Phase de lancement :


Organisation de la mission et planning :
 identification nominative des intervenants et disponibilité
requise
 planning prévisionnel
 première convocation pour les entretiens

66
Déroulement d’une mission d’audit


Recueil de l’existant :





Description des structures existantes,
Description des ressources logicielles et matérielles,
Mise en évidence :
objectifs,
 problèmes
 besoins
 facteurs clés de succès.

67
Déroulement d’une mission d’audit


Analyse de l’existant :


Analyse critique de l’existant sur les aspects
 Organisationnels
 Fonctionnels
 Techniques
 Financiers

68
Déroulement d’une mission d’audit


Recommandations :




C’est à partir de l’analyse de l’existant que sont proposées
des solutions ou des préconisations visant à optimiser : le
fonctionnement, les dépenses, la réponse aux besoins
utilisateurs
Préconisations en terme de :
 sécurité
 architecture informatique
 outils de développement
 conduite de projet
 méthodologie
 organisation
 relation maîtrise d’ouvrage / maîtrise d'œuvre
69
Déroulement d’une mission d’audit


Présentation finale :



Présentation aux commanditaires de la mission,
Synthèse avec :
 rappel du contexte
 indication des modalités de déroulement
 exposé rapide de l’existant
 mise en évidence des points forts
 mise en évidence des points faibles
 dysfonctionnements
 recommandations classées par priorité

organisation, conduite du projet, ressources…
70
Quelques points de repères


Difficultés les plus courantes constatées dans la
relation MOA/MOE:










Manque de confiance mutuelle
Manque de transparence dans la stratégie et l’action
Manque d’objectivité dans l’appréciation des problèmes
Difficultés à prendre des décisions claires
Lourdeur des structures de pilotage
Résistance naturelle aux changements
La MOE tend souvent à se substituer à la MOA sur des
sujets qui relèvent de la responsabilité de la MOA et
réciproquement
Validations difficiles
71
Quelques points de repères


Difficultés ressenties par la MOA :




Difficultés à fixer des orientations politiques tranchées
Manque de visibilité sur les travaux en cours
Mauvaise compréhension et appréciation des évaluations de
charges et délais élevés fournies par la MOE

72
Quelques points de repères


Difficultés perçues par la MOE :





Manque de disponibilité de la MOA
Besoins insuffisamment précis et stables
Manque d’engagement de la MOA
Difficulté à évaluer les charges et les délais et à les expliquer
à la MOA

73
Démarche d’audit de
projet

74
Audit de projet


L'audit de projet est présenté en trois volets :








Une sensibilisation aux risques spécifiques de chaque type
de grand projet de système d'information
Réf.: Guide d'Audit, "Audit des grands projets de systèmes
d'information : Évaluation des risques", IFACI)
Une analyse générique des risques liés à la conduite de
projet
Une analyse des risques spécifiques à chaque phase du
cycle de vie du projet

75
Les risques
spécifiques de
chaque type de
grand projet de S.I

76
Typologie de projets











Projet à niveau élevé d'engagements budgétaires
Projet stratégique au niveau de l'entreprise
Projet transverse
Projet aux enjeux organisationnels forts (de type
"change management")
Projet à base de technologies novatrices (exemples:
technologie objet, Internet, EDI,…)
Système de gestion spécifique complexe ou peu
répandu
Entreprise Ressource Planning (ERP) - Progiciel de
Gestion Intégré (PGI)
77
Typologie de projets










Outsourcing de l'informatique ou des systèmes
d'information (total ou partiel)
Fusion et regroupement d'entreprises ou d'activités
(entre plusieurs sociétés), acquisition, filialisation
Projet international d'unification de systèmes
informatiques ou de systèmes d'information
nationaux (exemple: un groupe avec ses filiales)
Fusion/regroupement de systèmes d'information ou
de centres informatiques
Projet à délai imposé

78
Audit de projet


Projet à niveau élevé d'engagements budgétaires


Motivations et raisons du choix de ce type de projet
 Remplacement d'une application lourde nécessitant des
équipes de conception-développement volumineuses
 Déploiement d'équipements à grande échelle

79
Audit de projet


Projet à niveau élevé d'engagements budgétaires


Risques généraux
 Dépassement budgétaire
 Présentation de coûts sous -estimés ou incomplets
 Recherche d'économies au détriment de la qualité
 Phases aval du projet réalisées rapidement, pour rattraper
les dérives constatées sur les phases amont
 Méthodes de travail ne permettant pas de garder la maîtrise
du déroulement du projet
 Arrêt du projet et dispersion de toutes les équipes après le
déploiement
 Contractualisation avec les prestataires externes présentant
des points faibles ou des lacunes
80
Audit de projet


Projet stratégique au niveau de l'entreprise




Motivations et raisons du choix de ce type de projet
 Lancement d'un nouveau produit, d'une nouvelle prestation
ou d'un nouveau métier
 Mise en conformité avec une nouvelle réglementation
Risques généraux
 Manque d'implication des commanditaires / Commanditaires
trop directifs
 Déclinaison incorrecte des éléments du plan stratégique
 Essoufflement du projet avant son total déploiement
 Dépassement de délai

La bonne fin d'un tel projet repose en grande partie
sur l'Étude d'opportunité
81
Audit de projet


Projet transverse




Motivations et raisons du choix de ce type de projet
 Passage d'une gestion verticale à une approche par
processus
Risques généraux
 Absence de vision transverse
 Pilotage fort d'une fonction, au détriment des fonctions
connexes
 Non prise en compte de la culture d'entreprise

82
Audit de projet


Projet aux enjeux organisationnels forts (de type
"change management")




Motivations et raisons du choix de ce type de projet
 Bouleversement des conditions d'exercice du métier
 Repositionnement de l'entreprise sur son marché
Risques généraux
 Manque d'implication de la Direction Générale jusqu'à la
bonne fin du projet de changement
 Mauvaise intégration du volet social
 Manque d'homogénéité entre le projet SI et les choix
organisationnels
 Dépassement de délai

83
Audit de projet


Projet à base de technologies novatrices (Technologie
objet, Internet, EDI,…)




Motivations et raisons du choix de ce type de projet
 Recherche d'un avantage concurrentiel
 Vitrine technologique
 Remplacement d'une technologie obsolète et mise en place
d'un socle technique évolutif et pérenne
Risques généraux
 Attrait de l'innovation pour elle-même
 Dépendance vis -à-vis des fournisseurs
 Mauvaise intégration dans le système d'information et
manque de coordination avec les projets des partenaires
 Oubli des coûts
84
Audit de projet


Système de gestion spécifique complexe ou peu
répandu




Motivations du choix de la DG
 Compte tenu du caractère spécifique, la seule solution
possible est faire des développements
Risques associés
 Spécifications fonctionnelles pointues et particulières
 Perturbation des systèmes amont et aval et propagation des
dysfonctionnements
 La solution d'informatisation n'est pas nécessairement la
solution du problème
 Dépassement de coûts : manque d'expérience par rapport à
des domaines plus standard
85
Audit de projet


Enterprise Ressource Planning (ERP) - Progiciel de
Gestion Intégré (PGI)


Motivations du choix de la DG
 Les concurrents ont pris un ERP (effet de mode)
 Aller vite et avoir une couverture plus large des besoins
fonctionnels
 Disposer d'une technologie plus avancée
 Suppression des interfaces applicatives
 Solution plus souple et moins chère qu'un développement
maison
 Diffusion d'un modèle d'organisation unique pour
l'ensemble des filiales
 Meilleure intégration et structuration des informations (une
base de données unique pour l'entreprise)
 Mise à disposition plus rapide et plus complète des
informations stratégiques (besoins de niveau DG)
86
Audit de projet


Enterprise Ressource Planning (ERP) - Progiciel de
Gestion Intégré (PGI)


Risques généraux
 Résistance au changement
 Forte intégration du système
 Complexité du paramétrage
 Diversité de l'environnement technique
 Risques liés à la migration et les interfaces
 Des enjeux importants liés aux coûts et aux délais
 Inadéquation fonctionnelle ou couverture fonctionnelle
incomplète, ce qui va obliger à plus de développements
spécifiques
 Surdimensionnement fonctionnel, sous -utilisation des
fonctions du produit
87
Audit de projet


Enterprise Ressource Planning (ERP) - Progiciel de
Gestion Intégré (PGI)


Risques généraux (suite)
 Sous -estimation des coûts et des délais de mise en œuvre
 Sous -estimation des impacts organisationnels
 Perte de maîtrise de l'évolution de l'organisation et des
processus métier
 Diminution de l'avantage concurrentiel (alignement).
 Sécurité logique insuffisante

88
Audit de projet


Outsourcing de l'informatique ou des systèmes
d'information (total ou partiel)


Motivations et raisons du choix de ce type de projet:
 Se recentrer sur son métier de base, l'informatique étant une
activité de support
 Réduire la taille et le coût des services centraux
 Améliorer la qualité du service rendu aux utilisateurs
 Faciliter les changements de structure de l'entreprise

89
Audit de projet


Outsourcing de l'informatique ou des systèmes
d'information (total ou partiel)


Risques généraux
 Perte de confidentialité
 Dégradation de la qualité de service
 Inflation des coûts
 Mauvaise gestion des changements
 Démotivation du personnel

90
Audit de projet


Fusion et regroupement d'entreprises ou d'activités
(entre plusieurs sociétés), acquisition, filialisation




Motivations et raisons du choix de ce type de projet
 Une réduction des frais fixes
 Un développement du business
 Une synergie commerciale et une amélioration des parts de
marché
Risques généraux
 Absence de questionnement sur le fait de garder ou non des
S.I. différents (Convergence en matière de S.I. et
architecture technique)
 Réduction des avantages escomptés de l'opération
 Perturbation de fonctionnement
 Dérapage des coûts, des délais et de la qualité
91
Audit de projet


Projet international d'unification de systèmes
informatiques ou de systèmes d'information
nationaux (exemple: un groupe avec ses filiales)


Motivations et raisons du choix de ce type de projet
 Centralisation du pilotage
 Économies de coûts
 Rationalisation et unification des pratiques de gestion
 Conséquences attendues : installation du même « core
system » partout
 Gains escomptés : mise en cohérence des informations de
gestion et rapidité de consolidation, vision exacte des
filiales

92
Audit de projet


Projet international d'unification de systèmes
informatiques ou de systèmes d'information
nationaux (exemple: un groupe avec ses filiales)


Risques généraux
 Erreur d'appréciation au départ : base réputée identique
partout
 Réalité différente : analyse trop schématique, sous
-estimation des particularismes locaux
 Découverte des problèmes après -coup, ce qui oblige à des
compléments d'étude et entraîne des dépassements de
coûts
 Non atteinte des performances attendues

93
Audit de projet


Fusion/regroupement de systèmes d'information ou
de centres informatiques




Motivations et raisons du choix de ce type de projet
 Rationalisation du fonctionnement, économies de coûts.
Risques généraux
 Dérapage des délais, d'où dérapage des coûts.
 Impacts sur les clients, sur le personnel (pertes de
compétence : les meilleurs partent, démotivation du
personnel : perte.
 Non atteinte de la cible.
 Arrêt du projet.

94
Audit de projet


Fusion/regroupement de systèmes d'information ou
de centres informatiques (suite)


1er cas : Risques déclinés en fonction du cas de
regroupement
 Le regroupement de centres informatiques peut se faire
dans deux configurations possibles côté constructeur :
– même constructeur: il faut vérifier les économies et le
fonctionnement
– constructeurs différents: la décision étant politique, un audit
n'est pas nécessaire
 Les risques portent principalement sur:
– la migration des données
– l'architecture du réseau
– l'organisation de l'exploitation et du support
– le projet RH
95
Audit de projet


Fusion/regroupement de systèmes d'information ou
de centres informatiques (suite)


2ème cas : Risques en cas de fusion et de regroupement de
SI:
 L'existence d'une étude de benchmarking et de son
application
 La décision du choix du SI ou des applicatifs à retenir, la
migration des données, le projet RH, la formation des
utilisateurs, l'organisation des processus
 L'existence d'un document de choix et d'un relevé de
décisions, d'un plan de migration
 La satisfaction des besoins de la maîtrise d'ouvrage, la
manière dont est organisé leur suivi

96
Audit de projet


Projet à délai imposé




Motivations de ce type de projet
 En général, projets résultant de contraintes réglementaires,
fiscales, etc
 Maintien du bon fonctionnement de l'entreprise tout en
intégrant les contraintes
Risques généraux : ils portent sur l'identification incomplète
des domaines à couvrir, des problèmes à traiter; ou bien sur
la non tenue du planning (préparation et réalisation). Il en
découle :
 Réparation à chaud sans ordre, ce qui engendre des risques
aggravés et des coûts plus importants, une perte de clients,
et des pertes d'exploitation
 Absence de plan de secours avec arrêt potentiel de l'activité,
 Tests incomplets du plan de secours
97
Audit de projet


Projet à délai imposé (suite)


Risques relatifs à l'organisation du projet
 Affectation de ressources trop importantes sur le reporting
par rapport aux forces vives nécessaires en traitement des
problèmes,
 Le reporting est en décalage avec la réalité du terrain (il
nécessite d'être validé et affiné par des audits qualité),
 Le schéma global de résolution de problèmes n'est pas
réaliste,
 La démarche n'est pas à l'état de l'art (cf. ISACA,…), n'est
pas structurée ni exhaustive, n'est pas formalisée ni
communiquée,
 Toutes les compétences ne sont pas réunies ; l'appel à
l'expertise externe nécessaire n'a pas été effectué,
 Les solutions ne sont pas mutualisées (cf. Forum des
compétences du secteur financier).
98
Risques liés à la
conduite de projet

99
Les cinq questions clés








Existe-t-il un consensus sur les objectifs du projet ?
Processus de décision/validation et suivi
d'application de ces décisions ?
Qui fait quoi dans le projet ?
Tous les acteurs disposent-ils des informations
nécessaires pour agir dans le sens du projet ?
Quel est le niveau d'avancement du projet ?

100
Audit de projet


Les risques liés à la conduite de projet sont abordés
selon les thèmes suivants
1) Objectifs du projet
2) Structure de projet
3) Instances de pilotage et de suivi
4) Méthode et outils
5) Planification
6) Contrôle du projet
7) Qualité

101
1) Objectifs du projet


Concernant l'intégration du projet dans l'entreprise,
s'assurer des points suivants :





Existence d'une définition claire du projet, de son périmètre,
Existence d'un projet en accord avec la stratégie de
l'entreprise et sa culture,
Existence d'un plan de communication

102
Objectifs du projet


Les objectifs et les besoins








Les objectifs du projet sont-ils définis et connus des MOA et
MOE ?
Les besoins sont-ils clairement définis ?
Le périmètre est-il défini et stabilisé ?
Les interactions et leurs impacts avec d'autres projets ontils été identifiés ?

Les risques


A t-on identifié et formalisé les risques potentiels ?

103
2) Structure de projet


Vérifier l'existence d'une structure de projet : assurer
l'organisation du projet





Vérifier l'existence d'un chef de projet (MOE et MOA)
S'assurer de la constitution d'une équipe de projet

Remarque : la structure d'un projet n'est pas
nécessairement figée. Selon la nature et l'importance
du projet, elle peut évoluer dans le temps

104
Structure de projet


Vérifier la participation de tous les acteurs au projet :







Propriétaire du projet clairement identifié
Maîtrise d'ouvrage :
 Liste des intervenants
 Rôle et responsabilités
Maîtrise d'œuvre :
 Liste des intervenants
 Rôle et responsabilités
S'assurer que les rôles et les responsabilités de la maîtrise
d'ouvrage et de la maîtrise d'œuvre sont formellement
identifiés

105
Structure de projet


Les moyens :




Moyens humains :
 Organiser en fonction des besoins
 Équilibre entre l'expérience et le potentiel
Moyens techniques :
 Environnement de développement efficace
 Outils de développement
 Aménagement de l'environnement physique

106
Structure de projet


Direction de projet










Évaluer les compétences de la direction de projet,
Vérifier la motivation des équipes,
Sonder la maîtrise d'ouvrage :
 besoins,
 craintes,
 communication,
Le but est d ’obtenir le meilleur rendement possible des
équipes en place.
Les principaux atouts appartiennent au domaine des
relations humaines motivation esprit d ’équipe leadership,
délégation... :
Évaluer la résistance au changement.
107
Structure de projet


Existence d'un groupe projet :






Membres permanents
Rôles et responsabilités
Réunions périodiques

Vérifier l'échange d'informations entre la direction de
projet et le groupe projet

108
Structure de projet


Les acteurs :




Identification claire des fournisseurs :
 Rôle et responsabilités
 Résultats attendus
 Délai
Acteurs externes :
 Obligations légales (ex: fiscal, CNIL…)
 Résultats à fournir
 Délai

109
3) Instances de pilotage et de suivi


Le mode de pilotage, les processus de
décision/validation







La structure de pilotage est-elle définie ?
 La structure de pilotage est -elle adaptée ?
 La structure de pilotage est -elle formalisée et connue de
tous les acteurs ?
 Les différentes instances de pilotage connaissent -elles
leurs "niveaux de délégation" ?
 Les objectifs de délégations sont -ils atteints ?
Vérifier l'existence d'un comité de pilotage
Vérifier l'existence d'un comité de projet
Vérifier l'existence d'un comité des utilisateurs.
Étudier la pertinence des participants présents au comité de
projet et au comité de pilotage.
110
Instance de pilotage et de suivi


Les attributions respectives des instances de projet
sont les suivantes :







Comité de pilotage :
 Instance de décision et de pilotage stratégique du projet
(lancement, développement de la solution, conduite du
changement et mise en œuvre, management du projet)
Comité de projet :
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
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
111
Instance de pilotage et de suivi


Le mode de pilotage, les processus de
décision/validation


Les comités de pilotage et de projet sont-ils adaptés et
efficaces ?
 Les participants aux différents comités sont-ils
représentatifs , ont-ils le bon niveau de décision ?
 Les utilisateurs sont-ils représentés dans les comités de
pilotage ?
 Les gestionnaires et la production ont-ils été intégrés dans
les structures de pilotage ?
 Les participants ne sont-ils pas trop nombreux ?
 La fréquence des comités est-elle correcte ?
 Qui prépare, anime, fait le compte-rendu des comités de
pilotage ? Et dans quel délai ?
 Existe-t-il une revue de projet ? (réunion MOA-MOE
périodique pour suivre l'avancement du projet)
112
Instance de pilotage et de suivi


Le reporting






Les indicateurs de suivi sont-ils définis ?
 Les indicateurs de suivi sont-ils adaptés en fonction de
l'étape ?
 Les indicateurs de suivi sont-ils mis à jour ?
 Les indicateurs de suivi sont-ils pertinents par rapport aux
objectifs du projet (contraintes de délais, de qualité, de coût,
…)
Existe-t-il un formalisme de reporting ?
 Le reporting se fait-il sous forme de tableau de bord ?
 Le reporting est-il conjoint et unique MOA-MOE ?
Quelle est la fréquence du reporting ? est-t-elle adaptée au
suivi?
113
Instance de pilotage et de suivi


La gestion des changements (évolutions de
périmètre)




Les demandes d'évolutions de périmètre sont-elles
formalisées?
 Les évolutions de périmètre sont-elles fréquentes ? Si oui,
combien y en a-t-il eu ?
La gestion des évolutions de périmètre est-elle bien
maîtrisée ?
 Existe-t-il une procédure de gestion des évolutions de
périmètre ?
 Les décisions sont-elles prises ?
 Les mesures d'impact sont-elles faites ?
 Y a t-il une gestion des versions ?
114
Instance de pilotage et de suivi


Les décisions




Les décisions sont-elles prises ? Avec un délai satisfaisant?
Sur la base d'un niveau d'information pertinent ?
Les points de décision sont-ils respectés (exemple: réunion
et note de lancement, décision d'opportunité) ?

115
4) Méthodes et outils


S’assurer de l'existence d'une méthode :





Vérifier qu'elle est bien appliquée
Identifier les points pouvant être bloquants tels que :
 Outils associés à la méthode
 Formation à la méthode et aux outils
 Cas de dérogation d'utilisation

Vérifier la mise en œuvre d'outils

116
5) Planification


Vérification d'un point de vue général :



Existe-t-il un planning directeur commun à tout le projet ?
La planification s'effectue du général au particulier et l'on
procède par itération :
 Existence d'un plan de projet initial
 Ce plan de projet a-t-il été révisé et pourquoi ?
 Existence de plans détaillés initiaux
 Révision des plans détaillés ?
 Gestion des ressources

117
Planification


Définition des produits à développer :



Notions de projet, sous-projet, lots
Identifications des phases et étapes :
 Contraintes
 Dates limites

118
Planification


Estimation des charges :




Utilisation d'une méthode d'estimation :
 Vérifier son application
 Vérifier la cohérence d'ensemble
Mise en adéquation des moyens :
 Humains
 Techniques

119
Planification


Avancement du projet (points en suspens)




Le planning général du projet est-il représentatif de la
réalité?
 Les acteurs se sont-ils engagés à respecter le planning
général du projet ?
 Les lots sont-ils bien identifiés et suivis dans le planning ?
 Le chemin critique est-il identifié ?
La mesure de l'avancement du projet est-elle réalisée ?
 La notion de reste à faire est-elle comprise par tous les
acteurs ?
 La réestimation périodique et en commun des reste-à-faire
est-elle faite ?
 Existe-t-il des "capteurs" d'alertes ?
 Existe-t-il des procédures pour traiter les alertes
« urgentes » ?
120
Planification


Évaluer la prise en compte des risques :


Par rapport :
 à la technologie utilisée
 aux projets en cours
 aux délais
 à la synchronisation des activités

121
6) Contrôle du projet




Le contrôle du projet est directement lié à la
planification
Il permet de vérifier :




Avancement des travaux
Contrôle des livrables
Contrôle de la qualité

122
Contrôle du projet


Vérifications nécessaires :










A-t-on mis l'accent sur les écarts et la recherche de
solutions ?
A-t-on pris en compte des demandes de changement après
évaluation?
Les demandes d'évolutions de périmètre sont-elles
formalisées ?
Les évolutions de périmètre sont-elles fréquentes ? Si oui,
combien y en a-t-il eu ?
La gestion des évolutions de périmètre est-elle maîtrisée ?
Existe-t-il une procédure de gestion des évolutions de
périmètre ?
Les décisions sont-elles prises ? Les mesures d'impacts
sont-elles faites ?
Y-a-il une gestion des versions ?
A-t-on pris en compte les points en suspens ?

123
Contrôle du projet




Point essentiel: le suivi périodique de l’état
d’avancement du projet
Le reporting


Les indicateurs de suivi sont-ils définis ?
 Les indicateurs de suivi sont-ils mis à jour ?
 Les indicateurs de suivi sont-ils pertinents par rapport aux
objectifs du projet (contrainte de délais, contrainte de
qualité, contrainte de coût,…) ?
 Existe-t-il un formalisme de reporting ?
 Le reporting se fait-il sous forme de tableau de bord ?
 Le reporting est-il conjoint et unique MOE-MOA ?

124
Contrôle du projet


Point essentiel : Le suivi périodique de l'état
d'avancement du projet


Efficacité du processus de décision/validation effectué par
les instances de pilotage

125
Contrôle du projet


Vérifications nécessaires :






Application du MAQ et PAQ s'ils existent (cf. partie Qualité)
Existence des revues (techniques, livrables)
Circuit d'approbation des livrables
Graduation des livraisons
Documentation produite

126
7) Qualité


Quelques définitions (AFNOR)






L ’assurance qualité est la mise en œuvre d ’un ensemble
approprié de dispositions préétablies et systématiques
destinées à donner confiance en l ’obtention de la qualité
requise.
La qualité est ce que le client souhaite explicitement ou
implicitement
La qualité du logiciel est son aptitude à satisfaire les
besoins des utilisateurs

127
Qualité



Les objectifs qualité ont-ils été formalisés ?
Existe-t-il des moyens pour s'assurer de la qualité ?



Existence d'un manuel d'assurance qualité de l'entreprise
Existence d'un plan d'assurance qualité du projet

128
Le manuel d’Assurance Qualité




Dispositions générales prises par l ’Entreprise pour
obtenir la qualité de ses produits et services.
Contient :





Les règles de gestion de la qualité
Les règles et procédures de gestion de l’Entreprise
Les plans types de documentation
L’organisation associée

129
Le plan d’Assurance Qualité







Établi à partir du MAQ
Décrit les procédures, les règles, les méthodes
applicables au projet
Fixe aux différents acteurs du projet leurs droits mais
aussi leurs devoirs en matière de qualité
L’élaboration du PAQ est du ressort du Responsable
Assurance Qualité du projet

130
Exemple de PAQ


Introduction :





Glossaire et abréviations.
Organisation :




Contexte, périmètre, procédures associées au PAQ.

Rôle des intervenants et des structures de pilotage.

Plan de développement :


Démarche, activités, livrables…

131
Exemple de PAQ


Documentation :




Procédures diverses :







Identification, contenu, validation
Gestion des fournisseurs, gestion des configurations,
gestion des modifications
Gestion des points en suspens, gestion des risques, gestion
de la recette

Reproduction, protection, livraison
Suivi de l’application du Plan d’Assurance Qualité

132
Qualité


A t-on formalisé les objectifs de qualité du produit
(Plan Qualité Projet)?




Les utilisateurs ont -ils été impliqués dans la définition du
niveau de qualité du produit ?

A-t-on formalisé les objectifs de qualité de service
attendue ?


Les utilisateurs ont -ils été impliqués dans la définition du
niveau de qualité attendue ?

133
La revue des points
clés de chaque
phase

134
Les grandes phases de conduite de projet








Étude d'opportunité/Lancement
Conception générale/Analyse
Conception détaillée
Développement/Réalisation ou Paramétrage
(progiciel)
Qualification : Tests/Recettes
Mise en œuvre/Conduite du changement

135
Étude d’opportunité/Lancement




Vérifier l'existence d'une expression détaillée et
formalisée des besoins dans un cahier des charges
fait par la MOA  Document contractuel : justification
du projet
S'assurer que l'étude d'opportunité comprend :







Les objectifs du projet
L'analyse des déficiences des systèmes existants
Les enjeux du projet
Les bénéfices attendus
Les contraintes relatives au projet
Les acteurs concernés

136
Étude d’opportunité/Lancement


S'assurer de l'intégration du projet au schéma
directeur ou plan directeur






Cohérence du projet dans le plan directeur informatique,
Cohérence du projet dans le système d'information actuel ou
futur,
S'assurer de la participation de la direction du département
utilisateur concerné dans la phase d'initialisation.

S'assurer de la participation au projet des acteurs
concernés : pertinence de l'équipe de projet




Identifier les acteurs de l'équipe de projet et leurs
responsabilités,
Évaluer l'adéquation entre les qualifications des personnes
impliquées et leurs tâches,
Vérifier la participation des principaux utilisateurs à l'équipe
de projet.
137
Étude d’opportunité/Lancement


Vérifier la formalisation de l'approbation du projet :
 Validation de l'étude d'opportunité.





S'assurer que l'étude d'opportunité a été revue par les
directions des départements utilisateurs concernés et par la
direction informatique
Vérifier que l'approbation a été formalisée par écrit
Vérifier la qualité de la personne qui a autorisé la poursuite
du projet

138
Conception générale/Analyse


S'assurer de l'existence d'une analyse comparative
des scénarios possibles : contrôle de la pertinence de
la solution de développement retenue.




Vérifier l'exhaustivité des scénarios proposés, y compris
celui de ne rien faire.
Vérifier la qualité de l'analyse technologique de chaque
alternative.
 Besoins/disponibilités de matériels et de logiciels
 Besoins en formation
 Besoins/disponibilités de ressources humaines
 Faisabilité opérationnelle
 Implication du responsable technique
 Contraintes juridiques/réglementaires
139
Conception générale/Analyse


S'assurer de l'existence d'une analyse comparative
des scénarios possibles : contrôle de la pertinence de
la solution de développement retenue


Vérifier la qualité de l'analyse économique de chaque
alternative
 Coûts de développement
 Coûts de formation
 Coûts de maintenance/exploitation
 Coûts de conversion/migration/paramétrage
 Coûts annexes
 Bénéfices attendus
 Coûts de fonctionnement
 Implication du responsable utilisateur
140
Conception générale/Analyse


S'assurer de l'existence d'une analyse comparative
des scénarios possibles : contrôle de la pertinence de
la solution de développement retenue




Vérifier l'existence d'une analyse des risques pour chaque
alternative
 Valeur et sensibilité des informations traitées
 Vulnérabilités
 Besoins correspondant en matière de contrôles internes
 Implication du responsable sécurité
S'assurer de l'existence de critères d'évaluation pour
réaliser l'analyse comparative en toute objectivité

141
Conception générale/Analyse


Vérifier la prise en compte des aspects de contrôle
interne et de sécurité dans l'élaboration du cahier des
charges afin d'assurer la sécurité du futur
développement







S'assurer que la conception générale du futur système
s'inscrit dans les objectifs généraux de contrôle en vigueur
dans l'environnement.
S'assurer que les contrôles d'exploitation ont été identifiés.
S'assurer de la prise en considération des besoins
spécifiques en matière de contrôles.
S'assurer de l'identification et de la description des besoins
en matière de contrôles programmés.

142
Conception générale/Analyse


Vérifier la formalisation de la poursuite du projet :
validation de la conception générale et choix de la
solution de développement








S'assurer que les études de faisabilité proposées ont été
revues par les membres du Comité du Projet
S'assurer de la présentation des différentes solutions
possibles au Comité de Pilotage
Vérifier la qualité de la personne qui a autorisé la poursuite
du projet
Vérifier l'existence d'une approbation écrite

143
Conception détaillée


S'assurer de l'utilisation d'une méthode d'analyse et
de conception: qualité de la phase de conception.






Vérifier l'existence d'une méthode d'analyse/de conception
S'assurer que cette méthode est correctement utilisée
Evaluer la maîtrise de cette méthode

Vérifier la conformité des spécifications détaillées au
cahier des charges : correcte interprétation des
besoins exprimés.




Vérifier l'exhaustivité des spécifications détaillées par
rapport à la conception générale
Evaluer la définition et la documentation des spécifications .

144
Conception détaillée


Vérifier la qualité des contrôles programmés





Vérifier l'existence de contrôles adaptés à chaque point
critique du système
 Contrôles préventifs
 Vérifier l'existence et la pertinence des contrôles correctifs
S'assurer de l'implication du responsable de la sécurité
Vérifier l'existence de pistes d'audit permettant de suivre la
totalité des transactions de leur point d'origine jusqu'aux
totalisations de contrôle correspondantes et vice-versa

145
Conception détaillée




S'assurer de l'implication suffisante des acteurs
concernés (utilisateurs, administrateurs de données,
responsable sécurité,…)
Vérifier la formalisation de la validation de la
conception détaillée








S'assurer que la conception détaillée préparée a été revue
par les membres du Comité de Projet
S'assurer que le document a été présenté au Comité de
Projet
Vérifier la qualité de la personne qui a autorisé la poursuite
du Projet
Vérifier l'existence d'une approbation écrite
146
Recommandations en matière de spécification


Pour assurer que la réalisation du logiciel correspond aux
besoins, au minimum, les documents suivants doivent exister:


Spécifications externes (ou spécifications fonctionnelles)
 Ce

document décrit, précisément et clairement, toutes les
caractéristiques du logiciel à réaliser (fonctions, contraintes, règles
de calcul) ainsi que toutes les interfaces externes. Une fois
approuvé par le utilisateurs, il constitue le document de référence.
Toutes les caractéristiques seront décrites de façon à ce qu'il soit
possible d'en vérifier objectivement la réalisation



Spécifications internes (ou spécifications organiques globales)
 Ce

document décrit tous les éléments d'architecture du système,
c'est-à-dire, les sous -ensembles à réaliser en précisant leurs
fonctions, et tous les éléments communs (modules de service,
fichiers, tables, bases de données, interfaces,…)

147
Développement/Réalisation


S'assurer de l'utilisation d'une méthode de
développement (pérennité et fiabilité des traitements)






Vérifier l'existence d'une méthode de développement
S'assurer que cette méthode est correctement utilisée
Évaluer la maîtrise de cette méthode par les développeurs

Vérifier le respect des normes de documentation et de
vérification





Étudier la pertinence des normes en vigueur
Vérifier l'application de ces normes par les développeurs
Apprécier la qualité de la documentation
S'assurer de la revue par le responsable du services études
de la documentation constituée
148
Développement/Réalisation




Vérifier la formalisation d'un programme général de
tests
Vérifier l'existence d'un plan de mise en place.




Vérifier l'existence et la pertinence du plan de mise en place
Vérifier l'approbation et la diffusion du plan de mise en place
S'assurer que le plan de mise en place définit au minimum :
 La nature des travaux à réaliser et leur ordonnancement
 Les charges de travail correspondantes et la durée des
travaux
 Les acteurs concernés
 Leurs rôles et responsabilités

149
Développement/Réalisation


Vérifier l'existence de procédures de contrôle et de
sécurité lors de la migration : assurer la réussite du
projet de conversion







Vérifier l'existence et la pertinence du plan du plan de
migration
S'assurer du respect des normes de développement et de
vérification du programme de conversion
S'assurer du respect des procédures de contrôles en
matière de passage en production
Vérifier l'existence d'une image des systèmes et des
données avant et après conversion
Vérifier l'implication du responsable assurance qualité dans
le processus de conversion
S'assurer de la formalisation de l'examen et de l'approbation
des résultats du processus de conversion par les directions
concernées

150
Développement/Réalisation


Objectif : Personnaliser le progiciel pour répondre
aux besoins exprimés par les utilisateurs




Définir et enregistrer les paramètres de configuration pour
adapter le progiciel au contexte organisationnel et technique
cible
Faire réaliser les adaptations spécifiques nécessaires pour
satisfaire les besoins non couverts

151
Paramétrage (Solution Progiciel)


Vérifier l'existence du dossier de spécification du
paramétrage






Le dossier doit consigner les options retenues sur le produit
(approche itérative en partant des options les plus
structurantes)
La démarche constitué par l'éditeur peut constituer le fil
conducteur pour le travail de paramétrage

Vérifier qu'un prototype représentatif a été réalisé
(implication des utilisateurs)

152
Qualification: tests/Recettes


Les tests représentent le vecteur principal de
l’amélioration de la qualité de l’application



Cependant, tester reste une des activités les moins
populaires chez les développeurs d’applications. En
effet, contrairement à la conception ou à la production
de code, le test ne génère que des fiches d’anomalies



De plus, étant réalisés en fin de processus de
développement, les tests ont tendance à être limités,
voire « oubliés », du fait des retards déjà accumulés
et de la pression pouvant être exercée sur l’équipe de
projet.
153
Tests/Recettes


La phase de tests constitue néanmoins une activité
centrale puisqu’elle assure la qualité absolument
nécessaire qui n’est fournie ni par les logiciels de
conception, ni par les outils de développements



Les conséquences économiques et financières
démontrent la nécessité de tester les applications en
cours de développement ; néanmoins, il est
impossible de tester l'application entièrement



Une partie importante des problèmes d’exploitation
résulte de défaillances de tests
154
Tests/Recettes


S'assurer du respect des normes de recette finale :
Procès-verbal (PV) de recette








Vérifier l'existence et la pertinence d'une procédure
formalisée de recette finale destinée à accepter formellement
l’application
Vérifier la participation active des acteurs concernés
S'assurer de la maîtrise suffisante du système par les
personnes impliquées dans la recette
Vérifier la pertinence des jeux d'essais et s'assurer de
l'étendue des tests
S'assurer que les tests de performances sont réalisés dans
les futures conditions d'exploitation du système
S'assurer de la formalisation des résultats des jeux d'essais
et de la recette finale par la direction du département
utilisateur
155
Conduite du changement






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.
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 la conduite du changement est structurée en 6
phases :







Identification et évaluation des changements,
Plan de communication,
Plan de formation,
Élaboration définitive de la documentation,
Organisation du soutien,
Reprise des données.
156
Conduite du changement


Identification et évaluation des changements





Existe-t-il une synthèse de l'évaluation des changements ?
L'évaluation a t-elle été validée ?
S'assurer que les entretiens réalisés sont représentatifs ?
Les utilisateurs participent-ils à l'évaluation des
changements ?

157
Conduite du changement


Plan de communication







Existe-t-il un plan de communication ?
Est-il complet ?
Les messages sont-ils clairs et simples ?
Y-a-t-il une progressivité de la communication par rapport au
développement du projet ?
Existe-t-il un soutien fort de la Maîtrise d'Ouvrage ?

158
Conduite du changement


Plan de formation










Vérifier l'existence d'un plan de formation des utilisateurs et
des opérateurs.
La hiérarchie des personnes à former est-elle impliquée ?
Vérifier l'identification des profils types des personnes à
former.
Vérifier la pertinence de la population à former.
Les objectifs de chaque formation sont-ils identifiés et
affichés?
Evaluer les cessions et apporter les éventuelles adaptions.

159
Conduite du changement


Plan de formation (suite)








Vérifier l'adéquation du planning de formation au planning
du projet.
Vérifier la pertinence de la durée du programme de
formation.
S'assurer de la qualité pédagogique des formateurs et du
contenu de la formation.
Vérifier l'existence d'une procédure d'évaluation des formés
et des formateurs.

160
Conduite du changement


Élaboration de la documentation






Vérifier l'existence d'un manuel d'utilisation, d'un aide
mémoire, d'un guide utilisateurs, d'une aide en ligne.
S'assurer de la bonne répartition entre documentation en
ligne et documentation papier.
Les accès à la documentation répondent-ils en priorité aux
besoins des utilisateurs ?

161
Conduite du changement


Vérifier l'existence d'un manuel utilisateurs






Vérifier que le manuel utilisateurs est conforme aux normes
en vigueur.
S'assurer de sa disponibilité et de sa compréhension par
l'ensemble des utilisateurs.
Vérifier qu'il comprend au minimum :
 les objets du système et la description des dessins d'écran
et des commandes disponibles,
 les responsabilités concernant le redressement des erreurs
ou anomalies,.
 La description des sorties et leur mode de diffusion,
 Les responsabilités en matière de
sauvegarde/archivage/purge.
S'assurer qu'il fait l'objet d'une procédure de mise à jour.
162
Conduite du changement


Vérifier l'existence d'un manuel d'exploitation.







Vérifier que le manuel d'exploitation est conforme aux
normes en vigueur.
S'assurer de son accessibilité et de sa compréhension par
les opérateurs.
S'assurer qu'il a été testé lors des tests finaux.
Vérifier qu'il comprend au minimum :
 la fonction des programmes,
 le libellé exact des fichiers concernés,
 la liste des messages opérateurs et les réponses attendues,
 les actions à suivre en cas d'anomalies,
 la liste des états générés et leurs destinations,
 les procédures de reprise,
 les responsabilités de l'exploitation en matière de contrôles
globaux.
S'assurer qu'il fait l'objet d'une procédure de mise à jour.
163
Conduite du changement


Organisation du soutien







Une organisation d'assistance aux utilisateurs a-t-elle été
mise en place dans la phase d'exploitation du nouveau
système ?
Son organisation générale a-t-elle été bien anticipée ?
S'assurer de la disponibilité réelle d'une formation et d'une
expertise.
Les différents niveaux de soutien sont-ils coordonnés et
cohérents ?

164
Conduite du changement


Reprise des données








Existe-t-il un dossier d'organisation de la reprise des
données ?
Le niveau de qualité des données d'origine est-il bien
maîtrisé ?
S'assurer de la mise en place de contrôles automatiques de
la qualité des données obtenues après reprise.
S'assurer de la mobilisation le plus tôt possible des
utilisateurs devant participer à la reprise des données.

165
Conduite du changement


Le bilan qualité comporte deux parties :



Le bilan qualité élaboré en référence au PAQ,
Le bilan qualité exprimé par les utilisateurs.

166
Bilan Qualité


Bilan de la qualité du logiciel élaboré en référence au PAQ :




Réalisé en prenant comme référence les exigences qualité fixées
par la maîtrise d’ouvrage, traduites par le maître d’œuvre en
objectifs et critères à respecter par le logiciel.
Exigences fixées par les utilisateurs au niveau du système:
 Conformité

: conformité aux besoins fonctionnels et techniques
exprimés par le cahier des charges fonctionnel et technique ;
 Performance : temps de traitement des échanges courants au
niveau des serveurs doit être inférieur à trois secondes dans au
moins 95% des cas d’utilisations de ces échanges, sur une
journée, pour environ 200 échanges par minute ;
 Sécurité : système disponible et intègre. Système disponible pour
les utilisateurs, tous les jours ouvrés, pour l’ensemble des
traitements, avec une indisponibilité maximale acceptée inférieure
à deux heures par semaine
 Convivialité : système facile d’exploitation sans aucune installation
de logiciel sur le poste client.
167
Bilan Qualité


Bilan qualité exprimé par les utilisateurs





Il est fortement recommandé d’élaborer un bilan en prenant
l’avis direct des utilisateurs.
Cette appréciation peut se recueillir à l’aide d’un
questionnaire qui doit passer en revue tous les aspects du
logiciel.
Critères d’appréciation de la qualité d’un logiciel :
 Complétude et qualité des fonctionnalités présentes,
 Ergonomie,
 Performance,
 Qualité de la documentation,
 Robustesse et fiabilité,
 Formation reçue,
 Qualité et efficacité de l’assistance et du soutien.
168
Exemples de
missions

169
Mission n°1: Contexte et objectifs






Avant de lancer la réalisation d'un nouveau système
destiné à remplacer les outils actuels de gestion
administrative, physique et douanière des
marchandises, une société a souhaité évaluer les
risques liés au projet et étudier l'opportunité d'une
solution alternative de type logiciel intégré.
Cette société travaille avec un prestataire
informatique spécialisé dans le domaine.
Phase d'intervention de la mission:


Définition des Besoins du Système (Cahier des charges en
cours de rédaction)

170
Mission n°1: Contexte et objectifs


Thèmes examinés :








Existence d'une solution satisfaisante "logiciel/progiciel
intégré" unique
Modernité et pertinence technique du projet
Modernité et pertinence fonctionnelle du projet
Montage projet pour la rédaction du cahier des charges et
pour la réalisation du système
Montage contractuel pour la réalisation du système

171
Mission n°1: Personnes rencontrées
Personnes rencontrées
 Directeur général adjoint,
 DSI client,
 Chef de projet EDI client,
 Chef de projet client,
 Directeur technique prestataire,
 Chef de projet prestataire.

172
Mission n°1: Principaux constats


Les solutions "logiciel intégré"






La mise en place d'un logiciel/progiciel intégré unique pour
la gestion des moyens de transport et des marchandises ne
semble pas appropriée (faible intérêt fonctionnel).
Risques humains et sociaux importants dans le contexte de
la ville.
Pas d'offre sur le marché des logiciels/progiciels intégrés
spécifiques pour une gestion globale de ce genre d'activité.
Une solution de ce type unique serait donc coûteuse.

173
Mission n°1: Principaux constats



Principaux constats (suite)
Modernité et pertinence technique du produit
envisagé






La méthode qui a été adoptée pour définir l'architecture
technique cible dans le cahier des charges est satisfaisante.
Globalement, les exigences essentielles ont été posées dans
le cahier des charges pour un réseau de communication
sécurisé appuyé sur des bases de données relationnelles.
Le cahier des charges présente les besoins techniques et
les contraintes à respecter. A ce titre, il est une base pour les
propositions des prestataires.

174
Mission n°1: Principaux constats


Modernité et pertinence fonctionnelle du produit
envisagé




La description des nouvelles fonctionnalités doit être
complétée :
 Les fonctionnalités détaillées sont très proches de celles
existantes ;
 Les nouvelles fonctionnalités sont peu explicites.
Absence d'une réelle étude des besoins

175
Mission n°1: Principaux constats





Montage du projet pour la rédaction du cahier des charges
Des difficultés ont été rencontrées dans le cadre de la rédaction
du cahier des charges.
Manque de clarté dans la définition des rôles et responsabilités
des différents acteurs de la gestion du projet : le chef de projet
utilisateurs (maîtrise d'ouvrage) n'a pas été formellement
identifié.
 Absence d'axe directeur donné au projet qui nuit à la
pertinence et à la cohérence des travaux des responsables
de projet informatiques et explique les différences de points
de vue entre parties à la rédaction du cahier des charges.
 Manque de disponibilité de ressources dédiées qui explique
la dérive dans les délais initialement prévus.

176
Mission n°1: Principaux constats




Montage projet pour la réalisation du système
 Risques importants de dysfonctionnement liés à la structure
pressentie pour la réalisation du système.
 Origine de ces risques : la confusion des rôles entre maîtrise
d'œuvre et maîtrise d'ouvrage.
 Une des causes majeures de l'échec des grands projets (*).
 La MOE tend à se substituer à la MOA sur des sujets qui
relèvent de la responsabilité de la MOA ;
 La réciproque étant vraie (ex : une MOA raisonnant en
termes de solutions).
(*) Projets mobilisant plus d'une dizaine de personnes en pointe,
plus d'un niveau hiérarchique, avec un accent mis sur la gestion
de projet.
177
Mission n°1: Principaux constats




Montage du projet pour la réalisation du système
 Les structures pressenties ne permettent pas de garantir
totalement :
 L'adéquation des fonctionnalités du système réalisé avec
les besoins exprimés,
 La livraison d'un outil techniquement performant,
 La réalisation et la mise en œuvre du système dans des
délais raisonnables.
Montage contractuel pour la réalisation du système
 La question n'a pas été abordée

178
Mission n°1: Recommandations


Recommandations générales


Il semble souhaitable de continuer le projet et pour qu'il se
déroule dans les meilleures conditions possibles, de :
 Nommer un chef de projet utilisateurs ;
 Créer les conditions d'association d'une SSII expérimentée à
la société informatique spécialisée pour la réalisation du
système ;
 Approfondir les possibilités de contractualisation dans le
cadre d'une mise en concurrence pour la réalisation du
système. La mobilisation d'une expertise juridique sur ce
sujet est conseillée.

179
Mission n°1: Recommandations


Pertinence technique du produit




La définition de l'architecture technique cible dans le cahier
des charges est satisfaisante

Pertinence fonctionnelle du produit :




L'absence réelle d’étude des besoins est un handicap
important.
Le caractère novateur du système peut être un atout
concurrentiel important de la société face à ses clients. D’où
la nécessité de vérifier rapidement les évolutions prévisibles
dans ce domaine :
 Auprès de quelques grandes sociétés de transport ;
 Auprès de la société la plus avancée sur le plan mondial
dans le domaine de l'informatisation logistique.
180
Mission n°1: Recommandations






Montage du projet pour la rédaction du cahier des
charges
Désigner un chef de projet utilisateur pour fixer les
orientations générales à donner au projet.
Montage du projet pour la réalisation du système




Même si des procédures adéquates d'arbitrage et de gestion
des relations entre les partenaires ont été prévues dans le
projet de convention pour la réalisation du système ;
Il conviendra de clarifier les rôles de chacun et de réfléchir à
l'opportunité de s'associer les compétences d'un prestataire
informatique expérimenté.

181
Mission n°1: Recommandations


Montage contractuel





Nécessité de choisir une procédure.
Les instances appropriées devront se prononcer sur le choix
d'une procédure pour le montage contractuel (appel d'offre
ouvert, appel d'offre restreint, marché négocié avec ou sans
compétition). Trois modèles de montages contractuels sont
possibles :
 Sous-traitance totale de l'informatique : appel d’offre,
 Parrainage par une société chargée de l'exploitation du
système (situation actuelle).
La solution " marché négocié sans mise en concurrence"
entre le maître d'ouvrage et le maître d'œuvre présenterait
des risques financiers et juridiques qu'il conviendra
d'analyser.
182


Chiffrage du projet






Le chiffrage actuel ne tient pas suffisamment compte de
l'existant, des projet précédents et de la connaissance du
métier et des outils des partenaires.
Le chiffrage du projet pourrait être revu à la baisse sur la
base d'une version validée du cahier des charges.
 On peut noter que lorsqu'une entreprise lance un appel
d'offres pour choisir un prestataire, elle demande une
évaluation du coût du projet.
Toutefois, dans la mesure où les dérives sur les projets de
cette taille sont très fréquentes, il convient de ne pas sousestimer les coûts, qui peuvent se révéler à terme beaucoup
plus élevés.

183
Mission n° 2: Contexte et objectifs




L'objectif de notre intervention consiste, dans le
cadre d'une acquisition potentielle, à dresser une
revue générale de l'informatique pour le compte du
repreneur de la société.
Pour ce faire, notre champ d'étude couvre cinq
domaines :







l’organisation de la fonction informatique,
l’architecture technique,
une revue des applications existantes,
la sécurité du système d'information (sécurité logique et
physique, plan de continuité des opérations, procédures de
développement et de maintenance, etc.),
les contrats de prestations de services.
184
Mission n° 2: Contexte et objectifs


Et essentiellement une prise de connaissance du
projet de migration informatique sur le nouveau
progiciel, y compris les chantiers Euro et An 2000. A
ce titre, nous avons étudié :






Les modalités de choix du progiciel,
L’organisation du projet et son degré d'avancement,
Ainsi que la nature et l’évaluation globale des travaux
restant à réaliser.

Phase d'intervention:


Migration du système d’information vers un progiciel
bancaire dans le cadre de la mise en place d’un schéma
directeur.
185
Mission n° 2: Personnes rencontrées









Directeur informatique et Directeur adjoint,
Responsable Réseau/Micro,
Directeur de l’Organisation,
Directeur de l'Agence Centrale,
Direction Commerciale, Secrétariat Crédits,
Direction des Opérations, Département Etranger,
Département Comptabilité,
Manager d'un cabinet de conseil et d'audit
(Maîtrise d'ouvrage déléguée du projet de migration
vers le nouveau progiciel).
186
Mission n° 2: Principaux constats sur le projet de
migration


De nombreux chantiers ne sont pas encore stabilisés,
le maintien d'un démarrage prévu dans les deux mois
à venir présente des risques importants :







Risques d'insuffisance des tests compte tenu des délais
restants,
États de gestion internes ne répondant que partiellement
aux besoins de la société,
Absence de maîtrise des processus complets d’exploitation,
Risque d'une solution dégradée au démarrage pour
plusieurs applicatifs.

187
Mission n° 2: Principaux constats sur le projet de
migration


Les risques potentiels associés au projet de migration
ont un impact fort sur le plan :






De la continuité de l’activité
 Absence de solution de secours sur le système cible.
Des coûts de mise en place
 Le budget de vingt millions de francs initialement alloué au
projet de migration est largement dépassé. Le non-respect
des délais fixés est susceptible de générer un surcoût
important (assistance supplémentaire de prestataires...).
De la continuité de l’exploitation
 Perturbations organisationnelles et fonctionnelles,
 Insuffisance de tests compte tenu des délais fixés,
 Maîtrise partielle ou insuffisante de l’enchaînement des
processus d’exploitation.
188
Mission n° 2: Principaux constats sur le projet de
migration




Les risques potentiels associés au projet de migration ont un
impact fort sur le plan (suite) :
 Du respect des exigences réglementaires et interbancaires
 De la solution de secours
 Faible visibilité à ce jour sur la pertinence des solutions
minimales requises.
 De la forte dépendance de l’établissement vis-à-vis de
l’éditeur du logiciel,
 De la motivation des équipes dédiées au projet
 Leur mobilisation est une condition indispensable au
succès de la migration.
Le maintien d'un démarrage dans les deux mois à venir présente
des risques de perturbations importants et/ou de blocages non
maîtrisés,
189
Mission n° 2: Recommandations


Compte tenu des risques évoqués, nous
recommandons de ne pas faire l'acquisition de
l'institution financière avant la migration vers le
progiciel



Un audit approfondi devrait être effectué après cette
migration n Nous recommandons de prendre en
compte les risques relatifs à une éventuelle rupture
des contrats informatiques en cours et le cas échéant
procéder à une analyse approfondie des contrats par
un juriste spécialisé.
190
Mission n° 3: Contexte et objectifs






Notre mission consiste à effectuer une revue d’un
dispositif téléindicateur pour le compte d’une grande
entreprise de transport.
La Maîtrise d’œuvre est assurée par une PME
spécialisée dans le développement de ce type de
produit.
Phase d'intervention :


Qualification/homologation du système : tests et recettes.

191
Mission n° 3: Personnes rencontrées
Personnes rencontrées
 Au niveau du maître d'œuvre :






Président Directeur Général de l'entreprise,
Directeur Commercial,
Chef de Projet.

Au niveau de l'entreprise de transport :




Représentant des utilisateurs,
Commanditaire du système,
Chargé de la maintenance du système sur site.

192
Mission n° 3: Principaux constats


Diagnostic général






La réception définitive du système n’est pas prononcée
(portefeuille de bogues important) ;
Le projet a engagé à ce jour des charges significativement
supérieures aux coûts prévus et n’est pas économiquement
en mesure, de prendre toutes les initiatives qui pourraient
être nécessaires ;
La maîtrise technique du système est concentrée sur une
seule personne. Cette situation est fragilisante pour le client.

193
Mission n° 3: Principaux constats


Le projet








Pas de méthode de conduite de projet,
Modifications effectuées pendant les développements sans
mise à jour de la documentation,
Peu de suivi de projet (planification et suivi d'avancement),
Manque de procédures,
Documentation inexistante ou inexploitable,
Formation des utilisateurs très insuffisante,

194
Mission n° 3: Principaux constats





Plate-forme de tests et qualification insuffisantes,
Procédure de gestion des anomalies trop peu
rigoureuse,
Contribution insuffisante de la maîtrise d'ouvrage
dans les phases de tests,






Aucun plan d'acceptation du système fourni par la maîtrise
d'ouvrage,
Manque de communication entre maîtrise d'œuvre et la
maîtrise d'ouvrage,
Relations conflictuelles entre la MOA et MOE.

195
Mission n° 3: Principaux constats



Le logiciel
Points faibles:






Produit incomplet,
Ne peut fournir le service attendu sans incidents,
Niveau de maintenabilité très insuffisant.

Point fort:


Caractère évolutif du produit

196
Mission n° 3: Recommandations


Organisation du projet :






Nécessité de mettre en place une nouvelle équipe de projet
et de prévoir une période de transition,
Formaliser une procédure précisant les modalités de
collaboration entre les utilisateurs et la fonction
informatique : confusion MOA/MOE,
Préciser les responsabilités de la MOE et de la MOA.

197
Mission n° 3: Recommandations


Contrôle du projet :












Continuer de stabiliser l'existant i.e. les demandes
d'évolution doivent rester gelées
Envisager l'acquisition d'outils performants de
développements pour améliorer la qualité du logiciel,
Nécessité de gérer la configuration et les versions du
logiciel,
Nécessité de mettre en œuvre une gestion rigoureuse des
anomalies,
Suivre une démarche de mise au point et de qualification du
logiciel en mettant en œuvre des procédures de tests,
La mise en place d'un site pilote est indispensable dans la
procédure de qualification.
198
Mission n° 3: Recommandations


Documentation :


Nécessité de constituer une documentation du système en
précisant :
 Les spécifications externes ou fonctionnelles,
 Les spécifications internes ou organiques globales,
 L'architecture technique globale et l'architecture modulaire
détaillée (les documents sont manuscrits),

199
Mission n° 3: Recommandations


Documentation (suite) :









Le plan de développement : document contenant les
informations de planification liées au développement du
logiciel.
Le découpage du projet en tâches élémentaires et
l’estimation de la charge de réalisation de chaque tâche en
précisant la compétence choisie et le temps requis ;
La planification des tâches et la consommation induite des
ressources
Les événements clés permettant de contrôler l’avancement.
On pourra ainsi mesurer le suivi d’avancement du projet en
comparant ressources consommées/résultats obtenus d’une
part et délais prévisionnels/délais réels d’autre part.
200
Mission n° 3: Recommandations


Documentation :


Nécessité de constituer un dossier « Utilisateurs »
comportant :
 Le manuel utilisateur
 Le guide de maintenance

201
Mission n° 3: Recommandations


Communication :








Implication de la direction générale dans la gestion des
projets,
Raisonner en terme de structure et non en terme de
personnes,
Respecter les rôles et responsabilités de chacun,
Compréhension du logiciel par les utilisateurs,
Participation importante des utilisateurs.

202
Conclusion

203
Les causes principales de dysfonctionnement
sont:






Une mauvaise prévision : mauvaise prévision des
tâches à effectuer, mauvaise prévision des
conséquences de la mise en place du nouveau
système
Une mauvaise organisation : partage des rôles entre
les intervenants imprécis, fonctions non identifiées,
taux de participation trop flou
Une mauvaise communication : contexte et objectifs
du projet méconnus, validations implicites,
interlocuteurs concernés non impliqués, compterendu insuffisant du maître d'œuvre au directeur de
projet
204
Les causes principales de dysfonctionnement
sont:






Des engagements contractuels mal définis entre la
maîtrise d'ouvrage et la maîtrise d'œuvre.
Les conséquences de ces dysfonctionnements
peuvent être un surcroît de charges, un allongement
des délais, une mauvaise qualité du logiciel ou des
services offerts aux utilisateurs pouvant aller même
jusqu'au rejet de l'application.

205
Maîtriser le développement du projet


Au plan de l'organisation :







Une implication forte de la hiérarchie ;
Des représentants maîtrise d'ouvrage et maîtrise d'œuvre
désignés ;
Des structures de travail (groupes utilisateurs, de pilotage)
et de décision (comité directeur, comité exécutif) équilibrées,
effectives et représentatives ;
Des rôles bien définis pour chaque participant

206
Maîtriser le développement du projet


Au plan de l'organisation (suite):









Un document de départ à l'intention de la maîtrise d'œuvre
définissant clairement les objectifs du projet, les contraintes
et les résultats attendus, les exigences de qualité et les
travaux préalables ;
Un calendrier et un budget prévoyant à l'avance les tâches à
effectuer et leur durée ;
Un tableau de bord et des procédures de contrôle de
l'avancement ;
Des procédures de validation et de recette ;
Un plan d'actions pour la maîtrise d'ouvrage.

207
Maîtriser le développement du projet


Au plan des méthodes et des outils :








Une démarche : succession de tâches à assumer et de
résultats à produire ;
Une méthode d'évaluation des charges ;
Une méthode de planification et de suivi de l'avancement
permettant d'avoir en permanence une bonne visibilité sur
'avancement du projet ;
Un plan d'assurance qualité ;
Des outils : atelier de génie logiciel, outil de conduite de
projet, etc.

208
Maîtriser le développement du projet






Toutes ces dispositions préétablies et systématiques
destinées à donner confiance en l'obtention de la
qualité requise doivent être consignées dans un plan
d'assurance qualité (PAQ).
Ce plan doit être spécifique à chaque projet et établi
en fonction des exigences qualité formulées par la
maîtrise d'ouvrage.
Les exigences qualité doivent être traduites en
facteurs qualité ou en critères qualité véritables.

209
Mohamed SAÂD

Saadmedin@yahoo.fr

Viser à l’ensemble, et
se mettre à l’œuvre
par les détails
(Proverbe chinois)
210

Contenu connexe

Tendances

7-AMDEC.ppt
7-AMDEC.ppt7-AMDEC.ppt
7-AMDEC.ppt
TMisSaM
 
L’identification, l’analyse et l’évaluation des risques selon l’ISO 31000 : l...
L’identification, l’analyse et l’évaluation des risques selon l’ISO 31000 : l...L’identification, l’analyse et l’évaluation des risques selon l’ISO 31000 : l...
L’identification, l’analyse et l’évaluation des risques selon l’ISO 31000 : l...
PECB
 
Tableaux de bord
Tableaux de bordTableaux de bord
Tableaux de bord
stephaneGillieron
 
Audit informatique
Audit informatiqueAudit informatique
Audit informatique
FINALIANCE
 
Valeur ajoutee de l'audit de performance
Valeur ajoutee de l'audit de performanceValeur ajoutee de l'audit de performance
Valeur ajoutee de l'audit de performanceicgfmconference
 
Memoire conception-mise-en-place-tableaux-de-bord-gestion-societe-confection[1]
Memoire conception-mise-en-place-tableaux-de-bord-gestion-societe-confection[1]Memoire conception-mise-en-place-tableaux-de-bord-gestion-societe-confection[1]
Memoire conception-mise-en-place-tableaux-de-bord-gestion-societe-confection[1]Brahim Mouacha
 
Tableau de bord prospectif
Tableau de bord prospectifTableau de bord prospectif
Tableau de bord prospectif
ABDELDJALIL DERRASCHOUK
 
Gouvernance du système d'information et parties prenantes
Gouvernance du système d'information et parties prenantesGouvernance du système d'information et parties prenantes
Gouvernance du système d'information et parties prenantes
Abdeslam Menacere
 
Le controle interne-pratique
Le controle interne-pratiqueLe controle interne-pratique
Le controle interne-pratique
Hervé Boullanger
 
Guide pratique de l'audit oec maroc
Guide pratique de l'audit   oec marocGuide pratique de l'audit   oec maroc
Guide pratique de l'audit oec marocbissa bissa
 
Audit sécurité des systèmes d’information
Audit sécurité des systèmes d’informationAudit sécurité des systèmes d’information
Audit sécurité des systèmes d’information
Abbes Rharrab
 
Gestion des risques bancaires
Gestion des risques bancairesGestion des risques bancaires
Gestion des risques bancaires
Zouhair Aitelhaj
 
Cobit v4.1
Cobit v4.1Cobit v4.1
Le tableau de bord de pilotage
Le tableau de bord de pilotageLe tableau de bord de pilotage
Le tableau de bord de pilotage
Verbinnen Dominique
 
Référentiels et Normes pour l'Audit de la Sécurité des SI
Référentiels et Normes pour l'Audit de la Sécurité des SIRéférentiels et Normes pour l'Audit de la Sécurité des SI
Référentiels et Normes pour l'Audit de la Sécurité des SI
Alghajati
 
DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE
DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGEDEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE
DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE
hpfumtchum
 
Tableau de bord, outil de pilotage du dirigeant d'entreprise
Tableau de bord, outil de pilotage du dirigeant d'entrepriseTableau de bord, outil de pilotage du dirigeant d'entreprise
Tableau de bord, outil de pilotage du dirigeant d'entreprise
Pascal Méance
 
GOUVERNANCE BANCAIRE ET RISQUE DE CRÉDIT
GOUVERNANCE BANCAIRE ET RISQUE DE CRÉDITGOUVERNANCE BANCAIRE ET RISQUE DE CRÉDIT
GOUVERNANCE BANCAIRE ET RISQUE DE CRÉDIT
Mohamed Messaoudi
 
Gestion des risques
Gestion des risquesGestion des risques
Gestion des risques
Aymen Foudhaili
 
La Gouvernance IT
La Gouvernance ITLa Gouvernance IT
La Gouvernance IT
Nicolas PIGNAL
 

Tendances (20)

7-AMDEC.ppt
7-AMDEC.ppt7-AMDEC.ppt
7-AMDEC.ppt
 
L’identification, l’analyse et l’évaluation des risques selon l’ISO 31000 : l...
L’identification, l’analyse et l’évaluation des risques selon l’ISO 31000 : l...L’identification, l’analyse et l’évaluation des risques selon l’ISO 31000 : l...
L’identification, l’analyse et l’évaluation des risques selon l’ISO 31000 : l...
 
Tableaux de bord
Tableaux de bordTableaux de bord
Tableaux de bord
 
Audit informatique
Audit informatiqueAudit informatique
Audit informatique
 
Valeur ajoutee de l'audit de performance
Valeur ajoutee de l'audit de performanceValeur ajoutee de l'audit de performance
Valeur ajoutee de l'audit de performance
 
Memoire conception-mise-en-place-tableaux-de-bord-gestion-societe-confection[1]
Memoire conception-mise-en-place-tableaux-de-bord-gestion-societe-confection[1]Memoire conception-mise-en-place-tableaux-de-bord-gestion-societe-confection[1]
Memoire conception-mise-en-place-tableaux-de-bord-gestion-societe-confection[1]
 
Tableau de bord prospectif
Tableau de bord prospectifTableau de bord prospectif
Tableau de bord prospectif
 
Gouvernance du système d'information et parties prenantes
Gouvernance du système d'information et parties prenantesGouvernance du système d'information et parties prenantes
Gouvernance du système d'information et parties prenantes
 
Le controle interne-pratique
Le controle interne-pratiqueLe controle interne-pratique
Le controle interne-pratique
 
Guide pratique de l'audit oec maroc
Guide pratique de l'audit   oec marocGuide pratique de l'audit   oec maroc
Guide pratique de l'audit oec maroc
 
Audit sécurité des systèmes d’information
Audit sécurité des systèmes d’informationAudit sécurité des systèmes d’information
Audit sécurité des systèmes d’information
 
Gestion des risques bancaires
Gestion des risques bancairesGestion des risques bancaires
Gestion des risques bancaires
 
Cobit v4.1
Cobit v4.1Cobit v4.1
Cobit v4.1
 
Le tableau de bord de pilotage
Le tableau de bord de pilotageLe tableau de bord de pilotage
Le tableau de bord de pilotage
 
Référentiels et Normes pour l'Audit de la Sécurité des SI
Référentiels et Normes pour l'Audit de la Sécurité des SIRéférentiels et Normes pour l'Audit de la Sécurité des SI
Référentiels et Normes pour l'Audit de la Sécurité des SI
 
DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE
DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGEDEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE
DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE
 
Tableau de bord, outil de pilotage du dirigeant d'entreprise
Tableau de bord, outil de pilotage du dirigeant d'entrepriseTableau de bord, outil de pilotage du dirigeant d'entreprise
Tableau de bord, outil de pilotage du dirigeant d'entreprise
 
GOUVERNANCE BANCAIRE ET RISQUE DE CRÉDIT
GOUVERNANCE BANCAIRE ET RISQUE DE CRÉDITGOUVERNANCE BANCAIRE ET RISQUE DE CRÉDIT
GOUVERNANCE BANCAIRE ET RISQUE DE CRÉDIT
 
Gestion des risques
Gestion des risquesGestion des risques
Gestion des risques
 
La Gouvernance IT
La Gouvernance ITLa Gouvernance IT
La Gouvernance IT
 

En vedette

Evaluation: Question 7
Evaluation: Question 7Evaluation: Question 7
Evaluation: Question 7
emmagranfield
 
Digipack decon 1
Digipack decon 1Digipack decon 1
Digipack decon 1
emmagranfield
 
Year 2 intro talk
Year 2 intro talkYear 2 intro talk
Year 2 intro talk
Nottingham Trent University
 
Remove the inner_beast_in
Remove the inner_beast_inRemove the inner_beast_in
Remove the inner_beast_in
robinjager
 
Evaluation: Question 3
Evaluation: Question 3Evaluation: Question 3
Evaluation: Question 3
emmagranfield
 
Special offer tools
Special offer toolsSpecial offer tools
Special offer tools
shate-m
 
0 flipped ppt
0 flipped ppt0 flipped ppt
Critical writing + first part of session
Critical writing + first part of sessionCritical writing + first part of session
Critical writing + first part of session
Nottingham Trent University
 
Music video decon 3
Music video decon 3Music video decon 3
Music video decon 3
emmagranfield
 
Catalog
 Catalog Catalog
Catalogshate-m
 
Pitch
PitchPitch
Andrew Goodwin’s key characteristics of a music video
Andrew Goodwin’s key characteristics of a music videoAndrew Goodwin’s key characteristics of a music video
Andrew Goodwin’s key characteristics of a music video
emmagranfield
 
Designing lessons
Designing lessonsDesigning lessons
Designing lessons
Nottingham Trent University
 
Audiowire presentationnn
Audiowire presentationnnAudiowire presentationnn
Audiowire presentationnn
robinjager
 
Catalog ru
 Catalog ru Catalog ru
Catalog ru
shate-m
 
Haïti - Arrestation arbitraire de Me André Michel
Haïti - Arrestation arbitraire de Me André MichelHaïti - Arrestation arbitraire de Me André Michel
Haïti - Arrestation arbitraire de Me André Michel
JLMB
 
test
testtest
test
shate-m
 

En vedette (20)

03 préparer le pmp management des coût
03 préparer le pmp   management des coût03 préparer le pmp   management des coût
03 préparer le pmp management des coût
 
01 préparer le pmp management du contenu
01 préparer le pmp   management du contenu01 préparer le pmp   management du contenu
01 préparer le pmp management du contenu
 
Le management de projet
Le management de projetLe management de projet
Le management de projet
 
Evaluation: Question 7
Evaluation: Question 7Evaluation: Question 7
Evaluation: Question 7
 
Digipack decon 1
Digipack decon 1Digipack decon 1
Digipack decon 1
 
Year 2 intro talk
Year 2 intro talkYear 2 intro talk
Year 2 intro talk
 
Remove the inner_beast_in
Remove the inner_beast_inRemove the inner_beast_in
Remove the inner_beast_in
 
Evaluation: Question 3
Evaluation: Question 3Evaluation: Question 3
Evaluation: Question 3
 
Special offer tools
Special offer toolsSpecial offer tools
Special offer tools
 
0 flipped ppt
0 flipped ppt0 flipped ppt
0 flipped ppt
 
Critical writing + first part of session
Critical writing + first part of sessionCritical writing + first part of session
Critical writing + first part of session
 
Music video decon 3
Music video decon 3Music video decon 3
Music video decon 3
 
Catalog
 Catalog Catalog
Catalog
 
Pitch
PitchPitch
Pitch
 
Andrew Goodwin’s key characteristics of a music video
Andrew Goodwin’s key characteristics of a music videoAndrew Goodwin’s key characteristics of a music video
Andrew Goodwin’s key characteristics of a music video
 
Designing lessons
Designing lessonsDesigning lessons
Designing lessons
 
Audiowire presentationnn
Audiowire presentationnnAudiowire presentationnn
Audiowire presentationnn
 
Catalog ru
 Catalog ru Catalog ru
Catalog ru
 
Haïti - Arrestation arbitraire de Me André Michel
Haïti - Arrestation arbitraire de Me André MichelHaïti - Arrestation arbitraire de Me André Michel
Haïti - Arrestation arbitraire de Me André Michel
 
test
testtest
test
 

Similaire à Audit des projets informatiques

Comment sélectionner les applications de gestion de projet appropriées?
Comment sélectionner les applications de gestion de projet appropriées?Comment sélectionner les applications de gestion de projet appropriées?
Comment sélectionner les applications de gestion de projet appropriées?
PMI-Montréal
 
Chapitre 1 introgestion projetduction à la gestion de projet [mode de compat...
Chapitre 1  introgestion projetduction à la gestion de projet [mode de compat...Chapitre 1  introgestion projetduction à la gestion de projet [mode de compat...
Chapitre 1 introgestion projetduction à la gestion de projet [mode de compat...
el mahdi Barhourhe
 
Keydra france presentation-inst-20111124
Keydra france presentation-inst-20111124Keydra france presentation-inst-20111124
Keydra france presentation-inst-20111124
Denis Boehringer
 
Gestion de projets
Gestion de projetsGestion de projets
Gestion de projets
Sana REFAI
 
E-business - développement
E-business - développementE-business - développement
E-business - développement
Manon Cuylits
 
Management de projets si 4 g - 1 - best practices 1 - 2014 (1)
Management de projets si   4 g - 1 - best practices 1 - 2014 (1)Management de projets si   4 g - 1 - best practices 1 - 2014 (1)
Management de projets si 4 g - 1 - best practices 1 - 2014 (1)adrien990
 
Gestion de Projets
Gestion de Projets Gestion de Projets
Gestion de Projets
Said Sadik
 
Web-conférence - Lean Engineering
Web-conférence - Lean EngineeringWeb-conférence - Lean Engineering
Web-conférence - Lean Engineering
XL Groupe
 
Acquisition, Conception et Implantation des SI
Acquisition, Conception et Implantation des SIAcquisition, Conception et Implantation des SI
Acquisition, Conception et Implantation des SI
Arsène Ngato
 
Etude comparative iso 9001 vs iso 27001.ppt
Etude comparative  iso 9001 vs iso 27001.pptEtude comparative  iso 9001 vs iso 27001.ppt
Etude comparative iso 9001 vs iso 27001.ppt
Khouloud Errachedi
 
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
LeClubQualiteLogicielle
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
Pierre
 
Les principales méthodes de gestion de projets
Les principales méthodes de gestion de projetsLes principales méthodes de gestion de projets
Les principales méthodes de gestion de projets
Laurence Genty
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
Nouhaila ALAMI
 
2015-04-29 Jean Cloutier Structure de découpage de projet
2015-04-29 Jean Cloutier Structure de découpage de projet2015-04-29 Jean Cloutier Structure de découpage de projet
2015-04-29 Jean Cloutier Structure de découpage de projet
PMI Lévis-Québec
 
Cm6.09 part2 pilotage_projet ing
Cm6.09 part2 pilotage_projet ingCm6.09 part2 pilotage_projet ing
Cm6.09 part2 pilotage_projet ingidigroupe6
 
Lean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesLean Software Development et pratiques Agiles
Lean Software Development et pratiques Agiles
Eric Le Merdy
 

Similaire à Audit des projets informatiques (20)

Comment sélectionner les applications de gestion de projet appropriées?
Comment sélectionner les applications de gestion de projet appropriées?Comment sélectionner les applications de gestion de projet appropriées?
Comment sélectionner les applications de gestion de projet appropriées?
 
Chapitre 1 introgestion projetduction à la gestion de projet [mode de compat...
Chapitre 1  introgestion projetduction à la gestion de projet [mode de compat...Chapitre 1  introgestion projetduction à la gestion de projet [mode de compat...
Chapitre 1 introgestion projetduction à la gestion de projet [mode de compat...
 
Keydra france presentation-inst-20111124
Keydra france presentation-inst-20111124Keydra france presentation-inst-20111124
Keydra france presentation-inst-20111124
 
Gestion de projets
Gestion de projetsGestion de projets
Gestion de projets
 
Retour d'expérience mise en oeuvre One2Team
Retour d'expérience mise en oeuvre One2TeamRetour d'expérience mise en oeuvre One2Team
Retour d'expérience mise en oeuvre One2Team
 
E-business - développement
E-business - développementE-business - développement
E-business - développement
 
Management de projets si 4 g - 1 - best practices 1 - 2014 (1)
Management de projets si   4 g - 1 - best practices 1 - 2014 (1)Management de projets si   4 g - 1 - best practices 1 - 2014 (1)
Management de projets si 4 g - 1 - best practices 1 - 2014 (1)
 
Gestion de Projets
Gestion de Projets Gestion de Projets
Gestion de Projets
 
Web-conférence - Lean Engineering
Web-conférence - Lean EngineeringWeb-conférence - Lean Engineering
Web-conférence - Lean Engineering
 
00 contexte gén management de l'intégration
00 contexte gén   management de l'intégration00 contexte gén   management de l'intégration
00 contexte gén management de l'intégration
 
Acquisition, Conception et Implantation des SI
Acquisition, Conception et Implantation des SIAcquisition, Conception et Implantation des SI
Acquisition, Conception et Implantation des SI
 
Etude comparative iso 9001 vs iso 27001.ppt
Etude comparative  iso 9001 vs iso 27001.pptEtude comparative  iso 9001 vs iso 27001.ppt
Etude comparative iso 9001 vs iso 27001.ppt
 
00 préparer le pmp contexte gén - management de l'intégration
00 préparer le pmp   contexte gén - management de l'intégration00 préparer le pmp   contexte gén - management de l'intégration
00 préparer le pmp contexte gén - management de l'intégration
 
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
 
Les principales méthodes de gestion de projets
Les principales méthodes de gestion de projetsLes principales méthodes de gestion de projets
Les principales méthodes de gestion de projets
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
 
2015-04-29 Jean Cloutier Structure de découpage de projet
2015-04-29 Jean Cloutier Structure de découpage de projet2015-04-29 Jean Cloutier Structure de découpage de projet
2015-04-29 Jean Cloutier Structure de découpage de projet
 
Cm6.09 part2 pilotage_projet ing
Cm6.09 part2 pilotage_projet ingCm6.09 part2 pilotage_projet ing
Cm6.09 part2 pilotage_projet ing
 
Lean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesLean Software Development et pratiques Agiles
Lean Software Development et pratiques Agiles
 

Dernier

Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
OCTO Technology
 
OCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO TALKS : 4 Tech Trends du Software Engineering.pdfOCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO Technology
 
Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
UNITECBordeaux
 
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Laurent Speyser
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
Université de Franche-Comté
 
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
OCTO Technology
 

Dernier (6)

Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
 
OCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO TALKS : 4 Tech Trends du Software Engineering.pdfOCTO TALKS : 4 Tech Trends du Software Engineering.pdf
OCTO TALKS : 4 Tech Trends du Software Engineering.pdf
 
Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
 
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
 
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
 

Audit des projets informatiques

  • 1. Cycle de Préparation au C.I.S.A Système de développement d’application, acquisition, implémentation et maintenance Mohamed SAÂD I.T.M et consultant en Systèmes d’Information 1
  • 2. SOMMAIRE  I- Développement d’applications informatiques  Approche traditionnelle SDLC  Rôles et responsabilités des groupes et des individus  Risques associés au développement logiciel  Utilisation des techniques d’analyse, de conception et de développement  Description des phases du SDLC  Méthodologies de développement du logiciel Systèmes de développement Orientés Objet  Prototypage  RAD  AGILE  Reengineering  Reverse Engineering   II- Pratiques de maintenance des systèmes d’information  Gestion du changement  Management de la configuration  Contrôle de la librairie logicielle  III- Pratiques de management des projets 2
  • 3. SOMMAIRE  IV- Pratiques d’amélioration des processus de développement du logiciel     ISO 9126 SPICE CMM CMMI  V- Audit des systèmes de développement, de l’acquisition et de la maintenance          Gestion des projets Étude de faisabilité Expression des besoins Processus d’acquisition logiciel Étude détaillé et les phases de développement Phase de tests Phase implémentation Revue de l’implémentation Procédures de changement et processus de migration 3
  • 4. I- La gestion de projets  Gérer c’est:          Organiser Planifier Contrôler Coordonner Diriger Communiquer Décider Déléguer Négocier 4
  • 5. I- La gestion de projets  Ensemble de processus permettant de maîtriser la réalisation d’un projet et de la mener à terme :    Découpage et description du projet en :  processus,  phases,  étapes. 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. Répartition claire du rôle et des responsabilités des acteurs 5
  • 6. Caractéristiques d’un projet       Implique le changement. Possède un début et une fin. Requiert des activités. Implique des individus. Fait dans un but précis. Destiné à un ou plusieurs clients 6
  • 7. Caractéristiques d’un projet   Gérer un projet:  C'est gérer le changement 7
  • 8. Facile ?    « Il n ’y a rien de plus risqué, de plus difficile à planifier et de plus dangereux à gérer que l’implantation d ’un nouveau système ! » Résistance acharnée de tous ceux qui auraient quelque chose à perdre par l ’implantation du nouveau système Soutien mitigé de tous ceux qui auraient quelque chose à gagner 8
  • 9. Les différents points de vue  Différents besoins et points de vue :     Le client, Les utilisateurs, L’équipe, Le chef de projet doit les comprendre et essayer de les satisfaire 9
  • 10. Les différents points de vue  Client :     Livraison rapide Peu coûteux Fonctions nécessaires Utilisateurs :     Beaucoup de fonctions Convivialité Fiabilité Performance 10
  • 11. Les différents points de vue  L’équipe :   Les responsables :  haute qualité  respect des délais  respect des budgets  aucune surprise Les développeurs :  travail motivant  analyse seulement  plan de carrière 11
  • 12. Les différents points de vue  L’équipe :  les opérateurs de maintenance :  facilité d’opération,  facilité de maintenance,  fiabilité,  documentation,  respect des standards. 12
  • 14. Les principaux apports de la gestion de projets      Suivi de projets plus efficace Prise en compte des risques au plus tôt Mise en évidence des bénéfices Gestion des points en suspens Gestion des demandes de changement 14
  • 15. Les enjeux de la gestion de projets  Le succès, l’échec d ’un projet repose sur :       La compréhension des processus de l’activité Une définition claire du périmètre Un contrôle permanent des résultats attendus et une vision globale du «comment le projet est réalisé» Une bonne anticipation et gestion des risques Une gestion rigoureuse des changements Une structure clairement définie : gestion, décision, communication 15
  • 16. Impacts       Les coûts Les délais La qualité L’image de l’Entreprise La compétitivité Les ressources humaines 16
  • 17. Les processus et les activités 17
  • 18. Les Processus Processus de lancement Processus d’évolution du système d’information Processus d’évolution du système informatique 1 Organisation 2 Opportunité Et Lancement Du projet 3 Élaboration D’une solution -Solution avec progiciel -Solution spécifique Intégration et Industrialisation Du système informatique 4 Mise en oeuvre 5 Conduite du changement 6 Management de l’équipe projet et Gestion de projet 7 Assurance et maîtrise de la Qualité 8 Urbanisme du Système d’Information 18
  • 19. Activités supports     Suivi de projet : ensemble des moyens et des actions qui permettent de mesurer ce qui a été fait et d’évaluer ce qui reste à faire Rédaction et suivi des contrats, relation avec les utilisateurs Estimation des charges, planification Organisation des équipes 19
  • 20. Activités supports  Gestion de la qualité :    Spécifications des caractéristiques de qualité Dispositions préventives Procédures de contrôle 20
  • 21. Activités supports  Gestion de la documentation :    Gestion de la configuration :   Conception et mise à jour des règles :  identification  structuration Production et diffusion. Identification et gestion des composants et des configurations :  constitution de versions sur la base des composants  bibliothécaire de projet Maîtrise des modifications 21
  • 22. Activités supports  Vérification :     Revue de fin de phase Tests d’intégration Inspection de code Validation :   Cycle de validation Recette définitive 22
  • 24. Différentes tailles de projets  Petits projets :     Quelques personnes Moins de 30 mois/homme Environnement familier Moyens projets :   5 à 10 personnes en pointe De 30 à 100 mois/homme 24
  • 25. Différentes tailles de projets  Grands projets :      Plus d'une dizaine de personnes en pointe, Plus d’un niveau hiérarchique, Accent mis sur la gestion de projet, De 100 à 1000 mois/hommes. Très gros projets :     Au moins 40 personnes en pointe, Plus de 1000 mois/hommes, Accent mis sur l’assurance qualité, Plus le projet est important, plus les exigences en matière de pilotage et de qualité seront fortes. 25
  • 26. Différents types de projet     Projet de gestion Projet système Développement d’un progiciel Projet de maintenance… 26
  • 27. Différents types de projet  Différences :     Corps de métier Répartition du temps par phase Répartition des activités Identique :   Problèmes humains Processus supports 27
  • 28. La maîtrise d’ouvrage       Donne son accord sur l’opportunité du projet, S'assure du financement du projet, Met en place les structures de pilotage, Définit les objectifs du projet et les besoins fonctionnels en regard de ces objectifs, Fixe le cadre des travaux confiés au maître d'œuvre, Effectue la recette définitive des prestations fournies par le maître d'œuvre 28
  • 29. La maîtrise d’ouvrage  Pilote la conduite du changement :     Organiser et suivre les actions de communication formation, et production de la documentation Et y participer le cas échéant Pilote les actions de sous-traitance NB : Certaines tâches peuvent être sous-traitées par la maîtrise d'ouvrage : aide à la rédaction de la définition des besoins et à la rédaction du cahier des charges; assistance à la réception du produit; pilotage des actions de conduite du changement, de communication et de formation 29
  • 30. La maîtrise d’œuvre  Responsable de la réalisation des travaux qui lui ont été confiés par la maîtrise d ’ouvrage 30
  • 31. La maîtrise d’œuvre       Constitue l’équipe projet et désigne le chef de projet, Assure la gestion de projet (ordonnancement, estimation, planification des tâches, gestion des risques et suivi du projet) Participe à la synthèse des besoins et réalise les travaux d'étude Réalise l'intégration du système (tests unitaires et d'intégration), Gère le contrôle qualité Rend compte à la maîtrise d'ouvrage de l'avancement du projet et lui soumet les éléments de choix relevant de sa compétence 31
  • 33. La méthode   Tout développement de projet nécessite une méthode Le suivi opérationnel des projets s’appuie sur la méthode 33
  • 34. La méthode  Elle recouvre deux aspects :   Une démarche de développement (cycle de vie et cycle de décision) :  phases  étapes  livrables Une technique de conception.  modélisation 34
  • 35. La méthode  Trois grandes approches de développement:    Une approche spécifique pour les développements sur mesure Une approche progiciel comprenant deux étapes successives:  évaluation, sélection et conception de l'intégration dans l'environnement fonctionnel et technique de l'entreprise  installation, adaptation, paramétrage, réalisation et mise en œuvre Le développement itératif pour satisfaire un besoin mal connu et/ou peu formalisé. Démarche cyclique de prototypage, validation et mise en œuvre 35
  • 36. Panorama des méthodes  Exemples:       Merise (Sema) Axial (IBM) RAD (James Martin) SDM/S (CEGELOG/AGS Management Systems Inc.) MCP (Warnier) Méthodes objets : UML 36
  • 37. Comparaison des phases selon les méthodes MERISE AXIAL SDM/S MCP Schéma Directeur Diagnostic Détermination des besoins Exp. Des besoins Étude préalable Schéma directeur Chois d’architecture système Étude d’opportunité Étude détaillée Conception Fnelle Spécif Externes Étude du S.I Étude technique Conception Technique Spécif Interne Élaboration du C.des charges Réalisation Étude de migration Programmation Étude du S.I Mise en oeuvre Plan de mise en oeuvre Tests Programmation et essais Évaluation économique Intégration Réception provisoire Conception détaillée Recette Lancement sous contrôle Réalisation et tests Généralisation Évaluation de l’application Mise en production Maintenance Évaluation du projet 37
  • 38. Les méthodes: quelques recommandations  Adopter une démarche et s’y tenir :      Choisir un cadre de référence (méthodes du marché et méthodes "maisons" Définir processus, activités, tâches, documentation,rôles et acteurs Avoir la volonté d’appliquer la démarche Pas de règle miracle :   Pragmatisme Bon sens 38
  • 40. Estimation des charges  Répond à un besoin de prévision de durée, du coût et de la répartition de l’effort à fournir (j/h) et permet de :     Faire une estimation de la rentabilité de l’investissement Évaluer une durée vraisemblable du projet Prévoir l’ordonnancement des étapes Prévoir les ressources (affectation des personnes) 40
  • 41. Estimation des charges  Besoins d’estimation à différents niveaux :     Projet : durée, budget, rentabilité Phase : ajuster le découpage, décision de soustraiter,prévoir les délais, les ressources Étape : planification, suivi du projet pour surveiller les écarts, affecter les ressources Tâche : planification fine pour suivre les équipes 41
  • 43. Familles de méthodes  Il existe plusieurs familles de méthodes d'estimation:      Modèles algorithmiques (coût fonction de variables) Jugement d'experts Analogie (référence à d'autres projets similaires) Estimation globale puis décomposition Décomposition (estimation individuelle détaillée puis agrégation) 43
  • 44. Estimations: Modèles algorithmiques  Principe   Avantages :      Objectif, Reproductible, Simple, Expérimental. Inconvénients :     Consiste à estimer à l'aide de fonctions mathématiques des variables jugées significatives. Entrées subjectives, Prise en compte des cas exceptionnels, Il existe de nombreux Modèles, lequel choisir ? 44
  • 45. Estimations: Jugement d’experts  Principe   Avantages :   Estimation par des experts :  Soit individuellement,  Soit en groupe avec une méthode de consensus. Prise en compte globale du contexte et des situations exceptionnelles. Inconvénients :   Estimation subjective en fonction des experts, Non reproductible. 45
  • 46. Estimations: Analogie  Principe :    Basé sur les résultats de projets comparables Mise en évidence des différences Évaluation des écarts 46
  • 47. Estimations: Analogie  Avantages :     Capitalisation sur l'expérience Bonne prise en compte du contexte Réutilisation possible de composants Inconvénients :   Degré de signification des projets passés Prise en compte des situations exceptionnelles 47
  • 48. Estimations: Globale  Principe :    Avantages :   Estimation globale partir des propriétés globales du processus et du produit Obtention d'une catégorie de projet parmi n à partir des propriétés globales (Matrice des familles de projet en charge et délai) On n'oublie pas les éléments communs Inconvénients :  Ne met pas en évidence les problèmes de détail 48
  • 49. Estimations: Décomposition  Principe de la décomposition analytique    Avantages :     Estimation individuelle de chacun des éléments analytiques (par activité et tâche) à partir de barèmes Agrégation et ajout des coûts communs Analyse plus approfondie Répartition des risques Permet l'itération Inconvénients :   Plus long, Ne regroupe pas les tâches similaires 49
  • 50. Estimations: Décomposition   La décomposition nécessite des barèmes Exemples de barèmes:     Compte-rendu d'interview et vérifications : 0,5 personne-jour par interview Interview: 0,5 personne-jour+déplacement Rédaction de rapport : 10 à 20 pages par personne - jour Codage et test unitaire d'un IHM simple : 0,5 personne-jour 50
  • 51. Quelques principes    Pas de modèle universel. Mais nécessité d'une démarche formalisée. Analyser en priorité :       Les particularités du projet L’identification des tâches Les contraintes Faire plusieurs estimations si nécessaire. Savoir justifier. Une bonne estimation repose sur la capitalisation. 51
  • 52. Outils de gestion de projets 52
  • 53. Outils de gestion de projets   Existence de nombreux logiciels de gestion de projet. Permettent de :       Planifier le projet, Créer des tâches, Affecter des ressources aux tâches, Indiquer le coût des ressources, Calculer le chemin critique, Faire des simulations (pour constater les impacts d'un retard par exemple). 53
  • 54. Outils de gestion de projets  Composants essentiels :   Réseau PERT :  se présente sous forme graphique et ressemble à un organigramme informatique horizontal montrant les liens entre les tâches  renseigne surtout sur le "chemin critique" Diagramme de GANTT :  orienté sur la gestion du temps  indique les dates de début et de fin des tâches  permet de planifier les tâches et réduire la date de fin du projet 54
  • 55. Outils de gestion de projets   Il existe de nombreux progiciels (plus de 80 dans le catalogue du CXP) Quelques exemples de produits:  MS Project, PMW, PSN 8, On Target, Artemis, Primavera, Plantrac TM, Harvard, Time Line, WINGS, Pertmaster, Etc... 55
  • 56. Quelques produits  MS PROJECT pour Windows (Microsoft)      Mise au point de planning, Présentations graphiques de PERT, GANTT et calendrier, Suivi des délais, gestion des coûts simple, Outil simple à manipuler, public non spécialiste de la gestion de projet. On Target (Symantec Corporation)     Gère jusque 1500 tâches par projet, Gère un nombre illimité de ressources par tâche, Possibilité d'établir des liens graphiques temps/ressources avec la souris, Utilisation facile 56
  • 57. Quelques produits  PSN 8 (Scitor Corporation)       Outil généraliste de planification de tâches et de gestion de ressources (individuelles ou en groupes) au sein d'un département Permet de réaliser des simulations en temps réel, des analyses et des synthèses Sait gérer plusieurs projets Gère 2000 activités par projet et 500 ressources par table, Produit des états de taille réglable PMW (ABT Corporation)   Outil orienté gestion des ressources S'adresse à un public connaissant bien la gestion de projet 57
  • 59. Constats généraux       De nombreux projets «avortent». Retard dans la livraison. Dépassement de budget. Problèmes d’exploitation et de maintenance. Résistance aux changements. Manque de compétences des gestionnaires. 59
  • 60. Lois, règles et légendes     L'effort nécessaire à fournir pour atteindre les objectifs prévus croît géométriquement avec le temps Les projets progressent rapidement jusqu’à ce qu’ils soient terminés à 90% puis, restent à 90% Lorsque les choses vont bien, quelque chose ne va pas Lorsque les choses ne peuvent pas être pires, elles le deviendront encore davantage 60
  • 61. Lois, règles et légendes     Si on tolère le changement, le rythme de changement dépassera le rythme de développement En moyenne, les grands projets finissent un an en retard, coûtent deux fois plus que l’évaluation initiale Un projet mal planifié prendra trois fois plus de temps à réaliser que prévu alors qu'un projet bien planifié ne prendra que deux fois plus de temps Aucun grand projet informatique n'est achevé dans les délais, dans les limites budgétaires prévues à l'origine et avec les mêmes responsables qu'à son initialisation 61
  • 62. Constats généraux: quelques statistiques   Dans la mesure où les dérives sur les projets de grande taille sont très fréquentes, il convient de ne pas sous-estimer les coûts, qui peuvent se révéler à terme beaucoup plus élevés A titre d'information, quelques statistiques sur la tenue des délais dans des moyens (30 à 100 mois/hommes) et grands projets (100 à 1000 mois/hommes) (source Carper-Jones) :      Projets annulés : 13% Projets en retard de plus de 12 mois : 12% Projets en retard de plus de 6 mois : 35% Projets approximativement à l'heure : 37% Projets terminés plus tôt que prévu : 3% 62
  • 64. Déroulement d’une mission d’audit  5 phases :      Lancement du projet et compréhension du contexte Recueil de l’existant Analyse de l'existant Recommandations Présentation finale 64
  • 65. Déroulement d’une mission d’audit  Phase de lancement :  Précision du champ de la mission et définition des objectifs associés :  éléments à l ’origine de la mission justifiant son opportunité, ses objectifs et les enjeux correspondants  définition du champ de l ’étude et éventuellement des ambiguïtés subsistant sur le champ de la mission  identification des différents services concernés  évolutions prévisibles à prendre en compte 65
  • 66. Déroulement d’une mission d’audit  Phase de lancement :  Organisation de la mission et planning :  identification nominative des intervenants et disponibilité requise  planning prévisionnel  première convocation pour les entretiens 66
  • 67. Déroulement d’une mission d’audit  Recueil de l’existant :     Description des structures existantes, Description des ressources logicielles et matérielles, Mise en évidence : objectifs,  problèmes  besoins  facteurs clés de succès. 67
  • 68. Déroulement d’une mission d’audit  Analyse de l’existant :  Analyse critique de l’existant sur les aspects  Organisationnels  Fonctionnels  Techniques  Financiers 68
  • 69. Déroulement d’une mission d’audit  Recommandations :   C’est à partir de l’analyse de l’existant que sont proposées des solutions ou des préconisations visant à optimiser : le fonctionnement, les dépenses, la réponse aux besoins utilisateurs Préconisations en terme de :  sécurité  architecture informatique  outils de développement  conduite de projet  méthodologie  organisation  relation maîtrise d’ouvrage / maîtrise d'œuvre 69
  • 70. Déroulement d’une mission d’audit  Présentation finale :   Présentation aux commanditaires de la mission, Synthèse avec :  rappel du contexte  indication des modalités de déroulement  exposé rapide de l’existant  mise en évidence des points forts  mise en évidence des points faibles  dysfonctionnements  recommandations classées par priorité organisation, conduite du projet, ressources… 70
  • 71. Quelques points de repères  Difficultés les plus courantes constatées dans la relation MOA/MOE:         Manque de confiance mutuelle Manque de transparence dans la stratégie et l’action Manque d’objectivité dans l’appréciation des problèmes Difficultés à prendre des décisions claires Lourdeur des structures de pilotage Résistance naturelle aux changements La MOE tend souvent à se substituer à la MOA sur des sujets qui relèvent de la responsabilité de la MOA et réciproquement Validations difficiles 71
  • 72. Quelques points de repères  Difficultés ressenties par la MOA :    Difficultés à fixer des orientations politiques tranchées Manque de visibilité sur les travaux en cours Mauvaise compréhension et appréciation des évaluations de charges et délais élevés fournies par la MOE 72
  • 73. Quelques points de repères  Difficultés perçues par la MOE :     Manque de disponibilité de la MOA Besoins insuffisamment précis et stables Manque d’engagement de la MOA Difficulté à évaluer les charges et les délais et à les expliquer à la MOA 73
  • 75. Audit de projet  L'audit de projet est présenté en trois volets :     Une sensibilisation aux risques spécifiques de chaque type de grand projet de système d'information Réf.: Guide d'Audit, "Audit des grands projets de systèmes d'information : Évaluation des risques", IFACI) Une analyse générique des risques liés à la conduite de projet Une analyse des risques spécifiques à chaque phase du cycle de vie du projet 75
  • 76. Les risques spécifiques de chaque type de grand projet de S.I 76
  • 77. Typologie de projets        Projet à niveau élevé d'engagements budgétaires Projet stratégique au niveau de l'entreprise Projet transverse Projet aux enjeux organisationnels forts (de type "change management") Projet à base de technologies novatrices (exemples: technologie objet, Internet, EDI,…) Système de gestion spécifique complexe ou peu répandu Entreprise Ressource Planning (ERP) - Progiciel de Gestion Intégré (PGI) 77
  • 78. Typologie de projets      Outsourcing de l'informatique ou des systèmes d'information (total ou partiel) Fusion et regroupement d'entreprises ou d'activités (entre plusieurs sociétés), acquisition, filialisation Projet international d'unification de systèmes informatiques ou de systèmes d'information nationaux (exemple: un groupe avec ses filiales) Fusion/regroupement de systèmes d'information ou de centres informatiques Projet à délai imposé 78
  • 79. Audit de projet  Projet à niveau élevé d'engagements budgétaires  Motivations et raisons du choix de ce type de projet  Remplacement d'une application lourde nécessitant des équipes de conception-développement volumineuses  Déploiement d'équipements à grande échelle 79
  • 80. Audit de projet  Projet à niveau élevé d'engagements budgétaires  Risques généraux  Dépassement budgétaire  Présentation de coûts sous -estimés ou incomplets  Recherche d'économies au détriment de la qualité  Phases aval du projet réalisées rapidement, pour rattraper les dérives constatées sur les phases amont  Méthodes de travail ne permettant pas de garder la maîtrise du déroulement du projet  Arrêt du projet et dispersion de toutes les équipes après le déploiement  Contractualisation avec les prestataires externes présentant des points faibles ou des lacunes 80
  • 81. Audit de projet  Projet stratégique au niveau de l'entreprise   Motivations et raisons du choix de ce type de projet  Lancement d'un nouveau produit, d'une nouvelle prestation ou d'un nouveau métier  Mise en conformité avec une nouvelle réglementation Risques généraux  Manque d'implication des commanditaires / Commanditaires trop directifs  Déclinaison incorrecte des éléments du plan stratégique  Essoufflement du projet avant son total déploiement  Dépassement de délai La bonne fin d'un tel projet repose en grande partie sur l'Étude d'opportunité 81
  • 82. Audit de projet  Projet transverse   Motivations et raisons du choix de ce type de projet  Passage d'une gestion verticale à une approche par processus Risques généraux  Absence de vision transverse  Pilotage fort d'une fonction, au détriment des fonctions connexes  Non prise en compte de la culture d'entreprise 82
  • 83. Audit de projet  Projet aux enjeux organisationnels forts (de type "change management")   Motivations et raisons du choix de ce type de projet  Bouleversement des conditions d'exercice du métier  Repositionnement de l'entreprise sur son marché Risques généraux  Manque d'implication de la Direction Générale jusqu'à la bonne fin du projet de changement  Mauvaise intégration du volet social  Manque d'homogénéité entre le projet SI et les choix organisationnels  Dépassement de délai 83
  • 84. Audit de projet  Projet à base de technologies novatrices (Technologie objet, Internet, EDI,…)   Motivations et raisons du choix de ce type de projet  Recherche d'un avantage concurrentiel  Vitrine technologique  Remplacement d'une technologie obsolète et mise en place d'un socle technique évolutif et pérenne Risques généraux  Attrait de l'innovation pour elle-même  Dépendance vis -à-vis des fournisseurs  Mauvaise intégration dans le système d'information et manque de coordination avec les projets des partenaires  Oubli des coûts 84
  • 85. Audit de projet  Système de gestion spécifique complexe ou peu répandu   Motivations du choix de la DG  Compte tenu du caractère spécifique, la seule solution possible est faire des développements Risques associés  Spécifications fonctionnelles pointues et particulières  Perturbation des systèmes amont et aval et propagation des dysfonctionnements  La solution d'informatisation n'est pas nécessairement la solution du problème  Dépassement de coûts : manque d'expérience par rapport à des domaines plus standard 85
  • 86. Audit de projet  Enterprise Ressource Planning (ERP) - Progiciel de Gestion Intégré (PGI)  Motivations du choix de la DG  Les concurrents ont pris un ERP (effet de mode)  Aller vite et avoir une couverture plus large des besoins fonctionnels  Disposer d'une technologie plus avancée  Suppression des interfaces applicatives  Solution plus souple et moins chère qu'un développement maison  Diffusion d'un modèle d'organisation unique pour l'ensemble des filiales  Meilleure intégration et structuration des informations (une base de données unique pour l'entreprise)  Mise à disposition plus rapide et plus complète des informations stratégiques (besoins de niveau DG) 86
  • 87. Audit de projet  Enterprise Ressource Planning (ERP) - Progiciel de Gestion Intégré (PGI)  Risques généraux  Résistance au changement  Forte intégration du système  Complexité du paramétrage  Diversité de l'environnement technique  Risques liés à la migration et les interfaces  Des enjeux importants liés aux coûts et aux délais  Inadéquation fonctionnelle ou couverture fonctionnelle incomplète, ce qui va obliger à plus de développements spécifiques  Surdimensionnement fonctionnel, sous -utilisation des fonctions du produit 87
  • 88. Audit de projet  Enterprise Ressource Planning (ERP) - Progiciel de Gestion Intégré (PGI)  Risques généraux (suite)  Sous -estimation des coûts et des délais de mise en œuvre  Sous -estimation des impacts organisationnels  Perte de maîtrise de l'évolution de l'organisation et des processus métier  Diminution de l'avantage concurrentiel (alignement).  Sécurité logique insuffisante 88
  • 89. Audit de projet  Outsourcing de l'informatique ou des systèmes d'information (total ou partiel)  Motivations et raisons du choix de ce type de projet:  Se recentrer sur son métier de base, l'informatique étant une activité de support  Réduire la taille et le coût des services centraux  Améliorer la qualité du service rendu aux utilisateurs  Faciliter les changements de structure de l'entreprise 89
  • 90. Audit de projet  Outsourcing de l'informatique ou des systèmes d'information (total ou partiel)  Risques généraux  Perte de confidentialité  Dégradation de la qualité de service  Inflation des coûts  Mauvaise gestion des changements  Démotivation du personnel 90
  • 91. Audit de projet  Fusion et regroupement d'entreprises ou d'activités (entre plusieurs sociétés), acquisition, filialisation   Motivations et raisons du choix de ce type de projet  Une réduction des frais fixes  Un développement du business  Une synergie commerciale et une amélioration des parts de marché Risques généraux  Absence de questionnement sur le fait de garder ou non des S.I. différents (Convergence en matière de S.I. et architecture technique)  Réduction des avantages escomptés de l'opération  Perturbation de fonctionnement  Dérapage des coûts, des délais et de la qualité 91
  • 92. Audit de projet  Projet international d'unification de systèmes informatiques ou de systèmes d'information nationaux (exemple: un groupe avec ses filiales)  Motivations et raisons du choix de ce type de projet  Centralisation du pilotage  Économies de coûts  Rationalisation et unification des pratiques de gestion  Conséquences attendues : installation du même « core system » partout  Gains escomptés : mise en cohérence des informations de gestion et rapidité de consolidation, vision exacte des filiales 92
  • 93. Audit de projet  Projet international d'unification de systèmes informatiques ou de systèmes d'information nationaux (exemple: un groupe avec ses filiales)  Risques généraux  Erreur d'appréciation au départ : base réputée identique partout  Réalité différente : analyse trop schématique, sous -estimation des particularismes locaux  Découverte des problèmes après -coup, ce qui oblige à des compléments d'étude et entraîne des dépassements de coûts  Non atteinte des performances attendues 93
  • 94. Audit de projet  Fusion/regroupement de systèmes d'information ou de centres informatiques   Motivations et raisons du choix de ce type de projet  Rationalisation du fonctionnement, économies de coûts. Risques généraux  Dérapage des délais, d'où dérapage des coûts.  Impacts sur les clients, sur le personnel (pertes de compétence : les meilleurs partent, démotivation du personnel : perte.  Non atteinte de la cible.  Arrêt du projet. 94
  • 95. Audit de projet  Fusion/regroupement de systèmes d'information ou de centres informatiques (suite)  1er cas : Risques déclinés en fonction du cas de regroupement  Le regroupement de centres informatiques peut se faire dans deux configurations possibles côté constructeur : – même constructeur: il faut vérifier les économies et le fonctionnement – constructeurs différents: la décision étant politique, un audit n'est pas nécessaire  Les risques portent principalement sur: – la migration des données – l'architecture du réseau – l'organisation de l'exploitation et du support – le projet RH 95
  • 96. Audit de projet  Fusion/regroupement de systèmes d'information ou de centres informatiques (suite)  2ème cas : Risques en cas de fusion et de regroupement de SI:  L'existence d'une étude de benchmarking et de son application  La décision du choix du SI ou des applicatifs à retenir, la migration des données, le projet RH, la formation des utilisateurs, l'organisation des processus  L'existence d'un document de choix et d'un relevé de décisions, d'un plan de migration  La satisfaction des besoins de la maîtrise d'ouvrage, la manière dont est organisé leur suivi 96
  • 97. Audit de projet  Projet à délai imposé   Motivations de ce type de projet  En général, projets résultant de contraintes réglementaires, fiscales, etc  Maintien du bon fonctionnement de l'entreprise tout en intégrant les contraintes Risques généraux : ils portent sur l'identification incomplète des domaines à couvrir, des problèmes à traiter; ou bien sur la non tenue du planning (préparation et réalisation). Il en découle :  Réparation à chaud sans ordre, ce qui engendre des risques aggravés et des coûts plus importants, une perte de clients, et des pertes d'exploitation  Absence de plan de secours avec arrêt potentiel de l'activité,  Tests incomplets du plan de secours 97
  • 98. Audit de projet  Projet à délai imposé (suite)  Risques relatifs à l'organisation du projet  Affectation de ressources trop importantes sur le reporting par rapport aux forces vives nécessaires en traitement des problèmes,  Le reporting est en décalage avec la réalité du terrain (il nécessite d'être validé et affiné par des audits qualité),  Le schéma global de résolution de problèmes n'est pas réaliste,  La démarche n'est pas à l'état de l'art (cf. ISACA,…), n'est pas structurée ni exhaustive, n'est pas formalisée ni communiquée,  Toutes les compétences ne sont pas réunies ; l'appel à l'expertise externe nécessaire n'a pas été effectué,  Les solutions ne sont pas mutualisées (cf. Forum des compétences du secteur financier). 98
  • 99. Risques liés à la conduite de projet 99
  • 100. Les cinq questions clés      Existe-t-il un consensus sur les objectifs du projet ? Processus de décision/validation et suivi d'application de ces décisions ? Qui fait quoi dans le projet ? Tous les acteurs disposent-ils des informations nécessaires pour agir dans le sens du projet ? Quel est le niveau d'avancement du projet ? 100
  • 101. Audit de projet  Les risques liés à la conduite de projet sont abordés selon les thèmes suivants 1) Objectifs du projet 2) Structure de projet 3) Instances de pilotage et de suivi 4) Méthode et outils 5) Planification 6) Contrôle du projet 7) Qualité 101
  • 102. 1) Objectifs du projet  Concernant l'intégration du projet dans l'entreprise, s'assurer des points suivants :    Existence d'une définition claire du projet, de son périmètre, Existence d'un projet en accord avec la stratégie de l'entreprise et sa culture, Existence d'un plan de communication 102
  • 103. Objectifs du projet  Les objectifs et les besoins      Les objectifs du projet sont-ils définis et connus des MOA et MOE ? Les besoins sont-ils clairement définis ? Le périmètre est-il défini et stabilisé ? Les interactions et leurs impacts avec d'autres projets ontils été identifiés ? Les risques  A t-on identifié et formalisé les risques potentiels ? 103
  • 104. 2) Structure de projet  Vérifier l'existence d'une structure de projet : assurer l'organisation du projet    Vérifier l'existence d'un chef de projet (MOE et MOA) S'assurer de la constitution d'une équipe de projet Remarque : la structure d'un projet n'est pas nécessairement figée. Selon la nature et l'importance du projet, elle peut évoluer dans le temps 104
  • 105. Structure de projet  Vérifier la participation de tous les acteurs au projet :     Propriétaire du projet clairement identifié Maîtrise d'ouvrage :  Liste des intervenants  Rôle et responsabilités Maîtrise d'œuvre :  Liste des intervenants  Rôle et responsabilités S'assurer que les rôles et les responsabilités de la maîtrise d'ouvrage et de la maîtrise d'œuvre sont formellement identifiés 105
  • 106. Structure de projet  Les moyens :   Moyens humains :  Organiser en fonction des besoins  Équilibre entre l'expérience et le potentiel Moyens techniques :  Environnement de développement efficace  Outils de développement  Aménagement de l'environnement physique 106
  • 107. Structure de projet  Direction de projet       Évaluer les compétences de la direction de projet, Vérifier la motivation des équipes, Sonder la maîtrise d'ouvrage :  besoins,  craintes,  communication, Le but est d ’obtenir le meilleur rendement possible des équipes en place. Les principaux atouts appartiennent au domaine des relations humaines motivation esprit d ’équipe leadership, délégation... : Évaluer la résistance au changement. 107
  • 108. Structure de projet  Existence d'un groupe projet :     Membres permanents Rôles et responsabilités Réunions périodiques Vérifier l'échange d'informations entre la direction de projet et le groupe projet 108
  • 109. Structure de projet  Les acteurs :   Identification claire des fournisseurs :  Rôle et responsabilités  Résultats attendus  Délai Acteurs externes :  Obligations légales (ex: fiscal, CNIL…)  Résultats à fournir  Délai 109
  • 110. 3) Instances de pilotage et de suivi  Le mode de pilotage, les processus de décision/validation      La structure de pilotage est-elle définie ?  La structure de pilotage est -elle adaptée ?  La structure de pilotage est -elle formalisée et connue de tous les acteurs ?  Les différentes instances de pilotage connaissent -elles leurs "niveaux de délégation" ?  Les objectifs de délégations sont -ils atteints ? Vérifier l'existence d'un comité de pilotage Vérifier l'existence d'un comité de projet Vérifier l'existence d'un comité des utilisateurs. Étudier la pertinence des participants présents au comité de projet et au comité de pilotage. 110
  • 111. Instance de pilotage et de suivi  Les attributions respectives des instances de projet sont les suivantes :     Comité de pilotage :  Instance de décision et de pilotage stratégique du projet (lancement, développement de la solution, conduite du changement et mise en œuvre, management du projet) Comité de projet : 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 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 111
  • 112. Instance de pilotage et de suivi  Le mode de pilotage, les processus de décision/validation  Les comités de pilotage et de projet sont-ils adaptés et efficaces ?  Les participants aux différents comités sont-ils représentatifs , ont-ils le bon niveau de décision ?  Les utilisateurs sont-ils représentés dans les comités de pilotage ?  Les gestionnaires et la production ont-ils été intégrés dans les structures de pilotage ?  Les participants ne sont-ils pas trop nombreux ?  La fréquence des comités est-elle correcte ?  Qui prépare, anime, fait le compte-rendu des comités de pilotage ? Et dans quel délai ?  Existe-t-il une revue de projet ? (réunion MOA-MOE périodique pour suivre l'avancement du projet) 112
  • 113. Instance de pilotage et de suivi  Le reporting    Les indicateurs de suivi sont-ils définis ?  Les indicateurs de suivi sont-ils adaptés en fonction de l'étape ?  Les indicateurs de suivi sont-ils mis à jour ?  Les indicateurs de suivi sont-ils pertinents par rapport aux objectifs du projet (contraintes de délais, de qualité, de coût, …) Existe-t-il un formalisme de reporting ?  Le reporting se fait-il sous forme de tableau de bord ?  Le reporting est-il conjoint et unique MOA-MOE ? Quelle est la fréquence du reporting ? est-t-elle adaptée au suivi? 113
  • 114. Instance de pilotage et de suivi  La gestion des changements (évolutions de périmètre)   Les demandes d'évolutions de périmètre sont-elles formalisées?  Les évolutions de périmètre sont-elles fréquentes ? Si oui, combien y en a-t-il eu ? La gestion des évolutions de périmètre est-elle bien maîtrisée ?  Existe-t-il une procédure de gestion des évolutions de périmètre ?  Les décisions sont-elles prises ?  Les mesures d'impact sont-elles faites ?  Y a t-il une gestion des versions ? 114
  • 115. Instance de pilotage et de suivi  Les décisions   Les décisions sont-elles prises ? Avec un délai satisfaisant? Sur la base d'un niveau d'information pertinent ? Les points de décision sont-ils respectés (exemple: réunion et note de lancement, décision d'opportunité) ? 115
  • 116. 4) Méthodes et outils  S’assurer de l'existence d'une méthode :    Vérifier qu'elle est bien appliquée Identifier les points pouvant être bloquants tels que :  Outils associés à la méthode  Formation à la méthode et aux outils  Cas de dérogation d'utilisation Vérifier la mise en œuvre d'outils 116
  • 117. 5) Planification  Vérification d'un point de vue général :   Existe-t-il un planning directeur commun à tout le projet ? La planification s'effectue du général au particulier et l'on procède par itération :  Existence d'un plan de projet initial  Ce plan de projet a-t-il été révisé et pourquoi ?  Existence de plans détaillés initiaux  Révision des plans détaillés ?  Gestion des ressources 117
  • 118. Planification  Définition des produits à développer :   Notions de projet, sous-projet, lots Identifications des phases et étapes :  Contraintes  Dates limites 118
  • 119. Planification  Estimation des charges :   Utilisation d'une méthode d'estimation :  Vérifier son application  Vérifier la cohérence d'ensemble Mise en adéquation des moyens :  Humains  Techniques 119
  • 120. Planification  Avancement du projet (points en suspens)   Le planning général du projet est-il représentatif de la réalité?  Les acteurs se sont-ils engagés à respecter le planning général du projet ?  Les lots sont-ils bien identifiés et suivis dans le planning ?  Le chemin critique est-il identifié ? La mesure de l'avancement du projet est-elle réalisée ?  La notion de reste à faire est-elle comprise par tous les acteurs ?  La réestimation périodique et en commun des reste-à-faire est-elle faite ?  Existe-t-il des "capteurs" d'alertes ?  Existe-t-il des procédures pour traiter les alertes « urgentes » ? 120
  • 121. Planification  Évaluer la prise en compte des risques :  Par rapport :  à la technologie utilisée  aux projets en cours  aux délais  à la synchronisation des activités 121
  • 122. 6) Contrôle du projet   Le contrôle du projet est directement lié à la planification Il permet de vérifier :    Avancement des travaux Contrôle des livrables Contrôle de la qualité 122
  • 123. Contrôle du projet  Vérifications nécessaires :          A-t-on mis l'accent sur les écarts et la recherche de solutions ? A-t-on pris en compte des demandes de changement après évaluation? Les demandes d'évolutions de périmètre sont-elles formalisées ? Les évolutions de périmètre sont-elles fréquentes ? Si oui, combien y en a-t-il eu ? La gestion des évolutions de périmètre est-elle maîtrisée ? Existe-t-il une procédure de gestion des évolutions de périmètre ? Les décisions sont-elles prises ? Les mesures d'impacts sont-elles faites ? Y-a-il une gestion des versions ? A-t-on pris en compte les points en suspens ? 123
  • 124. Contrôle du projet   Point essentiel: le suivi périodique de l’état d’avancement du projet Le reporting  Les indicateurs de suivi sont-ils définis ?  Les indicateurs de suivi sont-ils mis à jour ?  Les indicateurs de suivi sont-ils pertinents par rapport aux objectifs du projet (contrainte de délais, contrainte de qualité, contrainte de coût,…) ?  Existe-t-il un formalisme de reporting ?  Le reporting se fait-il sous forme de tableau de bord ?  Le reporting est-il conjoint et unique MOE-MOA ? 124
  • 125. Contrôle du projet  Point essentiel : Le suivi périodique de l'état d'avancement du projet  Efficacité du processus de décision/validation effectué par les instances de pilotage 125
  • 126. Contrôle du projet  Vérifications nécessaires :      Application du MAQ et PAQ s'ils existent (cf. partie Qualité) Existence des revues (techniques, livrables) Circuit d'approbation des livrables Graduation des livraisons Documentation produite 126
  • 127. 7) Qualité  Quelques définitions (AFNOR)    L ’assurance qualité est la mise en œuvre d ’un ensemble approprié de dispositions préétablies et systématiques destinées à donner confiance en l ’obtention de la qualité requise. La qualité est ce que le client souhaite explicitement ou implicitement La qualité du logiciel est son aptitude à satisfaire les besoins des utilisateurs 127
  • 128. Qualité   Les objectifs qualité ont-ils été formalisés ? Existe-t-il des moyens pour s'assurer de la qualité ?   Existence d'un manuel d'assurance qualité de l'entreprise Existence d'un plan d'assurance qualité du projet 128
  • 129. Le manuel d’Assurance Qualité   Dispositions générales prises par l ’Entreprise pour obtenir la qualité de ses produits et services. Contient :     Les règles de gestion de la qualité Les règles et procédures de gestion de l’Entreprise Les plans types de documentation L’organisation associée 129
  • 130. Le plan d’Assurance Qualité     Établi à partir du MAQ Décrit les procédures, les règles, les méthodes applicables au projet Fixe aux différents acteurs du projet leurs droits mais aussi leurs devoirs en matière de qualité L’élaboration du PAQ est du ressort du Responsable Assurance Qualité du projet 130
  • 131. Exemple de PAQ  Introduction :    Glossaire et abréviations. Organisation :   Contexte, périmètre, procédures associées au PAQ. Rôle des intervenants et des structures de pilotage. Plan de développement :  Démarche, activités, livrables… 131
  • 132. Exemple de PAQ  Documentation :   Procédures diverses :     Identification, contenu, validation Gestion des fournisseurs, gestion des configurations, gestion des modifications Gestion des points en suspens, gestion des risques, gestion de la recette Reproduction, protection, livraison Suivi de l’application du Plan d’Assurance Qualité 132
  • 133. Qualité  A t-on formalisé les objectifs de qualité du produit (Plan Qualité Projet)?   Les utilisateurs ont -ils été impliqués dans la définition du niveau de qualité du produit ? A-t-on formalisé les objectifs de qualité de service attendue ?  Les utilisateurs ont -ils été impliqués dans la définition du niveau de qualité attendue ? 133
  • 134. La revue des points clés de chaque phase 134
  • 135. Les grandes phases de conduite de projet       Étude d'opportunité/Lancement Conception générale/Analyse Conception détaillée Développement/Réalisation ou Paramétrage (progiciel) Qualification : Tests/Recettes Mise en œuvre/Conduite du changement 135
  • 136. Étude d’opportunité/Lancement   Vérifier l'existence d'une expression détaillée et formalisée des besoins dans un cahier des charges fait par la MOA  Document contractuel : justification du projet S'assurer que l'étude d'opportunité comprend :       Les objectifs du projet L'analyse des déficiences des systèmes existants Les enjeux du projet Les bénéfices attendus Les contraintes relatives au projet Les acteurs concernés 136
  • 137. Étude d’opportunité/Lancement  S'assurer de l'intégration du projet au schéma directeur ou plan directeur     Cohérence du projet dans le plan directeur informatique, Cohérence du projet dans le système d'information actuel ou futur, S'assurer de la participation de la direction du département utilisateur concerné dans la phase d'initialisation. S'assurer de la participation au projet des acteurs concernés : pertinence de l'équipe de projet    Identifier les acteurs de l'équipe de projet et leurs responsabilités, Évaluer l'adéquation entre les qualifications des personnes impliquées et leurs tâches, Vérifier la participation des principaux utilisateurs à l'équipe de projet. 137
  • 138. Étude d’opportunité/Lancement  Vérifier la formalisation de l'approbation du projet :  Validation de l'étude d'opportunité.    S'assurer que l'étude d'opportunité a été revue par les directions des départements utilisateurs concernés et par la direction informatique Vérifier que l'approbation a été formalisée par écrit Vérifier la qualité de la personne qui a autorisé la poursuite du projet 138
  • 139. Conception générale/Analyse  S'assurer de l'existence d'une analyse comparative des scénarios possibles : contrôle de la pertinence de la solution de développement retenue.   Vérifier l'exhaustivité des scénarios proposés, y compris celui de ne rien faire. Vérifier la qualité de l'analyse technologique de chaque alternative.  Besoins/disponibilités de matériels et de logiciels  Besoins en formation  Besoins/disponibilités de ressources humaines  Faisabilité opérationnelle  Implication du responsable technique  Contraintes juridiques/réglementaires 139
  • 140. Conception générale/Analyse  S'assurer de l'existence d'une analyse comparative des scénarios possibles : contrôle de la pertinence de la solution de développement retenue  Vérifier la qualité de l'analyse économique de chaque alternative  Coûts de développement  Coûts de formation  Coûts de maintenance/exploitation  Coûts de conversion/migration/paramétrage  Coûts annexes  Bénéfices attendus  Coûts de fonctionnement  Implication du responsable utilisateur 140
  • 141. Conception générale/Analyse  S'assurer de l'existence d'une analyse comparative des scénarios possibles : contrôle de la pertinence de la solution de développement retenue   Vérifier l'existence d'une analyse des risques pour chaque alternative  Valeur et sensibilité des informations traitées  Vulnérabilités  Besoins correspondant en matière de contrôles internes  Implication du responsable sécurité S'assurer de l'existence de critères d'évaluation pour réaliser l'analyse comparative en toute objectivité 141
  • 142. Conception générale/Analyse  Vérifier la prise en compte des aspects de contrôle interne et de sécurité dans l'élaboration du cahier des charges afin d'assurer la sécurité du futur développement     S'assurer que la conception générale du futur système s'inscrit dans les objectifs généraux de contrôle en vigueur dans l'environnement. S'assurer que les contrôles d'exploitation ont été identifiés. S'assurer de la prise en considération des besoins spécifiques en matière de contrôles. S'assurer de l'identification et de la description des besoins en matière de contrôles programmés. 142
  • 143. Conception générale/Analyse  Vérifier la formalisation de la poursuite du projet : validation de la conception générale et choix de la solution de développement     S'assurer que les études de faisabilité proposées ont été revues par les membres du Comité du Projet S'assurer de la présentation des différentes solutions possibles au Comité de Pilotage Vérifier la qualité de la personne qui a autorisé la poursuite du projet Vérifier l'existence d'une approbation écrite 143
  • 144. Conception détaillée  S'assurer de l'utilisation d'une méthode d'analyse et de conception: qualité de la phase de conception.     Vérifier l'existence d'une méthode d'analyse/de conception S'assurer que cette méthode est correctement utilisée Evaluer la maîtrise de cette méthode Vérifier la conformité des spécifications détaillées au cahier des charges : correcte interprétation des besoins exprimés.   Vérifier l'exhaustivité des spécifications détaillées par rapport à la conception générale Evaluer la définition et la documentation des spécifications . 144
  • 145. Conception détaillée  Vérifier la qualité des contrôles programmés    Vérifier l'existence de contrôles adaptés à chaque point critique du système  Contrôles préventifs  Vérifier l'existence et la pertinence des contrôles correctifs S'assurer de l'implication du responsable de la sécurité Vérifier l'existence de pistes d'audit permettant de suivre la totalité des transactions de leur point d'origine jusqu'aux totalisations de contrôle correspondantes et vice-versa 145
  • 146. Conception détaillée   S'assurer de l'implication suffisante des acteurs concernés (utilisateurs, administrateurs de données, responsable sécurité,…) Vérifier la formalisation de la validation de la conception détaillée     S'assurer que la conception détaillée préparée a été revue par les membres du Comité de Projet S'assurer que le document a été présenté au Comité de Projet Vérifier la qualité de la personne qui a autorisé la poursuite du Projet Vérifier l'existence d'une approbation écrite 146
  • 147. Recommandations en matière de spécification  Pour assurer que la réalisation du logiciel correspond aux besoins, au minimum, les documents suivants doivent exister:  Spécifications externes (ou spécifications fonctionnelles)  Ce document décrit, précisément et clairement, toutes les caractéristiques du logiciel à réaliser (fonctions, contraintes, règles de calcul) ainsi que toutes les interfaces externes. Une fois approuvé par le utilisateurs, il constitue le document de référence. Toutes les caractéristiques seront décrites de façon à ce qu'il soit possible d'en vérifier objectivement la réalisation  Spécifications internes (ou spécifications organiques globales)  Ce document décrit tous les éléments d'architecture du système, c'est-à-dire, les sous -ensembles à réaliser en précisant leurs fonctions, et tous les éléments communs (modules de service, fichiers, tables, bases de données, interfaces,…) 147
  • 148. Développement/Réalisation  S'assurer de l'utilisation d'une méthode de développement (pérennité et fiabilité des traitements)     Vérifier l'existence d'une méthode de développement S'assurer que cette méthode est correctement utilisée Évaluer la maîtrise de cette méthode par les développeurs Vérifier le respect des normes de documentation et de vérification     Étudier la pertinence des normes en vigueur Vérifier l'application de ces normes par les développeurs Apprécier la qualité de la documentation S'assurer de la revue par le responsable du services études de la documentation constituée 148
  • 149. Développement/Réalisation   Vérifier la formalisation d'un programme général de tests Vérifier l'existence d'un plan de mise en place.    Vérifier l'existence et la pertinence du plan de mise en place Vérifier l'approbation et la diffusion du plan de mise en place S'assurer que le plan de mise en place définit au minimum :  La nature des travaux à réaliser et leur ordonnancement  Les charges de travail correspondantes et la durée des travaux  Les acteurs concernés  Leurs rôles et responsabilités 149
  • 150. Développement/Réalisation  Vérifier l'existence de procédures de contrôle et de sécurité lors de la migration : assurer la réussite du projet de conversion       Vérifier l'existence et la pertinence du plan du plan de migration S'assurer du respect des normes de développement et de vérification du programme de conversion S'assurer du respect des procédures de contrôles en matière de passage en production Vérifier l'existence d'une image des systèmes et des données avant et après conversion Vérifier l'implication du responsable assurance qualité dans le processus de conversion S'assurer de la formalisation de l'examen et de l'approbation des résultats du processus de conversion par les directions concernées 150
  • 151. Développement/Réalisation  Objectif : Personnaliser le progiciel pour répondre aux besoins exprimés par les utilisateurs   Définir et enregistrer les paramètres de configuration pour adapter le progiciel au contexte organisationnel et technique cible Faire réaliser les adaptations spécifiques nécessaires pour satisfaire les besoins non couverts 151
  • 152. Paramétrage (Solution Progiciel)  Vérifier l'existence du dossier de spécification du paramétrage    Le dossier doit consigner les options retenues sur le produit (approche itérative en partant des options les plus structurantes) La démarche constitué par l'éditeur peut constituer le fil conducteur pour le travail de paramétrage Vérifier qu'un prototype représentatif a été réalisé (implication des utilisateurs) 152
  • 153. Qualification: tests/Recettes  Les tests représentent le vecteur principal de l’amélioration de la qualité de l’application  Cependant, tester reste une des activités les moins populaires chez les développeurs d’applications. En effet, contrairement à la conception ou à la production de code, le test ne génère que des fiches d’anomalies  De plus, étant réalisés en fin de processus de développement, les tests ont tendance à être limités, voire « oubliés », du fait des retards déjà accumulés et de la pression pouvant être exercée sur l’équipe de projet. 153
  • 154. Tests/Recettes  La phase de tests constitue néanmoins une activité centrale puisqu’elle assure la qualité absolument nécessaire qui n’est fournie ni par les logiciels de conception, ni par les outils de développements  Les conséquences économiques et financières démontrent la nécessité de tester les applications en cours de développement ; néanmoins, il est impossible de tester l'application entièrement  Une partie importante des problèmes d’exploitation résulte de défaillances de tests 154
  • 155. Tests/Recettes  S'assurer du respect des normes de recette finale : Procès-verbal (PV) de recette       Vérifier l'existence et la pertinence d'une procédure formalisée de recette finale destinée à accepter formellement l’application Vérifier la participation active des acteurs concernés S'assurer de la maîtrise suffisante du système par les personnes impliquées dans la recette Vérifier la pertinence des jeux d'essais et s'assurer de l'étendue des tests S'assurer que les tests de performances sont réalisés dans les futures conditions d'exploitation du système S'assurer de la formalisation des résultats des jeux d'essais et de la recette finale par la direction du département utilisateur 155
  • 156. Conduite du changement    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. 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 la conduite du changement est structurée en 6 phases :       Identification et évaluation des changements, Plan de communication, Plan de formation, Élaboration définitive de la documentation, Organisation du soutien, Reprise des données. 156
  • 157. Conduite du changement  Identification et évaluation des changements     Existe-t-il une synthèse de l'évaluation des changements ? L'évaluation a t-elle été validée ? S'assurer que les entretiens réalisés sont représentatifs ? Les utilisateurs participent-ils à l'évaluation des changements ? 157
  • 158. Conduite du changement  Plan de communication      Existe-t-il un plan de communication ? Est-il complet ? Les messages sont-ils clairs et simples ? Y-a-t-il une progressivité de la communication par rapport au développement du projet ? Existe-t-il un soutien fort de la Maîtrise d'Ouvrage ? 158
  • 159. Conduite du changement  Plan de formation       Vérifier l'existence d'un plan de formation des utilisateurs et des opérateurs. La hiérarchie des personnes à former est-elle impliquée ? Vérifier l'identification des profils types des personnes à former. Vérifier la pertinence de la population à former. Les objectifs de chaque formation sont-ils identifiés et affichés? Evaluer les cessions et apporter les éventuelles adaptions. 159
  • 160. Conduite du changement  Plan de formation (suite)     Vérifier l'adéquation du planning de formation au planning du projet. Vérifier la pertinence de la durée du programme de formation. S'assurer de la qualité pédagogique des formateurs et du contenu de la formation. Vérifier l'existence d'une procédure d'évaluation des formés et des formateurs. 160
  • 161. Conduite du changement  Élaboration de la documentation    Vérifier l'existence d'un manuel d'utilisation, d'un aide mémoire, d'un guide utilisateurs, d'une aide en ligne. S'assurer de la bonne répartition entre documentation en ligne et documentation papier. Les accès à la documentation répondent-ils en priorité aux besoins des utilisateurs ? 161
  • 162. Conduite du changement  Vérifier l'existence d'un manuel utilisateurs     Vérifier que le manuel utilisateurs est conforme aux normes en vigueur. S'assurer de sa disponibilité et de sa compréhension par l'ensemble des utilisateurs. Vérifier qu'il comprend au minimum :  les objets du système et la description des dessins d'écran et des commandes disponibles,  les responsabilités concernant le redressement des erreurs ou anomalies,.  La description des sorties et leur mode de diffusion,  Les responsabilités en matière de sauvegarde/archivage/purge. S'assurer qu'il fait l'objet d'une procédure de mise à jour. 162
  • 163. Conduite du changement  Vérifier l'existence d'un manuel d'exploitation.      Vérifier que le manuel d'exploitation est conforme aux normes en vigueur. S'assurer de son accessibilité et de sa compréhension par les opérateurs. S'assurer qu'il a été testé lors des tests finaux. Vérifier qu'il comprend au minimum :  la fonction des programmes,  le libellé exact des fichiers concernés,  la liste des messages opérateurs et les réponses attendues,  les actions à suivre en cas d'anomalies,  la liste des états générés et leurs destinations,  les procédures de reprise,  les responsabilités de l'exploitation en matière de contrôles globaux. S'assurer qu'il fait l'objet d'une procédure de mise à jour. 163
  • 164. Conduite du changement  Organisation du soutien     Une organisation d'assistance aux utilisateurs a-t-elle été mise en place dans la phase d'exploitation du nouveau système ? Son organisation générale a-t-elle été bien anticipée ? S'assurer de la disponibilité réelle d'une formation et d'une expertise. Les différents niveaux de soutien sont-ils coordonnés et cohérents ? 164
  • 165. Conduite du changement  Reprise des données     Existe-t-il un dossier d'organisation de la reprise des données ? Le niveau de qualité des données d'origine est-il bien maîtrisé ? S'assurer de la mise en place de contrôles automatiques de la qualité des données obtenues après reprise. S'assurer de la mobilisation le plus tôt possible des utilisateurs devant participer à la reprise des données. 165
  • 166. Conduite du changement  Le bilan qualité comporte deux parties :   Le bilan qualité élaboré en référence au PAQ, Le bilan qualité exprimé par les utilisateurs. 166
  • 167. Bilan Qualité  Bilan de la qualité du logiciel élaboré en référence au PAQ :   Réalisé en prenant comme référence les exigences qualité fixées par la maîtrise d’ouvrage, traduites par le maître d’œuvre en objectifs et critères à respecter par le logiciel. Exigences fixées par les utilisateurs au niveau du système:  Conformité : conformité aux besoins fonctionnels et techniques exprimés par le cahier des charges fonctionnel et technique ;  Performance : temps de traitement des échanges courants au niveau des serveurs doit être inférieur à trois secondes dans au moins 95% des cas d’utilisations de ces échanges, sur une journée, pour environ 200 échanges par minute ;  Sécurité : système disponible et intègre. Système disponible pour les utilisateurs, tous les jours ouvrés, pour l’ensemble des traitements, avec une indisponibilité maximale acceptée inférieure à deux heures par semaine  Convivialité : système facile d’exploitation sans aucune installation de logiciel sur le poste client. 167
  • 168. Bilan Qualité  Bilan qualité exprimé par les utilisateurs    Il est fortement recommandé d’élaborer un bilan en prenant l’avis direct des utilisateurs. Cette appréciation peut se recueillir à l’aide d’un questionnaire qui doit passer en revue tous les aspects du logiciel. Critères d’appréciation de la qualité d’un logiciel :  Complétude et qualité des fonctionnalités présentes,  Ergonomie,  Performance,  Qualité de la documentation,  Robustesse et fiabilité,  Formation reçue,  Qualité et efficacité de l’assistance et du soutien. 168
  • 170. Mission n°1: Contexte et objectifs    Avant de lancer la réalisation d'un nouveau système destiné à remplacer les outils actuels de gestion administrative, physique et douanière des marchandises, une société a souhaité évaluer les risques liés au projet et étudier l'opportunité d'une solution alternative de type logiciel intégré. Cette société travaille avec un prestataire informatique spécialisé dans le domaine. Phase d'intervention de la mission:  Définition des Besoins du Système (Cahier des charges en cours de rédaction) 170
  • 171. Mission n°1: Contexte et objectifs  Thèmes examinés :      Existence d'une solution satisfaisante "logiciel/progiciel intégré" unique Modernité et pertinence technique du projet Modernité et pertinence fonctionnelle du projet Montage projet pour la rédaction du cahier des charges et pour la réalisation du système Montage contractuel pour la réalisation du système 171
  • 172. Mission n°1: Personnes rencontrées Personnes rencontrées  Directeur général adjoint,  DSI client,  Chef de projet EDI client,  Chef de projet client,  Directeur technique prestataire,  Chef de projet prestataire. 172
  • 173. Mission n°1: Principaux constats  Les solutions "logiciel intégré"    La mise en place d'un logiciel/progiciel intégré unique pour la gestion des moyens de transport et des marchandises ne semble pas appropriée (faible intérêt fonctionnel). Risques humains et sociaux importants dans le contexte de la ville. Pas d'offre sur le marché des logiciels/progiciels intégrés spécifiques pour une gestion globale de ce genre d'activité. Une solution de ce type unique serait donc coûteuse. 173
  • 174. Mission n°1: Principaux constats   Principaux constats (suite) Modernité et pertinence technique du produit envisagé    La méthode qui a été adoptée pour définir l'architecture technique cible dans le cahier des charges est satisfaisante. Globalement, les exigences essentielles ont été posées dans le cahier des charges pour un réseau de communication sécurisé appuyé sur des bases de données relationnelles. Le cahier des charges présente les besoins techniques et les contraintes à respecter. A ce titre, il est une base pour les propositions des prestataires. 174
  • 175. Mission n°1: Principaux constats  Modernité et pertinence fonctionnelle du produit envisagé   La description des nouvelles fonctionnalités doit être complétée :  Les fonctionnalités détaillées sont très proches de celles existantes ;  Les nouvelles fonctionnalités sont peu explicites. Absence d'une réelle étude des besoins 175
  • 176. Mission n°1: Principaux constats    Montage du projet pour la rédaction du cahier des charges Des difficultés ont été rencontrées dans le cadre de la rédaction du cahier des charges. Manque de clarté dans la définition des rôles et responsabilités des différents acteurs de la gestion du projet : le chef de projet utilisateurs (maîtrise d'ouvrage) n'a pas été formellement identifié.  Absence d'axe directeur donné au projet qui nuit à la pertinence et à la cohérence des travaux des responsables de projet informatiques et explique les différences de points de vue entre parties à la rédaction du cahier des charges.  Manque de disponibilité de ressources dédiées qui explique la dérive dans les délais initialement prévus. 176
  • 177. Mission n°1: Principaux constats   Montage projet pour la réalisation du système  Risques importants de dysfonctionnement liés à la structure pressentie pour la réalisation du système.  Origine de ces risques : la confusion des rôles entre maîtrise d'œuvre et maîtrise d'ouvrage.  Une des causes majeures de l'échec des grands projets (*).  La MOE tend à se substituer à la MOA sur des sujets qui relèvent de la responsabilité de la MOA ;  La réciproque étant vraie (ex : une MOA raisonnant en termes de solutions). (*) Projets mobilisant plus d'une dizaine de personnes en pointe, plus d'un niveau hiérarchique, avec un accent mis sur la gestion de projet. 177
  • 178. Mission n°1: Principaux constats   Montage du projet pour la réalisation du système  Les structures pressenties ne permettent pas de garantir totalement :  L'adéquation des fonctionnalités du système réalisé avec les besoins exprimés,  La livraison d'un outil techniquement performant,  La réalisation et la mise en œuvre du système dans des délais raisonnables. Montage contractuel pour la réalisation du système  La question n'a pas été abordée 178
  • 179. Mission n°1: Recommandations  Recommandations générales  Il semble souhaitable de continuer le projet et pour qu'il se déroule dans les meilleures conditions possibles, de :  Nommer un chef de projet utilisateurs ;  Créer les conditions d'association d'une SSII expérimentée à la société informatique spécialisée pour la réalisation du système ;  Approfondir les possibilités de contractualisation dans le cadre d'une mise en concurrence pour la réalisation du système. La mobilisation d'une expertise juridique sur ce sujet est conseillée. 179
  • 180. Mission n°1: Recommandations  Pertinence technique du produit   La définition de l'architecture technique cible dans le cahier des charges est satisfaisante Pertinence fonctionnelle du produit :   L'absence réelle d’étude des besoins est un handicap important. Le caractère novateur du système peut être un atout concurrentiel important de la société face à ses clients. D’où la nécessité de vérifier rapidement les évolutions prévisibles dans ce domaine :  Auprès de quelques grandes sociétés de transport ;  Auprès de la société la plus avancée sur le plan mondial dans le domaine de l'informatisation logistique. 180
  • 181. Mission n°1: Recommandations    Montage du projet pour la rédaction du cahier des charges Désigner un chef de projet utilisateur pour fixer les orientations générales à donner au projet. Montage du projet pour la réalisation du système   Même si des procédures adéquates d'arbitrage et de gestion des relations entre les partenaires ont été prévues dans le projet de convention pour la réalisation du système ; Il conviendra de clarifier les rôles de chacun et de réfléchir à l'opportunité de s'associer les compétences d'un prestataire informatique expérimenté. 181
  • 182. Mission n°1: Recommandations  Montage contractuel    Nécessité de choisir une procédure. Les instances appropriées devront se prononcer sur le choix d'une procédure pour le montage contractuel (appel d'offre ouvert, appel d'offre restreint, marché négocié avec ou sans compétition). Trois modèles de montages contractuels sont possibles :  Sous-traitance totale de l'informatique : appel d’offre,  Parrainage par une société chargée de l'exploitation du système (situation actuelle). La solution " marché négocié sans mise en concurrence" entre le maître d'ouvrage et le maître d'œuvre présenterait des risques financiers et juridiques qu'il conviendra d'analyser. 182
  • 183.  Chiffrage du projet    Le chiffrage actuel ne tient pas suffisamment compte de l'existant, des projet précédents et de la connaissance du métier et des outils des partenaires. Le chiffrage du projet pourrait être revu à la baisse sur la base d'une version validée du cahier des charges.  On peut noter que lorsqu'une entreprise lance un appel d'offres pour choisir un prestataire, elle demande une évaluation du coût du projet. Toutefois, dans la mesure où les dérives sur les projets de cette taille sont très fréquentes, il convient de ne pas sousestimer les coûts, qui peuvent se révéler à terme beaucoup plus élevés. 183
  • 184. Mission n° 2: Contexte et objectifs   L'objectif de notre intervention consiste, dans le cadre d'une acquisition potentielle, à dresser une revue générale de l'informatique pour le compte du repreneur de la société. Pour ce faire, notre champ d'étude couvre cinq domaines :      l’organisation de la fonction informatique, l’architecture technique, une revue des applications existantes, la sécurité du système d'information (sécurité logique et physique, plan de continuité des opérations, procédures de développement et de maintenance, etc.), les contrats de prestations de services. 184
  • 185. Mission n° 2: Contexte et objectifs  Et essentiellement une prise de connaissance du projet de migration informatique sur le nouveau progiciel, y compris les chantiers Euro et An 2000. A ce titre, nous avons étudié :     Les modalités de choix du progiciel, L’organisation du projet et son degré d'avancement, Ainsi que la nature et l’évaluation globale des travaux restant à réaliser. Phase d'intervention:  Migration du système d’information vers un progiciel bancaire dans le cadre de la mise en place d’un schéma directeur. 185
  • 186. Mission n° 2: Personnes rencontrées         Directeur informatique et Directeur adjoint, Responsable Réseau/Micro, Directeur de l’Organisation, Directeur de l'Agence Centrale, Direction Commerciale, Secrétariat Crédits, Direction des Opérations, Département Etranger, Département Comptabilité, Manager d'un cabinet de conseil et d'audit (Maîtrise d'ouvrage déléguée du projet de migration vers le nouveau progiciel). 186
  • 187. Mission n° 2: Principaux constats sur le projet de migration  De nombreux chantiers ne sont pas encore stabilisés, le maintien d'un démarrage prévu dans les deux mois à venir présente des risques importants :     Risques d'insuffisance des tests compte tenu des délais restants, États de gestion internes ne répondant que partiellement aux besoins de la société, Absence de maîtrise des processus complets d’exploitation, Risque d'une solution dégradée au démarrage pour plusieurs applicatifs. 187
  • 188. Mission n° 2: Principaux constats sur le projet de migration  Les risques potentiels associés au projet de migration ont un impact fort sur le plan :    De la continuité de l’activité  Absence de solution de secours sur le système cible. Des coûts de mise en place  Le budget de vingt millions de francs initialement alloué au projet de migration est largement dépassé. Le non-respect des délais fixés est susceptible de générer un surcoût important (assistance supplémentaire de prestataires...). De la continuité de l’exploitation  Perturbations organisationnelles et fonctionnelles,  Insuffisance de tests compte tenu des délais fixés,  Maîtrise partielle ou insuffisante de l’enchaînement des processus d’exploitation. 188
  • 189. Mission n° 2: Principaux constats sur le projet de migration   Les risques potentiels associés au projet de migration ont un impact fort sur le plan (suite) :  Du respect des exigences réglementaires et interbancaires  De la solution de secours  Faible visibilité à ce jour sur la pertinence des solutions minimales requises.  De la forte dépendance de l’établissement vis-à-vis de l’éditeur du logiciel,  De la motivation des équipes dédiées au projet  Leur mobilisation est une condition indispensable au succès de la migration. Le maintien d'un démarrage dans les deux mois à venir présente des risques de perturbations importants et/ou de blocages non maîtrisés, 189
  • 190. Mission n° 2: Recommandations  Compte tenu des risques évoqués, nous recommandons de ne pas faire l'acquisition de l'institution financière avant la migration vers le progiciel  Un audit approfondi devrait être effectué après cette migration n Nous recommandons de prendre en compte les risques relatifs à une éventuelle rupture des contrats informatiques en cours et le cas échéant procéder à une analyse approfondie des contrats par un juriste spécialisé. 190
  • 191. Mission n° 3: Contexte et objectifs    Notre mission consiste à effectuer une revue d’un dispositif téléindicateur pour le compte d’une grande entreprise de transport. La Maîtrise d’œuvre est assurée par une PME spécialisée dans le développement de ce type de produit. Phase d'intervention :  Qualification/homologation du système : tests et recettes. 191
  • 192. Mission n° 3: Personnes rencontrées Personnes rencontrées  Au niveau du maître d'œuvre :     Président Directeur Général de l'entreprise, Directeur Commercial, Chef de Projet. Au niveau de l'entreprise de transport :    Représentant des utilisateurs, Commanditaire du système, Chargé de la maintenance du système sur site. 192
  • 193. Mission n° 3: Principaux constats  Diagnostic général    La réception définitive du système n’est pas prononcée (portefeuille de bogues important) ; Le projet a engagé à ce jour des charges significativement supérieures aux coûts prévus et n’est pas économiquement en mesure, de prendre toutes les initiatives qui pourraient être nécessaires ; La maîtrise technique du système est concentrée sur une seule personne. Cette situation est fragilisante pour le client. 193
  • 194. Mission n° 3: Principaux constats  Le projet       Pas de méthode de conduite de projet, Modifications effectuées pendant les développements sans mise à jour de la documentation, Peu de suivi de projet (planification et suivi d'avancement), Manque de procédures, Documentation inexistante ou inexploitable, Formation des utilisateurs très insuffisante, 194
  • 195. Mission n° 3: Principaux constats    Plate-forme de tests et qualification insuffisantes, Procédure de gestion des anomalies trop peu rigoureuse, Contribution insuffisante de la maîtrise d'ouvrage dans les phases de tests,    Aucun plan d'acceptation du système fourni par la maîtrise d'ouvrage, Manque de communication entre maîtrise d'œuvre et la maîtrise d'ouvrage, Relations conflictuelles entre la MOA et MOE. 195
  • 196. Mission n° 3: Principaux constats   Le logiciel Points faibles:     Produit incomplet, Ne peut fournir le service attendu sans incidents, Niveau de maintenabilité très insuffisant. Point fort:  Caractère évolutif du produit 196
  • 197. Mission n° 3: Recommandations  Organisation du projet :    Nécessité de mettre en place une nouvelle équipe de projet et de prévoir une période de transition, Formaliser une procédure précisant les modalités de collaboration entre les utilisateurs et la fonction informatique : confusion MOA/MOE, Préciser les responsabilités de la MOE et de la MOA. 197
  • 198. Mission n° 3: Recommandations  Contrôle du projet :       Continuer de stabiliser l'existant i.e. les demandes d'évolution doivent rester gelées Envisager l'acquisition d'outils performants de développements pour améliorer la qualité du logiciel, Nécessité de gérer la configuration et les versions du logiciel, Nécessité de mettre en œuvre une gestion rigoureuse des anomalies, Suivre une démarche de mise au point et de qualification du logiciel en mettant en œuvre des procédures de tests, La mise en place d'un site pilote est indispensable dans la procédure de qualification. 198
  • 199. Mission n° 3: Recommandations  Documentation :  Nécessité de constituer une documentation du système en précisant :  Les spécifications externes ou fonctionnelles,  Les spécifications internes ou organiques globales,  L'architecture technique globale et l'architecture modulaire détaillée (les documents sont manuscrits), 199
  • 200. Mission n° 3: Recommandations  Documentation (suite) :      Le plan de développement : document contenant les informations de planification liées au développement du logiciel. Le découpage du projet en tâches élémentaires et l’estimation de la charge de réalisation de chaque tâche en précisant la compétence choisie et le temps requis ; La planification des tâches et la consommation induite des ressources Les événements clés permettant de contrôler l’avancement. On pourra ainsi mesurer le suivi d’avancement du projet en comparant ressources consommées/résultats obtenus d’une part et délais prévisionnels/délais réels d’autre part. 200
  • 201. Mission n° 3: Recommandations  Documentation :  Nécessité de constituer un dossier « Utilisateurs » comportant :  Le manuel utilisateur  Le guide de maintenance 201
  • 202. Mission n° 3: Recommandations  Communication :      Implication de la direction générale dans la gestion des projets, Raisonner en terme de structure et non en terme de personnes, Respecter les rôles et responsabilités de chacun, Compréhension du logiciel par les utilisateurs, Participation importante des utilisateurs. 202
  • 204. Les causes principales de dysfonctionnement sont:    Une mauvaise prévision : mauvaise prévision des tâches à effectuer, mauvaise prévision des conséquences de la mise en place du nouveau système Une mauvaise organisation : partage des rôles entre les intervenants imprécis, fonctions non identifiées, taux de participation trop flou Une mauvaise communication : contexte et objectifs du projet méconnus, validations implicites, interlocuteurs concernés non impliqués, compterendu insuffisant du maître d'œuvre au directeur de projet 204
  • 205. Les causes principales de dysfonctionnement sont:    Des engagements contractuels mal définis entre la maîtrise d'ouvrage et la maîtrise d'œuvre. Les conséquences de ces dysfonctionnements peuvent être un surcroît de charges, un allongement des délais, une mauvaise qualité du logiciel ou des services offerts aux utilisateurs pouvant aller même jusqu'au rejet de l'application. 205
  • 206. Maîtriser le développement du projet  Au plan de l'organisation :     Une implication forte de la hiérarchie ; Des représentants maîtrise d'ouvrage et maîtrise d'œuvre désignés ; Des structures de travail (groupes utilisateurs, de pilotage) et de décision (comité directeur, comité exécutif) équilibrées, effectives et représentatives ; Des rôles bien définis pour chaque participant 206
  • 207. Maîtriser le développement du projet  Au plan de l'organisation (suite):      Un document de départ à l'intention de la maîtrise d'œuvre définissant clairement les objectifs du projet, les contraintes et les résultats attendus, les exigences de qualité et les travaux préalables ; Un calendrier et un budget prévoyant à l'avance les tâches à effectuer et leur durée ; Un tableau de bord et des procédures de contrôle de l'avancement ; Des procédures de validation et de recette ; Un plan d'actions pour la maîtrise d'ouvrage. 207
  • 208. Maîtriser le développement du projet  Au plan des méthodes et des outils :      Une démarche : succession de tâches à assumer et de résultats à produire ; Une méthode d'évaluation des charges ; Une méthode de planification et de suivi de l'avancement permettant d'avoir en permanence une bonne visibilité sur 'avancement du projet ; Un plan d'assurance qualité ; Des outils : atelier de génie logiciel, outil de conduite de projet, etc. 208
  • 209. Maîtriser le développement du projet    Toutes ces dispositions préétablies et systématiques destinées à donner confiance en l'obtention de la qualité requise doivent être consignées dans un plan d'assurance qualité (PAQ). Ce plan doit être spécifique à chaque projet et établi en fonction des exigences qualité formulées par la maîtrise d'ouvrage. Les exigences qualité doivent être traduites en facteurs qualité ou en critères qualité véritables. 209
  • 210. Mohamed SAÂD Saadmedin@yahoo.fr Viser à l’ensemble, et se mettre à l’œuvre par les détails (Proverbe chinois) 210