management des projets informatiques : complexitÃ© et

Systèmes d'Information et Management

Volume 1 | Issue 1 Article 2

1996

Management des projets informatiques :complexité et gestion des conflitsRolande MarciniakCNAM - Institut d'Informatique d'Entreprise, [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 CitationMarciniak, Rolande (1996) "Management des projets informatiques : complexité et gestion des conflits," Systèmes d'Information etManagement: Vol. 1 : Iss. 1 , Article 2.Available at: http://aisel.aisnet.org/sim/vol1/iss1/2

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

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

http://aisel.aisnet.org/sim/vol1/iss1?utm_source=aisel.aisnet.org%2Fsim%2Fvol1%2Fiss1%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol1/iss1/2?utm_source=aisel.aisnet.org%2Fsim%2Fvol1%2Fiss1%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

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

http://aisel.aisnet.org/sim/vol1/iss1/2?utm_source=aisel.aisnet.org%2Fsim%2Fvol1%2Fiss1%2F2&utm_medium=PDF&utm_campaign=PDFCoverPages

mailto:[email protected]%3E

Managementdes projets informatiques :

complexité et gestion des conflits

Rolande MARCINIAK,CNAM - Institut d'Informatique d'Entreprise

RÉSUMÉ

Cet article propose une approche, inspirée des théories de la complexité, pour unemeilleure compréhension du déroulement des projets informatiques.

Cette approche a été soumise à une vérification empirique sur un échantillon de vingtquatre projets d'informatique de gestion et de mille répondants (utilisateurs, informati-ciens, responsables utilisateurs et informaticiens).

La gestion des conflits constitue le pivot du modèle, dans la mesure où l'ensemble desautres variables transitent par les modes de résolution des conflits.

Mots-clés : Projets informatiques - Efficacité - Méthodes complexes - Gestion des conflits.

ABSTRACT

An empirical and longitudinal study of software development projects was undertakento investigate different paradigm . Effectiveness is a multidimensional concept and ope-rates as a paradox. Conflict management is important and conflict resolution can condu-ce to, or reduce effectiveness.

Key words : Project management - Conflict management - Effectiveness - Complexity.

REMERCIEMENTS

Cette recherche a reçu le soutien financier des organismes suivants :

- Centre National de la Recherche Scientifique (CNRS - PIRTTEM).

- Comité Interministériel pour l'Informatique et la Bureautique dans l'Administration

(CI IBA).

- Fondation Nationale pour l'Enseignement de la Gestion (FNEGE).

271

Marciniak: Management des projets informatiques : complexité et gestion des

Published by AIS Electronic Library (AISeL), 1996

SYSTÈMES D'INFORMATION ET MANAGEMENT

1. INTRODUCTION

Les projets informatiques consti-tuent des enjeux importants enraison des coûts d'investisse-

ment engagés, et de l'impact potentieldes nouvelles technologies de l'infor-mation sur les structures et les straté-gies organisationnelles.

Selon la norme X-50-105 (Afnor,1994), un projet se définit comme unedémarche spécifique, qui permet destructurer méthodiquement et pro-gressivement une réalité à venir. Unprojet est caractérisé tout d'abord parla satisfaction d'un besoin spécifiqueet particulier, ensuite par un objectifautonome, en ce sens que tout projet aun début et une fin, enfin par uncaractère novateur, au moins partielle-ment (technique, géographique, orga-nisationnel, etc.). Les projets « infor-matiques » concernent le développe-ment d'un logiciel ou d'un progiciel, lamise en place de systèmes informa-tiques (matériels, réseaux, logiciels debase...), ou de solutions intégrant lesaspects matériels et logiciels'.

Constatant la difficulté à mesurer larentabilité des investissements logi-ciels, du fait notamment de gainsattendus indirects ou qualitatifs visantà améliorer la gestion, ainsi que lasempiternelle dérive des délais et bud-gets préétablis, les professionnels ontproposé des méthodes pour mieuxgérer les processus d'informatisation.Ces méthodes peuvent être regrou-pées en trois catégories, selon qu'ellesvisent à estimer les délais et lescharges, conduire les activités de pro-jet, ou concevoir les systèmes d'infor-mation. Deux caractéristiques essen-

tielles doivent être retenues à leur pro-pos : tout d'abord, l'évolution perma-nente des concepts, techniques etoutils sur lesquels s'appuient cesméthodes, ensuite, le fait qu'ellesconstituent, au mieux, des conditionsnécessaires mais pas suffisantes de laréussite des projets informatiques. Cesdeux caractéristiques contribuent àcomplexifier les projets informa-tiques.

Les recherches menées dans lemonde académique, ont vu, pendantlongtemps, s'affronter deux approchesde l'informatisation des organisations :le déterminisme organisationnel et ledéterminisme technologique.

Les résultats de ces études détermi-nistes s'étant avérés contradictoires etambigus, une approche, privilégiantl'interaction dynamique des facteurs,remet en cause ces fondements déter-ministes. D'une part, selon cetteapproche, le comportement desacteurs participant directement ouindirectement à un projet informa-tique ne peut pas être prédit de maniè-re certaine, aussi le déterminismeorganisationnel rencontre-t-il desérieuses limites d'applicabilité.D'autre part, il existe une imprévisibi-lité relative de la technique, aussi lestenants de l'interaction dynamiquejugent le déterminisme technologiqueinsuffisant pour expliquer les résultatsd'une informatisation. Ce processusest le résultat d'interactions com-plexes et imprévisibles entre descontraintes externes liées à la techno-logie, des facteurs structurels et desmotivations ou rationalités indivi-duelles. Pour démontrer la validité dece point de vue le courant de l'interac-

1. Dans une visée plus complète on notera qu'un projet informatique peut être une composante(un sous-projet) d'un projet plus vaste, comme c'est le cas dans les projets concernant les systèmesd'armement, ou le développement de nouveaux produits financiers.

282

Systèmes d'Information et Management, Vol. 1 [1996], Iss. 1, Art. 2

http://aisel.aisnet.org/sim/vol1/iss1/2

MANAGEMENT DES PROJETS INFORMATIQUES . COMPLEXITÉ ET GESTION DES CONFLITS

tion dynamique s'est focalisé sur desétudes de cas, un seul projet étudié àla fois, et sur l'utilisation ou non, parles utilisateurs, du nouveau systèmeinformatique.

Or le critère adoption (versus rejet)de l'outil informatique ne reflètequ'une vision partielle de la réussite(versus échec) d'un projet informa-tique ; d'autres critères ont retenu l'at-tention des professionnels et ont étéévoqués ci-dessus. De plus le critèreadoption (versus-rejet) devient inadé-quat lorsque l'utilisation du nouveloutil est rendue obligatoire ; il peuts'imposer aux pratiques de travail desutilisateurs parce qu'il contient et gèretoutes les règles de gestion et d'orga-nisation, ou bien parce qu'il s'intègreà d'autres systèmes d'informationautomatisés.

Pourtant l'approche de l'interactiondynamique', par la synthèse qu'ellepropose de la dialectique déterminis-te, et les méthodes mises au point parles professionnels', par la variété etl'imbrication des critères de réussite(versus échec) proposés, poussent larecherche sur les projets informa-tiques vers les méthodes de la penséecomplexe. L'hypothèse générale peutêtre ainsi formulée : les méthodescomplexes devraient permettreune compréhension plus précise,d'une part des processus d'enchevê-trement des différents éléments,acteurs, technologie et structures, etd'autre part de la multidimensionnali-té des résultats atteints, à leur issue,par les projets informatiques.

Dans une première partie, cet articleconstruit les prémisses d'uneapproche de la complexité des projets

informatiques, en structurant desconcepts dans un modèle théorique,et propose une série d'hypothèses àvalider. La deuxième partie, consacréeà la validation des hypothèses, décritet justifie la méthodologie d'enquêteretenue, et présente et argumente lesrésultats obtenus sur vingt-quatre pro-jets d'informatique de gestion. Enconclusion sont abordées les formespossibles d'appropriation des résul-tats de ce travail, exploratoire, par lesprofessionnels.

2. MODELEDE LA COMPLEXITEDES PROJETSINFORMATIQUES

Les ingrédients de la pensée com-plexe se prêtent mal au découpageanalytique, notamment du fait de leurimbrication mutuelle. Aussi, présente-rons-nous tout d 'abord, les conceptsutilisés, selon la séquence de leurapparition dans le processus de créa-tion de notre modèle , dont la sourced'inspiration provient des épistémolo-gies de la pensée complexe (Morin,1990). Nous pourrons ensuite déve-lopper l ' argumentation relative auchoix de ces concepts pour l'étudedes processus d'informatisation.

2.1.Genèse du modèlede la complexitédes projets informatiques

La première notion à laquelle nousnous sommes attachés est celle demutidilnensionnalité , dont trois direc-

2. Cf. la bibliographie détaillée des courants de recherche sur les processus d'informatisation(Marciniak, 1991).

293




tions ont été poursuivies : multidi-mensionnalité des résultats, desacteurs, et des processus d'un projetinformatique. Chacune de ces troisdirections a été investiguée ; cheminfaisant, la réflexion faisait émergerd'autres concepts ou notions, dont onargumentera plus loin l'intérêt pournotre champ de recherche ; nous nousattacherons dans cette partie à lesénumérer.

Tout d'abord, la multidimensionnali-té des résultats d'un projet informa-tique nous a conduit à remonter auconcept de l'efficacité organisation-nelle et à en déduire les implicationsessentielles pour le contexte de notreétude ; la notion complémentaire deparadoxe s'est avérée absolumentnécessaire à la compréhension duconcept d'efficacité. L'aboutissementde cette direction de la multidimen-sionnalité a consisté à définir plu-sieurs variables dépendantes ou àexpliquer (différents critères de laréussite des projets informatiques), età poser des hypothèses sur la variétédes variables expliquant cette réussitemultidimensionnelle.

Ensuite, la multiplicité et la variétédes acteurs se manifestent inévita-blement par des rationalités (percep-tions, inférences, évaluations...) diffé-rentes, pouvant diverger voire s'op-poser, sur le déroulement et lesissues d'un projet informatique.Aussi cet aspect de la multidimen-sionnalité nous a-t-il dirigé vers laproblématique des rationalités desacteurs. Cette réflexion aboutit àaccorder une place centrale auxconflits survenant dans les projets

informatiques, et à poser une séried'hypothèses relatives à leurs diffé-rents modes de gestion.

Enfin, la multiplicité des processus'(Lorino, 1991) implique des décou-pages (sous-systèmes) du projetmais aussi des unités (autres sys-tèmes) dans lesquelles s'insère toutprojet informatique. Les critères dedécoupage d'un projet sont variés :le temps (découpage en phasesséquentielles remis partiellement encause par l'ingénierie simultanée),les activités (découpage selon lescompétences spécifiques requises),le produit (découpage en lots fonc-tionnels), etc. Pour cette troisièmedirection de la multidimensionnalité,nous avons adopté la perspectivesystémique d'imbrication de sys-tèmes4. Les processus constituentainsi les variables explicatives denotre modèle, et leur enchaînementtemporel fonde la dynamique denotre modèle.

