ERP vu par un juriste : quelles ERP vu par un juriste : quelles responsabilités ? quels acteurs ? responsabilités ? quels acteurs ? quels contentieux ?quels contentieux ?

Me André Meillassoux, Avocat,ATM Avocats, Parisameillassoux@atmavocats.comhttp://www.atmavocats.com

Sommaire : Introduction

1.1. Definition de l’ERPDefinition de l’ERP

. L’ERP, qu’est-ce que c’est ? Distinctions. . L’ERP, qu’est-ce que c’est ? Distinctions. Caractéristiques. Utilité. Objectifs.Caractéristiques. Utilité. Objectifs.

2. « Sociologie » de l’ERP2. « Sociologie » de l’ERP

. Pourquoi en parle-t-on ? « Equation », conflits ?. Pourquoi en parle-t-on ? « Equation », conflits ?

. Les problématiques : les nouveaux mots,. Les problématiques : les nouveaux mots,

. Où va t-on ? Vers quels problèmes ? . Où va t-on ? Vers quels problèmes ?

(introduction) . L’ERP, qu’est-ce que c’est ? Définition « Entreprise ressource planning » = « Progiciel de

Gestion Intégrée » Tentative de définition synthétique : C’est une application informatique :

. standard,

. couvrant l’ensemble des fonctions de gestion de l’entreprise

. gérant une base de données unique

On construit les systèmes d’information autour d’un noyau standard, plutôt que créer des systèmes spécifiques

Définition développée. Caractéristiques et distinctions.

(introduction) . « Sociologie » de l’ERP

« PGI » : outil, projet d’entreprise ou …débat de société ?

Le mythe de « l’outil générique qui fait tout »(Finances, stocks, commandes, factures, production, logistique, RH…)

Oui, mais beaucoup plus :

. Standardisation vs personnalisation

. Centralisation vs systèmes en « patchwork » et redondants

. Automatisation vs méthodes anciennes

(« One size fits all »)

(introduction) . « Sociologie » de l’ERP

« PGI » : projet d’entreprise ou débat de société ?

C’est un projet d’entreprise : « pas de projet ERP sans une définition claire du modèle de l’entreprise »

Objectifs (avouables ou non) :

Rendre accessibles toutes les informations en temps réel, changer les habitudes au sein de l’entreprise, « tayloriser » certaines tâches, réduire les coûts, voire les effectifs, éliminer ceux qui ne s’adapteront pas…

Rationaliser, uniformiser, centraliser, « mondialiser »... Mais aussi : « se débarrasser des informaticiens »

(introduction)« Sociologie » de l’ERP

Pourquoi en parle-t-on ? Phénomène de société Quelques chiffres (« Fortune »)Le CA des ERP : 1990 = 1 milliard $

2002 = 84 milliard $ 3 éditeurs : 50% du marché mondial SAP : CA supérieur à tous les autres réunis SAP équipe 90% des grandes entreprises françaises

(Etude : Ecole des Mines 2002) et plus de 30% de celles de plus de 2.000 salariés

L’économie française dépend d’un éditeur ?Le DSI de Péchiney : « Avons-nous une alternative pour gérer

nos sociétés ?»

(introduction)« Sociologie » de l’ERP

Pourquoi en parle-t-on ? Equations, conflits ? « Equation impossible » : Editeur, client (MOA), intégrateur, assistant à

maîtrise d’ouvrage… quel partage des rôles ? . Répartition des rôles entres les acteurs : Qui fait quoi ? Qui pilote le projet ?. Qui est responsable de quoi en cas de conflit ? (anticiper le contentieux)

Conflit d’intérêts ? Ils ont dit : Dépendance : « On remet les clés de l’entreprise à un éditeur pour 10 ans » ouou

« vivre heureux pour 5 à 6 ans » Réversibilité : « Comment en sort-on ? » Le SI : un projet « qui ne termine jamais » « On opère le tissu vivant (l’entreprise) sans anesthésie » L’intégration d’un ERP : la « quadrature du cercle »

Un triangle à angles fuyants (les trois grands objectifs d’un projet ERP) :

un résultat fonctionnel, pour un prix forfaitaire,et dans un délai fixe.

(introduction)« Sociologie » de l’ERP

Quels problèmes? Quels conflits? Vers où va-t-on ? L’ERP c’est aussi : (Standish Group) 31% de projets abandonnés 34% d’échecs avoués Budget : 52% des projets dépassent le budget de 189% en

moyenne Délais : dépassement moyen de 222% des plannings Résultat : 61% des fonctionnalités voulues à l’origine sont

