Claude Opus 5.5 : comment le tester sur vos tâches data

Claude Opus 5.5 est sorti le 22 septembre. Pour une équipe data, la question intéressante est assez précise : peut-il aider à relire du SQL, diagnostiquer un pipeline ou préparer une analyse avec moins de corrections humaines ?

Anthropic met en avant le travail sur le code et les tâches longues. C’est une raison de l’essayer, pas encore une raison de remplacer un workflow qui fonctionne. Les résultats de l’éditeur ne mesurent ni vos règles métier, ni le temps que vos analystes passent à vérifier une réponse. Annonce officielle du 22 septembre.

Je commencerais par une tâche circonscrite, avec un résultat attendu et un moyen de vérifier les erreurs. Cet article propose trois cas d’usage et un atelier SQL téléchargeable. Le jeu SQL et son corrigé ont été exécutés localement. Aucun appel à Opus 5.5 n’a été réalisé pour cet article : il s’agit d’un protocole à reproduire, pas d’un benchmark du modèle.

Qu’est-ce que Claude Opus 5.5, concrètement ?

Opus 5.5 est un modèle génératif d’Anthropic. Un programme peut lui transmettre des instructions, du texte, du code ou des images, puis récupérer une réponse. L’identifiant de la Claude API est claude-opus-5-5. Sa documentation indique une fenêtre de contexte d’un million de tokens et une sortie maximale de 128 000 tokens. Ces limites décrivent une capacité technique ; elles ne garantissent pas une analyse exacte d’un dossier volumineux. Fiche du modèle.

Il faut distinguer trois choses : le modèle, qui produit les réponses ; l’API, qui permet de l’appeler ; l’application, qui lui prépare le contexte et, éventuellement, des outils. Une requête contenant votre SQL ne donne pas automatiquement au modèle accès à Snowflake, au catalogue de données ou aux logs de production.

Pour relire un calcul de marge, votre application doit donc lui fournir la requête, le schéma utile et la définition métier. Pour vérifier effectivement le calcul, il faut ensuite un moteur SQL et un jeu de données de référence. Le modèle peut proposer une correction et expliquer un risque ; la base permet de contrôler le résultat.

Ce qui change pour une intégration existante

La migration mérite un passage dans la documentation avant de changer le nom du modèle. Opus 5.5 ne permet plus de désactiver le raisonnement. Les appels qui forcent un outil avec certains réglages de tool_choice sont rejetés. Les réponses peuvent commencer par des blocs de raisonnement : un code qui lit systématiquement content[0].text doit sélectionner les blocs par leur type. Guide de migration.

Autre détail utile : l’effort par défaut devient medium. Ce paramètre oriente la profondeur du traitement, sans fixer un budget strict de tokens. Pour comparer deux configurations, enregistrez-le explicitement et testez plusieurs niveaux sur votre tâche. Un nom de réglage identique entre deux générations ne prouve pas un comportement identique. Documentation du paramètre effort.

Trois cas d’usage à tester dans un département data

1. Relire une requête SQL avant une mise en production

Un analyste livre un calcul mensuel du chiffre d’affaires. La requête fonctionne, mais sa borne de fin exclut une partie des commandes. Ce type d’erreur est un bon candidat à une revue assistée : le problème porte sur le sens du calcul, au-delà de la syntaxe.

Le dossier transmis devrait contenir la règle métier, les types de colonnes, la requête et quelques lignes couvrant les limites. Demandez une correction minimale, les conséquences de l’erreur et les tests à ajouter. Évitez une consigne générale comme « optimise ce SQL », qui mélange justesse et performance.

Le gain à mesurer : combien d’erreurs utiles sont détectées avant la revue humaine, et combien de temps faut-il pour valider la correction ? Comptez aussi les alertes infondées. Un assistant qui fait réécrire une requête correcte peut coûter plus de temps qu’il n’en fait gagner.

Cette démarche prolonge le travail sur les modèles sémantiques et les définitions d’indicateurs. Sans règle claire, le modèle peut produire un SQL cohérent qui répond à une autre question.