La genèse de notre modèle vientd'être brossée à grands traits, nousallons maintenant reprendre, pourargumenter nos choix, chacun despoints suivants :

- tnultidimensionnalité et para-doxes de l'efficacité des projetsinformatiques,

- la gestion des situations conflic-tuelles dans les projets informa-tiques,

- la temporalité, l'imbrication deprocessus et l'écosystème desprojets informatiques.

3. On entend par processus : une organisation matérielle de personnes, matières, énergie, équi-pements et procédés en activités conçues pour produire un résultat final spécifié.

4. Elle est largement illustrée dans les manuels par l'analogie des poupées gigognes.

304



MANAGEMENT DES PROJETS INFORMATIQUES : COMPLEXITÉ ET GESTION DES CONFLITS

2.2.Multidimensionnalité etparadoxes... de l'efficacité

Le concept d'efficacité organisation-nelle ne peut pas être ignoré en dépitde l'ambiguïté qui l'entoure ; empiri-quement il demeure l'ultime variabledépendante de toute recherche ; auniveau de l'action, les différentes par-ties prenantes d'une organisation,clients, fournisseurs, salariés, diri-geants, propriétaires..., sont continuel-lement confrontés au problème deson évaluation. La multidimensionna-lité de ce concept a été démontréeet validée par de nombreusesrecherches (Montebello, 1976, Quinnet Rohrbaugh, 1983). L'efficience estune notion qui recouvre l'aptitude àminimiser les coûts de transformationd'intrants en produits acceptables.Selon le point de vue adopté, quantaux résultats, trois catégories d'effi-cience sont distinguées : économique,sociale et technique ; chacune d'entreelles est mesurée par des critères spé-cifiques.

L'efficience économique comparedes intrants et des extrants en termesde coûts. Lorsque la quantificationdes gains de l'informatisation est pos-sible, l'efficience économique du pro-jet informatique est obtenue par le cal-cul des ratios de choix d'investisse-ment. Certains critères d'efficienceéconomique ne concernent qu'unsous-ensemble d'intrants et d'extrants ;la productivité de l'équipe de projetinformatique par exemple, mesuréepar le ratio nombre de lignes sourcesproduites par la charge effectivementconsommée en jours-homme, a étéutilisée dans l'évaluation des projetsinformatiques ; l'interprétation de cesratios de productivité nécessitecependant un certain nombre de pré-cautions pour éviter des paradoxes,

liés aux effets du langage de program-mation utilisé, aux définitions deslignes de code...

L'efficience sociale est définie parl'intégration, l'implication et l'atteintedes objectifs personnels de chaquemembre de l'organisation. En ce quiconcerne les projets informatiques ondoit distinguer l'efficience sociale duprojet et celle du logiciel installé et uti-lisé à l'issue du projet. La premièreconcerne le point de vue desmembres de l'équipe, dans quellemesure le projet a constitué une expé-rience professionnelle enrichissanteet motivante. La seconde se place dupoint de vue des utilisateurs du logi-ciel, dans quelle mesure l'utilisationde ce dernier contribue à l'améliora-tion de leurs conditions de travail.

L'efficience technique est définiecomme l'aptitude à produire desbiens en quantité et qualité accep-tables. Pour notre propos il s'agira dela qualité du logiciel en termes de fia-bilité, pertinence, utilité des informa-tions, temps de réponse, facilité dedialogue et d'accessibilité...

Une autre facette de l'efficacité, lacapacité à atteindre des objectifs ou« l'effectivité », fait référence à des esti-mations préalables, à des buts. Il s'agitalors des gains obtenus, comparés auxgains attendus, grâce à l'utilisation dulogiciel, mais aussi de la réalisation duprojet dans des limites temporelles etfinancières préalablement définies.

D'autres études ont démontré lecaractère paradoxal du concept d'effi-cacité (Cameron, 1986, Lewin etMinton, 1986). L'efficacité est ainsi per-çue de manière différente selon lesindividus. Le consensus sur unensemble suffisant de critères estimpossible à atteindre dans la mesureoù les valeurs et les préférences indivi-

315




duelles sont différentes voire contra-dictoires, difficiles à identifier par lesindividus eux-mêmes, et variablesselon le temps. Les réussites (versuséchecs) d'un projet informatique pour-ront donc être perçues différemmentselon que l'on est responsable utilisa-teur, utilisateur final ou usager, respon-sable informatique, ou membre del'équipe de projet...

Le paradoxe provient aussi du faitqu'une organisation efficace doit pos-séder des attributs variés, contradic-toires, voire mutuellement exclusifs etopérant simultanément, tout en ne serenforçant pas. Ainsi en est-il du res-pect des délais qui peut entrer enconflit avec la qualité du logiciel etl'efficience sociale du projet, car sacompression peut imposer une ergo-nomie de logiciel minimale et desconditions de travail trop stressantespour l'équipe.

On peut donc s'attendre à l'émer-gence de paradoxes dont on devratenter l'interprétation : des variablesdéterminantes différentes selon lesindicateurs d'efficacité, l'interventioncontradictoire d'une même variabledéterminante, le rôle non linéaired'un prédicteur dont l'intensité pro-voque, à un certain seuil, l'inversiondu sens de son intervention.

Dans la mesure où les études rela-tives aux processus d'informatisationne s'étaient intéressées qu'à un seulcritère de réussite des projets infor-matiques et qu'à un seul point de vue,il apparaissait tout à fait opportund'amorcer une recherche intégrantmultidilnensionnalité et antagonismeparadoxal. Aussi avons-nous intégréces aspects dans notre modèle et dansnos hypothèses. Nous avons ainsiadopté trois critères d'efficience (éco-nomique, sociale et technique) et trois

