legal risks in erp projects paris 2007

44
ERP vu par un ERP vu par un juriste : quelles juriste : quelles responsabilités ? responsabilités ? quels acteurs ? quels quels acteurs ? quels contentieux ? contentieux ? Me André Meillassoux, Avocat, ATM Avocats, Paris [email protected] http://www.atmavocats.com

Upload: andre-meillassoux

Post on 05-Dec-2014

1.564 views

Category:

Technology


1 download

DESCRIPTION

Conference held in Paris on legal risks in Software projects

TRANSCRIPT

Page 1: Legal Risks In Erp Projects Paris 2007

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, [email protected]://www.atmavocats.com

Page 2: Legal Risks In Erp Projects Paris 2007

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 ?

Page 3: Legal Risks In Erp Projects Paris 2007

(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.

Page 4: Legal Risks In Erp Projects Paris 2007

(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 »)

Page 5: Legal Risks In Erp Projects Paris 2007

(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 »

Page 6: Legal Risks In Erp Projects Paris 2007

(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 ?»

Page 7: Legal Risks In Erp Projects Paris 2007

(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.

Page 8: Legal Risks In Erp Projects Paris 2007

(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

Page 9: Legal Risks In Erp Projects Paris 2007

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)

Page 10: Legal Risks In Erp Projects Paris 2007

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

Page 11: Legal Risks In Erp Projects Paris 2007

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

Page 12: Legal Risks In Erp Projects Paris 2007

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 ?

Page 13: Legal Risks In Erp Projects Paris 2007

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 ?

Page 14: Legal Risks In Erp Projects Paris 2007

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 ”

Page 15: Legal Risks In Erp Projects Paris 2007

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

Page 16: Legal Risks In Erp Projects Paris 2007

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

Page 17: Legal Risks In Erp Projects Paris 2007

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

Page 18: Legal Risks In Erp Projects Paris 2007

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

Page 19: Legal Risks In Erp Projects Paris 2007

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

Maître d’ouvrageMaître d’ouvrage

Editeur Hard-ware

Services divers

Page 20: Legal Risks In Erp Projects Paris 2007

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

Page 21: Legal Risks In Erp Projects Paris 2007

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

Page 22: Legal Risks In Erp Projects Paris 2007

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

Page 23: Legal Risks In Erp Projects Paris 2007

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

Page 24: Legal Risks In Erp Projects Paris 2007

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

Page 25: Legal Risks In Erp Projects Paris 2007

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 ?

Page 26: Legal Risks In Erp Projects Paris 2007

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

Page 27: Legal Risks In Erp Projects Paris 2007

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 »

Page 28: Legal Risks In Erp Projects Paris 2007

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

.

Page 29: Legal Risks In Erp Projects Paris 2007

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

Page 30: Legal Risks In Erp Projects Paris 2007

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

Page 31: Legal Risks In Erp Projects Paris 2007

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

Page 32: Legal Risks In Erp Projects Paris 2007

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…

Page 33: Legal Risks In Erp Projects Paris 2007

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

Page 34: Legal Risks In Erp Projects Paris 2007

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

Page 35: Legal Risks In Erp Projects Paris 2007

C. Que faire ?

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

Page 36: Legal Risks In Erp Projects Paris 2007

c. La gestion des dérapages

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

amiables contentieuses

Page 37: Legal Risks In Erp Projects Paris 2007

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

Page 38: Legal Risks In Erp Projects Paris 2007

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

Page 39: Legal Risks In Erp Projects Paris 2007

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

Page 40: Legal Risks In Erp Projects Paris 2007

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é

Page 41: Legal Risks In Erp Projects Paris 2007

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)

Page 42: Legal Risks In Erp Projects Paris 2007

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

Page 43: Legal Risks In Erp Projects Paris 2007

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

Page 44: Legal Risks In Erp Projects Paris 2007

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 »