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

Dimension: px
Commencer à balayer dès la page:

Download "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

URBANISME DES SYSTÈMES D INFORMATION

URBANISME DES SYSTÈMES D INFORMATION FAYCAL AYECH GL2. INSAT 2010/2011 INTRODUCTION AUX SYSTÈMES D INFORMATIONS URBANISME DES SYSTÈMES D INFORMATION De l Urbanisme à L Urbanisation des SI Urbanisme : Mise en œuvre des politiques urbaines

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

SPECIALISATIONS DU MASTER GRANDE ECOLE

SPECIALISATIONS DU MASTER GRANDE ECOLE SPECIALISATIONS DU MASTER GRANDE ECOLE Finance, Contrôle des Organisations Cette spécialisation se fonde sur la nécessité de prendre des décisions et/ou d organiser les différents processus au cœur de

Plus en détail

FILIÈRE METHODOLOGIE & PROJET

FILIÈRE METHODOLOGIE & PROJET FILIÈRE METHODOLOGIE & PROJET 109 Gestion de projet METHODOLOGIE ET PROJET Durée 3 jours Conduite de projet COND-PRO s Intégrer les conditions de réussite d une démarche de management par projet. Impliquer

Plus en détail

LISTE DES FORMATIONS. Mai 2015

LISTE DES FORMATIONS. Mai 2015 Gestion de projet Analyse d affaires Formation Évaluation de performance +1.514.826.5534 info@lcgsolution.com www.lcgsolution.com LCG Solution se distingue par la qualité du matériel de formation, la qualité

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

étude de rémunérations

étude de rémunérations étude de rémunérations dans la finance de marché Les salaires des métiers de la Moe et de la Moa AVEC NOUS, VOTRE TALENT PREND DE LA VALEUR 1 Sommaire Le mot des dirigeants Présentation METIERS DE LA MOE

Plus en détail

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité

Plus en détail

Pratique de logiciels de planification

Pratique de logiciels de planification Pratique de logiciels de planification MASTER TECHNOLOGIE & HANDICAP Université Paris 8 Sommaire Introduction Organisation d un projet Les principaux axes de la planification Gestion des tâches Gestion

Plus en détail

وزارة السكنى والتعمير وسياسة المدينة

وزارة السكنى والتعمير وسياسة المدينة وزارة السكنى والتعمير وسياسة المدينة Phase 3 Planification de la solution retenue et stratégie de changement Elaboration du Schéma Directeur du Système d Information des agences urbaines 2013 Sommaire

Plus en détail

[ Hornet ] Charte de méthodologie

[ Hornet ] Charte de méthodologie [ Hornet ] Hornet Cette création est mise à disposition selon le Contrat Paternité - Pas d'utilisation Commerciale - Partage des Conditions Initiales à l'identique disponible en ligne http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

Plus en détail

Mettre en place une infrastructure Web nouvelle génération avec Drupal et Acquia

Mettre en place une infrastructure Web nouvelle génération avec Drupal et Acquia Mettre en place une infrastructure Web nouvelle génération avec Drupal et Acquia Pour l architecte de solutions web Table des matières Présentation générale... 3 Des outils disparates.... 4 Une gestion

Plus en détail

M2S. Formation Gestion de projet. formation

M2S. Formation Gestion de projet. formation Formation Gestion de projet M2S formation Conduire et gérer un projet Construire et rédiger un chahier des charges de projet Conduite de projet informatiques Découpage et planification de projet Les méthodes

Plus en détail

Découvrez la gestion collaborative multi-projet grâce à la. solution Project EPM

Découvrez la gestion collaborative multi-projet grâce à la. solution Project EPM Découvrez la gestion collaborative multi-projet grâce à la solution Project EPM Project EPM 2007 est la solution de gestion de projets collaborative de Microsoft. Issue d une longue expérience dans le

Plus en détail

CHARTE ACTION LOGEMENT SUR :

CHARTE ACTION LOGEMENT SUR : CHARTE ACTION LOGEMENT SUR : LA GESTION DES RISQUES LE CONTROLE INTERNE L AUDIT INTERNE Validée par le Conseil de surveillance du 18 septembre 2013 1/22 SOMMAIRE INTRODUCTION... 3 I. LE CADRE DE REFERENCE...