atteintes Faillites pour perte des tableaux de bord de l’entreprise; DSI,

voire DG : fusibles de projet avortés

…et le projet ERP peut ressembler une croisière à bord du Titanic

Le juriste sur le thème 3 : (introduction) . Les nouveaux mots

L’ERP d’hier, c’est aussi désormais :

« L’entreprise étendue » : connexion des systèmes avec ceux des clients et des fournisseurs

CRM « Customer Relationship Management » (relation client) SCM « Supply Chain Management » (chaîne logistique) B 2 B, Portails, Places de marchés virtuelles ASP « Application Service Provider » (accès aux ERP en mode

plateforme ASP) « Open Source » Les systèmes fondés sur logiciels « libres » Les « connecteurs : EAI » (Enterprise Application Integration)

Les réponses du juriste. Les solutions contractuelles à la confrontation des

acteurs : anticiper les risques et les contentieux

Plan

4.1 Les schémas contractuels :

choix – quel modèle privilégier ?

4.2 Quelques conseils de gestion des risques :

. Sur le contrat d’intégration

. Sur les dérapages de projet

Plan 4.1.« un pré-requis : le contrat »

4.1. L’outil de gestion indispensable d’un projet ERP : Un schéma contractuel clair

Nous examinerons les 3 schémas possibles

Et nous verrons lequel choisir : les avantages et les inconvénients

Pourquoi ? Le contrat est nécessaire pour :

Formaliser les relations et la nature des engagements, Donner la liste des référentiels de conformité Fixer les objectifs de résultat: délais, périmètre fonctionnel,

performances, garanties, etc. Définir la répartition des rôles: maîtrise d’œuvre, maîtrise

d’ouvrage, « intégrateur », assistance à maîtrise d’ouvrage, etc. Un outil de gestion, de prévention des dérapages: définition des

conditions du suivi, du pilotage et des procédures d’alerte Outil de solution, en cas d’incidents : solutions amiables et

réparation (forfaitaire ou non) en cas de retard ou d’échec.

Éditeur, intégrateur, maître d’œuvre, fournisseurs divers. Où est la cohérence ?

1. Un schéma contractuel à éviter :

un simple contrat de licence avec l’éditeur de l’ERP choisi

Il faut un vrai contrat “d’intégration” de progiciel pour assurer sa mise en œuvre

La question : quel schéma privilégier ?

1. contrat “d’intégration” : quel schéma privilégier ?

Il faut arbitrer au regard des trois schémas suivants :

Le contrat de fourniture de SI “clé en main”

Un schéma “sans intégrateur”

Un schéma avec un “intégrateur- maître d’œuvre ”

1. Identification du schéma contractuel (5) : Schéma A “clé en main” ?

Maître d’ouvrageMaître d’ouvrage

Entreprise généraleEntreprise générale

Sous Sous traitantstraitants

Editeur Hard-ware

Services

1. Schéma contractuel (6) : A -“clé en main” :

ObservationsObservations C’est le schéma que très souvent le client recherche :

“une seule tête” responsable de tout Un seul contrat uniquement avec « l’entreprise

générale » (contrat d’entreprise et autres régimes juridiques de responsabilité)

On se rassure avec le mot “clé en main”, en oubliant les caractéristiques d’un projet d’intégration d’ERP

Dans la plupart des cas, ce schéma ne convient pas: on confond responsabilités juridiques et répartition des rôles nécessitée par la vie du projet

1. Schéma contractuel (7): A -“clé en main” : non

approprié

Ce n’est pas l’esprit d’un projet d’intégration d’ERP, qui nécessite une collaboration du client à sa réussite

Un projet informatique nécessite : l’implication totale de la MOA, une expression des besoins claire (CDC, SFD, SFT)

Or, un contrat « clé en mains » revient à confier toute la latitude à l’entreprise générale

Le projet perd en visibilité: on reporte la validation à la fin du projet

1. Schéma contractuel (8): A -“clé en main” : non

approprié De plus, dans la pratique, c’est le client qui, de fait : Choisit l ’ERP (même si l’intégrateur préconise) Souhaite ne pas payer un « mark-up » sur le prix de

la licence Conclut le contrat et gère, dans le temps, la relation :

en direct avec l’éditeur

Conclusion : à rejeter en principe

Schéma B : Pas d’intégrateur : descriptif

Maître d’ouvrageMaître d’ouvrage

Editeur Hard-ware

Services divers

Schéma B : Pas d’intégrateur : variante

