MSO Foundations

Screen 1: What you will be able to do by the end

MODULE 1 ORIENTATION · 2 MIN Ce que vous serez capable de faire à la fin

Avant d'écrire une ligne de code contre Claude, il est utile de savoir ce que les mots signifient.

Ce module introduit les fondamentaux du modèle et les bases techniques que le reste du cours Developer suppose que vous maîtrisez déjà.

À la fin de ce module, vous serez capable de : 1 Expliquer ce qu'est un token, comment la context window fonctionne comme un budget fixe, pourquoi l'échantillonnage rend les résultats variables, et ce que la non-déterminisme signifie pour les tests et les evals. 2 Décrire la famille de modèles Claude et ses niveaux de capacité, et distinguer le choix d'un modèle de l'activation d'un mode de raisonnement tel que la réflexion étendue. 3 Choisir entre le prompting zero-shot, one-shot et multi-shot, et peser le compromis coût-qualité de l'ajout d'exemples. 4 Décrire comment un développeur accède à Claude : SDK versus REST brut, réponses synchrones versus streaming, et modèles asynchrones pour les travaux à haut volume. DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

Nous avons construit ce cours Developer Module 1: MSO Foundations pour vous aider à accomplir du vrai travail avec Claude. Traitez-le comme du contenu éducatif. Il ne constitue pas un conseil juridique, financier ou autre conseil professionnel, alors adaptez ce que vous apprenez à votre propre situation. Nos produits et services évoluent rapidement, donc certains contenus peuvent contenir des erreurs ou être obsolètes ; n'oubliez pas de vérifier sur le site web ou la documentation d'Anthropic. Les exemples et scénarios utilisés dans le cours sont illustratifs et souvent fictifs. Si le matériel du cours mentionne une entreprise ou un produit, cela ne signifie pas qu'Anthropic les approuve, qu'ils approuvent Anthropic, ou que nous sommes affiliés. Notez également que votre utilisation des produits et services d'Anthropic est couverte par nos conditions, politiques et documentation ; si quelque chose dans ce cours entre en conflit avec eux, ils prévalent.

Screen 2: How LLMs behave: tokens, context, sampling, non-determinism

TeachingHow LLMs Behave·12 min Comment les LLM se comportent : tokens, context, sampling, non-déterminisme

Tokens Context Window Sampling Non-déterminisme

Tokens : l'unité d'entrée, de sortie et de coût Claude ne lit pas les caractères ou les mots directement. Il lit les tokens, et la moyenne de caractères par token dépend du tokenizer du modèle en question et diffère entre les générations de modèles. Traitez toute règle empirique de caractères par token comme dépendante du modèle et confirmez le comportement actuel du tokenizer au moment de la construction. Tout ce que le modèle traite est compté en tokens : votre prompt, l'historique de la conversation, les définitions d'outils, les résultats d'outils, et la réponse que le modèle génère. Les tokens sont l'unité à la fois de la tarification et du budget, donc quand vous estimez ce qu'une fonctionnalité coûte ou si une entrée s'adapte, vous comptez les tokens, pas les mots. Une habitude utile est de penser en tokens, puisque c'est l'unité dans laquelle l'API facture et que la context window mesure.

La context window : un budget fixe La context window est le nombre total de tokens que le modèle peut accepter pour une seule requête. Elle contient tout à la fois : le system prompt, la conversation complète jusqu'à présent, tous les documents que vous injectez, tous les résultats d'outils, et la sortie du modèle. C'est un budget fixe avec deux comportements limites distincts. Une requête dont l'entrée est déjà plus grande que la fenêtre est rejetée avec une erreur de validation avant que la génération ne commence. Une requête qui s'adapte à l'entrée peut toujours atteindre le plafond pendant la génération. Les modèles actuels s'arrêtent alors et retournent la sortie générée jusqu'à présent avec une raison d'arrêt model_context_window_exceeded plutôt que de lever une erreur. De toute façon, maintenir une longue session en cours d'exécution nécessite que l'application réduise ou résume l'historique avant chaque appel. En développement, la fenêtre se remplit rarement car les entrées de test sont courtes. En production, en revanche, les entrées plus longues et plus de tours remplissent la fenêtre plus rapidement. C'est l'échec que le Module 2 explore en détail.