Plus en détail

Systèmes et réseaux d information et de communication

Systèmes et réseaux d information et de communication 233 DIRECTEUR DES SYSTÈMES ET RÉSEAUX D INFORMATION ET DE COMMUNICATION Code : SIC01A Responsable des systèmes et réseaux d information FPESIC01 Il conduit la mise en œuvre des orientations stratégiques

Plus en détail

Autres appellations du métier

Autres appellations du métier Le métier aujourd'hui Autres appellations du métier Chef de projet informatique Chef de projet fonctionnel Chef de projet maîtrise d œuvre Chef de projet maîtrise d ouvrage (ou AMOA) Description synthétique

Plus en détail

Gestion et management de projet - Introduction - 1 -

Gestion et management de projet - Introduction - 1 - I Gestion et management de projet - Introduction - 1 - Définition du projet et de la gestion de projets. I-1 Actualité de la gestion de projet ancien ; extension et modification des projets depuis 30 ans

Plus en détail

Conseil opérationnel en organisation, processus & système d Information. «Valorisation, Protection et Innovation de votre Patrimoine Numérique»

Conseil opérationnel en organisation, processus & système d Information. «Valorisation, Protection et Innovation de votre Patrimoine Numérique» "Innovation, Valorisation et Protection du Patrimoine Numérique!" Conseil opérationnel en organisation, processus & système d Information «Valorisation, Protection et Innovation de votre Patrimoine Numérique»

Plus en détail

Leader de l Actuariat Conseil et de la Gestion des Risques

Leader de l Actuariat Conseil et de la Gestion des Risques Leader de l Actuariat Conseil et de la Gestion des Risques Optimind Winter respecte les meilleurs standards européens sur l ensemble des expertises associées à la chaîne des risques des organismes assureurs,

Plus en détail

Instance Nationale de Concertation CNAF Projet de Transformation de la DSI et des fonctions SG/AC

Instance Nationale de Concertation CNAF Projet de Transformation de la DSI et des fonctions SG/AC Instance Nationale de Concertation CNAF Projet de Transformation de la DSI et des fonctions SG/AC Le 5 Mars 2015 Version de travail Projet Février 2015-1 Ordre du jour Avancement des travaux Rappel du

Plus en détail

Le génie Logiciel (suite)

Le génie Logiciel (suite) Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information

Plus en détail

SYSTEMES D INFORMATION & CONCEPTION de BdD

SYSTEMES D INFORMATION & CONCEPTION de BdD SYSTEMES D INFORMATION & CONCEPTION de BdD PLAN CONCEPT DE SYSTEME D INFORMATION MODELISATION D UN SYSTEME D INFORMATION MODELISATION CONCEPTUELLE : les METHODES METHODE SYSTEMIQUE METHODE OBJET L3 Informatique

Plus en détail

Aligner le SI sur la stratégie de l entreprise

Aligner le SI sur la stratégie de l entreprise En convention avec la chaire Ecole Polytechnique Thales «Ingénierie des systèmes complexes» Aligner le SI sur la stratégie de l entreprise Etude de cas: Transformation d un Système d Information Philippe

Plus en détail

ACube. Charte méthodologique. Version 1.2 du 22/02/2010. Etat : Validé

ACube. Charte méthodologique. Version 1.2 du 22/02/2010. Etat : Validé Charte méthodologique Version 1.2 du 22/02/2010 Etat : Validé Communauté Adullact Projet SUIVI DES MODIFICATIONS Version Rédaction Description Vérification Date 1.0 S. Péguet Initialisation 20/03/07 1.1

Plus en détail

Cours de Génie Logiciel. David Janiszek. Le projet. En résumé. Troisième partie III. Eléments de gestion de projet

Cours de Génie Logiciel. David Janiszek. Le projet. En résumé. Troisième partie III. Eléments de gestion de projet Troisième partie III Eléments de gestion de projet Un projet informatique est l ensemble des activités et des actions à entreprendre pour répondre au besoin d informatisation d un ensemble de tâches dans