critères d'efficacité (gains organisa-tionnels, aide à la décision fournie etdélai de mise en place). Chaque critè-re se décompose en indicateurs (cf.annexe A, tableau des variablesdépendantes ).

Le paradigme de la multidimension-nalité et des paradoxes de l'efficacitésera soumis à la validation des hypo-thèses suivantes :

- Hypothèse 1Multidimensionnalitéde la réussite« Chaque variable à expliquer (cri-tère de réussite) constitue unconcept particulier de l'efficacité-efficience, aussi l'agrégation descritères n'a aucune signification ;de plus la réussite sur chacun descritères est obtenue de manièrespécifique, c'est-à-dire que lesvariables explicatives de chaquecritère différent ».

- Hypothèse 2Paradoxedes variables explicatives

« Les variables explicatives peu-vent à la fois favoriser la réussitedes projets sur un critère et lacontrarier sur un autre critère ».

- Hypothèse 3Paradoxe des perceptionsde la réussite« Les perceptions de la réussitedes projets informatiques varientselon les acteurs ».

Récemment, l'approche multidi-mensionnelle s'est développée dansles recherches sur les systèmes d'in-formation. Notre approche se diffé-rencie de ces études sur les troispoints suivants :

- nous nous focalisons sur le dérou-lement et les résultats des projetsinformatiques, alors qu'un certain

326



MANAGEMENT DES PROJETS INFORMATIQUES • COMPLEXITÉ ET GESTION DES CONFLITS

nombre d'auteurs s'intéressent,aux effets sociétaux ou macro-éco-nomiques de l'informatisation(Brynjolfsson, 1994, Brynjolfssonet al., 1994, Hitt et Brynjolfsson,1994 a, Hitt et Brynjolfsson, 1994 b,Brynjolfsson, 1993), ou bien à laperformance de la fonction infor-matique dans les organisations(Scott, 1994, Rowe, 1994) ;

nous avons adopté une approcheplus complète de la multidimen-sionnalité dans notre modèle (résul-tats, acteurs, processus) alors qu'unseul aspect multidimensionnel estpris en compte dans les études foca-lisées sur les processus d'informati-sation (Barki et Hartwick, 1994,Delone et Mclean, 1992, Mahmoodet Mann, 1991, Nissen, 1994),

nous accordons une place centra-le aux modes de gestion desconflits, variable dont le rôle dansles projets informatiques n'a, dumoins à notre connaissance,jamais été étudiée. Aussi allons-nous maintenant nous attacher àdémontrer l'importance et la per-tinence du recours à la gestiondes conflits pour étudier et com-prendre le déroulement des pro-jets informatiques.

2.3.La gestion des conflitsconductrice et réductricede la réussite des projetsinformatiques

2.3.1. Des rationalitésdifférentes... et des conflits...inévitables

Les projets informatiques se compo-sent d'activités impliquant la mise enoeuvre de savoir-faire techniques spé-cifiques et requièrent des compé-

tences variées, c'est-à-dire qu'ils néces-sitent l'intervention et la coordinationd'acteurs multiples. Or cette différen-ciation organisationnelle des partici-pants d'un projet, verticale ou hiérar-chique, horizontale ou division socia-le du travail, mais aussi contractuelledans le cas du développement exter-ne, a une incidence sur l'émergencedes désaccords. En effet, selon leurposition, les acteurs ont accès à desinformations différentes et de ce faitsont conduits à interpréter distincte-ment les problèmes posés, et à envisa-ger des solutions qui peuvent êtredivergentes. La différenciation organi-sationnelle constitue donc une sourcepotentielle importante des conflits.

La réalisation des différentes tâchesimplique une forte interdépendancedes acteurs ; or celle-ci peut donnerlieu à des perceptions de manoeuvresd'obstruction, réelles ou imaginaires,c'est le cas notamment lorsque lesinformaticiens se plaignent de leurdifficulté à obtenir des informationsde la part des responsables utilisa-teurs.

De plus le partage de ressourceslimitées contribue à renforcer l'incom-patibilité des objectifs et à encouragerles rivalités ; on rencontre fréquem-ment ce phénomène entre les diffé-rentes équipes informatiques dansl'utilisation des matériels de tests ou àpropos de l'affectation des individussur les projets.

Enfin les projets informatiques sontpar essence un nid de fécondationdes dissensions dans les entreprises,non seulement parce qu'ils concer-nent les systèmes d'information desorganisations et que la détention desressources informationnelles peutconstituer un enjeu de pouvoir, maisaussi parce que ces projets sont sou-

33 7




vent porteurs de changements organi-sationnels importants.

2.3.2. L'impact des formeset modes de résolutiondes conflits

Ainsi la différenciation organisation-nelle, le partage de ressources limi-tées, l'interdépendance des tâches quicaractérisent les projets, et la naturemême de l'informatisation, condui-sent à des impressions d'incompatibi-lité et d'entrave, et ces perceptionsaboutissent à des situations conflic-tuelles. Les conflits peuvent être ana-lysés selon trois dimensions, structu-re, mode d'expression, et espace dedéroulement, chacune de ces dimen-sions prenant une forme bipolaire(Kolb et Bartunek, 1992).

La première dimension concerne lastructure du conflit, c'est-à-dire lesapparences extérieures sur lesquellesil va s'appuyer. A un extrême on auraune structure formalisée comme lalégislation, les rôles officiels de média-teurs ou de recours, les postes de liai-son, les procédures et règlements pré-définis ; les contrats de sous-traitancedans le cas de l'externalisation dudéveloppement, les postes de corres-pondants informatiques, la charte éta-blissant les responsabilités entre utili-sateurs et informaticiens selon lesmodèles maître d'ouvrage et maîtred'oeuvre, ... sont des exemples typesde structure formelle visant à canali-ser les conflits. Cependant une struc-turation informelle peut aussi servirde réceptacle aux situations conflic-tuelles ; ce sont les normes, leslégendes et les rumeurs qui vont sup-pléer aux lois, les rôles officieux, lespersonnalités charismatiques sur les-quelles vont se concentrer les fluxd'informations et autour desquelles

vont se déployer des tactiques visant àfaire passer des points de vue ou desobjectifs particuliers. Les retentis-santes réussites (ou cuisants échecs)antérieures, leur souvenir capté dansla mémoire des individus, l'insatisfac-tion que procurent les systèmes infor-matiques préexistants, les leaders utili-sateurs, les relations informelles et pri-vilégiées entre certains utilisateurs etcertains informaticiens sont des mani-festations relativement courantes dela structure informelle sur laquelleprennent appui certains conflits.

Le mode d'expression constitue ladeuxième dimension descriptive duconflit. Au mode d'expression ration-nel, logique et stratégique du conflit,s'oppose une orientation non ration-nelle, émotive et impulsive ; ces deuxpôles du mode d'expression reflètentle plus souvent les relations de pou-voir préexistantes au conflit dans lamesure où l'expression non rationnel-le est souvent la forme adoptée (et laseule disponible) par les parties pre-nantes les plus menacées, les plusfaibles et souvent les moins bien infor-mées. Les positions relatives des direc-tions informatique et utilisateur dansl'organigramme, les effets attendus del'informatisation projetée qui peuventêtre perçus positivement (bénéfi-ciaires du changement) ou négative-ment (victimes du changement), lescompétences, statuts et rôles des parti-cipants qui peuvent être déséquilibréssont autant d'aspects qui orienterontle mode d'expression du conflit.

Enfin, la troisième dimension prenden considération l'espace dans lequelse déroule le conflit. Lorsque la miseen scène est publique, les conflits sontdéclarés et visibles ; ainsi, reconnus etautorisés, on leur applique le plussouvent des normes ou règles géné-

348



MANAGEMENT DES PROJETS INFORMATIQUES. COMPLEXITÉ ET GESTION DES CONFLITS

raies. Dans le cas de conflits occultés,le cadre d'une mise en scène privéepermet aux opposants de s'ignorer etde déployer une résistance passive ;seules des normes contextuelles etprovisoires peuvent émerger d'unetelle situation. La participation symbo-lique et passive aux réunions de tra-vail de même que l'absentéisme, larétention d'informations stratégiquesconcernant le projet, la non-intégra-tion, à un quelconque niveau du pro-jet, des futures victimes et/ou desopposants, ... constituent des manifes-tations privées des conflits.

