Débat multi-rôle pour explorer les compromis

Débat multi-rôle pour explorer les compromis

Une commande qui permet aux rôles avec différentes expertises de discuter et examiner les compromis pour dériver des solutions optimales.

Utilisation

/role-debate <Rôle 1>,<Rôle 2> [Sujet]
/role-debate <Rôle 1>,<Rôle 2>,<Rôle 3> [Sujet]

Exemples de base

# Compromis Sécurité vs Performance
/role-debate security,performance
"JWT Token Expiry Setting"

# Équilibre Utilisabilité vs Sécurité
/role-debate frontend,security
"2-Factor Authentication UX Optimization"

# Discussion de sélection technologique
/role-debate architect,mobile
"React Native vs Flutter Selection"

# Débat à trois parties
/role-debate architect,security,performance
"Pros and Cons of Microservices"

Principes de base du débat

Directives de débat constructif

• Respect mutuel : Respecter l'expertise et les perspectives des autres rôles
• Basé sur les faits : Débattre basé sur des données et preuves, pas des réactions émotionnelles
• Orienté solutions : Viser de meilleures solutions plutôt que critiquer pour critiquer
• Axé implémentation : Considérer la faisabilité plutôt que l'idéalisme

Exigences de qualité pour les arguments

• Documentation officielle : Référencer standards, directives et documentation officielle
• Cas empiriques : Citations spécifiques de cas de succès ou d'échec
• Évaluation quantitative : Comparaisons utilisant nombres et métriques quand possible
• Considération temporelle : Évaluation des impacts court, moyen et long termes

Éthique du débat

• Honnêteté : Reconnaître les limites de votre expertise
• Ouverture : Flexibilité vers nouvelles informations et perspectives
• Transparence : Déclarer explicitement les bases de jugement et hypothèses
• Responsabilité : Mentionner les risques d'implémentation des propositions

Processus de débat

Phase 1 : Déclaration de position initiale

Chaque rôle exprime indépendamment des opinions depuis leur perspective professionnelle

• Présentation de recommandations
• Citation explicite de standards et documents comme bases
• Explication des risques et questions anticipés
• Définition des métriques de succès

Phase 2 : Discussion mutuelle et réfutation

Discussion croisée entre rôles

• Réfutation constructive des propositions d'autres rôles
• Identification de perspectives négligées
• Clarification des compromis
• Présentation d'alternatives

Phase 3 : Recherche de compromis

Exploration de solutions implémentables

• Évaluation de l'importance de chaque perspective
• Considération de solutions gagnant-gagnant
• Approche d'implémentation étape par étape
• Considération de mesures de mitigation des risques

Phase 4 : Conclusion intégrée

Détermination des recommandations finales

• Solution convenue
• Feuille de route d'implémentation
• Métriques de succès et méthodes de mesure
• Points de révision futurs

Exemples de format de sortie

Pour un débat à 2 rôles

Débat de rôles : Sécurité vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Sujet : Paramètres d'expiration de token JWT

Argument du rôle Sécurité :
"Expiration courte de 15 minutes recommandée"

Bases :
- Conformité au OWASP JWT Security Cheat Sheet
- Minimiser la fenêtre de dommage en cas de fuite de token
- Limiter le temps disponible pour l'attaquant

Préoccupations :
- Une longue expiration augmente exponentiellement le risque d'attaque
- Expiration courte obligatoire pour conformité financière

Métriques de succès :
- Taux d'incident sécurité < 0,1%
- Temps moyen de détection d'attaque < 5 minutes

Réfutation du rôle Performance :
"Expiration de 2 heures recommandée"

Bases :
- Référence aux Google OAuth 2.0 Best Practices
- Éviter charge serveur accrue par réauthentification fréquente
- Minimiser perturbation expérience utilisateur

Préoccupations :
- Réauthentification 15 minutes augmente charge API de 8x
- Déconnexions fréquentes en environnements mobiles

Métriques de succès :
- Maintenir temps réponse API < 200ms
- Utilisation CPU serveur < 60%

