Manuel de cours sur le management des projets SI et de la recherche enjeux et pratiques

Télécharger

Manuel de cours sur le management des projets SI et de la recherche enjeux et pratiques

Z La construction de la recherche

Présenter de manière transparente la démarche générale emprun­tée par l’équipe de recherche ainsi que le dispositif méthodologique imaginé pour construire et analyser les données doit permettre au lecteur d’évaluer la cohérence de la démarche empruntée et la vali­dité des résultats avancés. Elle s’articule en deux sections. La pre­mière section explicite la posture épistémologique qui a conduit à recourir à la méthode des cas comme stratégie d’accès au réel. La seconde section décrit la conduite de l’étude, et la méthode utilisée pour analyser les données ainsi que pour améliorer la validité des conclusions dégagées.

LA MÉTHODOLOGIE DE RECHERCHE

UNE POSTURE INTERPRÉTATIVE

Notre recherche s’inscrit dans la tradition interprétativiste qui s’appuie sur la conviction que l’on peut accéder à une compré­hension du phénomène étudié en s’appuyant sur la représentation qu’en ont les acteurs. Ceux-ci sont considérés comme des personnes « connaissantes », dotées d’une capacité réflexive sur leurs pra­tiques quotidiennes. Une situation sociale ne peut se comprendre et s’expliquer indépendamment de ceux qui la vivent. La démarche du chercheur est donc de « donner à voir » la réalité des acteurs étudiés et d’en proposer une interprétation vraisemblable et signi­fiante pour eux. Celle-ci est fondée sur l’accès aux significations que les acteurs projettent à un instant donné sur leur réalité sociale, et elle résulte de l’ensemble des présupposés sociaux et théoriques des chercheurs. Cette posture est étroitement liée à la formulation de notre objet de recherche et au choix du recours à la théorie de la structuration comme grille de lecture. Rappelons-le, notre étude porte sur les pratiques de gestion des chefs de projet de la jeune génération, dite « Génération Y ». Il s’agit d’un travail exploratoire fondé sur une hypothèse principale : cette génération, supposée très marquée par la diffusion des outils 2.0 et les modèles d’organisation du travail qui l’accompagnent, a des normes de comportement et des référentiels d’action assez étrangers aux normes et référentiels actuellement en vigueur dans le domaine du management de projet. En nous appuyant sur l’étude in situ du vécu projet de trois jeunes chefs de projet et de leur équipe, nous souhaitons dès lors savoir comment se structurent leurs pratiques concrètement : Comment s’approprient-ils les méthodes et techniques de management de projet prescrits par les référentiels ? Peut-on repérer des pratiques émergentes qui empruntent aux logiques d’action attribuées de l’organisation 2.0 ? Comment s’articulent ces pratiques émergentes avec les normes et méthodes de management de projet prescrites par les référentiels ou l’entreprise ? Entrent-elles en contradiction ? Sont-elles simplement combinées ? Font-elles l’objet d’adaptations, plus ou moins fidèles à leur logique initiale ? Certaines enfin sont-elles remises en cause, abandonnées ?

UNE STRATÉGIE DE RECHERCHE QUALITATIVE FONDÉE SUR LA MÉTHODE DES CAS

Le terme « recherche qualitative » doit s’entendre ici comme une recherche dont les connaissances produites ne sont pas issues de procédures statistiques ou d’un quelconque moyen de quantifi­cation (Strauss et Corbin, 1998). Le choix d’une démarche quali­tative découle directement de notre posture interprétative et de la visée compréhensive de notre questionnement. En effet, parvenir à interpréter les pratiques nécessite :

  • 1) une contextualisation ;
  • 2) une description précise du phénomène ;
  • 3) une structuration dynamique et causale du phénomène étudié ;
  • 4) la prise en compte des visions du monde des personnes impliquées. Nous n’avons cherché ni à mesurer ni à quantifier les pratiques de management de projet, mais bien à les décrire et à les comprendre in situ, à travers les représentations que les acteurs en ont et une analyse fixe du contexte dans lequel elles prennent place.

Dans le cadre de cette étude, nous avons retenu la méthode des cas comme stratégie d’accès au réel, car elle permet :

  • 1) de prendre en compte le rôle du contexte dans la compré hension du phénomène ;
  • 2) de rendre compte de sa dimension temporelle et processuelle ;
  • 3) de saisir la complexité et la récursivité des relations à l’œuvre. Nous avons établi un plan de recherche dans lequel nous avons déterminé :
  • 1) les frontières du cas et l’unité d’analyse ;
  • 2) le nombre de cas étudiés et les critères de sélection.

Les frontières des cas étudiés devaient être celles du système social de référence au sein duquel s’insèrent les pratiques professionnelles étudiées, à savoir les pratiques de management projet. Dès lors, c’est l’équipe projet qui a été retenue comme unité d’analyse. Nous entendons par équipe projet, un « collectif de travail », c’est-à-dire un groupe de personnes ou une équipe travaillant dans une orga­nisation commune, dans le même espace, sur le même outil et/ou dans le même but.

Nous avons opté pour l’étude de trois projets de systèmes d’infor­mation (appelés Dev1, Dev2 et Param). Afin, d’une part, de neutra­liser les variations dans le management de projet dues au type de projet, et d’autre part de « maîtriser » le potentiel structurant du contexte organisationnel (structure, culture, processus, méthodes et outils internes de management de projet), nous avons souhaité que les équipes projets étudiées appartiennent toutes à la même entre­prise et au même programme. C’est ce l’on appelle parfois des « cas enchâssés » (Giordano, 2003). Notre choix s’est arrêté sur une SSII (Société de Services en Ingénierie Informatique, appelée MySSII) et plus précisément sur l’un des projets réalisé pour le compte d’un client, qui avait pour particularité de se décomposer en plusieurs sous-projets, chacun géré par un chef de projet.