Une dialectique complexe s'établitentre ces différentes dimensions etleur modalités polaires. En effet lesconflits sont dynamiques et peuvent sedéployer d'un pôle à un autre d'unemême dimension par le truchementd'une autre dimension. Ainsi un moded'expression irrationnel, canalisé parune structure formelle adaptée, facilita-teur compétent par exemple, pourraensuite s'exprimer rationnellement.Un conflit privé, qui ne peut pas s'ex-primer au travers de structures for-melles, pourra devenir public en utili-sant des relations informelles. Lesmécanismes par lesquels les conflitssont contenus, canalisés ou résolusorientent leur aspect constructif ou aucontraire destructeur. Les conflits peu-vent être positifs dans la mesure où ilsfocalisent l'attention sur des pro-blèmes importants et sur la nécessitéde les résoudre, incitent à la créativitéet à l'innovation, stimulent l'intérêt et lamotivation et augmentent la cohésiondes groupes. Mais a contrario ils peu-vent être négatifs lorsqu'ils favorisentl'hostilité, l'obstruction et l'aliénation etlorsqu'ils dissipent les énergies.

La nature de l'interaction d'un acteurindique la manière selon laquelle il

aborde une situation conflictuelle. Uneinteraction détachée indique un acteurindifférent aux enjeux, par inconscien-ce ou par crainte ; il y a adoption d'uneattitude de retrait, indifférence vis-à-visde ses propres aspirations ; en généralle pouvoir détenu est faible ; il se peutaussi que les enjeux soient particulière-ment faibles pour l'acteur. Lorsque lanature de l'interaction est accommo-dante les enjeux sont perçus et il y aune prédisposition à « ne pas faire devagues » et à céder du terrain. La naturecompétitive de l'interaction indiqueque les enjeux sont perçus importantset que l'acteur veut imposer son pointde vue. Enfin l'interaction coopérativesignale une volonté de comprendre lasituation et les enjeux, ainsi qu'uneorientation vers l'intercompréhension.Or les modes de résolution des conflits(Van de Ven et Ferry, 1980) vontdépendre de la nature des interactionsdéployées par les protagonistes d'unconflit.

Ainsi, lorsque le détachement domi-ne, les conflits sont ignorés . Le résul-tat de ce mode de « résolution » est engénéral insatisfaisant, et peut conduireà des impasses catastrophiques enphase opérationnelle, c'est-à-dire à lamise au rebut du logiciel réalisé.

L'interaction coopérative exprime ledésir des acteurs de réaliser, par laconfrontation de leurs désaccords, l'in-tégration de leurs aspirations. Les aspi-rations de départ peuvent ne pas êtretotalement intégrées, cependant lescompromis réalisés seront communé-ment acceptés. L'issue donne doncsatisfaction aux parties même si ellesont été conduites à revoir leurs aspira-tions originelles. La confrontationdes points de vue , parce qu'elle exigeconviction et ténacité des acteurs, per-met une intégration sélective et effica-

35 9




ce des objectifs. Non seulement lemode de résolution des conflits parconfrontation favorise l'efficacité orga-nisationnelle, mais il permet aussi d'at-teindre l'efficience sociale du projet ;en effet l'intercompréhension, néces-saire à la confrontation, constitue unfacteur de développement desmembres de l'équipe de projet.

La nature compétitive est fondée surle désir de satisfaire ses propres aspi-rations aux dépens des autres ; lesconflits sont déclarés ; une confronta-tion préalable peut avoir eu lieu quin'a pas abouti au consensus, l'orienta-tion compétitive domine et les désac-cords doivent alors être résolus enrecourant à la voie hiérarchique.Le résultat de ce mode de résolutionpeut être un compromis qui satisfaitou non les parties, ou bien une déci-sion tranchée qui ne satisfera pasl'une des parties au moins.

La nature accommodante, lorsqu'elledomine l'interaction, conduit àminimiser et à atténuer l'amplitu-de des désaccords pour « ne pasfaire de vagues », c'est-à-dire pour évi-ter le recours hiérarchique et/ou laconfrontation. Lorsque les acteurs dis-posent de ressources, les tractations etmarchandages constituent les fonde-ments de ce mode de résolution. Maisl'origine de ce mode de résolutionpeut aussi être culturelle, tradition deréticence à la confrontation, organisa-tionnelle, absence de règles derecours, faiblesse du management hié-rarchique, différence de pouvoir entreles parties. L'issue de ce mode de réso-lution peut ou non satisfaire les parties.

Constructeurs ou destructeurs, lesmodes de résolution des désaccordsauront un effet sur les résultats desprojets. Ainsi peut-on voir échouer unprojet en phase opérationnelle, logi-

ciel réalisé et installé, parce que lepoint de vue des unités opération-nelles, qui devaient alimenter la basede données, a été systématiquementignoré pendant le déroulement duprojet. Aussi, après l'installation dulogiciel, les procédures d'initialisationde la base de données s'avèrent inadé-quates et sont donc inappliquées ; dece fait le système informatique fonc-tionne sans reprise du passé, etdevient complètement inutile et inuti-lisable par les initiateurs du projetappartenant à différentes unités de latechnostructure de l'organisation.

La validation du rôle des modes derésolution des conflits sera réaliséepar le biais des hypothèses suivantes :

Le paradoxe de la résolutiondes conflits

- Hypothèse 4« Le mode de résolution par igno-rance a des effets négatifs sur laréussite des projets informa-tiques ».

- Hypothèse 5« Le mode de résolution parconfrontation a des effets positifssur la réussite des projets infor-matiques ».

- Hypothèse 6« Les modes de résolution parrecours hiérarchique et par atté-nuation ont des effets contradic-toires sur la réussite des projetsinformatiques ».

- Hypothèse 7« Le rôle des facilitateurs a deseffets positifs sur la réussite desprojets informatiques ».

Or les conflits peuvent surgir au coursdes différentes étapes d'un projet; aussiconvient-il d'examiner les différentsprocessus propres à les héberger.

3610



MANAGEMENT DES PROJETS INFORMATIQUES • COMPLEXITÉ ET GESTION DES CONFLITS

2.4.La flèche du temps,les processuset l'écosystèmes des projetsinformatiques

L'approche complexe implique l'in-clusion du facteur temps pour inter-préter le déroulement d'un projet eten comprendre l'aboutissement, apriori relativement imprévisible. Dèslors, il convient de noter que les voiesméthodologiques privilégiées sont

l'étude longitudinale et la recherche-

action.

En ce qui concerne les processus,une option aurait pu consister à dis-tinguer un processus par phase deprojet. Cette option a cependant plu-sieurs inconvénients ; tout d'abord lespratiques de découpage varient, selon

les méthodes et les outils de génie

logiciel mis en oeuvre, engendrantune polysémie difficile à maîtriser ; deplus se pose le problème de l'agréga-tion de processus qui peuvent avoirété menés soit en séquence, modèletraditionnel de la cascade, soit enconcomitance relative, modèle de l'in-

génierie simultanée. Une autre optionconsiste à distinguer deux processus,le processus de fonctionnement inter-ne de l'équipe de projet, et le proces-sus de son interaction avec les autresparties prenantes du projet. Ladeuxième option, outre qu'elle nepossède pas les inconvénients de l'op-

tion par phases, répond mieux au cri-tère d'imbrication de systèmes quenous avons évoqué plus haut, dans lamesure où le système « autres partiesprenantes du projet » constitue l'envi-ronnement immédiat du système« équipe de projet ».

