Claude Opus 5.5 face à Sonnet 5.5 pour le triage : que mesurer avant de choisir

La vraie question n’est pas de savoir quel modèle paraît le plus performant, mais lequel gère ce flux avec le moins de risques

Comparer Claude Opus 5.5 et Claude Sonnet 5.5 pour le service client suppose d’abord de préciser ce que signifie « effectuer le triage ». Dans cette évaluation, la tâche ne consisterait ni à répondre au client, ni à rédiger une solution, ni à décider seul d’un dédommagement. Il s’agirait de transformer une demande brève en données structurées qui aideraient une personne ou un système en aval à la classer et à l’orienter vers l’équipe appropriée.

Cette distinction est importante. Un modèle peut produire une réponse fluide tout en identifiant mal le problème, en inventant une information que le client n’a pas communiquée ou en ne remarquant pas qu’il manque des éléments. Pour les équipes opérationnelles, ces erreurs peuvent compter davantage que le ton ou la longueur de la réponse. La comparaison doit donc porter sur des champs précis et des décisions d’orientation, et non sur une impression générale de qualité conversationnelle.

Les éléments vérifiés disponibles ne permettent pas de désigner un gagnant pour ce flux. Ils ne comprennent pas d’évaluation commune des deux modèles sur des demandes de support, avec une grille partagée et des résultats reproductibles pour la classification, l’extraction et l’escalade. La documentation repérée sur Sonnet 5.5 renseigne sur le modèle lui-même, mais n’établit pas ses performances face à Opus 5.5 pour cette tâche. Une comparaison de configurations Medium identifie les deux modèles, mais les éléments vérifiés ne fournissent pas non plus de résultats de triage.

Ce guide ne présente donc ni scores ni simulation d’un test déjà réalisé. Il propose un protocole qu’une équipe peut appliquer si elle confirme l’accès aux variantes exactes et peut documenter les conditions de chaque exécution. D’ici là, toute recommandation sur le modèle à retenir doit rester conditionnelle. Pour d’autres comparaisons de modèles, l’index des comparatifs peut servir de point de départ, mais il ne remplace pas une évaluation adaptée au flux et aux données de l’équipe.

Définir la tâche et le format de sortie attendu avant les essais

La première étape consiste à rédiger une spécification indépendante des réponses de chaque modèle. Pour chaque demande, le système ne doit produire que les champs réellement utiles au processus. Un schéma illustratif pourrait contenir une catégorie principale, des catégories secondaires le cas échéant, un niveau d’urgence, le produit ou service mentionné, un identifiant explicite, les informations manquantes, un niveau de confiance et une décision de poursuivre ou d’escalader. L’équipe doit déterminer quels champs sont obligatoires et quelles valeurs sont autorisées.

Il ne faut pas confondre catégorie et orientation. « Problème de facturation » peut être une classification correcte, mais ne pas suffire à diriger le dossier si le message signale aussi une interruption urgente du service. La grille d’évaluation doit préciser comment traiter plusieurs sujets dans un même message, si plusieurs catégories sont permises et quelle règle détermine la priorité. Sans ces définitions, deux évaluateurs risquent de noter différemment une même réponse.

Il est également utile de séparer la validité syntaxique de la justesse sémantique. Une réponse peut respecter parfaitement un format structuré tout en remplissant ses champs avec des valeurs erronées. À l’inverse, le modèle peut comprendre correctement la demande, mais ne pas respecter le format exigé par l’intégration. Ces dimensions doivent être évaluées séparément afin qu’un problème opérationnel ne soit pas masqué par un score agrégé.

Les instructions, le schéma, les catégories, les règles d’escalade et la méthode de notation sont fixés avant les essais. Toute modification ultérieure doit être documentée comme une nouvelle version du test ; les règles ne doivent pas être changées rétroactivement pour favoriser le résultat d’un modèle.

Constituer un jeu de test représentatif, et pas seulement composé de cas faciles

Un test utile doit inclure des demandes claires ainsi que des cas difficiles. Les exemples clairs permettent de vérifier si le modèle reconnaît une intention formulée directement. Les demandes incomplètes montrent s’il sait repérer les informations manquantes. Les cas ambigus indiquent s’il demande une vérification ou choisit une catégorie sans fondement. Il faut aussi prévoir des messages portant sur plusieurs sujets, des fautes de frappe, des abréviations et des références au contexte, si ces caractéristiques existent dans le canal évalué.

Le jeu de test doit refléter la distribution attendue par l’équipe, tout en comportant suffisamment de situations à risque, même rares, pour les analyser séparément. Si une catégorie urgente apparaît peu souvent dans le trafic habituel, un petit échantillon aléatoire pourrait ne pas en contenir. L’équipe peut ajouter un lot de cas à risque pour l’évaluer spécifiquement, à condition de préciser que ce lot ne représente pas sa fréquence réelle.

