Ressources · 61

Recette projet : transformer un besoin en critères et preuves

Préparer scénarios, résultats attendus, preuves et arbitrage des réserves pour décider d’une livraison sur des tâches réellement vérifiées.

· 3 min

Schéma de méthode : Besoin → Critère → Scénario → Preuve → Décision Schéma de méthode · étapes expliquées dans le texte

Ce que ce guide permet

  • Partir d’une tâche
  • Écrire un attendu vérifiable
  • Relier la preuve au scénario
  • Arbitrer les réserves

Contrôle express

  • Qui doit accepter la livraison ?
  • Une réserve est-elle un succès ?
  • Peut-on réutiliser les tests après une correction ?

Méthode pas à pas

  1. 01

    Partir d’une tâche

    Écrivez qui doit accomplir quoi, dans quel contexte et avec quelles contraintes. La méthode proposée s’inspire de la préparation d’évaluations de services décrite par GOV.UK, sans assimiler une recette privée à une certification publique.

    Livrable : besoins et parcours prioritaires.

  2. 02

    Écrire un attendu vérifiable

    Remplacez les expressions comme rapide ou intuitif par un résultat observable et son contexte de mesure. Incluez erreurs, permissions, langue et accessibilité. Le critère décrit ce que l’utilisateur obtient, pas seulement la présence d’une fonctionnalité.

    Livrable : critères et données de test fictives.

  3. 03

    Relier la preuve au scénario

    Pour chaque essai, notez version, environnement, préconditions, action et résultat. Une capture d’écran seule ne prouve pas la réussite du parcours. Prévoyez une preuve que le reviewer peut relire ou rejouer sans accès aux secrets.

    Livrable : dossier de preuves reproductibles.

  4. 04

    Arbitrer les réserves

    Définissez avant recette les défauts bloquants, exceptions possibles et responsables. Une réserve acceptée exige un périmètre, un motif et une échéance ; elle ne transforme pas un essai échoué en essai réussi.

    Livrable : registre de réserves et décisions.

  5. 05

    Clore avec l’exploitation

    Testez aussi documentation, récupération et transfert au support. Pour un service utilisant l’IA, nommez ses limites et son responsable. Conservez le périmètre testé, les écarts ouverts et les conditions de nouvelle recette.

    Livrable : décision de livraison et suivi des réserves.

Fiche de travail à réutiliser

À compléter avec vos observations autorisées. Ces champs constituent une trame de travail, pas des résultats observés.

ChampInformation à consigner
BesoinPersonne, tâche et contexte
CritèreRésultat attendu et préconditions
EssaiVersion, données fictives et observé
DécisionRéserve, responsable et échéance

Exemple d’application

Situation illustrative

Exemple fictif : un formulaire envoie un dossier mais perd sa pièce jointe sur mobile.

Décision et preuve attendue

La recette distingue soumission technique et dossier complet ; le besoin ne passe que lorsque la pièce est récupérable par le destinataire.

Distinguer les mécanismes

MécanismeUtilitéPoint de vigilance
DémonstrationComprendre un parcours choisiNe pas la prendre pour toute la couverture
Recette métierVérifier tâches et résultats attendusInclure erreurs et profils distincts
Contrôle techniqueExaminer contrat et comportementRelier le résultat au besoin utilisateur

Indicateurs de pilotage

IndicateurCe qu’il mesurePremière action
Critères couvertsCritères effectivement exercésSéparer non testé, réussi et échoué
Réserves ouvertesÉcarts encore acceptés ou bloquantsNommer propriétaire et échéance
Preuves rejouablesScénarios reconstructiblesEnregistrer version et préconditions

Erreurs fréquentes

  • Ne pas la prendre pour toute la couverture
  • Inclure erreurs et profils distincts
  • Relier le résultat au besoin utilisateur

Questions fréquentes

Qui doit accepter la livraison ?

Le responsable désigné pour le besoin, avec les avis des compétences requises. Nommer cette responsabilité avant les tests évite un arbitrage implicite.

Une réserve est-elle un succès ?

Non. Elle reste un écart connu ; l’acceptation porte sur une décision documentée et un périmètre.

Peut-on réutiliser les tests après une correction ?

Oui, avec des données et préconditions stables, en identifiant la nouvelle version et les parcours susceptibles de régresser.

Références officielles

Références consultées le 2 octobre 2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.