Vous êtes sur la page 1sur 29

UNIVERSITE FELIX HOUPHOUET-BOIGNY

COCODY ABIDJAN REPUBLIQUE DE CTE DIVOIRE


UNION DISCIPLINE TRAVAIL

MINISTERE DE LENSEIGNEMENT SUPERIEUR ET DE LA


RECHERCHE SCIENTIFIQUE

UFR DES SCIENCES ECONOMIQUES ET DE GESTION

MASTER 1 DES SCIENCES DE GESTION

UE : Management des Systmes dinformation


ECUE 1 : Gestion des projets en SI

Professeur : M. YEO Yaya


Charg de Cours en informatique
Gestion des projets en systmes dinformation

Gestion des projets en SI

CHAPITRE 1 : STRUCTURATION DES SYSTEMES DINFORMATION

I) Position de la fonction informatique au sein de lentreprise


1) Le cas des grandes organisations
1.1. Lexistence dun service informatique interne
Le service informatique interne est charg dintervenir dans le cadre des problmes de toutes natures,
relatifs linformatique.
Le primtre de comptence et daction est le suivant :
- Le dveloppement des applications informatiques ;
- La matrise des moyens techniques (serveurs, postes clients, systmes dexploitation, rseaux
et moyens de communication, logiciels outils, etc) ;
- La qualit des services offerts.
1.2. Lorganisation du service informatique
Lorganisation est davoir une quipe par nature de service rendre donc par spcialit technique.
Aussi on a :
- Une quipe systme,
- Une quipe bases de donnes,
- Une quipe rseau et communication,
- Une quipe dveloppement,
- Une quipe maintenance informatique,
- Une quipe progicielle
1.3. La tendance lexternalisation des services informatiques
Pour mieux matriser les cots et le niveau de qualit des services rendus, les grandes entreprises ont
tendance externaliser tout ou partie des services informatiques.

2) Le cas des petites entreprises


2.1 Le recours aux services externes
Compte tenu de leur taille, ces entreprises ne peuvent pas se permettre davoir un service informatique
interne. Pour cela, elles vont devoir faire appel des services externes.
Toute fois, certaines peuvent avoir au sein de leurs personnels des salaris ayant une formation en
informatique.

1
Gestion des projets en systmes dinformation

2.2 Limpact de labsence de comptences internes


Confier son informatique des comptences extrieures entraine des cots difficilement supportables
pour ces petites organisations et une dpendance vis--vis de celles-ci. De plus les solutions proposes
par ces fournisseurs ne sont pas souvent adaptes leurs besoins.

II) Stratgie informatique


1) Relation entre la stratgie de lorganisation et la stratgie
informatique
Toute dcision stratgique va entrainer un besoin dvolution du systme dinformation. Si ce besoin
nest pas satisfait, au lieu dtre un facteur cl de succs dans la mise en uvre de la stratgie, le SI
deviendra un facteur dchec. Cependant la mise en uvre des dcisions stratgiques nest pas
immdiate ; elle se fait dans le temps et de faon ordonne selon un plan bien dfini appel plan
directeur ou schma directeur.

2) Notion de schma directeur


2.1 Dfinition
Le Schma Directeur (SD) dfinit le cadre gnral du dveloppement des SI principalement en termes
dobjectifs et de contraintes. Il dcrit la politique et orientations fondamentales de linformatique de
lentreprise pour les annes venir.
2.2 Objectifs
Lobjectif est de produire un plan de dveloppement court et moyen terme (3 7 ans). Il sagit de
dfinir les axes dvolution du SI ncessaires la cohrence avec la stratgie.
2.3 Rle
Le SD est rdig et propos la direction gnrale par la direction des SI et la direction informatique,
au vu des dcisions stratgiques prises.
Une fois approuv, il servira de repre au comit de pilotage des projets, afin de raliser lensemble
des projets quil contient, dans les conditions prvues.
2.4 Mise en uvre du SD
La ralisation des projets inclus dans le SD va suivre la mthodologie classique de la conduite de
projet. Cela implique le respect des contraintes de types budgtaires et de planning.
Cette mise en uvre va subir les alas de lavancement de la mise en uvre des dcisions elles-
mmes. Do un perptuel rajustement du SD en fonction des dcisions stratgiques.

2
Gestion des projets en systmes dinformation

CHAPITRE 2: ARCHITECTURE TECHNIQUE


Une approche de solution aux problmes mentionns passe par une meilleure organisation du SI qui
doit devenir plus intgr, mais aussi plus volutif. Ceci ncessite tout dabord ladoption de systmes
ouverts, obissant des standards permettant le choix dun grand nombre de produits sur le march.
Il faut donc tout prix viter les solutions senfermant sur un constructeur ou des dveloppements
maison ignorant les standards, solutions propritaires qui risquent terme de limiter les choix et la
concurrence des fournisseurs, et donc daugmenter les cots.

I) Structure technique des outils informatiques


1) Le serveur
1.1 Architecture matrielle
Un serveur est un ordinateur qui permet le partage de ressources entre utilisateurs.
a) Lordinateur central ou mainframe
Terme utilis lorigine de linformatique. Un ordinateur occupait un espace important et
pouvait peser 30 tonnes. Ces gros systmes sont galement caractriss par le fait quil sagit
de systmes propritaires (par opposition aux systmes standards).
b) Micro-ordinateur
Ordinateur de dimension rduite dont lunit centrale est constitue dun ou de plusieurs
microprocesseurs.
Il est galement caractris par son caractre standard qui permet de voir le mme type
dordinateur chez des fabricants diffrents faisant ainsi jouer la concurrence sur les prix pour
le mme usage.
1.2 Architecture logicielle
Un serveur, au sens informatique, est un ordinateur et/ou un logiciel, dont le but est de rendre des
services dautres ordinateurs ou logiciels connects laide dun rseau.
1.3 Lusage et lapplication fonctionnels
Suivant les services rendus, il existe plusieurs types de serveurs.
a) Le serveur de fichiers
Un serveur de fichiers possde une capacit de stockage importante. Il sert dposer la fois
des documents simples de type texte non structur, des documents complexes regroupant la
fois du texte, des images, des objets encapsuls (un document traitement de texte contenant
une feuille de calculs issue dun tableur, par exemple).
b) Le serveur de bases de donnes
Cest la version amliore du serveur de fichiers.
En plus du service de stockage, il fournit une logique applicative permettant dorganiser les

