Aller au contenu principal

Claude Sonnet 5 : le nouveau modèle agent par défaut pour Claude Code

· 10 minutes de lecture
Claude Dev
Claude Dev
Claude Dev

Anthropic a publié Claude Sonnet 5 le 30 juin 2026, en le présentant comme le modèle Sonnet le plus agentique à ce jour et le nouveau modèle par défaut pour les utilisateurs Claude Free et Pro.

Le message est clair : Sonnet 5 apporte dans une couche moins chère, plus rapide et largement disponible une grande partie du travail agentique qui exigeait récemment des modèles de classe Opus. Il peut planifier, utiliser navigateurs et terminaux, gérer de longues tâches de code, et fonctionne avec adaptive thinking par défaut.

Pour les utilisateurs Claude Code, Sonnet 5 est plus important qu'un simple rafraîchissement de modèle. Il va probablement devenir la couche d'exécution par défaut de nombreuses équipes : pas le modèle le plus fort d'Anthropic, mais celui que les développeurs utiliseront le plus souvent.

La mise à niveau n'est pas sans friction. Sonnet 5 a un nouveau tokenizer, un comportement API différent autour de thinking et des sampling parameters, des cyber safeguards temps réel, et un prix moins cher qu'Opus par token mais pas toujours par tâche.

Ce qu'Anthropic a livré​

Le post de lancement d'Anthropic décrit Sonnet 5 comme une amélioration majeure par rapport à Sonnet 4.6 pour le reasoning, le tool use, le coding et le knowledge work. L'entreprise affirme qu'il réduit l'écart avec Opus 4.8 tout en restant moins cher.

Les détails opérationnels comptent :

  • Model ID : claude-sonnet-5.
  • Disponibilité : modèle par défaut pour Free et Pro, disponible pour Max, Team, Enterprise, Claude Code et Claude Platform.
  • Fenêtre de contexte : 1M tokens par défaut et au maximum.
  • Sortie maximale : 128k tokens sur l'API Messages synchrone.
  • Prix : prix de lancement de 2 dollars par million de tokens d'entrée et 10 dollars par million de tokens de sortie jusqu'au 31 août 2026. Le prix standard sera ensuite 3/15 dollars.
  • Adaptive thinking : activé par défaut pour Claude Code et l'API.
  • Cyber safeguards : safeguards de cybersécurité temps réel activés par défaut, une première pour un modèle Sonnet-tier.

La position pratique est simple : Sonnet 5 ne cherche pas à remplacer Fable ou Mythos. Il cherche à rendre le travail agentique routinier.

Les retours positifs : il termine plus de travail​

Le signal positif le plus fort est cohérent entre les citations de partenaires officiels et les premiers tests médias : Sonnet 5 est meilleur pour terminer des travaux multi-étapes, pas seulement répondre à un prompt.

Les partenaires early access d'Anthropic décrivent des progrès en sustained coding, debugging, respect des conventions, brownfield code et pull requests menées jusqu'à un résultat testé. Le motif utile n'est pas "il écrit un meilleur texte". C'est "il continue, se vérifie davantage, et arrive à un résultat fini avec moins de relances".

Le test hands-on de TechRadar a trouvé la même chose hors du code. En chat ordinaire, Sonnet 5 ne semblait pas radicalement différent des autres assistants. Quand on lui demandait de finir un travail, comme planifier un voyage ou créer un budget tracker familial, Claude semblait mieux organisé autour de l'achèvement de la tâche.

Pour Claude Code, cette différence compte. Les meilleurs cas d'usage de Sonnet 5 ne sont pas les snippets en un tour, mais des workflows comme :

  • enquêter sur un bug, écrire un test de reproduction, corriger et vérifier ;
  • migrer un module tout en respectant les conventions du projet ;
  • inspecter une codebase confuse et produire un plan par étapes ;
  • utiliser terminal et browser tools pour collecter des preuves ;
  • produire un artifact, le réviser, et garder une sortie cohérente.

C'est là que Sonnet 5 devrait dépasser Sonnet 4.6 dans le travail quotidien des développeurs.

Benchmarks : plus fort, mais pas encore Opus​

La couverture publique reprend deux signaux benchmark utiles.

