La recette d’un projet informatique, du cahier de recette au procès-verbal

La recette d’un projet informatique est la phase pendant laquelle le client vérifie que le logiciel livré correspond à la commande. Elle se déroule sur un environnement dédié, à partir d’un cahier de recette qui liste les cas de test, et se termine par la signature d’un procès-verbal. Recettage et recette désignent la même chose.

La recette vérifie la conformité au besoin

La recette répond à une seule question : le logiciel fait-il ce que le contrat prévoyait ? Le client la pilote, puisque lui seul connaît le métier que l’outil doit servir. Les tests exécutés par l’équipe de développement répondent à une autre question : le code se comporte-t-il comme ses auteurs l’ont prévu ?

Trois activités voisines se confondent souvent avec la recette.

• Les tests unitaires et les tests d’intégration tournent automatiquement à chaque modification du code. Ils vérifient une fonction, une classe, un appel d’API. Ils portent sur le code, quand la recette porte sur le besoin métier.
• La qualification est le travail de l’équipe technique sur son propre livrable avant de le présenter au client. Un même scénario peut donc être joué deux fois, une fois en qualification par le prestataire, une fois en recette par le client.
• Les tests de charge et les tests de sécurité mesurent le comportement de l’application sous contrainte. Ils relèvent en général de la recette technique, avec des outils et des compétences différents de ceux d’un testeur métier.

En pratique, un gestionnaire de parc ouvre l’outil, crée une intervention, l’affecte à un technicien, imprime le bon de travail, et compare ce qu’il obtient à ce qu’il attendait.

Les trois niveaux de recette

Un projet un peu structuré passe par trois niveaux successifs. Deux d’entre eux portent des noms contractuels que les marchés publics et les contrats d’intégration reprennent presque toujours : la VABF, vérification d’aptitude au bon fonctionnement, et la VSR, vérification de service régulier.

Niveau	Qui teste	Environnement	Objet du test	Moment
Recette technique	L’équipe de développement	Intégration	L’application se déploie, tient la charge attendue, respecte les règles de sécurité et atteint les performances promises	Avant la livraison au client
Recette fonctionnelle (VABF)	Le client, souvent son chef de projet ou son assistance à maîtrise d’ouvrage (AMOA)	Environnement de recette, jeu de données de test	Chaque fonctionnalité produit le résultat décrit dans les spécifications	À la livraison d’un lot
Recette utilisateur (VSR)	Les utilisateurs finaux, sur leurs vrais dossiers	Production ou pré-production, données réelles	Le logiciel reste fiable dans le travail quotidien, sur la durée	Après la mise en service, sur une période fixée au contrat

Les données fabriquées pour la VABF restent propres et peu nombreuses. Un bug d’arrondi sur une facture, une lenteur qui apparaît au-dessus de 10 000 lignes ou un export dont les colonnes se décalent dans Excel sortent donc presque toujours pendant la VSR, une fois les vrais dossiers dans l’outil.

La durée de la VSR se négocie au contrat. Un mois calendaire reste la référence la plus courante, parce qu’il couvre au moins une clôture mensuelle. Quand l’outil gère une paie, un inventaire ou une saison commerciale, alignez la durée de la VSR sur ce cycle plutôt que sur le calendrier.

Le cahier de recette et ses cas de test

Le cahier de recette liste tout ce que le client va tester. Une fois la campagne terminée, il garde la trace de ce qui a été validé et de ce qui restait à corriger. Rédigez-le à partir des spécifications et des critères d’acceptation du cahier des charges, pendant le développement plutôt qu’après la livraison.

Un cas de test exploitable tient en six informations.

• Un identifiant, du type CT-042, pour que chaque anomalie renvoie à un cas de test précis.
• La fonctionnalité testée et le renvoi vers la spécification correspondante.
• Les pré-requis, c’est-à-dire l’état du système avant de commencer : un compte avec tel rôle, un dossier déjà créé, une donnée déjà importée.
• Le scénario, en étapes numérotées, écrites au niveau de détail d’un mode d’emploi.
• Le résultat attendu, formulé de façon vérifiable.
• Le résultat obtenu et la date d’exécution, remplis pendant la campagne.

