Le cahier des charges, une notion dépassée, à l’occasion de la mise en place d’un ERP ?
Un ERP est sur le plan strictement juridique, un progiciel (1). En dehors des textes régissant les droits respectifs des auteurs de logiciels et des utilisateurs dans le cadre de licences d’utilisation de progiciels, aucune loi spécifique ne régit les relations entre les parties à un contrat d’intégration de progiciels dans un système d’informations. Ce type de contrat relève du droit commun contractuel et la jurisprudence est venue préciser les responsabilités respectives du client et du fournisseur.
L’inadéquation de la notion traditionnelle de cahier des charges
Deux grands principes (2) se sont dégagés de manière constante au fil des années, à savoir qu’en matière de progiciel, il appartient au client de vérifier l’adéquation de celui-ci à ses besoins, la documentation du progiciel lui servant de cadre de référence (3). e plus, le client doit exprimer ses besoins réels et ses objectifs dans un cahier des charges (4). A cet égard, il a été jugé que les résultats à attendre sont ceux qui sont définis dans le cahier des charges (5).
La jurisprudence a, également de manière constante, rappelé que le fournisseur avait de son côté une obligation de conseil et de mise en garde vis-à-vis de son client. Dans le cadre de cette obligation de conseil et de mise en garde, il a été jugé qu’il devait exiger de son co-contractant qu’il formule le plus précisément possible ses objectifs, les torts étant souvent partagés lorsque le cahier des charges réalisé par le client n’est pas suffisamment précis mais que le fournisseur de son côté n’a pas mis en garde le client et n’a pas sollicité de précisions (6).
Cette jurisprudence, constante et ancrée dans les esprits n’est cependant pas vraiment adaptée en matière d’ERP même si ces derniers demeurent juridiquement des progiciels. En effet, leurs ampleur et richesse fonctionnelle d’une part, leur potentiel de paramétrage d’autre part, ne permettent pas à un client de vérifier préalablement à la souscription du contrat de licence et au contrat d’implémentation et de mise en œuvre, son adéquation parfaite à ses besoins. La
vérification d’une telle adéquation précise et exhaustive, s’inscrit dans le cadre d’un véritable projet nécessitant :
– d’analyser les besoins et procédures internes au client ;
– d’identifier les écarts par rapport à l’ERP ;
– de vérifier si ces écarts peuvent être traités par un paramétrage ou s’ils doivent être traités par des développements spécifiques.
Une telle démarche constitue un projet à lui tout seul qui s’inscrit dans la durée et ne peut être réalisé préalablement au choix.
Par ailleurs, en décidant de s’équiper d’un ERP, le client choisit essentiellement un concept, celui de progiciel de gestion intégrée, plutôt qu’un produit particulier. Bien entendu, il choisira l’ERP qui lui paraît globalement le mieux adapté à ses besoins parmi ceux offerts sur le marché, mais il sait par avance qu’aucun de ces produits ne sera strictement conforme à ses besoins et qu’il devra soit s’adapter au progiciel et modifier ses propres procédures internes, soit combler les écarts par des développements spécifiques.
La réalisation d’un cahier des charges précis, exhaustif et détaillé n’est donc plus un élément moteur dans le choix du produit lui-même, mais le deviendra lors de son implémentation. Le cahier des charges tel qu’il était entendu par la jurisprudence dans le cadre des progiciels plus classiques, devenant en réalité l’analyse réalisée conjointement par les parties au cours du projet d’intégration de l’ERP. Demander en effet au client de réaliser un cahier des charges complet exhaustif et détaillé de l’ensemble de ses besoins, sachant que l’ERP est destiné à couvrir tous les domaines de l’entreprise, n’est pas plus réaliste que de lui demander de valider l’adéquation de la totalité du produit à ses besoins avant de s’engager contractuellement.
Le recentrage du cahier des charges aux besoins fondamentaux du client
Dans ces conditions, le cahier des charges peut être recentré sur les besoins fondamentaux du client. Il peut prendre diverses formes telles qu’un questionnaire ou un appel d’offres. Ainsi, les éditeurs peuvent se voir demander d’identifier les écarts de leurs produits par rapport aux fondamentaux du client aux fins de lui permettre d’opérer un choix suffisamment éclairé.
Il reste bien entendu important pour le client de bien cerner et de bien définir les besoins fondamentaux, la réponse de l’éditeur ne l’engageant que dans le cadre de ce périmètre. C’est au client qu’il appartient donc de vérifier si les process et les modalités d’organisation interne, auxquels il n’entend pas renoncer pour s’adapter au progiciel, sont clairement mentionnés. Pour autant, il ne peut pas lui être reproché de ne pas avoir décrit l’ensemble de ses besoins y compris ses besoins non fondamentaux. L’analyse précise des besoins sera réalisée dans le cadre du prototypage. En effet, seul un prototype ou une maquette permettent au client et au fournisseur d’identifier la totalité des écarts, ceux à combler et ceux auxquels il faut renoncer.
Lors de la conclusion du contrat, les parties sont généralement d’accord sur la démarche de l’implémentation de l’ERP et sur ses contraintes. Néanmoins en cas d’échec et de litige, il n’est pas rare de voir resurgir les vieux démons, chacune des parties tentant de s’abriter derrière la jurisprudence classique et reprochant à l’autre soit un cahier des charges incomplet ou non exhaustif, soit de ne pas avoir validé préalablement le progiciel à ses besoins, soit un manquement à l’obligation de mise en garde et de conseil.
En l’absence de jurisprudence adaptée à ces nouveaux produits, il est donc impératif de préciser de manière expresse, dans le contrat, la démarche d’implantation de l’ERP sur laquelle les parties sont généralement d’accord, et le renvoit à de plus amples développements dans le cadre d’un plan assurance qualité (PAQ) ultérieur.
Or, si le PAQ intègre souvent des considérations juridiques, qui n’y ont d’ailleurs pas toujours leur place, il n’a pas vocation à gérer le périmètre des responsabilités. Il est donc indispensable que soit par exemple clairement précisé que le cahier des charges ne constitue qu’une description des besoins fondamentaux et n’a pas de caractère exhaustif. Cette précision permet ainsi au client de reporter à la phase d’analyse, l’identification exhaustive de ses besoins, et à l’éditeur de ne s’engager sur un prix définitif qu’à l’issue de cette analyse, en fonction des développements spécifiques à réaliser, et ce, dans le cadre d’un engagement commun, de tout mettre en œuvre pour limiter les développements et rester au plus près du concept progiciel.
Contrairement à ce que l’on pourrait penser au regard de la jurisprudence traditionnelle en matière de progiciels, cet engagement commun ne va pas de soi, et la meilleure des protections demeure une rédaction appropriée des termes du contrat.
[1] Cf. Isabelle Demnard-Tellier, « La gestion juridique de la mise en place d’un ERP : les temps révolus de la maîtrise d’ouvrage, maîtrise d’œuvre », L’Informatique Professionnelle n° 185, Juin/Juillet 2000
[2] Pour une étude, cf. Alain Bensoussan, « Informatique, Télécoms, Internet », Editions Fr. Lefebvre 2001, n° 829 et s.
[3] TC Paris, 16 décembre 1981, Expertises 1982 n° 31
[4] CA Toulouse, 5 mai 1997, JURISDATA n° 041319 ; CA Paris, 8 juillet 1981, Expertises 1981 n° 32
[5] TC Paris, 28 février 1984, Expertises 1984 n° 61
[6] CA Paris, 7 avril 1993, Expertises 1993 n° 166