Le partage de connaissances dans un projet d informatisation: Une approche basée sur les objets frontières

Transcription

1 Le partage de connaissances dans un projet d informatisation: Une approche basée sur les objets frontières Mona Ben Chouikha, ESCA, Casablanca, Maroc Résumé : Malgré son rôle essentiel dans le succès des projets d informatisation, le partage de connaissances détenues par les acteurs organisationnels impliqués dans de tels projets demeure un objectif difficile à réaliser. Cela est dû notamment à la faiblesse relative du nombre de travaux de recherche significatifs consacrés à ce sujet au cours des deux dernières décennies. Dans cet article, nous analysons les obstacles au partage de connaissances dans les projets d informatisation en termes de frontières de connaissances. En dehors de cette analyse, la principale contribution de cet article consiste en la description d une approche de partage de connaissances dans les projets d informatisation basée sur les objets frontières dont nous proposons une typologie. Une étude de cas, relative à un projet de développement d un outil de reporting dans un groupe d assurances, nous a permis de vérifier la pertinence de l approche proposée dans cet article et de mettre en évidence ses principales contributions. Mots clés : Projet d informatisation, connaissance, frontière de connaissances, objet frontière, acteur organisationnel, espace de projet Abstract : Despite its critical role in the success of computerization projects, sharing of knowledge held by organizational actors involved in such projects remains a difficult goal to achieve. This is mainly due to the relatively low number of significant research papers devoted to this topic in the past two decades. In this paper, we analyze the barriers to knowledge sharing in computerization projects in terms of knowledge boundaries. Apart from this analysis, the main contribution of this paper consists of the description of an approach to knowledge sharing in computerization projects based on boundary objects for which we propose a typology. A case study, related to the development of a reporting tool in an insurance group, has allowed us to verify the relevance of the approach proposed in this paper and to highlight its main contributions. Keywords : Computerization project, knowledge, knowledge boundary, boundary object, organizational actor, project space

2 1. Introduction Les organisations modernes ont besoin d un SI qui leur permet de prendre en compte les signaux émis par leur environnement économique, technologique et social changeant et instable, et les contraintes qui en résultent (Henderson & Venkatraman, 1993; Venkatraman, 1994; Hirschheim & Sabherwal, 2001; Sabherwal & Chan, 2001; Chan, 2002). En particulier, compte tenu des délais rapides de mise sur le marché de biens et services innovants, le SI d une organisation doit être suffisamment agile et évolutif pour supporter efficacement les processus innovants. Par ailleurs, pour que le SI soit durablement efficient et efficace, il est nécessaire qu il évolue soit par l adjonction de nouvelles applications, soit par la modification d applications existantes. Ces constats mettent en évidence l importance des projets d informatisation nécessaires pour répondre aux besoins informationnels des organisations et pour faciliter le changement organisationnel. Un projet d informatisation est une organisation unique et temporaire comportant des activités interdépendantes avec une date de début, une date de fin, un budget, et un objectif consistant à développer une application informatique afin de supporter partiellement ou totalement un ou plusieurs processus organisationnels. Aussi, le succès des projets d informatisation est une condition nécessaire pour que le SI d une organisation joue pleinement son rôle dans le support des processus organisationnels. Toutefois, les succès de projets d informatisation sont plutôt rares comme l attestent de nombreux auteurs qui ont noté qu il existe une crise du logiciel née depuis les années 60 du siècle dernier (Brooks, 1987, 1995; Toffolon, 1996, 1999). De nombreuses solutions ont été proposées dans la littérature pour sortir de la crise du logiciel et réduire ses impacts. Néanmoins, ces solutions n ont pas permis d éliminer tous les symptômes et les causes de la crise du logiciel qui persiste et semble s aggraver. Cet échec est dû à notre avis au fait que les solutions proposées à ce jour ont ignoré que la connaissance constitue l essence aussi bien du processus d informatisation que des artefacts qui en sont issus. Par conséquent, l amélioration de l efficacité des projets d informatisation passe par leur analyse comme des canaux de transmission, de partage, et d intégration des connaissances issues des individus, des méthodes, et de l apprentissage passé (Walz et al., 1993; Faraj & Sproull, 2000; Bredillet, 2004; Reich, 2007; Reich et al., 2008). En particulier, le partage de connaissances entre les acteurs organisationnels impliqués dans un projet informatisation est un facteur critique pour l aboutissement de ce projet. Notons que malgré l importance de la recherche relative au management de connaissances au sein des organisations, la part des travaux de recherche significatifs consacrés à ce sujet au cours des deux dernières décennies demeure relativement faible. Cela est dû notamment à la nature temporaire des projets d informatisation et à la dispersion des parties prenantes de ces projets à travers des structures et des formes organisationnelles diverses. Dans cet article, nous mettons l accent sur ce facteur en proposant une approche de partage de connaissances basée sur les objets frontières. Il s agit d identifier les frontières de connaissances entre les acteurs organisationnels impliqués dans un projet d informatisation et les objets frontières permettant de manager ces frontières. Pour ce faire, nous répondrons aux questions de recherche suivantes : Quelles sont les frontières de connaissances dans les projets d informatisation? Comment peut-on manager les connaissances aux frontières dans un projet d informatisation? Pour ce faire, nous nous basons sur un modèle d informatisation inspiré du modèle global du logiciel de Toffolon et Dakhli (2002) pour analyser les frontières de connaissances dans les projets d informatisation et proposer une approche de partage de connaissances aux frontières à l aide des objets frontières dont nous présentons une typologie. La motivation du choix de ce modèle est liée à sa nature à la fois générique et structurante, et sa capacité de décrire les différents aspects de l informatisation. Notre article est organisé comme suit. La section 2 explique pourquoi la connaissance est essentielle pour les projets d informatisation. Dans la section 3, nous présentons un modèle global d informatisation qui sert de base théorique de notre travail. Dans la section 4, nous analysons comment le management des connaissances aux frontières contribue au partage de connaissances. La section 5 utilise le modèle d informatisation proposé pour identifier les frontières de connaissances dans un projet d informatisation. Les objets frontières permettant de gérer es frontières sont décrits dans la section 6. Dans la section 7, nous présentons notre méthodologie de recherche qui inclut une étude de cas décrite et analysée à l aide de l approche proposée dans cet article. La section 8 conclut cet article en listant les contributions et les limites de l approche proposée ainsi que les futures directions de recherche. 2. Les projets d informatisation et la connaissance Les projets d informatisation sont basés sur des activités à forte intensité de connaissances et les artefacts informationnels qui en sont issus (applications, documents, modèles, ) peuvent être considérés comme une accumulation de connaissances partagées par les différents acteurs organisationnels impliqués dans ces projets (Lundin & Soderholm, 1995; Packendorff, 1995; Baetjer, 1998 ; Sodedund, 2002; Turner & Muller, 2003). Les membres d une équipe de projet apprennent individuellement et collectivement, acquièrent de nouvelles connaissances, transfèrent leurs connaissances aux autres, et créent de nouveaux concepts partagés. Ainsi, le 2

3 management de projets d informatisation et le management de connaissances sont deux processus imbriqués (Leseure & Brookes, 2004). Le succès d un projet d informatisation requiert l intégration de connaissances distribuées entre plusieurs individus et groupes sociaux au sein de l organisation (Faraj & Sproull, 2000 ; Becker, 2001 ; Yoo & Kanawattanachai, 2001). Newell et al. (2004), et Chiu et al. (2006) considèrent que le capital social est une voie possible d intégration des connaissances organisationnelles dispersées. Adler et Kwon (2002) définissent le capital social comme étant le capital sympathie résultant de la construction de relations sociales et pouvant être mobilisé pour supporter l action. Putnam (2000) a identifié deux types de capital social : les liens internes (bonding social capital), et les liens externes (bridging social capital). Les liens internes constituent une glue pour renforcer la cohésion d une équipe homogène. Les liens externes renforcent la cohésion de groupes sociaux qui ne se connaissent pas auparavant. Newell et ses coauteurs (2004) ont analysé l impact du capital social sur l intégration de connaissances dans le cadre d un projet d informatisation. Les résultats de leurs travaux distinguent la phase initiale des autres phases d un projet d informatisation. Pendant la phase initiale d un projet d informatisation, les membres de l équipe de projet utilisent les liens internes (bonding social capital) pour souder l équipe et renforcer sa cohésion interne en créant une compréhension commune des objectifs du projet et en partageant leurs connaissances. Au fur et à mesure que le projet avance, les membres de l équipe de projet mobilisent les liens externes (bridging social capital) pour acquérir les connaissances externes dont ils ont besoin pour atteindre les objectifs du projet, et qui sont distribuées entre plusieurs groupes sociaux. Les connaissances utiles pour un projet d informatisation appartiennent à quatre catégories identifiées dans la littérature relative à l apprentissage et au management de connaissances (Reich & Wee, 2006). Ce sont les connaissances du processus, les connaissances du domaine, les connaissances institutionnelles, et les connaissances culturelles. Les connaissances du processus sont les connaissances que les membres de l équipe de projet et les sponsors ont de la structure du projet, des tâches, des jalons, et de la méthodologie (Chan & Rosemann, 2001; Meehan & Richardson, 2002). Il s agit d un ensemble de connaissances qui permettent aux membres de l équipe de projet de prendre conscience de leur contribution au projet et de comprendre ce que l on attend d eux en termes de livrables. Ces connaissances permettent à l équipe de projet de s auto-organiser pour atteindre les objectifs du projet puisqu elle connaît les livrables exigés. Les connaissances du domaine incluent les connaissances de l industrie, de la situation courante de l organisation, de ses opportunités, de ses problèmes et de leurs solutions potentielles (y compris en termes de processus et de technologie). Selon Chan et Rosemann (2001), les connaissances du domaine sont composées de connaissances du métier, de connaissances techniques, et de connaissances du produit. Ces connaissances sont dispersées à l intérieur de l organisation. Par exemple, le sponsor d un projet d informatisation peut être celui qui détient le plus de connaissances sur l industrie, le problème à résoudre et ses solutions potentielles, et les opportunités à saisir. Les experts techniques à l intérieur et à l extérieur de l organisation détiennent les connaissances sur les technologies les plus adéquates pour supporter les solutions possibles du problème. De même, les membres de l équipe de projet ont une connaissance profonde de l organisation et de ses processus organisationnels impactés par le projet d informatisation. Les connaissances institutionnelles consistent en un mélange d histoires, d informations sur les structures du pouvoir, et des valeurs de l organisation. Elles ne portent pas sur les faits mais sur la manière d interpréter et comprendre ces faits. Cette catégorie de connaissances est essentielle pour un fournisseur de technologie ou pour un chef de projet extérieur à l organisation pour comprendre les problèmes difficiles, leurs solutions, et les décisions importantes prises dans le cadre du projet. Les connaissances culturelles sont basées à la fois sur les disciplines, les expertises, et les cultures nationales des membres de l équipe de projet. En effet, un projet d informatisation peut inclure des acteurs organisationnels experts dans des disciplines différentes, ou dont les origines et les cultures nationales sont différentes. Reich (2007) a noté que plus l organisation, le problème, l opportunité, ou la technologie sont complexes et innovants, plus la mobilisation et l exploitation de ces quatre catégories de connaissances sont importantes. 3. Le modèle global d informatisation Basé sur les théories économiques de l agence et des coûts de transaction (Coase, 1937; Williamson, 1981; Alchian & Demsetz, 1972; Jensen & Meckling, 1976) et sur la théorie des dimensions du logiciel (Toffolon, 1999), le modèle global du logiciel est un cadre qui structure la production du logiciel dans les organisations modernes (Toffolon & Dakhli, 2002). Ce modèle considère qu un projet d informatisation est une organisation temporaire composée d une structure où un ensemble d individus exercent des tâches conformément à une technologie de production pour atteindre un ensemble d objectifs (Leavitt, 1963). Selon le modèle global du logiciel, la structure d un projet d informatisation est basée sur quatre espaces de projet : l espace des problèmes, l espace des solutions, l espace de construction, et l espace d opération. Les individus impliqués dans un projet d informatisation (l équipe de projet) sont représentés par quatre types d acteurs organisationnels : le client, l architecte, le développeur, et l utilisateur final. Chaque type d acteur est associé à un espace de projet où il joue le rôle principal, et peut jouer un rôle secondaire dans d autres espaces de projet. Tout d abord, le client est associé à l espace de problème et joue un rôle secondaire dans l espace de solution et l espace d opération. 3

