Les caractéristiques essentielles du contrat ERP

Les enjeux juridiques de l’ERP

Cahier des charges, devoir de conseil, responsabilités contractuelles de l´intégrateur… autant de points qu´il convient de sécuriser d´un point de vue juridique, de préférence en amont de la mise en place d´un ERP.

Il sera nécessaire d’être précis dans la formulation des besoins : améliorer le délai de livraison des clients, de l´information, harmoniser un système informatique préalablement désintégré, etc.

Pour installer un PGI (Progiciel de gestion intégrée ou ERP, Enterprise Resource Planning), il faut faire un choix réfléchi du progiciel et la formulation précise de ce que l´on en attend. L’ERP ne doit pas être confondu avec le contrat d’infogérance, dont l’objectif est d’externaliser tout ou partie du système informatique de l’entreprise, alors que l’ERP reste d’utilisation interne.

Généralités

Définitions

L’E.R.P désigne généralement un logiciel standard, paramétrable, qui gère les ressources humaines, la gestion, les achats, la finance d’une entreprise… Ce type de logiciel a vocation à gérer tous les secteurs d’activité et toutes les fonctions de l’entreprise, l’adaptation aux besoins de l’entreprise étant réalisée par paramétrage.

Historiquement, le premier ERP a été conçu par la société Allemande SAP (signifiant ‘Systems Applications & Products in Data Processing’).

Ce logiciel répond à un besoin de cohérence, s’agissant d’une application unique, à l’inverse de l’utilisation de nombreux applicatifs et bases de données différents. L’investissement financier repose essentiellement sur le paramétrage du logiciel.

Un logiciel ERP n’est pas un logiciel spécifique, et il faut prévoir les conséquences juridique d’un dépassement des objectifs, comme les éventuelle carences du programme.

Dans tous les cas, le progiciel devra privilégier souplesse et évolutivité. Sa capacité d´évolution est primordiale, qu´il s´agisse de ses fonctionnalités ou de son accès aux nouvelles technologies (intégration d´images, Internet mobile..).

Négociation et information

La négociation de ce type de contrat est délicate. Il convient de réaliser d’abord une étude de faisabilité approfondie (contrat d’audit). Il faut vérifier la capacité de l’éditeur à accompagner l’entreprise dans la durée et à partager avec elle son expertise sur le métier.

Il faut savoir que certains des enjeux de l’entreprise ne pourront être atteints, si elle adopte l’ERP, qu’à la condition de modifier la façon dont elle aborde son métier. Il faut donc que la maîtrise d’ouvrage de l’éditeur soit encore plus forte que lorsque l’on conçoit un logiciel spécifique, car de nombreuses demandes d’adaptation de l’ERP vont s’exprimer.

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 analysis ». 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).

La collaboration entre les parties est essentielle . Le client aura un devoir de collaboration renforcée. L’étape de la formation et de la prise en main de l’outil est primordiale.

Il est essentiel de formaliser très précisément l’expression des attentes, besoins et objectifs à atteindre sous la forme d’un cahier des charges.

Avant de conclure un contrat ERP, il conviendra de prendre soin de vérifier si l’Editeur est capable d’accompagner la société dans la durée.

Lorsqu’une entreprise achète un ERP, elle n’a pas à payer seulement les licences : elle doit aussi s’associer à l’éditeur en tant que consultant.

Le contrat

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. CCass. Com., 04/02/1997). Un arrêt de la chambre commerciale de la Cour de cassation (CCass. Com., 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).

Une fois rédigé, après discussion avec l’éditeur, ce cahier des charges des transforme en 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 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 parties

Le Maître d’ouvrage (client)

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.

Le Maître d’œuvre (éditeur/intégrateur)

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.

Il est aussi à noter que l’intégrateur et l’éditeur peuvent être deux personnes différentes. Il faudra donc envisager leur devoir de collaboration entre eux.

Le coeur du contrat

Un projet ERP peut créer deux structures contractuelles :

– soit une relation bipartite entre le client et le prestataire, avec un contrat « clé en main »,

– soit une architecture plus complexe, associant des contrats de licence, de maintenance, de développement spécifique, de consulting,…

Dans ce cadre, on peut envisager un contrat de licence cumulé avec un contrat de paramétrage, ou avec un contrat d’étude au préalable complété par un contrat d’intégration.

Dans tous les cas, de nombreux écueils sont à préciser : le contrat devra préciser toutes les options éventuellement à créer spécifiquement pour le client, le système doit demeurer  » maintenable « , le client doit retrouver ses données après passage du logiciel, il doit aussi pouvoir conserver le format des données, si la maintenance s’arrête, il faut prévoir la migration vers un nouvel ERP.

Au niveau de la validation et de la réception des étapes, il faut prévoir des échéances et procéder étape par étape afin de valider chaque fonctionnalité.

Un contrat de formation spécifique doit aussi être élaboré ou tout du moins prévu (recours à un prestataire extérieur).

En pratique, le contrat devra prévoir les différentes étapes :

– Etude préalable et audit de l’existant,

– Formation des  » key users « ,

– Analyse des besoins, concrétisés dans le  » Gap Analysis  » afin de comparer les besoins à fournir par le logiciel ERP par rapport à l’ancien progiciel

– Définition des besoins spécifiques,

– Elaboration des Spécifications,

– Paramétrage/prototypage,

– Réalisations techniques,

– Tests,

– Recette provisoire,

– Formation des utilisateurs finaux,

– Reprise des données existantes,

– Mise en production,

– Assistance au démarrage,

– Recette définitive.

Le déroulement du projet

En cas de présence d’équipes techniques chez 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. CCass, 1ère Civ., 02/10/2001).

Le client doit :

– instruire les questions d´ordre politique et organisationnel,

– mettre en place les instances d’information interne afin que les informations soient transmises au niveau où elles doivent l´être,

– établir le tableau de bord des enjeux et des choix et décisions en découlant au début du projet et le mettre à jour au fur et à mesure de son avancement,

– élaborer et mettre en oeuvre les plans de communication interne et éventuellement externe,

– arrêter, 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 généralement 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.

Evolution

L’adoption du logiciel ne représente pas un seul projet. Le fournisseur publiera des versions successives, différentes les unes des autres, et le passage d’une version à la suivante peut constituer un véritable second projet. Lors de la sortie d’une nouvelle version, il faut en effet :

– faire l’inventaire de ce qui est proposé, évaluer ce qui est intéressant, choisir ;

– évaluer le coût des travaux de reconception ;

– évaluer l’effet du changement de version sur tout ce qui se trouve à la périphérie du progiciel, et qu’il impacte.

Toutefois, ces nouvelles versions peuvent n’intéresser que partiellement l’entreprise.

Ainsi, une véritable structure du projet doit être mise en œuvre, y compris pour l’adoption des versions nouvelles.

Le choix d’un ERP implique une orientation de plusieurs années pour l’entreprise. D’où l’importance fondamentale à la fois du contrat initial, et des procédure d’évolution de ce dernier.

Formation du personnel

Il faudra envisager deux types de formation :

– la formation des  » key users « , personnel de l’entreprise chargé de collaborer avec l’intégrateur pendant la mise en place de l’ERP,

– la formation des salariés après installation du logiciel.

Ces deux types de formations doivent faire l’objet de deux contrats séparés.