Plus en détail

Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise.

Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise. Solutions PME VIPDev Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise. Cette offre est basée sur la mise à disposition de l ensemble de nos compétences techniques et créatives au service

Plus en détail

Créateur d applications web et mobiles

Créateur d applications web et mobiles Créateur d applications web et mobiles Projets Performances Team http://www.projet2team.fr Projet2Team Projets Performances Team http://www.projet2team.fr SAS au capital de 25.000 - RCS 789 681 285 7 rue

Plus en détail

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Notion de méthode de conception de SI Méthodes OO de conception Généralités sur les méthodes

Plus en détail

ITIL V3. Objectifs et principes-clés de la conception des services

ITIL V3. Objectifs et principes-clés de la conception des services ITIL V3 Objectifs et principes-clés de la conception des services Création : janvier 2008 Mise à jour : juillet 2011 A propos A propos du document Ce document de référence sur le référentiel ITIL V3 a

Plus en détail

Domaines de consultation bso

Domaines de consultation bso Domaines de consultation bso Supervision Compétences-clé Conseil en organisation Coaching La supervision, le conseil en organisation et le coaching sont des domaines de consultation professionnels adaptés

Plus en détail

DEVENEZ CHEF DE PROJET! VERSION 3 > Certificat d études avancées en Management de Projet Appliqué

DEVENEZ CHEF DE PROJET! VERSION 3 > Certificat d études avancées en Management de Projet Appliqué DEVENEZ CHEF DE PROJET! COURS POSTGRADE DE LA HES-SO Développé et animé par la HEG de Genève LA REUSSITE N EST JAMAIS UN HASARD VERSION 3 > Certificat d études avancées en Management de Projet Appliqué

Plus en détail

Fonctions Informatiques et Supports Opérationnels

Fonctions Informatiques et Supports Opérationnels Fonctions Informatiques et Supports Opérationnels Nos métiers par activité Nos métiers de l informatique comprennent d une part un volet études et d autre part la gestion des infrastructures ; les fonctions

Plus en détail

Concours interne de l agrégation du second degré. Section économie et gestion. Programme de la session 2013

Concours interne de l agrégation du second degré. Section économie et gestion. Programme de la session 2013 Concours interne de l agrégation du second degré Concours interne d accès à l échelle de rémunération des professeurs agrégés dans les établissements d enseignement privés sous contrat du second degré

Plus en détail

Banque Accord redonne de l agilité à son système d information avec l aide de MEGA

Banque Accord redonne de l agilité à son système d information avec l aide de MEGA redonne de l agilité à son système d information avec l aide de MEGA À propos de Banque Accord : Filiale financière du groupe Auchan Seule banque française détenue à 100% par un distributeur 3 activités

Plus en détail

Elles énumèrent les connaissances qui doivent être acquises par les élèves à l issue de la classe terminale.

Elles énumèrent les connaissances qui doivent être acquises par les élèves à l issue de la classe terminale. Annexe 5 SCIENCES DE GESTION - CLASSE TERMINALE SPÉCIALITÉ : SYSTÈMES D INFORMATION DE GESTION Présentation Les technologies de l information et de la communication contribuent à la construction d'une

Plus en détail

ITIL V3. Transition des services : Principes et politiques

ITIL V3. Transition des services : Principes et politiques ITIL V3 Transition des services : Principes et politiques Création : janvier 2008 Mise à jour : août 2009 A propos A propos du document Ce document de référence sur le référentiel ITIL V3 a été réalisé

Plus en détail

LA GESTION DE PROJET

LA GESTION DE PROJET LA GESTION DE PROJET Introduction... 2 I. Le projet... 2 A. Définition du projet... 3 B. Types de projet... 3 C. Caractéristiques d un projet... 3 D. Triangle des acteurs... 4 II. Management de projet....

Plus en détail

Le Référentiel Management/Encadrement

Le Référentiel Management/Encadrement répertoire des métiers Le Référentiel Management/Encadrement Le management/encadrement est vu comme une fonction transversale liée à l organisation et à l ensemble des familles professionnelles. Le référentiel

Plus en détail

Référentiel professionnel pour le Diplôme d État d Ingénierie Sociale DEIS

