Formation Claude Opus

Dans cet atelier, nous comparons trois gammes de modèles Anthropic : Claude Haiku, Sonnet et Opus. Le mot français « haïku » s'écrit avec un tréma, contrairement au nom du modèle. Haiku vise les demandes brèves, Sonnet le quotidien et Opus les problèmes qui réclament davantage de raisonnement. Chaque intelligence artificielle reste testée sur le besoin réel.

Le parcours part du besoin. Le même prompt passe sur Haiku, Sonnet et Opus. On compare justesse, prix par réponse acceptée, jetons et temps de reprise. Pour classer 2 000 lignes, le modèle Haiku peut suffire ; une analyse à plusieurs contraintes peut justifier Sonnet ou Opus.

Claude dans claude.ai et Claude via l'API d'Anthropic répondent à des usages distincts. L'interface convient à une conversation ou à l'analyse ponctuelle d'un fichier ; l'API sert une production répétée ou des agents. Le compte rendu note le canal, la version et les fonctions autorisées. Sans ces données, deux utilisateurs peuvent croire comparer Opus avec des réglages différents. L'identifiant model et les capacités sont contrôlés dans la comparaison officielle des modèles Claude.

Le jeu d'essai reprend des tâches réelles : contrats, tableaux, pièces techniques, migration ou bugs. Chaque tâche a une réponse de référence, un seuil et des erreurs critiques. La sortie est relue à l'aveugle lorsque le protocole le permet.

La même consigne passe sur Claude Opus, Claude Sonnet et Haiku. Les fichiers, les paramètres et la grille restent identiques. Haiku 4.5 dispose de la réflexion étendue, mais pas de la réflexion adaptative ni du paramètre effort. Le coût inclut le prix par million de jetons, les relances, les contrôles et la correction humaine. Opus peut revenir moins cher s'il évite trois reprises.

Le banc garde le prompt, l'identifiant model, la date, les jetons, les sources et la réponse validée. Une nouvelle version reprend le dossier. La décision remplace les avis « Opus est meilleur » ou « Sonnet suffit » et reste lisible pour les utilisateurs, les développeurs et le responsable du budget.

Claude Opus 4.8 prend en charge la réflexion adaptative, activée dans l'API avec thinking: { type: "adaptive" }. Sans ce réglage thinking, la requête s'exécute sans réflexion adaptative. Le paramètre effort vaut « high » par défaut et peut être abaissé après mesure du budget et de la qualité. Ces réglages évoluent : on vérifie la documentation officielle du réglage et l'écran réellement disponible avant l'exercice.

Nous comparons trois réglages sur des cas complexes : niveau bas, niveau intermédiaire et niveau élevé. Le dernier est réservé aux problèmes où le modèle examine plusieurs hypothèses ou contrôle un calcul. Chaque mode impose une conclusion courte, des éléments vérifiables et les incertitudes. Le raisonnement interne n'est pas une preuve.

Le réglage retenu répond à une question concrète : quelle valeur minimale atteint le seuil de qualité ? Ce principe vaut pour Opus, Sonnet et toute autre intelligence artificielle. Il réduit le budget d'une chaîne de production et limite une conversation interminable. Il aide aussi à détecter un besoin mal défini : si cinq relances sont nécessaires, le problème vient parfois du prompt, des données ou du détail demandé.

La fiche d'essai consigne le mode thinking, le niveau effort et le comportement standard utilisé comme référence. Les valeurs low, medium et high sont testées sur la même tâche lorsqu'elles sont disponibles. Une section séparée note la qualité, le délai et le coût : changer de mode sans garder ce contexte rend la comparaison inutilisable.

Une grande fenêtre ne transforme pas un dossier mal rangé en bonne analyse. Anthropic documente actuellement l'identifiant figé claude-opus-4-8, une fenêtre de contexte d'un million de jetons et une sortie totale maximale de 128 000 jetons dans Messages synchrone, calcul interne compris. Ces valeurs sont vérifiées au moment du projet. Même disponible, le million n'est pas un objectif. Charger toutes les pièces d'une entreprise augmente le bruit, le coût et le risque d'exposer une information inutile.

Le travail commence par un tri des pièces nécessaires et des éléments interdits. Le contenu extrait d'un PDF est contrôlé, les tableaux sensibles sont échantillonnés et les doublons sont retirés. On découpe les tâches complexes en étapes observables. Claude reçoit d'abord les règles, puis les fichiers utiles, puis la question. Ce format donne souvent une réponse plus stable qu'une consigne géante.

Les utilisateurs apprennent à lire les tokens sans en faire une science décorative. Les input tokens correspondent aux éléments envoyés ; les output tokens couvrent la réponse et le calcul interne. Les tokens du prompt dépendent notamment des pièces et de la conversation. Lorsqu'un cache est utilisé, les cached tokens sont relevés à part. Chaque relevé sépare donc input tokens, output tokens et cached tokens. On calcule le budget d'un cas accepté sur plusieurs essais. C'est plus honnête qu'un prix théorique au million, surtout lorsque des appels supplémentaires ajoutent leurs propres échanges. Le tarif applicable est repris dans la grille tarifaire officielle d'Anthropic le jour du test.

