EPI Business school

Cours de Management des Systèmes

d'Information
(Année universitaire: 2021/2022)

Enseignant: ABBADI Wassim

Gestion de projet
Définition d'un projet
« Un projet correspond à la situation dans laquelle on se trouve quand on
doit atteindre un objectif avec des moyens appropriés dans un délai donné
».
« La gestion ou conduite de projet a pour but de mener un projet à son
terme en prenant en compte les contraintes et en faisant face aux imprévus
». A chaque point caractéristique d'un projet (objectif, moyens, délai), la
conduite de projet associe une technique de gestion.
 Le délai donne lieu à une gestion du
temps dont le rôle est de définir le
parcours, de le jalonner, d'établir des
calendriers et de maîtriser la
consommation de l'enveloppe temps.
 Les moyens affectés constituent le budget
du projet, qui est transformé en travail,
locaux, matériel, temps machine,
déplacement... Cette transformation
nécessite une gestion des ressources
portant sur les ressources humaines et les
moyens matériels. Dans les projets
système d'information, les ressources
humaines occupent une place primordiale.
Utiliser chacun au mieux, constituer des
équipes efficaces, affecter les personnes
au moment adéquat en fonction de leurs
compétences, coordonner les travaux,

1
 limiter le nombre d'acteurs sans pour
autant exclure.. telles sont les attributions
de cette fonction
 L'objectif du projet doit à son terme être
concrétisé par une ou plusieurs
fournitures. Ce sommet donne naissance
à la gestion de la production qui a pour
but de suivre et de diriger l'avancement
vers l'objectif tout au long du projet. Il faut
sans cesse s'assurer que l'on se
rapproche du but et que l'on ne part pas
dans des directions remettant en cause un
avancement consolidé.
L'activité de gestion de projet peut être
décomposée en trois activités principales :
 Analyser : déterminer le chemin
pour atteindre l'objectif. Découpage
du projet en actions à entreprendre
et estimation de l'effort nécessaire.
 Organiser : constituer les équipes,
ordonner les tâches, élaborer le
calendrier.
 Piloter : suivre l'avancement du
projet en qualité et en quantité,
analyser les écarts et prendre les
décisions.
Un projet se gère du début à la fin. L'approche de la problématique définie
à l'issue de l'analyse des risques peut être remise en cause par un aléa
interne ou externe. Cela peut conduire à une re-planification, une nouvelle
répartition des tâches, voire à une modification de l'objectif initial. C'est ce
que représente la boucle de rétroaction dans le schéma précédent.
Un projet (également les projets SI) possède quatre caractéristiques:
• il
est unique: s'il existe de nombreux projets analogues ou similaires,
aucun projet n'est identique à un autre en raison des évolutions
technologiques et des spécificités organisationnelles de chaque entreprise.
Contrairement aux processus répétitifs, l'organisation d'un projet est
toujours à redéfinir;
• il
est limité dans le temps: un projet est mené par rapport à un calendrier
dans un espace temps borné par un début et une fin;
• il
doit répondre à des contraintes de délais, de coûts, de ressources, mais
également de qualité, ce qui impose la mise en place d'un processus de
management de projet;
• il
est pluridisciplinaire: il requiert des compétences techniques,
administratives, financières, juridiques,etc.

2
Les classifications des projets de système d'information :
La diversité des projets de système d'information incite les entreprises à
procéder à des classifications qui peuvent se fonder soit sur des
critères généraux, soit sur le type de projet conduit.

a-La classification selon des critères généraux:

Une première classification s'appuie sur les critères généraux qui sont:
• le budget, qui correspond au montant engagé pour la réalisation du
projet;
• le périmètre, qui détermine l'ensemble des activités et processus
concernés par le projet;
• la complexité de lancement et de mise en œuvre du projet, tant au
niveau technologique qu'au niveau organisationnel.
Cette classification est utile pour déterminer l'ordre de réalisation des
projets en fonction des contraintes et des ressources de l'entreprise.
Le projet d'intégration d'un progiciel de gestion intégré (PGI) dans un
groupe est un projet essentiel de plusieurs milliers de dinars demandant
une définition très précise des objectifs et se déroulant sur des années. Il
est complexe étant donné que son périmètre concerne l'ensemble des
processus. Une organisation de ce projet doit être mise en place pour sa
mise en œuvre.
Remarque: Progiciel: ensemble de logiciels conçus pour répondre à
des besoins spécifiques et permettre une utilisation autonome.
C'est un puissant système informatique composé d'une série
d'applications appelées aussi modules.
PGI: Progiciel de Gestion Intégrée ou encore ERP: Enterprise
Ressources Planning).
Exemples d'ERP: SAGE,SAP,DASSAULT SYSTEMS

b-La classification selon le type de projet:

Le type du projet détermine son mode de pilotage. Un projet obligatoire
sera piloté par les coûts, un projet de productivité par la rentabilité. En
revanche, un projet stratégique pourra s'appuyer sur l'une ou l'autre
approche.
Type de projet Description p Exemples
Par la • Refonte d'un système d'information obsolète (dépassé)
Projet impactant la rentabilité
Projet stratégique stratégie globale • Implantation d'un PGI permettant de proposer de nouveau
et/ou les
de l'entreprise services
couts

