Claude Code Best Practices : prompts, dérive des agents et 6 fonctions

Vous allez découvrir comment diagnostiquer méthodiquement les prompts qui basculent après un changement de modèle, à quoi vous reconnaissez que votre agent Claude Code se dégrade peu à peu, et quelles six fonctions vous laissez probablement inutilisées. Cet article remet en perspective les bonnes pratiques d'une conférence Anthropic à l'intention des équipes de développement et des responsables techniques de PME, et les confronte à la documentation officielle.

À propos de la source : L'analyse porte sur un montage vidéo de plusieurs sessions de la conférence Anthropic « Code with Claude » à Londres (19 mai 2026). Deux intervenants sont identifiables avec certitude : Margot van Laar, Applied AI Engineer chez Anthropic (talk sur le prompting), et Ivan Nardini, Developer Advocate chez Google Cloud (talk partenaire). Toutes les affirmations ont été vérifiées dans la documentation officielle (liste complète des sources en fin d'article).

Les chiffres issus de démos en direct sont des observations isolées, pas des benchmarks – ils sont marqués dans le texte par « (démo) » ; les conseils pratiques non étayés des intervenants par « (heuristique des intervenants) ». Date de cet article : 13 juillet 2026. Au moment de la conférence, Claude Opus 4.7 et Sonnet 4.6 étaient d'actualité. Désormais disponibles : Opus 4.8 et Claude Fable 5 (accès à l'offre promotionnelle Fable 5).

Comment bien formuler ses prompts pour Claude ?

Avant toute correction de prompt, construisez d'abord une suite d'évaluation qui fournit le diagnostic. Un prompt qui tourne en production depuis des mois et dont des cas de test échouent soudain lors d'un changement de modèle peut avoir deux causes (recommandation de Margot van Laar dans le talk sur le prompting).

Soit le nouveau modèle se comporte simplement différemment – cela peut se corriger par le prompt. Soit il est tout bonnement moins capable pour la tâche – dans ce cas, aucun réglage du prompt n'aide, seul un autre modèle ou une autre architecture le fera.

Votre suite d'évaluation a besoin de trois groupes de cas :

• Control-Cases – doivent toujours réussir, car ils sont incontestables.
• Edge-Cases – des cas sur lesquels le modèle a déjà échoué de façon avérée.
• Cas aux limites de compétence – vérifient si le modèle reconnaît quand il devrait escalader ou refuser clairement une demande, au lieu de s'aventurer dans des compétences qu'il n'a pas.

Nettoyez le prompt seulement ensuite, au lieu de peaufiner immédiatement la formulation. Les prompts qui grossissent au fil des mois accumulent du lest : des correctifs obsolètes pour des générations de modèles antérieures, des textes de site web copiés, des instructions contradictoires. Règle empirique : si, à la lecture, vous ne distinguez plus entre rôle, guideline, policy, tonalité et données, le modèle en est encore moins capable.

Séparez ces éléments structurellement avec des balises XML – rôle, guidelines, policy, tonalité et données utiles dans des blocs distincts. Ajoutez un output contract et, au niveau de l'API, des stop sequences qui sécurisent le format de la réponse.

Dans les objectifs, citez toujours les deux côtés d'un arbitrage – jamais un seul. Dans l'exemple présenté, le prompt d'un bot de support disait en substance : éviter l'escalade vers un humain, car elle coûte environ 8 dollars US (démo). Le bot n'escaladait ensuite plus, même quand cela aurait été nécessaire, par exemple en cas de véritable erreur de facturation.

La solution : nommer les deux côtés – le coût de l'escalade et le coût de la non-escalade (remboursements, perte de confiance). Plus un modèle devient capable, plus il optimise de façon conséquente l'objectif explicitement formulé. Un objectif formulé d'un seul côté n'est donc pas interprété avec plus de tolérance, mais suivi plus strictement – mentionner les deux côtés devient plus important avec des modèles plus puissants, pas moins.

