ouvrir guide/chapitre-08 --roles
Chapitre 8 · Acte III · Une équipe entière dans votre terminal
Tous
les rôles
12 min · espace pour avancer, flèches pour revenir
Pourquoi une équipe compte des rôles
Fusionnez ces regards dans une seule tête, et vous obtenez l'angle mort.
Ce que personne n'a vu parce que tout le monde regardait la même chose. Dans les projets générés par IA que je reprends, la constante est frappante : un seul rôle a été joué, le développeur.
Le testeur ne regarde pas ce que le code fait : il cherche ce qu'il ne fait pas. L'expert sécurité ne demande pas si ça marche, mais comment en abuser.
Le fil rouge du chapitre : chez Talia, un patient doit pouvoir annuler sa réservation. Sept casquettes, de l'idée à la prod.
La chaîne, poste par poste
- 01 · POCadre le besoin et ses critères d’acceptation. Il interviewe, vous répondez.
- 02 · ArchitecteNe demande pas « comment faire » mais « entre quoi et quoi choisit-on ». Livrable : un ADR.
- 03 · DevReçoit la spec et l’ADR. Une étape sur sept, remise à sa juste place.
- 04 · TesteurN’a pas écrit le code. Cherche ce qui casse : cas limites, entrées invalides, utilisateur pressé.
- 05 · SécuritéPosture d’attaquant : injections, secrets, permissions, données personnelles, dépendances.
- 06 · RéviseurCherche la dette, pas les bugs : quelqu’un comprendra-t-il ça dans six mois ?
- 07 · LivraisonCommit qui dit pourquoi, PR qui donne le contexte, checklist déroulée.
Casquette 1 · cadrer avant de vouloir
❯ claude ❯ Joue le rôle d'un product owner. Interviewe-moi sur ❯ l'annulation de réservation, puis écris la user story ❯ et ses critères d'acceptation dans specs/annulation.md. · Claude prépare ses questions... Trois questions avant d'écrire quoi que ce soit : 1. Que se passe-t-il à moins de 24 h du rendez-vous ? 2. Talia est-elle prévenue ? Par quel canal ? 3. Un créneau annulé redevient-il réservable aussitôt ?
Chacune de ces questions est un bug évité. Et les critères d'acceptation serviront deux fois : le dev en fera des tests, la livraison en fera une checklist.
Le biais de l'auteur
La même session
« Teste ton code »
- Elle sait ce que le code est censé faire
- Elle vérifie ce qu’elle a compris du besoin
- Donc la compréhension qui a produit les bugs
- 6 tests verts, et deux anomalies dessous
Une session neuve
Il n’a pas écrit ce code
- Il découvre, il n’est d’accord avec personne
- Consigne adversariale : trouve ce qui casse
- Quelques secondes de mise en place
- Le seul service qu’aucun prompt ne rend
Le biais de l'auteur ne se corrige pas avec un meilleur prompt. Il se corrige avec un contexte vierge.
Casquette 4 · le regard qui n'a rien écrit
❯ claude ❯ Session neuve : tu n'as pas écrit ce code. Joue le ❯ testeur adversarial sur l'annulation : cherche ce qui ❯ casse. Cas limites, entrées invalides, utilisateur pressé. · Claude attaque la fonctionnalité... Trouvé : annuler 23 h 59 avant la séance passe encore la règle compare des heures entières, pas des minutes. Trouvé : double clic sur « Annuler », deux requêtes. Rapport : 2 anomalies, 3 tests manquants proposés.
Deux vraies anomalies, qu'aucun des six tests verts ne couvrait. Le dev et ses tests étaient d'accord entre eux : c'est exactement le problème.
À vous
Le code marche, six tests sont verts, le testeur a soldé ses anomalies. Peut-on livrer ?
Choisissez : la scène vous répond.
Casquette 5 · dites-lui qu'il est votre RSSI
❯ claude ❯ Session dédiée. Tu es mon RSSI. Audit adversarial ❯ avant mise en prod : injections, secrets exposés, ❯ permissions, données personnelles, dépendances. · Claude passe en posture d'attaquant... Critique : /annuler?id=812 : l'id suffit pour annuler. N'importe qui peut annuler la séance d'un autre. Moyen : le nom du patient apparaît dans les logs. Rapport écrit. Rien ne part en prod sans corrections.
Retour au vendredi soir du chapitre 1
La faille était écrite noir sur blanc dès la première page, cochée en vert comme une fierté.
« Annulation en un clic : le patient reçoit /annuler?id=812 ». Le code marchait, tous les tests passaient, et n'importe qui pouvait annuler le rendez-vous de n'importe qui. Personne ne l'a vue, parce que personne ne la cherchait.
Les deux derniers postes
- Le réviseur→cherche la dette : la règle des 24 h vivait en double, serveur et interface. Un jour, quelqu'un aurait modifié l'une des deux copies.
- La livraison→commit qui dit pourquoi, PR avec le contexte, checklist déroulée. La PR se relit en cinq minutes.
Le réviseur est le seul rôle qu'il faut savoir brider : à qui l'on demande des défauts en trouvera toujours. Cantonnez-le à la justesse, la lisibilité et la cohérence.
L'objection qui arrive toujours
7sessions, pas un prompt géant
Dans une même session, tout ce qui précède teinte ce qui suit. Le Claude qui vient d'implémenter sait ce que le code est censé faire, et il emporte ce savoir dans le test, dans l'audit, dans la revue.
Bénéfice secondaire : sept contextes courts et ciblés se comportent mieux, et coûtent moins cher, qu'un contexte fleuve.
La chaîne n'est pas fermée
Une posture explicite, une mission précise, un livrable écrit : « joue X, cherche Y, écris ton rapport dans Z » suffit à créer un rôle.
- L'utilisateur presséIl annule depuis son téléphone, dans le métro, avec trente secondes devant lui. Faites-le raconter son parcours et noter où il abandonnerait.
- Le benchmarkAvant même l'architecte : quelles options existent, selon quels critères, avec quel tableau comparatif. Vous arbitrez sur pièces au lieu de suivre la première idée.
Fin du chapitre 8
Vous savez faire jouer tous les rôles à la main. La suite ouvre la boîte à outils qui les équipe et les automatise : skills, subagents, MCP, hooks, et la grille qui permet de choisir sans se tromper.
La version article garde tout : la FAQ, les détails, les liens. Cette traversée en est la bande-annonce habitée.