maîtrise d'ouvrage- maîtrise d'oeuvre - droit-ntic.com · gestion de processus de...

MMaaîîttrriissee dd’’OOuuvvrraaggee –– MMaaîîttrriissee dd’’œœuuvvrree DDaannss lleess pprroojjeettss ddee mmiissee eenn œœuuvvrree ddee SSyyssttèèmmeess dd’’IInnffoorrmmaattiioonn

DDaannss lleess pprroojjeettss ddee mmiissee eenn œœuuvvrree ddee SSyyssttèèmmeess dd’’IInnffoorrmmaattiioonn

Mémoire d’étude

2006

Thierry ROBY

• [email protected]


« … la technique pour l’Informatique (Maîtrise d’œuvre), la sémantique

pour la Maîtrise d’Ouvrage ». Michel VOLLE

Ce document provient du site Droit-Tic.com


3

Résumé.

Aujourd'hui les systèmes d'information sont de plus en plus complexes. Les

entreprises dépendent grandement voire même dangereusement du bon

fonctionnement de leur système informationnel.

Ainsi le processus d'informatisation nécessite une certaine préparation et doit

être conduit avec prudence. Cette mission est généralement confiée à une

société d'ingénierie et de conseil en informatique agissant en qualité de maître

d'oeuvre. Toutefois le maître d'oeuvre, malgré ses compétences et son

expertise notable, ne peut deviner à lui seul le besoin de son client, destinataire

du système informatique. Sans une définition précise et claire du besoin le

système ainsi mis en oeuvre risque fort de se révéler insuffisant et non

satisfaisant. Aussi le client est tenu à une nécessaire obligation de collaboration

dans la définition et la formalisation de son besoin. Cette intervention constitue

la maîtrise d'ouvrage du système.

Or en pratique il est malheureusement fréquent d'observer une grande

confusion entre la maîtrise d'oeuvre et la maîtrise d'ouvrage. En effet lorsque le

système à mettre en oeuvre s'avère complexe le client ne dispose

généralement pas des compétences suffisantes pour définir lui même son

besoin. Aussi délègue-t-il cette mission à une société de conseil en

informatique (en pratique on parle d'Assistance à Maîtrise d’Ouvrage) qui très

souvent s'avère être le même intervenant qui se chargera ensuite de la

conception. Dès lors il est facile de confondre la définition du besoin (maîtrise

d’ouvrage) et la conception entendue au sens large (maîtrise d’oeuvre).

Il est donc indispensable de clarifier au mieux la nature précise de l'intervention

concernée pour déterminer l'étendue de la responsabilité envisagée.



4

Sommaire.

Introduction Générale. ……………………………………………………………. p 6

1ère Partie. Maîtrise d’Ouvrage – Maîtrise d’œuvre

Introduction. ………………………………………………………………………… p 8

1ère sous partie : Maîtrise d’Ouvrage … …………………………………………. p 10

I § Son rôle : De la formulation du besoin à la réception du système.

II § La Maîtrise d’Ouvrage en interne ou « externalisée »

2ème sous partie : Maîtrise d’Oeuvre ………………………………………………. p 20

I § Son rôle : De l’évaluation du besoin à la réalisation du système.

II § La responsabilité de la Maîtrise d’œuvre …

Conclusion de la 1ère partie. …………………….………………………………….. p 30

2ème Partie. Périmètre d’intervention : prérogatives et obligations

1ère sous partie : Définition du périmètre d’Intervention : rôle et responsabilité .. p 34

I § Délimitation du rôle de chacun

II § Délimitation des responsabilités respectives

2ème sous partie : Organisation des relations contractuelles ……………………. p 43

I § Dans le cadre de relations contractuelles multiples

II § Dans le cadre d’un contrat « Clé en main »

Conclusion de la 2ème partie ………………………………………………………… p 56

Conclusion Générale. ………………………………………………………………… p 57

Annexes ………………………………………………………………………………… p 59



5

DDaannss lleess pprroojjeettss ddee llaa mmiissee eenn œœuuvvrree ddee SSyyssttèèmmeess dd’’IInnffoorrmmaattiioonn



6

Introduction.

A l’époque actuelle et depuis plus de vingt ans nous sommes entrés dans l’ère

de l’informatique, c'est-à-dire le traitement automatique de l’information par des

méthodes mathématiques. L’informatique est présente partout dans notre vie

quotidienne. Nous vivons en effet dans une « Société de l’Information »1.

Depuis le début de l’Humanité la conservation de l’information a pris des formes

différentes, selon l’époque et les moyens techniques disponibles, de la simple

transmission orale au support papier et aujourd’hui la technologie numérique.

Ainsi de nos jours on ne peut nier que l’information soit une ressource

importante, notamment à notre activité économique (exploitation de fichiers

clients, brevet, savoir-faire …) nécessitant un outil informatique capable de

collecter, transporter, traiter et stocker l’information afin d’en améliorer la

gestion tout en réduisant les coûts, tendant toujours plus vers un traitement

« zéro papier » (stratégie de réduction de la quantité de documents imprimés )

et la dématérialisation totale des processus de gestion de l’information. Au fur

et à mesure de l’évolution technologique le besoin s’est étoffé et les systèmes

d’information sont ainsi devenus de plus en plus complexes afin de répondre

aux attentes des utilisateurs tout en garantissant l’intégrité des informations

traitées face aux risques d’atteintes frauduleuses (virus, hackers …). Ainsi quel

que soit le système d’information les objectifs sont ambitieux et la mise en place

généralement délicate. Or les entreprises dépendent grandement, voire

dangereusement, du bon fonctionnement de leur système d’information

(logiciel, fichier client …) et dont la défaillance est susceptible d’engendrer une

importante désorganisation ainsi qu’un préjudice financier conséquent. En effet

l’Informatique dans les entreprises est aujourd’hui une réalité que ce soit pour la

gestion de processus de production, la comptabilité, la gestion des stocks ou la

relation avec les clients. Dans ce cas on recherchera naturellement la

responsabilité du ou des professionnel(s) qui auront participé à la mise en

œuvre du système d’information. Pour cela il conviendra d’étudier les termes du

1 - Sommet Mondial de la Société de l’Information ( SMSI ) qui s’est tenu à TUNIS du 16 au 18 novembre 2005



7

contrat liant le prestataire à son client. Pourtant il faut remarquer que les

engagements pris sont généralement assez peu précis. Dès lors il n’est pas

toujours évident de déterminer ce qui avait été convenu et donc d’établir si la

prestation a été ou non correctement exécutée. Aussi la jurisprudence a

dégagé à la charge du prestataire informatique une obligation générale de

conseil sans toutefois exonérer le client d’une nécessaire collaboration. Pour

autant les causes possibles d’échec sont multiples. On pensera bien entendu à

un défaut de conception ou à un contrôle insuffisant ou inapproprié des

différents intervenants. Ce qu’on appelle la maîtrise d’œuvre. Or la pratique

montre que la réussite d’un projet informatique dépend avant tout d’une bonne

définition du besoin, qui s’avère souvent insuffisante. Cette mission qui

constitue la maîtrise d’ouvrage doit être menée en principe par le client. En effet

les fonctions de maîtrise d’ouvrage et de maîtrise d’œuvre sont distinctes. Mais

la frontière de ces deux métiers n’est pas toujours évidente à tracer, notamment

lorsque le client se fait aider pour sa maîtrise d’ouvrage par une société de

conseil. Aussi malheureusement en pratique on observe fréquemment une

certaine confusion entre le maître d’ouvrage et le maître d’œuvre, notamment

dans le cadre des contrats « Clé en Main ». Cette confusion conduit

généralement à des conflits entre les différents intervenants avec pour

conséquence l’échec du projet. En effet la définition précise des rôles,

obligations et prérogatives respectives, de chacun s’avère souvent délicate

notamment dans le cadre de la définition du besoin : S’agit-il d’une fonction

relevant d’une mission de conception entendue au sens large (maîtrise

d’œuvre) ou de la formulation du besoin (maîtrise d’ouvrage) ? De même la

validation du système d’information relève-t-elle du client ou du professionnel

chargé de l’accompagnement du projet ? La réponse ne semble pas évidente. Il

faut en effet reconnaître que les implications du maître d’ouvrage et du maître

d’œuvre semblent souvent se superposer et empiéter l’une sur l’autre.

C’est pourquoi nous allons définir les missions relevant de la maîtrise

d’ouvrage et de la maîtrise d’œuvre ainsi que les obligations qui en

découlent (1ère Partie) afin de mieux cerner le périmètre d’intervention

de chacun d’eux et leur responsabilité respective (2ème Partie).



8

Classiquement on pourrait croire que le rôle du maître d’ouvrage consiste

uniquement à définir son besoin et ensuite à contrôler la conformité du système

d’Information mis en œuvre aux objectifs définis. Envisagée ainsi le maître

d’œuvre se contenterait de réaliser techniquement la solution et à la livrer au

client conformément à la demande de celui-ci. La pratique montre que cette

vision est erronée. En effet le maître d’ouvrage et le maître d’œuvre sont

associés dès le commencement du projet et collaborent durant tout le

processus de mise en œuvre. Le maître d’ouvrage, responsable du processus

de production, exprimera ainsi ses attentes, ses besoins (stratégiques,

fonctionnels …). Dès lors le maître d’œuvre, garant de la qualité (technique) du

produit, assistera son client dans la définition du besoin afin de lui proposer la

meilleure solution technique. Nous allons donc définir l’étendue de la mission et

des responsabilités respectives de la maîtrise d’ouvrage (Sous Partie 1) et du

maître d’œuvre (Sous Partie 2).



9

MMaaîîttrriissee dd’’OOuuvvrraaggee –– MMaaîîttrriissee dd’’œœuuvvrree DDaannss lleess pprroojjeettss ddee llaa mmiissee eenn œœuuvvrree ddee SSyyssttèèmmeess dd’’IInnffoorrmmaattiioonn



10

La Maîtrise d’ouvrage ...

Nous l’avons évoqué la réussite du projet informatique dépend essentiellement

d’une bonne définition du besoin, ce qu’on appelle la maîtrise d’ouvrage. Cette

phase est indispensable afin de bien définir les objectifs ainsi que les moyens

mis à disposition pour satisfaire ce besoin. Cette mission est déterminante et

conditionne la suite du projet. En principe ce travail revient au client,

destinataire du système d’information, qui doit « définir ses besoins réels et les

objectifs à atteindre en précisant clairement la nature et l’importance des

travaux qu’elle souhaite voir mécaniser, (…) définir de façon précise, eu égard

à son organisation et à ses problèmes spécifiques, tous les éléments

susceptibles d’affecter la solution proposée »2. Néanmoins l’informatique étant

une technique en constante évolution, peu accessible aux non initiés et le client

ne disposant pas toujours d’un service informatique en mesure de réaliser ce

travail d’analyse, il devra très souvent recourir aux services d’une entreprise

spécialisée3. Aussi après avoir évoqué en quoi consiste la maîtrise d’ouvrage (I)

nous envisagerons les conséquences juridiques selon que la Maîtrise

d’Ouvrage sera assumée par le client lui-même ou déléguée à un prestataire

spécialisé ( II ).

I§ – La Maîtrise d’Ouvrage : une fonction essentielle et déterminante

On parle couramment de la maîtrise d’ouvrage. Or il faut remarquer en pratique

qu’il y a non pas une mais des maîtrises d’ouvrage 4 intervenant aux différentes

étapes du projet. Ces différents intervenants participeront ainsi à la définition du

besoin ( A ) et au contrôle de conformité du système mis en œuvre au regard

des objectifs fixés ( B).

2 - CA Paris 5ème ch. C, 15 juin 1990, Sté ADT Consultants c/ Sté COM et COM 3 - CA Paris 5ème ch, 24 mai 1977, Thirouard Promill c / Singer Informatique, Juris-Data, n° 480 ; CA Versailles 13ème ch, 6 janvier 1989, Sté Eficor c/Sté Sligos, Juris-Data, n° 40205. 4 - « De l’Informatique ( savoir vivre avec l’automate ) » - Michel VOLLE, éditions économica 2006, chapitre 12



11

A – Définition et formalisation du besoin :

La maîtrise d’ouvrage consiste tout d’abord à définir les enjeux et les

objectifs (stratégiques, fonctionnels) ainsi que les moyens permettant de

répondre à ce besoin (humains, techniques, financiers …). Ce qu’on appelle en

pratique la maîtrise d’ouvrage stratégique (MOAS ou maîtrise d’ouvrage

décisionnelle) consiste tout d’abord à déterminer le rôle (la fonction stratégique)

que l’on souhaite attribuer au système d’information (objet communicant ou

multimédia, gestion de la comptabilité ou du stock, gestion et exploitation des

données « client », échange et partage de données entre les utilisateurs,

collecte et gestion de commandes de la part des clients). Il s’agira bien souvent

d’offrir de nouveaux services ou d’améliorer l’efficacité des services existants.

Une fois les objectifs stratégiques déterminés il conviendra d’établir les

méthodes nécessaires à une définition rigoureuse du besoin (modélisation), au

contrôle du projet et des différents prestataires et enfin à la prise en main du

système d’Information par les utilisateurs. C’est ce que l’on appelle la maîtrise

d’ouvrage déléguée, qui consiste à définir un cadre méthodologique et formel à

la maîtrise d’ouvrage (définition des méthodes, rédaction de la documentation,

négociation de contrats, pilotage du projet …).

Nous l’avons dit la mise en place d’un système d’information est souvent

délicate en raison de nombreuses contraintes. En effet il conviendra d’évaluer

les contraintes d’exploitation, c'est-à-dire l’ensemble des paramètres liés à

certaines exigences en terme de sécurité, de performances, d’adaptabilité,

interaction entre le système d’exploitation et les applications … En effet

aujourd’hui la problématique de sécurité représente un enjeu majeur en raison

de la responsabilisation grandissante des gestionnaires de systèmes

d’information 5 et de l’importance considérable des dommages consécutifs à

une attaque informatique ( virus, spyware, hacking … ). Aussi il est primordial

d’assurer « la sécurité des données et notamment d’empêcher qu’elles soient

déformées, endommagées ou que des tiers non autorisés y aient accès ». En

outre il est nécessaire d’envisager la reprise des données du système existant.

Ces informations constituent un actif économique vital pour l’entreprise. Il est

5 - voir notamment article de Me Isabelle RENARD JDN 23/01/2003, art 34 de la loi CNIL n° 78-17 du 6 janvier 1978.



12

donc indispensable d’analyser le système existant (système d’exploitation,

données pertinentes, type de fichier, existence d’une base de données, format)

afin d’évaluer les moyens de récupérer les données et de les transférer vers le

nouveau système mis en place. Ces différentes missions seront prises en

charge par un ou plusieurs Assistant(s) à maîtrise d’ouvrage (consultant en

sécurité, chargé de la modélisation du système, urbaniste ...).

On doit également remarquer que la réussite du projet informatique

dépend avant tout de l’adhésion des utilisateurs. En effet l’objectif principal d’un

système d’information consiste à alléger au maximum la gestion. Pour se faire

le système d’information doit mettre à disposition des utilisateurs l’ensemble

des ressources dont ils auront besoin. Or dans la plupart des cas les utilisateurs

disposent de compétences informatiques limitées. Il est donc indispensable

d’envisager un outil d’utilisation simple et fonctionnelle afin d’éviter le risque de

rejet des utilisateurs. C’est pourquoi il est très important d’identifier les

contraintes d’utilisation, c’est à dire les impératifs fonctionnels et

ergonomiques liés au profil des utilisateurs. En effet le système est destiné à

des utilisateurs et devra donc répondre le plus possible à leurs attentes. On

rajoutera que la mise à disposition d’un système « intuitif » permettra de réduire

les coûts de formation des utilisateurs. Il sera donc nécessaire de collecter leurs

souhaits, évaluer leur réaction face à l’outil informatique et ainsi déterminer les

exigences spécifiques en matière de convivialité et d’ergonomie, coordonner

ces informations et éventuellement arbitrer lorsque la demande des utilisateurs

« dérape ». Cette fonction revient à la maîtrise d’ouvrage opérationnelle qui

arbitrera les demandes sous le contrôle de la maîtrise d’ouvrage stratégique et

selon la méthodologie définie par la maîtrise d’ouvrage opérationnelle.

Au terme de ce travail d’analyse la maîtrise d’ouvrage rédige les spécifications

générales du cahier des charges exprimant le besoin (stratégique, fonctionnel).

Le maître d’œuvre reprendra ensuite ces spécifications en les précisant afin

d’établir une proposition de réalisation (technique) et déterminer ainsi une

estimation prévisionnelle du coût du projet. Ces spécifications détaillées devront

être validées par le maître d’ouvrage qui confirmera ainsi l’adéquation entre son

besoin et la proposition établie ainsi que son coût prévisionnel.



13

Dès lors les ambitions devront être réduites si celles-ci ne correspondaient pas

aux moyens financiers disponibles. Le cahier des charges est donc un

document essentiel qui servira de feuille de route au maître d’ouvrage et au

maître d’œuvre durant tout le projet.

B – Réception de l’ouvrage et contrôle de conformité :

Une fois le système mis en œuvre et livré le maître d’ouvrage contrôle la

conformité du système (en terme de fonctions, de disponibilité, de

performances et de sécurité) au besoin. En pratique on parle de remise de

recettes. Le système livré devra donc comprendre toutes les fonctions

envisagées, opérationnelles et disponibles. Or il est fréquent que le client, se

considérant insatisfait du fonctionnement de son système Informationnel,

prétende que la solution livrée n'était pas conforme à ce qu'il désirait6. En tout

état de cause le défaut de conformité s'appréciera au regard du cahier des

charges et à la précision du contrôle établi lors de la réception du système par

le client. Le maître d’ouvrage devra donc déterminer les jeux de tests qui

permettront d’établir la conformité (fonctionnelle) du système d’information au

besoin défini dans le cahier des charges.

La remise des recettes est donc une étape importante durant laquelle le maître

d’ouvrage, ou son représentant, devra valider l’ensemble du système

d’information et noter les éventuels dysfonctionnements ou les carences

fonctionnelles au regard du besoin des utilisateurs. La validation des recettes

engage donc le maître d’ouvrage et rend délicat un recours ultérieur contre le

maître d’œuvre7. Il faut également remarquer que l’échec du projet peut avoir

pour cause le rejet du système mis en oeuvre par les utilisateurs. En effet il

existe généralement une certaine incompréhension et de nombreux doutes

quant aux véritables objectifs (amélioration de la gestion, de la rentabilité,

contrôle accru des salariés). Aussi il faudra préparer la mise en place du

système d’information auprès des utilisateurs en expliquant les enjeux

(stratégiques et fonctionnels) 8 et ensuite les former à l’utilisation du système.

6 - En ce sens l’article de Me Marc d’Haultfoeuille paru dans le Journal du Net le 8/11/2005 7 - CA Paris 8 mars 1983 8 - « La conduite du changement, enjeu de l’adhésion des utilisateurs » JDN



14

La maîtrise d’ouvrage peut être effectuée par le client lui-même (en interne).

Mais très souvent la complexité du système à mettre en œuvre oblige le client à

faire recours aux services d’une société de conseil en informatique9 pour

l’assister dans sa maîtrise d’ouvrage. Bien entendu les possibilités de recours

éventuels seront différentes selon que la maîtrise d’ouvrage sera conduite par

les propres services du client (A) ou par un prestataire chargé de l’assistance à

maîtrise d’ouvrage (B).

II§ – Maîtrise d’ouvrage en Interne ou externalisée :

A – La Maîtrise d’Ouvrage :

Comme nous l’avons déjà évoqué le Maître d’Ouvrage est l’entité

porteuse du besoin, définissant les objectifs (stratégiques, fonctionnels), ainsi

que les moyens mis à disposition (moyens humains et techniques, délai,

budget) pour la réalisation des objectifs fixés. La maîtrise d’ouvrage revient

donc en principe au client qui peut définir son besoin par ses propres moyens.

Bien entendu la définition du besoin par le client lui même présente l’avantage

d’une parfaite connaissance du métier et ainsi en théorie une juste évaluation

des fonctionnalités nécessaires. Néanmoins la pratique démontre que cette

mission requiert des compétences spécifiques (en terme de méthodologie et

pédagogie auprès des utilisateurs finaux notamment) dont le client ne dispose

généralement pas. En effet une définition insuffisante engagera la

responsabilité du client au titre de son obligation de collaboration envers le

maître d’œuvre chargé de la conception sans toutefois dégager le professionnel

de l’obligation de mettre en garde sur les carences et les insuffisances du

cahier des charges10. Dans cette situation aucun recours n’est envisageable

dans la mesure où il existe un lien de subordination dans le cadre du contrat de

travail entre le client décideur du projet et les agents chargés de la formalisation

du besoin et du contrôle de conformité. En effet sauf faute lourde, l’employeur

est responsable des fautes de ses subordonnés (article 1384 Code Civil). C’est

pourquoi il est souvent préférable de faire appel à une société spécialisée

notamment pour la définition du besoin.

9 - CA Paris 5ème ch, 24 mai 1977, Thirouard Promill c / Singer Informatique, CA Versailles 23ème ch, 6 janvier 1989, Sté Eficor c/Sté Sligos 10 - CA Paris 5ème ch. B, 31 janv 1986, Sté Comptoir de l’automobile c / Sté Kienzle Informatique



15

B – La Maîtrise d’Ouvrage « externalisée » :

Comme nous venons de l’évoquer le client peut déléguer tout ou partie de la

maîtrise d’ouvrage à une société spécialisée en conseil en Informatique. Le

conseil s’engage à fournir à son client les éléments lui permettant de prendre

des décisions éclairées. Ainsi il devra l’aider à formaliser le plus précisément

possible son besoin, l’informer sur les conséquences selon le choix technique

envisagé. L’analyse du besoin sera limitée à certains aspects techniques ou

envisagée d’une manière générale, selon la complexité de l’ouvrage et les

moyens financiers disponibles. En pratique on parle également « d’Assistance à

Maîtrise d’ouvrage ». Curieusement malgré l’importance déterminante de cette

prestation dans le processus d’informatisation peu d’études sont consacrées

aux contrats de conseil en informatique11. Pourtant il est nécessaire d’en

déterminer la nature juridique afin de mesurer les obligations qui en découlent.

Le doyen Savatier avait évoqué la notion de « Vente de services » ce qui

semble aujourd’hui écartée par la majorité de la doctrine12. On pourrait

également penser qu’il s’agit d’un contrat de mandat. Pourtant on doit

remarquer que le plus souvent le contrat de conseil prévoit l’accomplissement

d’actes strictement matériels (études, rédaction du cahier des charges) et non

juridiques. Il semble donc établi que généralement ces contrats relèvent des

contrats d’entreprise13 à moins que le prestataire ne soit amené à représenter le

maître d’ouvrage (notamment à l’occasion de la remise des recettes). A priori

nous pouvons définir le contrat de conseil en informatique comme un contrat de

prestation de service réalisé de manière indépendante et à titre onéreux par

lequel le prestataire (conseil en informatique) s’engage à mettre à disposition

du client son savoir faire ainsi que ses moyens humains et techniques

nécessaires à l’analyse de son besoin défini dans un document technique et le

contrôle de conformité du système mis en oeuvre.

11 - Geneviève VINEY « La responsabilité des entreprises prestataires de conseil » JCP éd G 1975, I, n° 2750 12 - De Lamberterie I « Les Techniques Contractuelles suscitées par l’Informatique » Thèse Paris 1977, Malaurie et Aynès - Contrats Spéciaux Cujas 1996 13 - Lamy Droit de l’informatique et des réseaux 1999 – « Les Contrats de conseil en informatique »



16

Aussi dans le cadre de sa mission de maîtrise d’ouvrage le professionnel est

principalement tenu d’une forte obligation de conseil (1.1), qui peut s’étendre à

une obligation en tant que mandataire (1.2), sans exclure une nécessaire

collaboration de la part du client (2).

1.1 – Une obligation générale de conseil …

A l’occasion de cette mission l’assistant à maîtrise d’ouvrage est tenu à une

obligation générale de conseil14 selon les règles de l’art en vigueur dans la

profession15. Ce devoir de conseil consiste en une obligation de moyens16, à

moins que le prestataire ne se soit engagé explicitement à atteindre un résultat

déterminé. En effet, de par la complexité du travail et la nécessité d’une

collaboration active du client, ce contrat comporte un fort aléa et ne saurait

donc en principe donner lieu à la promesse d’un résultat certain17.

Cette obligation de conseil varie en intensité selon l’importance du

fonctionnement du système d’Information pour la continuité de l’activité du

client. Il devra dans tous les cas informer le client (a) et attirer son attention sur

les conséquences éventuelles de la solution informatique proposée (b).

a ) Le devoir d’information :