Sampling : pourquoi le même prompt peut donner des réponses différentes Un modèle de langage ne choisit pas un seul token suivant fixe. À chaque étape, il produit une distribution de probabilité sur les tokens suivants possibles, puis en échantillonne. Les paramètres, tels que la température, façonnent cette distribution : une température plus basse concentre la probabilité sur les tokens les plus probables et rend la sortie plus répétable, tandis qu'une température plus élevée l'étale et rend la sortie plus variée. Parce que le choix est échantillonné plutôt que fixe, le même prompt exécuté deux fois peut retourner un libellé différent même quand les deux réponses sont correctes. C'est une propriété de la façon dont le modèle génère. Notez que les contrôles d'échantillonnage dépendent du modèle : les modèles Claude les plus récents n'acceptent pas les paramètres d'échantillonnage non-défaut. Définir la température, top_p, ou top_k retourne une erreur 400, et le comportement sur ces modèles est dirigé par le prompting à la place. Même où la température est acceptée, la température 0 rend les résultats plus répétables mais ne garantit pas des résultats identiques entre les appels. Confirmez le support des paramètres actuels dans la référence API au moment de la construction.

Non-déterminisme : ce qu'il signifie pour les tests et les evals Le non-déterminisme est la conséquence principale de l'échantillonnage : les entrées identiques ne garantissent pas des résultats identiques. Cela change la façon dont vous testez une fonctionnalité Claude. Un test qui affirme le texte exact d'une réponse sera incohérent, car le modèle peut exprimer la même réponse correcte de nombreuses façons. À la place, affirmez la propriété qui doit tenir : un champ requis est présent, une valeur est dans la plage, la structure s'analyse. Quand vous devez juger le sens plutôt que la structure, utilisez un eval avec un juge noté par modèle. C'est pourquoi le cours traite les evals comme la norme pour savoir qu'une fonctionnalité est correcte, et pourquoi le Module 3 construit cette capacité.

Screen 3: Model options and reasoning modes

TeachingModels & Reasoning·10 min Options de modèle et modes de raisonnement

La Famille de Modèles Modes de Raisonnement Comment Ils Fonctionnent Ensemble

La famille de modèles Claude Claude est une famille de modèles qui s'étend actuellement sur quatre niveaux : Fable, Opus, Sonnet, et Haiku. Chaque modèle représente un compromis différent entre le coût, la latence et la capacité. Sonnet est le défaut équilibré pour la plupart des charges de travail en production. Haiku est construit pour la vitesse et l'efficacité des coûts sur les tâches qui s'adaptent à son enveloppe de capacité. Opus gère le travail exigeant au-dessus de l'enveloppe Sonnet, et Fable est le niveau le plus capable, construit pour le raisonnement le plus exigeant, le codage et le travail agentique où l'intelligence maximale est la priorité. Le défaut pratique est de commencer avec Sonnet, de monter d'un niveau seulement quand un eval montre que le niveau actuel manque votre barre de qualité, et de descendre à Haiku seulement quand un eval montre que la baisse de qualité est acceptable pour la tâche. Confirmez la liste actuelle des modèles et les identifiants par rapport à platform. claude. com/docs au moment de la construction, car la famille Claude évolue.