4 Ensuite, l architecte est associé à l espace de solution et joue un rôle secondaire dans l espace des problèmes et l espace de construction. De même, le développeur est associé à l espace de construction et joue un rôle secondaire dans l espace de solution et l espace d opération. Enfin, l utilisateur final est associé à l espace d opération et joue un rôle secondaire dans l espace de construction et l espace des problèmes. Le client et l utilisateur représentent les acteurs organisationnels appartenant à la maîtrise d ouvrage alors que l architecte et le développeur représentent les acteurs organisationnels appartenant à la maîtrise d œuvre. Le modèle global du logiciel décrit un projet d informatisation comme un ensemble de contrats du type producteur/consommateur entre des acteurs organisationnels appartenant aux quatre types listés ci-dessus. Ces contrats sont réalisés conformément à un méta-processus itératif désigné par l acronyme PACO (Problème Solution Construction - Opération) qui permet de définir la partie dynamique d un projet d informatisation c'est-à-dire les tâches réalisées par les membres de l équipe de projet. Selon le modèle global du logiciel, un projet d informatisation part d un problème organisationnel défini et résolu dans l espace des problèmes. La solution organisationnelle est soumise par le client à l architecte qui, dans l espace des solutions, définit une solution informatique (architecture) pour supporter la solution organisationnelle. Cette solution est implémentée dans l espace de construction par le développeur qui livre un logiciel mis en œuvre dans l espace d opération par l utilisateur final. La production de ce logiciel livré à l utilisateur final dépend des processus de production d artefacts informationnels intra-espaces de projet, et du processus de production inter-espaces de projet dérivés du métaprocessus PACO. Dans cet article, nous complétons la partie dynamique du modèle global du logiciel par l adjonction d un processus de gestion de projet exécuté par un chef de projet qui joue le rôle principal dans un espace de gestion de projet. Le chef de projet joue un rôle secondaire dans les quatre espaces de projet. De même, les quatre types d acteurs organisationnels impliqués dans un projet d informatisation jouent un rôle secondaire dans l espace de gestion de projet. Le chef de projet d informatisation est l interlocuteur de tous les autres acteurs organisationnels impliqués dans un projet d informatisation, et le garant de l efficience et de l efficacité du projet dont il est responsable. Finalement, dans chacun des cinq espaces de projet, les acteurs organisationnels impliqués dans un projet d informatisation utilisent une technologie de production pour accomplir leurs tâches et atteindre les objectifs du projet. Cette technologie est composée de ressources matérielles, de méthodes, de techniques, d outils, et de procédures en vigueur au sein de l organisation. Le schéma suivant (Figure 1) illustre la modélisation d un projet d informatisation utilisée dans cet article. P Client Espace de problème Nouveaux problèmes Nouveaux besoins Utilisateur final Espace d opération O Chef de projet Solution organisationnelle Espace de gestion de projet Implémentation de la solution informatqiue A Espace de solution Architecte Solution informatique Espace de construction Développeur C Figure 1: Modèle d informatisation 4. Le management des connaissances aux frontières L intérêt des frontières entre les différents groupes sociaux et les différentes disciplines a été mis en évidence par plusieurs auteurs (Leonard-Barton, 1995 ; Brown & Duguid, 2001). Partant des travaux de Star et Griesemer (1989), Carlile (2002) a identifié trois propriétés relationnelles de la connaissance située aux frontières entre des domaines de connaissances différents. Ces propriétés sont la différence, la dépendance, et la nouveauté (Carlile & Rebentisch, 2003). La différence résulte de la spécialisation entre les domaines et concerne la quantité ou le type de connaissances accumulées. La dépendance entre deux entités à été définie par Litwak et Hylton (1962) comme étant la condition imposant à chacune des deux entités de prendre en compte l autre afin d atteindre leurs objectifs. Sans la dépendance, la différence entre les connaissances détenues par deux acteurs n a pas de conséquence. La troisième propriété relationnelle de la connaissance aux frontières est liée au degré de nouveauté affectant les relations entre des acteurs appartenant à des mondes sociaux différents et collaborant dans le cadre d un projet. Il en résulte qu aux frontières de connaissances, la nouveauté impacte à la fois la capacité des acteurs à partager leurs connaissances et leur capacité à évaluer la connaissance des autres acteurs avec lesquels ils interagissent. Carlile (2002) a noté que l avènement d une nouveauté aux frontières entre différentes disciplines ou différents groupes sociaux peut se traduire par l absence d un langage commun permettant de représenter les différences et les dépendances entre les acteurs impliqués dans un projet. 4

5 Selon Carlile (2002, 2004, 2005), le management des connaissances aux frontières est nécessaire pour faciliter le partage de connaissances requises pour atteindre les objectifs communs d une équipe de projet. Pour ce faire, cet auteur distingue trois types de frontières de connaissances (syntaxique, sémantique, et pragmatique) et propose trois approches pour les manager efficacement Carlile (2004, 2005). La frontière syntaxique est caractérisée par la stabilité et la maîtrise des différences et des dépendances entre les acteurs organisationnels. Selon cet auteur, le transfert de connaissances est l approche la plus appropriée pour manager les frontières syntaxiques. Une telle approche dite orientée traitement de l information est basée sur le développement d un langage commun pour partager et évaluer la connaissance aux frontières (Galbraith, 1973). La transition entre la frontière syntaxique et la frontière sémantique a lieu lorsque la nouveauté rend ambiguës certaines dépendances et différences ou certaines interprétations. Pour manager les frontières sémantiques, Carlile (2004) suggère une approche de traduction dite approche interprétative permettant de créer des interprétations communes constituant des moyens adéquats pour partager et évaluer les connaissances aux frontières. Le passage d une frontière sémantique à une frontière pragmatique a lieu lorsqu une importante nouveauté génère des intérêts conflictuels entre les acteurs. Ces intérêts constituent des obstacles au partage et à l évaluation des connaissances aux frontières. En effet, en présence d intérêts conflictuels, les connaissances développées dans un domaine génèrent souvent des conséquences négatives pour les autres domaines, matérialisées par des coûts occasionnés pour chacun des acteurs appartenant aux domaines impliqués. En raison de ces coûts, les acteurs sont moins disposés à effectuer les changements induits par une nouveauté importante. Selon Carlile (2004), le management des frontières pragmatiques est basé sur une approche de transformation - dite approche politique qui facilite le développement d intérêts communs à travers la transformation des intérêts conflictuels et des connaissances des acteurs. Ces intérêts communs constituent des moyens adéquats pour partager et évaluer les connaissances aux frontières. Carlile (2004) suggère que le partage de connaissances aux frontières passe par la création d objets frontières communs aux différents acteurs organisationnels impliqués dans un projet. Le concept d objet frontière a été introduit par Star et Griesemer (1989) comme instrument de cohésion de plusieurs mondes sociaux autour d un même objectif partagé. Ainsi, les objets frontières sont caractérisés par leur capacité à fédérer, autour d un projet commun, des acteurs aux identités hétérogènes et aux intérêts différents voire contradictoires. Autrement dit, les objets frontières permettent d organiser la collecte d informations, la production et la circulation de connaissances entre des acteurs organisationnels appartenant à des groupes sociaux différents (Star & Griesemer, 1989 ; Briers & Chua, 2001 ; Vinck 2009). La représentation de la connaissance à l aide d objets frontières (Star 1989) et les processus de management des connaissances aux frontières que ces objets facilitent (Carlile 2002) sont les facteurs clés pour le développement d un contexte efficace commun aux acteurs organisationnels détenteurs des différentes sources de connaissances. Selon Carlile (2002), un objet frontière efficace établit un langage commun permettant de représenter les connaissances et fournit une méthode concrète pour spécifier les différences et les dépendances. Les objets frontières peuvent être des spécialistes techniques (individus), des méthodes mutuellement acceptées, ou des artefacts partagés. Quelle que soit leur catégorie, non seulement ils facilitent la représentation de la connaissance, mais aussi sa traduction et sa transformation. Ben Chouikha (2010) a confirmé les analyses de Carlile (2002, 2004) dans le cadre du design d une organisation apprenante et les a validées à l aide d une étude de cas longitudinale portant sur plusieurs équipes de projet dans un contexte de fusion entre deux compagnies internationales de services de télécommunications. De leur côté, Ben Chouikha et Dakhli (2011) ont complété les travaux de Carlile dans une étude du partage de connaissances dans une organisation virtuelle. La création d objets frontières pour manager les connaissances aux frontières entraîne une transformation des connaissances détenues par les différents acteurs interagissant à cette frontière. Dans le cas où le degré de nouveauté est peu élevé ou les dépendances entre les domaines de spécialisation sont stables (frontières ou interfaces bien définies), le transfert de connaissances peut être suffisant pour le partage de connaissances entre des individus, des groupes, ou des organisations (Argote, 1999; Winter & Szulanski, 2001). Par contre, avec l accroissement de l importance du degré d innovation, les différences et les dépendances entre les individus et les groupes d individus génèrent souvent des effets négatifs et des problèmes qui doivent être résolus conjointement. Ainsi, les connaissances spécialisées qui doivent être intégrées doivent être transformées afin d éliminer les effets négatifs, résoudre les problèmes associés, et construire une solution collective. L intégration des connaissances détenues par plusieurs acteurs comporte de nombreuses difficultés et dépend du contexte dans lequel ces acteurs agissent (Becker, 2001; Maaninen-Olsson et al., 2008; Carton & Farastier, 2012). 5. Les frontières de connaissances dans un projet d informatisation Dans cette section, nous montrons tout d abord, que la difficulté de partager la connaissance dans les projets d informatisation est due à l existence de nombreuses frontières de connaissances entre les acteurs de tels 5