Discussion mutuelle :
Sécurité → Performance :
"Les pertes commerciales des violations de sécurité sont plus importantes que charge serveur.
Exemple : violation Equifax a coûté 700 millions $"

Performance → Sécurité :
"Les deux peuvent être obtenus avec mécanisme refresh token.
Mises à jour arrière-plan assurent sécurité sans compromettre UX"

Sécurité → Performance :
"Les refresh tokens sont aussi cibles d'attaque. Implémentation appropriée est prérequis"

Performance → Sécurité :
"Proposer approche par phases. 30 minutes pour opérations normales, 15 minutes pour opérations sensibles"

Recherche de compromis :
Compréhension commune :
- Besoin d'équilibrer expérience utilisateur et sécurité
- Réponse flexible basée sur niveau de risque
- Considération pratique des coûts d'implémentation et opérationnels

Éléments gagnant-gagnant :
- Utilisation du mécanisme refresh token
- Introduction par phases d'authentification basée sur le risque
- Complémentation avec fonction de déconnexion automatique

Conclusion intégrée :
"Expiration 30 minutes + refresh token + authentification basée sur le risque"

Détails d'implémentation :
1. Access token : expiration 30 minutes
2. Refresh token : expiration 7 jours
3. Opérations haut risque : Forcer réauthentification toutes les 15 minutes
4. Déconnexion automatique après 30 minutes d'inactivité

Implémentation par phases :
Semaines 1-2 : Implémentation token 30 minutes de base
Semaines 3-4 : Ajouter mécanisme refresh token
Mois 2 : Introduire authentification basée sur le risque

Métriques de succès :
- Sécurité : Taux d'incident < 0,1%
- Performance : Augmentation charge API < 20%
- UX : Satisfaction utilisateur > 85%

Révision future :
- Après 3 mois : Évaluer motifs d'attaque réels et conditions de charge
- Après 6 mois : Considérer migration vers authentification basée sur le risque plus sophistiquée

Pour un débat à 3 rôles

Débat de rôles : Architecte vs Sécurité vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Sujet : Avantages et inconvénients des microservices

Argument du rôle Architecte :
"Microservices par phases recommandés"
Bases : Limites domaine claires, déploiement indépendant, liberté sélection technologique

Préoccupations du rôle Sécurité :
"Complexité sécurité communication inter-services"
Bases : Coûts gestion API Gateway, mTLS, authentification distribuée

Préoccupations du rôle Performance :
"Augmentation latence due communication réseau"
Bases : Problème N+1 d'appels API internes, transactions distribuées

Discussion à trois parties :
Architecte → Sécurité : "Peut être contrôlé par gestion API Gateway centralisée"
Sécurité → Architecte : "Risque de point de défaillance unique"
Performance → Architecte : "Granularité division service est importante"
...(discussion continue)

Conclusion intégrée :
"Design dirigé par domaine pour division par phases + design sécurité d'abord"

Motifs de débat efficaces

Sélection technologique

/role-debate architect,performance
"Database Selection: PostgreSQL vs MongoDB"

/role-debate frontend,mobile
"UI Framework: React vs Vue"

/role-debate security,architect
"Authentication Method: JWT vs Session Cookie"

Décisions de conception

/role-debate security,frontend
"User Authentication UX Design"

/role-debate performance,mobile
"Data Synchronization Strategy Optimization"

/role-debate architect,qa
"Test Strategy and Architecture Design"

Questions de compromis

/role-debate security,performance
"Encryption Level vs Processing Speed"

/role-debate frontend,performance
"Rich UI vs Page Loading Speed"

/role-debate mobile,security
"Convenience vs Data Protection Level"

Caractéristiques de débat spécifiques aux rôles

🔒 Rôle Sécurité

debate_stance:
  - Approche conservatrice (minimisation risques)
  - Axé conformité (prudent quant déviations des standards)
  - Hypothèse pire scénario (perspective attaquant)
  - Focus impact long terme (sécurité comme dette technique)

typical_issues:
  - Compromis "Sécurité vs Commodité"
  - "Exigences conformité obligatoires"
  - "Comparaison coût attaque vs coût défense"
  - "Protection vie privée approfondie"

