Blog / · 5 min de lecture
Claude Sonnet 5 : le modèle "assez bon" vient de devenir le vrai sujet
Sonnet 5 arrive dans Claude et GitHub Copilot. Pas le modèle le plus spectaculaire, mais probablement celui qui va tourner le plus dans les vrais workflows de dev.
Anthropic a sorti Claude Sonnet 5 le 30 juin. Pas Opus. Pas le modèle qui finit en screenshot sur LinkedIn avec un benchmark absurde. Sonnet.
Et c’est justement pour ça que la sortie est intéressante.
Les modèles “frontier” font la démo. Les modèles Sonnet font la facture. Ils sont ceux qu’on met dans les agents qui tournent tous les jours, dans Copilot, dans les outils internes, dans les petits scripts qui ouvrent des PR pendant qu’on bosse sur autre chose.
Le sujet n’est pas : “est-ce que Sonnet 5 est le meilleur modèle du monde ?”
Le sujet est plus banal, donc plus important : est-ce qu’il est assez fiable pour devenir le modèle par défaut sans qu’on ait l’impression de travailler avec une version discount ?
Le vrai changement : Sonnet monte sur les tâches longues
Anthropic vend Sonnet 5 comme un modèle plus solide sur le coding, le tool use et les workflows multi-étapes. Ça a l’air très générique dit comme ça. Pourtant, c’est exactement la zone où les modèles “milieu de gamme” se plantaient encore trop souvent.
Pas sur l’écriture d’une fonction. Ça, tout le monde sait faire maintenant.
Le problème, c’était le suivi :
- lire trois fichiers avant de modifier le quatrième ;
- garder le contexte d’une décision prise dix minutes plus tôt ;
- ne pas oublier de relancer les tests ;
- ne pas réinventer l’architecture en plein milieu d’un bugfix ;
- utiliser les outils sans produire un JSON de travers une fois sur cinq.
Un modèle moins cher qui tient mieux ces gestes-là change davantage le quotidien qu’un modèle premium qui gagne trois points sur un leaderboard.
Dans un vrai workflow agentique, tu ne paies pas seulement de l’intelligence. Tu paies de l’endurance.
Pourquoi GitHub Copilot compte dans l’histoire
Le signal le plus concret, c’est que Sonnet 5 arrive aussi dans GitHub Copilot : VS Code, Visual Studio, Copilot CLI, cloud agent, GitHub Mobile, JetBrains, Xcode, Eclipse. Ce n’est pas une intégration de niche.
Ça veut dire une chose simple : le modèle va être testé par des gens qui ne lisent pas les release notes d’Anthropic. Des devs qui cliquent sur un picker de modèle, lancent une refacto, et jugent au résultat.
C’est beaucoup plus violent qu’un benchmark.
Dans un benchmark, l’échec est une ligne rouge dans un tableau. Dans Copilot, l’échec est un diff idiot sur une branche où tu avais déjà peu de temps.
Si Sonnet 5 tient, il va devenir le choix raisonnable pour 70% des tâches :
- correction de bugs localisés ;
- refacto medium ;
- génération de tests ;
- review de PR ;
- scripts internes ;
- compréhension d’une codebase pas trop monstrueuse.
Et Opus restera pour les moments où il faut vraiment sortir l’artillerie : architecture tordue, audit sécurité, migration risquée, énorme contexte métier.
Le piège du modèle “moins cher”
Je me méfie quand même du narratif “moins cher donc mieux”. Un modèle moins cher encourage mécaniquement à lui donner plus de travail. Et c’est là que les dégâts commencent.
Un Sonnet très bon peut te faire oublier qu’il reste un modèle probabiliste avec un accès partiel à ton système. Il peut écrire plus vite que toi, mais il ne porte pas la responsabilité de ce qu’il merge.
Le pattern que je vois déjà arriver :
- On met Sonnet 5 par défaut.
- On lui donne des tâches plus longues parce qu’il tient mieux.
- On review moins parce que “franchement, il est fiable”.
- Une décision métier déguisée en nettoyage technique passe dans le diff.
Ce n’est pas un problème Anthropic. C’est un problème de workflow.
Les modèles deviennent assez bons pour qu’on baisse la garde au mauvais moment.
Mon arbre de décision actuel
Si je devais router mes tâches aujourd’hui, je ferais simple :
Sonnet 5 par défaut pour le dev quotidien. Pas parce qu’il est parfait. Parce qu’il devrait offrir le meilleur ratio prix / qualité / latence sur les tâches qui reviennent tous les jours.
Opus quand la tâche a une vraie ambiguïté d’architecture ou un risque produit. Dès qu’il faut arbitrer, pas seulement exécuter, je préfère payer plus cher et récupérer une meilleure analyse.
Haiku ou équivalent léger pour classification, extraction, tri, petites transformations. Envoyer un modèle Sonnet sur ça, c’est comme prendre un taxi pour traverser le salon.
La nouveauté, c’est que Sonnet ne ressemble plus à une concession. Avant, on choisissait Sonnet parce qu’Opus coûtait trop cher. Maintenant, on peut le choisir parce que c’est probablement le bon outil.
Ce que je vais regarder dans les prochaines semaines
Pas les scores. Les comportements.
Je veux voir :
- s’il casse moins les formats de tool calls ;
- s’il sait s’arrêter quand il manque une info ;
- s’il évite les refactors hors scope ;
- s’il garde une meilleure discipline de tests ;
- s’il produit des diffs reviewables, pas des romans en 40 fichiers.
Le dernier point est sous-estimé. Un agent qui code “bien” mais rend des diffs impossibles à relire est mauvais en production. La qualité d’un agent se mesure aussi à la fatigue qu’il laisse au reviewer.
Le verdict à chaud
Sonnet 5 n’est pas une annonce glamour. C’est mieux que ça : une annonce d’infrastructure.
Si Anthropic a réussi son coup, le modèle va disparaître dans les workflows. On ne dira pas “j’ai utilisé Sonnet 5”. On dira juste “Copilot m’a préparé la PR”, “Claude a nettoyé le module”, “l’agent a passé les tests”.
C’est ça, l’adoption réelle.
Pas le moment où tout le monde en parle. Le moment où plus personne ne pense à le nommer.
Sources
Continuer la lecture