3
Gestion des projets en systmes dinformation

donnes et de les exploiter de manire plus efficace et performante.


Le logiciel de gestion de bases de donnes assure :
- Lorganisation des donnes ;
- Leur stockage ;
- Laccs aux donnes ;
- Leur scurit.

c) Le serveur dapplications
Ce serveur stocke des programmes conus spcialement pour grer un problme donn. Ces
programmes permettent denrichir et dexploiter une base de donnes.

d) Le serveur Web
Ce serveur stocke des programmes conus en HTML appels pages web. Lensemble de
plusieurs pages web traitant dun mme sujet est appel site web.

e) Le serveur dimpression
Ce serveur permet le partage dune imprimante entre plusieurs utilisateurs.

2) La base de donnes
Une base de donnes est un ensemble structur dinformations, stock sur une mmoire de masse,
disposant dun logiciel spcialis dans lorganisation et la gestion des donnes, la scurit des
donnes, ainsi que dans le contrle des accs concurrents.
2.1 Les fichiers
Les fichiers constituent une organisation de donnes qui historiquement existaient avant lapparition
des bases de donnes.
Laccs une information se fait de faon squentielle (lire toutes les informations qui prcdent
linformation recherche) ou de faon indexe (accs directe linformation recherche).
2.2 Les bases de donnes hirarchiques
Une base de donnes hirarchique est organise en arborescence. Un lment peut avoir plusieurs
descendants, mais il ne possde quun seul ascendant. On est en prsence de relation de type 1:N
(relation pre-fils).
2.3 Les bases de donnes rseaux
Dans ce type de base de donnes, il est possible de crer des liens entre tous les objets. Il autorise
lexistence de plusieurs liens entre deux entits. Le rsultat final est un graphe quelconque.
On gre les liens de type N:M.

4
Gestion des projets en systmes dinformation

2.4 Les bases de donnes relationnelles


Le modle relationnel fournit une reprsentation des donnes sous forme matricielle. Les donnes sont
stockes dans des tables deux dimensions o les colonnes reprsentent les domaines (champs) et les
lignes reprsentent les n uplets (tuples ou enregistrements).
En algbre relationnelle, on dira quune table est une relation.

Exemple : la relation employe


Employe (matricule, nom, prenom, date_emb, date_naiss)

Dans le modle relationnel, les proprits sont subordonnes une proprit particulire appele
identifiant ou cl primaire. Cette cl permet didentifier un et un seul enregistrement ce qui permet
dviter les redondances.

Exemple : matricule dans la relation Employe

2.5 Les bases de donnes objets


Ici les informations sont stockes sous forme dobjets incluant la fois les donnes et les traitements.

3) Le poste client
3.1 Le client lourd ou client de gestion
Ce terme dsigne une application cliente graphique excute sur le systme dexploitation de
lutilisateur (poste utilisateur). Un client lourd possde des capacits de traitement volues et une
interface graphique sophistique.
3.2 Le client lger
Ce terme fait rfrence deux technologies totalement diffrentes.
Dans un cas la logique de prsentation de lapplication sappuie exclusivement sur une interface web.
Dans lautre cas, on utilise un logiciel client ddi, sexcutant soit dans une machine de type pc
reconvertie en terminal, soit dans une machine de type terminal ddi.

4) Le systme dexploitation
Le systme dexploitation est le logiciel de base de lordinateur. Il constitue une interface entre le
matriel et les logiciels applicatifs.

5
Gestion des projets en systmes dinformation

II) Structures types de dploiement


1) Dploiement client serveur
Le dploiement client/serveur consiste mettre disposition des postes clients les applications
oprationnelles auxquelles ils ont accs.
Dans ce mode de fonctionnement o le client se compose dun poste de travail autonome (un
ordinateur et non un terminal passif), la mise disposition dune application doit se faire par la
distribution des excutables sur les postes des utilisateurs.

2) Utilisation dun serveur dapplication


Ici le systme fonctionne en sparant le lieu dexcution de lapplication du lieu de prsentation. Les
excutables sont tous installs sur un seul poste, le serveur.
Les postes clients disposent de raccourcis pointant sur le serveur dapplication.

3) Recours au middleware (mdiateur)


Le middleware est une couche logicielle dont le but est dassurer le dialogue entre le client et le
serveur dans des environnements htrognes.

Exemple : le pilote ODBC est un middleware, il constitue une interface pour se connecter une base
de donnes, il permet de transmettre des requtes au moteur de la base de donnes et de rcuprer les
rponses pour les clients.

4) Utilisation du transactionnel
Le transactionnel permet de crer un niveau de fiabilit et dabstraction suffisant au regard de la
complexit croissante de dploiement des applications oprationnelles.
La phase de distribution des composants dune application est une phase critique en matire de
dploiement ; elle doit se faire en un tout ou rien.
Si pour une raison quelconque cette phase naboutit pas, elle peut laisser lapplication dans un tat
totalement instable.

5) Mode de dploiement n-tiers


Avant darriver des architectures multi tiers (n-tiers), revoyons les diffrentes tapes.
5.1 Architecture un tiers
Dans cette architecture, le client est un terminal passif. Le serveur prend en charge la totalit du
dploiement : la gestion des donnes, lexcution des traitements et la prsentation des rsultats. Le
client ne fait quafficher.

6
Gestion des projets en systmes dinformation

5.2 Architecture deux-tiers


