une grille d'analyse des projets systÃ¨me d'information

Systèmes d'Information et Management

Volume 3 | Issue 4 Article 2

1998

Une grille d'analyse des projets systèmed'information : proposition de critères et validationChantal MorleyINT, Evry, [email protected]

Follow this and additional works at: http://aisel.aisnet.org/sim

This material is brought to you by the Journals at AIS Electronic Library (AISeL). It has been accepted for inclusion in Systèmes d'Information etManagement by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contact [email protected].

Recommended CitationMorley, Chantal (1998) "Une grille d'analyse des projets système d'information : proposition de critères et validation," Systèmesd'Information et Management: Vol. 3 : Iss. 4 , Article 2.Available at: http://aisel.aisnet.org/sim/vol3/iss4/2

http://aisel.aisnet.org/sim?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss4%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol3?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss4%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol3/iss4?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss4%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol3/iss4/2?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss4%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss4%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol3/iss4/2?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss4%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

mailto:[email protected]%3E

Une grille d'analysedes projets système

d'information :proposition de critères

et validation

Chantal MORLEYMaître de conférences à 1'INT, Evry

RÉSUMÉ

Les projets de développement de système d'information sont encore tropsouvent mal maîtrisés. Les recherches passées ont enseigné la non pertinenced'une approche méthodologique unique et monolithique. Deux principes sem-blent aujourd'hui acquis : une appréciation des méthodes basée sur des fac-teurs de contingence et une approche par composants méthodologiques. Ce-pendant, le chef de projet a besoin d'éléments qui l'aident à prendre des dé-cisions méthodologiques.

L'article présente le résultat d'un travail de recherche, mené dans le cadred'un groupe rassemblant universitaires et praticiens. Il comporte deux as-pects. D'abord, la proposition d'une grille d'analyse permettant au chef deprojet de mieux connaître les caractéristiques-clés de son projet, avant d'éla-borer le dispositif à mettre en place. Ensuite, le résultat d'une enquête de va-lidation de cette grille auprès d'un échantillon de trente-sept chefs de projet.

Mots-clés : Analyse de projet, Composant méthodologique, Gestion desrisques, Pilotage de projet.

ABSTRACT

Too many information system projects are still uncontrolled. The previousresearches have shown that a monolithic and standard methodology is notappropriate. Today, two principles seem established : a contingency approachof methodologies and a component oriented view of methods. Nevertheless,the project manager is to be helped when taking methodological decisions.

This paper presents the result of a research undertaken by a group of re-searchers and consultants. The article contains two main points. First, theproposal of a criteria-grid to help the project manager to stress the key pointsof his project before establishing a plan of action. Secondly, the result of thevalidation of this grid, based on a survey amongst 37 project managers.

Key-words : Project analysis, Methodological component, Risk management,Project management.

N° 4 - Vol. 3 - 1998 49 1

Morley: Une grille d'analyse des projets système d'information : proposit

Published by AIS Electronic Library (AISeL), 1998

SYSTÈMES D'INFORMATION ET MANAGEMENT

L'ANALYSE CONTEXTUELLEDES PROJETS SYSTÈMED'INFORMATION :PROPOSITION D'UNE GRILLED'ANALYSE ET RÉSULTATD'UNE ENQUÊTEDE VALIDATIONDE CETTE GRILLE

Introduction

Les méthodes de développementde système d'information(1) ontfait l'objet d'une offre abondantedepuis près de vingt ans. Cepen-dant, comme l'écrit R. Reix, "déve-lopper, à partir de technologiescomplexes et évolutives, des sys-tèmes d'information qui saurontatteindre leurs objectifs, répondrepleinement aux besoins des utili-sateurs , être performants et fa-ciles à maintenir, tout en respec-tant les échéances et les coûts,demeure, encore aujourd'hui undéfi difficile pour les gestionnairesde projet" (Reix, 1995b). La per-sistance de difficultés non maîtri-sées conduit à diverses attitudes.Certains adoptent une positioncritique vis-à-vis des méthodes(2).D'autres mettent l'accent sur le

rôle du chef de projet(3) ou surles normes(4). D'autres, en re-vanche, proposent de nouvellesapproches : c'est notamment lecas du courant de la modélisationobjet et notamment d'UML(5), etdu mouvement RAD(S). Cependant,l'intérêt de ces nouveautés ne doitpas faire oublier deux grandes le-çons du passé.

La première leçon est celle de lacontingence : dès les années 80,plusieurs chercheurs sont arrivésà la conclusion qu'il n'y a pas demeilleure méthode dans l'absolu,mais des méthodes plus ou moinsadaptées à un contexte et un pro-blème. Les facteurs de contin-gence généralement retenus sontl'incertitude (Davis et al., 1986)ou le risque du projet (McFarlan,1981 ; Boehm, 1988 ; Barki,1994) ou les deux (Eurométhode,1996). Aujourd'hui, "le principegénéral de la nécessité d'une ré-ponse adaptée aux caractéristi-ques du projet, donc de la non-pertinence d'une méthodologieuniverselle, semble désormais ac-quis" (Reix, 1995).

La seconde leçon est celle de lamodularité : les grilles de classifi-cation des méthodes(7) ont accré-

(1) On entend par "méthode de développement" tout ensemble organisé de principes,techniques et outils intellectuels à utiliser lors d'un projet informatique.

(2) Parmi les plus récents , voir par exemple (Wastell , 1996) ou (Fitzgerald , 1996).(3) Voir par exemple dans (Gibson , 1994 ) : "Le succès d 'un projet repose en grande

partie sur le chef de projet , et l'échec de bon nombre de projets est dù à sesinsuffisances " (p. 119).

(4) Il existe un nombre important de normes sur la conduite de projet Informatique, voirpar exemple (Bennatan, 1995).

(5) Issue de préoccupations logicielles , la modélisation objet (Bouzeghoub , 1995 ; Muller,1997) tend aujourd'hui à se situer également au niveau informationnel etorganisationnel comme le montre par exemple (Kettani et al., 1998).

(6) Rapid Application Development , méthode participative de développement d'applicationsdans des délais réduits (Girling , 1998 ; Stapleton , 1997 ; Hughes , 1997).

(7) Voir par exemple (Amadeus, 1987).

50 2

Systèmes d'Information et Management, Vol. 3 [1998], Iss. 4, Art. 2

http://aisel.aisnet.org/sim/vol3/iss4/2

UNE GRILLE D'ANALYSE DES PROJETS SYSTÈME DINFORMATION

dité l'idée qu'une méthode peutêtre considérée comme un produitfini. Or, l'évolution des méthodesa montré de nombreux empruntsréciproques d'une méthode à l'au-tre(8) (Adam, 1998). Il y a donclieu de considérer qu'une méthoden'est pas un bloc, mais qu'ellecomporte en général des techni-ques qui peuvent être utilisées defaçon ponctuelle ou accompagnéesd'autres éléments méthodologi-ques. C'est également l'orientationadoptée par deux projets de re-cherche européens Nature(9) etF3(10).

L'acceptation de ces deux prin-cipes - une appréciation des mé-thodes basée sur des facteurs decontingence et une approche parcomposants méthodologiques - apour conséquence une responsabi-lité accrue du chef de projet, àqui il revient de bâtir une dé-marche méthodologique adaptée àson projet. Cela rejoint une défini-tion plus générale du rôle mana-gérial que défend notamment J.-L.

Le Moigne face à une situationcomplexe - et un projet systèmed'information est souvent com-plexe -, on ne peut pas se con-tenter de puiser dans un catalo-gue de solutions toutes faites(11),mais il faut développer une com-préhension de la situation pourrepérer les opportunités ou lesrisques. D'une certaine façon, lerôle du chef de projet a une di-mension stratégique : les mé-thodes ont apporté des réponses,leur utilisation appelle, touteschoses égales par ailleurs, unexercice analogue à ce que C.-A.Martinet appelle une "délibérationstratégique"(12).

Il devient donc Important d'ai-der le chef de projet à prendreses décisions méthodologiques.C'est l'objectif que s'est fixé legroupe Système d'information duCMSL(13). La première étape denotre recherche fut de fournir uneaide à une analyse a priori desprojets : c'est le résultat de cetravail qui est présenté ici.

(8) Par exemple , Merise / 2 (Panet, 1994 ) avec notamment l'introduction dans Merise desmodèles de flux et des techniques de généralisation /spécialisation ; ou la constitutiond'UML à partir d 'éléments propres à trois méthodes concurrentes.

(9) Novel Approaches to Theories Underlying Requirements Engineering (ISI, 1994). Leschercheurs ont notamment proposé un méta -modèle du processus de modélisationqui fonde la conception d'un outil logiciel permettant de stocker l'expertiseméthodologique pour guider les concepteurs . Ils ont également bâti le schéma d'uneboîte à outils informatisée pouvant accueillir des structures réutilisables.

(10) F3 : From Fuzzy to Formal . Le but du projet est de formaliser une démarche , avec lesouci de favoriser la capitalisation des expériences acquises. Le groupe a construitune architecture de bibliothèque de composants réutilisables (ISI, 1994).

(11) "Les situations perçues comme complexes (...), dans lesquelles les problèmes sontdifficilement et incomplètement perçus , les effets induits et autres boucles étrangesmalaisément anticipables (...) appellent souvent une intervention cognitive deconception : il s'agit de modéliser , de concevoir des modèles possibles, et quin'existent pas encore , et non plus de puiser dans le portefeuille des modèles toutfaits ." (Le Moigne, 1986 ) p. 243.

( 12) "Le processus de délibération peut /doit rencontrer, soupeser, comparer, mixer, doserces formes de rationalité substantive sans qu 'il puisse s'en remettre, sauf simplecationoutrancière, à l'une d'entre elles a priori " (Martinet, 1996) p. 12.

(13) Centre d'étude pour la Maîtrise des Systèmes et du Logiciel, au ConservatoireNational des Arts et Métiers. Ce groupe a pris la suite des travaux entrepris par legroupe Conception de Système d' information de l'AFCET (Tabourier, 1996).

51 3



SYSTÈMES D INFORMATION ET MANAGEMENT

Lors de l'année 1996-97, legroupe de travail a élaboré unegrille mettant en évidence les ca-ractéristiques -clés d'un projet,susceptibles de générer des ris-ques . Par rapport aux travaux an-térieurs , nous avons considéréque ces caractéristiques ne sontpas "fongibles", c'est-à-dire qu'onne peut pas caractériser un projetpar une mesure unique , telle 1"1n-certitude globale du projet" (Daviset al., 1986). L'expérience nous aappris la nécessité de connaltrechacune des sources de risque etdonc de travailler avec le conceptde "profil de projet" (Ahituv,1984). L'objectif était de proposerun instrument guidant le chef deprojet vers une meilleure connais-sance de son projet, avant qu'ilélabore le dispositif à mettre enplace (démarche, organisation, ac-tions , moyens , techniques, mo-dèles , modes de gestion... ).

