Chapitre 12.1 — Les modèles mentaux du pilote
⏱️ TL;DR — Tout le playbook tient en quelques modèles mentaux. (1) L’agent est un membre d’équipe, pas un distributeur : tu l’encadres, tu ne le télécommandes pas. (2) Ton levier n’est pas « mieux prompter » mais configurer le terrain (mémoire, conventions, hooks, skills). (3) Tu délègues l’exécution, gardes le jugement. (4) Tu cristallises le volatil en persistant. (5) Tu vérifies par l’observation. Intériorise ces cinq idées et le « comment m’y prendre » cesse d’être un mystère : chaque décision en découle.
🎯 Objectifs
- Énoncer les modèles mentaux qui sous-tendent le pilotage.
- Relier chaque partie du playbook à un modèle.
- Diagnostiquer une difficulté par le modèle qu’elle viole.
Les cinq modèles
1. L’agent est un membre d’équipe, pas un distributeur
Un distributeur : tu appuies, ça sort, tu recommences si c’est raté. Un membre d’équipe : tu lui donnes du contexte, des conventions, un objectif, et tu revois son travail. Le second modèle produit un travail cohérent et fiable ; le premier, une suite de sorties déconnectées. Toute ta frustration (« designs incohérents », « conventions non reprises ») vient de traiter un membre d’équipe comme un distributeur.
2. Ton levier, c’est le terrain — pas le prompt
Le débutant croit que la clé est de « mieux prompter ». Le pilote sait que la clé est ce qu’il y a autour de la conversation : le CLAUDE.md (P3), le design system (P4), les hooks (P7), les skills (P9). Un terrain bien configuré rend le bon comportement par défaut — quel que soit le prompt. C’est le déplacement d’énergie central du playbook : de « l’art du prompt » à l’architecture de l’environnement.
3. Délègue l’exécution, garde le jugement
L’agent excelle à exécuter et explorer ; toi, tu décides. Les décisions d’architecture, les compromis, « est-ce le bon problème ? », « ce finding est-il réel ? » — ça reste à toi (P8, P11). Déléguer le jugement, c’est abdiquer le rôle d’architecte. Déléguer l’exécution, c’est l’exercer.
4. Cristallise le volatil en persistant
La conversation disparaît (P1). Ce qui reste, c’est ce que tu écris : code, CLAUDE.md, skills, hooks, ADR, commits. Bien piloter, c’est convertir en permanence des intentions éphémères en artefacts durables — pour que la cohérence et la continuité ne dépendent pas de ta mémoire ni d’une session.
5. Vérifie par l’observation, pas par la confiance
« Ça devrait marcher » n’est pas une preuve (P5, P11). Tu exiges l’observation : tests verts montrés, flux exercé, rendu vu. La confiance se construit sur des filets (hooks, CI, revue), elle ne se décrète pas.
Chaque partie découle d’un modèle
| Modèle | Se concrétise en… |
|---|---|
| Membre d’équipe | cadrage (P2), reprise (P6) |
| Le terrain > le prompt | CLAUDE.md (P3), design (P4), hooks (P7), skills (P9) |
| Délègue l’exécution, garde le jugement | subagents (P8), revue (P11) |
| Cristallise le volatil | mémoire (P3), continuité (P6), commits (P6) |
| Vérifie par l’observation | boucle (P5), qualité (P11) |
Tu ne mémorises pas 60 chapitres : tu intériorises cinq idées, et le reste devient des applications évidentes.
💡 Réflexe d’architecte — Quand tu bloques (« ça déraille, je ne sais pas quoi faire »), remonte au modèle violé : est-ce que je le traite en distributeur (→ donne du contexte) ? est-ce que je mise sur le prompt au lieu du terrain (→ configure) ? est-ce que je délègue une décision (→ reprends-la) ? est-ce que je compte sur le volatil (→ écris-le) ? est-ce que je crois au lieu de vérifier (→ observe) ? Le diagnostic est presque toujours là.
✏️ Exercices
Exercice 1 — Diagnostique par le modèle. Repense à ta dernière session frustrante. Quel(s) modèle(s) violais-tu ? Qu’aurais-tu fait différemment ?
✅ Solution
La plupart des frustrations se rangent sous un ou deux modèles : traiter l’agent en distributeur (pas de contexte/conventions), miser sur le prompt (pas de terrain configuré), ou croire au lieu de vérifier. Nommer le modèle violé donne directement le remède. C’est l’outil de diagnostic le plus rapide du playbook.
Exercice 2 — Le levier terrain. Choisis une chose que tu répètes en prompt à chaque session. Transforme-la en élément de terrain (CLAUDE.md, hook, skill, fichier-modèle). Tu viens d’appliquer le modèle 2.
✅ Solution
Une consigne répétée est un signal de terrain manquant : convention → CLAUDE.md, automatisme → hook, workflow → skill, style → fichier-modèle. Chaque conversion réduit ce que tu dois redire et rend le comportement plus fiable. Répète-le assez et tu ne « promptes » presque plus — tu pilotes un terrain.
🧠 Quiz de révision
1. Distributeur vs membre d’équipe : quelle différence de posture ?
Le distributeur : appuyer, obtenir, recommencer si raté (sorties déconnectées). Le membre d’équipe : donner contexte + conventions + objectif, puis revoir (travail cohérent). L’incohérence vient de traiter l’un comme l’autre.
2. Quel est le vrai levier de productivité, selon le modèle 2 ?
Le terrain (CLAUDE.md, design system, hooks, skills), pas « mieux prompter ». Un terrain bien configuré rend le bon comportement par défaut, quel que soit le prompt.
3. Que délègue-t-on, que garde-t-on ?
On délègue l’exécution et l’exploration ; on garde le jugement (décisions d’archi, compromis, « est-ce le bon problème ? », « ce finding est-il réel ? »). Déléguer le jugement = abdiquer le rôle d’architecte.
4. Que signifie « cristalliser le volatil en persistant » ?
Convertir les intentions éphémères (la conversation) en artefacts durables (code, CLAUDE.md, skills, hooks, ADR, commits), pour que cohérence et continuité ne dépendent ni de ta mémoire ni d’une session.
5. Comment se construit la confiance dans le travail de l’agent ?
Par l’observation (tests montrés, flux exercé, rendu vu) et des filets (hooks, CI, revue) — pas par décret. « Ça devrait marcher » n’est jamais une preuve.
Chapitre suivant : Confiance vs vérification — doser l’un et l’autre selon le risque.