•14 min de lecture
La recette logicielle est la phase pendant laquelle le client vérifie qu'une application livrée est conforme au besoin, avant de l'accepter et de la mettre en production. Elle enchaîne en général la VABF (conformité fonctionnelle), les tests d'acceptation utilisateurs (UAT), puis la VSR (service régulier en conditions réelles), avec des tests de non-régression à chaque correction. Une recette bien organisée suit six étapes : stratégie et périmètre, cahier de recette, environnement aux données anonymisées, exécution tracée, qualification des anomalies, puis PV et décision de go/no-go. À titre de repère, prévoyez 15 à 25 % de la durée de développement et mobilisez des utilisateurs clés côté métier. Un testeur QA externe se justifie lors d'un pic de charge avant release, en l'absence de QA interne ou pour lancer l'automatisation.
La recette est le moment où le donneur d'ordre contrôle que le logiciel livré répond à ce qui était demandé, puis décide de l'accepter. Le mot compte : c'est une vérification menée pour le compte du client, qui débouche sur une décision, pas une simple activité technique de l'équipe de développement.
Elle n'est donc ni une démonstration, où l'on ne montre que ce qui fonctionne, ni une séance de découverte des besoins, où l'on demande de nouvelles fonctionnalités. Une demande absente du périmètre initial n'est pas une anomalie : c'est une évolution, à traiter et à chiffrer comme telle.
Les tests unitaires, écrits par les développeurs, vérifient qu'un morceau de code fait ce que son auteur a prévu. Ils sont rapides et indispensables, mais ils ne disent rien de la justesse du besoin : si la règle de gestion a été mal comprise, le code est faux et les tests passent quand même.
La QA continue, elle, accompagne le développement : revue des spécifications, tests au fil de l'eau, intégration dans la chaîne CI/CD. Elle réduit le nombre d'anomalies qui atteignent la fin de projet, sans remplacer la recette.
La recette arrive en bout de chaîne, teste l'application assemblée du point de vue de l'utilisateur et engage le client. Les trois se complètent : une recette qui doit compenser l'absence des deux autres devient longue, chère et décourageante.
Elle vérifie chaque règle de gestion et chaque parcours au regard des spécifications. Le testeur déroule les scénarios ; le product owner ou le chef de projet arbitre les écarts d'interprétation.
Elle valide ce que l'utilisateur ne voit pas : installation, sauvegarde et restauration, supervision, journalisation, tenue en charge, procédure de retour arrière.
Elle confirme que l'outil permet de faire le travail, avec de vrais cas et de vraies contraintes. Une application peut être conforme à sa spécification et pourtant inutilisable sur le terrain.
Les sigles varient selon les organisations, et VABF et VSR viennent du vocabulaire des marchés informatiques. Peu importe l'étiquette : l'essentiel est de se mettre d'accord, dès le contrat, sur ce que recouvre chaque étape.
Sur l'environnement de recette, on contrôle la conformité aux spécifications, fonctionnalité par fonctionnalité. C'est la campagne la plus volumineuse, généralement conduite par les testeurs.
Les utilisateurs clés déroulent des parcours métier de bout en bout, une fois la VABF stabilisée. Inutile de les solliciter plus tôt : ils se lasseraient de buter sur des anomalies déjà connues.
Après la mise en production, on observe l'application en conditions réelles sur une période convenue, souvent de deux à quatre semaines : stabilité, performances, traitements périodiques, volumes.
Rejouer les parcours critiques après chaque correction ou évolution, pour vérifier que ce qui marchait marche toujours. C'est le premier candidat à l'automatisation.
Mesurer temps de réponse et tenue en charge avec un outil comme JMeter, sur une cible chiffrée : par exemple moins de deux secondes pour 95 % des requêtes à 500 utilisateurs simultanés.
Contrôler les droits par profil, l'authentification, le traitement des données personnelles et les failles courantes, avec un audit dédié ou un test d'intrusion si l'application est exposée ou sensible.
Automatisez ce qui est stable, répétitif et critique : les parcours rejoués à chaque livraison, en priorité la non-régression. Gardez en manuel les tests exploratoires, l'ergonomie et les fonctions encore instables, dont les scripts seraient à réécrire à chaque sprint.
Faites le calcul avant de vous lancer. Une campagne manuelle de 8 jours-homme, dont 5 sont automatisables pour un investissement de 30 jours-homme, s'amortit au bout de 6 à 8 releases une fois la maintenance des scripts comptée. Avec une release par mois, c'est rentable en moins d'un an. Avec deux par an, ça ne l'est sans doute pas.
Pour les applications mobiles, le parc d'appareils et les versions d'OS ajoutent une dimension, qui dépend en partie du choix entre natif et cross-platform.
La référence historique : multi-langages et multi-navigateurs, un écosystème vaste, mais davantage de mise en place et de maintenance.
Très apprécié des équipes front-end JavaScript pour son confort de débogage et sa prise en main rapide.
Plus récent, multi-navigateurs, rapide et doté d’attentes automatiques qui limitent les tests instables : un bon choix pour démarrer aujourd’hui.
La recette se prépare bien avant la première campagne. Ce déroulé, à dimensionner selon votre projet, vaut aussi bien pour une PME que pour un éditeur.
Écrivez sur deux ou trois pages ce qui sera testé, ce qui ne le sera pas, par qui, sur quel environnement et selon quels critères de sortie. Le point de départ, ce sont les critères de recette posés dans le cahier des charges : la stratégie les transforme en plan d'action.
Priorisez par le risque : une erreur sur le calcul de la facturation ne pèse pas comme un libellé mal aligné. Classez chaque domaine selon son impact métier et sa probabilité de panne, puis concentrez l'effort là où les deux sont élevés. Tester tout avec la même intensité revient à sous-tester ce qui compte.
Le cahier de recette rassemble les scénarios à dérouler. Chacun doit être exécutable par une personne qui n'a pas participé au projet et relié à une exigence, afin de mesurer la couverture. Commencez sa rédaction pendant les développements : découvrir une spécification ambiguë à ce moment-là coûte bien moins cher qu'en fin de projet.
Pour une application de taille moyenne, 150 à 400 scénarios sont un ordre de grandeur courant ; à deux ou trois scénarios rédigés par heure, prévoyez donc plusieurs semaines de préparation. Voici une mini-trame de cas de test, à reproduire dans votre outil :
L'environnement doit ressembler autant que possible à la production : mêmes versions, mêmes interfaces (ou des simulateurs identifiés comme tels), même volumétrie sur les traitements sensibles. Il doit aussi être stable : un déploiement sauvage en pleine campagne fausse tous les résultats. Fixez donc un rythme de livraison en recette, par exemple deux fois par semaine.
Côté données, copier la production telle quelle pose un problème au regard du RGPD. Privilégiez des données anonymisées ou synthétiques, en gardant à l'esprit que des données simplement pseudonymisées restent des données personnelles. Associez votre DPO en amont et préparez les données de test à l'avance : c'est souvent là que la recette prend ses premiers jours de retard.
Chaque exécution doit laisser une trace : qui a testé quoi, sur quelle version, avec quel résultat. Jira, complété par Xray, ou TestRail relient exigences, cas de test et anomalies. Un tableur peut suffire pour un très petit projet, mais il devient vite ingérable à plusieurs testeurs et sur plusieurs cycles.
Organisez la campagne en cycles : une première passe complète, un lot de corrections, puis une seconde passe incluant la non-régression. Un point quotidien de 15 minutes entre testeurs et développeurs suffit à arbitrer les anomalies. Suivez trois indicateurs simples : part de scénarios exécutés, part de scénarios réussis, nombre d'anomalies ouvertes par gravité.
Une anomalie exploitable contient les étapes de reproduction, le résultat attendu, le résultat obtenu, une capture et la version testée. Sa gravité se décide sur des critères définis à l'avance, sans quoi tout devient urgent. Exemple de grille et de délais de correction, à adapter à votre contrat :
Le PV de recette formalise la décision. Il contient l'identification du projet et de la version, le périmètre testé, les dates et l'environnement, la synthèse des campagnes, la liste des réserves avec leur échéance de levée, la décision (acceptation, acceptation avec réserves, refus) et les signatures.
La réunion de go/no-go réunit le sponsor, la DSI, le chef de projet, le responsable des tests et l'exploitation. Elle applique des critères fixés avant la campagne, par exemple : aucune anomalie bloquante, trois majeures au plus avec contournement documenté, 95 % des scénarios réussis et une procédure de retour arrière testée. Si ces seuils ne sont pas atteints, reporter d'une semaine coûte presque toujours moins cher que corriger dans l'urgence.
Un repère de terrain : 15 à 25 % de la durée de développement, à ajuster selon la criticité et la dette de tests. Prenons une application métier développée en six mois par quatre développeurs, avec un testeur en renfort. Comptez une première campagne de VABF de deux semaines, une semaine de corrections et de seconde passe, puis une à deux semaines d'UAT : quatre à cinq semaines, auxquelles s'ajoute une marge pour les aléas.
Côté équipe, le ratio d'un testeur pour trois à cinq développeurs est un bon point de départ. Il se resserre sur les produits réglementés ou fortement intégrés.
N'oubliez pas la charge métier, souvent absente des plannings. Trois utilisateurs clés mobilisés deux jours par semaine pendant quatre semaines représentent 24 jours-homme : à annoncer à leurs managers dès le cadrage, et non la veille de la campagne.
Le modèle de contrat ne change pas la façon de bien tester, mais il change ce que la recette déclenche. Pour le choix du modèle lui-même, reportez-vous à notre comparatif régie ou forfait.
Le prestataire s'engage sur un résultat. L'acceptation prononcée en recette déclenche en général le paiement du solde et le début de la garantie, dont la durée est fixée au contrat, souvent autour de trois mois.
Vérifiez cinq points : la durée de la recette, le sort des réserves, l'existence d'une acceptation tacite passé un délai, les délais de correction pendant la garantie, et la frontière entre non-conformité corrigée sans frais et évolution à chiffrer.
Le prestataire met à disposition des compétences, sous obligation de moyens. Il n'y a en général ni garantie sur le résultat ni acceptation conditionnant un solde : le client pilote la recette et les corrections consomment la capacité de l'équipe.
Le PV garde tout son intérêt, comme outil de décision et de traçabilité interne. Pensez simplement à conserver de la capacité après la mise en production, car personne ne corrigera les anomalies une fois l'équipe dissoute.
Ces principes généraux ne remplacent pas la lecture de votre contrat : faites valider ces clauses par votre service juridique.
En agile, la recette ne disparaît pas : elle se répartit. Chaque user story porte des critères d'acceptation, idéalement au format « étant donné, quand, alors », et la Definition of Done exige qu'ils soient vérifiés, que la non-régression passe et que la documentation soit à jour.
Sur un sprint de deux semaines, le testeur prépare ses scénarios dès l'affinage, teste au fil des développements, puis contribue à la stabilisation en fin de sprint. La démo, enfin, sert à recueillir le retour des métiers. Elle ne vaut pas recette à elle seule : on y montre des parcours choisis, sans en éprouver les cas limites.
Conservez une UAT courte avant chaque release majeure, surtout si elle embarque plusieurs sprints ou plusieurs équipes. Le sujet se complique à l'échelle : notre article sur le pilotage agile d'un projet IT détaille comment choisir son cadre.
La plupart de ces erreurs ne sont pas techniques : ce sont des problèmes d'organisation, visibles dès le cadrage, et faciles à corriger à ce moment-là.
Les retards de développement se reportent sur le dernier maillon, à date de mise en production inchangée. Sanctuarisez la durée de recette dans le planning et décidez à l'avance ce qui sera retiré du périmètre en cas de glissement.
Des utilisateurs prévenus la veille, sans temps dégagé, testent entre deux réunions ou pas du tout. Faites valider leur disponibilité par leur manager dès le cadrage, en jours précis et non en intentions.
Chaque correctif peut casser autre chose. Sans jeu de non-régression rejoué à chaque livraison, le dernier cycle découvre des pannes sur des fonctions déjà validées, au pire moment.
Volumes dérisoires, interfaces coupées, données trop propres : tout passe en recette et casse en production. Listez les écarts entre les deux environnements et testez-les autrement, ou assumez le risque par écrit.
Tester que tout fonctionne quand tout va bien ne suffit pas. Les pannes coûteuses viennent des saisies invalides, des droits insuffisants, des doublons, des coupures réseau et des traitements interrompus.
Si tout est bloquant, plus rien ne l'est, et les développeurs traitent les tickets au hasard. Un arbitre unique, une grille partagée et un tri quotidien évitent cet engorgement.
Fixés la veille de la mise en production, les seuils se négocient sous la pression du calendrier. Écrits avant la campagne, ils rendent la décision factuelle et protègent ceux qui la prennent.
Un regard indépendant trouve ce que l'équipe ne voit plus. Un testeur QA externe se justifie surtout si vous reconnaissez l'un de ces signaux :
Exécute les scénarios, rédige des anomalies précises et absorbe un pic de charge. À encadrer par un responsable des tests. La certification ISTQB Foundation atteste du vocabulaire et des bases.
Rédige le cahier de recette, conduit une campagne, écrit des tests automatisés et contrôle les données en SQL. C'est le profil le plus polyvalent pour une PME sans QA interne.
Définit la stratégie, pilote les campagnes, anime le go/no-go et pose le socle d'automatisation. Il peut intervenir à temps partiel pour cadrer, puis transmettre à l'équipe.
La certification ISTQB (niveaux Foundation, Advanced et Expert, portée en France par le CFTL) garantit un langage commun, sans préjuger de la pratique : en entretien, demandez au candidat de qualifier une anomalie réelle ou de critiquer un scénario. Un consultant testeur logiciel peut rejoindre une équipe déjà en place, ou accompagner un projet confié à des prestataires de développement informatique. Intégrez-le si possible avant la campagne : il lui faut quelques jours pour s'approprier le métier et pour relire les scénarios.
FASEYA présente des profils qualifiés sous 72h.
Missions, compétences et outils de nos consultants : retrouvez notre page dédiée à la recette logicielle.
Une question ? Un besoin en consultants IT ? Notre équipe est à votre écoute pour vous accompagner dans vos projets digitaux.
30 minutes d'échange pour comprendre vos besoins et vous proposer les meilleurs profils.
Gratuit et sans engagement