Référentiel professionnel pour le Diplôme d État d Ingénierie Sociale DEIS Institut du Travail Social de Tours Cellule VAE Référentiel professionnel pour le Diplôme d État d Ingénierie Sociale DEIS Annexe I de l arrêté du 2 août 2006 relatif au Diplôme d État d Ingénierie Sociale

Plus en détail

METIER DU CYCLE DE VIE DES APPLICATIONS

METIER DU CYCLE DE VIE DES APPLICATIONS METIER DU CYCLE DE VIE DES APPLICATIONS Finalité : Répondre aux besoins des utilisateurs en mettant à leur disposition des solutions informatiques applicatives et techniques adaptées. Emplois génériques

Plus en détail

Ensemble mobilisons nos énergies

Ensemble mobilisons nos énergies Ensemble mobilisons nos énergies «Lancé en Juin 2005, SIRIUS est désormais un projet au cœur de notre entreprise, au service des ambitions et des objectifs qui s inscrivent dans le cadre de notre stratégie

Plus en détail

Ingénieurs en Réseaux et Télécom 8 à 10 ans

Ingénieurs en Réseaux et Télécom 8 à 10 ans Participer à l élaboration du schéma directeur des réseaux et télécom et assurer le suivi de sa mise en œuvre ; Définir une politique de maîtrise des risques liées aux systèmes, réseaux et télécoms, ainsi

Plus en détail

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013 UML Mise en œuvre dans un projet 2013 Introduction Rôles et activités dans un projet Définir la méthode de votre projet Adapter la modélisation à la méthode de votre projet Conseils de mise en œuvre de

Plus en détail

MICROSOFT DYNAMICS CRM & O Val

MICROSOFT DYNAMICS CRM & O Val MICROSOFT DYNAMICS CRM & O Val O Val Operational Value JSI Groupe 2, rue Troyon 92310 Sèvres 1 AGENDA 1. QUI SOMMES-NOUS? 2. NOS OFFRES 3. UNE ORGANISATION COMMERCIALE DÉDIÉE À NOS CLIENTS 4. O VAL : OPERATIONAL

Plus en détail

UDSG CLASSIFICATION DOSSIER DOCUMENTAIRE

UDSG CLASSIFICATION DOSSIER DOCUMENTAIRE UDSG CLASSIFICATION DOSSIER DOCUMENTAIRE 2 SOMMAIRE I. LES FAMILLES PROFESSIONNELLES... 5 II. LES FONCTIONS GENERIQUES... 12 FAMILLE ETUDES ET CONCEPTION......... 15 ASSISTANT D ETUDES ET CONCEPTION...16

Plus en détail

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie Licence en Informatique à Horraire Décalé Cours Gestion de projet informatique Première partie 1 PLAN Introduction 1. Les concepts de base en management de projet : 3-33 2 Les processus du management de

Plus en détail

Urbanisation des Systèmes d'information

Urbanisation des Systèmes d'information Urbanisation des Systèmes d'information Les Audits de Systèmes d Information et leurs méthodes 1 Gouvernance de Système d Information Trois standards de référence pour trois processus du Système d Information

Plus en détail

Votre infrastructure est-elle? La collaboration informatique. améliore la performance globale

Votre infrastructure est-elle? La collaboration informatique. améliore la performance globale Votre infrastructure est-elle? La collaboration informatique améliore la performance globale Des processus automatisés Travail isolé ou processus de groupe : où en êtes-vous? Le travail en équipe a toujours

Plus en détail

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

Services informatiques aux organisations

Services informatiques aux organisations I. APPELLATION DU DIPLÔME II. CHAMP D'ACTIVITÉ Services informatiques aux organisations Spécialité «Solutions logicielles et applications métiers» Spécialité «Solutions d infrastructure, systèmes et réseaux»

Plus en détail

Management de l Innovation

Management de l Innovation Management de l Innovation Mention du Master Sciences et Technologies de l Université Pierre et Marie Curie Directeur du Département de Formation : Patrick Brézillon Contact secrétariat : 01 44 39 08 69

Plus en détail

Modélisation des Systèmes d Information Jean-Yves Antoine

