Projet informatique, système d’acteurs. Interactions et jeux complexes, la particularité des projets informatiques… Tout projet informatique est sous-tendu par un système de rapport entre acteurs.
Ces acteurs sont issus des groupes différents : utilisateurs, informaticiens, maître d’ouvrage, maître d’œuvre, fournisseurs… Cet ensemble est le lieu d’interactions et de jeux complexes et fait la particularité des projets informatiques.
Selon Marciniak et Rowe, « l’examen de ces particularités conduit à souligner les aspects du management de projet qui s’avèrent pertinents pour ce type de projet : l’analyse des risques, la préparation du projet, la gestion des conflits et du système d’acteurs » (Marciniak et al., 2005).
La question de l’analyse du risque est essentielle même si nous ne la traitons pas dans cet article, tant elle est vaste et surtout particulière aux projets informatiques : de nombreuses études montrent que depuis plus d’une trentaine d’années les projets d’implantation de technologies de l’information connaissent des taux d’échec élevés, malgré les importantes ressources qui y sont allouées.
Table des matières
Interactions et jeux complexes
La première véritable étude sur la difficulté des projets…. Selon Kappelman et McLean, une des causes évidentes de cette situation vient du fait que les groupes d’acteurs ne parlent pas le plus souvent le même langage : alors que les utilisateurs ou usagers de système informatique parlent de sa capacité à satisfaire leurs besoins en information, de sa convivialité, les spécialistes (informaticiens) voient plutôt la performance technique du système, sa facilité de maintenance ou l’absence d’erreurs (Kappelman et al, 1994).
L’aspect qui nous semble particulièrement important est la gestion du système d’acteurs et éventuellement des conflits (Interactions). En théorie, chacun joue une partition dans le projet.
Par exemple, la maîtrise d’ouvrage (MOA), qui est représentée généralement par un ou plusieurs départements métier (ou la direction générale), se charge d’élaborer en amont un cahier des charges. C’est un document qui spécifie les besoins fonctionnels de l’application à développer.
Il est généralement réalisé en lien avec la direction des systèmes d’information (DSI) qui apporte ses connaissances de l’environnement technique et son expérience des solutions technologiques, en vue de juger de la faisabilité des demandes.
La maîtrise d’œuvre (MOE) – qui couvre développement et intégration – est prise en charge par la DSI. Elle peut également être sous-traitée (entièrement ou en partie) à une ou des sociétés de services (fournisseurs) etc.
Concernant Pi.com, les acteurs du projet sont :
- la maîtrise d’ouvrage (MOA), assurée par la direction générale avec les départements métiers de la prévoyance (dans lesquels se trouvent les utilisateurs) ;
- la maîtrise d’œuvre (MOE) qui relève de la DSI ; à noter ici qu’une autre catégorie d’acteurs entrent en action, notamment des équipes informatiques (Interactions) externes ou prestataires de services qui sont plus nombreux que les internes ;
- le conseil d’administration pour le caractère stratégique du projet ;
- l’unité Recherche et Développement, entité composée de chercheurs.
On ne peut pas faire une analogie parfaite par rapport à la catégorisation de Boutinet, mais la situation des chercheurs de la R&D par exemple, les place dans une position d’acteurs confrontants :
- la critique sur la faible prise en compte dans le projet de l’aspect sécurité des applications par l’un des chercheurs,
- spécialisé dans le domaine, a permis une évolution significative de la démarche projet ;
- cependant, sans être conflictuels, les rapports entre l’équipe MOE et l’entité R&D ne les ont pas incités à la coopération.
Le projet Pi.com nous conduits à analyser d’une part des situations de communication entre les informaticiens eux-mêmes et, d’autre part, entre les informaticiens et la maîtrise d’ouvrage en particulier les utilisateurs futurs du projet.
Relations informaticiens-informaticiens
Beaucoup d’organisations sont passées à l’externalisation de leur service informatique, espérant réduire les coûts liés aux investissements dans les technologies de l’information.
Le recours à des sociétés de services et d’ingénierie informatiques (SSII) pour les projets, même de petite taille, semble être la règle.
Ce qui pose la question de la sous-traitance de l’informatique des entreprises. Beaucoup d’auteurs ayant travaillé sur le phénomène (Feeny et al., 2000) estiment (Interactions) que la sous-traitance générale et uniforme s’avère être une mauvaise décision, une erreur qui peut coûter cher ; ne pas sous-traiter en est une autre. Une sous-traitance sélective serait une piste pour les entreprises.
La MOE, la direction de système d’information en l’occurrence a fait appel à plusieurs SSII dans le cadre de Pi.com pour développer les sous-ensembles indiqués plus haut.
Les « externes » représentaient 90 % des informaticiens engagés sur le projet, ce qui n’est pas sans risque pour le directeur de système d’information.
Avant les années 1980, on parlait de directeur informatique… (DSI). Ils sont « recrutés » en fonction de la demande de ressources dans les projets et de leurs profils métiers.
Les fonctions de l’informatique regroupent une nébuleuse d’une… (développeurs, analystes, chefs de projet MOE, chef de projet MOA, chefs de projet junior, etc.).
Plusieurs questions résultent de cette configuration de projet où les acteurs sont des externes :
- les problèmes d’harmonisation de volumes horaires hebdomadaires et surtout de procédures de travail ;
- la gestion n’est pas seulement administrative car ces acteurs ont les contraintes de leur entreprise d’origine (35 heures par exemple) et doivent respecter celles de l’entreprise d’accueil ;
- la diversité même des acteurs ;
- contrairement à une idée répandue, la « confrérie » des informaticiens est d’une grande diversité qui est souvent liée aux technologies sur lesquelles ils sont compétents ;
- la question de la légitimité des internes par rapport (Interactions) aux externes ;
- cette légitimité est liée aux compétences techniques : plus l’informaticien est techniquement « bon », plus il est respecté par ses pairs ;
- la gestion de compétences des acteurs : en effet ces informaticiens, après avoir « rempli » leur contrat, partent avec leurs compétences, leurs acquis et leur expérience du projet.
C’est l’ensemble de ces défis que doit gérer le DSI. Au début, ce DSI est en réalité un directeur de projet.
Il a en charge le projet et il rend compte à la direction et aux réunions du conseil d’administration. Il a recruté un chef de projet « architecte technique » pour ce projet et qui serait susceptible de manager tous les profils entrants au cours du projet.
Pour mieux communiquer, une organisation a été mise en place sous forme de comité de supervision (MOA/MOE) et comité de coordination interne à la maîtrise d’œuvre.
L’objectif de cette organisation est d’être efficace pour éviter les pathologies récurrentes aux projets informatiques : dépassement de délais, dépassement de coûts, usine à gaz, projet sans pilote, spécifications floues…
Vue de l’extérieur, l’équipe informatique est soudée et se fédère autour du directeur du projet. Mais à l’intérieur, comme dans tous les projets, se nouent des relations de pouvoir qui stabiliseront le projet par l’émergence d’un leader charismatique (Boutinet, 2006) :
- le directeur du projet, sans doute assailli par les justifications de coûts et délais par la DG, le CA ainsi que la gestion administrative du projet, semble « perdre pied » techniquement (Interactions);
- l’architecte technique recruté pour le projet semble, au fil de son expérience technique, acquérir une plus grande légitimité auprès des informaticiens externes.
Conséquence : une fronde des développeurs et chefs de projet pour inciter l’architecte à « prendre les rennes du projet ».
Relations informaticiens-utilisateurs
Le débat sur les réactions des salariés face aux technologies continue à faire l’objet d’une abondante littérature (Markus, 2000 ; Dorrer, 2004) ; Quan, 2006).
Ces réactions viendraient du fait que l’opposition au changement est une caractéristique du comportement humain.
Outre cette référence à la nature humaine (Leleu-Merviel, 2008), on peut se poser quelques questions simples sur l’introduction des technologies informatiques, par exemple, dans l’entreprise :
- les individus ont-ils leur mot à dire sur le choix de la technologie et son introduction ?
- Un concept devenu à la mode est celui de la gouvernance des technologies de l’information IT gouvernance mais la réalité est toute autre ;
- la technologie elle-même est-elle facile à maîtriser (Interactions)?
- Est-elle adaptée aux utilisateurs ?
- la formation et l’aide sont elles fournies ?
- comment la communication se fait-elle autour de cette nouveauté ?
- Cette dernière question nous a amené à observer les relations d’échange entre les concepteurs réalisateurs de Pi.com et les salariés qui l’utiliseront pour leur travail. Il s’agit des échanges qui vont de l’élaboration du cahier des charges à la mise en service du « produit ».
Le comité de supervision indiqué plus haut a pour rôle de permettre une plus grande coopération entre les futurs utilisateurs du SI et les informaticiens chargés de le mettre en œuvre. La tendance dans les projets informatiques est d’associer les utilisateurs, voire de créer des laboratoires tests utilisateurs.
Selon Quan, « pour être sûr que les utilisateurs et les informaticiens se comprennent, on a même parfois poussé le raisonnement jusqu’à former ces mêmes utilisateurs aux méthodes Merise, RUP ou au modèles UML pour que ceux-ci puissent lire et donc valider les schémas et documents élaborés par les concepteurs informaticiens ».
La démarche, même si elle paraît louable (Interactions) et pragmatique, pose néanmoins le problème de ce que nous appellerons la compétence supplémentaire de l’utilisateur : s’il est vrai que les utilisateurs sont choisis parce qu’ils connaissent leur métier et donc savent en théorie ce que l’application doit faire, ont-ils vraiment la capacité d’exprimer leurs besoins efficacement ? Cette question va se poser lors de l’élaboration du cahier des charges.
Dans le projet Pi.com, c’est la maîtrise d’ouvrage (MOA) qui a la charge d’élaborer avec l’aide de la maîtrise d’œuvre le cahier des charges. Cette MOA est composée de la direction générale.
À l’image d’autres projets-phares comme la certification ISO,…, et des acteurs métiers (chefs de service, responsables d’unités, gestionnaires de dossiers). Au début la communication a été laborieuse.
A lire aussi Technologies d’information et de communication : quel rôle dans les dynamiques territoriales de développement ?
La première difficulté entre informaticiens et utilisateurs est celle de la disponibilité des acteurs métiers pour élaborer ce cahier des charges et les spécifications qui en découlent.
La MOE prend l’initiative de l’élaborer elle-même : conséquence, le cahier des charges ainsi que les réalisations qui ont été faites par la suite ne sont pas acceptées par les acteurs métiers qui estiment n’avoir pas été associés.
Outre ce manque de disponibilité, les informaticiens estiment qu’il y a un déphasage entre les acteurs métiers eux-mêmes :
- d’une part il y a un déphasage, pensent-ils, entre la « hiérarchie du service et les subordonnés », ces derniers ayant une toute autre vision de l’application à réaliser ;
- d’autre part, nous passons notre temps à leur expliquer les relations interservices, ça nous prend un temps énorme et c’est exaspérant pour un informaticien à cause du temps énorme passé en MOA ou assistant MOA.
Enfin les responsables métiers n’hésitent pas à exprimer leurs inquiétudes sur l’automatisation des fonctions : attention à ne pas tout automatiser, sinon après je fais quoi moi avec mes gars.
Les relations ainsi observées au début du projet sont présentées dans la figure 6.
Les systèmes informatiques appelés abusivement système d’information ne sont pas seulement des outils techniques au service d’une organisation.
Il s’agit d’un cas particulier de projet que la composante humaine vient complexifier. S’il est possible d’apporter des solutions aux difficultés techniques de mise en œuvre des systèmes d’information, la question du facteur humain demeurera (Interactions) posée tant que l’accent ne sera pas mis sur la communication entre les concepteurs (informaticiens) de ce « système » et les potentiels utilisateurs (salariés et autres non informaticiens).
Sans généraliser à partir de cette étude de cas, on peut conclure que les salariés sont les moins mis en avant dans les processus communicationnels des projets tels que les conçoivent ces entreprises.
A lire aussi Décès de l’ancien Ministre de la Communication Moctar Kébé à l’âge de 84 ans
Pourtant, la mise en place d’un système de communication-coopération peut amener à intégrer des variables comme la confiance qui peuvent contribuer de façon significative à la créativité de ces acteurs projet. Un modèle de travail coopératif, axé sur la communication, est envisageable pour émuler cette créativité.
A lire aussi
La communication et la confiance pour la réussite du projet