3
 Projet de Projet améliorant Par la • Informatisation d'un processus
productivité la productivité de rentabilité
• Reconfiguration d'un processus
l'entreprise
Par les • Intégration des modifications du plan
couts
Projet comptable général dans le logiciel de gestion d
résultant de immobilisations
Projet obligatoire
contraintes • Implantation d'un logiciel de consolidation
légales,
réglementai respectant les normes IAS/IFRS
res,etc

Les enjeux d'un projet de système d'information:

Les enjeux d'un projet de SI sont de contribuer à l'efficacité et à la maîtrise du
système d'information ainsi qu'à la performance globale de l'entreprise tant le
système d'information est un véritable actif stratégique au service de la stratégie
globale de l'entreprise.

4
La place du projet de SI dans la stratégie de l'entreprise:
Un projet de système d'information doit s'inscrire dans la stratégie globale de
l'entreprise car il consomme des ressources importantes (humaines, financières,
etc.) pendant une longue période. C'est la raison pour laquelle l'entreprise doit, avant
même de se lancer dans un projet, définir ses objectifs à moyen terme dans un
schéma directeur informatique Ce document permettra une planification globale des
projets et des investissements à conduire dans l'entreprise, selon différents critères
(budget, délais, risques, charges internes, besoins en conduite de changement, etc.)
Les projets sont ensuite analysés sous l'angle de leur périmètre. Si le projet est trop
étendu ou trop complexe, il est décomposé en sous-projets (SP) avec des
périmètres différents.
Le projet d'intégration d'un progiciel de gestion intégré dans un groupe pourra
donner lieu à plusieurs sous-projets:
• SP1 : intégration du module de gestion des ventes;
• SP2 : intégration du module de comptabilité;
• etc.
Les sous-projets sont hiérarchisés pour déterminer l'ordre de leur réalisation. Ils
peuvent être regroupés en lots: on parle alors de « lotissement ». Cette subdivision
permet de faciliter la réalisation de projets de système d'information.

L'organisation du projet:
Une fois la décision de lancer un projet prise, se pose la question de la gestion de ce
projet. La conduite d'un projet nécessite la mise en place d'une démarche
méthodologique visant à assurer la coopération et la coordination des acteurs ainsi
que l'organisation des tâches dans un souci de rentabilité, d'efficacité et de qualité.
Elle se base sur une organisation du projet en deux entités distinctes qui sont:
• la maîtrise d'ouvrage (MOA), qui est le client du projet;
• la maîtrise d'œuvre (MOE), qui est le fournisseur, l'organe
réalisateur du projet. Ces deux entités peuvent appartenir à la même
entreprise.
L'organisation du projet est mise en place par un comité directeur.

5
 Le comité directeur
Le comité directeur des projets de système d'information est un comité permanent
composé de membres de la direction générale et, éventuellement, de représentants
de la direction des systèmes d'information (DSI) et des directions métiers (DM). Il
définit la politique informatique de l'entreprise et élabore le schéma directeur. Dans le
cadre d'un projet, le comité directeur:
• initie le projet et précise ses orientations;
• définit le périmètre du projet, voire, si la définition des processus est difficile,
les fonctions ou les services impactés;
• met en place le comité de pilotage;
• valide le budget et décide du démarrage du projet.
Dès la fin de l'étude préalable, le comité directeur n'intervient plus directement dans le
cycle de vie du projet.
La maîtrise d'ouvrage
L'AFNOR (Association française de normalisation) définit la maîtrise d'ouvrage
comme « une personne physique ou morale qui sera propriétaire de l'ouvrage [et]
assure le paiement des dépenses liées à la réalisation ». La MOA peut faire appel à
un assistant à la maîtrise d'ouvrage (AMOA ou AMO), entité interne ou externe qui
l'assistera dans la conduite du projet.
L'organisation de la MOA est fonction de la taille du projet, mais elle est
généralement constituée d'un comité de pilotage et d'un comité des utilisateurs.

Le comité de pilotage
Le comité de pilotage est l'organe directeur de la maîtrise d'ouvrage en charge des
arbitrages nécessaires à la conduite du projet (révision des délais, modification du
périmètre du projet, etc.). Il est créé par le comité directeur, à qui il rend compte de
l'évolution du projet. Présidé par un directeur de projet (chef de projet MOA), il est
composé de représentants opérationnels concernés par la nouvelle application, de
l'assistant à la maîtrise d'ouvrage, d'experts internes ou externes.
Le chef de projet MOA doit disposer d'une bonne connaissance de l'entreprise, de
son activité et de ses usages.
La mission d'un chef de projet MOA : il doit « garantir le bon déroulement des projets
qui lui sont confiés. Il conçoit et réalise les recettes, planifie et suit l'avancement des
projets et participe à l'accompagnement du changement pour les utilisateurs.

Le comité des utilisateurs