Dans un second temps, lors del'année 1997-98, nous avons con-fronté cette grille à l'expérienced'un échantillon de chefs de pro-jet, offrant une large représenta-tion des entreprises françaises,moyennes ou grandes, afin d'envalider le principe et le contenu.

Le but de cet article est de pré-senter la grille d'analyse des pro-jets et les résultats de sa valida-tion par des professionnels.

PREMIÈRE PARTIE :METHODOLOGIESDE RECHERCHE UTILISÉES

1.1. Méthodologiepour l'élaboratiande la gfile

Le tableau 1 présente la listedes critères , accompagnés d'unedéfinition abrégée et d'une justifi-cation sommaire. Nous les repren-drons dans la seconde partie, ac-compagnés des résultats de l'en-quête de validation.

La méthodologie retenue pourélaborer cette grille d'analyses'inscrit dans la famille des mé-thodes dites interprétatives(14) ousubjectivistes(15). Cette approchede recherche correspond à la tra-dition de l'idéalisme allemand, se-lon laquelle la réalité ultime ré-side dans les idées et non dans laperception des phénomènes. Lesconnaissances se construisentgrâce aux interprétations du réelperçu auxquelles se livrent leschercheurs, chacun avec son sa-voir, son expérience, son histoire.Parmi les méthodes qui relèventde cette approche(16), nous avonschoisi la méthode subjective/argu-mentative, basée sur la confronta-tion d'opinions et la spéculation,car elle vise à la productiond'idées et théories nouvelles.

Cf. tableau 1

(14) Voir (Reix , 1995c).(15) Voir (Burrel - Morgan , 1993).(16) Voir la typologie de (Galliers, 1991).

524



UNE GRILLE D'ANALYSE DES PROJETS SYSTÈME DINFORMATION

N° Nom du critère Définition justification

1 Reprise Obligation de reprendre Nécessité d'activité de reprised'un existant le contenu de bases de données des donnéesinformationnel ou fichiers existants Source de connaissance

de l'existant

2 Réutilisabilité visée Obligation de mener Effort de généralisationla conception en reprenant Effort d'alimentation d'une basedes éléments existants de composants(représentations ou monceauxde logiciel)

3 Réutilisation Obligation d'alimenter une base Contrainte de conceptionimposée de composants réutilisables Effort de spécialisation

4 Aspect novateur Nouveauté pour la maîtrise Risque de rejet (maîtrisedu projet d'ouvrage ou pour la maîtrise d 'ouvrage)

d'oeuvre Risque de retard (maîtrised'oeuvre)

5 Centralisation Lieu de décision Impact possible sur le repérageou polycentrisme des investissements des décideurs

informatiques Impact possible surl'architecture du systèmed'information

6 Communication Existence de contraintes Impact sur l'organisation duintroduites par les besoins projet (communication humaine)en communication (humaine Contraintes de normalisationou technique) (communication technique)

7 Indépendance Degré de dépendance par Nécessité de coordinationdu projet rapport à d'autres projets Source de risques

8 Type d'enjeu Apport du futur système Oriente la définitiond'information pour l'entreprise de la qualité attendue

9 Variété des acteurs Nombre de décideurs pouvant Risque de conflitavoir des points de vue différents et d allongement des délais

10 Exigence Critère dominant d'appréciation Impact sur le type de pilotagedominante de la réussite du projet par

le maître d'ouvrage

11 Balance Point de départ Impact sur la démarchebesoins/offre de la conception : nouvelle de conception

technologie ou besoins

12 Granularité Nature des travaux à effectuer Impact sur le choix(étude globale, étude détaillée, des interlocuteurs et surdéveloppement...) la marge de décision

13 Taille du projet Charge estimée du projet Facteur de risqueImpact sur l'organisationdu projet

14 Variété Nombre de sites visés Impact sur la chargedes contextes par l'application et ayant Impact sur la démarched'implantation des particularités locales (approche générique

ou approche par site pilote)

15 Volume Degré d'utilisation de la future Impact sur la démarcheet fréquence applicationd'utilisation

Tableau 1 : Critères de la grille d'analyse

535



SYSTÈMES DINFORMATION ET MANAGEMENT

Ainsi, la grille d'analyse des si-tuations de projet a été obtenuepar croisement des expériencesvariées d'une trentaine d'ex-perts(17) et par explicitation deconnaissances pratiques et théori-ques (Tabourier, 1996). Douzeséances, alternant expressions li-bres des experts, justifications despropositions, exemples vécus etdiscussions, ont été nécessairespour obtenir une première versionde la grille. Celle-ci se compose dequinze critères. Pour chacun d'en-tre eux, nous nous sommes effor-cés d'expliciter les raisons pourlesquelles nous proposions de leretenir.

sation, aspects socio-arganisation-nels ). Ils avaient également reçuune sensibilisation théorique etpratique à la technique de l'entre-tien semi-directif.

Chaque interviewé a reçu, unesemaine avant l'interview, uneprésentation écrite des objectifs dela recherche, ainsi que la descrip-tion de chaque critère de la grille,telle qu'elle figure ci-après dans laseconde partie. Il était invité, lorsd'un entretien d'une heure et de-mie à deux heures, à s'exprimerde façon libre, sur la grille ens'appuyant sur son expérience :intérêt et degré d'importance descritères, autres critères, actionsassociées à l'une ou l'autre valeur.

1.2. Méthodologie de l'enquête

L'objectif étant de valider lestermes de la grille, aussi bien surle plan sémantique (compréhen-sion des mots) que sur le fond(pertinence des critères retenus),l'entretien semi-directif est apparule plus adapté.

L'enquête a été effectuée entreoctobre et décembre 1997, auprèsde 37 chefs de projet, principale-ment en région parisienne(18). Lesentretiens ont été menés par 58étudiants, seuls ou par groupe dedeux. Les étudiants étaient entroisième année de l'INT(19), ayantchoisi une spécialisation Systèmed'information offerte par INT-Ma-nagement. Tous avaient été for-més l'année précédente à la con-ception de système d'information(démarche, techniques de modéli-

1.3. Échantillon de l'enquête

Tous les interviewés ont étéchoisis par les étudiants eux-mêmes, soit à l'occasion de leurrecherche de stage de fin d'étude,soit en s'adressant directement auDépartement Système d'Informa-tion d'une entreprise. L'échantillonobtenu se présente ainsi.

Les 37 interviews représentent27 entreprises différentes. Dans lecas de plusieurs interviewés dansla même entreprise, il s'agit deservices différents dans unegrande entreprise. La répartition(tableau 2) couvre la plupart dessecteurs, majoritairement des en-treprises de plus de 3 000 per-sonnes , sauf quelques petites so-ciétés de services en ingénierie in-formatique et télécommunication.

(17) Le groupe était composé de professionnels de l'informatique et d'universitaires. Laplupart avaient à la fois une activité de conseil et une activité de réflexionméthodologique.

