20 juin 2016

La clause de "recette" dans les contrats de prestations informatiques

FICHE PRATIQUE

 

CLAUSE ESSENTIELLE DES CONTRATS INFORMATIQUES

Clause essentielle des contrats de fourniture de développements logiciels ou d’une solution ou portant sur l’intégration de progiciels, la clause de « recette » présente la particularité d’être à la fois très juridique et très opérationnelle. Autrement dit, elle s’adresse et doit « parler » autant au juriste qu’aux personnels chargés de la conduite du projet, aussi bien côté client (« MOA ») que côté prestataire.


Objet de la clause de recette

Dans les contrats informatiques, elle a pour double objet d’organiser la « délivrance » conforme des documents et logiciels attendus par le client et sa « réception » au sens juridique du terme par le client (notions définies dans le Code Civil), c’est-à-dire la vérification de l’aptitude des "livrables" à être exploités conformément aux besoins exprimés par le maître de l'ouvrage au sein d’un référentiel défini par avance dans le contrat (tels que : cahier des charges, spécifications fonctionnelles et techniques détaillées, compte-rendu d’analyse préalable, etc.).


Obligation essentielle du maître de l'ouvrage (client)

L’obligation de recetter les livrables, contrepartie de l’obligation essentielle de délivrance conforme pesant sur le fournisseur, est une obligation essentielle du client. Dans le commun intérêt des parties, elle doit être rédigée avec le plus grand soin, de façon à la fois précise et détaillée.

L’expression des besoins, autrement dit le référentiel de conformité, décrira les livrables documentaires à fournir au client en cours de projet et, pour les livrables logiciels, les fonctionnalités et niveaux de service et de performances attendus du système informatique ou de l’application à délivrer. C'est la conformité des livrables à ce référentiel qui sera testée lors de la recette.

La phase de recette, c'est-à-dire la procédure de tests et de validation de la conformité des livrables aux spécifications contractuelles ne doit pas être confondue avec les tests réalisés par le prestataire avant la fourniture des "livrables", qui ne sauraient se substituer à ceux que doit obligatoirement réaliser le client, avec ses propres équipes et au besoin avec l’aide du prestataire ou d’un tiers (du type assistant à la maîtrise d’ouvrage).


Le périmètre de la recette et le "protocole de recette"

Le périmètre de la recette (total ou partielle, provisoire ou définitive) et la procédure à suivre pour parvenir à la recette définitive des livrables devront être clairement indiqués au contrat. Cela suppose aussi bien la rédaction d’une clause de recette générale dans le corps du contrat que l’élaboration d’un "protocole de recette" détaillé, rédigé en premier lieu par les opérationnels et revu par un juriste, prévoyant la procédure étape par étape et phase par phase. Ce document sera intégré en annexe au contrat (p. ex dans le "PAQ"), soit à idéalement à sa signature, soit en début de projet (et au besoin mis à jour en cours de projet). La clause de recette y renverra explicitement.


Quelques précisions à apporter dans la clause de recette

La clause de recette précisera l’objet et le périmètre de la recette, les délais impérativement liés aux différentes phases (intermédiaire ou modulaire, documentaire, provisoire, définitive...), les modalités et conditions de signature du procès-verbal de recette et les conséquences (i) d’une absence de réserves dans les délais indiqués et (ii) d’une acception avec ou sans réserves ou d’un refus de la recette des livrables par le client (réparation des anomalies non levées après recette avec réserves, résolution en cas d’impossibilité constatée d’exploiter les livrables ou d’un taux d’anomalies bloquantes et semi-bloquantes trop important et non levées).