Résolvez les tâches soumises à des contraintes strictes par une boucle Generate-Evaluate-Repair plutôt que par un seul grand modèle. Lors d'une démo en direct, un prompt simple a échoué à établir un planning hebdomadaire avec des contraintes strictes (disponibilité du personnel, effectif minimum) (démo). Un grand modèle avec thinking étendu a certes résolu la tâche complètement, mais a nécessité environ trois fois plus de tokens et, en conséquence, davantage de latence (démo).

La solution la plus économique et la plus fiable était une boucle de trois prompts simples et distincts :

1. Le Generator produit un brouillon.
2. L'Evaluator le vérifie règle par règle, avec une preuve pour chaque violation.
3. Le Repair corrige de façon ciblée uniquement les problèmes signalés.

Résultat : tous les cas de test résolus, à un coût inférieur à celui du grand modèle seul. Effet secondaire pratique : les règles complémentaires souples et dépendantes du cas – par exemple « la personne A ne devrait si possible pas être affectée avec la personne B » – passent simplement dans le prompt de l'Evaluator, au lieu de modifier une fonction de contrôle stricte dans le code.

Pourquoi mon agent Claude se dégrade-t-il avec le temps ?

À quoi reconnaissez-vous que votre agent est gonflé :

• Le prompt système a grossi au fil des mois, et plus personne n'ose y supprimer quoi que ce soit.
• Plusieurs de vos outils sont en réalité des sous-agents déguisés avec leur propre logique.
• Le taux de réussite de vos évaluations baisse insidieusement, sans qu'une modification isolée semble en être responsable.
• Le modèle assume un travail de raisonnement pour lequel il aurait en réalité besoin d'un outil.

Première étape : laissez Claude trier lui-même les échecs de vos évaluations. Dans un atelier de la conférence consacré à la décomposition d'agents, un agent de gestion d'inventaire a servi d'étude de cas (démo) – au fil des mois, il avait atteint environ 400 lignes de prompt système et douze outils, dont trois sous-agents déguisés. Le taux de réussite des évaluations était passé de 83 à 62 pour cent.

Les participants à l'atelier n'ont pas posé le diagnostic eux-mêmes : ils ont laissé Claude Code trier les résultats de leurs propres évaluations et extraire les thèmes d'échec. Résultat : le modèle assumait beaucoup de travail de raisonnement pour lequel il aurait fallu des outils, la structure de sortie des sous-agents n'était pas correctement imposée, et le prompt système trop long provoquait des contradictions.

Reconstruisez l'agent de façon radicalement plus légère une fois le diagnostic posé. La refonte l'a ramené à un prompt de 15 lignes, trois outils (Bash, Read, Write), des Skills pour la logique métier et exactement un sous-agent restant pour la prévision des ventes.

Une tâche qui consommait auparavant plus de 200 000 tokens, parce qu'un fichier CSV complet était chargé dans le contexte, est devenue nettement moins chère après le passage à l'accès au système de fichiers et à l'exécution de code (démo). Claude écrit et exécute lui-même du Python, au lieu de traiter les données brutes « de tête ». Le schéma sous-jacent : les agents grossissent par ajouts successifs, personne ne retire rien, et à un moment le prompt contient plus de lest que de substance.

Le levier contre cela : les Agent Skills. Anthropic les définit officiellement comme des « packages » composés d'instructions, de métadonnées et de ressources. Le principe de conception central est la progressive disclosure : les Skills se chargent en trois étapes – d'abord uniquement le frontmatter (nom plus courte description), puis, au besoin, le corps, puis les fichiers complémentaires liés.

Le contexte reste léger tant qu'une Skill n'est pas nécessaire, et les Skills peuvent être combinées (documentation officielle). Si vous souhaitez faire développer un agent pour votre propre entreprise, vous trouverez chez nous un point de départ sous faire développer des agents IA. Un prompt léger plus des Skills plutôt qu'un prompt système monolithique est désormais un élément central d'une architecture d'agent professionnelle.