La différence entre un cahier utile et un cahier décoratif tient au résultat attendu. Personne ne peut trancher avec « le devis se crée correctement ». « Le devis apparaît dans la liste avec le statut Brouillon, le numéro DEV-2026-0001 et un total HT de 1 240 € » se vérifie d’un coup d’œil, y compris par quelqu’un qui découvre le dossier.

Les cas de test couvrent aussi ce qui doit échouer. Un formulaire qui refuse un SIRET invalide, un utilisateur sans droit qui ne voit pas le bouton de suppression, un import qui rejette un fichier mal formé : ces scénarios valent autant que les parcours qui se passent bien. Un défaut sur ces contrôles coûte même plus cher une fois en production.

Le déroulé d’une campagne de recette

Une campagne commence par une livraison sur l’environnement de recette, accompagnée d’une note de version qui liste ce que le lot contient. Les testeurs déroulent ensuite les cas de test du cahier, un par un, en consignant chaque écart.

Une bonne équipe de recette côté client réunit trois profils : un utilisateur qui connaît le métier par cœur, un référent capable de trancher quand le comportement observé pose une question de fond, et une personne qui tient le tableau de suivi. Ce suivi compte plus qu’on ne croit, parce qu’une campagne se perd vite dans les captures d’écran envoyées par messagerie.

Pour chaque anomalie, ouvrez une fiche : le cas de test concerné, le résultat obtenu, une capture et une gravité.

Gravité	Situation	Exemple	Effet sur le procès-verbal
Bloquante	Un processus essentiel devient impossible	La validation d’une commande échoue	La recette est refusée, une nouvelle livraison est demandée
Majeure	Le processus aboutit, par un contournement ou avec un résultat dégradé	Le filtre de recherche renvoie des résultats incomplets	Correction avant signature, ou réserve assortie d’un délai ferme
Mineure	L’usage reste normal, le défaut porte sur la forme	Un libellé erroné, un alignement approximatif	Réserve listée au procès-verbal, corrigée pendant la garantie

Discutez cette grille au moment du contrat, avant le premier désaccord. Écrivez dans la clause de recette la règle d’acceptation qui va avec : zéro anomalie bloquante, zéro anomalie majeure non corrigée, les mineures listées en réserves avec un délai. Sans cette règle, chaque anomalie devient une négociation.

Prévoyez aussi le nombre d’itérations. Deux allers-retours suffisent sur un lot bien qualifié. Au troisième, le problème vient rarement du code : soit le besoin a changé en cours de route, soit les spécifications laissaient une zone grise que personne n’avait vue au cadrage du projet.

graph TD
  A["Livraison sur l’environnement de recette"] --> B["Exécution des cas de test du cahier"]
  B --> C{"Écart avec le résultat attendu ?"}
  C -->|Non| D["Cas de test validé"]
  C -->|Oui| E["Fiche d’anomalie, gravité qualifiée"]
  E --> F["Correction par l’équipe de développement"]
  F --> G["Nouvelle livraison et tests de non-régression"]
  G --> B
  D --> H{"Zéro bloquante, zéro majeure ?"}
  H -->|Non| F
  H -->|Oui| I["Procès-verbal signé, mineures en réserves"]
  I --> J["Mise en production, démarrage de la garantie"]

Le procès-verbal de recette et ce qu’il engage

Le procès-verbal de recette est le document par lequel le client déclare accepter le livrable. Sa signature déclenche en général trois effets prévus au contrat : le paiement du solde, le transfert de la responsabilité d’exploitation, et le départ de la période de garantie pendant laquelle le prestataire corrige gratuitement les anomalies.

Un procès-verbal utile contient la date, le périmètre exact de ce qui a été recetté, la version testée, la liste nominative des réserves, le délai de correction de chacune et les conséquences prévues si ce délai passe. Une réserve écrite « quelques points de détail restent à voir » ne protège personne.