Le comité des utilisateurs est constitué de représentants des utilisateurs qui
interviennent dans les domaines d'activité concernés par le projet, d'experts métiers
et du chef de projet MOA. Il est important d'obtenir une réelle participation de ses
membres durant le déroulement du projet afin que la solution réalisée dans le cadre
du projet soit acceptée par les utilisateurs finaux. Ses attributions sont les suivantes:
• expression des besoins;
• validation des livrables;
• participation aux tests de la solution;

6
 • participation aux actions de formation;
• réception définitive de la solution.

La maitrise d'œuvre
L'AFNOR définit la maîtrise d' œuvre comme« une personne physique ou morale qui
réalise l'ouvrage pour le compte du maître d'ouvrage, assure la responsabilité
globale de la qualité technique, du délai et du coût ».
La MOE est responsable de la solution jusqu'à sa livraison et de la qualité de la
soluution fournie pendant la période de garantie. De plus, elle a un devoir de conseil
et d'alerte au sujet des risques pouvant résulter des orientations prises par le chef de
projet MOA.
La maîtrise d'œuvre assure notamment les responsabilités suivantes:
• analyse des besoins de la maîtrise d'ouvrage;
• proposition d'une ou de plusieurs solutions techniques;
• identification et planification des tâches à réaliser;
• définition des moyens humains et matériels nécessaires à la conduite du projet;
• réalisation de la solution retenue dans la conformité des besoins exprimés et
suivi des activités externalisées;
• compte rendu au directeur de projet de l'avancement du projet et soumission
des éléments à valider;
• livraison au directeur de projet de la solution testée;
• déploiement de la solution avec la participation de la MOA (responsabilités
partagées).
Si elle ne dispose pas en interne des compétences nécessaires, la MOE peut
externaliser certaines tâches inhérentes à la réalisation de la solution, voire être
représentée par une SSII sélectionnée par la MOA.
La MOE est généralement constituée d'un groupe de projet et d'une équipe de
conception et de réalisation.

Le groupe de projet
Le groupe de projet est dirigé par un chef de projet MOE, qui assure les fonctions
d'animation au sein de la MOE et de communication avec la MOA, au travers de
réunions et/ou de tableaux de bord permettant le pilotage du projet. Il doit disposer
d'une réelle expertise technique pour piloter une équipe de conception et de
réalisation composée de techniciens et d'ingénieurs en informatique.
Le chef de projet MOE a pour mission d'assurer l'organisation et la mise en place
d'un projet informatique avec l'aide de ressources internes et externes à l'entreprise.
Ses tâches comprennent:
• le recueil des besoins et la rédaction des spécifications;
• la planification des phases de réalisation;
• la coordination de la maîtrise d'ouvrage et des équipes de développement;
• la supervision des tests et de la recette;

7
 • la participation au support de production (documentation, formation);
• l'animation de réunions avec le client;
• le reporting de l'activité.
Le groupe de projet a pour principale tâche de gérer les équipes de développement
et/ou de paramétrage, internes ou externes. Il organise l'assurance qualité et suit
l'avancement et la consommation des ressources du projet.

. L'équipe de conception et de réalisation

L'équipe de conception et de réalisation programme, développe, paramètre la
solution. Lorsque ces activités sont confiées à un prestataire externe, il est
indispensable qu'une personne de l'entreprise fasse partie du groupe de projet

Remarque: Les relations entre la maîtrise d'ouvrage et la maîtrise

d'œuvre:
Un des principaux facteurs de succès d'un projet est la qualité de la relation entre la
MOA et la MOE. De nombreux dysfonctionnements proviennent d'un manque de
communication, de coopération, de coordination et de confiance entre ces deux
entités. Pour renforcer la confiance entre les acteurs des deux entités, les principes
suivants doivent être respectés:
• définir avec précision les rôles respectifs de la MOA et de la MOE;
• doter le projet de structures décisionnelles, fixer un calendrier de réunions
(fréquence, thèmes abordés, participants), déterminer les modalités
d'arbitrage en cas de conflit;
• favoriser la communication, la coopération et la coordination en organisant
des réunions de travail et des points d'avancement.
La MOA doit rester forte et conserver l'orientation stratégique du projet, même si la
MOE joue un rôle de conseil.

8
Malgré la diversité des projets, différentes phases et étapes clés sont communes à
tout projet et nécessitent l'implication de la MOA et de la MOE.
Les différentes phases et étapes du cycle de vie d'un projet de SI:
Phases Étapes Acteurs impliqués
Étude préalable MOA

Conception générale Analyse MOA

Appel d'offres MOA
Conception détaillée MOA et MOE

Développement Réalisation MOE

Recettage de la solution MOA et MOE
Déploiement MOE
Maintenance MOA et MOE

Un jalon est un événement important à l'intérieur d'une phase ou en fin de phase. Un

événement n'a pas de durée; il correspond au franchissement d'une étape lorsque
les exigences fixées préalablement en termes de délais, de coûts, de ressources et
de qualité sont remplies. Un jalon permet donc de vérifier que les conditions de
poursuite du projet sont réunies.
 Cycle de vie d'un projet de développement:

Phases Étapes livrables

