--- type: "BlogPosting" title: "Naviguer dans le brouillard de la guerre : le skill /wayfinder de Matt Pocock" description: "Le skill /wayfinder de Matt Pocock résout le problème du brouillard de la guerre dans la planification IA : une couche d'orchestration faite de carte, ticket et session qui fusionne les sous-sessions en un spec détaillé." resource: "https://www.contextstudios.ai/fr/blog/naviguer-dans-le-brouillard-de-la-guerre-le-skill-wayfinder-de-matt" language: "fr" tags: ["Agents IA", "Context Engineering", "Outils développeur", "Matt Pocock", "Claude Code"] generated: by: "process:contextstudios-md/1" at: "2026-10-05T07:11:56.927Z" status: "stable" --- # Naviguer dans le brouillard de la guerre : le skill /wayfinder de Matt Pocock Published: 2026-09-14 Tags: Agents IA, Context Engineering, Outils développeur, Matt Pocock, Claude Code ![Naviguer dans le brouillard de la guerre : le skill /wayfinder de Matt Pocock](https://wary-platypus-754.convex.cloud/api/storage/c4f1da15-8e3b-44eb-9208-bc384eb87afd) **L'essentiel :** /wayfinder est un skill de planification pour agents IA qui résout le problème du « brouillard de la guerre » : les projets dont l'état final n'est pas entièrement défini au départ. Au lieu de jongler à la main entre sessions et fenêtres de contexte, une couche d'orchestration prend en charge : elle décompose la planification en sous-sessions avec une carte commune et des types de tickets précis, puis fusionne le tout en un spec détaillé. ## Le problème : la planification comme goulot d'étranglement des agents AFK Matt Pocock, fondateur de [aihero.dev](http://aihero.dev) et opérateur d'un repo GitHub de skills avec plus de 220 000 étoiles, décrit dans un entretien avec Latent Space le goulot typique de son travail : l'exécution tourne presque seule avec des **agents AFK** (Away From Keyboard) — la planification qui précède, non. - La session de planification doit garder un œil constant sur la fenêtre de contexte : combien de tokens consommés, jusqu'où la session est-elle déjà allée ? - Les handoffs entre fils de planification, prototypes et recherche se font à la main et sont source d'erreurs. - Au bout, un spec trop grossier pour qu'un agent « continue simplement ». L'approche de /wayfinder : une couche d'orchestration au-dessus de la planification qui prend cette tenue de comptes en charge. ## Comment fonctionne /wayfinder La mécanique se réduit à trois concepts nommés avec précision — Pocock les appelle des « leading words », car un vocabulaire univoque stabilise le comportement de l'agent : 1. **Carte (Map)** — un document central avec l'aperçu grossier et toutes les décisions prises jusqu'ici. 2. **Ticket** — la tâche concrète d'une sous-session unique. 3. **Session** — le contexte de travail qui reçoit carte et ticket et travaille depuis eux vers une clôture. Chaque sous-session a besoin exactement de deux choses : la compréhension de l'ensemble par la **carte** et sa tâche spécifique en **ticket**. Une session grilling peut ainsi gérer d'autres sessions grilling et fusionner à la fin les résultats dans un niveau de détail qu'un seul contexte ne produirait pas. ### Les quatre types de tickets | Type | Usage | |------|------| | Grilling | Un dialog de planification qui extrait les décisions | | Prototype | Prototype rapide pour vérifier une voie | | Research | Recherche ciblée sur un sous-aspect | | Task | Tout ce que l'humain doit faire et l'agent ne peut pas | Cette taxonomie est délibérément petite. Pocock n'utilise donc pas /wayfinder que pour le logiciel : des cours peuvent être planifiés avec — toute structure de but flou plus décisions partielles est compatible. ## Le concept central : Fog of War Le « brouillard de la guerre » signifie deux choses chez Pocock : l'état d'un projet dont on ne peut pas entièrement définir l'état final au départ — et la limitation des contextes d'agents individuels. /wayfinder réduit les deux pas à pas : chaque session lève un morceau de brouillard, la carte inscrit la clarté, et la génération de tickets suivante s'y appuie. Le gain pratique est un workflow copiable : ``` 1. lancer /wayfinder, nommer le vague objectif de projet 2. la carte émerge : cadre + questions ouvertes 3. externaliser les questions ouvertes en tickets grilling/research/prototype 4. réintégrer les résultats dans la carte 5. transférer le spec fini en tickets task pour agents AFK ``` ## Pourquoi le motif tient Le skill est un cas d'école de l'idée « skills = SOP pour agents » : une démarche documentée, réutilisable, qui remplace la gestion manuelle du contexte. Qui travaille avec Claude Code ou des harnesses similaires peut appliquer les trois briques (carte, ticket, session) directement à ses projets — la taxonomie est neutre vis-à-vis du harness. La leçon la plus importante de l'entretien : des noms précis avant une logique maligne. Qui distingue systématiquement carte, ticket et session obtient moins de dérive dans les longs fils de planification — indépendamment du modèle qui tourne dessous. ## FAQ **Pourquoi /wayfinder si j'ai déjà un workflow spec-first ?** Le workflow spec-first suppose l'état final connu. /wayfinder est exactement pour les cas d'avant : un but vague, plusieurs branches ouvertes, des priorités floues. Les sous-session éclaircissent les branches, et au bout reste le spec détaillé avec lequel le workflow normal continue. **Quelle différence entre carte et ticket ?** La carte est le document transversal : aperçu, contexte, toutes les décisions prises jusqu'ici. Le ticket est la tâche singulière et clôturable d'une session. Cette séparation évite que chaque sous-session doive re-« deviner » toute l'historique. **Pourquoi des types de tickets propres comme Grilling et Prototype sont-ils sensés ?** Parce que chaque type a une fin différente : Grilling finit par une décision, Prototype par une voie vérifiée, Research par une réponse, Task par une coche. L'agent reconnaît au type quelle forme de sortie est demandée — cela réduit les relances et les sorties erronées. **Peut-on reconstruire le principe sans le repo de Pocock ?** Oui, la mécanique est délibérément simple : un document carte, des tickets numérotés, un nommage clair par niveau. Le repo de Pocock sur [github.com/mattpocock/skills](http://github.com/mattpocock/skills) fournit le modèle prêt, mais le modèle derrière (mots directeurs plus flux d'information) se transfère dans tout harness à fichiers texte. **Pour quelles tailles de projet le skill paie-t-il le plus ?** Le plus fort pour les projets moyens à grands avec plusieurs décisions partielles — projets greenfield, formats de cours, refactors lourds en migrations. Pour des specs d'une phrase sans branches ouvertes, l'overhead est inutile ; le chemin direct de spec à task suffit. ## Sources - [The /wayfinder Skill: Navigating the "Fog of War" of Planning — Latent Space](https://www.latent.space/p/wayfinder-skill) - [/wayfinder sur aihero.dev](https://www.aihero.dev/skills-wayfinder) - [AI Skills for Real Engineers — aihero.dev](https://www.aihero.dev/skills) - [mattpocock/skills sur GitHub](https://github.com/mattpocock/skills) - [Matt Pocock sur YouTube](https://www.youtube.com/@mattpocockuk) ## Related - [Developpement d'agents IA](https://www.contextstudios.ai/fr/developpement-agent-ia.md) - [Systemes multi-agents](https://www.contextstudios.ai/fr/systemes-multi-agents.md) - [Developpement IA](https://www.contextstudios.ai/fr/developpement-ia.md) - [Integration LLM](https://www.contextstudios.ai/fr/integration-llm.md)