Legal Risks In Erp Projects Paris 2007

1,302 views
1,158 views

Published on

Conference held in Paris on legal risks in Software projects

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,302
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Legal Risks In Erp Projects Paris 2007

  1. 1. ERP vu par un juriste : quelles responsabilités ? quels acteurs ? quels contentieux ? Me André Meillassoux, Avocat, ATM Avocats, Paris [email_address] http://www.atmavocats.com
  2. 2. <ul><li>Sommaire : Introduction </li></ul><ul><li>Definition de l’ERP </li></ul><ul><li>. L’ERP, qu’est-ce que c’est ? Distinctions. Caractéristiques. Utilité. Objectifs. </li></ul><ul><li>2. « Sociologie » de l’ERP </li></ul><ul><li>. Pourquoi en parle-t-on ? « Equation », conflits ? </li></ul><ul><li>. Les problématiques : les nouveaux mots, </li></ul><ul><li>. Où va t-on ? Vers quels problèmes ? </li></ul>
  3. 3. (introduction) . L’ERP, qu’est-ce que c’est ? Définition <ul><li>«  Entreprise ressource planning » = « Progiciel de Gestion Intégrée » </li></ul><ul><li>Tentative de définition synthétique : </li></ul><ul><li>C’est une application informatique : </li></ul><ul><li>. standard, </li></ul><ul><li>. couvrant l’ensemble des fonctions de gestion de l’entreprise </li></ul><ul><li>. gérant une base de données unique </li></ul><ul><li>On construit les systèmes d’information autour d’un noyau standard, plutôt que créer des systèmes spécifiques </li></ul><ul><li>Définition développée. Caractéristiques et distinctions. </li></ul>
  4. 4. (introduction) . « Sociologie » de l’ERP <ul><li>« PGI » : outil, projet d’entreprise ou …débat de société ? </li></ul><ul><li>Le mythe de « l’ outil générique qui fait tout » </li></ul><ul><li>(Finances, stocks, commandes, factures, production, logistique, RH…) </li></ul><ul><li>Oui, mais beaucoup plus : </li></ul><ul><li>. Standardisation vs personnalisation </li></ul><ul><li>. Centralisation vs systèmes en « patchwork » et redondants </li></ul><ul><li>. Automatisation vs méthodes anciennes </li></ul><ul><li>(« One size fits all ») </li></ul>
  5. 5. (introduction) . « Sociologie » de l’ERP <ul><li>« PGI » : projet d’entreprise ou débat de société ? </li></ul><ul><li>C’est un projet d’entreprise : « pas de projet ERP sans une définition claire du modèle de l’entreprise » </li></ul><ul><li>Objectifs (avouables ou non) : </li></ul><ul><li>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… </li></ul><ul><li>Rationaliser, uniformiser, centraliser, « mondialiser »... Mais aussi : « se débarrasser des informaticiens » </li></ul>
  6. 6. (introduction) « Sociologie » de l’ERP Pourquoi en parle-t-on ? Phénomène de société <ul><li>Quelques chiffres (« Fortune ») </li></ul><ul><li>Le CA des ERP : 1990 = 1 milliard $ </li></ul><ul><li> 2002 = 84 milliard $ </li></ul><ul><ul><li>3 éditeurs : 50% du marché mondial </li></ul></ul><ul><ul><li>SAP : CA supérieur à tous les autres réunis </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>L’économie française dépend d’un éditeur ? </li></ul></ul><ul><li>Le DSI de Péchiney : « Avons-nous une alternative pour gérer nos sociétés ?» </li></ul>
  7. 7. (introduction) « Sociologie » de l’ERP Pourquoi en parle-t-on ? Equations, conflits ? <ul><li>« Equation impossible » : Editeur, client (MOA), intégrateur, assistant à maîtrise d’ouvrage… quel partage des rôles ? </li></ul><ul><li>. Répartition des rôles entres les acteurs : Qui fait quoi ? Qui pilote le projet ? </li></ul><ul><li>. Qui est responsable de quoi en cas de conflit ? (anticiper le contentieux) </li></ul><ul><li>Conflit d’intérêts ? Ils ont dit : </li></ul><ul><ul><li>Dépendance : « On remet les clés de l’entreprise à un éditeur pour 10 ans » ou « vivre heureux pour 5 à 6 ans » </li></ul></ul><ul><ul><li>Réversibilité : « Comment en sort-on ? » </li></ul></ul><ul><ul><li>Le SI : un projet « qui ne termine jamais » </li></ul></ul><ul><ul><li>« On opère le tissu vivant (l’entreprise) sans anesthésie » </li></ul></ul><ul><ul><li>L’intégration d’un ERP : la « quadrature du cercle » </li></ul></ul><ul><li>Un triangle à angles fuyants (les trois grands objectifs d’un projet ERP) : </li></ul><ul><li>un résultat fonctionnel, </li></ul><ul><li>pour un prix forfaitaire, </li></ul><ul><li>et dans un délai fixe. </li></ul>
  8. 8. (introduction) « Sociologie » de l’ERP Quels problèmes? Quels conflits? Vers où va-t-on ? <ul><li>L’ERP c’est aussi : (Standish Group) </li></ul><ul><li>31% de projets abandonnés </li></ul><ul><li>34% d’échecs avoués </li></ul><ul><li>Budget : 52% des projets dépassent le budget de 189% en moyenne </li></ul><ul><li>Délais : dépassement moyen de 222% des plannings </li></ul><ul><li>Résultat : 61% des fonctionnalités voulues à l’origine sont atteintes </li></ul><ul><li>Faillites pour perte des tableaux de bord de l’entreprise; DSI, voire DG : fusibles de projet avortés </li></ul><ul><li>… et le projet ERP peut ressembler une croisière à bord du Titanic </li></ul>
  9. 9. Le juriste sur le thème 3 : (introduction) . Les nouveaux mots <ul><li>L’ERP d’hier, c’est aussi désormais : </li></ul><ul><li>« L’entreprise étendue » : connexion des systèmes avec ceux des clients et des fournisseurs </li></ul><ul><li>CRM « Customer Relationship Management » (relation client) </li></ul><ul><li>SCM « Supply Chain Management » (chaîne logistique) </li></ul><ul><li>B 2 B, Portails, Places de marchés virtuelles </li></ul><ul><li>ASP « Application Service Provider » (accès aux ERP en mode plateforme ASP) </li></ul><ul><li>« Open Source » Les systèmes fondés sur logiciels « libres » </li></ul><ul><li>Les « connecteurs : EAI » ( Enterprise Application Integration) </li></ul>
  10. 10. Les réponses du juriste . Les solutions contractuelles à la confrontation des acteurs : anticiper les risques et les contentieux <ul><li>Plan </li></ul><ul><li>4.1 Les schémas contractuels : </li></ul><ul><li> choix – quel modèle privilégier ? </li></ul><ul><li>4.2 Quelques conseils de gestion des risques : </li></ul><ul><li>. Sur le contrat d’intégration </li></ul><ul><li>. Sur les dérapages de projet </li></ul>
  11. 11. Plan 4.1.« un pré-requis : le contrat » <ul><li>4.1. L’outil de gestion indispensable d’un projet ERP : Un schéma contractuel clair </li></ul><ul><li>Nous examinerons les 3 schémas possibles </li></ul><ul><li>Et nous verrons lequel choisir : les avantages et les inconvénients </li></ul>
  12. 12. Pourquoi ? <ul><li>Le contrat est nécessaire pour : </li></ul><ul><ul><li>Formaliser les relations et la nature des engagements, </li></ul></ul><ul><ul><li>Donner la liste des référentiels de conformité </li></ul></ul><ul><ul><li>Fixer les objectifs de résultat: délais, périmètre fonctionnel, performances, garanties, etc. </li></ul></ul><ul><ul><li>Définir la répartition des rôles: maîtrise d’œuvre, maîtrise d’ouvrage, « intégrateur », assistance à maîtrise d’ouvrage, etc. </li></ul></ul><ul><ul><li>Un outil de gestion, de prévention des dérapages: définition des conditions du suivi, du pilotage et des procédures d’alerte </li></ul></ul><ul><ul><li>Outil de solution, en cas d’incidents : solutions amiables et réparation (forfaitaire ou non) en cas de retard ou d’échec. </li></ul></ul><ul><ul><li>Éditeur, intégrateur, maître d’œuvre, fournisseurs divers. </li></ul></ul><ul><ul><li>Où est la cohérence ? </li></ul></ul>
  13. 13. 1. Un schéma contractuel à éviter : <ul><li>un simple contrat de licence avec l’éditeur de l’ERP choisi </li></ul><ul><li>Il faut un vrai contrat “d’intégration” de progiciel pour assurer sa mise en œuvre </li></ul><ul><li>La question : quel schéma privilégier ? </li></ul>
  14. 14. <ul><li>contrat “d’intégration” : quel schéma privilégier ? </li></ul><ul><li>Il faut arbitrer au regard des trois schémas suivants : </li></ul><ul><li>Le contrat de fourniture de SI “ clé en main ” </li></ul><ul><li>Un schéma “sans intégrateur” </li></ul><ul><li>Un schéma avec un “intégrateur- maître d’œuvre ” </li></ul>
  15. 15. 1. Identification du schéma contractuel (5) : Schéma A “ clé en main ” ? <ul><li>Maître d’ouvrage </li></ul><ul><li>Entreprise générale </li></ul><ul><li>Sous traitants </li></ul><ul><li>Editeur </li></ul><ul><li>Hard-ware </li></ul><ul><li>Services </li></ul>
  16. 16. 1. Schéma contractuel (6) : A - “ clé en main ” : Observations <ul><li>C’est le schéma que très souvent le client recherche : “une seule tête” responsable de tout </li></ul><ul><li>Un seul contrat uniquement avec « l’entreprise générale » (contrat d’entreprise et autres régimes juridiques de responsabilité) </li></ul><ul><li>On se rassure avec le mot “clé en main” , en oubliant les caractéristiques d’un projet d’intégration d’ERP </li></ul><ul><li>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 </li></ul>
  17. 17. 1. Schéma contractuel (7): A - “ clé en main ” : non approprié <ul><li>Ce n’est pas l’esprit d’un projet d’intégration d’ERP, qui nécessite une collaboration du client à sa réussite </li></ul><ul><li>Un projet informatique nécessite : l’implication totale de la MOA, une expression des besoins claire (CDC, SFD, SFT) </li></ul><ul><li>Or, un contrat « clé en mains » revient à confier toute la latitude à l’entreprise générale </li></ul><ul><li>Le projet perd en visibilité: on reporte la validation à la fin du projet </li></ul>
  18. 18. 1. Schéma contractuel (8): A - “ clé en main ” : non approprié <ul><li>De plus, dans la pratique, c’est le client qui, de fait : </li></ul><ul><li>Choisit l ’ERP (même si l’intégrateur préconise) </li></ul><ul><li>Souhaite ne pas payer un « mark-up » sur le prix de la licence </li></ul><ul><li>Conclut le contrat et gère, dans le temps, la relation : en direct avec l’éditeur </li></ul><ul><li>Conclusion : à rejeter en principe </li></ul>
  19. 19. Schéma B : Pas d’intégrateur : descriptif <ul><li>Maître d’ouvrage </li></ul><ul><li>Editeur </li></ul><ul><li>Hard-ware </li></ul><ul><li>Services divers </li></ul>
  20. 20. Schéma B : Pas d’intégrateur : variante <ul><li>Maître d’ouvrage </li></ul><ul><li>qualifié aussi de “maître d’œuvre” </li></ul><ul><li>L’Editeur </li></ul><ul><li>Les fournisseurs </li></ul><ul><li>La SSII </li></ul>
  21. 21. Schéma B : Pas d’intégrateur : ce qui manque <ul><li>Il manque : </li></ul><ul><li>Un «  architecte » ou « maître d’œuvre » </li></ul><ul><li>Qui ne soit : ni le client, ni les « artisans » </li></ul><ul><li>Qui conçoive et contrôle le projet </li></ul><ul><li>indépendamment des fournisseurs: </li></ul><ul><ul><li>D ’ERP sous licence </li></ul></ul><ul><ul><li>De services complémentaires ou de ressources </li></ul></ul><ul><ul><li>De hardware </li></ul></ul>
  22. 22. Schéma C: avec un “intégrateur-maître d’œuvre” <ul><li>Maître d’ouvrage </li></ul><ul><li>Intégrateur </li></ul><ul><li>ERP </li></ul><ul><li>Hardware </li></ul><ul><li>Le schéma le mieux adapté : </li></ul><ul><li>Prestataires </li></ul>
  23. 23. Le schéma C qui convient : avec un “intégrateur-maître d’œuvre” : Pourquoi ? <ul><li>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 </li></ul><ul><li>Avec un fort niveau d’engagement : “maître d’œuvre” </li></ul><ul><li>Responsable de </li></ul><ul><ul><li>La conception </li></ul></ul><ul><ul><li>La réalisation </li></ul></ul><ul><ul><li>La « bonne fin » du projet </li></ul></ul><ul><li>Qui supervise, coordonne, voire gère la relation avec les contractants du maître de l’ouvrage </li></ul>
  24. 24. 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
  25. 25. 4.2 Quelques conseils : a) Sur le contrat d’intégration <ul><li>Les clauses à soigner : </li></ul><ul><li>Distinguer le double objet : tâches de réalisation et de conduite du projet </li></ul><ul><li>Clauses opérationnelles : recettes, Définitive/provisoire ; « VA-VSR » </li></ul><ul><li>Garanties </li></ul><ul><li>PI : cession-concession </li></ul><ul><li>Responsabilité : dommages directs et immatériels, quel plafond ? </li></ul><ul><li> </li></ul>
  26. 26. 4.2 Quelques conseils : a) Sur le contrat d’intégration <ul><li>Les clauses à soigner : </li></ul><ul><li>Soigner les définitions </li></ul><ul><li>Quel est le référentiel de la « conformité » due par l’intégrateur : la « Documentation validée » </li></ul><ul><li>Associer les fins de phases et sous phases, ainsi que les paiements à des livrables </li></ul><ul><li> </li></ul>
  27. 27. 4.2 Quelques conseils : a) Sur le contrat d’intégration <ul><li>Un contrat à deux détentes : </li></ul><ul><li>La partie avec visibilité : forfait et délai </li></ul><ul><li>(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) </li></ul><ul><li>Pour la suite, éventuellement et surtout si le projet est sujet à évolution, un contrat cadre, prévoyant : </li></ul><ul><ul><li>De petits forfaits par lots bien définis </li></ul></ul><ul><ul><li>Des travaux complémentaires en mode régie ou « régie forfaitisée » </li></ul></ul><ul><li> </li></ul>
  28. 28. 4.2 Quelques conseils : b) Sur les dérapages de projet <ul><li>Quelques constats </li></ul><ul><li>a) un décalage permanent inhérent à la différence entre l’attente du client et la réalité du produit </li></ul><ul><li>b) Les traumatismes de l ’ERP </li></ul><ul><li>Un changement radical des process et des habitudes dans l’entreprise. </li></ul><ul><li>L ’élimination programmée de ceux qui ne s ’adapteront pas au NSI </li></ul><ul><li>. </li></ul>
  29. 29. 4.2 Quelques conseils : b) Sur les dérapages de projet <ul><li>c) Des blocages psychologiques : craintes, suspicions, résistances…Les vaincre suppose la réussite de l’accompagnement au changement </li></ul><ul><li>d) Une absence de visibilité : difficulté d ’appréhender l ’ampleur des changements et la manière dont le projet sera vécu </li></ul>
  30. 30. 4.2 Quelques conseils : b) Sur les dérapages de projet <ul><li>e) L ’inflation des « développements spécifiques » </li></ul><ul><li>Certes, on part d’un progiciel standard : les fonctionnalités préprogrammées de l ’ERP </li></ul><ul><li>Mais : </li></ul><ul><ul><li>le projet va nécessiter une série d’adaptations imprévues et très probablement des évolutions par rapport au CDC initial </li></ul></ul><ul><ul><li>pour conserver certaines pratiques de l’entreprise, il faudra faire certains compromis </li></ul></ul>
  31. 31. 4.2 Quelques conseils : b) Sur les dérapages de projet <ul><li>(e. suite ) L’inflation des « développements spécifiques » : conséquences </li></ul><ul><li>Une sortie de l’épure du « tout spécifique » </li></ul><ul><li>Une complexification </li></ul><ul><li>Des coûts immédiats de production des développements </li></ul><ul><li>Des coûts parfois considérables pour les futures migrations de versions de l ’ERP </li></ul>
  32. 32. b) Sur les dérapages de projet Distinguer les dérapages <ul><li>Les dérapages inhérents aux ERP qu’il faut tolérer : </li></ul><ul><li>Ces retards, ces révisions, ces retours en arrière, ces arrêts pour une réflexion stratégique sont inhérents à l’ERP </li></ul><ul><li>Un projet comme celui-ci présente par nature un caractère évolutif : les acteurs et le contrat doivent y être préparés </li></ul><ul><li>De même, les résistances, les conflits, les mises en doute… </li></ul>
  33. 33. b) « Dérapages » : Recommandations pratiques <ul><li>Organiser l’ accompagnement du changement </li></ul><ul><li>Veiller à une forte implication de la direction générale de l ’entreprise, outre la DSI </li></ul><ul><li>Créer une réelle synergie entre la direction informatique et la direction générale </li></ul><ul><li>Mobiliser les équipes internes (utilisateurs, etc.) </li></ul>
  34. 34. b)« Dérapages » : Recommandations pratiques à l’usage de la maîtrise d’ouvrage <ul><li>Mettre au jour les causes des résistances </li></ul><ul><li>Oser le «  parler vrai » sur les conséquences de l’intégration : changer les hommes </li></ul><ul><li>Ne pas laisser les informaticiens en liberté : garder le contrôle </li></ul><ul><li>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 </li></ul>
  35. 35. C. Que faire ? <ul><li>c. Que faire et comment faire en cas de dérapage avéré d’un projet ERP ? </li></ul>
  36. 36. c. La gestion des dérapages <ul><li>i) Les actions préalables «en interne » </li></ul><ul><li>ii) Les actions : La riposte graduée </li></ul><ul><ul><li>amiables </li></ul></ul><ul><ul><li>contentieuses </li></ul></ul>
  37. 37. c. La gestion des dérapages i. Les actions préalables en interne <ul><li>Analyse : faire les constats objectifs en temps utile </li></ul><ul><li>Utiliser la « grille » du schéma contractuel pour imputer les responsabilités aux différents intervenants </li></ul><ul><li>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) </li></ul><ul><li>Reprendre la direction du projet </li></ul><ul><li>Obtenir un état de la situation objectif des chefs de projet et de la D.S.I </li></ul>
  38. 38. c) dérapages ii. Les actions : la riposte graduée <ul><li>1) Il s ’agit de construire une stratégie avec le concours : </li></ul><ul><li>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 </li></ul><ul><li>Sur le fondement du (ou des) contrat(s) conclu(s) par le client </li></ul><ul><li>Schéma revisité et validé par des juristes pour analyser les forces et les faiblesses de la situation </li></ul><ul><li>De l’assureur, si besoin est </li></ul>
  39. 39. c) dérapages ii. Les actions : la riposte graduée <ul><li>2) Les actions amiables directes envers l ’intégrateur qui est au centre du système , surtout si le schéma contractuel est bon </li></ul><ul><ul><li>Il a le rôle de maître d’oeuvre </li></ul></ul><ul><ul><li>Le contrat l’oblige à déterminer l’origine du problème et à le résoudre </li></ul></ul>
  40. 40. c) dérapages ii. Les actions : la riposte graduée <ul><li>3) Les solutions amiables avec l ’aide de tiers: </li></ul><ul><li>Choix amiable d’un expert conciliateur </li></ul><ul><li>Ou désignation d’un Expert judiciaire en référé </li></ul>
  41. 41. c) dérapages ii. Les actions : la riposte graduée <ul><li>4) … Si tout a échoué : la procédure judiciaire : </li></ul><ul><li>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 </li></ul><ul><li>Demande de dommages et intérêts à titre de provision, devant le juge des référés, ou directement « au fond » </li></ul><ul><li>Recours aux clauses du contrat : </li></ul><ul><ul><li>clauses de résiliation/résolution </li></ul></ul><ul><ul><li>Clauses pénalités et/ou d’astreinte (« police privée ») </li></ul></ul><ul><ul><li>substitution de prestataire (si prévu par le contrat ou en cas de résiliation effective) </li></ul></ul>
  42. 42. Le régime de responsabilité contractuelle des prestataires <ul><li>Les différents régimes de responsabilité </li></ul><ul><li>responsabilité pour faute prouvée </li></ul><ul><ul><ul><li>l’obligation du prestataire est une obligation de moyen: la charge de la preuve repose sur le client </li></ul></ul></ul><ul><li>responsabilité pour manquement à une obligation de résultat </li></ul><ul><ul><ul><li>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 </li></ul></ul></ul>
  43. 43. Le régime de responsabilité contractuelle des prestataires <ul><li>Des responsabilités différenciées en fonction des acteurs… </li></ul><ul><li>… et du schéma contractuel retenu par le client : </li></ul><ul><li>La responsabilité de l’intégrateur maître d’œuvre du projet </li></ul><ul><li>L’éditeur du progiciel: quelle responsabilité en cas de dysfonctionnement? </li></ul><ul><li>Les cas de la sous-traitance ou de la co-traitance solidaire ou conjointe </li></ul><ul><li>La responsabilité de l’assistant à la maîtrise d’ouvrage </li></ul><ul><li>La responsabilité « résiduelle » du maître de l’ouvrage </li></ul>
  44. 44. CONCLUSION des pré requis juridiques <ul><li>Tout se joue en aval: une bonne négociation de votre contrat E.R.P. </li></ul><ul><li>En cas de dérapage : </li></ul><ul><li>Faire une analyse objective </li></ul><ul><li>Opter pour une gestion graduée des ripostes </li></ul><ul><li>Ne pas négliger les moyens amiables, quitte à s’engager dans un « précontentieux » </li></ul>

×