La sélection des collectifs de travail a été guidée par un critère de représentativité théorique (Hlady Rispal, 2002) : comme nous voulions étudier les modalités d’évolution, d’adaptation ou de per­sistance des pratiques de management de projet SI liée à l’intégra­tion des collaborateurs dits « de la génération Y » (nés après 1977), nos principaux critères de sélection des projets SI ont été :

  • 1) que le chef de projet appartienne à la génération Y, c’est-à-dire qu’il ait moins de 35 ans ;
  • 2) que l’équipe soit multigénérationnelle ;
  • 3) qu’elle soit suffisamment grande pour nous permettre d’interroger 7 à 10 personnes, le chef de projet compris.

Soumis à de fortes contraintes de production, le chef de projet d’une des trois équipes ne nous a finalement accordé que 4 entre­tiens au lieu des 7 minimums demandés. La répartition des per­sonnes interviewées, selon les générations, est la suivante : Génération Y : 9, dont 3 chefs de projet

Génération X : 6

Boomers : 4.

Le tableau suivant présente de manière synthétique les caractéris­tiques des personnes interrogées.

LE DÉROULEMENT DES ENTRETIENS

La préparation des entretiens a donné lieu à la formalisation de deux guides d’entretien : l’un destiné à l’interview des chefs de pro­jet et l’autre destiné à l’interview des autres membres de l’équipe (cf. Annexe 3).

Les entretiens se sont systématiquement déroulés en quatre phases successives :

  • 1) l’introduction de l’entretien ;
  • 2) l’ouverture de l’entretien ;
  • 3) le centrage de l’entretien sur le thème de la recherche et la phase d’approfondissement des thèmes du guide d’entretien ;
  • 4) la conclusion de l’entretien.

L’introduction de l’entretien

Très souvent négligée, l’introduction est une phase déterminante dans la conduite d’un entretien. D’elle va dépendre la franchise et le degré d’implication de l’informant dans la production des don­nées, et donc potentiellement leur richesse et leur fiabilité. Elle vise notamment l’instauration d’un climat de confiance et de coopéra­tion entre l’interviewé et le chercheur.

Nous présentions de façon transparente notre identité et l’objet de la recherche, à savoir « la façon dont les projets sont gérés en pratique aujourd’hui, l’utilisation des outils et la façon dont les jeunes généra­tions s’intègrent ». Nous expliquions l’objectif, la durée et la façon dont allait se dérouler l’entretien. Nous demandions également l’autorisation d’enregistrer l’entretien en nous engageant à la confidentialité de son contenu. Enfin, nous invitions l’informant à nous exposer ses éventuelles réserves ou interrogations sur le projet de recherche ou les finalités de l’entretien. Les répondants en profitaient parfois pour demander des précisions sur notre statut et la nature de notre relation avec l’entreprise.

L’ouverture de l’entretien

Avant de centrer l’entretien sur les pratiques de management de projet, une compréhension du contexte de l’informant était néces­saire. Il lui était donc demandé des informations :

− sur son identité (âge, formation, expérience, ancienneté, etc.) ;

− sa position au sein du projet (fonction, missions et tâches qui en découlent, son ancienneté au sein du projet, etc.) ;

− les méthodes et outils utilisés pour gérer le projet.

Le centrage de l’entretien et l’approfondissement des thèmes du guide d’entretien

S’ensuivait un centrage de l’entretien et des demandes d’approfon­dissement sur cinq aspects du management de projet détaillés ci-dessous.

Le choix de ces thèmes d’approfondissement résulte principalement de notre état de l’art. Celui-ci nous a en effet permis d’identifier certaines valeurs supposées et attentes au travail des membres de la génération Y pouvant éventuellement induire un questionnement des pratiques de management de projet, telles qu’elles sont institu­tionnalisées par les référentiels. Les fondements théoriques restent néanmoins limités compte tenu du peu de recherches empiriques et théoriques publiées aujourd’hui sur ce sujet.

La conclusion de l’entretien

La phase de conclusion invitait le répondant à formuler :

  • 1) une appréciation globale de la vie du projet ;
  • 2) une appréciation sur le fonctionnement de l’équipe projet.

Ces points ayant été généralement évoqués tout au long de l’entre­tien, il s’agit davantage d’en faire la synthèse. La clôture de l’entre­tien se faisait généralement en remerciant le répondant.

Concernant les risques de biais pouvant nuire à la validité de nos résultats, deux précautions ont été prises durant la phase de réali­sation des entretiens.

Pour contrôler la subjectivité des propos, nous avons pris le parti de ne pas poser de questions explicites sur « les jeunes » ou « la génération Y », considérant que les spécificités générationnelles émergeraient en phase d’analyse de la comparaison des discours par tranche d’âge. Par ailleurs, des moyens « d’objectivation » du propos des acteurs ont dû être imaginés pour dépasser leur juge­ment sur les faits et accéder à la réalité de leur vécu. Ainsi, lorsque l’interviewé parlait de la génération Y d’une manière générique (par exemple : « aujourd’hui les jeunes, ils ne communiquent pas, ils bossent avec un casque sur les oreilles toute la journée »), il était alors demandé d’illustrer le propos par des anecdotes et des exemples vécus. En outre, lorsque les conditions dans lesquelles était conduit l’entretien le permettaient, il était proposé à l’inter­viewé de montrer des documents permettant d’illustrer ses décla­rations (par exemple, l’outil de planification utilisé au sein de l’équipe). Une telle technique répond au principe de triangulation des données.

