Guide complet du développeur pour Claude Code 2.0 : des questions annexes à la revue multi-agents

Il est préférable de considérer Claude Code 2.0 comme un système de travail à part entière, et non comme une simple boîte d'auto-complétion plus grande. L'amélioration majeure réside dans le modèle de fonctionnement autour de l'agent : des questions annexes (side questions) qui ne polluent pas le fil principal, des vérifications répétées qui s'exécutent en arrière-plan pendant que vous travaillez, des contrôles d'effort pour adapter le raisonnement au niveau de risque, des compétences (skills) qui chargent des procédures uniquement lorsque cela est nécessaire, une mémoire qui survit aux nouvelles sessions, et des agents de revue capables d'inspecter une pull request sous plusieurs angles.

En date du 11 août 2026, l'installation locale de Claude Code testée pour ce guide est la version 2.1.227. Le journal des modifications officiel de Claude Code (changelog) indique la v2.1.227 comme étant la version actuelle dans la documentation, avec des correctifs de fiabilité concernant les feature flags, l'exécution Bash des GitHub Actions, /tui, le comportement du menu des commandes slash, et les performances. Le produit évoluant rapidement, considérez ceci comme un guide d'implémentation pour la branche actuelle 2.1.x, et non comme un manuel figé.

Si vous en êtes encore à évaluer si un flux de travail de codage basé sur des agents (agentic coding workflow) a sa place dans votre équipe, commencez par la base : Claude Code peut lire un dépôt, exécuter des commandes, modifier des fichiers et vérifier les résultats au sein d'une boucle d'agent. La question n'est plus "peut-il écrire du code ?". La question est de savoir si vous avez suffisamment de processus autour de lui pour que cette boucle reste utile. C'est la même raison pour laquelle nous séparons l'implémentation de l'agent de l'expérimentation des prompts dans notre guide d'implémentation d'agents IA et dans nos travaux sur les flux de travail de codage basés sur les agents.

Le modèle mental : protéger le fil principal

L'erreur principale avec les agents de codage est de traiter la conversation comme un brouillon infini. Chaque question annexe, journal (log) collé, supposition ratée, plan à moitié formulé et demande de type "tant que tu y es" rivalise pour obtenir du contexte. Claude Code 2.0 offre aux développeurs davantage de moyens de répartir ce travail :

• Utilisez /btw lorsque la réponse ne doit pas être intégrée à la transcription principale.
• Utilisez un sous-agent (subagent) lorsque quelque chose nécessite des outils, la lecture de fichiers ou une exploration dans un contexte séparé.
• Utilisez /loop lorsqu'une vérification doit se répéter sans que vous ayez à la relancer manuellement.
• Utilisez les compétences (skills) lorsqu'un flux de travail est suffisamment répétable pour mériter une procédure locale.
• Utilisez la mémoire (memory) lorsqu'une règle ou une correction doit survivre à la prochaine nouvelle session.

C'est là le véritable changement pratique. Une bonne configuration de Claude Code n'est pas "un seul fichier CLAUDE.md géant". C'est un ensemble de canaux restreints et bien délimités pour le bon type de contexte.

/btw : poser des questions sans polluer l'historique

La référence officielle des commandes décrit /btw [question] comme une question annexe rapide qui ne s'ajoute pas à la conversation. La documentation du mode interactif rend la distinction encore plus claire : /btw voit toute la conversation mais n'a accès à aucun outil, tandis qu'un sous-agent dispose d'outils mais démarre avec un contexte vide.

Cela rend /btw parfait pour des questions telles que :

/btw qu'avons-nous décidé concernant l'ordre de migration ?
/btw cette erreur vient-elle probablement de l'exécuteur de tests ou de la base de données ?
/btw résume les parties risquées du diff actuel en un paragraphe

Utilisez /btw lorsque vous avez besoin d'une réponse basée sur ce que Claude sait déjà. Ne l'utilisez pas pour examiner un fichier, inspecter des logs, appeler une API ou vérifier une affirmation. C'est le travail d'un sous-agent. La règle d'or est simple : si la question annexe ne doit pas modifier le plan et ne nécessite pas d'outils, utilisez /btw. Si la réponse pourrait affecter l'implémentation, ramenez-la dans le fil principal ou assignez-la à un sous-agent.