2. Préparer le diagnostic d’un pipeline en échec

Un traitement d’ingestion échoue après une évolution de schéma. Vous disposez du message d’erreur, du changement de code et du contrat attendu. Opus peut être évalué sur sa capacité à relier ces éléments, classer les hypothèses et proposer les vérifications suivantes.

Le livrable utile ressemble à une fiche d’incident : faits observés, hypothèses, contrôle à effectuer, correction possible et risque de reprise. Il faut distinguer « une colonne semble absente » de « la source a été modifiée », si cette seconde affirmation n’est pas établie par les traces.

Le gain à mesurer : le temps nécessaire pour obtenir une hypothèse vérifiable. Pour le premier essai, rejouez un incident résolu avec ses traces expurgées et gardez la résolution pour l’évaluateur. La proposition reste soumise à revue avant toute relance ou modification du pipeline.

3. Préparer une note d’analyse à partir de résultats contrôlés

Une direction commerciale demande pourquoi les ventes baissent. L’équipe data a déjà calculé les agrégats par produit, canal et période. Le modèle peut aider à organiser les observations et à préparer une note lisible.

Fournissez des résultats calculés, leur périmètre et les définitions des indicateurs. Demandez de distinguer variation observée, explication possible et donnée manquante. Une baisse du panier moyen n’établit pas à elle seule la cause d’un recul de chiffre d’affaires.

Le gain à mesurer : le temps de rédaction après contrôle des chiffres, ainsi que les affirmations non soutenues par les données. Une note bien écrite mais causalement fausse doit échouer à l’évaluation.

Ces trois usages demandent une réponse élaborée. Pour une simple affectation à une catégorie, comparez aussi les solutions spécialisées, comme dans notre guide de Jev de TypeSafe AI. L’architecture peut réserver un modèle généraliste aux dossiers qui nécessitent une analyse supplémentaire.

Prix API : combien coûte un essai d’Opus 5.5 ?

Au 25 septembre 2026, le tarif standard de la Claude API est de 4 dollars par million de tokens d’entrée et 20 dollars par million de tokens de sortie, contre 5 et 25 dollars pour Opus 5. À volume strictement identique, cela représente une baisse de 20 %. Tarifs officiels.

Exemple purement arithmétique : avec 10 000 tokens d’entrée non mis en cache et 2 000 tokens de sortie facturés, un appel reviendrait à 0,08 dollar. Pour 1 000 appels identiques, ce serait 80 dollars. Ce n’est ni une mesure de notre atelier, ni un devis pour vos requêtes. Le nombre de tokens dépend des contenus et du comportement du modèle.

Le raisonnement compte dans la sortie facturée, même lorsque son texte n’est pas affiché. max_tokens limite le total raisonnement et réponse. Il faut donc regarder l’usage retourné par l’API, pas seulement la longueur du texte visible. Fonctionnement du raisonnement adaptatif.

Le calcul économique doit aussi intégrer les tentatives supplémentaires, les outils éventuels et la revue humaine. Pour un lot, comparez :

• le coût API de toutes les tentatives rapporté aux tâches acceptées ;
• le temps de contrôle et de correction par tâche ;
• la part du lot effectivement traitée avec une qualité acceptable.

Gardez les frais API en dollars et le temps humain en minutes tant que vous n’avez pas choisi un taux de conversion et une valorisation explicites. Si vous utilisez déjà le cache ou le traitement par lots, appliquez vos conditions réelles des deux côtés de la comparaison.

Tutoriel : construire un premier test de revue SQL

L’atelier utilise Python 3.10 ou une version ultérieure et SQLite, inclus dans la bibliothèque standard Python. La partie locale fonctionne sans clé API. L’essai du modèle est une seconde étape, facultative et facturable.

Étape 1 : télécharger le cas et son corrigé

Enregistrez ces fichiers dans un même dossier :

• cas.sql, les commandes fictives ;
• requete-a-relire.sql, la requête à évaluer ;
• correction-reference.sql, le corrigé réservé à l’évaluateur ;
• verifier_sql.py, les contrôles locaux ;
• requete.json et appeler_claude.py, pour l’essai API ;
• grille-evaluation.csv et mode d’emploi.