6 projets. Ensuite, nous utilisons le modèle global du logiciel pour élaborer une typologie des frontières de connaissances dans un projet d informatisation. 5.1 La difficulté de partage de connaissances dans un projet d informatisation Becker (2001) a mis en évidence la difficulté de manager les connaissances distribuées entre plusieurs individus et groupes sociaux au sein d une organisation. En particulier, les projets d informatisation impliquent des acteurs dont les rôles sont multiples et l implication est variable. Les interactions entre ces acteurs nécessaires pour atteindre les objectifs du projet - sont affectées par la spécificité du cadre organisationnel du projet (coût, qualité, délais, cultures nationales, culture organisationnelle, ). La dispersion de la connaissance organisationnelle peut être à l origine d une mobilisation insuffisante par les membres de l équipe de projet - des connaissances critiques soit en raison des différences de statut, soit en raison des distances physiques les séparant, ou encore du fait d un manque de familiarité lié aux différences de culture, de modes de pensée, et de langages (Arthur et al., 2001 ; Reich, 2007). Selon Reich (2007), le management de connaissances dans le contexte d un projet d informatisation consiste à appliquer un ensemble de principes et de processus conçus pour mettre les connaissances significatives à la disposition de l équipe de projet. Ainsi, le management efficace de connaissances facilite la création et l intégration de connaissances, minimise la quantité de connaissances perdues, et réduit les écarts de connaissances entre les membres de l équipe de projet. Ce processus est facilité par l existence d une identité et de pratiques partagées (Hardy et al., 2005; Levina & Vaast, 2005; Feng et al., 2011). Par contre, les différences de statut entre les acteurs participants constituent des obstacles pour ce processus (Hoegl & Gemuenden, 2001; Levina, 2005; Metiu, 2006). L inefficacité de la coopération dans un projet d informatisation est due à l existence de frontières sociales ou organisationnelles entre les membres de l équipe de projet, qui empêchent la création d une identité et de pratiques communes et renforcent les différences de statuts. La distance physique spatiale ou temporelle séparant les membres d une équipe de projet est un exemple de frontière organisationnelle (Levina & Vaast, 2005, 2008). De même, les différences entre les langages parlés ou écrits, les cultures nationales ou professionnelles, et les fonctions exercées constituent des frontières sociales qui peuvent aussi bien aggraver les inégalités et renforcer les différences de statuts entre les membres de l équipe de projet, qu empêcher la création d une identité et de pratiques partagées (Lam 1997; Espinosa et al., 2003; Krishna et al. 2004; Levina & Vaast, 2005, 2006; Metiu, 2006 ; Birnholtz & Finholt, 2007; Cramton & Hinds, 2007; Levina & Vaast, 2008). Les différences entre les pratiques professionnelles et industrielles forment d autres frontières qui peuvent renforcer les différences de statuts en créant de nouveaux rapports de force, et empêcher l intégration de nouveaux membres ou d intervenants externes dans une équipe de projet d informatisation (Bourdieu, 1984; Carlile, 2004; DiMaggio, 1991; Montgomery & Oliver, 2007). En dehors des frontières organisationnelles et sociales, Cramton et Hinds (2007) et Walsham (2002) ont souligné que les frontières résultant des différences de pratiques entre les membres de l équipe de projet constituent les obstacles les plus importants inhibant la coopération entre ces membres. La coopération dans un projet d informatisation est rendue encore plus difficile par le fait qu une part importante des connaissances nécessaires au projet est tacite ou incorporée dans les pratiques des différents acteurs impliqués dans ce projet (Lam, 1997; Cramton, 2001; Hinds & Mortensen, 2004; Metiu, 2006, Levina & Vaast, 2008). 5.2 Typologie des frontières de connaissances dans un projet d informatisation Le modèle d un projet d informatisation présenté ci-dessus montre qu un projet d informatisation se déroule dans cinq espaces de projet dans lesquels cinq types d acteurs organisationnels jouent soit un rôle principal soit un rôle secondaire. La production du logiciel est conforme à un métamodèle itératif désigné par l acronyme PACO. Ainsi, un projet d informatisation est composé de trois parties : statique, dynamique, et organisationnelle. L adjonction d un espace de projet et d un processus de gestion de projet complète respectivement la partie statique et la partie dynamique (Figure 1). De même, l adjonction d un chef de projet complète la partie organisationnelle. Il en résulte trois types de frontières de connaissances : des frontières inter-espaces de production, des frontières intra-espaces de production, des frontières entre l espace de gestion de projet et l organisation y compris les espaces de production. Les frontières de connaissances inter-espaces de production résultent du fait que les quatre types d acteurs de projet associés aux quatre espaces détiennent des connaissances spécifiques et spécialisées. Ainsi, les connaissances du client sont relatives à son métier et au problème et à la solution organisationnelle qu il chercher à informatiser. A noter que même si le client a des connaissances relevant du domaine des technologies de l information et de la communication, ces connaissances sont souvent trop générales. De même, l architecte n a qu une connaissance superficielle et générale des autres métiers notamment ceux du client et de l utilisateur final. De nombreux architectes ne connaissent que peu de choses sur les langages de développement et les bases de données. C est le cas, par exemple, des architectes urbanistes ou encore des architectes fonctionnels. De leur côté, les développeurs ignorent en général les règles d architecture et les considèrent souvent comme des 6

7 contraintes. Par ailleurs, ils ont en général du mal à comprendre les demandes et les questions des utilisateurs finaux lorsqu ils essaient de dialoguer avec eux sans utiliser un langage informatique. Les frontières intra-espaces de production résultent du fait qu un type d acteurs organisationnels associés à un espace de projet inclut en réalité une population hétérogène d acteurs organisationnels détenant des connaissances différentes et spécialisées. C est le cas, par exemple, du type «architecte» qui regroupe tous les acteurs organisationnels fournissant un support transversal aux projets d informatisation. Il s agit notamment des architectes urbanistes, des architectes fonctionnels, des architectes techniques (spécialistes en architecture logicielle, architectes d infrastructure), des experts en méthodes, des ingénieurs qualité, et des experts en bases de données. C est aussi le cas du type «développeur» qui inclut notamment les analystes, concepteurs, les programmeurs, et les intégrateurs de logiciels. De même, le type «utilisateur final» peut inclure des acteurs organisationnels appartenant à des niveaux hiérarchiques différents ou spécialisés dans des métiers différents. Finalement, le type «client» fait référence à une population hétérogène constituée de managers intermédiaires, de cadres supérieurs, et de membres de la direction d une organisation. Les frontières entre l espace de gestion de projet et le reste de l organisation sont liées aux besoins de communication et de coordination du chef de projet non seulement avec les acteurs organisationnels appartenant aux quatre espaces de production, mais aussi avec les différents niveaux de management de l organisation qui sont parties prenantes d un projet d informatisation. Tout d abord, le chef de projet doit dialoguer avec le client pour comprendre ses besoins et lui rendre compte sur l avancement du projet. Ensuite, il doit aussi dialoguer avec l architecte qui l aide à définir une solution informatique pérenne supportant la solution organisationnelle. Ensuite, le chef de projet doit suivre l avancement de son projet, coordonner ses équipes, et gérer les priorités, les conflits et les ressources. Enfin, il doit rendre compte en permanence aux instances de gouvernance du projet représentant la direction de l organisation. Ainsi, le chef de projet est en interaction permanente avec une population hétérogène d acteurs organisationnels dont il ne partage pas les connaissances spécialisées. Selon les cas, les frontières de connaissances d un projet d informatisation sont syntaxiques, sémantiques, ou pragmatiques. Dans la suite de cet article, les frontières entre l espace de gestion de projet et l organisation sont désignées par l expression «frontières de gestion de projet». Le tableau suivant (Tableau 1) résume la typologie des frontières de connaissances dans un projet d informatisation. Type Inter-espaces Intra-espaces Gestion de projet Liste des frontières - Client - Architecte - Architecte - Développeur - Développeur Utilisateur final - Utilisateur final - Client - Architecte - Architecte - Développeur - Développeur - Utilisateur final Utilisateur final - Client - Client - Chef de projet - Client - Chef de projet Architecte - Chef de projet Développeur - Chef de projet Utilisateur final - Chef de projet Instances de gouvernance Tableau 1: Typologie des frontières dans un projet d informatisation 6. Les objets frontières dans un projet d informatisation Pour manager les connaissances aux frontières dans un projet d informatisation, différents objets frontières peuvent être définis. Avant de lister des exemples de tels objets, nous en proposons une classification en fonction de leurs principales caractéristiques. Tout d abord, les trois propriétés de la connaissance aux frontières - la différence, la dépendance, la nouveauté - identifiées par Carlile (2002) impactent les contrats du type Producteur/Consommateur caractérisant les relations entre les acteurs organisationnels impliqués dans un projet d informatisation. Il en résulte que les objets frontières permettant de manager les connaissances aux frontières jouent un rôle dans l amélioration de l élaboration et de la réalisation de ces contrats. Ainsi, un objet frontière peut avoir quatre rôles : transfert, clarification, production, et communication. Dans un projet d informatisation, un objet frontière de transfert fournit aux acteurs participant à une frontière syntaxique un langage commun leur permettant de transférer les connaissances nécessaires à la réalisation du contrat qui les lie. Un cahier de charges concernant le développement d un logiciel comptable est un exemple d objet frontière de transfert. Un objet frontière de clarification permet de réduire l incertitude et l ambiguïté inhérente à un contrat entre des acteurs organisationnels participant à une frontière sémantique. C est le cas, par exemple, d un prototype informatif 7

