Plan de recette d’une application métier : prouver avant d’accepter

Écrivez le plan avant la livraison. Pour chaque cas, nommez le besoin vérifié, la version, l’acteur et ses droits, l’état de départ, les données, les actions, le résultat attendu observable, le résultat obtenu et la preuve. Ajoutez la personne qui exécute et celle qui décide.

Exécutez d’abord les parcours dont l’échec aurait le plus d’impact. Gardez séparés quatre états : réussi, échoué, bloqué et non exécuté. Un cas critique absent reste absent, même si 99 autres cas sont verts. La campagne se termine par une décision documentée, jamais par un pourcentage isolé.

Commencez par identifier exactement ce qui sera testé. « La dernière version » ne suffit pas : consignez l’identifiant de livraison, l’environnement, les données chargées, les interfaces disponibles et les configurations qui influencent le résultat. Une correction installée pendant la recette crée une nouvelle base de comparaison. Notez son impact et les cas à rejouer.

Les critères d’entrée et de sortie présentés par l’ISTQB répondent à deux questions différentes : que faut-il avoir pour commencer, puis qu’est-ce qui doit être atteint pour déclarer l’activité terminée ? Arriver au bout du temps prévu n’efface pas les critères manquants. Si les parties prenantes décident néanmoins de s’arrêter, le risque résiduel reste à examiner et à consigner.

« Vérifier la facturation » ne constitue pas encore un cas. Il manque l’acteur, le dossier de départ, la règle appliquée et le résultat qui permettra de conclure. Écrivez une suite courte : besoin, état de départ, données, actions, résultat attendu observable et preuve.

« L’écran est rapide », « le résultat paraît correct » ou « l’interface est intuitive » ne sont pas encore des attendus testables. Fixez la mesure, le contexte et le seuil quand une qualité non fonctionnelle compte. La présentation publique d’ISO/IEC 25010:2023 indique que son modèle de qualité peut aider à identifier des objectifs de test et des critères d’acceptation. Elle ne fournit pas un seuil universel pour votre produit.

CAS DE RECETTE

Identifiant et besoin couvert :
Version et environnement :
Acteur et droits :
État de départ :
Données de test et règle de construction :
Actions exactes :
Résultat attendu observable :
Résultat obtenu :
Statut — réussi / échoué / bloqué / non exécuté :
Preuve et emplacement :
Testeur et date :
Anomalie liée, retest et limite connue :

Un seul dossier « propre » prouve peu. Pour chaque règle importante, préparez la situation courante, les limites qui changent le comportement, une valeur absente et une action interdite lorsque ces situations peuvent réellement se produire. Ajoutez les doublons, dates, arrondis, volumes et interfaces seulement lorsqu’ils correspondent à un risque du projet.

Faites tester par les personnes qui connaissent la règle et utiliseront le parcours, sans leur demander de couvrir seules les risques techniques. L’ISTQB place idéalement les utilisateurs visés dans les tests d’acceptation. Une personne métier sait reconnaître une facture incohérente ; elle n’est pas pour autant chargée de démontrer une protection contre les injections ou une conformité d’accessibilité.

Vous ne testerez presque jamais toutes les combinaisons possibles. Commencez par ce qui ferait le plus de tort : perte ou corruption de données, erreur de montant, droit d’accès incorrect, blocage du travail, doublon, rupture d’interface ou dossier impossible à reprendre. Reliez chaque risque aux cas qui le couvrent et gardez la liste de ce qui reste exclu.

L’ISTQB présente plusieurs stratégies de priorisation : par risque, par couverture ou par priorité des exigences. Les dépendances et la disponibilité des personnes ou environnements peuvent modifier l’ordre. Documentez la raison : « facile à exécuter » n’est pas une priorité métier.

Vous ne saisissez aucun contenu métier dans l’outil ci-dessous. Relisez d’abord les six maillons du cas, puis les critères de sortie et l’autorité de décision. Reportez enfin les nombres issus du même relevé de campagne. Laissez la réponse à « non renseigné » si vous l’ignorez. Conservez les cas échoués, bloqués, non exécutés ou sans preuve dans leur état, ainsi que les réserves en attente.

L’outil ne calcule aucune moyenne. Il traite les problèmes dans cet ordre : préparation bloquée, information absente ou partielle, compteurs incohérents, cas critique non prouvé, puis anomalie bloquante. Lorsque ces obstacles sont levés, il signale encore le risque résiduel, notamment un échec non classé ou une dérogation en attente. Le dossier n’est candidat que si les deux garde-fous de campagne sont prêts. Même dans ce cas, l’acceptation reste une décision humaine.