Le prestataire devra tout d’abord aider, assister son client dans la formulation

précise de son besoin. Par la suite il devra attirer l’attention de son client sur les

contraintes d’exploitation ( sécurité, performances, compatibilité avec des

applications tierces, degré de complexité de mise en place ) ainsi que les

implications juridiques 18 ( protection des données nominatives à caractère

personnel, droits d’utilisation octroyés par la licence du logiciel, accès au code

source et possibilité d’adapter librement le système selon l’évolution des

besoins … ) voire financières ( crédit-bail ou location du matériel, coût de

maintenance … ). Cette obligation d’information implique que le contenu du

cahier des charges soit compréhensible du client afin qu’il puisse le valider en

toute connaissance de cause19.

14 - De Lamberterie I, « Les techniques contractuelles suscitées par l’informatique », Thèse, Paris, 1977, p 212 et s, 15 - règles éditées par le SNICAF ( Syndicat des Conseils en Informatique ) 16 - CA Lyon, 2ème ch. 23 déc 1969, JCP éd G 1970, II, n° 16557 ; CA Paris, 25ème ch. A 23 janv 1990 17 - T Com 1ère ch 19 avril 1971, JCP éd G 1971 ; CA Paris 1ère ch 12 juillet 1972 Sté Flammarion / IBM 18 - Lamy Droit de L’Informatique et des réseaux 1999 – « Valeurs Informatiques et Libertés ». 19 - CA 1ère ch, A , sect urg 22 avril 1980 Sté Olivetti / Karpathios



17

Ce devoir d’information peut se transformer, selon la complexité de l’ouvrage

informatique et l’importance de sa mise en place pour l’activité du client, en

véritable obligation de mise en garde.

b ) La mise en garde :

En effet l’informatisation est souvent accompagnée d’un sentiment plus ou

moins irrationnel qui conduit le client à n’envisager que les avantages certains

de l’informatisation en refusant d’évaluer les incidences négatives ou

perturbatrices possibles. Or la pratique a montré et montre encore que

l’informatisation, si elle n’est pas correctement menée, peut conduire à une

grave désorganisation de l’entreprise et avoir des incidences sur son activité.

Aussi le prestataire doit-il tempérer l’enthousiasme excessif de son client et

l’alerter sur les difficultés possibles que peuvent engendrer les opérations

d’informatisation. Il devra ainsi évoquer d’éventuelles perturbations au regard

des exigences particulières (en terme de sécurité, performances, disponibilité,

évolutivité …). Aussi plus le processus d’informatisation et son bon

fonctionnement seront nécessaires à la continuité de l’activité de l’entreprise,

plus cette obligation de mise en garde sera contraignante. Dans certains cas, le

prestataire peut également être amené à représenter juridiquement son client.

1.2 – obligation de mandataire :

Lorsque le conseil en informatique est amené à représenter son client il agi

dans le cadre d’un mandat ( art 1984 C Civ ). Ça pourrait être le cas par

exemple lors de la remise des recettes (validation du système une fois

réceptionné). En effet nous l’avons déjà évoqué, une fois le système réalisé et

livré, l’assistant du maître d’ouvrage contrôle la conformité du système au

cahier des charges. Il s’agira donc a priori que d’une assistance technique

(étude, réalisation de documentation, des jeux de tests et d’essai,

établissement et contrôle des recettes fonctionnelles). Toutefois suivant la

nature de son intervention on peut être amené à se demander si l’assistant

n’agit pas en tant que mandataire de son client lors de la réception de

l’ouvrage. Au cas où des défaillances apparues lors de la livraison n’auraient

pas fait l’objet de réserves de la part du mandataire celui-ci engagera sa



18

responsabilité envers le client pour avoir manqué à sa mission de contrôle20. En

effet le professionnel aura validé le système pour le compte de son client21

rendant tous recours ultérieurs contre le maître d’œuvre, chargé de la

conception, impossibles. Le mandataire est donc responsable envers le

mandant du dommage causé lorsqu’il n’a pas correctement rempli sa mission,

même si elle n’est ni dolosive, ni lourde, ni grave22. Bien évidemment le

professionnel ne peut deviner seul le besoin de son client. C’est pourquoi le

client ne saurait reprocher au prestataire une quelconque carence dans la

définition de son besoin sans y avoir lui-même activement participé23.

2 - Obligation de collaboration du client :

Comme nous l’avons dit plus haut le client délègue uniquement l’aspect

technique de cette mission (méthodologie, analyse fonctionnelle et organique)

mais reste maître de l’ouvrage à mettre en place et est donc seul en mesure de

déterminer son besoin réel. En effet la société utilisatrice « Maîtresse de son

entreprise qui, seule avait en conséquence le contrôle et la responsabilité de

cette organisation et à qui il appartenait de prendre les mesures propres à la

réalisation de cette adaptation (…) »24. Le client devra donc collaborer

étroitement et franchement avec le prestataire en exprimant clairement ses

attentes, son besoin25, en l’informant du fonctionnement de son entreprise

(organigramme, réaction face à l’outil informatique et niveau de compétence

des cadres et salariés destinataires du système) et en faisant en sorte que ses

collaborateurs soient disponibles aux éventuelles demandes d’information26.

Comme nous l’avons évoqué les conséquences juridiques sont différentes

selon que la maîtrise d’ouvrage sera réalisée en interne ou de manière

indépendante par un prestataire externe. Pourtant en pratique les choses ne

sont pas aussi claires. En effet cette mission peut être effectuée dans le cadre

