Documente Academic
Documente Profesional
Documente Cultură
Les ERP
J. Sornet 2014
APPLICATIONS
Ces applications sont essentiellement pdagogiques. Elles visent une assimilation assez large de la
problmatique des ERP et vont au-del du rfrentiel. Elles ne constituent aucunement des modles
de sujets dexamen et, dailleurs, le chapitre 3 (lERP dans lorganisation) ny est pas spcifiquement
trait car il peut tre illustr par plusieurs anciens sujets du DSCG et les exercices proposs dans
divers ouvrages.
Exercice 1.1 Proposer une solution logicielle argumente dans chacun des cas suivants :
A - PME de 300 personnes fabriquant portes et fentres sur mesure aprs tude et devis.
Lentreprise, tablie depuis longtemps, a une activit assez stable en sous-traitance
dentreprises du btiment ou pour des particuliers.
Le systme dinformation, qui doit tre rnov, exploite les lments suivants :
- une gestion de production couple un logiciel dtudes permettant llaboration des devis
techniques. Cet ensemble a comme origine un organisme professionnel inter-rgional et il est
parfaitement adapt et soutenu ;
- un pack comptabilit gnrale, gestion de la paie et gestion commerciale intgr et interfac
avec la GPAO mais trs ancien et ne devant plus tre maintenu dans huit mois, aprs
disparition de la SSII ditrice de ces logiciels ;
- un ensemble dapplications bureautiques parfaitement adaptes aux besoins pour la
dtermination et le suivi des cots. Ces applications bnficient dextractions automatiques
depuis la GPAO.
B - PME commerciale de 120 personnes en pleine croissance, devant absorber une entreprise
similaire et doubler ainsi son activit.
Lentreprise dispose dun logiciel comptable performant, mais le reste de la gestion est pris en
charge par un ensemble dapplications spcifiques prsentant de nombreux dfauts
(interoprabilit problmatique, maintenance alatoire, coexistence de plusieurs rfrentiels
de donnes).
Exercice 1.2 Dterminer les raisons qui ont pu freiner le dveloppement des ERP dans les
petites entreprises.
Exercice 2.1 Expliquer les fusions ou acquisitions constates depuis plusieurs annes chez
les diteurs.
Exercice 2.3 Caractriser loffre SAP destine aux PME (All in One, One, By Design)
partir du site de cet diteur ou de vos connaissances. Vous expliquerez le rle et la place des
outils danalyse Crystal et Business Object dans ces ERP.
Cas 1 : groupe industriel employant 4000 personnes, rparties dans cinq units, dont deux
implantes aux USA. Lentreprise fournit des moteurs et des boites de vitesse diffrents
constructeurs automobiles.
Cas 2 : entreprise employant 800 personnes. Lentreprise est implante en France, o elle
ralise 100% de son chiffre daffaires dans le domaine du ngoce de produits alimentaires
prissables. Ses clients sont essentiellement des centrales dachat, des industries de
transformation et des collectivits.
Exercice 4.1 Rapprocher les tapes prsentes dans le document CEGID ci-dessous des
tapes classiques du dveloppement de projet de systme dinformation.
Exercice 4.2 A partir des exemples prsents ci-dessous (exemples publis sur internet par
divers diteurs), rcapituler dans un tableau les principales raisons du choix dun ERP.
Les ERP, Enterprise Resource Planning , sont une des technologies pivots de l'entreprise
de demain. Mais avons-nous la maturit et les comptences managriales pour les utiliser ?
Le rve deviendrait-il ralit ? Une seule donne de gestion fiabilise et stocke dans une base
de donnes unique, accessible dans tous les recoins de l'organisation et partage par tous les
acteurs, telles sont les promesses des ERP. Ce mode de traitement intgr constitue une
rvolution. Actuellement, les donnes de gestion se caractrisent par l'indisponibilit,
l'incohrence, l'ambigut et un cot lev de production.
Cette situation de dsintgration informationnelle a des consquences dramatiques pour
l'entreprise :
- Le client est insatisfait, il ne reoit pas sa commande temps ou il reoit une commande
incomplte.
- Les systmes de conception, de production, de distribution sont inefficients ; en l'absence de
donnes partages, chaque sous-systme s'optimise localement au dtriment de la recherche
d'une optimisation globale.
- Le systme informatique est clat en de nombreux sous-systmes qui ne communiquent
pas, ses cots de dveloppement, de maintenance et d'volution sont levs.
- Le management est inefficace, il passe plus de temps se chamailler sur des donnes de
gestion diffrentes qu' s'entendre pour exploiter toutes les synergies cratrices de valeur.
Mais l'exprience dmontre que les projets ERP sont des projets trs risqus. D'abord, l'effet
d'infrastructure et le caractre normatif des ERP fait prendre l'entreprise des risques
stratgiques dus l'irrversibilit de leur implantation. Le phnomne ERP est trop rcent
pour avoir une juste valuation de ces risques en termes de perte de comptitivit potentielle -
o se diffrencier quand toutes les entreprises auront install des ERP standards ? - ou de
perte d'indpendance au profit de quelques diteurs de progiciels en position dominante.
Ensuite, le caractre global et structurant des ERP fait prendre l'entreprise des risques
d'innovation dus la complexit des projets. L'implantation d'un ERP vise changer
l'organisation. Le passage d'un outil progiciel standard un dispositif organisationnel ad hoc
ncessite donc un processus d'innovation. Ce processus est risqu. Il peut ne pas produire les
effets escompts. Il n'existe pas de chiffres fiables permettant d'valuer les risques
d'innovation. Les entreprises sont peu prolixes sur leurs difficults. L'chec reste tabou. Mais
les exemples et les rumeurs qui circulent dans les milieux informs laissent pressentir un taux
d'chec trs important. partir de l'analyse d'un chantillon de 21 projets, nous avons pu
identifier sept types de risques d'innovation.
Quelle est l'origine de ces risques d'innovation ? Le bouc missaire est vite trouv. C'est la
faute des progiciels intgrs, trop complexes, trop rigides. Certes, la technologie des ERP est
complexe, mais l'outil n'est pas la cause essentielle des checs. Le risque prend sa source dans
le management de l'innovation. On reconnat que les projets ERP sont des projets
d'organisation, mais on continue aborder l'implantation d'un ERP comme un projet
informatique classique. A-t-on pris la mesure du sens du mot organisation ? Qu'est-ce qu'une
organisation ? Qu'est-ce qu'organiser ? Comment conduire un projet global d'organisation ?
Des rponses inappropries ces trois questions expliquent les difficults rencontres dans
l'implantation des ERP. L'chec sanctionne l'inadquation des stratgies d'intgration
informationnelle.
Celui-ci n'est qu'une suite de conflits qui s'acclrent et s'amplifient mesure que le projet se
concrtise. On en dnombre quatre types :
- Le conflit de mode opratoire porte sur la dfinition et la meilleure manire de raliser une
tche ou un ensemble de tches. Par exemple, les acteurs vont se confronter sur la question
des procdures de passation d'une commande, sur la manire de saisir une facture, sur les
mthodes de calcul d'un cot de revient.
- Le conflit de mtier porte sur le type de comptences ncessaires, sur la distribution de ces
comptences entre les acteurs, sur l'organisation des filires mtiers. La mise en place d'un
ERP transforme plus ou moins profondment les mtiers. D'anciens mtiers deviennent
obsoltes, de nouveaux mtiers mergent. Le profil des mtiers change mais les individus
restent et s'interrogent sur leur avenir.
- Le conflit d'influence porte sur la distribution du pouvoir. Ce type de conflit se manifeste
Quelles leons pratiques peut-on tirer de cette conflictualit extraordinaire ? Les initiateurs de
projets ERP se trompent de concept d'organisation. Ils vhiculent la mme image de
l'organisation-machine que les ingnieurs industriels de la premire heure. Comme eux, ils
confondent l'criture de procdures et la construction d'une organisation. Illusionns dans un
exercice de r-engineering virtuel , ils oublient que l'organisation est un systme
sociotechnique, un subtil quilibre de modes opratoires, de mtiers, de relations d'influence
et de systmes de valeurs. Les mmes causes provoquant les mmes effets, comme eux, ils
refont les mmes erreurs.
Les initiateurs des projets ERP ont-ils compris l'organisation ? Des propos souvent entendus
tels que compte tenu des cots d'adaptation, il vaut mieux adapter l'organisation au progiciel
plutt que l'inverse en font douter. Malgr le dveloppement des sciences de l'organisation,
ils sont rests attachs aux vieux concepts tayloriens du dbut du sicle. L'ambigut de la
notion de processus en tmoigne. Un processus est-il autre chose qu'une macro-gamme ?
Rduite ses modes opratoires, rebaptiss pour la circonstance processus , l'organisation
fait de la rsistance. Organiser, c'est reconstruire une communaut autour de nouveaux modes
de coopration. Les checs constats proviennent de l'imprparation des quipes projets
grer cette problmatique communautaire qui s'exprime au travers des conflits de mtiers,
d'influence et de valeurs.
Agir dans une organisation suppose une posture stratgique. Comme sur un march, il faut
comprendre les dynamiques profondes, identifier les acteurs en prsence, valuer les
manoeuvres possibles, choisir une option, dfinir une tactique de mise en oeuvre.
Dans cette perspective, on distingue deux stratgies d'action :
- La routinisation, qui vise dployer ou renforcer une norme d'action dj approprie par
les acteurs et lgitime leurs yeux. L'action organisationnelle met dans ce cas l'accent sur
l'instrumentation de cette norme d'action, sur la formation des acteurs l'utilisation des
nouvelles procdures et sur le renforcement des mcanismes de sanction. Par exemple,
l'implantation du module achat d'un ERP dans une entreprise ayant dj des nomenclatures
achat standardises et homognes et une direction des achats puissante relve d'une stratgie
de routinisation.
Quelles leons pratiques tirer de cette distinction entre ces deux stratgies d'action ? D'abord,
que tout projet ERP doit tre contextualis. Il n'existe pas une approche standard idale en
matire de projet ERP, mais des approches cohrentes avec des contextes d'organisation
diffrents. On n'aborde pas la mise en place des modules finance et contrle de gestion d'un
ERP dans un groupe multinational de culture financire anglo-saxonne comme on aborde la
mise en place des mmes modules fonctionnels dans un groupe franais rcemment privatis
ou dans un hpital. Ensuite, que tout projet ERP doit faire l'objet d'une rflexion stratgique.
/
Exercice 5.2 Aprs analyse du texte ci-dessous, faire ressortir une dizaine de points
essentiels pour limiter les consquences dun chec de limplmentation dun ERP. Peut-on
liminer tout risque de lERP ?
Les ncessits techniques et organisationnelles dune entreprise la poussent recourir, le plus
souvent, des progiciels de gestion intgre qui sappliquent un grand nombre de processus
internes. Ainsi les progiciels de gestion intgre PGI ou ERP ( Entreprise
Resource Planning ) sont aujourdhui indispensables la gestion des flux dune entreprise.
Mais quid lorsque le projet drape ? Quel est rellement le cot de l'chec d'un projet
informatique pour une entreprise ?
De nombreuses tudes professionnelles indiquent que les projets dimplmentation dERP
rencontrent souvent des difficults. En moyenne selon les tudes (ex : "The Chaos Report",
Standish Group, juin 2009), de 20 30% des projets ERP sont des checs plus ou moins
complets, et plus de 50% sont achevs dans la douleur, avec retard ou moyennant un surcot
significatif. Les causes en sont notamment une mauvaise analyse dadquation du produit aux
besoins, des difficults dvelopper ou intgrer dans les faits le progiciel command, ou
encore une drive calendaire ou financire. Les entreprises doivent donc se consacrer avec
une grande rigueur la gestion de projet, et planifier en dtail les consquences de son
succs comme de son chec.
Un ERP est communment dfini comme un progiciel grant tout ou partie des processus
oprationnels de lentreprise, en intgrant l'ensemble de ses fonctions vitales, telles que la
gestion des ressources humaines, la gestion comptable, la gestion financire, les processus de
vente et de distribution, l'approvisionnement en produits, le suivi des fournisseurs, la
maintenance des quipements, le commerce lectronique, la facturation, la gestion des bases
clients, ladministration des campagnes marketing, etc.
Quelle que soit la taille de lentreprise, les ERP utiliss ont une importance stratgique, et
conditionnent les aspects commerciaux, financiers, logistiques et humains de son activit. Un
ERP a un impact sur un grand nombre dquipes et de services, qui sont amenes lutiliser
chacun pour leurs besoins spcifiques.
En outre, les projets commerciaux de lentreprise sont le plus souvent conditionns par les
fonctionnalits et les performances de son systme informatique, lui-mme tributaire de
lefficacit des ERP qui y sont implants. Un projet dimplmentation dERP au sein dune
entreprise, quil sagisse de son quipement initial ou de sa modernisation, constitue donc un
projet hautement stratgique, en ce quil influe sur tous les autres. Il nest pas excessif ce
titre de parler dentreprise assiste par ordinateur .
Lentreprise doit dfinir ses besoins et contraintes avec soin, afin de choisir lERP qui
convient le mieux ses spcificits. De mme, lentreprise doit galement slectionner
lintgrateur avec soin, car de lefficacit de ses prestations dpend le succs du projet. A ce
titre, il est traditionnellement admis quun ERP, en tant que logiciel, doit tre choisi par le
client auquel il incombe de vrifier ladquation du produit ses besoins.
Dans les faits cependant, le choix dun ERP implique une vritable tude dadquation, afin
didentifier les carts invitables entre les fonctionnalits standard du progiciel et les besoins
de lentreprise. Cette dtermination des carts permet de jauger limportance de la ncessaire
phase de personnalisation (paramtrages, interfaages ou dveloppements spcifiques
complmentaires).
Ainsi, le projet dintgration dun ERP ne doit pas tre conu comme un projet comme un
autre. Ses impacts doivent tre mesurs et quantifis, et doivent tre ports la connaissance
du prestataire retenu. Beaucoup dentreprises passent dailleurs des appels doffres qui
exposent leurs besoins, afin de bnficier dun ventail doffres parmi lesquelles elles
choisissent loffre technique et financire qui lui convient le mieux.
Le client peut donc exiger du prestataire intgrateur, non seulement son conseil et son
expertise, mais galement une prestation pralable danalyse fine des besoins et
didentification des carts, afin de planifier la charge relle de travail.
Le client doit galement exiger du prestataire une analyse des changements oprer au sein
de lentreprise, afin de mesurer le temps que les quipes du client vont consacrer au projet. La
conduite du changement ne se rsume pas quelques sessions de formation des
Le prestataire a tout intrt rappeler au client que cette conduite du changement est
ncessaire, dautant quelle est en dehors de sa sphre dintervention. Plus dun projet choue
parce que le client na pas su sensibiliser ses propres quipes au nouveau progiciel, ou quil
sest crisp sur ses anciennes habitudes et na pas apprhend la nouveaut fonctionnelle.
Le projet ERP doit ds lors tre encadr par un contrat en adquation avec les attentes du
client, qui doit identifier avec soin le primtre prcis des interventions du prestataire et
envisager leur dimension juridique : force obligatoire de lexpression initiale des besoins,
modalits de fourniture des matriels et des logiciels, droulement des phases de
spcification, dintgration et de dploiement, obligation de rsultat, respect des dlais et
application des pnalits, matrise duvre et mthodologie de travail, matrice de rpartition
des tches, calendrier, phases et lots du projet, description des procdures de recette des
livrables, modalits de collaboration du client, garanties de qualit et niveaux de service et
enfin, la responsabilit du prestataire en cas dchec du projet.
Lchec dun projet revient souvent, en dernire analyse, labsence de dlivrance conforme
du systme attendu. Que lchec soit d un dpassement des dlais, lincapacit du
prestataire fournir les fonctionnalits convenues, labsence des performances souhaites,
une drive des cots ou encore un dfaut de pilotage des prestations, le client constate en
dernier ressort quil ne dispose pas de lERP command.
Il arrive aussi que le client ne mne pas suffisamment la conduite du changement, ou modifie
unilatralement le primtre de ses besoins, ou encore manque son obligation de
collaboration en ne validant pas les spcifications ou en naccomplissant pas les tches lui
incombant. Il serait faux de croire quun projet informatique choue toujours cause du
prestataire en charge de le mener : bien souvent, le client na pas su se mettre en ordre de
bataille.
Deux questions se posent alors : quelle est la responsabilit du prestataire dans cet chec, et
quel est le prjudice subi par le client susceptible dtre indemnis ?
Dans ce contexte, le prestataire fustige souvent le dfaut de collaboration du client, qui tarde
transmettre les informations ou lments ncessaires au droulement de lintgration, ou
encore valider les livrables, par exemple. Il est donc dans lintrt des deux parties dtablir,
ds le stade du contrat, la matrice de rpartition des responsabilits voques plus haut, afin
de clairement identifier les diligences qui leur incombent ainsi que le rythme auquel chacun
doit les effectuer.
La seconde question, objet de la prsente tude, implique quant elle de mesurer quel sont les
dommages rellement subis par le client.
Le Code civil dispose, son article 1149, que les dommages et intrts dus au crancier
sont, en gnral, de la perte quil a faite et du gain dont il a t priv .
Le principe est immdiatement tempr par larticle 1150, qui dispose que le dbiteur nest
tenu que des dommages et intrts qui ont t prvus ou quon a pu prvoir lors du contrat,
lorsque ce nest point par son dol que lobligation nest point excute . Enfin, larticle 1151
prcise que mme en cas de faute dolosive, les dommages et intrts ne doivent comprendre
lgard de la perte prouve par le crancier et du gain dont il a t priv, que ce qui est une
suite immdiate et directe de linexcution de la convention .
La jurisprudence ajoute quune fois le dommage dtermin dans sa nature et son tendue, il
importe uniquement dassurer la victime une indemnisation intgrale par le versement de
lquivalent montaire dudit dommage au jour de sa rparation (Cass. Com. 16 fvrier
1954).
A lvidence, le remboursement des factures payes par le client, ainsi que lmission
dventuels avoirs en compensation des factures mises, mais refuses par le client, ne
correspondent quaux restitutions qui accompagnent toute rsolution contractuelle. Le
progiciel nayant pas t livr ni mis en production, il est normal que sa contrepartie
contractuelle, le paiement du prix, soit galement remis en cause. Il sagit de la consquence
ultime de lexception dinexcution, car la cause du paiement disparat dfinitivement.
Dans un arrt du 7 octobre 2008, la Cour de cassation a dailleurs rappel cette distinction
essentielle entre la restitution et lindemnisation, en traitant dune part de la question des
restitutions croises conscutives la rsolution du contrat de fourniture dun systme
informatique, et dautre part la question de lindemnisation des prjudices subis par le client.
Chaque projet ERP est unique, car il correspond toujours une entreprise particulire, avec
son organisation, ses mthodes, ses ressources, ses besoins, ses contraintes. La gamme des
prjudices ventuellement occasionns par un chec du projet informatique est donc trs
varie. A titre dexemple, larrt de la Cour dappel de Paris du 19 janvier 2011 (Ple 5
chambre 10, Comexposium / Axe Selection, Expertises n360, juillet 2011) illustre cette
varit des postes de prjudice en cas dchec dun projet ERP.
Nanmoins, il est possible de classifier les catgories de prjudices envisageables, entre cot
humain, cot matriel (et logiciel), consquences sur la production, et gain de productivit
manqu. Il faut ainsi pouvoir identifier toute dpense, tout investissement qui est directement
li au projet informatique, et qui est expos en pure perte si le projet informatique naboutit
pas.
A titre dexemple, on doit considrer que le temps consacr par les quipes du client (sa DSI
mais galement ses diffrents mtiers ds lors quils doivent exprimer leurs besoins) la
constitution du cahier des charges, est directement li au projet informatique, puisquil en
concrtise la conception initiale. Si lentreprise ne met jamais le progiciel en uvre, le temps
pass rdiger le cahier des charges est perdu. A lvidence, il en va de mme du temps
consacr par les prposs de lentreprise analyser loffre du prestataire, la ngocier ou
demander des claircissements.
Une fois les prestations engages, et comme rappel plus haut, le client doit ddier des
quipes lexcution de son obligation de collaboration, en rpondant aux questions
complmentaires du prestataire, en participant aux ateliers de spcifications, bref en
accompagnant le prestataire dans sa phase danalyse des pratiques de lentreprise. L encore,
le temps consacr par les quipes ces diligences nest pas consacr autre chose.
Tout manquement cette obligation de collaboration peut avoir un impact trs fort sur le
Pour en revenir aux prjudices du client, lachat de matriels ou de logiciels (non compris
dans le primtre ddes fournitures du prestataire) constitue bien entendu une autre catgorie
de dpenses intrinsquement lie au projet, et ce dautant plus que cet achat est parfois
prconis par lintgrateur. A moins que le client ait lopportunit de rutiliser diffremment
ces achats aprs lchec du projet (on peut prendre l'exemple des baies qui illustre cet article),
il faut considrer quils ont t contracts en vain. A cet gard, le prjudice peut aller trs loin,
compte tenu des cots du matriel informatique, mais aussi des contrats ventuellement
conclus avec dautres prestataires (mise en place dun rseau de communications
lectroniques, fournitures diverses, etc.).
Si ces phases naboutissent pas un progiciel oprationnel, il faut considrer que ce travail en
mode dgrad a fait perdre en productivit. Il sagit dun mal ncessaire si le projet est un
succs, qui sera compens par les gains de productivit futurs mais si le projet choue, il
sagit encore dune pesanteur subie en pure perte, linstar dune baie de serveurs achete en
vain.
Au lieu de leur faire gagner du temps, le progiciel conduit les quipes du client en perdre sur
leur travail quotidien, parce quils doivent vrifier les rsultats des traitements effectus via le
progiciel, sans parler de la dmotivation qui risque daccompagner une phase de qualification
trop fastidieuse. Les aspects psychologiques de limplmentation dun nouveau progiciel sont
extrmement importants, et il nest pas rare de voir les cocontractants se reprocher
mutuellement une absence de motivation
Il faut ici faire un sort lillusion, invoque par certains plaideurs, qui rside dans
laffirmation que les salaires verss par le client ses prposs auraient t pays en toute
hypothse , pour contester que le temps pass par les quipes du client puisse constituer un
prjudice, puisquen toute hypothse, lentreprise tait tenue de payer ses salaris. Cette
dfense relve du sophisme : certes les salaris auraient naturellement t pays, mais ils
auraient bien entendu consacr leur temps de travail rmunr dautres tches, qui elles,
auraient contribu augmenter les rsultats de lentreprise. A linverse, quatre mois passs
participer aux ateliers de spcification dun progiciel qui nest finalement jamais livr, sont
quatre mois perdus. Le salari a perdu son temps ; lentreprise a perdu les salaires qui
correspondent au temps perdu par ses employs.
Enfin, certains juges admettent mme que le temps pass rechercher un nouveau progiciel et
Sil est finalement ais, pour lentreprise cliente, de dcompter lensemble des dpenses
exposes en vain, elle doit toutefois observer certaines prcautions pour que ces dpenses
puissent tre ultrieurement considres comme des prjudices et recevoir une juste
compensation.
3. LES PRECAUTIONS A OBSERVER
Le client doit amnager la preuve des prjudices qu'il subit. La jurisprudence a raffirm avec
constance que le juge ne peut estimer ceux-ci de manire forfaitaire (CA Com, 24 novembre
2009, n08-16428). Les prcautions prendre, pour le client, sont de trois ordres :
Ces trois axes doivent tre perus comme des instruments dune gestion optimale du projet,
idalement confis une Direction Qualit ou un service spcialement ddi au pilotage du
projet, au titre de la matrise douvrage. Si de nombreux mtiers de lentreprise peuvent
contribuer, un stade ou un autre, au droulement du projet, il est vivement conseill quau
moins une personne conserve une vision transversale et historicise du projet.
Mais ces trois axes consistent en ralit, dun point de vue contentieux, sassurer que les
dommages ventuellement subis seront considrs comme prvisibles, directs et certains.
Cest cette tude qui permet destimer, ab initio, les cots induits par le projet, les gains de
productivit attendus, et les risques encourus en cas dchec, Il sagit dun lment fort daide
la dcision.
Il est trs important, ds avant la rdaction du contrat, didentifier avec rigueur les cots
gnrs en interne et en externe pour la prparation du projet, la slection du prestataire, et
lensemble des diligences pendant tout le projet. Tout matriel, tout service acquis aux fins de
ralisation de lERP doit tre identifi comme tel, afin dtre valoris dans la demande
dindemnisation si le projet choue. Cest le seul moyen dont le client dispose pour faire
reconnatre son dommage.
Toutes les entreprises ne souhaitent ou ne peuvent pas commander une tude dimpact
pralable au lancement de leur projet ERP. Mais tout le moins, elles doivent dcrire les
enjeux du projet et les communiquer au prestataire, afin que celui-ci ait conscience des
Larticle 1150 du Code civil dispose quon ne peut indemniser que les dommages qui ont t
prvus ou qui taient prvisibles lors de la conclusion du contrat. Il est donc capital, pour le
client, dexposer ds le contrat lensemble des enjeux techniques et conomiques que le projet
ERP revt pour lui. Il est ncessaire dinformer par crit le prestataire, dans le contrat, que
lERP command conditionne lensemble de la chane de production par exemple, et donc la
capacit du client mener ses activits.
LERP peut galement constituer la condition sine qua non dune rorganisation stratgique
de lentreprise, en vue de la conqute de nouveaux marchs. LERP peut avoir un impact sur
les personnels embauchs, et un chec du projet peut ainsi dsquilibrer les ressources
humaines de lentreprise.
Le prestataire auquel tous ces enjeux sont indiqus pourra difficilement prtendre par la suite
quil ne savait pas et le caractre impratif dune date de livraison prend alors tout son
sens, parce quil est directement corrl aux autres activits de lentreprise.
Outre la prvision des consquences en cas daccident et lindication au prestataire des enjeux
conomiques du projet, le client doit galement prendre soin de quantifier ce que le projet lui
cote, afin dtre en mesure de prsenter lensemble de ces investissements comme des
prjudices, entendus comme les pertes subies et les gains manqus de larticle 1149 du Code
civil.
Les pertes subies sentendent de toutes les dpenses exposes pour construire, suivre et
valider le projet informatique (matriels et temps humain compris), et les gains manqus
sentendent des gains de productivit que le client tait lgitimement en droit dattendre
compter de la date imprative de mise en production de lERP.
Le client que souhaite faire valoir ses prjudices doit fournir des justificatifs prcis. Plus d'une
dcision a refus l'indemnisation d'un client malheureux pour la simple raison qu'il ne
produisait pas de documents tayant son calcul de prjudice (voir par exemple CA Paris, 3e
chambre, 15 septembre 2006, n05/22450) !
A lvidence, toute dpense matrielle expose par le client sans pouvoir tre rutilise dans
un autre contexte, constitue une perte sche pour lui.
Le cot salarial peut tre double : il concerne non seulement les personnels spcialement
embauchs pour pallier les carences du prestataire (spcialistes ou intrimaires), mais
galement lensemble du temps perdu par les personnels du client dans llaboration et le
suivi du projet.
On constate ici limportance capitale qui rside des feuilles de temps de chaque collaborateur,
exposant le temps pass et le reliant directement au projet en cause (laboration du cahier des
charges et des spcifications, suivi et validations des livrables, travail en double commande
impos en raison des retards, etc.). Ce cot salarial peut dailleurs concerner une grande
varit de personnels : quipes informatiques, contrleurs de gestion, acheteurs, quipes
Afin dtablir le caractre direct du prjudice, cest--dire son lien de causalit avec lchec
du projet, il est capital que les lments de preuve produits par le client soient identifis
comme inhrents au projet. Les feuilles de temps doivent identifier les travaux du salari et
les relier expressment au projet. Les embauches ralises doivent tre traces comme tant
directement conditionnes par le projet, etc. Dans cette optique, doivent galement tre
conserves toutes les notes internes, les courriers, et bien videmment lensemble des comptes
rendus de runion et de comits de pilotage, qui se rvleront des preuves particulirement
importantes en cas de litige.
La perte prouve doit donc sentendre, au sens large, de la perte de temps et donc des cots
salariaux, des tiers inutilement associs au droulement du projet, des dpenses exposes en
vain, et mme de celles qui seront invitablement exposes lorsque le client devra prparer un
nouveau projet de modernisation informatique.
Dautres postes de prjudice sont encore envisageables, pour autant que le client ait eu la
discipline de les quantifier et de les attribuer spcifiquement son projet ERP : prjudice
dimage ; atteinte sa valorisation financire (notamment sil a dj communiqu auprs de
ses actionnaires ou du public sur sa modernisation informatique, en particulier sil est ct en
bourse) ; perte de chance, si labsence de livraison en temps et heure du progiciel fait perdre
un march au client ou lempche de rpondre avec rigueur un appel doffres, par exemple ;
bouleversement des calculs damortissement des actifs de lentreprise, etc.
Le gain manqu doit sentendre de labsence des gains de productivit attendus, et au-del de
limpossibilit doptimiser les autres investissements de lentreprise. Il doit tre indemnis en
tant que prjudice certain, par opposition la perte de chance qui ne constitue pas un
prjudice certain mais seulement potentiel.
Comme le rappelle l'Expert informatique Hubert Bitan dans son commentaire de l'arrt de la
Cour d'appel de Paris du 19 janvier 2011 (CA Paris, Ple 5 chambre 10, Comexposium / Axe
Selection, revue Lamy Droit de l'Immatriel n74 p. 43), la jurisprudence a affirm ds 1932
que la rparation d'un prjudice futur est parfaitement admissible ds lors qu'elle apparat
comme "la prolongation certaine et directe d'un tat des choses actuel et comme tant
susceptible d'estimation immdiate" - ce qui distingue le gain manqu de la perte de chance,
qui n'est qu'hypothtique et donc moins aisment prouve.
En gnral, une entreprise souhaite squiper dun ERP parce quelle souhaite amliorer sa
performance, optimiser ses flux, et bnficier dune vision transversale de son activit ce
pourquoi nous parlions dentreprise assiste par ordinateur . Rductions de stocks,
raccourcissement des processus logistiques, automatisation des plans de maintenance des
matriels, rductions dinvestissements en consquence sont autant de postes budgtaires
qui doivent tre corrls au projet dERP, et prsents au juge avec prcision.
Toutes ces prcautions permettent dassurer, le cas chant, une vritable rparation
intgrale des prjudices subis par le client. Plus linformation relative ces enjeux connexes
sera prcise, voire chiffre, plus le client aura la possibilit dtayer la ralit et la quotit des
dommages subis devant le juge. Il est important quune vocation des gains esprs figure au
contrat, afin den faire des prjudices prvisibles. Le cahier des charges, notamment, est tout
dsign cette fin. Idalement, le contrat lui-mme prcise quels sont ces enjeux.
Mais, afin que ces prcautions ne restent pas lettre morte, il est galement important de
surveiller les clauses relatives la responsabilit du prestataire, que celui-ci tient videmment
limiter du mieux quil peut. Il sagit l des clauses limitatives ou exonratoires de
responsabilit, qui nourrissent une abondante jurisprudence.
Les contrats informatiques comportent galement trs souvent des clauses relatives la
rparation des ventuels dommages provoqus par lune des parties, en particulier le
prestataire. Ces clauses sont de deux types : elles sappliquent soit ltendue de la prestation
promise, soit, de faon plus frquente, ltendue du droit rparation du client.
Ces dernires plafonnent le montant de lindemnisation que le prestataire serait amen payer
Ces clauses influent forcment sur le cot des prestations proposes, notamment parce
quelles conditionnent le montant des polices dassurances que le prestataire doit contracter.
Ces clauses participent pleinement lconomie du contrat, et le client doit avoir lesprit
quelles influent sur son quilibre.
Leur rdaction peut inclure lindemnisation du damnum emergens et exclure celle du lucrum
cessans, distinguer entre dommages directs et dommages indirects pour exclure la
rparation des seconds, plafonner le montant total de lindemnisation un multiple du
montant du contrat, laligner sur le montant de la police dassurance du prestataire, etc. Ces
clauses doivent tre examines avec soin par le client, car elles sont gnralement proposes
sinon imposes par le prestataire, et quelles seront considres comme acceptes en tant que
telles ds lors quelles figurent au contrat sign par le client.
Depuis larrt de principe Chronopost du 22 octobre 1996, et encore rcemment dans larrt
Faurecia II du 13 fvrier 2007, la Cour de cassation a rgulirement nonc que si la clause
limitative de responsabilit permettait au prestataire de choisir de ne pas excuter le
contrat, ds lors quil sait dj le cot total quune telle inexcution engendrera pour lui
puisquil la lui-mme dtermin alors cette clause a pour effet de vider le contrat de sa
substance, en tant tout caractre contraignant aux engagements contractuels du prestataire.
Certains commentateurs ont dailleurs crit que larrt Faurecia II du 13 fvrier 2007 procde
une application trop systmatique de la thorie, et anantit lintrt des clauses limitatives de
responsabilit (ou cantonne leurs effets aux seules obligations non essentielles ). Ils
sappuient volontiers sur larrt de la Cour dappel de renvoi (Paris), dit Faurecia III en
date du 26 novembre 2008, qui tente effectivement de cantonner les effets de la thorie des
obligations essentielles.
Toutefois, la Cour dappel de renvoi sest place non plus sur le terrain de lexcution
contractuelle dfaillante, mais sur le terrain de la formation du contrat, pour constater que la
clause avait t spcifiquement accepte par le client, dans un contrat o la fixation mme du
prix avait t lie la fixation du plafond de responsabilit du prestataire, de manire
explicite, pour une prise en charge partage du risque . Ainsi, la Cour a nonc que le
manquement une obligation essentielle ne peut conduire carter la clause limitative de
responsabilit que pour autant que cette clause na pas t ngocie par le client, ou si elle est
dun montant drisoire.
Selon cet arrt de la saga Faurecia, confirm par la chambre commerciale de la Cour de
Il semble toutefois prmatur de voir dans cette dcision un vritable coup darrt au
dveloppement de la thorie, dans la mesure o les faits de lespce sont assez particuliers. Le
prestataire tait en effet en mesure dtablir que le plafond dindemnisation avait t ngoci
par les parties, et expressment intgr dans lquilibre conomique du contrat.
5. CONCLUSION
Ils doivent galement tre scrupuleusement tracs et relis au projet ERP, quil sagisse des
dpenses concrtes ou de la rmunration des personnels impliqus, afin de constituer des
prjudices immdiats et directement lis lchec du projet.
Ils doivent galement tre pris en compte dans le calcul de lventuel plafond de
responsabilit du prestataire, qui aura tendance limiter celle-ci. Certes, la jurisprudence
relative aux obligations essentielles permet de combattre ces plafonds sils vident le contrat de
sa substance, mais en toute hypothse, le plafond de responsabilit doit tre pens par le client
laune de lensemble des enjeux lis au projet.
Un projet ERP ne peut ni ne doit tre conu de faon isole des autres activits de lentreprise,
parce quil les conditionne souvent toutes. Une telle rforme des pratiques de lentreprise doit
donc sentourer de toutes les prcautions possibles, et chaque euro dpens pour son succs
doit tre identifi et trac par le client afin dtre indemnis en cas dchec.
De son ct, le prestataire a tout intrt responsabiliser le client sur les tches qui incombent
celui-ci (notion de matrice des tches), et prciser de manire trs prcise les contours de
son engagement, le primtre fonctionnel et technique dont il est responsable, les
informations au vu desquelles il sengage, et les limitations de responsabilit dont il entend
assortir sa prestation, afin que chacune des deux parties sengage en pleine connaissance de
cause.
Pharma plus est une socit pharmaceutique internationale prsente commercialement et par
limplantation dusines en France, en Allemagne, aux Etats unis et au Japon. En plus de ces
implantations stratgiques, lentreprise a une prsence significative sur dautres marchs via
de petites filiales commerciales et quelques usines de conditionnement.
Travail faire
Le sige de Pharma Plus est en train de dfinir une stratgie pour son systme dinformation.
Pour cela, le sige est en train de raliser une tude des gains et des cots pour la mise en
place dun ERP au niveau europen dans un premier temps, et potentiellement un dploiement
de cet ERP sur les filiales dEurope de lEst et dAfrique du nord.
Souhaitant valuer plusieurs options, le sige considre galement une stratgie dERP par
rgion ou groupe de pays et vous demande de raliser en parallle, de votre ct, une tude
des gains apports par lERP et de ses cots pour sa mise en place au Maroc. LERP pourrait
probablement tre dploy en Algrie et en Tunisie ultrieurement.
Les processus qui doivent tre couverts par le systme dinformation sont :
- les achats (couverts par lERP), soit 3 utilisateurs ;
- les ventes (couverts par lERP), soit 3 utilisateurs ;
- les stocks (couverts par lERP), soit 3 utilisateurs ;
- la gestion des emplacements (couverts par une application logistique WMS Warehouse
Management System), soit 3 utilisateurs ;
- la production (couverts par lERP), soit 3 utilisateurs ;
- la maintenance (couverts par lERP), soit 3 utilisateurs ;
- la qualit (couverts par lERP), concernant 6 utilisateurs ;
- la distribution (couverts par lERP), concernant 6 utilisateurs ;
- la finance (couverts par lERP), concernant 3 utilisateurs.
ERP et WMS ont t choisis par le sige et vous sont imposs, la charge dtude pralable est
donc ngligeable.
Pour vous aider raliser une valuation des cots, vous avez demand vos collaborateurs
deffectuer des recherches, et ils vous ont apport les informations suivantes :
- en terme de dure, le projet devrait durer 6 mois ;
- en terme de cot de logiciel, pour lERP ou le WMS, le cot de licence est de 1000 Euros
par utilisateur, puis de 100 euros par an en cot de maintenance. Pour la base de donnes, le
cot de licence est de 5000 Euros (une licence par serveur), puis de 500 Euros par an en cot
de maintenance ;
- en terme de machine, il faudra acheter 2 serveurs de moyen gamme 10 000 Euros lunit
(dveloppement, test), et 1 serveur haut de gamme (production) 20 000 Euros. Les cots de
maintenance annuels seront de 1000 Euros pour les serveurs de moyenne gamme et de 2000
Euros pour le serveur de haute gamme ;
- il faudra galement remplacer les ordinateurs clients raison dun poste par utilisateur (cout
unitaire de remplacement de 1000 Euros par ordinateur) ;
- vous disposez dj dun rseau informatique et un audit informatique a confirm que le
rseau est suffisant.
Vous avez lanc un appel doffre 3 socits de service, dont il ressort que la charge de
consultant sera la suivante :
- pour la partie conception-organisation, il faut compter 15 jours homme par processus ;
- pour la partie ralisation, il faut compter 5 jours homme par processus ;
- pour la partie test, il faut compter 5 jours homme par processus ;
- pour le dmarrage, il faut compter 10 jours homme par processus (charge incluant les
activits de formation et de reprise de donnes). Un processus correspond une fonction de
gestion.
Les socits de service prvoient un dveloppement spcifique pour chacun des modules
production, qualit et distribution, de complexit moyenne, soit 10 jours par dveloppement.
Il faudrait aussi raliser une interface entre lERP et le WMS, soit 20 jours de ralisation.
Les trois socits de service ont confirm la dure du projet initial de 6 mois, un chef de projet
MOE tant dsign durant cette priode, o 4 techniciens de Pharma Plus seront mobiliss.
Travail faire
L'ERP sera interfac avec la majeure partie des applications mtiers utilises par S&S, comme
par exemple l'outil de dimensionnement des portiques de signalisation. S&S a compar les
systmes d'entreprise IBS ASW, IFS, Jeeves, Movex (Lawson, anciennement Intentia) et
SAP. L'tude s'est concentre sur la frquence et le type de mise jour, ainsi que sur leur
catgorie, leur primtre fonctionnel et leurs cots rels, donne extrmement rare sur le
march.
Les cots levs reprsentent la raison principale poussant les entreprises ne pas procder
aux mises jour de leur systme d'information. Jeeves est l'exception ce constat, avec un
cot de mise jour de l'ordre de 215 euros par utilisateur. Selon l'tude, ce facteur encourage
les clients Jeeves mettre jour leur systme d'entreprise plus rgulirement que les
utilisateurs d'autres solutions.
L'ge du systme et le nombre de mises jour, le niveau d'utilisation quotidienne et les
critres de maintenance ont une influence significative sur la satisfaction des clients, et sur la
productivit de l'entreprise elle-mme. La satisfaction des clients atteint 2,9 sur une chelle
allant de 0 3 parmi les utilisateurs Jeeves, suivie par une moyenne de 2,7 pour les clients
SAP, et 1,9 pour ceux d'IFS. Les clients les moins satisfaits seraient ceux de Movex et d'IBS,
avec respectivement 1,6 et 1,5 selon ltude.
Puisque les mises jour sont simples et rapides, la grande majorit des clients les mettent en
oeuvre ds leur sortie. Lavantage conomique (cot de migration) et professionnel
(productivit et comptitivit par lutilisation dune solution toujours jour) sont significatifs.
Jeeves distribue ses licences travers un rseau international dintgrateurs slectionns. Les
licences sont abordables ( partir de 1300 euros par utilisateur pour une configuration de type
ngoce) et la qualit des intgrateurs permet de garantir un haut niveau de qualit et un
respect des dlais. Prs de 20 intgrateurs franais couvrent lintgralit du territoire.
Une tude internationale dmontre que les clients de lERP Jeeves bnficient du plus faible
cot de possession. Un cabinet indpendant dmontre les atouts de Jeeves en matire de cot
rel de possession, de productivit et de satisfaction.
La solution Jeeves
Comment bnficier dune solution technologique qui dynamise lorganisation dentreprise et
permet de conjuguer amlioration de la productivit et rduction des cots ?
Dans le cadre du dveloppement de la version 9.2 de son produit, Jeeves a concentr ses
efforts sur trois axes majeurs, plbiscits par les entreprises utilisatrices dERP, savoir :
- Dvelopper lergonomie au service de la productivit
Chose tonnante, Prodware avait jusqu'alors plutt choisi ses proies dans les spcialistes des
technologies Microsoft et Sage. En s'offrant 100% des parts d'Anelia, il renforce son
partenariat avec Sage mais met galement un pied chez SAP, la filiale d'IBM tant
distributeur valeur ajoute des solutions SAP All in One.