Cette clause renverra explicitement aux définitions des termes essentiels à sa mise en œuvre (prévoir un article "définitions"), dont les documents constituant le référentiel de conformité, les notions de recette provisoire et définitive (s'il y a lieu), les non-conformités ou « anomalies », etc. On aura soin de décrire synthétiquement  les notions d'anomalies les unes par rapport aux autres en les situant sur une échelle de criticité (ex : bloquante/semi-bloquante/mineure).

Compte tenu de son objet juridique essentiel (la vérification de l’obligation de délivrance conforme), la clause renverra également à la validation, par les deux parties, des spécifications fonctionnelles et techniques et le cas échéant aux performances (ex: temps de réponse, délai de traitement, etc.). et les niveaux de services attendus (un "SLA" pourra être ajouté au besoin, surtout si le prestataire assurera ensuite la tierce maintenance de la solution livrée). Côté client, il faudra se souvenir que les besoins doivent avoir été expressément spécifiés pour entrer dans le champ contractuel et donc dans l’objet de la phase recette.


Quelques précisions à apporter dans le "protocole de recette"

Le "protocole de recette" (plus opérationnel que la clause proprement dite, bien qu’il ait des effets juridiques indéniables) prévoira la ou les procédures de recette (en cas de phases successives) de façon détaillée, les modalités de notification des anomalies, dysfonctionnements ou non-conformité après la phase de tests (fiches d’anomalies, cahier d’incidents...), leurs délais de résolution par le prestataire suivant leur taux de criticité, leur taux d’acceptabilité par le client au stade de la recette provisoire ou définitive non assortie de réserves (ex : 0% pour les anomalies bloquantes, 0% pour les semi-bloquantes, X% pour les mineures) ou assortie de réserves (taux à prévoir également ici), les modalités de "levée" des anomalies ou dysfonctionnements signalés lors de la phase de recette initiale dans un nouveau délai ou dans le cadre de la "garantie" en cas de recette avec réserves (voir prochainement notre Fiche pratique sur la "clause de garantie" dans les contrats informatiques).

Ce protocole annexé précisera également, pour les livrables logiciels, les protocoles de tests ou jeux d’essai que devra élaborer le client, avec ou sans collaboration du prestataire, afin de « dérouler » la procédure de recette avant le signalement des anomalies ou non-conformités.


Recette provisoire et recette définitive

A noter aussi, en pratique on distingue fréquemment dans les contrats de prestations informatiques, surtout pour les projets d’une certaine importance, une phase dite de « recette provisoire » de la procédure de "recette définitive". Juridiquement, la recette dite définitive correspond à la réception proprement dite des livrables, celle qui a pour effet de constater la conformité des livrables fournis sans réserves après tests et corrections éventuelles des anomalies. Elle couvre les "vices apparents".

Eu égard aux définitions des termes ayant cours dans les marchés publics (cf. les "CCAG TIC") et à la pratique dans les marchés privés de prestations informatiques, on peut définir la procédure de recette "provisoire", parfois dénommée "Vérification d’Aptitude au Bon Fonctionnement" (VABF) comme l’aptitude de la solution ou du système informatique livré à fonctionner en conformité avec les spécifications dans le cadre d’une simulation de situations réelles, c’est-à-dire sur la base de jeux d’essais déroulés dans un environnement de tests de la solution ou du système informatique. Quant à la recette "définitive", encore nommée parfois "Vérification de Service Régulier" (VSR), elle peut être définie comme « la réception de la solution dans le cadre de son exploitation sur un environnement de production, suivant les niveaux de services définis et mesurables » (cf. Y. Bismuth, Pratique Contractuelle - La clause de recette dans les contrats informatiques, Communication Commerce Electronique, Mars 2012, pp. 47-48).

Le recours à une telle distinction n’a rien d’indispensable. A défaut de précision, la clause de recette sera censée se référer à la recette définitive.


Le procès-verbal de recette

Il convient surtout de se référer à des notions claires et à une procédure parfaitement encadrée afin d’apporter un maximum de sécurité juridique au prestataire et au maître de l’ouvrage. A cet égard, l’on ne saurait trop recommander de veiller à préciser les modalités de signature du procès-verbal de recette provisoire et/ou définitive (avec ou sans réserves), les délais et les effets attachés aux dépassements et les modalités de l’acceptation et d’émission ou non de réserves en phase de recette avant la signature essentielle du procès-verbal de recette.

En effet, "l'acquisition" de la recette reste en principe soumise à la signature d'un procès-verbal de recette sans réserves, c'est-à-dire après levée de toutes les anomalies ou non-conformités considérées comme un obstacle à l'acceptation conformément aux prévisions du contrat.


La question de la "recette tacite"

A noter, toutefois, les tribunaux admettent parfois la "recette tacite" définitive d’une solution livrée, faute pour le client d’avoir émis en temps utile des réserves écrites concernant des livrables qu’il utilise depuis un certain temps sur un environnement de production.

Il est cependant envisageable d’exclure un tel effet en fixant des conditions d’acceptation plus strictes ou en poussant plus loin l’exigence, à la condition toutefois que le refus du client repose toujours sur des conditions objectives et ne constitue pas un manquement à son obligation de coopération ou un abus de droit.


Que se passera-t-il en cas de refus de la recette ?

Enfin, les conséquences du refus de signature du procès-verbal de recette (si bien entendu il n'est pas abusif ou la conséquence d'une coupable passivité du maître de l'ouvrage) ne doivent pas négligées.

Quelle sera l'issue du projet ? Fin du contrat au moyen de la clause de résolution ? Réécriture du code défectueux par le prestataire ? Achèvement du projet par un prestataire tiers à ses frais ?

Ceci revient à dire que la clause de recette devra envisager par avance tous les scénarios possibles au plan opérationnel et juridique. C'est pourquoi cette clause est centrale et ne doit jamais être négligée.



 

Guillaume LELU






Aucun commentaire:

Publier un commentaire