MTok signifie un million de tokens dans une grille de prix. Ce n'est pas un forfait par conversation : un calcul sépare le volume input, le volume output et les éventuelles lectures de cache. Le relevé conserve le nombre de MTok, le tarif daté et la devise. Il évite ainsi de comparer un prix par MTok à un coût total de tâche.

Le prompt caching peut réduire la part répétée d'un contexte stable. L'équipe distingue l'écriture du cache, sa lecture et les tokens qui restent hors cache. Un test sans cache sert de référence ; le prompt caching n'est retenu que si le contenu est réellement réutilisé et si la qualité reste identique.

La Batch API convient aux traitements qui n'exigent pas une réponse immédiate. Un lot pilote vérifie les entrées, les sorties, les erreurs et le délai avant un volume plus grand. Le coût de la Batch API est lu dans la page pricing officielle le jour du test. Aucun tarif, plafond ou délai de Batch API n'est recopié sans date.

Pour comparer une requête standard, une requête avec prompt caching et un batch, le tableau garde quatre colonnes : input, output, MTok facturés et résultat accepté. Cette lecture évite de choisir le mode le moins cher sur une réponse inutilisable. Elle permet aussi de repérer un fichier ou une section qui gonfle le contexte sans améliorer la réponse.

La section pricing sépare quatre relevés : usage standard, usage avec caching, usage en batch et usage web. Chaque relevé note l’input en MTok et la sortie en MTok et le total de token. La ligne pricing standard garde le MTok input et le MTok de sortie. La ligne pricing caching garde le MTok écrit, le MTok relu et chaque token hors caching. La ligne pricing batch garde le MTok input, le MTok de sortie et les erreurs du batch. Le contrôle pricing compare ensuite standard, caching et batch sans mélanger les unités. Un second lot en batch et un second essai caching vérifient la stabilité.

Pour une session web, la section de contrôle distingue le tool appelé, son input et sa sortie. Une session web de référence fixe le context autorisé ; chaque tool reçoit le même context. L’équipe note quel tool reste utile dans le web, puis quel tool doit être retiré. Le test emploie le réglage standard, puis un réglage fast uniquement s’il est disponible. Un troisième essai fast confirme le résultat ; une session AWS est documentée séparément. La fiche emploie les libellés web, fast et AWS seulement lorsqu’ils correspondent au canal réel. Le fast mode reste une research preview réservée à Claude API ; il n’est pas disponible sur Amazon Bedrock, Google Cloud ni Microsoft Foundry.

Claude Opus peut préparer une synthèse, comparer des clauses, contribuer au design d'un document ou produire un texte long. Au lieu de « analyse ce dossier », la consigne précise le public, le format, les critères et les passages à citer. Pour une maquette de design, on fournit les contraintes d'usage et une grille de revue. Pour la rédaction, on indique les faits autorisés, les mots interdits et la longueur attendue.

La première réponse sert de matière, pas de verdict. Une recommandation de design peut ignorer l'accessibilité. Cette intelligence artificielle n'est pas une source. Nous ouvrons les références, testons les nombres et faisons relire les décisions sensibles par une personne compétente. La méthode s'applique à une proposition commerciale comme à l'analyse de contrats, de tableaux et de dossiers.

Pour comparer Sonnet et Opus, on évite de changer dix paramètres à la fois. Le même contenu de départ, la même consigne et la même grille passent dans les deux versions. Les différences sont annotées : omission, invention, structure, style, temps de correction. Après quelques cas, l'équipe sait lesquels méritent Opus et lesquels restent sur un assistant plus léger.

Le terme anglais coding désigne ici le travail sur un dépôt : lire l'architecture, expliquer des bugs, préparer une migration et proposer des tests. Un exercice de coding fournit l'objectif, les commandes autorisées et la définition de « terminé ». Claude ne connaît ni vos règles de production ni l'intention cachée derrière un ancien module. Avant toute édition, l'agent lit les fichiers concernés et reformule le périmètre.

Une intervention de développement est découpée : reproduire le défaut, localiser la cause, modifier le minimum, lancer les contrôles, puis présenter les différences. Les développeurs relisent les lignes sensibles lors de la revue de code. Aucun assistant ne pousse en production, ne supprime une base ou ne contacte un utilisateur sans validation explicite. Les failles de sécurité, les migrations de données et les changements de facturation reçoivent un contrôle supérieur.

Les bancs de coding comme SWE-bench Verified ou Terminal-Bench donnent un repère sur une version et un protocole. Ils ne prouvent pas qu'un modèle réussira votre projet. Nous ajoutons donc un benchmark de coding issu du travail réel : une migration réversible, des bugs connus, un test manquant et une consigne ambiguë. Ce protocole de coding attend plus que du code qui compile : une correction comprise, testée et révisable.