La règle est volontairement précise : additionner les commandes paid d’août 2026, mois défini en UTC, avec un montant en centimes et zéro en l’absence de commandes. Toutes les dates du fichier sont des chaînes homogènes dans ce fuseau. Pour votre activité, adaptez ensuite la règle au fuseau de référence métier.

Étape 2 : constater l’erreur indépendamment du modèle

La requête initiale contient :

WHERE status = 'paid'
  AND paid_at BETWEEN '2026-08-01' AND '2026-08-31'

Dans ce jeu SQLite, les horodatages du 31 août comportent aussi une heure. Ils sont supérieurs à la chaîne de fin 2026-08-31 et sont exclus. Une borne supérieure exclusive au début du mois suivant corrige le problème :

WHERE status = 'paid'
  AND paid_at >= '2026-08-01'
  AND paid_at < '2026-09-01'

Lancez :

python3 verifier_sql.py

Le contrôle doit retrouver 30 000 centimes pour la requête initiale et 42 000 pour le corrigé. Il vérifie les commandes incluses, l’exclusion des commandes annulées et le résultat zéro sans commande payée. Ces nombres appartiennent uniquement à ce petit jeu fictif.

Étape 3 : lancer volontairement l’essai API

Créez une clé depuis la console Claude, puis fournissez-la à votre environnement via ANTHROPIC_API_KEY, par exemple avec votre gestionnaire de secrets. Dans le dossier de l’atelier, créez un environnement Python et installez le SDK :

python3 -m venv .venv
source .venv/bin/activate
python -m pip install anthropic
python appeler_claude.py

L’accès au modèle et les quotas restent ceux de votre compte. La requête préparée fixe model à claude-opus-5-5, output_config.effort à medium et max_tokens à 4096. Elle transmet les règles, le jeu fictif et le SQL initial, sans le corrigé. Le script conserve la réponse et l’usage dans un fichier horodaté. Son code a été contrôlé localement ; son exécution contre le service reste à réaliser.

Lisez stop_reason avant de noter la réponse. Une sortie arrêtée par max_tokens est incomplète ; un refus doit également être compté. Même end_turn ne valide pas la justesse du SQL. Relisez la proposition, puis testez-la dans une base isolée. Le script fourni n’exécute jamais la requête produite par le modèle. Gestion des fins de réponse.

Étape 4 : comparer et décider

Évaluez d’abord quatre points : l’erreur est-elle identifiée, la correction préserve-t-elle la règle, les cas limites sont-ils couverts, le modèle prétend-il avoir exécuté un test sans outil ? Ajoutez ensuite la latence, l’usage API et le temps de revue dans le CSV.

Rejouez le même cas avec votre traitement actuel et gardez toutes les tentatives. Puis élargissez à des requêtes représentatives, y compris des requêtes déjà correctes. Conservez un lot distinct pour vérifier que vos ajustements de consigne ne fonctionnent pas uniquement sur les exemples connus.

Une erreur de borne trouvée sur un exemple ne suffit pas à décider d’une migration. En revanche, des corrections plus utiles, un taux d’acceptation maintenu et moins de revue sur vos cas peuvent justifier un essai limité dans le workflow.

Où commencer dans votre équipe ?

Je choisirais une tâche déjà bien définie, avec un propriétaire et un historique de résultats contrôlés. La revue SQL est un bon point de départ lorsque votre équipe peut vérifier les réponses rapidement. Sur un diagnostic d’incident, la qualité des traces fournies devient déterminante.

Pour un nouveau workflow, testez Opus 5.5 dès la conception à côté des autres options. Pour un flux existant, mettez le coût de migration et de maintenance dans le calcul. Une économie d’inférence peut être intéressante, mais elle doit couvrir le travail qu’elle déclenche.

Chez Nymphar, c’est le type de décision que nous proposons de cadrer avec les équipes data : choisir une tâche, définir les critères d’acceptation, puis mesurer ce que l’IA améliore réellement. Échanger sur votre cas d’usage.