Les modes de raisonnement sont un paramètre séparé du choix du modèle Choisir quel modèle exécuter est une décision. Que le modèle raisonne avant de répondre est une décision séparée que vous prenez par appel. Sur les modèles actuels, le mode de raisonnement est la réflexion adaptative : le modèle décide quand et combien réfléchir, et vous réglez la profondeur avec un paramètre d'effort plutôt qu'un budget de tokens fixe (le contrôle budget_tokens plus ancien est déprécié et, sur les générations de modèles les plus récentes, retourne une erreur 400). Le contenu de réflexion est omis des réponses par défaut sur les modèles les plus récents. Demandez un affichage résumé quand vous avez besoin de le montrer. Le raisonnement gagne son coût sur les problèmes difficiles et multi-étapes et est gaspillé sur les recherches et la classification. Le point clé pour ce module est que les deux leviers se composent : le choix du modèle choisit le membre de la famille, tandis que le mode de raisonnement est configuré par requête. Les défauts par modèle diffèrent (certains des modèles les plus récents pensent de manière adaptative par défaut ou toujours), donc confirmez les défauts de réflexion actuels pour votre modèle au moment de la construction.

Comment les deux fonctionnent ensemble Parce que le choix du modèle et le mode de raisonnement sont indépendants, chacun peut être défini séparément. Un modèle capable avec le raisonnement désactivé est rapide et direct, tandis qu'un modèle plus petit avec le raisonnement activé dépense plus de tokens pour réfléchir. Les tâches les plus exigeantes associent un modèle capable avec un paramètre d'effort plus élevé. Le Module 2 enseigne la mécanique de l'activation du raisonnement et la gestion des blocs de réflexion qu'il retourne. La décision de quel modèle exécuter, pesée par rapport au coût, à la latence et à la qualité, est abordée dans le Module 4.

Screen 4: Prompting modes: zero-shot, one-shot, multi-shot

TeachingPrompting Modes·8 min Modes de prompting : zero-shot, one-shot, multi-shot

Les Trois Modes Compromis Coût & Qualité Mode & Choix du Modèle

Les trois modes Séparé de la façon dont vous formulez un prompt est le nombre d'exemples travaillés que vous donnez au modèle à l'intérieur. Zero-shot donne l'instruction et aucun exemple : vous décrivez la tâche et demandez le résultat. One-shot ajoute un exemple de l'entrée associée à la sortie souhaitée. Multi-shot, aussi appelé few-shot, inclut plusieurs de ces exemples. Les exemples ne sont pas des données d'entraînement ; ils se trouvent dans le prompt et montrent au modèle la forme exacte de la réponse que vous voulez, ce qu'une description seule échoue souvent à préciser.

Le compromis coût et qualité Chaque exemple que vous ajoutez coûte des tokens à chaque appel et consomme le budget de context, donc le choix échange la qualité contre le coût. Recourez au zero-shot quand la tâche est simple et la forme de sortie est évidente. Passez au one-shot ou multi-shot quand la sortie a une structure spécifique, une casse, ou un cas limite qu'une description continue de manquer. Souvent un ou deux exemples corrects corrigent généralement le problème plus rapidement qu'un autre paragraphe d'instructions. La discipline générale, que le Module 2 renforce, est d'ajouter la plus petite quantité de prompt qui produit un résultat fiable.

Le choix du mode interagit avec le choix du modèle Le mode de prompting et le choix du modèle sont des leviers liés. Un modèle plus capable réussit souvent zero-shot sur une tâche où un modèle plus petit a besoin de quelques exemples pour correspondre à la structure, donc ajouter des exemples peut permettre à un modèle moins cher de faire le travail. Les deux décisions valent la peine d'être prises ensemble : essayez le modèle le plus simple et le moins d'exemples qui répondent à votre eval, et ajoutez la capacité ou les exemples seulement où l'eval dit que vous en avez besoin.

Screen 5: The technical substrate: SDKs, REST, streaming, async

TeachingTechnical Substrate·12 min Le substrat technique : SDK, REST, streaming, async

SDK vs. REST Sync, Streaming & Real-time Async for High-Volume Work

