Évaluation Ultime — Skill Stratégique

Pipeline d’analyse à 3 agents séquentiels autour de 7 frameworks. Tous les checkpoints du Vérificateur doivent être PASS avant d’atteindre le Validateur.

Invocation

~/.hermes/scripts/pipeline-evaluation.sh "<description du projet ou de l'idée>"

Frameworks

1. /premortem — Anticipation des échecs probables

Définition : Imaginer que le projet a échoué dans 6 mois et remonter les causes. Technique de Gary Klein (pré-autopsie prospective).

Critères :

• Horizon = 6 mois post-lancement
• Lister ≥5 scénarios d’échec probables (pas seulement catastrophiques)
• Chaque scénario inclut : cause racine, signal précoce détectable, mitigation possible
• Classer par probabilité × impact

Prompt-template :

PREMORTEM — [SUJET]
Imagine : dans 6 mois, [SUJET] a échoué. C'est un fait acquis.
Analyse rétrospectivement :
1. Quelles sont les 5 causes d'échec les plus probables (pas les plus dramatiques) ?
2. Pour chacune : signal précoce détectable (avant que ce soit trop tard) ?
3. Pour chacune : mesure préventive actionnable aujourd'hui ?
Format : tableau Cause | Probabilité(H/M/L) | Signal précoce | Mitigation

2. /blindspot — Traque des angles morts cognitifs

Définition : Identifier ce que l’analyste ne sait pas qu’il ne sait pas — biais de confirmation, zones d’ignorance structurelle, données manquantes critiques.

Critères :

• 4 quadrants : connu/connu, connu/inconnu, inconnu/connu, inconnu/inconnu
• Identifier ≥3 biais cognitifs actifs (confirmation, ancrage, disponibilité…)
• Lister les données absentes qui changeraient la conclusion
• Poser les questions que personne ne pose

Prompt-template :

BLINDSPOT — [SUJET]
Analyse les angles morts de cette évaluation de [SUJET] :
1. Quadrant des inconnues : qu'est-ce qu'on ne sait pas qu'on ignore ?
2. Biais cognitifs actifs dans cette analyse (≥3, avec exemple concret)
3. Données critiques manquantes qui retourneraient la conclusion
4. Questions inconfortables que l'analyse évite
5. Qui bénéficierait d'un échec ? Qui a intérêt à ce qu'on se trompe ?

3. L99 — Niveau Expert 99 (Décision GO/NO-GO)

Définition : Posture du praticien de niveau 99 — expert chevronné qui a vu suffisamment de patterns pour trancher sans hésiter. Décision binaire GO/NO-GO avec signature de l’argument décisif.

Critères :

• Décision binaire stricte : GO ou NO-GO (pas de “ça dépend”)
• L’argument décisif doit tenir en une phrase
• Liste des conditions qui inverseraient la décision
• Niveau de conviction (0-100%) avec justification

Prompt-template :

L99 DECISION — [SUJET]
Tu es un expert de niveau 99 dans ce domaine. Tu as vu des dizaines de projets similaires réussir et échouer.
Après avoir lu le rapport Stratège et la grille Auditeur :
1. DÉCISION : GO ou NO-GO (une seule réponse, pas de nuance)
2. ARGUMENT DÉCISIF : la phrase unique qui justifie cette décision
3. CONDITIONS DE RENVERSEMENT : 3 conditions qui changeraient ce verdict
4. NIVEAU DE CONVICTION : X/100 — pourquoi pas 100 ?
5. RISQUE RÉSIDUEL PRINCIPAL si GO : ce qui pourrait encore faire échouer

4. show logic — Raisonnement Transparent

Définition : Rendre visible chaque étape du raisonnement — pas de conclusion sans le chemin qui y mène. Anti-pattern des “boîtes noires” analytiques.

Critères :

• Chaque assertion est sourcée ou marquée [HYPOTHÈSE]
• Chaque saut logique est explicite
• Chaîne causale tracée de bout en bout
• Les incertitudes sont quantifiées (pas “peut-être”, mais “30% de chance que”)

Prompt-template :

SHOW LOGIC — [SUJET]
Rends visible ton raisonnement sur [SUJET] :
Format obligatoire pour chaque point :
  ASSERTION → SOURCE/HYPOTHÈSE → IMPLICATION → CONFIDENCE %
Utilise "parce que", "donc", "si X alors Y" explicitement.
Marque [HYPOTHÈSE NON VÉRIFIÉE] quand tu supposes sans données.
Chaîne causale finale : A → B → C → CONCLUSION

5. OODA — Observe, Orient, Decide, Act