Pour le choix des outils, suivez cet ordre (heuristique des intervenants) : d'abord des primitives intégrées (Bash, système de fichiers, recherche web), puis, au besoin, des outils personnalisés, et des serveurs MCP seulement quand plusieurs clients ou agents doivent partager le même jeu d'outils. L'idée de base est étayée par la documentation : le blog d'ingénierie d'Anthropic recommande d'exécuter les serveurs MCP via du code (« Code execution with MCP ») – ce qui apporte des avantages en tokens et en latence par rapport à de nombreuses définitions d'outils MCP placées directement dans le contexte.

Utilisez les sous-agents de façon ciblée, pas par défaut. Ils valent surtout la peine en cas de véritable parallélisation – de nombreuses instances de Claude travaillant simultanément sur un problème, par exemple pour explorer une base de code. Ou lorsque vous avez besoin d'un contexte neuf, non pollué : un relecteur qui n'est pas le même agent que l'auteur. Tout le reste se résout généralement plus simplement directement dans l'agent principal, complété par une Skill adaptée.

Quelles fonctions de Claude Code la plupart des équipes négligent-elles ?

Six fonctions modestes mais efficaces au quotidien sont, selon les intervenants, utilisées par très peu d'équipes. Un contrôle rapide pour voir ce qui manque dans votre workflow :

1. Esc+Esc / /rewind – Appuyer deux fois sur Échap avec une ligne de saisie vide ouvre un menu de rewind qui permet de ramener le code et/ou la conversation à un point antérieur. Quand un agent s'est fourvoyé, c'est souvent plus rapide qu'un nettoyage manuel (documentation).
2. Hiérarchie CLAUDE.md – Au démarrage, Claude Code charge intégralement le CLAUDE.md du répertoire de travail actuel, ainsi que tous les fichiers CLAUDE.md des répertoires parents et le ~/.claude/CLAUDE.md global. Les CLAUDE.md des sous-dossiers ne sont en revanche pas chargés automatiquement au démarrage, mais seulement en cas de besoin. La syntaxe de chemin avec @ permet en outre d'importer d'autres fichiers. Contenu recommandé : commandes de build, style de code, workflows récurrents – des choses qu'il faudrait sinon réexpliquer à chaque nouveau chat (documentation).
3. /model et /config – Le modèle et la configuration peuvent être changés à tout moment directement dans la session (documentation), sans nouvelle session pour des sous-tâches de difficulté différente.
4. Interleaved thinking – fini le « think hard » – Depuis la génération Claude 4, Claude continue de réfléchir aussi entre les appels d'outils, et pas seulement une fois au début d'une réponse (Anthropic appelle cela interleaved thinking). Dans la vidéo de la conférence, « think hard » était encore cité comme déclencheur – c'est dépassé. Selon la documentation actuelle, seul « ultrathink » est le mot déclencheur reconnu par Claude Code pour le thinking étendu ; d'autres formulations comme « think hard » sont désormais traitées comme du texte ordinaire (documentation Extended Thinking, documentation Model Config).
5. Régulateur d'effort et Auto-Mode – Cinq niveaux officiels – low, medium, high, xhigh, max – commutables via /effort, auxquels s'ajoute un mode /fast distinct. Shift+Tab permet de faire défiler les Permission-Modes, dont l'Auto-Mode. La documentation recommande l'Auto-Mode sous condition : lorsque vous faites confiance à la direction de la tâche, pas de façon générale (documentation Model Config, documentation Interactive Mode) :

6. Sessions parallèles via les worktrees Git – pas un bricolage, mais une bonne pratique officiellement documentée : plusieurs sessions travaillent simultanément sur différentes branches sans se gêner (documentation Best Practices). Pour les équipes sans expérience du parallélisme, c'est souvent l'étape la plus simple vers un meilleur débit, sans toucher à l'architecture des prompts ou des agents.

Que sont les Routines, les Memory Stores et les Dreams ?

Examinez ces cinq briques de plateforme si vous voulez exploiter des agents durablement et avec une mémoire – et pas seulement de façon interactive dans une session isolée. Elles constituent le second grand bloc thématique de la conférence. Précision importante au préalable : toutes les briques citées ici ont officiellement le statut Beta ou Research Preview – ce ne sont pas des produits généralement disponibles et parvenus à maturité, mais des fonctions en évolution.