Comment un développeur accède à Claude : SDK versus REST brut À la base, Claude est atteint via une API REST HTTP : votre code envoie une requête à un endpoint avec votre clé API et un corps JSON, et lit une réponse JSON en retour. Vous pouvez appeler cet endpoint directement avec n'importe quel client HTTP. Plus couramment, vous utilisez un SDK officiel, disponible pour Python et TypeScript entre autres, qui est une fine couche de commodité sur la même API REST. Il gère l'authentification, la construction de requête, les tentatives et l'analyse de réponse afin que vous écriviez moins de code passe-partout. Le SDK et le REST brut atteignent la même API et le même modèle. Le SDK vous épargne d'assembler les requêtes à la main. Le Module 2 construit contre le SDK et l'API Messages, qui repose sur cette même fondation.

Réponses synchrones, streaming et en temps réel Une requête synchrone est le modèle le plus simple : vous envoyez la requête et attendez que la réponse complète revienne en une seule pièce, puis vous agissez dessus. C'est bien pour les réponses courtes et les travaux backend où personne n'attend. Quand une réponse est longue ou qu'un utilisateur regarde, le streaming envoie la réponse en pièces au fur et à mesure que le modèle la génère. La sortie apparaît immédiatement plutôt qu'après une attente d'écran blanc, et votre code réassemble les pièces dans le message final. Claude expose le streaming sur la même connexion HTTP en utilisant les événements envoyés par le serveur. Le Module 2 enseigne comment consommer un stream en toute sécurité et récupérer quand il est interrompu.

Modèles asynchrones pour les travaux à haut volume Deux modèles abordent les travaux à haut volume, et ils résolvent des problèmes différents. Le SDK Python expose un client async (AsyncAnthropic) qui utilise async/await non-bloquant pour faire des appels API sans bloquer le thread de votre application. Dans le SDK TypeScript, le client Anthropic standard est basé sur Promise, donc vous attendez les appels directement. Il n'y a pas de classe de client async séparé. De toute façon, la requête revient toujours en temps réel, mais votre application peut gérer d'autres travaux pendant qu'elle attend. C'est le bon modèle quand vous avez besoin de concurrence sans blocage. L'API Message Batches est un modèle séparé pour les charges de travail en masse hors ligne. Vous soumettez un grand ensemble de requêtes en un appel, recevez un identifiant, et interrogez la fin. Les travaux par lot peuvent prendre jusqu'à 24 heures pour se terminer et s'exécutent à un coût inférieur par token en échange de cette latence. Cela convient aux pipelines hors ligne, aux exécutions d'évaluation et aux travaux en masse où aucun utilisateur n'attend chaque résultat et où le coût importe plus que le délai d'exécution.

Screen 6: Module quiz

QuizModule 1·5 min Quiz du module Essayez maintenant. Voici quelques questions à choix multiples pour tester votre compréhension du cours jusqu'à présent. Question 1Un coéquipier dit que deux prompts identiques doivent retourner un texte identique. Quelle est la réponse la plus précise ? AC'est vrai, le modèle est déterministe. BPas nécessairement, le modèle échantillonne chaque token suivant à partir d'une distribution de probabilité, donc le libellé peut varier même quand les deux réponses sont correctes. CC'est seulement vrai si le streaming est désactivé. DC'est seulement vrai sur le plus grand modèle. Question 2Quelle affirmation sépare le mieux le choix du modèle du mode de raisonnement ? AIls sont le même paramètre. BLa réflexion étendue est un modèle différent. CChoix du modèle choisit quel membre de la famille s'exécute ; la réflexion étendue est un paramètre par appel que tout modèle de support peut exécuter avec activé ou désactivé. DLe mode de raisonnement est fixe par compte. Question 3Une tâche de classification courte et bien spécifiée retourne la bonne réponse zero-shot. Qu'est-ce que l'ajout de trois exemples fera très probablement ? AAméliore la précision substantiellement. BAjoute un coût de token à chaque appel pour peu ou pas de gain. CChange le modèle utilisé. DDésactive l'échantillonnage. Question 4Vous devez traiter des milliers d'entrées hors ligne au coût le plus bas. Quelle forme convient ? AAppels asynchrones dans une boucle. BStreaming. CEnvoi par lot avec interrogation. DUne context window plus grande.