Modélisation des Systèmes d Information Jean-Yves Antoine Modélisation des Systèmes d Information Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine Processus de développement logiciel Jean-Yves Antoine U. Bretagne Sud - UFR SSI - IUP Vannes année 2001-2002

Plus en détail

Cadre de référence pour soutenir la gestion et la revue diligente des projets en ressources informationnelles

Cadre de référence pour soutenir la gestion et la revue diligente des projets en ressources informationnelles Cadre de référence pour soutenir la gestion et la revue diligente des projets en ressources informationnelles Document d orientation aux organismes publics Annexe A Rôles et responsabilités détaillés des

Plus en détail

WHITEPAPER. Quatre indices pour identifier une intégration ERP inefficace

WHITEPAPER. Quatre indices pour identifier une intégration ERP inefficace Quatre indices pour identifier une intégration ERP inefficace 1 Table of Contents 3 Manque de centralisation 4 Manque de données en temps réel 6 Implémentations fastidieuses et manquant de souplesse 7

Plus en détail

Octobre 2010. Ressources. Prévention des risques psychosociaux : le plan d actions national

Octobre 2010. Ressources. Prévention des risques psychosociaux : le plan d actions national Octobre 2010 Ressources Prévention des risques psychosociaux : le plan d actions national Prévention des risques psychosociaux : Le plan d actions national Le diagnostic concernant les risques psychosociaux,

Plus en détail

Guide pratique des solutions d automatisation des processus métier Avril 2014

Guide pratique des solutions d automatisation des processus métier Avril 2014 Guide pratique des solutions d automatisation des processus métier Avril 2014 Kemsley Design Limited Kemsley Design Limited www.kemsleydesign.com www.column2.com www.kemsleydesign.com www.column2.com Présentation

Plus en détail

HERMES 5.1. Méthode de gestion pour tous les projets MANUEL POUR MANAGER

