Les pilotes de ligne n'apprennent pas seulement à voler : ils apprennent, par leur nom, les erreurs qui font tomber les avions. Nommer un piège, c'est le rendre reconnaissable au moment où l'on y glisse, et c'est le rendre partageable : une équipe qui peut dire « on est en pleine session fourre-tout » à la place de « ça part un peu dans tous les sens, non ? » se corrige dix fois plus vite.
Ce dernier chapitre rassemble les huit anti-patterns que je retrouve chez tous ceux que j'accompagne. Chacun a un symptôme, un dégât, un remède, et un chapitre de ce guide qui le traite en profondeur. Puis vous passerez votre propre pratique à la grille : vingt questions, un score, et une lecture honnête de ce qu'il reste à travailler.
Le bestiaire
Huit pièges, et pour chacun le même triptyque : le symptôme, le dégât, le remède.
- 01 · La session fourre-toutUn seul fil de conversation qui dure depuis trois jours, où la refonte du panier côtoie un bug CSS. Le contexte se remplit de sujets morts, et chaque nouvelle demande paie le poids de toutes les précédentes, en qualité comme en tokens. Remède : une session, un sujet, un critère de done (chapitre 7).
- 02 · L'acharnement correctif« Non, toujours pas », dix fois de suite, sur le même bug. Chaque rustine s'empile dans un contexte qui contient surtout l'historique de vos échecs, et l'IA régresse au lieu de converger. Remède : deux allers-retours ratés, stop : /clear, et un prompt reformulé (chapitre 7).
- 03 · Le CLAUDE.md obèseQuatre cents règles accumulées, et le sentiment vexant qu'aucune n'est suivie. Noyée dans la masse, la règle qui compte pèse autant que la règle morte, c'est-à-dire presque rien. Remède : élaguer, dater, ne garder que ce qui corrige une erreur réellement récurrente (chapitre 3).
- 04 · La confiance aveugleMerger sans avoir lu le diff ni lancé l'application. Le dégât est différé, donc pire : le code plausible passe la démo et casse en production. Remède : jamais de tâche sans critère de done exécutable, jamais de merge sans preuve (chapitre 6).
- 05 · L'exploration infinieDes specs, des plans, des comparatifs, et toujours rien en production. Le coût d'opportunité, plus sournois qu'un bug, et la préparation qui périme avant d'avoir servi. Remède : le plan est au service du diff ; si le résultat attendu tient en une phrase, codez direct (chapitre 5).
- 06 · Le tout-MCPDouze serveurs branchés « au cas où ». Chaque serveur coûte du contexte en permanence, que vous l'utilisiez ou non : votre fenêtre étouffe avant même la première demande. Remède : pour chaque serveur, une justification, et le réflexe de comparer avec un CLI ou une skill (chapitre 9).
- 07 · Le prompt tapis-volant« Fais-moi une app », et l'on monte sur le tapis en espérant qu'il vole jusqu'au bon endroit. L'IA décide de tout, vite et avec assurance, et vous découvrez ses choix quand ils sont déjà du code. Remède : le cadrage. Fichiers concernés, contraintes, résultat attendu, interdits (chapitres 1 et 4).
- 08 · Le luxe permanentLe modèle le plus puissant, effort de raisonnement au maximum, pour renommer une variable. Une facture multipliée sans gain de qualité, car la puissance ne sert que si la tâche en demande. Remède : qui, dans une équipe réelle, ferait cette tâche ? Confiez-la au modèle de ce gabarit (chapitre 10).
Une semaine, deux versions
Le piège le plus répandu mérite sa démonstration. Voici la même semaine de travail, vécue deux fois :
❯ /context Contexte : 92 % occupé. Un seul fil depuis mardi. Forfaits, bug CSS, README, migration : tout s'y mélange. ❯ /clear ❯ Lis CLAUDE.md. Sujet unique : l'arrondi des forfaits. ❯ Done : le test des tarifs passe au vert. Rien d'autre. · Claude lit, corrige, relance le test... ✓ Tests forfaits : 4/4 verts. Session close en 12 min.
La première moitié est une session fourre-tout arrivée au bout d'elle-même : un contexte saturé où plus rien ne converge. La seconde est la même charge de travail, découpée : des sessions courtes, un sujet et un done exécutable chacune. Même semaine, même projet, mais des fils propres et une facture divisée.
Le découpage n'est pas une contrainte de plus, c'est ce qui rend tout le reste facile.
L'auto-audit : vingt questions
Prenez cinq minutes et répondez honnêtement : la grille ne note pas ce que vous savez, elle note ce que vous faites vraiment, sur vos projets actuels.
Comptez un point par « oui » franc. Un « oui parfois » est un non.
- Vos projets actifs ont-ils un CLAUDE.md relu il y a moins d'un mois ?
- Vos demandes précisent-elles les fichiers concernés et le résultat attendu ?
- Sur une fonctionnalité non triviale, exigez-vous un plan avant le code ?
- Relisez-vous et amendez-vous les plans proposés avant de valider ?
- Vos grosses fonctionnalités partent-elles d'une spec écrite et versionnée ?
- Chaque tâche a-t-elle un critère de done exécutable (test, build, capture) ?
- Lisez-vous les diffs avant de merger ?
- Lancez-vous l'application pour de vrai avant de livrer ?
- Une session séparée relit-elle le code produit (testeur ou réviseur) ?
- Un audit de sécurité passe-t-il avant chaque mise en production ?
- Appliquez-vous la règle des deux corrections (stop, /clear, reformuler) ?
- Les erreurs récurrentes de Claude deviennent-elles une ligne de CLAUDE.md ou un test ?
- Vos sessions ont-elles un sujet unique ?
- Faites-vous jouer les rôles (PO, testeur, sécurité) dans des sessions distinctes ?
- Savez-vous justifier chaque serveur MCP branché face à un CLI ou une skill ?
- Vos règles non négociables passent-elles par des hooks plutôt que par des consignes ?
- Adaptez-vous le modèle à la tâche au lieu de garder le plus gros par défaut ?
- Regardez-vous votre consommation au moins une fois par mois ?
- Des tâches répétitives (revue de PR, rapports) tournent-elles sans vous ?
- Votre équipe partage-t-elle prompts, skills et conventions, plutôt que chacun les siens ?
- De 0 à 7 · La pratique instinctiveVous utilisez un outil puissant comme on conduit sans code de la route : ça avance, et ça coûte cher en accrochages invisibles. La bonne nouvelle est que vos gains les plus énormes sont les moins chers : relisez les actes I et II, et commencez par les questions 1, 6 et 11. Trois « oui » de plus changent une pratique.
- De 8 à 14 · La base solideLe socle est là, et votre marge est dans les trous : la famille de questions où vous avez tout raté pointe en général un anti-pattern dominant, le même depuis des mois. Nommez-le, affichez-le, traitez-le pendant deux semaines avant de toucher au reste.
- De 15 à 20 · La pratique outilléeVotre sujet n'est plus individuel, il est collectif : diffuser, harmoniser, embarquer les nouveaux. Une pratique excellente qui ne vit que dans votre terminal est un savoir qui part en vacances avec vous. Skills partagées, hooks d'équipe, conventions écrites : c'est votre prochain chantier.
Ce qui bouge vite
Encart daté d'août 2026, à relire avec cette date en tête : ce domaine bouge vite, et une partie des conseils de 2025 a déjà expiré.
Le plan mode systématique s'est nuancé. La doctrine de 2025 disait : toujours planifier avant de coder. Celle de 2026 est plus fine : la vérification exécutable a pris le premier rôle, et sur une petite tâche bien cadrée dont le done est un test qui passe, le plan est du luxe. Le chapitre 5 donne la règle de bascule.
Les slash commands custom ont cédé la place aux skills. Empaqueter un savoir-faire dans une skill, qui se charge à la demande et se partage à l'équipe, a remplacé la collection de commandes maison. Chapitre 9.
Le tout-MCP s'est démodé. Brancher un serveur pour chaque besoin était le réflexe de 2025. L'expérience a tranché : le contexte est trop précieux, et un CLI ou une skill fait souvent mieux pour moins cher. Le MCP reste irremplaçable là où il l'est vraiment. Chapitre 9 encore.
Comment rester à jour sans faire de la veille un second métier : ce guide maintient un changelog, chaque chapitre révisé porte sa date de dernière mise à jour en tête de page, et les passages périmés sont corrigés plutôt qu'empilés. Revenez-y ; c'est fait pour.
Et maintenant
Le guide s'arrête ici, et il faut se dire les choses simplement : vous avez la méthode complète. Cadrer, faire vérifier, orchestrer les rôles, outiller, payer juste, automatiser, produire au-delà du code.
Un mot, avant de se quitter, sur le cabinet de Talia. Le chapitre 1 s'achevait sur une menace : « vous découvrirez ses choix dans trois semaines, en production ». Relisez le chemin parcouru depuis.
L'app.js de 1 240 lignes du vendredi soir a reçu un brief (chapitre 3), un workflow (chapitre 5), des tests qui recréditent les forfaits (chapitre 6), une équipe entière (chapitre 8), un audit qui a fermé la faille de l'annulation en un clic (la même qui s'affichait fièrement dès la première démo), une facture divisée (chapitre 10) et une vidéo de lancement (chapitre 12).
L'application du vendredi soir est morte ; le produit qui l'a remplacée est en production, et les patients de Talia y prennent rendez-vous chaque jour, sans pouvoir annuler les séances des autres. C'était le même projet depuis le début, et vous venez de le livrer. Voilà ce que « vibe coder est un métier » voulait dire.
Dernière chose : ce site lui-même, davidsilvera.com, a été codé avec Claude en appliquant chaque chapitre que vous venez de lire.
Vous ne lisez pas un guide sur la méthode : vous naviguez dedans.
Il reste l'écart entre savoir et faire, et c'est exactement là que j'interviens. En quinze ans de développement, de Mappy à Voodoo en passant par WeMoms, Accor et le Programme alimentaire mondial de l'ONU, j'ai vu ce qui fait qu'une équipe adopte une pratique ou la regarde passer. Concrètement, je propose trois choses.
L'audit de pratique d'équipe : j'observe comment votre équipe travaille réellement avec Claude, je passe la grille à l'échelle du collectif, je nomme les anti-patterns qui vous coûtent, et vous repartez avec un plan d'action priorisé. La formation intra : la méthode de ce guide, transmise à vos développeurs, sur votre code, pas sur des exemples jouets.
La mise en place de l'outillage : CLAUDE.md, skills, hooks, revue automatique en CI, installés et adoptés, pas seulement recommandés, réglages de confidentialité et de conformité compris.
Sur ce dernier point, une annexe hors parcours répond à la question que votre direction posera avant toutes les autres : où part le code, ce qui en est conservé, et comment déployer proprement en entreprise. Si votre score collectif vous a fait grimacer, c'est le bon moment pour en parler.
Questions fréquentes sur les anti-patterns
Quelles sont les erreurs à éviter avec Claude Code ?
Huit anti-patterns reviennent constamment : la session fourre-tout (tout dans un fil interminable), l'acharnement correctif (dix rustines au lieu d'un /clear), le CLAUDE.md obèse (des centaines de règles, aucune suivie), la confiance aveugle (merger sans lire ni tester), l'exploration infinie (préparer sans produire), le tout-MCP (le contexte étouffé par les serveurs), le prompt tapis-volant (« fais-moi une app ») et le luxe permanent (le plus gros modèle pour tout). Tous partagent une racine : la mauvaise gestion d'une fenêtre de contexte finie.
Comment auditer l'usage de l'IA dans son équipe de développement ?
Commencez par mesurer la pratique réelle plutôt que la pratique déclarée : faites passer à chaque membre une grille factuelle (brief, vérification, hygiène de session, rôles, outillage, coûts), comme celle de ce chapitre, et comparez les scores. Les écarts entre personnes révèlent l'absence de conventions partagées ; les zéros collectifs révèlent les anti-patterns d'équipe. Un audit externe ajoute l'observation directe des sessions et un plan d'action priorisé : c'est l'accompagnement que je propose aux équipes de trois à quinze développeurs.
La suiteIl n'y a pas de chapitre 14 : la suite s'écrit dans votre terminal. Reprenez votre parcours (développeur, créateur ou CTO), relisez les chapitres qui le composent, et appliquez-en un par semaine, en commençant par celui que la grille vous a désigné. Repassez l'auto-audit dans trois mois. Et si vous voulez faire franchir ce chemin à toute une équipe sans y passer des mois, l'audit de pratique et la formation intra sont là pour ça : parlons-en.
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