Soumettre le quiz Ignorer pour l'instant

Screen 7: Exercise: predict the behavior

ExercisePredict the Behavior·6 min Exercice : prédire le comportement Essayez maintenant. Chaque scénario ci-dessous présente une configuration tirée de l'une des quatre fondations de ce module, l'échantillonnage, le mode de prompting, la forme de requête et le budget de context. Pour chacun, sélectionnez la réponse qui prédit le comportement correct et identifie la raison pour laquelle. Un crédit partiel est disponible quand vous répondez correctement à trois sur quatre. Scénario 1Considérez une tâche de classification exécutée à température 0 par rapport à la même tâche exécutée à une température élevée. Prédisez comment les résultats diffèrent entre les exécutions répétées. AÀ une température basse, le modèle concentre la probabilité sur les tokens les plus probables, donc les exécutions répétées retournent le même label beaucoup plus régulièrement, bien que jamais avec un déterminisme garanti, même à température 0. À une température élevée, la distribution s'étale, donc le libellé et même le label choisi peuvent varier. Pour un classificateur, vous voulez le comportement de basse température, répétable. BLes deux configurations retournent une sortie identique à chaque exécution, car la température affecte seulement la longueur de la réponse, pas quels tokens sont choisis. CLa course à température élevée est plus précise, car étaler la distribution permet au modèle de considérer plus de réponses correctes. DLa température n'a aucun effet sur une tâche de classification, car la classification retourne toujours un label fixe indépendamment de l'échantillonnage. Scénario 2Considérez une tâche qui continue de retourner une sortie dans la mauvaise structure sous un prompt zero-shot. Prédisez ce qui change si vous passez au multi-shot. AChanger au multi-shot réentraîne le modèle sur la nouvelle structure, donc le changement est permanent entre tous les appels futurs une fois que les exemples sont envoyés. BAjouter deux ou trois exemples d'entrée-sortie corrects montre au modèle la structure exacte à correspondre, ce qui corrige généralement un problème de structure que plus de texte d'instruction n'a pas fait. Le coût est des tokens supplémentaires à chaque appel, donc ajoutez le moins d'exemples qui rendent la sortie fiable. CMulti-shot n'aidera pas un problème de structure ; seulement augmenter la température change la forme de la sortie. DMulti-shot abaisse le coût de token par appel, car les exemples permettent au modèle de produire des réponses plus courtes. Scénario 3Considérez un pipeline qui doit traiter 50 000 documents pendant la nuit sans utilisateur en attente. Prédisez quelle forme de requête convient et pourquoi. AUne boucle synchrone convient mieux, car appeler l'API une fois par document est le modèle le plus simple et évite la surcharge de soumettre un lot. BLe streaming convient mieux, car envoyer la réponse en pièces permet au pipeline de commencer à traiter chaque document plus tôt. CLe modèle par lot convient : soumettez les requêtes dans un lot et interrogez la fin, acceptant une latence plus longue pour un coût inférieur par token. Une boucle synchrone atteindrait les limites de débit et bloquerait l'application, et le streaming n'achète rien car aucun utilisateur ne regarde. DUne context window plus grande convient mieux, car adapter tous les 50 000 documents dans une seule requête évite de faire des appels répétés. Scénario 4Considérez une longue session d'agent multi-tour dont la context window continue de se remplir. Prédisez les symptômes et nommez le budget en faute. ALe modèle supprime silencieusement les tours les plus anciens pour faire de la place, donc la session continue mais perd tranquillement le contexte précoce sans aucune erreur. BLa context window est un budget de token fixe ; à mesure que l'historique et les résultats d'outils s'accumulent, elle se remplit. Une entrée qui est déjà surdimensionnée est rejetée avec une erreur avant la génération, tandis qu'une requête qui s'adapte à l'entrée mais atteint le plafond pendant la génération revient avec une sortie tronquée et une raison d'arrêt model_context_window_exceeded. Le symptôme est une session qui a bien fonctionné en test échouant une fois que les entrées grandissent, c'est pourquoi l'application doit réduire ou résumer l'historique. CLe symptôme est un échantillonnage plus lent, et le budget en faute est le paramètre de température, qui doit être abaissé à mesure que la session grandit. DIl n'y a pas de budget fixe ; la fenêtre s'étend automatiquement pour contenir tout l'historique qui s'accumule, donc une longue session n'échoue jamais pour cette raison.

