Le chapitre 1 l'annonçait : « Claude est un développeur » est une idée très en dessous de la réalité. Une équipe qui livre un produit compte un product owner qui cadre le besoin, un architecte qui tranche, un développeur qui implémente, un testeur qui cherche ce qui casse, un expert sécurité qui pense en attaquant, un réviseur qui relit, et quelqu'un qui livre proprement. Sept regards sur le même code.
Claude peut tenir chacun de ces postes, et les tenir bien, à une condition que ce chapitre démontre pas à pas : les faire jouer séparément. Pour le prouver, on reprend le cabinet de Talia, la kiné du chapitre 1, et on mène une fonctionnalité entière, l'annulation de réservation, de l'idée à la mise en production. Sept casquettes, sept courtes démos, une méthode que vous pourrez rejouer dès ce soir.
Chaque rôle est un regard
Une équipe produit ne compte pas des rôles pour des raisons d'organigramme. Elle en compte parce que chaque rôle regarde le projet autrement. Le PO voit un besoin et des critères de réussite, pas des lignes de code. L'architecte voit des compromis. Le testeur ne regarde pas ce que le code fait : il cherche ce que le code ne fait pas. L'expert sécurité ne se demande pas si ça marche, il se demande comment en abuser.
Fusionnez ces regards dans une seule tête, humaine ou artificielle, et vous obtenez l'angle mort : ce que personne n'a vu parce que tout le monde regardait la même chose.
En quinze ans de développement mobile, chez Mappy, Accor ou au Programme alimentaire mondial, les bugs les plus graves que j'ai vu attraper avant la production l'ont presque toujours été par quelqu'un qui n'avait pas écrit le code. Et dans les projets générés par IA que je reprends aujourd'hui, ceux qui « marchent globalement », la constante est frappante : un seul rôle a été joué, le développeur. Personne n'a cadré le besoin, personne n'a attaqué le code, personne n'a relu.
La solution ne demande ni recrutement ni outil supplémentaire : le même agent, des casquettes explicites, et surtout des sessions distinctes. Vous verrez en fin de chapitre pourquoi ce dernier point n'est pas un détail. Place au fil rouge : le cabinet de Talia doit permettre à un patient d'annuler sa réservation. Déroulons la chaîne.
- Le product ownerTransforme l'idée floue en spec avec critères d'acceptation.
- L'architecteCompare des options et fige la décision dans un ADR.
- Le devImplémente dans le cadre reçu, un test par critère.
- Le testeurSession neuve : cherche ce qui casse, pas ce qui marche.
- L'expert sécuritéAttaque le code en RSSI avant toute mise en prod.
- Le réviseurRelit à froid et traque la dette.
- La livraisonCommit propre, PR documentée, checklist déroulée.
Le PO : cadrer avant de vouloir
Le réflexe naïf consiste à écrire « ajoute l'annulation de réservation » et à laisser Claude décider du reste. Vous connaissez la suite depuis le chapitre 1. Le geste professionnel inverse la charge : avant d'exiger quoi que ce soit, on demande à Claude de jouer le product owner et de nous interviewer. C'est l'interview inversée du chapitre 3, appliquée à une fonctionnalité : Claude pose les questions qu'un PO poserait, vous répondez, il rédige la user story et ses critères d'acceptation.
❯ 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é. Répondez-y, et la spec qui en sort n'est pas un document de plus : les critères d'acceptation serviront deux fois, le dev en fera des tests (chapitre 6) et la livraison en fera une checklist. Le besoin est écrit, versionné, et survivra à la session qui l'a produit.
L'architecte : des options, pas une évidence
Session suivante, casquette suivante. L'architecte ne demande pas « comment faire », il demande « entre quoi et quoi choisit-on ». La nuance est décisive : une IA à qui l'on demande une solution en produit une, immédiate et plausible. Une IA à qui l'on demande des options, leurs compromis et une décision argumentée produit une réflexion. Le livrable a un nom chez les architectes : l'ADR, pour architecture decision record. Une page qui dit ce qu'on a décidé, ce qu'on a écarté, et pourquoi.
❯ claude ❯ Lis specs/annulation.md. Joue l'architecte : propose ❯ 2 ou 3 options techniques, leurs compromis, et rédige ❯ ta décision argumentée dans docs/adr/002-annulation.md. · Claude compare les options... Option A : suppression du créneau. Simple, mais on perd l'historique (impossible de suivre les annulations). Option B : statut « annulée » + horodatage. Retenue. ADR écrit : décision, raisons, conséquences.
Notez que l'option A était le premier réflexe, celui qu'un « vas-y code » aurait produit sans bruit. Elle était fausse pour ce cabinet : sans historique, impossible de repérer le patient qui annule chaque semaine. L'ADR rejoint le dossier de brief du chapitre 3 : dans six mois, une session neuve saura pourquoi ce choix a été fait, et ne le défera pas par inadvertance.
Le dev : implémenter dans le cadre
Voici la casquette que tout le monde connaît, remise à sa juste place : une étape sur sept. Le dev ne décide ni du besoin ni de la structure, il reçoit la spec du PO et l'ADR de l'architecte. C'est le workflow du chapitre 5, nourri par des documents au lieu d'un prompt improvisé, et la règle du chapitre 6 s'applique sans négociation : chaque critère d'acceptation a son test.
❯ claude ❯ Lis specs/annulation.md et docs/adr/002-annulation.md. ❯ Implémente l'annulation. La règle des 24 h a son test, ❯ comme chaque critère d'acceptation de la spec. · Claude implémente... annulation.ts écrit, règle des 24 h côté serveur. 6 tests ajoutés, un par critère d'acceptation. ✓ 6/6 verts. La casquette de dev s'arrête ici.
Remarquez ce que cette session n'a pas fait : juger son propre travail. Le « 6/6 verts » prouve que le code fait ce que le dev a compris du besoin. Reste à découvrir ce qu'il n'a pas compris, et pour cela il faut d'autres yeux.
Le testeur : le regard qui n'a rien écrit
Le testeur n'est pas le dev, et ce n'est pas une affaire de compétence : c'est une affaire de mémoire. Demandez « teste ton code » dans la session qui vient de l'écrire, et vous obtenez des tests qui vérifient ce que la session a compris du besoin, c'est-à-dire la même compréhension que celle qui a produit les bugs. Les développeurs humains connaissent ce phénomène : le biais de l'auteur. Il vaut, trait pour trait, pour l'IA. On ouvre donc une session neuve, où Claude découvre le code sans l'avoir écrit, avec une consigne adversariale : trouve ce qui casse.
❯ 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. Ni le dev ni ses tests n'étaient mauvais : ils étaient d'accord entre eux, ce qui est exactement le problème. Le testeur, lui, n'était d'accord avec personne.
L'expert sécurité : demandez-lui d'être votre RSSI
Le cabinet de Talia manipule des données de santé : ce rôle n'est pas une option. Session dédiée, posture d'attaquant, et une liste de chasse précise : injections, secrets exposés en clair, permissions trop larges, données personnelles qui fuient, dépendances vulnérables. La règle est non négociable : rien ne part en production sans son rapport. Et bonne nouvelle : Claude sait jouer ce rôle à fond. Dites-lui qu'il est votre RSSI, votre responsable de la sécurité des systèmes d'information, et exigez le rapport qu'un RSSI produirait.
❯ 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.
La faille critique mérite qu'on s'y arrête : le code marchait, tous les tests passaient, et n'importe qui pouvait annuler le rendez-vous de n'importe qui. Et si vous lisez ce guide depuis le début, retournez un instant à la toute première démo du chapitre 1 : dans la sortie triomphante du vendredi soir, il y avait cette ligne, cochée en vert comme une fierté : « Annulation en un clic : le patient reçoit /annuler?id=812 ».
La faille était écrite noir sur blanc dès la première page.
Personne ne l'a vue, parce que personne ne la cherchait : c'est très exactement le métier de ce rôle-ci. C'est aussi le genre de trou que ni le dev ni le testeur fonctionnel n'avaient de raison de chercher, et l'un des premiers points que je vérifie quand j'audite un projet repris.
Le chapitre 11 montrera comment brancher cette revue en automatique sur chaque PR ; en attendant, jouez-la à la main, systématiquement.
Le réviseur : la relecture à froid
Le testeur cherchait des bugs, le réviseur cherche de la dette. Sa question n'est pas « est-ce que ça marche » mais « est-ce que quelqu'un comprendra ça dans six mois » : lisibilité, cohérence avec le reste du code, complexité inutile. Rappelez-vous le chapitre 2 : la prochaine session n'aura aucun souvenir de celle-ci. Le réviseur travaille pour elle.
❯ claude ❯ Nouvelle session. Joue le réviseur : lisibilité, ❯ dette, cohérence avec le reste du code. Sois exigeant. · Claude relit à froid... La règle des 24 h vit en double (serveur et UI) : à extraire dans une fonction partagée unique. Nommage : cancelBooking ici, annulerRdv ailleurs. Approuvé après ces deux corrections. Dette évitée.
Deux remarques modestes en apparence. Mais la règle dupliquée est la graine d'un bug classique : un jour, quelqu'un modifie l'une des deux copies. Le réviseur est le rôle le plus discret de la chaîne et celui qui rapporte le plus sur la durée : la dette qu'il évite ne se voit jamais, c'est le but.
Deux remarques, et pas quinze : c'est la marque d'un bon rapport de revue, et le seul rôle de la chaîne qu'il faut savoir brider. Un réviseur à qui l'on demande de trouver des défauts en trouvera toujours, même sur du bon code, puisque c'est la mission qu'on lui a donnée. Cadrez-le : ne signale que ce qui nuit à la justesse, à la lisibilité ou à la cohérence, le reste est facultatif. Sans cette borne, vous suivrez ses conseils en empilant des abstractions dont personne n'avait besoin.
La livraison : finir proprement
Le rôle que tout le monde saute, parce que « le code est fini ». Un commit propre qui dit pourquoi, une PR qui donne le contexte, une checklist qui reprend ce que la chaîne a produit : les critères du PO, la décision de l'architecte, les verdicts du testeur, du RSSI et du réviseur.
❯ claude ❯ Dernière casquette : la livraison. Commit propre, ❯ PR décrite, checklist de mise en prod déroulée. · Claude prépare la livraison... Commit : « annulation de réservation, règle des 24 h ». PR : contexte, lien vers l'ADR, tests, captures. Checklist : tests verts ✓ audit sécurité soldé ✓ migration réversible ✓. Prête pour l'humain.
La PR se relit en cinq minutes, parce que chaque rôle a laissé une trace écrite au fil de l'eau : la spec, l'ADR, les rapports. Rien à reconstituer de mémoire. C'est ce que « livrer proprement » veut dire : la personne qui relit, vous compris dans six mois, reçoit le raisonnement avec le code.
Pourquoi pas un seul gros prompt
L'objection arrive toujours : pourquoi sept sessions au lieu d'un prompt géant, « implémente, teste, audite et livre » ? La réponse tient dans le chapitre 2 : 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 emportera ce savoir dans le test, dans l'audit, dans la revue.
Le contexte du dev contamine le regard du testeur.
Séparer les sessions est le seul moyen de donner à chaque rôle ce qui fait sa valeur : un regard neuf. Bénéfice secondaire appréciable : sept contextes courts et ciblés se comportent mieux, et coûtent moins cher, qu'un contexte fleuve (chapitre 10).
Et si relancer des sessions vous paraît laborieux, le chapitre 9 vous montrera comment un subagent isole un contexte sans même quitter votre terminal : la virginité du regard sans le changement de fenêtre.
Deux casquettes bonus : l'utilisateur pressé et le benchmark
La chaîne des sept rôles n'est pas fermée, elle s'étend à volonté. Deux casquettes supplémentaires rendent d'immenses services.
Le test utilisateur simulé, d'abord : demandez à Claude de jouer l'utilisateur pressé, celui qui annule sa séance depuis son téléphone, dans le métro, avec trente secondes devant lui, et de raconter son parcours pas à pas en notant l'endroit exact où il abandonnerait. Le parcours qui rage-quit se lit dans son récit, avant qu'un vrai patient ne le vive.
Le benchmark, ensuite : avant même l'architecte, faites jouer à Claude le comparatif de solutions. Quelles options existent pour envoyer les rappels de rendez-vous, selon quels critères, avec quel tableau comparatif et quelle recommandation argumentée. Vous arbitrez sur pièces au lieu de suivre la première idée.
Questions fréquentes sur les rôles de Claude
Claude peut-il remplacer un product owner ?
Il peut en jouer le geste central : transformer une idée floue en user story assortie de critères d'acceptation, en posant les questions qu'un PO poserait. C'est l'interview inversée : vous détenez la connaissance du besoin, Claude la structure et la met par écrit. Ce qu'il ne remplace pas : la vision produit, la connaissance de vos utilisateurs réels et l'arbitrage des priorités, qui restent votre travail. Utilisé ainsi, il élimine la première cause de bug : un besoin jamais formulé.
Comment faire réviser son code par l'IA ?
Dans une session séparée de celle qui a écrit le code : c'est la condition d'un regard neuf. Donnez une casquette explicite, le réviseur, avec un périmètre clair : lisibilité, dette, cohérence avec le reste du code. Puis exigez un livrable : une liste de remarques classées et un verdict. Gardez la revue distincte du test : le réviseur cherche la dette, le testeur cherche les bugs, et mélanger les deux missions dans une même session affaiblit les deux regards.
Qu'est-ce qu'un agent testeur ?
Une session de Claude dédiée à chercher ce qui casse, sans avoir écrit le code qu'elle teste. Sa posture est adversariale : cas limites, entrées invalides, parcours utilisateur simulés comme l'utilisateur pressé ou le double clic rageur. La séparation d'avec la session de développement est essentielle : elle neutralise le biais de l'auteur, ce réflexe qui pousse à ne vérifier que ce qu'on a compris du besoin. Sa sortie : un rapport d'anomalies et la liste des tests manquants.
Comment faire un audit de sécurité avec Claude ?
Ouvrez une session dédiée et donnez à Claude la posture d'un attaquant : dites-lui qu'il est votre RSSI. Faites-le chercher les classiques : injections, secrets exposés en clair, permissions trop larges, données personnelles mal protégées, dépendances vulnérables. Exigez un rapport écrit, avec une gravité et une correction proposée pour chaque point, et tenez la règle : rien ne part en production sans ce rapport. Claude tient ce rôle remarquablement bien, et le chapitre 11 montre comment le brancher en automatique sur chaque pull request.
La suiteVous savez faire jouer tous les rôles à la main. Le chapitre 9 ouvre la boîte à outils qui les équipe et les automatise : skills, subagents, MCP, hooks, et surtout la grille qui permet de choisir la bonne brique sans se tromper.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe