Sonnet 5.5 ou Opus 5.5 : quel modèle Claude pour quel usage en entreprise ?

Qu’est-ce que Claude Sonnet 5.5, sorti le 28 septembre 2026 ?

Anthropic a publié Claude Sonnet 5.5 le 28 septembre 2026, sous l’identifiant claude-sonnet-5-5. C’est le deuxième modèle de la famille 5.5, six jours après Opus 5.5, et Haiku 5.5 doit suivre dans les prochaines semaines. Pour une entreprise qui a déjà des cas d’usage sur Claude, la question pratique devient : quel modèle de la famille affecter à quel usage ?

Claude Sonnet 5.5 est le modèle intermédiaire de la famille 5.5 d’Anthropic, présenté comme un complément plus rapide et moins coûteux à Opus 5.5. Il vise les tâches bien définies du quotidien, garde le tarif par token de Sonnet 5 et revendique, selon l’éditeur, jusqu’à 30 % de coût en moins par tâche, grâce à moins de tokens consommés.

Ce qu’Anthropic annonce, et ce que l’annonce laisse ouvert

Côté vitesse, l’éditeur annonce une génération de texte plus de 30 % plus rapide que celle de Sonnet 5. Côté coût, il parle d’une baisse pouvant aller jusqu’à 30 % par tâche, obtenue par un nombre de tokens réduit, le tarif restant le même. Sur la qualité, Anthropic publie des scores où Sonnet 5.5 se place à deux points d’Opus 5.5 sur GDPval-AA, une évaluation de travaux de bureau (1844 contre 1846). Le modèle est disponible sur la plateforme Claude, sur Amazon Web Services, Google Cloud et Microsoft Azure, avec rétention zéro des données.

Ces chiffres viennent de l’éditeur et de ses propres jeux de tests, ils ne disent rien de votre charge de travail. L’annonce ne mentionne par ailleurs aucune date de retrait de Sonnet 5, ce qui laisse le temps de comparer avant de basculer.

Sonnet 5.5 ou Opus 5.5 : quel modèle choisir selon l’usage ?

Choisissez Sonnet 5.5 pour les tâches bien cadrées, répétées et sensibles au temps de réponse : extraction, rédaction courte, code courant, agents outillés au périmètre précis. Gardez Opus 5.5 pour les travaux complexes, longs ou ambigus, où une erreur coûte plus cher que le modèle. Départagez sur un jeu d’évaluation tiré de vos propres données.

La séparation proposée par Anthropic est simple : Opus pour le travail complexe, Sonnet pour les tâches bien définies. Sur les évaluations publiées par Anthropic, l’écart de qualité est mince sur certaines, comme GDPval-AA, et plus marqué sur d’autres, notamment en code. L’écart de coût par token est net : Opus 5.5 reste facturé plus cher que Sonnet 5.5 sur la grille publique. Pour une DSI, reste à savoir si un cas d’usage ressemble à une tâche bien définie, et seul un essai sur vos données le dit.

Les usages où Sonnet 5.5 suffit probablement

Les candidats naturels sont les cas à fort volume dont les consignes sont stables : classement de courriers, extraction de champs dans des contrats types, assistants internes consultés des centaines de fois par jour, étapes répétitives d’un agent. Plus la tâche est définie à l’avance, moins elle profite d’un modèle plus puissant, et plus la vitesse et le coût pèsent dans la balance. Les agents qui pilotent des écrans ou appellent des API enchaînent beaucoup d’étapes, et chaque étape rapide économise du temps d’attente.

Les usages qui justifient encore Opus 5.5

Les analyses longues, les dossiers où les sources se contredisent, les décisions que quelqu’un devra défendre devant un comité : là, l’erreur est chère et le surcoût du modèle haut de gamme devient accessoire. C’est aussi le cas des tâches mal spécifiées, où le modèle doit combler seul les trous du cahier des charges. Si vous avez déjà basculé vos usages complexes sur Opus 5.5, rien n’oblige à les redescendre : le bon test consiste à rejouer vos cas réels sur les deux modèles et à regarder d’abord l’écart de qualité.

Comment un tarif par token inchangé peut-il baisser la facture ?

La facture d’un cas d’usage est le produit d’un tarif par token et d’un nombre de tokens. Sonnet 5.5 garde le tarif de Sonnet 5 et vise l’autre facteur : Anthropic annonce jusqu’à 30 % de coût en moins par tâche, grâce à moins de tokens consommés. Le gain se vérifie au niveau du cas d’usage, tâche par tâche.

