Quelle est la différence entre la recette et les tests ?

Les tests sont menés par le prestataire pour vérifier que son code fonctionne comme prévu. La recette est menée par le client, ou pour son compte, pour vérifier que le logiciel répond au contrat et au métier, sur des scénarios réels. Les deux sont nécessaires : une recette sans tests préalables découvre trop d'anomalies, et des tests sans recette laissent passer ce que seul l'utilisateur sait repérer.

Combien de temps dure une recette logicielle ?

La durée d'une recette logicielle dépend du nombre de scénarios, de la disponibilité des utilisateurs et du nombre d'allers-retours de corrections. Dans les marchés publics informatiques, le CCAG-TIC fixe par défaut à 30 jours la vérification de service régulier qui suit la recette fonctionnelle. En contrat privé, la durée se négocie : elle doit être écrite, avec un second passage prévu après les corrections.

Peut-on refuser la réception d'un logiciel ?

En général oui : selon les clauses du contrat, un client peut refuser ou ajourner la réception d'un logiciel lorsqu'une anomalie bloquante empêche d'utiliser une fonction essentielle prévue. Le refus doit être écrit, motivé et rattaché aux scénarios du cahier de recette. Pour des anomalies majeures ou mineures, la pratique est plutôt une réception avec réserves, chacune assortie d'un délai de correction. En cas de désaccord, un avocat peut analyser le contrat.

Qui rédige le cahier de recette ?

Le cahier de recette est idéalement rédigé par le client, qui connaît ses cas réels, avec l'aide du prestataire, qui connaît le fonctionnement prévu. Le prestataire peut proposer une première version à partir du cahier des charges et des maquettes ; les utilisateurs clés la complètent avec leurs exceptions métier. L'important est qu'il soit validé par les deux parties avant la livraison.

Que se passe-t-il si l'on utilise le logiciel sans signer le procès-verbal ?

Utiliser un logiciel en production sans signer de procès-verbal peut valoir réception de fait si le contrat le prévoit, ce qui est fréquent. Les anomalies non signalées par écrit risquent alors de basculer dans la garantie, voire hors de celle-ci. Avant toute mise en production anticipée, notez par écrit les anomalies connues et la date à laquelle la recette sera close.

Recette logicielle : méthode et cahier de recette

Qu'est-ce que la recette d'un logiciel ?

La recette d'un logiciel est l'ensemble des vérifications menées par le client, ou pour son compte, afin de décider si le logiciel livré peut être accepté. Elle ne remplace pas les tests du prestataire : elle les complète avec le regard de ceux qui utiliseront l'outil.

Le prestataire teste que son code fonctionne. Le client vérifie que le logiciel répond à son métier : que la facture d'une intervention partielle sort au bon montant, que le commercial ne voit pas les marges, que l'export comptable s'importe dans le logiciel du cabinet. Ce sont deux questions différentes, et la seconde ne peut pas être déléguée entièrement.

Étape	Qui la mène	Question posée
Tests unitaires et d'intégration	Le prestataire	Le code fait-il ce que le développeur a voulu ?
Recette fonctionnelle	Les utilisateurs clés du client	Le logiciel fait-il ce que le contrat et le métier demandent ?
Vérification en exploitation	Le client, en conditions réelles	Le logiciel tient-il dans la durée, avec les vrais volumes ?
Réception	Le dirigeant ou son représentant	Accepte-t-on la livraison, avec ou sans réserves ?

VABF, VA, VSR : d'où viennent ces sigles ?

Ces sigles viennent des marchés publics informatiques, et de nombreux contrats privés les reprennent tels quels. Le cahier des clauses administratives générales des marchés de techniques de l'information et de la communication (CCAG-TIC, édition 2021) prévoit deux vérifications successives.

La vérification d'aptitude (VA), souvent appelée VABF (vérification d'aptitude au bon fonctionnement) dans les contrats. D'après le texte de l'article 32 du CCAG-TIC reproduit par le site spécialisé code-commande-publique.com, elle a pour objet de constater que les prestations, livrées ou exécutées, présentent les caractéristiques techniques qui les rendent aptes à remplir les fonctions précisées dans les documents particuliers du marché. C'est la recette fonctionnelle.
La vérification de service régulier (VSR), qui vise à constater que les prestations sont capables d'assurer un service régulier dans les conditions normales d'exploitation prévues par les documents particuliers du marché. Selon le même article, la régularité du service s'observe par défaut pendant 30 jours à compter de la décision positive de vérification d'aptitude.

Pour une PME, le vocabulaire importe peu ; la logique, elle, est utile : d'abord vérifier que tout fonctionne sur un environnement de test, ensuite observer le logiciel en production quelques semaines avant de considérer la livraison comme définitivement acceptée.