HERMES 5.1. Méthode de gestion pour tous les projets MANUEL POUR MANAGER HERMES 5.1 Méthode de gestion pour tous les projets MANUEL POUR MANAGER ManagerHERMES_FR.indd 1 20.05.15 12:05 ManagerHERMES_FR.indd 2 20.05.15 12:05 «Ce qui dure, c est le changement» (Michael Richter,

Plus en détail

ALDEA ET SYSTEMES D INFORMATION

ALDEA ET SYSTEMES D INFORMATION ALDEA CONSEIL EN ORGANISATION ET SYSTEMES D INFORMATION 30 avenue du Général Leclerc 92100 Boulogne-Billancourt Tel : +33 1 55 38 99 38 Fax : +33 1 55 38 99 39 www.aldea.fr Aldea - Conseil Organisation

Plus en détail

Tous droits réservés SELENIS

Tous droits réservés SELENIS 1. Objectifs 2. Etapes clefs 3. Notre proposition d accompagnement 4. Présentation de SELENIS 2 Un projet est une réalisation spécifique, dans un système de contraintes donné (organisation, ressources,

Plus en détail

Les rôles respectifs des acteurs et des Instances dans la conduite d un projet informatique

Les rôles respectifs des acteurs et des Instances dans la conduite d un projet informatique Les rôles respectifs des acteurs et des Instances dans la conduite d un projet informatique Conduite de projet dossier Le souci de maîtriser des projets informatiques a donné lieu à de multiples tentatives

Plus en détail

Extrait du référentiel Métiers de la Branche :

Extrait du référentiel Métiers de la Branche : OPIIEC OBSERVATOIRE PARITAIRE DES METIERS DE L, DE L INGENIERIE, DES ETUDES ET DU CONSEIL REFERENTIEL METIERS Extrait du référentiel Métiers de la Branche : Etudes et développement Référentiel Métiers

Plus en détail

Generali France optimise la visibilité et la gestion de l ensemble du portefeuille de projets informatiques grâce à la solution PPM de CA Clarity.

Generali France optimise la visibilité et la gestion de l ensemble du portefeuille de projets informatiques grâce à la solution PPM de CA Clarity. PRESENTATION DE LA TECHNOLOGIE : INNOVATION ET TRANSFORMATION DES ACTIVITES Generali France optimise la visibilité et la gestion de l ensemble du portefeuille de projets informatiques grâce à la solution

Plus en détail

Introduction. Pourquoi ce livre?

Introduction. Pourquoi ce livre? Introduction Pourquoi ce livre? La gestion de projet est un processus à la fois courant et complexe de nos organisations. Courant car la culture du travail en «mode projet» fait partie du vocabulaire et

Plus en détail

Le développement des compétences au service de l organisation apprenante

Le développement des compétences au service de l organisation apprenante Daniel Held et Jean-Marc Riss : Le développement des compétences au service de l organisation apprenante Paru dans : Employeur Suisse, no 13, 1998 Les changements de plus en plus importants et rapides

Plus en détail

Altaïr Conseil. Gestion des risques et pilotage des projets informatiques

Altaïr Conseil. Gestion des risques et pilotage des projets informatiques Gestion des risques et pilotage des projets informatiques Altaïr Conseil 33, rue Vivienne 75 002 Paris - Tél. : 01 47 33 03 12 - Mail : contact@altairconseil.fr Constats Des projets de plus en plus nombreux

Plus en détail

OpenPaaS Le réseau social d entreprise. Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations

OpenPaaS Le réseau social d entreprise. Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations OpenPaaS Le réseau social d entreprise Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations Propriétés du Document Source du Document Titre du Document FSN OpenPaaS

Plus en détail

Composition à partir d'un dossier portant sur les éléments généraux du droit et sur le droit des affaires

Composition à partir d'un dossier portant sur les éléments généraux du droit et sur le droit des affaires Concours externe de l agrégation du second degré Section économie et gestion Programme de la session 2013 Les candidats à l'agrégation externe d économie et gestion ont le choix entre cinq options : -

Plus en détail

Gestion de projet & management informatique. augmentez l expertise de votre capital humain

Gestion de projet & management informatique. augmentez l expertise de votre capital humain Gestion de projet & management informatique augmentez l expertise de votre capital humain GESTION DE PROJET GENERALISTE 3 jours GPMI01 Cette formation vous apportera la maîtrise du bon déroulement de vos

Plus en détail

Processus de développement UP

Processus de développement UP Chapitre 1 Processus de développement UP I. Pourquoi UP? II. Définition III. Activités et phases IV. Modèles mis en place 1. Pourquoi UP? Les notions de base acquises dans le module ACOO1, notamment la

Plus en détail

GL - 2 2.1 Le Génie Logiciel

GL - 2 2.1 Le Génie Logiciel GL - 2 2.1 Le Génie Logiciel Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda 1 Rappels La production logicielle est une activité complexe de façon

Plus en détail

Les concepts de l ingénierie et de l intégration des systèmes

Les concepts de l ingénierie et de l intégration des systèmes Les concepts de l ingénierie et de l intégration des systèmes Systèmes et processus d Ingénierie Systèmes Yann Pollet Conservatoire National des Arts et Métiers Chaire d intégration des systèmes «Complexité»

Plus en détail

Forum panafricain sur le leadership et le management de l action gouvernementale. Forum des secrétaires généraux de gouvernement

Forum panafricain sur le leadership et le management de l action gouvernementale. Forum des secrétaires généraux de gouvernement Centre Africain de Formation et de Recherche Administratives pour le développement Fondation pour le Renforcement des Capacités en Afrique (ACBF) Forum panafricain sur le leadership et le management de

Plus en détail

URBANITES! Lausanne, 16 février 2015!

URBANITES! Lausanne, 16 février 2015! URBANITES Lausanne, 16 février 2015 Urbanistes dans la ville : enjeux de la formation savoirs, savoir-faire, savoir dire Antonio Da Cunha Professeur ordinaire Institut de géographie et durabilité Faculté

Plus en détail

Prendre la bonne décision, au bon moment, sur le bon sujet, sur la base des meilleures analyses, pour agir sur le bon indicateur.

Prendre la bonne décision, au bon moment, sur le bon sujet, sur la base des meilleures analyses, pour agir sur le bon indicateur. 2 Toute entreprise dispose d un capital informationnel qui, s il est efficacement géré, contribue à sa valeur et à sa performance. La société RHeport, propose une solution logicielle : RH&View, innovante,

Plus en détail

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 CYCLE de VIE des SYSTEMES INFORMATISES Expression du besoin Développement du «système» Exploitation

Plus en détail

TdB Informatique de l'acv: dictionnaire des indicateurs

TdB Informatique de l'acv: dictionnaire des indicateurs TdB Informatique de l'acv: dictionnaire des indicateurs Informations générales sur le document Type de document Stratégie Standard Document de référence Exigence d application Obligatoire Recommandé Domaine

Plus en détail

ESTIMATIONS DES CHARGES D UN PROJET DE SYSTEME D INFORMATIONS. 05/09/2007 V1.0 Gestion projets - Estimation charges 1

ESTIMATIONS DES CHARGES D UN PROJET DE SYSTEME D INFORMATIONS. 05/09/2007 V1.0 Gestion projets - Estimation charges 1 ESTIMATIONS DES CHARGES D UN PROJET DE SYSTEME D INFORMATIONS 05/09/2007 V1.0 Gestion projets - Estimation charges 1 - Risques projets Sommaire: - Estimation des charges - Méthodes d Estimation 05/09/2007

Plus en détail

Les grandes familles du numérique

Les grandes familles du numérique Les grandes familles du numérique Les métiers de la production Gérer, exploiter et veiller les systèmes informatiques et réseaux Technicien infrastructure Technicien système, intégration, réseau, télécom,

Plus en détail

Etude de mise en place d un système de contrôle de gestion et d évaluation des performances des agences des bassins hydrauliques (ABH) au Maroc

Etude de mise en place d un système de contrôle de gestion et d évaluation des performances des agences des bassins hydrauliques (ABH) au Maroc Etude de mise en place d un système de contrôle de gestion et d évaluation des performances des agences des bassins hydrauliques (ABH) au Maroc Atelier de travail sur les Systèmes d Information de Gestion

Plus en détail

La modernisation de la gestion publique au sein des EPSCP. Colloque des Agents Comptables. 05 juin 2015

La modernisation de la gestion publique au sein des EPSCP. Colloque des Agents Comptables. 05 juin 2015 La modernisation de la gestion publique au sein des Colloque des Agents Comptables 05 juin 2015 EPSCP Frédéric Dehan Directeur Général des Services Université de Strasbourg 1) Des éléments de contexte

Plus en détail

STRATEGIE, GOUVERNANCE ET TRANSFORMATION DE LA DSI

STRATEGIE, GOUVERNANCE ET TRANSFORMATION DE LA DSI STRATEGIE, GOUVERNANCE ET TRANSFORMATION DE LA DSI NOTRE EXPERTISE Dans un environnement complexe et exigeant, Beijaflore accompagne les DSI dans le pilotage et la transformation de la fonction SI afin

Plus en détail

Cartographie Applicative existante Page 1 sur 5

Cartographie Applicative existante Page 1 sur 5 Cartographie Applicative existante Page 1 sur 5 Nom de l application Inclure le numéro de version, la date de mise en service, date de dernière mise à jour et le fournisseur (interne, prestataire, éditeur)

Plus en détail

The Promotion of Employee Ownership and Participation

The Promotion of Employee Ownership and Participation The Promotion of Employee Ownership and Participation Study prepared by the Inter-University Centre for European Commission s DG MARKT (Contract MARKT/2013/0191F2/ST/OP) Final report October 2014 French

Plus en détail

M2S. Formation Management. formation. Animer son équipe Le management de proximité. Manager ses équipes à distance Nouveau manager

M2S. Formation Management. formation. Animer son équipe Le management de proximité. Manager ses équipes à distance Nouveau manager Formation Management M2S formation Animer son équipe Le management de proximité Manager ses équipes à distance Nouveau manager Coacher ses équipes pour mieux manager Déléguer et Organiser le temps de travail

Plus en détail

Ministère du travail, de l emploi, de la formation professionnelle et du dialogue social CAHIER DES CHARGES DU CONSULTANT

Ministère du travail, de l emploi, de la formation professionnelle et du dialogue social CAHIER DES CHARGES DU CONSULTANT Ministère du travail, de l emploi, de la formation professionnelle et du dialogue social CAHIER DES CHARGES DU CONSULTANT APPUI CONSEIL «GESTION DES AGES» dans le cadre du Contrat de génération Le présent

Plus en détail

Programme de management et sciences de gestion CPGE Économique et commerciale, option technologique (ECT)

Programme de management et sciences de gestion CPGE Économique et commerciale, option technologique (ECT) Programme de management et sciences de gestion CPGE Économique et commerciale, option technologique (ECT) 1) 0rientations générales L enseignement de «management et sciences de gestion» intègre des approches

