Dans un arrêt du 11 octobre 2022, la cour d’appel de Rennes en a déduit que le client ne pouvait pas refuser l’offre de son prestataire de vérifier avec lui les causes de l’apparition du problème et les moyens d’y remédier. « En s’abstenant en effet de rechercher une solution technique avec son cocontractant, elle [la société cliente] s’est interdit de démontrer que le grief allégué existe, est pérenne, et interdit toute poursuite du contrat ». Dans ces conditions, la cour a estimé que ni la résolution ni la résiliation du contrat n’étaient justifiées.
L’obligation de collaboration du client est particulièrement présente en matière de contrats informatiques, notamment concernant les contrats de développement de logiciels spécifiques.
C'est d'ailleurs sur les épaules du client que pèse la première obligation dans un projet informatique puisqu'il lui appartient d'exprimer son besoin, ce qui se fait au travers de la remise au prestataire d'un cahier des charges.
En matière de développement de logiciels spécifiques, l'expression du besoin par le client doit être la condition sine qua non de l'existence d'une obligation de résultat.
En l'absence d'expression précise par le client de son besoin dans un cahier des charges ou tout autre document à fonction équivalente, le prestataire n'en reste pas moins tenu à une obligation de développer un logiciel conformément aux instructions ou consignes qu'il a reçues.
Le maître d'ouvrage doit exécuter, en toute bonne foi, la convention en collaborant, de manière loyale et confiante, à la mission du prestataire de services (CA Paris 10-7-1980).
Il est ainsi tenu de collaborer à la définition de ses besoins, au choix d'un matériel adapté, à l'élaboration et à la mise en place du système informatique (CA Paris 7-5-1986 : GP 1987.som.24), de garantir au fournisseur une alimentation électrique conforme au cahier des charges convenu et de respecter les consignes d'exploitation ou de lui de fournir les informations sans lesquelles celui-ci ne peut pas mener à bien sa mission .
Il est responsable des retards qu'il provoque (CA Paris 28-6-1998).
Il est aussi tenu d'acquitter le montant des prestations fournies dès lors que ces dernières sont exécutées correctement (CA Paris 14-4-1988).
I. Collaboration fait nécessairement partie du périmètre contractuel.
« Celui qui sait » – le professionnel informatique – est spécialement débiteur envers « Celui qui ne sait pas » – le client – d'obligations d'information, de conseil et de mise en garde.
Réciproquement, « Celui qui ne sait pas » – le client – est lui-même tenu d'une obligation générale de collaboration à l'endroit du professionnel informatique.
La façon la plus commode et la plus répandue d’expression des besoins dans ce domaine est la rédaction d’un cahier des charges, certes théoriquement facultatif, mais qui en fait s’impose dès que les prestations envisagées sont un peu complexe, comme les contrats clé en main (en revanche, à mesure que l’informatique s’est vulgarisée, sa nécessité diminue pour les contrats simples même dans ce domaine, qui a cessé d’être nouveau et mystérieux). Le client doit à tout moment faire preuve d'une implication suffisante en apportant sa pleine et entière collaboration vis-à-vis du professionnel informatique.
En amont, au stade des pourparlers précontractuels, il doit participer à la définition de ses besoins et à leur formulation, ainsi que préciser au professionnel les spécificités d'organisation qui sont les siennes et les usages – parfois très particuliers – qu'il attend de son système informatique.
En aval, au stade du déploiement et de l'exploitation du système, il appartient notamment au client de contribuer à la phase de collecte des données variables en adressant au professionnel les données d'entrée requises. De même, le client doit participer de façon effective aux instances de pilotage du projet informatique (comité stratégique, comité de suivi, comité de pilotage...) afin de valider et superviser les délais de déploiement, gérer les problèmes de migration et d'exploitation du système ou encore se prononcer sur les principaux changements techniques à opérer.
Enfin, en phase de réception du système, le client doit contribuer avec le professionnel à l'élaboration des documents techniques (protocole de recette, cahier de tests...) décrivant les scenarii et modes opératoires des différents tests ou « jeux d'essais » qui seront réalisés entre les parties. Ajoutons également qu'il incombe au client de prononcer la réception du système lorsque rien ne s'y oppose objectivement.
Ceci exposé, la nécessaire collaboration due par le client ne doit pas prendre des proportions excessives et dégénérer en immixtion fautive dans les attributions du professionnel.
· De même, manque à son obligation de collaboration le client qui met le professionnel informatique dans l'impossibilité de respecter les délais contractuellement prévus du fait de sollicitations incessantes en vue d'évolutions et de modifications du site internet objet du contrat (CA Aix-en-Provence, 2e ch., 2 mars 2017, n° 13/22835, Drilnet c/ Christian J. : JurisData n° 2017-010487) ;
· Enfin s'immisce abusivement dans les attributions du professionnel, le client qui, en violation des dispositions contractuelles, fait procéder à l'intervention d'un tiers sur le système pour procéder à sa dépose et à son remplacement et qui organise ainsi la disparition de l'objet même du contrat alors qu'il était encore dans les liens de celui-ci (CA Versailles, ch. 12, 13 nov. 2012, n° 11/03488, SA Alain Affelou Franchiseur c/ SAS SPIE Communications : JurisData n° 2012-027710).
II. Manquement au devoir de collaboration
En matière de contrats informatiques, surtout s’ils sont complexes, les tribunaux mettent à la charge du client une obligation de collaborer avec celui qui fournit le matériel ou la prestation. Cette obligation est le corollaire de l’obligation d’information et de conseil incombant au fournisseur ou au prestataire.
En d’autres termes, l’obligation de conseil qui pèse sur le prestataire informatique a pour corollaire une obligation de collaboration de la part du client qui se doit d’analyser et d’exprimer ses besoins en communiquant au prestataire les informations nécessaires. À défaut, ce dernier pourra être considéré comme fautif et se voir imputer en tout ou partie l’échec du projet et la résiliation du contrat en découlant.
A titre d’illustration, une entreprise ayant acheté un dispositif informatique pour gérer les aspects « fournisseurs », « commercial » et « production » de son activité a été déclarée pour moitié responsable de l’échec de l’installation du module de production, dès lors qu’elle n’avait pas informé son fournisseur de ses spécificités de fonctionnement ni exprimé clairement ses besoins (Cass. com. 10-1-2018 précité). De même, il a pu être reproché à une entreprise qui avait conclu plusieurs contrats avec un prestataire informatique pour renouveler ses sites internet professionnels et grand public de ne lui avoir fourni aucun cahier des charges ni, une fois le premier site opérationnel, transmis les logos et codes couleur nécessaires pour sa duplication pour l’autre site (CA Aix-en-Provence 5-10-2017 no 2017/296).
Aussi, en est-il dans l’arrêt de la cour d’appel de Paris, pôle 5, ch. 11, 19 mars 2021, n° 17/20062 dans laquelle une société qui souhaitait être accompagnée pour une évolution de son ERP. Suite à un audit de ses besoins, un prestataire lui a fait une proposition commerciale, qui a été acceptée, proposant le maintien et l'évolution de l'ERP tout en assurant la mise en place de futures évolutions. Lors de cet audit, le prestataire avait cependant identifié divers risques, et préconisait de conserver le logiciel dans sa version actuelle et de l'améliorer par étapes, puis d'assurer une migration progressive vers une version supérieure.
Cette solution, qui répondait au cahier des charges, nécessitait que le client fournisse la base historique du support réalisé par le précédent prestataire, mais également de mettre en œuvre la charge en personnel et un budget nécessaire à l'adaptation. Faute de cela, les juges ont considéré que c'était à bon droit que le prestataire avait mis un terme au contrat.
D’où un contrat est résolu aux torts partagés en raison du « < dysfonctionnement > » de logiciels, alors que le client a refusé de les utiliser, en dépit des solutions de remplacement trouvées par le fournisseur ; il devait être patient face à une innovation (pourquoi les praticiens et usagers de l’informatique répugnent à employer les mots simples d’avarie, de désordre, de dérangement, de malfaçon, de panne, de pépin…, et préfèrent utiliser l’affreux « < dysfonctionnement > », sans parler du mal sonnant « bogue », bug, désignant une erreur d’écriture d’un programme).
Sources :