Cinq chercheurs ont été impliqués dans la phase de réalisation des entretiens. Afin de garantir une certaine homogénéité des données recueillies, un guide de l’interviewer a également été rédigé. Outre deux annexes qui rappelaient les objectifs et les grands principes de la technique de conduite d’un entretien de recherche, celui-ci détaillait pour chaque question du guide d’entretien, le type de données recherchées et les sous-thèmes sur lesquels il fallait relan­cer et approfondir (cf. Annexe 3).

MÉTHODE ET OUTIL DE L’ANALYSE QUALITATIVE DES DONNÉES

L’intégralité des entretiens réalisés a été enregistrée et retrans­crite (par un sous-traitant). Tous les entretiens réalisés ont fait l’objet d’une analyse de contenu en trois temps.

D’abord, a été effectuée une lecture flottante crayon en main des retranscriptions d’entretiens ou de documents de manière à avoir une vue globale du corpus et éventuellement des points récurrents.

Ensuite, nous avons choisi d’effectuer le codage en nous appuyant sur le logiciel NVivo de manière à réduire, structurer, classer et extraire aisément nos données. Un dictionnaire des thèmes, calqué sur la structure du guide de l’interviewer a été élaboré. L’arbores­cence du dictionnaire des thèmes est présentée en Annexe 4. L’unité de codage retenue est le groupe de phrases. Le codage a été réparti entre les cinq membres de l’équipe. Des fiches de synthèse ont été rédigées par chaque codeur de manière à identifier les points saillants et remarquables. Notons qu’afin d’éviter les biais interco­deurs, un soin particulier a été apporté à la définition de chacune des catégories dans le logiciel. Par ailleurs, un entretien a été codé collectivement pour caler les options de codage et s’assurer d’une compréhension homogène de tous les codes.

Enfin, des extractions par cas et par thème ont été effectuées, à par­tir desquelles des « micro-analyses » ont été effectuées. Il s’agissait d’une analyse « linéaire », presque mot à mot, du corpus au cours de laquelle l’objectif était de faire un premier travail d’abstrac­tion du propos des acteurs. Les extractions se sont faites en deux temps, d’abord une répartition des extractions par thèmes entre les membres de l’équipe, puis une répartition des extractions par cas, ponctuées de réunions d’équipe pour échanger et confronter nos idées. Au cours de ces réunions de travail, un consensus s’est formé autour de l’idée que trois figures de management de projet, incar­nées chacune par un chef de projet, émergeaient de nos données : la figure de la mise en réseau, la figure de l’immédiateté et la figure de la professionnalisation. Un deuxième codage, manuel cette fois, a alors été réalisé pour corroborer cette hypothèse et sélectionner les verbatim en vue de la rédaction des cas.

3 Les résultats de la recherche

ANALYSE DES ENTRETIENS : TROIS FIGURES DU MANAGEMENT DE PROJET PAR LA GÉNÉRATION Y

LE CONTEXTE DES CAS

Dans le cadre de l’étude terrain, nous avons analysé les pratiques de management de trois chefs de projet appartenant à la géné­ration Y (– de 35 ans). Leurs projets s’intègrent dans un seul et même programme, réalisé par une SSII pour le compte d’une mutuelle. Son objectif est l’adaptation et l’intégration d’une solu­tion assurance santé dont le périmètre fonctionnel couvre la gestion des cotisations, la gestion des prestations et le pilotage des activités. Ce programme s’étale sur quatre ans et mobilisait au moment du recueil (automne 2010) une centaine de personnes. Les trois projets retenus ont été contractualisés sur le mode du forfait.

L’équipe Dev1 et l’équipe Dev2 sont deux équipes « jumelles » chargées du développement. Elles sont situées sur des plateaux open space de la SSII, dans deux régions différentes. L’équipe Param est l’équipe de paramétrage, localisée chez le client.

LE CAS DU SITE DEV1 : LA FIGURE DE LA MISE EN RÉSEAU

Les caractéristiques du management de cette équipe sont les suivantes : la collaboration à l’intérieur de l’équipe est importante, souvent en face à face. Mais elle a été organisée par la mise en place d’un réseau dynamique de rôles, qui permet de faire circuler la connaissance. Le chef de projet anime ce réseau comme un entraîneur ou un capitaine d’équipe qui répartit les rôles avec le souci de faire progresser chacun, mais aussi de développer un jeu collectif. Les collaborateurs peuvent être critiques sur certains points, mais ils adhèrent au dispositif mis en place par le chef de projet.

Un fonctionnement collaboratif à l’intérieur de l’équipe

Le fonctionnement dans l’équipe fait une large part à la collabo­ration. « Lorsque nous avons des soucis, nous allons voir qui nous voulons. À la limite, notre chef de projet, c’est toujours nous qui allons le voir, il est rare que ce soit lui qui dise : “Où en es-tu ? Que fais-tu ?” Nous nous organisons vraiment. » (Dev1Col55). La per­ception d’une interdépendance est exprimée : « Plus que le ressenti, c’est sur le plan pratique. Je dirais qu’il y a presque une dépendance entre nous. (...) Nous pouvons intervenir sur d’autres domaines que nous ne connaissons pas trop, cela nous contraint ou cela oblige d’avoir une relation avec les autres collaborateurs, chacun travaille sur des domaines différents. » (Dev1Col54). Les échanges sont perçus comme une nécessité : « Il ne faut pas rester dans son coin (...) si on travaillait comme ça, on irait droit dans le mur. » (Dev1Col40). C’est reconnu par tous : « C’est plutôt un travail collaboratif. Dans le projet, pas une personne ne travaille toute seule. » (Dev1Col32). Les échanges sont nombreux, que ce soit pour le projet – « C’est un projet dynamique où les gens ne râlent pas si nous venons leur poser des questions, ils essaient de répondre » (Dev1Col35) – ou plus largement – « on parle beaucoup (...) et pas forcément du projet » (Dev1Col55). La messagerie instantanée peut entretenir une communication de convivialité : « Same Time, c’est du chat, si on a un truc à dire... (rire) c’est la génération Y qui veut cela. » ( Dev1Col34). Les échanges directs sont très appréciés : « J’aime moins cette configuration-là. En fait, dans l’autre, nous étions quatre les uns à côté des autres, plus les bureaux à côté. Nous pouvions communiquer rapidement avec tout le monde. Là, nous sommes tous en ligne, c’est moins facile, les chefs sont plus loin, mais nous nous adaptons. » (Dev1Col35).