Plus en détail

Japanese SOX. Comment répondre de manière pragmatique aux nouvelles obligations en matière de contrôle interne

Japanese SOX. Comment répondre de manière pragmatique aux nouvelles obligations en matière de contrôle interne Japanese SOX Comment répondre de manière pragmatique aux nouvelles obligations en matière de contrôle interne Avant-propos Au cours des dernières années, les législateurs à travers le monde ont émis de

Plus en détail

Cohésion d Equipe - Team Building

Cohésion d Equipe - Team Building Public concerné : Cadres et cadres supérieurs. Cohésion d Equipe - Team Building Objectifs : Comprendre les mécanismes de fonctionnement d une équipe. Comprendre les rôles de chacun et le rôle de l encadreur.

Plus en détail

NOMENCLATURE COMMUNE DE CLASSIFICATION DES EMPLOIS DE L ADMINISTRATION PUBLIQUE

NOMENCLATURE COMMUNE DE CLASSIFICATION DES EMPLOIS DE L ADMINISTRATION PUBLIQUE ROYAUME DU MAROC MINISTERE DE LA MODERNISATION DES SECTEURS PUBLICS NOMENCLATURE COMMUNE DE CLASSIFICATION DES EMPLOIS DE L ADMINISTRATION PUBLIQUE Rapport de la phase 3 Marché N 13/2007/MMSP Nomenclature

