Organisation par projets : Pro et Contra [1]

9 mai 2002

Le rôle de la maîtrise d'ouvrage du système d'information (SI) dans l'entreprise est en débat. Est-il nécessaire d'organiser, de professionnaliser des compétences en maîtrise d'ouvrage ? Ou bien au contraire faut-il démanteler les compétences existantes ?

Des équipes de maîtrises d'ouvrage (MOA) se sont développées dans les directions pour mieux exprimer les besoins en matière de SI et mieux maîtriser l'"alignement stratégique" du SI (ou, en termes moins vagues, sa pertinence envers les priorités du métier). Comptant dans de grandes entreprises jusqu'à quelques dizaines de personnes, ces MOA ont été chargées d'analyser les besoins, rédiger et faire valider les cahiers des charges, suivre les réalisations, assurer les recettes fonctionnelles, organiser les déploiements et formations, animer et contrôler le bon usage du SI, mener une veille comparative sur les SI des autres entreprises du secteur. 

Certaines entreprises démantèlent maintenant ces équipes et reclassent leurs personnels à l'informatique qui retrouve ainsi son rôle ancien de maître du SI, responsable de son adéquation aux besoins et à la stratégie. On entend de nouveau la phrase jadis fameuse "la distinction entre maîtrise d'ouvrage et maîtrise d'œuvre est franco-française et n'a pas de raison d'être : tout ça, c'est de l'informatique". Il est vrai que l'informatique elle-même redéfinit son périmètre en sous-traitant certaines de ses activités, en recourant à des progiciels pour d'autres ; des directions informatiques se sont ainsi rapprochées des méthodes et priorités qui sont celles de la MOA.

Dans d'autres entreprises, on ne jure que par les "projets" : le succès d'une réalisation informatique dépend, dit-on, de la fermeté, de la clarté de l'organisation autour d'un directeur de projet maître à la fois de la conception et de la coordination des travaux, sous l'autorité duquel sont placées des compétences métier et des compétences informatiques dont il organise le dialogue. Ces entreprises-là, elles aussi, font éclater la MOA : il n'y aura plus d'équipes permanentes, mais des compétences que l'on regroupera à l'occasion d'un projet et que l'on dispersera à la fin du projet. 

Pourquoi ce retour de balancier ? Sans doute des erreurs ont été commises. Certaines MOA se sont comportées, au sein des métiers, comme une "informatique bis" aussi technique, aussi éloignée des besoins que la plus autiste des directions informatiques. D'autres se sont bureaucratisées : ayant appris à maîtriser le formalisme des cahiers des charges, elles s'y sont complu  et ont perdu la compétence métier sans pour autant acquérir une compétence en système d'information. D'autres enfin ont été découragées par la contradiction persistante entre l'ambition de leur mission et son manque de légitimité, notamment en ce qui concerne la maîtrise des budgets informatiques.

Ces erreurs peuvent s'expliquer par un manque de maturité tant du côté de l'entreprise que des MOA elles-mêmes : l'entreprise n'est pas mûre pour accorder aux MOA les moyens de leur mission ; les MOA ne possèdent pas les compétences qui leur seraient nécessaires. Ce manque de maturité se traduit par une organisation boiteuse, des incohérences larvées, l'incompréhension collective de certaines évidences. Tout cela use l'énergie des personnes de bonne volonté, décourage l'acquisition des compétences et retarde la maturation. Il se peut que celle-ci soit dans certaines entreprises indéfiniment ajournée. Alors en effet l'organisation des MOA doit être révisée. 

Le recentrage sur l'informatique ou l'organisation par projets permettent de corriger certains de ses défauts. Cependant ils ont aussi leurs inconvénients. Il faut donc se demander si le retour de balancier n'est pas trop rapide : la remise en question des MOA résulterait non des défauts que présente le principe de cette organisation, mais de l'incapacité de l'entreprise à mûrir un dispositif permettant à ses métiers de maîtriser le SI. Le recentrage sur l'informatique, l'organisation par projets seraient alors des solutions de repli et non les meilleures solutions possibles. 

Nous allons ici examiner les implications de l'organisation par projets. Nous verrons que cette organisation, loin d'impliquer une dissolution de la MOA, fait de façon paradoxale apparaître des exigences auxquelles la MOA doit répondre - et qu'elle confirme donc la nécessité d'équipes qui sont, au sein de chacun des métiers de l'entreprise, responsables de la qualité du SI. 

*

*  *

L'organisation par projets 

Historiquement, les entreprises ont d’abord fait des SI spécifiques. La méthode comportait (1) une réflexion des décideurs au niveau DG, (2) des notes d'organisation, (3) une descente de ces notes dans l'organigramme, (4) le tri des conséquences en termes de SI puis (5) en termes informatiques. L’entreprise était réactive en matière de SI. Dans les plans métier pluriannuels il n'existait pas d'étape concernant le SI, même si l'on savait que pour réaliser le plan il faudrait un SI approprié. Beaucoup d'entreprises en sont encore là. 

