Réviser la dernière version du plan, en conservant les objectifs, le périmètre et les décisions raisonnables d'origine, sans refaire l'analyse des besoins. Consulter d'abord le projet et la documentation, sans redemander des informations déjà disponibles ; si le plan original manque, le demander.
1. Grill : Décisions implicites (obligatoire)
Identifier les comportements à fort impact que le plan a implicitement décidé ou omis pour l'utilisateur. Examiner le parcours utilisateur pour vérifier les valeurs par défaut, les cas d'erreur/annulation/réessai, la reprise d'état, les contrats inter-modules, la migration de compatibilité et les limites de permission. Utiliser des contre-exemples concrets pour challenger les hypothèses, sans exécuter une liste de contrôle mécanique.
Ne poser que des questions sur les véritables compromis qui modifieraient significativement l'expérience, l'architecture, les données, la sécurité ou les coûts ; les faits vérifiables et les détails peu coûteux et réversibles sont résolus par la compétence elle-même. Chaque question doit indiquer l'hypothèse/la lacune, les conséquences et une suggestion. Plusieurs tours sont possibles, avec de nombreuses questions par tour, numérotées par thème, en posant d'abord les questions sur les décisions préalables ; attendre la réponse avant de finaliser, le silence n'est pas considéré comme un accord.
2. Oracle : Validation objective (optionnelle)
Activée uniquement lorsqu'il existe des critères objectifs crédibles et rentables ; l'utilisateur peut sauter cette étape. Pour les exigences clés, spécifier la source du critère, la méthode de vérification et les conditions de réussite ; donner la priorité aux normes, aux implémentations de référence, aux exemples validés par l'utilisateur et aux invariants. Pour les tâches d'optimisation, lister séparément la base de référence, les indicateurs et les contraintes à ne pas dégrader. Ne pas faire passer l'auto-évaluation du modèle ou les indicateurs proxy pour la vérité ; les parties impossibles à vérifier automatiquement sont conservées pour validation manuelle.
3. Prototype : Comparaison subjective (optionnelle)
Activée uniquement lorsque l'apparence ou la sensation influence la solution et que les mots seuls ne suffisent pas ; l'utilisateur peut sauter cette étape. Utiliser des références ou des prototypes minimaux présentant des différences substantielles pour permettre à l'utilisateur de comparer et de choisir, sans continuer à sonder les préférences abstraites. Ne créer un prototype isolé que si le mode actuel le permet et si l'utilisateur l'a autorisé ; sinon, écrire « comparaison de prototypes → choix de l'utilisateur → mise en œuvre associée » dans la seconde version, et conserver les éléments en suspens correspondants. Ne pas prétendre avoir validé sans avoir montré ou comparé.
Convergence
Converger après avoir confirmé, délégué explicitement ou reporté les décisions importantes ; également converger si l'utilisateur demande de terminer. Produire une seconde version du plan complète et indépendante, intégrant les décisions, les étapes de mise en œuvre et les points de validation/porte de prototype applicables, accompagnée d'un bref résumé des modifications et des hypothèses restantes ; indiquer pour les éléments reportés quand ils seront décidés et ce qu'ils bloquent. Ne pas remettre seulement un questionnaire ou des correctifs, ne pas prétendre avoir épuisé les risques. S'arrêter après la sortie, ne pas commencer la mise en œuvre ou relancer la révision.