La base est formée par Claude Managed Agents (Beta) : un agent harness préconstruit dans une infrastructure gérée, au choix la sandbox cloud propre à Anthropic ou un hébergement autonome (self-hosted). Avantage par rapport à une boucle d'agent faite maison : pas de sandboxing propre, pas de mise à l'échelle ni de gestion de sessions à gérer soi-même – vous vous concentrez sur les outils, les Skills et les sous-agents.

Les Multi-agent sessions s'appuient dessus – appelées encore « callable agents » dans la vidéo, officiellement Multi-agent sessions. Un coordinateur délègue à jusqu'à 20 agents, chacun dans son propre thread de session avec événements intégrés et observabilité. Cela répond à un problème connu des architectures multi-agents faites maison : la communication entre l'orchestrateur et les sous-agents se perd facilement, et la journalisation sur plusieurs agents est fastidieuse.

Pour une mémoire qui dépasse les sessions individuelles, il existe les Memory stores (Beta) : un stockage persistant et versionné sous /mnt/memory/, au choix en read_write ou read_only au niveau du système de fichiers. Chaque modification crée une nouvelle version immuable servant de piste d'audit, gérable par API, CLI ou console. Limites : huit Memory Stores par session, 2 000 Memories par store.

Comme ces mémoires deviennent confuses avec le temps, il existe les Dreams (Research Preview, accès sur demande). Un job asynchrone produit, à partir d'un Memory Store et de 1 à 100 transcriptions de sessions, un nouveau Memory Store distinct – vérifié, dédupliqué, réorganisé. Le store d'entrée reste inchangé.

Pour les exécutions proactives, déclenchées par le temps ou par des événements, il existe les Routines (Research Preview) : de véritables sessions Claude Code complètes sur l'infrastructure cloud d'Anthropic, déclenchées par un planning (intervalle d'au moins une heure), un déclencheur API (HTTP POST avec Bearer token) ou des événements GitHub comme les pull requests/releases, filtres inclus. Créées via /schedule, disponibles pour les comptes Pro, Max, Team et Enterprise.

Trois patterns d'équipe issus du talk :

• Un duo générateur-critique : une Routine ouvre des pull requests, une seconde les relit automatiquement.
• Un vérificateur de déploiement via un webhook de CD.
• Une priorisation hebdomadaire automatisée du backlog.

Pour situer ces cinq briques, voici un aperçu compact :

Comment vérifier ce que Claude a construit ?

Construisez votre vérification de façon que non seulement les humains, mais aussi les agents puissent la contrôler de manière fiable. Une équipe interne d'Anthropic prépare ainsi les modifications front-end – via des fixtures Storybook, des attributs de données DOM qui reflètent l'état d'un composant de façon lisible par machine, ainsi que le Playwright MCP officiel de Microsoft.

Idée centrale : trois voies de contrôle équivalentes vers le même résultat.

• Un humain parcourt l'application manuellement.
• Un agent pilote le même parcours dans le navigateur.
• Le même parcours s'exécute en headless dans la CI.

Chaque exécution est enregistrée et archivée comme preuve.

Construisez les spécifications sous forme d'artefact HTML cliquable, pas de long document Markdown. C'est plus dense en information et plus facile à évaluer qu'un texte continu que presque personne ne lit de toute façon en entier.

Laissez Claude vous interviewer activement via le mécanisme AskUserQuestion – Claude pose alors des questions structurées avec des options de réponse, au lieu de se lancer immédiatement –, au lieu de devoir tout formuler vous-même à l'avance. Pour les décisions de design, faites en plus générer plusieurs variantes en parallèle et comparez-les visuellement.

Cela est devenu plus praticable parce qu'Opus 4.7 traite, selon Anthropic, nettement plus de résolution d'image que son prédécesseur : jusqu'à 2 576 pixels de côté (environ 3,75 mégapixels, trois fois plus qu'Opus 4.6). Dans le benchmark de Visual Acuity, le modèle atteint 98,5 au lieu de 54,5 pour cent pour Opus 4.6 (Anthropic).

