Compétence Stratégie
Description
Aide l'utilisateur à transformer un problème métier flou en un mécanisme structuré, vérifiable et prêt à être mis en œuvre, en traitant explicitement les indicateurs, les responsabilités et les risques.
Principe fondamental : la solution n'est pas générée en une seule fois, mais avancée par phases. Chaque phase dépend des conclusions de la phase précédente. À la fin de chaque phase, le processus s'arrête pour attendre votre confirmation. Pas de confirmation, pas d'étape suivante.
Quand utiliser
- Lorsqu'il faut transformer une orientation floue en une stratégie, un mécanisme ou un plan d'incitation exécutable.
- Lorsqu'il faut concevoir ou reconcevoir des mécanismes d'incitation, des règles, une allocation de ressources ou un système de gouvernance.
- Lorsqu'il faut réutiliser l'expérience de projets antérieurs et des méthodes réutilisables.
- Lorsqu'il faut vérifier si une solution est réalisable, s'il existe des limites de responsabilité floues ou une inadéquation des responsabilités.
Quand ne pas utiliser
- Pour des tâches simples de questions-réponses, de recherche de connaissances ou d'importation de fichiers qui ne sont pas de nature stratégique.
- Pour des tâches de génération de contenu pur, de rédaction publicitaire, etc., qui ne sont pas de conception de mécanismes.
Règles de démarrage (chargement progressif du contexte)
Le contexte est chargé selon le principe « charger uniquement ce qui est nécessaire », ne chargez pas l'intégralité des fichiers à chaque démarrage :
references/user-context.md(Niveau 1｜Préférences de travail personnelles : style de communication, style de sortie, habitudes de collaboration avec l'IA)references/business-context.md(Niveau 2｜Contexte métier : modèle économique, produits et services, rôles clés, indicateurs, contraintes)- Le briefing actuel du projet (stocké dans le fichier projet correspondant sous
cases/après la confirmation de la Phase 0) - Lecture sélective des références de stratégie (framework / méthode / checklist / patterns) en fonction de la tâche en cours
- Lorsque l'expérience antérieure est nécessaire, consultez d'abord
references/project-experience-index.mdpour localiser les entrées pertinentes, puis lisez uniquement les parties correspondantes du fichier de solution, sans lecture complète.
Initialisation initiale
Si user-context.md ou business-context.md n'existent pas, lisez le fichier .example.md correspondant et effectuez l'initialisation via la conversation. L'utilisateur peut choisir l'une des méthodes suivantes :
- Méthode A (texte) : indiquez directement à l'Agent vos préférences de travail et le contexte métier.
- Méthode B (fichiers) : fournissez des fichiers existants (présentation de l'entreprise, description du métier, organigramme, description des indicateurs, documents de stratégie antérieurs, etc.), l'Agent en extrait les informations nécessaires.
Les résultats organisés sont d'abord présentés à l'utilisateur pour confirmation, puis les fichiers de contexte réels sont créés. L'initialisation n'a pas besoin d'être terminée en une seule fois ; elle peut être suffisante pour entrer dans la Phase 0, puis complétée ultérieurement selon les besoins.
Calendrier de création des autres fichiers utilisateur :
project-experience-index.md: lors de la première recherche d'expérience antérieure, si le fichier n'existe pas, créez d'abord un index vide basé surproject-experience-index.example.md; s'il n'y a pas de projet antérieur, ignorez la recherche d'expérience antérieure, cela n'affecte pas l'avancement du Workflow.user-methods.md: pas besoin d'initialisation initiale. La première fois que l'utilisateur confirme vouloir formaliser une nouvelle méthode, créez-la à partir deuser-methods.example.md.
Réécriture du contexte (Selective Write-back)
Lorsque de nouvelles informations potentiellement réutilisables à long terme apparaissent au cours du projet :
- Déterminez à quel niveau elles appartiennent :
- Préférences de travail personnelles →
user-context.md - Contexte métier stable →
business-context.md - Nouvelles méthodes ou expériences d'analyse de l'utilisateur →
user-methods.md - Expérience de projet antérieure →
project-experience-index.md - Informations temporaires du projet en cours → fichier projet actuel dans
cases/
- Préférences de travail personnelles →
- N'écrivez pas automatiquement, demandez d'abord à l'utilisateur s'il souhaite les conserver.
- Après confirmation de l'utilisateur, mettez à jour le fichier correspondant ; les informations propres au projet en cours restent dans le fichier projet actuel, sans être écrites dans les Références à long terme.
Les Références de stratégie intégrées (strategy-framework.md, mechanism-strategy-method.md, incentive-patterns.md, risk-checklist.md, project-briefing-checklist.md) sont en lecture seule par défaut et ne doivent pas être modifiées automatiquement pour un seul projet.
Principe : lire selon les besoins, conserver après confirmation.
Protocole de passage des phases de la solution
La solution progresse à travers 8 phases. Chaque phase a des conditions d'entrée, des règles et des conditions de sortie. À la fin de chaque phase, arrêtez-vous et attendez votre confirmation. Il est possible de revenir à une phase antérieure à tout moment.
Règles globales (applicables à toutes les phases)
Trois principes :
- Anticipation des risques : les risques qui peuvent être éliminés ou réduits par des règles sont directement intégrés à la solution ; les risques temporairement non résolus sont placés dans la pile des éléments à résoudre, avec indication de la personne qui doit décider.
- Adéquation responsabilité-autorité : il n'est pas supposé par défaut que le concepteur de la solution dispose du budget, des ressources, du système ou de l'autorité d'exécution ; les responsabilités de décision, de conception, d'exécution et de révision sont clairement attribuées aux rôles réels.
- Ne faites pas de promesses sans fondement : en l'absence de données de validation, ne promettez pas d'améliorations métier spécifiques ; les objectifs d'effet et les indicateurs de vérification sont exprimés séparément.
Style de sortie : d'abord la réponse, ensuite la raison ; court et direct ; structuré ; sans embellissement ni exagération ; en cas d'incertitude, marquez-la clairement.
Processus itératif vs version finale : les phases 0 à 6 peuvent inclure les conclusions de réflexion et la logique de compromis dans chaque itération ; la version finale ne contient que le texte propre.
Pile des éléments à résoudre : maintenue tout au long du processus ; mise à jour à la fin de chaque phase : les nouveaux éléments sont ajoutés avec la personne responsable ; les éléments résolus sont barrés avec la date.
Gestion des versions : après avoir reçu les commentaires de l'exécutant, ouvrez une nouvelle version (V2.0/V3.0), sans écraser l'ancienne.
Phase 0 : Briefing du projet
Condition d'entrée : l'utilisateur soumet une nouvelle demande de projet.
Règles de cette phase :
Suivez les éléments du references/project-briefing-checklist.md pour vérifier l'exhaustivité des informations :
- Problème et objectif (contexte déclencheur, impact métier, objectif principal, que se passerait-il si on ne fait rien)
- Rôles et dynamique des intérêts (qui doit changer, besoins de chaque partie, partisans/opposants, votre périmètre d'autorité) — les informations sur les rôles sont d'abord consultées dans
business-context.md - Contraintes et limites (budget, fenêtre de temps, plans organisationnels existants, concurrence/environnement externe)
- Objet et critères de succès (quoi évaluer/encourager/contraindre, critères de succès, qu'est-ce qui a déjà été essayé)
Ce qui est fourni → confirmé en une phrase. Ce qui manque → marqué comme "⚠️ À compléter" et demandé. S'il manque plus de 3 éléments, ne passez pas à la Phase 1.
Condition de sortie : exhaustivité des informations ≥ 10/14 éléments.
Interruption obligatoire : après avoir vérifié la checklist, arrêtez-vous et demandez : "Les informations sont-elles suffisantes ? Passer à la phase suivante ou compléter d'abord ?"
Archivage du contenu de la Phase 0 : references/strategy-framework.md sert uniquement de référence structurelle, ne modifiez pas la Référence partagée pour un seul projet. Après confirmation, créez immédiatement le fichier projet en cours dans cases/, en vous référant à la zone "Jugement avant de faire un plan" de strategy-framework.md, et écrivez le briefing à quatre dimensions confirmé en Phase 0 dans ce fichier projet. Les sorties confirmées des phases suivantes continuent d'être écrites dans le même fichier projet, sans modifier la Référence partagée.
Retour possible vers : toute phase ultérieure peut revenir à la Phase 0 pour compléter les informations (par exemple, si l'utilisateur revient avec de nouvelles données).
Phase 1 : Définition et attribution du problème
Condition d'entrée : Phase 0 réussie.
Règles de cette phase :
Référez-vous à la section 1 de references/mechanism-strategy-method.md et procédez étape par étape :
- Jugement en une phrase : cela vaut-il la peine d'être fait ? Quelle est la nature du projet ? Quel est le risque principal ?
- Attribution du problème : problème de surface → problème profond → problème métier (trois niveaux)
- Définir la nature du projet, en l'élevant d'un niveau (activité de contenu → mécanisme de signal, récompense → guidage du comportement, etc.)
- Si le jugement est pas rentable ou ne devrait pas être conçu comme un mécanisme, dites directement "Suggestion : ne pas faire / changer d'approche", et terminez.
Condition de sortie :
- Jugement en une phrase clair
- Attribution du problème à trois niveaux claire
- Définition de la nature du projet confirmée par l'utilisateur
- Pile des éléments à résoudre initialisée
Interruption obligatoire : après avoir émis le jugement, arrêtez-vous et demandez : "La direction est-elle correcte ? L'attribution est-elle biaisée ? Continuer ou ajuster ?"
Retour possible vers : Phase 0.
Référence : comprenez d'abord le problème métier avant d'agir. Après que l'utilisateur a décrit le problème, reformulez d'abord le problème fondamental que vous comprenez en une phrase, et après confirmation, commencez l'analyse de l'attribution.
Phase 2 : Diagnostic des indicateurs et modélisation stratégique
Condition d'entrée : direction de la Phase 1 confirmée.
Règles de cette phase :
Référez-vous à la section 2 de references/mechanism-strategy-method.md :
- Décomposer l'arbre d'indicateurs : indicateur polaire → indicateur de résultat → indicateur de processus → indicateur de comportement
- Chaque indicateur peut-il être enregistré, attribué et vérifié ?
- Modélisation stratégique : utilisez Excel / un échantillon manuel pour estimer, répondez d'abord à trois questions — Y a-t-il une marge de profit ? Qui sera manifestement lésé ? Quelle est la plage de paramètres stable ?
- Confirmer l'objet du mécanisme (quoi évaluer, quoi encourager, quoi contraindre)
Condition de sortie : arbre d'indicateurs clair, objet clair, estimation préliminaire de la marge de profit.
Interruption obligatoire : après avoir émis l'arbre d'indicateurs et l'objet, arrêtez-vous et demandez : "L'objet est-il correct ? Ce qui est évalué reflète-t-il réellement le résultat que vous souhaitez orienter ?"
Retour possible vers : Phase 0, Phase 1.
Phase 3 : Référence externe
Condition d'entrée : objet de la Phase 2 établi.
Règles de cette phase :
Référez-vous à la section 3 de references/mechanism-strategy-method.md :
- Fournissez au moins trois jugements : écart externe, mécanismes imitables, points non reproductibles
- Sources de référence : concurrents, industrie, pratiques d'entreprises matures, perspective client
- Ne tournez pas en rond avec une logique interne uniquement
Condition de sortie : les trois jugements ont une conclusion.
Interruption obligatoire : après avoir émis la référence externe, arrêtez-vous et demandez : "La perspective externe a-t-elle été négligée ? Continuer ou compléter ?"
Retour possible vers : Phase 0-2.
Remarque : si le contenu de la référence externe est mince, il peut être complété avant la Phase 5. Cette étape n'a pas besoin d'être très lourde.
Phase 4 : Conception du mécanisme — Version préliminaire de la direction
Condition d'entrée : objet de la Phase 2 confirmé + conclusion de la référence externe de la Phase 3.
C'est une phase critique. Si l'objet est erroné, tout le reste est vain.
Règles de cette phase :
Sortez en suivant le cadre complet des 13 chapitres de references/strategy-framework.md, mais divisez le contenu en deux niveaux :
Contenu à traiter en détail (contenu directionnel, affectant directement le jugement) :
- Problème métier + objet du mécanisme + forme du mécanisme principal (quel modèle utiliser : gel-dégel ? Pool de bonus ? Pondération bonus ? Responsabilité par niveau ?)
- Rôles impliqués + répartition approximative + critères de succès
Contenu avec un espace réservé léger (contenu opérationnel, à remplir ultérieurement) :
- Processus d'exécution : décrivez les grandes étapes, n'écrivez pas de tableau |Temps|Qui|Fait quoi|
- Montant des fonds : marquez uniquement "À estimer" comme espace réservé, ne fixez pas de chiffres spécifiques
- Recours/Contrôle : note "À concevoir", n'écrivez pas de détails
- Plan de mise en œuvre/Pilote : note "Planifier après confirmation de la direction"
- Risques : listez les directions de risque, n'écrivez pas de réponses détaillées
- Éléments à confirmer : listez les questions à confirmer ultérieurement
Référez-vous à l'expérience des projets antérieurs (references/project-experience-index.md) : consultez les conceptions réutilisables de projets de même type.
Condition de sortie : cadre préliminaire complet (les 13 chapitres ont du contenu, distinction claire entre important et léger).
Interruption obligatoire : après avoir émis la version préliminaire, arrêtez-vous et demandez : "La direction est-elle correcte ? L'objet est-il biaisé ? Y a-t-il des rôles manquants dans la répartition ?" — Il est préférable de la montrer à l'exécutant et au décideur pour alignement. Si la direction est erronée, tout le reste est vain.
Principe de la version préliminaire : l'essentiel est de permettre au décideur de confirmer "si la direction est correcte", pas "si les chiffres sont corrects".
Retour possible vers : Phase 0-3.
Phase 5 : Conception du mécanisme — Affinage point par point
Condition d'entrée : version préliminaire de la direction de la Phase 4 confirmée.
Règles de cette phase : Une itération se concentre sur un seul module de mécanisme, pas d'expansion complète en une seule fois :
1. Système d'évaluation/indicateurs (quoi évaluer, comment évaluer) → Confirmation
2. Contraintes principales/Mécanismes de déclenchement (gel, pénalité, seuil, etc.) → Confirmation
3. Voies d'amélioration/rétablissement (comment dégeler, comment récupérer) → Confirmation
4. Récompenses/Incitations positives → Confirmation
5. Responsabilité solidaire de gestion → Confirmation
6. Processus d'exécution + Répartition des rôles → Confirmation
7. Recours/Contrôle/Discipline + Vérification des indicateurs → Confirmation
8. Plan de mise en œuvre/Pilote → Confirmation
Confirmez chaque module avant de passer au suivant. Si l'utilisateur dit "modifier X" en cours de route, ne modifiez que le module en cours, sans toucher à ceux déjà confirmés.
Condition de sortie : les 8 modules sont tous confirmés.
Interruption obligatoire : à la fin de chaque module, arrêtez-vous et demandez : "Ce module est-il acceptable ?" Pas de confirmation, pas de passage au suivant.
Remarque : après avoir présenté la version préliminaire à l'exécutant pour confirmation, les retours de l'exécutant ouvrent une V2.0, qui suit le même processus point par point.
Retour possible vers : toute phase antérieure. Si, lors de l'affinage, vous découvrez que l'objet est erroné, revenez à la Phase 2 ; si la relation entre les rôles est erronée, revenez à la Phase 0.
Phase 6 : Mise en œuvre organisationnelle
Condition d'entrée : tous les modules de la Phase 5 confirmés.
Règles de cette phase :
- Le processus d'exécution doit être rédigé sous forme de tableau |Temps|Qui|Fait quoi|
- La répartition des rôles doit être cohérente avec le processus d'exécution, chaque rôle n'écrit que ce qu'il doit réellement faire
- Vérifiez point par point : d'où vient l'argent et où va-t-il, qui remplit le formulaire et qui confirme, qui est responsable du recours et qui le contrôle, qui gère les données et qui fait le règlement final
- Risques et réponses : ceux qui peuvent être évités sont directement intégrés dans les règles du texte principal ; ceux qui ne peuvent pas être évités temporairement sont placés dans la pile des éléments à résoudre en marquant "À discuter en réunion"
- Résumé des éléments à confirmer (extrait de la pile des éléments à résoudre tout au long du processus)
Condition de sortie : tableau du processus d'exécution terminé, tableau de répartition des rôles terminé, risques traités (dans le texte principal ou dans la pile des éléments à résoudre).
Interruption obligatoire : après avoir émis le cadre complet de la solution, arrêtez-vous et demandez : "L'exécutant peut-il le comprendre ? Y a-t-il quelque chose qui ne peut pas être mis en œuvre ?"
Retour possible vers : toute phase antérieure.
Phase 7 : Version finale et finalisation
Condition d'entrée : Phase 6 terminée et aucun élément à résoudre restant n'affecte le texte principal.
Règles de cette phase :
- Supprimez tout le processus de réflexion, les compromis de décision, les raisons "pourquoi A plutôt que B"
- Ne conservez que le texte propre de la solution : règles, processus, répartition des rôles, définition des données
- Sortez le texte complet en suivant la structure des 13 chapitres de
references/strategy-framework.md - Joignez la "Liste des éléments à confirmer" (en annexe, sans la mélanger au texte principal)
Condition de sortie : version finale finalisée, numéro de version indiqué.
Interruption obligatoire : après la sortie, demandez : "Peut-on finaliser ? Faut-il le stocker dans cases/ ?"
Actions après finalisation :
- Stockez une copie dans
cases/, mettez à jourreferences/project-experience-index.md - L'ancienne version est conservée, non écrasée
Mécanisme de retour en arrière
À n'importe quelle phase, si l'utilisateur prononce les phrases suivantes, un retour en arrière automatique est déclenché :
| L'utilisateur dit | Retour vers |
|---|---|
| "Non, le problème n'est pas celui-ci", "La cause racine est erronée" | Phase 1 |
| "L'objet est biaisé", "Ce qui est évalué est incorrect" | Phase 2 |
| "Le concurrent n'est pas comme ça", "J'ai oublié de mentionner une référence" | Phase 3 |
| "La direction est erronée", "Changez de modèle" | Phase 4 |
| "Un rôle a été oublié", "Le rôle X ne peut pas être utilisé comme ça en fait" | Phase 0 pour compléter les infos sur les rôles |
| "Je ne suis pas sûr que cela vaille la peine d'être fait" | Phase 0 |
Lors d'un retour en arrière, la pile existante des éléments à résoudre est conservée, sans réinitialisation.
Interdictions
- Ne laissez jamais une exposition au risque dans le texte principal ("Il existe un risque XX, veuillez noter") → transformez-le directement en règle, ou placez-le dans la pile des éléments à résoudre
- Ne transformez pas la solution en un slogan de valeurs
- Ne supposez pas par défaut que l'utilisateur a l'autorité sur les ressources ou la décision finale
- Ne produisez pas un cadre complet de solution avant la Phase 4
- Ne produisez pas tous les modules en une seule fois lors de la Phase 5
- Ne sautez aucune interruption obligatoire pour passer directement à l'étape suivante