Le client prend en charge la partie traitement et la partie prsentation de lapplication.
Le serveur assure la gestion des donnes.
Le client et le serveur dialoguent travers un middleware. Ici le client rpond aux normes dun client
intelligent.
Cette architecture a t beaucoup utilise et reste encore dactualit.
5.3 Larchitecture trois-tiers
Cette architecture permet la sparation complte des donnes, des traitements et de la prsentation.
Ici on retrouve un serveur de donnes, un serveur dapplication et le client qui se charge de la
prsentation.
Internet et le web reprsentent galement une architecture de type trois tiers. La partie prsentation est
dvolue au poste client au travers dun logiciel spcialis, le navigateur. Ce dernier communique avec
le serveur web au travers du protocole http.
La gestion des donnes est confie un serveur de bases de donnes.
5.4 Larchitecture n-tiers
Il ne sagit pas de multiplier les niveaux de services, mais de repartir lapplication sur de multiples
fournisseurs de services.

Exemple : la base de donnes peut tre hberge par deux serveurs diffrents.

6) Utilisation dun portail ou dun espace numrique de travail


Les espaces numriques de travail (ENT) sont des sites web portail permettant daccder, via un point
dentre unique et scuris, un bouquet de services numriques. Ils peuvent tre mis en uvre dans
les tablissements scolaires ou entreprises.

Exemple : Office 365 anciennement Live@edu de Microsoft


Cet espace est compos :

- dune messagerie,
- dun gestionnaire de calendrier,
- dun gestionnaire de tches,
- doutils office,
- de skydrive

7
Gestion des projets en systmes dinformation

CHAPITRE 3 : LA CONDUITE ET LA GESTION DE PROJET


I) Principes gnraux de la gestion de projets
1) Dfinition dun projet
Un projet est la mise en uvre coordonne dun ensemble de moyens pour atteindre un but prcis,
dans un dlai fix, et un cot fix.

Un projet est lensemble dactions qui concourent la ralisation dun objectif unique et mesurable.
Unique : atteint une fois et dfinitivement.
Mesurable : dterminer chaque instant sil est atteint ou pas.

2) Naissance dun projet


Un projet nait suite :
- Lexpression dun besoin ;
- La confrontation un problme donn
Un projet nait aussi linitiative des :
- Dcideurs ;
- Cadres suprieurs ;
- Chefs de services ;
- Informaticiens ;
- Pressions extrieures.

3) Intervenants dans un projet


La ralisation dun projet informatique requiert lintervention dun ensemble de partenaires,
appartenant les uns la matrise douvrage, et les autres la matrise duvre. La participation de ces
intervenants aux diffrentes phases de projet doit tre organise afin dutiliser au mieux les
comptences de chacun, dviter toute perte dnergie et de minimiser les facteurs de risques.
Les acteurs habituels dun projet informatique sont :
- Le chef de projet (organisateur du projet) ;
- Le responsable qualit de projet ;
- Ladministrateur de donnes ;
- Les consultants ;
- Les experts ;
- Une quipe danalystes programmeurs ;
- Des exploitants informatiques ;
- Des reprsentants de la matrise douvrage : directeurs, spcialistes mtiers, experts juridiques.

8
Gestion des projets en systmes dinformation

Prestataires
Consultants extrieurs
Experts

Direction de projet

- Chef de projet
- Responsable
qualit

Organisation
Informatique

- Analystes programmeurs
UTILISATEUR - Administrateurs de
donnes
- directeurs
- Techniciens
- spcialistes mtiers
- exploitants
- utilisateurs du
systme actuel

ENTREPRISE

Consultants Experts
Prestataires
extrieurs

LE POSITIONNEMENT DES INTERVENANTS HABITUELS DUN PROJET


INFORMATIQUE

4) Organisation dun projet


Lorganisation et le suivi du projet ncessitent en outre la mise en place de structures de travail, de
coordination et de dcision entre la matrise duvre et la matrise douvrage. Il sagit des trois
comits suivants :
- Le comit de direction ;
- Le comit de pilotage ;
9
Gestion des projets en systmes dinformation

- Le comit utilisateur
a) Le comit de direction
Il a en charge :
- La dfinition des axes du projet
- Les choix stratgiques et structurants
- La validation des travaux raliss
- Le suivi et la gestion des carts
Cela pour sassurer de la cohrence des projets entre eux et de leur conformit aux axes de
dveloppement de lorganisation.

b) Le comit de pilotage
Cest le contrleur du projet.
Il a en charge :
- Lorganisation interne du projet (tche du chef de projet) ;
- Le suivi de lavancement des travaux ;
- La coordination des intervenants ;
- Lanalyse et le suivi des risques
Le contrle va porter la fois sur latteinte de lobjectif et sur les conditions de la ralisation du projet,
en termes de dlais, de cots et de qualit du rsultat, par rapport au cahier des charges.

c) Le comit utilisateur
Ce comit a en charge :
- La formalisation des besoins utilisateurs ;
- La prparation des choix et arbitrages pour le comit de direction ;
- La prparation de la mise en uvre.

d) Le chef de projet
Il a en charge la conduite et la gestion de projet.
- Le terme conduire un projet fait rfrence au parcours dun chemin, jalonn dun
enchanement logique et chronologique de tches accomplir pour atteindre lobjectif. Cela
correspond essentiellement aux proccupations de planification de projet.
- Grer un projet correspond un aspect plus conomique du rle du chef de projet. Il sagira de
respecter les cots relatifs la ralisation du projet et de vrifier la qualit du rsultat obtenu
par rapport au cahier des charges.
Le chef de projet dirige le groupe de projet compos des informaticiens et non informaticiens
participant la ralisation du projet.

10
Gestion des projets en systmes dinformation

5) Les tapes de la conduite dun projet


Afin dassurer le succs du projet et dviter lorganisation de gaspiller ses ressources, il est
ncessaire de respecter un enchainement dtapes dans la conduite de projet, et des jalons, ou points de
dcisions, afin de choisir entre la poursuite et larrt du projet.

a) Etude prliminaire
Elle a pour but de sassurer quil existe bien un objectif atteindre permettant de satisfaire un besoin.
Elle consiste faire un tat des lieux, c'est--dire :
- A dterminer lobjectif du projet et sassurer dun besoin satisfaire ;
- A fixer le point de dpart, c'est--dire la situation actuelle dans le domaine ;
- A fixer le point darrive, c'est--dire le niveau de rsultat atteindre.