Aujourd'hui on observe cependant une autre tendance. Pour faire évoluer l'entreprise, la DG fixe d'abord l'objectif puis monte un projet traitant les divers aspects métier, informatique, formation et organisation. Ainsi le projet devient le mode d'action des dirigeants des grandes entreprises. La réflexion sur le SI est alors proactive. Les métiers prennent le contrôle de leur SI, ce qui implique la mise en place d'une MOA stratégique (au sens de : MOA auprès du comité stratégique de l'entreprise) employant des personnes qui considèrent le métier, son évolution, ses relations avec le SI sur trois à cinq ans.

Toutes les entreprises étaient réactives il y a dix ans ; aujourd'hui, la moitié ou les deux tiers d’entre elles sont devenues proactives. 

Les projets et la MOA

Tout projet part d'un objectif de progrès exprimé par le responsable d'une branche d'activité ou d'une " business line" ; il s’agira d’offrir de nouveaux services ou d’améliorer l'efficacité des services existants. Ce responsable est le client du projet sur lequel il investira quelques M€.

Le client nomme une MOA dont la mission sera de transformer l’objectif de progrès en une réalité pour l'entreprise. Elle aura comme leviers d'action les produits et services commercialisés, les procédures et compétences métier et les outils informatiques. Elle construit un projet métier et elle lance divers chantiers ; pour certains d’entre eux elle fera appel à des maîtrises d'œuvre (MOE) internes ou externes (informatique, formation, communication etc.), pour d'autres elle assurera elle-même la réalisation.

La MOA se manifeste ainsi dans les projets. Or tout projet est par nature limité dans le temps. La chronologie des projets ne coïncide pas avec celle d'une MOA opérationnelle permanente. Il faut alors distinguer la MOA de projet et la MOA permanente, cette dernière se consacrant au maintien du SI en condition opérationnelle, à la maintenance évolutive, à l'expression des besoins au plus près des utilisateurs, à l'animation de la bonne utilisation du SI.

Projets et progiciels

L'existence d'une offre de progiciels a des effets sur la façon d'aborder les projets. L’entreprise aura recours à des progiciels dans les domaines qui ne relèvent pas de son cœur de métier, ce qui représente 80 % du SI ; 20 % des applications concernent le cœur de métier et réclament des fonctionnalités trop pointues pour que le progiciel puisse suffire. La définition de la frontière entre ce que l’entreprise fera faire ou non par des progiciels est un moment important de l'analyse stratégique. Pour être performante, l'entreprise doit être avertie des possibilités qu'offrent les progiciels avant de rédiger le cahier des charges. La modélisation du métier doit tenir compte des modèles supportés par les progiciels.

Le dialogue avec l'informatique prend alors une forme nouvelle. La MOA est souveraine dans le cas du spécifique ; dans le cas du progiciel, elle doit rechercher le compromis qui permet de minimiser les aspects spécifiques. Ca ne peut se faire intelligemment que dans une structure réunie sous la bannière d'un chef de projet, lequel est un MOA.

Analyse des risques

L'organisation par projets présente des risques lorsqu'elle est mal comprise :

1) Dans la sociologie de l'entreprise, le caractère héroïque et noble attribué aux projets peut susciter une inflation de projets qui bousculent le travail opérationnel et gênent son efficacité. Il faut éviter la surcharge mentale, la saturation des agents opérationnels. 

Chaque projet suscite une modification de l'actif de l'entreprise et correspond à un investissement. Si l’entreprise focalise son attention et ses priorités sur cet investissement, elle risque de ne pas accorder assez d'importance à l'exploitation quotidienne ; or un SI, pas plus qu’une ville, ne peut être continuellement en chantier. Il faut donc que la maîtrise d’ouvrage mène une réflexion en amont pour limiter les projets au strict nécessaire. Par ailleurs l’organisation peut exploser si chaque changement du contexte suscite un projet qui à son tour en suscite d'autres. Il faut gérer le portefeuille des applications pour stabiliser les processus de l’entreprise.

2) Il arrive que le directeur du projet soit coincé entre les caprices d'un métier à la demande versatile et inflationniste, et les caprices d'une informatique qui veut faire passer les contraintes et disponibilités de sa plate-forme avant la satisfaction des besoins (ses choix seront différents selon qu’elle a de l'Unix ou du Gecos, que du débit est ou non disponible sur le réseau etc.) La difficulté est encore accrue lorsque l'informatique contrôle de facto le budget du SI. Il est fréquent qu’après avoir choisi le portefeuille de projets la DG attribue une "enveloppe" (en hommes * jours, ce qui incite à négliger les dépenses de formation, de déploiement etc.) à la direction informatique. Les MOA n’ont alors en pratique aucun moyen de contrôler, suivre et maîtriser la réalisation des projets. Or le contrôle doit appartenir au métier, au client. L'informatique doit recevoir le budget qui lui est nécessaire en tant que maître d’ouvrage de la plate-forme technique, mais les budgets des projets doivent être détenus par les métiers. 

3) Confrontés aux difficultés ci-dessus, certains projets cultivent l’isolement en s’affranchissant des contraintes de la cohérence. Ils se mettent ainsi en contradiction avec la notion même de système d'information qui suppose la cohérence des référentiels, la suppression des redondances dans les travaux. Alors on ne construit plus un SI, mais une "chose" qui ne mérite pas le nom de système.

Il faut donc raisonner deux étapes :
- d'une part définir le portefeuille de projets (urbanisme du SI) ;
- d'autre part gérer les projets eux-mêmes.
Pour éviter que l’organisation par projets focalise l'attention sur la seule gestion des projets et incite à négliger l'urbanisme, il faut présenter aux dirigeants une médaille à deux faces : projets d'un côté, urbanisme de l'autre. 

Il faut que la MOA sache présenter les enjeux du SI dans le langage des dirigeants et obtenir d’eux une validation authentique, de sorte qu’ils apportent une valeur ajoutée lors de la conception du SI.

Dans la plupart des entreprises la démarche d'urbanisme reste imprécise. Il est de la responsabilité du DG de la mettre en place.