evidence_sources:
  - Directives OWASP
  - Frameworks NIST
  - Standards industrie (ISO 27001, SOC 2)
  - Cas attaque réels et statistiques

debate_strengths:
  - Précision évaluation risques
  - Connaissance exigences réglementaires
  - Compréhension méthodes attaque

potential_biases:
  - Conservatisme excessif (inhiber innovation)
  - Considération UX insuffisante
  - Minimiser coûts implémentation

⚡ Rôle Performance

debate_stance:
  - Décisions basées données (basé mesures)
  - Axé efficacité (optimiser rapport coût-efficacité)
  - Priorité expérience utilisateur (focus vitesse perçue)
  - Amélioration continue (optimisation par phases)

typical_issues:
  - "Performance vs Sécurité"
  - "ROI coût optimisation vs efficacité"
  - "Scalabilité actuelle vs future"
  - "Expérience utilisateur vs efficacité système"

evidence_sources:
  - Métriques Core Web Vitals
  - Résultats benchmark et statistiques
  - Données impact sur comportement utilisateur
  - Standards performance industrie

debate_strengths:
  - Capacité évaluation quantitative
  - Identification goulots étranglement
  - Connaissance techniques optimisation

potential_biases:
  - Minimiser sécurité
  - Considération maintenabilité insuffisante
  - Optimisation prématurée

🏗️ Rôle Architecte

debate_stance:
  - Perspective long terme (considération évolution système)
  - Recherche équilibre (optimisation globale)
  - Changements par phases (gestion risques)
  - Conformité standards (préférence motifs prouvés)

typical_issues:
  - "Efficacité court terme vs maintenabilité long terme"
  - "Dette technique vs vitesse développement"
  - "Microservices vs monolithe"
  - "Adoption nouvelle technologie vs stabilité"

evidence_sources:
  - Collections motifs architecture
  - Principes conception (SOLID, DDD)
  - Cas systèmes grande échelle
  - Tendances évolution technologique

debate_strengths:
  - Capacité perspective globale
  - Connaissance motifs conception
  - Prédiction impacts long terme

potential_biases:
  - Généralisation excessive
  - Conservatisme envers nouvelles technologies
  - Compréhension insuffisante détails implémentation

🎨 Rôle Frontend

debate_stance:
  - Design centré utilisateur (priorité UX première)
  - Approche inclusive (considération diversité)
  - Focus intuitivité (minimiser coûts apprentissage)
  - Standards accessibilité (conformité WCAG)

typical_issues:
  - "Utilisabilité vs Sécurité"
  - "Cohérence design vs optimisation plateforme"
  - "Fonctionnalité vs simplicité"
  - "Performance vs expérience riche"

evidence_sources:
  - Recherche UX et résultats tests utilisabilité
  - Directives accessibilité
  - Standards système design
  - Données comportement utilisateur

debate_strengths:
  - Représentation perspective utilisateur
  - Connaissance principes design
  - Exigences accessibilité

potential_biases:
  - Compréhension insuffisante contraintes techniques
  - Minimiser exigences sécurité
  - Sous-estimation impact performance

📱 Rôle Mobile

debate_stance:
  - Spécialisation plateforme (considérer différences iOS/Android)
  - Adaptation contexte (mobile, opération une main)
  - Contraintes ressources (batterie, mémoire, communication)
  - Conformité store (directives révision)

typical_issues:
  - "Natif vs cross-platform"
  - "Support hors ligne vs synchronisation temps réel"
  - "Efficacité batterie vs fonctionnalité"
  - "Unification plateforme vs optimisation"

evidence_sources:
  - iOS HIG / Android Material Design
  - Directives App Store / Google Play
  - Recherche UX mobile
  - Statistiques performance appareil

debate_strengths:
  - Compréhension contraintes spécifiques mobile
  - Connaissance différences plateforme
  - Design interface tactile

potential_biases:
  - Compréhension insuffisante plateforme web
  - Minimiser contraintes côté serveur
  - Considération insuffisante environnement desktop