La signature sans réserve n’efface pourtant pas tout. La cour d’appel de Douai, dans un arrêt du 11 avril 2011, a jugé qu’une réception sans réserve ne couvre que les défauts apparents de conformité, et que certaines prestations prévues au contrat ne s’apprécient qu’à l’usage sur une durée plus longue. Un défaut que le client ne pouvait pas voir pendant ses tests reste donc discutable après coup, sur le terrain de la garantie ou de l’obligation de délivrance conforme.

L’inverse existe aussi. Les juges reconnaissent une recette tacite quand le comportement du client vaut acceptation. La cour d’appel de Paris, le 28 janvier 2022, a retenu une recette implicite en l’absence de tout procès-verbal signé, à partir d’un faisceau d’indices : une mise en production effective, six mois d’usage sans réserve, et le passage à un contrat de maintenance. Un client qui exploite l’outil au quotidien tout en repoussant la signature se retrouve donc dans la même situation que s’il avait signé.

Deux réflexes protègent le client comme le prestataire. Recettez sur la version exacte qui partira en production, parce qu’un procès-verbal signé sur une version antérieure ne prouve pas grand-chose. Et refusez le procès-verbal de complaisance, celui qu’on signe pour débloquer une facture ou pour tenir une date annoncée en comité de direction, avec la promesse orale que le reste suivra. La signature engage le client tout de suite. Les corrections promises à l’oral, il faudra les redemander sans aucun écrit pour les appuyer.

Le temps à prévoir pour une campagne de recette

Chiffrez la recette à partir du cahier plutôt qu’au jugé. Comptez le nombre de cas de test, multipliez par le temps d’exécution moyen, ajoutez la rédaction des fiches d’anomalie et les itérations de correction. Un cahier de 150 cas à dix minutes pièce fait environ 25 heures de test, soit trois jours et demi pour un testeur à plein temps. Comptez le double avec les fiches d’anomalie et deux tours de correction.

Ce calcul suppose des testeurs disponibles. Le planning de recette déraille plus souvent par manque de créneaux que par excès de cas de test, parce que les personnes qui connaissent le mieux le métier ont les agendas les plus chargés. Bloquez leurs journées de recette dès la signature du contrat.

Recetter lot par lot plutôt qu’en une fois

Une recette gardée pour la fin du projet concentre tous les écarts au moment où le budget et le calendrier ont le moins de marge. Un malentendu sur une règle de calcul repéré six mois après l’atelier qui l’a définie coûte bien plus cher que le même écart corrigé au sprint suivant.

Faites donc recetter chaque lot par le client dès qu’il est livré. Une équipe qui travaille en sprints courts livre toutes les deux semaines une version que le référent métier teste dans la foulée. Le procès-verbal final devient alors un récapitulatif de validations déjà prononcées. La campagne de clôture se termine en quelques jours.

La qualité du code livré compte autant que le rythme. Une équipe qui écrit ses tests avant le code attrape les régressions avant qu’elles n’arrivent sur l’environnement de recette. Les testeurs métier passent alors leur temps sur les questions d’usage, au lieu de signaler à nouveau un bouton qui a cessé de fonctionner entre deux livraisons. Cette discipline évite aussi d’accumuler de la dette technique pour tenir une date de recette.

Trois décisions prises tôt changent le déroulé de la campagne. Fixez la grille de gravité et la règle d’acceptation dans le contrat. Faites rédiger le cahier de recette pendant le développement, à partir des spécifications issues du cadrage et de la conception. Et prévoyez ce qui se passe après la signature, puisque la garantie contractuelle finit par s’éteindre alors que l’outil continue d’évoluer. Un contrat de maintenance applicative prend le relais.

Chez Lonestone, on prépare la recette dès les premiers sprints. Nos ingénieurs, pour la plupart entre 10 et 25 ans d’expérience, livrent à chaque itération une version testée que le référent métier valide aussitôt. Si vous préparez la recette d’un outil métier sur mesure, parlons de votre cahier de recette pendant que les spécifications s’écrivent encore.

FAQ

Questions fréquentes

Quelle est la définition du recettage ?

Le recettage est la phase pendant laquelle le client vérifie qu’un logiciel livré est conforme à ce qui a été commandé. Il se déroule sur un environnement dédié, à partir d’un cahier de recette qui liste les cas de test et les résultats attendus, puis se conclut par la signature d’un procès-verbal de recette. Recette et recettage désignent la même activité. Elle se distingue des tests unitaires, qui vérifient le code de façon automatique, et de la qualification, que le prestataire réalise sur son propre livrable avant de le présenter au client.

