Changement d’un logiciel métier dans les entreprises : quelles précautions juridiques prendre ?

L’actualité, et notamment les difficultés financières rencontrées par l’enseigne GIFI en février 2024[1], nous rappelle qu’un changement d’ERP est susceptible d’emporter des conséquences majeures pour les entreprises, tant sur le plan organisationnel que sur le plan économique.

Les progiciels de type ERP (« Enterprise Ressource Planning » ou « Progiciel de gestion intégré ») ou encore CRM (« Customer Relationship Management » ou « logiciel de relation client ») jouent un rôle majeur pour l’entreprise ayant décidé de les adopter : ils permettent – en théorie – d’accroître sa productivité et sa compétitivité sur un marché donné en assurant un pilotage optimisé de ses ressources.

De facto, ce type d’outil est susceptible d’appréhender plusieurs fonctions vitales d’une organisation telles que la gestion des commandes et des stocks, la gestion des fournisseurs et des clients ou encore la facturation.

Pour autant, toute implémentation ou tout changement d’un progiciel de ce type impose, pour l’entreprise, une analyse préalable particulièrement poussée de ses besoins afin d’éviter toute difficulté, friction et même litige lors de la phase de déploiement.

Il s’agit donc d’anticiper au plus tôt afin d’éviter toute déconvenue ultérieure qui pourrait être préjudiciable au fonctionnement à la rentabilité de l’entreprise.

Le présent article à pour objectif de dresser une liste synthétique – et non exhaustive – des points à anticiper avant de se lancer dans un tel projet.

[1] GIFI a en effet subi de lourdes pertes financières en 2023 du fait d’une migration informatique vers un nouvel ERP jugée « très douloureuse ». Source : https://www.bfmtv.com/economie/entreprises/gifi-en-difficulte-a-cause-d-une-migration-informatique-douloureuse_AV-202403010079.html.

I. L’expression des besoins et le cahier des charges du client

Bien naturellement, amorcer l’implémentation ou le changement d’un logiciel métier impose une analyse préalable de la situation existante.

Idéalement, un audit des systèmes en place permet de dresser un état des lieux des outils, de leurs performances et des éventuelles difficultés rencontrées (coûts trop élevés ; système peu évolutif ; failles de sécurité etc.).

Cet audit sera à la base de la rédaction d’une expression de besoins puis d’un cahier des charges venant détailler clairement :

Les attentes de l’entreprise cliente, notamment en termes de contraintes et d’objectifs poursuivis ;
Les spécifications techniques et fonctionnelles énonçant les caractéristiques techniques relatives aux exigences opérationnelles de l’entreprise ;
Les échéances clés et le budget qu’elle entend consacrer au projet ;
Le niveau d’engagement attendu du futur fournisseur. A ce titre, certains engagements juridiques seront opportunément insérés et clarifiés dans ces documents (respect des niveaux de services et pénalités, obligation de moyens/résultat, réversibilité des données etc.).

Ce document sera rédigé le plus tôt possible, directement par l’entreprise (en impliquant les juristes ou les cabinets de conseils juridiques externes), puis sera communiqué aux fournisseurs présélectionnés ; il constituera donc le socle du projet permettant aux fournisseurs de se prononcer sur la faisabilité et les coûts associés en exerçant, dès cette phase, leur obligation de conseil et d’information précontractuelle.

Mais il sera aussi une sorte de « référentiel » tout le long du projet, en étant idéalement – ou obligatoirement ? – annexé au contrat de licence, de développement ou d’intégration du progiciel. D’où l’importance d’être extrêmement méticuleux dans sa rédaction, le juge n’hésitant pas, en cas de difficultés, à sanctionner le client ayant insuffisamment exprimé et détaillé ses besoins[1].

[1] V. not. Cour d’appel d’Aix-en-Provence, 8^e chambre b, 5 octobre 2017, n° 15/20138.

II. L’analyse juridique de la proposition commerciale du prestataire informatique

La proposition commerciale du fournisseur ou de l’éditeur est censée venir répondre à l’expression de besoins et, éventuellement, l’affiner ou la recadrer.

