Par Nicolas Humeau

En tant que choix d'organisation, le mode projet est parvenu à maturité. Non seulement le management par projet ne suscite plus débat, mais encore il s'érige en bonne pratique. En tant que voie d'action, le mode projet est encore plus banalisé. Le management de projet constitue le pilier de tout portefeuille de compétences. Pour autant, face aux difficultés pratiques qui font du métier de chef de projet - et notamment de chef de projet S.I. - un sacerdoce, ne devrait-on pas réinterroger quelques fondamentaux du mode projet ? D'où vient cet écart entre une vision idéalisée et une réalité moins que rose ?

C'est aux interfaces entre le projet S.I. et son environnement que se trouvent une partie des réponses. Là prend naissance un système fondé sur trois pivots : des individus (appartenant à plusieurs groupes), des groupes (régis par une sociologie) et des systèmes technologiques support (dont il faut comprendre les logiques d'usage).

Pivot n°1 : l'individu et son appartenance à plusieurs groupes

Lorsqu'un projet prend forme, on le découpe en autant de dimensions pertinentes que nécessaire. Par exemple, les dimensions pertinentes de cet article sont l'individu, le groupe et le système technologique support. Dans cette phase de structuration, on s'en tient généralement au registre de l'opportunité pour doter en ressources humaines un projet. Le bon choix semble être la première personne qui vienne à l'esprit à l'évocation de chacune des dimensions.