La prise en compte de l'écosystèmedu projet, amorcée par le découpagevu précédemment, s'est poursuiviepar le repérage de trois catégoriespertinentes de l'environnement duprojet informatique. En effet un pro-jet, quel que soit son degré d'autono-mie, n'est jamais complètement isolé.Le projet peut, par ses effets, modifierles structures de l'organisation quil'abrite, et ces effets sont mesurés,dans le modèle, par les indicateursd'efficacité-efficience cités plus haut.Mais il peut aussi subir l'influence desstructures de l'organisation danslaquelle il se déploie. Tout d'abord,l'étude de faisabilité constitue l'envi-ronnement temporel précédant le lan-cement du projet. Le déroulement desactivités préalables suivantes : la défi-nition des fonctions à automatiser etde leurs interactions avec d'autresfonctions de l'entreprise, les scénariosd'automatisation élaborés, l'étudeéconomique (estimation des coûts etdes gains attendus) et la planificationdes opérations à réaliser pendant leprojet, auront un impact sur sondéroulement et ses issues. Enfin deuxtypes d'environnement fonctionnelsont à prendre en compte, d'une partl'unité qui abrite le projet, c'est-à-direle plus souvent le département infor-matique de l'organisation, d'autre partl'unité ou les unités qui utiliseront lelogiciel, c'est-à-dire les départementsutilisateurs concernés. La façon dontsont conduites les activités du dépar-tement informatique, le niveau desatisfaction des utilisateurs vis-à-visdes systèmes informatiques préexis-tants et leurs attitudes a priori, vis-à-visde l'informatique, composent, dansnotre modèle, le climat général danslequel va baigner le projet.

5. Environnement d'un système ouvert selon Morin, 1990, pp. 29-34

37 11




L'ensemble de ces cinq processus(activités internes de l'équipe de pro-jet, activités d'interaction avec lesautres partie prenantes du projet, acti-vités d'études préalables, activités dudépartement informatique et activitésinformatisées des départements utili-sateurs) constitue dans le modèle legroupe des variables indépendantesqui auront un impact sur les résultatsdu projet, c'est-à-dire sur les indica-teurs d'efficacité-efficience cités plushaut. Comme on l'a souligné précé-demment (cf les hypothèses du para-digme de l'efficacité) ces effets peu-vent être paradoxaux, et relativisentl'aspect déterministe du modèle. Nousaccordons un rôle primordial auxvariables modes de gestion desconflits, dans la mesure où elles ser-vent à véhiculer l'imprévisibilité etcontribuent à la gérer plus ou moinsefficacement ; aussi chaque processuscomportera des variables résolutionde conflits. Ainsi conçue, l'imbricationdes processus du déroulement desprojets informatiques nous conduit àanalyser l'enchaînement (par anté-riorité) des processus ; cette analysedevrait permettre d'affiner la compré-hension du déroulement des projetsinformatiques, et de valider le décou-page (en processus) de notre modèleet le rôle pivot de la gestion desconflits.

3. METHODOLOGIEET VALIDATIONSDU MODELE

Les arguments développés précé-demment ont constitué le fondementde l'élaboration d'un modèle compre-nant des variables d'efficacité-efficien-ce et des variables processus (cf l'an-

nexe A pour la liste des variables). Cesvariables ont été construites en tenantcompte de la spécificité du domaineétudié et soumises à validations. Nousexaminerons successivement, laméthodologie employée, collecte ettraitement des données, et les résul-tats obtenus par rapport aux hypo-thèses établies dans la première partiede l'article.

3-1-Méthodologiede la collecte etdu traitement des données

3.1.1. La collecte des données

Le modèle et les hypothèses ont ététestés sur un échantillon de 24 projetsd'informatique de gestion, dont lataille, en charge consommée, varie de15 à 158 homme-mois. La collecte desdonnées s'est effectuée par question-naires remplis par quatre catégoriesde répondants (tableau 1).

L'enquête a été longitudinale, c'est-à-dire que les données ont étérecueillies à trois moments différentsde la vie des vingt-quatre projets(tableau 2).

3.1.2. Le traitement des données

L'étape de validation permet de véri-fier que les résultats de l'enquête sontcohérents avec le corpus théoriqueretenu . Trois catégories de validationont été réalisées : la validation intrin-sèque, la validation extrinsèque et lavalidation des hypothèses. Cette der-nière catégorie de validation sera exa-minée plus loin, nous nous attachons,dans ce paragraphe, aux deux autrescatégories de validation.

La validation intrinsèque consiste àvérifier qu'un instrument mesure bien

3812



MANAGEMENT DES PROJETS INFORMATIQUES. COMPLEXITÉ ET GESTION DES CONFLITS

Nombre Nombre de Nombre de Nombre de Nombrede Projets Responsables Responsables Membres de d'Utilisateurs

utilisateurs informatique l'équipeprojet

24 78 38 199 685

Tableau 1 : Nombre de questionnaires exploités

ce qu'il est censé mesurer. Des itemsont été construits pour chaquevariable ; il a fallu vérifier que les itemscensés mesurer une même variable seregroupaient bien entre eux et se dis-tinguaient significativement d'autresitems censés mesurer d'autresvariables. Quatre techniques diffé-rentes ont été systématiquementconduites en parallèle : A.C.P., coeffi-cient alpha de Cronbach, corrélationsmédianes des items d'une mêmevariable et corrélation de la variableavec une mesure concurrente. La déci-sion de conclure à la validité intrin-sèque a été prise lorsque les résultatsétaient concluants pour au moinstrois de ces techniques ; les itemsd'une variable ainsi validée ont alorsété agrégés. Seize variables ont étévalidées. Seule la variable relative auxcompétences déployées par l'équipe,composée de cinq dimensions etquinze items, n'a pas été validéeintrinsèquement ; les items ont étéconservés et traités individuellement.

La validation extrinsèque concernel'utilité pratique d'un instrument parrapport à une problématique, ou plusconcrètement et dans le contexte de

l'étude : « dans quelle mesure, lesvariables processus (indépendantes)retenues sont-elles pertinentes, pourexpliquer la réussite des projets infor-matiques (les variables dépendantesd'efficacité-efficience) ? ». Trois tech-niques de validation ont été utilisées :corrélation, régression pas à pas etrégression multiple. La décision deconclure à la pertinence d'une variableprocessus (indépendante) a été priselorsque le résultat sur deux de ces troistechniques était significatif. Soixantedix huit variables processus (indépen-dantes) ont pu être retenues commeétant pertinentes (le pourcentage de lavariance expliquée variant de 0,37 à0,90 %). Neuf variables processus n'ontpas été activées dans la validationextrinsèque. Cela ne signifie pas pourautant qu'elles ne sont pas corréléesaux variables d'efficience-efficacité,puisque la puissance du test indiqueque l'échantillon est insuffisant pourinvalider les liaisons. On peut cepen-dant noter que si de telles liaisons exis-tent elles sont vraisemblablement defaible amplitude.

Les tableaux figurant en annexe Arésument, par groupe de variables

moment 1 moment 2 moment 3To To + 8 à 18 mois To + 18 à 29 mois

fin de l'étude préalable installation du logiciel utilisation opérationnelle(avant le démarrage (à l'issue du projet) du logiciel (de 1 à 12 moisdu projet) après l'installation du logiciel)

Tableau 2 : Déroulement de l'enquête

39 13




processus, les résultats obtenus, pourles validations intrinsèques et extrin-sèques.

3.2.Validation des hypothèses

Les résultats sont tout d'abord analy-

sés pour chaque groupe d'hypothèses,

la dynamique de l'enchaînement des

processus est ensuite examinée.

3.2.1. Les hypothèses relativesà l'efficacité-efficiencedes projets informatiques

- Hypothèse 1

Multidimensionnalité dela réussite

« Chaque variable à expliquer (cri-tère de réussite) constitue unconcept particulier de l'efficacité-efficience, aussi l'agrégation descritères n'a aucune significationde plus la réussite sur chacun descritères est obtenue de manièrespécifique, c'est-à-dire que lesvariables explicatives de chaquecritère différent ».

En ce qui concerne la première par-tie de notre hypothèse , « Chaquevariable à expliquer (critère de réussi-te) constitue un concept particulier del'efficacité-efficience, aussi l 'agréga-tion des critères n'a aucune significa-tion... » nous avons utilisé, pour confir-mer la particularité de chaque critèred'efficacité-efficience, l'analyse encomposantes principales en forçant lenombre (égal au nombre de critères)de facteurs demandés.

Chaque facteur différenciant signifi-cativement chacun des critères, la pre-mière partie de l'hypothèse 1 estconfirmée.

En moyenne, une même variableindépendante, retenue après valida-tion extrinsèque, est corrélée signifi-cativement à 3,2 variables dépen-dantes sur 8,2 (soit à environ 39 % desvariables dépendantes). Le tableau 3détaille ces résultats par type derépondant.

Nous pouvons considérer que ladeuxième partie de notre hypothèse 1« ...la réussite sur chacun des critèresest obtenue de manière spécifique,c'est-à-dire que les variables explica-