Les échanges ne s’arrêtent pas aux frontières des générations : « De l’image du plus ancien que nous avons, nous avons normalement plus de connaissances. Nous avons un schéma traditionnel, clas­sique de dire : “Je devrais lui montrer cela, lui expliquer.” Et des fois, c’est lui qui me dit : “On fait comme ça, mais on pourrait faire autrement.” J’ai une connaissance du projet parce que j’étais là avant, parce qu’il existait l’autre projet qui était similaire côté métier. C’était l’aspect capitalisation personnelle. Il y a aussi bien sûr toute l’expérience professionnelle d’avant que j’ai. Des fois, ils vont être plus pertinents et plus performants sur certaines solu­tions. Ils ont un regard qui est différent aussi. » (Dev1Col54). « Je dirais que cela marche dans les deux sens. Je ne fais pas de dif­férence. » (Dev1Col40). Sous l’influence de la génération Y, mais aussi à cause de la nouvelle disposition de l’espace de travail, l’uti­lisation de la messagerie instantanée s’est développée : « Je pense que les jeunes s’habituent plus à Same Time, à la communication rapide. Je m’y suis mis, mais c’est vrai que j’ai eu plus de mal. » ( Dev1Col35). Elle permet des réponses immédiates, mais aussi d’effec tuer une autre tâche en parallèle : « Elle sert pour des ques­tions rapides où nous n’avons pas besoin d’avoir un suivi par mail. Cela évite de se lever. Au moins, la personne peut répondre, même si elle est au téléphone, lorsqu’elle veut. » (Dev1Col35). On observe des ajustements dans la communication entre générations. Si le chef de projet adjoint observe un style propre aux jeunes – « les plus jeunes vont faire du SMS sur de la messagerie instantanée, en terme d’écriture, ils vont raccourcir les mots (...) ça ne me gêne pas » (Dev1CPA40), d’autres obtiennent de leur part une forme plus classique : « les mails sont pas en SMS. Je leur dis : tu m’en­voies un mail où tu me parles normalement. Entre nous, ici, nous nous parlons normalement. Nous nous écrivons même à peu près normalement. » (Dev1Col40).

Le fonctionnement de ce projet est parfois opposé à un projet précédent, où « il existait plus de cloisonnements » (Dev1Col54), et « chacun faisait ses trucs dans son coin et, au final, cela ne marche pas » (Dev1Col55). « Les collaborateurs étaient autonomes. Ils devaient rédiger les spécifications et ils développaient celles qu’ils avaient rédigées, (...) ils avaient un fonctionnement à rester vraiment sur leur projet et ne pas trop communiquer parce qu’ils n’avaient pas besoin. » (Dev1CPA40).

Ce mode de fonctionnement nécessite un accord des parties pre­nantes : au début, certains collaborateurs qui avaient connu un fonctionnement différent n’ont pas accepté, et ils ont été affec­tés à un autre projet : « Il y avait aussi des caractères forts dans l’équipe qui ont généré des soucis. C’était plus dans leur démarche de fonctionnement qu’ils avaient avant. De leur imposer quelque chose de nouveau, une autre démarche, c’est ce qui a le plus posé problème. » (Dev1CPA40).

Le mode de fonctionnement est perçu comme spécifique au site et il est mis en regard avec le site de Dev2. L’atmosphère est revendi­quée comme différente : « Il paraît qu’il y a une grosse différence entre Dev2 et Dev1, les chefs nous l’ont dit. Ils sont toujours hal­lucinés de voir le bruit qu’il y a dans notre équipe en rapport avec notre communication, entre nous, et le silence assourdissant qu’il y a sur le plateau de Dev2. » (Dev1Col40). En effet, dit CPA40 : « Nous échangeons pas mal, par rapport à Dev2 où il n’y a aucun bruit. Là, il y a de la communication entre les gens, alors que sur Dev2, non. » À Dev1, le groupe peut être sollicité pour résoudre une difficulté rencontrée par un collaborateur : « Ici, nous nous aidons effectivement beaucoup. C’est important. (...) Lorsque nous tombons sur un problème plus complexe, il faut que nous en par­lions (...) Nous allons finir par y arriver, mais nous allons nous mobiliser à plusieurs. » (Dev1Col55). À Dev2, la logique de partage n’est pas aussi prégnante : « Je pense que c’est différent. Ici, c’est plutôt familial au niveau entreprise. À Dev2, c’est beaucoup plus industriel. Il y a les deux notions tout de même. » (Dev1Col32). « La différence vient de l’approche des personnes. (...) Ils sont peut-être un peu plus individualistes. Tandis qu’à Dev1, nous sommes tout de même un peu plus collectifs. » (Dev1Col40). L’entraide est davantage valorisée à Dev1 qu’à Dev2 : « Je pense que nous tra­vaillons plus ensemble, nous prenons plus nos responsabilités les uns et les autres, nous sommes plus solidaires. » (Dev1Col40). Du coup les nouveaux arrivants s’intègrent peut-être plus facilement : « Il y a cinq mois, nous avons intégré cinq ou six petits nouveaux, qui ont été recrutés (...) Cela s’est super bien passé parce qu’à la moindre difficulté, nous allions les voir, nous les aidions », alors que « côté Dev2, (...) cela a été une catastrophe, (...) là-bas, cela communiquait beaucoup moins et ils étaient un petit peu livrés à eux-mêmes. » (Dev1Col34). En effet, « j’ai l’impression qu’ils aiment moins être dérangés (...), la communication n’est pas la même là-bas. » (Dev1Col34). Mais le comportement est attribué à un climat général : « Ce n’est pas dû à la volonté des personnes ; c’est lié à l’ambiance du plateau, du lieu. Ce n’est pas du tout la même ambiance, c’est flagrant. » (Dev1Col40). Alors qu’à Dev1, on n’hésite pas à solliciter les autres : « Nous demandons sur le plateau : “Tu as travaillé sur cela, tu as travaillé sur cela, as-tu tra­vaillé là-dessus ? Tu peux peut-être m’aider.” » (Dev1Col40). Et les nouveaux sont bien encadrés : « Là-bas, j’ai l’impression qu’ils sont dans leur coin. » (Dev1Col35)

