Mémoire d étude Thierry ROBY. [email protected]

Transcription

1 Mémoire d étude 2006 Thierry ROBY [email protected]

2 «la technique pour l Informatique (Maîtrise d œuvre), la sémantique pour la Maîtrise d Ouvrage». Michel VOLLE

3 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 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 5 Dans les projets de la mise en œuvre de Systèmes d Information

6 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 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 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 9 Maîtrise d Ouvrage Maîtrise d œuvre Dans les projets de la mise en œuvre de Systèmes d Information

10 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ée 3. 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 «De l Informatique ( savoir vivre avec l automate )» - Michel VOLLE, éditions économica 2006, chapitre 12

11 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 du 6 janvier 1978.

12 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 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ésirait 6. 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 œuvre 7. 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/ CA Paris 8 mars «La conduite du changement, enjeu de l adhésion des utilisateurs» JDN

14 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 informatique 9 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 charges 10. 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 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 informatique 11. 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 doctrine 12. 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 entreprise 13 à 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 Geneviève VINEY «La responsabilité des entreprises prestataires de conseil» JCP éd G 1975, I, n De Lamberterie I «Les Techniques Contractuelles suscitées par l Informatique» Thèse Paris 1977, Malaurie et Aynès - Contrats Spéciaux Cujas Lamy Droit de l informatique et des réseaux 1999 «Les Contrats de conseil en informatique»

16 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 conseil 14 selon les règles de l art en vigueur dans la profession 15. Ce devoir de conseil consiste en une obligation de moyens 16, à 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 certain 17. 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 cause 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 ; CA Paris, 25 ème ch. A 23 janv 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» CA 1 ère ch, A, sect urg 22 avril 1980 Sté Olivetti / Karpathios

17 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 18 responsabilité envers le client pour avoir manqué à sa mission de contrôle 20. En effet le professionnel aura validé le système pour le compte de son client 21 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 grave 22. 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é 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 besoin 25, 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 information 26. 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 1 er 26 janvier 1999, BI n art 1991 et 1992 du Code Civil 23 - Cass 1 ère civ 21 déc 1964, n , 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 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 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 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 client 27 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 Cass, soc 1 er déc 1976, N , Gaz Pal 1977

20 20 Maîtrise d Ouvrage Maîtrise d œuvre Dans les projets de la mise en œuvre de Systèmes d Information

21 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 œuvre 28 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 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 fonctionnelle 29, 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écifique 31. Dès lors, il devra procéder à l analyse organique 32 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 On notera à ce sujet l initiative AUCHAN et DAIMLER BENZ en matière d intégration de solution open source voir définitions en annexe p

23 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 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 œuvre 33. 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ésenter 34. 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 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 25 chaque opération sa qualification propre 35, il semble qu il soit préférable de déterminer une qualification d ensemble 36, 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 entreprise 37. 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 travail 38, à 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écis 40. 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 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 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 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 moyens 41 et ne peut engager un résultat certain 42. Certains auteurs considèrent que la maîtrise d œuvre «Clé en main» implique nécessairement une obligation de résultat 43. Or même en cas de contrat «Clé en main» la collaboration du client est nécessaire à la satisfaction de son besoin 44. 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 disponibles 45. 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 ; CA Paris, 25ème ch. A 23 janv 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/ T Com Marseille. 17 juin 1994 Sté Lodecom c / Sté Cati n CA Paris, 25 ème ch. A, 10 avril 1990 Sté Prosystem c / Sté Typophot Studio, Juris-Data, n 21244

27 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 fautil 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 conforme 47. Aujourd hui la sécurité des Systèmes d Information constitue à l évidence un enjeu crucial 48. 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 doctrine 49, 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 fond 50. 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 support 51. 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 et suivants Code civil). En effet on le sait ce régime de responsabilité est applicable aux logiciels 52. Toutefois il semble que l application de ce régime de responsabilité soit limitée aux atteintes physiques aux biens ou aux personnes 53. Or il faut remarquer que la loi ne limite pas explicitement l application de ce régime de responsabilité aux atteintes physiques 54. 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/ 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 Bohoussou L'Obligation de garantie dans les contrats relatifs à l'informatique, Thèse, Montpellier, CA Paris, 25 ème ch. B, 22 juin 2001; Cass. com 19 mai 1998 n «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 l article 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 28 également les atteintes causées à des choses incorporelles. L information considérée comme un bien 55, 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ôle 56. En effet le professionnel aura validé le système pour le compte de son client 57 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 grave 58. 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 «Etude sur le statut juridique de l Information» - Chron DALLOZ n de E DARAGON 56 - art 1993 Code Civil 57 - art 1998 du Code Civil ; Civ 1 er 26 janvier 1999, BI n art 1991 et 1992 du Code Civil