8 réalisé dans le cadre de l ingénierie des besoins et des exigences (Toffolon & Dakhli, 2002). Notons qu un objet frontière de clarification peut être un acteur organisationnel. Par exemple, un assistant à la maîtrise d œuvre est un objet frontière de clarification puisqu il aide l architecte et le développeur à réduire l ambiguïté inhérente à la solution organisationnelle à informatiser. De même, un architecte immergé dans un projet d informatisation est un objet frontière de clarification puisqu il aide les développeurs à comprendre la solution à implémenter et les règles et les contraintes d architecture à prendre en compte. Un objet frontière de production est un produit définitif accepté par les acteurs organisationnels participant à une frontière de connaissances et faisant partie des artefacts conservés pendant la durée de vie du logiciel. C est le cas, par exemple, d un rapport d expertise d architecture d un logiciel validé par le client, et accepté par le chef de projet et par le développeur. C est aussi le cas d une version du logiciel acceptée par le client et l utilisateur qui la met en œuvre dans l espace d opération. Généralement, un objet frontière de production permet de manager une frontière pragmatique. Toutefois, un tel objet peut être utilisé pour manager une frontière syntaxique notamment en l absence de nouveauté. Un objet frontière de communication permet notamment de manager les frontières de gestion de projet auxquelles participe le chef de projet. En effet, le chef de projet doit communiquer avec les différents acteurs organisationnels impliqués dans ce projet. Compte tenu de l hétérogénéité de ces acteurs et des connaissances qu ils détiennent, le chef de projet utilise des objets frontières de communication variés pour manager les frontières de gestion de projet. Par exemple, un diagramme de GANTT simplifié est un objet frontière de communication adéquat pour manager la frontière Chef de projet Client alors qu un diagramme de GANTT détaillé ressource par ressource, ou un diagramme de PERT sont des objets frontières de communication permettant de manager la frontière Chef de projet Développeur. De même, un tableau de bord décrivant synthétiquement l avancement du projet et expliquant les retards est un objet frontière de communication permettant de manager la frontière Chef de projet Instances de gouvernance. Notons que les objets frontières de communication sont généralement standards et permettent de manager les trois types de frontières de connaissances. Ensuite, les objets frontières sont issus de l une des approches proposées par Carlile (2004) en fonction des frontières de connaissances qu ils permettent de manager (Feng et al., 2011). Ainsi, il est évident que les objets frontières de transfert sont issus de l approche de transfert de connaissances. De même, les objets frontières de clarification résultent de l approche interprétative. Par ailleurs, les objets frontières de production sont le plus souvent issus de l approche politique de négociation. En effet, de tels objets sont des produits finis qui doivent concilier les intérêts conflictuels des acteurs organisationnels participant à une frontière pragmatique. Toutefois, en l absence de nouveauté, un objet frontière de production peut être issu d une approche de transfert de connaissances. Les objets frontières de communication peuvent être issus de l une des trois approches de management des connaissances aux frontières. En effet, s agissant souvent d indicateurs ou d instruments portant sur des artefacts intangibles, le contenu de tels objets frontières doit être consensuel afin de refléter les points de vue conflictuels des acteurs organisationnels concernés. Dans ce cas, on peut considérer qu ils résultent de l approche politique de négociation. Dans d autres cas, les objets frontières de communication sont issus de l approche interprétative. C est le cas par exemple si l un des acteurs organisationnels participant à une frontière de connaissances ne comprend pas la signification du contenu d un objet frontière de communication. Toutefois, de nombreux standards d objets frontières de communication existent et sont acceptés par la plupart des acteurs organisationnels impliqués dans un projet d informatisation. Les relations entre les approches de management des connaissances aux frontières (Carlile, 2004) et les objets frontières sont résumés dans le tableau 2. Le tableau 3 fournit des exemples d objets frontières dans le cas d un projet d informatisation. Finalement, un objet frontière peut être décrit à l aide de trois dimensions : frontière, rôle, approche de management des connaissances aux frontières. On obtient ainsi une typologie comprenant un nombre important d objets frontières associés à un projet d informatisation. Certes, tous les objets n ont pas le même poids dans le management des connaissances aux frontières dans le cadre d un projet d informatisation. Toutefois, l importance de leur nombre est un indicateur de la complexité des frontières de connaissances et de la difficulté de partager les connaissances dans une équipe de projet. Objet frontière Objet frontière de transfert Objet frontière de clarification Objet frontière de production Objet frontière de communication Approche de management des connaissances aux frontières - Approche de transfert de connaissances - Approche interprétative - Approche politique de négociation - Approche de transfert de connaissances - Approche politique de négociation - Approche interprétative - Approche de transfert de connaissances Tableau 2: Relations entre les objets frontières et les approches de Carlile (2004) 8

9 Frontière Exemple d objet frontière Rôle Client - Architecte Architecte - Développeur Développeur Utilisateur final Utilisateur final - Client Chef de projet Instances de gouvernance Chef de projet - Développeur Développeur- Développeur - Cahier de charges - Assistant à la maîtrise d œuvre - Rapport d expertise d architecture - Synthèse des règles d architecture à prendre en compte - Architecte immergé dans l équipe de projet - Accès à un forum des questions fréquemment posées à l architecte - Rapport d expertise d architecture - Transfert - Clarification - Production - Transfert - Clarification - Clarification - Production - Prototype informatif - Clarification - Maquette - Clarification - Formation à l utilisation du logiciel - Clarification - Version du logiciel final - Production - Liste des besoins informatisables - Transfert - Liste des demandes majeures d évolution - Transfert - Tableau de bord d avancement du projet - Communication - Diagramme GANTT détaillé - Planning de référence - Compte rendu de réunions - Modèle de données - Programmes testés à intégrer - Accès à un forum des questions fréquemment posées - Accès à un référentiel des problèmes de codage et de leurs solutions Tableau 3: Exemples d objets frontières dans un projet d informatisation - Communication - Communication - Communication - Production - Production - Clarification - Clarification 7. Méthodologie de recherche Dans cette section, nous présentons succinctement le cas d étude, la méthode de collecte de données, et l analyse des résultats Description du cas d étude La validation empirique de l approche présentée dans cet article repose sur une étude de cas menée au sein d un groupe international d assurances dans le cadre d un projet de développement d un outil de reporting. Ce groupe a été constitué à travers de nombreuses opérations de fusion et d acquisition portant sur des compagnies d assurances françaises et étrangères. Il regroupe aujourd hui environ salariés répartis dans plusieurs pays. La stratégie de ce groupe est de développer à moyen terme et de manière significative ses parts sur le marché de l épargne. Le segment de clientèle ciblé est constitué des clients aisés en mesure d épargner entre et hors immobilier. Pour capter cette clientèle, ce groupe d assurances met en place une démarche commerciale spécifique et des forces de vente dédiées. Afin de permettre aux conseillers financiers d offrir à cette clientèle la meilleure qualité de service, il est prévu de les doter d un outil de reporting global de l épargne et de suivi du patrimoine par client. L objectif de cet outil désigné dans la suite du document par l acronyme NREP (Nouveau Reporting) - est de fournir aux conseillers financiers une vision consolidée du patrimoine de chaque client, de faciliter les analyses financières et patrimoniales du portefeuille de clients, et de fournir à chaque client un reporting sur la situation de son compte. De même, le département du marketing du groupe d assurances a exprimé son intérêt pour l outil NREP qui permet de fournir des indicateurs susceptibles de faciliter la mise en œuvre de campagnes marketing. Autrement dit, les principales fonctions de l outil NREP de reporting consistent à: fournir au client un service après-vente de qualité, permettre au conseiller financier et au client de partager la même vision objective des contrats, rendre possible une délégation de certains actes de gestion au client sur ses contrats (versement, rachat ), faciliter au conseiller financier la préparation de ses entrevues avec ses clients, réduire les appels téléphoniques du client à son conseiller financier, faciliter le cadrage et l orientation des campagnes de marketing. L outil NREP sera accessible aux clients concernés afin de leur permettre une visibilité sur leurs contrats 7 jours 7 et 24 heures sur 24. Le processus à informatiser décrit la démarche commerciale suivi par les conseillers 9

