Le développeur 10x ne pense pas 10 fois mieux. Il code 10 fois plus vite. Et l’IA vient d’offrir ce superpouvoir à tout le monde, sans le garde-fou qui allait avec. Donc avant de prompter, confrontez chaque décision significative à l’aide d’un panel de personas. Chacun avec ses préoccupations, ses angles morts, et un mandat pour être en désaccord. On cherche à produire de la friction, car cela améliore la réflexion.
Avant l’IA, l’exécution prenait du temps. Ce temps amenait de la friction : des reviews, des débats, des impasses qui vous forçaient à reconsidérer. On réfléchissait longtemps parce que construire la mauvaise chose coûtait des semaines. Aujourd’hui, on la construit en quelques minutes. Prompt après prompt, on exécute à la vitesse de la pensée jusqu’en production. Plus de friction. Plus de recul. Plus de moment pour vérifier qu’on résout le bon problème.
L’IA amplifie dans la direction qu’on lui donne. Nos prompts sont le reflet de nos angles morts : on ne questionne que ce qu’on sait déjà questionner. Ce qu’on ne pense pas à demander est précisément ce qu’on a besoin d’entendre. Et la profondeur n’y changera rien. Un mauvais chemin se creuse. On dérive au fil des prompts, sans alerte. Une IA ne vous dira jamais que la question est mauvaise ; elle se contentera juste d’y répondre.
Réintroduire la friction
Si la pratique du canard en plastique (rubber duck debugging) ne vous est pas étrangère, commencez par là : forcez la clarté avant l’exécution. Demandez à votre IA de reformuler avant d’agir : <votre requête>, est-ce clair pour toi ? Simple. Pas cher. Rapide.
Mais la clarté seule ne suffit pas à détecter les angles morts. Nos biais vivent dans nos prompts. Pour les révéler, il faut de la confrontation avec des perspectives différentes qui stress-testent la requête. A l’image d’un atelier de design ou de review, on réunit des personnes aux préoccupations différentes ; chacun regarde le même sujet avec un angle qu’aucun autre n’aurait pris seul. De Bono posait déjà ce principe en 1985 avec ses six chapeaux : forcer l’adoption de perspectives multiples pour sortir de la pensée unidirectionnelle. Ce que l’IA change, c’est qu’on peut le pratiquer seul, à la demande, avec des perspectives calibrées sur son propre domaine.
Mise en place du panel
Voici les points essentiels pour constituer sa table de persona:
Définir le nom et l’objectif de la table
Débattre sur un design, review du code, faire un refinement ou confronter une vision. Nommer votre table vous permet de l’invoquer au besoin par un simple <prompt> Qu’en pense <nom de la table> ?. Un simple fichier markdown <nom de la table>.md est suffisant. A l’intérieur, définissez l’objectif de la table et la matière qu’elle va exploiter.
// CORE_TEAM.md
# Core Team Panel for Specy
This document defines a panel which evaluates all changes to the Specy language and to the skills that produce and consume it.
The panel is a prompt construct: a single reviewer role-plays all eight perspectives in sequence, ensuring every change is stress-tested from angles that a single viewpoint would miss.
Ma préférence pour l’invocation est d’utiliser une commande qui reflète la cérémonie ou la tâche à accomplir (/design-review
// .claude/commands/review.md
Review the following proposal using the design panel defined in CORE_TEAM.md at the root of this project.
Read CORE_TEAM.md first to load the panellists and the debate protocol, then apply it to:
$ARGUMENTS
Constituer un panel de préoccupation
Plutôt que de parler en rôle pur, choisissez des préoccupations concrètes. Un provocateur remettra en cause les fondations. Un simplificateur challengera le besoin sous un angle de la facilité d’implémentation. Chaque perspective doit avoir un sens en fonction du périmètre et des angles morts assumés afin de simuler un système de pensée crédible. Sinon, vous allez avoir uniquement des personas qui iront systématiquement dans la même direction. On cherche ici à maximiser la friction pour couvrir un large spectre de perspectives.
Chaque panéliste suit le même format.
### {N} — The {Role Name}
*"{Core conviction tagline}"*
{One-sentence description of the perspective}
**Watches for:** {specific warning signals}
**Blind spot:** {acknowledged bias of this perspective}
Pour une design review, voici un exemple de panel :
// CORE_TEAM.md
## The ten panellists
### 1 — The Simplicity Advocate
*"Extra syntax is acceptable only when it resolves an ambiguity or prevents a modelling error."*
Guards against construct proliferation. Blocks additions expressible with existing constructs.
**Watches for:** redundant keywords, overlapping constructs, grammar surface explosion.
**Blind spot:** may resist additions that improve learnability.
### 2 — The DDD Fidelity Advocate
### 3 — The Domain Readability Advocate
### 4 — The Machine Reasoning Advocate
### 5 — The Cross-File Coherence Advocate
### 6 — The Skill Experience Advocate
### 7 — The Domain Expert
### 8 — The Product Manager
### 9 — The Vision Guardian
### 10 — The Provocateur
Ou pour confronter une vision, la composition est différente :
// VISION_TEAM.md
## The eight panellists
### 1 — The Knowledge Economist
### 2 — The DDD Strategist
### 3 — The Enterprise Archaeologist
### 4 — The Legacy Rewrite Veteran
### 5 — The AI Futurist
### 6 — The Epistemologist
### 7 — The Product Strategist
### 8 — The Provocateur
Définir le protocole de collaboration
C’est le format de restitution de la collaboration. Concrètement, c’est votre interface. Cela dépendra de votre besoin et de vos préférences en fonction du panel.
Exemple de protocole :
- Clarifier votre requête
- Présenter la requête à débattre
- Le tour de table des panélistes
- La confrontation entre panéliste (en limitant les tours, sinon ça ne termine jamais)
- La synthèse du débat
- Le verdict avec le positionnement global de la table
Maintenir son panel
Au fil des débats, le comportement des personas et surtout leur position vous donneront des indices sur leur légitimité dans la table. Un persona toujours aligné n’a que peu d’intérêt. Un persona incapable de s’aligner ajoute du bruit. Portez votre attention sur:
- La matière. Un projet exploratoire n’a pas les mêmes problématiques qu’un projet en production. La matière à exploiter sera différente et n’admet pas le même degré d’exigence. Par exemple la CORE_TEAM n’est pas constituée d’ops ou de testeurs, car le projet est encore exploratoire.
- La priorité. Je constitue la table en fonction de l’objectif du moment. Dans une phase exploratoire, j’explore large et diversifié. Par exemple, un provocateur vous donnera des enseignements structurants et poussera pour des changements radicaux. Pivoter coûte peu à ce stade. Une fois en production, ce coût explose.
- L’équilibre. Toujours avoir des persona plus terre à terre afin d’ancrer les débats. Dans la CORE_TEAM, le persona qui va maintenir et recentrer sur la vision globale sera souvent en opposition avec le provocateur. Le persona de la simplicité sera en opposition avec le dogmatisme de l’évangeliste DDD. L’opposition rend les frictions intéressantes. Et sans frictions, vous en tirerez peu de valeur.
Observez le comportement de vos personas, cela vous donnera des indices sur le moment où le panel doit évoluer.
Optionnel - Un mini système de gouvernance
Tout comme le concept de builder/checker, ce genre de pratique peut évoluer vers un système de gouvernance. Dans la section “Constituer un panel de préoccupation”, les deux panels CORE_TEAM et VISION_TEAM traduisent une séparation entre l’exécution et le pilotage. La VISION_TEAM challenge la direction; la CORE_TEAM challenge l’exécution. Et quand l’exécution doit dériver, elle remonte au panel VISION_TEAM. Pour mettre en place ce système: élaborez votre vision avec le panel dédié dans un markdown, puis mettez un garant sur les panels d’exécution (ou tout autre comme OPS, UX).
Dans l’exemple de la CORE_TEAM
### 7 — The Vision Guardian
*"Every grammar decision either brings Specy closer to being a validation oracle or pushes it back towards documentation that rots. Which is this?"*
Guards the strategic vision from `VISION.md`. Every construct must answer: *Can an AI derive a verifiable proof from this?* Does not debate the vision itself (VISION_TEAM.md's territory) but ensures tactical decisions don't undermine it.
**Watches for:** ...
**Blind spot:** ...
Renvoyez tout écart légitime de vision en invoquant la VISION_TEAM: soumet l'écart à la VISION_TEAM.
Dans une organisation plus large, nous pourrions donc imaginer des panels entretenus et mis à disposition par d’autres services (un “panel-as-a-service”), créant ainsi un catalogue de perspectives partagé à l’échelle de l’organisation. Le panel ne remplace pas les interactions humaines et ne présuppose d’aucune délégation de responsabilité ou de décision. On rend juste accessible un premier niveau de confrontation.
Ce que ça change
Le propre d’un outil, c’est qu’il amplifie des capacités humaines. On positionne trop souvent l’IA comme un remplaçant. De la même manière que le GPS nous prive peu à peu de notre capacité à nous orienter, l’IA ne devrait pas nous atrophier de notre capacité à raisonner (cf Avoiding skill atrophy in the age of AI).
Cette pratique m’a poussé à rejeter beaucoup de prompts. Parfois par manque de clarté, ou lorsque j’allais trop vite et trop loin. J’ai pu améliorer mes prompts et, de facto, maîtriser l’exécution qui en découle. J’avais donc peu de surprise à l’arrivée. Et à l’ère du vibe-coding, ce n’est pas négligeable. Mais le gain le plus marquant selon moi, c’est la prise de décision en toute conscience des trade-offs.
Cette pratique change la posture vis à vis de l’IA : passer de “générer” à “confronter”. Elle force un challenge permanent et élargit le champ de vision. Comme l’IA, nous faisons preuve d’irrégularité. Et maintenir le même niveau d’exigence, en tout temps, nous est quasiment impossible. Le panel est le reflet de nos perspectives. On se sert uniquement de l’IA pour rendre ces perspectives constantes, comme un guardrail sur nos biais.
Ce qui aurait demandé une structure et des personnes disponibles, l’IA le rend plus accessible, sans toutefois le remplacer. La friction est devenue optionnelle. C’est précisément pour cela qu’il faut la choisir.
Panel creation prompt
# Design Review Panel
## Purpose
This panel evaluates changes to [YOUR SYSTEM/LANGUAGE/PRODUCT]. It is a prompt construct: a single reviewer role-plays all perspectives in sequence, stress-testing every proposal from angles a single
viewpoint would miss.
## Panellists
Define 5-8 panellists. Each follows this template:
### N — The [Concern] Advocate
*"One-sentence principle that guides this panellist's judgement."*
[What they guard. What they block. 1-2 sentences.]
**Watches for:** [3-4 specific anti-patterns]
**Blind spot:** [The legitimate concern they tend to dismiss]
## Debate protocol
Every debate follows six stages. All panellists must speak on every item.
### Stage 1 — Clarify
The proposer states: **What** changes, **Why**, **Where** (file/line refs), **Scope** (what is out of scope). Each panellist may ask one clarifying question. Loops until all confirm "clear". The user
must explicitly approve Stage 1 before the debate advances.
### Stage 2 — Present
Concrete diff, before/after examples, impact on existing artefacts (breaking changes, migration).
### Stage 3 — Respond
Each panellist states **support**, **concern**, or **block** in 1-2 sentences with a concrete reason.
### Stage 4 — Rebut
The proposer addresses each concern. One round only.
### Stage 5 — Synthesise
Neutral summary: points of agreement, remaining disagreements as specific questions, conditions under which concerns would be withdrawn.
### Stage 6 — Verdict
| Verdict | Meaning |
|---------|---------|
| **Consensus: adopt** | No substantive objection remains |
| **Consensus: reject** | Problem is real but solution is inadequate. Must state what a better solution needs |
| **Refine** | Has merit but needs specific modifications listed in synthesis |
| **Split** | Disagreement persists. Escalated to decision-maker with both positions recorded |