Un agent relie Claude à des outils : recherche, terminal ou logiciel interne. Un système autonome reçoit une liste limitée d'actions en lecture et d'actions modifiantes, avec un budget de jetons, un nombre de tentatives et une condition d'arrêt. Les agents consignent les commandes et rendent leurs sorties avant toute intégration.

Automatiser ne retire pas l'humain. Une chaîne peut classer des documents ou lancer une génération de façon autonome. Aucun message externe ni changement de production ne part sans feu vert. L'autonomie dépend de la gravité d'une erreur. Le relevé des dépenses peut être automatique sans automatiser la décision.

Claude Code, le Claude Agent SDK et le Model Context Protocol peuvent servir cette intégration. Selon les fonctions nécessaires, Claude est également accessible par la Claude API, Claude Platform sur AWS, Amazon Bedrock, Google Cloud et Microsoft Foundry. Avant d'automatiser, l'équipe vérifie la page officielle du fournisseur, le contrat, la conservation des données et les outils réellement disponibles. Chaque outil est limité aux seules actions requises.

Une session web et une session API ne donnent pas forcément accès au même tool ni au même contexte. Pour chaque fournisseur, la fiche précise l'API, la région AWS ou cloud retenue, le model, les fichiers autorisés et le responsable. Ces éléments sont vérifiés avant l'essai ; ils ne sont pas déduits du nom commercial affiché dans une interface.

Une erreur d'outil doit rester visible. Le système ne transforme pas un échec réseau, un fichier absent ou un test rouge en réussite. Pour une action réversible, l'équipe prévoit aussi le retour à l'état précédent avant d'accorder le droit de modification.

Un comparatif sérieux ne se résume pas à opposer Claude à ChatGPT. GPT désigne une famille d'OpenAI ; ChatGPT est une interface et un ensemble de fonctions. Gemini recouvre également plusieurs versions et produits de Google. Nous notons l'identifiant model exact, le mode activé, le prix applicable et les fonctions fournies. Sans cette fiche, le match GPT, ChatGPT et Claude est impossible à reproduire.

Le protocole utilise les mêmes tâches : génération de contenu, analyse de fichiers, codage, recherche d'erreurs et planification complexe. Claude Opus, un GPT disponible dans ChatGPT et un modèle Gemini reçoivent les mêmes éléments. Chaque intelligence artificielle est jugée sur les faits, les omissions, le temps de reprise et le budget. Le meilleur choix peut varier entre conception, mise au point et conversation client.

Pour un chatbot d'intelligence artificielle, le temps de réponse et la stabilité comptent autant que la profondeur. Le chatbot interne peut accepter un délai pour analyser un dossier ; le chatbot public doit aussi respecter son plafond de dépenses et son mode de repli. Un chatbot n'envoie aucune réponse sensible sans règle de validation adaptée au risque.

Cette comparaison protège aussi contre les habitudes. Certains utilisateurs préfèrent l'interface qu'ils connaissent, même si un autre assistant réussit mieux un cas précis. Le tableau final indique quel assistant employer, pour quel besoin, avec quelle consigne et quelle validation.

Un atelier commence par trois tâches représentatives. Claude Opus, Claude Sonnet et Claude Haiku reçoivent le même prompt et les mêmes fichiers. Pour chaque modèle, la fiche note les tokens d'entrée, les tokens de sortie, les erreurs et les reprises humaines. Le groupe compare les résultats sans changer les critères.

Pour le code, Claude Opus lit d'abord les règles du projet, puis le code concerné. Le scénario demande une correction minimale et une revue de code. Les agents n'utilisent que les outils autorisés. Le compte rendu conserve model, thinking et effort afin que l'équipe puisse rejouer le banc d'essai et comparer les sorties.

Pour un document ou une maquette de design, deux utilisateurs relisent les productions issues du même brief. Le dossier passe dans Opus, Haiku, un modèle GPT via ChatGPT et un modèle Gemini. La fiche relève les omissions, les erreurs, la stabilité et le coût de reprise.

Le journal cite la documentation d'Anthropic, sa date et l'identifiant du modèle. Quand une capacité ou une version change, le même protocole est relancé. Opus n'est retenu que si son gain mesuré justifie son coût.

Chaque projet se termine par une fiche de décision. Elle reprend les modèles testés, le volume de jetons, le coût observé, les erreurs, les contrôles et le résultat retenu. Une conclusion peut être simple : Haiku pour le tri, Sonnet pour le quotidien, Opus pour quatre tâches complexes bien identifiées.

Les réponses sensibles restent soumises à une revue humaine. Une analyse juridique n'est pas un avis d'avocat ; une proposition financière n'est pas une décision ; du code généré n'est pas une mise en production. La preuve exigée augmente avec le risque. Sources, tests, journal d'exécution et accord explicite forment la chaîne de contrôle.

Enfin, le banc d'essai est relancé quand Anthropic, OpenAI ou Google change un modèle. On ne promet pas qu'Opus gardera les mêmes capacités, le même prix ou la même fenêtre. Le parcours montre comment produire une grille d'évaluation, un journal des versions, une règle de bascule, un budget par tâche et un protocole de validation.