b) Ltude de faisabilit et de rentabilit


Cette phase a pour but de sassurer quil existe des solutions techniques pour rsoudre le problme et
quelles sont conomiquement viables. Il sagit de rechercher les diffrentes solutions possibles en
mesure de satisfaire le besoin de lutilisateur. Ensuite de vrifier que les ressources prvues pour le
projet sont compatibles avec lune des solutions techniques proposes. Les solutions techniques
proposes doivent tre sociologiquement, psychologiquement, moralement et politiquement
acceptables dans le contexte.
Le deuxime jalon permet au comit de direction de choisir, parmi les solutions possibles ventuelles,
celle qui lui parait la plus pertinente et la plus efficiente, au moment o il prend sa dcision. Cette
dcision sera prise partir du dossier dorientation ralis et prsent par le chef de projet.

c) La dfinition du projet
Cette tape a pour but :
- La dtermination des rsultats partiels (intermdiaires) ;
- La dtermination des ressources mettre en uvre ;
- La dtermination de leurs cots dobtention et de leur planification.
Elle consiste dcomposer le projet selon trois domaines :
- La planification du projet, qui permet de dfinir les dlais de ralisation des tches.
- Les ressources ncessaires la ralisation des tches et leur cot dobtention (budget
prvisionnel) ;
- La nature des rsultats attendus sous la forme dun cahier des charges fonctionnel.
La ralisation de cette troisime tape ncessite lutilisation doutils de dcomposition cartsienne,
pour dterminer :
Les rsultats partiels obtenir ;
Les tches effectuer pour les obtenir ;
11
Gestion des projets en systmes dinformation

Les ressources et les cots ncessaires.


Cela permet dviter les omissions, les retards, les dpassements de budget et les dfauts du rsultat
obtenu.

d) La ralisation du projet
Lobjectif est dexcuter lensemble des actions (tches) permettant dobtenir le rsultat attendu. Il
sagit daffecter chaque tche pour sa ralisation, une comptence interne ou externe.
Cette phase est la phase critique dun projet. Pour la russir, le chef de projet doit faire preuve de
comptences en termes de relations humaines, de gestion et de planification de projet.

e) Phase de mise en uvre et de maintien hors service


Lensemble des oprations mettre en uvre pour sassurer sur le plan interne et sur le plan
environnemental, du point de vue conomique et social, que la mise hors service ne cre pas de
nuisance et de perturbation. Ces oprations ont un cot dont il faut tenir compte lors de ltude de
faisabilit.

II) Rdaction du cahier des charges fonctionnel


1) La rdaction de lanalyse fonctionnelle
1.1 Principes
Dans trois cas sur quatre, les utilisateurs se dclarent insatisfaits des produits et services quils
utilisent. Ils attribuent leur insatisfaction des lacunes fonctionnelles.
Pour rsoudre ce problme, il faut rdiger un cahier des charges fonctionnel.

a) Catgories de fonctions
Les deux catgories essentielles sont les fonctions principales et secondaires dusage.
Les fonctions principales dusage sont celles qui crent les rsultats attendus dans le domaine
concern. Elles permettent de rpondre la question quoi c'est--dire la nature des rsultats que
lon peut attendre de lusage du produit ou du service.
Les fonctions secondaires dusage expriment la manire dobtenir le rsultat. Elles rpondent la
question comment c'est--dire apportent des informations sur la manire dobtenir les rsultats.

b) Spcificit des fonctions secondaires


En matire de fonctions secondaires on pourrait retenir les aspects suivants :
Lergonomie
Il sagit dadapter le poste de travail ltre humain qui loccupe.

12
Gestion des projets en systmes dinformation

Lergonomie au travail a pour but dviter les fatigues inutiles de lhomme dans lexercice de son
travail. Il sagit des fatigues visuelles et intellectuelles.
Pour la fatigue visuelle on privilgie dans les logiciels des crans o les informations sont facilement
lisibles et reprables ; donc bien contrastes. On vitera aussi les couleurs agressives lil.
En ce qui concerne la fatigue intellectuelle, on vitera dobliger lutilisateur chercher comment
obtenir un rsultat ou mmoriser des informations inutiles.
La convivialit
Il sagit de la facilit dutilisation dun logiciel.
Il faut aider lutilisateur dans ses manipulations grce :
A laide en ligne ;
Aux listes de valeurs disponibles pour les codes et objets du systme, accessibles par les
libells ;
Au respect dans le logiciel de la vision mtier de lutilisateur.
La navigation
Il sagit de permettre lutilisateur de naviguer dans ses donnes de manire naturelle sans avoir
quitter laction entreprise.
Exemple : un mdecin qui utilise son cran de consultation doit pouvoir saisir les informations dun
patient sans pour autant quitter lcran de consultation.

c) Types danalyses fonctionnelles


- Lanalyse fonctionnelle externe
Elle est pratique par la matrise douvrage. Elle exprime le besoin et constitue le point de vue de la
demande.
- Lanalyse fonctionnelle interne
Elle est pratique par la matrise duvre. Elle exprime la recherche de solutions techniques
permettant de formuler un produit ou un service apte satisfaire le besoin de la matrise douvrage.
Elle constitue le point de vue de loffre.

1.2 La mise en uvre de la mthode danalyse fonctionnelle externe


a) analyse de lexistant
Lanalyse de lexistant va permettre de reprer les lments positifs, que lon souhaite conserver, mais
galement de lister les dfauts et les lacunes de la solution actuelle.

b) analyse des offres sur le march


Il sagit de collecter les informations concernant les produits existant sur le march.
Il existe de nombreuses sources dinformation, notamment Internet, mais il faut se mfier des
informations caractre commercial, qui manent des crateurs de logiciels.
13
Gestion des projets en systmes dinformation

Lanalyse des avantages et des inconvnients prsents par les utilisateurs dun organisme utilisant
dj le produit, permet la matrise douvrage de mieux cerner ladquation dun outil par rapport
ses propres besoins.
Il y a aussi de nombreux salons qui permettent de collecter des informations sur les produits.