Si vous souhaitez mettre en place de tels workflows de vérification et d'interview dans votre entreprise, notre cours Certificat IA vous offre une introduction pratique à cette façon de travailler avec Claude.

Claude Code fonctionne-t-il aussi sur Google Cloud ?

Oui – et, pour les entreprises disposant déjà d'une infrastructure Google Cloud, c'est plus qu'une note en marge. Dans le talk partenaire, Ivan Nardini, Developer Advocate chez Google Cloud, a montré comment Claude Code fonctionne sur l'Agent Platform de Google Cloud (anciennement Vertex AI). Trois choses changent lors de la mise en place :

• Authentification : Application Default Credentials au lieu d'une clé d'API, activées via la variable d'environnement CLAUDE_CODE_USE_VERTEX=1 – pas de clé distincte à faire tourner.
• Facturation : vous payez soit à la consommation de tokens, soit vous réservez du Provisioned Throughput avec une capacité réservée pour les applications de production.
• Gouvernance : vos requêtes passent par votre propre projet GCP, avec ses droits IAM, ses quotas et sa facturation ; la gouvernance des données et la Zero-Data-Retention sont documentées séparément par Google (documentation Claude Code, documentation Google Cloud).

S'y ajoutent des endpoints globaux et régionaux, selon les exigences de disponibilité et de résidence des données. Pour l'accès aux bases de données, le talk a cité MCP Toolbox for Databases – open source de Google (googleapis/mcp-toolbox) –, qui connecte les agents à BigQuery et Looker.

Pour les PME disposant d'une infrastructure GCP existante, cela signifie concrètement : vous intégrez un agent Claude Code dans votre structure existante de gouvernance et de coûts sans gestion de clés supplémentaire, au lieu de construire un monde de facturation parallèle.

Pour les décideurs : que cela signifie-t-il pour les équipes de développement ?

Le goulot d'étranglement du développement logiciel se déplace – de l'écriture du code vers la revue, la vérification et la coordination (thèse issue du talk de clôture).

Quand le codage n'est plus le facteur limitant, les goulots se déplacent là où il y avait auparavant de la capacité : qui vérifie le code généré ? Qui assure la coordination entre les membres de l'équipe et les agents qui travaillent en parallèle ? Comment le savoir se transmet-il quand quelqu'un travaille de façon productive avec des agents dès le premier mois ?

Au sein d'Anthropic, ces points évoluent ainsi (expressément présenté comme pratique interne, pas comme recommandation générale) :

• La revue de code n'a plus lieu systématiquement, mais à la discrétion des humains, selon le risque de la modification.
• La planification se fait just-in-time plutôt que sous forme de longue roadmap, qui est de toute façon périmée après quelques mois.
• Les débats techniques de fond passent de plus en plus par plusieurs pull requests concurrentes réellement générées plutôt que devant un tableau blanc – on décide sur le code achevé, avec son impact sur tous les appelants, et non sur l'argumentation la plus convaincante en réunion.
• Un point d'étape hebdomadaire sous forme de tableur a cédé la place à une Skill de standup dédiée, qui rassemble l'état d'avancement de façon automatisée.

Renoncez au simple volume de code comme indicateur de réussite – « X pour cent du code généré par l'IA » en dit peu sur la qualité ou l'utilité. Mesurez plutôt le temps d'onboarding, le temps de cycle des PR jusqu'au merge et la part de commits assistés par l'IA comme signal de contexte.

Ces indicateurs ne sont pas une fin en soi, mais montrent si la revue, la CI et le déploiement suivent le débit. Vérifiez donc d'abord si votre processus de revue et de vérification suit ce que Claude Code produit aujourd'hui – avant d'investir dans davantage d'outillage d'agents.

Questions fréquentes

Comment convertir d'anciens prompts à ultrathink ?

