Pour limiter les risques d’échec

La caractéristique première d’un ERP est d’avoir été conçu par l’éditeur, non pour satisfaire les besoins particuliers d’une entreprise, mais pour satisfaire les besoins d’un marché.
L’objectif à atteindre sera, dès lors, de permettre à l’entreprise qui opte pour une solution de ce type de pouvoir utiliser un produit standard, tout en ne renonçant pas à satisfaire aussi largement que possible ses propres besoins.
Pour atteindre cet objectif, un arbitrage permanent s’impose, lequel aboutira soit à privilégier les besoins particuliers du client, soit à remettre en cause ses méthodes de travail. Rappelons en effet que le Tribunal de Commerce de Paris, dans une décision du 18 décembre 2002, retient que les progiciels étant « par nature » des produits standards, il revient au client de rechercher les adaptations à apporter en fonction de ses besoins (8ème chambre - JBA Presys/Become – Jurisdata 2002-209791).
Or, les finalités recherchées par chaque acteur ne sont pas naturellement convergentes.
Alors que la Direction Générale du client se préoccupera essentiellement du respect du prix et des délais convenus, l’intégrateur tentera, quant à lui, de s’écarter le moins possible des fonctions standard de l’ERP, les utilisateurs, quant à eux, auront pour principale préoccupation de continuer à bénéficier de tous les acquis du système qu’ils utilisaient, tout en profitant des avantages offerts par la nouvelle solution ERP sans trop bouleverser leurs habitudes de travail.
Seule une démarche rigoureuse incluant une conduite du changement (préalable à la mise en œuvre du projet) et une répartition des rôles équilibrée tendant à satisfaire l’ensemble des acteurs permettront de transformer le projet ERP en véritable réussite. A défaut les juges sont enclins à renvoyer les parties dos à dos comme l’a fait la Cour d’appel de Paris dans une décision du 7 mai 2003 aux termes de laquelle elle conclue que les deux parties sont également « responsables du développement non satisfaisant du projet d’utilisation d’un progiciel, sans que les défaillances de l’une exonèrent l’autre des conséquences de ses propres manquements » (25ème chambre section B – GFI Informatique/Etablissement Denis – Jurisdata 2003-217493).

Une période incontournable de «gap analysis»

Il s’agit ici de maîtriser l’écart fonctionnel qui va nécessairement apparaître entre l’expression initiale des besoins du client et les possibilités qu’offre l’ERP. Certes, il est toujours possible de combler cet écart par des développements spécifiques mais les inconvénients de ce type d’aménagement sont évidents (impact sur les délais et le prix, complexification notable de l’objectif de pérennité).
C’est pourquoi la maîtrise de cet écart fonctionnel, quelles que soient la qualité et la complétude du cahier des charges, rend nécessaire une phase d’analyse dite «gap analysis».
Quelle que soit la démarche adoptée, elle devra être structurante et amènera les utilisateurs clés à définir la cible fonctionnelle. Sur ce plan, le pouvoir de décision reviendra en dernier ressort non à l’intégrateur, en dépit des fonctions de maîtrise d’œuvre qu’il assume, mais au client.
L’intégrateur, outre son rôle de préconisateur, devra évaluer les conséquences sur la cohérence de la solution, le prix de mise en œuvre de l’ERP, sur les coûts de maintenance, ainsi que sur les délais qu’entraînera toute prise en compte d’un besoin ne s’inscrivant pas dans les fonctionnalités standards de l’ERP.
En effet, la Cour de Cassation sanctionne le prestataire, au titre de son devoir de conseil, qui n’envisage pas les risques de l’absence de définition précise des besoins pour le projet et ne s’enquière pas des informations nécessaires (Chambre Commerciale n°00-11.530 – 6 mai 2003 – Proland /Union générale de la mutualité du Rhône).

Mettre en œuvre un véritable partenariat

S’agissant d’un projet d’entreprise, la Direction Générale du client se doit de s’impliquer fortement. C’est en effet à elle que revient naturellement la tâche de mobiliser toutes les ressources de l’entreprise, de telle sorte que la réussite de la mise en place de la solution ERP soit un objectif totalement partagé ainsi que l’ont rappelé les juges du Tribunal de Commerce de Dijon à propos de la mise en œuvre d’un ERP : les opérations d’adaptation et de paramétrage supposent une restructuration du système et impliquent une collaboration étroite entre le fournisseur et le client (21 janvier.2002 - Inédit). La Cour de Cassation retient ce nécessaire partenariat à propos d´un client qui n'avait pas évalué l'ampleur de la tâche qui lui incombait et s'était mise dans l'impossibilité de respecter les objectifs qu'il avait contractés, engageant ainsi sa responsabilité à l'égard du prestataire (1ère Civ n° 99-16.329 – 2 octobre 2001 – Ballario/SPI).
Plus généralement, le client participe activement à toutes les phases du projet et il arrive d’ailleurs assez souvent qu’il mette sur le projet, non seulement une équipe fonctionnelle assumant la fonction de maîtrise d’ouvrage, mais également des ressources techniques dans une structure interne assurant une part de la maîtrise d’œuvre.
Cette participation active, essentielle, est toutefois souvent à l’origine de difficultés importantes et de dérives en tout genre :

• une double équipe maîtrise d’œuvre,
• une information morcelée,
• une instabilité chronique du besoin,
• une déresponsabilisation de l’intégrateur ou de l’éditeur,
• ou encore l’immixtion du client dans la part de maîtrise d’œuvre assumée par l’intégrateur, immixtion que les juges peuvent sanctionner lourdement (Cour d’Appel de Paris – 5ème chambre section B – LaPoste/Capgemini – Sinorg --Jurisdate 2001-150713).

Aussi, la mise en place et la mise à jour d’une planification de projet rigoureuse et le respect de la répartition des tâches à produire par chacun se révèlent impératifs dans un projet de cette nature.

Attention à la notion d’obligation de résultat

Pendant longtemps, on a considéré que les fonctions de maîtrise d’œuvre, qu’on associait souvent à l’obligation de résultat conçue comme une garantie de bonne fin, devaient être assumées par le seul prestataire, l’exercice de cette maîtrise impliquant que ce dernier soit seul décideur.
Cette interprétation est parfois consacrée par la Cour de Cassation qui retient que l’intention des parties (caractérisée dans le bon de commande, le cahier des charges et les courriers échangés) de procéder à une informatisation globale et intégrée de la comptabilité dans des délais précis caractérisent l’obligation de résultat (Chambre commerciale n°98-10.600 – 26 juin 2001 – Locasystem/AGP Conseil).
Cette conception, quelque peu absolutiste, a engendré de sérieuses difficultés, ne serait-ce que parce que le client et ses utilisateurs entendaient avoir voix au chapitre dès lors que le métier de l’entreprise était au cœur des choix à effectuer.
Heureusement, les choses ont évolué et les juges du fond sont de plus en plus pragmatiques comme en témoignent par exemple une décision récente du Tribunal de Commerce de Paris qui considère qu’un client ne pouvait ignorer que la durée de vie d’une version de logiciel est nécessairement courte et que tout utilisateur doit s’attendre à migrer d’une version à l’autre à intervalles réguliers (8ème chambre – 5 mai 2004 – Peyre/Silog – Jurisdate 2004-246666).
On sait aujourd’hui que la recherche d’une sécurité contractuelle construite sur un partage de responsabilités déséquilibré, tendant à faire assumer par l’intégrateur la quasi-totalité des risques, s’avère dans la majorité des cas improductive !