Type de Nombre de Nombre de Nombre de Nombre moyenrépondant variables variables variables de variables

indépendantes indépendantes dépendantes dépendantessoumises à corrélées soumises à corrélées signif.validation significat. à au validation à la mêmeextrinsèque moins une extrinsèque variable

variable indépendantedépendante m - 8,2 m - 3,2

Responsableutilisateur 35 27 9 2,8

Responsableinformatique 53 41 8 2,7

Utilisateur 20 19 9 4,9

Membre del'équipe 53 48 7 2,5

Tableau 3: Activation des variables indépendantes

4014



MANAGEMENT DES PROJETS INFORMATIQUES COMPLEXITÉ ET GESTION DES CONFLITS

tives de chaque critère différent» estconfirmée.

- Hypothèse 2

Paradoxe des variablesexplicatives« Les variables explicatives peu-vent à la fois favoriser la réussite

des projets sur un critère et lacontrarier sur un autre critère ».

Une variable est paradoxale, lors-qu'elle est corrélée significativement àla fois négativement et positivement àau moins deux variables dépendantes.Les pourcentages de variables contra-dictoires varient de 22 % à 58 % selonle type de répondant (cf. le tableau 4).Nous pouvons donc admettre la valida-tion de l'hypothèse N° 2.

La prise en compte des variables indé-pendantes, non contradictoires et inter-venant sur plus de la moitié des variablesdépendantes, conduit à brosser uneesquisse des structures cognitives de l'ef-ficacité des projets informatiques.

Pour les responsables utilisateurs, la

réussite d'un projet informatique

dépend principalement de la résolu-

tion des conflits par confrontation, del'action des facilitateurs et du soutien

de la hiérarchie au projet.

Les responsables informatiques

considèrent que l'action des informati-ciens, en particulier celle des experts,

pendant l'étude préalable, nuit à la

réussite des projets, alors que la com-pétence déployée par l'équipe, notam-ment la capacité à faire l'analyse cri-tique du système préexistant et à com-muniquer avec les utilisateurs, contri-

bue notablement à leur réussite.

Selon les utilisateurs, l'action desinformaticiens et des facilitateurs, pen-dant le déroulement du projet, ainsique la focalisation sur l'organisationdes services et la conception des postesde travail constituent les variables-clésdu succès.

Enfin les membres de l'équipe attri-buent la réussite à une mobilisationde toutes les parties prenantes, et plusparticulièrement des responsables uti-lisateurs, à la focalisation sur l'organi-sation et la conception des postes detravail utilisateurs et à leur degré d'ini-tiative sur le projet.

- Hypothèse 3Paradoxe des perceptionsde la réussite

« Les perceptions de la réussitedes projets informatiques varientselon les acteurs ».

Type de Nombre de variables Nombre de variables Pourcentagerépondant indépendantes retenues indépendantes retenues

et paradoxales

Responsablesutilisateurs 27 6 22,22 %

Responsablesinformatique 41 9 21,95 %

Utilisateurs 19 10 57,89 %

Membres del'équipe projet 48 17 37,42 %

Tableau 4 : Intervention paradoxale des variables indépendantespar type de répondant

41 15




Groupe de Nombre de variables Nombre de variables Nombre de variablesvariables indép. retenues pour indép. non paradoxales indép. paradoxales

tout type de répondant et communes à plus de et communes à plus de2 types de répondants 2 types de répondants

Efficienceéconomique 22 3 5

Qualité dulogiciel 21 4 3

Aide à ladécision fournie 17 2 1

Gainsorganisationnels 23 1 6

Tableau 5 : Nombre de variables indépendantes retenuespar variable dépendante

Pour l'ensemble des types de répon-dants il y a eu 83 cas de variables indé-

pendantes retenues à l'issue des vali-dations extrinsèques. Mais, on ne

trouve que 10 cas de concordance depoints de vue pour plus de deux typesde répondants, et 15 cas contradic-toires, cas où la variable indépendanteest paradoxale. Le tableau 5 résume

ces résultats ; il convient de signalerque n'ont été prises en compte, dans

ce tableau, que les variables dépen-dantes pour lesquelles plus de deux

types de répondants ont été interro-gés.

L'hypothèse 3 est donc confirmée.

Dans quelle mesure cependantpeut-on dégager un consensus mini-mal entre les différents types derépondants ?

L'efficience économique est atteintegrâce à l'action des facilitateurs, laconfrontation des points de vue et lafocalisation sur la conception despostes de travail utilisateurs.

L'efficacité de l'aide à la prise dedécision, apportée par le logiciel, pro-vient de la hiérarchie, action des res-ponsables utilisateurs et soutien dessupérieurs au projet.

L'efficience technique dépendd'une faible intensité des désaccords,plus précisément de désaccords rela-tifs aux choix techniques pendantl'étude préalable, de la mobilisationde toutes les parties prenantes et plusparticulièrement des facilitateurs.

L'importance des gains organisa-tionnels apportés par l'utilisation dulogiciel réalisé dépendent de l'absen-ce de sujets de désaccord sur les pro-cédures et résultats des tests d'intégra-tion, c'est-à-dire de la spécificationcorrecte des fonctionnalités en phasede conception.

3.2.2. Les hypothèses relativesà la gestion des situationsconflictuelles

Hypothèse 4le mode de résolution par igno-rance a des effets négatifs sur laréussite des projets informatiques

Hypothèse 5le mode de résolution parconfrontation a des effets positifssur la réussite des projets infor-matiques

- Hypothèse 6les modes de résolution parrecours hiérarchique et par atté-

4216




nuation ont des effets contradic-toires sur la réussite des projetsinformatiques

- Hypothèse 7le rôle des facilitateurs a des effetspositifs sur la réussite des projetsinformatiques

Les résultats obtenus permettent devalider les hypothèses relatives auxmodes de résolution des conflits (cf.tableau 6).

L'ignorance des conflits a un impactnégatif sur les résultats du projet, alorsque la confrontation des points devue a un effet positif.

Le recours à la voie hiérarchique,ainsi que l'atténuation des conflits ontdes effets paradoxaux. La fréquenceplus élevée du mode hiérarchique estvraisemblablement liée à l'existencede règles formelles et procédures derecours en cas de désaccords.

Enfin l'intervention de facilitateursfavorise la réussite des projets etconstitue la variable indépendante laplus active. Un examen plus appro-fondi des données indique laprésence d'un circuit causal entre lesvariables suivantes, intervention desfacilitateurs, mobilisation de toutes lesparties prenantes et mode de résolu-tion par confrontation.

3.2.3• Processus : les cerclesvicieux et vertueux des projetsinformatiques

L'imbrication des processus

« L'analyse de l'enchaînement(par antériorité) des processusdevrait permettre d'affiner lacompréhension du déroulementdes projets informatiques et devalider le découpage (en proces-sus) de notre modèle et le rôlepivot de la gestion des conflits ».

La combinaison des relations, entreles variables-clés, c'est-à-dire la struc-ture dynamique du système projet,dévoile des processus amplificateurs,bénéfiques ou néfastes (Senge, 1991).

Pour chaque dimension de la réussi-te des projets on peut découvrir deuxcircuits l'un vertueux , l'autre vicieux.

L'examen de chacun de ces circuitsaide à comprendre la logique sous-jacente, à déceler les causes structu-relles et leur interaction avec descauses factuelles ou apparentes. Lepropos sera illustré avec l'exemple desgains organisationnels engendrés parle logiciel installé : réductions de coût,gains directs, avantages qualitatifs.

Le cercle vertueux (cf. figure 1) estengendré par la satisfaction des utili-sateurs à l'égard des systèmes d'infor-mation préexistants au nouveau logi-

Modes derésolution

Nombre de fois où les variablesont été retenues avec corrélationsignificative positive

Nombre de fois où les variablesont été retenues avec corrélationsignificative négative

Ignorance 0 7

Atténuation 2 1

Hiérarchie 5 3

Confrontation 6 0

Action desfacilitateurs 12 0

Tableau 6 : L'impact des modes de résolution des conflits

43 17