10 financiers pour capter les clients aisés ciblés par la stratégie du groupe. Ce processus se décline en quatre étapes. Il s agit tout d abord d effectuer un diagnostic permettant de faire l état des lieux du patrimoine du client. Ce diagnostic constitue la base à partir de laquelle le conseiller financier définit le conseil qu il proposera au client. Ensuite, des simulations sont réalisées pour permettre d apporter au client la preuve de la pertinence et du bien fondé des conseils du conseiller financier. La troisième étape consiste à élaborer un reporting accessible à tout moment par le client et le conseiller financier et garantissant la transparence du conseiller par rapport à son client. La quatrième étape est le suivi effectué par les conseillers financiers du patrimoine de leurs clients. Actuellement, les conseillers financiers de ce groupe d assurances ne disposent pas d une vision unique et globale sur l ensemble des contrats d épargne de leurs clients. Certes, de nombreux outils de reporting sont disponibles au sein de ce groupe et utilisés par les conseillers financiers. Toutefois, ces outils ne permettent pas aux conseillers financiers de consolider les résultats de leurs portefeuilles de clients, de les présenter suivant plusieurs axes d analyse, et d effectuer des requêtes sur ces portefeuilles de clients et de contrats suivant plusieurs critères de sélection. L outil NREP à mettre en place est un réceptacle de données relatives aux conseillers financiers, aux clients, et aux contrats. Ces données sont gérées par les applications informatiques existantes faisant partie du système d information du groupe d assurances. Après une étude préliminaire d opportunité, il a été décidé de développer l outil NREP en interne par la Direction du Système d Information (DSI) de la filiale française du groupe qui comprend notamment un département d architecture et un département de développement. Le département d architecture est composé d architectes urbanistes, d architectes fonctionnels, d architectes techniques, d experts en méthodes, en qualité, en bases de données, et en composants techniques réutilisables (composants éditique, de sécurité, ). Ces ressources sont soit des salariés du groupe d assurances soit des prestataires de services travaillant en régie. Le département de développement est composé de concepteurs qui sont soit des salariés du groupe soit des prestataires en régie qui sont chargés de l analyse et conception des applications informatiques. La réalisation, les tests unitaires et les tests d intégration de ces applications sont assurés par une société indienne «off-shore». Les applications informatiques développées en interne doivent respecter les règles d architecture et d urbanisation du système d information publiées dans un guide mis à disposition du département de développement. Ces règles ont été définies dans le cadre de la mise en place de l urbanisation du système d information du groupe. Les projets d informatisation doivent être conduits conformément à une méthode de conduite de projet élaborée par les experts en méthodes. Bien qu elle soit basée sur le modèle du cycle de vie conventionnel en cascade (Boehm, 1976, 1984), cette méthode prend en compte le maquettage et le prototypage au cours de la phase de définition de besoins et des exigences des utilisateurs et mentionne la possibilité de développement itératif en faisant référence au modèle en spirale (Boehm, 1988). En dehors de la dispersion géographique et culturelle de ses équipes de conception et de réalisation, le projet d informatisation étudié présente deux difficultés importantes. D une part, les utilisateurs n ont pas exprimé leurs besoins de manière formelle, ce qui rend difficile la définition des besoins et des exigences. D autre part, pour prendre en compte la diversité des contrats et des produits d épargne proposés par le groupe d assurances, l outil NREP doit pouvoir échanger des flux informationnels avec toutes les applications gérant ces produits. Il en résulte que l outil NREP doit prendre en compte les contraintes techniques (structure des bases de données, format de données, contraintes d interfaçage, ) et les contraintes d exploitation (disponibilité des informations, périodicité des échanges, ) de ces applications. Le tableau 4 ci-dessous fournit une synthèse des caractéristiques du projet d informatisation analysé dans le cadre de cette étude de cas. 10

11 Caractéristiques Taille de l organisation Secteur d activités Pratique du management de connaissances Objectif du projet étudié Durée du projet Environ salariés Assurances Description Objectif stratégique Mise en place d outils de management de connaissances : intranets, forums, wikis, FAQ, Développement d un outil de reporting sur le patrimoine des clients 18 mois Equipe de projet Un chef de projet 2 analystes concepteurs 2 développeurs off-shore Présence d un maître d ouvrage : représentants des conseillers financiers et du département de marketing Présence d un maître d œuvre : DSI Support d un architecte fonctionnel et d un architecte technique spécialiste en architecture logicielle à l équipe de conception (durée d intervention: 20 jours) Support de plusieurs experts en bases de données (durée d intervention: 15 jours) Dispersion géographique de l équipe de projet Oui : les concepteurs sont en France et les programmeurs sont en Inde Dispersion culturelle de l équipe de projet Utilisateurs cibles Organisation de la conduite de projet Méthode de conduite de projet à respecter Les concepteurs ne maîtrisent pas la langue anglaise et les programmeurs ne possèdent aucune notion de la langue française La culture nationale des programmeurs est différente de la culture nationale des autres contributeurs au projet (architectes, experts en bases de données, conseillers financiers, maître d ouvrage, ) Conseillers financiers, clients, département de marketing Comité de pilotage mensuel avec diffusion d un compte rendu Réunion hebdomadaire de l équipe de projet avec diffusion d un compte rendu Réunion mensuelle avec un représentant de l équipe de réalisation (vidéoconférence) Mise à disposition d un site intranet du projet où sont publiés les documents relatifs à l avancement de projet Obligatoire Standards à respecter Standards d assurance et de contrôle qualité Standards documentaires Standards d architecture Outils obligatoires utilisés Outil de conception acquis sur le marché Référentiel des fonctions métier Outil de gestion de projet Outils optionnels utilisés Intranet, référentiel documentaire, forums, wikis, Déploiement Dans un premier temps, déploiement dans la filiale française du groupe Ensuite, déploiement généralisé à l ensemble du groupe Tableau 4: Caractéristiques du projet étudié 7.2. Collecte des données et analyse des résultats Les données collectées proviennent de deux sources parmi celles identifiées par Yin (1994). D une part, nous avons consulté les documents mis à notre disposition par le chef de projet ou publiées dans le site intranet du projet, les documents disponibles dans le site intranet de la filiale française du groupe d assurances, dans le référentiel documentaire, et les documents fournis par le département d architecture. D autre part, nous avons recueilli des informations sur le déroulement du projet et les principaux événements qui l ont affecté (retards, problèmes techniques, problèmes organisationnels, ) à travers une observation non participante qui consistait à assister aux réunions importantes organisées par le chef de projet (réunion d équipe, comité de pilotage) et à échanger de manière informelle avec les membres de l équipe de projet ou avec les contributeurs au projet appartenant au département d architecture ou à la maîtrise d ouvrage. La méthode adoptée pour mener à bien notre étude de cas est une méthode qualitative inductive où les données du terrain ont été utilisées pour mettre en évidence les concepts représentatifs du phénomène étudié (Thiétart, 1999). L analyse des informations collectées nous a confirmé l intérêt de ce cas d étude aussi bien au niveau de l évaluation du modèle théorique qu au niveau de ses implications managériales. Tout d abord, l organisation de 11

12 la DSI de la filiale française du groupe d assurances étudié présente de nombreux points communs avec l organisation suggérée par le modèle d un projet d informatisation présenté ci-dessus. En effet, en dehors de l espace de gestion de projet représenté par le chef de projet, le département d architecture peut être assimilé à l espace des solutions alors que l espace de construction est composé du département de développement et de la société indienne «offshore». L espace des problèmes est composé des membres de la maîtrise d ouvrage qui incluent les représentants des utilisateurs finaux de l outil NREP (le département du marketing, les conseillers financiers). Les utilisateurs finaux de l outil NREP sont regroupés dans l espace d opération. Ainsi, nous pouvons conclure que le modèle d un projet d informatisation est adéquat pour modéliser la DSI qui assure le développement de l outil NREP au sein du groupe d assurances étudié. Ensuite, les informations recueillies nous ont permis de vérifier l existence des frontières identifiées par le modèle théorique proposé dans cet article. D une part, le fait que la définition des besoins et des exigences des utilisateurs ne soit pas décrite de manière formelle confirme l existence d une frontière entre la maîtrise d ouvrage et la maîtrise d œuvre. Cette frontière est à l origine des problèmes de définition des besoins des utilisateurs et des échecs de nombreux projets d informatisation. Les solutions proposées dans la littérature pour manager cette frontière n ont pas été totalement efficaces puisqu elles ont considéré cette frontière de manière globale. Conformément à l analyse de Brooks (1987), notre modèle prend en compte la diversité des frontières sous-jacentes à la frontière entre la maîtrise d ouvrage et la maîtrise d œuvre en la décomposant en quatre types : Client Architecte, Chef de projet Client, Chef de projet Utilisateur final, Développeur Utilisateur final. Cette décomposition permet de suggérer des moyens adéquats pour manager chaque type de frontière. D autre part, la diversité des métiers contribuant à la maîtrise d œuvre confirme l existence de frontières de connaissances aussi bien entre les départements d architecture et de développement qu au sein de chaque département. En effet, le département d architecture est peuplé d experts exerçant différents métiers, n utilisant pas les mêmes concepts professionnels, et n ayant pas les mêmes pratiques. Par exemple, les concepts et les pratiques utilisés par les architectes fonctionnels et les experts de bases de données sont différents. De même les concepteurs et les réalisateurs ne comprennent pas toujours l utilité des règles d architecture et des standards méthodologiques ou d assurance qualité, imposés par le département d architecture. Il en est de même du côté de la maîtrise d ouvrage où la diversité des utilisateurs finaux et de leurs représentants montre l existence de frontières de connaissances aussi bien entre les utilisateurs finaux et leurs représentants, qu entre les utilisateurs finaux, ou entre les représentants des utilisateurs finaux. Par exemple, les concepts, les pratiques, et les centres d intérêt des conseillers financiers diffèrent sensiblement de ceux des membres du département de marketing. Par conséquent, notre modèle facilite l identification détaillée de frontières de connaissances dans un projet d informatisation. C est ainsi que l application de ce modèle aux informations collectées dans le cadre de notre étude de cas nous a permis de vérifier l existence des frontières de connaissances listées ci-dessus (Tableau 1). Dans la suite de cette section, nous avons mis l accent sur un sous-ensemble de frontières de connaissances dont l analyse synthétise les principales conclusions de notre étude de cas. Il s agit des frontières de connaissances suivantes: Entre les représentants du client (maîtrise d ouvrage) et l architecte fonctionnel intervenant dans le projet : cette frontière résulte notamment de la diversité des métiers des utilisateurs finaux, de la connaissance insuffisante de ces métiers par les architectes fonctionnels, et de l absence d un dictionnaire de données métier définissant de manière unique les termes métier utilisé. Entre l architecte fonctionnel et l architecte technique intervenant dans le projet : cette frontière résulte de deux causes. D une part, l architecte technique, qui n a pas de connaissances approfondies de l architecture des systèmes décisionnels, n a pas pris en compte tous les aspects de la solution fonctionnelle proposée par l architecte fonctionnel. D autre part, l architecte fonctionnel n a pas de connaissances approfondies des règles et des contraintes de l architecture interne d une application informatique. Entre les architectes fonctionnel et technique et les concepteurs : Cette frontière exprime la méfiance des concepteurs qui considèrent que la solution proposée par les architectes est complexe. De leur côté, les architectes technique et fonctionnel considèrent que les concepteurs ne prennent pas en compte complètement les caractéristiques de l architecture qu ils ont définie pour l outil NREP. A cet égard, le fait que l architecte fonctionnel et l architecte technique ont montré leurs divergences publiquement dans les réunions avec les concepteurs a renforcé cette frontière. Entre les concepteurs et les programmeurs off-shore : cette frontière résulte de la différence entre les cultures nationales des concepteurs et des programmeurs, de la maîtrise insuffisante de la langue anglaise (resp. française) par les concepteurs (resp. les programmeurs), et de la méconnaissance par les programmeurs appartenant à la société indienne offshore des standards et des pratiques professionnelles en vigueur au sein de la DSI de la filiale française du groupe d assurances. Le fait que les concepteurs de la DSI de la filiale française du groupe d assurances n ont pas confiance dans les programmeurs off-shore a entraîné une rétention de l information qui a renforcé cette frontière, et n a pas facilité la réalisation de l outil NREP. 12