Un fonctionnement mis en place par le chef de projet

Le chef de projet n’est pas dans l’entreprise depuis longtemps. En l’absence de cadre normalisé, il a eu la liberté d’organiser le fonctionnement à sa façon. « J’ai mon système de management à moi. (...) Je ne réponds pas au dogme de MySSII, au dogme de management. Je n’ai rien, j’arrive ainsi avec mon expérience et je travaille. » (Dev1CP34)

Par exemple, l’utilisation des différents outils de communication a été définie : « Cela a été clairement dit sur ce projet. On nous a bien briefés sur les mails, nous les envoyons pour des demandes d’infos et nous ne mettons pas les gens en copie aussi. (...) Nous utilisons les mails pour les choses qui vont demander un peu d’étude. Ce sont des réponses qui ne peuvent pas être immédiates. Ce sont plus des informations à traiter. Par contre, lorsque nous avons besoin d’un renseignement tout de suite, nous utilisons le téléphone ou la messagerie instantanée. » (Dev1Col55). Les réunions et le face-à-face occupent une place importante : « Je vais envoyer un mail s’il y a vraiment une directive, un besoin de traçabilité. Après, pour les tâches de tous les jours, les actions que nous menons, en ayant fait une réunion au préalable avec les personnes, nous communiquons plus facilement. » (Dev1CPA40). Il s’agit d’une « culture » spéci­fique au projet : « Nous échangeons de façon verbale. Si je prends par exemple des demandes d’évolution de bases de données ou d’IHM, il y a des documents, mais je ne sais pas si tout le monde ne fait pas d’abord une première version histoire de dire, et après, en finalisant à l’oral. J’avais l’habitude de faire des échanges par mail en gardant tous les mails de côté et, ici, ce n’est pas trop la culture. » (Dev1Col32). Il y a également un souci partagé d’inté­grer les nouveaux arrivants : « Il y a ce que nous appelons le livret d’accueil, c’est l’accueil. Avec l’expérience, ce n’est pas vraiment l’autonomie du collaborateur, mais c’est aussi le souci d’intégrer les autres. Les autres, ce sont les nouveaux arrivants. » (Dev1Col54).

Par rapport au projet précédent, le rôle du chef de projet dans l’évolution des relations dans l’équipe est souligné : « Je pense que c’est lié au management. Nous avons vraiment eu des directives très précises. (...) Nous avons beaucoup plus de directives (Same Time, les échanges, la façon de travailler, les comptes rendus d’activité), et cela a forcément changé l’ambiance. » (Dev1Col55). Cette nouvelle façon de travailler a transformé les relations dans l’équipe : « L’am­biance a changé, mais ce ne sont pas les gens. » ( Dev1Col55). « Une réorganisation a eu lieu dans la direction du projet, une améliora­tion des communications entre les différentes équipes internes, des communications entre les chefs et les développeurs. » (Dev1Col32). La gestion de l’interdépendance par la collaboration a été voulue : « Je pense aussi qu’il y a un esprit qui a été mis en place pour favoriser ce lien entre les collaborateurs, faire passer un message en disant que nous sommes tous concernés par le même objectif. » (Dev1Col54)

La construction d’un réseau de connaissance

Chaque nouvel arrivant reçoit une connaissance de base : « Nous utilisons un terme ici, qui est le socle. Nous avons un socle com­mun. Cela fait que chaque arrivant va avoir une présentation des métiers de la santé (médecin, pharmacien, etc.), et par rapport au projet, il sait qu’il y a un socle. Tout le monde intervient et travaille sur le socle. Après, nous travaillons plus ou moins en profondeur, dans le détail. Je pense que cela aide à l’intégration. » (Dev1Col54). Mais ensuite, les nouveaux sont placés de façon à pouvoir s’appuyer sur d’autres : « Nous avons été dispersés dans l’équipe pour être mis avec des sachants pour pouvoir poser les questions directement. » (Dev1Col35). Ensuite, la connaissance construite par l’expérience circule : « On va s’adresser à la personne qui, normalement, devrait pouvoir répondre. Si la personne ne sait pas répondre, elle doit connaître quelqu’un qui pourrait répondre. » (Dev1CPA40).