de ce qu’on appelle le portage salarial ou en régie, par lequel un consultant se

20 - art 1993 Code Civil 21 - art 1998 du Code Civil ; Civ 1er 26 janvier 1999, BI n° 30 22 - art 1991 et 1992 du Code Civil 23 - Cass 1ère civ 21 déc 1964, n° 63-11-065, JCP éd G 1965, II, n° 14005; CA Paris 25ème ch B, 7 juillet 1989, Sté Pragama et autre c/Sté Casanova, Jurisdata, n° 24805 24 - CA 15ème ch, 21 juin 1971, JCP éd g 1972, II N° 17138, note Mégret 25 - Com 1ère ch 19 avril 1971, JCP éd G 1971, CA Paris 1ère ch 12 juillet 1972, Sté Flammarion / IBM 26 –CA Paris 5ème ch B, 30 juin 1983 Passeport c/ KIENZLE Informatique ; CA Paris 26 mars 1987, Sté Polytitan et autre c/ Sté Robotique et autres D 1987 IR p 111; CA Paris 5èch A 10 mai 1988, SA Leprince c/SA Olivetti D 1988 IR



19

fait embaucher par une entreprise qui facture des honoraires au client chez qui

le consultant intervient. On peut donc se demander si le consultant ne dépend

pas de l’entreprise cliente chez qui il intervient. En effet généralement il

possède un bureau, un email au nom de la société et intervient au sein de la

société de manière semblable à un salarié. Néanmoins dès lors que le

consultant ne rend pas de compte directement de ses actes au client27 il reste

exclusivement subordonné à l’entreprise, qui facture sa mission de conseil, et

avec laquelle il a signé un contrat de travail. Aussi en cas de mauvaise

exécution ou d’inexécution l’entreprise, qui aura facturée l’intervention de son

consultant, sera seule responsable auprès du client de la même manière que

nous venons de voir plus haut.

Nous venons de le voir la maîtrise d’ouvrage est déterminante et engage la

responsabilité du client. L’assistant à maîtrise d’ouvrage (externe) sera un

intermédiaire privilégié entre le maître d’ouvrage et le maître d’œuvre. Chargé

d’assister le maître d’ouvrage dans la définition de son besoin et/ou lors de la

remise des recettes il devra conseiller au mieux son client et établir ainsi un

véritable dialogue en étroite collaboration avec le maître d’œuvre afin d’aboutir

à la mise en œuvre d’un système d’Information correspondant au besoin.

Responsable de la qualité (technique) du produit livré, le maître d’œuvre devra

ainsi évaluer, en collaboration avec le maître d’ouvrage, la meilleure solution et

la réaliser.

27 - Cass, soc 1er déc 1976, N° 75-12.965, Gaz Pal 1977



20

MMaaîîttrriissee dd’’OOuuvvrraaggee –– MMaaîîttrriissee dd’’œœuuvvrree DDaannss lleess pprroojjeettss ddee llaa mmiissee eenn œœuuvvrree ddee SSyyssttèèmmeess dd’’IInnffoorrmmaattiioonn



21

La Maîtrise d’œuvre ...

Nous venons de le voir le rôle du maître d’ouvrage est essentiel durant le

déroulement du projet Informatique. Le rôle du maître d’œuvre28 n’en est pas

moins un élément déterminant dans la réussite du projet. La maîtrise d’œuvre

peut être interne, généralement pris en charge par le DSI (non évoquée dans

cette étude). Mais bien souvent les compétences nécessaires, le manque de

disponibilité des services internes (qui doivent gérés l’exploitation et la

maintenance du système), la problématique juridique en cas d’échec, incitent le

client à faire recours à un prestataire externe pour remplir cette mission. Chargé

de garantir la bonne fin du projet en réunissant les compétences et les moyens

nécessaires à l’atteinte des objectifs fixés par la maîtrise d’ouvrage il sera

amené à assumer une mission généralement vaste, de conception,

d’accompagnement (coordination des différents intervenants), voire de mise en

œuvre d’un système d’information « Clé en Main ». Cette mission est donc

cruciale et la responsabilité qui en découle importante. C’est pourquoi après

avoir envisagé l’étendue éventuelle de la mission du maître d’œuvre ( I ) nous

évoquerons la responsabilité qui en découle ( II ).

I § – Etendue de la Maîtrise d’œuvre :

Que ce soit dans le cadre de la conception (A), de l’accompagnement et du

suivi (B) voire d’une mission intégrale de livraison d’un système d’information

« Clé en main » (C) le maître d’œuvre assume un rôle fondamental.

A – La mission de Conception :

Avant d’envisager la conception et le développement (1.2) de la solution

informatique le professionnel devra préalablement procéder à un examen

minutieux de la demande effectuée par le client (1.1).

1.1 Examen de faisabilité du besoin :

En effet en bon professionnel le prestataire devra étudier la précision technique

ainsi que la faisabilité de la demande de son client. Cet examen se fera par une

lecture approfondie du cahier des charges (spécifications générales du besoin), 28 - « La Maîtrise d’œuvre en Informatique » - Jacques VIET Gaz Pal - Doctrine 1992



22

établi par le client ou avec le concours d’une entreprise spécialisée dans le

conseil en informatique. Lorsque le maître d’œuvre considère que la solution

est techniquement faisable il procède alors à une analyse fonctionnelle29, afin

de déterminer ainsi les spécifications détaillées, en précisant d’avantage le

besoin et propose au client une solution susceptible de répondre au besoin

formulé (stratégique, fonctionnel) ainsi que le coût prévisible et le délai de mise

en œuvre. Une fois la proposition validée par le client, le maître d’œuvre

engage la réalisation du système et établi les spécifications techniques. Il devra

ainsi déterminer la solution technique adaptée conformément aux contraintes

spécifiques définies par la maîtrise d’ouvrage.

1.2 Conception du système d’information : Aussi sa mission consistera à déterminer le support matériel, à développer ou

faire développer un ou plusieurs logiciel(s) spécifique(s), intégrer et configurer

des progiciels ou encore les adaptera au besoin du client. Il s’agira donc de

choisir entre l’utilisation d’une solution existante (progiciel), dans un souci

d’économie, ou l’élaboration d’un système spécifique, qui pourra représenter

une plus value en terme de gestion et donc d’image de marque vis à vis de la

concurrence utilisant d’autres solutions métiers peut être moins performantes

ou moins adaptées. Parmi les solutions progiciel il est possible de s’orienter

vers une solution « propriétaire » ou « open source »30. Une solution « open

source » présentera ainsi le même avantage que l’élaboration d’un système

spécifique (en terme de modularité et de pouvoir d’adaptation) tout en réduisant

les coûts de développement par rapport à l’élaboration d’une solution

spécifique31. Dès lors, il devra procéder à l’analyse organique32 et ainsi

déterminer les spécifications techniques du système et le réaliser.

1.3 Livraison du système une fois réalisé :

Une fois le système réalisé le maître d’œuvre doit en effet le livrer (en pratique

on parle de la remise des recettes). Le système livré devra être conforme au

cahier des charges. Aussi les fonctionnalités définies par la maîtrise d’ouvrage

29 - voir définitions en annexe p 30 - La philosophie « Open Source » développée en 1984 par richard STALLMAN qui prévoit l’utilisation, la copie, la redistribution ou la modification libre des sources informatiques. 31 - On notera à ce sujet l’initiative AUCHAN et DAIMLER BENZ en matière d’intégration de solution open source. 32 - voir définitions en annexe p



23

devront être opérationnelles et disponibles. Le délai de livraison est

généralement déterminé dans le contrat de maîtrise d’œuvre mais on admet en

pratique un certain report lorsque des difficultés techniques le justifient (non

décelables à la conclusion du contrat). Lors des recettes le maître d’œuvre

assistera son client lors des tests (tests fonctionnels, montée en charge …). La

livraison s’accompagnera également de la rédaction et de la mise à disposition

d’une documentation (manuel, tutoriaux ...) facilitant l’utilisation et la prise en

main du nouveau système par l’utilisateur. Cette documentation devra donc être

claire (lisible) et compréhensible de l’utilisateur.

La fourniture du support matériel, du ou des logiciel(s) et des services

nécessaires à l’exploitation du système d’Information feront généralement

l’objet de conventions spécifiques, conclues entre le client et les divers

intervenants, distinctes du contrat de maîtrise d’œuvre.

B – La mission d’Accompagnement et de suivi :

La mise en place d’un système d’Information fait généralement intervenir de

nombreux prestataires dont il est nécessaire de coordonner le travail. Aussi le

maître d’œuvre sera amené à effectuer le suivi et l’accompagnement de la

réalisation du système d’information (choix des prestataires, gestion du

planning, suivi et la validation technique des différentes phases jusqu’à la

remise des recettes) sous le contrôle du maître d’ouvrage. Il pourra également

être amené à gérer la transition de l’actuel système vers le nouveau système en

veillant à garantir la reprise des données pertinentes. En ce cas on contrôlera

d’une part la conformité du système et d’autre part la conformité (intégrité) des

données reprises aux données initiales. Enfin il pourra être amené à former les

utilisateurs à la prise en main des nouveaux outils logiciels.

C – La mission « Clé en main » :

Le client peut, par souci de simplicité, souhaiter la livraison d’un système

Informatique « Clé en main » auprès d’un prestataire unique. Celui-ci assumera

donc une mission de maîtrise d’œuvre complète consistant à étudier le besoin

du client (qui relève normalement de la maîtrise d’ouvrage), concevoir et livrer

le système informatique satisfaisant au besoin et fournir les différents

composants matériels et logiciels.



24

La mission du maître d’œuvre peut être conséquente et sa responsabilité non

négligeable. En effet il pourra s’agir d’un manquement dans le cadre de la

mission de conception, que ce soit pour ne pas avoir cerner les faiblesses du

cahier des charges, lorsque la solution livrée n’est pas conforme au besoin, ou

encore lors d’une intervention erronée et préjudiciable du maître d’œuvre

chargé de la coordination du projet. Aussi il convient donc de déterminer la

nature juridique de l’engagement pris par le maître d’oeuvre (A) afin d’envisager

l’étendue de sa responsabilité (B).

II § – Cadre juridique de la Maîtrise d’œuvre :

A ) Qualification juridique du contrat de maîtrise d’œuvre :

En effet avant d’envisager les éventuelles obligations du maître d’œuvre il est

souhaitable de déterminer la nature de son engagement. Il convient avant tout

de distinguer d’une part les prestations de fourniture des éléments constitutifs

du système d’information (support matériel, logiciels, services) de la mise en

œuvre du système qui relève seul de la maîtrise d’œuvre. Dès lors seul le

prestataire, qui aura pris en charge l’analyse et la bonne fin du projet (viabilité,

réalisation, livraison) en faisant bénéficier son client de tout son savoir-faire et

de ses compétences techniques pour le conseiller au mieux, ce sera comporté

comme le véritable maître d’œuvre33. La maîtrise d’œuvre s’opère

généralement dans le cadre d’un contrat d’entreprise par lequel le maître

d’oeuvre s’engage moyennant rémunération à accomplir de manière

indépendante un travail, au profit du maître d’ouvrage, sans la représenter34.

Néanmoins lorsque les actes établis par le maître d’œuvre engagent

juridiquement le client final et qu’il ne s’agit donc pas exclusivement d’une

mission d’assistance technique la maîtrise d’œuvre peut s’opérer dans le cadre

d’un mandat (lorsque que le maître d’œuvre est chargé de contrôler le travail

des divers prestataires pour le compte du client). Concernant les contrats « Clé

en main » malgré une jurisprudence, approuvée par une partie de la doctrine,

qui appréhende de manière distributive la relation contractuelle en donnant à

33 - TGI Paris 7 mars 1989, GPE / Edition C et T / France Télécom. 34 - Lamy « Droit de l’Informatique et des réseaux » ; Contrats spéciaux – Ed CUJAS Malaurie Aynès 13ème 1999/2000, p 435 ; J HUET « la modification du droit sous l’influence de l’informatique » JCP 1983 I 3095, n° 27



25

chaque opération sa qualification propre35, il semble qu’il soit préférable de

déterminer une qualification d’ensemble36, une nature juridique qui

transcenderait la simple juxtaposition des différentes prestations. Aussi le

contrat « Clé en main », même lorsqu’il prévoit notamment la fourniture du

support matériel dans le cadre d’une vente, demeure un contrat d’entreprise37.

Cette position semble d’ailleurs conforme à la volonté commune des parties qui

ont convenu de l’exécution d’un contrat unique et nécessairement indivisible.

B ) Les obligations du maître d’œuvre :

Durant sa mission le maître d’œuvre devra principalement conseiller au mieux

son client (1) afin de livrer un système conforme au besoin (2). Dans le cadre

du suivi du projet et de la coordination des divers intervenants il pourra être

amené à représenter le maître d’ouvrage (3).

1 - Le devoir de conseil :

En effet nous l’avons déjà évoqué la définition du besoin peut s’avérer souvent

insuffisante ce qui conduit généralement à un échec. Il appartient donc au

maître d’œuvre d’évaluer la précision du cahier des charges et si nécessaire

d’informer le client sur les insuffisances ou les incohérences. Aussi le maître

d’œuvre, s’il décèle une définition insuffisante du besoin devra proposer au

client de réaliser lui même l'étude préalable du besoin (son intervention relèvera

alors de l’assistance à maîtrise d’ouvrage), inciter le client à faire recours à un

conseil Informatique extérieur pour élaborer le cahier des charges, ou refuser

purement et simplement le travail38, à condition de ne pas l'avoir préalablement

accepté39. Lorsque le client aura fait recours à un conseil extérieur le maître

d’œuvre devra néanmoins vérifier si le cahier des charges, qui a été ainsi

élaboré, est suffisamment précis40. Par la suite il devra expliquer à son client,

de manière compréhensible, les atouts et les spécificités techniques du

système à mettre en place : son fonctionnement, son administration. Ainsi il

devra tempérer l’enthousiasme excessif de son client et l’alerter sur les

35 - Cass 3ème civ, 16 mars 1977 n° 75-13.776 JCP éd G 1978, II, n° 18913, note HASSLER Th 36 - CA Paris 5ème ch B, 4 janvier 1980, JCP éd G 1982, II, n° 19734, note GOUTAL; Cass 1ère civ 18 sept 2002 Expertises 2003, n° 269, p. 149, note HUET J 37 - Lamy « Droit de l’Informatique et des réseaux » 1999/2000 p 504 38 - CA Paris, 5ème ch. B, 24 mai 1991, Sté Compagnie Générale Accident et autre c / Sté Richard NISSAN 39 - CA Grenoble, 1ère civ, 19 janv 1998, A de Wit c/ S Pascalet 40 - CA Paris, 5ème ch. C, 25 juin 1992 Sté AGRO FRIGO Service c / Sté SYBEL Informatique



26

difficultés envisageables au regard des exigences spécifiques (en terme de

sécurité, de performance, de disponibilité et d’évolutivité). Généralement ce

devoir de conseil n’est qu’une obligation de moyens41 et ne peut engager un

résultat certain42. Certains auteurs considèrent que la maîtrise d’œuvre « Clé en

