Par JDNet
Solutions (Benchmark Group)
URL : http://www.journaldunet.com/solutions/0211/021120_juridique.shtml
Lancer l'impression
La mise en uvre dans une entreprise d'un
progiciel d'ERP (Enterprise Resources Planning) ou Progiciel de Gestion
Intégré (PGI), entraîne des changements de méthode
considérables pour les utilisateurs finaux. Cette conduite du changement
doit être particulièrement préparée et suivie,
au risque de générer un refus des utilisateurs et un échec
du projet.
Selon une étude récente et à
titre d'exemples, 31 % des projets ERP seraient abandonnés, dans
189 % des cas les budgets prévus seraient dépassés
et dans 222 % les délais ne seraient pas tenus (Matinée
A.P.P. sur les ERP). Bien entendu, ces chiffres ne précisent
pas qui du client ou des prestataires sont responsables.
De ces constats, plusieurs recommandations générales
peuvent être données.
- les projets ERP ne doivent pas être
des projets " informatiques " et être gérés
uniquement pas la Direction des Systèmes d'Information. Ils doivent
notamment être lancés, suivis et soutenus par la Direction
Générale et toutes les directions ;
- le client doit tout particulièrement
définir la nature et le périmètre du projet notamment
aux niveaux technique et géographique, définir ses objectifs
en termes financiers et de délais (forfait, régie, régie
plafonnée, délais impératifs ou non) ;
- les utilisateurs doivent être impliqués
dans le processus d'implémentation. Plusieurs projets d'ERP ont
ainsi échoué car les utilisateurs n'ont découvert
le produit quasiment qu'au moment de la réception finale. C'est
la raison pour laquelle des projets ERP doivent s'accompagner d'une communication
interne (voire externe) permanente ;
- la phase préparatoire ou pré-contractuelle
(étude d'opportunité, élaboration d'un cahier des
charges, appel d'offres, choix du ou des prestataires, négociation
du ou des contrats) est essentielle dans les projets ERP. Tel n'est pas
toujours le cas. Pourtant, ces projets font intervenir de nombreuses équipes,
sur différents sites et/ou pays, avec des cultures d'entreprises
et des méthodes de travail souvent divergentes.
L'organisation (Comités de pilotage
et de suivi, Plan d'Assurance Qualité, etc.) et les procédures
d'avancement du projet (réceptions et validation de chaque étape
ou des lots) doivent également être précisément
définies puis appliquées.
Pour chacune de ces raisons, les projets ERP
sont particulièrement sensibles.
Mais quelle structure
contractuelle retenir ?
Deux logiques
contractuelles s'opposent généralement ; les clients souhaitant
une relation bipartite entre un maître d'ouvrage et un maître
d'uvre et un contrat " clé en mains " ; les prestataires
(éditeurs, cabinets de conseil, constructeurs) préférant
une architecture plus complexe associant des contrats de licence, de maintenance,
de vente, de prestations et de conseils. En fonction du projet et du client,
ces différents prestataires peuvent également se positionner
l'un vis-à-vis des autres comme cotraitants, solidaires ou conjoints,
ou sous-traitants.
A ce titre, les notions
de maîtrise d'ouvrage et de maître d'uvre sont généralement
utilisées. Mais que recouvrent-elles ?
1 Le Maître
d'ouvrage
Le maître d'ouvrage est globalement celui pour qui le projet
informatique est réalisé.
Il doit clairement définir ses besoins, leur nature et leur étendue
dans un " cahier des charges ".
En principe,
le maître d'ouvrage est responsable de la définition du "système".
Cependant, il peut confier cet aspect à un tiers par contrat (l'assistant
à maîtrise d'ouvrage).
La jurisprudence
considère que le maître de l'ouvrage :
- doit apporter toutes les précisions voulues dans la définition
de ses besoins et dans l'expression des contraintes d'exploitation (CA
Paris, 18 juin 1985, Gaz. Pal. 1986, I, p. 72) ;
- doit définir, eu égard à son organisation et ses
problèmes spécifiques, tous ses besoins réels et
les objectifs et performances à atteindre (
), définir
de façon précise, tous les éléments susceptibles
d'affecter la solution proposée (CA Paris, 15 juin 1990, Juris-Data
n° 22939 et CA, Toulouse 5 mai 1997, Juris-Data n° 041319) ;
afin de permettre aux prestataires de s'engager en toute connaissance
de cause et de limiter les "dérapages".
Le maître d'ouvrage
doit également :
- choisir et lancer les moyens nécessaires pour le projet ;
- préciser un délai de mise en service opérationnel
qui soit compatible avec les moyens mis en uvre ;
- communiquer au maître d'uvre tous les éléments
sur le contexte général de l'opération, les données
préexistantes, les contraintes et difficultés particulières
;
- anticiper les conséquences de la mise en place du système
sur son organisation ;
- procéder aux différentes réceptions découlant
de l'opération ;
- assurer l'exploitation restant à sa charge.
2 Le Maître
d'uvre
Le maître d'uvre est "la personne physique ou
morale qui, pour sa compétence technique, est chargée par
le maître d'ouvrage de diriger et de contrôler les travaux
et de proposer la réception et leur règlement" (AFNOR,
Norme P03001) ou "se charge de la mise en place des systèmes
sur le plan technique" (Parisot).
La qualification de maître d'uvre ne peut être retenue
que s'il dispose d'une autonomie dans ses choix techniques et qu'il pilote
de manière effective le projet.
Le maître d'uvre doit proposer à son client la solution
la mieux adaptée à ses besoins, en lui communiquant toutes
les informations nécessaires avant et durant le projet et, si nécessaire,
en le mettant en garde. Il doit également piloter, animer, coordonner,
planifier et suivre le déroulement du projet, assister aux opérations
de réception et corriger les " écarts " constatés.
Enfin, en fonction des projets, il peut être utile de faire une
distinction entre la maîtrise d'uvre de conception, la maîtrise
d'uvre de réalisation et d'intégration.
Trop souvent, le
choix de la structure contractuelle n'est abordé par les clients
utilisateurs qu'après la sélection du ou des prestataires.
Pourtant, elle impacte directement les obligations de chacune des parties.