Le code est la partie facile. Les rails sont ton vrai travail.
Comment passer du vibecoding à du code qu'un client peut relire, reprendre lundi matin, et que tu peux défendre à l'oral.
01 La bascule
Deux façons d'utiliser le même outil. Une seule tient devant un client.
Tu demandes, ça sort, tu regardes si ça marche. Le seul juge, c'est ton œil. Ça marche très bien pour un petit outil perso : tu es le seul utilisateur, le seul mainteneur, et personne ne te demandera jamais pourquoi tu as choisi ça.
Tu construis les rails — l'exigence, le plan, le spec, le test, la vérif — et l'agent court dedans. Tu ne produis plus du code, tu produis un système qui produit du code correct. C'est ça, le métier.
Un client ne juge pas ta vitesse de frappe. Il juge trois choses, dans cet ordre : est-ce que ça fait ce que j'ai demandé, est-ce que mon dev peut reprendre ça, et est-ce que tu sais pourquoi tu as fait chaque choix.
Selon une enquête de février 2026, 71 % des développeurs qui travaillent avec des agents utilisent Claude Code comme outil principal. Ce qui suit n'est donc pas une niche d'early adopters : c'est en train de devenir le standard de fait du métier, et un client technique s'attend à ce que tu le maîtrises.
02 Les quatre lois
Tout le reste en découle. Si tu ne retiens que cette section, tu as déjà 80 % du bénéfice.
Donne-lui un moyen de vérifier
Un agent s'arrête quand le travail a l'air fini. Sans test à lancer, « a l'air fini » est le seul signal disponible, et c'est toi qui deviens la boucle de vérification : chaque erreur attend que tu la remarques.
Un moyen de vérifier, c'est tout ce qui renvoie pass ou fail et que l'agent peut lire : une suite de tests, un build, un linter, un script qui compare la sortie à un fichier de référence, une capture d'écran.
Le contexte est ta ressource rare
Tout ce que l'agent lit remplit sa fenêtre, et sa qualité baisse quand elle se remplit. Une seule session de debug peut brûler des dizaines de milliers de tokens pour rien.
D'où : /clear entre deux tâches sans rapport, les recherches lourdes en subagent, et si tu as corrigé deux fois la même chose sans succès, tu repars à zéro avec un meilleur prompt plutôt que d'insister.
Explore, puis planifie, puis code
Trois phases séparées, jamais mélangées. Shift+Tab jusqu'à plan mode on : l'agent lit et répond, il ne peut rien modifier. Ce n'est pas une politesse, c'est verrouillé au niveau de l'outil.
Exception : si tu peux décrire le diff en une phrase, saute le plan. Planifier un renommage de variable est du théâtre.
Chaque ligne remonte à une exigence
C'est le cœur du « respect des requirements ». Une équipe a fait son premier audit de traçabilité après six mois de dev assisté : une part importante du code généré ne se rattachait à aucune exigence documentée, il existait des tests pour des features que personne n'avait demandées, et des features explicitement demandées manquaient.
La parade est bête : chaque bloc répond à une phrase du client. Un bloc qui ne répond à rien, tu le nommes comme du scope que tu as pris, ou tu le supprimes.
03 Le cycle en 7 étapes
L'ordre compte. Chaque étape a une condition de sortie : tant qu'elle n'est pas remplie, tu ne passes pas à la suivante.
Tu écris ce que le client a dit, avec ses mots. Pas ta reformulation, pas ta traduction en jargon technique. Une phrase du client est une exigence ; ta reformulation est déjà une décision que tu as prise sans le dire.
Voici le brief. Liste les exigences, en citant la phrase exacte pour chacune. Sépare ce qui est demandé de ce que tu déduis.
Tu sors quand tu as la liste des exigences citées, et la liste séparée de tes déductions.
Plan mode. L'agent lit le code, les données, l'API. Il ne touche à rien. Le but n'est pas qu'il comprenne, c'est que toi tu comprennes — il te restitue.
Lis src/ et explique comment marche l'ingestion. Ne modifie rien.
Regarde l'historique git de ce fichier et résume comment on en est arrivé là.
Tu sors quand tu sais comment ça marche vraiment, pas comment ça devrait marcher.
Il propose un plan, tu le corriges. Ctrl+G l'ouvre dans ton éditeur pour que tu l'édites toi-même. Un plan que tu n'as pas modifié est un plan que tu n'as pas lu.
Je veux ajouter X. Quels fichiers changent ? Fais un plan.
Tu sors quand le plan nomme les fichiers et l'ordre des tranches.
Tu le laisses t'interroger, puis il écrit SPEC.md. Ensuite tu ouvres une nouvelle session pour construire : contexte propre, entièrement dédié à l'implémentation, avec un spec écrit à côté.
C'est la seule étape où un prompt long se justifie, parce que tu configures un interrogatoire et pas une tâche.
Je veux construire [X]. Interroge-moi en détail avec AskUserQuestion. Implémentation technique, cas limites, arbitrages. Pas de questions évidentes, creuse les parties dures auxquelles je n'ai pas pensé. Continue jusqu'à ce qu'on ait tout couvert, puis écris SPEC.md.
Un spec utile est autoportant : il nomme les fichiers et les interfaces, il dit ce qui est hors scope, et il finit par une vérification bout en bout qui prouve que la feature marche. Le temps passé à préciser le spec rapporte plus que le temps passé à surveiller l'implémentation.
Tu sors quand le spec dit aussi ce qui est hors scope.
Une tranche à la fois. Test d'abord quand c'est du cœur métier. Commit à chaque tranche. L'erreur classique est de demander la feature entière : tu obtiens 600 lignes que tu ne peux plus relire.
Implémente l'étape 1 du plan. Lance les tests. Corrige les échecs.
Écris d'abord le test qui échoue. Montre-moi l'échec avant d'implémenter.
Regarde comment X est fait dans foo.ts. Suis le même pattern.
La précision d'un prompt, en une comparaison
Tu sors quand chaque tranche est démontrable seule et commitée.
Un subagent relit le diff en contexte neuf. Il ne voit que le diff et tes critères, pas le raisonnement qui a produit le code. Celui qui a écrit ne peut pas être celui qui note.
Relis le diff contre SPEC.md avec un subagent. Chaque exigence est-elle implémentée ? Signale les manques, pas le style.
Trouve les bugs qui passent les tests mais cassent en prod.
Un relecteur à qui tu demandes de trouver des trous en trouvera, même quand le code est bon : c'est ce que tu lui as demandé. Si tu cours après chaque remarque, tu finis en sur-architecture — couches d'abstraction en plus, code défensif, tests pour des cas impossibles.
Donc dis-lui explicitement de ne signaler que ce qui touche la correction ou une exigence écrite, et traite le reste comme optionnel.
Tu sors quand les écarts réels sont corrigés, et que tu as noté ceux que tu as choisi de ne pas corriger.
Commits propres, README, .env.example, décisions documentées. C'est la partie que tu crois secondaire et que le client lit en premier.
Commit avec un message descriptif.
Tu sors quand un inconnu fait tourner ton truc sans te poser une seule question.
04 La banque de prompts
Ils sont courts exprès. Un prompt long se dilue. Ce qui compte, c'est de nommer le fichier, le cas, et ce que « fini » veut dire.
| Situation | Le prompt |
|---|---|
| Comprendre du code | Lis src/ et explique comment marche X. Ne modifie rien. |
| Comprendre une décision passée | Regarde l'historique git de ce fichier et résume comment on en est arrivé là. |
| Obtenir un plan | Je veux ajouter X. Quels fichiers changent ? Fais un plan. |
| Écrire un spec | Interroge-moi en détail avec AskUserQuestion, puis écris SPEC.md. |
| Construire une tranche | Implémente l'étape 1 du plan. Lance les tests. Corrige les échecs. |
| Forcer le TDD | Écris d'abord le test qui échoue. Montre-moi l'échec. |
| Rester cohérent | Regarde comment X est fait dans foo.ts. Suis le même pattern. |
| Déboguer | Reproduis le bug avec un test qui échoue. Ensuite seulement, corrige la racine. |
| Faire relire | Relis le diff contre SPEC.md avec un subagent. Signale les manques, pas le style. |
| Chercher le vrai risque | Trouve les bugs qui passent les tests mais cassent en prod. |
| Livrer | Commit avec un message descriptif. |
Les deux réflexes qui valent tous les prompts
- Une seule chose par prompt. Trois problèmes dans un message donnent trois corrections moyennes.
- Coupe tôt. Esc dès que ça part de travers, Esc Esc pour revenir en arrière. Corriger vite bat corriger bien. Et après deux corrections ratées sur le même sujet, /clear : le contexte est pollué par les tentatives mortes.
Exige la preuve, pas l'affirmation
Demande la sortie du test, la commande lancée et ce qu'elle a renvoyé, la capture d'écran. Relire une preuve est plus rapide que refaire la vérification toi-même — et ça marche aussi pour les sessions que tu n'as pas regardées tourner.
05 Une journée client, bloc par bloc
Le cycle appliqué à un livrable d'une journée : un take-home, un POC, une mission courte.
Vérité terrain
Un vrai appel à l'API que tu vas utiliser. Tu regardes le résultat avec tes yeux. Tu notes les limites réelles : requêtes par minute, concurrence, latence.
C'est la Loi 1 appliquée à la brique de base. Ne conçois jamais une journée de produit sur un primitif que tu n'as jamais vu tourner. Si la première sortie est mauvaise, ça change le scope, et mieux vaut le savoir à la minute 20 qu'à la sixième heure.
Cadrer et explorer
Étapes 1 et 2. Tu sors avec les deux décisions structurantes fermées et justifiées par écrit. La justification écrite au moment du choix vaut dix justifications reconstruites le soir.
Voici le brief et 5 options de scope. Attaque-les. Laquelle est indéfendable, et pourquoi ?
Planifier et spécifier
Étapes 3 et 4. Tu fermes les décisions techniques restantes, puis tu transformes le registre de décisions en spec exécutable.
Pour chaque décision ouverte : recommande, et dis ce que tu rejettes.
Construire la colonne vertébrale
Étape 5, dans l'ordre du plan. Le critère de découpage : chaque étage doit être démontrable seul. Comme ça, à chaque heure qui passe, tu as une démo — et si la journée déraille, tu livres l'étage atteint au lieu de rien.
Commit après chaque étage. Déploie quelque chose de trivial tôt : le pipeline de déploiement doit exister avant que tu en aies besoin, jamais le dernier soir.
Durcir
Étape 6 : relecture, puis un second modèle en adversarial, puis la passe sécu. Tu corriges ce qui est réel et tu notes ce que tu as choisi de ne pas corriger — cette note est du matériau pour ton registre de scope.
Et surtout : casse-le exprès. Une entrée invalide, une URL morte, une limite de débit atteinte. Est-ce qu'un message lisible par un humain arrive jusqu'à l'utilisateur ? C'est ça qu'il verra un mardi à 18h, pas ton architecture.
Les livrables écrits
Aussi lourdement noté que le code, et systématiquement bâclé. Les hypothèses, les décisions, le registre de scope, l'économie unitaire en dollars réels relevés au fil de l'eau.
Beaucoup de clients et d'évaluateurs regardent désormais l'historique de tes sessions IA. Ce qu'ils cherchent : les endroits où tu as contredit le modèle. Un désaccord entre deux modèles que tu as tranché, et pourquoi.
Ça ne se reconstruit pas à 23h : le transcript contredira ta version. Tiens un tableau à trois colonnes — ce que le modèle proposait, ce que tu as fait à la place, pourquoi — et remplis-le au moment où ça arrive.
06 L'écosystème skills
Ce que les gens installent vraiment, et ce que ça dit du métier.
En mars 2026, Claude Code embarque 101 plugins intégrés : 33 construits par Anthropic (12 language servers, 10 dev workflow dont feature-dev, code-review, commit-commands, security-guidance et frontend-design, 5 outils de setup, plus quelques output styles et messagerie) et 68 plugins partenaires.
| Phase | Skill | Ce qu'elle impose | Traction |
|---|---|---|---|
| Cadrage | Grill Me | T'interroge jusqu'à compréhension partagée du plan | ≈156 k installs |
| Tout le cycle | Superpowers | brainstorm → spec → plan → TDD → subagents → review → merge | ≈41 k ★ · marketplace officiel |
| Écriture | Karpathy Guidelines | 4 règles : penser avant, simplicité, chirurgie, orienté but | ≈144 k ★ |
| Écriture UI | Frontend Design | Sort de l'esthétique générique par défaut | ≈277 k installs · le plus installé |
| Test | webapp-testing | Teste en vrai navigateur (Playwright) | officiel Anthropic |
| Debug | systematic-debugging | Reproduire → hypothèse → plus petit test → racine | ≈2,5 h/sem |
| Revue | code-review | Relit le diff en contexte neuf | officiel Anthropic |
| Revue | Code-Simplifier | Lisibilité sans changer le comportement | officiel Anthropic |
| Sécurité | Trail of Bits | CodeQL + Semgrep, méthodo d'audit pro | cabinet d'audit |
| Contexte | Handoff | Compresse une session pour repartir propre | Matt Pocock |
| Contexte | Caveman | Coupe la narration, −65 % de tokens | ≈68 k ★ |
| Doc externe | Context7 | Doc à jour et à la bonne version d'une lib | plugin partenaire |
Le point commun de toutes les skills en tête : elles imposent une procédure, pas un ton. Aucune ne rend le modèle plus intelligent. Toutes l'empêchent de sauter une étape.
C'est exactement l'enseignement à retenir : ce qui gagne en 2026, ce sont les workflows structurés, pas les prompts malins.
La distinction que tout le monde rate : CLAUDE.md ou skill ?
Donc il doit rester court. Les commandes que l'agent ne peut pas deviner, les conventions qui diffèrent du défaut, les dossiers interdits, les pièges non évidents. Pour chaque ligne : « est-ce que l'enlever provoquerait une erreur ? » Si non, coupe.
Tout le savoir-faire qui ne sert que parfois. Un CLAUDE.md obèse fait ignorer les règles qui comptent : elles se noient dans le bruit. Si l'agent répète une erreur malgré une règle écrite, le fichier est probablement trop long.
Et les hooks
Une instruction dans CLAUDE.md est un conseil. Un hook est un script qui tourne toujours, sans exception : lint après chaque édition, blocage d'un dossier, test qui doit passer avant que le tour se termine. Quand une règle ne doit jamais sauter, elle ne va pas dans un fichier de règles, elle va dans un hook.
Trois choses, et rien de plus : plan mode systématique, une relecture adversariale avant la démo, et un CLAUDE.md de 15 lignes. Installer un framework en 7 phases la veille, c'est apprendre l'outil au lieu de faire l'exercice.
07 « Propre pour un client », concrètement
Ce n'est pas un jugement esthétique. C'est une liste. Coche-la, elle est sauvegardée dans ton navigateur.
- ✓Le README démarre le projet en 3 commandesSi un reviewer doit te poser une question pour lancer le truc, c'est raté.
- ✓Un .env.example completEt l'app dit quelque chose d'utile quand une clé manque, au lieu de planter à l'import.
- ✓Aucun secret dans l'historique gitVérifie l'historique complet, pas juste l'état actuel. Si une clé y est passée un jour : tu la révoques, et tu le dis.
- ✓Les erreurs sont lisibles par un humainLe client verra tes messages d'erreur bien avant ton architecture.
- ✓Des tests sur le cœur, pas sur toutLe chemin critique et les cas limites que tu as nommés dans le spec. Le reste est du bruit.
- ✓Zéro code mortPas de fonction « au cas où », pas de commentaire fossile, pas d'option jamais branchée.
- ✓Les commits racontent l'histoireUn commit = un changement logique. C'est lu.
- ✓Chaque partie remonte à une exigenceEt ce qui n'y remonte pas est nommé comme tel, au lieu d'être glissé sous le tapis.
- ✓Les hypothèses sont écritesQuestion → hypothèse → ce que ça a changé. La troisième colonne est la seule qui contient des opinions, donc la seule vraiment lue.
- ✓Le registre de scope est honnêteDedans / dehors / plus tard, avec la raison. Et « coupé par manque de temps » quand c'est le cas : un aveu honnête achète la crédibilité des neuf autres lignes.
08 Les pièges
Les reconnaître tôt fait gagner des heures. Ils sont tous des conséquences de la Loi 2.
La session fourre-tout
Tu commences une tâche, tu poses une question sans rapport, tu reviens à la première. Le contexte est plein de bruit et la qualité chute sans que tu voies pourquoi.
/clear entre deux tâches sans rapport.
La correction en boucle
Tu corriges, c'est faux, tu recorriges, c'est encore faux. Le contexte est saturé de tentatives mortes, qui pèsent autant que le bon code.
Après deux échecs, /clear et un meilleur prompt initial intégrant ce que tu as appris.
Le CLAUDE.md obèse
Trop long, donc à moitié ignoré : les règles qui comptent se noient. Symptôme typique : l'agent répète une erreur contre laquelle tu as écrit une règle.
Élaguer sans pitié. Ce qui doit être garanti devient un hook.
La confiance sans vérif
Une implémentation qui a l'air très bien et qui ne gère aucun cas limite. Les erreurs silencieuses coûtent plus cher que les crashs bruyants.
Si tu ne peux pas le vérifier, tu ne le livres pas.
L'exploration infinie
« Investigue ça » sans cadre : 200 fichiers lus, une réponse vague, un contexte mort.
Cadre la question, ou délègue à un subagent qui te rend un résumé.
Le déploiement laissé à la fin
Tu démontres localhost parce que le pipeline n'existait pas encore. Sur un livrable client, c'est une exigence ratée, pas un détail.
Déploie un truc trivial dès la première moitié de la journée.
09 Checklist de la veille
À passer le soir avant de rendre. Le dernier point est le seul qui ne se rattrape pas.
- ✓Le truc est déployé et répond, maintenantÀ une vraie URL, que quelqu'un d'autre peut ouvrir.
- ✓La boucle complète tourne depuis un téléphoneSi l'utilisateur final est sur mobile, non testé sur mobile = non livré.
- ✓Un chemin d'erreur a été déclenché exprèsEt le message qui en sort est lisible par un humain non technique.
- ✓Les documents sont commitésSpec, hypothèses, approche, décisions.
- ✓Les coûts réels sont notésRelevés au fil de l'eau, pas estimés à la fin.
- ✓Tu peux défendre 3 décisions à l'oralAvec ce que tu as rejeté, et pourquoi.
- ✓Tu peux citer un endroit où tu as contredit le modèleEt ce que tu as fait à la place. Note-le quand ça arrive, pas le dernier soir.