29 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 informatique Cass 1 ère civ 21 déc 1964, n , 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 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 p 52. CA Paris 5ème ch B, 30juin 1983, Passeport c/kienzle Informatique, Juris-Data n

30 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ée 61. 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 Cass 1 ère civ 21 déc 1964, n , JCP éd G 1965, II, n ; CA Paris, 25 ème ch B, 7 juillet 1989, Sté Pragama et autre c/ Sté Casanova, Juris-Data, n 23628

31 31 Maîtrise d Ouvrage Maîtrise d œuvre

32 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 œuvre 62. 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) TGI Paris 7 mars 1989, GPE / Edition C et T / France Télécom

33 33 Rôle et Responsabilité Maîtrise d Ouvrage Maîtrise d œuvre

34 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élisation 63 du système d information, afin de traduire le besoin fonctionnel des utilisateurs finaux (la vision métier), et son urbanisation 64. 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 «L Urbanisme : une opportunité pour réinventer la relation maîtrise d ouvrage / maîtrise d oeuvre», Christophe LONGPEPE

35 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 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 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 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 charges 65, 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 39 suffisamment précis 67. 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 40 dans le cahier des charges. Le système livré doit donc comprendre toutes les fonctions envisagées, opérationnelles et disponibles 69. 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é 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ème 71. 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 T Com Marseille. 17 juin 1994 Sté Lodecom c/ Sté Cati n CA Paris, 25 ème ch. A, 10 avril 1990 Sté Prosystem c / Sté Typophot Studio, Juris-Data, n art et s du Code Civil relatif à la loi sur la responsabilité du fait des produits défectueux

41 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 42 Stratégie distributive ou unitaire de la Responsabilité Maîtrise d Ouvrage Maîtrise d œuvre

43 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 luimê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 complexe 72 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 «Projet ERP : quelle structure contractuelle choisir?» - de Me Marc d Haultfoeuille (Journal du Net 20/11/2002)

44 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 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) ) 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és art 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 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 conseil 75. 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 CA. Paris 5ème ch., 7 avril 1993, JDD Informatique c/ Sté Nouvelle Para hôtelière : Expertise novembre 1993

47 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 assistant 76. 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 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 intervention 77. 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 acquises 78. 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 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 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 contrats 79, 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 PGI 80 (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 incertaine 81. D autant que la cour de cassation est revenu à une lecture classique de l article 1165 du code civil 82 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 B TEYSSIE, Les groupes de Contrats, Thèse Montpellier éd 1975 LGDJ «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/ 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 Cass. Ass Plén 12 juillet 1991, «arrêt Besse» D note GHESTIN, JCP 1991, II, note G VINEY

50 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 informatique 83 : 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 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 doctrine 85, ainsi que la jurisprudence 86, s accordent pour appréhender ce contrat comme un tout indissociable dont la nature juridique (relevant des contrats d entreprise 87 ) 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 entreprise 88. 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 Lamy Droit de l Informatique et des Réseaux 2005, n 786, p note GOUTAL sous CA Paris 5 ème ch B, 4 janvier 1980, JCP éd G 1982, II, n Cass. 1 ère civ, 18 sept Expertises 2003, n 269, p 149, note J HUET CA Aix-en-Provence, 2 ème ch, 7 fév 1991, Sté G3 S Informatique c/ Sté clinique de Toutes Autres, J-D n Lamy Droit de l Informatique et des réseaux 2005

52 52 Les prestations «livrées» dans le cadre d une opération «Clé en main» sont donc indissociables et solidaires 89. La solidarité entraînant l interdépendance des différentes prestations, «la non-fourniture d un seul élément ou sa nonconformité 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) 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 (primordiale 91 ) de conseil, à raison de la nature particulière de sa mission 92, 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és 93 voire le dissuader de mettre en place un procédé susceptible de subir de graves dysfonctionnements potentiels 94. 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 client «Pratique du Droit de l Informatique», 5 ème éd. DELMAS 2002, X Linant de Bellefonds, A Hollande, p T C Paris, 28 février 1984, Expertises 1984, p CA Paris, 4 janvier 1980, Sté Cerci/Cadeaux Publi Service, JCP 1982, II CA Paris, 27 mars 1984, Olivetti c/ Rollet, D 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 CA Paris, 4 janvier 1980, Sté Cerci/Cadeaux Publi Service, JCP 1982, II 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 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écifications 96 et opérationnel. Le prestataire «clé en main» est alors tenu à une obligation de résultat 97. 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ésultat 98. De même le maître d œuvre sera responsable des dommages causés par les dysfonctionnements du système 99. 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 client 100. L acceptation des soustraitants 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 client TGI Lyon, 12 avril 1989, Me Clop et six autres huissiers / Nixdorf Computer, Expertises 1989, n 121, p De Lamberterie I, «Les contrats Informatiques», Litec 1983, n 194 et Cass. Civ., 14 avril 1992, SCP Illy-Meffre / Nixdorf, Expertises 1992, p art et suivants. C Civ relatif à la responsabilité du fait des produits défectueux art 3 de la loi du 31 décembre 1975 relative à la sous-traitance 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 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ésultat 103. 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 «Pratique du Droit de l Informatique», 5 ème éd. DELMAS 2002, X Linant de Bellefonds, A Hollande, p Cass. Civ., 14 avril 1992, SCP Illy-Meffre / Nixdorf, Expertises 1992, p 265