(18) Une enquête a eu lieu à Monaco et une autre au Mexique, cette dernière viaInternet . Ces deux interviews "excentrées" (liées à la nationalité de deux étudiants dugroupe d'enquêteurs) n'ont pas fait apparaître de réaction particulière face à la grille.

(19) L'INT , Institut National des Télécommunications , rassemble une école de gestion,INT-Management, et une école d'ingénieurs , Télécom-INT.

546



UNE GRILLE DANALYSE DES PROJETS SYSTÈME DINFORMATION

A deux reprises, un Interviewéa fait explicitement référence àson expérience dans deux sec-

teurs différents, nous avons alorsconsidéré que chaque secteur étaitreprésenté.

Secteur Nombre d'entreprises Nombre d ' interviews

Industrie 4 4Banques 4 7Opérateurs télécommunication 5 12Services (hors télécommunications) 5 5SSII 6 8Laboratoires pharmaceutiques 3 3

Tableau 2 : Secteurs représentés dans l 'échantillon

SECONDE PARTIE :PRÉSENTATIONDES CRITÈRES ET RÉSULTATDE L'ENQUÊTE

2.1. Importance des critères

Le tableau 3 donne une vueagrégée des résultats. Dans lescolonnes 4 à 9, on a fait figurerle nombre de réponses, suivi du

pourcentage que cela représentesur l'ensemble des réponses con-cernant le critère. En colonne 3,la note a été calculée en totalisantle nombre de réponses, avec lespondérations suivantes(20) :

• très important = 2,

• moyennement important = 1,

• pas important = 0.

Cf. tableau 3

(20) La pondération permet d 'obtenir un classement . Elle présente un caractèrearbitraire : une autre pondération pourrait modifier un peu la hiérarchisation. Entoute rigueur, il faudrait faire un test statistique sur les rangs. Cependant, notreobjectif était principalement de vérifier quels critères "parlaient" spontanément auxchefs de projets et de découvrir ceux qui ne correspondaient pas du tout à leurperception. De ce point de vue, la hiérarchisation obtenue semble cohérente.

557




N° Critère Note Très Moyennement PasImportant important important

ou Important

1 Reprise d ' un exis- 47 17 46% 13 35 % 7 19%tant informationnel

7 Indépendance 47 15 40% 17 46% 5 13%du projet

13 Taille du projet 45 15 40 % 15 40 % 7 19%

8 Type d'enjeu 44 15 40% 14 38% 8 21%

10 Exigence 43 12 32 % 19 51% 6 16%dominante

4 Aspect novateur 40 9 24 % 22 60% 6 16 %du projet

6 Communication 37 13 35 % 11 30% 13 35 %

9 Variété des acteurs 34 10 27 % 14 38% 13 35 %

15 Volume et 32 8 21 % 16 43 % 13 35 %fréquenced'utilisation

14 Variété 31 4 11 % 23 62% 10 27%des contextesd'implantation

3 Réutilisation 23 7 19 % 9 24 % 21 57 %imposée

2 Réutilisabilité visée 18 4 11 % 10 27 % 23 62 %

5 Centralisation 18 3 8% 12 32 % 22 60%ou polycentrisme

11 Balance besoins/ 16 3 8% 10 27 % 24 65%offre

12 Granularité 10 2 5% 6 16 % 29 78%

Tableau 3 : Classement des critères selon l'importance

Nous allons les reprendre de fa-çon qualitative, dans l'ordre declassement, en donnant d'abord ladescription du critère, puis les ap-préciations par les chefs de projetet les impacts perçus.

2.2. Critère 1:reprise d'un existantinformationnel

Description

important pour deux raisons.D'abord, un existant à reprendrepeut être une contrainte qui setraduira par des activités spécifi-ques, par exemple concevoir ledispositif logiciel et organisation-nel permettant la migration desdonnées de l'ancien vers le nou-veau système. Mais ce peut êtreaussi une source de connaissancequi facilite certaines activités deconception, notamment le recense-ment des règles de gestion.

Il s'agit de l'obligation pourl'équipe de projet de récupérersans modification tout ou partied'un existant informationnel, ma-nuel ou informatisé. Ce critère est

Données

Parmi ceux qui ont trouvé le cri-tère important ou très important,l'accent était davantage mis sur

568



UNE GRILLE DANALYSE DES PROJETS SYSTÈME D INF ORMATION

les données à reprendre que surles modèles. Cependant, un tiersdes interviewés ont interprété lecritère dans le sens, à savoir"Faut-il faire une étude de l'exis-tant ?" ou "Faut-il reprendre desfonctionnalités existantes ?". Quel-ques-uns ont ainsi considéré quece n'était pas un élément caracté-risant le projet, mais que l'étudepréalable devait déterminer si l'onreprenait ou non l'existant.

Impacts

En ce qui concerne les actionsassociées, il ressort clairementque la reprise doit être traitéecomme un problème à part. Saprésence est liée soit à la nécessi-té de conserver un historique quine sera plus accessible que dansle nouveau système ; soit à la re-prise d'informations permanentes,c'est-à-dire qui ne sont pas liées àun cycle opérationnel ; soit à lareprise de données opérationnellesau cycle long, par exemple descommandes dans le secteur del'aéronautique.

Plusieurs recommandations tou-chant à la reprise d'un existantinformationnel ont été émises.

• La définition d'une stratégie demigration est nécessaire pourcinq raisons :1. l'information peut être éparpil-

lée sur différents supports ;

2. certaines données peuventêtre de mauvaise qualité ;

3. il faut peut-être profiter de lareprise pour introduire desaméliorations (changement destructure de date facilitant lepassage à l'an 2000 parexemple) ;

4. l'information peut n'être re-prise que partiellement : Ilfaut déterminer le degré et lanature des données reprises ;

5. la reprise peut inclure laconstruction de nouvelles in-terfaces avec les applicationsqui utilisent les données dansleur format existant.

• Il faut définir les responsabilitésdans l'opération de reprise. Sil'on est dans le cas d'un sys-tème implanté sur plusieurssites présentant des caractéristi-ques différentes , la reprise sefait localement.

• L'estimation de la charge est dif-ficile à faire . Elle est souventsous-évaluée. Il peut être néces-saire de développer un outil dereprise automatique.

• La reprise doit être planifiée suf-fisamment tôt, car c'est parfoisun facteur de retard à la miseen oeuvre d'une nouvelle appli-cation. Les spécifications de re-prise ne peuvent démarrer quelorsque l'on a les spécificationsde la structure cible, ainsi quel'architecture technique.

• Il faut parfois prévoir une for-mation à la nouvelle présenta-tion des données.

En conclusion , l'incidence de lareprise d 'un existant informationnelsur la conduite du projet peuts'énoncer ainsi. Si l'on a un exis-tant informationnel à reprendre, ilfaudra d'une part recueillir l'infor-mation sur les structures exis-tantes et les applications qui lesutilisent, et d'autre part estimer,planifier et conduire le projet Mi-gration en liaison avec le projetprincipal.

2.3. Critère 7:Indépendance du projet

Description

Il s'agit de répondre à la ques-tion suivante : le projet est-il in-dépendant d'autres projets en

57 9



SYSTÈMES D1NFORMATION ET MANAGEMENT

cours ? Plus précisément : les dé-cisions à prendre dans la con-duite de ce projet sont-elles tribu-taires des décisions prises ou àprendre dans les autres projets ?L'avancement du projet dépend-ildes résultats d'autres projets ? Cecritère est important car il condi-tionne l'organisation du projet,notamment le dispositif de pilo-tage. Il permet d'évaluer la lati-tude décisionnelle des acteurs duprojet. Une interdépendance fortenécessite une coordination globaledes projets, des échanges d'infor-mation entre les projets pourconnaître les choix respectifs.C'est par ailleurs une source derisque, les aléas des autres pro-jets peuvent avoir des répercus-sions sur le projet.

Données

Du point de vue des interviewés,le critère est apparu important defaçon unanime pour les projets àimplantation internationale etpour les projet télécom (installa-tion réseau local, ... ). On a pu re-lever quatre interprétations, cha-cune conduisant à la préconisa-tion d'actions spécifiques. Lesdeux premières représentent lamajorité des réponses.

Impacts

ire interprétation : le projet estdépendant d'autres projets, et enattend soit des résultats de tra-vaux (étude ou logiciels), soit desdécisions, soit des informations.La dépendance est perçue commeun facteur de risque important :"Plus on a de liens avec d'autresprojets, moins on a de chances deréussir". Les impacts portent :

- sur les charges, car la dépen-dance génère une charge non né-gligeable de coordination (charge

transverse), voire des charges nonproductives (attentes) ;

- sur la complexité du projet ;

- sur la planification, car cer-taines tâches peuvent dépendre dedécisions ou productions atten-dues ; cela peut changer la critici-té de certaines tâches ;

- sur les délais, car certains re-tards des autres projets peuventavoir une répercussion.

Il est donc recommandé :

• d'estimer les risques des autresprojets et de se ménager des de-grés de liberté ;

• d'établir un Plan Qualité pournotamment définir les droits etdevoirs de chacun, mettre enplace des mesures d'arbitrage,planifier des points de rencontreréguliers avec les autres projets,prévoir d'utiliser un outil per-mettant le partage d'informa-tions :

• de confier à un Comité de pilo-tage la responsabilité de mettreen place un dispositif de coordi-nation, de veiller au respect desplannings et d'établir des jalonsobligatoires ; on regroupe ainsiun ensemble de projets fonction-nellement indépendants, maiss'échangeant des données ; leComité de pilotage pourra égale-ment synchroniser la communi-cation extérieure aux projetsainsi que les formations des fu-turs utilisateurs.

2e interprétation : l'applicationvisée par le projet doit communi-quer avec d'autres applications,qui ne sont pas forcément encours de refonte.

Il est recommandé de se posercette question de dépendance, si-non l'on risque la redondanced'information dans le systèmed'information, voire une perte

58 10



UNE GRILLE D'ANALYSE DES PROJETS SYSTÈME D'INFORMATION

d'intégrité. Pour déterminer lesdomaines concernés, il est bon des'appuyer sur une cartographie dusystème d'information de l'entre-prise. Avant toute installation, Ilfaut vérifier que l'application fonc-tionne correctement dans son fu-tur environnement.

3e interprétation : le projetpartage des ressources avec d'au-tres projets.

S'il s'agit de ressources hu-maines, cette dépendance peutavoir des impacts sur la planifica-tion. Il faut parfois trouver dessolutions de rechange.

Si deux projets utilisent pourl'exploitation future les mêmesressources informatiques, certainschoix techniques peuvent avoirdes conséquences sur les perfor-mances de l'autre application.Cette forme peut aussi être consi-dérée comme un cas particulierde la première.

4e interprétation : le projets'inscrit dans un contexte politi-que et stratégique qui peut in-fluencer son déroulement. Parexemple, il peut y avoir des chan-gements de priorités ou des pres-sions sur le chef de projet.

En conclusion, l'indépendancedu projet est apparue majoritaire-ment comme un facteur pouvantInfluer sur la conduite du projet.Les réponses sont d'ordre organi-sationnel. Il est à noter qu'aucuninterviewé n'a pris explicitement lepoint de vue réciproque : d'autresprojets sont dépendants de l'avan-cement de mon propre projet.

2.4. Critère 13: Table du projet

Description

Ce critère traduit la charge pré-visible du projet et le couple{délai, nombre de personnes de

l'équipe projet}. On peut considé-rer une taille élevée comme unfacteur de risque intrinsèque, àcause des problèmes de coordina-tion et cohérence que cela en-traîne. Ce critère doit être pris encompte car il peut conduire, pourmaîtriser le projet, à le découper,ordonnancer les sous-ensembles,mettre en place des moyens decoordination (administration dedonnées) et de réutilisation (in-terne et externe au projet).

Données

De nombreux commentaires ontété exprimés par les interviewés.

La taille est apparue comme unfacteur de risque d'échec. Ungrand projet demande des moyensimportants. Un nombre élevé depersonnes dans l'équipe de projetgénère des besoins de coordina-tion. "Les problèmes augmententde façon exponentielle avec lenombre de personnes" ; "Au-delàde douze personnes dans l'équipe,le projet est ingérable". Plus lataille est grande, plus on doit gé-rer d'informations sur le projet.Certains ont évoqué une politiqued'entreprise consistant à favoriserles projets de petite taille : "Onévite les projets trop longs parcequ'il y a de fréquents change-ments dans la hiérarchie, et quec'est plus cher".

Il est plus difficile de motiver sile projet est de grande taille. Al'inverse, la Direction ou Directiongénérale est souvent plus impli-quée, car les enjeux sont plus im-portants. Un grand projet permetainsi d'ouvrir certaines portesdans l'entreprise. Cependant, "lesprojets an 2000 sont un exemplede projet difficile à mener, car cene sont pas des projets stratégi-ques qui passionnent les foules".

59 11



SYSTÈMES I7 INFORMATION ET MANAGEMENT

Pour les projets télécom, la tailledétermine souvent si l'on a affaireà un projet standard ou à unprojet sur mesure.

ImpactsCe critère doit être évalué à

chaque étape du projet. Diversesactions ont été évoquées.

La charge de gestion de projets'accroît fortement avec la taille :il faut donc diviser le travail etaugmenter l'encadrement intermé-diaire. Pour cela, il est souhaita-ble de découper en sous-projets.Certains recommandent de décou-per le projet en phases de maxi-mum six mois , le délai étantconsidéré comme le plus grandfacteur de risque.

Une gestion rigoureuse estnécessaire : établir un planning,effectuer le suivi, mettre en placeune administration de données,augmenter la communicationstructurée.

En conclusion, la taille du projetest prise en compte par une majo-rité d'interviewés. La tendance estplutôt d'éviter les grands projetsou de découper en sousprojets, ouen étapes à horizon réduit. Le re-cours à d!fférentes techniques degestion du projet (encadrement,planning, communication structu-rée) a été fréquemment évoqué.

2.5. Critère 8 : Type d'enjeu

DescriptionCe critère traduit l'objectif géné-

ral du projet : pour quoi veut-oninvestir ? Il représente le typed'avantage que le maître d'ouvrageescompte obtenir en échange desefforts - en particulier financiers -consentis pour mener le projet.Par exemple, la rentabilité du ca-pital investi est recherchée dans

la diminution de main d'oeuvre debureau grâce à l'automatisationd'une partie des tâches, ou aucontraire dans une améliorationdes prises de décisions au moyend'un observatoire du système opé-rant au service du management,ou encore dans une améliorationdu fonctionnement opérationnelpar un usage créatif des technolo-gies de l'information et de la com-munication.

La valeur de ce critère n'est pastoujours facile à percevoir, carsouvent elle n'est pas affichéeclairement, ou bien les objectifspeuvent être multiples. Il fautnéanmoins chercher à percevoirles enjeux dominants. Ce critèreest important, car sa valeur influesur la définition de la qualité re-cherchée et l'architecture généraledu système. Pour améliorer laproductivité administrative, l'es-sentiel va se jouer autour de l'au-tomatisation : plus on automatise,plus on améliore la productivité.Pour construire une mémoire envue de l'établissement de tableauxde bord, le principal est d'obtenirune structuration robuste des in-formations, qui puisse résister àla variété des cas et à l'évolution :on va capter l'information de lafaçon la plus indépendante de sonutilisation, en s'intéressant auxévénements, aux protagonistes, àla sémantique. Pour améliorer l'ef-ficacité opérationnelle, Il est im-portant d'analyser les processuset la synergie entre travail infor-matisé et intervention ou décisionhumaine : la représentation dusystème d'information comprendles trois facettes données, traite-ments et décisions. Pour assurerla pérennité de l'investissementgrâce à l'évolutivité, on va avoirrecours à des techniques de géné-ricité, de modularisation, de para-métrisation.

60 12



UNE GRILLE D'ANALYSE DES PROJETS SYSTÈME D1NFORMATION

Données

L'importance accordée à ce cri-tère par un nombre élevé d'inter-viewés doit être analysée avec pré-caution. Il a en effet donné lieu àplusieurs interprétations erronées.Certains ont compris : "Il est im-portant de connaître les enjeux"(7 réponses). D'autres ont consi-déré que cela signifiait : "Il fautqu'un projet soit rentable" (4 ré-ponses). D'autres enfin ont assi-milé le critère à : "Les enjeuxétaient-ils Importants ?" (3 ré-ponses).

Les enjeux étant définis par lamaîtrise d'ouvrage, il est apparuimportant de bien les identifier,pour pouvoir faire valider lespoints-clés. L'un des interviewés aassimilé l'enjeu à une spécifica-tion. Un autre considère que lesenjeux doivent figurer dans lePlan Assurance Qualité. Plusieursrecommandent de distinguer lesenjeux tournés vers le client et lesenjeux internes à l'entreprise.

Impacts

Différents impacts sur le pilo-tage du projet ont été perçus.

• Selon le type d'enjeu, on aurabesoin de compétences diffé-rentes (ingénieur, informaticien,gestionnaire, organisateur).

• Selon le type d'enjeu, on estplus ou moins sensible à la ren-tabilité du projet : "Un projetstratégique, c'est celui dont onne sait pas mesurer le retoursur investissement" dit-on enforme de boutade. Mais, plu-sieurs interviewés considèrentque de toutes façons, il faut sefixer des objectifs quantifiés.

• Si le type d'enjeu mesure l'im-portance du projet, alors les en-jeux peuvent évoluer, ce qui a

un impact sur la planificationet/ou sur les moyens affectés.

• Selon le type d'enjeu, Il y a plusou moins de risque, par exemplesur le plan social (rejets, ralen-tissement du projet, interventiondes syndicats).

• Selon le type d'enjeu, le projetest plus ou moins complexe.Ainsi, l'aide à la gestion a étéperçue comme un problèmetechnique de recherche d'infor-mation (datawarehouse), alorsque l'objectif de productivité né-cessite d'étudier des processuscomplexes.

• Si l'enjeu est l'utilisation denouvelles technologies, il fautd'une part bien maîtriser les as-pects techniques (par exempleen faisant un prototype), d'autrepart veiller à respecter le budgetet les plannings car les de-mandes peuvent être inflation-nistes.

En conclusion, l'appréciation dutype d'enjeu sur la conduite duprojet est apparue plutôt impor-tante, mais selon des points devue variés. Ce qui domine, c'estd'identtfler les enjeux, car on y as-socie des risques de différentesnatures (complexité, faiblesse demoyens, mouvement social, non-maîtrise technique, dépassementbudget/ délai...).

2.6. Critère 10:Exigence dominante

Description

Ce critère répond à la questionsuivante : dans la triade délai-coût-qualité, y a-t-il une conditionprincipale du succès du projet ?Quel critère sera-t-il primordialpour le maître d'ouvrage ? Ce cri-tère est important car il peutconduire à modifier le type de pi-

61 13



SYSTÈMES DINFORMATION ET MANAGEMENT

lotage, c'est-à-dire la variable es-sentielle à privilégier : pilotage parles coûts, pilotage par les délais,renforcement du dispositif qualité.

Données

Beaucoup d'interviewés ontconsidéré qu'en général il s'agit defaire un compromis entre dif-férentes exigences, notammentcoût/délai/qualité, voire que cesont des objectifs qualité au senslarge du terme et qu'il faut lesclasser par ordre de priorité. Pourcertains, le coût est cependantmentionné comme le plus impor-tant ; pour d'autres, en nombre àpeu près équivalent, c'est le délai.Certains considèrent qu'ils sontliés car délai accru = coût accru.L'un des interviewés pense quesouvent le délai n'est pas vrai-ment impératif : "C'est un argu-ment du client pour maintenir lapression, mais on se rend compteque quand on dépasse ce n'estpas dramatique".

Si les exigences du client sonttrop lourdes, il faut lui montrerles dangers ou risques d'échec(délai trop court ou budget insuf-fisant par exemple). Certainsconsidèrent que la seule vraie exi-gence, c'est :

- de répondre aux "besoins réels"(par opposition aux besoins ex-primés) ;

- ou de comprendre les besoinsfonctionnels (métier, réglemen-tation) ;

- ou d'être "en adéquation avecla politique du groupe" ;

- ou d'obtenir un retour rapidesur investissement (chiffre d'af-faires généré ou nombre de sous-criptions au nouveau service, parexemple). La mesure d'atteinte del'exigence est alors différée quel-ques mois après la fin du projet.

Le simple respect du cahier descharges et des exigences contrac-tuelles a été mentionné par uneminorité. L'un des interviewés acompris le critère comme : "guiva juger que le projet est bon ?".

Impacts

Les impacts n'ont pas été dé-crits clairement.

Si le délai est dominant, l'ex-pression principale est qu'il fautplus de moyens et moins d'exi-gences et seul un des interviewésrelève que l'exigence de délai "nesignifie pas mener le projet rapi-dement, mais tomber juste entemps et en heure". Notamment, ilfaut une équipe plus Importante ;l'un remarque toutefois que surcertaines tâches, un accroisse-ment de ressources ne réduirapas le délai. Il faut parfois sauterdes étapes de validation ; il fautparfois réduire le périmètre fonc-tionnel. Toutes les méthodes sontbonnes (langage objet, réutilisationde code) si elles réduisent le délai,car souvent l'application ne vivrapas très longtemps.

Si l'utilisation des ressources in-ternes est dominante, cela permetde garder le contrôle du projet etd'avoir plus de poids face au Co-mité de pilotage. Mais, un presta-taire de services a considéré quel'utilisation de ressources internesentraîne des charges supplémen-taires.

Si la qualité est dominante, unresponsable qualité doit pouvoirsurveiller.

Si les coûts sont limités, ilfaut maximiser la réutilisation del'existant.

En conclusion, l'appréciation del'exigence dominante sur la con-duite du projet reflète ce qui appa-raît comme l'exigence généralement

62 14



UNE GRILLE D'ANALYSE DES PROJETS SYSTÈME DlNFORMATION

dominante. De ce fait, chacun sem-ble fortement marqué par soncontexte d'intervention (prestataireinterne ou externe, engagementscontractuels ou non, répercussiondes retards, etc.). Ainsi, selon l'unou l'autre des interviewés, c'est lecoût, le délai ou la qualité qui esttoujours prioritaire.

2.7. Critère 4:Aspect novateur du projet

Description

Ce critère répond à la questionsuivante : le projet est-il novateurpar rapport à la culture et l'expé-rience des acteurs ? L'aspect no-vateur peut concerner le domaineapplicatif, les techniques mises enoeuvre dans le système cible, lesméthodes, démarches et outils dedéveloppement. Il traduit le degréde changement relatif à ungroupe d'acteurs. Ce critère estimportant puisqu'il traduit un fac-teur de risque : risque de rejet sil'aspect novateur concerne la maî-trise d'ouvrage ; et risque de dé-passement des charges si l'aspectnovateur concerne le maître d'oeu-vre. La prise en compte de ce fac-teur peut être un suivi rigoureuxde l'avancement, une stratégie derepli sur des solutions plus fami-lières, l'appel à une expertise ex-terne, la formation des acteurs...

Données

Un projet peut ainsi être nova-teur pour la maîtrise d'ouvrage oupour la maîtrise d'oeuvre. Cer-taines réponses ont porté sur l'unou l'autre aspect ou sur les deux.Le premier aspect a été pris encompte par dix-huit chefs de pro-jet et tous ont alors considéréqu'il avait de l'importance. Le se-cond a fait l'objet de vingt-cinq

réponses et il a été jugé assezpeu important.

Impacts

Si le projet est novateur pour lamaîtrise d'ouvrage

• il y a un risque de dérapagedans les délais car l'analyse desbesoins peut être plus Impor-tante et prendre plus de temps :

• il faut introduire une compo-sante terrain importante : com-prendre l'organisation, apprécierles compétences des utilisateurset évaluer le 'ressenti" des fu-turs utilisateurs il faut notam-ment vérifier que le nouveausystème d'information n'introduitpas de contraintes sur l'exercicedu métier ;

• il faut préparer la gestion duchangement, car le futur sys-tème risque d'être refusé explici-tement ou implicitement (nonutilisation) ; en particulier, ilfaut identifier, bâtir et planifierla formation des utilisateurs.

Pour ce qui est de l'aspect nova-teur du projet pour le maîtred'oeuvre :

• il faut faire une analyse de ris-ques concernant le matériel, lelogiciel et l'expérience de l'équipede projet ; il peut être utile derechercher des témoignages d'ex-périences semblables, sur d'au-tres projets ou dans d'autres en-treprises ;

• il faut être attentif aux compé-tences techniques de l'équipe etprévoir éventuellement unecharge de formation ; il peutêtre utile de s'appuyer sur une"hot-line" du fournisseur du pro-giciel ou logiciel

• il faut être vigilant dès le débutdu projet, lors de l'étude préala-

63 15



SYSTÈMES DINFbRMATION ET MANAGEMENT

ble, pour ne pas faire des choixde conception erronés.Le cumul des deux aspects no-

vateurs, technique et organisation-nel, augmente les risques de fa-çon importante.

En conclusion, l'appréciation del'aspect novateur du projet sur laconduite du projet peut s'énoncerainsi. Il est majoritairement consi-déré comme important, mais sansexcès. Il a été perçu à peu près àparts égales soit comme l'introduc-tion d'un changement organisation-nel (règles de gestion, métier, ré-partition des pouvoirs et responsa-bilités), soit comme l'utilisationd'une nouvelle technique informati-que. Dans les deux cas, il introduitun risque qui doit être géré.

2.8. Critère 6: Co ninunicatlon

Description

Ce critère représente les con-traintes et exigences en matière

de communication. Dans legroupe d'experts, une divergenced'interprétation est apparue : com-munication humaine (dans legroupe de projet, entre tous lesacteurs) ou communication tech-nique ? Nous avons choisi de lais-ser l'ambiguïté pour la validation,afin d'observer les différentes posi-tions. Certaines contraintes decommunication humaine peuventavoir un impact sur la com-plexité du projet et son organisa-tion. Les contraintes de communi-cation technique peuvent Imposernormes ou standardisation.

Données

Le critère a effectivement donnélieu à deux interprétations : com-munication humaine ou communi-cation technique. Certains ontmentionné les deux sens. La ré-ponse de certains est ambiguë.

Communication humaine Communication technique Indéterminé

1847%

1335%

719%

Parmi ceux qui ont considéré lecritère comme communication hu-maine, seuls deux interviewésl'ont considéré comme peu Impor-tant. La moitié de ceux qui l'ontinterprété dans un sens techniquel'a considéré comme Important oumoyennement important. Ceux quisont restés dans l'ambiguïté ontmajoritairement considéré le cri-tère peu important.

Impacts

En ce qui concerne la commu-nication humaine, les commen-

taires ont été spontanés et abon-dants. On peut les classer ensix groupes, selon les acteursconcernés :

1. La communicationà l'intérieur de l'équipe

Le chef de projet en est respon-sable : il lui revient de l'organiseret la superviser. Il est souhaitableque chaque membre de l'équipe sesente impliqué dans le projet, res-ponsabilisé et solidaire du groupevis-à-vis du client. Pour cela, desréunions régulières et fréquentes

64 16



UNE GRILLE DANALYSE DES PROJETS SYSTÈME D 'INFORMATION

(hebdomadaires, par exemple) per-mettent de faire le point surl'avancement, de coordonner lestravaux et que chacun s'exprime.Ce type de communication com-prend également un suivi indivi-duel et inclut parfois le contrôlequalité interne. Elle doit avoir uncaractère informel. Bien menée,elle peut faire gagner du temps.Mais elle requiert une définitiondes rôles de chacun, une capacitéde communication de la part desresponsables (chef de projet, di-recteur de projet), une ouvertureaux idées nouvelles, une adhésionde l'équipe. Pour quelques-uns,des moyens électroniques (messa-gerie, groupware) sont un supportutile, mais ils doivent être assortisde règles de bonne camaraderie.

2. La communicationentre la maîtrise d'oeuvreet la maîtrise d'ouvrage

Largement mentionnée, elle ap-paraît comme devant être plusformalisée que la communicationdans l'équipe. Elle doit être défi-nie a priori, notamment dans sesprocédures (forme, fréquence...) etles rôles de chacun. Les interlocu-teurs de part et d'autre doiventêtre précisés. Par exemple : quirédige les comptes rendus, les de-mandes de modification ? Qui va-lide les livrables ? "Il faut éviterde gérer du flou". Elle doit êtreadaptée à la taille du projet, pourn'être "ni trop structurée, ni tropaléatoire" et assurer une bonnecoordination entre les différentsacteurs pour éviter des dérapages.Elle prend trois formes classi-ques : comité de pilotage, notam-ment pour suivre le planning et lebudget ; comité de projet, pourfaire le point ; réunions uti-lisateurs, notamment pour l'ana-lyse des besoins et la recette.Elle s'accompagne de documents

écrits, état d'avancement, rap-parts, etc.

3. La communicationentre l'équipe de projetet les utilisateurs

Il s'agit là d'une forme particu-lière de la communication maîtred'oeuvre - maître d'ouvrage, ayantpour objectif l'acceptation du fu-tur système. Ceux qui n'ont pascet objectif la proscrivent, considé-rant que le cahier des chargesdoit suffire. Orientée vers le chan-gement, elle se traduit par di-verses recommandations.

• Il faut vendre son projet auxutilisateurs, leur mettre l'eau à labouche, mais ensuite ne pas lesfaire attendre trop longtemps si-non ils risquent d'être déçus. Si lefutur système change de façonimportante leur façon de travail-ler, il faut leur en montrer lesavantages. Elle doit être rassu-rante, "la plus démagogique possi-ble" dit l'un des interviewés.

• Sur un projet de très grandetaille, elle peut prendre une formeplus officielle et relever d'une véri-table politique de communication,avec notamment la mise en placed'une cellule de communication,l'établissement d'un plan de com-munication, la diffusion d'un jour-nal. Cela constitue un projet ensoi.

• La communication avec lesutilisateurs, si elle porte sur l'ex-pression des besoins, prend laforme d'une démarche participa-tive. Elle est parfois quasi impo-sée par la pression des syndicats,notamment pour la réalisationd'IHM. Il faut alors présenter desmaquettes et tester l'ergonomieavant de faire les spécificationstechniques. Mais peut-être la res-ponsabilité de cette forme de com-munication doit-elle être partagée,

6517




les utilisateurs devant eux-mêmesrechercher et solliciter les infor-mations.

4. La communication externeavec les clients

Lorsque le futur système touchela forme des relations entre l'en-treprise et ses clients (par exem-ple, modification des relevés ban-caires), il apparaît utile de faireune communication avant la miseen oeuvre de la nouvelle applica-tion.

5. La communicationentre étapes

Sur des projets importants,l'équipe de projet peut être com-plètement changée, y compris lechef de projet. Par exemple,l'étude préalable est sous-traitéeà une société extérieure.

Il y a alors parfois des pro-blèmes de transfert d'une équipeà l'autre, si elles ne se rencon-trent pas. Une formalisation im-portante et précise des travaux ef-fectués en amont est alors de-mandée.

6. La communicationentre projets

Cette forme est apparue néces-saire à plusieurs interviewés, no-tamment dans les grandes struc-tures. Le chef de projet doit assu-rer la promotion de son projet au-près des autres groupes de projet.Dans certains cas, il doit y avoirune cohérence d'ensemble entreplusieurs projets. Il apparaît alorspréférable de nommer un direc-teur de projet pour assurer cettecoordination et gérer un équilibredes pouvoirs entre les différentsprojets.

En ce qui concerne la communi-cation d'un point de vue technique,

peu d'actions ont été proposées. Ilest apparu difficile de donner uneréponse générale, indépendanted'une configuration précise. Cecritère est plutôt perçu commeune contrainte : structure desmessages , infrastructures utili-sées , normes techniques, normeEDI... ou comme une spécifica-tion : communication avec d'au-tres systèmes. Il faut donc en te-nir compte dès l'étude préalable,et mettre en place les bons maté-riels et logiciels. Cependant, cettecontrainte technique peut avoirun impact sur les charges, les dé-lais et la performance du système.Elle doit donc être prise encompte lors de la planification.

En conclusion, l'appréciation dela communication sur la conduitedu projet est apparue globalementimportante à une majorité d'inter-viewés pour ce qui est de la com-munication humaine : dWérentsmoyens, formalisés et informels,sont préconisés. La communicationtechnique a été plutôt considéréecomme une contrainte ou une spé-cification.

2.9. Critère 9: Variétédes acteurs

Description

Ce critère traduit le nombre dedécideurs ou d'interlocuteurs duprojet, ainsi que leurs positionsrespectives. Ce critère est impor-tant, car un nombre élevé d'ac-teurs génère un risque de conflitset d'allongement des délais. Ainsi,si les décideurs sont nombreux,on peut avoir des objectifs contra-dictoires ou une dilution des res-ponsabilités, conduisant à uneabsence de prise de décision. Lerisque est d'autant plus grandque les décideurs sont d'un pou-voir égal. Si les interlocuteurs

6618



UNE GRILLE DANALYSE DES PROJETS SYSTÈME D1NFORMATION

sont nombreux, la définition desbesoins risque d'être éparpillée etla solution lente à se construire.La valeur de ce critère peut con-duire à une organisation et desmodalités de participation particu-lières. Selon la variété des interlo-cuteurs, on peut avoir des formesde dialogue différentes. Si la va-leur est telle que le risque est éle-vé, on pourra mettre en place uneorganisation de la maîtrise d'ou-vrage rendant possible la prise dedécision. Parfois, on pourra êtreconduit à redéfinir le champ duprojet, selon une approche parversions de l'application ou uneapproche par sous-projets menésen parallèle. Dans ce dernier cas,le découpage en sous-projets con-duira à limiter le nombre d'ac-teurs pour chacun d'eux.

Données

Ce critère n'a pas été jugé perti-nent pour les projets télécom,peut-être parce que le problèmene se rencontre guère. Certainsont distingué interlocuteurs et dé-cideurs : la multiplicité des pre-miers est apparue comme une ri-chesse, celle des seconds commeun problème. La plupart n'ont faitréférence qu'aux décideurs ; l'una d'ailleurs regretté le faible nom-bre de décideurs dans son envi-ronnement. Trois interviewés ontrestreint le critère à "variété desacteurs dans l'équipe de projet" etont préconisé une coordinationaccrue.

Impacts

Les impacts d'une grande variétéont été ainsi perçus.

• Impact sur la complexité : "Lacomplexité d'un projet est unefonction exponentielle du nom-bre d'intervenants. Les pro-blèmes de variété d'acteurs sont

plus difficiles à régler que lesproblèmes techniques". La varié-té des acteurs a été parfois liéeà la taille du projet.

• Impact sur les décisions : "Plusil y a de décideurs, moins il y ade décisions prises, car ce quiprédomine c'est l'aspect politiqueet le pouvoir, et non pas l'aspectrationnel des décisions".

• Impact sur les délais : chaquegroupe peut avoir des objectifsdifférents et opposés, les accordsentre acteurs sont difficiles àobtenir, ce qui génère des réu-nions supplémentaires.

• Impact sur la charge : celaoblige notamment à avoir unecommunication spécifique pourchaque groupe, d'où un travailsupplémentaire (même si cen'est pas toujours un facteur derisque). De plus, la constitutionde multiples groupes de travailest un frein à l'avancement.

• Impact sur la responsabilitétrop de décideurs dilue les res-ponsabilités de chacun.

• Impact sur la stabilité du projet,pour cause de conflits notam-ment.

Les actions préconisées sont lessuivantes.

Il est recommandé de prendreen compte ce facteur dès le débutdu projet, notamment dans lePlan Assurance qualité, en éta-blissant une charte d'organisationqui précise les rôles et établit undispositif de rencontres périodi-ques. Il est préférable de toutécrire et de tout faire valider.

Le chef de projet doit multiplierles contacts et mettre en placedes travaux de groupe ; il doit ce-pendant Identifier les bons interlo-cuteurs, ce qui est plus difficile siles groupes impliqués sont variés.Plusieurs préconisent d'instaurer

67 19




(contractuellement ou non) un dé-cideur unique : "Avoir plusieursmaîtres d'ouvrage, c'est commeavoir plusieurs médecins : on nesait plus lequel écouter". D'autres,au contraire, mentionnent qu'ilne faut négliger personne, maisqu'il faut chercher des terrainsd'entente et négocier avec lesresponsables.

En conclusion, l'appréciation dela variété des acteurs sur laconduite du projet est que c'est unélément important qui touche auprocessus de décision. La variétéest parfois jugée d'un risque tropimportant : il faut la réduire a prio-ri en recherchant un décideur uni-que. Sinon, le chef de projet doitrechercher un consensus et ver-rouiller les décisions.

2.10. Critère 15 : Volumeet fréquence d'utilisation

Description

Ce critère traduit le nombred'utilisateurs finals, pondéré parla fréquence d'utilisation. Parexemple, le futur système serautilisé occasionnellement par quel-ques utilisateurs, ou de façon in-tensive par un nombre réduitd'utilisateurs, ou bien l'utilisationsera occasionnelle, mais le nom-bre d'utilisateurs sera important,ou encore le futur système serautilisé intensivement par de multi-ples utilisateurs. Si les volumessont importants et la fréquenceélevée, on sera conduit à diffé-rents ajustements dans le projet.Par exemple, modifier la démarchepour introduire de l'ingénierieconcourante, les aspects techni-ques étant étudiés parallèlementaux aspects fonctionnels. On anti-cipe ainsi sur l'optimisation physi-que, par une structuration des

données intégrant les aspects vo-lumétriques et une rechercheéventuelle de répartition.

DonnéesCertains interviewés ont perçu

ce problème comme un problèmetechnique (problème d'architec-ture, particulièrement importanten client-serveur ; problème de di-mensionnement, de puissance ma-chine, de sécurisation, de réparti-tion logicielle, de nombre de ser-veurs, de choix du constructeur),pertinent dans les phases en aval(étude détaillée et réalisation). Unautre a considéré au contraireque l'étude de volumétrie devaitêtre faite dès l'étude de l'existant.

Pour certains, ce critère netouche que les projets qualifiésd"'informationnels", par oppositionaux projets dits "de gestion". L'undes interviewés a interprété le cri-tère comme une mesure de succèset d'une bonne acceptation dunouveau système. Un autre a in-diqué qu'il est plus pertinent des'interroger sur l'importance etl'utilité de l'application pour l'utili-sateur final : certains projets sontainsi "vitaux" car les utilisateursne peuvent pas s'en passer. Unautre considère que l'intérêt mon-tré par l'utilisateur est fonction dela fréquence d'utilisation.

Impacts

Les impacts perçus sont divers :exigences, avantages, choix desutilisateurs.

S'il y a beaucoup d'utilisateurs,la qualité et la fiabilité doiventêtre élevées : il faut donc davan-tage de moyens de contrôle, devérification et de test. L'ergonomiedoit être adaptée : "L'ergonomieWindows est adaptée à des opéra-tions complexes et variées, maispas à de la saisie de masse". Les

68 20



UNE GRILLE D'ANALYSE DES PROJETS S YSTÈME DINFORMATION

temps de réponse sont très impor-tants : il faut faire des bancsd'essai (benchmark).

S'il y a beaucoup d'utilisateurs,le projet sera soutenu par les ni-veaux hiérarchiques élevés. Deplus, "les bugs résiduels serontdécouverts plus rapidement". Ilfaut cependant organiser rigoureu-sement leur suivi.

Il peut y avoir un Impact surles acteurs à impliquer : "Traiterune base de données avec deuxmille utilisateurs potentiels estdifférent d'un projet de dataware-house avec trois utilisateurs quiessaient d'extraire la substantifi-que moelle d'une base de donnéesénorme".

En conclusion, les volume et fré-quence d'utilisation sont apparuspertinents mats plutôt secondaires,car s'agissant d'aspects techniques(y compris une ergonomie adaptée).

2.11. Critère 14 :Variété des oontextesd'implantation

Description

Ce critère traduit le nombre desites touchés par la future appli-cation et présentant des caracté-ristiques locales spécifiques : dif-férence technique (matériel, basede données, logiciel de base) ; dif-férence dans les données gérées(spécificités propres à chaquesite) ; différence dans l'organisa-tion (variantes de procédure).

Ce critère est important, car lavariété peut générer une chargede travail importante ; elle peutinfluer sur la façon de conduire leprojet : on peut ainsi soit opterpour une conception génériqueque l'on déclinera selon les sites,soit pour une conception sur un

site pilote, que l'on adaptera auxautres sites. Vouloir réduire la va-riété peut conduire à un travailde rapprochement informationnelet/ou organisationnel et/ou infor-matique.

Données

On peut estimer, en regard deleur expérience déclarée, que cer-tains des interviewés n'ont pasrencontré de projets donnant lieuà des implantations dans descontextes différents.

La variété a été massivementcomprise dans un sens technique.Un interviewé a toutefois soulignéque la variété pouvait aussi prove-nir du niveau de qualification desutilisateurs et de leur connais-sance d'applications antérieures,ce qui génère des besoins de for-mation différenciés. Les consé-quences de la variété des con-textes ont été perçues sous diffé-rents angles.

Impacts

La variété a un impact sur lescharges donc sur les coûts et lesdélais. En effet, elle introduitde la complexité : "Il est plus fa-cile de faire mille fois la mêmechose que dix choses différentes".Cela requiert du travail et del'énergie supplémentaires, pour te-nir compte des impossibilités dechaque site et négocier le change-ment. Il faut parfois prévoir descompétences différentes pour cha-cun des environnements. De plus,il faut savoir estimer ce critère,notamment parce que le client n'apas toujours une bonne connais-sance de son existant.

Elle est à prendre en comptedès le début, même si c'est unproblème de déploiement. Il estrecommandé d'avoir une approcheindustrielle, par exemple commen-

6921




cer par un site pilote, puis décli-ner la solution sur les autres.Pour certains, il faut réduire lavariété en standardisant l'organi-sation et/ou l'environnement tech-nique. Cela peut parfois conduireà un pré-projet de remaniementdes environnements. Pour d'au-tres, la variété nécessite de para-métrer, de construire un modèleadaptable et paramétrable : cela ades conséquences sur les coûts dedéveloppement, mais aussi sur lescoûts de maintenance.

En conclusion, l'appréciation dela variété des contextes d'implan-tation sur la conduite du projet estapparue clairement à ceux qui ontété confrontés à ce problème parti-culier, sans que son importancesoit considérée de premier ordre.

2.12. Critère 3:Réutilisation imposée

cherche de composants, effort despécialisation).

Données

Plus de la moitié des interviewésont trouvé le critère peu impor-tant, ou plus exactement ils ontrarement rencontré une obligationde réutilisation. Le plus souvent,aucun dispositif de réutilisationn'existe, parfois la politique est dene pas être lié à des composantstechnologiquement obsolètes. Cer-tains ont donné peu d'importanceau critère parce qu'ils considé-raient la réutilisation comme unespécification ou parce que le mo-dule réutilisé n'avait aucune ré-percussion sur le projet (modulesd'accès à des structures de don-nées). quelques-uns ont précisé lanature des composants à réutili-ser : application (une réponse),modules (six réponses), modèles(deux réponses), normes (une ré-ponse), progiciel (deux réponses).

Description

Ce critère indique dans quellemesure le système doit être cons-truit en utilisant des composantsexistants, c'est-à-dire par assem-blage. Il se distingue du critère 1(Reprise d'un existant information-nel) dans la mesure où l'on réuti-lise des éléments de représenta-tion ou de logiciel, et non ducontenu. On peut devoir reprendreune partie du logiciel, par exem-ple un algorithme de calcul dontles règles n'ont pas changé. Ilfaut comme ci-dessus se poser laquestion de la nature des com-posants réutilisables. Au niveaule plus élevé, il faut ranger parmiles composants les progiciels.Ce critère est important car ilpeut modifier la démarche et in-troduire des activités d'exploitationde la base de composants (re-

Impacts

La réutilisation est le plus sou-vent perçue comme source de ris-que, particulièrement dans le casde la réutilisation de modules. Eneffet :

la réutilisation implique de faireune évaluation de l'état de cha-que composant et du travailcomplémentaire. Il est souhaita-ble que la réutilisation s'appuiesur une administration des com-posants, qui en facilite l'accès etdiffuse auprès des chefs de pro-jet la connaissance sur leurexistence et leurs caractéristi-ques. Chaque composant estalors accompagné d'une docu-mentation écrite. Dans le casd'un module, celle-ci doit décrireson fonctionnement, les interfa-

7022



UNE GRILLE D'ANALYSE DES PROJETS SYSTÈME D1NF'ORMATION

çages nécessaires et les con-traintes de mise en ceuvre ;

• la réutilisation nécessite par-fois un recueil d'informationauprès d'utilisateurs, pour véri-fier l'adéquation avec les règlesde gestion.

En conclusion, l'appréciation dela réutilisation imposée sur laconduite du projet peut s'énoncerainsi. Dans la moitié des cas, au-cune réutilisation n'est imposée.Peut-être le libellé du critère a-t-ildavantage attiré l'attention sur lescontraintes et risques découlant dela réutilisation que sur les avan-tages et gains. Pour la même rai-son, peut-être a-t-on davantage as-socié réutilisation avec composantlogiciel.

2.13. Critère 2:Réutilisabilité visée

Description

Ce critère indique dans quellemesure le système doit êtreconstruit en "pièces de lego" pou-vant être ultérieurement réutili-sées. Il faut alors préciser la na-ture de ce qui sera réutilisé : mo-dèles, représentations génériques,composants logiciels à caractèrefonctionnel et lié à un métier,composants logiciels techniques,composant logiciel paramétrable...Ce critère est important car il re-présente une contrainte qui obligeà un effort de généralisation et àun découpage en composants "dé-contextualisés". Il faut égalementse demander si les règles d'ali-mentation d'une base de compo-sants existent déjà et doivent êtreprises en compte, ou s'il faut lesdéfinir.

DonnéesSeule une minorité d'interviewés

ont trouvé le critère important ettous l'ont assorti de restrictions.Ainsi, le critère est important sil'on est dans le cas d'un progiciel,ou si l'on prévoit une mainte-nance importante sur l'applicationque l'on veut alors très évolutive,ou encore si la réutilisabilité portesur des modules de type fonctiontechnique (mise en forme de mes-sage, par exemple). Dans ce der-nier cas, les réutilisations ulté-rieures étaient déjà concrètementidentifiées au moment du projet.Pour le reste, les interviewés ontaccordé une faible importance aucritère dans la mesure où ilsn'ont jamais rencontré en pratiqueune exigence de réutilisabilité,sauf pour des modèles de donnéesdont on sait à l'avance qu'ils se-ront réutilisés. Pour certains, laréutilisabilité ne concernait queles modèles de traitement et deflux, vraisemblablement parce quela réutilisation des structures dedonnées était acquise (donnéespartagées par plusieurs applica-tions). Certains ont cité une réuti-lisation de modules logiciels, maiscela n'avait pas été prévu ; il n'yavait donc rien eu de spécifique.Un tiers des interviewés a consi-déré la réutilisabilité comme diffi-cile à mettre en ceuvre, voire uto-pique. Certains appartiennent àdes structures dans lesquelles desefforts ont été entrepris pour dé-velopper la réutilisabilité. Les diffi-cultés touchent d'une part à ladéfinition de composants auto-nomes, d'une taille raisonnable (nitrop grands car ils ont moins dechances d'être réutilisés, ni troppetits car alors l'effort de re-cherche est de peu d'intérêt) ;d'autre part à l'évolution techno-logique : en effet, si le compo-sant doit faire l'objet d'une