13 Entre les experts en méthodes du département d architecture et l équipe de projet : cette frontière traduit les problèmes d application par les concepteurs de la méthode de développement recommandée par le département d architecture. Les concepteurs ont noté la lourdeur de cette méthode basée sur le modèle du cycle de vie conventionnel en cascade (Boehm, 1976, 1984) et considèrent que son application dans le cadre du développement de l outil NREP est une source de retards et d incohérences. Le management des connaissances aux frontières a eu lieu à travers un ensemble de décisions prises par le chef de projet et validées par les instances de gouvernance. Ces décisions ont impacté aussi bien l équipe de projet que les modes de collaboration entre les différentes parties prenantes dans le projet. Ainsi, un assistant à la maîtrise d œuvre est intervenu pendant les premières phases du projet pour aider l architecte fonctionnel à comprendre l ensemble des aspects métiers à prendre en compte dans la définition de l architecture de l outil NREP. Cet assistant à la maîtrise d œuvre est un ancien conseiller financier qui a rejoint depuis quelques années la DSI pour y exercer le métier de gestionnaire des problèmes et des incidents informatiques et fonctionnels. Cette décision a permis de manager la frontière entre les représentants du client (maîtrise d ouvrage) et l architecte fonctionnel intervenant dans le projet. En effet, l assistant à la maîtrise d œuvre connaît bien le vocabulaire et les concepts métier pris en compte par l outil NREP et possède une connaissance de l informatique et du reporting suffisante pour qu il puisse jouer le rôle de facilitateur entre les acteurs impliqués dans cette frontière. Sa contribution au projet a consisté à animer plusieurs sessions de travail auxquelles ont participé l architecte fonctionnel et les membres de la maîtrise d ouvrage, et à faciliter la réalisation de maquettes et de prototypes informatifs pour réduire l incertitude inhérente aux besoins des utilisateurs. Compte tenu des informations que nous avons collectées, la contribution de l assistant à la maîtrise d oeuvre a été jugée efficace par les acteurs impliqués dans cette frontière. Par conséquent, l assistant à la maîtrise d œuvre peut être considéré comme un objet frontière de clarification permettant de manager la frontière inter-espaces Client- Architecte. Il en est de même pour les maquettes et les prototypes informatifs réalisés à ce stade. Toutefois, un dictionnaire métier définissant de manière unique les différents concepts métier peut être considéré aussi comme un objet frontière de clarification complémentaire de l objet frontière assistant à la maîtrise d œuvre. La frontière de connaissances entre l architecte fonctionnel et l architecte technique intervenant dans le projet est une frontière intra-espace qui matérialise une incompréhension entre ces deux acteurs due à l insuffisance de leur culture professionnelle commune. En effet, l architecte technique est un ancien programmeur qui ne maîtrise que l architecture logicielle des applications (composants, connecteurs) et n a que de vagues notions de l architecture fonctionnelle et de l architecture décisionnelle. De son côté, l architecte fonctionnel n a pas d expérience significative dans la définition de l architecture logicielle d une application et ne maîtrise pas toutes contraintes liées à l interfaçage entre composants ou entre applications. Aussi, l architecte technique a considéré que l architecture fonctionnelle de l outil NREP proposée par l architecte fonctionnel n a pas d intérêt et a proposé de définir la solution directement en termes de composants techniques. Pour éviter que ces divergences de points de vue entre l architecte technique et l architecte fonctionnel ne causent un retard important pour le projet, le chef de projet a suggéré que l architecte fonctionnel forme l architecte technique aux concepts de base de l architecture décisionnelle. Bien que cette formation ait été jugée positive par l architecte technique, ses divergences avec l architecte technique ont perduré pendant toute notre période d observation. Ces divergences de points de vue ont été aggravées par un manque de confiance entre ces deux acteurs. Elles ont souvent fait surface dans les réunions de l équipe de projet et dans les sessions de travail avec les concepteurs. Malgré ces divergences, l architecture logicielle de l outil NREP a pu être élaborée sur la base de l architecture fonctionnelle. Aussi, la formation dispensée par l architecte fonctionnel n a joué que partiellement le rôle d objet frontière de clarification. La frontière de connaissances entre les architectes (fonctionnel et technique) et les concepteurs est une frontière inter-espaces qui a été managée en trois étapes. Tout d abord, une session de formation a été animée par l architecte fonctionnel et l architecte technique pour familiariser les deux concepteurs avec les notions de base et les contraintes de l architecture des SI, et les convaincre de l utilité de ces notions. Cette formation peut être considérée comme un objet frontière de clarification contrairement aux guides d architecture, publiés par le département d architecture, qui ont été jugés incompréhensibles par les deux concepteurs. Ensuite, des maquettes des architectures fonctionnelle et logicielle de l outil NREP ont été élaborées de manière itérative par les deux architectes et discutées par les deux concepteurs au cours de plusieurs séances de travail. Les architectures fonctionnelle et logicielle de l outil NREP ont étés définies suite à ces séances de travail. Enfin, il a été décidé d associer à temps partiel - un architecte technique dans les équipes de développement (conception, réalisation) afin d aider les concepteurs et les programmeurs à implémenter les architectures fonctionnelle et logicielle de l outil NREP, et vérifier que toutes les caractéristiques de cette solution ont été prises en compte. En dehors de la formation, quatre autres objets frontières peuvent être identifiés à ce stade. Il s agit de deux objets frontières de clarification et de deux objets frontières de production. Les maquettes des architectures fonctionnelle et logicielle, et l architecte technique associé à l équipe de développement sont des objets frontières de 13

14 clarification. Les deux objets frontières de production sont l architecture fonctionnelle et l architecture logicielle de l outil NREP. La frontière de connaissances entre les concepteurs et les programmeurs off-shore est une frontière intra-espace complexe qu il a été difficile de manager. La complexité de cette frontière est due à l existence de trois types de dispersions : géographique, linguistique, et culturelle. La dispersion géographique traduit l éloignement des équipes de conception et de réalisation. Cet éloignement a été aggravé par la dispersion linguistique causée par les problèmes des langues parlées et écrites par les programmeurs et les concepteurs. Ainsi, la communication entre les deux parties qui a eu lieu par téléphone, par mail, ou par vidéoconférence - a été difficile et a causé de nombreuses incompréhensions. La dispersion culturelle, causée par les différences entre la culture nationale des programmeurs et celle des concepteurs a instauré un climat de méfiance entre les deux parties qui a constitué une barrière pour le partage de connaissances. Les difficultés de communication entre les programmeurs et les concepteurs et l absence de traduction en langue anglaise des documents de conception et des standards à respecter expliquent le fait que dans un premier temps - il n y a pas eu d objet frontière contribuant à manager cette frontière de connaissances. Afin de faire face aux risques d échec du projet, le chef de projet a proposé de faire appel à une société internationale de consulting composée de consultants en SI maîtrisant les langues française et anglaise, dont certains sont d origine indienne. Après l approbation de cette décision par les instances de gouvernance, la société internationale de consulting est devenue l interlocuteur de l équipe de projet et des architectes et l intermédiaire entre ces derniers et les programmeurs de la société indienne off-shore. Elle a ainsi réalisé les traductions en langue anglaise des documents fournis par les concepteurs et des standards à appliquer et rendait compte de l avancement des travaux de programmation au chef de projet. De même, elle a réalisé la traduction en langue française des documents élaborés par les programmeurs indiens et fourni une version en français de l outil NREP destinée aux tests d intégration réalisés par la DSI. A ce stade, plusieurs objets frontières peuvent être identifiés. Ainsi, la version en français du logiciel, les documents de réalisation traduits en langue française, et les documents de conception traduits en langue anglaise sont des objets frontières de transfert. A noter que parmi ces objets frontières, certains seront packagés et livrés aux utilisateurs finaux. Dans ce cas, ils deviendront des objets frontières de production. Les comptes rendus d avancement fournis par la société internationale de consulting sont des objets frontières de communication. Finalement, la société internationale de consulting peut être considérée comme un objet frontière de clarification. La frontière de connaissances entre les experts en méthodes et l équipe de projet traduit la résistance des concepteurs à l application de la méthode standard de conduite de projet définie et recommandée par le département d architecture. Cette méthode est basée sur le modèle de cycle de vie conventionnel en cascade (Boehm, 1976, 1984). Bien qu elle s inspire du modèle en spirale (Boehm, 1998) pour certaines phases où elle autorise le maquettage, le prototypage, et le développement itératif, elle est perçue par les concepteurs comme étant trop contraignante et une source d incohérences et de retards importants. Pour contourner la résistance des concepteurs, le chef de projet a proposé aux experts en méthodes de travailler avec les concepteurs pour identifier les aspects méthodologiques et les standards documentaires dont l application aura une valeur ajoutée significative pour l avancement du projet. Cette décision n a pas été approuvée par les instances de gouvernance qui considèrent que sa mise en œuvre sera coûteuse et causera des retards. Ainsi, aucun objet frontière n a été construit pour manager cette frontière de connaissances. Cette étude de cas présente un triple intérêt. D une part, elle nous a permis de vérifier l intérêt de l approche proposée dans cet article pour identifier les frontières de connaissances dans un projet d informatisation et analyser les objets frontières permettant de les manager. En effet, les études des frontières de connaissances et de leur management dans un projet d informatisation sont souvent descriptives et ne fournissent pas des informations suffisantes pour faciliter le partage de connaissances et aider les instances de gouvernance du projet à prendre les décisions appropriées. D autre part, elle nous a fourni des informations confirmant la nécessité de préciser le concept d objet frontière. Ayant pour objectif de faciliter le partage de connaissances, un objet frontière peut prendre plusieurs formes. Il peut être un artefact informationnel, un être humain ayant des compétences multiples, ou une entité organisationnelle. C est le cas, par exemple, de l assistant à la maîtrise d oeuvre et de la société internationale de consulting dans le cas du projet de développement de l outil NREP. Ce constat confirme en partie les résultats obtenus par Levina et Vaast (2005) et Carton et Farastier (2012) qui ont introduit la notion d acteur-frontière. Par ailleurs, pour être efficaces, les objets frontières ayant la forme d artefacts informationnels doivent être construits collectivement par les acteurs organisationnels impliqués dans une frontière de connaissances. Cela explique le rôle positif joué par les sessions de formation, les prototypes informatifs, et les maquettes pour manager les connaissances aux frontières dans notre étude de cas. Cela explique aussi pourquoi les guides et les standards construits par une catégorie d acteurs ne sont pas toujours des objets frontières efficaces. Enfin, nous avons utilisé cette étude de cas pour mettre en évidence les implications managériales suivantes : 14

