legal risks in erp projects paris 2007
DESCRIPTION
Conference held in Paris on legal risks in Software projectsTRANSCRIPT
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
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 »