Mais, il n’y a pas uniquement un partage d’expérience, assez classique. Le chef de projet construit un réseau de connaissance distribuée, car, dit-il, « c’est une façon de me dégager, plus ils apprennent, plus je me dégage de cette partie-là et moins je suis, entre guillemets, essentiel pour eux à ce niveau-là, et je pense que c’est ce qu’ils attendent en partie » (Dev1CP34).

Pour construire ce réseau, des rôles en lien avec la connaissance sont identifiés : les « sachants » et les « référents ». Le chef de projet (qui possède une grande connaissance fonctionnelle) et son adjoint (doté d’une expertise technique sont perçus par rap­port à leurs connaissances : « Nous venons voir les sachants (...) les sachants, ce sont des gens qui ont un peu plus d’expérience. ») (Dev1Col35).

Quand une spécification un peu complexe est à traiter, il décide de la répartir entre plusieurs collaborateurs. Il travaille plus parti­culièrement avec l’un d’eux pour qu’il ait une bonne connaissance de la question, et il le nomme « référent » : « J’ai privilégié cer­taines personnes comme étant mes référents pour faire les spéci­fications techniques parce que ce sont des personnes en qui j’ai confiance. » (Dev1CP34). La désignation d’un référent ne corres­pond pas à la position hiérarchique : « Moi qui suis non-cadre tout en bas de l’échelle, cela ne me gêne pas de me mettre en référent. » ( Dev1Col55). La définition d’un référent permet d’augmenter le réseau de connaissances : « Par exemple, je suis référent IHM, nous avons aussi des référents sur les cotisations : lorsque nous avons des questions, nous appelons ces personnes. » (Dev1Col32).

Les référents permettent une diffusion du savoir : « Nous ne leur donnons pas le travail tout fait, nous les investissons dans la relec­ture de la spécification, dans le devis chiffré avec le temps nécessaire. Généralement, celui que nous aurons mis en avant sur cette spécifi­cation va devenir le référent de la spécification. » (Dev1CPA40). Le référent coordonne alors le petit groupe affecté à la spécification : « Cela veut dire que je vérifiais où ils en étaient, s’ils avaient des problèmes et je les aidais à régler leurs problèmes. J’étais un peu le référent puisque c’était moi qui avais fait un peu les spécifications techniques sur cette question-là. » (Dev1Col35). Ce rôle de réfé­rent est ponctuel : « J’ai mes propres petits tableaux Excel pour les suivre, si j’encadre trois-quatre personnes, si je les suis sur une petite évolution, je sais ce que j’ai donné à chacune d’elles. C’est surtout pour le fonctionnement, pour savoir ce que je leur donne à faire, si cela a été fait ou pas. » (Dev1Col40). Le chef de projet informe sur la répartition des connaissances : « Je pense que Dev1CP34 joue bien son rôle, il oriente tout de même bien les tâches. Lorsqu’il met une personne, qui ne le maîtrise pas bien, sur un sujet, il lui dit : “Nous te mettons sur cette tâche, mais tu peux aller demander à untel, untel pour t’aider et te montrer les choses spécifiques pour ta tâche.” » (Dev1Col32). Malgré le découpage, il reste une certaine souplesse qui est bien perçue : « Les tâches sont spécifiques, mais ne sont pas trop détaillées : il y a une certaine souplesse au niveau développement, réalisation des tâches. » ( Dev1Col32). L’autonomie laissée à chacun est compensée par le recours au réseau de rela­tions : « Nous avons pas mal d’autonomie, des fois, cela manque un petit peu de cadrage, mais cela se passe plutôt pas trop mal. » (Dev1Col34)

Les collaborateurs s’organisent alors en « ateliers » : « Nous dis­cutons à plusieurs, sur un même thème, sur une même spécifi­cation, dans des ateliers de travail. (...) Ils sont créés au fur et à mesure ; sur certaines spécifications, plusieurs personnes vont tra­vailler dessus, en principe, deux, trois personnes, voire beaucoup plus, travaillent sur une spécification. Du coup, nous faisons des fiches de relecture puis nous nous réunissons pour voir les ques­tions de chacun, pour éclaircir les choses, pour donner les tâches. » (Dev1Col32).

La constitution d’un réseau de connaissance permet la résolution des problèmes sans passer par le chef de projet : « Je ne sais pas s’ils font de la messagerie instantanée. Cela ne me dérange pas. L’essen­tiel est qu’ils ne restent pas bloqués. Je m’en fous de la façon dont ils se débloquent. Je peux les aider aussi. Après, qu’ils se lèvent, ne se lèvent pas, qu’ils font de la messagerie instantanée, tant qu’ils ont la solution, qu’ils appellent un mec d’une autre équipe qui va leur donner la réponse, cela me va très bien. » (Dev1CP34).

Dans la mesure du possible, l’affectation permet de diffuser les connaissances. « En effet, dit l’adjoint du chef de projet, si la réso­lution du problème doit être rapide, nous favoriserons les gens qui sont plus amenés à répondre rapidement. Par exemple, nous favori­serons une personne qui aura développé, qui aura produit le travail pour corriger une QC8 relative à ce travail. Par contre, si la réponse est moins rapide, nous essayons de capitaliser en donnant la tâche à quelqu’un qui ne l’a jamais fait pour qu’il se rapproche de la personne qui maîtrise, afin d’élargir leur domaine de compétence. D’ailleurs, c’est tout notre intérêt parce que nous ne pouvons pas gérer les absences. » (Dev1CPA40). Cela a un coût et oblige par­fois à prévoir des délais plus longs : « Nous faisons des choix où nous savons pertinemment que cela ne va pas tout à fait le faire, mais nous le faisons tout de même parce que nous souhaiterions les faire monter en compétence. Dans notre planification, lorsque nous faisons ces choix-là, nous prenons un peu plus de marge. » (Dev1CPA40). Certains collaborateurs peuvent aussi conseiller le chef de projet sur l’affectation : « Dès qu’il réalise un devis, je lui dis : « Sur cette partie-là, lui pourrait faire cela, lui faire cela. » et ils peuvent affecter les tâches à l’intérieur de leur périmètre : « En fonction de mon tableau, je me dis : ce serait bien que tu donnes cette tâche-là à telle personne. » (Dev1Col40).