15 Pour manager les connaissances aux frontières inter-espaces, on peut utiliser efficacement des acteurs humains ayant des compétences multiples comme objets frontières. Pour manager les connaissances aux frontières résultant de différences de cultures nationales ou de langues parlées ou écrites, des entités organisationnelles peuvent être des objets frontières efficaces. Pour manager une frontière de connaissances à l aide un objet frontière ayant la forme d un artefact informationnel, tous les acteurs organisationnels impliqués dans cette frontière doivent participer à la construction de cet objet frontière. La mise en place d un dictionnaire métier peut aider à manager la frontière de connaissances entre la maîtrise d ouvrage et la maîtrise d œuvre. 8. Conclusion et futures directions de recherche Dans cet article, nous avons proposé un cadre théorique pour analyser les frontières de connaissances dans un projet d informatisation et identifier les objets frontières qui permettent de les manager. Le modèle d informatisation d un projet utilisé dans ce travail constitue un cadre générique d informatisation et non pas une méthode d informatisation particulière. Il est donc ouvert à toutes les approches et les méthodes d informatisation quelle que soit leur nature. Ainsi, l identification des frontières et des objets frontières dans le cadre d un projet d informatisation constitue la première contribution de notre article et la réponse à la première question de recherche posée. L intérêt de cette analyse réside d une part, dans son indépendance des méthodes d informatisation existantes, et d autre part, de la prise en compte par chaque frontière de connaissances identifiée - de la multiplicité des acteurs organisationnels qui y participent. C est le cas notamment des frontières inter-espaces de projet qui, malgré leur dénomination mentionnant deux types d acteurs organisationnels, prennent en compte tous les autres acteurs qui y participent. Par exemple, la frontière de connaissances Client Architecte prend en compte non seulement les types d acteurs «Client» et «Architecte» mais aussi les types d acteurs «Développeur» et «Utilisateur» final qui jouent un rôle secondaire respectivement dans l espace de solution et dans l espace de problème. Le fait que chaque type de frontière de connaissances dans un projet d informatisation inclut de nombreux acteurs organisationnels hétérogènes et détenant des connaissances spécialisées permet de mettre en évidence la complexité de ces frontières et la difficulté de les manager. Par ailleurs, nous avons répondu à la deuxième question de recherche en définissant une typologie d objets frontières dans le cadre d un projet d informatisation et en fournissant des exemples de tels objets. La deuxième contribution de cet article est liée à la précision du concept d objet frontière. Nous avons établi qu un objet frontière peut être soit un artefact informationnel, soit un acteur organisationnel, soit une entité organisationnelle. La troisième contribution de notre article résulte des implications managériales de l approche que nous avons proposée pour manager les connaissances aux frontières. Toutefois, l analyse présentée dans cet article doit être approfondie pour décrire les objets frontières de production issus de l approche politique de négociation. Il s agit de préciser notamment le rôle des cultures nationales et organisationnelles dans la formation des objets frontières de production dans le cas où l innovation et l instabilité ne se limitent pas à la technologie mais incluent des facteurs sociaux et culturels. C est le cas, par exemple, des projets d informatisation dans les organisations virtuelles ou dans les organisations naissant après une fusion. Une autre direction de recherche importante consiste à utiliser les résultats obtenus pour construire des instruments d évaluation de la capacité des méthodes et des approches d informatisation à favoriser le partage de connaissances, et à les appliquer aux principales méthodes et d approches d informatisation. Finalement, les conclusions issues de l étude de cas présentée dans cet article doivent être enrichies et consolidées à l aide d autres études de cas. Il s agit d une troisième direction de recherche. Bibliographie Adler, P., Kwon, S. W. (2002). Social capital: Prospects for a new concept. Academy of Management Review, Vol. 27, No. 1, 2002, pp Alchian, A. A., and Demsetz, H., Production, Information Costs and Economic Organization, American Economic Review, Vol. 62, No. 5, 1972, pp Argote, L., Organizational Learning: Creating, Retaining, and Transferring Knowledge. Kluwer, Norwell, MA, Arthur, M., De Fillippi, R., & Jones, C., Project-based learning as the interplay of career and company nonfinancial capital. Management Learning, Vol. 32, No. 1, 2001, pp Baetjer, H., Jr., Software as Capital: An Economic Perspective on Software Engineering, The Institute of Electrical and Electronics Engineers, Inc., Piscataway, New Jersey, Becker, M. C., Managing dispersed knowledge: organizational problems, managerial strategies, and their effectiveness. Journal of Management Studies, Vol. 38, No. 7, 2001, pp

16 Ben Chouikha M, Dakhli S. Ben Dhaou, Knowledge Sharing Enablers and Barriers: The Case of Virtual Organizations, in the Proceedings of the IFIP-AIS MCIS 2011, Limassol, Cyprus, September 3-5, Ben Chouikha, M., Design de l Organisation Apprenante : Etude de Cas Longitudinale des Equipes de Projet NOKIA SIEMENS NETWORKS, Thèse de doctorat, Université de Paris-IX Dauphine, Paris, Décembre, Birnholtz, J., and Finholt, T., Cultural Challenges to Leadership in Cyberinfrastructure Development. in Leadership at a Distance: Research in Technology-Supported Work, S. Weisband (ed.), New York: Lawrence Erlbaum Associates, 2007, pp Boehm B. W., A Spiral Model of Software Development and Enhancement, Computer, Vol. 21, No. 5, 1988, pp Boehm, B. W., Software Engineering, IEEE Transactions on Computers, Vol. C25, No.12, 1976, pp Boehm, B., Egyed, A., Kwan, J., Port, D., Shah, A., Madachy, R., Using the winwin spiral model: a case study. IEEE Computer, Vol., No. 7, 1998, pp Boehm, B., Grunbacher, P., Briggs, R., Developing groupware for requirements negotiation: lessons learned. IEEE Software, Vol. 18, No. 3, 2001, pp Boehm, B.W., Verifying and Validating Software Requirements and Design specifications, IEEE Software, Vol.1, No.1, 1984, pp Bourdieu, P., Distinction: A Social Critique of the Judgment of Taste. Cambridge, MA: Harvard University Press, Bredillet, C. N., Projects: Learning at the edge of organization. In P. W. Morris & J. K. Pinto (Eds.), The Wiley Guide to Managing Projects, Hoboken: John Wiley & Sons, Briers M., and Chua W. F. The role of actor-networks and boundary objects in management accounting change : a field study of an implementation of activity-based costing, Accounting, Organizations and Society, Vol. 26, 2001, pp Brooks, F. P. Jr., No Silver Bullet-Essence and Accidents of Software Engineering. Computer, Vol. 20, No. 4, 1987, pp Brooks, F. P. Jr., The Mythical Man Month: Essays on Software Engineering, Reading, M.A., Addison-Wesley, Brown, J. S., and Duguid, P., Knowledge and organization: A socialpractice perspective, Organization Science, Vol. 12, 2001, pp Carlile, P. R., A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New Product Development, Organization Science, Vol. 13, No. 4, 2002, pp Carlile, P. R., and Østerlund, C., Relations in Practice: Sorting Through Practice Theories on Knowledge Sharing in Complex Organizations, Information Society, Vol. 21, No. 2, 2005, pp Carlile, P. R., and Rebentisch, E. S., Into the Black Box: The Knowledge Transformation Cycle. Management Science, Vol. 49, No. 9, 2003, pp Carlile, P. R., Transferring, Translating, and Transforming: An Integrative Framework for Managing Knowledge across Boundaries, Organization Science, Vol. 15, No. 5, 2004, pp Carton, S., and Farastier, A., Intégration des connaissances client dans un projet en systèmes d information : influence de l environnement de connaissance du projet, Revue Systèmes d Information et Management, Vol. 17, No. 2, Chan, R., & Rosemann, M., Managing knowledge in enterprise systems. Journal of Systems and Information Systems, Vol. 5, No. 2, 2001, pp Chan, Y. E., Why Haven't We Mastered Alignment? The Importance of the Informal Organization Structure. MIS Quarterly Executive, Vol. 1, No. 2, pp Coase, R., The Nature Of The Firm, Economica, Vol. 4, 1937, pp , Traduction Française: Revue Française d'economie, Vol. 2, No. 1, 1987, pp Cramton, C. D., & Hinds, P. J., Intercultural Interaction in Distributed Teams: Salience of and Adaptations to Cultural Differences. In Proceedings of the Academy of Management Annual Meeting, Best Papers, G. Salomon (ed.), Philadelphia, PA, August 3-8, Cramton, C. D., The Mutual Knowledge Problem and Its Consequences for Dispersed Collaboration. Organization Science, Vol. 12, No. 3, 2001, pp Dakhli, S. B. D., The Solution Space Organiszation: Linking Information Systems Architecture and Reuse. In the Proceedings of the ISD 2008 Conference, Paphos, Cyprus, August 25-27, Springer-Verlag, DiMaggio, P. J., Social Structure, Institutions, and Cultural Goods: The Case of the United States. In Social Theory for a Changing Society, P. Bourdieu and J. S. Coleman (eds.), Boulder, NY: Westview Press, 1991, pp Espinosa, J. A., Cummings, J. N., Wilson, J. M., & Pearce, B. M., Team Boundary Issues across Multiple Global Firms. Journal of Management Information Systems, Vol. 19, No. 4, 2003, pp Feng; Y., Ye, H.; and Pan, S. L, Delivering Knowledge Across Boundaries: A Case Study of Bankco s Offshoring Projects, Pacific Asia Journal of the Association for Information Systems, Vol. 3, No. 3, 2011, pp Available at: Flichy, P. L innovation technique, La découverte, Paris, Galbraith, J. R., Designing complex organizations, Addison-Wesley Publishing Company,