7123



SYSTÈMES D INFORMA11ON ET MANAGEMENT

conversion technique, autant lerecréer directement.

maintenance (application fortementévolutive).

ImpactsLa réutilisabilité s'accompagne

de conditions nécessaires à samise en oeuvre.

• Il faut s'appuyer sur une struc-ture permettant de stocker lefonds commun, de gérer lamaintenance des composants,notamment des composants logi-ciels, et de définir des normespour chaque type de composant.La documentation de chaquecomposant doit être efficace,précise, détaillée. Elle doit facili-ter une compréhension correcteet rapide de la fonction du com-posant et permettre de le modi-fier. Il faut informer les autreschefs de projet à chaque créa-tion de composant.

• La réutilisabilité a un coût, carelle complexifie le travail à effec-tuer. En début de projet, il fautune réflexion sur les besoins ul-térieurs : quels éléments ? queldegré de réutilisation : tel quelou avec des adaptations ? Laréutilisabilité peut aussi consis-ter à concevoir des modules pa-ramétrables.En conclusion, l'appréciation de

la réutilisabilité visée sur la con-duite du projet peut s'énoncer ain-si. Actuellement, c'est un objectifrarement rencontré, sauf dansdeux cas. Le premier cas est celuide la réutilisation de modèles,celle-ci étant probablement possibleparce qu'une administration dedonnées a été mise en place dansl'entreprise. Le second cas est ce-lui de la réutilisation de l'appli-cation pour en faire des versionsdiérentes, que ce soit pour desclients dWérents (cas d'un pro-giciel ou équivalent), ou bienparce qu'on prévoit un fort taux de