TechRadar rapporte un score Anthropic de 80,5 % sur Terminal-bench 2.1 agentic coding pour Sonnet 5, contre 67 % pour Sonnet 4.6. ITPro rapporte 63,2 % sur SWE-bench Pro pour Sonnet 5, contre 58,1 % pour Sonnet 4.6 et 69,2 % pour Opus 4.8.

La forme est claire :

  • Sonnet 5 est une vraie amélioration face à Sonnet 4.6.
  • Opus 4.8 reste plus fort sur les tâches de code les plus difficiles.
  • Sonnet 5 peut approcher ou égaler Opus 4.8 sur certaines tâches à effort élevé.
  • La valeur principale est la flexibilité coût-performance, pas la qualité frontier absolue.

La documentation d'Anthropic insiste aussi sur les courbes coût-performance à différents effort levels sur BrowseComp et OSWorld-Verified. Le point important n'est pas un seul chiffre de leaderboard. C'est que les équipes peuvent maintenant ajuster effort et coût sur un modèle Sonnet-class au lieu de passer directement à Opus.

Le coût caché de migration : les tokens ont changé​

Le plus gros détail d'implémentation est le nouveau tokenizer.

Anthropic indique que le même texte d'entrée produit environ 30 % de tokens en plus sur Sonnet 5 que sur Sonnet 4.6, selon le contenu. Cela ne change pas la forme de l'API, mais change les budgets.

Cela affecte :

  • les token counts dans les logs ;
  • l'économie du prompt cache ;
  • les limites max output ;
  • la planification de la fenêtre de contexte ;
  • les estimations de coût pour des prompts équivalents ;
  • les comparaisons d'eval contre Sonnet 4.6.

Le prix de lancement n'est donc pas toute l'histoire. Même si le prix standard par token reste 3/15 dollars, le même workload peut consommer plus de tokens. Les équipes doivent recompter leurs prompts sous Sonnet 5 avant de supposer que la migration est neutre en coût.

Changements API à ne pas manquer​

Sonnet 5 n'est un remplacement drop-in que si votre code évite les réglages obsolètes ou non supportés.

Les docs signalent trois changements :

  1. Adaptive thinking est activé par défaut. Les requêtes sans champ thinking qui tournaient sans thinking sur Sonnet 4.6 utilisent maintenant adaptive thinking. Pour le désactiver, passez thinking: {type: "disabled"}.
  2. Manual extended thinking est supprimé. thinking: {type: "enabled", budget_tokens: N} renvoie une erreur 400. Utilisez adaptive thinking avec le paramètre effort.
  3. Les sampling parameters ne sont plus acceptés. Des valeurs non par défaut pour temperature, top_p ou top_k renvoient une erreur 400. Utilisez les instructions du system prompt pour guider le comportement.

Pour les utilisateurs Claude Code, cela signifie qu'il faut auditer les anciens wrappers et agent harnesses personnalisés avant de changer de model ID. Une mise à niveau de modèle peut devenir un bug de production si le client envoie encore de vieux paramètres.

Safety : mieux que Sonnet 4.6, moins fort qu'Opus​

Anthropic affirme que Sonnet 5 a des taux plus faibles d'hallucination et de sycophancy que Sonnet 4.6, et de meilleurs résultats en agentic safety. Il refuse aussi plus volontiers les requêtes malveillantes et résiste mieux aux hijackings de type prompt injection.

Mais l'entreprise indique aussi que Sonnet 5 montre encore plus de comportements misaligned qu'Opus 4.8 et Claude Mythos Preview sur son automated behavioral audit.

Le sujet cyber est précis. Sonnet 5 n'a pas été entraîné délibérément pour la cybersécurité. Il peut réaliser des tâches cyber routinières et non nuisibles, mais sur les évaluations cyber dangereuses il est beaucoup moins performant qu'Opus 4.8 et Mythos 5. Comme il est tout de même plus fort que Sonnet 4.6, Anthropic l'a lancé avec des cyber safeguards temps réel activés par défaut.

Pour les équipes sécurité, la lecture pratique est :

  • utiliser Sonnet 5 pour l'ingénierie normale et le défensif routinier ;
  • s'attendre à des refus sur les prompts cyber prohibited ou high-risk ;
  • utiliser Opus 4.8, avec le bon accès, pour la cybersécurité qui exige moins de guardrails ;
  • journaliser stop_reason: "refusal" car les refus peuvent arriver comme réponses HTTP 200 réussies.