17 Gurbaxani V., & Whang S., The Impact of Information Systems on Organizations and Markets. Communications of the ACM, Vol. 34, No. 1, 1991, pp Hardy, C., Lawrence, T. B., & Grant, D., Discourse and Collaboration: The Role of Conversations and Collective Identity. Academy of Management Review, Vol. 30, No. 1, 2005, pp Henderson, J. C. & Venkatraman, N., Strategic Alignment: A Model for Organizational Transformaton via Information Technology. In Allen, T. J. & Scott Morton, M. S. (Eds.), Information Technology and the corporation of the 1990s. Research Studies. Oxford: Oxford University Press, Henderson, J. C. & Venkatraman, N., Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal, Vol. 32, No. 1, 1993, pp Hinds, P. J., & Mortensen, M., Understanding Conflict in Geographically Distributed Teams: The Moderating Effects of Shared Identity, Shared Context, and Spontaneous Communication. Organization Science, Vol. 16, No. 3, 2004, pp Hirschheim, R., & Sabherwal, R. (2001). Detours toward Strategic Information Systems Alignment. California Management Review, Vol. 44, No. 1, pp Hoegl, M., and Gemuenden, H. G., Teamwork Quality and the Success of Innovative Projects: A Theoretical Concept and Empirical Evidence. Organization Science, Vol. 12, No. 4, 2001, pp Jensen, M. C., and Meckling, W. H., Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure, Journal of Financial Economics, Vol. 3, No. 4, 1976, pp Krishna, S., Sahay, S., & Walsham, G., Cross-Cultural Issues in Global Software Outsourcing. Communications of the ACM, Vol. 47, No. 4, pp Lam, A., Embedded Firms, Embedded Knowledge: Problems of Collaboration and Knowledge Transfer in Global Cooperative Ventures. Organization Studies, Vol. 18, No. 6, pp Leavitt, H. J., (ed.), The Social Science of Organizations, Four Perspectives, Prentice-Hall, Englewood Cliffs, New Jersey, Leonard-Barton, D., Well Springs of Knowledge: Building and Sustaining the Sources of Innovation. Harvard Business School Press, Boston, MA, Leseure, M. J., & Brookes, N. J., Knowledge management benchmarks for project management. Journal of Knowledge Management, Vol. 8, No. 1, 2004, pp Levina, N., & Vaast, E., Innovating or Doing as Told? Status Differences and Overlapping Boundaries in Offshore Collaboration. MIS Quarterly, Vol. 32, No. 2, 2008, pp Levina, N., & Vaast, E., The Emergence of Boundary Spanning Competence in Practice: Implications for Implementation and Use of Information Systems, MIS Quarterly, Vol. 29, No. 2, 2005, pp Levina, N., and Vaast, E., Turning a Community into a Market: A Practice Perspective on It Use in Boundary- Spanning. Journal of Management Information Systems, Vol. 22, No. 4, 2006, pp Levina, N., Collaborating on Multiparty Information Systems Development Projects: A Collective Reflection-in- Action View. Information Systems Research, Vol. 16, No. 2, 2005, pp Litwak, E., and Hylton, L. F., Interorganizational Analysis: A hypothesis on coordination agencies. Administrative Science Quarterly, Vol. 6, 1962, pp Lundin, R. A., & Soderholm, A., A Theory of the temporary organization. Scandinavian Journal of Management, Vol. 11, No. 4, 1995, pp Maaninen-Olsson, E., Wismén, M., Carlsson, A, A., Permanent and temporary work practices: knowledge integration and the meaning of boundary activities, Knowledge Management Research & Practice, Vol. 6, No. 4, 2008, pp Meehan, B., & Richardson, I., Identification of software process knowledge management. Software Process Improvement and Practice, Vol. 7, No. 2, 2002, pp Metiu, A., Owning the Code: Status Closure in Distributed Groups. Organization Science, Vol. 17, No. 4, 2006, pp Meyer M., Objet-frontière ou Projet-frontière?. Construction, (non-)utilisation et politique d une banque de données, Revue d'anthropologie des connaissances, Vol. 3, No. 1, 2009, pp Montgomery, K., & Oliver, A. L., A Fresh Look at How Professions Take Shape: Dual-Directed Networking Dynamics and Social Boundaries. Organization Studies, Vol. 28, 2007, pp Newell, S., Tansley, C. Huang, J., Social Capital and Knowledge Integration in an ERP Project Team: The Importance of Bridging AND Bonding. British Journal of Management, 15, 2004, pp Nonaka, I., and Takeuchi, I., The Knowledge-Creating Organization, Oxford Press, Oxford, U.K., Packendorff, J., Inquiring into the temporary organization: New directions for project management research. Scandinavian Journal of Management, Vol. 11, No. 4, 1995, pp Putnam, R., Bowling alone: The collapse and revival of American community, Simon and Shuster, New York, Reich, B. H., & Wee, S. Y., Searching for knowledge in the PMBOK guide. Project Management Journal, Vol. 37, No. 2, 2006, pp Reich, B. H., Gemino, A., & Sauer, C., Modeling the Knowledge Perspective of IT Projects. Project Management Journal, Vol. 39, Supplement, 2008, pp. S4 S14. 17

18 Reich, B. H., Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice. Project Management Journal,Vol. 38, No. 2, 2007, pp Sabherwal, R., & Chan, Y. E., Alignment Between Business and IS Strategies: A Study of Prospectors, Analyzers, and Defenders. Information Systems Research, Vol. 12, No. 1, pp Soderlund, I., Managing complex development projects: Arenas, knowledge processes and time. R & D Management, Vol. 32, No. 5, 2002, pp Star, S., and Griesemer J., Institutional Ecology, Translations, and Boundary Objects: Amateurs and Professionals in Berkeley s Museum of Vertebrate Zoology, , Social Studies of Science, Vol. 19, No. 3, 1989, pp Thiétart, R. A., Méthodes de recherche en management, Paris, Editions Dunod, Toffolon, C., and Dakhli, S., The Software Engineering Global Model. In Proceedings of the COMPSAC 2002 Conference, Oxford, United Kingdom, Los Alamitos (pp ), CA: IEEE Computer Society Press, Toffolon, C., L Incidence du Prototypage dans une Démarche d Informatisation, Thèse de doctorat, Université de Paris-IX Dauphine, Paris, Décembre, Toffolon, C., The Software Dimensions Theory. In Joaquim Filipe (Ed.), Enterprise Information Systems, Selected Papers Book, KLUWER ACADEMIC PUBLISHERS, Tumer, R. J., & Muller, R., On the nature of the project as a temporary organization. International Journal of Project Management, Vol. 21, No. 1, 2003, pp Venkatraman, N., IT-enabled business transformation: From automation to business scope redefinition. Sloan Management Review, 1994 (Winter), pp Vinck D., De l objet intermédiaire à l objet-frontière : Vers la prise en compte du travail d équipement, Revue d'anthropologie des connaissances, Vol. 3,No. 1, 2009, pp Walsham, G., Cross-Cultural Software Production and Use: A Structurational Analysis. MIS Quarterly, Vol. 26, No. 4, 2002, pp Walz, D. B., Elam, J. J., & Curtis, B., Inside a software design team: Knowledge acquisition, sharing and integration. Communications of ACM, Vol. 36, No. 10, 1993, pp Wenger, E., Communities of Practice : Learning, Meaning and Identity, New York, Cambridge University Press, Williamson, O. E., The Modern Corporation: Origins, Evolution, Attributes, Journal of Economic Literature, Vol. 19, 1981, pp Winter, S., and Szulanski, G., Replication as strategy. Organization Science, Vol. 16, 2001, pp Yin, R. K., Case Study Research: Design and Methods, Beverly Hills, CA : Sage Publishing, Yoo, Y., & Kanawattanachai, P., Developments of transactive memory systems and collective mind in virtual teams. The International Journal of Organizational Analysis, Vol. 9, No. 2, 2001, pp Remerciements: Je remercie Dr. Salem Ben Dhaou DAKHLI pour avoir accepté de relire cet article, pour ses conseils et ses remarques détaillées sur les parties théorique et empirique, et pour son aide dans le cadre de l étude de cas. 18