Le chef de projet anime dynamiquement le réseau

Le chef de projet ne perçoit pas son équipe comme des colla­borateurs interchangeables : « À un moment, c’est de l’industrie, une ressource est une ressource. Pour moi, une ressource n’est pas une ressource. » Pour lui, c’est un peu un réseau d’amis : « Je tourne tout de même pas mal à l’affectif et j’aime bien les gens avec qui je travaille. L’ambiance est bonne. » (Dev1CP34). Dans l’affectation des tâches, les souhaits sont pris en compte : « Nous nous arrangeons pour que cela corresponde à leur attente ; pour l’instant, nous ne nous sommes pas trop trompés. » (Dev1CPA40). La réunion hebdo madaire permet au chef de projet d’ajuster l’orga­nisation : « Elle a vraiment vocation à ce que je communique les informations générales qui viennent de la direction de projet et que je discute de l’organisation, de mon  ressenti. » (Dev1CP34). Il a le souci de manifester une reconnaissance qui revient au groupe : « Lorsqu’ils ont bien développé rapidement, je leur dis pour qu’ils sachent tout de même que nous avons bien travaillé. » (Dev1CP34). Mais aussi par l’affectation des tâches : « C’est vrai que je suis assez sensible à cela. Dans cette notion de reconnaissance, il n’y a pas besoin de faire un grand discours. Des fois, les gens qui recon­naissent, avec un signe, nous savons très bien que cela va. Cela peut même être indirectement, on va te dire : “Tiens, tu vas faire cela, cela veut dire qu’on vous reconnaît.” » (Dev1Col54).

Les gens doivent se sentir bien : « L’idée est qu’ils soient bien dans le projet pour se sentir à l’aise, qu’ils n’aient pas trop la pression. » (Dev1CPA40), donc on n’impose pas d’outils annexes, on suggère : « Tous les outils annexes, chacun va les prendre en main comme il le veut. En fait, plein d’outils sont disponibles en gratuit, et peuvent faire gagner du temps, mais encore faut-il vouloir les utiliser. » (Dev1CPA40).

Par ailleurs, le projet n’est pas un projet « industriel et rôdé », ce qui explique que certaines personnes ne se soient pas senties « à l’aise ». Les collaborateurs doivent pouvoir s’adapter à ce fonction­nement d’équipe.

Le chef de projet valorise son équipe : « Il y a globalement une différence de niveau entre Dev1 et Dev2. L’équipe de Dev1 est plus expérimentée que l’équipe de Dev2. » Mais il les stimule : « Je les challenge tout de même assez régulièrement », il favorise leur pro­gression : « J’essaie vraiment de les former, de toujours vulgariser au maximum ce que nous faisons pour que les gens comprennent au moins ce qu’il y a derrière. » Et il sait reconnaître leurs résul­tats : « Ils travaillent bien, je suis très content d’eux, je le leur dis assez régulièrement. » (Dev1CP34). Cette progression est ressentie par l’équipe : « C’est une équipe qui progresse. Il y a de l’acquisi­tion de compétences. » (Dev1Col40).

En retour, le chef de projet attend une reconnaissance de sa légi­timité : « Je les respecte, ils me respectent, je suis transparent. Je pense qu’ils me respectent aussi parce que je connais la technique et le produit. Personne ne discute cela. » (Dev1CP34).

Mais surtout, les collaborateurs doivent jouer le jeu, et répondre de façon réactive à son animation dynamique. Ils participent à l’esti­mation des charges : « Lorsque nous discutons, au niveau analyse, nous sommes ensemble devant la spécification, devant les écrans et là, c’est du dialogue face à face. » (Dev1Col32). Et ils informent de l’avancement : « Souvent, comme nous ne pouvons pas savoir jusqu’à quel point il faut creuser, nous nous trouvons dans le cas où nous devons faire un macro-chiffrage. C’est alors moi qui réalise le chiffrage, au fur et à mesure, et qui les tiens au courant : “J’ai trouvé que cela n’allait pas, nous devons prévoir un peu plus de temps.” Ou, à l’inverse, nous finissons plus rapidement et la tâche est terminée. Il y a un dialogue entre eux et moi. » (Dev1Col32). Les jeunes réagissent bien : « Ils ne vont pas rester inactifs, ils ne vont pas rester à attendre la tâche, ou qu’on leur fournisse une tâche. » (Dev1Col54). De même, en cas de blocage, la réaction est immédiate : « Si j’ai un problème, je ne vais pas attendre 17 h pour lui dire que je suis bloqué, que je ne peux rien faire et que j’ai besoin d’être débloqué ou que j’ai besoin de telle ou telle infor­mation. » (Dev1Col40). En cas de surconsommation prévisible, les collaborateurs informent tout de suite le chef de projet : « Si nous voyons que nous n’avons pas assez de charges ou assez de délais, nous venons lui en parler en lui disant que cela ne va pas. C’est toujours en dynamique. » (Dev1Col35). Les collaborateurs ne sont pas tenus pour seuls responsables des dépassements : « Si un dépassement a lieu, cela peut être justifié. Tout est une question de justification. Ils sont prêts à écouter. » (Dev1Col40). En effet, le chiffrage est parfois hasardeux, et le chef de projet cherche des moyens d’améliorer la justesse des estimations, notamment celles qui touchent aux anomalies qu’il faut traiter : « Cela peut être des anomalies du produit qu’ils ont acheté à l’origine ; c’est-à-dire que cela ne vient pas de notre développement. Nous avons une bonne activité là-dessus et celle-ci est très dure à quantifier. Nous en pre­nons constamment. Nous avons un temps moyen en termes de pilotage. Nous nous disons qu’une QC prend une journée et demie et c’est tout. Nous avons une QC qui peut prendre cinq jours, une QC qui peut prendre 0,125 jour. Nous ne le savons pas tout de suite et, quelque part, nous pouvons planifier l’activité et nous retrouver dans le rouge par rapport à cette QC. Nous progressons, nous avons des outils de reporting sur QC qui nous permettent de voir comment nous maintenons notre stock et d’affiner un peu ce chiffrage moyen. » (Dev1CP34).

