Meilleures pratiques pour Claude Opus 4.7

La plupart des gens passent à Opus 4.7 sans changer leurs habitudes. Ils modifient l'ID du modèle et continuent exactement comme avec Opus 4.6.

C'est laisser beaucoup de potentiel de côté.

Les recommandations d'Anthropic pour Opus 4.7 sont subtiles mais importantes : le modèle réfléchit plus à haute intensité, est plus sélectif sur les appels d'outils et les sous-agents, lit les instructions de façon plus littérale, et performe mieux quand tu le traites comme un ingénieur compétent à qui tu délègues une tâche, plutôt qu'un pair programmeur bavard que tu guides toutes les trente secondes.

Cette page est la version pratique de ces conseils. Elle combine les recommandations de lancement d'Anthropic, la documentation de Claude Code, et les patterns qui comptent vraiment dans les workflows d'ingénierie réels.

Pour la présentation du modèle, voir Claude Opus 4.7. Pour des exemples par domaine, voir les cas d'usage de Claude Opus 4.7.

Victoire rapide

Si tu veux une habitude qui améliore immédiatement tes résultats avec Opus 4.7 :

Here is the task, the constraint set, the files that matter, and the definition of done.
Do the full job, validate before you report back, and call out missing information instead of guessing.

Ce changement est important parce qu'Opus 4.7 performe mieux quand le premier tour lui donne assez d'espace pour réfléchir, planifier et exécuter sans avoir besoin de cinq corrections correctives.

1. Traite Opus 4.7 comme un délégué, pas un pair programmeur

C'est le changement de modèle mental le plus important.

Les anciens workflows de code ressemblaient souvent à ça :

1. donner un prompt vague
2. attendre une tentative partielle
3. ajouter une clarification supplémentaire
4. corriger l'approche
5. ajouter une autre contrainte

Ce style est coûteux avec Opus 4.7 parce que chaque nouveau tour utilisateur ajoute une surcharge de raisonnement et fait basculer le modèle dans une boucle plus interactive que ce dont il a besoin pour du travail difficile.

Le meilleur pattern :

1. énoncer clairement le travail dès le premier tour
2. inclure les vraies contraintes et critères d'acceptation
3. laisser le modèle avancer plus loin avant d'intervenir
4. examiner le résultat à un checkpoint significatif plutôt que de micromanager chaque étape

Premier tour médiocre :

Help me fix auth.

Bon premier tour :

Fix the OAuth redirect loop where successful login returns users to /login instead of /dashboard.

Constraints:
- keep the existing session format
- do not change provider configuration
- update tests if needed