1.3 Prsentation de lanalyse fonctionnelle et rdaction du cahier des charges

1 : utile
2 : ncessaire
Fonction
3 : important F0 : nulle
principale,
4 : trs important F1 : faible
secondaire,
5 : vital F2 : bonne
technique
F3 : forte

Type de Numro Fonction Caractre Niveau Classe de


fonction impratif atteindre flexibilit

Description Description
prcise de la du niveau
fonction attendu

Tableau danalyse fonctionnelle

Ce modle de tableau va tre utilis de deux faons :

a) Il servira de base la rdaction du cahier des charges fonctionnel


Il faut renoncer lide quun cahier des charges puisse exprimer en totalit le besoin satisfaire.
La premire raison est lie lincapacit exprimer la totalit de sa pense en lexprimant travers un
crit.
La seconde raison est lie aux filtres que le destinataire va mettre de manire inconsciente, dans le
dcodage du message. Entrainant ainsi malgr lui des faux-sens et des contresens.
Le cahier des charges peut nanmoins prsenter, avec rigueur et prcision, lessentiel de lexpression
du besoin. Lobjectif nest pas dobtenir de nombreuses offres, mais des offres bien cibles par rapport
au besoin exprim.

14
Gestion des projets en systmes dinformation

Rdiger un cahier des charges aprs llaboration dun tableau danalyse fonctionnelle est trs ais.
Pour la ralisation du tableau, on pratique une dmarche intellectuelle danalyse, laide de fils
conducteurs permettant dobtenir une certaine exhaustivit.
Pour la rdaction du cahier des charges on utilise une dmarche de synthse, permettant dclairer le
contexte global de lexpression des besoins et reliant les fonctions attendues, exprimes de manire
ponctuelle dans le tableau prcdent.

b) Le tableau danalyse fonctionnelle servira galement lors du dpouillement des rponses


lappel doffre.
Le tableau permettra de slectionner les offres en pointant la prsence et le niveau des fonctions
attendues dans les diffrentes offres reues.
La premire colonne permettra de classifier les fonctions par type ;
La seconde permettra de les numroter, afin de les rfrer plus facilement ;
La troisime colonne permettra de dfinir le contenu de la fonction, par un descriptif prcis du
rsultat attendu.
Le caractre impratif permettra de prciser si lon peut se passer ou non de cette fonction
dans la solution qui sera retenue ;
Le niveau atteint permet de prciser la manire de raliser cette fonction et le niveau
dapprofondissement de la solution recherche, c'est--dire de prciser lexpression du besoin.
La classe de flexibilit permet de dfinir la flexibilit dune fonction par rapport son cot
dobtention.

1.4 La rdaction du cahier des charges


Le cahier des charges doit permettre aux destinataires qui le liront, de comprendre le contexte de
lexpression du besoin et doit leur offrir une vision globale et cohrente de la problmatique de la
matrise douvrage.

Les risques viter dans la rdaction du cahier des charges

Type de risque Caractristique


Inversion des rles Confondre matrise douvrage et matrise
duvre
Confusion analyse fonctionnelle interne et Confondre expression du besoin et solutions
externe techniques
Confusion entre contraintes techniques et Les contraintes simposent car elles sont lies au
environnementales et choix techniques contexte, les choix sont rducteurs.

15
Gestion des projets en systmes dinformation

a) Le premier risque consiste inverser les rles


Cela arrive frquemment, lorsque le cahier des charges est rdig par le service informatique de
lorganisation et non par les utilisateurs. On confond alors un rle dassistance matrise douvrage,
que peut tenir le service informatique, et le rle de la matrise douvrage.

b) Le deuxime risque consiste confondre expression du besoin et solution technique mettre


en uvre pour le satisfaire
Dans la rdaction dun cahier des charges, la matrise douvrage a pour mission dexprimer son besoin
la matrise duvre, le plus prcisment et le plus clairement possible.

c) Le troisime risque consiste confondre contraintes environnementales et contraintes


techniques avec les fonctions techniques
Il ne faut pas tendre les prescriptions techniques des domaines non impratifs. Cela entrainerait un
appauvrissement de la rponse aux appels doffres.

2) La gestion des appels doffres


a) Le choix des destinataires
- Le cas des marchs de gr gr
Il faut choisir les destinataires de lappel doffre auxquels sera transmis le cahier des charges.

- Le cas des marchs publics


Il est ncessaire dadapter une dmarche trs prcise avec des procdures diffrentes suivant le
montant et la nature du march.

b) Le dpouillement des rponses aux appels doffres


- Le cas des offres de progiciels
On cochera les fonctions prsentes dans le produit propos par rapport celles attendues dans
le tableau. On veillera ce quaucune fonction caractre impratif ou trs importante ne soit
absente dune solution, qui retiendra lattention. Toute solution ne rpondant pas cette
exigence sera rejete.

- Le cas des logiciels spcifiques


Toutes les fonctions du cahier des charges doivent se retrouver dans le produit propos.
Nanmoins, il est possible que les offres reues dpassent le budget octroy pour la ralisation
du logiciel. Dans ce cas la colonne de flexibilit au cot permettra de trancher et dliminer
toutes les fonctions plus ou moins couteuses.

16
Gestion des projets en systmes dinformation

CHAPITRE 4 : LIMPLANTATION DU SYSTEME DINFORMATION


I) Mise en place dun systme
1) Mthodologie de tests et recettes
1.1 Les tests unitaires
Ils permettent de valider le fonctionnement des programmes, voire de chaque procdure, considre
individuellement. Ce type de tests est ralis par les informaticiens.

1.2 Les tests dintgration


Ces tests permettent de valider lenchanement des traitements au sein dun mme module applicatif.
Ils permettent aussi de valider linteraction des traitements entre deux modules applicatifs diffrents.

1.3 Les tests de non rgression


Il sagit de vrifier que des modifications effectues pour corriger des dysfonctionnements
dexploitation, ne provoquent pas des effets indsirables sur des parties de lapplication, qui
fonctionneraient correctement antrieurement.