ciel ; cet état de grâce engendre desméthodes de travail entre informati-ciens et non-informaticiens caractéri-sées par la confrontation à propos deschoix fonctionnels et d'organisationet la participation active de toutes lesparties prenantes. L'ensemble de ceséléments constitue un noeud de cau-salité structurelle, dont on ne peut, àvrai dire, dégager l'origine ; est-ceparce que les utilisateurs sont satis-faits que ces méthodes de travail sontadoptées ? ou bien est-ce l'utilisation,à l'origine, de ces méthodes de travailqui a provoqué la satisfaction ? Il y a làun exemple de circuit spiral danslequel les effets sont nécessaires auprocessus qui les génère. Par ailleurs,on décèle une cause plus factuelle,relative à la composition de l'équipede projet ; lorsque les membres del'équipe ont précédemment acquis del'expérience dans leur fonction sur leprojet (chef de projet, concepteurs,réalisateur), leur compétence dans lesactivités de validation favorise la réus-site.

Dans le cas du cercle vicieux (cf,figure 2) on découvre deux noeuds decausalité structurelle. Le premier cir-cuit est en quelque sorte l'inverse ducas précédent, c'est-à-dire qu'une descause originelles concerne l'insatisfac-tion des utilisateurs à l'égard de leurssystèmes d'information ; cependantleur attitude a priori très favorable àl'égard de l'informatique complète cecircuit ; les données disponibles n'ontpas permis de vérifier si ces utilisa-teurs sont plus technicistes que lestechniciens et donc utopistes ou sim-plement avertis et donc virulents àl'égard de l'impéritie des informati-ciens ; en réalité les deux cas de figurepeuvent exister. Le deuxième noeudde causalité structurelle concerne lesstructures du département informa-

tique, plus spécifiquement son accul-turation à travers des modes spéci-fiques de résolution des conflits quivont se transmettre dans les projets.

Notons enfin que la même causefactuelle, l'expérience de l'équipeintervient ici négativement et illustrele caractère paradoxal de l'efficacité.Peut-on interpréter ce paradoxe ?

D'un côté, cercle vertueux, l'expé-rience de l'équipe lui permet de réali-ser ses activités de validation demanière efficace.

De l'autre côté, cercle vicieux, l'équi-pe aura tendance, du fait de son expé-rience (dans le cas du cercle vicieux ils'agit d'une expérience multiple :fonction, domaine applicatif, informa-tique), à régler les problèmes rencon-trés par ajustements internes au lieude se confronter avec les autres par-ties prenantes du projet, notammentles utilisateurs et les facilitateurs. Dece fait l'éventail, plus restreint, desréponses apportées conduit à dessolutions engendrant des gains orga-nisationnels plus faibles.

Il convient de noter aussi que l'acti-vation d'abord positive, puis négative,de la variable « expérience de l'équi-pe » confirme notre argumentationprécédente à propos du « ... rôle nonlinéaire d'un prédicteur dont l'intensi-té provoque, à un certain seuil, l'in-version du sens de son intervention ».

L'élaboration de diagrammes systé-miques bipolaires pour chacune desvariables dépendantes, c'est-à-direpour chaque dimension de la réussiteet de l'échec, a une vertu heuristiquepuisqu'elle permet, à partir de fonde-ments théoriques sans cesse amélio-rés, de découvrir les logiques sous-jacentes du fonctionnement des pro-jets informatiques.

4418



MANAGEMENT DES PROJETS INFORMATIQUES COMPLEXITÉ ET GESTION DES CONFLIT,,

satisfaction à l'égard des source de conflits : fonctionnalitéssystèmes préexistants en cours d'étude préalable

mobilisation de toutes

résolution parles parties prenantes

résolution par confr ntation confrontationen cours de projet en cours d'étude

f -préalable

%,,, s4^compétence équipe :communication avecles utilisateurs

gains réalisésélevés compéte e

#

til équipe :

organisationcompétence équipe

validationcompétence équipe :critique du

expérien e équipesystème préexist I t -^ source de conflits : organisatic

en cours de projet

Figure 1 : Le cercle vertueux des «gains réalisés »(les données ont été agrégées par projet)

insatisfactionà l'égard dessystèmes préexistants incompétence équipe

communication avec utilisateurs

pas de résolutionpar confrontation

source conflits : h x technique en cours de projeten cours d 'étude préalable

gains réaliséntensité des conflits eh cours de projetfaibles

résolution par atténuationau sein de l'équipe de projet

résolution par hiérarchieen cours d'étude préalable

expérienceéquipe

résolution par hiérarchierésolution par atténuation au sein du départementau sein du département informatiqueinformatique

Figure 2: Le cercle vicieux des « gains réalisés »(les données ont été agrégées par projet)

4519




4. CONCLUSION

L'étude a montré les effets béné-fiques du recours à la confrontationdes désaccords , et ce constat rejointles résultats d'études antérieures réali-sées sur d 'autres projets que les pro-jets informatiques (Ke-sbom Schillinget Edward , 1989). Cependant , comptetenu du contexte dans lequel émergele conflit (le pouvoir détenu par cha-cune des parties prenantes , la philo-sophie personnelle de la personnequi doit gérer le conflit , l'impact dumode de résolution du conflit sur lesdélais, le budget, les équipes, lesconditions structurelles préexistantesau projet ...) des stratégies circons-tanciées et dynamiques pourraientêtre adoptées . Le tableau 7 décrit cesstratégies.

Des mécanismes peuvent être misen place dans les organisations pour

favoriser un mode de résolution parti-culier. Ainsi l'expression des partiesles plus faibles et la confrontation despoints de vue ont favorisées par latransition des conflits sur leurs dimen-sions bipolaires. Ou bien dansd'autres organisations on définit desrègles de recours hiérarchique pourrésoudre les conflits non résolus auxniveaux inférieurs. On peut aussiavoir recours à des mesures préven-tives afin de diminuer les occasionsde conflits ; ainsi la vérification systé-matique et approfondie des contratsde sous-traitance avant leur signaturepermet d'en corriger les termes ambi-gus, sources courantes d'interpréta-tions divergentes et, par amplification,de conflits.

Mode de résolution Conseillé quand Déconseillé quand

«ignorer les désaccords » - l'enjeu est peu important - l'enjeu est importantconflits occultés - l'enjeu tend à s'effacer - l'enjeu est persistantrésistance passive - solution temporaire

« atténuer les divergences - comme ci-dessus - comme ci-dessusde points de vue » plus plusne pas faire de vagues - relations feutrées nécessaires - la solution est irréalisteadopter un compromis momentanément - l'engagement des partenaires

chaque partie a quelque chose semble douteuxà offrir - les parties sont disposées à lales ressources sont limitées confrontation

« combattre les autres - des règles et procédures sont - les perdants n'ont pas lapoints de vue divergents » en vigueur possibilité d'exprimer leursrecours hiérarchique - le pouvoir est réel du fait de la besoinscoup de force position ou de l'autorité exercée - il y a un risque d'effondrement

futur notamment du fait del'instabilité du pouvoir

« confronter les points - du temps est disponible pour - il n'y a pas de temps disponiblede vue divergents » la confrontation pour la confrontationsincérité - les parties prenantes sont - les parties prenantes sont inaptesécoute aptes et désireuses d'aller et ou ne désirent pas aller à

à la confrontation la confrontation

Tableau 7: La contingence des modes de résolution des conflits

4620




ANNEXE A : Bilan des validations des variables

PROCESSUS « fonctionnement interne de l'équipe » intrinsèque extrinsèque

coordination de l'équipe avec le chef de projet (1 item) P

coordination entre les membres de l'équipe (1 item) P

coordination de l'équipe avec personnes extérieures (1 it.) P

rôle du chef de projet (5 items) V C

rôle des personnes extérieures (5 items) V C

rôle des membres individuellement (5 items) V C

rôle des membres de l'équipe en groupe (2 items) V P

comportements de l'équipe ++ (1 item) C

comportements de l'équipe + (2 items) V N

comportements de l'équipe - (2 items) V N

intensité des désaccords avec le chef de projet (1 item)

intensité des désaccords avec pers. extérieures (1 item) N

intensité des désaccords entre membres équipe (1 item) N

mode de résolution désaccords par « ignorance» (1 item) N

mode de résolution désaccords par « hiérarchie» (1 item) C

mode de résolution désaccords par « atténuation » (1 item) C

mode de résolution désaccords par « confrontation » (1 it.) P

compétence équipe en modélisation (3 items) I P

compétence équipe en communication (3 items) I C

compétence technique équipe (3 items) I P

compétence équipe en évaluation (3 items) I P