Un point de contexte utile pour le budget : le tarif de Sonnet 5 avait été annoncé comme tarif d’introduction jusqu’au 31 août. Selon la grille publique d’Anthropic, il est devenu le tarif standard et la hausse prévue au 1er septembre n’a pas eu lieu. Pour une DSI qui avait provisionné cette hausse, la ligne se libère.

Mesurer le coût d’une tâche terminée

Le tarif affiché par million de tokens ne dit rien d’un traitement réel. Deux modèles au même tarif peuvent produire des factures très différentes si l’un raisonne plus longtemps ou répond plus long. Les tokens de réflexion sont facturés comme des tokens de sortie, même lorsque leur texte n’est pas renvoyé. La mesure utile est le coût d’une tâche terminée, qualité comprise : il faut donc faire tourner un échantillon de vos requêtes, relever les tokens consommés, la latence et le taux de réponses acceptables, puis comparer. Cette discipline rejoint ce que nous décrivions dans notre analyse de la dépendance à un modèle et de l’architecture qui permet d’en changer.

Que changer dans le code pour passer à Sonnet 5.5 ?

Le guide de migration d’Anthropic liste les changements, et ils ne sont pas tous cosmétiques : plusieurs réglages qui passaient hier renvoient désormais une erreur 400. Sur Messages API, il faut changer l’identifiant du modèle, lire les blocs de réponse par type, renvoyer les blocs de raisonnement inchangés, remplacer l’outil imposé par un choix automatique et recalibrer le niveau d’effort. Les applications sous Claude Managed Agents n’ont, selon le guide, que le nom du modèle à changer.

Le raisonnement tourne par défaut

Sur Sonnet 5.5, une requête sans champ thinking s’exécute avec le raisonnement adaptatif. Pour les équipes venues de Sonnet 4.6 ou d’un modèle antérieur, qui tournaient sans raisonnement, le comportement change : la réponse peut commencer par des blocs de raisonnement, donc un code qui lit le premier bloc comme du texte casse. Les tokens de réflexion comptent dans la limite de sortie.

Pour garder un fonctionnement sans raisonnement préalable, Sonnet 5.5 n’accepte plus la valeur « disabled » qu’utilisait Sonnet 5 : il faut envoyer « between_tools », réglage qui ne fonctionne qu’aux niveaux d’effort bas, moyen et élevé. Un simple changement d’identifiant de modèle suffit donc à produire une erreur sur toute intégration qui désactivait le raisonnement de manière explicite.

Les réglages qui renvoient une erreur

Le guide cite, parmi les requêtes rejetées avec une erreur 400, l’outil imposé (tool_choice de type any ou tool), mais aussi, pour les équipes qui viennent de Sonnet 4.6 ou d’un modèle plus ancien, les budgets de raisonnement manuels et les paramètres d’échantillonnage, et, pour celles qui viennent de Sonnet 4.5 ou avant, le préremplissage de la réponse de l’assistant. Dans un prototype, ces réglages sont souvent posés au début et jamais relus : il faudra les retrouver un par un dans le code.

Deux autres changements concernent les agents. Sur l’API Claude et Google Cloud, l’usage de l’ordinateur passe par le nouveau jeu d’outils computer_toolset_20260801. Et les notes que le modèle écrit entre deux appels d’outils, quand elles dépassent une ou deux phrases, reviennent dans des blocs de raisonnement : aucune requête n’échoue, mais une interface qui affichait ces notes devient silencieuse.

Le niveau d’effort à recalibrer

Sonnet 5.5 propose cinq niveaux d’effort, du plus bas au plus haut, recalibrés par rapport à Sonnet 5 : le même niveau ne produit pas la même quantité de réflexion. Le guide recommande de rejouer ses essais d’effort et de refaire sa base de coût. Un niveau d’effort trop haut peut annuler à lui seul le gain annoncé, et un niveau trop bas dégrade la qualité.

Peut-on router entre Sonnet 5.5 et Opus 5.5 sans casser ses agents ?

Oui, à condition de router par conversation ou par tâche, en évitant le milieu d’un échange. Sonnet 5.5 ne lit pas les blocs de raisonnement produits par Opus 5.5, et l’API les écarte : la requête réussit, mais le modèle repart sans ce raisonnement. Un routage proprement conçu affecte un modèle à chaque cas d’usage et s’y tient.

Le raisonnement ne passe pas d’un modèle à l’autre