Qui doit recetter, et avec quel temps ?

La recette doit être faite par ceux qui connaissent le métier, avec du temps réservé dans leur planning : sans cela, elle se réduit à quelques clics la veille de la mise en service.

Un responsable de recette côté client, souvent le chef de projet interne : il tient le cahier de recette, arbitre la gravité des anomalies et propose la décision de réception.
Des utilisateurs clés de chaque profil : la comptable pour la facturation, un chef d'équipe pour l'application terrain, une assistante pour la saisie des demandes. Chaque profil voit des écrans et des droits différents.
Le prestataire, qui prépare l'environnement et les données de test, explique les nouveautés de chaque version et corrige.
Le dirigeant, qui signe le procès-verbal et tranche les désaccords.

Un chef d'atelier qui teste entre deux urgences ne recette rien. Bloquez des demi-journées identifiées, en dehors des pics d'activité, et prévoyez un second passage après les corrections.

Comment écrire un cahier de recette ?

Un cahier de recette est un tableau de scénarios : pour chaque fonction, une situation réelle, les données à utiliser, ce qui doit se passer et ce qui s'est réellement passé. Il se rédige à partir du cahier des charges et des maquettes, avant la livraison et non après.

N°	Scénario	Données de test	Résultat attendu	Constaté
12	Le technicien clôture une intervention sans réseau, avec signature du client	Intervention 4512, téléphone en mode avion	Le rapport part au retour du réseau, sans ressaisie	Conforme
13	L'assistante facture une intervention terminée à moitié	Devis à deux postes, un seul réalisé	Facture limitée au poste réalisé, devis gardé ouvert	Anomalie majeure n° 7
14	Un technicien tente d'ouvrir la fiche tarifs	Compte technicien	Accès refusé	Conforme

Un bon cahier couvre quatre familles de cas :

Les cas nominaux : le parcours habituel, du début à la fin.
Les exceptions métier : l'annulation, l'avoir, le client sans adresse e-mail, la commande modifiée après validation.
Les droits : chaque profil ne voit et ne fait que ce qui lui est permis.
Les limites : un import de plusieurs milliers de lignes, un nom de client avec apostrophe, un vieux téléphone Android.

Bloquante, majeure, mineure : comment classer les anomalies ?

Une anomalie se classe selon son effet sur l'activité, pas selon le temps de correction. Les trois niveaux et leurs conséquences doivent figurer dans le contrat ou le plan de recette avant le premier test.

Gravité	Définition	Exemple	Effet sur la réception
Bloquante	Une fonction essentielle est impossible, sans contournement	Aucune facture ne peut être validée	Réception refusée ou ajournée
Majeure	Une fonction est faussée mais un contournement existe	La TVA d'un taux particulier se calcule mal, correction manuelle possible	Réception possible avec réserve et délai de correction
Mineure	Une gêne sans effet sur le résultat	Un libellé tronqué, un tri inversé	Réserve ou simple liste de corrections

Chaque anomalie est décrite pour être reproduite : le compte utilisé, les étapes exactes, le résultat attendu, le résultat obtenu, une capture et l'heure. Une demande nouvelle (« il faudrait aussi pouvoir dupliquer un devis ») n'est pas une anomalie : elle se note à part et suit le circuit des évolutions, sinon la recette ne se termine jamais.

Quel environnement de recette prévoir ?

La recette se fait sur un environnement séparé de la production, configuré comme elle, avec des données de test réalistes mais non réelles. La CNIL recommande de développer et de tester dans un environnement distinct de la production, sur des données fictives ou anonymisées.

Des données représentatives : des clients aux cas variés, un volume proche du réel, des historiques. Un environnement vide masque les lenteurs et les cas tordus.
Des envois neutralisés : les e-mails, SMS et notifications de la recette ne doivent jamais partir chez vos vrais clients, et les paiements passent par le mode test du prestataire de paiement.
Des services tiers en mode test : un transporteur, un logiciel comptable ou une plateforme de facturation ont souvent leur propre recette. Pour le site de pièces Peugeot Motocycles, chaque service Chronopost a dû être validé par le transporteur sur des étiquettes de test avant l'ouverture des accès de production.
Les applications mobiles passent par les canaux de test des magasins : Apple TestFlight permet d'inviter jusqu'à 10 000 testeurs externes, après validation de la première version par Apple ; un test interne Google Play accepte jusqu'à 100 testeurs.

Chez YMHB Web, une version testable est accessible en permanence pendant la construction, conformément à la méthode publiée : la recette se fait par morceaux, à chaque cycle, au lieu de tout découvrir à la fin.

Le procès-verbal de réception : avec ou sans réserves

Le procès-verbal de réception est le document signé qui acte que le client accepte la livraison, éventuellement avec des réserves. Il doit être précis, car il déclenche souvent le paiement du solde et le début de la garantie.