main » implique nécessairement une obligation de résultat43. Or même en cas

de contrat « Clé en main » la collaboration du client est nécessaire à la

satisfaction de son besoin44. En fait l’originalité du contrat « Clé en main » ne

provient pas de l’autorité de l’obligation de conseil (obligation de résultat) mais

au fait que cette obligation repose exclusivement sur le même prestataire. Il

s’agit donc d’une obligation de moyens « renforcée ».

2 - La garantie de conformité :

Bien entendu le système d’information doit être conforme à ce qui a été

convenu à la signature du contrat. La réception de l'ouvrage (remise des

recettes) permettra ainsi d’examiner la conformité du système d’information au

besoin. Il est ainsi tenu à une obligation de résultat. Le système livré doit donc

comprendre toutes les fonctions envisagées, opérationnelles et disponibles45.

On remarque néanmoins que durant la phase de démarrage les fonctions ne

sont pas immédiatement disponibles et opérationnelles. Aussi la jurisprudence

admet un certain taux d'indisponibilité46. Il reste à déterminer ce qui avait été

promis pour établir si le système est conforme ou pas. En effet il est fréquent

que le client, se considérant insatisfait prétende que la solution livrée n'était pas

conforme à ce qu'il désirait. En tout état de cause le défaut de conformité

s'appréciera au regard du cahier des charges initial, dont le maître d’œuvre

devra évaluer la précision technique au titre de son devoir de conseil. Il

conviendra donc que le client détaille le plus précisément possible ses besoins

(fonctionnalités ...) et apporte les précisions nécessaires à l’expression des

contraintes d’exploitation (performance, sécurité, convivialité ...). Aussi la phase

de réception du système (remise des recettes) est importante et engage la

responsabilité du client maître d’ouvrage. En effet si le client valide sans 41 - CA Lyon, 2ème ch. 23 déc 1969, JCP éd G 1970, II, n° 16557 ; CA Paris, 25ème ch. A 23 janv 1990 42 - T Com 1ère ch 19 avril 1971, JCP éd G 1971 ; CA Paris 1ère ch 12 juillet 1972 Sté Flammarion / IBM ; 43 - De Lamberterie « Les Contrats en Informatique », Litec, 1983 n° 194 et 195 ; Linant de Bellefonds 44 - A Paris 5ème ch A 28 sept 1988 Sté Financière La Jardine c/Sté ICL France et Jarène, n° 86/1787 45 - T Com Marseille. 17 juin 1994 Sté Lodecom c / Sté Cati n° 9311528 46 - CA Paris, 25ème ch. A, 10 avril 1990 Sté Prosystem c / Sté Typophot Studio, Juris-Data, n° 21244



27

réserves le système, celui-ci sera réputé satisfaire le besoin exprimé dans le

cahier des charges, et un recours ultérieur contre le maître d’œuvre, sur le

fondement du défaut de conformité, sera délicat (voire impossible). Encore faut-

il se demander si une solution Informatique, qui devait nécessairement intégrer

des fonctionnalités spécifiques (en terme de sécurité notamment pour les

banques, compagnies d’assurances, mutuelles d’assurance santé …) sans que

ce sujet ait été explicitement évoqué par le client, sera jugée non conforme47.

Aujourd’hui la sécurité des Systèmes d’Information constitue à l’évidence un

enjeu crucial48. En fait la discussion portera sans doute plus sur le manquement

à une obligation de conseil du professionnel intervenant dans la conception

sans décharger le client de son obligation de collaboration et de vigilance. Le

client cherchera éventuellement à invoquer la garantie des vices cachés.

Néanmoins il semble, malgré un important débat en doctrine49, que l’action

fondée sur la garantie des vices cachés soit inadéquate dans la mesure où,

comme l’ont fait remarquer des auteurs, la perturbation ne procède pas de la

forme de la création mais de son fond50. En outre l’application du régime de la

vente semble discutable malgré une jurisprudence assimilant la garantie de

fonctionnement du logiciel fourni avec le support matériel (drivers, …) à la

garantie du support51.

Le maître d’œuvre, chargé de la conception, sera également responsable de la

qualité (sécurité) du système d’information mis en œuvre (art 1386-1 et suivants

Code civil). En effet on le sait ce régime de responsabilité est applicable aux

logiciels52. Toutefois il semble que l’application de ce régime de responsabilité

soit limitée aux atteintes physiques aux biens ou aux personnes53. Or il faut

remarquer que la loi ne limite pas explicitement l’application de ce régime de

responsabilité aux atteintes physiques54. Aussi dans une société où les

échanges sont de plus en plus dématérialisés il semble raisonnable d’admettre

47 - En ce sens l’article de Me Marc d’Haultfoeuille paru dans le Journal du Net le 8/11/2005 48 - Salon de la sécurité Informatique 2005, actions de sensibilisation du CLUSIF 49 - Delaval D « La Responsabilité du créateur de logiciel et ses limites », Gaz Pal 1992 ; a contrario TOUBOL F « Le logiciel : analyse juridique » Fiduci-LGDJ 1986 50 - Bohoussou L'Obligation de garantie dans les contrats relatifs à l'informatique, Thèse, Montpellier, 1993 51 - CA Paris, 25ème ch. B, 22 juin 2001; Cass. com 19 mai 1998 n° 95-21.116 52 - « La Responsabilité du créateur de logiciel et ses limites » Me Danièle DELAVAL 53 - Rép. min. n° 15677, JOANQ 24 août 1998, p 4728 54 - l’article 1386-2 du Code civil énonce en effet que « Les dispositions du présent titre s’appliquent à la réparation du dommage qui résulte d’une atteinte à la personne ou à un bien … »



28

également les atteintes causées à des choses incorporelles. L’information

considérée comme un bien55, une atteinte à sa sécurité (intégrité) et causée par

une défaillance du système d’information serait susceptible d’engager la

responsabilité du maître d’œuvre chargé de la conception/intégration. Parmi

ces atteintes possibles, des délinquants informatiques pourraient par exemple

corrompre l'intégrité d'un fichier (virus, hacker) et en altérer l'authenticité, c'est

à dire le lien direct et ininterrompu entre l'auteur et le fichier qu'il a créé, portant

ainsi une atteinte considérable à l’information contenue. Toutefois cette

responsabilité ne peut être reconnue que si l'état des sciences et de la

technologie permettait légitimement, au moment de la conception et de la

livraison du système informatique, d’en garantir la sécurité. On en déduit qu'il

s'agit d'une obligation de moyens et non de résultat.

3 – obligation de mandataire :

Lorsque le conseil en informatique est amené à représenter son client il agi

dans le cadre d’un mandat (art 1984 C Civ). Ça pourrait être le cas lors du suivi

et de la coordination des divers intervenants lorsque le maître d’ouvrage est

directement lié aux divers prestataires intervenants dans la réalisation du projet

(opérateur de télécommunications, fournisseur d’accès Internet, hébergeur,

infogérant, vendeur de matériel informatique …) sans avoir la possibilité

(technique, méthodologique) de contrôler la qualité de leur travail. Au cas où les

prestations n’auraient pas été correctement réalisées sans que des réserves

aient été émises par le maître d’œuvre celui-ci engagera sa responsabilité

envers le client pour avoir manqué à sa mission de contrôle56. En effet le

professionnel aura validé le système pour le compte de son client57 rendant

délicat un éventuel recours contre l’intervenant n’ayant pas correctement réalisé

la prestation promise. Le mandataire est donc responsable envers le mandant

du dommage causé lorsqu’il n’a pas correctement rempli sa mission, même si

elle n’est ni dolosive, ni lourde, ni grave58. Nous l’avons vu l’obligation du

professionnel en cas d’échec est forte sans toutefois dégager le client d’une

nécessaire obligation de collaboration.

55 - « Etude sur le statut juridique de l’Information » - Chron DALLOZ n° 7 1998 de E DARAGON 56 - art 1993 Code Civil 57 - art 1998 du Code Civil ; Civ 1er 26 janvier 1999, BI n° 30 58 - art 1991 et 1992 du Code Civil



29

C ) L’obligation de collaboration du client :

En effet le professionnel ne peut deviner seul le besoin de son client. C’est

pourquoi le client ne pourra reprocher au prestataire une quelconque carence

dans la définition de son besoin sans avoir lui-même activement participé59 à

cette définition. En effet afin d’aboutir à la réalisation d’un système d’information

réellement adapté il est nécessaire que le client définisse ses besoins et les

objectifs à atteindre en précisant clairement la nature et l’importance des

processus qu’il souhaite informatiser, eu égard à son organisation et à ses

problèmes spécifiques, tous les éléments susceptibles d’affecter la solution

proposée. Cela signifie que le client doit informer le plus possible le prestataire

sur ses attentes (en terme de fonctionnalités, de sécurité, de performance,

convivialité et d’évolutivité) ainsi que le fonctionnement de son entreprise

(organigramme, niveau de compétence des cadres et salariés …) et participer

ou faire participer activement son personnel en répondant aux diverses

requêtes que ne manquera pas de poser le prestataire informatique60.

59 - Cass 1ère civ 21 déc 1964, n° 63-11-065, JCP éd G 1965, II, n° 14005; CA Paris 25ème ch B, 7 juillet 1989, Sté Pragama et autre c/Sté Casanova, Jurisdata, n° 24805 60 - T Com 1ère ch 19 avril 1971, JCP éd G 1971, CA Paris 1ère ch 12 juillet 1972, Sté Flammarion / IBM Linant de Bellefonds X et Hollande A, Contrats Informatiques et télématiques. Delmas 1992. p 52. CA Paris 5ème ch B, 30juin 1983, Passeport c/Kienzle Informatique, Juris-Data n° 24805.



30

Conclusion :

Comme nous venons de le voir la responsabilité du maître d’œuvre est grande,

principalement en matière de conseil. Néanmoins, comme nous l’avons vu

l’échec du projet n’est pas nécessairement et exclusivement imputable au

maître d’oeuvre. La pratique montre en effet que la plupart des échecs sont liés

à la maîtrise d’ouvrage. Généralement le maître d’ouvrage ne définira pas

suffisamment son besoin et accusera au final le maître d’œuvre. Or le client qui

ne se sera pas suffisamment impliqué (manque de précision du besoin, carence

décisionnelle, attitude dilettante) manquera à son obligation de collaboration.

Dans ce cas la responsabilité du maître d’œuvre pourra être partiellement ou

totalement écartée61.

Pour autant il est généralement difficile de déterminer le rôle et les prérogatives

précises des divers intervenants. D’autant qu’encore aujourd’hui les

conventions (lorsqu’elles existent) ne détaillent pas ou peu les rôles précis de

chacun. Aussi généralement en cas d’échec les parties se renvoient « la balle »

et il est alors nécessaire de déterminer l’intervention fautive. Il pourra en effet

s’agir d’une définition insuffisamment précise du besoin qui mettra en jeu une

responsabilité partagée d’une part entre le maître d’ouvrage et l’éventuel

assistant à maîtrise d’ouvrage et d’autre part entre le maître d’ouvrage et le ou

les maître(s) d’oeuvre. Il pourra également s’agir d’un défaut dans la conception

du système ou d’une intervention inappropriée ou insuffisante lors de la

réalisation technique, qui mettra en cause la responsabilité du ou des

intervenants fautifs. C’est pourquoi nous envisagerons l’étendue du rôle des

divers intervenants permettant d’en déduire leur périmètre d’intervention et

leurs responsabilités respectives.

61 - Cass 1ère civ 21 déc 1964, n° 63-11-065, JCP éd G 1965, II, n° 14005 ; CA Paris, 25ème ch B, 7 juillet 1989, Sté Pragama et autre c/ Sté Casanova, Juris-Data, n° 23628



31




32

Nous venons de l’évoquer la mise en place d’un système d’Information est

généralement complexe et implique de multiples intervenants. Il est ainsi

souvent délicat de distinguer le rôle précis et la nature exacte de l’implication de

chacun. On l’a dit le client doit définir avec le plus de précision possible son

besoin ainsi que les moyens (financiers, humains, techniques, contractuels …)

appropriés. C’est ce qu’on appelle la maîtrise d’ouvrage. Suivant la complexité

du besoin le client peut être amené à se faire assister par une société de

conseil en Informatique dans le cadre de l’assistance à maîtrise d’ouvrage. Une

fois le besoin défini la réalisation technique du système d’Information implique

la participation de nombreux prestataires (ssii, intégrateurs, éditeurs de

progiciels, fournisseurs d’accès et opérateurs en télécommunication,

hébergeurs et infogérants …. ) dont le niveau de responsabilité dépend de la

nature et de l’étendue de leur intervention. En effet parmi ces prestataires seul

celui qui aura pris en charge l’analyse du projet (viabilité, réalisation, livraison)

en faisant bénéficier son client de tout son savoir-faire et de ses compétences

techniques pour le conseiller au mieux, ce sera comporté comme le véritable

maître d’œuvre62. Or dans bien des cas les rôles de chacun se superposent et il

devient alors délicat de distinguer l’intervention relevant de la maîtrise

d’ouvrage de celle du maître d’œuvre. Aussi après avoir délimiter le périmètre

d’intervention et la responsabilité respective du maître d’ouvrage, de son

assistant éventuel, et du maître d’œuvre concepteur du système d’Information

et coordinateur du projet (Sous Partie I) nous envisagerons les relations

contractuelles liants ces différents intervenants selon le cadre juridique choisi

( Sous partie II).

62 - TGI Paris 7 mars 1989, GPE / Edition C et T / France Télécom



33

Rôle et Responsabilité




34

Définition des périmètres d’Intervention …

Nous l’avons déjà évoqué la maîtrise d’ouvrage est un phase cruciale dans la

conduite du projet informatique. C’est une mission considérable qui nécessite

des compétences particulières. C’est pourquoi en général le client recours à

l’assistance d’un prestataire externe. Dans ce cas il n’est pas toujours évident

de déterminer le rôle de chacun. Le contrat d’engament passé entre le client et

l’assistant à maîtrise d’ouvrage devra donc préciser le niveau d’intervention du

prestataire et ses moyens d’action (par rapport à la structure du client et dans

ses relations avec le maître d’œuvre) ainsi que les responsabilités respectives.

Le maître d’œuvre ne pourra pas a priori se décharger en se prévalant de

l’intervention d’un prestataire pour la définition du besoin notamment. En effet la

nature de l’intervention dans le cadre de la maîtrise d’ouvrage est bien distincte

de celle relevant de la maîtrise d’œuvre. Aussi après avoir délimité le niveau

d’intervention de chacun (client, assistant à maîtrise d’ouvrage, maître d’œuvre)

nous déterminerons la responsabilité qui en résulte (nature des obligations

respectives du client à l’égard de l’assistant à maîtrise d’ouvrage et du maître

d’œuvre, de l’assistant à l’égard de son client et du maître d’œuvre à l’égard du

maître d’ouvrage).

I§ – La délimitation du rôle respectif de chacun … A ) La Maîtrise d’Ouvrage décisionnelle :

Nous l’avons déjà dit la mise en place des Systèmes d’Information implique

aujourd’hui une importante maîtrise d’ouvrage (stratégique ou décisionnelle). Le