Parcourez systématiquement vos bibliothèques de prompts et vos modèles à la recherche de la formulation « think hard » et remplacez-la par « ultrathink ». Raison : selon la documentation actuelle de Claude Code, seul « ultrathink » est un mot déclencheur reconnu pour le thinking étendu – « think hard » est aujourd'hui traité comme du texte ordinaire et ne déclenche plus de raisonnement supplémentaire. Dans la vidéo de la conférence, « think hard » était encore cité comme déclencheur ; c'était correct au moment de l'enregistrement, mais c'est désormais dépassé.

Est-ce rentable pour une petite équipe, ou seulement pour de grandes organisations de développement ?

Les bases – débogage de prompts appuyé sur des évaluations, hygiène du CLAUDE.md, rewind, niveaux d'effort, Skills légères plutôt que prompts gonflés – fonctionnent quelle que soit la taille de l'équipe et ne coûtent rien de plus. La plateforme d'agents (Managed Agents, Routines, Memory Stores, Multi-agent Sessions) est liée aux comptes Pro, Max, Team ou Enterprise et porte le statut Beta ou Research Preview. Pour une équipe de cinq personnes, il vaut généralement mieux commencer par les bases et n'aborder les briques de plateforme que plus tard, face à un besoin concret.

Quand ai-je besoin d'un serveur MCP plutôt que d'un outil personnalisé ?

Selon l'heuristique des intervenants, optez pour MCP dès que plusieurs clients ou plusieurs agents doivent utiliser le même jeu d'outils standardisé – par exemple lorsque le même outil de système de tickets est utilisé par l'agent de support et par la configuration Claude Code des développeurs. Pour un projet à agent unique, des primitives intégrées comme Bash, le système de fichiers et la recherche web, ainsi que, au besoin, de simples outils personnalisés, suffisent généralement.

Ai-je besoin de ma propre infrastructure serveur pour les Routines ?

Non. Les Routines s'exécutent comme de véritables sessions Claude Code complètes sur l'infrastructure cloud propre à Anthropic et démarrent via un planning, un appel d'API ou des événements GitHub. La fonction porte actuellement le statut Research Preview et est disponible pour les comptes Pro, Max, Team et Enterprise.

Par quoi commencer demain ?

Construisez d'abord une petite suite d'évaluation avec des cas de contrôle, des edge cases et des cas aux limites de compétence pour votre prompt le plus important – sans évaluations, chaque modification de prompt reste une devinette. Vérifiez en parallèle que votre CLAUDE.md est à jour, et faites trier par Claude lui-même un agent gonflé à partir des échecs d'évaluation.

Sources

Le point de départ de cet article était une vidéo de @ajitcodes sur X (https://x.com/ajitcodes/status/2076501882319810994) avec des enregistrements de sessions de la conférence Code with Claude – toutes les affirmations ont été vérifiées et complétées à l'aide des sources primaires suivantes :

• Code with Claude London – page officielle de la conférence
• Anthropic : Claude Opus 4.7
• Anthropic : Claude Sonnet 4.6
• Documentation Claude Code : Interactive Mode
• Documentation Claude Code : Memory (CLAUDE.md)
• Documentation Claude Code : Commands
• Documentation Claude : Extended Thinking
• Documentation Claude Code : Model Config
• Documentation Claude Code : Best Practices
• Documentation Claude : Agent Skills Overview
• Anthropic Engineering : Equipping Agents for the Real World with Agent Skills
• Anthropic Engineering : Code Execution with MCP
• Documentation Claude : Managed Agents Overview
• Documentation Claude : Multi-agent Sessions
• Documentation Claude : Memory Stores
• Documentation Claude : Dreams
• Documentation Claude Code : Routines
• GitHub : Microsoft Playwright MCP
• Documentation Claude Code : Google Vertex AI
• Documentation Google Cloud : Partner Models
• GitHub : Google MCP Toolbox for Databases

Les fonctions Beta et Research Preview peuvent changer à tout moment ; toutes les indications sont fournies d'après la documentation des éditeurs, sans garantie.