Pourquoi il est prudent de prévoir une recette non tacite

L’issue de la phase de développement d’un outil logiciel, qu’il s’agisse par exemple d’une plateforme web, d’une application ou d’un logiciel en tant que tel, est ce que l’on appelle la recette (ou la réception ou le recettage). Son objectif est de confirmer que le livrable commandé et attendu est bien conforme au cahier des charges, aux besoins exprimés par le client. On constate que souvent la phase de recette n’est pas organisée, ou qu’elle est prévue par le prestataire sous une forme tacite, parfois il est prévu que la recette soit prononcée de façon expresse, à la suite des phases de test.

Souvent les prestataires informatiques expliqueront qu’une recette tacite doit être prévue car à défaut le projet peut être sans fin dans la mesure où le client « traîne souvent » à faire les tests de recettage et à valider le livrable. Pour autant, est-ce une bonne idée de l’accepter ?

Dans un 1er temps il est sans doute utile de rappeler que l’une des obligations essentielles du client dans un projet de développement informatique est sa participation effective au projet, il ne doit pas déraisonnablement ralentir le travail du prestataire, à défaut c’est le client qui se rend responsable lui-même. Si une recette est prévue, il faut que le client tienne lui aussi les timings. D’ailleurs, si aucun procès-verbal de recette n’est signé mais que l’exploitation de la solution informatique a commencé, les juges auront tendance à considérer que le client a bien accepté le livrable (d’autant plus s’il a écrit sa satisfaction à son prestataire et que la période de maintenance post garantie a effectivement démarré avec le paiement des factures correspondantes).

Or une recette tacite et l’absence de PV de réception comporte plusieurs inconvénients côté client. Tout d’abord, cela ne permet pas d’émettre des réserves sur les livrables ; or le travail à faire par le prestataire pour permettre de lever ces réserves doit entrer dans le budget initial de développement et non dans l’enveloppe de maintenance si les anomalies sont signalées pendant la période de garantie. Ensuite le PV de recette, qui est un document contradictoire et daté, permet de faire démarrer avec une date certaine la période de garantie pendant laquelle le prestataire doit encore corriger à ses frais des anomalies vis à vis du cahier des charges.

Il est donc prudent de prévoir une clause de recette expresse et ses conditions précises adaptées au projet et aux équipes techniques (ou non) du client qui devront valider les livrables.

Pour autant, il ne suffit pas que le contrat prévoie l’obligation d’une recette écrite pour être totalement tranquillisé. La phase de recette en pratique ne doit pas être prise à la légère. Elle doit faire l’objet d’un véritable effort de contrôle du client (souvent pris par le temps en fin de projet et pressé de la mise en production), pour déceler et signaler d’éventuelles réserves. Un PV de recette signé par le client fera foi devant les juges pour constater la conformité des livrables attendus, que le prestataire a assuré et finalisé sa mission et donc que le client doit payer le solde de la prestation. Or quoi de plus préjudiciable que d’avoir une solution informatique qui ne fonctionne pas correctement, avec une obligation de payer et pas de moyen de pression vis à vis du prestataire ?

La bonne réalisation d’une prestation de développement informatique nécessite un doux mélange équilibré avec l’expertise technique du prestataire, la collaboration du client au long du projet et une alchimie entre les dispositions juridiques contractuelles et le fonctionnement des équipes client.

N’hésitez pas à contacter les experts de MIIP – MADE IN IP sur ces questions !

Charlotte Urman / Conseil en Propriété Industrielle