1.4 Les tests fonctionnels


Il sagit de vrifier que les rsultats des traitements raliss par le programme sont conformes aux
rsultats attendus.

1.5 La recette du logiciel par les utilisateurs


Cest la rception du chantier.
Elle permet la matrise douvrage de faire valider :
- La conformit de la nature et de la qualit des rsultats obtenus, par rapport aux besoins
exprims ;
- La conformit des rsultats quant la manire de les obtenir, en terme de procdures comme
dergonomie ;
- La compltude des fonctions fournies, par rapport aux attentes.

2) Gestion de la comptence des utilisateurs


La mise en place de tout nouveau systme entraine une modification des habitudes et des mthodes de
travail. Il appartient lorganisation de mettre en uvre les mesures ncessaires au maintien de la
comptence des salaris.
Pour cela, il est ncessaire :
- danalyser la transformation induite des postes de travail, concerns par la mise en place du
systme ;

17
Gestion des projets en systmes dinformation

- de comparer les comptences, requises par les nouveaux profils de postes, avec celles
possdes par les titulaires de ces postes ;
- de dfinir et de mettre en uvre un plan de formation permettant, le cas chant, dadapter la
personne son nouveau profil de poste ;
- ventuellement, denvisager le changement de titulaire du poste. Ceci implique la recherche de
reclassement de la personne prcdente et la recherche du recrutement ou de la promotion
interne dun nouveau salari.

3) Conduite du changement organisationnel


La modification des habitudes de travail, qui dcoule de la mise en place dun nouveau systme,
entraine des peurs, sur lesquelles se fonde le risque de rsistance au changement.
Ces peurs sont lies au passage dune situation connue et matrise par les acteurs du systme, une
situation nouvelle, donc inconnue.
Cela leur laisse entrevoir la possibilit :
- dtre incapable de sadapter la nouvelle situation, donc de risquer dtre destitu (perte de
son emploi) ;
- ou de devoir partager certaines informations, donc de perdre du pouvoir.

Lors de la mise en place dun systme, il est donc absolument ncessaire danalyser les facteurs de
risques de rsistance au changement.
La conduite du changement organisationnel requiert du manager un certain nombre de qualits :
lempathie1, lui permettant de comprendre le mode de comportement et de raisonnement
dautrui ;
la capacit valuer les facteurs de risque de rsistance au changement ;
la capacit construire un argumentaire efficace pour viter ces risques ;
la capacit grer la dynamique dun groupe, qui doit lui permettre de grer lvolution des
rles dans le groupe tout en stabilisant ltat des relations humaines au sein du groupe.

II) Cycle de vie du projet


1) Les phases du cycle de vie
Une fois le choix de la solution effectu, le projet va connaitre les phases de vie habituelles de tout
projet. La phase dans laquelle on se trouve, aprs le choix de la solution, est fonction du choix entre
progiciel et logiciel spcifique.

1
Mcanisme par lequel un individu peut comprendre les sentiments et les motions dune autre personne.
18
Gestion des projets en systmes dinformation

Type de solution Phase du cycle de vie


1) Mise en place ou dploiement
2) Croissance ou exploitation
Progiciel
3) Maintenance ou maturit
4) Mise hors service ou dclin
1) Dveloppement de la solution
2) Mise en place ou dploiement
Logiciel spcifique 3) Croissance ou exploitation
4) Maintenance ou maturit
5) Mise hors service ou dclin

2) Les diffrents types de maintenance


2.1 La maintenance corrective
Elle a pour but dassurer la correction des vices cachs du systme. Ces dysfonctionnements peuvent
apparatre au moment de la mise en place du systme, mais galement dans la dure dutilisation de
celui-ci.
Pour matriser le risque li lapparition, en cours dexploitation, dun dysfonctionnement, la
souscription dun contrat de maintenance corrective est ncessaire. Celui-ci permettra lorganisation
daccder la correction des problmes rencontrs, sous conditions contractuelles, notamment en
termes de dlai, et moyennant un cot fixe.

2.2 La maintenance volutive


La mise en place dun nouveau systme implique une utilisation longue dans le temps, en moyenne
une dizaine dannes. Or lexpression des besoins ne peut tre ni finie, ni stable trs longtemps. Le
logiciel devra donc voluer pendant sa dure dutilisation, de manire sadapter lvolution des
besoins.
En labsence dun contrat de maintenance volutive, lorganisation court un risque dont elle ne peut
pas mesurer lampleur.
a) Soit elle se retrouvera avec un logiciel :
- au mieux, inoprant dans certaines situations ;
- au pire, inutilisable
b) soit elle devra investir :
- dans un nouveau produit ;
- ou dans une nouvelle version de son logiciel, un cot inconnu priori.
Il est donc prudent, dans la mesure du possible, de souscrire un contrat de maintenance volutive.

19
Gestion des projets en systmes dinformation

III) Gestion de la qualit en matire de SI


La qualit en matire de SI obit plusieurs principes tirs de la norme ISO 9000 :

a) Premier principe : orientation client


Recherche permanente de la satisfaction du client et de lamlioration continue de celle-ci.

b) Deuxime principe : leadership de la direction


Pour que la qualit soit la proccupation de tous au sein de lorganisation, la direction doit
dmontrer un engagement fort et permanent.

c) Troisime principe : implication du personnel


La qualit est laffaire de tous, elle repose sur la volont de progrs permanent de chacun. Chaque
personne doit tre comptente dans son poste de travail.
Cela signifie :
- Possder les connaissances ncessaires son action ;
- Possder les bonnes pratiques c'est--dire le savoir faire requis ;
- Possder les comportements adapts aux situations inhrentes au poste de travail.

d) Quatrime principe : approche processus


Les actions entreprises pour tre efficace ne doivent pas tre considres de manire isole, mais
sintgrer dans le cadre dun processus modlis et audit.
Un processus est une succession de tches ayant un vnement dclencheur et un objectif.

e) Cinquime principe : amlioration continue


Lamlioration de la qualit est une dmarche continue de progrs quotidiens raliss par tous.