C'est important pour les longues sessions. Claude Code peut désormais rouvrir la récente superposition (overlay) /btw sans nouvelle question, transformant ce canal secondaire en un bloc-notes léger pour les raisonnements éphémères. Ce n'est pas un substitut à la mémoire du projet. C'est un moyen d'éviter que votre transcription de travail ne devienne un fourre-tout.

/loop : rendre l'attente explicite

La même référence des commandes définit /loop [intervalle] [prompt] comme une compétence qui exécute un prompt de manière répétée tant que la session reste ouverte. L'intervalle est facultatif ; Claude peut gérer son propre rythme. Le prompt est facultatif lorsque la maintenance autonome ou .claude/loop.md est disponible. L'alias est /proactive.

Les boucles utiles sont ennuyeuses :

/loop 5m vérifie si le déploiement de prévisualisation est terminé et signale uniquement si le statut change
/loop 10m relance le test instable (flaky test) et arrête-toi après un passage réussi
/loop vérifie s'il y a du travail inachevé évident dans le dépôt avant mon retour

Les mauvaises boucles sont vagues :

/loop rends le projet meilleur
/loop continue d'optimiser ça

Une boucle a besoin d'une condition de sortie. Sinon, vous avez créé un stagiaire infatigable sans aucune définition de tâche terminée. La version pour développeur senior paresseux consiste à demander la plus petite vérification répétée qui vous évite de faire vos propres requêtes de vérification (polling). Surveiller un déploiement. Relancer un seul test. Vérifier si une longue migration est terminée. Ne transformez pas /loop en un chef de produit en arrière-plan.

Pour les systèmes d'agents en production, c'est le même modèle que nous utilisons dans les services d'automatisation de l'IA : les vérifications répétables sont utiles lorsque l'état est observable et que l'action est contrainte. Elles sont dangereuses lorsque l'objectif est flou.

/effort : adapter le raisonnement au risque

/effort [niveau|auto] vous permet de définir l'effort du modèle. La documentation liste low (faible), medium (moyen), high (élevé), xhigh (très élevé), max (maximum), et ultracode, la disponibilité dépendant du modèle. Cela peut être modifié via un curseur interactif et prend effet immédiatement.

Utilisez les niveaux d'effort comme les vitesses d'une voiture :

Ne laissez pas chaque tâche à l'effort maximum. Ce n'est pas de la rigueur ; c'est un paramètre par défaut onéreux. La meilleure habitude est d'augmenter l'effort uniquement lorsque la surface de décision s'élargit. Si une tâche touche à l'argent, à l'authentification, à la perte de données, au déploiement ou à plusieurs paquets, augmentez l'effort. Si la tâche est mécanique et que les tests sont rapides, restez à un niveau inférieur et vérifiez.

/dataviz : les graphiques ont besoin de règles de conception, pas seulement de SVG

La documentation des commandes décrit /dataviz [requête] comme une compétence pour les graphiques, les diagrammes et les tableaux de bord. Elle choisit la forme du graphique, attribue des couleurs selon le rôle, valide les palettes pour l'accessibilité visuelle (daltonisme) et le contraste, et applique des règles de repérage, d'interaction et d'accessibilité.

Le mot important est "compétence" (skill). /dataviz n'est pas une baguette magique pour le bon goût en matière de graphiques. C'est une procédure packagée qui aide Claude à prendre de meilleures décisions concernant le type de graphique, la couleur et l'accessibilité. Utilisez-la pour les rapports d'ingénierie, les tableaux de bord de publication, les résumés de régression, les courbes de coûts, les comparaisons de benchmarks et les historiques d'incidents.

Une bonne requête ressemble à ceci :

/dataviz transforme ce CSV de latence en un graphique avant/après pour une revue technique. Affiche p50, p95 et p99. Rends la régression évidente sans utiliser uniquement du rouge/vert.

Une mauvaise requête est "fais un graphique sympa". La contrainte utile est la décision que le graphique doit soutenir. Si une visualisation ne change pas ce qu'un lecteur comprend ou fera ensuite, n'en créez pas.