Maître d’ouvrageMaître d’ouvrage qualifié aussi de “maîtrequalifié aussi de “maître d’œuvre”d’œuvre”

L’Editeur Les fournisseurs

La SSII

Schéma B : Pas d’intégrateur : ce qui manque

Il manque : Un « architecte » ou « maître d’œuvre » Qui ne soit : ni le client, ni les « artisans » Qui conçoive et contrôle le projet indépendamment des fournisseurs:

D ’ERP sous licence De services complémentaires ou de ressources De hardware

Schéma C: avec un “intégrateur-maître d’œuvre”

Maître d’ouvrage

Intégrateur

ERP Hardware

Le schéma le mieux adapté :

Prestataires

Le schéma C qui convient : avec un “intégrateur-maître d’œuvre” : Pourquoi ?

Car il y a un “architecte”, qui veille à la réussite du projet tant au stade de la conception que dans la phase de réalisation et de recette du NSI

Avec un fort niveau d’engagement : “maître d’œuvre”

Responsable de La conception La réalisation La « bonne fin » du projet

Qui supervise, coordonne, voire gère la relation avec les contractants du maître de l’ouvrage

RAPPEL DU PLAN

4.2 Quelques conseils dans la gestion des risques :

a. Sur le contrat d’intégration

b. Sur les dérapages de projet

4.2 Quelques conseils : a) Sur le contrat d’intégration

Les clauses à soigner : Distinguer le double objet : tâches de réalisation et de

conduite du projet Clauses opérationnelles : recettes, Définitive/provisoire ;

« VA-VSR » Garanties PI : cession-concession Responsabilité : dommages directs et immatériels, quel

plafond ?

4.2 Quelques conseils : a) Sur le contrat d’intégration

Les clauses à soigner : Soigner les définitions Quel est le référentiel de la « conformité » due par l’intégrateur

: la « Documentation validée » Associer les fins de phases et sous phases, ainsi que les

paiements à des livrables

4.2 Quelques conseils : a) Sur le contrat d’intégration

Un contrat à deux détentes : La partie avec visibilité : forfait et délai

(on ne voit le périmètre des développements spécifiques et des interfaces qu’après l’étude de cadrage et l’ajustement du CDC)

Pour la suite, éventuellement et surtout si le projet est sujet à évolution, un contrat cadre, prévoyant : De petits forfaits par lots bien définis Des travaux complémentaires en mode régie ou « régie forfaitisée »

4.2 Quelques conseils : b) Sur les dérapages de projet

Quelques constats a) un décalage permanent inhérent à la différence entre l’attente

du client et la réalité du produit b) Les traumatismes de l ’ERP

Un changement radical des process et des habitudes dans l’entreprise.

L ’élimination programmée de ceux qui ne s ’adapteront pas au NSI

.

4.2 Quelques conseils : b) Sur les dérapages de projet

c) Des blocages psychologiques : craintes, suspicions, résistances…Les vaincre suppose la réussite de l’accompagnement au changement

d) Une absence de visibilité : difficulté d ’appréhender l ’ampleur des changements et la manière dont le projet sera vécu

4.2 Quelques conseils : b) Sur les dérapages de projet

e) L ’inflation des « développements spécifiques » Certes, on part d’un progiciel standard : les fonctionnalités

préprogrammées de l ’ERP

Mais : le projet va nécessiter une série d’adaptations imprévues et très

probablement des évolutions par rapport au CDC initial pour conserver certaines pratiques de l’entreprise, il faudra faire

certains compromis

4.2 Quelques conseils : b) Sur les dérapages de projet

(e.suite) L’inflation des « développements spécifiques » : conséquences

Une sortie de l’épure du « tout spécifique » Une complexification Des coûts immédiats de production des développements Des coûts parfois considérables pour les futures migrations de

versions de l ’ERP

b) Sur les dérapages de projet Distinguer les dérapages

Les dérapages inhérents aux ERP qu’il faut tolérer: Ces retards, ces révisions, ces retours en arrière, ces arrêts

pour une réflexion stratégique sont inhérents à l’ERP

Un projet comme celui-ci présente par nature un caractère évolutif : les acteurs et le contrat doivent y être préparés

De même, les résistances, les conflits, les mises en doute…

b) « Dérapages » : Recommandations pratiques

Organiser l’accompagnement du changement

Veiller à une forte implication de la direction générale de l ’entreprise, outre la DSI

Créer une réelle synergie entre la direction informatique et la direction générale

Mobiliser les équipes internes (utilisateurs, etc.)

b)« Dérapages » : Recommandations pratiques

à l’usage de la maîtrise d’ouvrage