f) Sixime principe : approche factuelle pour la prise de dcision


La prise de dcision sappuie sur une analyse des problmes rels et une modlisation des
solutions possibles.

g) Septime principe : relations mutuellement bnfiques avec les fournisseurs


Instaurer une relation de confiance base sur un march gagnant-gagnant , au lieu dune
relation de mfiance base sur la recherche du prix le plus bas.

20
Gestion des projets en systmes dinformation

IV) Gestion des risques


Tout projet dimplantation de systme dinformation prsente des risques. La matrise de ces
risques est donc ncessaire pour la russite du projet.

1) Mthodologie danalyse du risque


En matire de systme dinformation, le risque dun projet se mesure selon les critres suivants :
- La taille du projet ;
- Le degr dintgration ;
- La difficult technique ;
- La dure ;
- La stabilit de lquipe projet

La taille du projet
Plus la taille du projet est importante, plus un grand nombre dacteurs de lorganisation est
concern. Il a donc plus de probabilit de dsorganiser lensemble de la structure.

Le degr dintgration
Le degr dintgration se mesure par le nombre et la complexit des modules oprationnels qui
doivent interagir avec le SI. Plus ce nombre est important, plus le degr dintgration sera
difficile mettre en place car il faudra :
Tester et rceptionner toutes les interactions ;
Mener des analyses dimpact ;
Contrler les ventuelles rgressions sur les lments de lexistant ;

La difficult technique
Les SI utilisent des technologies volution rapide et lon se retrouve trs souvent en situation
dutiliser et de mettre en uvre une technologie nouvelle non matrise.

La dure
La dure dun projet est quantifie en nombre de mois. Plus le projet dure, plus la motivation de
lquipe smousse au fil du temps.

La stabilit de lquipe projet


La stabilit de lquipe projet est lie la dure du projet. Plus la dure du projet est longue, plus
la probabilit est forte dune dfection au sein de lquipe projet ou du dpart du chef de projet ;
et plus la frquence des rapports conflictuels entres les membres de lquipe est leve.

21
Gestion des projets en systmes dinformation

2) Gestion des risques


La connaissance des risques permet den prvenir les effets nfastes en mettant en place des
mthodes de gestion du risque.

La taille
Lorsquun projet est de grande taille, on peut le dcouper en sous-projets de manire obtenir des
rsultats intermdiaires qui pourront tre valids et appropris par lorganisation au fur et
mesure de leur obtention.

Le degr dintgration
Les risques lis au degr dintgration ncessitent une rflexion pralable pour dfinir ce quil
convient dintgrer et ce qui ne prsente pas dintrt rel.

Les difficults techniques


La solution des risques lis aux difficults techniques repose sur des ides de bon sens.
La premire ide consiste ne pas cder au modernisme systmatique, mais plutt sassurer,
avant de mettre en uvre une technologie quelle est mature et quelle possde un retour sur
exprience.
Le second aspect consiste ne pas surestimer ses propres comptences. Il faut savoir faire appel
aux comptences extrieures le cas chant. Le choix de faire ce que lon ne matrise pas est une
fausse conomie.

La dure du projet
Les risques lis la dure excessive des projets seront en partie rsolus par le fait de segmenter
la taille des gros projets en projets partiels.

La stabilit de lquipe projet


Les risques lis la stabilit de lquipe projet seront limits par le fait davoir rduit la taille et la
dure. Cela diminuera les tensions, les facteurs de conflit et donc lusure du chef de projet et de
son quipe.

22
Gestion des projets en systmes dinformation

CHAPITRE 5 : LES PROGICIELS DE GESTION INTEGRES


PGI (Progiciel de Gestion Intgre) est la traduction adopte en franais pour ERP (Enterprise
Resource Planning). Les premiers ERP sont apparus dans les annes 70.

I) Positionnement des PGI


1) Caractristiques dun PGI
- Un PGI vise offrir lorganisation une solution logicielle globale. Cette solution permet de
grer les principaux processus mtiers de lorganisation de manire cohrente.
- Une solution qui garantie une prennit et une stabilit de fonctionnement. Cest une solution
prte lutilisation.
- Lutilisation dune base de donnes unique permet dviter les redondances dinformation et le
problme de rfrentiel de donnes (une mme information reprsente diffremment)

Exemples: SAP (Systems, Applications and Products for data processing), Adomix de SAGE,
Navision de Microsoft, Peoplesoft.

2) Avantages et inconvnients
2.1) Les avantages
Les avantages dun PGI sont les suivants :
- Cohrence des donnes ;
- Ergonomique unique ;
- Interoprabilit des modules ;
- Application paramtrable ;
- Rduction de la dure de mise en uvre ;
- Matrise des cots ;
- Fiabilit des rsultats ;
- Indpendance des dirigeants par
rapport aux informaticiens ;
- Existence dun choix de solutions
concurrentes ;
- Existence de solutions mtiers

23
Gestion des projets en systmes dinformation

Ces avantages sappliquent toutes les gnrations de PGI, actuelles ou venir.


2.2) Les inconvnients
Les inconvnients sont les suivants :
- Obligation de rorganiser lentreprise conformment aux ncessits du logiciel ;
- Remise en cause simultane de lensemble du systme dinformation de lorganisation ;
- Cot direct trs lev, mais galement cot induit trs important, et souvent sous-estim (en
termes de temps de travail des personnels et en termes de baisse defficacit des services) ;
- Perte de savoir-faire li aux applications informatiques ;
- Choix des mthodes de gestion limits aux capacits du logiciel ;
- Dpendance par rapport aux intgrateurs et aux consultants.

II) La conduite dun projet PGI


