Migration d’un logiciel ERP : comment acheter aux bonnes conditions ?
Notre rubrique en partenariat avec l’Ordre des avocats de Saint-Etienne – « Les Pages du Barreau » – se consacre, ce mardi, à la migration d’un logiciel ERP. Choisir la solution logicielle adaptée, trouver un intégrateur compétent, négocier le bon prix : ces étapes préalables demandent du temps et de l’énergie. Arrivé au moment de signer le contrat, il est tentant de relâcher ses efforts et de faire confiance à son prestataire pour gérer les imprévus. Mais attention, négliger la rédaction du contrat, c’est courir le risque de fragiliser l’ensemble du projet. Par Me Romain De Zan, avocat.
Changer d’ERP (enterprise resource planning, ou logiciel métier) est de plus en plus souvent un projet à dimension humaine, mais à taille industrielle. Dans un contexte où TPE, PME et ETI externalisent une part croissante de leurs systèmes dans le Cloud, il n’est pas rare de rencontrer des dirigeants ayant connu des migrations douloureuses, voire désastreuses.
Les causes d’échec sont bien connues : besoins mal exprimés, turnover côté client ou prestataire, calendriers irréalistes, promesses commerciales intenables, obstacles opérationnels ou techniques sous-estimés ou encore échec dans la conduite du changement… autant de facteurs qui transforment parfois la livraison d’un ERP en simple soulagement, loin du succès espéré.
Pourtant, un contrat bien négocié et un cahier des charges précis permettent d’éviter nombre de ces écueils. Focus sur quelques réflexes à adopter côté client.
Réflexe n° 1 : exprimer clairement vos besoins
Hors les cas spécifiques de la méthode agile, le cahier des charges reste une étape incontournable et, surtout, à la charge du client. Défini par la norme Afnor NF Z 61-100, le cahier des charges décrit les clauses techniques, qualitatives et administratives du projet. Il devient la base de la proposition du prestataire et, idéalement, une annexe contractuelle.
Premier point d’attention : le client est responsable de l’exactitude et de l’exhaustivité de ses besoins. En l’absence d’une telle définition, des imperfections dans le système livré lui seront en partie imputables. À titre illustratif, la Cour de cassation a jugé qu’un client précisant ses demandes au fur et à mesure du projet était coresponsable des défaillances du système (Cass. Civ. 1, 8 juillet 2003). De même, un client introduisant des demandes nouvelles en dernière phase de projet, même de bonne foi, peut être tenu pour responsable de retards ou d’échecs (CA Douai, 22 juin 2023).
Pour éviter ces écueils, le client doit comprendre ce qui lui est proposé, sans se cacher derrière une éventuelle inexpérience technique ; signaler toute incompréhension au prestataire dès qu’elle survient (CA Versailles, 21 sept. 2023) ; questionner les prestataires sur des points critiques : compatibilité avec l’infrastructure, difficultés prévisibles lors du projet, des tests ou lors de la recette, temps nécessaire pour les tests, etc. Ces étapes garantissent que le prestataire endossera une pleine responsabilité, sauf si le client est un professionnel de même spécialité.
Réflexe n° 2 : anticiper la recette, pour ne pas la subir
Dans le secteur informatique, la recette (validation des livrables) peut être considérée comme implicite en l’absence de formalisation écrite. Or, une recette implicite peut jouer en défaveur du client en cas de défauts ou de bugs. Aussi, le contrat prévoira utilement un cahier de recettes décrivant les critères de validation ; des tests juridiques et RGPD inclus dans les phases de recette ; une obligation de procès-verbal de recette contradictoire, signé par les deux parties.
La jurisprudence illustre l’importance de formaliser cette étape. Par exemple, dans une affaire où un ERP dysfonctionnait avec des modules du client, la cour a jugé que l’absence de PV de recette rendait impossible la preuve de conformité du prestataire (CA Rennes, 12 déc. 2023).
À l’inverse, une cour a estimé que, même en l’absence de recette intermédiaire, le client devait collaborer activement en testant régulièrement les livrables pour permettre au prestataire de corriger les anomalies (CA Toulouse, 27 fév. 2024).
Réflexe n° 3 : négocier les clauses de responsabilité
Les clauses limitant la responsabilité des prestataires sont courantes, mais souvent trop restrictives pour couvrir les enjeux d’un projet ERP. Elles plafonnent en effet fréquemment les indemnisations au montant total du contrat, ce qui est largement insuffisant en cas de pertes d’exploitation significatives. ,La négociation de ces clauses est devenue l’un des piliers de la gestion de risques de ce type de projets.
Le client est donc encouragé à exiger l’augmentation le plafond de responsabilité pour refléter les risques réels ; à supprimer les exclusions des pertes indirectes, si possible ; pour faire accepter ces deux premières modifications, à rappeler au prestataire que sa responsabilité civile professionnelle peut être mobilisée pour couvrir un sur-risque… et à prévoir une limitation de responsabilité corrélée à la garantie couverte par l’assureur.
À noter que dans une affaire récemment jugée (CA Paris, 22 mars 2024), les juges ont validé une clause limitant la responsabilité à la somme perçue sur l’année civile, en précisant que celle-ci n’apparaissait pas nécessairement disproportionnée !
Réflexe n°4 : Intégrer RGPD et cybersécurité dans le contrat
L’article 32 du RGPD oblige le client, en tant que responsable de traitement, à encadrer les mesures de sécurité techniques, organisationnelles et matérielles de tous les traitements de données personnelles de son entreprise. Cela inclut notamment les conditions dans lesquelles le prestataire accède au système d’information (SI) de son client pour développer, tester, maintenir, corriger, mettre à jour les ERP on premise, ou encore les conditions dans lesquelles sont réalisés les flux de données entre le SI du client et les bases de données en Cloud, alimentant le logiciel ERP.
Afin de se conformer aux exigences du RGPD et de la Loi Informatique et Libertés de 1978, le client veillera à conclure une convention de sous-traitance RGPD dès le début du projet, le liant à son prestataire, en parallèle du contrat commercial ; à mentionner ses exigences claires sur les conditions d’accès à distance du prestataire pour tests ou maintenance ; à opérer un contrôle préalable des mesures de sécurité, en s’appuyant sur le guide de la Commission nationale de l’informatique et des libertés (Cnil), mis à jour en mai 2024.
Avec 4 milliards de cyberattaques commises par des intelligences artificielles (IA) chaque jour dans le monde, sécuriser les connexions et les données dès le commencement d’un projet est impératif.
En résumé, un projet ERP ne se résume pas à un simple contrat technique. Il engage la responsabilité du client autant que celle du prestataire. L’avocat en droit du numérique joue un rôle clé pour structurer cette relation et garantir le succès du projet. Car, en matière d’ERP, un contrat bien négocié est souvent la meilleure assurance.