maître d’ouvrage doit au travers de ses diverses missions se comporter comme

un client compétent. Il est ainsi responsable de la définition et de la cohérence

du système d’information. Dans le cadre de son rôle il aura en charge la

modélisation63 du système d’information, afin de traduire le besoin fonctionnel

des utilisateurs finaux (la vision métier), et son urbanisation64. C’est en effet lui

qui est responsable de la définition de son besoin et qui doit valider le cahier 63 - voir définition en annexe p 59 64 - « L’Urbanisme : une opportunité pour réinventer la relation maîtrise d’ouvrage / maîtrise d’oeuvre », Christophe LONGPEPE



35

des charges (spécifications générales et détaillées), déterminer et lancer les

moyens (financiers, humains, techniques), suivre la réalisation, et enfin valider

la conformité du système au cahier des charges. Parallèlement à la mise en

œuvre du projet la maîtrise d’ouvrage devra anticiper les conséquences de la

mise en place du système sur son organisation (conduite du changement) et

sensibiliser les utilisateurs aux adaptations nécessaires (élaboration de

documentation, formation). Seul à disposer de la vision d’ensemble il devra

assumer le pilotage du projet, c'est-à-dire définir les objectifs stratégiques du

système d’Information et arbitrer les éventuels conflits (demande des

utilisateurs et des différentes directions divergentes ) qui pourraient survenir ou

persister, choisir le ou les prestataire(s) ( dont le maître d’œuvre ), déterminer le

cadre juridique le mieux adapté au projet (assistance à maîtrise d’ouvrage

externe ou interne, maîtrise d’œuvre interne ou externe, choix du maître

d’œuvre, définition et rédaction des conventions d’assistance à maîtrise

d’ouvrage et de maîtrise d’œuvre …), définir les engagements des différents

prestataires et mettre en place les moyens de suivi et de contrôle du projet.

Nous l’avions évoqué le client ne dispose pas toujours « en interne » de la

méthodologie (en terme de modélisation notamment) nécessaire à la définition

du besoin. Aussi il est fréquent que le maître d’ouvrage délègue cette mission à

un société de conseil qui l’assistera dans sa maîtrise d’ouvrage. Le maître

d’ouvrage conservera néanmoins un rôle sémantique et devra collaborer à la

définition de son besoin avec l’assistant à maîtrise d’ouvrage ainsi qu’avec le

maître d’oeuvre.

B ) L’Assistance à Maîtrise d’Ouvrage ( opérationnelle ) :

Dans le cadre de l’Assistance à maîtrise d’ouvrage le prestataire peut assister

le client dans la définition et la formalisation de son besoin (modélisation…) afin

d’assurer la convergence entre la vision métier et les spécifications (générales

et détaillées), le choix des prestataires et la définition de leurs engagements, le

contrôle de la conformité du système livré aux objectifs fixés (remise des

recettes) dont le maître d’ouvrage assure le pilotage. Le domaine d’intervention

est donc généralement vaste. Il pourra en effet s’agir d’une mission d’études



36

préalables, d’audit ou encore d’assistance à maîtrise d’ouvrage. Aussi il est

nécessaire de bien définir la prestation fournie, les engagements et les moyens

dont il dispose pour remplir sa mission (transmission de documents et de toutes

informations utiles, disponibilité du personnel …). En effet il est nécessaire de

délimiter clairement le rôle et la responsabilité de chaque intervenant afin

d’éviter le risque de confusion entre la maîtrise d’ouvrage « client », son

assistant et le maître d’oeuvre.

C ) La Maîtrise d’œuvre …

De la conception (définition, développement, intégration) …

En effet en bon professionnel le prestataire devra étudier la précision technique

ainsi que la faisabilité de la demande de son client. Cet examen se fera par une

lecture approfondie du cahier des charges (spécifications générales), établi par

le client ou avec le concours d’une entreprise spécialisée dans le conseil en

informatique. Lorsque le maître d’œuvre considère que la solution est

techniquement faisable il détermine alors les spécifications détaillées, en

précisant d’avantage le besoin (en terme d’exploitation, de fonctionnalités…) et

propose au client une solution susceptible de répondre au besoin formulé

(stratégique, fonctionnel) ainsi que le coût prévisible et le délai de mise en

œuvre Une fois le besoin défini et validé par le maître d’ouvrage, le maître

d’œuvre aura en charge la réalisation de ces objectifs. Il pourra être amené à

développer ou faire développer un ou plusieurs logiciels spécifiques, intégrer et

configurer un ou plusieurs logiciels standard(s) (progiciel) ou l’adapter au

besoin spécifique conformément au besoin défini par le maître d’ouvrage. Il

sera donc responsable tout d’abord de la faisabilité de la demande formulée par

le maître d’ouvrage et de la conformité de la réalisation aux objectifs définis.

Lorsque le système intègre un ou plusieurs progiciel(s) le maître d’œuvre sera

responsable de ce choix et de l’adéquation des fonctionnalités fournies au

besoin du client.

… à la coordination.

Aujourd’hui la complexité des systèmes d’Information implique l’intervention de

nombreux prestataires dont il convient de coordonner l’action (gestion du

planning de réalisation des différentes applications, contrôle des prestataires et



37

de la conformité de leur réalisation aux objectifs fixés). Aussi il est souvent

nécessaire que le maître d’œuvre coordonne l’ensemble des prestataires qui

interviennent dans le projet. Il agira en collaboration et sous le contrôle du

maître d’ouvrage ou de son assistant.

Maître d’œuvre d’une solution « clé en main ».

Le maître d’œuvre peut également être amené à assumer une mission

consistant à livrer un système informatique « clé en main ». En effet cela

permet au client une gestion simplifiée de son projet (cadre contractuel

simplifié, responsabilité unique, prise en charge de la gestion méthodologique

et opérationnelle du projet …). Le maître d’œuvre se chargera ainsi d’une

mission complète consistant à définir le besoin du client (mission qui relève de

l’assistance à maîtrise d’ouvrage), établir une proposition de réalisation, et enfin

réaliser et livrer le système conformément aux termes de sa proposition

(fonctionnalités, délai, coût). Dans le cadre de cette mission le maître d’œuvre

sous-traitera généralement auprès de divers prestataires spécialisés

(consultants, ssii, éditeurs de progiciels, opérateurs de télécommunication …). Il

sera alors responsable de la qualité de l’ensemble des prestations fournies et

devra donc contrôler la qualité et la conformité des produits et services livrés

par les différents prestataires associés.

Nous venons de le voir, le rôle de chaque intervenant au projet informatique est

déterminant. Aussi la responsabilité qui en découle est conséquente.

II§ Délimitation des responsabilités respectives ….

A ) La responsabilité du client …

En effet le client (maître d’ouvrage) sera responsable du pilotage du projet,

c'est-à-dire le suivi et le contrôle des différentes phases afin d’assurer la

convergence entre la vision « métier » et la solution technique envisagée. Le

pilotage du projet se différencie de la mission de coordination, assumée par le

maître d’œuvre, dans la mesure où il implique un aspect sémantique et

décisionnel tandis ce que la coordination vise au suivi et au contrôle de la

qualité (technique) des prestations réalisées conformément au cahier des

charges. Le client est donc responsable de la qualité de la définition de son



38

besoin (spécifications générales), qu’il aura effectué lui-même ou avec le

concours d’un prestataire externe. Il devra donc collaborer activement avec le

maître d’œuvre et l’éventuel assistant à maîtrise d’ouvrage et veiller à ce que

les spécifications reflètent son besoin (stratégiques, fonctionnelles).

B ) Le devoir de conseil de l’assistant à maîtrise d’ouvrage :

La qualité du travail de l’assistant à maîtrise d’ouvrage conditionne la mise en

oeuvre d’un système d’Information, réalisé par le maître d’œuvre,

conformément au besoin spécifié. Aussi sa responsabilité est conséquente

principalement au titre de son obligation de conseil. Le prestataire sera donc

garant de son savoir-faire (compétence méthodologique, managériale …),

concernant la mission acceptée, et d’une indépendance absolue à l’égard du

maître d’œuvre. En effet son rôle consiste essentiellement à contrôler les

différentes étapes du projet (obligation de suivi et de « reporting » détaillé, dans

le cadre de la définition et de la formalisation du besoin, des recettes

fonctionnelles …). Ainsi il devra anticiper les difficultés envisageables (retard

sur le planning, dérive financière, solution technique divergente vis-à-vis des

besoins exprimés) et ainsi alerter le maître d’ouvrage afin de lui permettre de

prendre rapidement les décisions adéquates pour redresser le projet.

C ) La Responsabilité du maître d’œuvre : 1 - Le devoir de conseil du maître d’œuvre …

Le Maître d’œuvre est également tenu à un fort devoir de conseil et devra ainsi

évaluer la précision du cahier des charges et si nécessaire informer le client sur

les insuffisances ou les incohérences. Aussi le maître d’œuvre, s’il décèle une

définition insuffisante du besoin, devra proposer au client de réaliser lui même

l'étude préalable du besoin (cette intervention relèvera de l’assistance à

maîtrise d’ouvrage), inciter le client à faire recours à un conseil Informatique

extérieur pour élaborer le cahier des charges65, ou refuser purement et

simplement le travail, à condition de ne pas l'avoir préalablement accepté66.

Lorsque le client aura fait recours à un conseil extérieur le maître d’œuvre

devra néanmoins vérifier si le cahier des charges, qui a été ainsi élaboré, est

65 - CA Paris, 5ème ch. B, 24 mai 1991, Sté Compagnie Générale Accident et autre c / Sté Richard NISSAN 66 - CA Grenoble, 1ère civ, 19 janv 1998, A de Wit c / S Pascalet



39

suffisamment précis67. Le maître d’œuvre complètera ensuite les spécifications

du client en élaborant les spécifications détaillées, qui constitueront son offre de

réalisation des objectifs fixés par la maîtrise d’ouvrage. Le maître d’œuvre

devra donc conseiller au mieux son client (maître d’ouvrage) dans la définition

du besoin sans toutefois limiter ce besoin en fonction d’éventuelles difficultés

techniques. En effet comme le relève très justement certains spécialistes « la

grosse difficulté a été de faire admettre à la MOE qu’elle était au service de la

MOA tout comme la MOA l’était des utilisateurs finaux »68. Durant le projet il

devra généralement contrôler la conformité et la qualité des différentes

prestations livrées et éventuellement alerter son client sur les écarts constatés,

par rapports aux attentes définies dans le cahier des charges. Par la suite il

devra expliquer à son client, de manière compréhensible, les atouts et les

spécificités techniques du système à mettre en place et éventuellement insister

sur les difficultés envisageables (en terme de sécurité, de performance, de

disponibilité et d’évolutivité…).

Lorsqu’il s’engage à réaliser et à livrer un système « Clé en main » le maître

d’œuvre assumera une mission vaste dont la définition, opérationnelle et

méthodologique, du besoin. Ce type d’engagement, qui présente l’avantage

pour le client d’une gestion simplifiée, est néanmoins dangereux dans la

mesure où le maître d’œuvre chargé à la fois d’évaluer le besoin et d’établir une

proposition conforme pourra être tenté de limiter le besoin lorsqu’il rencontre

des difficultés techniques. En conséquence le maître d’œuvre « Clé en main »

sera tenu à un devoir de conseil renforcé. Le client (maître d’ouvrage) devra

donc s’engager pleinement auprès du maître d’œuvre et veiller à la cohérence

entre les spécifications définies et son besoin.

2 - La garantie de conformité :

Le maître d’œuvre est en effet responsable de la qualité technique du système

d’information (fonctionnalités, performances). A ce titre il est tenu à une

obligation de résultat. La réception du système mis en oeuvre (remise des

recettes) permettra ainsi d’examiner la conformité du système au besoin défini

67 - CA Paris, 5ème ch. C, 25 juin 1992 Sté AGRO FRIGO Service c / Sté SYBEL Informatique 68 - Michel VOLLE ( voir Volle.com )



40

dans le cahier des charges. Le système livré doit donc comprendre toutes les

fonctions envisagées, opérationnelles et disponibles69. On remarque néanmoins

que durant la phase de démarrage les fonctions ne sont pas immédiatement

disponibles et opérationnelles. Aussi la jurisprudence admet un certain taux

d'indisponibilité70.

3 – La garantie de la qualité (technique) du système :

Le maître d’œuvre, en sa qualité de producteur, est également responsable des

dommages éventuellement causés par la défectuosité du système71. Toutefois

cette responsabilité ne peut être reconnue que si l'état des sciences et de la

technologie permettait légitimement, au moment de la conception et de la

livraison du système informatique, d’en garantir la sécurité. On en déduit qu'il

s'agit d'une obligation de moyens et non de résultat.

69 - T Com Marseille. 17 juin 1994 Sté Lodecom c/ Sté Cati n° 9311528 70 - CA Paris, 25ème ch. A, 10 avril 1990 Sté Prosystem c / Sté Typophot Studio, Juris-Data, n° 21244 71 - art 1386-1 et s du Code Civil relatif à la loi sur la responsabilité du fait des produits défectueux



41

Nous l’avons vu chaque intervenants (notamment le client) jouent un rôle

déterminant dans la réussite ou l’échec du projet. Nous avons établi la nature et

l’étendue de la responsabilité de chacun (le maître d’ouvrage et ses assistants

éventuels, le maître d’œuvre …). Pour autant en cas d’échec la difficulté

consistera à en identifier la cause. En effet le constat d’échec ou du moins de

déception par rapport aux prestations promises ne se révèle généralement

qu’au terme de la mise en œuvre (à la livraison du système d’information ou au

cours de l’exploitation). Dans ce cas il faudra déterminer qui du client, de son

assistant, du maître d’œuvre ou des divers prestataires est responsable de

l’échec. La responsabilité peut être entière ou partagée (le client pour défaut de

collaboration, l’assistant à maîtrise d’ouvrage ou/et le maître d’œuvre pour

défaut de conseil). Les différends nés à l’occasion d’un contrat « Clé en main »

seront a priori plus aisés à déterminer puisqu’il s’agira d’une unique convention

entre le maître d’ouvrage et le maître d’œuvre. En revanche lorsque le projet

s’articule dans un cadre juridique complexe faisant intervenir de multiples

contrats de prestation il sera généralement nécessaire de reconstruire la chaîne

des engagements contractuels et ainsi établir à qui imputer la responsabilité

des conséquences dommageables résultant de la mauvaise exécution ou du

défaut d’exécution de la prestation promise.



42

Stratégie distributive ou unitaire de la Responsabilité




43

Organisation des relations contractuelles … Généralement deux logiques s’opposent. D’une part le client qui souhaite une

relation unique, dans le cadre d’une convention « Clé en main », entre lui-

même (en qualité de maître d’ouvrage) et le maître d’œuvre, faisant

essentiellement supporter la réussite (ou l’échec) du projet sur le maître

d’oeuvre. D’autre part, les prestataires qui préfèreront une architecture juridique

plus complexe72 associant divers contrats (prestation de conseil et d’assistance

à maîtrise d’ouvrage, contrat de maîtrise d’œuvre, vente de matériel

informatique et de télécommunication, licence d’utilisation de progiciel,

prestations de services, …), entre le client et chacun des prestataires,