Le choix dun PGI prsente une importance stratgique dans la mesure o celui-ci :
- Va impacter la gestion de presque tous les processus et concerner la plupart des services ;
- Va reprsenter un cot trs important, de manire directe et induite ;
- Va engager lorganisation sur le long terme.
Il est donc fondamental pour lorganisation de russir son projet dimplantation.
1) Comment russir limplantation dun PGI ?
Pour cela, il faut bien connaitre les besoins de son organisation. Cela implique :
- De mener une analyse pralable approfondie des processus de lentreprise (Etude de
lexistant) ;
- De dfinir prcisment les rgles de gestion que lon souhaite mettre en place ;
- De dfinir avec prcision les changements organisationnels souhaitables et les modes
dorganisation prjudiciables.
Une fois les besoins tablis, on peut alors :
- Rechercher un PGI adapt aux besoins dfinis, vrifier quil est utilis avec satisfaction dans
son secteur dactivits dans des organisations de taille et de fonctionnement comparables ;
- Dfinir le paramtrage qui convient avec lassistance de lintgrateur ;
- Mesurer les besoins dadaptation de lorganisation.
2) Analyse du risque
La mise en place dun PGI constitue un projet informatique. Les risques dimplantation dun logiciel
sappliquent au cas dun PGI :
- La taille : trs importante dans le cas des PGI puisque tout le systme dinformation et toute la
structure de lentreprise sont quasiment concerns ;
- La matrise des techniques : la mise en place dun PGI prsente peu de difficults car il sagit
dun outil utilisant des mthodes standards et prouves de dploiement ;
- Le degr dintgration : il est maximal car tous les processus de lentreprise sont concerns ;

24
Gestion des projets en systmes dinformation

- La dure : elle est en gnral trs longue compte tenu du primtre. Il faut souvent plusieurs
annes pour tout implanter ;
- La stabilit de lquipe projet : celle-ci est souvent instable cause de la dure et des effets de
la rsistance au changement.
3) Incidence organisationnelle
Compte tenu de leur structure globale et de leur mthode de dploiement, la mise en place dun PGI
implique la mise en uvre simultane dune ringnierie des processus. Cela permet dadapter
lorganisation aux ncessits du progiciel retenu.
Il faudra alors faire face aux rsistances au changement. Il faut que les salaris se sentent impliqus, il
faut leur expliquer le bien fond des actions quon leur demande dentreprendre

25
Gestion des projets en systmes dinformation

Bibliographie

Michelle GILLET, Patrick GILLET, Management des systmes dinformation, Manuel et application,
3ime dition, Paris, Dunod, 2013

Jacques SORNET, Oona HENGOAT, Nathalie LE GALLO , Systmes dinformation de gestion, tout-en-
un, Paris, Dunod, 2010

Jean-franois Soutenain, Eric Willems, Patrice Saintenoy, Alain Burlaud, Systmes dinformation de
gestion, Manuel & applications, 4 dition, Vanves, SupFoucher, 2010

26
Gestion des projets en systmes dinformation

TABLE DES MATIERES


CHAPITRE 1 : STRUCTURATION DES SYSTEMES DINFORMATION .......................................................... 1
I) Position de la fonction informatique au sein de lentreprise .......................................................... 1
1) Le cas des grandes organisations ................................................................................................ 1
2) Le cas des petites entreprises ..................................................................................................... 1
II) Stratgie informatique .................................................................................................................... 2
1) Relation entre la stratgie de lorganisation et la stratgie informatique .................................. 2
2) Notion de schma directeur ........................................................................................................ 2
CHAPITRE 2: ARCHITECTURE TECHNIQUE ............................................................................................... 3
I) Structure technique des outils informatiques ................................................................................ 3
1) Le serveur .................................................................................................................................... 3
2) La base de donnes ..................................................................................................................... 4
3) Le poste client ............................................................................................................................. 5
4) Le systme dexploitation ........................................................................................................... 5
II) Structures types de dploiement .................................................................................................... 6
1) Dploiement client serveur ......................................................................................................... 6
2) Utilisation dun serveur dapplication ......................................................................................... 6
3) Recours au middleware (mdiateur)........................................................................................... 6
4) Utilisation du transactionnel ....................................................................................................... 6
5) Mode de dploiement n-tiers ..................................................................................................... 6
6) Utilisation dun portail ou dun espace numrique de travail .................................................... 7
CHAPITRE 3 : LA CONDUITE ET LA GESTION DE PROJET.......................................................................... 8
I) Principes gnraux de la gestion de projets ................................................................................... 8
1) Dfinition dun projet .................................................................................................................. 8
2) Naissance dun projet .................................................................................................................. 8
3) Intervenants dans un projet ........................................................................................................ 8
4) Organisation dun projet ............................................................................................................. 9
5) Les tapes de la conduite dun projet ....................................................................................... 11
II) Rdaction du cahier des charges fonctionnel ............................................................................... 12
1) La rdaction de lanalyse fonctionnelle..................................................................................... 12
2) La gestion des appels doffres ................................................................................................... 16
CHAPITRE 4 : LIMPLANTATION DU SYSTEME DINFORMATION ........................................................... 17
I) Mise en place dun systme .......................................................................................................... 17
1) Mthodologie de tests et recettes ............................................................................................ 17

27
Gestion des projets en systmes dinformation

2) Gestion de la comptence des utilisateurs ............................................................................... 17


3) Conduite du changement organisationnel ................................................................................ 18
II) Cycle de vie du projet .................................................................................................................... 18
1) Les phases du cycle de vie ......................................................................................................... 18
2) Les diffrents types de maintenance ........................................................................................ 19
III) Gestion de la qualit en matire de SI ...................................................................................... 20
IV) Gestion des risques ................................................................................................................... 21
1) Mthodologie danalyse du risque ............................................................................................ 21
2) Gestion des risques ................................................................................................................... 22
CHAPITRE 5 : LES PROGICIELS DE GESTION INTEGRES .......................................................................... 23
I) Positionnement des PGI ................................................................................................................ 23
1) Caractristiques dun PGI .......................................................................................................... 23
2) Avantages et inconvnients ...................................................................................................... 23
II) La conduite dun projet PGI........................................................................................................... 24
1) Comment russir limplantation dun PGI ? .............................................................................. 24
2) Analyse du risque ...................................................................................................................... 24
3) Incidence organisationnelle ...................................................................................................... 25
Bibliographie ......................................................................................................................................... 26

28