S3. Management de l’informatique
Plan du thème n°3. L’ORGANISATION DE PROJETS INFORMATIQUES
I. Etude de documents :
1. Maîtrise d’ouvrage / maîtrise d’œuvre : responsabilités et collaboration 2. L’organisation par projet : l’organisation idéale ?
Travail à faire :
Question 1. A partir du document 1 :
- 1.1. Différenciez les contrats de projet « en régie » des contrats « au forfait » - 1.2. Relevez les problèmes organisationnels soulevés par ce choix
- 1.3. et justifiez les raisons pour lesquelles les entreprises clientes de SSII privilégient désormais les projets au forfait.
Question 2. A partir du document 2 :
- 2.1. Définissez les notions d’ « organisation matricielle » et d’ « organisation concourante », différenciez cette dernière de l’organisation « taylorienne » et identifiez les avantages attendus de ce type d’organisation des projets.
- 2.2. Identifiez les problèmes spécifiques de gestion des ressources humaines (relations entre le responsable de projet & les membres de l’équipe projet) et de motivation que rencontrent les équipes des projets informatiques ?
Document 1. Maîtrise d’ouvrage / maîtrise d’œuvre : responsabilités et collaboration
1Nous avons vu précédemment que dans un projet de système d’information, on distingue trois acteurs principaux : - le couple maître d’œuvre – maître d’ouvrage,
- l’équipe de projet avec, à sa tête, le responsable ou « chef » de projet - les utilisateurs.
Rappelons les rôles de maître d’œuvre et maître d’ouvrage : Ils sont liés par une relation contractuelle. Le maître d’ouvrage est ou représente le client qui demande la réalisation d’un ouvrage, le maître d’œuvre est le fournisseur qui réalise l’ouvrage.
Ainsi, le service informatique d’une entreprise pourra être tour à tour maître d’œuvre vis-à-vis d’un autre service (ex : commercial) à qui il doit fournir un produit logiciel, et maître d’ouvrage vis-à-vis d’une société extérieure – une SSII- à qui il sous-traite tout ou partie du projet. La fonction de maître d’ouvrage peut être remplie directement par les directions fonctionnelles ou métier qui commandent l’ouvrage (RH, Gestion et finance…), ou bien par une maîtrise d’ouvrage dite déléguée qui assure l’interface entre l’utilisateur et le maître d’œuvre. Fréquemment, et notamment dans le cas où l’utilisateur assure lui-même la maîtrise d’ouvrage, une assistance à maîtrise d’ouvrage est sollicitée auprès d’un prestataire interne ou externe à l’entreprise.
Quelle que soit l’organisation retenue, l’idée est de différencier celui qui est responsable de la rédaction du cahier des charges et de l’expression des besoins des utilisateurs, le maître d’ouvrage, de celui qui est tenu de le respecter, le maître d’œuvre.
Mais cette procédure, selon laquelle le maître d’ouvrage recueille les besoins auprès des utilisateurs, choisit une solution globale, met en forme les besoins, afin qu’ils soient suffisamment précis et compréhensibles par le maître d’œuvre, les consigne dans le cahier des charges (CC) qu’il transmet au maître d’œuvre, qui établit une solution détaillée permettant de satisfaire le besoin exprimé, cette solution devant être acceptée et validée par le maître d’ouvrage (qui devient le CC de réalisation et sert souvent de référence lors de la recette fonctionnelle du produit final), cette procédure donc, met très largement en évidence des problèmes qui peuvent être sources de litiges entre le client et le fournisseur :
- le besoin formalisé par le client est-il exhaustif ?
- le besoin exprimé est-il compréhensible par le fournisseur ? - le client a-t-il les moyens de valider la solution ?
Seule une participation étroite entre utilisateurs, maître d’ouvrage et maître d’œuvre, non seulement dans la préparation mais aussi dans la réalisation et la livraison de l’ouvrage, la possibilité de reconsidérer le périmètre fonctionnel, les priorités d’un projet, ses délais voire son prix peuvent garantir la bonne fin du projet.
Pourtant, du point de vue économique, la situation a profondément évolué ces dernières années. On constate que les contrats que passent des entreprises avec des sociétés externes type SSII tendent à devenir de plus en plus
exigeants. Les enjeux de coûts sont tellement élevés et la concurrence entre SSII est si forte que les entreprises clientes ont tendance à vouloir verrouiller très vite les engagements contractuels : les spécifications, les délais comme le prix.
Ainsi, dans ce cadre, deux types de contrat sont classiquement utilisés.
Historiquement, les SSII faisaient signer des contrat en régie : elles envoyaient des équipes projet d’informaticiens chez leurs clients jusqu’à pleine réalisation du projet. L’estimation de la charge de travail étant très délicate, les SSII facturaient à l’heure travaillée. A charge pour le client de vérifier que la facture était justifiée. Surtout, la SSII n’avait véritablement qu’une obligation de moyens vis-à-vis de son client.
Aussi, on comprend tout à fait que le rapport de force s’équilibrant, les entreprises clientes privilégient désormais les contrats au forfait : en principe, le prix négocié au préalable pour un périmètre fonctionnel prédéfini n’est pas révisable (sauf impondérable) ; il appartient donc au maître d’œuvre de scrupuleusement respecter le budget initialement négocié, toute dérive de coût (dépassement de la durée prévue, versement d’heures supplémentaires) étant à sa charge, et de respecter également les délais si le client a pris soin d’inscrire au contrat des indemnités de retard en cas de dépassement ! Aussi, parle-t-on d’obligation
de résultat du maître d’œuvre vis-à-vis du maître d’ouvrage dans ce cas.
Régie ou forfait : à bon chat, bon rat (L. Bloch) p 89
« Lorsqu’une entreprise confie un projet
informatique à une société de services, il y a 2 types de solutions pour l’organisation du travail et de sa facturation :
- au forfait, le prestataire s’engage, sur la base d’un CC détaillé, à réaliser le système demandé dans un délai donné pour une somme fixée une fois pour toute au départ, à lui de mettre en place les moyens appropriés pour mener le projet à bien ; il a une obligation de résultat ;
- en régie, le prestataire a plutôt une obligation de moyens, il met à la disposition du client un certain nombre d’ingénieurs et de programmeurs sous la conduite d’un chef de projet, et la facturation a lieu à la journée, en quelque sorte comme pour un taxi, et le travail est fini quand il est fini ; c’est en fait de la délégation de personnel plus ou moins déguisée.
Bien entendu, des contrats mixtes peuvent être négociés, avec une partie en régie pour les tâches pour lesquelles il est de l’intérêt des deux parties qu’elles prennent le temps nécessaire (ex : formation des utilisateurs), et une autre au forfait, lorsque les contraintes économiques ou de délais sont vitales pour le client.
Cette évolution explique pourquoi des ingénieurs informaticiens employés par certaines SSII peu scrupuleuses se plaignent d’une forme de dégradation de leurs conditions de travail, en devant assumer les contraintes de délais et de budget préalablement acceptées par leur employeur2.
Quant à l’équipe projet, elle est placée sous l’autorité d’un chef de projet3, responsable devant le maître d’œuvre de l’avancement du projet. Si l’on a découpé le projet en plusieurs sous-projets, un chef de projet est responsable de l’ensemble du projet, d’autres pilotent de plus près chacun des sous-projets. Le chef de projet a d’abord une fonction de gestion des ressources humaines : il anime l’équipe, veille à la cohésion du groupe et à la motivation de chacun et il est responsable de l’élaboration et du suivi du planning de travail, de la répartition des rôles, de la coordination du travail de chacun. Il doit être capable d’écoute et de négociation avec chaque membre de l’équipe pour l’estimation de la charge affectée afin que les délais aient réellement une chance d’être respectés. Si l’allocation du budget global lui échappe bien souvent, il se trouve de fait responsable de l’efficience du projet, toute dérive de temps se traduisant par un risque de dépassement de budget.
Cependant, c’est plus encore sa capacité à corriger une dérive de temps ou de budget en obtenant l’adhésion de son équipe qui fait sa valeur et son importance.
2 Voir par exemple (mais ce n’est qu’un exemple…) : http://dchaffiol.free.fr/index.htm
Si le contrat est au forfait et que le client ne dispose pas de compétences et d’effectifs suffisants pour participer activement au projet, le prestataire peut être tenté d’interpréter de façon très restrictive le CC et ses propres obligations au contrat, et au contraire de manière extensive et pointilleuse les obligations du client. Si les équipes du client participent activement au travail et que l’estime réciproque règne entre les participants, ce type de dérive est moins probable et de toute façon plus limité car chacun est en mesure d’apprécier le travail à faire et son volume. Mais, dans un contexte où chaque entreprise lutte pour sa survie et, où pour une société de services, avoir des employés en attente de travail (en « inter-contrat ») est une lourde charge, si le prestataire a pu mesurer l’incompétence de son client, il résistera difficilement à la tentation de gonfler les facturations en exigeant la signature d’avenants au contrat initial pour toute prestation supposée à tord ou à raison ne pas avoir été prévue par le CC.
Si le travail au forfait comporte des inconvénients, le travail en régie n’en est pas exempt. On peut même dire qu’il est incontrôlable si le client ne dispose pas de sa propre équipe et d’un chef de projet capable de suivre le travail au jour le jour. Il est tellement confortable d’avoir une réserve permanente de personnels en régie, un peu sous-occupés mais de ce fait assez disponibles en cas d’urgence, et d’emploi plus malléable que les personnels internes !
Ainsi, une sous-traitance modérée peut être un excellent moyen de renforcer le potentiel de l’entreprise, à condition que cette externalisation soit équilibrée par le maintien d’une véritable équipe du client, capable de conserver la compétence interne et de contrôler les prestataires, et pas juste de rédiger des CC. L’externalisation à tout crin, assortie de la liquidation des compétences internes est une erreur, et celui qui la commet ne tarde pas à être puni par la déliquescence de son SI, l’explosion de ses coûts, l’incohérence de ses procédures de gestion, bref de la perte de contrôle d’éléments fondamentaux du fonctionnement de l’entreprise.
L’externalisation peut être un succès si elle est menée par une entreprise compétente qui sait ce qu’elle fait ; elle saura alors choisir de bons prestataires et obtenir d’eux un travail de qualité : à bon chat, bon rat. »
Document 2. L’organisation par projet : l’organisation idéale ?
L’organisation par projet4 connaît un engouement sans précédent depuis la fin des années 1980 (ou mode projet/voir par exemple : http://management.journaldunet.com/dossiers/050582projet/index.shtml ). Empruntée aux grands projets de l’aérospatiale, les industriels et en particulier les constructeurs (automobile comme informatique) s’en sont emparés afin de développer de nouveaux produits dans un contexte chamboulé par la concurrence et la mise en œuvre d’organisation de la production en « juste-à-temps ». Typique des SSII, toutes les activités économiques sont susceptibles aujourd’hui d’emprunter ses principes.
L’organisation « taylorienne » au sein de laquelle les individus sont séparés selon leur expertise dans une logique fonctionnelle (services informatique / RH / Marketing….) sont peu propices à l’introduction de projets innovants et transversaux. Adaptée à la production de masse, elle se révèle inopérante dans le contexte d’une concurrence forte.
Toyota l’avait en son temps bien compris : l’introduction d’organisations en « juste-à-temps » de la production et de la chaîne logistique s’est accompagnée d’une profonde remise en cause de l’organisation du travail.
Quand la concurrence est rude, qu’il faut répondre à une demande différenciée et évolutive des clients, que les cycles de vie des nouveaux produits sont toujours plus courts, cette chrono-compétition ne peut être maîtrisée que par des sociétés capables de concevoir de nouveaux produits très rapidement introduits sur le marché.
Il n’est plus question alors, d’une organisation séquentielle pour le développement des projets qui amènerait le service marketing à réaliser une étude de marché, puis de transmettre le dossier aux ingénieurs de conception d’un nouveau modèle, qui à son tour transmettrait le dossier au bureau de méthodes pour la conception du processus de production, la création de nouvelles usines, dossier qui retournerait au service marketing pour l’élaboration du plan marketing, en passant par les RH pour définir les plans de formation… Non seulement ce processus est trop long mais il est dangereux : c’est un processus difficilement réversible, chaque changement d’orientation impliquant pratiquement un nouveau bouclage global.
Ainsi, Intel est réputée pour construire ses usines destinées à la fabrication de ses nouveaux microprocesseurs deux ans à l’avance… En outre, dans les organisations en « juste-à-temps », l’ensemble du processus de production a été morcelé entre différents sous-traitants et partenaires industriels, ce qui accroît les besoins de coordination au sein de ces réseaux d’entreprises. Ainsi, c’est en 1989 pour son projet X06 (la « Twingo ») que Renault a promu son technocentre, lieu de conception intégrée, dit « en plateau » (en analogie avec un plateau de cinéma), où toutes les expertises sont réunies, aussi bien internes (marketing) qu’externes (sous-traitants, concessionnaires) pour garantir la viabilité économique et technique du projet avant tout lancement proprement dit. Pour reprendre l’image la plus fréquente pour qualifier ce changement organisationnel, à la course de relais – l’ingénierie séquentielle -, sera préférée « l’équipe de rugby au sein de laquelle chaque membre de l’équipe progresse en même temps que les autres tandis que de nombreuses combinaisons restent possibles à tous les stades du jeu »5.
Ce modèle d’ingénierie dite « concourante » (ou « simultanée »)6 a alors inspiré toutes sortes d’organisations ayant besoin de faire travailler des équipes autonomes pour mener à
bien des projets complexes. D’après L. Bloch7, P. Brooks, l’auteur en 1975 de l’ouvrage intitulé « le mythe de l’homme- mois » et responsable du projet OS 360 fut l’un des premiers à réfuter l’efficacité d’une organisation « taylorienne » de l’informatique.
Par leur caractère intellectuel et immatériel, les activités de développement ne peuvent faire l’objet d’une estimation de charges et donc de durée trop précise et que par conséquent, toute division du travail trop poussée y est impossible. Il utilisa des phrases lapidaires du type « si une femme peut faire un enfant en neuf mois, neuf femmes peuvent-elles le faire en un mois ? » pour exprimer cette idée. « Dès lors que l’écriture d’un
4 Voir « De la gestion de projet au management par projet – maîtrise d’une organisation transversale » de J-L G. Muller et M.
Joly, AFNOR 2002
5 Gilles Garel : Le management de projet, La Découverte 2003 p 37.
6http://www.urfist.cict.fr/pub5_1.html (§1)
7 « systèmes d’information, obstacles et succès », Vuibert, 2005 p 101
programme n’est pas effectuée par une personne unique qui en a eu l’idée, mais qu’un groupe de demandeurs s’adresse à un groupe de réalisateurs, les trois-quarts du temps cumulé qu’ils vont consacrer ensemble à définir et à construire le programme seront consacrés à des échanges d’informations entre eux et ce, parce que seule une réalisation du projet par itérations successives s’avère efficace : réalisation d’un prototype sommaire, que l’on montre au donneur d’ordres, qui fait part de ses critiques et de ses suggestions à partir desquelles sera réalisé un second prototype plus élaboré, et ainsi de suite, pendant tout le cycle de vie du projet, en fait. C’est notamment pour cela qu’ajouter du personnel à l’équipe d’un projet
en retard ne fait qu’accroître le retard : il faut former et informer les nouveaux arrivants, et cela prend du temps qui s’ajoute à celui que les développeurs consacraient déjà à la communication au sein de l’équipe : les hommes et les mois ne sont interchangeables que lorsqu’une tâche peut être divisée entre plusieurs travailleurs sans réclamer de communication entre eux. Et Brooks de préconiser une organisation de l’équipe de développement selon le modèle d’une équipe chirurgicale dans un bloc opératoire : de même que seul le chirurgien en titre manie effectivement le bistouri, dans une telle équipe, le chef-programmeur et les développeurs soumis à son autorité dispose d’un adjoint (en binôme) et se voit assisté de spécialistes dont certains ne seront éventuellement pas employés à plein temps et qui pourront contribuer à plusieurs projets. (p 101) ».
Ainsi, dans des SSII d’une certaine importance, par exemple Unilog, ce type d’organisation « matricielle » est systématiquement mis en œuvre. Lorsqu’un informaticien entre chez Unilog, il se voit affecter un service d’attache et il est soumis à un supérieur hiérarchique qui est responsable de son affectation sur différents projets au cours de l’année, qui l’évaluera régulièrement et définira son plan de formation et de carrière. Mais, à chaque fois qu’il est affecté à la réalisation d’un projet, il sera sous
l’autorité d’un chef de projet qui, sans être un supérieur hiérarchique au sens strict, sera son interlocuteur direct tout au long du projet. L’intérêt de ce type d’organisation est évident pour la société : elle gère simultanément plusieurs projets ; aussi, il lui faut optimiser l’affectation de son personnel entre les différents projets. Ainsi, un spécialiste réseau n’interviendra que les 15 premiers jours sur un projet de 6 mois avant d’être affecté à un autre projet.
Aussi, le sentiment des informaticiens soumis à ce type de structure peut être partagé. Si le travail en équipe paraît à juste titre mobilisateur (chacun connaît l’objectif du projet) dès lors qu’elle n’excède pas une dizaine de personnes, si l’ajustement mutuel (une communication horizontale abondante et non hiérarchique entre les membres de l’équipe) est préféré aux relations hiérarchiques classiques, si elle semble se prêter aux échanges de pratiques entre experts différents, elle ne doit cependant pas être idéalisée. Il n’y a pas plus de « one best way » en organisation de projet, qu’en organisation de la production.
Le style de management pratiqué par le chef de projet sera déterminant pour la qualité des relations entre les membres de l’équipe. Saura-t-il pratiquer un management participatif, sera-t-il capable de déléguer
Chez Unilog, au sein d’une entité opérationnelle (un établissement autonome à taille humaine), on peut observer qu’une organisation matricielle est mise en place, les SBL étant des regroupements par clients selon leurs métiers et les OBL, des regroupements des
des initiatives et à donner le meilleur de lui-même. En fait, le rôle du responsable de projet est ambivalent. Il a trois casquettes : tour à tour « leader », « manager » & « chef ». En début de projet, dans la phase de conception, il doit inciter les membres de son équipe à proposer les meilleures solutions, qu’ils soient spécialistes de bases de données ou « programmeurs virtuoses »… et à travailler ensemble. Il est censé impulser une direction commune à son équipe. Le manager s’assure que chacun fait avec efficience ce qu’il est censé faire. Mais comme la vie des projets n’est pas « un long fleuve tranquille », il lui appartient également d’évaluer le travail effectué, de rappeler à chacun ses responsabilités, de mettre fin aux conflits éventuels, voire de trancher lorsque des décisions « désagréables » doivent être prises (mise à l’écart d’un développeur incompétent, replanification drastique voire abandon du projet). Le fait que le responsable de projet soit souvent un analyste-programmeur expérimenté n’est pas dû au hasard. Au pouvoir octroyé (on obéit au chef) on préfère le pouvoir « mérité » de celui qui a connu « quelques victoires et de nombreuses défaites8 ».
Plus encore, certains sociologues d’entreprise notent une forme de stress spécifique à cette forme organisationnelle. L’organisation par projet rend chaque membre de l’équipe responsable de la réussite de l’équipe et du projet dans son ensemble alors même que, par ses risques naturels, de nombreux facteurs extérieurs à la volonté des personnes peuvent entraver la bonne marche du projet. Etre responsable sans pour autant porter le projet sur ses épaules demande beaucoup de discernement. Ce sont des situations favorables aux heures supplémentaires faites « à l’œil » et pour « la bonne cause »…
Enfin, certains informaticiens vivent difficilement la double autorité9 à laquelle ils sont soumis, « coincés » entre le chef de projet et le supérieur hiérarchique référent ou passent difficilement d’un projet à l’autre sans avoir réellement le temps de faire le point, de retrouver leurs marques, sans être sûr que leurs mérites seront reconnus.
Reste qu’il est intéressant de constater que le secteur informatique a toujours mis en œuvre les formes organisationnelles les plus abouties. Le fait que les échecs des projets informatiques soient élevés, certes, mais relativement moins que dans d’autres secteurs économiques ne relève pas du hasard. Les projets informatiques sont fondamentalement incertains et exigent de mobiliser des compétences en constante évolution. En conséquence, les organisations doivent être souples. Si l’absence de méthode est fatale, il serait erroné de tout attendre d’une méthode ou d’un logiciel de planification sophistiqué. La dimension humaine est essentielle à la réussite des projets. La capacité des organisation à tirer les leçons du passé, à « capitaliser les connaissances acquises » d’un projet à l’autre, l’est tout autant.
8 Voir sur ce point l’avis éclairé de Scott Berkun, ex-ingénieur informatique chez MS, « l’art du management de projet »,O’Reilly, 2006
9 Recommandée d’ailleurs par Taylor, tout ouvrier relevant à la fois de l’autorité du chef d’atelier et de l’ingénieur de production
« Finalement, il aura fallu ces années d’égarement pour que l’on admette enfin la vérité toute simple : dans un projet, ce qui compte le plus, c’est l’entente entre ses membres et les conditions de travail.
Voici un exemple qui illustre bien cette loi d’Airain : pendant des années, Fred Brooks fit faire et refaire le même projet à ses étudiants de l’Université de Caroline du nord. Certaines conditions du projet restaient constantes telles que les délais, les livrables et la taille de l’équipe qui y était affectée alors qu’il faisait varier les méthodes et techniques utilisées semestre après semestre.
Les conclusions de cette expérience menée pendant une dizaine d’années sont que les paramètres sur lesquels on se focalise habituellement (méthodes et techniques) semblent ne pas avoir autant d’importance qu’on le suppose. En revanche, des facteurs comme l’harmonie au sein de l’équipe et une répartition intelligente des rôles ont eu une influence déterminante sur le résultat des projets presque identiques supervisés par Fred Brooks.
Point n’est besoin d’une observation aussi systématique pour comprendre l’importance du facteur humain dans la réussite d’un projet. Il suffit de penser à votre réaction si votre patron pose un cahier des charges sur votre bureau en vous demandant « combien vous faut-il pour faire ça avec l’aide d’une autre personne
? ». La première question que vous allez poser ne sera pas d’ordre technique (comme « quel environnement système ? » ou « est-ce que je peux utiliser l’outil de mon choix ? ») mais plutôt « qui sera l’autre personne ? »…
Donc, il faut que l’harmonie règne, non pas pour des raisons d’angélisme (du genre « aimez-vous les uns les autres »…) mais bien pour des raisons d’efficacité. Cette question des rapports humains a souvent été négligée dans la gestion des projets informatiques. Pourtant, en matière de développement logiciel, il est illusoire d’espérer obtenir de bons résultats si on va à l’encontre de la nature humaine et surtout de la façon de travailler des développeurs et pour ça il faut éviter de les mettre dans une
« matrice de contraintes contradictoires »...
Sur ce point, les responsables de projet ont une influence primordiale et doivent comprendre dans quelle situation leurs développeurs sont les plus efficaces. En effet, le comportement des gens dépend directement de l’influence de leur environnement et donc des directives de leurs dirigeants.
Extraits du livre « Le 3ème tournant » d’Alain Lefebvre, éditions Dunod. http://alain-lefebvre.com