• Expression des besoins
• Étude d'opportunité • Cahier des charges MOA
Avant-projet • Portefeuille de projets
• Rapport d'opportunité initial
• Planification globale
• Rapport d'opportunité mis à jour
Initialisation
• Plan de projet initial
• Analyse fonctionnelle • Plan de projet complété
Analyse
• Analyse détaillée • Analyse détaillée
• Développement et tests
• Intégration • PV de recettes fonctionnelles
Réalisation • Recettes techniques
• Recettes fonctionnelles
• Feu vert de démarrage
Déploiement
•PV de mise en production
Exploitation
et • Bilan du projet
maintenance

L’estimation des charges :

Notions générales :
La charge représente la quantité de travail nécessaire indépendamment du
nombre de personnes qui seront affectées à la réalisation du projet. Elle s’exprime en
jour/homme. Un mois/homme est équivalent à 20 jours/homme.
(Jour/homme : Unité de mesure qui correspond au travail d’une personne pendant
une journée. Par exemple, un projet qui demande 10 jours/homme peut
théoriquement nécessiter le travail d’une personne pendant 10 jours, de 10
personnes pendant 1 jour ou encore de 2 personnes pendant 5 jours).
Elle permet d’obtenir le coût prévisionnel en fonction de la charge estimée et du coût
complet d’un jour/homme. L’unité jour/homme est donc l’unité d’œuvre pour le calcul
analytique du coût du projet. Exemple : pour une durée prévue de 60 mois/homme à
10000 DT le mois/homme, le coût prévisionnel du projet est estimé à 600000 DT.
La durée du projet dépend du nombre de personnes affectées à sa réalisation (par
exemple, une personne pendant 5 ans ou 5 personnes pendant 1 an).
Ordre de grandeur de la taille des projets :

• Très petit projet: <= 6 mois/homme;

• Petit projet: entre 6 et 12 mois/homme;
• Projet moyen: entre 12 et 30 mois/homme;
• Grand projet: entre 30 et 100 mois/homme;
• Très grand projet: >= à 100mois/homme.

Les méthodes d'estimation de la charge :

Méthodes Descriptions
Cette méthode se fonde sur une estimation descendante. Dans un premier temps, le
projet est décomposé en phases. Dans un deuxième temps, les phases sont
Décomposition décomposées à leur tour en activités significatives et évaluables en termes de charge.
Ensuite, la charge totale du projet est déterminée avec une majoration de 10 à 20 %
pour couvrir la gestion de projet à proprement parler.
 Cette méthode est utilisée pour les tâches répétitives (par Exemple, le déploiement sur
Multiplication des postes).
Analogie Cette méthode est basée sur l'expérience en gestion de projet (expérience avec d’autres
projets).
Délimitation Cette méthode utilise des minimas et des maximas pour extraire une valeur réaliste.

