Sélection du modèle Claude Code pour le travail analytique

Claude Code utilise Sonnet par défaut, ce qui convient à la plupart des tâches d’analytics engineering. Mais vous pouvez changer de modèle en cours de session, et savoir quand monter à Opus fait une vraie différence dans la qualité des sorties pour certaines tâches.

Changer de modèle

La commande /model affiche les modèles disponibles et permet de changer :

/model

Vous pouvez également lancer Claude Code avec un modèle spécifique :

claude --model opus

Le changement prend effet immédiatement. Votre historique de conversation est conservé — vous ne perdez pas le contexte lors du changement de modèle.

Sonnet : le choix quotidien

Sonnet est plus rapide, moins coûteux (en facturation API) et consomme moins de quota d’abonnement. Pour la majorité des tâches d’analytics engineering, il produit des sorties indiscernables d’Opus :

• Génération de modèles de base — La réplication de patterns à partir de modèles existants est bien dans les capacités de Sonnet. Il lit vos conventions, les applique de manière cohérente, génère le YAML. Voir Génération de modèles de base avec Claude Code.
• Écriture de tests — Tests de schéma, contraintes d’unicité, vérifications de non-nullité. La densité de patterns est élevée et la complexité conceptuelle est faible.
• Documentation — Descriptions de colonnes, descriptions de modèles, blocs de docs. Sonnet génère des brouillons solides qui nécessitent peu d’édition.
• Débogage simple — Erreurs de build avec des messages d’erreur clairs, références de colonnes manquantes, appels ref() cassés.
• Exploration de la base de code — “Expliquer cette structure de projet” ou “tracer le lignage de la source au mart” sont des tâches de lecture et de résumé que Sonnet gère proprement.

Si vous démarrez avec Claude Code, restez sur Sonnet. Ne passez à Opus que lorsque vous avez constaté un cas où la sortie de Sonnet est insuffisante.

Opus : l’amélioration du raisonnement

Opus offre une profondeur de raisonnement substantiellement supérieure. La différence apparaît dans les tâches qui nécessitent de maintenir simultanément plusieurs contraintes, de tracer une logique complexe sur de nombreux fichiers, ou de produire des sorties qui requièrent une véritable planification plutôt qu’une simple application de patterns.

Passez à Opus pour :

• Débogage de modèles incrémentaux complexes — Lorsqu’un modèle incrémental produit des résultats incorrects et que le problème implique l’interaction entre le prédicat incrémental, la clé unique et la stratégie de merge, Opus trace la logique de manière plus fiable. Sonnet manque parfois des cas limites dans le raisonnement multi-étapes sur la façon dont is_incremental() interagit avec unique_key et merge_update_columns.
• Refactorisation de logique de macros imbriquées — Les macros Jinja qui appellent d’autres macros, avec une logique conditionnelle et des varargs, nécessitent que le modèle maintienne toute la chaîne d’appel en mémoire pendant le raisonnement sur la refactorisation. Opus maintient ce contexte plus précisément.
• Décisions architecturales multi-fichiers — Lorsque vous demandez à Claude de restructurer un groupe de modèles (diviser un mart complexe en couches intermédiaires, repenser une stratégie de jointure sur une section de DAG), Opus produit des plans plus cohérents car il raisonne plus rigoureusement sur les dépendances.
• Investigations de qualité des données subtiles — “5% des sessions ont une attribution NULL et nous ne savons pas pourquoi” nécessite que le modèle forme des hypothèses, trace les données à travers plusieurs transformations et identifie quelle étape introduit le problème. La profondeur de raisonnement supplémentaire d’Opus est importante ici.

Le compromis coût-vitesse

En facturation API, Opus coûte environ 5 fois plus par token que Sonnet et est nettement plus lent. Une génération de modèle de base qui prend 30 secondes sur Sonnet peut prendre 90 secondes sur Opus, avec une qualité de sortie identique.

Sur un plan d’abonnement, le compromis est l’utilisation du quota plutôt que le coût direct. Opus consomme davantage de votre allocation d’utilisation par interaction.

La règle pratique : utiliser Sonnet par défaut, monter à Opus lorsque la sortie de Sonnet est insuffisante. N’utilisez pas Opus par anticipation parce qu’une tâche “semble difficile”. Essayez d’abord sur Sonnet. Si la sortie rate des contraintes, perd le fil des dépendances ou ne maintient pas le problème complet en contexte, passez à Opus et ré-invitez.

C’est différent du choix de modèle dans l’API pour une tâche ponctuelle. Dans Claude Code, vous pouvez essayer Sonnet, évaluer le résultat en quelques secondes et monter à Opus dans la même session. Le coût d’essayer d’abord le modèle moins cher est presque nul.

Sélection de modèle pour des workflows spécifiques

Un pattern pratique

Certains analytics engineers développent un workflow en deux passes pour les tâches complexes :

1. Passe Sonnet : Générer l’implémentation initiale. Rapide, peu coûteux, structure correcte.
2. Revue Opus : Passer à Opus et lui demander de revoir le code généré par Sonnet. “Review this incremental model for edge cases in the merge strategy.” Opus détecte les problèmes introduits par Sonnet.

Cela combine la vitesse de Sonnet pour la génération avec la profondeur d’Opus pour la revue. Le coût total est inférieur à tout faire sur Opus, et la qualité de sortie est souvent supérieure parce que l’étape de revue est explicitement formulée comme une recherche de problèmes plutôt qu’une génération depuis zéro.