55 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écifications 104. 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 fournisseur 105. 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 De Lamberterie I, «Les contrats Informatiques», Litec 1983, n 194 et CA Paris, 5 ème Ch. A, 28 sept. 1988, Sté Financière La Jardine c / Stés ICL France et Jarène, n 86/ Lamy Droit de l Informatique et des Réseaux 1999, n 849, p502

56 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 Informatique 109. 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 CA Paris, 25 ème ch, 12 nov 1985, Juris-Data n CA Paris, 4 janvier 1980, Sté Cerci/Cadeaux Publi Service, JCP 1982, II CA Paris, 5 ème ch, 12 janv. 1979, Juris-Data n 35 in Lamberterie, n 31, p 23

57 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 «Départ de Renault : Jean-Pierre Corniou ne dément pas» - LeMondeInformatique.fr du 11/04/ Loi CNIL du 6 janvier 1978 (art 34 notamment)

58 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 contrat 112 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éroulement 113. 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 «Pratique du Droit de l Informatique», 5 ème éd. DELMAS 2002, X Linant de Bellefonds, A Hollande «Départ de Renault : Jean-Pierre Corniou ne dément pas», précité

59 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 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 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 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 61 2. Références : 2.1. Législation : Loi CNIL du 6 janvier 1978 Responsabilité du fait des produits défectueux (art 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 (1 er 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/ «La conduite du changement, enjeu de l adhésion des utilisateurs» de Laëtitia BARDOUL - Journal du Net le 7/03/ «CRM : l intégration des données, une étape imposée» de Laëtitia BARDOUL - Journal du Net le 14/03/ «Le traitement juridique des failles de sécurité» de Me Marc d Haultfoeuille - Journal du Net le 8/11/ «Archivage électronique : des contraintes juridiques et technologiques» de E CAPRIOLI et G WEISZ - Journal du Net le 16/03/ «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 , 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

62 Pour aller plus loin : En ce qui concerne le Droit Informatique CNIL (Commission de l Informatique et des Libertés) Droit NTIC Droit et Nouvelles Technologies Lex Electronica Au niveau Informatique : Sommet Mondial sur la Société de l Information ( SMSI ) AFAI (Association Française de l Audit et du Conseil Informatiques) CLUSIF ( Club de la Sécurité des Systèmes d Information Français ) ( Michel VOLLE ) Club de la Maîtrise d Ouvrage des Systèmes d Information Club des Urbanistes et Architectes des Systèmes d Information Cigref : Club Informatique des Grandes Entreprises Françaises

63 63 3. Divers types d organisation de projet : 3.1 Organisation dissociée : Définition du besoin (Conception) Cahier des charges Spécifications Générales MOE (Conseil) MOA (décisionnelle) Client Contrat de Conseil et d Assistance Informatique MOA déléguée Maîtrise d Ouvrage Spécifications Détaillées Contrôle et validation par la maîtrise d ouvrage décisionnelle des spécifications détaillées (Établies par le MOE) Réalisation et Livraison du Système. MOE de conception (Réalisateur) Remise des recettes MOE d accompagnement (Conseil) Prestataires (éditeurs ) 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. 3.2 Organisation «Clé en main» : MOA (décisionnelle) Client Contrat de Conseil et d Assistance Informatique MOA déléguée Cahier des charges Maîtrise d Ouvrage MOE (Conseil) MOE (Réalisateur) Cahier des charges Spécifications Générales et Détaillées MOA (décisionnelle) Client 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.