Mettre au jour les causes des résistances Oser le « parler vrai » sur les conséquences de l’intégration :

changer les hommes Ne pas laisser les informaticiens en liberté : garder le contrôle Il vaut mieux interrompre ou retarder un projet, quel que soit

le coût ou le préjudice d’image, que de poursuivre sur de mauvaises bases, ou mettre trop tôt le NSI en production

C. Que faire ?

c. Que faire et comment faire en cas de dérapage avéré d’un projet ERP ?

c. La gestion des dérapages

i) Les actions préalables «en interne » ii) Les actions : La riposte graduée

amiables contentieuses

c. La gestion des dérapages i. Les actions préalables en interne

Analyse : faire les constats objectifs en temps utile Utiliser la « grille » du schéma contractuel pour imputer les

responsabilités aux différents intervenants Se faire assister par un expert tiers pour disposer d’un avis

extérieur (il peut jouer le cas échéant le rôle de conciliateur) Reprendre la direction du projet Obtenir un état de la situation objectif des chefs de projet et

de la D.S.I

c) dérapages ii. Les actions : la riposte graduée

1) Il s ’agit de construire une stratégie avec le concours: De l’ expert-conseil extérieur, qu’en général la compagnie

d’assurance du client et/ou du prestataire délègue et rémunère Sur le fondement du (ou des) contrat(s) conclu(s) par le client Schéma revisité et validé par des juristes pour analyser les

forces et les faiblesses de la situation De l’assureur, si besoin est

c) dérapages ii. Les actions : la riposte graduée

2) Les actions amiables directes envers l ’intégrateurl ’intégrateur quiqui est au centre du système, surtout si le schéma contractuel est bon Il a le rôle de maître d’oeuvre Le contrat l’oblige à déterminer l’origine du

problème et à le résoudre

c) dérapages ii. Les actions : la riposte graduée

3) Les solutions amiables avec l ’aide de tiers:

Choix amiable d’un expert conciliateur

Ou désignation d’un Expert judiciaire en référé

c) dérapages ii. Les actions : la riposte graduée

4) …Si tout a échoué : la procédure judiciaire : Action en responsabilité contre l’intégrateur et/ou résolution

du contrat (choix stratégique), ainsi qu’à l’encontre des autres prestataires (assistant à maîtrise d’ouvrage, éditeur) et appel en garantie des autres sous-traitants éventuels par l’intégrateur

Demande de dommages et intérêts à titre de provision, devant le juge des référés, ou directement « au fond »

Recours aux clauses du contrat : clauses de résiliation/résolution Clauses pénalités et/ou d’astreinte (« police privée ») substitution de prestataire (si prévu par le contrat ou en cas de

résiliation effective)

Le régime de responsabilité Le régime de responsabilité contractuelle des prestatairescontractuelle des prestataires

Les différents régimes de responsabilitéLes différents régimes de responsabilité responsabilité pour faute prouvée

• l’obligation du prestataire est une obligation de moyen: la charge de la preuve repose sur le client

responsabilité pour manquement à une obligation de résultat

• l ’obligation du prestataire est une obligation de résultat (exemple, un délai impératif) : la charge de la preuve repose sur le prestataire, qui doit démontrer qu’il n’a pas commis de faute ou que sa faute n’a pas entraîné de préjudice

Le régime de responsabilité Le régime de responsabilité contractuelle des prestatairescontractuelle des prestataires

Des responsabilités différenciées en fonction des acteurs…Des responsabilités différenciées en fonction des acteurs………et du schéma contractuel retenu par le client :et du schéma contractuel retenu par le client :

La responsabilité de l’intégrateur maître d’œuvre du projet

L’éditeur du progiciel: quelle responsabilité en cas de dysfonctionnement?

Les cas de la sous-traitance ou de la co-traitance solidaire ou conjointe

La responsabilité de l’assistant à la maîtrise d’ouvrage

La responsabilité « résiduelle » du maître de l’ouvrage

CONCLUSION des pré requis CONCLUSION des pré requis juridiquesjuridiques

Tout se joue en aval: une Tout se joue en aval: une bonne négociation de votre bonne négociation de votre contrat E.R.P.contrat E.R.P.

En cas de dérapage : En cas de dérapage : Faire une analyse objective Faire une analyse objective Opter pour une gestion Opter pour une gestion

graduée des ripostesgraduée des ripostes Ne pas négliger les moyens Ne pas négliger les moyens

amiables, quitte à amiables, quitte à s’engager dans un s’engager dans un « précontentieux »« précontentieux »