Signer l'avis de recette : ce que vous engagez vraiment en QA

Dans le quotidien d'un testeur QA, la recette ressemble souvent à une dernière étape technique : on déroule les derniers cas de test, on clôture les anomalies bloquantes, on coche une case dans l'outil de suivi. Pourtant, juridiquement, l'avis de recette (ou procès-verbal de recette) est l'acte qui constate contractuellement que le logiciel livré est conforme aux spécifications convenues.

Cet acte n'est pas neutre. Il produit trois effets juridiques majeurs :

• Il constate la conformité de la prestation à la commande, c'est-à-dire qu'il vaut acceptation de l'ouvrage au sens du contrat de prestation logicielle.
• Il déclenche le transfert des risques : à compter de la recette, c'est le client qui supporte les aléas d'exploitation, sauf pour les défauts dont vous étiez en charge de la détection.
• Il fait courir les délais : garantie contractuelle, période de garantie de bon fonctionnement (GBF), point de départ du paiement du solde.

Quand vous délivrez un avis de recette favorable, vous ne dites pas seulement "j'ai fini mes tests". Vous attestez d'un niveau de conformité sur lequel votre client va fonder sa décision de mise en production. C'est précisément là que naît votre exposition professionnelle.

La nature de la recette que vous prononcez change radicalement votre niveau d'exposition. Il faut distinguer trois situations.

La recette sans réserve

Vous validez l'ensemble du périmètre testé sans signaler d'anomalie restante. Juridiquement, le client est réputé avoir accepté les défauts apparents — ceux qu'un examen normal aurait dû révéler. Le revers : si un défaut apparent qui aurait dû être couvert par votre plan de test ressort en production, le client peut vous reprocher un manquement à votre obligation de moyens, voire de résultat selon la rédaction de votre contrat.

La recette avec réserve

Vous prononcez la recette tout en listant les anomalies connues non bloquantes et les zones non couvertes. C'est la position la plus protectrice pour vous : vous documentez ce que vous savez ne pas avoir validé. Les réserves doivent être précises, datées et annexées au PV ; une réserve vague ("quelques points restent à vérifier") n'a quasiment aucune valeur défensive.

La recette refusée (ajournement)

Le périmètre ne permet pas la mise en production. Vous refusez de prononcer la recette et exigez des corrections. Le risque ici n'est pas la faute de validation mais le retard de campagne : si votre refus décale la release, le client peut chercher à vous imputer le préjudice commercial du décalage.

En pratique : préférez toujours une recette avec réserve documentée à une recette sans réserve confortable. La réserve écrite est votre meilleure pièce en cas de litige.

Beaucoup de litiges QA ne portent pas sur ce qui a été signé, mais sur ce qui ne l'a jamais été. La recette tacite survient lorsque le client met le logiciel en exploitation effective sans qu'aucun PV n'ait été formellement signé. La jurisprudence considère régulièrement que l'utilisation paisible et prolongée d'un logiciel en production vaut acceptation tacite.

Pour vous, testeur, c'est un double piège :

1. Si vous aviez des réserves orales mais non formalisées, la mise en production les neutralise : vous ne pourrez pas démontrer que vous aviez alerté.
2. À l'inverse, si le client met en production une version que vous n'aviez pas validée (mise en prod anticipée par-dessus votre recette ajournée), vous devez impérativement le tracer pour ne pas être tenu d'un bug sur un périmètre que vous n'avez jamais accepté.

La parade est simple et tient en une habitude : tout passe par écrit. Un e-mail récapitulatif après chaque campagne, listant l'état des anomalies, les zones couvertes et celles qui ne l'ont pas été, vaut bien plus qu'un PV signé six mois plus tard. Conservez ces traces : ce sont elles qui délimiteront votre responsabilité réelle face à une réclamation.

La question décisive en cas de litige est la nature de votre engagement. Le testeur QA est en principe tenu d'une obligation de moyens : vous vous engagez à mettre en œuvre des méthodes, des compétences et une diligence conformes à l'état de l'art, sans garantir l'absence absolue de bug — objectif technologiquement inatteignable.

Mais attention aux clauses qui transforment cette obligation. Certaines rédactions de contrat ou de cahier des charges imposent un taux de couverture, un nombre maximal d'anomalies résiduelles ou une garantie de "zéro défaut bloquant en production". Ces formulations vous font glisser vers une obligation de résultat, où la simple survenance d'un bug suffit à engager votre responsabilité, sans que le client ait à prouver votre faute.

Avant de signer une mission, relisez :

• les engagements de niveau de service (SLA) et de qualité chiffrés ;
• les clauses de garantie et leur durée ;
• l'éventuelle clause limitative de responsabilité (souvent plafonnée au montant de la mission) ;
• la définition contractuelle de la "recette" et de ses critères d'acceptation.

Quelle que soit la rédaction, votre assurance RC Pro intervient pour les dommages immatériels causés au client par une faute professionnelle de validation. C'est ce poste — le préjudice financier d'un client qui n'a subi aucun dommage matériel — qui représente l'essentiel de votre exposition de testeur.

Même avec une recette parfaitement documentée, un risque résiduel demeure : le défaut que personne n'a vu, le cas limite non spécifié, la régression introduite par un correctif de dernière minute. Aucune signature, aussi prudente soit-elle, ne supprime totalement ce risque. Elle le délimite, elle ne l'efface pas. La nature même du logiciel — combinatoire d'états, dépendances invisibles, environnements hétérogènes — rend l'exhaustivité du test théoriquement inatteignable. Vous ne validez jamais l'absence de bug ; vous validez l'absence de bug détectable dans le périmètre et le temps qui vous ont été alloués.

C'est la raison d'être de l'assurance de responsabilité civile professionnelle pour un métier de validation. Concrètement, elle prend en charge :

• les dommages immatériels subis par le client (perte de chiffre d'affaires, surcoûts de correction, pénalités contractuelles qu'il a dû verser à ses propres clients) ;
• la faute professionnelle : erreur, omission ou négligence dans la conception ou l'exécution du plan de test ;
• les frais de défense et la protection juridique lorsque la réclamation est contestable.

Un point souvent négligé concerne la temporalité de la garantie. La plupart des contrats RC Pro fonctionnent en base réclamation : c'est la date à laquelle le client vous réclame réparation qui compte, et non la date de la mission. Or un défaut validé par erreur peut ressortir des mois, voire des années après la recette. Une garantie subséquente solide est donc déterminante pour un testeur, qui peut se voir reprocher une validation longtemps après avoir quitté le projet.

Pour aller plus loin sur les garanties propres à votre métier de QA, consultez la fiche dédiée assurance test et recette de logiciels. La bonne pratique reste la combinaison des deux protections : une discipline contractuelle rigoureuse (réserves écrites, traçabilité, e-mails récapitulatifs) en amont, et un contrat RC Pro adapté pour absorber le risque que la discipline n'a pas pu éliminer. L'une sans l'autre laisse une brèche : une excellente méthode ne vous protège pas d'une réclamation imprévisible, et une bonne assurance ne remplacera jamais des preuves de diligence le jour où il faudra démontrer ce que vous avez réellement validé.