Plus en détail

Thème 2: Approche globale du client: le partage de l information

Thème 2: Approche globale du client: le partage de l information Association internationale de la sécurité sociale Conférence internationale sur les technologies de l'information et de la communication dans la sécurité sociale Les technologies de l'information et de

Plus en détail

Introduction à la gestion de projets

Introduction à la gestion de projets Introduction à la gestion de projets Jean-Philippe PERNIN Université Stendhal Département Informatique Pédagogique Bureau I 113 Mél. : Jean-Philippe.Pernin@u-grenoble3.fr Jean-Philippe Pernin - DIP - Université

Plus en détail

SERVICES INFORMATIQUES AUX ORGANISATIONS

SERVICES INFORMATIQUES AUX ORGANISATIONS Brevet de Technicien Supérieur SERVICES INFORMATIQUES AUX ORGANISATIONS BREVET DE TECHNICIEN SUPÉRIEUR SERVICES INFORMATIQUES AUX ORGANISATIONS Spécialité «solutions d infrastructure, systèmes et réseaux»

Plus en détail

PLATEFORME INTERACTIVE MOBILE

PLATEFORME INTERACTIVE MOBILE PLATEFORME INTERACTIVE MOBILE PLATEFORME INTERACTIVE MOBILE Ecosystème de Développement Economique et Social www.jaida.ma Platforme Interactive Mobile SOMMAIRE OPPORTUNITE DU PROJET CADRE GÉNÉRAL ET OBJECTIFS

Plus en détail

Contrôle de gestion. Section 1 : Positionnement du contrôle de gestion et identification du métier

Contrôle de gestion. Section 1 : Positionnement du contrôle de gestion et identification du métier Section 1 : Positionnement du contrôle de gestion et identification du métier 1. Rôle et place du Contrôle de Gestion dans l organisation Au début du XXème siècle, l émergence de la structure divisionnelle

Plus en détail

L objectif de cette intervention est d expliquer la construction intellectuelle ayant mené à l élaboration du nouveau parcours de formation et de

L objectif de cette intervention est d expliquer la construction intellectuelle ayant mené à l élaboration du nouveau parcours de formation et de 1 L objectif de cette intervention est d expliquer la construction intellectuelle ayant mené à l élaboration du nouveau parcours de formation et de décrire les points forts de la réforme. 2 Le référentiel

Plus en détail