Qui doit rédiger le cahier de recette ?

Le cahier de recette appartient au client, parce que lui seul sait ce que l’outil doit produire pour son métier. En pratique, il est souvent co-rédigé : le prestataire fournit la trame et les scénarios techniques à partir des spécifications, le client ajoute ses cas réels et ses règles de gestion. Sur les projets qui comportent une assistance à maîtrise d’ouvrage (AMOA), cette rédaction fait partie de sa mission. Le document se rédige pendant le développement, à partir des spécifications validées au cadrage du projet, plutôt qu’après la livraison.

Que se passe-t-il si le client refuse la recette ?

Un refus de recette se prononce quand une anomalie bloquante empêche un processus essentiel de fonctionner. Le client notifie son refus par écrit, en listant les anomalies qui le motivent, et le prestataire livre une nouvelle version soumise à une nouvelle campagne. Le contrat prévoit en général un nombre d’itérations, un délai de correction et ce qui se passe au-delà : pénalités de retard, résiliation, ou réduction du prix. Un refus qui repose sur des demandes absentes des spécifications relève d’une évolution à chiffrer plutôt que d’une anomalie.

La recette est-elle payante ?

Le client prend à sa charge le temps que ses équipes passent à tester, soit plusieurs jours-homme à prévoir dans le planning. Du côté du prestataire, la correction des anomalies détectées pendant la recette est incluse dans le prix du développement. Les demandes qui sortent du périmètre contractuel sont en revanche chiffrées comme des évolutions. Quand le prestataire rédige lui-même le cahier de recette ou anime la campagne, cette prestation se facture et figure au devis.

Que signifient VABF et VSR ?

La VABF, vérification d’aptitude au bon fonctionnement, est la recette fonctionnelle : le client teste chaque fonctionnalité sur un environnement dédié, avec des données de test, et vérifie la conformité aux spécifications. La VSR, vérification de service régulier, vient après la mise en service : elle observe le comportement du logiciel en conditions réelles, sur les vraies données et les vrais volumes, pendant une période fixée au contrat, souvent un mois.

Combien de temps dure une recette informatique ?

La durée se calcule à partir du cahier de recette. Un cahier de 150 cas de test à dix minutes d’exécution moyenne fait environ 25 heures de test, soit trois jours et demi pour un testeur à plein temps. En ajoutant la rédaction des fiches d’anomalie et deux itérations de correction, la campagne occupe deux à trois semaines calendaires pour un outil métier de taille moyenne, parce que les testeurs métier y consacrent rarement des journées entières. Un client qui recette chaque lot en cours de projet ramène cette campagne finale à quelques jours. Un développement en sprints courts donne ce rythme de livraison.

Un procès-verbal de recette signé sans réserve protège-t-il totalement le prestataire ?

Non. La cour d’appel de Douai, dans un arrêt du 11 avril 2011, a jugé qu’une réception sans réserve ne couvre que les défauts apparents de conformité, ceux que le client pouvait déceler pendant ses tests. Une anomalie qui ne se révèle qu’à l’usage prolongé reste discutable après la signature, au titre de la garantie contractuelle ou de l’obligation de délivrance conforme. À l’inverse, exploiter le logiciel pendant des mois sans émettre de réserve peut valoir recette tacite, même sans procès-verbal signé.

Peut-il y avoir une recette sans procès-verbal ?

Oui, les tribunaux reconnaissent la recette tacite. La cour d’appel de Paris, le 28 janvier 2022, a retenu une recette implicite en l’absence de procès-verbal, sur un faisceau d’indices : mise en production effective, six mois d’usage sans réserve et passage à un contrat de maintenance. Un client qui utilise le logiciel au quotidien tout en refusant de signer se retrouve donc dans la même situation que s’il avait signé. Le procès-verbal écrit reste préférable pour les deux parties, puisqu’il date précisément le départ de la garantie et fixe le périmètre accepté.