2.14. Critère 5: Centralisationou polycentrisme

Description

Ce critère traduit les choix del'entreprise en matière de réparti-tion des capacités d'investisse-ment. Celles-ci peuvent être cen-tralisées ou, à l'inverse, de multi-ples acteurs de l'entreprise peu-vent prendre l'initiative de projetsmettant en jeu des technologiesd'information et communication.Le projet peut accompagner etconcrétiser la mise en oeuvred'une décentralisation ou bienl'entreprise cherche à mettre aupas les acteurs en leur Imposantune centralisation et le projet enest une manifestation. Ce critèrea un impact d'une part sur lesacteurs impliqués, d'autre partsur la complexité du système d'in-formation. En général, dans le casde polycentrisme, il y a davantaged'acteurs et la complexité de l'ar-chitecture globale du système d'in-formation est plus élevée. Dansles deux cas de changement, leprojet va s'accompagner d'unedéstabilisation Importante. Deplus, aller vers le polycentrismepeut générer des variantes de trai-tement, si on prend en compted'éventuelles spécificités locales.Aller vers la centralisation de-mande un effort d'intégration,voire d'homogénéisation.

DonnéesLe critère a donné lieu à des in-

terprétations diverses. De ce fait,l'appréciation de son importancerenvoie à des préoccupations diffé-rentes, selon l'interlocuteur. Lamajorité de ceux qui l'ont considé-