Tout comme le cahier des charges et/ou l’expression de besoins du client, la proposition commerciale joue un rôle central sur le plan juridique car elle permet au fournisseur de clarifier certains aspects liés au budget, au respect des obligations inscrites et des échéances, à la sous-traitance et, plus largement, à la faisabilité du projet.

Là encore, une vigilance particulière devra être apportée quant à la documentation juridique qui pourrait être associée à la proposition commerciale (conditions générales de vente notamment) qui pourraient, si elles étaient validées par le client à l’occasion de la signature de la proposition commerciale, devenir opposables à ce dernier et atténuer considérablement les engagements juridiques du prestataire.

De ce fait, il sera opportun de faire vérifier cette proposition commerciale par un juriste ou un avocat avant sa validation.

III. La négociation du contrat avec l’éditeur et/ou le fournisseur de services

Cette validation du projet d’ERP sera généralement corrélée à l’établissement par les parties d’un ou plusieurs contrats, en fonction des prestations confiées et à réaliser :

Contrat de licence permettant l’utilisation de l’ERP : il conviendra d’y détailler les fonctionnalités du progiciel, sa notice d’utilisation, ses prérequis techniques ou encore la volumétrie supportée (nombre d’utilisateurs ; profil d’utilisateur ; taille limite des données). Les modalités d’hébergement pourront y être spécifiées (SaaS ou On Premise par exemple).
Contrat d’intégration venant cadrer l’implémentation de la solution sur le système d’information de l’entreprise. Il devra ainsi déterminer les modalités techniques et opérationnelles de l’intégration ainsi que le(s) délai(s) associé(s). Le sujet de la migration des données devra y être impérativement explicité (modalités de transfert des données existantes sur le nouvel outil ; procédure de mise en place de la bascule etc.).
Contrat de développement (si la solution est clairement personnalisée – et non simplement paramétrée – afin de répondre aux besoins spécifiques du client) : ici, un focus particulier devra être effectué concernant les droits de propriété intellectuelle portant sur les développements spécifiques.
Contrat de maintenance ou de tierce maintenance applicative : devront ici être développés les niveaux de services (« SLA » en anglais), document dont l’objet est de déterminer les obligations du prestataire informatique en cas de dysfonctionnement du progiciel. Une hiérarchie entre les différents types d’anomalies devra être, associée à des délais d’intervention très précis du prestataire. Des pénalités seront en outre envisagées en cas de non-respect de ces SLA. Ce contrat pourra aussi être étayé par des PAQ (Plan d’assurance Qualité) et des PAS (Plan d’Assurance Sécurité).

En tout état de cause, ces différents contrats devront être clairs quant aux droits et obligations des parties en privilégiant, autant que possible pour l’entreprise, une obligation de résultat sur tout élément déterminant, quantifié ou quantifiable, et indiqué comme tel dans le cahier des charges. Ce dernier devra en outre être annexé au(x) contrat(s) comme indiqué précédemment.

De même, ils devront prévoir les modalités de mise en œuvre de la réversibilité, phase qui envisagera la possibilité pour l’entreprise cliente de récupérer aisément l’intégralité de ses données en fin de contrat. Prévoir ce point permet d’éviter au client toute situation de dépendance technologique – et économique ! – vis-à-vis de son prestataire, situation qui serait susceptible de le mettre dans une posture pour le moins délicate s’il souhaite changer ultérieurement de fournisseur.

Enfin, chaque grande étape du projet (intégration, paramétrage, migration des bases de données etc.) devra faire l’objet de procédures de tests puis de recettes. Ces dernières sont indispensables car elles permettent de vérifier que le progiciel fonctionne correctement et qu’il répond, point par point, au cahier des charges.

Quoiqu’il en soit, ces contrats devront être âprement négociés afin d’éviter, pour l’une des parties, de se voir imposer par l’autre des clauses « standards » et inadaptées.

**************************

Les dérives, malheureusement fréquentes dans les projets informatiques, résultent bien souvent du non-respect de ces principes de base : il importe donc pour l’entreprise de ne pas négliger le temps à passer sur les étapes préalables au lancement d’un tel projet en se faisant accompagner par des équipes pluridisciplinaires et spécialisées (informaticiens/DSI, DAF, juristes etc.).