Compétences d'Agent (Skills) : sortir le travail répétable du chat

La documentation sur les compétences explique le mécanisme de base : une compétence est un fichier SKILL.md contenant des instructions que Claude peut charger lorsque c'est pertinent ou lorsqu'il est invoqué directement. Contrairement à la mémoire toujours chargée, le corps d'une compétence ne se charge que lorsqu'il est utilisé. Les commandes personnalisées et les compétences ont en fait convergé : un fichier de commande et une compétence peuvent tous deux créer un comportement de commande slash.

C'est une avancée majeure pour les équipes. Cela signifie que vous pouvez arrêter de coller la même checklist à chaque session :

• "Comment nous révisons les migrations" devient une compétence de revue de migration.
• "Comment nous préparons une note de version" devient une compétence de note de version.
• "Comment nous déboguons les webhooks de paiement" devient une compétence de débogage de paiements.
• "Comment nous exécutons les vérifications de régression visuelle" devient une compétence de vérification.

Gardez les compétences courtes au début et placez les exemples volumineux, les modèles et les scripts dans des fichiers de support annexes. La documentation prend explicitement en charge les modèles, exemples, scripts et la documentation de référence à côté de SKILL.md. Cela vous offre un modèle clair : la compétence décide de ce qui doit être chargé, et non votre prompt système.

Pour une stratégie plus approfondie à ce sujet, consultez notre article sur l'ingénierie de contexte pour les agents IA. Le principe est le même : le contexte est un budget. Dépensez-le uniquement lorsqu'il modifie la prochaine action.

Mémoire : CLAUDE.md n'est pas un fourre-tout

La documentation sur la mémoire précise que chaque session Claude Code commence avec une fenêtre de contexte vierge. La continuité provient de deux mécanismes : les fichiers CLAUDE.md et l'auto-mémoire. CLAUDE.md contient des instructions et des règles rédigées par l'utilisateur à l'échelle du projet, de l'utilisateur ou de l'organisation. L'auto-mémoire contient des apprentissages et des modèles écrits par Claude, stockés par dépôt et partagés entre les arborescences de travail (worktrees), avec les 200 premières lignes ou 25 Ko chargés à chaque session.

La hiérarchie pratique de la mémoire devrait être :

1. Règles strictes : placez-les dans CLAUDE.md ou dans des hooks.
2. Procédures répétables : placez-les dans des compétences (skills).
3. Préférences découvertes : laissez l'auto-mémoire les capturer, puis organisez-les si elles deviennent importantes.
4. Faits de session temporaires : gardez-les dans la conversation ou dans /btw, pas dans la mémoire.

N'écrivez pas de visites guidées de l'architecture dans la mémoire si Claude peut inspecter le dépôt. Écrivez plutôt des règles qui ne sont pas évidentes à partir du code : "ne jamais exécuter le script de réinitialisation destructrice en production", "les offres utilisent des centimes, pas des euros", "les posts LinkedIn doivent aller sur la page de l'entreprise". Ce sont ces détails qui préviennent les erreurs coûteuses.

Revue de code multi-agents : une seconde ligne de défense, pas l'autorité finale

La documentation sur la revue de code décrit la fonctionnalité de revue gérée comme une préversion de recherche pour les offres Team et Enterprise. Elle révise les pull requests GitHub, publie des commentaires en ligne et utilise une flotte d'agents spécialisés pour inspecter le contexte complet de la base de code à la recherche d'erreurs logiques, de vulnérabilités de sécurité, de cas particuliers défaillants (edge cases) et de régressions. Les découvertes sont classées par gravité et n'approuvent ni ne bloquent la PR. Sur les autres forfaits, la commande locale /code-review est toujours disponible dans le terminal.

Cette dernière contrainte est saine. La revue multi-agents ne doit pas remplacer la responsabilité humaine. Elle doit détecter ce que les humains manquent lorsque le diff est grand, que le relecteur est fatigué ou que le cas particulier est enfoui dans un autre fichier.

Utilisez-la avant une revue humaine lorsque :