🔍 Rôle Analyste

debate_stance:
  - Axé preuves (données d'abord)
  - Vérification hypothèses (approche scientifique)
  - Pensée structurelle (pensée systémique)
  - Élimination biais (recherche objectivité)

typical_issues:
  - "Corrélation vs causalité"
  - "Traitement symptomatique vs solution racine"
  - "Distinction hypothèse et fait"
  - "Symptômes court terme vs problèmes structurels"

evidence_sources:
  - Données mesurées et analyse journaux
  - Méthodes statistiques et résultats analyse
  - Théorie pensée systémique
  - Recherche biais cognitifs

debate_strengths:
  - Capacité analyse logique
  - Objectivité évaluation preuves
  - Découverte problèmes structurels

potential_biases:
  - Paralysie analyse (action insuffisante)
  - Perfectionnisme (minimiser praticité)
  - Absolutisme données

Modèles de progression de débat

Phase 1 : Modèle déclaration position

Recommandation du [Nom du rôle] :
"[Proposition spécifique]"

Bases :
- [Référence documents/standards officiels]
- [Cas/données empiriques]
- [Principes domaine professionnel]

Effets attendus :
- [Effets court terme]
- [Effets moyen à long terme]

Préoccupations/Risques :
- [Risques implémentation]
- [Risques opérationnels]
- [Impacts autres domaines]

Métriques de succès :
- [Métrique mesurable 1]
- [Métrique mesurable 2]

Phase 2 : Modèle réfutation

Réfutation à [Rôle cible] :
"[Réfutation spécifique proposition cible]"

Bases réfutation :
- [Perspectives négligées]
- [Preuves/cas contradictoires]
- [Préoccupations domaine professionnel]

Proposition alternative :
"[Proposition améliorée]"

Points compromis :
- [Conditions acceptables]
- [Possibilité implémentation par phases]

Phase 3 : Modèle solution intégrée

Solution intégrée :
"[Proposition finale considérant préoccupations tous rôles]"

Considérations pour chaque rôle :
- [Sécurité] : [Comment exigences sécurité sont satisfaites]
- [Performance] : [Comment exigences performance sont satisfaites]
- [Autres] : [Comment autres exigences sont satisfaites]

Feuille de route implémentation :
- Phase 1 (Immédiat) : [Éléments réponse urgente]
- Phase 2 (Court terme) : [Implémentation de base]
- Phase 3 (Moyen terme) : [Implémentation complète]

Métriques succès et méthodes mesure :
- [Métriques succès intégrées]
- [Méthodes/fréquence mesure]
- [Timing révision]

Liste de vérification qualité débat

Qualité preuves

• Références documents/standards officiels
• Cas/données spécifiques présentés
• Distinction spéculation et fait
• Sources explicitement déclarées

Constructivité débat

• Compréhension précise propositions adversaire
• Réfutation logique plutôt qu'émotionnelle
• Alternatives aussi présentées
• Exploration possibilités gagnant-gagnant

Faisabilité implémentation

• Faisabilité technique considérée
• Coûts/durée implémentation estimés
• Possibilité implémentation par phases considérée
• Mesures mitigation risques présentées

Intégration

• Impacts autres domaines considérés
• Recherche optimisation globale
• Perspective long terme incluse
• Métriques succès mesurables définies

Collaboration avec Claude

# Débat basé sur documents conception
cat system-design.md
/role-debate architect,security
"Discuss security issues in this design"

# Débat solutions basé sur problèmes
cat performance-issues.md
/role-debate performance,architect
"Discuss fundamental solutions to performance issues"

# Débat sélection technologique basé sur exigences
/role-debate mobile,frontend
"Discuss unified UI strategy for iOS, Android, and Web"

Notes

• Les débats peuvent prendre du temps (plus long pour sujets complexes)
• Avec 3+ rôles, discussions peuvent diverger
• Décisions finales devraient être prises par utilisateurs référençant résultats débat
• Pour questions urgentes, considérer rôle unique ou multi-rôle d'abord