Réaction externe : le modèle par défaut est l'histoire​

Axios a présenté Sonnet 5 comme une manière d'amener l'IA agentique au travail quotidien tout en gardant un profil de risque inférieur à Opus, Fable et Mythos. C'est la bonne lecture.

Sonnet 5 compte parce qu'il change le défaut. Si les utilisateurs Free et Pro, les utilisateurs Claude Code et les développeurs plateforme ont tous un modèle Sonnet plus agentique, les workflows d'agents cessent d'être un edge case premium et deviennent l'expérience Claude normale.

Le risque est que les utilisateurs surestiment l'autonomie. Le test de TechRadar était positif, mais notait encore le besoin de supervision humaine pour les décisions, les vérifications, les réservations, les uploads et l'exécution finale. Sonnet 5 rapproche du travail terminé, mais ne remplace pas la review.

Pour ce site, le cadrage utile est simple :

Sonnet 5 est le modèle à essayer en premier pour l'automatisation Claude Code quotidienne, mais pas le modèle auquel faire confiance aveuglément.

Checklist d'adoption Claude Code​

1. Mettre à jour le model ID​

Déplacer les workloads de test de :

claude-sonnet-4-6

vers :

claude-sonnet-5

Faites-le d'abord dans une branche ou un environnement staging. Ne changez pas le modèle par défaut en production sans rejouer vos evals.

2. Supprimer les anciens paramètres API​

Cherchez dans la codebase :

  • temperature
  • top_p
  • top_k
  • thinking: {type: "enabled"}
  • budget_tokens

Supprimez les sampling parameters non par défaut et migrez les contrôles thinking manuels vers adaptive thinking plus effort.

3. Recompter les tokens​

Ne réutilisez pas les budgets token de Sonnet 4.6. Recomptez les plus gros prompts, les préfixes mis en cache et les sessions Claude Code typiques sous Sonnet 5.

Surveillez particulièrement :

  • les grands résumés de repo ;
  • les plans générés ;
  • les logs collés dans le prompt ;
  • les longs résultats d'outils ;
  • les max output proches de la longueur attendue.

4. Définir effort explicitement​

La politique la plus sûre est de décider effort au niveau de la tâche :

  • medium pour les edits et explications routiniers ;
  • high pour les tâches Claude Code normales où la justesse compte ;
  • xhigh pour debugging difficile, migrations et longues exécutions d'agents.

Ne considérez pas high effort comme une qualité gratuite. Il modifie latence et usage token.

5. Garder Opus dans le routing mix​

Sonnet 5 devrait devenir le défaut de nombreux workflows, mais pas de tous.

Gardez Opus 4.8 pour :

  • les refactors à haut risque ;
  • les reviews sensibles côté sécurité ;
  • les décisions d'architecture ambiguës ;
  • les tâches où un edge case manqué coûte cher ;
  • la review finale de grands changements générés par Sonnet.

Le modèle pratique : Sonnet pour l'exécution, Opus pour l'escalade.

Conclusion​

Claude Sonnet 5 est une sortie plus importante qu'elle n'en a l'air, parce qu'elle déplace un comportement agentique plus fort dans le niveau de modèle que la plupart des équipes utiliseront tous les jours.

Ce n'est pas le nouveau modèle Claude haut de gamme. C'est le nouveau workhorse par défaut.

Pour les utilisateurs Claude Code, la bonne démarche est une adoption délibérée :

  • le benchmarker contre Sonnet 4.6 sur vos vraies tâches ;
  • réajuster les budgets token pour le nouveau tokenizer ;
  • supprimer les paramètres API non supportés ;
  • mesurer le coût par effort level ;
  • garder Opus 4.8 pour les escalades ;
  • surveiller les refus cyber-safeguard dans les logs.

Si Sonnet 4.6 était la baseline pratique précédente et Opus 4.8 le power tool, Sonnet 5 tente de ramener davantage de cette puissance dans le workflow quotidien. C'est exactement pourquoi il mérite une migration prudente plutôt qu'un changement de défaut aveugle.

Sources consultées​