7224




ré comme "peu important" l'ontperçu comme sans significationpour eux. Seuls deux interviewésont compris le critère dans lesens initialement prévu : "gui dé-cide des investissements Informa-tiques?". On peut relever six au-tres interprétations du critère,avec pour chacune des actionsspécifiques.

Impacts

lre interprétation : Y a-t-il unou plusieurs maîtres d'ouvragepour le projet ?

Cette interprétation comporteune légère ambiguïté : rares ontété ceux qui ont parlé explicite-ment de capacité d'investissement.Le seul interlocuteur qui l'a fait adéclaré que suivant le financeur,l'étendue du projet pouvait être li-mitée. Mais ce même interlocuteura jugé le critère peut important. Ilen ressort deux choses : la plu-part semble s'être toujours trou-vés dans la même situation, quireste stable ; et ce qui importe auchef de projet c'est surtout de sa-voir qui va prendre les décisionset valider les orientations tout aulong du projet.

Le polycentrisme est par exem-ple rencontré dans des structuresd'une certaine taille, où chaqueDirection est responsable de sonsystème d'information et possèdeson propre budget, la mise enoeuvre et l'exploitation pouvantrester du ressort d'une directioninformatique centralisée. Les déci-deurs sont alors multiples sur lesprojets dits "transverses".