• la modification traverse les limites des paquets,
• la branche touche à l'authentification, aux paiements, aux permissions ou à la suppression de données,
• le diff contient du code généré,
• l'implémentation a été majoritairement écrite par des agents,
• le relecteur a besoin d'une carte des risques avant de lire chaque ligne.

Ne l'utilisez pas comme une simple validation automatique. Un agent de revue peut mettre en évidence des risques, mais votre équipe reste responsable de la fusion (merge).

Une configuration pratique pour une équipe

Si vous adoptez Claude Code 2.0 au sein d'une équipe, commencez petit :

1. Installez et confirmez la version avec claude --version.
2. Ajoutez un fichier CLAUDE.md minimal contenant uniquement les règles non évidentes.
3. Créez une compétence pour le flux de travail le plus répété.
4. Apprenez aux développeurs quand utiliser /btw par rapport à un sous-agent.
5. Définissez les efforts par défaut par catégorie de risque.
6. Ajoutez /code-review avant la revue humaine sur les grosses branches.
7. Utilisez /loop uniquement pour des vérifications observables avec des conditions d'arrêt claires.

C'est suffisant. Vous n'avez pas besoin d'une plateforme complète dès le premier jour. La première victoire est une boucle plus propre : rassembler le contexte, agir, vérifier et garder le bruit hors du fil principal.

Définition de "Fait" (Definition of Done) pour l'adoption de Claude Code 2.0

• CLAUDE.md existe et ne contient que les règles actuelles et non évidentes du projet.
• Au moins un flux de travail d'équipe est passé d'un prompt copié-collé à une compétence.
• Les développeurs connaissent la règle d'utilisation entre /btw et un sous-agent.
• Les niveaux d'effort sont documentés pour les tâches à faible risque, normales et à haut risque.
• /code-review fait partie de la checklist des PR pour les diffs risqués ou fortement générés par des agents.
• Un prompt de boucle inclut un intervalle concret, une condition observable et une règle d'arrêt.
• La mémoire est révisée mensuellement afin que les règles obsolètes ne deviennent pas une dette technique cachée.

FAQ

Claude Code 2.0 est-il identique à Claude Code v2.1.227 ?

Pas exactement. "Claude Code 2.0" est la génération du produit à laquelle les gens font référence ; la v2.1.227 est la version actuelle vérifiée pour ce guide au 11 août 2026. Le numéro de version s'incrémente fréquemment — parfois quotidiennement — avec des correctifs de fiabilité, de nouvelles commandes slash et des ajustements de feature flags. Vérifiez toujours votre version installée avec claude --version et recoupez avec le changelog officiel avant de vous fier à une fonctionnalité spécifique. Si vous rédigez de la documentation ou des guides d'équipe, fixez la version que vous avez testée et notez la date de vérification.

Quand dois-je utiliser /btw plutôt qu'un sous-agent ?

Utilisez /btw lorsque la réponse dépend du contexte de la conversation en cours et ne nécessite pas d'outils. Par exemple, si vous voulez un résumé rapide de ce qui a été décidé jusqu'à présent, ou une vérification de bon sens pour savoir si un modèle d'erreur correspond à quelque chose de déjà discuté, /btw est le bon choix. Utilisez un sous-agent lorsque Claude doit inspecter des fichiers, exécuter des commandes, chercher dans des logs ou explorer quelque chose sans remplir le contexte principal. Un sous-agent commence avec une fenêtre de contexte vide mais dispose d'un accès complet aux outils, ce qui le rend idéal pour un travail d'investigation qui ne devrait pas polluer votre transcription de travail. La règle générale : si l'aparté ne doit pas modifier le plan et ne nécessite pas d'outils, utilisez /btw. Si la réponse pourrait affecter l'implémentation, ramenez-la dans le fil principal ou assignez un sous-agent.

Pour quoi /loop est-il le plus utile ?