Cette méthode utilise les pourcentages généralement admis par les méthodes
Pourcentages structurées (par Exemple, s'agissant du développement interne, selon la méthode
HERMES: 5 % pour l'étude préalable, 35 % pour la conception, 55 % pour la réalisation
et 5 % pour l'introduction).
Méthode HERMES : méthode de gestion de projets développée par l’administration
fédérale Suisse surtout pour les projets informatiques

COCOMO
Cette méthode se fonde sur la taille du projet exprimée en lignes
(COnstructive de code.
COstMOdel)
Elle permet de définir une estimation de l’effort à fournir dans un
développement logiciel et la durée que ce dernier prendra en
fonction des ressources allouées

Ces différentes méthodes sont utilisées par les entreprises selon leur expérience
des projets à conduire et la nature de ces derniers.
En l’absence d’estimation précise de la charge de travail et de contrôle du travail, on
risque de voir apparaître le phénomène décrit par la « loi de Parkinson 1957 » : «
Tout travail se dilate jusqu’à remplir le temps disponible ».
Les différentes méthodes appartiennent à trois familles :
• Le jugement d’experts qui estime la charge du projet d’après leur expérience sur
des projets similaires méthode DELPHI;
• Les méthodes de répartition proportionnelles : elles sont basées sur l’hypothèse
que les différents sous-ensembles sont liés par une relation de proportionnalité;
• Les méthodes utilisant un modèle:
- Le modèle Cocomo et sa variante le modèle Diebold;
- Le modèle d’évaluation analytique;
- Le modèle des points fonctionnels.

Chacune de ces méthodes a pour point commun de :

• Construire une base de connaissances sur l’expertise de projets antérieurs;

• Faire l’estimation du projet selon une unité de mesure;
• Convertir la taille en charge;
• Ajuster la taille en fonction des particularités du projet;
• Répartir la taille dans les différentes étapes.

La méthode DELPHI :
Cette méthode fut élaborée en 1948 par la Rand Corporation. La méthode consiste
à rechercher des analogies avec des projets antérieurs. Ces projets peuvent être
internes ou externes à l’entreprise. L’analogie prend en compte les facteurs
d’environnement.
• chaque expert propose une estimation en utilisant sa propre expérience;
• les jugements sont rendus publics, mais restent anonymes. Chaque expert peut
alors modifier ou confirmer son estimation;
• les nouvelles estimations sont dévoilées et chaque expert peut se justifier;
• normalement les experts arrivent à un consensus et cela permet de construire en
commun une première analyse du projet.
 La méthode de répartition proportionnelle :
Elle s’appuie sur le découpage temporel de référence. On utilise généralement la
répartition suivante :
Étapes Ratios
Étude préalable 10 % du total du projet
Étude détaillée 20 à 30 % du total du projet
Étude technique 5 à 15 % de la charge de réalisation
Réalisation 2 fois la charge d’étude détaillée
Mise en œuvre 30 à 40% de la charge de réalisation

Ces ratios sont issus des expériences positives et négatives de projets. Ces ratios
sont à la fois des recommandations et des règles. Ainsi, une étude préalable ne doit
pas consommer plus de 10% des ressources du projet.
Chacune de ces étapes est découpée en phases (par exemple pour l’étude
préalable, le découpage donne 3 phases : observation, conception/organisation,
appréciation) et chacune de ces phases fait l’objet du même principe d’estimation
(par exemple pour les trois phases ci-dessus : observation : 30 à 40%,
conception/organisation : 50 à 60%, appréciation : 10% de la charge d’étude
préalable).

Le modèle Cocomo :
Proposé en 1981 par B.W BOHEM, le mot Cocomo signifie Constructive Cost
Model c’est-à-dire modèle de construction des coûts. Il repose sur deux
hypothèses :
• Un informaticien sait plus facilement donner une évaluation de la taille du logiciel à
développer que faire une estimation du travail nécessaire;
• Il faut toujours le même effort pour écrire un nombre donné de lignes de
programme quel que soit le langage de troisième génération employé.

Ces deux hypothèses ont permis à l’auteur de calculer des coefficients de

corrélation entre la taille du logiciel et la charge consommée à partir d’observation
sur une centaine de projets réalisés. L’unité d’œuvre est l’instruction source. Il faut
donc disposer du nombre estimé de lignes de programme du programme source. Ce
modèle permet d’obtenir la charge de réalisation en mois/homme. Les formules de
calcul de la charge et du délai sont les suivantes :

Charge en mois/homme = a (kisl) b

Délai normal en mois= c (charge mois/homme)d

Avec : kisl = nombre de milliers d’instructions source livrées. Les paramètres

a, b et c varient selon la taille du projet.

D’après l’expérience, les valeurs sont les suivantes :

Type de projet Charge en mois/homme Délai en mois
Simple Charge = 3,2 (kisl) 1,05 D = 2,5 (charge mois/homme) 0,38
Moyen Charge = 3 (kisl) 1,12 D = 2,5 (charge mois/homme) 0,35
Complexe Charge = 2,8 (kisl) 1,2 D = 2,5 (charge mois/homme) 0,32

Ces valeurs « brutes » sont ensuite corrigées en fonction des caractéristiques du

projet. La charge du projet est ainsi multipliée par un facteur correcteur. Ces
corrections sont dues à quatre sources de risque :

Logiciel Projet Matériel Personnel

Fiabilité Utilisation d’une Taille mémoire Compétence des
Base de données méthode Stabilité de concepteurs
Complexité Utilisation d’un AGL l’environnement Expérience des
Temps d’exécution Contrainte de délai Disponibilité de la concepteurs
machine de test Compétence des
développeurs
Connaissance de
l’environnement technique
Expérience du langage

La démarche pour l’utilisation du modèle Cocomo se déroule ainsi en 5 étapes :

• Estimation du nombre d’instructions sources (kisl);
• Calcul de la charge brute;
• Sélection des facteurs correcteurs;
• Application des facteurs correcteurs pour obtenir la charge nette;
• Évaluation du délai normal.

La méthode d’évaluation analytique :

Elle s’appuie sur une typologie des programmes à développer. Les unités d’œuvre
sont donc les différents types de programmes. La typologie est permanente mais les
poids affectés aux unités d’œuvre varient en fonction de l’environnement et de
l’équipe de développement.
Elle permet d’évaluer le cout d’un projet à partir de la décomposition du travail à
réaliser en taches élémentaires. C’est la plus répandue des méthodes.
Exemples de logiciels qui traitent cette méthode :
- MULTIDEVIS dans le domaine du bâtiment
- MS PROJECT pour la planification des projets

Type de transaction Facile Moyen Difficile

Menu 0,25 0,5 1
Consultation 1 2,5 4
Mise à jour 1,5 3 5
Édition en temps réel 1 2 4

Type de programme par lots Facile Moyen Difficile

Extraction 0,5 1 1,5
Mise à jour 2 3 5
Édition 1,5 2,5 4

Les poids standards sont en jour/homme. On fait une estimation du nombre de

programmes à réaliser en les ventilant par nature en fonction de la demande du
client (cahier des charges ou dossier de spécification).
La charge calculée à l’aide des poids ci-dessus, appelée charge de réalisation,
comprend la programmation, l’élaboration des jeux d’essai de test et la mise au point
des programmes.
Pour obtenir la charge totale, il faut rajouter le temps pour les tests d’enchaînement
et pour l’encadrement (respectivement 10 et 20% de la charge de réalisation).
Le temps minimum incompressible de réalisation du projet est donné par la formule :
 Délai = 2,5 * charge en mois homme 1/3

La méthode des points fonctionnels :

L’auteur est Alan Albrecht en 1979, salarié d’IBM. Cette méthode a
d’abord été diffusée dans les entreprises clientes d’IBM puis adoptée par
la suite par de nombreux professionnels grâce à la constitution
d’association d’utilisateurs.
Le principe est de faire une estimation de la charge par rapport à la
description externe du projet, de ses fonctions. On identifie cinq types
d’unités d’œuvre et trois degrés de complexité. A chaque degré et à
chaque type, on affecte un nombre de points. La méthode permet de
calculer pour un projet donné son poids en points de fonction.
Différentes règles permettent ensuite de passer des points de fonction à
la charge de travail du projet.
La démarche comporte trois étapes :

• Calcul de la taille : dénombrement des différents composants

fonctionnels et de leur degré de complexité. Cinq types de composants
servent d’unités d’œuvre : deux relatifs aux données:
1. groupe logique de données internes (GDI) : correspond à
une entité ou à une association porteuse de données dans
une modèle Entité / Association;
2. groupe logique de données
externes (GDE); et trois relatifs aux
traitements:
1. entrée (ENT);
2. sortie (SOR);
3. interrogation(INT).
• Ajustement de la taille : on ajuste les points obtenus en fonction de la
spécificité du produit (système distribué, performance, réutilisation du
code, convivialité, etc.) au total 14 facteurs de pondération;
• Transformation des pointsde fonction en charge: elle est différente selon
l’environnement et le
facteur humain. Différentes formules ou études sont utilisées. Le
cabinet Butler-Cox a ainsi estimé que l’utilisation d’un L4G donne 1
jour de charge pour 10 points.

Cette méthode a pour but d’évaluer ou de mesurer les SI en terme de

richesse fonctionnelle livrée à l’utilisateur, de son point de vue donc du
métier.
Elle propose une mesure de la production de logiciel basée sur les
fonctions utilisateurs.
Elle aide à prévoir la taille d’un projet, son effort de développement et
 la productivité du développement informatique.

Fig : Composants de la méthode des points de fonction (ou points fonctionnels)

Les paramètres d'un plan d'assurance et contrôle qualité :

Paramètres Définitions Critères y contribuant
Aptitude avec laquelle le SI fonctionne sans • Disponibilité
Fiabilité défaillance pour une durée donnée (robuste, • Robustesse
constant, etc.) • Sécurité
• Bonne utilisation des
Aptitude avec laquelle le SI fonctionne avec
Efficacité un optimum de ressources et de temps
ressources machines
(mémoire, etc.)
Aptitude avec laquelle le SI est protégé • Disponibilité
Sécurité (Intégrité) contre les altérations ou les accès non • Intégrité
autorisés • Confidentialité
Effort requis pour l'apprentissage et le • Ergonomie
Convivialité dialogue homme/machine et la • Facilité d'utilisation
documentation • Facilité d'apprentissage
• Modularité
Réutilisabilité Aptitude avec laquelle le SI peut être utilisé • Indépendance logiciel et
dans de multiples applications matériel
• Niveau de paramétrage
Aptitude avec laquelle le SI peut • Compatibilité
Interopérabilité communiquer ou interagir avec d'autres
• Interfaçage
systèmes
Effort requis pour le transférer d'un
environnement à un autre. La portabilité peut • Modularité
être vue sous ses deux aspects: • Indépendance logiciel et
Portabilité • intégrable sur d'autres systèmes matériel
d'exploitation;
• intégrable sur d'autres machines.
Effort requis pour s'assurer de son bon • Automatisation des tests
Testabilité fonctionnement (jeu d'essais et vérification
• Facilité d'analyse des résultats
de résultats)
Effort requis pour localiser et corriger une • Qualité de la documentation
Corrigibilité erreur (lisibilité, traçabilité, accessibilité, etc.) • Traitement des erreurs
Effort requis pour l'amélioration, à • Perfectibilité
spécifications inchangées, ou pour le • Flexibilité
Adaptabilité • Modularité
modifier afin de répondre à de nouvelles
 versions du système d'exploitation • Niveau de paramétrage

On peut aussi prévoir un paragraphe précisant les mesures de la qualité (propriété

et métrique). Il décrit ainsi les paramètres retenus pour définir les objectifs et les
engagements qualité. Il est à adapter en fonction des spécificités du projet.
Exemples de paramètres de qualité applicables à un projet :
Engagements
Paramètres Propriétés Métriques
qualité
Indisponibilité du système, relative à une
Disponibilité anomalie, inférieure à 8 heures cumulées par
Garantir la fiabilité trimestre
Fiabilité Livrer chaque version du
du système Aucune anomalie bloquante recensée dans
système avec un
les versions diffusées auprès des utilisateurs
minimum d'anomalies
Garantir la sécurité
du système et la Utilisation et intégrité Les bases réelles ne devront pas être
Sécurité confidentialité des des données utilisées pour les tests.
informations
traitées
À chaque version, l'ensemble de la
Lisibilité, exhaustivité et
documentation technique est conforme,
cohérence de la
exhaustive et cohérente avec la version de
documentation
référence du système, avec un taux
Assurer la mainte technique associée à
maximum de 5 % par rapport à une liste de
Maintenabilité nabilité et la chaque version
contrôle.
réversibilité du
Taux de satisfaction
système Les trois quarts des personnels concernés
des équipes lors de
doivent considérer cette prestation comme
l'exécution d'opérations
correctement exécutée.
de réversibilité
Corrigibilité Garantir la réactivité Respect du délai de Livraison des versions intermédiaires selon
requise en cas de correction des délai arrêté Livraison des versions
demandes de anomalies bloquantes
semestrielles selon délai arrêté, avec [ ... ]
modification Respect du délai de
traçabilité totale entre les demandes de
livraison pour les
modification et les modifications réalisées
versions semestrielles
Efficacité ... ... ...

Convivialité ... ... ...

Conduite de projet PGI :

● Spécificité de la démarche
○ généralités
■ importance stratégique pour l'entreprise
■ impacter la gestion de tous les processus
■ représente un cout très important de manière directe ou indirecte
■ engage l'organisation sur le long terme
○ Critères de réussite
■ Bien connaitre les besoins de l'organisation
■ mener une analyse préalable
■ définir précisément les règles de gestion à mettre en place
■ définir précisément les changements organisationnels souhaitables
■ rechercher un PGI adapté aux besoins
● vérifier l'usage dans le secteur d'activité
● vérifier l'usage dans les organisations de taille et fonctionnement comparables
■ définir le paramétrage à mettre en place avec l'aide de l'intégrateur
■ mesurer les besoins d'adaptation mutuelle
○ Méthode de déploiement
 ■ Architecture Client Serveur
■ Utilisation des Bases de données relationnelles
■ modules applicatifs orientés gestion des processus opérationnels et Outils d'aide àla
décision
● Analyse du risque
○ nécessité de gérer la conduite du changement organisationnel
○ critères de mesure du risque
■ taille
■ maitrise des techniques
■ degré d'intégration
■ durée
■ stabilité de l'équipe projet

Le contenu d'un projet ERP :

« Quelles sont les principales différences entre un projet ERP et un projet de
développement classique?
Nous en citons ici les principales:
• Tout d'abord, il faudra mener une évaluation rigoureuse à la fois des besoins
de l'entreprise et de l'offre d'une première sélection de différents progiciels
présents sur le marché, et ce afin de choisir le produit.
• L'analyse des processus devra être extrêmement approfondie, car elle
permettra de définir les bases du paramétrage du progiciel. Ce paramétrage
est le cœur opérationnel du projet.
• Des équipes de paramétrage seront donc constituées, avec un profil et des
compétences spécifiques; elles intègrent souvent des consultants, l'entreprise
ne disposant pas en général d'une ressource suffisante en interne.
• La principale tâche des informaticiens sera de réaliser l'intégration du progiciel
(reprise des données pour initialiser le système, interfaces avec l'existant).
Dans certains cas, on leur demandera également de programmer des
modules complémentaires pour combler les «trous fonctionnels» du progiciel.

• Compte tenu de l'étendue des projets, une réflexion particulière doit être
accordée au déploiement: le projet ERP concerne souvent plusieurs activités
et/ou plusieurs sites (filiales). Il faudra planifier l'organisation et le rythme des
mises en œuvre.
Si l'on fait le bilan de ces différents points, il apparaît clairement que le projet ERP va
demander une plus grande implication aux utilisateurs et à leur management: ceux-ci
seront en effet leaders du projet tant dans la phase de choix du produit que dans
celle de l'analyse des processus, du paramétrage et du déploiement. Dans un projet
de développement spécifique classique, le leadership était sans conteste celui des
informaticiens; dans les nouveaux projets de développement, on peut parler d'un
partenariat étroit; mais dans les projets ERP, la responsabilité et l'effort opérationnel
basculent clairement dans le camp des utilisateurs.
 Les étapes d'un projet ERP :
Jean-Louis Tomas identifie douze phases dans l'implantation d'un ERP :

La planification revêt une importance particulière du fait de l'étendue des projets

ERP. Elle va permettre de découper le projet en étapes, tâches, livrables ,
accomplies par les différents acteurs et permet ainsi de faire le suivi du projet.
L'analyse opérationnelle correspond à l'étude des processus élémentaires et de
leur évolution.
La formation des équipes permettra d'informer et de former quatre groupes
intervenant sur le projet: le management, le comité de pilotage du projet, les équipes
de mise en œuvre (qui feront le paramétrage) et les équipes d'infrastructure
technique (informaticiens ).
L'adéquation et la configuration visent à définir comment implanter les principaux
processus dans l'ERP et à paramétrer ceux-ci afin d'obtenir un premier prototype.
Les simulations en taille réelle vont permettre aux acteurs d'affiner le paramétrage
en testant le fonctionnement, la cohérence et l'ergonomie des choix effectués.
La fermeture des trous fonctionnels pose la question des fonctionnalités non
couvertes en standard par le produit: il faudra déterminer dans quels cas l'entreprise
peut s'adapter au produit, pour éviter des modifications spécifiques et, si c'est
impossible, faire réaliser par les informaticiens des modifications spécifiques,
 compatibles avec l'ERP. Ces derniers effectueront également la création de liens
avec l'environnement, c'est-à-dire la reprise des données et les interfaces avec les
systèmes existants.
La documentation utilisateur décrit les procédures opérationnelles mises en œuvre
dans l'ERP ainsi que les modifications spécifiques éventuelles.
La formation des utilisateurs consistera à identifier des profils d'utilisation et à
organiser des sessions de formations adaptées aux besoins des différents profils.

Enfin, on pourra envisager la mise en production, qui ne sera qu'une étape avant le
déploiement sur d'autres sites ou d'autres activités ...
Au total, le projet ERP pourra s'étendre sur plusieurs mois, voire une ou deux
années. En pratique, l'entreprise devra également passer par une longue phase
d'apprentissage opérationnel afin d'intégrer le nouveau fonctionnement et de
bénéficier des avantages de l'ERP. »(in Management des SI – MH DELMOND, Y
PETIT, JM GAUTIER – Dunod 2007)

Conduite du changement :
Carte heuristique
 La conduite du changement au cœur de la réussite des projets :

L’étude d’opportunité porte aussi sur la conduite du changement

C'est le moment décisif pour se poser quelques questions comme : « Est-ce le bon
projet ? », « Peut- on réellement lui donner des garanties de réussite ? ». On
délaisse trop souvent la conduite du changement à ce stade, car le projet n’en est
encore qu’au stade de l’idée. Discuté presque uniquement en haut lieu, il souffre de
l’absence d’information des partenaires sociaux, qui empêche toute communication.
Pourtant, il s’agit d’un moment-clé pour valider les conditions réelles et concrètes qui
garantissent la réussite :
• Le projet est-il soutenu par de vrais sponsors ? Le vrai sponsor est celui qui
acceptera de le défendre dans les moments difficiles, de soutenir la direction de
projet, et de donner l’impulsion pour faire bouger l’organisation par la voie
managériale quand il le faudra.
• Lechantier conduite du changement est-il bien dimensionné ? C’est le moment de
mesurer l’énergie nécessaire à rendre effectif le changement : acteurs dédiés au sein
du projet, budgets de formation, etc. Mieux vaut ne pas attendre le déploiement pour
annoncer les coûts induits par les choix de déploiement décidés au moment du
cadrage.
Des décisions claires devront être prises en cas de réponse négative à ces deux
questions : « Je n’ai pas de sponsor ! », « Je ne dispose pas de ressources
suffisantes », voire « L’ambition du projet est démesurée et les moyens à affecter
sont disproportionnés ». La DSI jouera alors son rôle en alertant les commanditaires,
s’épargnant au passage bien des déconvenues pour la suite du projet.

Conception générale : approche des utilisateurs

Le projet est lancé. Des représentants des futurs utilisateurs sont associés à la
définition de la solution cible dont les contours se dessinent. Moment propice pour se
préoccuper des utilisateurs.
Qui sont-ils Quelles sont leurs caractéristiques au regard du changement à venir ?
Quelles sont leurs aptitudes à vivre positivement ce changement ? Quelles sont leurs
attitudes pressenties ?
Le chef de projet est particulièrement bien placé pour réaliser (ou tout du moins
superviser) cette étude, qui demande une bonne connaissance de la solution cible.
Au vu de cette étude, il veillera à réaliser les bonnes actions de communication pour
amener le futur utilisateur d’une attitude d’indifférence à l’égard du projet à une
attitude contributive au moment du déploiement.
Durant cette phase, le chef de projet constitue le réseau d’alliés qui prendront le
relais pour assurer la promotion du projet dans les moments-clés.

Conception détaillée/recette : mise en place des formations

Dès que le projet devient concret (fonctionnalités, ergonomie, etc.) il est temps de se
préoccuper de la préparation du déploiement : Qui faudra-t-il former et comment ?
(e-learning ? présentiel ? mix ?). Qui faudra-t-il accompagner et comment ?
(utilisateurs clés, support déploiement). La valeur ajoutée de la DSI à ce stade est en
particulier la maitrise des outils à mettre à disposition du projet : réalisation de
modules e-learning, mise à disposition d’outils collaboratifs pour renforcer les liens
entre le projet central et les relais locaux...

Déploiement : vigilance et ajustements

Le chef de projet est payé de ses efforts d’anticipation en matière de conduite du
changement : son plan de déploiement lui permet de synchroniser l’ensemble des
actions techniques et d’accompagnement afin de minimiser les perturbations
opérationnelles.
Tout n’est pas gagné pour autant : il reste attentif aux signaux du terrain et est en
mesure d’adapter son dispositif pour répondre aux aléas. Il est particulièrement
visible à ce stade que la conduite du changement est partie intégrante de la gestion
de projet.

Stabilisation, atteinte de la performance et fin de projet: passer le relai

Le projet n’est pas fini le jour du déploiement. La fin de l’accompagnement resserré
peut coïncider avec la phase de vérification de service régulier avant le passage en
maintenance.
Lorsque l’utilisation du SI devient nominale, le chef de projet veille à transmettre le
sujet aux équipes pérennes : passage du support au helpdesk, des formations des
nouveaux arrivants à la DRH, etc.