compétence équipe en organisation (3 items) I C

compétence globale équipe (1 item) P

dimension du travail - degré d'initiative (4 items) V P

dimension du travail : charge de travail (2 items) V N

dim. du travail : contrôle charge de travail (2 items) V N

dimension du travail : responsabilisation (2 items) V C

dimension du travail : variété des tâches ( 1 item) P

dim. travail : feed-back en provenance du travail (1 item) P

dim, travail : feed-back en prov. des collègues (1 item) C

dim. travail : feed-back en prov. du supérieur (1 item)

Légende : colonne validation intrinsèque V = validation, I = pas de validation,colonne validation extrinsèque N = négative, C = contradictoire, P = positive

4721




ANNEXE A (suite) : Bilan des validations des variables

PROCESSUS « interaction avec les autres parties validationprenantes du projet » intrinsèque extrinsèque

rôle des membres de l'équipe chef de projet inclus (4 ii) V C

rôle des responsables informatiques (4 items) V C

rôle des experts informatiques (4 items) V C

rôle des responsables utilisateurs (4 items) V C

rôle des utilisateurs (4 items) V C

rôle des facilitateurs (4 items) V P

intérêt des supérieurs (1 item) C

fréquence & importance des modifications (1 item) C

intensité des désaccords (1 item) C

résolution des désaccords par « ignorance » (1 item) N

résolution des désaccords par « atténuation » (1 item) C

résolution des désaccords par « hiérarchie » (1 item) C

résolution des désaccords par « confrontation » (1 item) P

sujets désaccords : fonctionnalités (1 item) C

sujets désac. : struct. phys. données, org. réseaux (1 item) C

sujets désaccords : tests & validation (1 item) C

sujets désaccords : conception postes de travail ( i item) P

Légende : colonne validation intrinsèque V = validation, I = pas de validation,colonne validation extrinsèque N - négative, C = contradictoire, P = positive

PROCESSUS « Etude préalable » validationintrinsèque extrinsèque

rôle des membres de l'équipe chef de projet inclus (4 it.) V N

rôle des responsables informatiques (4 items) V

rôle des experts informatiques (4 items) V C

rôle des responsables utilisateurs (4 items) V N

rôle des utilisateurs (4 items) V

rôle des facilitateurs (4 items) V P

volume désaccords (1 item) N

résolution désaccords par « ignorance» (1 item)

résolution désaccords par « atténuation» (1 item) P

résolution désaccords par « hiérarchie » (1 item) N

résolution désaccords par « confrontation» (1 item)

sujets désaccords : coûts & délais (1 item) N

sujets désaccords : matériels & logiciels de base (1 item) C

sujets désaccords : solutions fonctionnelles (1 item) P

4822



MANAGEMENT DES PROJETS INFORMATIQUES COMPLEXITÉ ET GESTION DES CONFLITS

ANNEXE A (fin) : Bilan des validations des variables

PROCESSUS « fonctionnement du département validationinformatique » intrinsèque extrinsèque

système d'évaluation « récompenses » (2 items) V N

système d'évaluation «sanctions» (2 items) V N

volume désaccords (1 item) C

résolutions désaccords par « ignorance » (1 item)

résolutions désaccords par «atténuation» (1 item)

résolutions désaccords par « hiérarchie » (1 item) P

résolutions désaccords par « confrontation » (1 item)

PROCESSUS « département utilisateur » validationintrinsèque extrinsèque

attitudes a priori vis-à-vis de l'informatique (3 items) V

satisfaction vis-à-vis des systèmes informatiquespréexistants (16 indicateurs de 2 items) V P

VARIABLES DÉPENDANTES validationintrinsèque

efficience économique : bilan global (1 item)

ef. éc.: productivité (nb. d'instructions source produites par jour)

efficience technique. qualité globale du logiciel (1 item)

efficience technique : qualité du logiciel (13 indicateurs de 2 items) V

efficience sociale du projet (2 items) V

efficience sociale du logiciel (1 item)

efficience sociale du logiciel (11 items) V

efficacité. aide à la décision apportée (6 items) V

efficacité : gains réalisés (somme des scores)

efficacité gains réalisés par rapport à g. attendus (scores)

efficacité gains effectivement réalisés par rapport à g. att. (scores)

retard : différence en mois entre date effective d'installation & date prévue

Légende : colonne validation intrinsèque V= validation, I =pas de validation,

colonne validation extrinsèque N = négative , C = contradictoire, P = positive

4923




BIBLIOGRAPHIE

Afnor (1994), Management de projet,Afnor, Paris.

Barki, H. et Hartwick, J. (1994),« Measuring User Participation, UserInvolvment, and User Attitude », MISQuarterly, March, p. 59-79.

Brynjolfsson, E., (1993) « The Producti-vity Paradox of Information Technology »,Communications of the ACM, vol. 35,December, p.66-77.

Brynjolfsson, E., (1994) « Information,Assets, Technology and Organization »,Management Science vol. 40, N°12,December, p. 1645-1662.

Brynjolfsson, E. et Hitt, L. (1994 a)«Paradox Lost? Firm-level Evidence on theReturns to Information Systems Spending)),MIT Sloan School Working Paper, November.

Brynjolfsson, E. et Hitt, L. (1994 b)« Creating Value and Destroying Profits?Three Measures of Information Technology'sContributions », MIT Sloan School WorkingPaper, December.

Brynjolfsson, E., Malone, T., Gurbaxani, V.et Kambil, A. (1994) « Does informationTechnology Lead to Smaller Firms ? »,Management Science, vol. 40, N°12,December, p. 1628-1644.

Kezsbom, D. S., Schilling, D.L. et Edward,K.A. (1989) « Dynamic Project Manage-ment)), Wiley-Interscience John Wiley &Sons Inc.

Cameron, K.S. (1986) « Effectivenessas a Paradox : Consensus and Conflictof Organizationnal Effectiveness »,Management Science, vol. 32, N° 5, May,p. 539-553.

DeLone, W. et McLean, E. (1992)« Information Systems Success : The Questof the Dependent Variable », InformationSystems Research, vol. 3, March, p. 60-95.

Kolb, D. M. et Bartunek, J.M. (1992)«Hidden Conflict in Organizations », SagePublications.

Lorino, P. (1991) Le contrôle de gestionstratégique : la gestion par les activités,Dunod Entreprise.

Lewin, A.Y. et Minton, J.W. (1986)« Determining Organizational Effectiveness :another look, and an agenda for research)),Management Science, vol. 29, No 5, May,

p. 514-538.

Mahmood, M. et Mann, G. (1991)Measuring the Impact of InformationTechnology on Organizational Perfor-mance : a Key Ratios Approach, inProceedings of the Twenty-fourthInternational Conference on SystemsSciences, pp.251-258, Los Alamitos,

California.

Marciniak, R. (1991) « Les Mesures de l'ef-ficacité des projets informatiques : modéli-

sation et validations », Doctorat enSciences de gestion, juin, Université d'Aix-Marseille 3, I.A.E. Aix en Provence.

Montebello, M. (1976) «Efficacité de l'en-treprise : analyse et perspectives », Thèsepour le Doctorat d'Etat és-Sciences deGestion, Université d'Aix-Marseille 3, IAE.

Morin, E. (1990) « Introduction d la pen-sée complexe » Communication & com-plexité ESF.

Nissen, M. (1994) Valuing IT throughVirtual Process Measurement, inProceedings International Conference onInformation Systems, December, pp. 309-323, Vancouver, British Columbia.

Quinn, R.E. et Rohrbaugh, J. (1983) « ASpatial Model of Effectiveness Criteria :Towards a Competing Values Approach toOrganizational Analysis », ManagementScience, vol. 29, N° 3, March, p. 363-377.

Rowe, F. (1994) ((L'impact de l'informati-sation sur la performance de l'entreprise »,Revue française de gestion, N°97, p. 30-42.

Scott, J. (1994) The Measurement ofInformation Systems Effectiveness :Evaluating a Measuring Instrument, inProceedings International Conference onInformation Systems, December 1994, pp.111-128, Vancouver, British Columbia.

Senge, P. (1991) « La cinquième discipli-ne» Flrst.

Van de Ven, A.H. et Ferry, D. (1980)«Measuring and Assessing Organizations »,John Wiley & Sons.

5024



management des projets informatiques : complexitÃ© et

Documents