# Recette : comment tester une solution avant de la mettre en service > Scénarios, testeurs, classement des anomalies, procès-verbal et réserves : la recette d’un logiciel expliquée aux PME qui la font pour la première fois. Publié le 29 octobre 2026 · Valentin Souvay, fondateur et consultant en transformation numérique (Onilys) Source : https://onilys.fr/blog/recette-comment-tester-une-solution-avant-de-la-mettre-en-service/ Le prestataire annonce que c’est prêt. Entre cette annonce et la mise en service, il y a la recette : le moment où vos équipes vérifient que la solution fait ce qui était demandé. C’est votre dernière occasion d’obtenir des corrections sans discussion. ## En bref ### La recette en cinq points - Des **scénarios** écrits à l’avance, tirés des besoins du cahier des charges, joués par les utilisateurs. - Des **données réalistes**, pas des exemples de démonstration. - Des **anomalies classées** : bloquante, majeure, mineure, avec un délai de correction pour chacune. - Un **procès-verbal** signé, avec ou sans réserves, qui marque la fin du projet et le début de la garantie. - Un **calendrier** réaliste : la recette prend du temps aux équipes, il faut le prévoir. Dans un projet logiciel, la recette est l’étape que personne n’attend avec impatience : les équipes ont leur travail, le prestataire voudrait livrer, la direction voudrait que ça tourne. Elle est pourtant le moment où se joue la qualité de ce que vous allez utiliser pendant des années. Une anomalie trouvée en recette se corrige dans le cadre du projet ; la même anomalie découverte après la mise en service se négocie, se facture, ou reste. Voici comment organiser une recette utile, dans une entreprise qui n’a pas de service informatique pour le faire. ## Ce qu’on vérifie, et ce qu’on ne vérifie pas La recette vérifie que la solution fait ce qui a été demandé, dans les conditions réelles d’utilisation. Elle ne vérifie pas que le code est bien écrit (c’est le travail du prestataire) ni que la solution est parfaite (ce n’est pas le but). Elle répond à une question : peut-on travailler avec ? C’est pour cela qu’elle se prépare dès le cahier des charges. Chaque besoin classé « indispensable » devrait avoir son scénario de test. Nous l’avions conseillé dans [notre article sur le cahier des charges](https://onilys.fr/blog/rediger-un-cahier-des-charges-que-les-prestataires-comprennent/) ; si ce n’est pas fait, c’est le moment. ## Préparer les scénarios Un scénario décrit une situation réelle, de bout en bout, avec le résultat attendu : > Un chef d’équipe déclare depuis son téléphone les heures de cinq personnes sur deux chantiers pour la journée d’hier. Le lendemain, l’assistante retrouve ces heures dans l’outil de paie, sans ressaisie, avec les bons chantiers. Les bons scénarios ont trois caractéristiques : - ils sont **écrits par les utilisateurs**, ou avec eux, à partir de leur quotidien ; - ils couvrent les **cas particuliers** : un salarié sur trois chantiers, un chantier terminé, une correction après validation ; - ils utilisent des **données réalistes** : vos vrais articles, vos vrais clients, pas les exemples du prestataire. Comptez quelques dizaines de scénarios pour un outil métier de PME. Classez-les : ceux qui doivent passer pour mettre en service, ceux qui peuvent attendre une correction. ## Organiser la période de recette **Un environnement de test**, distinct de la production, avec une copie de données réalistes. Les testeurs doivent pouvoir casser des choses sans conséquence. **Des testeurs désignés** dans chaque service concerné, avec du temps dégagé. Une demi-journée par semaine pendant deux semaines est un ordre de grandeur courant. **Un registre des anomalies**, partagé : un tableau avec le scénario, ce qui s’est passé, une capture d’écran, la gravité, le statut. Un outil simple suffit, à condition qu’il soit unique et que le prestataire y ait accès. **Des points réguliers** avec le prestataire, deux fois par semaine, pour trier les anomalies, décider ce qui est corrigé et quand, et retester. ## Classer les anomalies Le classement évite les discussions sans fin. Trois niveaux suffisent : - **Bloquante** : empêche un scénario indispensable. Pas de mise en service tant qu’elle n’est pas corrigée. - **Majeure** : le scénario passe avec un contournement pénible. À corriger avant la mise en service ou dans un délai court fixé par écrit. - **Mineure** : gêne, défaut d’affichage, libellé. À corriger dans le cadre de la garantie ou de la maintenance. Une anomalie n’est pas une demande d’évolution. Si le besoin n’était pas dans le cahier des charges, c’est une évolution, à chiffrer à part. Cette distinction protège les deux parties ; le registre doit la faire apparaître. ## Le procès-verbal de recette La recette se termine par un document signé par les deux parties : le procès-verbal. Il constate que la solution est conforme, sans réserve ou avec des réserves listées, chacune avec un délai de correction. Ce document a des effets concrets, à vérifier dans le contrat avant de commencer : - il marque souvent le **transfert de responsabilité** : après lui, les problèmes relèvent de la garantie ou de la maintenance ; - il déclenche généralement le **solde du paiement**, parfois conditionné à la levée des réserves ; - il fait démarrer la **période de garantie**, pendant laquelle les anomalies sont corrigées sans frais. Signer sans réserve pour faire plaisir, ou refuser de signer pour des points mineurs, sont deux erreurs symétriques. Le procès-verbal avec réserves datées est l’outil normal d’une fin de projet. ## Après la recette La recette vérifie l’outil ; elle ne remplace ni la formation, ni la reprise des données, ni la conduite du changement. Les premières semaines de mise en service révéleront d’autres choses : prévoyez un support renforcé, un canal pour remonter les problèmes et un point d’étape avec le prestataire après un mois. Et conservez les scénarios : ils serviront à retester chaque mise à jour importante de l’outil, et à former les nouveaux arrivants. Ils sont, avec le cahier des charges, la mémoire du projet. Organiser une recette fait partie de l’assistance à maîtrise d’ouvrage que nous assurons pour nos clients : écrire les scénarios avec les équipes, tenir le registre, arbitrer avec le prestataire. [Parlons de votre projet](https://onilys.fr/contact/){.cta} ## Questions fréquentes ### Qui doit faire la recette ? Les utilisateurs, pas le prestataire ni le chef de projet seul. Ce sont les personnes qui feront le travail avec l’outil qui verront si un cas réel passe. Le chef de projet organise, consigne les anomalies et arbitre ; le prestataire corrige. ### Que se passe-t-il si on signe la recette avec des réserves ? Les réserves listent ce qui reste à corriger, avec un délai. La mise en service peut avoir lieu si rien n’est bloquant, et le solde du paiement est souvent lié à leur levée. Il faut que le contrat le prévoie ; vérifiez-le avant de commencer. ### Combien de temps prévoir ? Pour un outil métier de PME, comptez une à trois semaines, avec les utilisateurs mobilisés une partie de leur temps, puis un cycle de corrections et une seconde passe. Prévoir une recette trop courte est l’une des causes les plus fréquentes de mises en service douloureuses.