Une anomalie utile commence par un fait reproductible. Évitez « facturation cassée » ou « bug urgent ». Identifiez la fonction concernée, la version, l’environnement, le cas et les données. Donnez les étapes, le résultat attendu, le résultat obtenu et les pièces disponibles. L’équipe peut alors analyser l’écart, le corriger, constater qu’il n’est pas reproductible ou le reclasser comme demande d’évolution.

Le syllabus ISTQB distingue la gravité — degré d’impact — de la priorité de correction et propose aussi de conserver le statut et la référence du cas. Cette distinction évite deux raccourcis : une anomalie très visible n’est pas forcément la plus grave ; une anomalie grave ne disparaît pas parce qu’elle sera corrigée plus tard.

L’étiquette « mineure » ne protège aucune décision. Si l’écart touche fortement le métier, une obligation, un montant, des utilisateurs ou une exigence, revoyez d’abord sa gravité : il a peut-être été mal classé. S’il reste réellement d’impact limité, sa priorité peut néanmoins être élevée à cause d’une échéance ou d’une démonstration proche. Conservez les deux justifications.

1. La règle

Une intervention clôturée et non facturée crée un unique brouillon quand un responsable autorisé la valide. Le technicien ne peut plus modifier le tarif après cette validation.

2. Le cas nominal

CALCUL FICTIF

Déplacement : 40,00 €
Temps : 2 × 70,00 € = 140,00 €
Pièce : 1 × 25,00 € = 25,00 €
Total hors taxes attendu : 40,00 + 140,00 + 25,00 = 205,00 €

3. Les cas qui mettent la règle en difficulté

• aucune pièce : la ligne absente ne doit pas produire un montant fantôme ;
• technicien sans droit : la modification du tarif doit être refusée et expliquée ;
• double validation : un second brouillon ne doit pas apparaître ;
• service de facturation indisponible : l’intervention ne doit pas être déclarée facturée sans brouillon traçable ;
• correction après anomalie : le cas nominal et les variantes pertinentes sont rejoués sur la nouvelle version.

La preuve dépend du résultat : lignes et identifiant du brouillon, statut du dossier, journal de l’appel ou message de refus. Une capture peut aider, mais elle ne suffit pas si elle ne montre ni la version, ni le contexte, ni la donnée qui établit l’unicité.

Le relevé final rassemble la version, le périmètre, les critères de sortie, les cas exécutés et non exécutés, les résultats par risque, les cas échoués, les anomalies non closes, les réserves ou dérogations en attente, les preuves, les écarts au plan et le risque résiduel. Le décideur peut alors distinguer ce qui a été vérifié de ce que la campagne n’a pas démontré.

Les modèles de documentation existent, notamment dans la présentation publique d’ISO/IEC/IEEE 29119-3:2021. Ce guide n’en reproduit pas le contenu payant et ne prétend pas qu’un formulaire unique convient à tout projet. Gardez le dossier proportionné, mais assez précis pour expliquer la décision plusieurs mois plus tard.

RELEVÉ DE RECETTE

Produit, version et environnement :
Périmètre inclus et exclusions :
Critères d’entrée et de sortie :
Parcours et risques critiques :
Cas — réussi / échoué / bloqué / non exécuté :
Anomalies ouvertes — gravité / priorité / statut / responsable :
Réserves ou dérogations en attente :
Retests et non-régression :
Preuves et emplacement :
Écarts au plan et limites :
Risque résiduel :
Décideur, décision, date et éventuelles conditions prévues :

Le test de relève du logiciel métier intervient en amont lorsqu’une nouvelle équipe doit comprendre, déployer et restaurer l’existant. Une recette qui prépare un changement de système doit aussi rester distincte de la bascule et son retour arrière. Pour faire cadrer le périmètre, les rôles et les preuves de votre projet, vous pouvez en décrire le contexte.

Une recette ne s’écrit pas après coup : ses critères viennent du cahier des charges et du périmètre retenu pour le premier lot. Si l’un des deux reste flou, les cas de test le seront aussi, et l’acceptation se jouera sur des impressions.

Deux familles de tests sont régulièrement oubliées et méritent leur propre dossier : la vérification des droits d’accès, qui contrôle ce que chaque rôle ne doit pas pouvoir faire, et les contrôles de sécurité d’une application métier, dont la restauration et la journalisation. Le calendrier de recette, enfin, s’estime avec combien de temps il faut pour développer un SaaS — et le prestataire s’évalue sur ses preuves d’acceptation passées, comme l’explique le guide du choix sur preuves.