Le chef de projet et son adjoint sont eux aussi très réactifs lorsqu’ils sont alertés : « Si une tâche prend trop de temps par rapport à ce qui était prévu, avec Dev1CP34, nous allons tout de suite les accompagner pour voir si nous pouvons les débloquer et s’ils prennent le bon chemin dans la résolution. Nous sommes très sou­vent amenés à aller nous installer à côté d’eux. Il y a une chaise par plot. Nous prenons la chaise et nous nous installons à côté d’eux. » (Dev1 CPA40).

De façon générale, l’équipe a intégré l’objectif de respect des temps impartis : « Les gens sont tout de même sensibilisés à cela, entre guillemets, à la performance. J’ai estimé tant, j’ai fait un devis de tant, et personne ne dépasse systématiquement. Les gens sont tout de même sensibles. » (Dev1CP34). De même, pour prendre des congés, l’intérêt collectif est pris en compte : « Globalement, je n’ai pas trop à changer les congés. Je ne les change pas trop parce que les gens n’abusent pas non plus. J’ai une personne qui est partie un mois en Indonésie, elle a raison. C’est le plus jeune d’ailleurs. C’était au mois d’octobre, il ne l’a pas fait en août. Il m’a dit : “Je ne le fais pas au mois d’août, tout le monde est en congés, je ne veux pas non plus perturber le truc.” Les gens sont tout de même responsables. » (Dev1CP34)

Cependant, si un collaborateur omet de signaler une sous-consom­mation pour se livrer à des activités personnelles, il est rappelé à l’ordre au nom de l’intérêt collectif : « Sur les glissements, sur l’activité globale du lot, ce n’est pas individualisé. Je travaille prin­cipalement là-dessus. Par exemple, pour une personne, je regarde dans son CRA, elle est toujours pile. Je chiffre 2,125, il fait 2,125. Il se moque de moi. Cela veut dire qu’il met moins de temps. Il me l’a fait deux, trois, quatre semaines et, après, je l’ai eu. Je l’ai pris à part et je lui ai dit. » (Dev1CP34).

C’est le chef de projet qui affecte les priorités : « C’est à moi de lui dire que j’ai terminé et il va me dire : “j’ai d’autres priorités, j’aimerais bien que tu passes là-dessus parce que c’est urgent”. » (Dev1Col40). Mais, il préserve une certaine stabilité dans le tra­vail des collaborateurs. Si lui-même ajuste le macro-planning en cours de semaine, ce n’est qu’en fin de semaine qu’il établit le planning détaillé pour la semaine à venir : « Je le bouge tout de même assez régulièrement parce que cela bouge tout le temps. C’est classique. Tous les deux, trois jours, je bouge le planning. (...)Toutes les semaines, j’intègre ces tâches dans l’outil de CRA avec les charges initiales prévues. » (Dev1CPA34). En effet, il y a des impondérables liés à des retours après livraison au client : « Nous avons beaucoup de retours de clients. Nous avons tout de même une grosse activité en termes de fiches retours, fiches de renseignements pour découverte du produit. » (Dev1CP34). Cependant, on observe que, contrairement à ce qui se passe sur un autre site (Param), le chef de projet préserve l’équipe d’un stress lié à l’arrivée aléatoire de des perturbations. En effet, il n’interrompt pas les tâches en cours pour une réaffectation ou un changement de priorité à prendre en compte immédiatement : « Nous sommes prévenus à l’avance, à la limite, il nous dit : “j’ai tant d’anomalies, il faudrait les résoudre pour telle date.” Nous savons que nous sommes mis un peu sous pression. Cela peut être cyclique : attention, les spécifications arrivent, ils sont en retard sur les spécifications. Cela veut dire qu’il va falloir, pour respecter les délais, que nous travaillions fort. » (Dev1Col40). Le traitement des anomalies se fait entre deux activités planifiées : « Dès que nous avons fini une activité ou dès que nous avons un temps mort parce que nous sommes en attente de quelque chose, il y a ce que nous appelons les QC (c’est-à-dire des anomalies détectées par rapport aux livraisons que nous avons faites précédemment) qu’il faut corriger. » (Dev1Col35).

De plus, le chef de projet protège l’équipe de perturbations exté­rieures : « S’il y a des tensions, s’il y a des trucs qui reviennent de Dev1, ils ne le savent pas, en fait, je fais couvercle, ils ne voient pas, j’évite de faire redescendre. » (Dev1CP34).

Il inscrit le projet dans une dynamique de progrès, à laquelle les collaborateurs adhèrent : « Par exemple, l’estimation a fait l’objet d’une amélioration : « De plus en plus, comme on connaît mieux le produit, on sait à peu près où on va mettre les pieds, on est capables de mieux analyser, on est

40