Les enjeux juridiques de l'ERP

L´Enterprise Ressource Planning (ERP) est un outil de gestion très puissant conçu dans les années 80 pour permettre à des groupes de taille mondiale de disposer d´un système d´information unique. Plus récemment, des PME ont intégré ce type d´outil dans des versions adaptées à leur taille. Les ERP comportent, en standard, les principales fonctionnalités nécessaires à la gestion d´une entreprise. Les gains en cohérence et en productivité sont importants, mais la mise en oeuvre d´un tel outil et son apprentissage sont des phases délicates pour une société de taille moyenne.

Référentiel de départ : le cahier des charges

Un progiciel ne peut répondre dans sa version standard à l´intégralité des besoins d´une entreprise. Il est essentiel de formaliser très précisément l´expression des attentes sous forme de cahier des charges, c´est le premier document qui servira de référentiel. Si le client n´a pas rédigé de cahier des charges, il lui appartient de définir au moins ses besoins et les objectifs à atteindre (cf. Cass. Com. 04/02/1997). Un arrêt de la chambre commerciale de la Cour de cassation, certes ancien, (5.12.89/JCP 90,IV p 45) estime que le cahier des charges est une condition pour que l´acheteur puisse se prévaloir d´une non-conformité du système à l´usage attendu.Ce cahier des charges doit être le plus précis et concret possible. En effet, plus il est général et plus il est d´interprétation extensive et par là même dangereux pour l´intégrateur et pour le client. Le fait que le cahier des charges ait été rédigé par le client ne dé-responsabilise pas l´intégrateur qui, en tout état de cause, est tenu par son obligation générale de conseil et devra répondre sur la faisabilité de ce qui lui est demandé. Ce devoir de conseil est fréquemment rappelé par les tribunaux, c´est un cas classique de mise en jeu de la responsabilité contractuelle de l´intégrateur sur le fondement de l´article 1147 du code civil (cf. Cass. Com 11/01/1994).

L´intégrateur peut difficilement apprécier a priori l´adéquation de l´ERP au besoin du client. C´est pourquoi il est prudent de commencer le projet par mettre en évidence sa cohérence et ses ambiguïtés dans le cadre d´une phase préalable dite "phase d´étude d´adéquation" ou "gap analisys". Durant cette phase, l´intégrateur devra veiller à éclairer son client sur les aspects implicites que peut comporter le cahier des charges. Par exemple, une fonction ou un résultat intermédiaire non exprimé dans le cahier des charges, mais indispensable à l´obtention d´un résultat prévu dans ce même cahier des charges (qui doit impérativement être annexé au contrat).

L'évolution du référentiel vers les Spécifications Fonctionnelles Générales

L´intégrateur analysera, dans une seconde phase, les besoins du client de façon détaillée pour réaliser des Spécifications Fonctionnelles Générales (SFG) qui conduisent généralement à une évolution du périmètre fonctionnel initial du projet. Ce document validé par le client doit aboutir à l´abandon du cahier des charges en tant que référentiel de réalisation au profit des SFG et ce dans la mesure où les Parties sont d´accord sur ce nouveau référentiel. A défaut, le Cahier des Charges fera foi.

Les modifications contractuelles

Les analyses conduisent souvent à révéler des fonctionnalités plus riches que prévues à l´origine, de nouvelles fonctionnalités ou des améliorations. La question de savoir si elles étaient prévisibles ou non est souvent source de discussions très vives en cours de projet. Le contrat doit prévoir un mécanisme d´arbitrage pour permettre aux parties de trouver une solution consensuelle qui devra faire l´objet d´un avenant au contrat initial.

La conduite de projet par l'intégrateur et la conduite du changement par le client

L´intégrateur accompagne les équipes internes du client pour concevoir et réaliser avec elles l´applicatif cible en leur apportant son expertise et son savoir-faire méthodologique. Il doit mettre en place l´organisation capable d´apporter une visibilité dans le suivi du projet, une anticipation des difficultés et la mise en oeuvre de procédures d´alerte. Il lui appartient de coordonner les équipes du projet pour permettre une anticipation des besoins de charge et un contrôle du reste à faire et des écarts.De son côté, le client doit être vigilant à ne pas sous-évaluer la charge de travail de ses équipes internes, ce qui est une cause fréquente de dérive d´un projet d´intégration d´ERP, et à collaborer activement, dans un véritable esprit de partenariat, au succès du projet (cf. TC Dijon 21/01/2002, à propos de la mise en oeuvre d´un ERP : "les opérations d´adaptation et de paramétrage supposent une restructuration du système et impliquent une collaboration étroite entre le fournisseur et le client", la Cour de Cassation retient cette même obligation à propos d´une société qui se refuse, sans motif précis, à valider les applications livrées par l´intégrateur, cf. 1ère Civ. 02/10/2001).

La conduite du changement nécessite que le client instruise les questions d´ordre politique et organisationnel, mette en place les instances de reporting interne afin que les informations soient transmises au niveau où elles doivent l´être, établisse le tableau de bord des enjeux et des choix et décisions en découlant au début du projet et le mette à jour au fur et à mesure de son avancement, élabore et mette en oeuvre les plans de communication interne et éventuellement externe, arrête, en concertation avec l´intégrateur, un plan de formation approprié. Ainsi à l´obligation de conseil de l´intégrateur est contrebalancée par l´obligation de collaboration et d´implication du client (cf. CA Paris 20/12/1990 et 27/01/1994).

Le déclenchement des alertes

Les difficultés qui peuvent surgir en cours de projet sont nombreuses. Beaucoup d´entre elles peuvent être résolues si une procédure d´alerte est déclenchée au bon moment et au bon niveau hiérarchique. L´obligation d´alerte est clairement une obligation de l´intégrateur. Les cas les plus typiques portent sur les retards de livraison dont les causes sont souvent multiples mais qui peuvent être traités dans l´intérêt de toutes les parties au projet si le problème est remonté assez tôt. Il en est de même des problèmes relationnels qui peuvent se faire jour.Une autre situation fréquemment rencontrée est celle où l´intégrateur se voit progressivement assumer les fonctions de maître d´ouvrage en plus de celles de maître d´oeuvre (expression d´un besoin, développement d´une fonction non demandée, réalisation des tests...) ou le contraire. Face à ce risque, il est nécessaire de définir dès l´élaboration du contrat les tâches revenant à chacune des parties. A défaut, naîtront une confusion des rôles, une incompréhension et un manque de communication qui peuvent amener un projet novateur à l´échec et au contentieux.