Soumettre Ignorer pour l'instant

Screen 8: Recap: five takeaways

RecapFive Takeaways·2 min Récapitulatif : cinq points clés

1 Les tokens sont l'unité d'entrée, de sortie et de coût. Pensez et budgétisez en tokens plutôt qu'en mots, car c'est l'unité dans laquelle l'API facture et que la context window mesure.

2 La context window est un budget de token fixe qui contient la requête entière à la fois. Une entrée surdimensionnée génère une erreur avant la génération, tandis que atteindre le plafond pendant la génération retourne une sortie tronquée avec une raison d'arrêt model_context_window_exceeded, donc gérer l'historique est le travail de l'application.

3 L'échantillonnage rend la génération non-déterministe. Le même prompt peut retourner un libellé différent à chaque exécution, donc tester sur un texte exact est peu fiable. C'est ce pour quoi les evals sont construits.

4 Le choix du modèle et le mode de raisonnement sont des leviers séparés et composables. Choisissez le plus petit modèle et le raisonnement et le prompting les plus simples qui répondent à votre eval et ajoutez la capacité seulement où l'eval dit que vous en avez besoin.

5 Un développeur accède à Claude via une API REST, généralement via un SDK. Choisissez entre synchrone, streaming, async/await, ou par lot selon qu'un utilisateur attend et si la charge de travail est en temps réel ou en masse hors ligne.

Ce qui vient ensuite : le Module 2 met ces fondations en œuvre dans la conception de prompts, les schémas d'outils, le streaming, l'ingénierie de context, et la construction d'agents.

Sources Claude 101 (Skilljar), Building with the Claude API (Skilljar), AI Fluency: Framework & Foundations (Skilljar), platform. claude. com/docs. Vérifiez les spécifications du produit au moment de la publication.

Vous pouvez maintenant parler le vocabulaire partagé du cours Developer. Les tokens, la context, l'échantillonnage, les niveaux de modèles, les modes de prompting, et la mécanique de transport de l'API ont maintenant des noms, donc le reste du cours peut s'appuyer directement dessus.

Screen 9: Congrats! You've successfully completed this module.

Module CompleteDeveloper Path·2 min Félicitations ! Vous avez terminé ce module avec succès. Vous pouvez maintenant expliquer les tokens, la context window, l'échantillonnage et la non-déterminisme, distinguer le choix du modèle du mode de raisonnement, choisir le bon mode de prompting pour le travail, et décrire comment un développeur accède à Claude via les SDK, REST, streaming, et les modèles async. Ces fondations sont le vocabulaire partagé sur lequel le reste du cours Developer s'appuie.

0 of ? checkpoints passed

M1

MSO Foundations Tokens, context, sampling, model tiers, prompting modes, and the technical substrate.

Vous êtes ici

M2

Production-Grade Prompting, Agents & Tool-use Prompting craft, extended thinking, tool schemas, streaming, context engineering, and agent construction.

Prochaine étape

M3

Claude Code, MCP & Integration Permission modes, durable project context, plugin packaging, and MCP integration without leaking credentials.

M4

Production Engineering, Evals, and Security Evals, tracing, failure handling, cost and orchestration budgets, and security boundaries that hold in production.

M5

Accelerators and IP Contribution Package accelerators, prepare verifiable contributions, choose deployment platforms, and mark trust boundaries.

Revoir le module Recommencer Commencer le Module 2 → Retour à l'accueil du cours

Module 1 terminé.