Relevant areas:
- src/lib/auth.ts
- src/middleware.ts
- app/login/*

Definition of done:
- login succeeds
- user lands on /dashboard
- no redirect loop
- tests pass

Ce n'est pas du prompt-engineering de surface. C'est juste un meilleur brief de délégation.

2. Concentre tout au premier tour

Le post de meilleures pratiques d'Anthropic sur Opus 4.7 revient constamment là-dessus : si le travail est réel, donne au modèle le brief complet dès le départ.

Le premier tour devrait généralement inclure :

• la tâche réelle
• ce à quoi ressemble le succès
• ce qui ne doit pas changer
• quels fichiers, services ou répertoires sont concernés
• les références ou patterns existants à respecter
• comment le résultat sera validé

Tu cherches à éliminer deux modes d'échec :

• sous-spécification : le modèle doit deviner ce que tu voulais dire
• correction tour par tour : le modèle continue de payer un coût de raisonnement pour intégrer des corrections qui auraient dû être dans le brief initial

Bonne structure :

Task:
[what to build, fix, review, or investigate]

Constraints:
- [what must stay true]
- [what must be avoided]

Relevant context:
- [files, routes, services, tickets, docs]

Definition of done:
- [observable outcome]
- [verification step]

Ce pattern fonctionne pour le code, la revue, la sécurité, la documentation et le travail multimodal.

3. Utilise xhigh par défaut, pas max

Opus 4.7 a ajouté un niveau d'effort xhigh et Claude Code y a déplacé sa valeur par défaut pour une bonne raison.

xhigh est le meilleur défaut pour la plupart des travaux de code sensibles à l'intelligence, parce qu'il capture la majorité des avantages d'un raisonnement approfondi sans le comportement de "pensée incontrôlée" que max peut déclencher sur des tâches longues.

Règle pratique :

En cas de doute, commence à xhigh.

Descends à high quand :

• tu fais tourner plusieurs sessions en même temps
• la tâche est difficile mais pas critique
• tu veux mieux contrôler les dépenses

Passe à max seulement quand :

• la tâche est inhabituellement difficile
• le coût d'une erreur est élevé
• tu as vraiment besoin du plafond du modèle, pas juste "probablement mieux"

L'erreur commune est de laisser max activé parce que ça semble plus sûr. Ce n'est généralement pas le cas. Ça rend souvent le modèle plus lent et plus verbeux que nécessaire.

4. Oriente le taux de réflexion que tu veux

Opus 4.7 utilise la pensée adaptative, ce qui signifie que le modèle décide quand réfléchir plus intensément et quand avancer vite. C'est généralement bien. C'est toujours modulable.

Quand tu veux plus de réflexion :

This problem is subtle. Think carefully and step by step before acting.
Verify assumptions before you edit anything.

Quand tu veux moins de réflexion :

Prioritize a direct answer over deep reasoning.
Be concise and only inspect additional files if necessary.

Utilise ça avec parcimonie. N'empile pas douze méta-instructions. Une ou deux lignes suffisent.

Bons cas d'usage pour plus de réflexion :

• changements d'architecture
• migrations
• revue de code
• analyse de sécurité et des risques
• investigations avec des preuves incomplètes

Bons cas d'usage pour moins de réflexion :

• une modification ciblée dans un fichier que tu as déjà nommé
• questions de référence rapides
• refactors mécaniques simples

5. Dis à Opus 4.7 quand utiliser les outils

Anthropic dit explicitement qu'Opus 4.7 utilise les outils moins souvent par défaut et raisonne plus avant d'agir. C'est généralement une amélioration. Ça signifie aussi que le modèle peut inspecter moins que tu ne l'espères, sauf si tu lui dis autrement.

Si tu veux une investigation agressive, dis-le.

Au lieu de :

Review this service for bugs.

Utilise :

Review this service for bugs.
Read the relevant implementation files before concluding.
Use search and file reads aggressively where needed.
Do not rely on assumptions if you can verify them from the codebase.

C'est important pour :

• revue de code
• débogage
• revue de sécurité
• investigation dans une grande base de code
• écriture basée sur des sources

Le modèle n'est pas "mauvais avec les outils" maintenant. Il est simplement plus sélectif. Donne-lui la politique que tu veux.

6. Dis-lui quand utiliser les sous-agents

Anthropic dit aussi qu'Opus 4.7 lance moins de sous-agents par défaut. Encore une fois, c'est généralement rationnel. Ce n'est pas toujours ce que tu veux.

Si le travail bénéficie du parallélisme, dis-le dans le premier tour.

Exemple :

Use subagents when the work naturally splits.
Spawn multiple subagents in the same turn when fanning out across independent files or domains.
Do not spawn a subagent for work you can complete directly in one response.

Bons moments pour forcer le parallélisme :

• revoir plusieurs fichiers indépendants
• comparer plusieurs docs ou logs
• auditer différents domaines séparément : frontend, backend, base de données
• lire la base de code en parallèle avant l'implémentation

Mauvais moments pour forcer le parallélisme :

• un correctif sur un seul fichier
• des modifications étroitement couplées
• des tâches où le résultat de l'étape B dépend de l'étape A

Opus 4.7 est plus judicieux par défaut. C'est bien. Tu dois quand même spécifier ta politique d'orchestration quand le workflow en dépend.

7. Réduis les tours utilisateur sur le travail interactif

C'est l'une des recommandations les plus claires d'Anthropic et l'une des plus faciles à ignorer.

Chaque tour utilisateur supplémentaire ajoute une surcharge. Si tu travailles de façon interactive, regroupe tes questions et corrections au lieu de les distiller une par une.

Médiocre :

Actually change the schema too.

puis :

Also update tests.

puis :

Do not touch the billing UI.

Mieux :

Update the auth flow and schema, update tests, but do not modify the billing UI.
Keep the session format unchanged.

Ça ne signifie pas "ne jamais interrompre". Ça signifie interrompre aux frontières utiles, pas toutes les quelques secondes.

8. Utilise le mode auto seulement quand le brief est solide

Le mode auto et Opus 4.7 forment un duo puissant pour les tâches longues, mais seulement quand le périmètre est clair.

Le mode auto a du sens quand :

• la tâche est bien spécifiée
• le repo ou l'environnement est familier
• tu fais confiance à la direction générale
• tu veux moins d'interruptions pour permissions

Le mode auto ne convient pas quand :

• la tâche touche la production ou une infrastructure partagée
• l'objectif est encore flou
• tu t'attends à beaucoup de jugements humains
• l'environnement lui-même n'est pas de confiance ou inconnu

La séquence qui fonctionne :

1. écrire un bon brief au premier tour
2. vérifier que le plan semble cohérent
3. passer en mode auto pour l'exécution si la tâche est bien délimitée

N'utilise pas le mode auto pour compenser un brief faible. Ça fait juste avancer le modèle plus vite dans la mauvaise direction.

9. Coupe la friction des permissions plutôt que de cliquer dessus

L'un des meilleurs conseils de lancement de Boris Cherny pour Opus 4.7 était opérationnel, pas au niveau du modèle : si le modèle va tourner plus longtemps et de façon plus autonome, l'ancien workflow de permissions devient le goulot d'étranglement.

Il y a deux correctifs propres :

Mode auto pour le travail bien délimité

Si la tâche est claire et l'environnement de confiance, le mode auto supprime la plupart de la boucle "approuver, approuver, approuver" tout en maintenant des vérifications de sécurité en arrière-plan.

Convient bien :

• refactors longs dans un repo familier
• travail d'implémentation avec une définition de "done" claire
• investigations où tu fais confiance à la direction générale

Ne convient pas :

• environnements inconnus
• travail sensible en production
• tâches vagues où le modèle a encore besoin d'être beaucoup guidé

Pour les mécaniques approfondies, voir Claude Code Auto Mode et la documentation officielle des modes de permissions.

/fewer-permission-prompts pour les commandes sûres répétées

Boris a aussi mentionné une nouvelle compétence /fewer-permission-prompts. L'idée est simple : scanne ce que Claude a répétitivement été bloqué sur, puis transforme les commandes sûres et répétitives en règles de permissions explicites plutôt que de cliquer dessus indéfiniment.

C'est bien mieux comme workflow Opus 4.7 que les deux extrêmes :

• approuver manuellement la même commande inoffensive 20 fois
• passer directement au mode contournement total

La bonne cible, ce n'est pas "aucune sécurité". C'est "moins d'interruptions inutiles".

10. Utilise les récapitulatifs et le mode focus pour les longues exécutions autonomes

Opus 4.7 est meilleur quand tu le laisses tourner. Ça rend deux habitudes au niveau de l'interface beaucoup plus précieuses.

Récapitulatifs

Claude Code a livré les récapitulatifs dans 2.1.108, juste avant Opus 4.7. Boris les a mis en avant pour une bonne raison : si tu reviens sur une session longue après dix minutes ou deux heures, un court récapitulatif est mieux que d'essayer de reconstruire l'état à partir du défilement.

Les récapitulatifs sont particulièrement utiles quand :

• tu passes une tâche en arrière-plan
• tu reviens sur une session plus tard dans la journée
• une longue exécution a touché de nombreux fichiers ou phases
• tu veux le résumé "qu'est-ce qui s'est passé / quelle est la prochaine étape" rapidement

Pense aux récapitulatifs comme à une ré-entrée dans la session, pas juste une résumation.

Mode focus

Boris a aussi mentionné le nouveau mode focus dans le CLI. Le timing est logique : une fois que tu fais confiance à Opus 4.7 pour investiguer, modifier et vérifier plus indépendamment, le détail de la transcription peut devenir du bruit visuel.

Le mode focus est utile quand :

• tu te soucies plus du résultat final que de la transcription en direct
• le modèle fait tourner une longue séquence de commandes correctement
• tu veux examiner l'état final, pas regarder chaque action intermédiaire

C'est un changement de workflow qui vaut la peine d'être fait. Les modèles plus puissants déplacent le goulot d'étranglement de "peut-il faire le travail ?" à "combien de ce travail ai-je vraiment besoin de surveiller ?"

11. Configure l'effort délibérément

Le thread de Boris a aussi renforcé quelque chose que les docs d'Anthropic rendent maintenant beaucoup plus clair : traite l'effort comme un contrôle de première classe, pas un paramètre caché.

Règle pratique :

• effort plus bas pour des réponses rapides et des dépenses réduites
• effort plus élevé pour de l'ingénierie et de la revue plus difficiles
• ne pars pas du principe que "l'effort le plus élevé" est toujours le meilleur workflow

Ça compte davantage sur Opus 4.7 parce que la pensée adaptative laisse le modèle monter ou descendre en puissance bien plus naturellement que l'ancien style à budget fixe.

Garde ces valeurs par défaut :

• low ou medium pour les modifications rapides et les Q&R légers
• high quand tu veux un niveau de travail moins cher mais toujours capable
• xhigh pour de l'ingénierie quotidienne sérieuse
• max pour les tâches vraiment difficiles où le coût d'une erreur est élevé

Si tu ignores l'effort, tu laisses l'un des plus grands contrôles d'Opus 4.7 inutilisé.

12. Commence une nouvelle session quand la tâche change

Opus 4.7 a une fenêtre de contexte de 1M tokens. Ça ne signifie pas que tu dois garder chaque travail dans une session immortelle.

Les propres recommandations d'Anthropic sur la gestion des sessions sont directes : quand la tâche change, commence une nouvelle session.

Utilise la session actuelle quand :

• la prochaine étape fait partie de la même tâche
• le contexte actuel est toujours pertinent
• relire les mêmes fichiers serait du gaspillage

Commence une nouvelle session quand :

• tu passes à une tâche différente
• la session a accumulé plusieurs approches échouées
• tu as déjà corrigé le modèle deux ou trois fois
• le contexte contient maintenant plus de bruit que de signal

Utilise les outils de façon agressive :

• /clear pour les tâches sans rapport
• /rewind quand la dernière branche de travail était mauvaise
• /compact aux jalons naturels, pas au milieu d'un débogage fragile
• les sous-agents pour l'investigation, pour que le thread principal reste propre

Un grand contexte aide. La dégradation du contexte est bien réelle.

13. Donne à Opus 4.7 un harnais de vérification

Ce point est ressorti clairement du thread de Boris et correspond aux propres recommandations d'Anthropic : si tu veux le plus grand bond avec Opus 4.7, donne-lui un moyen de vérifier s'il a vraiment réussi.

L'une des meilleures qualités d'Opus 4.7 est qu'il est plus disposé à vérifier son propre travail. Aide-le.

Ajoute un langage de validation explicite :

Before you report done:
- verify assumptions you relied on
- run the relevant tests
- check the final changed files for consistency
- list remaining risk, if any

C'est particulièrement important pour :

• les migrations
• les changements d'auth
• les corrections de concurrence
• la revue de sécurité
• l'analyse basée sur des documents

Le modèle est plus auto-vérificateur que les versions précédentes. Tu veux quand même que "done" signifie quelque chose de concret.

Exemples concrets d'un harnais de vérification :

• travail backend : une commande de test, un check curl, ou un build typé
• travail frontend : un check navigateur, un diff de screenshot, ou un passage lint/build
• refactors : compile + test + grep pour l'ancienne surface d'API
• docs ou contenu : une checklist de claims à vérifier par rapport aux sources

Sans chemin de vérification, une autonomie plus longue signifie principalement une exécution non vérifiée plus longue. Avec un, ça devient une autonomie utile.

14. Utilise les budgets de tâches pour les longues exécutions

Anthropic a introduit les budgets de tâches en bêta publique parce que le travail agentique plus long a besoin d'un budget visible par le modèle, pas juste d'un plafond de sortie qu'il ne peut pas voir.

Si tu fais tourner des agents ou des charges de travail API, teste les budgets de tâches sur :

• des refactors longs
• des travaux de recherche + implémentation
• de l'automation en arrière-plan
• des boucles de revue et réparation de code

La meilleure pratique n'est pas "toujours utiliser le plus grand budget". C'est :

• donner au modèle assez d'espace pour terminer
• garder le budget fini
• mesurer quelles classes de travaux ont vraiment besoin de plus

Ça devient plus important sur Opus 4.7 parce que le modèle est heureux de dépenser plus de réflexion à des niveaux d'effort plus élevés sur des exécutions difficiles.

15. Calibre sur la réalité des tokens, pas le prix marketing

Opus 4.7 a conservé le prix catalogue d'Opus 4.6. Ça ne signifie pas que ta charge de travail coûte pareil.

Ton coût réel est affecté par :

• le nouveau tokenizer
• les dépenses de raisonnement plus élevées à des niveaux d'effort plus hauts
• le pipeline d'images plus grand
• le nombre de tours utilisateur que tu crées
• la fréquence à laquelle le modèle doit se remettre de prompts ambigus

Les meilleures pratiques ici sont simples :

• benchmark sur tes vraies charges de travail
• teste high versus xhigh
• utilise un effort plus faible sur des travaux plus petits
• sous-échantillonne les images dont tu n'as pas besoin en pleine fidélité
• arrête de traiter les clarifications répétées d'utilisateurs comme gratuites

Certains partenaires ont rapporté une meilleure qualité à un effort plus bas qu'Opus 4.6 n'en avait besoin. C'est de là que viennent les économies de coûts en pratique.

16. Trois templates de prompts à garder

Template 1 : Implémentation à fort enjeu

Implement [task].

Constraints:
- [must preserve]
- [must avoid]

Relevant files:
- [file/path]
- [file/path]

Working style:
- think carefully before acting
- verify assumptions from code, not guesses
- use subagents only when the work naturally splits

Definition of done:
- [observable outcome]
- [test or verification]

Template 2 : Revue et investigation

Investigate [problem].

Use tools and file reads aggressively where needed.
Do not guess if the codebase can answer the question.

I want:
- root cause
- files involved
- likely fix
- edge cases or risks

Template 3 : Analyse à forte densité documentaire

Review these materials and produce a decision memo.

Requirements:
- separate facts from interpretation
- call out ambiguity explicitly
- list what evidence is missing
- cite the exact source section when possible

17. Les plus grosses erreurs à éviter

Les habitudes qui gaspillent le plus Opus 4.7 :

• premiers tours vagues
• laisser max activé pour le travail de routine
• garder la friction de permission par défaut même après avoir identifié quelles commandes sont sûres
• ignorer les récapitulatifs puis se réorienter manuellement dans de longues sessions
• regarder chaque ligne de transcription alors que le mode focus faciliterait la revue
• supposer que le modèle va investiguer de façon agressive sans être dit de le faire
• supposer qu'il va se déployer vers les sous-agents automatiquement comme le faisaient les anciens workflows
• laisser des tâches sans rapport s'accumuler dans une seule session
• juger le coût uniquement par le prix catalogue plutôt que le comportement réel des tokens

La plupart des plaintes "Opus 4.7 est trop cher" sont en réalité des plaintes de workflow déguisées en étiquettes de prix.

Sources

• Best practices for using Claude Opus 4.7 with Claude Code
• Using Claude Code: session management and 1M context
• Claude Code best practices docs
• Claude Code permission modes
• Claude Code changelog
• Claude Code commands
• Boris Cherny, launch-day X thread on Opus 4.7 workflow tips, April 16, 2026
• Introducing Claude Opus 4.7

Pages liées

• Claude Opus 4.7
• Claude Opus 4.7 use cases
• Claude Code Pricing and Token Usage
• Claude Code Auto Mode
• Claude Code Models