Définition : Framework de décision sous contrainte temporelle et incertitude (John Boyd). Référence l’implémentation existante.

Référence : ~/.hermes/skills/rtcc-ooda-methodology/SKILL.md

Application dans ce pipeline :

OBSERVER  : données du marché, contexte actuel, signaux faibles
ORIENTER  : interprétation des données + positionnement compétitif
DÉCIDER   : choix d'approche stratégique (pas encore GO/NO-GO — c'est L99)
AGIR      : plan d'action séquencé avec jalons mesurables

6. /wargame — Simulation Adversariale

Définition : Jouer le rôle des opposants — concurrents, régulateurs, utilisateurs hostiles, marché défavorable. Simuler leurs réactions et contre-mesures.

Critères :

• Minimum 3 profils adversariaux différents
• Pour chaque profil : motivation, ressources disponibles, tactique probable
• Identifier le scénario adversarial le plus dangereux
• Définir les contre-mesures défensives

Prompt-template :

WARGAME — [SUJET]
Simule les réactions adversariales contre [SUJET] :

PROFIL 1 — Concurrent direct :
  Motivation : [pourquoi ils attaqueraient]
  Ressources : [ce qu'ils peuvent déployer]
  Tactique : [comment ils réagiraient dans 90 jours]

PROFIL 2 — Régulateur/Institution :
  [même structure]

PROFIL 3 — Marché/Utilisateurs hostiles :
  [même structure]

SCÉNARIO LE PLUS DANGEREUX : [lequel ? pourquoi ?]
CONTRE-MESURES : [top 3 défenses à préparer maintenant]

7. /deepsync — Décorticage Général→Spécifique

Définition : Descente structurée du niveau macro (vision) au micro (action). Évite les plans qui restent au niveau des principes sans toucher le sol.

Critères :

• 5 niveaux minimum : Vision → Stratégie → Tactique → Opération → Action
• Chaque niveau a ses indicateurs de succès propres
• Les actions du niveau 5 sont exécutables dans la semaine
• Les dépendances entre niveaux sont explicites

Prompt-template :

DEEPSYNC — [SUJET]
Décompose [SUJET] du général au spécifique :

NIVEAU 1 — VISION (18 mois) : où veut-on arriver ?
NIVEAU 2 — STRATÉGIE (6 mois) : comment y aller ?
NIVEAU 3 — TACTIQUE (3 mois) : quelles batailles gagner ?
NIVEAU 4 — OPÉRATION (1 mois) : quelles actions prioritaires ?
NIVEAU 5 — ACTION (cette semaine) : que faire lundi matin ?

Pour chaque niveau : Objectif | KPI de succès | Dépendances

Pipeline Tri-Agent

AGENT 1 — Stratège (PLAN)

• Frameworks : /premortem + /blindspot + OODA + /deepsync
• Input : description du projet/idée
• Livrable : plan.md — document de conception avec carte des risques, stratégie d’approche, décomposition macro→micro

AGENT 2 — Auditeur (VÉRIFICATEUR)

• Frameworks : /wargame + show logic
• Input : plan.md du Stratège
• Checkpoints obligatoires (tous PASS requis) :
  1. CP1 — Simplicité & Technique : la solution est-elle réalisable sans dette technique excessive ?
  2. CP2 — Données Probantes : best practices confirmées + avis experts + retours utilisateurs réels ?
  3. CP3 — Viabilité Financière : le modèle économique tient-il sous stress test ?
• Livrable : audit.md — grille PASS/FAIL avec preuves pour chaque checkpoint

AGENT 3 — Validateur (DÉCIDEUR)

• Framework : L99
• Input : plan.md + audit.md
• Condition d’accès : les 3 checkpoints de l’Auditeur DOIVENT être PASS
• Livrable : decision.md — GO confirmé ou NO-GO ferme avec explication

Règles du Pipeline

1. Les agents sont séquentiels — le suivant ne démarre pas sans le livrable du précédent.
2. Si CP1 ou CP2 ou CP3 = FAIL → pipeline arrêté, NO-GO automatique, rapport d’explication.
3. Les livrables sont sauvegardés dans ~/.hermes/logs/eval-YYYYMMDD-HHMMSS/.
4. Le Validateur n’a pas accès au sujet original — uniquement plan.md et audit.md (évite le biais d’ancrage).

Conflits et Intégrations

• OODA : référence rtcc-ooda-methodology — ne pas dupliquer, utiliser comme sous-composant.
• Task Observer : ce skill est observé par task-observer pour amélioration continue.
• route-claude.sh : le pipeline utilise le wrapper existant pour déléguer à Claude Code CLI.