Chaque cas doit être associé à une étiquette de référence et à une brève explication de la décision attendue. Pour les cas contestables, il est préférable que deux personnes examinent le critère et s’accordent sur la référence avant de comparer les modèles. Si les évaluateurs ne peuvent pas trancher avec la politique disponible, le cas doit être marqué comme incertain, exclu du score principal ou analysé à part.

Pour éviter que le jeu de test ne devienne un exercice de mémorisation, il est utile de réserver des cas qui ne serviront pas à ajuster les instructions. Les demandes doivent être anonymisées et limitées aux données nécessaires. Il ne faut pas copier des conversations identifiantes dans un outil avant d’avoir vérifié que le canal et les conditions de traitement autorisent cet usage.

Vérifier que la comparaison est réellement équivalente

Le nom affiché dans une interface ne suffit pas à identifier ce qui est testé. Avant de lancer les essais, il faut consigner l’identifiant exact du modèle renvoyé par chaque canal, la date, l’interface ou l’API utilisée et les paramètres configurables. Si l’un des accès pointe vers une autre variante, utilise des outils supplémentaires ou applique une configuration indisponible pour l’autre modèle, la comparaison n’est plus strictement équivalente.

La documentation disponible sur Sonnet 5.5 décrit des changements, la compatibilité et d’autres informations propres à ce modèle, mais ne couvre pas Opus 5.5 et ne permet pas, à elle seule, d’égaliser les deux accès. La comparaison d’Artificial Analysis mentionnée dans les éléments fournis identifie des configurations Medium pour les deux modèles. Elle indique une paire qui pourrait être étudiée, mais ne prouve pas que le canal utilisé par l’équipe offre les mêmes paramètres, ni qu’elle a évalué le flux de support.

Si les réglages ne sont pas identiques, il ne faut pas fabriquer une équivalence qui n’existe pas. Deux analyses sont possibles : l’une porte sur les capacités dans la configuration commune disponible ; l’autre, sur les performances opérationnelles des canaux réellement envisagés. Dans la seconde, les différences doivent être clairement signalées. Il faut également consigner les limites de sortie, les outils accessibles, les nouvelles tentatives automatiques et toute transformation appliquée par la plateforme.

Pour isoler l’effet du modèle, les instructions doivent rester identiques. Si un prompt est ajusté différemment pour chaque modèle, l’expérience compare l’ensemble modèle-configuration, et non les modèles seuls. Cette expérience peut être utile pour choisir une solution à déployer, mais elle doit être désignée correctement et documentée comme telle.

Évaluer séparément chaque dimension et analyser les erreurs qui changent une décision

Le score principal doit être ventilé. Pour la classification, on mesure la proportion d’étiquettes correctes et on détaille les résultats par catégorie : une moyenne générale peut masquer un échec précisément dans le type de demande le plus sensible. Pour l’extraction, chaque champ est vérifié séparément, en comptant les omissions comme les informations ajoutées sans fondement. Si plusieurs valeurs sont autorisées, la grille doit préciser leur mode de notation.

La détection des informations manquantes exige une référence explicite : quelle donnée manque, si elle est réellement nécessaire et si la réponse attendue consiste à poser une question, à laisser le champ vide ou à escalader. Il ne suffit pas de récompenser un modèle qui répond fréquemment « je ne sais pas ». Une abstention inutile peut ralentir le support ; ne pas s’abstenir lorsqu’une incertitude est importante peut envoyer un dossier dans la mauvaise file.

L’escalade doit être mesurée à partir des deux types d’erreurs. Une escalade non exigée mobilise inutilement les équipes humaines, tandis que l’absence d’escalade pour un cas incertain peut transformer une supposition en décision opérationnelle. L’équipe doit pondérer ces coûts selon leurs conséquences. Si l’absence d’escalade est nettement plus risquée, elle peut définir un seuil prudent et publier la charge de vérification supplémentaire qui en découle.

Les erreurs de format sont comptabilisées indépendamment de la qualité du contenu. Le rapport peut indiquer la proportion de sorties conformes au schéma puis, parmi celles-ci, la proportion qui satisfait également les critères de contenu. Les erreurs à fort impact doivent aussi être examinées manuellement : urgence mal évaluée, données personnelles inventées, mauvaise orientation et absence d’escalade.

Les écarts entre modèles ne doivent pas être considérés comme concluants sans tenir compte de l’incertitude statistique et sans examiner les cas concernés. Lorsque le jeu de test est petit, quelques exemples peuvent fortement faire varier un pourcentage. Publier le nombre de réussites, le dénominateur et les erreurs observées aide davantage à interpréter le résultat qu’une simple note.

Calculer la latence et le coût par cas accepté, plutôt que de se fier à une impression

La latence doit être mesurée selon une méthode constante : du moment où la demande est envoyée jusqu’à la disponibilité et à la validation de la sortie. Il est utile de communiquer la médiane et une mesure de la queue de distribution, telle que le 95e percentile, ainsi que le nombre d’exécutions. Les mesures doivent couvrir les conditions prévues en production ; une exécution isolée ne représente pas nécessairement la variabilité du service.