Or, si l'on excepte les profils à compétence informatique pointue, constituer un groupe projet S.I. selon cette logique de top of mind est contestable. Il faut au contraire contextualiser le choix en étudiant la disponibilité effective de la personne, sa logique d'action (quel est son but dans l'organisation ? Quelles sont ses ressources pour y parvenir ?) ainsi que ses autres contraintes, le projet auquel on envisage de l'associer en étant une de plus. En pratique, ces critères de faisabilité - déterminants au moment de passer à l'action - sont sous-pondérés dans la prise de décision.

L'appartenance à plusieurs groupes dans l'organisation constitue ainsi une difficulté occultée. Un acteur projet efficace a besoin de temps (disponibilité), de motivation (inscription dans une logique d'action) et de sérénité (compatibilité avec des contraintes existantes). Face à ces réalités, la pertinence a priori d'un individu pèse moins qu'on ne le pense.

Pivot n°2 : le groupe et sa sociologie

Une fois le groupe projet constitué, sa logique d'action va résulter à la fois de l'addition des logiques individuelles (minoritairement) et d'une sociologie proprement collective, supérieure à la somme de ses parties (majoritairement). Ceci impose d'anticiper deux facteurs humains :

* La compatibilité : les ressources humaines du projet sont-elles "compatibles" dans leur disponibilité, leur motivation et leurs contraintes ?

* La synergie : si oui, est-il possible d'aller plus loin en maximisant les bénéfices pour les individus comme pour le projet ?

Si l'expérience permet d'appréhender correctement le premier facteur (la condition nécessaire), le second (la condition suffisante) nécessite un outillage adapté. Les sciences sociales entrent alors en jeu. Parmi elles, la sociologie des organisations propose des éclairages pertinents sur la synergie d'un groupe de projet.

En premier lieu, elle nous apprend qu'un groupe n'est pas un simple agrégat de personnes. Un groupe n'apparaît que lorsque plusieurs personnes remplissent trois critères cumulatifs : interagir, avoir "conscience" de ces interactions, et identifier le rôle qu'y joue l'autre. Les exigences cumulées de ces trois conditions amènent à préconiser qu'un groupe ne dépasse pas une douzaine de membres. Au-delà, mieux vaut créer un ou plusieurs sous-groupes, et pourquoi pas autant de sous-projets (par exemple en rendant plus autonomes les différents lots du S.I., chacun disposant d'une war room pour ses participants).

L'apprentissage du travail en commun obéit ensuite à un cycle en cinq étapes que les sociologues Tuckman et Jensen ont ainsi formalisé :

Cycle de Tuckman & Jensen
Etapes	Enjeux pour le chef de projet
Forming (gestation)	Susciter l'intérêt, mettre en relation
Storming (bouillonnement)	Maintenir la cohésion, gérer les conflits
Norming (maturation)	Légitimer et incarner les normes de fonctionnement
Performing (délivrance)	Coordonner, motiver, arbitrer… "manager"
Adjourning (dissolution ou transformation)	Accompagner ou impulser

Durant l'étape Performing, le processus interne d'influence fonctionne à plein. Dynamisé, parfois grisé, par la communauté de vision de ses membres, le groupe manifeste souvent une tendance à l'auto-aveuglement, qui culmine dans ce que Irving Janis a appelé "pensée de groupe", et qu'il définit comme "la recherche par le groupe d'un consensus, quel qu'en soit le prix, qui aplanit les dissensions et empêche d'envisager des alternatives crédibles". Cette recherche tend à favoriser soit les solutions conservatrices, soit au contraire une prise de risque excessive. Le chef de projet doit alors jouer un rôle modérateur et garder suffisamment de recul pour mettre en perspective les propositions émises. Dans un projet de système d'information, les aveuglements les plus fréquents concerneront bien entendu le temps et les coûts.

Pivot n°3 : la technologie et ses logiques d'usage

Outils bureautiques pour formaliser les livrables, plateaux virtuels pour centraliser les productions, suivre leur avancement et communiquer au sein des équipes… autant de concrétisations du projet qui supposent un interfaçage efficace entre l'homme et son levier d'action, la technologie. Pour autant, la relation de l'homme à la machine ne se laisse pas facilement appréhender. Le chef de projet peut y parvenir en cherchant à comprendre et orienter les logiques qui président à l'usage des applications informatiques dans sa propre équipe. Cela lui permettra d'ailleurs de mieux comprendre les futurs utilisateurs du S.I. qu'il met en place ! Ces logiques obéissent principalement à deux facteurs.

Le premier facteur est d'ordre structurel et décisionnel. La structure du projet s'insère dans celle, plus globale, de l'organisation. À son tour, le choix d'organisation induit des modes de décision, sur lesquels les collaborateurs vont régler leur système d'action, c'est-à-dire leurs attentes et les ressources mobilisées pour y satisfaire. L'introduction dans ce fragile équilibre d'un outillage informatique sophistiqué, via un projet, doit être pensée de manière à maximiser les avantages à la fois pour le projet et pour les principaux systèmes d'action à l'œuvre. Par exemple, une erreur fréquente du chef de projet est de profiter de l'outil technologique pour installer une visibilité totale. Cette fausse bonne pratique tend à supprimer les zones grises dans lesquelles les régulations informelles entre acteurs s'opèrent. Face à ce qu'ils perçoivent comme un nouveau big brother, les acteurs du projet rechignent à l'utiliser, voire détournent son utilisation, aboutissant à ce que Luc Loquen qualifie de "structures de mensonge".

Le second facteur est d'ordre temporel. Intégrer le temps à la gestion des usages informatiques sur un projet, c'est reconnaître aux collaborateurs le droit au temps dit "qualitatif" (par opposition au temps "utile"). Ce temps de pause, parfois de prise de recul, peut rester du temps posté, en ce sens que la personne demeure assise devant son ordinateur, mais l'utilise à des fins non directement liées au projet. Vouloir réglementer, voire supprimer, cette pratique ne sert à rien. Ce serait mal compris par des travailleurs dont les temporalités privées et professionnelles sont de plus en plus mélangées. Ce serait en outre contre-productif, car chaque personne doit disposer de marges de manœuvre dans l'aménagement de son temps. Il est facile de multiplier trente minutes quotidiennes de temps qualitatif par la productivité - universelle ? - d'une minute de travail utile, faisant ainsi apparaître un soi-disant coût d'opportunité. Il est plus difficile d'admettre que l'être humain n'est pas une machine à rendement constant. S'il est indéniable que les projets S.I. accusent des retards importants, ce n'est pas la productivité individuelle qui est en cause, mais plutôt d'autres facteurs que nous avions abordé dans un précédent article, auquel nous renvoyons le lecteur.