impliquant ainsi une approche distributive de la responsabilité des divers

intervenants. Nous étudierons donc l’organisation contractuelle et les

conséquences en matière de détermination des responsabilités selon que le

projet sera géré dans le cadre d’une architecture juridique complexe et

dissociée (I) ou simplifiée dans le cadre d’un projet « clé en mains » (II). Il

s’agira donc pour le client de déterminer le cadre contractuel le mieux adapté à

ses attentes (définition des périmètres d’intervention et de la nature des

engagements des différents prestataires …) afin de mener à bien son projet.

I§ Organisation contractuelle dissociée du projet :

Nous l’avons déjà évoqué les projets complexes s’organisent principalement

entre le client et le maître d’œuvre (A), le client et l’assistant à maîtrise

d’ouvrage (B), et enfin entre le client et les divers prestataires associés

intervenant dans le projet (C).

A ) Relation contractuelle entre MOA et MOE :

Nous l’avons vu dans la première partie, le cadre contractuel liant le maître

d’ouvrage et le maître d’œuvre relève la plupart du temps des contrats

d’entreprise par lequel le maître d’œuvre s’engage à conseiller au mieux son

client dans le cadre de la définition du besoin (évaluation et cadrage des

spécifications générales, rédaction des spécifications détaillées) afin de réaliser

et de livrer un système conformément aux termes de sa proposition. 72 - « Projet ERP : quelle structure contractuelle choisir ? » - de Me Marc d’Haultfoeuille (Journal du Net – 20/11/2002)



44

Le client s’engage quant à lui à collaborer avec le maître d’œuvre dans la

définition du besoin et la mise en œuvre du système d’Information.

1 ) La responsabilité du maître d’œuvre à l’égard de son client :

a - Devoir de conseil :

Dans le cadre de la conception et la mise en œuvre du système :

Le maître d’œuvre doit évaluer la qualité des spécifications générales établies

par le client et si nécessaire le mettre en garde sur les insuffisances ou les

l’incohérence de sa demande. Une fois la demande précisée et maîtrisée le

maître d’œuvre doit établir une proposition de réalisation technique

(spécifications détaillées) « conforme » aux spécifications générales, c'est-à-

dire reflétant le besoin défini par le client.

Lorsque le client se fait assister dans sa maîtrise d’ouvrage, le maître d’œuvre est

néanmoins tenu à une obligation de conseil et doit veiller à la précision des

spécifications générales sans pouvoir se décharger totalement sur l’Assistant à

Maîtrise d’Ouvrage concernant notamment l’examen des spécifications générales.

Dans le cadre de l’accompagnement (coordination) du projet :

Dans le cadre de sa mission d’accompagnement et de coordination du projet, le

maître d’œuvre doit guider le client dans le choix des prestataires (et ainsi

délimiter leur niveau d’intervention respectif), suivre et contrôler les prestataires

intervenants au projet. Il est donc responsable à l’égard du client d’un fort

devoir de conseil et de mise ne garde s’il constate que la prestation des divers

intervenants n’est pas conforme à ce qui avait été convenu et que le projet

« dérape ». Il devra enfin généralement accompagner le client durant les étapes

de la réception du système (des recettes provisoires aux recettes définitives).

Le maître d’œuvre pourra également être amené à accompagner le client dans

son plan de formation des utilisateurs ou du personnel technique chargé

d’assurer la gestion du système.

b - Obligation de conformité :

Le maître d’œuvre doit réaliser et livrer un système conforme à sa proposition

(en terme de performances, services, fonctionnalités, ergonomie …). Il est alors

tenu à une obligation de résultat. C’est ainsi que durant la remise des recettes

le client (éventuellement assisté dans cette mission) contrôlera la conformité du



45

système réalisé et livré au cahier des charges. Les recettes provisoires

permettront de constater les éventuels dysfonctionnements ou carences

fonctionnelles afin de les corriger. Lors des recettes définitives les fonctions,

envisagées dans le cahier des charges, devront donc être disponibles et

opérationnelles. En cas de dysfonctionnement(s) ou d’indisponibilité et à défaut

de réserve(s), de la part du client, le système sera considéré comme

réceptionné et accepté.

c - Obligation de qualité (sécurité) du système (produit) livré :

Le maître d’œuvre est également responsable de la qualité technique (dont la

sécurité) du système. En effet en sa qualité de producteur il est responsable

des dommages causés par la défectuosité du système (y compris du logiciel)73.

2 ) La responsabilité du client ( MOA ) à l’égard du maître d’oeuvre :

Nous l’avons évoqué le client est tenu à une nécessaire obligation de

collaboration à l’égard du maître d’œuvre. Il doit ainsi définir et maîtriser son

besoin. Il est en effet responsable de la qualité des spécifications générales.

Aussi même lorsque les prestataires (société de conseil et d’audit, maître

d’oeuvre) collaborent à la définition du besoin, le client reste responsable de la

qualité (sémantique) des spécifications générales et de leurs « conformités » à

son besoin. Il doit donc veiller à la précision et à la cohérence de l’expression

de son besoin. A défaut, il ne pourra reprocher au maître d’œuvre d’avoir

réaliser un système qui ne serait pas pleinement satisfaisant alors que les

spécifications générales ne permettaient pas au maître d’œuvre de déceler que

celles-ci ne reflétaient pas totalement le besoin. Une fois le besoin défini et

durant la mise en place du système, le client devra généralement s’assurer de

la disponibilité et de la collaboration active, auprès du maître d’oeuvre, du

personnel associé au projet (personnel technique, utilisateurs, responsables

« métier »). Enfin durant la remise des recettes il devra contrôler, avec soin, la

conformité du système mis en œuvre au cahier des charges. Pour cela il

établira les procédures, les documents de contrôle et les jeux de tests

adaptés74.

73 - art 1386-1 et s du Code Civil relatif à la loi sur la responsabilité du fait des produits défectueux 74 - CA Paris 5ème ch A 11 oct 1989, Sté Maxiam c / Sofitec



46

Nous l’avons vu la définition du besoin mettra généralement en jeu une

responsabilité partagée du client (maître d’ouvrage), qui ne se sera pas

suffisamment impliqué dans le projet, et du maître d’œuvre, qui aura manqué à

son devoir de conseil75. C’est pourquoi il est très souvent nécessaire que le

client soit assisté et conseillé dans sa maîtrise d’ouvrage, qui réclame des

compétences et un savoir-faire dont il ne dispose généralement pas, afin de

pouvoir pleinement et utilement collaborer avec le maître d’oeuvre.

B ) Relation contractuelle entre le client (MOA) et l’AMOA :

1 – Forte obligation de conseil de l’AMOA à l’égard du client ( MOA ) :

Nous l’avons évoqué le rôle de l’assistant à maîtrise d’ouvrage est

généralement déterminant dans la réussite du projet (notamment dans le cadre

de la définition du besoin). Aussi le prestataire chargé de cette mission est tenu

envers son client à une forte obligation de conseil concernant la définition de

son besoin, la validation du cahier des charges et durant la remise des recettes.

Durant l’établissement du cahier des charges et la mise en oeuvre il devra

mettre en garde son client s’il constate que le projet « dérape » (demande

incohérente des utilisateurs, explosion des coûts, non respect des délais …).

Enfin il assistera son client lors de la remise des recettes en collaborant à

l’établissement des procédure et des documents de contrôle, des jeux de test et

le mettre en garde sur d’éventuels dysfonctionnements en notant les réserves

nécessaires à la reprise des bogues. Ainsi le prestataire est garant de son

savoir-faire mais surtout d’une indépendance absolue (juridique et financière) à

l’égard du maître d’œuvre. Il devra en effet garantir à son client des choix

objectifs dans son intérêt et non celui du maître d’œuvre. La collaboration entre

les équipes de l’AMOA et du maître d’œuvre n’implique donc pas la confusion

entre la maîtrise d’ouvrage et la maîtrise d’œuvre. En effet le maître d’ouvrage

reste maître de la définition de son besoin. Le maître d’œuvre se contentant

uniquement d’apporter (sans imposer) sa vision technique afin d’envisager et

anticiper les contraintes (techniques) éventuelles.

75 - CA. Paris 5ème ch., 7 avril 1993, JDD Informatique c/ Sté Nouvelle Para hôtelière : Expertise novembre 1993



47

2 - Obligation de collaboration du client :

Le client doit collaborer auprès de l’AMOA dans la définition (et la maîtrise) de

son besoin et le contrôle de conformité du système livré aux spécifications

générales. En effet il devra veiller à fournir au prestataire toutes les informations

utiles et nécessaires à la définition du besoin, s’assurer de la disponibilité

effective du personnel dédié au projet (utilisateurs, chefs de service…) et

s’impliquer pleinement durant la réception du système. Il devra donc contrôler la

qualité (et la lisibilité) du cahier des charges afin de valider pleinement son

besoin ainsi défini, établir les documents de contrôle et les jeux de tests afin de

s’assurer de la conformité du système livré au cahier des charges.

Aussi lorsqu’il est démontré que l’AMOA a manqué à son obligation de conseil,

il devra assumer les dommages consécutifs à l’échec du projet (frais de reprise

du projet, pertes d’exploitation, déficit d’image…). Il pourra s’agir d’une

responsabilité exclusive (défaut de conseil de l’AMOA) ou partagée (échec dû à

l’incompréhension entre l’AMOA qui a manqué à son obligation de conseil et le

client pour ne pas avoir suffisamment collaboré). Malgré son importance

déterminante, la maîtrise d’ouvrage méthodologique et opérationnelle (et son

assistance éventuelle) semble encore aujourd’hui mal perçue, voire abstraite

dans la mesure où ce travail n’abouti pas directement à la réalisation et à la

livraison du système d’information. Toutefois il convient de noter des initiatives

de la part des professionnels tendant à encadrer d’avantage le déroulement de

la maîtrise d’ouvrage et la responsabilité respective du client et de son

assistant76.

C ) Relation contractuelle entre le client (MOA) et les divers prestataires :

Nous l’avons évoqué le client est généralement amené à contracter auprès de

divers prestataires intervenants au projet (constructeur, vendeur de matériel

informatique, éditeur de progiciel, ssii, opérateur de télécommunication,

fournisseur d’accès Internet …) en dehors du maître d’œuvre et de l’assistant à

maîtrise d’ouvrage. En effet en dehors de la prestation de pur conseil (réservée

à l’AMOA) il convient de distinguer selon que l’intervenant agira en tant que

76 - Charte 2004 entre le CIGREF et le Syntec Informatique, voir également « Pratique du droit de l’Informatique » Editions DELMAS 2002 – Alain HOLLANDE, Xavier Linant de Bellefonds



48

maître d’œuvre ou comme un simple prestataire informatique associé au projet.

Or le client pourra être tenté d’imposer au prestataire les obligations liées à la

fonction de maître d’œuvre (notamment le devoir de conseil). Aussi la

qualification de « maître d’œuvre » dans le contrat ne saurait s’imposer au juge

qui appréciera la qualité du rôle joué par le prestataire au regard de la nature

(concrète) de son intervention77. Lorsqu’il n’agit pas en tant que maître d’œuvre

le prestataire est néanmoins tenu d’exécuter la prestation conformément à ses

engagements. Aussi le client doit contrôler la qualité et surtout la conformité des

diverses prestations livrées au résultat attendu. Il est donc nécessaire que le

client et le prestataire définissent précisément la prestation attendue ainsi que

les engagements respectifs des cocontractants (du client et du prestataire). Ces

prestataires interviennent généralement dans le cadre d’une co-traitance

conjointe ou solidaire. La co-traitance sera conjointe lorsque la prestation est

réalisée par un intervenant unique (découpage du projet par « lots »). Dans ce

cas chaque intervenant sera responsable de la réalisation de son travail

(conformité et qualité). Elle sera solidaire lorsque la réalisation implique

plusieurs intervenants qui seront alors solidairement responsables des

dommages causés par suite d’un vice ou d’un dysfonctionnement de l’ensemble

réalisé. Dans tous les cas, le maître d’œuvre ne devra pas être lié

(juridiquement ou financièrement) aux différents prestataires concernés. En

effet ainsi le maître d’œuvre pourra déterminer des solutions techniques dans

l’intérêt exclusif du client.

Nous l’avons vu la réussite d’un projet informatique dépend essentiellement

d’une maîtrise d’ouvrage maîtrisée et encadrée. Aussi l’opportunité et la

nécessité d’une assistance professionnelle dans la maîtrise d’ouvrage semblent

aujourd’hui acquises78. Nous l’avons évoqué le cahier des charges constitue un

élément de référence indispensable. Il constitue en effet avant tout un élément

de référence technique pour le maître d’œuvre et les divers intervenants

associés au projet. Il représente également un élément de référence juridique

pour déterminer le rôle et les responsabilités respectives de chacun. Ainsi, tout

à la fois feuille de route et charte de réalisation, il permettra d’établir les 77 - CA de Paris 25ème ch, section B du 2 juillet 2004 - IFTH / Léonard Fashion, Kersys 78 - « Les atouts d’une maîtrise d’ouvrage bien encadrée » - Marc SCHULER et Guillaume RAIMBAULT, DSI 10/06/05



49

éventuelles négligences du client dans son obligation de collaboration

(notamment dans le cadre de la définition de son besoin), du maître d’œuvre

dans son devoir de conseil ou encore des divers prestataires dans l’obligation

de délivrance conforme. L’examen du cahier de charges permettant de

comparer le résultat livré (constaté lors des la remise des recettes) au résultat

attendu (défini dans le cahier des charges). Aussi en cas d’échec ou de

dysfonctionnements du système livré il conviendra d’en identifier la cause et

donc le responsable. Il est donc indispensable que le client veille à formaliser le

rôle de chaque intervenant (et sa responsabilité éventuelle) et encadre

activement l’ensemble des étapes du projet (définition et validation du besoin,

examen et accord sur la proposition de réalisation du maître d’œuvre, recettes

provisoires, correction des écarts, recettes définitives, mise en exploitation et

formation des utilisateurs) en contrôlant la conformité du résultat livré. Nous

l’avons évoqué les projets informatiques impliquent généralement un ensemble

de contrats qui son liés par un même objectif final, à savoir la mise en œuvre

d’un système informatique. Pour autant ces groupes de contrats79, qui sont

nécessairement liés, constituent-ils un ensemble indissociable et solidaire de

prestations ? On pensera notamment aux contrats de mise en place d’un PGI80

(Progiciel de Gestion Intégrée) ou ERP qui prévoient la fourniture d’un progiciel,

auprès d’un éditeur de logiciel, et son intégration dans le système d’information

(mis en œuvre par un intégrateur agissant en qualité de maître d’oeuvre). Il

semble qu’en l’absence de cadre juridique aménagé (Groupement d’entreprises

solidaires, contrat « clé en main »…) la réponse soit encore incertaine81.

D’autant que la cour de cassation est revenu à une lecture classique de l’article

1165 du code civil82 en décidant qu’il n’existe pas de lien contractuel direct

entre les contractants extrêmes au sein des groupes de contrats. Aussi la

