Changer de modèle modifie le contrat d’intégration, pas seulement son identifiant

Anthropic a lancé Claude Sonnet 5.5 le 28 septembre, en annonçant des gains de vitesse et d’efficacité par tâche. Pour les équipes qui construisent elles-mêmes leurs requêtes à la Messages API, le guide de migration mérite autant d’attention que les chiffres de performance. Il décrit des changements dans les paramètres acceptés et le traitement des conversations. En revanche, Anthropic indique que les utilisateurs de Claude Managed Agents n’ont qu’à actualiser le nom du modèle. L’analyse qui suit concerne les intégrations API développées sur mesure. [1] [2]

Un test rapide limité à un seul tour peut manquer deux problèmes distincts : une requête qui échoue aussitôt et une autre qui aboutit avec un contexte différent. Chacun appelle son propre critère de validation. Une réponse HTTP réussie prouve que le service a répondu, pas que l’application a conservé son déroulement. Cette distinction doit guider la migration.

Sonnet 5 acceptait thinking: {"type": "disabled"}. Sonnet 5.5 rejette ce réglage avec une erreur 400. Son niveau minimal de raisonnement est between_tools, disponible aux niveaux d’effort low, medium et high ; xhigh et max le rejettent. C’est une modification du contrat de requête, pas un simple réglage. Les équipes qui désactivaient le raisonnement pour maîtriser la latence doivent choisir délibérément le nouveau mode et remesurer leur flux de travail, au lieu de supposer que l’ancienne requête reste valable. [2]

Le mode between_tools supprime le raisonnement étendu avant la réponse, mais des mises à jour de progression entre appels d’outils peuvent encore arriver sous forme de blocs thinking. La boucle d’outils doit renvoyer ces blocs intacts avec le message complet de l’assistant. Il faut revoir tout lecteur qui suppose que le premier bloc de contenu est du texte, ou qui reconstruit un tour à partir du seul texte et des appels d’outils. Pour lire la réponse, fiez-vous au type de chaque bloc ; pour poursuivre la conversation, conservez le tour de l’assistant tel qu’il a été renvoyé. [2] [6]

Sonnet 5.5 rejette les valeurs de tool_choice qui imposent un appel : tool et any. Anthropic recommande auto avec des schémas d’outils strict lorsque la plateforme le permet. Le mode strict peut contraindre la forme des arguments d’un appel effectué ; auto laisse toujours le modèle répondre sans appeler d’outil. Amazon Bedrock ne propose pas strict tool use pour ce modèle : l’application doit donc y valider elle-même les arguments. [2] [4]

Cette distinction a un effet concret. Si un processus doit consulter l’enregistrement le plus récent avant de répondre, une réponse bien formée ne prouve pas que la consultation a eu lieu. Ne validez l’étape qu’après réception et vérification du résultat de l’outil requis. Inscrivez cette règle dans l’application, puis testez les deux parcours : un appel valide et une réponse directe alors que l’appel était obligatoire. C’est une déduction architecturale tirée du comportement documenté, pas une affirmation sur la fréquence à laquelle Sonnet 5.5 omettrait les outils.

Les blocs thinking de Sonnet 5.5 ne peuvent être réutilisés que par le compte qui les a produits ou par un compte lié. Si un compte non lié les renvoie, l’API les écarte avant l’inférence et la requête aboutit ; sans l’en-tête de diagnostic approprié, cette suppression est silencieuse. Un changement de modèle peut aussi rendre un bloc illisible. Une réponse réussie du routeur ne prouve donc pas que le modèle a reçu le raisonnement antérieur. [3]

Une autre règle porte sur le préfixe : les instructions system, les outils et les messages antérieurs doivent rester inchangés lorsqu’un bloc thinking signé est renvoyé. Les comptes créés à partir du 31 août 2026 sont soumis à cette vérification par défaut ; les comptes plus anciens ont un autre comportement par défaut. Un essai sans erreur avec une clé ne suffit donc pas à garantir le résultat pour tous. Conservez un historique auquel on ajoute des messages sans réécrire les précédents et testez la reprise des sessions enregistrées, les changements d’outils, la réduction de l’historique côté client et les changements de route. Si disponible, consultez input_transformations pour repérer les blocs écartés. [3]

Le guide de migration demande aussi de gérer les refus. Un refus doit entrer dans la logique de réponse et de contrôle du produit ; renvoyer aveuglément la requête comme après une panne réseau confond une décision de politique avec une indisponibilité du service. Anthropic documente un repli côté serveur facultatif, limité à certaines catégories de refus et à des conditions précises sur la Claude API. Cela ne rend pas tous les refus susceptibles d’être relancés et ne promet pas le même comportement sur chaque plateforme. [5]

Lors des tests de validation, consignez le motif réel d’arrêt, le déclenchement éventuel d’un repli configuré officiellement et ce que l’utilisateur a vu. Le traitement de sécurité devient ainsi observable sans utiliser une nouvelle tentative de bas niveau pour contourner un refus. On évite aussi qu’un tableau de bord limité aux réponses HTTP réussies masque un changement dans les réponses reçues par les utilisateurs.

Nous proposons cinq parcours de validation : une ancienne requête avec raisonnement désactivé ; un appel d’outil autrefois imposé ; un échange sur plusieurs tours qui renvoie des blocs thinking ; une conversation enregistrée puis reprise avec le compte et le routage réels ; et un refus géré par le produit. Vérifiez le statut HTTP, les types de blocs, l’exécution et la validation des outils, les diagnostics de continuité disponibles ainsi que l’état final visible par l’utilisateur. Ajoutez une longue session et un changement de route, car un test rapide sur un seul tour ne révèle pas les erreurs d’historique.

Ce n’est qu’ensuite qu’il faut comparer le taux de tâches acceptées, le temps total et le coût par tâche acceptée pour un niveau d’effort indiqué. Les chiffres de vitesse et de coût d’Anthropic sont des hypothèses utiles pour cette expérience, pas un substitut aux mesures sur votre propre charge de travail. La leçon dépasse cette sortie : un modèle fait partie d’un protocole entre l’application, les outils, l’historique et les utilisateurs. La mise à niveau est achevée lorsque ce protocole continue de produire le résultat attendu. [1]