S'il y a plusieurs maîtres d'ou-vrage, il faut mettre en place unestructure de travail, de décision etd'information. Une telle organisa-tion a des conséquences sur lescoûts. En effet, d'une part, il faut

davantage de communication versles maîtres d'ouvrage, d'autrepart, il faut gérer les spécificitésde chaque groupe. Il faut bienidentifier les acteurs importantspour chaque maîtrise d'ouvrage,car il peut être difficile de trouverle bon interlocuteur sur un pointprécis. C'est alors un facteur défa-vorable pour le projet, provoquantde multiples dépendances. Enfin,il est préférable de détermineravant le début du projet commentseront répartis les coûts.

S'il y a centralisation, l'enve-loppe budgétaire est décidée parune Direction centrale (ou Direc-tion générale), cela introduit uncadre plus rigide.

2e interprétation : Est-ce quele futur système d'information vamodifier l'organisation ? Cette in-terprétation rejoint, mais sur lepoint précis de l'organisation, lecritère 4 (Aspect novateur du pro-jet). L'attention a surtout été por-tée sur le cas d'un changementd'organisation, cette situationétant reconnue comme parfois né-cessaire pour s'adapter aux de-mandes du marché. "On demandeaux cadres d'être flexibles etadaptables. Une organisation s'ap-puyant sur de tels cadres doitdonc être aussi flexible et chan-geante".

Le système d'information doitdonc comporter de la souplesse etpouvoir s'adapter à des évolutionsd'organisation. La modularité peutêtre un moyen de s'adapter plusfacilement.

La conduite du changement doitêtre prise en compte dès le début,car elle peut avoir un impact fi-nancier non négligeable, notam-ment par les formations à assu-rer. Le changement est parfois unfacteur de mobilisation des ac-

7325




teurs : qu'ils considèrent le chefde projet comme un ennemi ouquelqu'un dont il faut se faire unallié, les acteurs concernés ne sedésintéresseront pas du projet.

Se interprétation : Est-ce quele projet comporte un ou plu-sieurs centres de décision, enten-dus comme plusieurs maîtresd'oeuvre ?

Une organisation centralisée estla plus pratiquée et semble êtreprivilégiée. Certains considèrentqu'il y a toujours centralisation,au moins sous la forme d'un Co-mité de projet ou Comité de pilo-tage. "Pour réussir, un projet doitavoir un centre fort", même sicertaines capacités de décisionpeuvent être partiellement délé-guées : "Si les centres de décisionsont très dispersés, ce n'est pasla peine de commencer un projet".

Si l'organisation du projet estdécentralisée avec plusieurs maî-tres d'oeuvre, les décisions serontplus difficiles à prendre, ce qui al-longera les délais. Il est souhaita-ble de fixer des limites, de définircontractuellement les rôles et res-ponsabilités de chaque groupe(notamment si l'on travaille avecdes sous-traitants) : livrables,planning, avancement, points derencontre obligatoire. Sinon, cha-cun peut justifier son échec parcelui de l'autre ; ou bien on peuts'attendre mutuellement. Par ail-leurs, il y a un risque de ne plusavoir de vue synthétique, de vued'ensemble du projet ; les diffé-rents responsables d'équipe ontsouvent une fonction plus admi-nistrative que technique, ce qui li-mite ou oriente l'information qu'ilspeuvent apporter pour reconsti-tuer cette vue d'ensemble.

4e interprétation : L'architec-ture technique est-elle ou noncentralisée ?

Si elle est décentralisée, il fauts'intéresser dès le début, voireavant le démarrage effectif du pro-jet, à la "géographie de l'utilisa-tion du système d'information",c'est-à-dire vérifier qu'il y a lesbon tuyaux pour faire communi-quer tout le monde. La décentrali-sation technique est plus com-plexe à mettre en oeuvre et ra-joute un facteur de risque dû àl'hétérogénéité du matériel et desprotocoles et à la multiplicité desInterlocuteurs.

Si le choix n'est pas fait, il fautproduire deux devis complets,avec les avantages et Inconvé-nients de l'une et l'autre solution.

Se interprétation : Prévoit-onun ou plusieurs sites d'implanta-tion pour la future application In-formatique ? Cette interprétationest en fait le sens attribué au cri-tère 14 (Variété des contextesd'implantation).

Les recommandations sont ana-logues : Il est souhaitable de tra-vailler en choisissant un site pi-lote, sur lequel se fera la premièreimplantation ; il faut planifier lesdifférentes implantations. Il nefaut pas surestimer les économiesd'échelle que pourrait apporter laréutilisation de l'application, carla complexité et le paramétrage dechaque. installation génèrent uncoût pour chaque site.

6e interprétation : Comment lebudget doit-il est alloué au pro-jet : globalement ou pour chaqueétape du projet ?

Cette interprétation attire l'atten-tion sur le fait que si l'enveloppebudgétaire est strictement limitéeet qu'elle est allouée en un seul

7426



UNE GRILLE D'ANALYSE DES PROJETS SYSTÈME DINF ORMATION

bloc, il appartient au chef de pro-jet de la répartir sur les diffé-rentes étapes, faute de quoi il severra contraint d'amputer le tra-vail des dernières étapes, pour in-suffisance de ressources.

En conclusion, l'appréciation ducritère centralisation ou polycen-trisme sur la conduite du projet estliée aux dWérentes interprétations :nombre de maîtres d'ouvrage, or-ganisation cible, nombre de maî-tres d'oeuvre, forme de l'architec-ture technique, nombre de sitesd'implantation, mode d'allocationde l'enveloppe budgétaire. Il estnécessaire pour nous de revoir sapertinence et sa formulation.