Un procès-verbal utile mentionne :

la version exacte livrée et l'environnement concerné ;
le périmètre recetté, par renvoi au cahier de recette ;
la décision : réception sans réserve, réception avec réserves, ajournement ou refus ;
la liste des réserves, chacune avec sa gravité et un délai de levée ;
la date et les signatures des deux parties.

Attention à la réception de fait : beaucoup de contrats prévoient qu'une mise en production ou une utilisation prolongée sans réserve écrite vaut réception. Si vous utilisez le logiciel avant d'avoir signé, consignez par écrit les anomalies en cours. Le guide consacré au contrat de développement logiciel passe en revue les clauses de réception à négocier avant de signer.

Que se passe-t-il après la réception ?

Après la réception, les réserves sont levées une à une, puis s'ouvre la période de garantie contractuelle, qui couvre les défauts non détectés en recette. Une réserve et une anomalie sous garantie ne suivent pas le même circuit : la réserve est une correction due avant de solder le projet, la garantie couvre ce qui apparaît ensuite.

La garantie ne couvre ni les évolutions ni les changements d'environnement (nouvelle version d'iOS, API d'un partenaire modifiée). À son terme, ces sujets relèvent de la maintenance, décrite dans le guide de la TMA.

La recette ne s'arrête pas non plus à la réception : chaque mise à jour peut casser une fonction qui marchait. Pour la plateforme Klass., YMHB Web a écrit un programme qui rejoue 269 contrôles à chaque mise à jour (accès, cloisonnement entre établissements, scénarios métier) : sans zéro erreur, la mise à jour ne part pas. C'est la version automatisée d'un cahier de recette.

Checklist de recette

Les niveaux de gravité et leurs effets sur la réception sont écrits avant le premier test.
Un responsable de recette est nommé côté client, avec du temps réservé.
Le cahier de recette couvre cas nominaux, exceptions, droits et limites.
L'environnement de recette est séparé de la production, avec des données fictives ou anonymisées.
Les envois d'e-mails, de SMS et les paiements sont neutralisés ou en mode test.
Chaque anomalie est reproductible : compte, étapes, attendu, obtenu, capture.
Les demandes nouvelles sont notées à part, hors recette.
Un second passage est prévu après les corrections.
Le procès-verbal cite la version, le périmètre, les réserves et leurs délais.
Les scénarios essentiels sont rejoués à chaque mise à jour.

Questions fréquentes

Quelle est la différence entre la recette et les tests ?: Les tests sont menés par le prestataire pour vérifier que son code fonctionne comme prévu. La recette est menée par le client, ou pour son compte, pour vérifier que le logiciel répond au contrat et au métier, sur des scénarios réels. Les deux sont nécessaires : une recette sans tests préalables découvre trop d'anomalies, et des tests sans recette laissent passer ce que seul l'utilisateur sait repérer.
Combien de temps dure une recette logicielle ?: La durée d'une recette logicielle dépend du nombre de scénarios, de la disponibilité des utilisateurs et du nombre d'allers-retours de corrections. Dans les marchés publics informatiques, le CCAG-TIC fixe par défaut à 30 jours la vérification de service régulier qui suit la recette fonctionnelle. En contrat privé, la durée se négocie : elle doit être écrite, avec un second passage prévu après les corrections.
Peut-on refuser la réception d'un logiciel ?: En général oui : selon les clauses du contrat, un client peut refuser ou ajourner la réception d'un logiciel lorsqu'une anomalie bloquante empêche d'utiliser une fonction essentielle prévue. Le refus doit être écrit, motivé et rattaché aux scénarios du cahier de recette. Pour des anomalies majeures ou mineures, la pratique est plutôt une réception avec réserves, chacune assortie d'un délai de correction. En cas de désaccord, un avocat peut analyser le contrat.
Qui rédige le cahier de recette ?: Le cahier de recette est idéalement rédigé par le client, qui connaît ses cas réels, avec l'aide du prestataire, qui connaît le fonctionnement prévu. Le prestataire peut proposer une première version à partir du cahier des charges et des maquettes ; les utilisateurs clés la complètent avec leurs exceptions métier. L'important est qu'il soit validé par les deux parties avant la livraison.
Que se passe-t-il si l'on utilise le logiciel sans signer le procès-verbal ?: Utiliser un logiciel en production sans signer de procès-verbal peut valoir réception de fait si le contrat le prévoit, ce qui est fréquent. Les anomalies non signalées par écrit risquent alors de basculer dans la garantie, voire hors de celle-ci. Avant toute mise en production anticipée, notez par écrit les anomalies connues et la date à laquelle la recette sera close.

Recette logicielle : comment vérifier un logiciel avant de l'accepter

L'essentiel