multiplicité des intervenants entraînant généralement une certaine confusion

des rôles il sera souvent difficile de déterminer le ou les prestataire(s)

responsable(s) de l’échec. 79 - B TEYSSIE, Les groupes de Contrats, Thèse Montpellier éd 1975 LGDJ 1975 80 - « L’architecture contractuelle dans les groupements de contrats de progiciel de gestion intégrée » - mémoire de DESS Droit de l’Informatique et du Multimédia 2003/2004 - Wallyd BENCHIKH 81 - Cass. Com, 22 janvier 1994, RIDA, 1991 n° 379 pour le maintient des contrats qui ne portent pas sur les prestations défectueuses ; Cass. Com 13 janv 1998, Expertises, 1998, p 235 en faveur de la résolution de l’ensemble des contrats reconnaissant ainsi l’indivisibilité des groupes de contrats. 82 - Cass. Ass Plén 12 juillet 1991, « arrêt Besse » D 1991. 549 note GHESTIN, JCP 1991, II, 21743 note G VINEY



50

C’est pourquoi le client préférera une gestion « Clé en main » du projet auprès

d’un prestataire unique qui fournira ainsi l’ensemble des prestations

nécessaires à la mise en œuvre du système informatique.

II§ Organisation « Clé en main » du projet :

Nous l’avons évoqué le client peut par souci de simplicité faire appel à un

prestataire unique dans le cadre d’une convention « Clé en main » qui

assumera une mission de maîtrise d’œuvre complète consistant, après avoir

étudier le besoin, à réaliser et un livrer un ensemble Informatique. Nous l’avons

déjà évoqué le rôle du prestataire « Clé en main » déborde largement de la

maîtrise d’œuvre classique dans la mesure où la mission comprend également

la définition du besoin (mission relevant normalement de l’assistance à maîtrise

d’ouvrage qu’elle soit interne ou externalisée). Aussi on a souvent du mal à

cerner l’étendue de la prestation « Clé en main » tant la diversité des

prestations fournies est généralement grande. Les conséquences en cas de

différend, concernant la satisfaction du système mis en œuvre aux objectifs

fixés, sont bien entendu différentes. Tout d’abord parce que dans ce cas le

projet s’articule dans le cadre d’une convention unique entre le client (maître

d’ouvrage) et le maître d’œuvre. Ainsi la responsabilité n’est pas diluée auprès

de multiples intervenants. La responsabilité du maître d’œuvre est également

différente en raison de l’étendue de sa mission. Aussi après avoir analysé

l’étendue du domaine d’intervention du contrat de maîtrise d’œuvre « Clé en

main » (A) nous en déterminerons les caractéristiques et la nature juridique (B)

et enfin nous établirons les obligations respectives des parties (C).

A ) Définition de la prestation « Clé en main » :

1 - Remarques préliminaires :

Avant d’évoquer l’étendue des prestations fournies il convient de déterminer ce

qu’est véritablement un contrat « Clé en main ». En effet comme l’a fait très

justement remarquer le Professeur Le Tourneau il existe deux variantes de

contrat de fourniture d’un ensemble informatique83 : l’une consistant

uniquement à fournir un ensemble matériel et logiciel qui se rapproche d’une

opération de vente ; l’autre que l’on qualifiera de « véritable contrat clés en 83 - Ph. Le Tourneau, Théorie et pratique des contrats Informatiques, Dalloz 2000



51

main (…) dans lequel l’engagement du prestataire porte sur un résultat global »

et dont nous détaillerons les caractéristiques ( nature et étendue des

prestations, nature juridique du contrat, obligations des parties ).

2 - Délimitation de la prestation « clé en main » :

L’opération « clé en main » se caractérise donc par une prestation globale par

laquelle un prestataire unique (maître d’œuvre) s’engage à livrer à son client un

ensemble Informatique impliquant nécessairement une multitude de prestations

associées (conseil en Informatique, fourniture de matériel, mise à disposition de

progiciel, réalisation d’un logiciel spécifique, maintenance Informatique,

formation …). Le contrat « Clé en main » mêle donc étroitement « trois types

distinctes de prestations, à savoir le conseil (concernant notamment l’étude et

la définition du besoin), la fourniture de matériel et de logiciel » 84.

• Les prestations d’étude et de conseil dans la définition du besoin (choix du

matériel, définition des fonctionnalités, spécifications d’exploitation…) aboutiront

à la rédaction d’un cahier des charges (comprenant les spécifications générales

et détaillées), qui devra être validé par le client.

• Le maître d’œuvre devra alors réaliser et livrer le système conformément au

cahier des charges (caractéristiques matérielles, fonctionnalités logicielles...).

B ) Caractéristiques et nature juridique du contrat « Clé en main » :

Nous l’avons évoqué le contrat « clé en main » implique des prestations qui

bien que techniquement et fonctionnellement distinctes ne peuvent être

dissociées. En effet aujourd’hui la doctrine85, ainsi que la jurisprudence86,

s’accordent pour appréhender ce contrat comme un tout indissociable dont la

nature juridique (relevant des contrats d’entreprise87) transcende la simple

juxtaposition des différentes prestations. Aussi le contrat « Clé en main »,

même lorsqu’il prévoit notamment la fourniture du support matériel dans le

cadre d’une vente, demeure un contrat d’entreprise88. Cette position semble

d’ailleurs conforme à la volonté commune des parties qui ont convenu de

l’exécution d’un contrat unique et nécessairement indivisible.

84 - Lamy Droit de l’Informatique et des Réseaux 2005, n°786, p527 85 - note GOUTAL sous CA Paris 5ème ch B, 4 janvier 1980, JCP éd G 1982, II, n° 19734 86 - Cass. 1ère civ, 18 sept. 2002. Expertises 2003, n° 269, p 149, note J HUET. 87 - CA Aix-en-Provence, 2ème ch, 7 fév 1991, Sté G3 S Informatique c/ Sté clinique de Toutes Autres, J-D n° 45592 88 - Lamy Droit de l’Informatique et des réseaux 2005



52

Les prestations « livrées » dans le cadre d’une opération « Clé en main » sont

donc indissociables et solidaires89. La solidarité entraînant l’interdépendance

des différentes prestations, « … la non-fourniture d’un seul élément ou sa non-

conformité ne pourra entraîner une résolution partielle du contrat mais la

résolution de l’ensemble contractuel »90.

C ) Obligations respectives des parties :

Nous l’avons déjà évoqué la particularité de la mission « Clé en main » entraîne

des obligations spécifiques (surtout envers le maître d’œuvre), à savoir : une

obligation « renforcée » de conseil (1.1) ainsi qu’à une obligation de résultat lors

de la livraison du système (1.2) sans décharger pour autant le client d’une

nécessaire collaboration (2).

1.1 - Devoir de Conseil renforcé :

En effet le maître d’œuvre « clé en main » assume la bonne fin de l’ensemble

du projet (définition, conception, réalisation, livraison). Il est donc responsable

d’un certain nombre de choix déterminants notamment en ce qui concerne la

définition du besoin du client (qui relève en principe de la maîtrise d’ouvrage) et

la fourniture du système. Il est ainsi en quelque sorte « juge et partie ». Ce qui

peut amener à considérer que la réussite (ou l’échec) dépend essentiellement

du maître d’œuvre et de la qualité de son intervention. C’est pourquoi il est tenu

à une obligation renforcée (primordiale91) de conseil, à raison de la nature

particulière de sa mission92, d’une part lors de l’étude préalable et la définition

du besoin et d’autre part durant la mise en place du système en informant le

client sur les contraintes et les risques des choix techniques effectués93 voire le

dissuader de mettre en place un procédé susceptible de subir de graves

dysfonctionnements potentiels94. Il ne s’agit cependant que d’une obligation de

moyens dans la mesure où la qualité du conseil du maître d’œuvre dépend de

la collaboration active du client95.

89 - « Pratique du Droit de l’Informatique », 5ème éd. DELMAS 2002, X Linant de Bellefonds, A Hollande, p 77 90 - T C Paris, 28 février 1984, Expertises 1984, p 108 91 - CA Paris, 4 janvier 1980, Sté Cerci/Cadeaux Publi Service, JCP 1982, II-19734. 92 - CA Paris, 27 mars 1984, Olivetti c/ Rollet, D. 1985 somm. 42, obs. HUET J 93 - Cass. Com. 19 mai 1998, Expertises 1998, n°210, p 310 ; Cass. Com. 5 janv 1999, Expertises 1999, n° 229, p 269 94 - CA Paris, 4 janvier 1980, Sté Cerci/Cadeaux Publi Service, JCP 1982, II-19734 95 - CA Paris, 5ème ch, A, 28 sept. 1988, Sté Financière La Jardine c / Stés ICL France et Jarène, n° 86/1787



53

1.2 – Obligation de livraison conforme :

Une fois le cahier des charges défini et validé par le client, le maître d’œuvre

s’engage à réaliser et à livrer un système conforme aux spécifications96 et

opérationnel. Le prestataire « clé en main » est alors tenu à une obligation de

résultat97. Cette analyse parait évidente concernant la livraison du support

matériel et du ou des progiciel(s) intégré(s) dont les caractéristiques peuvent

être déterminées d’avance. Cependant qu’en est-il en ce qui concerne la

réalisation et la livraison d’un logiciel spécifique ? Nous pouvons considérer

qu’à partir du moment où le cahier des charges définit précisément les

spécifications du logiciel envisagé l’obligation de livraison conforme engage la

responsabilité du maître d’œuvre et demeure une obligation de résultat98.

De même le maître d’œuvre sera responsable des dommages causés par les

dysfonctionnements du système99. Toutefois cette responsabilité ne peut être

établie que si l'état des sciences et de la technologie permettait légitimement,

au moment de la conception et de la livraison du système informatique, d’en

garantir la sécurité. Le maître d’œuvre n’est donc tenu à ce titre que d’une

obligation de moyen.

Généralement le maître d’œuvre ne disposant pas de toutes les compétences

nécessaires à la réalisation de sa mission il sera amené à sous-traiter certaines

prestations auprès de divers intervenants spécialisés. Toutefois il demeura

responsable envers le client de la qualité et de la conformité de ces prestations

dont il assure la coordination. En outre il devra soumettre le ou les

intervenant(s) concerné(s) à l’acceptation du client100. L’acceptation des sous-

traitants sera généralement établie dans le cahier des charges qui devra

spécifier les divers intervenants ainsi que leur(s) prestation(s) respectives.

Nous l’avons évoqué la responsabilité du maître d’œuvre « Clé en main » est

considérable mais dépend de la nécessaire collaboration du client101.

96 - TGI Lyon, 12 avril 1989, Me Clop et six autres huissiers / Nixdorf Computer, Expertises 1989, n° 121, p 358 97 - De Lamberterie I, « Les contrats Informatiques », Litec 1983, n° 194 et 195 98 - Cass. Civ., 14 avril 1992, SCP Illy-Meffre / Nixdorf, Expertises 1992, p 265. 99 - art 1386-1 et suivants. C Civ relatif à la responsabilité du fait des produits défectueux. 100 - art 3 de la loi du 31 décembre 1975 relative à la sous-traitance. 101 - CA Paris, 5ème ch, A, 28 sept. 1988, Sté Financière La Jardine c / Stés ICL France et Jarène, n° 86/1787 ; CA Paris, 16 février 1990, Laiterie Le St Denis de l’Hôtel / Burroughs, Expertises 1990 n° 126, p 111



54

2 – Obligation de collaboration du client :

Comme le relève très justement la doctrine « Dans certains cas, le client … se

repose entièrement sur le fournisseur, jugé totalement compétent, n’assume

pas pleinement son rôle dans la définition des besoins et décline

volontairement ou involontairement toute initiative dans la transmission des

informations indispensables à la mise en œuvre de l’opération. Or, c’est précisément dans le clé en main que la collaboration du client se révèle le

plus nécessaire en pratique »102. Le rôle du client est en effet essentiel dans

la réussite du projet. Celui-ci devra donc valider avec soin le cahier des

charges, établi par le maître d’œuvre, confirmant ainsi la « conformité » des

spécifications définies à son besoin. Durant la phase de réalisation il devra

collaborer avec le maître d’œuvre et les divers intervenants. Lors de la

réception du système il devra vérifier la conformité du système livré et des

fonctionnalités intégrées aux spécifications en établissant les jeux de tests

adaptés et les divers documents de contrôle.

Nous l’avons vu le rôle du maître d’œuvre « clé en main » est déterminant.

Ainsi il pourrait sembler logique de considérer que l’opération « clé en main »

implique nécessairement pour le maître d’oeuvre une obligation de résultat

concernant la satisfaction du client. La jurisprudence semble considérer que le

maître d’œuvre « clé en main » est tenu à une obligation de résultat103. La

doctrine semble partagée mais considère majoritairement qu’il s’agit

fondamentalement d’une obligation de moyens. La confusion s’explique sans

doute par la diversité des prestations fournies. En effet le maître d’œuvre « clé

en main » est amené dans un premier temps à intervenir en tant que conseil

dans l’analyse et la définition du besoin. La collaboration active du client reste

alors indispensable. Il n’est donc tenu qu’à une obligation renforcée de moyens

en tant que conseil non réalisateur, c'est-à-dire ne réalisant et ne livrant aucune

prestation matérielle ou logiciel.

102 - « Pratique du Droit de l’Informatique », 5ème éd. DELMAS 2002, X Linant de Bellefonds, A Hollande, p 75 103 - Cass. Civ., 14 avril 1992, SCP Illy-Meffre / Nixdorf , Expertises 1992, p 265



55

Ce n’est qu’une fois que les spécifications du besoin auront été définies et

validées par le client que le maître d’œuvre, en tant que réalisateur du système,

sera tenu d’une obligation de résultat concernant la livraison d’un système

conforme aux spécifications104. Dès lors le seul fait que le résultat ne soit pas

atteint (système Informatique opérationnel, fonctionnel et conforme au besoin

des utilisateurs) n’établit pas nécessairement la faute du fournisseur105. En effet

le maître d’œuvre clé en main « n’a donc pas plus d’obligations que n’en

auraient à eux tous les divers prestataires concourant à l’informatisation. »106.

La nature des obligations du maître d’œuvre dépend donc avant tout de l’objet

de son intervention (en tant que conseil ou réalisateur). Aussi même dans le

cadre d’une opération « Clé en main » le client ne pourra se reposer

entièrement sur le savoir-faire du maître d’œuvre et devra assumer pleinement

son rôle dans la définition du besoin et la collaboration indispensable au succès

d’un projet Informatique.

104 - De Lamberterie I, « Les contrats Informatiques », Litec 1983, n° 194 et 195 105 - CA Paris, 5ème Ch. A, 28 sept. 1988, Sté Financière La Jardine c / Stés ICL France et Jarène, n° 86/1787 106 - Lamy Droit de l’Informatique et des Réseaux 1999, n°849, p502



56

Conclusion : Nous l’avons vu le client aura le choix entre une gestion diversifiée, en

procédant à une répartition « par lots » de son projet d’informatisation ou dans

un cadre unique « clé en main » par lequel le maître d’œuvre fourni l’ensemble

des prestations. Pour autant le maître d’oeuvre « clé en main » ne peut