2.15. Critère 11 :Balance besoins/offre

Description

Ce critère répond à la questionsuivante : le projet est-il guidéprincipalement par une expressiondes besoins ou par une offre tech-nologique existante ? Nous appe-lons "offre" un composant de lasolution disponible et utilisable enl'état. Ce peut être par exempleun produit de groupware ou unemessagerie électronique. Ce critèreest important, car selon le cas laconception doit partir soit des be-soins soit de l'offre. S'il n'y a pasd'offre dominante, on peut avoirindifféremment une approche parles besoins ou par l'offre. Si onest dans le cas d'une offre domi-nante, on suppose que l'usage del'outil devrait générer le besoin aposteriori. Dans le cas de besoinsdominants, il peut soit n'y avoiraucune solution sur étagère, ou lavolonté de ne pas utiliser unetelle solution. Dans le cas d'équili-bre, le besoin exprimé pourra êtrecouvert en partie ou en totalité

par des solutions disponibles quel'on envisage de considérer (progi-ciels ou composants réutilisables).

Données

Plus de la moitié des interviewésont considéré qu'il y avait tou-jours des besoins, ce qui expliqueen grande partie le peu d'impor-tance accordé au critère. Certainsont considéré que c'était générale-ment un compromis ou un équili-bre à rechercher (cas de progiciel,notamment). L'un a suggéré deparler plutôt de "Degré de libertéentre offre et besoins". L'un desinterviewés a interprété "Le projetcorrespond-il à un besoin chez leclient final ou faudra-t-il le fairenaître ?".

Pour un projet télécom, une ap-proche par l'offre correspond à unprojet standard, c'est-à-dire unprocessus connu, rapide, au coûtdéfini ; dans une approche parles besoins, il s'agit d'un contratsur mesure, qui nécessite un ca-hier des charges.

Impacts

Si l'offre est dominante, il fautparfois convaincre le client, il fautsusciter l'intérêt ; c'est ce qu'onobserve notamment pour l'utilisa-tion des technologies internet. Al'inverse, l'existence d'une offrepeut parfois faciliter un projet ; ilest recommandé de partir desfonctionnalités offertes (cas d'unprogiciel), mais il faut arriver àune expression des besoins, avecun aspect contractuel, si l'on veutfaire une recette.

Si les besoins sont dominants,le respect des délais est plus im-portant. Parfois les besoins résul-tent de l'observation de nouveauxservices chez les concurrents.

7527



SYSTÈMES D INFORMATION ET MANAGEMENT

En conclusion , le critère Balancebesoins/offre a été perçu commesecondaire par la majorité, peut-être en raison d'une interprétationimmédiate : "Il y a toujours desbesoins". Cependant, pour les in-terviewés familiers des progiciels,des technologies Internet ou desprojets télécom, ce critère a été cor-rectement compris. Chez ces der-niers, une recherche de compromisentre les deux approches est alorsfortement apparue.

2.16. Critère 12: Granularité

DescriptionCe critère Indique la nature des

travaux à effectuer par le projet :étude globale, étude détaillée, dé-veloppement... La granularité re-présente le niveau des élémentsque l'on étudie. Ce critère n'a desens que si l'on appelle "projet"tout ou partie des travaux de dé-veloppement de système d'infor-mation qui vont de l'idée initiale àla mise en oeuvre de l'application.Il peut prendre des valeurs cor-respondant aux étapes du cyclede vie d'un projet complet, chaqueétape donnant lieu à un projet.La granularité indique le niveaude dialogue et décision auquel sesitue le projet : les Interlocuteurset la nature des choix à faire va-rient en conséquence.

Données

Vingt-quatre personnes ont dé-claré explicitement ou par absencede réponse ne pas avoir comprisla signification du critère. Neufl'ont interprété comme "la nécessi-té de faire des étapes dans unprojet". Quelques-uns ont déclarén'avoir l'expérience que d'uneétape.

ImpactsLes actions associées ont été

peu nombreuses.Plus on est en amont dans le

cycle de -vie du projet, plus il y ad'incertitude ; on est dans le flouaussi bien en ce qui concerne lesobjectifs que pour ce qui est dudélai et des coûts. Les utilisateursdoivent être d'autant plus im-pliqués car les décisions sontcapitales.

Par ailleurs, selon l'étape du cy-cle de vie, des compétences diffé-rentes sont requises, on n'aurapas les mêmes acteurs et onn'utilisera pas la même méthode.Par exemple, pour un schéma di-recteur, on utilise surtout la tech-nique des interviews.

En conclusion, le terme granulari-té a été très mal compris. Quel-ques relations entre étapes et con-duite de projet (organisation, mé-thodes, choix d'acteurs...) ont tou-tefois été esquissées. Nous allons,comme pour le critère 11, revoir sapertinence et son expression.

CONCLUSION

En conclusion, la grille a étéglobalement validée et la majoritédes critères jugés pertinents. Cer-tains critères ont cependant étémal compris ou ont donné lieu àdes interprétations diverses. Au-cun critère supplémentaire dediagnostic n'a été suggéré. A lasuite de cette recherche, nousavons affiné -la grille d'analyse etfait apparaître des regroupementsde critères représentant différentspoints de vue sur le projet (pointde vue du maître d'oeuvre, pointde vue du maître d'ouvrage, con-texte... ). Par ailleurs, tous les en-quêteurs ont été bien reçus et la

7628




démarche de formalisation d'unegrille a suscité un grand intérêt,qui peut s'expliquer de la façonsuivante. Les connaissances deschefs de projet sont souvent ta-cites, donc difficiles à transmettre.C'est principalement sur le terrainqu'elles s'acquièrent, par socialisa-tion (Reix, 1995). L'expérience per-sonnelle ou les directives Impo-sées occupent ainsi une place ma-jeure dans les décisions méthodo-logiques prises sur un projet. Parexemple, seuls quatre chefs deprojet sur trente-sept ont men-tionné l'existence d'une grilled'analyse en vue de choix métho-dologiques. Compte tenu de la du-rée moyenne des projets - un àdeux ans - et de la variété possi-ble, l'expérience s'acquiert lente-ment. L'enquête fait donc apparaî-tre l'attente d'un moyen permet-tant d'augmenter plus rapidementla compétence du chef de projet,c'est-à-dire sa capacité à com-prendre des situations complexeset à agir en conséquence. Cecinous encourage à poursuivre letravail de recherche sur les deuxaxes prévus : d'une part établirune liste de composants méthodo-logiques et leur associer des sa-voirs existants ; d'autre part, met-tre en relation certaines valeursremarquables des critères de notregrille et l'utilisation de certainscomposants méthodologiques.

RÉFÉRENCES

Adam, F. et Fitzgerald, B. (1998),« Nouveaux regard sur les méthodolo-gies d'analyse, de conception et deprogrammation informatique », Sys-tèmes d'Information et Management,Vol. 3, n° 2, p. 5-22.

Ahituv, N., Hadass, M. et Neumann,S. (1984), «A Flexible Approach to In-formation System Development », MISquarterly, juin.

Amadeus, (1987), Projet du pro-gramme ESPRIT - Software TechnologySubprogram.

Barka, H., Rivard, S. et Talbot, J.(1994) « Des projets de développementde système d'information horscontrôle, un énoncé exagéré ? », Actesdes quatrièmes rencontres des équipesde recherche francophones en systèmed'information, Poigny la Forêt, 20 et21 juin.

Bennatan, E.-M. (1995), Manage-ment des projets informatiques,AFNOR, Paris.

Bouzeghoub, M., Gardarin, G. etValduriez, P. (1995), Objets, Eyrolles,Paris.

Burrel, G. et Morgan, C. (1993),Sociological paradigms and organisa-tional analysis, Arena, Aldershot.

Davis, G.B., Olson, M.H., Ajenstat,J. et Peaucelle, J.-L. (1986), Systèmesd'Information pour le Management,2 vol., Editions Economica, Paris.

Eurométhode (1996), Manuel d'utili-sation, version 1, Commission Centraledes Marchés, Paris.

Fitzgerald, B. (1996), « Formalizedsystems development methodologies :a critical perspective », InformationSystems Journal, Vol. 6, n° 1, p. 3-23.

Galliers, R.D. (1991), < (Choosing Ap-propriate Information Systems Re-search Approach : a Revised Taxono-my » in Information Systems Re-search : Contemporary Approachesand Emergent Traditions, H.E. Nissen,H.K. Klein et R. Hirschheim, NorthHolland, Amsterdam, p. 327-345.

Gibson, R. (1994), Conduite des pro-jets informatiques, Masson, Paris.

Girling, R. et McManus, J. (1988),« The Future of Software Developmentin Large Organisations ? », Manage-ment Services, avril et mai, p. 16-19.

Hughes, J., Leblanc, B. et Morley,C. (1996), RAD, une méthode pour dé-velopper plus vite, InterEditions, Paris.

ISI, (1994), Ingénierie des systèmesd'information, numéro spécial «L'ingé-nierie des besoins », Vol. 2, n° 6.

Kettani, N., Mignet, D. Paré, P. etRosenthal-Sabroux, C. (1998), DeMerise à UML, Eyrolles, Paris.

7729




Le Moigne, J.-L. (1986), « Intelli-gence et conception » in Intelligencedes mécanismes , mécanismes de l'in-telligence, J.-L. Le Moigne (éd.) Fon-dation Diderot, Fayard , Paris.

Martinet , C.-A. (1996), « Penséestratégique et rationalités . Un examenépistémologique », URA CNRS 1257,papier de recherche n° 23.

McFarlan , F.W. (1981 ), « PortfolioApproach to Information Systems »,Harvard Business Review, sept.-oct.

Muller, P.-A. (1997), Modélisationobjet avec UML , Eyrolles, Paris.

Panet, G. et Letouche , R. (1994).Merise/ 2, Ed. Organisation , Paris.

Reix, R . ( 1995), « Savoir tacite et sa-voir formalisé dans l'entreprise », Re-

vue française de gestion , septembre-octobre, n° 105, p. 17-28.

Reix, R. (1995b), Systèmes d'infor-mation et management des organisa-tions , Vulbert, Paris.

Reix, R. (1995e), « Etat de l'Art Sys-tème d'information », Colloque desIAE.

Stapleton, J. (1997), DSDM, dyna-mic system development method, Addi-son Wesley, Harlow.

Tabourier, Y. (1996-97), Comptesrendus du Groupe 135, AFCET.

Wastell, D.G. (1996), « The fetish oftechnique : methodology as a socialdefence », Information Systems Jour-nal, Vol. 6, n° 1, p. 25-40.

7830



une grille d'analyse des projets systÃ¨me d'information

Documents