/loop est idéal pour les vérifications répétées et observables : statut de déploiement, tests instables, complétion de file d'attente, scans de nettoyage ou maintenance périodique. L'essentiel est que chaque itération ait une condition de sortie claire — "arrête-toi après un passage réussi" ou "signale uniquement si le statut change". Évitez les boucles vagues comme "continue d'améliorer ça", car elles créent du travail sans ligne d'arrivée et consomment des jetons indéfiniment. Une boucle bien conçue remplace l'interrogation manuelle (polling) : au lieu de vérifier vous-même un déploiement toutes les 5 minutes, vous déléguez cela à Claude et n'êtes notifié que lorsque quelque chose change. Pour les systèmes d'agents en production, c'est le même modèle que nous utilisons pour la surveillance automatisée — les vérifications répétables sont utiles lorsque l'état est observable et que l'action est contrainte.

Quel niveau /effort dois-je utiliser ?

Utilisez un effort moindre pour les modifications mécaniques avec une vérification peu coûteuse : renommages, formatage, corrections de tests simples. Augmentez l'effort pour les décisions d'architecture, le débogage de problèmes complexes, les revues de sécurité, les migrations de données et tout ce pour quoi une mauvaise réponse coûte cher. Le curseur d'effort ne concerne pas la qualité ; il s'agit de faire correspondre la profondeur de raisonnement au risque. Un renommage à l'effort max gaspille des jetons sans améliorer le résultat. Une migration de données à effort low économise des jetons mais risque d'entraîner une perte de données subtile. L'approche pratique consiste à définir les paramètres par défaut de l'équipe par catégorie de tâches : faible (low) pour les changements mécaniques, moyen (medium) pour le travail normal sur les fonctionnalités, élevé (high) pour le débogage, et xhigh/max pour tout ce qui touche à l'authentification, aux paiements ou à l'intégrité des données. Révisez vos paramètres par défaut mensuellement au fur et à mesure que le modèle et les outils évoluent.

Les Compétences d'Agent (Agent Skills) remplacent-elles CLAUDE.md ?

Non. CLAUDE.md est destiné aux instructions et règles persistantes qui s'appliquent à chaque session — normes de codage, conventions de projet, règles de sécurité. Les compétences (skills) sont destinées aux procédures répétables qui ne doivent se charger que lorsque cela est pertinent — une checklist de migration, un modèle de note de version, un flux de travail de débogage. Si une checklist est longue ou spécifique à une tâche, elle a probablement sa place dans une compétence, pas dans la mémoire. Les deux mécanismes se complètent : CLAUDE.md établit les règles de base, et les compétences fournissent des procédures étape par étape qui s'activent à la demande. Considérez CLAUDE.md comme le manuel de l'équipe et les compétences comme les guides d'exploitation (runbooks). L'auto-mémoire capture les préférences et modèles découverts que ni le manuel ni les guides d'exploitation ne couvrent encore.

La revue de code multi-agents peut-elle remplacer la revue humaine ?

Non. C'est une seconde ligne de défense, pas un remplacement du jugement humain. La revue de Claude Code peut mettre en évidence des bugs, des problèmes de sécurité, des cas particuliers et des régressions qu'un relecteur fatigué pourrait manquer sur un gros diff. Mais l'équipe conserve la responsabilité de la décision de fusionner. La revue multi-agents est la plus précieuse avant une revue humaine lorsque le changement franchit les limites des paquets, touche à l'authentification ou aux paiements, contient du code généré ou a été principalement écrit par des agents. Dans ces cas-là, les agents de revue produisent une carte des risques qui aide le relecteur humain à se concentrer d'abord sur les zones aux enjeux les plus élevés. Traitez-la comme un multiplicateur de force : elle attrape ce que les humains manquent, mais elle n'a pas le contexte pour décider de ce qui est acceptable pour votre produit.

Sources

• Journal des modifications de Claude Code (Changelog) — Historique des versions et notes de publication pour la branche 2.1.x
• Référence des commandes de Claude Code — Documentation officielle pour /btw, /loop, /effort, /dataviz et les autres commandes slash
• Mode interactif de Claude Code — Comportement des sous-agents et de /btw, règles d'isolation du contexte
• Compétences (Skills) de Claude Code — Format du fichier SKILL.md, fichiers de support et invocation des compétences
• Mémoire de Claude Code — Hiérarchie du CLAUDE.md, auto-mémoire et continuité des sessions
• Revue de code par Claude Code — Revue de PR multi-agents, classification de la gravité et fonctionnalité de revue gérée