assumer la responsabilité exclusive du projet, qui traduirait une obligation de

résultat. Le client devra pleinement s’impliquer dans le projet et collaborer avec

le maître d’œuvre. En effet l’originalité et l’intérêt de l’opération ne tiennent pas

tant à la nature de l’obligation du maître d’œuvre mais plutôt à l’unicité du cadre

juridique excluant ainsi le risque de dilution des responsabilités entre les divers

intervenants. Aussi l’obligation de conformité (obligation de résultat) du maître

d’œuvre « clé en main », agissant en tant que réalisateur du système, n’est pas

différente de celle du maître d’œuvre ou toute autre prestataire réalisant une

prestation déterminée. Nous l’avons vu l’obligation de conseil n’est pas

uniforme et présente toute une gamme d’intensité107. L’intensité de l’obligation

de conseil dépendra donc du périmètre d’intervention du maître d’œuvre. Ce

devoir sera renforcé lorsqu’il assumera une mission complète « clé en main »108

ou amoindri lorsque le client aura préalablement fait recours à une société de

conseil en Informatique109. Dans tous les cas, le client devra assumer

pleinement son rôle décisionnel et primordial dans le projet, notamment dans le

cadre de la définition de son besoin. Le choix d’une gestion diversifiée ou « clé

en main » ne devra donc pas être motivé par le souhait du client de se

décharger de sa responsabilité mais par un raisonnement d’opportunité

économique et technique.

107 - CA Paris, 25ème ch, 12 nov 1985, Juris-Data n° 25007 108 - CA Paris, 4 janvier 1980, Sté Cerci/Cadeaux Publi Service, JCP 1982, II-19734 109 - CA Paris, 5ème ch, 12 janv. 1979, Juris-Data n° 35 in Lamberterie, n° 31, p 23



57

Conclusion Générale :

Nous l’avons vu la réussite d’un projet Informatique dépend essentiellement de

l’implication réelle du client ainsi que du savoir-faire du maître d’œuvre et de

l’ensemble des prestataires. Le maître d’œuvre quant à lui sera tenu à une

obligation dont la nature et l’intensité dépendront de l’objet de son intervention

et de l’étendue de sa mission. Les projets Informatiques consistent

généralement à mettre en œuvre un système Informatique, qui sera géré et

administré par l’entreprise cliente. Aujourd’hui on assiste de plus en plus à la

mise en place d’applications en mode web (ASP ...) voire vers l’externalisation

des ressources Informatiques (processus, applications, données). Il pourrait

alors être tentant de croire que ce type de projet ne nécessite pas autant de

rigueur que ce que nous venons de voir. Pourtant la nature des interventions

demeure fondamentalement la même. Ainsi le client devra assumer pleinement

sa maîtrise d’ouvrage, en se faisant éventuellement assister d’une société de

conseil en Informatique, afin de déterminer les ressources informatiques qu’il

souhaite externaliser (son besoin). En effet comme l’explique les professionnels

« … on n’externalise bien que ce qu’on connaît. »110. Il conviendra également

d’envisager les modalités techniques du transfert, garantissant la disponibilité

des données lors du basculement (redondance…) ainsi que leur protection

(confidentialité, intégrité), en conformité avec la loi « informatique et liberté»111.

Il sera généralement utile (voire indispensable) d’envisager les modalités d’un

éventuel retour en arrière (restitution des données, réversibilité du processus,

dédit en faveur de prestataire en cas de rupture anticipée du contrat). Une fois

les spécifications déterminées, la maîtrise d’œuvre consistera à mettre en

œuvre les moyens techniques du transfert des données vers l’application

infogérée. Ce type d’opération est donc plus sensible encore qu’une

informatisation classique (cette opération est en effet souvent vécue comme

une perte de contrôle par l’entreprise cliente sur son système d’information) et

implique donc une rigueur accrue de la part des acteurs du projet.

110 - « Départ de Renault : Jean-Pierre Corniou ne dément pas » - LeMondeInformatique.fr du 11/04/2006 111 - Loi CNIL du 6 janvier 1978 (art 34 notamment)



58

Aussi le client devra s’impliquer pleinement d’une part dans le cadre du

transfert des données (audit de l’ensemble des ressources informatiques,

définition des spécifications, contrôle de conformité et de qualité des données

lors des recettes de l’opération d’externalisation) mais également durant le

déroulement du contrat en informant le prestataire des éléments susceptibles

d’affecter l’exploitation du système d’Information et en encourageant la

collaboration entre ses équipes et celles du prestataire. De son côté le

prestataire, généralement maître d’œuvre de l’opération d’externalisation des

ressources informatiques du client, est bien entendu garant de son savoir-faire

mais également d’engagements particuliers liés à la nature du projet (garantie

quant à la confidentialité et à la sécurité (intégrité) des données, à l’égard des

droits d’utilisation du ou des progiciel(s) infogéré(s), voire des garanties

financières en cas de cessation d’activité afin de permettre au client la

restitution de ses données). En effet malgré des efforts pour normaliser ce type

de contrat112 il semble qu’il soit difficile d’organiser de manière certaine des

relations adaptées entre les parties tant les opérations sont spécifiques à

chaque entreprise et pour lesquelles les professionnels manquent de

l’expérience nécessaire pour en maîtriser précisément le bon déroulement113. Il

est donc indispensable d’appréhender ce type d’opération semblablement à

toute autre opération informatique, sans quoi le risque d’échec est quasiment

inévitable. Malheureusement encore aujourd’hui les clients (décideurs)

entretiennent l’illusion que l’informatisation des processus de gestion et

d’exploitation des données nécessaires à leur activité dépend exclusivement de

la responsabilité du ou des prestataires (s) et de leur savoir-faire. Or

l’informatisation se construit à deux (le client et le maître d’œuvre) et implique

généralement une relation sur la durée (dans le cadre de la mise en œuvre et

durant l’exploitation des ressources). Il semble donc évident que la réussite

passe plus que jamais par une maîtrise d’ouvrage forte et mature.

112 - « Pratique du Droit de l’Informatique », 5ème éd. DELMAS 2002, X Linant de Bellefonds, A Hollande 113 - « Départ de Renault : Jean-Pierre Corniou ne dément pas », précité



59

Annexes : 1. Définitions :

• Système d’information .………………………………………. p 58 • Maîtrise d’Ouvrage …………………………………………… p 58 • Modélisation …………………………………………………… p 60 • Urbanisation …………………………………………………… p 60 • Maîtrise d’œuvre .…………………………………………….. p 60 • Analyse fonctionnelle et organique …………………………. p 60

• Système d’information : (définition diffusée par Wikipédia ) Un ensemble organisé de ressources (matériel, logiciel, personnel, données, procédures…) permettant d'acquérir, de stocker, de transformer et de communiquer des informations sous forme de textes, images, sons, ou de données codées dans des organisations. Selon leur finalité principale, on distingue des systèmes d'information supports d'opérations (traitement de transaction, contrôle de processus industriels, supports d'opérations de bureau et de communication) et des systèmes d'information supports de gestion (aide à la production de rapports, aide à la décision…). Un système ou sous-système d'équipements, de télécommunication ou informatique, interconnectés dans le but de l'acquisition, le stockage, la manipulation, la gestion, le déplacement, le contrôle, l'affichage, l'échange, la transmission ou la réception de voix et/ou de données, faisant intervenir, des logiciels et du matériel. Parmi ces éléments le système d’Information peut comprendre un oui plusieurs progiciels qui se définissent par « un ensemble cohérent et indépendant constitué de programmes, de services, de supports de manipulation ou d’information (bordereaux, langages …) et d’une documentation conçue pour réaliser des traitements informatiques standards, dont la diffusion revêt un caractère commercial et qu’un usager peut utiliser de façon autonome, après une mise en place et une formation limitées ».

• Maîtrise d’Ouvrage :

On appelle maître d'ouvrage (parfois maîtrise d'ouvrage, notée MOA) l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet. Le résultat attendu du projet est la réalisation d'un produit, appelé ouvrage. La maîtrise d'ouvrage maîtrise l'idée de base du projet, et représente à ce titre les utilisateurs finaux à qui l'ouvrage est destiné. Ainsi, le maître d'ouvrage est responsable de l'expression fonctionnelle des besoins mais n'a pas forcément les compétences techniques liées à la réalisation de l'ouvrage.



60

• Modélisation et Urbanisation :

La modélisation consiste à envisager l’ensemble du système

d’Information et de ses fonctionnalités nécessaires sous forme de

modèle (type UML) afin de dégager les solutions techniques

aptes à répondre au besoin.

Une méthode de modélisation informatique avec UML, par Michel Volle http://solutions.journaldunet.com/0503/050322_chro_bpms.shtml

L’urbanisation consiste à préparer la mise en oeuvre du système

d’Information et organiser sa mise en place et son exploitation

future afin d’anticiper les conséquences managériales et

organisationnelles au niveau des utilisateurs et ainsi d’en limiter

les effets négatifs.

Notion d’Urbanisation des SI http://fr.wikipedia.org/wiki/Urbanisation_(informatique)

• Maîtrise d’Oeuvre :

Le maître d'oeuvre (ou maîtrise d'oeuvre, notée MOE) est l'entité retenue par le maître d'ouvrage pour réaliser l'ouvrage, dans les conditions de délais, de qualité et de coût fixées par ce dernier conformément à un contrat. La maîtrise d'oeuvre est donc responsable des choix techniques inhérents à la réalisation de l'ouvrage conformément aux exigences de la maîtrise d'ouvrage. Dans le cadre de sa mission, le maître d’œuvre devra procéder à l’analyse fonctionnelle (1) et organique (2). 1 ) L’analyse fonctionnelle consiste à déterminer l’ensemble des spécifications et des performances défini pour chaque fonction. 2 ) L’analyse organique à consiste à déterminer les incidences issues du type de matériels, des systèmes d’exploitation, de l’architecture réseau (local, distant) sur l’exploitation du système.



61

2. Références :

2.1. Législation :

• Loi CNIL du 6 janvier 1978 • Responsabilité du fait des produits défectueux (art 1386-1 et s C Civ)

2.2. Bibliographie et ressources web :

• « La Maîtrise d’Ouvrage de projet de Système d’information » AFAI – Collection Pratiques Professionnelles (Septembre 2003)

• « Maîtrise d’œuvre en Informatique » de Jacques VIET Gazette du palais 1992 (1er sem.) , Doctrine

• « De l’Informatique ( savoir vivre avec l’automate ) » Michel VOLLE, éditions économica 2006 • « Les difficiles rapports DSI - maîtrises d'ouvrage »

de Laëtitia BARDOUL - Journal du Net le 15/11/2004 ûhttp://solutions.journaldunet.com/0411/041115_enquete_moa.shtml

• « La conduite du changement, enjeu de l’adhésion des utilisateurs » de Laëtitia BARDOUL - Journal du Net le 7/03/2005 ûhttp://solutions.journaldunet.com/0503/050307_changement.shtml

• « CRM : l’intégration des données, une étape imposée » de Laëtitia BARDOUL - Journal du Net le 14/03/2005 ûhttp://solutions.journaldunet.com/0503/050314_integration_donnees.shtml

• « Le traitement juridique des failles de sécurité » de Me Marc d’Haultfoeuille - Journal du Net le 8/11/2005 ûhttp://www.journaldunet.com/juridique/juridique051108.shtml

• « Archivage électronique : des contraintes juridiques et technologiques» de E CAPRIOLI et G WEISZ - Journal du Net le 16/03/2004 ûhttp://www.journaldunet.com/juridique/juridique040316.shtml • « La Responsabilité des entreprises prestataires de conseils »

JCP éd G 1975, I, n° 2750 – Genevieve VINEY • « Le contrat dit de licence de logiciel »

JCP éd G 1986, II. 14659, H CROZE et Y BISMUTH • « La Responsabilité du Créateur de Logiciel et ses limites » Gazette du Palais du 16 avril 1992 – Me Danièle DELAVAL • « Le logiciel : analyse juridique »

Fiduci-LGDJ 1986 – F TOUBOL • « Pratique du droit de l’Informatique »

Alain HOLLANDE / Xavier LINANT DE BELLEFONDS – DELMAS 2002 • « L’architecture contractuelle dans les groupements de contrats de

progiciel de gestion intégrée » - Wallyd BENCHIKH DESS Droit de l’Informatique et du Multimédia 2003/2004

• « Responsabilité de l'entreprise et de ses dirigeants du fait de la perte de données informatiques »

de Me Isabelle RENARD - Journal du Net 23/01/2003 ûhttp://solutions.journaldunet.com/0301/030123_chro_juridique.shtml



62

2.3. Pour aller plus loin : En ce qui concerne le Droit Informatique • CNIL (Commission de l’Informatique et des Libertés) ûhttp://www.cnil.fr/ • Droit NTIC ûhttp://www.droit-ntic.com • Droit et Nouvelles Technologies ûhttp://www.droit-technologie.org/ • Lex Electronica ûhttp://www.lex-electronica.org/

Au niveau Informatique : • Sommet Mondial sur la Société de l’Information ( SMSI ) û http://www.itu.int/wsis/contact/index-fr.html • AFAI (Association Française de l’Audit et du Conseil Informatiques) – û http://www.afai.fr/ • CLUSIF ( Club de la Sécurité des Systèmes d’Information Français )

û https://www.clusif.asso.fr • http://www.volle.com ( Michel VOLLE ) • Club de la Maîtrise d’Ouvrage des Systèmes d’Information û http://www.clubmoa.asso.fr/ • Club des Urbanistes et Architectes des Systèmes d’Information û http://www.urba-si.asso.fr/ • Cigref : Club Informatique des Grandes Entreprises Françaises û http://www.cigref.fr/index.html



63

3. Divers types d’organisation de projet : 3.1 Organisation dissociée : Définition du besoin (Conception) …

…Réalisation et Livraison du Système.

3.2 Organisation « Clé en main » :

MOA (décisionnelle) Client

MOA déléguée Cahier des charges Spécifications Générales

Spécifications Détaillées

MOE (Conseil) Maî

tris

e d’

Ouv

rage

Contrat de Conseil et d’Assistance Informatique

Contrôle et validation par la maîtrise d’ouvrage décisionnelle des spécifications détaillées

(Établies par le MOE)

MOA (décisionnelle) Client

MOA déléguée

Remise des recettes

MOE de conception (Réalisateur)

Maî

tris

e d’

Ouv

rage

Contrat de Conseil et d’Assistance Informatique

Cahier des charges

Contrôle et validation, par la maîtrise d’ouvrage, de la conformité du système (et de ses différents

composants logiques et matériels) livré au cahier des charges.

Prestataires (éditeurs …)

MOE (Conseil) MOA (décisionnelle)Client

Cahier des charges Spécifications

Générales et Détaillées

MOE (Réalisateur)

Contrôle et validation par la maîtrise d’ouvrage des

spécifications du besoin.

Contrôle et validation, par la maîtrise d’ouvrage,

de conformité du système réalisé au cahier des charges.

MOE d’accompagnement (Conseil)


maîtrise d'ouvrage- maîtrise d'oeuvre - droit-ntic.com · gestion de processus de...

Documents