Pour calculer le coût, il faut documenter le canal, la date, les unités facturées et les tarifs applicables à cette configuration. Les éléments vérifiés ici ne suffisent pas à confirmer une comparaison complète des prix pour les deux modèles dans les canaux qu’une équipe utiliserait. Il ne faut pas reprendre un tarif publié dans une source secondaire, applicable à une autre variante ou à une autre date, comme s’il représentait le coût réel de l’intégration évaluée.

Un indicateur plus utile que le coût nominal par appel est le coût par cas accepté. Pour le calculer, on additionne les coûts observés des exécutions et des vérifications nécessaires, puis on divise le total par le nombre de cas qui satisfont la grille. Si une sortie invalide entraîne une nouvelle tentative ou une intervention humaine, ce travail peut aussi entrer dans le coût opérationnel, à condition que la méthode soit définie et appliquée de la même manière aux deux options.

Le calcul ne doit pas inclure des coûts qui n’ont pas été mesurés. Si l’infrastructure, le temps de vérification ou les nouvelles tentatives sont exclus, il faut le préciser. Le résultat vaut pour la configuration et le volume considérés ; il ne constitue pas une caractéristique universelle du modèle.

Traiter la confidentialité et la gouvernance comme des propriétés du canal

La confidentialité ne se déduit ni du nom du modèle ni de sa capacité à classer des demandes. Elle dépend des conditions du service précis : quelles données sont envoyées, combien de temps elles sont conservées, qui peut y accéder, si elles sont utilisées à d’autres fins et quels contrôles le canal propose. Ces conditions peuvent varier entre une interface grand public, un service d’entreprise et une API ; elles ne doivent donc pas être présentées comme une propriété générale d’Opus 5.5 ou de Sonnet 5.5.

Avant de tester des demandes réelles, la personne responsable doit identifier le canal, vérifier les conditions qui s’y appliquent et obtenir les autorisations internes requises. Si cette vérification n’est pas possible, il faut utiliser des données synthétiques ou correctement anonymisées, sachant que l’anonymisation ne supprime pas automatiquement tous les risques. Les secrets, identifiants de connexion et données personnelles non indispensables à l’évaluation doivent également être exclus.

Même lorsque les conditions de traitement sont acceptables, la sortie doit être considérée comme une suggestion tant que l’évaluation et les mécanismes de contrôle ne justifient pas une autre approche. Une mauvaise classification peut avoir des conséquences sur les délais de réponse ou sur la qualité du service reçu. Pour les décisions relatives à la priorité, à l’accès, à l’indemnisation ou à la clôture d’un dossier, la politique doit préciser le contrôle humain requis et la façon de corriger les erreurs.

Publier une conclusion sans en exagérer la portée

Un rapport utile présenterait les résultats globaux et ceux ventilés par type de demande, ainsi que le protocole, le nombre de cas, les étiquettes de référence, les instructions et les configurations vérifiées. Il expliquerait aussi les exclusions, les cas incertains, les erreurs les plus lourdes de conséquences et les conditions d’accès qui n’ont pas pu être harmonisées. Lorsque les conditions de publication le permettent, les éléments nécessaires à la reproduction du test seraient partagés, sans données susceptibles d’identifier des clients.

La conclusion doit se limiter à la population, au canal et à la configuration évalués. Si Sonnet 5.5 présente un coût par cas accepté plus bas sur un jeu composé de demandes courantes, cela ne prouve pas qu’il est préférable pour tous les types de support. Si Opus 5.5 détecte davantage de cas ambigus dans un échantillon donné, cela ne démontre pas non plus un avantage universel. Le résultat peut justifier un test en mode silencieux ou un pilote avec vérification humaine, mais pas une automatisation immédiate.

Les conditions d’un essai en production doivent être fixées à l’avance : taux maximal d’erreurs critiques, proportion de sorties valides, politique d’escalade, contrôles de confidentialité et mécanisme de retour à la situation précédente. Si ces seuils ne sont pas atteints, la prudence consiste à maintenir la vérification humaine ou à renoncer au déploiement. Si les deux modèles échouent de façon similaire dans une catégorie, le problème vient peut-être du schéma, de la politique ou de la qualité des données, plutôt que d’une différence que le choix du modèle pourrait résoudre.

Au vu des éléments actuellement vérifiés, aucun des deux modèles ne peut être recommandé comme gagnant pour le triage. Les conditions nécessaires à une décision sont toutefois claires : confirmer les identifiants et les canaux, définir une grille, exécuter la même série de cas dans des conditions documentées et mesurer les erreurs qui ont une incidence sur les opérations. Tant que ces données ne sont pas disponibles, tout choix reste une hypothèse à tester, et non une conclusion étayée.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.