Le guide précise que Sonnet 5.5 lit les blocs de Sonnet 5, d’Opus 4.8 et de modèles plus anciens, mais pas ceux d’Opus 5, d’Opus 5.5 ni des modèles Fable et Mythos. Les blocs écartés ne sont pas facturés et la requête renvoie un code 200, donc rien ne signale le problème côté application. Pour les comptes créés depuis le 31 août 2026, l’API impose en plus que les conversations restent en ajout seulement : modifier l’historique avant de rejouer un bloc de raisonnement renvoie une erreur 400.

Concrètement, un agent qui bascule d’Opus à Sonnet en cours de session pour économiser sur la fin d’un traitement perd le fil de son propre raisonnement. Le routage se décide à l’ouverture de la session, et les journaux doivent indiquer quel modèle a produit quelle étape.

L’outil advisor : Opus conseille, Sonnet exécute

Anthropic propose aussi, en version bêta, un mode où un modèle exécute et un autre conseille. Avec Sonnet 5.5 comme exécutant, les conseillers acceptés sont notamment Opus 5, Opus 5.5 et Sonnet 5.5 ; les anciens conseillers renvoient une erreur. Le conseil revient chiffré dans un bloc dédié, donc son texte n’est pas lisible dans la réponse. Pour une organisation soumise à des exigences de traçabilité, c’est un point à régler avant l’usage : savoir ce que l’on peut conserver, relire et justifier d’un conseil que l’application ne lit pas.

Qui décide du modèle utilisé par chaque cas d’usage ?

Dans beaucoup d’organisations, personne. Le choix se fait au moment du développement, par l’équipe qui a écrit le premier appel, puis il reste figé jusqu’à la prochaine alerte de budget. Avec une famille de modèles qui se renouvelle vite, ce vide devient visible : quelqu’un doit pouvoir dire pourquoi tel agent tourne sur Opus et tel autre sur Sonnet.

Nous recommandons de tenir un registre des modèles par cas d’usage, avec le responsable du choix, les critères écrits (seuil de qualité sur le jeu d’évaluation, plafond de coût, contraintes d’hébergement) et le critère de retour arrière. Dans la méthodologie de gouvernance LOOP™, un changement de modèle est traité comme une modification de l’agent lui-même, avec une approbation tracée. Le cadre de conformité AI Act demande de toute façon de documenter les systèmes que l’on déploie, ce registre en fournit la matière.

Les refus de sécurité à recetter

Selon le guide, Sonnet 5.5 refuse dans plus de catégories que Sonnet 5, avec un arrêt de type refus qui précise la catégorie : cyber, biologie, développement de modèles concurrents, extraction du raisonnement ou autres domaines de la politique d’utilisation. Le guide note que des travaux anodins peuvent déclencher la dernière. Les équipes qui traitent des contenus sensibles, en banque, en assurance ou en santé, ont donc intérêt à rejouer leurs cas limites avant la bascule, et à prévoir le comportement de l’application quand une réponse est refusée.

Le cas des hébergements imposés

Beaucoup d’entreprises consomment Claude via leur fournisseur de cloud, pour des raisons de contrat ou de localisation des données. Sonnet 5.5 est annoncé sur Amazon Web Services, Google Cloud et Microsoft Azure. Vérifiez la disponibilité dans votre région avant la recette, ainsi que les écarts de fonctionnalités entre plateformes : l’usage de l’ordinateur, par exemple, passe par un jeu d’outils différent sur Amazon Bedrock et sur l’API Claude ou Google Cloud.

Que retenir pour votre feuille de route IA ?

Avec la famille 5.5, le choix du modèle se prend usage par usage, comme dans un portefeuille. Les organisations qui disposent d’une couche d’abstraction, d’un jeu d’évaluation et d’un responsable nommé peuvent affecter Sonnet 5.5 aux usages répétitifs et garder Opus 5.5 pour le complexe, dès ce trimestre. Pour les autres, chaque sortie ouvre un nouveau chantier, et Haiku 5.5 arrivera avant que le précédent soit clos.

Gartner estime que plus de 40 % des projets d’IA agentique seront annulés d’ici fin 2027, en raison de coûts qui dérapent, d’une valeur métier floue ou de contrôles de risque insuffisants. Répartir les modèles par usage agit sur la première cause, à condition de mesurer le coût par tâche. Pour situer votre organisation, le diagnostic de maturité IA évalue votre niveau sur les 6 axes du référentiel Koneetiv (édition 2026). Et si vous cherchez un intégrateur Claude en France pour conduire ce type d’arbitrage, Koneetiv, partenaire officiel Anthropic et pure player Claude, accompagne les entreprises sur leurs agents Claude en production.