Plateforme Claude et conception de solutions

Écran 1 : Concevoir des solutions avec Claude va au-delà du simple choix d'un modèle.

ENSEIGNEMENT 2 MIN · INTRODUCTION AU MODULE Concevoir des solutions avec Claude va au-delà du simple choix d'un modèle.

Lors de la conception de solutions avec Claude, il y a quatre décisions clés à prendre avant de commencer à construire.

01 Quelle partie du travail Claude devrait-il posséder ?

Avant de façonner quoi que ce soit, vous devez décider ce que vous confiez à Claude, ce que vous laissez aux systèmes existants, et ce qui reste avec un humain.

02 Quelle est la forme du travail ?

Augmentez-vous un appel en direct, automatisez-vous un flux de travail, ou déployez-vous un agent qui agit de manière autonome ?

03 Pouvez-vous nommer l'architecture de référence à laquelle vous vous engagez ?

Choisir une architecture de référence à l'avance peut vous éviter des pivots coûteux plus tard.

04 Où votre travail interagit-il avec Claude ?

Sélectionner le bon point d'entrée, le bon modèle et la bonne stratégie de contexte maintiendra votre solution fonctionnelle et rentable.

Dans ce module, vous apprendrez à prendre ces décisions pour traduire un problème commercial ambigu en une solution proposée et défendre vos choix face à des alternatives crédibles.

À la fin de ce module, vous serez capable de : 1 Décomposer la demande d'un partenaire en ce que Claude fait, ce que les systèmes existants font et ce que les humains font, en utilisant les quatre propriétés de l'IA générative comme lentille de décision. 2 Choisir entre un appel augmenté, un flux de travail et un agent en nommant ce que chaque choix coûte. 3 Choisir un modèle d'architecture de référence pour la forme du problème devant vous et reconnaître quand la récupération fait un travail que l'état en direct devrait posséder. 4 Prendre des décisions défendables concernant le modèle, la fenêtre de contexte et la stratégie de contexte, et utiliser les évaluations comme porte avant tout changement de modèle. 5 Savoir où chaque point d'entrée de plateforme s'adapte (Claude. ai, l'API, un SDK, Claude Code, ou un serveur MCP) et quelle personnalisation appartient à chaque couche. 6 Distinguer entre les points d'entrée Claude qu'un utilisateur voit, les interfaces de temps de construction qu'un ingénieur code, et les routes de livraison qu'une entreprise se procure, ainsi qu'identifier lesquels sont exclus par les contraintes de gouvernance ou d'industrie réglementée avant tout autre compromis. POUR QUI EST CE MODULE

Ce module est destiné à l'Architecte qui transforme une demande ambiguë d'un partenaire en une solution que quelqu'un peut construire, financer et défendre. Vous êtes technique, décisif et conscient des compromis. Vous n'écrivez pas le code de production dans ce module, et il ne vous l'enseigne pas. Il enseigne les décisions qui se situent au-dessus du code : quel travail Claude devrait posséder, quelle forme ce travail prend, quelle architecture de référence s'adapte, et quels choix de modèle, de contexte et de point d'entrée maintiennent le système précis et abordable une fois qu'il est réel.

« Le travail » dans ce module

Tout ici est construit autour d'un engagement d'exemple : prendre un problème commercial d'un partenaire et arriver à une architecture proposée sur laquelle vous pouvez vous appuyer quand une alternative crédible est sur la table. Dans ce scénario, les partenaires sont des acheteurs d'entreprise dans des contextes à enjeux élevés, souvent réglementés, où un choix de conception qui semblait propre dans une démo devient un mauvais itinéraire découvert lors d'un audit trois mois plus tard. Ce scénario est présenté comme une série de décisions, chaque décision vous demandant quelque chose de différent.

Les décisions correspondent aux sections suivantes :

La décomposition est l'endroit où vous assignez chaque partie de la demande à Claude, à un système existant ou à un humain, en utilisant les quatre propriétés de l'IA générative comme lentille. Se tromper en sur-assignant à Claude est l'erreur précoce la plus courante et la plus coûteuse. La sélection de modèle est l'endroit où vous décidez si le travail est un appel augmenté, un flux de travail ou un agent. Chaque choix vous fournit et vous coûte quelque chose, nommer les coûts est l'objectif. Les architectures de référence sont l'endroit où un plan connu et bon s'adapte soit à la forme du problème, soit est mal appliqué. L'échec à surveiller est la récupération qui fait silencieusement un travail que l'état transactionnel en direct devrait posséder. Le modèle, le contexte et le point d'entrée sont l'endroit où vous choisissez un niveau de modèle, une stratégie de contexte et une route de livraison, et où les évaluations deviennent une porte d'étape avant tout changement de modèle. Vérifiez si les contraintes de gouvernance et d'industrie réglementée excluent une route avant de considérer tout compromis de coût ou de latence.

Plutôt que de mémoriser ces étapes, l'objectif dans ce module est de reconnaître quelle décision est devant vous, car chacune récompense un mouvement différent : la décision qui vous sert bien en décomposition est différente de celle où vous choisissez un point d'entrée. Dans la tâche cumulative à la fin de ce module, vous assemblerez une architecture complète à partir d'un nouveau brief.

CLAUSE DE NON-RESPONSABILITÉ / AVIS POUR CONTENU ÉDUCATIF

Nous avons construit ce cours Architecte Module 1 : Plateforme Claude et conception de solutions pour vous aider à faire 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 l'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 contrôlent.

Écran 2 : Les quatre propriétés autour desquelles les architectes conçoivent

Enseignement 12 min · Comment Claude se comporte

Les quatre propriétés autour desquelles les architectes conçoivent Avant de décider ce que Claude devrait faire dans une solution, vous devez avoir une compréhension claire de comment Claude se comporte. Quatre propriétés du modèle façonnent chaque décision de conception suivante. Aucune de ces propriétés n'est un défaut à corriger, chacune est une force autour de laquelle vous concevez – comme un ingénieur en structures conçoit autour des propriétés de ses matériaux de construction.

Considérez cet écran comme un travail préliminaire, vous ne vous demande pas de prendre des décisions de conception à ce stade. L'objectif est de reconnaître les quatre propriétés par leur nom et de comprendre les conséquences de conception de chaque propriété pour vous préparer à prendre des choix éclairés dans les exercices de jugement plus tard dans le module.

Les quatre propriétés et leurs conséquences de conception Pour chaque propriété ci-dessous, les mêmes caractéristiques qui rendent Claude capable dans une situation sont celles qui le font échouer dans une autre. Lisez chaque ligne comme une capacité associée à sa limitation correspondante, et l'atténuation qu'un architecte utilise.

Sélectionnez chaque propriété pour voir sa capacité associée, sa limitation et son atténuation.

Next Token Prediction Knowledge Working Memory Steerability

Capacité : Tâches construites sur des modèles courants : résumer, reformater et expliquer des concepts bien établis. Limitation : Tout ce qui nécessite de la précision sur les détails. Claude peut produire du texte qui semble exact mais ne l'est pas. Ce risque se concentre autour des noms, des dates, des citations et des statistiques. Atténuation : Utilisez des citations, la signalisation d'incertitude et des boucles générateur-vérificateur. Acheminez les recherches factuelles spécifiques via des appels d'outils ou des sources faisant autorité plutôt que de vous fier uniquement à la sortie du modèle.

Capacité : Sujets dans les données d'entraînement du modèle qui sont courants, récents et régulièrement inclus où le modèle peut répondre de manière fiable à partir de ce qu'il a appris. Limitation : Sujets qui sont rares, de niche, contestés ou qui changent fréquemment. Le modèle peut présenter des informations obsolètes ou incomplètes avec le même ton confiant qu'il utilise pour les faits établis. Atténuation : Utilisez la recherche Web, la récupération (RAG), l'utilisation d'outils ou les serveurs MCP pour faire d'un système externe la source de vérité au lieu du modèle. Au lieu de vérifier la connaissance paramétrique du modèle, la réponse faisant autorité provient de la source récupérée. Quand la fraîcheur ou l'autorité compte, réintroduisez les données vous-même plutôt que de vous fier à ce qui a été fourni dans les données d'entraînement du modèle.

Capacité : Tout ce qui rentre dans la fenêtre de contexte active. Limitation : La fenêtre de contexte est une limite dure : une fois que le contenu sort de la fenêtre, le modèle n'y a pas du tout accès. Deux erreurs différentes se produisent à la limite, mais elles peuvent être faciles à confondre. L'une est une demande surdimensionnée, c'est-à-dire un prompt ou une conversation qui est déjà trop grande pour être envoyée. Quand une demande surdimensionnée est envoyée, elle est rejetée avant la génération. Si la demande dépasse la limite de token du modèle, l'API retourne une erreur invalid_request_error 400 avec un message indiquant que le prompt est trop long. Si le corps de la demande brute dépasse la limite d'octets de l'API, l'API retourne une erreur request_too_large 413 avec un message indiquant que la demande dépasse le nombre maximum d'octets autorisés. L'autre erreur se produit quand un prompt rentre, mais sa génération heurte le plafond de la fenêtre et s'arrête tôt à la place ; sur les modèles actuels, la réponse revient avec une raison d'arrêt model_context_window_exceeded et une sortie tronquée. Pour éviter de heurter la limite, vous pouvez vérifier le champ usage sur chaque réponse et l'API de comptage de tokens avant d'envoyer. Atténuation : Utilisez le chargement progressif du contexte, le chunking et le chargement prioritaire des informations critiques. Pour le travail prolongé, les projets peuvent aider à gérer ce qui reste dans la portée. Prenez l'habitude de résumer entre les tours quand le contexte devient long.

Capacité : Instructions courtes, concrètes et vérifiables avec des formats définis, des limites de longueur explicites, des rôles clairs. Limitation : Instructions abstraites ou ambiguës, longues chaînes de raisonnement et tâches nécessitant une précision numérique ou logique exacte. Pour une précision numérique à enjeux élevés, le calcul déterministe ou l'exécution d'outils devrait posséder la réponse. Le modèle peut suivre la lettre d'une instruction tout en s'éloignant de l'intention. Atténuation : Utilisez les prompts système, les sorties structurées et l'exécution de code pour tout ce qui nécessite une précision logique. Quand l'intention et l'instruction littérale pourraient diverger, reformulez l'objectif explicitement aux côtés de l'instruction.

De la propriété à la conséquence de conception Nous revisiterons chacune de ces propriétés dans une partie ultérieure de ce cours. Mappez chaque propriété à sa conséquence de conception maintenant pour que la connexion soit en place avant que vous en ayez besoin :

Non-déterminisme. La même entrée peut produire des sorties différentes entre les exécutions. C'est pourquoi les cadres d'évaluation existent : vous ne pouvez pas certifier un comportement que vous n'avez observé qu'une fois. (Alimente le travail d'évaluation dans le Module 2. ) Le contexte comme ressource finie. La fenêtre de contexte est une limite dure avec un budget de token fixe. Ce que vous y mettez, dans quel ordre, et ce que vous laissez de côté sont des décisions de conception qui affectent à la fois ce avec quoi le modèle peut travailler et ce qu'il coûte de l'exécuter. (Alimente la stratégie de modèle et de contexte, plus tard dans ce module. ) La confiance n'est pas la validité. Claude peut produire une mauvaise réponse avec le même ton fluide et assuré qu'il utilise pour une bonne. C'est pourquoi le placement humain dans la boucle et la vérification sont des choix architecturaux, pas des réflexions après coup. (Alimente le travail de déploiement responsable dans le Module 3. ) Limites de connaissance et de capacité. Le modèle est fiable avec les sujets qui sont courants, récents et cohérents dans ses données d'entraînement, et peu fiable avec les sujets qui sont rares, privés ou qui changent rapidement. Pour les sujets peu fiables, la recherche Web, la récupération, les outils et MCP peuvent être utilisés pour faire d'un système externe la source de vérité au lieu du modèle. (Alimente les architectures de référence et RAG, plus tard dans ce module. )

Scénario : Un échec qui a commencé par une mauvaise lecture de propriété Un architecte a vu une démo s'exécuter proprement cinq fois de suite et a conclu que le comportement était déterministe. Sur cette base, l'équipe a expédié un pipeline de réconciliation financière qui traitait chaque sortie de modèle comme un résultat fixe et reproductible et n'a construit aucune vérification autour. Dans la deuxième semaine de production, les sorties ont dérivé : la même déclaration, retraitée, a produit une catégorisation différente. Cette discordance a été découverte par hasard uniquement quand un analyste a décidé de relancer un lot. Rien n'avait changé dans l'entrée, mais des sorties différentes ont été produites parce que le modèle est un système non-déterministe et l'architecture avait été construite comme s'il était déterministe. La leçon n'est pas que le modèle n'est pas fiable, c'est qu'une démo n'est pas une preuve de déterminisme et que les quatre propriétés sont présentes que votre architecture les reconnaisse ou non.

Coût · Complexité · Risque Coût : Concevoir sans considérer ces propriétés est l'erreur la plus coûteuse qu'un architecte puisse faire, car le coût arrive après le lancement, quand le rework est le plus coûteux et reconstruire la confiance est le plus difficile. Complexité : Nommer les quatre propriétés à l'avance garde les conversations de conception ultérieures précises. Vous pouvez reconnaître « c'est un problème de limite de connaissance » au lieu de débattre si le modèle est « assez bon ». Risque : Les propriétés ne s'annoncent pas. Un système qui ne conçoit pas autour de ces propriétés ne produira pas une erreur ; il dérive silencieusement et l'écart se traduit par des sorties variables qui peuvent être trouvées dans un audit ou par un utilisateur en colère, pas par le système lui-même.

Écran 3 : Points d'entrée, interfaces de temps de construction, routes de livraison

Enseignement 12 min · Carte de plateforme et primitives

Points d'entrée, interfaces de temps de construction, routes de livraison Tout au long de ce cours, vous choisirez comment un utilisateur atteint Claude, mais avant cela, vous avez besoin d'un ensemble cohérent de vocabulaire. Trois termes sont souvent utilisés de manière interchangeable, mais ils se situent à différentes couches de l'architecture. Cet écran enseigne chacun de ces termes. Choisir entre eux vient plus tard, une fois que le reste de la conception est en place.

Trois couches, trois décisions distinctes Ces trois couches ne sont pas des alternatives les unes aux autres. Chaque déploiement implique les trois et les confondre est la source la plus courante de conversations d'architecture confuses.

Points d'entrée Ce avec quoi une personne ou un système interagit directement. Les points d'entrée sont les wrappers qui décident qui peut parler à Claude et comment. Exemples : Claude. ai (web, mobile, bureau), Claude Code, une application personnalisée construite sur l'API.

Interfaces de temps de construction Comment un ingénieur programme contre Claude, la couche sur laquelle le code du partenaire est écrit. Exemples : L'API directe, les SDK, MCP, l'Agent SDK.

Routes de livraison Où le trafic API se termine. Les routes de livraison déterminent sur l'infrastructure de qui la demande s'exécute. Exemples : Anthropic directement, AWS Bedrock, GCP Vertex AI, Microsoft Foundry.

Pourquoi garder les couches distinctes compte Un point d'entrée est choisi pour l'utilisateur et le travail. Une interface de temps de construction est choisie pour l'équipe d'ingénierie et l'intégration. Une route de livraison est choisie pour les engagements cloud du partenaire et la posture de conformité. Ce sont trois conversations différentes avec trois parties prenantes différentes, et une décision dans une couche dicte rarement les autres. Pour l'instant, concentrez-vous sur l'apprentissage de leurs noms et de leur distinction. Sélectionner parmi eux sous des contraintes réelles sera enseigné plus tard, une fois que vous avez un modèle, un modèle et une architecture pour les adapter.

Un échec qui est venu de l'effondrement des couches Une proposition pour une solution de flux de travail de banque de détail a mis Claude Code, un point d'entrée d'ingénierie, devant un public non-ingénieur parce que, selon les paroles de l'auteur, « c'est tout Claude ». C'est tout Claude, dans le sens où le même modèle se trouve sous chaque point d'entrée. Mais le point d'entrée est le wrapper, et Claude Code a été construit pour les développeurs exécutant un terminal, pas pour le personnel de la succursale bancaire suivant un flux de travail. Traiter les trois couches comme une a effacé la distinction qui aurait dû éliminer le choix immédiatement.

Coût · Complexité · Risque Coût : Chaque point d'entrée porte son propre coût d'intégration. Choisir la mauvaise couche parce que le vocabulaire était peu clair peut mener à payer pour la mauvaise solution, puis à payer à nouveau pour la remplacer. Complexité : Quand les trois couches sont nommées et discutées précisément, un examen de conception peut isoler exactement quelle décision est contestée. Quand elles sont floues, l'examen argue en cercles. Risque : Un point d'entrée choisi avant que l'utilisateur soit nommé est une erreur d'architecture courante et évitable qui est souvent traçable à l'effondrement de ces trois couches distinctes en un seul concept.

Écran 4 : Placez chaque pièce dans sa couche

Point de contrôle 4 min · Carte de plateforme et primitives

Placez chaque pièce dans sa couche Cliquez sur une pièce de plateforme pour la sélectionner, puis cliquez sur le bon seau de couche pour la placer. Cliquez sur une pièce placée pour la retourner au pool. Les 8 éléments doivent être placés avant de soumettre.

claude. ai API directe Claude Desktop SDK Bedrock / Vertex / Foundry Claude Code MCP Agent SDK

Points d'entrée

Interfaces de temps de construction

Routes de livraison

Soumettre Passer pour l'instant

Écran 5 : Les pièces qu'un architecte assemble les solutions à partir de

Enseignement 16 min · Carte de plateforme et primitives

Les pièces qu'un architecte assemble les solutions à partir de Chaque modèle et architecture dans ce cours est un assemblage d'un petit ensemble de primitives. Nommez-les une fois, ici, pour que les leçons ultérieures deviennent des combinaisons de pièces que vous reconnaissez déjà. Cet écran nomme les sept primitives, leur travail et une déclaration d'une ligne pour vous enseigner à quoi chacune sert. Vous ne choisissez pas parmi eux pour l'instant ; vous apprenez à quoi chacun sert.

Sept primitives, sept travaux Lisez chaque primitive comme un seul travail. Plutôt que d'aller en profondeur sur une primitive, gardez une vue holistique de tous les sept pour l'instant. Une compétence clé en tant qu'architecte est de composer ces primitives pour développer une solution.

Cliquez sur chaque carte pour la retourner : le recto nomme la primitive et son travail d'un mot, le verso donne la définition d'une ligne.

ActOutilsFlip ↻ Ce qui permet au modèle de prendre une action ou de récupérer un résultat à partir de votre code, une fonction que le modèle peut appeler.

ConnecterMCPFlip ↻ Un protocole pour exposer un ensemble d'outils pour que plusieurs clients Claude puissent atteindre les mêmes points d'entrée.

Isoler / paralléliserSous-agentsFlip ↻ Confiez une sous-tâche délimitée à un contexte séparé pour que le travail s'exécute en isolation ou en parallèle.

GarantirHooksFlip ↻ Code déterministe qui s'exécute sur des événements définis pour appliquer une règle que le modèle ne peut pas ignorer.

Empaqueter une procédureCompétencesFlip ↻ Une unité versionnée et réutilisable (instructions plus scripts optionnels) qui empaquète une procédure répétable.

Coordonner les pairsÉquipes d'agentsFlip ↻ Plusieurs agents travaillant comme pairs coordonnés, chacun possédant une partie d'un objectif plus large.

Composer au runtimeFlux de travail dynamiquesFlip ↻ Assemblez les étapes d'un flux de travail au runtime plutôt que de les fixer à l'avance.

Les équipes d'agents (agents pairs coordonnés) et les flux de travail dynamiques (composition au runtime) étendent le vocabulaire plus ancien des agents uniques et des flux de travail fixes. Vous les verrez nommés dans les conversations actuelles des praticiens même si de nombreux systèmes existants les précèdent.

Pourquoi les inventorier maintenant Les modèles enseignés plus tard dans ce module, l'appel augmenté, le flux de travail, l'agent, ne sont pas des catégories abstraites. Chaque modèle est un assemblage particulier des sept primitives. Un flux de travail est des étapes câblées dans votre code, souvent en utilisant des outils. Un agent est le modèle choisissant sa propre séquence d'appels d'outils. Un système multi-agent est un orchestrateur déléguant à des sous-agents. Quand vous atteindrez ces leçons, vous composerez des primitives que vous avez déjà nommées, pas les rencontrer pour la première fois.

Scénario : Un échec qui est venu du vocabulaire partagé manquant Dans un examen d'architecture, quelqu'un a dit « nous utiliserons un agent ». Cinq personnes dans la salle ont entendu cinq choses différentes : l'une a entendu un modèle utilisant un seul outil, l'une a entendu un flux de travail multi-étapes, l'une a entendu une équipe de sous-agents, l'une a entendu Claude Code, et l'une a entendu un chatbot. La conversation de conception s'est arrêtée pendant vingt minutes avant que quelqu'un réalise qu'ils décrivaient des architectures différentes avec le même mot. En établissant une compréhension commune du vocabulaire primitif, l'équipe peut opérer avec clarté et efficacité.

Coût · Complexité · Risque Coût : Atteindre une primitive plus lourde que le travail ne l'exige est payée en latence, tokens et surface opérationnelle, à chaque demande. Par exemple, utiliser une équipe d'agents quand un seul appel d'outil suffirait. Complexité : Chaque primitive ajoutée à une conception est une pièce à construire, observer et gouverner. La discipline est d'utiliser le moins de primitives nécessaires pour répondre à l'exigence. Risque : Sans un vocabulaire partagé, les équipes ne peuvent pas communiquer efficacement parce qu'elles ne s'accordent pas sur ce que sont les pièces.

Écran 6 : Associez la primitive au travail

Point de contrôle 4 min · Carte de plateforme et primitives

Associez la primitive au travail Associez chaque élément à gauche à son correspondant à droite dans les trois ensembles. C'est le contrôle de préparation avant la moitié conception du module. Répondez aux trois ensembles, puis soumettez.

Ensemble 1 sur 3 : Propriétés de comportement à leurs conséquences de conception Associez chaque propriété à la conséquence de conception qu'elle crée. Non-déterminismeChoisir... Pourquoi les cadres d'évaluation existentPourquoi la récupération et les outils existentPourquoi la stratégie de contexte est une décision de conceptionPourquoi le placement humain dans la boucle compte Limite de connaissanceChoisir... Pourquoi les cadres d'évaluation existentPourquoi la récupération et les outils existentPourquoi la stratégie de contexte est une décision de conceptionPourquoi le placement humain dans la boucle compte Le contexte comme ressource finieChoisir... Pourquoi les cadres d'évaluation existentPourquoi la récupération et les outils existentPourquoi la stratégie de contexte est une décision de conceptionPourquoi le placement humain dans la boucle compte La confiance n'est pas la justesseChoisir... Pourquoi les cadres d'évaluation existentPourquoi la récupération et les outils existentPourquoi la stratégie de contexte est une décision de conceptionPourquoi le placement humain dans la boucle compte

Ensemble 2 sur 3 : Pièces de plateforme à leur couche Associez chaque pièce de plateforme à la couche dans laquelle elle se situe. Claude CodeChoisir... Point d'entréeInterface de temps de constructionRoute de livraison MCPChoisir... Point d'entréeInterface de temps de constructionRoute de livraison BedrockChoisir... Point d'entréeInterface de temps de constructionRoute de livraison

Ensemble 3 sur 3 : Primitives à leur travail Associez chaque primitive à son travail d'un mot. OutilsChoisir... AgirIsoler / paralléliserGarantirEmpaqueter une procédure Sous-agentsChoisir... AgirIsoler / paralléliserGarantirEmpaqueter une procédure HooksChoisir... AgirIsoler / paralléliserGarantirEmpaqueter une procédure CompétencesChoisir... AgirIsoler / paralléliserGarantirEmpaqueter une procédure

Soumettre Passer pour l'instant

Écran 7 : Où Claude s'adapte (Claude / systèmes / humains)

Enseignement 9 min · Décomposition

Où Claude s'adapte (Claude / systèmes / humains) Quand vous architecturez une solution pour un partenaire, vous prenez déjà trois sortes de décisions : ce que la demande est, quels systèmes vous avez disponibles pour l'adresser, et où le jugement humain doit être impliqué. Ce module ajoute une quatrième décision : déterminer où Claude peut aider. Cette quatrième décision est celle que les architectes se trompent parce qu'ils manquent de compréhension profonde des forces prédictibles et des modes de défaillance de Claude. L'objectif de ce module est de vous donner un cadre de décision concret pour déterminer où « Claude peut aider » avec spécificité.

Qui fait quoi ? Chaque solution a trois propriétaires : les assigner tôt vous met en place pour le succès Chaque solution que vous architecturez avec Claude atterrit dans l'un des trois seaux :

PropriétaireQu'est-ce qui appartient ici

Ce que Claude faitLe travail qui bénéficie de la compréhension du langage, de la résumé, de la planification, de la rédaction ou de l'action médiatisée par des outils. Ce que les systèmes existants fontTout ce que votre partenaire a déjà payé pour rendre fiable : le service de statut de commande, le moteur de politique, la table de règles, la base de données d'enregistrement. Ce que les humains fontLes appels de jugement, les chemins d'exception, les approbations, les moments où avoir raison compte plus que d'être rapide.

Les architectes confondent parfois les trois en « ce que Claude fait », mais sur-assigner des tâches à Claude rend presque toujours le processus plus coûteux, plus lent et plus difficile. La clé est de savoir ce que Claude fait mieux et ce dont il devrait être responsable dans votre solution.

Délégation : décider ce que Claude est de confiance pour posséder La décomposition produit une carte de délégation. Pour chaque partie de la demande, vous décidez non seulement si Claude peut le faire, mais si Claude devrait le posséder : travail approprié pour l'IA, travail retenu par l'humain, ou travail collaboratif où Claude rédige et une personne décide. Justifiez chaque assignation par :

Réversibilité : Un mauvais appel peut-il être annulé ? Enjeux : Qu'est-ce qu'un mauvais appel coûte ? Responsabilité : Qui doit répondre pour cela ?

Cet écran vous enseignera la discipline de la délégation, la première des quatre compétences de fluidité IA. Les quatre propriétés de comportement qui vous disent ce que Claude peut être de confiance pour faire ont été enseignées dans la section des fondations ; ici vous les appliquerez.

Scénario : Décomposer une demande de partenaire, assigner chaque étape au bon propriétaire Un partenaire demande un « assistant de triage des réclamations qui lit une réclamation, décide de la priorité, recherche la couverture de la politique et envoie un e-mail à l'expert-sinistre ». L'instinct initial d'un architecte pourrait être de mettre les quatre étapes dans le seau « Ce que Claude fait », mais la lentille des quatre propriétés arrête cela :

« Lire la réclamation. » C'est carrément dans la zone de capacité de Claude. Lire et interpréter une réclamation est un travail riche en modèles de langage, et si le schéma de sortie est limité, à la fois Next Token Prediction et Steerability travaillent en votre faveur. C'est un travail que Claude fait. « Décider de la priorité. » Cette étape peut sembler être une tâche de langage, mais ce n'est pas le cas. La priorité est une règle déterministe que votre partenaire définit et maintient déjà. Ce qui compte comme priorité dans l'organisation du partenaire vit dans un moteur de règles, pas dans les données d'entraînement de Claude. Acheminer cela à Claude introduit une limitation de connaissance inutile. Au lieu de cela, Claude appelle le moteur de règles et le système existant fait le travail de décider de la priorité. « Rechercher la couverture de la politique. » Cela heurte le même problème que la priorité, mais avec des enjeux plus élevés. Les politiques changent et les tables de couverture sont mises à jour, et le modèle n'a aucun moyen fiable de savoir quand la version qu'il a apprise pendant l'entraînement a cessé d'être actuelle. La réponse doit provenir du système qui détient les données de couverture en direct, récupérées via l'utilisation d'outils ou un serveur MCP. « Envoyer un e-mail à l'expert-sinistre. » Cette étape doit être divisée. Rédiger le message est un travail de langage et c'est quelque chose pour Claude. Envoyer le message appartient au système de messagerie. Un humain devrait examiner et approuver tout ce qui dépasse un seuil de valeur, parce que si Claude décide par lui-même, ses limitations de Working Memory et Steerability deviennent des risques.

La décomposition devrait être motivée par la réponse à la question « où les quatre propriétés plaident pour Claude plutôt que le système qui fait déjà cela correctement ? » plutôt que « Où Claude peut-il aider ? » Faites attention à ce changement de formulation, c'est le concept clé que ce module construit.

Coût · Complexité · Risque Coût : Chaque recherche qu'un simple système déterministe aurait pu gérer est envoyée à Claude à la place. Vous finissez par payer le modèle pour faire un travail qu'une requête de base de données ou une table de règles aurait pu faire pour une fraction du coût, et sur des milliers de demandes, cela peut s'accumuler rapidement. Complexité : Quand vous déplacez la logique hors d'un système piloté par table et dans le modèle, les erreurs cessent d'être traçables. Une règle déterministe échoue de manière prévisible et débogable. Un modèle gérant le même travail produit des sorties variables qui sont beaucoup plus difficiles à observer et diagnostiquer. Risque : Le modèle n'a aucun moyen fiable de savoir quand ses informations sont obsolètes, et il ne signalera pas l'écart. Quand le modèle devient la source de vérité au lieu du système réel du partenaire, les réponses faisant autorité peuvent dériver silencieusement, sans erreur levée et sans avertissement donné.

Écran 8 : Quand la vérification déterministe a silencieusement dérivé

Attention 4 min · Décomposition

Quand la vérification déterministe a silencieusement dérivé

Crochet de configuration Quand l'équipe est enthousiaste à propos de Claude, mettre une vérification déterministe à l'intérieur du modèle fournit une conception plus propre : un composant, moins d'intégrations, et plus facile à démontrer. C'est le type de mouvement qu'un architecte senior fait quand une équipe se déplace rapidement et la règle semble « assez facile » pour le modèle.

Un appel de portée, transcrit La conversation ci-dessous est un vrai échange de portée. Deux personnes font un appel raisonnable pour simplifier une conception, et au moment, cela semble être une victoire propre. Ce qu'ils ont réellement fait, c'est confier une règle commerciale déterministe, une qui doit être juste à chaque fois, à un modèle probabiliste, qui est juste la plupart du temps mais pas tout le temps. Cet écart n'a pas fait surface pendant le développement, au lieu de cela, il a fait surface trois mois plus tard, dans un audit. Cette section explore un mode de défaillance où l'objectif est de vous montrer ce qui s'est mal passé pour que vous puissiez reconnaître le modèle tôt et prendre une décision différente.

Partenaire : « Nous avons une règle que toute réclamation de plus de 5 000 £ a besoin d'un expert-sinistre senior. Aujourd'hui, nous faisons une vérification SQL contre la table des réclamations. Claude peut-il gérer cela à la place ? » Architecte : « Nous pouvons inviter Claude à extraire le montant et acheminer en conséquence s'il dépasse 5K. Cela le garde en une étape au lieu d'atteindre un système séparé pour vérifier, donc c'est beaucoup plus simple. » Partenaire : « Parfait, cela fonctionne pour moi. »

[Trois mois plus tard, en production]

Sur 14 000 réclamations traitées, 41 ont été acheminées incorrectement Tous les 41 partageaient le même problème. Le montant n'était pas écrit comme un nombre propre. Il était caché dans une phrase, comme « les dommages estimés à environ cinq mille livres ». Le modèle a traité « environ cinq mille » comme une estimation vague plutôt qu'un chiffre qui devrait déclencher un examen senior, donc ces réclamations ont été traitées de manière standard. La règle était précise. Les informations avec lesquelles elle devait travailler ne l'étaient pas, et le modèle a suivi la lettre de la règle au lieu de son intention.

Ce qui s'est cassé : une règle déterministe confiée à un système probabiliste Le seuil n'a pas changé, mais ce qui l'a appliqué l'a fait. Une règle déterministe qui doit être correcte à chaque fois a été pliée dans Claude, qui est juste la plupart du temps. L'écart entre eux est l'endroit où les 41 mauvais acheminements ont vécu. L'équipe n'a jamais construit un ensemble de cas de test pour vérifier l'acheminement, parce qu'elle avait traité l'acheminement comme quelque chose que le modèle gérerait simplement plutôt qu'une règle sur laquelle l'entreprise comptait. Cette différence est le cœur du problème. Une règle sur laquelle l'entreprise compte doit être testée, observée et possédée par un humain. Quelque chose que vous supposez que le modèle gérera est laissé seul jusqu'à ce qu'il se casse. Les mauvais acheminements ont été attrapés par un audit, pas par la surveillance du système. Le type de journalisation qui aurait attrapé une vérification SQL cassée n'enregistre pas les choix qu'un modèle fait à l'intérieur d'une seule demande, donc rien n'a signalé la dérive. L'échec est resté invisible jusqu'à ce que quelqu'un le cherche.

Pourquoi cela s'est cassé Une règle qui doit être juste à chaque fois a été confiée à un système qui est juste la plupart du temps. Ce compromis est facile à manquer pendant la portée parce que le modèle gère les cas propres correctement, et les cas propres sont ce que vous voyez dans les démos et les tests précoces. Le coût de « la plupart du temps » ne se révèle pas jusqu'à ce que vous fassiez un audit et à ce moment-là, le partenaire appelle.

Écran 9 : Triez les capacités du service sur le terrain

Point de contrôle 4 min · Décomposition

Triez les capacités du service sur le terrain Un partenaire de service sur le terrain vous a remis une liste de demandes pour un assistant de connaissances que ses ingénieurs utiliseront sur site. Cliquez sur une capacité pour la sélectionner, puis cliquez sur le bon seau propriétaire pour la placer. Les 8 éléments doivent être placés avant de soumettre.

Résumez les notes de cas de l'ingénieur en un résumé d'une page Retournez le niveau de stock actuel de la pièce SKU 78-A à l'entrepôt le plus proche Approuvez un remboursement de plus de 2 000 £ si l'ingénieur le demande Extrayez le numéro de pièce d'une photo de l'étiquette d'unité Calculez le temps facturable total sur trois tickets de travail Rédigez un e-mail de suivi au client expliquant le retard Dites à l'ingénieur si la garantie s'applique à ce numéro de série Décidez s'il faut escalader un incident de sécurité au gestionnaire de terrain

Claude

Systèmes existants

Humain

Soumettre Passer pour l'instant

Écran 10 : Décomposez la demande

Point de contrôle 4 min · Décomposition

Décomposez la demande Un brief de partenaire est ci-dessous. Pour chaque étape, sélectionnez le bon propriétaire : ce que Claude fait, ce que les systèmes existants font, ou ce que les humains font. Le point de contrôle précédent testait si vous pouviez reconnaître les quatre propriétés ; celui-ci teste si vous pouvez décomposer la division.

Le brief Un partenaire logistique régional veut un assistant qui, pour chaque exception d'expédition entrante : lit la note d'exception en texte libre du transporteur, décide si l'expédition se qualifie pour un remboursement automatique selon la politique publiée du partenaire, recherche le niveau de contrat du client, rédige une notification au client et émet le remboursement.

Lisez la note d'exception en texte libre du transporteur

Claude Système existant Humain

Décidez si l'expédition se qualifie pour un remboursement automatique selon la politique publiée du partenaire

Claude Système existant Humain

Recherchez le niveau de contrat du client

Claude Système existant Humain

Rédigez la notification au client

Claude Système existant Humain

Émettez le remboursement

Claude Système existant Humain

Soumettre Passer pour l'instant

Écran 11 : Composer les primitives en appel augmenté, flux de travail, agent

Enseignement 13 min · Sélection de modèle

Composer les primitives en appel augmenté, flux de travail, agent Une fois que vous avez établi quelles parties d'une tâche Claude possède par rapport à ce que vos systèmes et personnes possèdent, la décision suivante est structurelle : quelle forme la participation de Claude prend-elle ? Il y a trois modèles à choisir : un LLM augmenté, un flux de travail et un agent. Chacun prend une position différente sur deux axes : la prévisibilité (comment prévisible est le chemin à travers le travail) et l'autonomie du modèle (combien d'autonomie vous êtes prêt à confier au modèle).

Trois modèles pour structurer la participation de Claude

LLM augmenté Flux de travail Agent

Un seul appel de modèle : vous envoyez la demande, le modèle complète la tâche, et votre code gère le câblage autour. Vous pouvez ajouter l'utilisation d'outils, la récupération ou la réflexion étendue à cet appel, mais le modèle fait toujours un travail délimité en une passe. Le flux de contrôle ne se ramifie jamais en fonction de ce que le modèle décide. Utilisez ceci quand la tâche est bien définie, la sortie est quelque chose que vous pouvez vérifier, et il n'y a aucune raison de diviser le travail entre plusieurs étapes. Vous décomposez la tâche en étapes nommées et les orchestrez dans votre propre code. Chaque étape peut ou non appeler Claude. Parce que le flux de contrôle vit dans votre code plutôt qu'à l'intérieur du modèle, vous pouvez le journaliser, le tester et raisonner sur son comportement de la même manière que vous le feriez pour tout autre logiciel. Utilisez ceci quand le coût d'erreur est réel, l'observabilité compte, et les étapes peuvent être déterminées à l'avance. Vous donnez à Claude un objectif et un ensemble d'outils et le modèle détermine sa propre séquence d'étapes pour atteindre cet objectif. Le flux de contrôle vit à l'intérieur du modèle, pas dans votre code. C'est ce qui le rend un agent plutôt qu'un flux de travail : le chemin à travers le travail n'est pas écrit à l'avance nulle part où vous pouvez l'inspecter. Utilisez ceci uniquement quand le chemin à travers le travail ne peut pas être énuméré à l'avance, et uniquement quand le coût d'une sortie inattendue ou incohérente est acceptable et récupérable. En production, les agents sont généralement limités par des points d'entrée d'outils limités, des budgets par tour, des permissions explicites et des critères d'arrêt. Ces contraintes ne sont pas optionnelles ; elles empêchent un agent de devenir un passif.

Mapper les cas d'utilisation par prévisibilité et autonomie Tracez tout cas d'utilisation sur deux axes : comment prévisible est le chemin, et combien d'autonomie vous êtes prêt à accorder au modèle.

ÉLEVÉE BASSE PRÉVISIBILITÉ BASSE PRÉVISIBILITÉ ÉLEVÉE AUTONOMIE DU MODÈLE

AgentAutonomie élevée, prévisibilité basse. Le modèle possède la trajectoire. FluxTravailForme prévisible ; jugement de modèle limité à l'intérieur de chaque étape. LLM augmentéPrévisibilité élevée, autonomie basse. Un seul appel de modèle délimité.

Les LLM augmentés se situent dans le quadrant de prévisibilité élevée, autonomie basse. Vous connaissez la tâche, vous savez ce qui est bon et le modèle l'exécute une fois. Les flux de travail occupent la bande du milieu. La forme globale est prévisible, mais chaque étape peut impliquer un jugement de modèle de manière contenue. Les agents se situent dans le coin d'autonomie élevée, prévisibilité basse. C'est le modèle à atteindre quand énumérer les étapes à l'avance et c'est la partie coûteuse du problème : investigation ouverte, travail à long horizon et tâches où le prochain mouvement dépend de ce que le dernier a découvert. Claude Code est un exemple prouvé en production : il explore une base de code inconnue, décide quels fichiers lire en fonction de ce qu'il a déjà trouvé, et exécute un travail d'ingénierie multi-étapes que personne ne pourrait écrire à l'avance. C'est la capacité que les agents déverrouillent, mais le coût associé est tout aussi réel. C'est là que les défaillances non-déterministes se concentrent en production, parce que la trajectoire du modèle est le flux de contrôle et il n'y a pas de limite de code où une garde peut s'asseoir.

Sous-modèles dans les flux de travail Choisir un flux de travail ne spécifie pas complètement la conception. Il y a quatre formes qu'un flux de travail peut prendre, et chacune reflète une hypothèse différente sur la façon dont les étapes se rapportent les unes aux autres.

Sous-modèleForme Quand cela gagne sa placeExemples

Chaînage L'étape 2 prend la sortie de l'étape 1 comme entrée, travaillant séquentiellement et linéairement. Utilisez ceci quand la tâche se décompose naturellement en étapes avec des remises claires, comme extraire, puis classer, puis résumer. Chaque étape a une sortie définie que l'étape suivante consomme. Un pipeline d'examen de contrat : le premier appel extrait toutes les obligations et délais du document brut, le second classe chacun par niveau de risque, et le troisième rédige un mémo de résumé pour l'avocat. Chaque étape a une sortie propre que l'étape suivante consomme.

Acheminement Un classificateur, souvent Claude lui-même, décide quel chemin en aval prendre. Utilisez ceci quand les entrées varient en type et différents types nécessitent un traitement différent. Un ticket d'assistance entrant arrive : un classificateur le lit et achemine les questions de facturation vers un index de récupération sur les données de compte, les problèmes techniques vers un index de récupération sur la documentation produit, et les escalades directement vers une file d'attente humaine. Le même point d'entrée d'entrée, trois chemins de traitement différents.

Parallélisation Plusieurs appels de modèle s'exécutent simultanément ; les résultats sont agrégés ou votés. Utilisez ceci quand les sous-tâches sont indépendantes et peuvent s'exécuter en même temps. Examiner plusieurs fichiers ou examiner des sections distinctes d'un long document s'adapte à cette forme parce qu'aucune sous-tâche ne dépend de la sortie de l'autre. Un examen de diligence raisonnable sur douze contrats de fournisseur : chaque contrat est envoyé à un appel de modèle séparé simultanément. Les douze résultats sont retournés et agrégés dans un seul rapport de risque. Aucun appel ne dépend de la sortie d'un autre, donc il n'y a aucune raison de les exécuter séquentiellement.

Évaluateur-optimiseur Un appel de modèle produit une première tentative de sortie. Un deuxième appel l'évalue et demande une révision. La boucle se répète jusqu'à ce qu'un critère de qualité soit atteint ou qu'une limite de tentative soit atteinte. Utilisez ceci quand la qualité est vérifiable mais une seule tentative n'est pas assez fiable. La génération de code exécutée contre une suite de tests, ou l'extraction de sortie structurée avec un schéma strict, sont des applications courantes. Un modèle rédige une réponse à une plainte client. Un deuxième appel de modèle évalue le brouillon par rapport à une rubrique (nomme-t-il le problème spécifique, prend-il la responsabilité, offre-t-il des prochaines étapes concrètes dans le ton de la marque) et vérifie si la sortie correspond à la structure attendue. Si ce n'est pas le cas, l'évaluateur retourne des commentaires spécifiques et le générateur réécrit. La boucle se termine quand chaque élément de rubrique passe ou atteint une limite de tentative.

Ces quatre modèles ne s'excluent pas mutuellement. La plupart des flux de travail de production combinent plus d'un modèle, et le bon choix est généralement le plus simple qui répond aux exigences de tolérance d'erreur et d'observabilité de la tâche, et revisitez ce choix une fois que vous avez des données de production ; escaladez uniquement quand la mesure montre que le modèle plus simple ne suffit pas.

Un cadre pour choisir le bon modèle : cinq facteurs en séquence Parcourez ces cinq facteurs en séquence. Pour chacun, demandez-vous si le facteur exclut l'un des trois modèles – LLM augmenté, flux de travail, agent. Le premier facteur qui exclut un modèle est le facteur décisif. Le tableau ci-dessous montre ce que chaque modèle vous coûte sur chaque facteur, pour que vous puissiez voir exactement où les compromis atterrissent.

FacteurLa question à répondreLLM augmentéFlux de travailAgent

PrévisibilitéPouvez-vous énumérer les étapes à l'avance ? Basse : tâche délimitée unique. Basse : vous avez écrit le chemin. Élevée : la trajectoire est imprévisible par conception. Coût d'erreurQu'est-ce qu'une mauvaise réponse coûte : une tentative, un audit, un procès ? Moyen : vous expose à la distribution de sortie du modèle sans gardes au niveau des étapes. Bas : des gardes déterministes s'assoient entre les étapes. Élevé : vous expose à la distribution de sortie complète sur plusieurs tours. ObservabilitéVotre équipe d'opérations peut-elle voir ce qui s'est passé et reconstruire pourquoi ? Moyen : un seul appel est facile à journaliser mais opaque à l'intérieur. Bas : les étapes se journalisent comme le code le fait, avec des outils standard. Élevé : la trajectoire se lit comme une transcription ; la plupart des outils d'observabilité actuels ne sont pas construits pour alerter sur cela. Budget de latenceQuel est le délai visible par l'utilisateur ? Bas : le plus rapide dans les configurations standard, bien que la réflexion étendue ou la récupération ajoute du temps. Moyen : prévisible mais additif en durée. Élevé : le runtime est ouvert ; budgétez pour le pire cas, pas la médiane. CoûtQuel est le coût de token par demande à votre volume attendu ? Bas : le moins de tokens par demande. Moyen : s'adapte au nombre d'étapes. Élevé : le raisonnement itératif, l'utilisation d'outils multi-tours, les tentatives et le contexte croissant peuvent augmenter matériellement l'utilisation de tokens et la latence. Les agents mal limités sont souvent le modèle le plus coûteux.

Essayez d'inviter avant de considérer le fine-tuning Si l'invitation semble peu fiable, l'instinct de nombreux ingénieurs est d'atteindre le fine-tuning. Sur Claude, c'est généralement le mauvais premier mouvement. Travaillez d'abord à travers cette séquence :

Optimisez l'invitation. La plupart des problèmes de fiabilité sont des problèmes d'invitation. Ajoutez l'utilisation d'outils ou la récupération si l'invitation seule ne suffit pas. Passez à un modèle plus fort comme un évaluateur-optimiseur si la qualité n'est toujours pas où elle doit être. Seulement alors considérez le fine-tuning.

Le fine-tuning a une place, mais dans des situations spécifiques :

La tâche s'exécute à très haut volume et le coût d'inférence est la vraie contrainte. La latence est critique et un modèle spécialisé plus petit surpassera un modèle général invité. La sortie doit suivre un format cohérent et l'invitation ne l'a pas résolu de manière fiable.

En dehors de ces situations, le fine-tuning vous verrouille à une version de modèle fixe et rétrécit vos options sans grand-chose à montrer pour cela. Traitez-le comme la dernière étape d'une progression délibérée, pas comme un correctif rapide pour une invitation qui ne fonctionne pas encore.

Remarque sur la disponibilité Le fine-tuning de Claude n'est pas largement disponible. L'accès est limité, varie selon le modèle et la route de livraison, et change à mesure qu'Anthropic élargit le programme. Confirmez les options actuelles avec l'équipe de compte Anthropic avant de recommander ce chemin à un partenaire.

Ces trois modèles ne sont pas des catégories abstraites. Chacun est un assemblage des primitives que vous avez inventoriées dans la section des fondations : un appel augmenté est le modèle plus les outils ; un flux de travail est des primitives câblées ensemble dans votre propre code ; un agent est le modèle choisissant sa propre séquence d'appels d'outils. Choisir un modèle, c'est choisir comment composer ces pièces.

Architecture basée sur les compétences comme option d'emballage Aux côtés du choix d'un modèle, décidez comment la capacité est emballée. Trois options se situent sur un spectre : une solution d'invitation uniquement (instructions seules), l'utilisation directe d'outils (le modèle appelle des fonctions dans votre code) et une architecture basée sur les compétences (une compétence versionnée et réutilisable qui empaquette la procédure, ses instructions et tous les scripts comme une unité gouvernée). Atteindre une compétence quand la même procédure s'exécute à plusieurs reprises, doit être distribuée entre les équipes ou les produits, ou doit être versionnée et gouvernée. Appliquez la lentille de délégation au modèle lui-même : ce modèle accorde-t-il à Claude une autorité de décision appropriée ou excessive pour le profil de risque devant vous ? Un agent qui peut agir de manière autonome est le bon choix uniquement quand les enjeux et la réversibilité de ses actions justifient l'autonomie qui lui est donnée.

Coût · Complexité · Risque Coût : Les agents ne coûtent pas automatiquement plus que les flux de travail. Ce qui entraîne le coût est la quantité de contexte qui s'accumule au cours de la conversation et le nombre d'appels de modèle effectués. Un flux de travail mal conçu peut coûter plus qu'un agent bien conçu. La conception compte plus que l'étiquette de modèle. Complexité : Les flux de travail et les agents échouent de différentes manières. Un flux de travail échoue quand une étape dans votre code échoue. Un agent échoue quand le modèle prend une mauvaise décision quelque part dans une séquence de tours. Ce deuxième type d'échec est plus difficile à repérer et plus difficile à diagnostiquer, et vos outils de débogage standard ne le captureront pas de la même manière. Risque : L'autonomie d'un agent est votre surface de responsabilité. Un agent peut faire n'importe quoi que ses outils permettent, y compris des combinaisons que vous n'avez pas testées. Plus large est la permission d'outils, plus grand est l'espace de choses qui peuvent mal tourner. Gardez le point d'entrée d'outils aussi étroit que la tâche le permet.

Écran 12 : Quand l'équipe voulait de la flexibilité et a obtenu du non-déterminisme

Attention 4 min · Sélection de modèle

Quand l'équipe voulait de la flexibilité et a obtenu du non-déterminisme

Crochet de configuration : quand les équipes choisissent des agents et ne devraient pas C'est une erreur courante. Les agents sont souvent choisis parce qu'une tâche semble ouverte, pas parce que la tâche en exige vraiment un. Mais se sentir incertain sur la façon de structurer le travail est différent d'une tâche où les étapes ne peuvent vraiment pas être déterminées à l'avance. Si vous auriez pu écrire les étapes dans le code, vous auriez pu utiliser un flux de travail au lieu d'un agent et éviter de prendre la complexité inutile du flux de contrôle non-déterministe.

Les trois citations ci-dessous proviennent de la rétrospective de 90 jours d'une seule équipe. Chacune nomme une couche différente du même erreur sous-jacente.

« Nous avons choisi un agent parce que nous ne voulions pas le contraindre trop tôt. Au mois deux, nous avions ajouté tellement d'outils de garde-fou que nous avions essentiellement réécrit le flux de travail à l'intérieur de la boucle d'agent, moins la journalisation. » « La conformité est venue et a demandé quelle étape avait approuvé le débours. Nous avons pointé du doigt vers un tour de modèle. Ils ont demandé quelle version du modèle. Nous avons vérifié la trace. La version avait avancé de deux semaines plus tôt et personne n'avait revalidé. » « Les chemins réels à travers le système, quand nous avons exploré les traces, se sont divisés en seulement quatre formes. Quatre. Nous aurions pu écrire cela comme un routeur et quatre chaînes et nous aurions économisé six mois. »

Ce qui s'est cassé et pourquoi Chaque citation nomme un échec distinct, et ils se composent dans l'ordre. L'équipe a optimisé pour une flexibilité future inconnue au lieu de la forme présente connue. Quand l'équipe a exploré ses traces au mois trois, les chemins réels à travers le système se sont divisés en quatre formes, tous énumérables à partir de la semaine un. Le flux de travail dont ils avaient besoin était un routeur avec quatre chaînes. Ils ont construit un agent à la place et ont passé six mois à reconstruire cette structure à l'intérieur de la boucle. Le non-déterminisme est devenu un problème de conformité. Quand un auditeur a demandé quelle étape avait approuvé un débours, l'équipe ne pouvait que pointer vers un tour de modèle. Ce que le modèle d'agent a spécifiquement ajouté, c'est de ne pas avoir d'étape discrète et auditable à pointer. C'est ainsi que l'autonomie d'agent devient un risque de conformité : pas en fonctionnement normal, mais quand une partie externe a besoin d'une réponse déterministe et le système ne peut produire qu'une trajectoire. Une version de modèle non épinglée a composé l'écart. L'auditeur a ensuite demandé quelle version du modèle avait fonctionné. La trace a montré que la version avait avancé de deux semaines plus tôt sans porte de revalidation. C'est un écart de gouvernance de modèle et aurait été un problème sous n'importe quel modèle : une version non épinglée sans porte de revalidation ou un flux de travail expédié de la même manière aurait hérité de la même exposition. Un seul de ces deux échecs concerne le modèle d'agent lui-même.

Choisir un agent quand vous n'êtes pas sûr si c'est le bon modèle n'est pas un défaut sûr. Un agent est le bon choix uniquement quand les étapes à travers le travail ne peuvent vraiment pas être déterminées à l'avance. Si les étapes sont connues à l'avance, choisir un agent plutôt qu'un flux de travail signifie payer pour la flexibilité que vous n'utiliserez pas : tokens supplémentaires, latence et écarts d'audit qui font surface quand la conformité demande quelque chose que vos traces ne peuvent pas répondre. Les agents ne devraient pas être évités, mais ils devraient être adaptés à l'objectif. Si le travail avait été vraiment imprévisible, un agent aurait été le bon appel pour exactement cette raison. L'erreur de cette équipe était de sauter à un agent quand les quatre chemins à travers leur système étaient connaissables dès le départ. Un routeur et quatre chaînes auraient donné une structure propre et auditable. Au lieu de cela, ils ont passé six mois à reconstruire cette structure à la main à l'intérieur d'une boucle d'agent.

Écran 13 : Systèmes multi-agents et orchestration

Enseignement 9 min · Sélection de modèle

Systèmes multi-agents et orchestration La sélection de modèle vous a dit quand atteindre un agent. Certains problèmes sont trop grands ou trop variés pour qu'un seul agent les tienne dans un contexte. Quand cela se produit, la conception passe à plusieurs agents travaillant ensemble : un orchestrateur qui décompose le travail et des sous-agents qui en portent chacun une partie. Cet écran enseigne comment ces systèmes sont structurés, comment ils échouent et où un humain appartient dans la boucle.

Orchestrateur et sous-agents : rôles, délégation, synthèse Un système multi-agent a deux rôles.

L'orchestrateur Possède l'objectif : il décompose le travail, décide ce qu'il faut déléguer et synthétise les résultats en une seule réponse. L'orchestrateur ne fait jamais le travail de sous-tâche lui-même ; son travail est la délégation et la synthèse.

Les sous-agents Possèdent des sous-tâches délimitées : chacun s'exécute dans son propre contexte, fait une pièce et retourne un résultat.

Trois choses doivent être conçues, pas supposées : comment le travail est décomposé en sous-tâches, comment la sortie de chaque sous-agent est structurée pour que l'orchestrateur puisse la combiner, et comment l'orchestrateur résout les conflits ou les écarts quand les résultats reviennent.

Le modèle travaillé : fan-out sur un grand élément de travail La forme multi-agent la plus courante est un fan-out. Par exemple : un agent parent fait face à un élément de travail trop grand pour un contexte : une base de code de 400 fichiers à auditer, un corpus de 200 documents à résumer et un dépôt réglementaire à vérifier par rapport à cinquante règles. L'orchestrateur divise l'élément en unités indépendantes, envoie un sous-agent par unité (en parallèle où les unités ne dépendent pas les unes des autres) et synthétise ensuite les résultats retournés en un seul livrable. Ici, le gain est double : chaque sous-agent travaille dans un contexte propre dimensionné à son unité, et les unités indépendantes s'exécutent simultanément.

Récupération d'erreur : où un échec peut être attrapé et où il ne peut pas Dans un système multi-agent, la question architecturale à poser est « Où chaque mode de défaillance est-il récupérable ? ».

Un échec de sous-agent est généralement récupérable : si une unité échoue, l'orchestrateur peut la réessayer, l'acheminer ailleurs ou la laisser tomber et signaler l'écart, tandis que le reste du travail continue. Un échec d'orchestrateur est généralement non récupérable : si l'agent qui possède l'objectif et détient la synthèse perd son fil, toute la course échoue, et le travail de sous-agent partiel peut être échoué.

Concevez pour cette asymétrie, rendez le travail de sous-agent idempotent et réessayable, et protégez l'état de l'orchestrateur.

ÉchecOù cela atterritRéponse de conception

Un sous-agent retourne un résultat mal formé ou videGarante de sous-agent (récupérable)Validez chaque résultat ; réessayez ou réacheminchez l'unité échouée ; enregistrez l'écart plutôt que d'échouer la course. Deux sous-agents retournent des résultats conflictuelsÉtape de synthèse (récupérable)Donnez à l'orchestrateur une règle de résolution de conflit explicite, ou escaladez le conflit à un humain. L'orchestrateur perd l'objectif ou son état de synthèseOrchestrator (souvent non récupérable)Protégez l'état de l'orchestrateur ; pointez le progrès pour qu'une course échouée puisse reprendre plutôt que de redémarrer. Les traces se fragmentent entre l'orchestrateur et les sous-agentsObservabilité (transversale)Propagez un identifiant de trace partagé pour qu'une seule course soit reconstructible de bout en bout.

Modèles de points de contrôle humain dans la boucle pour les flux de travail d'agent Un système multi-agent peut prendre de nombreuses actions avant qu'un humain ne voit jamais la sortie, ce qui rend le placement du point de contrôle une décision de conception délibérée. Un point de contrôle humain dans la boucle est une porte qui met en pause l'exécution pour examen, positionnée par le risque et la réversibilité de l'action sur le point d'être prise. Placez une porte avant toute action irréversible ou à enjeux élevés qu'un sous-agent prendrait autrement de manière autonome ; échantillonnez les actions à enjeux plus bas plutôt que de gater chacune. Le traitement complet du routage par enjeux sera couvert dans une section ultérieure, ici le point est que la porte fait partie de la conception d'orchestration, pas boulonnée après coup.

Coût · Complexité · Risque Coût : Les systèmes multi-agents multiplient les dépenses de token, chaque sous-agent a son propre contexte, et l'orchestrateur paie pour synthétiser. Atteindre le modèle quand le travail dépasse vraiment un contexte, pas comme défaut. Complexité : Chaque agent ajouté est une autre limite de défaillance à observer et gouverner. La discipline est le moins d'agents qui répondent à l'exigence, avec une propriété claire de l'objectif. Risque : L'échec dangereux est celui silencieux : un sous-agent laisse tomber une unité et l'orchestrateur synthétise une réponse confiante et complète en apparence sur un travail incomplet. Validez la couverture, ne supposez pas.

Écran 14 : Quand le fan-out a caché une unité abandonnée

Attention 4 min · Sélection de modèle

Quand le fan-out a caché une unité abandonnée

La trace Une équipe de conformité a construit un système multi-agent pour vérifier un contrat de fournisseur de 50 sections par rapport à une liste de contrôle de politique interne. L'orchestrateur a étendu le travail à un sous-agent par section, chacun retournant un verdict de passage/drapeau, et a synthétisé un résumé propre : « 48 sections examinées, 3 signalées ». Le résumé se lisait comme complet et a été circulé au responsable juridique. Deux sections n'avaient jamais été examinées. Un sous-agent avait expiré et n'avait rien retourné ; un autre n'avait pas pu analyser une page numérisée et avait retourné un résultat vide. L'orchestrateur, sans vérification de couverture, a compté uniquement les résultats qu'il avait reçus et a signalé « 48 examinés », mais il y avait 50 sections, et personne n'avait dit à l'étape de synthèse de réconcilier le compte.

Ce qui s'est cassé et pourquoi

Pas de vérification de couverture à la synthèse. L'orchestrateur a synthétisé sur les résultats qu'il a reçus, sans règle que le nombre de résultats doit égaler le nombre d'unités envoyées. Un échec récupérable n'a jamais été récupéré. Un sous-agent expiré est le cas récupérable, mais uniquement si quelque chose le réessaye ou signale l'écart. Ici, l'échec était silencieux parce que rien ne regardait la limite. Synthèse confiante sur un travail incomplet. La fluidité de la sortie a masqué l'écart. Un système multi-agent échoue le plus dangereusement quand le résumé semble complet et ne l'est pas.

Pourquoi cela s'est cassé L'exhaustivité a été supposée, pas vérifiée. L'orchestrateur a envoyé 50 unités et a signalé sur les résultats qu'il a reçus. Deux unités n'ont jamais revenu, et rien dans la conception n'a remarqué la différence. Trois écarts se sont alignés pour laisser passer cela.

Le compte n'a jamais été réconcilié. L'étape de synthèse a additionné les verdicts qu'elle a reçus et s'est arrêtée là. Aucune règle ne disait que le nombre de résultats devait correspondre au nombre d'unités envoyées, donc 48 résultats retournés sont devenus « 48 examinés » au lieu de « deux manquent ». Un échec récupérable n'avait rien le regardant. Un sous-agent expiré et un résultat d'analyse vide sont tous deux le cas récupérable, mais uniquement quand quelque chose réessaye l'unité ou signale l'écart. Aucun composant ne possédait la limite de sous-agent, donc les deux échecs ont passé silencieusement. La sortie se lisait comme complète. Le résumé était fluide et bien formé, ce qui est exactement ce qui a rendu l'écart invisible. Un système multi-agent échoue le plus dangereusement quand un résumé confiant est construit sur un travail qui n'a jamais été terminé. Le correctif est une vérification de couverture à la synthèse : les résultats retournés doivent égaler les unités envoyées, ou la course signale la différence avant que quelqu'un ne lise le résumé.

Écran 15 : Critiquez la conception d'orchestration

Point de contrôle 5 min · Sélection de modèle

Critiquez la conception d'orchestration

Architecture de brouillon soumise pour examen Ci-dessous se trouve une architecture multi-agent de brouillon soumise pour examen : un orchestrateur éventant un grand travail de classification de documents à des sous-agents. Six composants sont énumérés. Sélectionnez les trois qui portent un défaut de contrôle ou de limite de défaillance.

Sélectionnez exactement 3 composants qui portent un défaut de contrôle ou de limite de défaillance.

1L'orchestrateur décompose le corpus en unités par document

↓

2Les sous-agents s'exécutent en parallèle, chacun retourne un verdict

↓

3La synthèse additionne les verdicts retournés dans un rapport

↓

4Action irréversible (auto-archive) prise sans porte humaine

5Pas de tentative ou de signalisation d'écart sur un sous-agent échoué 6L'ID de trace partagé propagé à chaque sous-agent

Soumettre Passer pour l'instant

Écran 16 : Les formes que l'industrie a déjà payé pour apprendre

Enseignement 15 min · Architectures de référence

Les formes que l'industrie a déjà payé pour apprendre Choisir un modèle vous donne la bonne structure. Les modèles vous donnent la forme. La question suivante à poser est comment cette structure se connecte à tout ce qui l'entoure. Les architectures de référence vous donneront le câblage.

Architectures de référence : ce qui est bon et où les projets se trompent Les architectures de référence sont des références, pas des plans à adhérer. L'objectif n'est pas de faire correspondre un problème à une conception fixe et de l'implémenter comme dessiné. Chaque charge de travail de partenaire est unique, donc votre objectif ici est de comprendre ces modèles courants assez bien pour généraliser à partir d'eux. En fin de compte, vous devriez être capable de prendre la forme qui s'adapte, de l'adapter à la charge de travail devant vous et de reconnaître quand une charge de travail s'appuie sur plus d'un modèle à la fois. La plupart des problèmes de partenaire correspondent à l'une des quelques architectures de référence déjà prouvées dans l'écosystème Claude : des modèles documentés pour la façon de câbler une application LLM ensemble pour résoudre une classe récurrente de problème. Le tableau ci-dessous couvre les architectures de référence courantes, ce qu'elles ressemblent quand elles sont bien construites et les modes de défaillance qui apparaissent à plusieurs reprises.

Développez chaque modèle pour voir ce qui est bon et où les projets se trompent.

Agent (voir S11)Ce qui est bon : Le modèle travaille vers un objectif en décidant quels outils appeler et dans quel ordre. L'autonomie est maintenue en contrôle en limitant ce que les outils peuvent faire et en fixant un budget sur le nombre de tours que le modèle obtient. Utilisez ceci quand le chemin à travers le travail ne peut pas être écrit à l'avance : enquêter sur une base de code, tirer de plusieurs sources de recherche ou trier des cas clients complexes. Où les projets se trompent : Autonomie sans limite : donner au modèle des outils qui changent l'état sans examen humain, sans limite de tour et sans moyen de mesurer si l'objectif a été atteint. Génération augmentée par récupération (RAG) (voir S11)Ce qui est bon : Un corpus de connaissances stable, comme des manuels de produit, des documents internes ou du texte réglementaire, est chunké et indexé. Quand une question arrive, les chunks les plus pertinents sont récupérés et passés au modèle comme contexte. Où les projets se trompent : Utiliser RAG pour répondre à des questions sur l'état en direct : statut de commande, niveaux d'inventaire, files d'attente de tickets. L'index est un instantané. Si les données sous-jacentes ont changé depuis le dernier rafraîchissement, la réponse sera fausse. Pipeline de traitement de documents → Évaluateur-optimiseur (voir S11)Ce qui est bon : Extraction structurée à partir de documents semi-structurés comme les réclamations, les factures et les contrats. Le pipeline gère l'OCR, extrait les champs par rapport à un schéma, valide la sortie et achemine les exceptions. Un évaluateur-optimiseur est courant ici parce que l'extraction au premier passage sur les cas limites n'est pas assez fiable pour faire confiance sans vérification. Où les projets se trompent : Pas de chemin d'exception. Les extractions à faible confiance passent par le même pipeline que les documents propres, sans porte humaine pour attraper ceux que le modèle a mal compris. Service client / triage de tickets → Acheminement (voir S11)Ce qui est bon : Classer l'intention et ce que l'utilisateur demande, puis acheminer vers le bon backend : une couche de récupération de connaissances pour les questions de documentation, une API transactionnelle pour les requêtes d'état en direct comme le statut de commande ou les changements de compte, et une couche d'approbation humaine pour les actions à conséquences élevées. Où les projets se trompent : Utiliser la récupération pour le statut de commande en direct au lieu d'appeler l'API directement. Pas de chemin d'escalade vers un humain. Déployer une variante d'agent avant que le flux de travail routé plus simple n'ait été correctement mesuré. Agent de codage (exploration agentic avec étapes déterministes d'édition/test/examen) (voir S11)Ce qui est bon : Le travail se divise en deux phases. Premièrement, l'agent enquête sur la base de code pour comprendre ce qui doit changer : cette partie est agentic parce que le chemin à travers une base de code inconnue ne peut pas être écrit à l'avance. Deuxièmement, les éditions réelles suivent des étapes déterministes : analyser, planifier, proposer, tester, examiner. Les sous-agents gèrent les tâches isolées avec assez de contexte pour faire le travail mais pas tellement que les étapes deviennent ingérables. Où les projets se trompent : Laisser l'agent éditer et valider sans porte d'examen humain. Ne pas suivre les taux de régression par rapport à un ensemble d'éval pour chaque langue ou framework dans la base de code. Traiter le tout comme une conversation plutôt qu'un pipeline structuré avec des remises définies.

La profondeur complète de l'implémentation RAG, y compris les stratégies de chunking, les approches d'intégration, la récupération hybride lexicale-plus-sémantique et la fusion de rang réciproque, est couverte dans l'écran de conception de pipeline RAG qui suit.

Comment décider si un problème a besoin d'un ou plusieurs modèles Les problèmes de partenaire réels se situent fréquemment à la limite entre deux architectures. Un flux de travail de routage pourrait confier certaines intentions à une boucle d'investigation agentic. Un pipeline de traitement de documents pourrait utiliser RAG sur le texte de politique quand il heurte un cas d'exception. Tirer parti de plus d'un modèle est parfois la bonne réponse. Ce qui compte, c'est pourquoi vous atteindrez un deuxième modèle. Ne pensez pas aux modèles comme des pièces que vous clipsez ensemble. Regardez pourquoi chacun fonctionne et façonnez l'idée pour adapter votre problème. Tirez parti d'un deuxième modèle quand les deux parties de votre problème se cassent différemment d'une manière qui vaut la peine de gérer séparément. Si vous atteindrez un deuxième modèle parce que vous n'avez pas décidé quel problème vous résolvez, adaptez un seul modèle à la place. C'est une décision de conception que vous reportez, pas un modèle que vous appliquez.

L'erreur la plus courante : récupération appliquée à l'état en direct L'erreur d'architecture de référence la plus courante est d'utiliser la récupération où un appel d'outil appartient. Vous pouvez la reconnaître en cherchant ces symptômes : chunks obsolètes, résultats qui changent à chaque rafraîchissement d'index, réponses qui contredisent ce qui est dans la base de données. Un meilleur modèle d'intégration ou un intervalle de rafraîchissement plus court ne résoudra pas ce problème. Au lieu de cela, appelez le système qui possède l'état en direct directement plutôt que de récupérer une version en cache.

Coût · Complexité · Risque Coût : Composer deux architectures de référence double à peu près la surface que vous devez maintenir. En cas de doute, choisissez-en une. Complexité : Chaque architecture de référence porte son propre contrat d'éval. Vous avez besoin d'ensembles d'éval séparés par architecture, pas un seul ensemble d'éval pour le système composé. Un système qui semble sain au niveau supérieur peut masquer des défaillances dans l'un de ses composants. Risque : L'application erronée de la récupération à l'état en direct produit des réponses obsolètes mais confiantes. Le système semble sain de l'extérieur : latence normale, pas d'erreurs. Le coût de détection est élevé parce qu'il n'y a pas de signal que quelque chose ne va pas jusqu'à ce qu'un utilisateur remarque que la réponse ne correspond pas à la réalité.

Écran 17 : Quand la récupération a été atteinte au lieu d'un appel d'outil

Attention 4 min · Architectures de référence

Quand la récupération a été atteinte au lieu d'un appel d'outil

Crochet de configuration : comment RAG échoue quand appliqué à l'état en direct La compétence plus large sous-jacente ici est l'ingénierie du contexte : décider quel mécanisme est responsable de mettre chaque type de données devant le modèle. La récupération sur un index vectoriel est un exemple, et cette trace montre ce qui se passe quand on lui demande de posséder des données qu'elle ne peut pas posséder. Cela se produit souvent quand une équipe atteint RAG parce qu'elle a fonctionné sur un cas d'utilisation précédent, sans s'arrêter pour demander si le nouveau partage les mêmes propriétés. RAG fonctionne bien quand la réponse vit dans un corps de matériel de référence qui reste stable entre les rafraîchissements d'index, par exemple, la documentation, le texte de politique, les manuels de produit. Il se casse pour l'état en direct parce que la récupération traite vos données comme des instantanés de texte, pas comme un système avec des valeurs actuelles. Quand ces instantanés ne s'accordent pas, le modèle choisit le plus similaire et répond avec confiance. Il n'y a aucun moyen de savoir quel instantané est actuel. La trace ci-dessous montre exactement comment cela se joue.

La trace : assistant de service client de détaillant d'électronique L'utilisateur demande : « Où est ma commande ? »

CHUNK RÉCUPÉRÉ #1 (similarité 0,78) : « La commande #88412 a été placée le 11 juin et expédiée le 12 via courrier standard. Numéro de suivi AB123… » CHUNK RÉCUPÉRÉ #2 (similarité 0,74) : « La commande #88412 est actuellement en cours de traitement. Expédition attendue dans les 24 heures. »

SORTIE DU MODÈLE : « Votre commande a été expédiée le 12 juin via courrier standard. Suivi : AB123… »

Les deux chunks étaient des chaînes réelles qui existaient dans le corpus à différents moments. L'index les a confondus. La commande avait été expédiée, retournée au dépôt en raison d'une étiquette endommagée et attendait une réexpédition. Notez que cet état actuel n'apparaît dans aucun chunk : le corpus contenait deux instantanés obsolètes et aucun enregistrement de l'endroit où se trouvait la commande, parce qu'un index capture ce qui était vrai quand il a été écrit, pas au présent. Un outil de service client pour récupérer le statut de commande en direct existait dans l'API du partenaire. Il n'a pas été appelé.

Ce qui s'est cassé et pourquoi L'erreur de catégorieRécupération est le bon mécanisme pour la connaissance : FAQ, politiques, manuels. C'est le mauvais mécanisme pour l'état transactionnel. Le statut de commande n'échouait pas parce que la récupération est cassée. Il échouait parce que l'état actuel avait été représenté comme des instantanés de texte historique en premier lieu. Un échec d'architecture de données, pas un échec de récupérationL'état en direct a été indexé comme du texte, donc le système a cherché un corpus d'instantanés passés plutôt que d'interroger le système d'enregistrement. La similarité n'est pas la vérité L'intégration de similarité a fusionné deux instantanés obsolètes en une seule réponse. Un score de similarité plus élevé ne signifie pas une réponse plus vraie ; cela signifie que le texte récupéré était sémantiquement proche de la requête, ce qui n'est pas la même chose quand l'état sous-jacent a changé depuis que le texte a été écrit. Le correctif est un appel d'outilPas un meilleur chunker, un intervalle de rafraîchissement plus court ou un seuil de similarité plus élevé : un appel d'outil au service de statut de commande. La base de connaissances garde le contenu FAQ. La base de données transactionnelle garde les commandes. Deux types de données, deux modèles d'accès, deux mécanismes.

Le principe de récupération La récupération est pour la connaissance stable : les choses qui étaient vraies hier et seront vraies demain. L'utilisation d'outils est pour l'état en direct : les choses dont la valeur actuelle est possédée par un système et change indépendamment de votre index. Les confondre produit des réponses qui sont fluides, confiantes et fausses d'une manière difficile à détecter parce que le système ne montre pas de signal d'erreur. Le modèle a retourné une réponse. La réponse semblait correcte. Le client a reçu des informations fausses sur sa propre commande.

Écran 18 : Critiquez le diagramme

Point de contrôle 6 min · Architectures de référence

Critiquez le diagramme Pratique : examinez une architecture de brouillon de partenaireCI-dessous se trouve un croquis d'architecture de référence d'un assistant de service client. Six composants sont énumérés. Sélectionnez les trois qui sont mal appliqués pour cette conception de routage. Sélectionnez exactement 3 composants qui sont mal appliqués.

1Classificateur d'intention (appel Claude)

↓↓

2Récupération sur « Index de statut de commande » 3Récupération sur « Corpus de manuel de produit »

↓↓

4Boucle d'agent avec point d'entrée d'outil : remboursement, annulation, adresse de mise à jour 5(manquant) Chemin d'escalade vers agent humain

↓↓

6Compositeur de réponse (appel Claude)

Soumettre Passer pour l'instant

Écran 19 : Chunking et indexation

Enseignement 10 min · Conception de pipeline RAG

Chunking et indexation L'écran précédent sur les architectures de référence a nommé RAG comme une forme connue et bonne et a montré où elle est mal appliquée. Cet écran va un niveau plus profond, dans la conception du pipeline de récupération lui-même : comment un corpus est divisé en chunks, comment ces chunks sont indexés et comment la stratégie de récupération est adaptée aux modèles de requête que le système verra.

Chunking : comment vous divisez le corpus, par ce que le corpus est Un chunk est l'unité qui est récupérée. L'approche de chunking est choisie par la structure du matériel source, pas par une taille par défaut.

Approche de chunkingComment cela fonctionne Quand cela gagne sa place

Taille fixeSe diviser en spans uniformes (avec chevauchement) indépendamment de la structure. Texte homogène et non structuré où les limites naturelles sont faibles ; le plus simple à exploiter. SémantiqueSe diviser sur les limites de sens, les changements de sujet, les groupes de phrases qui vont ensemble. Prose où un chunk récupéré doit être autonome pour répondre bien ; réduit les coupures à mi-idée. HiérarchiquePréserver la structure du document, les sections, les sous-sections et récupérer au niveau qui s'adapte. Documents structurés (contrats, manuels, politiques) où le contexte de section porte du sens.

Indexation : comment vous rendez les chunks trouvables, par comment les requêtes sont formulées L'indexation décide ce que « similaire » signifie quand une requête arrive. La stratégie est choisie par le modèle de requête.

Stratégie d'indexationCe qu'elle correspond Quand cela gagne sa place

Dense (intégrations)Similarité sémantique, sens, pas des mots. Requêtes formulées différemment de la source ; paraphrase, intention, correspondance de concept. Sparse (mot-clé, par exemple BM25)Termes exacts, identifiants, codes, noms. Requêtes qui dépendent de tokens spécifiques : numéros de pièce, citations de statut, codes d'erreur. HybrideLes deux, avec les résultats combinés. Modèles de requête mixtes, le cas de production courant ; récupère les résultats de correspondance exacte que la récupération dense manque.

Quand un index hybride retourne deux listes classées, elles doivent être fusionnées en une. La fusion de rang réciproque est la façon standard et faible en tuning de le faire : chaque résultat est noté par son rang dans chaque liste, et le score combiné favorise les éléments qui se classent bien dans les deux. Le point pour un architecte est que combiner les résultats denses et sparse est une décision de conception avec un défaut connu et défendable.

Articuler le compromis Chaque conception de récupération fait des compromis entre trois choses :

Qualité de récupération : Le bon chunk revient-il ? Latence : Combien de temps la récupération ajoute-t-elle à chaque demande ? Maintenance : Combien coûte le pipeline à garder correct à mesure que le corpus grandit et change ?

Les chunks plus petits et l'indexation hybride ont tendance à augmenter la qualité et la latence ensemble ; les chunks plus grands et l'indexation dense uniquement réduisent la latence et la maintenance mais manquent les requêtes de correspondance exacte. Il n'y a pas de point universellement correct, seulement le point qui s'adapte à ce corpus et à ces requêtes, énoncé comme un compromis que vous pouvez défendre.

Coût · Complexité · Risque Coût : L'indexation hybride et les chunks plus petits augmentent le calcul de récupération et la latence par demande. Dimensionnez le pipeline aux modèles de requête que vous avez réellement, pas à celui le plus complet imaginable. Complexité : Chaque choix de chunking et d'indexation est quelque chose à maintenir à mesure que le corpus change. Un pipeline qui était correct au lancement peut se dégrader silencieusement à mesure que les documents sont ajoutés. Risque : Le mode de défaillance est une réponse confiante construite sur le mauvais chunk. La qualité de récupération n'est pas visible dans la sortie, elle doit être mesurée par rapport à un ensemble étiqueté, c'est pourquoi ce travail se lie directement à l'évaluation.

Écran 20 : Concevez le pipeline RAG

Exercice 8 min · Conception de pipeline RAG

Concevez le pipeline RAG Le briefUn partenaire de services professionnels a un corpus d'environ 4 000 documents : contrats d'engagement client (hautement structurés, numérotés par section), des rapports de projet passés (prose longue) et un manuel de méthodologie (structuré, avec des procédures définies). Leur équipe pose trois sortes de questions : « que dit notre méthodologie sur X ? » (recherche de concept), « trouvez la clause sur la résiliation dans le contrat Acme » (recherche de cible exacte) et « résumez comment nous avons géré des engagements comme celui-ci » (synthèse large sur les rapports). Rédigez votre conception de pipeline. Pour chacun des trois types de documents, nommez l'approche de chunking que vous utiliseriez et expliquez pourquoi. Ensuite, nommez la stratégie d'indexation pour le corpus complet et énoncez le compromis que vous faites. Écrivez votre réponse avant de cliquer pour révéler la réponse du modèle. Sentez-vous libre de demander à Claude de comparer ce que vous avez écrit avec la réponse fournie.

Votre conception de pipeline

Révélez la réponse du modèle Passer pour l'instant

Contrats et manuel de méthodologie : Chunking hiérarchique qui préserve la structure de section et de sous-section. Les deux sources sont structurées et numérotées par section, donc récupérer au niveau de la section garde la clause ou la procédure intacte et autonome. Le chunking de taille fixe coupe les limites de section et perd le contexte structurel sur lequel la requête dépend. Rapports de projet : Chunking sémantique sur les limites de sens pour que chaque chunk récupéré soit autonome. La prose longue n'a pas de numéros de section pour ancrer le chunking hiérarchique, et les chunks de taille fixe coupent à mi-idée. Le chunking sémantique garde chaque passage récupéré assez cohérent pour répondre à la question par lui-même. Stratégie d'indexation : Hybride dense-plus-sparse. L'ensemble de requêtes mélange les recherches de clause exacte (« trouvez la clause de résiliation dans le contrat Acme ») avec les questions conceptuelles ouvertes (« comment avons-nous approché X ? »). Sparse gère les recherches de cible exacte où les identifiants spécifiques comptent ; dense gère la recherche de concept et les requêtes de synthèse où le sens, pas les termes exacts, entraîne la correspondance. Ni l'un ni l'autre seul ne couvre les deux modèles. Le compromis dominant : la variété de requêtes est la contrainte de charge. L'index hybride ajoute le calcul de récupération et une étape de fusion de rang, mais ces coûts gagnent leur place parce que l'ensemble de requêtes a vraiment besoin des deux modes.

Comment votre conception s'est-elle comparée ?

Correct : ma conception correspondait Partiel : proche, mais décalé sur une pièce Incorrect : j'ai manqué la structure

Écran 21 : Modèle, fenêtre de contexte et stratégie de contexte

Enseignement 13 min · Stratégie de modèle et de contexte

Modèle, fenêtre de contexte et stratégie de contexte À ce stade, vous devriez avoir un modèle et une architecture de référence, mais pas un système expédiable. Trois décisions restent, et chacune détermine ce que la même architecture coûte à l'échelle : 1. Quel modèle s'adapte à la tâche, 2. Combien de la fenêtre de contexte utiliser réellement, et 3. Si votre stratégie de contexte devrait être progressive ou monolithique. Ces décisions se composent sur chaque demande à volume de production.

Termes distincts qui sont faciles à confondre Les termes suivants sont souvent utilisés de manière interchangeable dans la pratique mais les confondre produit des erreurs d'architecture de référence. Prenez le temps d'examiner attentivement chaque terme en détail :

Fenêtre de contexte. L'espace d'attention actif du modèle. Tout à l'intérieur de la fenêtre de contexte est disponible pour le raisonnement et tout en dehors ne l'est pas du tout. La fenêtre de contexte se réinitialise entre les appels à moins que votre application ne gère explicitement la continuité. Récupération. Connaissance externe récupérée, tirée au moment de la requête d'un corpus que le modèle ne détient pas en mémoire. La récupération augmente la fenêtre de contexte ; elle ne la remplace pas. Le modèle ne voit que ce que le récupérateur fait surface. État d'application persistant. Possédé et géré par votre système, pas le modèle. Statut de commande, enregistrements d'utilisateur, soldes de compte. Le modèle n'a pas d'accès inhérent et nécessite un appel d'outil pour l'obtenir. Résumés et couches de mémoire. Continuité gérée par l'application entre les tours ou les sessions. Le modèle n'a pas de mémoire native entre les appels, donc tout ce qui persiste le fait parce que votre application l'a stocké et l'a repassé. C'est un choix architectural, pas une capacité de modèle.

Sélection de modèle : commencez par Sonnet, avancez délibérément La famille de modèles Claude se compose actuellement d'Opus, Sonnet et Haiku, chacun optimisé pour différents compromis de coût, latence et capacité. Opus est le modèle le plus capable d'Anthropic disponible pour utilisation, adapté au raisonnement exigeant, au codage avancé et à la synthèse de recherche où Sonnet ne répond pas à votre barre de qualité. Le point de départ par défaut est toujours Sonnet. Passez à Opus uniquement quand un ensemble d'éval vous dit que Sonnet ne répond pas à votre barre de qualité. Passez à Haiku uniquement quand un ensemble d'éval confirme que le compromis de qualité est acceptable pour votre tâche spécifique. Votre décision de déplacer les modèles devrait toujours être mesurée, pas réflexe.

Dimensionnement de la fenêtre de contexte : la falaise de la mémoire de travail Tout ce que le modèle attend vit dans la fenêtre de contexte. À l'intérieur de la fenêtre, l'attention est disponible. En dehors, le modèle n'a pas du tout accès. La mémoire de travail est la propriété avec la limite la plus dure des quatre : les choses fonctionnent jusqu'à ce qu'elles ne le fassent pas, et la transition est abrupte. La fenêtre de contexte est mesurée en tokens. La quantité de texte qu'un token couvre varie selon la génération de modèle, le tokenizer et la langue, donc traitez tout ratio caractères-par-token fixe comme une illustration approximative plutôt qu'une règle. Mesurez au lieu d'estimer : chaque réponse API signale les comptes de tokens réels dans son champ usage, et ces comptes mesurés sont ce que la limite de contexte et la facturation appliquent. Tout ce qui entre dans la fenêtre de contexte, votre prompt système, l'historique de conversation, les documents récupérés, les sorties d'outils et les réponses du modèle, est compté en tokens. Cela compte pour deux raisons : la fenêtre de contexte a une limite de token fixe, et vous êtes facturé par token sur chaque appel API. Les deux contraintes apparaissent directement dans les décisions couvertes dans cette section. L'implication pratique est directe : ne budgétez pas la fenêtre complète. Budgétez pour la plus grande conversation réaliste, plus le contexte récupéré, plus le prompt système, plus le brouillon de travail, plus la marge pour la croissance. La fenêtre de contexte est un plafond, pas une cible, donc concevoir vers le plafond signifie que vous le frappez en production.

Stratégie de contexte : spectre entre progressive et monolithique Chaque charge de travail de production fait un choix, implicitement ou explicitement, sur la façon dont le contexte atteint le modèle sur chaque appel. Le choix se situe sur un spectre entre deux pôles. À une extrémité, une stratégie de contexte monolithique place tout dans le prompt à la fois : le document complet, l'historique de conversation complet, le corpus de récupération complet. Cela fonctionne pour les tâches délimitées avec des tailles d'entrée prévisibles. C'est aussi la stratégie qui heurte la falaise de la mémoire de travail en production, parce que le contexte s'accumule entre les tours et la fenêtre se remplit silencieusement avant que quelqu'un ne remarque que quelque chose a été tronqué. À l'autre extrémité, une stratégie de contexte progressive met en scène le contexte à la place : elle récupère juste à temps, résume entre les tours et charge uniquement ce que l'étape suivante a besoin. La plupart des charges de travail de production appartiennent ici. Deux autres modèles se situent entre les pôles et apparaissent assez souvent pour être traités comme des stratégies. Le tableau ci-dessous énonce où chacune des quatre stratégies gagne sa place et où elles se cassent. Développez chaque stratégie pour voir où elle gagne sa place et où elle se casse.

Monolithique, charger le contexte complet requis dans un seul promptOù cela gagne sa place :Tâches délimitées avec taille d'entrée prévisible. Préfixes stables qui bénéficient de la mise en cache de prompt. Q&A à un seul coup où la latence de récupération ne vaut pas la peine. Raisonnement qui nécessite vraiment un accès simultané à tout le matériel. Où cela se casse :Conversations ou boucles d'outils où le contexte s'accumule tour après tour. Le coût et la latence s'adaptent linéairement à la longueur d'entrée. La qualité d'attention peut se dégrader sur des contextes très longs bien avant la limite dure. Progressive, porter en avant uniquement ce que l'étape suivante a besoinOù cela gagne sa place :Dialogue multi-tour et raffinement itératif. Boucles d'agent où chaque étape dépend principalement de l'état récent. Flux de travail qui se décomposent en étapes avec des remises étroites et bien définies. Le défaut pour la plupart des charges de travail de production. Où cela se casse :Tâches nécessitant une cohérence à long terme sur l'historique complet. Décisions qui dépendent du détail abandonné dans un tour antérieur. La mise en cache de prompt est plus difficile quand le contexte porté en avant mute à chaque tour. L'entrée exacte que le modèle a vue à l'étape N n'est plus reconstructible, ce qui complique le débogage. Récupération (RAG), récupérer les chunks pertinents d'un magasin externe au moment de la requêteOù cela gagne sa place :Bases de connaissances trop grandes pour tenir dans le contexte. Sources qui changent plus vite que le prompt n'est redéployé. Domaines où toute requête unique a besoin que d'une petite tranche de matériel disponible. Cas où la citation de source est une exigence. Où cela se casse :Requêtes nécessitant une synthèse sur de nombreux documents que le récupérateur note indépendamment. Chunking qui divise les unités sémantiques comme les tableaux, les blocs de code ou les arguments multi-paragraphes. Défaillances de rappel où le document correct n'entre jamais dans le top-k. La qualité de récupération devient un système que vous devez évaluer et maintenir. Compaction, résumer ou compresser périodiquement le contexte accumuléOù cela gagne sa place :Agents de longue durée et conversations où la transcription complète est gaspillée mais l'état récent compte. Transitions de phase dans les flux de travail multi-étapes qui peuvent faire un point de contrôle à un résumé propre. Sessions qui dépasseraient autrement les limites de contexte à mi-tâche. Où cela se casse :Résumés qui abandonnent le détail de charge : identifiants exacts, valeurs numériques, décisions antérieures, cas limites mentionnés une fois. Le résumé est lui-même un appel de modèle avec latence, coût et modes de défaillance. La compaction est largement unidirectionnelle. Mesurer la fidélité du résumé par rapport à la transcription originale est un problème d'évaluation non résolu.

En pratique, les stratégies peuvent être combinées Les quatre stratégies ci-dessus sont présentées séparément pour la clarté d'apprentissage, mais les systèmes de production combinent presque toujours. Chacun gère une dimension différente du problème de contexte, donc un système bien conçu les met en couches délibérément plutôt que d'en choisir un. Un exemple travaillé, agent de codage de longue durée :

PhaseQu'est-ce qui se passeStratégie en jeu

Démarrage de sessionCharger la description de la tâche et les quelques fichiers que l'utilisateur référence explicitement Préfixe monolithique, Un petit contexte stable chargé une fois, idéal pour la mise en cache de prompt. Travail actifChaque appel d'outil (fichier de lecture, tests d'exécution, édition) s'ajoute au contexte de travailÉtat récent progressif, L'ajout le plus récent est ce que l'étape suivante a besoin. DécouverteL'agent réalise qu'il a besoin d'un fichier qu'il n'a pas chargé initialement ; recherche la base de code et tire les correspondancesRécupération juste à temps, Le corpus est trop grand pour précharger, et seule une tranche pertinente est récupérée à la demande. Remplissage de contexteAprès de nombreux tours, l'exploration précoce prend de la place ; les conclusions comptent mais pas les sorties d'outils verbatim Compaction, Résume « ce que nous avons essayé et ce que nous avons appris », en préservant uniquement les idées et les décisions qui portent le travail en avant.

Remarquez qu'aucune stratégie unique ne pourrait porter cette charge de travail. Monolithique seul heurte la limite de contexte. Progressive seule n'a aucun moyen de faire surface le code que l'agent n'a pas chargé initialement. Récupération seule perd le fil de ce qui a été essayé. Compaction seule n'a rien à compacter jusqu'à ce que d'autres stratégies aient construit la trajectoire. L'apprentissage architectural : lors de la conception d'un système de contexte, posez-vous ces questions séparées :

Qu'est-ce que le modèle a besoin au démarrage ? → entraîne la ligne de base monolithique Qu'est-ce qu'il a besoin des étapes les plus récentes ? → entraîne la fenêtre progressive Qu'est-ce qu'il pourrait avoir besoin de récupérer à la demande ? → entraîne la couche de récupération Quel matériel antérieur peut être compressé sans perdre le détail pertinent pour la décision ? → entraîne la politique de compaction

La stratégie de contexte et le dimensionnement du contexte sont des décisions séparées qui interagissent mais ne se déterminent pas mutuellement. Les traiter comme une est l'endroit où la plupart des conceptions de gestion du contexte se trompent.

Ce que la réflexion étendue contrôle La réflexion étendue est une capacité par demande : le modèle travaille à travers le problème dans un bloc de réflexion séparé avant de produire la réponse finale. Comment vous le contrôlez a changé entre les générations de modèles. Sur Claude Opus 4. 6 et versions ultérieures, Claude Sonnet 4. 6 et versions ultérieures et Claude Sonnet 5, la réflexion adaptative avec le paramètre d'effort est le contrôle recommandé : vous définissez combien d'effort de raisonnement appliquer plutôt que de configurer un budget de token. La réflexion adaptative est le seul mode de réflexion sur Claude Fable 5. Le budget de token de réflexion manuel plus ancien (budget_tokens) est déprécié sur la génération 4. 6 et supprimé sur Claude Sonnet 5, où il retourne une erreur 400 ; vérifiez le support du modèle actuel par rapport à platform. claude. com au moment de la publication. Les tokens de réflexion sont facturés comme des tokens de sortie au taux de sortie standard du modèle et les générer ajoute de la latence à l'appel. Quand la réflexion étendue n'est pas engagée, aucun de ces tokens n'est généré et aucun n'est facturé. La décision d'utiliser la réflexion étendue s'ancre sur la question de savoir s'il faut ajouter une passe de raisonnement facturée à un appel. Le modèle raisonne de toute façon en interne. Ce que vous choisissez, c'est de dépenser des tokens et de la latence sur une passe étendue. Sur les modèles qui supportent la réflexion étendue, l'API peut retourner une représentation résumée du processus de réflexion plutôt que la sortie de raisonnement complète. Vous êtes facturé pour les tokens de réflexion réellement consommés pendant le raisonnement, pas pour la longueur du résumé visible. Une fois que cette distinction est claire, la règle de décision est directe. La réflexion étendue est un compromis de coût et de latence. Exécutez d'abord vos évals sans elle : si la précision ne répond toujours pas à vos exigences après avoir travaillé sur le prompt lui-même, alors considérez l'activer. Avec la réflexion étendue engagée, vous payez pour les tokens de réflexion et la latence supplémentaire sur chaque appel. Le cas pour l'activer devrait venir d'un écart de précision mesuré, pas de l'hypothèse que c'est un mode qui « ne peut pas faire de mal ». Sans cette preuve, vous payez le coût sans preuve qu'il déplace vos métriques de précision.

Porte chaque changement de modèle avec un éval avant de l'expédier Tout changement au modèle est un changement au comportement du système. Un échange entre deux modèles est un déploiement de code et devrait être traité comme tel. Au minimum, vous avez besoin de trois choses :

Un ensemble de test organisé de prompts avec des sorties connues-bonnes qui couvre la distribution réelle de travail que le système voit Une fonction de notation (noté par modèle par rapport à une rubrique, ou programmatique où vous pouvez exprimer la vérification dans le code) Un seuil delta fixé à l'avance en dessous duquel vous n'expédiez pas. Fixez le seuil avant d'exécuter l'éval. Si vous le fixez après, vous n'établissez pas une norme, vous écrivez les critères d'acceptation après la construction.

Cas travaillé : une rétrogradation Sonnet à Haiku, bien faite Le cas ci-dessous montre la séquence complète d'une rétrogradation de modèle exécutée par rapport à une contrainte de production réelle. Le modèle à porter dans votre propre travail est le critère de restauration : fixé à l'avance, refusé de négocier quand les données sont arrivées, et utilisé pour motiver une migration partielle au lieu d'une complète. Un pipeline d'intelligence de document s'exécute sur Sonnet depuis six mois et a utilisé tout son budget. Maintenant, l'équipe veut passer à Haiku.

L'équipe construit un ensemble d'éval de 250 documents représentatifs avec des cibles d'extraction validées à la main, stratifiées entre les types de documents qui apparaissent dans le trafic de production. L'échantillon est dimensionné pour que les scores par type de document restent significatifs, pas seulement la moyenne globale. L'équipe exécute les deux modèles par rapport au même ensemble et note chaque extraction avec la même rubrique de notation. La signature de régression revient comme suit : Sonnet marque 0,94 en moyenne, Haiku marque 0,86 en moyenne, et la variance se concentre dans deux types de documents où Haiku marque 0,71 et 0,74 respectivement. Le reste des types de documents arrive dans la tolérance. Le critère de restauration était fixé à l'avance : si un seul type de document tombe en dessous de 0,85, la migration est rejetée. Deux types de documents ont traversé cette ligne, donc la migration telle que proposée est rejetée. Le mouvement de sauvetage est d'acheminer ces deux types de documents à Sonnet via le classificateur existant, et d'acheminer les autres types à Haiku. Le coût baisse matériellement sans prendre la régression sur les types de documents difficiles.

Plutôt que les scores spécifiques, votre apprentissage de ce cas devrait être concentré sur la façon dont le critère de restauration a été décidé avant que les données n'arrivent. Cela signifiait que quand les données sont arrivées, l'équipe n'a pas eu à négocier avec elle-même, et l'ensemble d'éval a fait surface une option de migration partielle qu'un seul score global aurait caché.

Pointeur vers l'avant La sélection de modèle et la stratégie de contexte sont deux des leviers de la zone d'invitation. Vous apprendrez deux autres leviers de la zone d'invitation (conception de prompt système et réutilisation de prompt) plus tard dans ce module.

Coût · Complexité · Risque Coût : Le contexte monolithique est le tueur de budget silencieux. Dans un pipeline lourd en documents, une conversation qui commence avec un prompt de 4 000 tokens peut porter 80 000 tokens au tour 30. Le coût par appel grandit avec la conversation, et il n'y a pas de signal visible jusqu'à ce qu'il apparaisse dans la facturation. Complexité : Un échange de modèle semble être un changement de configuration d'une ligne, mais il réécrit comment le produit entier se comporte. Traitez les échanges de modèle comme des versions. Risque : Pas d'ensemble d'éval signifie pas de signal de restauration. Une régression découverte en production est une régression qui n'a pas du tout été détectée, parce qu'au moment où vous la voyez, l'utilisateur l'a déjà.

Écran 22 : Quand le défaut à Opus partout a produit un dépassement de coût de 7×

Attention 4 min · Stratégie de modèle et de contexte

Quand le défaut à Opus partout a produit un dépassement de coût de 7×

Crochet de configuration Quand la démo doit atterrir et le partenaire est dans la salle, la réponse intelligente est « utiliser le meilleur modèle disponible ». Cette réponse est aussi le chemin de moindre résistance pendant la construction : pas d'ensemble d'éval requis, pas de défense d'un choix. La facture arrive plus tard, et à ce moment-là, le système a été en direct assez longtemps pour que la rétrogradation porte un coût de gestion du changement associé.

90 jours après le lancement Symptôme. Le coût mensuel s'exécute à sept fois le chiffre de modélisation original. La latence sur le chemin visible par l'utilisateur s'assoit à 2,3 secondes médiane, ce qui est bien au-dessus de la cible de 800 millisecondes que le partenaire a acceptée au lancement. Les scores de satisfaction client n'ont pas bougé par rapport à la ligne de base pré-lancement. Cause. Chaque appel dans la pile utilise Opus. Il n'y a pas de sélection de modèle par étape dans l'architecture, parce qu'il n'y avait pas d'éval par étape qui aurait rendu la sélection par étape nécessaire. L'équipe a défaut au « meilleur modèle disponible » pendant la construction et n'a jamais revisité le choix une fois que le trafic était en direct. Facteurs contributifs. Trois choses se sont composées : Le document d'architecture original n'incluait pas une décision de niveau de modèle à aucune étape, donc le défaut implicite s'est porté jusqu'au déploiement. Le coût a été examiné mensuellement plutôt que déterminé pendant le développement, donc l'écart entre les dépenses projetées et réelles n'a pas fait surface jusqu'à des semaines après le lancement. La réflexion étendue avait été activée sur un classificateur de routage qui n'avait pas besoin de raisonnement du tout, et ce paramètre a ajouté une latence mesurable et un coût à chaque demande qui a traversé le classificateur. Ce que l'équipe a changé. L'équipe a construit un ensemble d'éval rétroactivement, couvrant le travail que chaque étape de pipeline faisait réellement. Ils ont acheminé l'étape du classificateur à Haiku et confirmé pas de régression sur l'éval. Ils ont acheminé la résumé à mi-pipeline à Sonnet et confirmé pas de régression là aussi. Ils ont gardé Opus sur l'étape de composition de réponse finale, qui était le seul endroit où l'éval a dit que le niveau supérieur gagnait sa place. Le coût mensuel a baissé de 71 %. La latence a baissé à 940 millisecondes médiane. Les scores de satisfaction client sont restés inchangés.

Comment une décision de niveau de modèle devient une conversation de budget Trois mécanismes de défaillance se sont composés, et chacun est reconnaissable à l'avance.

Le premier : « pas de décision de niveau de modèle » était elle-même une décision implicite, et le système a défaut à l'option la plus coûteuse. L'absence d'un choix délibéré n'est pas neutre. Le second : la visibilité des coûts a traîné la construction de semaines. La facture est arrivée après le lancement, après que le partenaire soit déjà allé en direct. Cela a déplacé la conversation de coût hors de la conception et dans la gestion du changement. Le troisième : l'ensemble d'éval n'existait pas pendant la construction, donc quand « utiliser le meilleur modèle » a été proposé, l'équipe n'avait rien à pointer qui aurait fondé un choix différent. L'ensemble d'éval n'est pas seulement une porte de version, c'est la seule chose qui rend la décision de niveau défendable.

Pourquoi cela se casse ? Ne pas choisir un modèle équivaut à choisir le plus coûteux. Un ensemble d'éval semble être du travail supplémentaire à l'avance mais c'est aussi la seule chose qui rend la décision de modèle défendable.

Écran 23 : Calculatrice de coût et de latence

Point de contrôle 9 min · Stratégie de modèle et de contexte

Calculatrice de coût et de latence Utilisez la calculatrice pour explorer les configurations. Définissez le niveau de modèle (Opus / Sonnet / Haiku), la stratégie de contexte (monolithique / progressive), le volume d'appels par jour et la réflexion étendue (activée / désactivée). Les lectures affichent le coût et la latence pour chaque paramètre. Votre objectif : trouver une configuration qui répond à la fois au plafond de coût et au budget de latence en même temps, les deux ne peuvent pas être échangés l'un contre l'autre. La calculatrice affiche uniquement les valeurs ; elle ne note pas votre exploration. Plus d'une configuration valide existe.

Niveau de modèle OpusSonnetHaiku

Stratégie de contexte MonolithiqueProgressive

Appels par jour

Réflexion étendue DésactivéeActivée

Coût mensuel estimé, Latence médiane,

Chiffres illustratifs basés sur la tarification de liste publiée en juin 2026 (tarification actuelle par million de tokens d'entrée/sortie pour Opus, Sonnet et Haiku, disponible sur docs. claude. com). Vérifiez la tarification et la latence actuelles sur docs. claude. com avant de vous fier à ces chiffres avec un partenaire.

Décision : identifier le contrôle de charge Une fois que vous avez une configuration où les deux lectures sont dans le budget, demandez-vous : quel seul paramètre, s'il était assoupli, dépasserait un budget en premier ?

A. Le volume d'appels, parce que c'est la seule entrée que vous ne pouvez pas changer. B. Le contrôle du contrainte dominant, par exemple, si la latence est le budget serré, le niveau de modèle ou le paramètre de réflexion étendue qui entraîne la latence. C. Aucun ; tout paramètre peut être changé librement une fois que les deux lectures sont vertes.

Soumettre Passer pour l'instant

Une fois que vous avez une configuration de passage et avez sélectionné la bonne réponse ci-dessus : en 2–3 phrases, nommez la contrainte dominante dans votre configuration de passage et identifiez le seul paramètre qui est de charge pour elle. Écrivez votre réponse, puis révélez la réponse du modèle ci-dessous.

Votre justification

Révélez la réponse du modèle La contrainte dominante dépend de quel budget était plus serré dans votre configuration. Si la latence est la contrainte contraignante, le niveau de modèle et le paramètre de réflexion étendue sont de charge, ce sont les contrôles qui déplacent le plus directement la latence. Si le coût est contraignant, le niveau et la stratégie de contexte sont de charge. Le contrôle de charge est celui lié à quel budget avait le moins de marge. Le nommer explicitement est ce qui rend la configuration défendable plutôt que chanceuse.

Écran 24 : Concevoir les prompts système, les modèles et les garde-fous

Enseignement 10 min · Invitation comme architecture

Concevoir les prompts système, les modèles et les garde-fous L'écran de modèle et de contexte couvrait le choix d'un niveau de modèle et d'une stratégie de contexte. L'autre grand levier dans cette zone de décision est l'invitation elle-même. À l'échelle d'entreprise, l'invitation n'est pas une phrase que vous tapez, mais un actif que vous concevez : un prompt système, un modèle réutilisable et les garde-fous qui gardent les deux sûrs et cohérents. C'est le premier des trois écrans sur l'invitation comme discipline architecturale.

Architecture de prompt système pour la réutilisation d'entreprise Un prompt système pour un chat unique et un prompt système sur lequel des centaines de demandes par jour dépendent sont des artefacts différents. La version d'entreprise est conçue pour la réutilisation, ce qui signifie qu'elle a une structure : une déclaration claire du rôle et de la portée, les contraintes que le modèle doit tenir (ce qu'il ne doit pas faire, ce qu'il doit toujours faire) et un contrat de sortie qui nomme la forme que la réponse doit prendre. Quand un prompt système est réutilisé à l'échelle, l'ambiguïté est un défaut multiplié sur chaque demande.

Modèles : cohérence et sécurité, appliquées Un modèle est un prompt système avec des emplacements paramétrés (les pièces qui changent par demande) et un échafaudage fixe autour d'eux. L'objectif de conception est que l'échafaudage fixe porte les garanties de cohérence et de sécurité, pour que remplir un emplacement ne puisse pas accidentellement supprimer une contrainte. Un modèle bien conçu rend le chemin sûr le chemin par défaut : la personne l'utilisant fournit le contenu variable et hérite des garde-fous sans avoir à les réautoriser.

Description : la compétence de 4D appliquée à la conception d'invitation La description est l'une des quatre compétences de fluidité IA, la discipline de dire au modèle précisément ce que vous voulez : la portée de la tâche, le format de la sortie et les contraintes qui la limitent. Appliquée à la conception d'invitation, la description est ce qui sépare une invitation qui fonctionne dans une démo d'une qui tient en production. Une invitation bien décrite nomme :

La portée : Ce qui est dedans et hors limites Le format : Le contrat de sortie exact Les contraintes : Les règles qui ne doivent jamais être violées

La sous-spécification est un écart que le modèle remplit avec sa propre hypothèse, différemment à chaque fois, et c'est l'échec clé à surveiller. Diagnostiquer les écarts de sous-spécification signifie lire une invitation pour ce qu'elle ne dit pas. Où l'invitation est silencieuse, le modèle improvise et l'improvisation est exactement le non-déterminisme que vous ne voulez pas dans un actif réutilisé. Le correctif est de rendre l'implicite explicite : reformulez l'objectif aux côtés de l'instruction, nommez le format et limitez les contraintes.

Coût · Complexité · Risque Coût : Une invitation vague est payée dans chaque demande qui a besoin de correction, de tentative ou de nettoyage humain. Concevoir l'invitation bien une fois est beaucoup moins cher que diagnostiquer la dérive sur des milliers d'appels. Complexité : Les modèles concentrent la complexité en un endroit où elle peut être examinée et gouvernée, au lieu de la disperser sur des invitations ad-hoc que personne ne possède. Risque : Un garde-fou sous-spécifié est pire qu'un manquant, parce qu'il crée l'apparence d'un contrôle sans la substance. Une contrainte que le modèle peut silencieusement contourner n'est pas une contrainte.

Écran 25 : Techniques d'ingénierie d'invitation entre les modèles

Enseignement 7 min · Invitation comme architecture

Techniques d'ingénierie d'invitation entre les modèles Une fois qu'une invitation est conçue pour la réutilisation, la question suivante est quelle technique utiliser à l'intérieur. La technique est choisie par la complexité de la tâche, pas par l'habitude. Cet écran couvre les techniques principales, comment le choix change entre les modèles et comment éviter de construire un biais dans l'invitation.

Sélection de technique par complexité de tâche

TechniqueQu'est-ce que c'estQuand cela s'adapte

Zéro-shotInstruction uniquement, pas d'exemples. Tâches bien spécifiées que le modèle gère déjà de manière fiable ; le défaut à essayer en premier. Peu de coups Une poignée d'exemples d'entrée/sortie dans l'invitation. Tâches où le format ou le jugement souhaité est plus facile à montrer qu'à décrire. Chaîne de pensée Invitez le modèle à raisonner étape par étape avant de répondre. Raisonnement multi-étapes, logique de type arithmétique, ou tâches où le chemin compte pour la réponse.

La progression est délibérée : commencez zéro-shot, ajoutez des exemples uniquement si la tâche en a besoin, et ajoutez un raisonnement explicite uniquement si la structure de la tâche l'exige. Chaque étape ajoute des tokens et de la latence, donc atteindre la technique la plus légère qui répond à l'exigence.

Différences comportementales entre les modèles Le même invitation ne se comporte pas identiquement entre les niveaux de modèle ou les générations. Un modèle plus capable peut avoir besoin de moins d'échafaudage (moins d'exemples, moins d'instruction étape par étape explicite) pour atteindre la même qualité, tandis qu'un modèle moins capable peut avoir besoin de plus. Une invitation accordée pour un modèle est un point de départ pour un autre, pas un artefact fini. C'est pourquoi un échange de modèle est traité comme une version et gated avec une évaluation : l'appairage invitation-modèle est ce que vous expédiez réellement.

Éviter le biais dans la construction d'invitation La construction d'invitation peut introduire un biais que la tâche n'a jamais prévu. La formulation directrice, les ensembles d'exemples déséquilibrés (ensembles peu de coups qui montrent seulement un type de cas) et les hypothèses cuites dans l'instruction entraînent tous la sortie d'une manière qui peut être facile à manquer. La discipline est de formuler de manière neutre, d'équilibrer les exemples entre les cas que le système verra réellement et de vérifier si l'invitation présume une réponse qu'elle devrait éliciter.

Point de contrôle : matrice de sélection de technique Pour chaque tâche ci-dessous, sélectionnez la technique (zéro-shot / peu de coups / chaîne de pensée) et tapez une raison d'une phrase. Les deux sont requis avant de soumettre.

Tâche 1. Classer un ticket d'assistance client dans l'une des cinq catégories standard : facturation, technique, retours, compte ou général. Choisir... Zéro-shotPeu de coupsCharîne de penséeCorrect : Zéro-shot. La tâche est bien spécifiée, les catégories sont nommées, et le modèle gère la classification de manière fiable sans exemples. Tâche 2. Extraire les champs structurés, date, fournisseur et montant, à partir de reçus de dépenses qui varient largement en mise en page et en formatage. Choisir... Zéro-shotPeu de coupsCharîne de penséeCorrect : Peu de coups. Le format d'extraction souhaité est plus facile à démontrer avec des exemples qu'à décrire dans les instructions, en particulier compte tenu de la variation de mise en page. Tâche 3. Déterminer si une clause de contrat multi-étapes crée une responsabilité selon trois conditions qui interagissent les unes avec les autres. Choisir... Zéro-shotPeu de coupsCharîne de penséeCorrect : Chaîne de pensée. La réponse dépend d'une séquence d'étapes de logique conditionnelle ; inviter le raisonnement étape par étape réduit la chance de sauter une interaction. Tâche 4. Résumer une description de produit de 400 mots en deux phrases. Choisir... Zéro-shotPeu de coupsCharîne de penséeCorrect : Zéro-shot. Résumé standard sur une entrée bien délimitée ; ajouter des exemples ou des étapes de raisonnement explicites ajoute des tokens et de la latence sans gain de qualité.

Soumettre Passer pour l'instant

Coût · Complexité · Risque Coût : Les techniques plus lourdes coûtent des tokens et de la latence sur chaque appel. La chaîne de pensée sur une tâche qui ne l'exige pas est une taxe récurrente pour aucun gain. Complexité : Les exemples peu de coups sont du contenu à maintenir : à mesure que la tâche évolue, les exemples obsolètes entraînent silencieusement le modèle mal. Risque : Le biais introduit dans l'invitation est invisible dans toute sortie unique et ne fait surface que dans l'agrégat, c'est pourquoi la formulation neutre et les exemples équilibrés sont une exigence de conception, pas une étape de polissage.

Écran 26 : Mécanique de mise en cache, invitations modulaires et compétences

Enseignement 8 min · Invitation comme architecture

Mécanique de mise en cache, invitations modulaires et compétences Les invitations réutilisables soulèvent une question que l'invitation unique ne pose jamais : comment réutilisez-vous efficacement et comment emballez-vous pour que une équipe puisse partager et gouverner ? Cet écran couvre la mécanique de la mise en cache, la différence entre une bibliothèque d'invitation modulaire et une compétence, et la décision de laquelle utiliser.

Un cache qui ne frappe jamais Une équipe a mis son invitation d'analyse réutilisable en production et n'a vu aucune des économies de coût que la mise en cache était censée apporter. La cause était l'ordre : ils avaient placé le contenu par demande (le document analysé) en haut de l'invitation, avant le grand bloc d'instruction fixe. Parce que le cache correspond sur un préfixe stable, mettre le contenu dynamique en premier signifiait que le préfixe changeait sur chaque demande et le cache ne frappait jamais. Le correctif était de réorganiser avec le contenu fixe en premier et le contenu dynamique en dernier.

Mécanique de mise en cache qu'un architecte conçoit autour Points de rupture de cacheL'utilisation de cache fonctionne sur un préfixe stable. Marquez la limite entre la partie fixe de l'invitation (cacheable) et la partie variable (non), et gardez la partie fixe vraiment fixe. Ordre du contenuStatique avant dynamique, toujours. Le grand bloc d'instruction inchangé va en premier ; le contenu par demande va après le point de rupture. Sélection TTLFaites correspondre la durée de vie du cache à la fréquence à laquelle le contenu fixe change réellement et à la fréquence à laquelle l'invitation est appelée. Une invitation appelée constamment bénéficie d'un cache plus durable ; une appelée rarement peut ne jamais amortir l'écriture. Quand le coût d'écriture ne vaut pas la peineLa mise en cache a son propre coût. Si une invitation est appelée rarement ou sa partie fixe est petite, la mise en cache peut coûter plus qu'elle n'économise. La mise en cache est une décision de conception, pas un défaut à activer partout.

Bibliothèques d'invitation modulaires vs compétences comme unités réutilisables versionnées Il y a deux façons de rendre une invitation réutilisable entre une équipe. Une bibliothèque d'invitation modulaire est une collection partagée de fragments d'invitation et de modèles que les ingénieurs assemblent dans leur propre code. Une compétence est une unité plus formelle et versionnée : un SKILL. md qui empaquette les instructions, les scripts exécutables optionnels et la gestion des versions, pour que la procédure entière voyage comme un actif gouverné. Une compétence est la primitive de réutilisation nommée dans l'écran des fondations (empaqueter une procédure répétable) appliquée à l'invitation.

La décision de réutilisation : bibliothèque ou compétence

ConsidérationPenchant vers une bibliothèque d'invitationPenchant vers une compétence

RépétabilitéUne invitation assemblée, souvent ajustée par utilisation. Une procédure stable exécutée de la même manière à chaque fois. DistributionPartagé dans une base de code ou une équipe. Distribué entre les équipes ou les produits qui ont besoin de la même procédure. GouvvernanceL'éger ; les ingénieurs possèdent les fragments. Nécessite le versioning, l'approbation et la restauration, les compétences portent cela.

Coût · Complexité · Risque Coût : La mise en cache peut réduire considérablement le coût quand elle frappe et ajouter du coût quand elle ne le fait pas. Modélisez les économies avant de vous engager. Complexité : Une compétence concentre une procédure en une unité versionnée qui peut être examinée et restaurée ; une propagation de copier-coller d'invitations ne peut pas. Risque : Une invitation non gouvernée qui est copiée entre les équipes dérive en de nombreuses versions légèrement différentes, chacune avec son propre comportement silencieusement différent. La réutilisation versionnée est le contrôle.

Écran 27 : Rédigez l'actif d'invitation réutilisable

Exercice 6 min · Invitation comme architecture

Rédigez l'actif d'invitation réutilisable Le briefL'organisation d'assistance d'un partenaire exécute la même opération des centaines de fois par jour : étant donné un ticket d'assistance d'un client et la section pertinente du manuel de produit, produisez une réponse rédigée qui suit les directives de ton du partenaire, cite la section du manuel sur laquelle elle s'est appuyée et ne promet jamais un remboursement ou un calendrier que l'agent n'a pas approuvé. Rédigez l'actif d'invitation réutilisable. Prenez les trois décisions de conception ci-dessous et écrivez une brève justification pour chacune :

Où le préfixe stable se termine-t-il et le contenu par demande commence-t-il ? Nommez le placement du point de rupture et expliquez pourquoi. Comment appliquez-vous le garde-fou de ne jamais promettre un remboursement structurellement, pas seulement comme une instruction énoncée ? Décrivez la contrainte du contrat de sortie. Devrait-ce expédier comme un modèle ou une compétence ? Nommez le choix d'emballage et énoncez la raison.

Écrivez votre réponse, puis révélez la réponse du modèle ci-dessous. Sentez-vous libre de demander à Claude de comparer ce que vous avez écrit avec la réponse fournie.

Votre conception d'actif d'invitation

Révélez la réponse du modèle

Placement du point de rupture de cache : Mettez le rôle, les règles de ton, le contrat de sortie et le garde-fou de ne jamais promettre en premier comme le préfixe stable, puis le ticket et la section du manuel comme le seul contenu par demande. Le contenu dynamique avant le point de rupture signifie que le préfixe change sur chaque appel et le cache ne frappe jamais. À des centaines d'appels par jour, le préfixe stable est l'endroit où les économies de coût vivent. Application du garde-fou : Construisez-le dans le contrat de sortie comme une contrainte structurelle que le format exige, pas comme une phrase dans le texte de rôle. Une règle énoncée dans le rôle peut être dérivée. Une contrainte construite dans le contrat de sortie façonne le format de réponse et ne peut pas être silencieusement ignorée. Emballage : Une compétence versionnée. La procédure est stable, exécutée identiquement des centaines de fois par jour entre l'organisation d'assistance, et a besoin du versioning et de la restauration. Un modèle collé que chaque agent garde localement n'a pas de gouvernance centrale, ne peut pas être restauré et dérive en légèrement différentes versions au fil du temps.

Écran 28 : Sélection de point d'entrée, de route et de gouvernance

Enseignement 11 min · Points d'entrée et gouvernance

Sélection de point d'entrée, de route et de gouvernance Vous avez choisi le modèle et la forme, et maintenant il est temps de choisir comment un partenaire consomme Claude. Choisir comment un partenaire consomme Claude implique trois décisions séparées, prises en séquence. Les obtenir dans le bon ordre empêche les erreurs d'architecture les plus courantes.

Quel point d'entrée s'adapte au travail ? Quelle interface de temps de construction convient à l'équipe ? Quelle route de livraison s'adapte aux engagements cloud du partenaire ?

Les trois couches (points d'entrée, interfaces de temps de construction et routes de livraison) ont été enseignées comme vocabulaire dans la section des fondations. Cet écran est le travail de sélection : choisir parmi eux sous des contraintes réelles.

Quels points d'entrée Claude s'adaptent au travail ? Un point d'entrée est le wrapper qui décide qui peut parler à Claude, ce que Claude peut toucher et combien d'ingénierie le partenaire doit faire pour y arriver. Pensez aux points d'entrée comme la même intelligence emballée pour différents travaux. Choisir le mauvais point d'entrée ne casse pas le travail, mais cela ajoute de la friction que le partenaire sentira chaque jour. Au-delà de Claude. ai et Claude Code, Anthropic expédie trois points d'entrée qui étendent Claude dans des applications ou des environnements spécifiques. Avant de construire des flux de travail de partenaire qui dépendent de l'un d'eux, vérifiez les capacités actuelles, les configurations supportées et la disponibilité par rapport à la documentation d'Anthropic. Points d'entrée pour utilisateur final Point d'entréeDescriptionPublic et utilisationCompromi central

Claude. ai (applications web, mobile et bureau)Le produit de chat pour utilisateur final hébergé par Anthropic. Un utilisateur connecté ouvre une conversation, attache des fichiers, utilise des projets pour le contexte partagé et connecte des services comme Slack, Outlook ou Google Drive via des connecteurs intégrés. Il vient en niveaux de consommateur (Gratuit, Pro, Max) et en Claude pour le travail. Claude pour le travail a deux niveaux. Le niveau équipe ajoute les contrôles d'administration, SSO et SAML, la capture de domaine et un engagement contractuel de ne pas entraîner sur le contenu du client. Le niveau entreprise ajoute le provisioning SCIM, la rétention configurable, les journaux d'audit, une API de conformité et une option prête pour HIPAA avec un BAA signé. Pour les travailleurs du savoir utilisant Claude comme partenaire de réflexion pour la recherche, la rédaction, l'analyse et l'examen. Aucun code n'est écrit. L'application web, l'application mobile et Claude Desktop atteignent tous le même produit Claude. ai. C'est le point d'entrée pour les utilisateurs appliqués d'IA, pas les constructeurs. Le niveau de consommateur s'adapte aux individus et aux petites équipes et Claude pour le travail s'adapte aux organisations qui ont besoin de contrôles de gouvernance et d'identité sur le même produit. Zéro coût de construction vs. zéro point d'entrée d'intégration : Vous obtenez le produit qu'Anthropic expédie et vous ne pouvez pas l'intégrer dans un autre produit ou personnaliser ce qui est exposé. Le bon niveau dépend des besoins de gouvernance : les niveaux de consommateur pour le travail à faible sensibilité, Claude pour le travail où les contrôles d'administration, SSO et les engagements de non-entraînement sont requis. Claude Code (terminal, plugin IDE, bureau, web)Un outil de codage agentic qui lit les fichiers, édite le code, exécute les commandes et exécute les tâches d'ingénierie multi-étapes sous des limites de permission configurables. Pour les ingénieurs faisant du vrai travail de développement : explorer les bases de code, refactoriser entre les fichiers, déboguer, construire des fonctionnalités. Le produit s'exécute dans un terminal, dans les plugins IDE (VS Code, JetBrains, autres), sur le bureau et sur le web à claude. ai/code. Le même agent, où que vous travailliez. Construit pour l'ingénierie : option exceptionnelle pour le code mais pourrait être la mauvaise forme pour un produit de service client ou tout flux de travail non-ingénierie. Claude CoworkUn agent de bureau pour les non-développeurs qui fonctionne avec les fichiers locaux et les applications, automatisant la gestion des fichiers et des tâches sous des permissions configurables. Pour les opérations, l'administration et d'autres rôles qui ont besoin que Claude prenne des actions sur leur ordinateur plutôt que de simplement produire du texte dans une fenêtre de chat. Disponible sur tous les plans payants (Pro, Max, Équipe, Entreprise) via l'application Claude Desktop sur macOS et Windows ; le support Linux est en bêta. Actions système réelles vs. surcharge de supervision : puissant pour l'automatisation de fichiers et de tâches parce que Cowork fonctionne sur l'ordinateur de l'utilisateur directement, avec la conséquence que la portée de permission et l'examen humain comptent plus qu'ils ne le font dans un point d'entrée chat uniquement. Claude dans ChromeUn agent de navigation qui fonctionne à l'intérieur du navigateur Chrome, naviguant sur les pages et prenant des actions au nom de l'utilisateur. Pour les travailleurs du savoir dont les tâches sont ancrées dans les applications Web plutôt que dans les fichiers ou les bases de code. N/A Claude pour ExcelUn agent de feuille de calcul qui fonctionne à l'intérieur d'Excel, travaillant directement avec les cellules, les formules et les données structurées. Pour les analystes, les équipes de finance et tout rôle dont l'outil de travail principal est une feuille de calcul. N/A

Interfaces de temps de construction : comment vous programmez contre Claude Une fois qu'un point d'entrée est choisi, la décision suivante est quelle couche programmatique le code du partenaire parle. Le tableau ci-dessous décrit les quatre interfaces de temps de construction. L'API, les SDK, MCP et l'Agent SDK ne sont pas des alternatives les uns aux autres dans tous les cas, ils se superposent les uns aux autres. Interfaces de temps de construction InterfaceDefinitionPublic et objectifCompromi

API directeL'interface HTTP directe à Claude. Un développeur s'authentifie, envoie une demande avec des messages, un nom de modèle et des paramètres, et reçoit une réponse. Pour les équipes construisant Claude directement dans leur propre produit. L'équipe du partenaire possède tout : tentatives, streaming, utilisation d'outils, observabilité et l'interface utilisateur. C'est l'interface de temps de construction la plus fondamentale, et la couche sur laquelle tout le reste s'assoit. Contrôle maximum vs responsabilité maximale : Utilisez ceci quand un SDK n'a pas exposé une fonctionnalité dont vous avez besoin, ou quand l'équipe préfère HTTP brut. SDK (Python, TypeScript, Java, Go, Ruby, C#, PHP)Les SDK offrent la même capacité que l'API, enveloppée dans des types natifs de langue et des aides qui réduisent le boilerplate. Ils gèrent l'authentification, le formatage des demandes, les tentatives, le streaming et le plomberie d'utilisation d'outils de manière idiomatique. La boucle d'agent, le cas échéant, est toujours le code du partenaire. Pour les équipes utilisant le même cas d'utilisation que l'API directe, mais l'équipe veut des types natifs de langue, moins de boilerplate et l'ergonomie intégrée pour le streaming et l'utilisation d'outils. Choix par défaut pour intégrer Claude dans un produit. Ergonomie vs. contrôle : Les abstractions SDK se déplacent au rythme de version d'Anthropic. Si vous avez besoin d'une fonctionnalité API brute que le SDK n'a pas exposée, vous allez revenir à HTTP de toute façon. MCPUn protocole ouvert pour exposer un ensemble d'outils, d'invitations et de ressources d'un serveur pour que tout client MCP-aware y compris Claude. ai, Claude Code, l'API ou un client tiers puisse les découvrir et les utiliser. Pas une convention d'appel pour Claude dans un seul produit, mais une convention de partage entre les produits. Pas une convention d'appel pour Claude dans un seul produit, mais une convention de partage entre les produits. Pour les équipes qui ont besoin des mêmes outils accessibles à partir de plusieurs clients Claude. Le même point d'entrée d'outil est nécessaire dans deux clients ou plus : Claude. ai, Claude Code, une application interne, un produit d'un partenaire. Construisez le serveur une fois, connectez-le partout. Réutilisabilité entre les clients vs. complexité architecturale ajoutée : Si un seul client l'utilisera jamais, MCP ajoute une surcharge sans beaucoup de retour. Agent SDK (@anthropic-ai/claude-agent-sdk)Exécuter une boucle d'agent gérée, la même boucle qui alimente Claude Code, à partir du code d'application du partenaire. Le paquet gère l'itération, l'exécution d'outils et la résiliation. Actuellement TypeScript (@anthropic-ai/claude-agent-sdk sur npm) et Python (claude-agent-sdk sur PyPI). Pour les équipes qui ont besoin que Claude agisse sur plusieurs tours à l'intérieur du produit du partenaire, avec l'application du partenaire contrôlant le flux de travail environnant, et Claude Code CLI est la mauvaise forme. Cas courant : un agent interne intégré dans une application Web, pas un outil de terminal. Boucle gérée vs. orchestration personnalisée : L'Agent SDK gère l'itération et la résiliation, mais le partenaire abandonne le contrôle fin sur la boucle elle-même.

Un moyen de garder ces termes séparés API et SDK : le même point d'entrée, ergonomie différente. L'API et le SDK sont le même point d'entrée du point de vue de Claude. Le SDK est un wrapper opinionné empilé sur l'API. Il ajoute des types natifs de langue, gère le streaming et le boilerplate d'utilisation d'outils, et permet à l'équipe du partenaire de travailler dans leur pile préférée (Python, TypeScript, Java, Go, Ruby, C# ou PHP) plutôt que contre HTTP brut. Le SDK est le défaut pour la plupart des équipes. La seule raison de tomber à HTTP brut est quand une fonctionnalité API fraîchement expédiée n'a pas encore fait son chemin dans le SDK. MCP et utilisation d'outils API : couches différentes, pas des alternatives. MCP est le protocole pour partager les outils entre les points d'entrée, comment un point d'entrée d'outil est exposé et découvert entre plusieurs clients. L'utilisation d'outils API est comment Claude appelle un outil à l'intérieur d'une seule demande. MCP et l'utilisation d'outils API ne sont pas des alternatives. Sous le capot, un serveur MCP expose les outils que tout client MCP-aware peut appeler en utilisant l'utilisation d'outils API. Le choix se résume à la fréquence à laquelle vous allez réutiliser la fonctionnalité : choisissez MCP quand un point d'entrée d'outil a besoin d'être accessible à partir de plusieurs clients Claude ; choisissez l'utilisation d'outils API brute quand les outils vivent à l'intérieur d'un seul produit uniquement. Claude Agent SDK : quand un partenaire a besoin d'une boucle d'agent qu'il peut intégrer dans son propre produit. Les partenaires et les ingénieurs utilisent souvent « SDK » pour signifier soit le SDK Anthropic soit l'Agent SDK selon le contexte. Le SDK Anthropic est un wrapper de commodité sur l'API. Il gère le boilerplate mais n'exécute pas une boucle d'agent. L'Agent SDK est le runtime géré qui exécute la boucle, la même que celle qui alimente Claude Code. Le modèle choisit un outil, l'exécute, voit le résultat et continue jusqu'à ce que la tâche soit terminée ou qu'une condition d'arrêt se déclenche. Le partenaire l'appelle à partir de son code d'application, et le SDK gère le reste. Quelle couche utiliser se résume à ce que Claude doit faire : une demande, une réponse ? Utilisez l'API ou le SDK. Outils réutilisables entre plusieurs clients ? Utilisez MCP. Claude agissant sur plusieurs tours à l'intérieur du produit du partenaire ? Utilisez l'Agent SDK. Les trois couches fonctionnent ensemble, pas les unes contre les autres.

Claude Code : couches de personnalisation et de gouvernance Choisir Claude Code est le début d'une deuxième décision : quelle personnalisation appartient à quelle couche. Une couche, dans ce contexte, est un point d'entrée de configuration discret qui contrôle un aspect de comment l'agent pense ou agit : chacun est indépendant, composable et appliqué à un point différent dans l'exécution de l'agent. Les couches se divisent en deux groupes : façonner ce que l'agent sait et fait (CLAUDE. md, compétences, sous-agents, MCP) et gouverner ce que l'agent est autorisé à toucher (Hooks, limites de permission, flux d'approbation, sandboxing et exécution restreinte). Les couches de façonnage et les couches de gouvernance sont distinctes. Obtenir cette division correcte est ce qui rend un agent à la fois utile et sûr à exécuter en production. Couches de personnalisation et de gouvernance de Claude Code CoucheQu'est-ce que cela faitQuand cela appartient ici

FAÇONNAGE : Ce que l'agent sait et fait CLAUDE. mdUn fichier markdown chargé dans le contexte au démarrage de la session. Définit les instructions permanentes, les conventions de projet et la connaissance de base que l'agent devrait toujours avoir. Contexte persistant qui s'applique à chaque tâche du projet (normes de codage, disposition du repo, conventions d'équipe). CompétencesProcessus définis en markdown que Claude Code peut invoquer à la demande plutôt que de charger à l'avance, gardant le contexte principal maigre. Flux de travail répétables que l'équipe ne devrait pas avoir à épeler à chaque fois. Les exemples typiques sont un flux de validation-push-PR, un générateur de notes de version, une procédure de migration de schéma. Sous-agentsL'agent appelant et créant des agents supplémentaires pour analyser les sections d'une tâche ou des aides de fenêtre de contexte isolées pour les tâches délimitées comme l'examen de code ou l'exploration de base de code qui encombreraient autrement le fil principal. Travail qui devrait s'exécuter avec des outils en lecture seule, un point d'entrée d'outil restreint ou un prompt système différent de la session principale. Serveurs MCPPoints d'entrée d'outils et de données externes connectés à Claude Code sur le protocole standardisé. Quand le même point d'entrée d'outil doit être réutilisable entre les clients, par exemple quand le serveur MCP Linear de l'équipe devrait aussi fonctionner à partir de Claude. ai. GOUVERNANCE : Ce que l'agent est autorisé à toucher HooksScripts qui s'exécutent sur les événements du cycle de vie de Claude Code (par exemple avant/après l'exécution d'un outil, au démarrage de la session, à l'arrêt), utilisés comme portes déterministes que l'agent ne peut pas ignorer. Portes déterministes que l'agent ne doit pas ignorer, où la garantie doit venir du code plutôt que de l'invitation. Limites de permission et flux d'approbationSix modes de permission contrôlent ce que Claude Code peut faire sans inviter. Le défaut demande avant chaque action. acceptEdits approuve les éditions de fichier et les commandes de système de fichiers courantes (mkdir, touch, rm, mv, cp, sed), bien que d'autres commandes Bash invitent toujours. Le mode plan verrouille la session en lecture seule jusqu'à ce que l'utilisateur approuve un plan. Le mode auto utilise un classificateur pour approuver les actions sûres et bloquer les risquées ; c'est une aperçu de recherche qui fonctionne sur tous les plans (activé par l'administrateur sur l'équipe et l'entreprise) et utilise par défaut l'API Anthropic comme fournisseur. Une variable d'environnement active les fournisseurs CSP. dontAsk auto-refuse tout ce qui inviterait et exécute uniquement ce que vos règles d'autorisation couvrent, ce qui le rend le mode pour CI verrouillé. bypassPermissions ignore tous les contrôles et est limité aux conteneurs ou CI uniquement. Tout environnement où le coût d'une action involontaire est non trivial. Les permissions gouvernent ce que l'agent est autorisé à toucher. Les hooks gouvernent ce qui doit se produire avant ou après une action. Sandboxing et exécution restreinteConfinement autour de l'espace de travail dans lequel Claude Code s'exécute, y compris les limites du système de fichiers, les règles de sortie réseau et les surfaces de commande limitées. Tout déploiement où une mauvaise action aurait des conséquences réelles et où les invites d'approbation seules ne sont pas un backstop suffisant. L'environnement lui-même devrait appliquer la limite, pas seulement le jugement de l'agent.

Routes de livraison CSP : où le trafic API se termine Une fois que le point d'entrée et l'interface de temps de construction sont choisis, une décision s'assoit en dessous : où le trafic API se termine ? Le même modèle Claude est disponible via quatre routes de livraison. Ce qui diffère, c'est quel compte cloud la dépense atterrit, quel système d'identité gère l'authentification, quelle région le trafic se termine et quel contrat de passation couvre le partenaire. La règle de décision n'est pas sur la capacité technique, le modèle se comporte de la même manière sur chaque route. La règle est sur ce que le partenaire s'est déjà engagé. Si le partenaire a déjà un contrat AWS à long terme, Bedrock est généralement le chemin le plus facile, la dépense d'IA tombe sous le même accord qu'il a déjà, et le système d'identité que son équipe utilise (IAM) fonctionne tel quel. La même logique s'applique à Vertex AI sur GCP et Foundry sur Azure : si le partenaire vit dans ce cloud, utilisez cette route. L'API Anthropic directe est l'appel correct quand le partenaire n'a pas de forte préférence cloud, veut les nouvelles fonctionnalités le moment où elles expédient, ou préfère garder la dépense d'IA avec Anthropic directement. Un compromis : les routes médiatisées par CSP (Bedrock, Vertex, Foundry) ont tendance à traîner l'API première partie sur les nouvelles fonctionnalités de semaines, parfois plus longtemps pour les capacités majeures. Routes de livraison CSP Route de livraisonQu'est-ce que c'est et comment le partenaire l'atteintQuand choisir

Anthropic première partieL'API Anthropic directe à api. anthropic. com, facturée par Anthropic, et authentifiée avec une clé API Anthropic. Les SDK en Python, TypeScript, C#, Java, Go, PHP et Ruby enveloppent ce point d'entrée. Le partenaire n'a pas d'engagement cloud contraignant, veut les fonctionnalités les plus récentes le jour où elles expédient, ou préfère consolider la dépense d'IA directement avec Anthropic. Choix par défaut quand aucune contrainte de passation ne tire de l'autre côté. AWS BedrockClaude servi comme modèle géré sur AWS. Appelé via l'API Messages à /anthropic/v1/messages sur l'infrastructure gérée par AWS, facturé sur le compte AWS du partenaire et authentifié via IAM. L'intégration Bedrock Runtime précédente (InvokeModel/Converse via boto3 ou le SDK AWS) reste disponible comme le chemin hérité documenté. La disponibilité régionale compte et les profils d'inférence résolvent le problème de routage inter-régions. Le partenaire a un accord AWS d'entreprise engagé, exécute le reste de sa pile sur AWS et veut que la dépense d'IA se déduise de cet engagement. L'identité, la mise en réseau et l'audit héritent tous du compte AWS existant. GCP Vertex AIClaude servi comme modèle géré dans le jardin de modèles Vertex AI de Google Cloud. Appelé via le client Anthropic Vertex ou le SDK Google, facturé sur le projet GCP du partenaire, authentifié avec les identifiants Google Cloud. Les modèles sont activés par projet dans la console du jardin de modèles. Le partenaire exécute sur GCP, le reste de sa pile ML vit dans Vertex AI et ils veulent un point d'entrée de facturation et d'audit unique entre les modèles de base. Microsoft Foundry (Azure)Claude servi via le catalogue Foundry de Microsoft sur Azure. Facturé sur l'abonnement Azure du partenaire, authentifié via Entra ID, déployé dans la région Azure du partenaire. Le partenaire a un accord d'entreprise Microsoft, exécute l'identité via Entra ID et le reste de leur empreinte cloud est sur Azure. Foundry consolide la passation d'IA sur le même papier. Remarque : Foundry offre les modèles Claude dans deux formes d'hébergement : hébergé sur Azure (généralement disponible, l'inférence s'exécute dans l'environnement Azure du partenaire ; au moment de la rédaction Opus 4. 8, Sonnet 5 et Haiku 4. 5, vérifiez la liste actuelle au moment de la publication) et hébergé sur l'infrastructure Anthropic (autres modèles, l'inférence achemine vers l'infrastructure gérée par Anthropic). Les partenaires avec des exigences strictes de résidence des données ou de conformité RGPD devraient vérifier la forme d'hébergement et la posture de conformité des modèles spécifiques qu'ils déploient avant de s'engager à cette route.

Ce qui ne change pas entre les routes. Le modèle Claude lui-même est le même indépendamment de la route. L'invitation, la stratégie d'évaluation, l'utilisation d'outils et le comportement de la fenêtre de contexte se transfèrent tous. Ce qui change, c'est le wrapper : les identifiants de modèle et les chaînes de version diffèrent entre les routes, la disponibilité régionale diffère et les fonctionnalités côté CSP qui enveloppent l'inférence (comme les profils d'inférence sur Bedrock, les déploiements de modèle dans Foundry et l'accès au jardin de modèles dans Vertex) ajoutent tous des concepts que l'architecte doit savoir existent même si l'équipe d'ingénierie du partenaire possède l'implémentation.

Compétences comme mécanisme d'intégration Les compétences sont un mécanisme d'intégration, pas seulement un emballage. Une compétence peut être attachée à une demande via le paramètre container. skills, publiée et versionnée via le point de terminaison /v1/skills et gérée sous contrôle de version comme tout autre actif déployé. Les compétences nécessitent l'outil d'exécution de code pour s'exécuter, ce qui signifie que le modèle d'intégration porte une dépendance d'environnement d'exécution en sandbox. Quand la décision d'intégration est comment une procédure réutilisable atteint Claude entre les points d'entrée, une compétence versionnée est un mécanisme à peser aux côtés de MCP et de l'utilisation d'outils directe.

Coût · Complexité · Risque Coût : Chaque point d'entrée porte un coût d'intégration non trivial. Ne choisissez pas plus d'un à moins que le cas d'utilisation du partenaire ne s'étend sur eux. Complexité : Les deux erreurs les plus courantes sont d'atteindre Claude Code sur un travail non-ingénierie et de traiter MCP comme la couche d'intégration par défaut indépendamment de si la réutilisabilité qu'il offre est nécessaire. Le point d'entrée devrait suivre le travail, pas le précéder. Risque : Dépasser le mauvais point d'entrée est coûteux, pas seulement parce que le code doit être réécrit, mais parce que les conventions et les habitudes d'utilisateur qui se sont construites autour. Recommencer sur un meilleur point d'entrée est moins cher que cela et commencer sur le bon est moins cher.

Sécurité, gouvernance et contraintes d'industrie réglementée Certaines décisions de point d'entrée ne sont pas à votre discrétion. Quand un partenaire est soumis au secret professionnel avocat-client, HIPAA, RGPD, FedRAMP ou une politique interne de résidence des données, ces contraintes éliminent les points d'entrée avant que le coût, l'ergonomie ou l'effort de construction n'entrent dans la conversation. Claude. ai est le point d'entrée que cela frappe le plus souvent. Le produit de qualité consommateur n'a pas été conçu pour satisfaire tous les exigences de gestion des données d'entreprise de la boîte. L'API et le SDK, acheminés via une passerelle approuvée par le partenaire avec la journalisation, la rétention et les contrôles d'identité dans l'infrastructure du partenaire, sont les points d'entrée qui survivent à la plupart des examens réglementés. Nommez la contrainte gouvernante quand vous recommandez un point d'entrée et laissez la contrainte éliminer les options avant les préférences. Contraintes d'industrie réglementée ContrainteQu'est-ce que cela tend à éliminerQu'est-ce qui survit généralement à l'examen

Secret professionnel avocat-clientLes niveaux de consommateur de Claude. ai pour l'examen de documents privilégiés et tout ce qui touche le matériel privilégié via une surface que le cabinet ne peut pas auditer de bout en bout. Claude pour le travail ajoute les contrôles d'administration et la journalisation d'audit, mais un cabinet doit toujours confirmer que la configuration répond à sa propre barre de gestion des privilèges avant que le matériel privilégié ne circule à travers. API ou SDK derrière l'application du cabinet et la passerelle approuvée, authentifiée via SSO, acheminée via une passerelle LLM approuvée par le cabinet qui enregistre chaque demande. Le cabinet possède la piste d'audit de bout en bout, ce sur quoi l'examen des privilèges se tourne. HIPAA (gestion PHI)Tout point d'entrée où un accord d'associé commercial n'est pas en place pour la configuration spécifique que le partenaire utilise. Un BAA qui existe pour une configuration ne s'étend pas à une autre, donc une route non couverte est éliminée même quand le partenaire détient un BAA ailleurs. API ou SDK sur une configuration couverte par BAA via la route de livraison que le partenaire utilise déjà. L'existence de BAA n'est pas suffisante parce que l'admissibilité des fonctionnalités compte. Les fonctionnalités bêta sont généralement exclues de la couverture BAA à moins qu'elles ne soient explicitement énumérées comme admissibles. RGPD et résidence des donnéesRoutes de livraison où la région d'exécution du modèle ne peut pas être épinglée et routes où les données quittent la limite géographique approuvée à n'importe quelle étape. Une route de livraison médiatisée par CSP (Bedrock ou Vertex) avec la région épinglée à une juridiction couverte et les termes DPA hérités du contrat cloud existant. Foundry est la route à vérifier ici, parce que ses garanties de résidence ne sont pas quelque chose que ce cours peut confirmer. Vérifiez la documentation actuelle de la route Foundry avant de vous fier à elle pour la résidence. FedRAMP / gouvernementTout chemin qui n'est pas sur un environnement cloud autorisé au niveau d'impact requis. Claude pour le gouvernement (C4G) pour les charges de travail civiles FedRAMP High. Bedrock GovCloud pour FedRAMP High et DoD IL4/5. Vertex Assured Workloads pour FedRAMP High et IL2. Remarque : les environnements gouvernementaux autorisés s'exécutent sur un décalage de modèle, donc les modèles Claude les plus récents atteignent GovCloud et Assured Workloads après la version commerciale. Confirmez quel modèle la route offre avant de vous engager à elle. Politique interne de résidence des donnéesRoutes en dehors de la liste de fournisseurs cloud approuvée du partenaire, indépendamment de la capacité technique sous-jacente. La route de livraison sur le CSP approuvé du partenaire. C'est de la passation, pas de l'ingénierie : la bonne route est celle que leur CIO a déjà autorisée.

Remarque : Vérifiez toujours la portée d'autorisation actuelle pour chacune des contraintes avec Anthropic avant de vous engager.

Pointeur vers l'avant Le Module 3 (IA responsable, sécurité et risque pour les architectes) va en profondeur sur la conception de garde-fou, la gestion des données et le cadre complet d'industrie réglementée. Le rôle de cette section est de faire surface la contrainte au point dans la conversation de conception où elle élimine les options, ce qui est juste ici à la décision de point d'entrée et de route de livraison.

Écran 29 : Quand Claude Code a été choisi en dehors de l'ingénierie

Attention 4 min · Points d'entrée et gouvernance

Quand Claude Code a été choisi en dehors de l'ingénierie Crochet de configurationClaude Code fait une première impression forte. Il peut exécuter des tâches d'ingénierie complexes et multi-étapes en une fraction du temps qu'un développeur passerait manuellement, et cette capacité est difficile à oublier. Le risque est que cela amène les équipes à atteindre Claude Code par défaut, même quand le travail ne l'exige pas et une intégration plus simple ou Claude seul suffirait. Le diagramme ci-dessous était une vraie remise d'un partenaire nous demandant de valider leur conception. L'architecture proposée : assistant d'opérations de banque régionale Une banque régionale voulait ce qu'elle appelait un « assistant d'opérations » pour son personnel de succursale. Le travail nécessitait de rechercher les soldes des clients, de planifier les rendez-vous et de répondre aux questions de politique. L'architecture proposée avait trois composants :

Claude Code s'exécutant sur les ordinateurs portables de succursale, avec un fichier CLAUDE. md maintenu par succursale pour encoder les conventions locales. Les serveurs MCP pour la base de données client, le système de rendez-vous et le corpus de politique, chacun exposé via le protocole standardisé. Les sous-agents gérant les vérifications de conformité sur chaque interaction, avec leur propre point d'entrée d'outil restreint.

L'annotation sur le diagramme

Claude Code sur les ordinateurs portables de succursale (CLAUDE. md par succursale)

Point d'entrée d'ingénierie pour un flux de travail opérationnelLe personnel de succursale n'exécute pas de terminaux ; le point d'entrée ne correspond pas à l'utilisateur ↓

Serveurs MCP : base de données client, système de rendez-vous, corpus de politique

MCP gagne sa place uniquement quand réutilisé entre les clientsAucun autre client Claude n'existait dans cette banque ↓

Les sous-agents exécutent les vérifications de conformité sur chaque interaction

La conformité assignée à la garantie déterministe la plus faibleLe chemin à conséquence élevée ne devrait pas s'exécuter sur les sous-agents

L'annotation en rouge sur le diagramme entier se lit : c'est un point d'entrée d'ingénierie pour un flux de travail opérationnel. Le personnel de succursale n'exécute pas de terminaux, donc le point d'entrée lui-même ne correspond pas à l'utilisateur. La conformité est un chemin à conséquence élevée et ne devrait pas s'exécuter sur les sous-agents, qui fournissent des garanties déterministes plus faibles que le code côté serveur. Le corpus de base de données client n'a pas besoin d'être exposé sur MCP juste parce que MCP était sur le menu pour le point d'entrée ; MCP gagne sa place quand le même point d'entrée d'outil est réutilisé entre les clients, et dans ce cas, il n'y avait pas d'autres clients dans la banque. L'architecture qui s'adapte au travail est une application Web personnalisée appelant l'API directement. La conformité vit dans le code côté serveur déterministe où les garanties sont explicites plutôt qu'émergentes. L'interface utilisateur est authentifiée via le SSO de la banque et s'adapte à un flux de travail bancaire plutôt qu'à un outil de développeur. Les appels d'outils sont auditées à la limite du serveur. Cette architecture était la bonne réponse dès l'écran un. Trois mécanismes de défaillance, chacun visible dans la proposition originale Le premier : le point d'entrée a été choisi avant que l'utilisateur soit nommé. Le personnel de succursale a besoin d'une interface qui s'adapte à un flux de travail bancaire, pas un outil de développeur. Cette contrainte aurait dû déterminer le point d'entrée avant toute autre décision. Le second : MCP a été porté en avant d'un projet antérieur comme une couche d'intégration par défaut. L'argument de réutilisabilité qui justifie MCP ne s'appliquait pas ici. Il n'y avait pas d'autres clients Claude dans la banque qui consommeraient le même point d'entrée d'outil. La couche de protocole payait le coût d'intégration pour une capacité que le partenaire n'avait pas besoin. Le troisième : la conformité, le chemin à conséquence la plus élevée du système, a été assignée au point d'entrée avec les garanties déterministes les plus faibles. Le modèle a été inversé. Le travail qui avait le plus besoin de certitude au niveau du code s'exécutait sur le point d'entrée le plus loin de lui. Pourquoi cela se casse ? Le choix du point d'entrée devrait suivre l'utilisateur et le travail. Atteindre Claude Code ou MCP juste parce que le dernier projet les a utilisés paie pour les capacités que le partenaire n'a pas besoin.

Écran 30 : Choisissez le point d'entrée et nommez le compromis décisif

Point de contrôle 7 min · Points d'entrée et gouvernance

Choisissez le point d'entrée et nommez le compromis décisif Pour chaque scénario de partenaire, choisissez l'option qui nomme à la fois le bon point d'entrée ET le compromis qui entraîne le choix. Un bon point d'entrée associé à la mauvaise raison n'est pas correct, le raisonnement est ce qui est testé. Un exemple travaillé est montré pour le scénario 1 ; vous complétez les scénarios 2 à 6.

Scénario 1, exemple travaillé Une équipe d'opérations non-ingénierie a besoin d'un assistant de chat sur des documents internes approuvés. Choix correct : claude. ai avec un projet, parce que le compromis décisif est l'audience : une équipe non-technique a besoin d'un point d'entrée prêt à l'emploi, pas une interface de temps de construction.

Scénario 2. Une banque régionale veut déployer un assistant d'agent de prêt qui récupère les données de compte client à partir d'un système bancaire central et génère des résumés de prêt de brouillon. La banque s'exécute sur AWS et a un accord d'entreprise existant.

A. AWS Bedrock, parce que le compromis décisif est la profondeur d'intégration : l'assistant a besoin d'un accès programmatique aux données bancaires centrales et doit s'intégrer dans l'infrastructure AWS existante de la banque. B. claude. ai Entreprise, parce que le compromis décisif est la profondeur d'intégration : la banque a besoin d'une gouvernance de produit avec SSO et contrôles d'audit. C. API directe, parce que le compromis décisif est la profondeur d'intégration : l'API directe donne le plus de contrôle sur la façon dont les demandes sont construites.

Scénario 3. Un cabinet juridique veut utiliser Claude pour aider les avocats à examiner les documents privilégiés. Le conseil général du cabinet a déterminé que tous les outils d'IA touchant le matériel privilégié doivent s'exécuter derrière l'infrastructure d'audit du cabinet.

A. claude. ai Entreprise, parce que le compromis décisif est la gouvernance/contrôle : Enterprise ajoute SSO, la journalisation d'audit et les contrôles d'administration. B. API directe ou SDK derrière l'application du cabinet et la passerelle, parce que le compromis décisif est la gouvernance/contrôle : le cabinet doit posséder la piste d'audit de bout en bout, ce qui nécessite d'acheminer via l'infrastructure que le cabinet contrôle. C. AWS Bedrock, parce que le compromis décisif est la résidence réglementaire : Bedrock fournit la gestion des données régionales qui satisfait les exigences de privilège.

Scénario 4. Une entreprise logistique mondiale veut donner au personnel d'opérations d'entrepôt un assistant Claude pour les notes de remise de quart et la complétion de liste de contrôle d'équipement. Le personnel est non-technique et travaille à partir de tablettes partagées sur le sol.

A. API directe avec une interface personnalisée, parce que le compromis décisif est la profondeur d'intégration : une construction personnalisée donne le contrôle total sur l'expérience. B. claude. ai avec un projet, parce que le compromis décisif est l'audience : le personnel non-technique a besoin d'une interface prête à l'emploi qu'il peut utiliser sans formation, et les projets fournissent le contexte partagé dont l'équipe a besoin. C. Claude Code, parce que le compromis décisif est l'audience : Claude Code s'exécute sur les tablettes et donne au personnel un accès direct aux capacités de Claude.

Scénario 5. Un réseau de santé a besoin de déployer un assistant de documentation clinique qui traite les dossiers des patients. Le réseau détient un BAA avec AWS et a confirmé que Bedrock est couvert par cet accord. Une proposition concurrente suggère d'utiliser l'API Anthropic directe avec un BAA séparément négocié.

A. AWS Bedrock, parce que le compromis décisif est la résidence réglementaire : Bedrock épingle les données à une région américaine qui satisfait HIPAA. B. API Anthropic directe avec un BAA séparément négocié, parce que le compromis décisif est la gouvernance/contrôle : l'API directe donne plus de contrôle sur la façon dont PHI circule à travers le système. C. AWS Bedrock, parce que le compromis décisif est la gouvernance/contrôle : le BAA existant du réseau couvre cette configuration, ce qui élimine le risque de conformité avant tout autre compromis. D. claude. ai Entreprise avec un BAA, parce que le compromis décisif est la gouvernance/contrôle : Enterprise ajoute la configuration prête pour HIPAA et les contrôles d'audit.

Scénario 6. Une entreprise de services financiers construit un système de commentaire commercial à haute fréquence. Le système doit générer un résumé en langage naturel court de chaque commerce dans les 400 millisecondes d'exécution. L'entreprise s'exécute sur GCP.

A. Google Vertex AI, parce que le compromis décisif est la latence : l'exigence de 400 ms exige le chemin de latence la plus basse, et Vertex AI garde le chemin de demande à l'intérieur de l'environnement Google Cloud existant du cabinet, minimisant la latence de aller-retour réseau. B. API Anthropic directe, parce que le compromis décisif est la latence : l'API directe a les versions de fonctionnalités les plus rapides et la surcharge la plus basse. C. AWS Bedrock, parce que le compromis décisif est la latence : l'infrastructure gérée de Bedrock est optimisée pour l'inférence de latence basse.

Soumettre Passer pour l'instant

Écran 31 : Un système d'examen de contrat pour un cabinet juridique de taille moyenne

Point de contrôle 7 min · Assemblage et récapitulatif

Un système d'examen de contrat pour un cabinet juridique de taille moyenne Quatre architectures complètes sont décrites ci-dessous. Chacune s'engage sur les cinq décisions de conception que le module couvrait : le point d'entrée de plateforme, le modèle, comment le travail est divisé entre Claude, les systèmes existants et les humains, la stratégie de modèle et de contexte et la posture humain dans la boucle. Un seul tient face au brief. Les trois autres semblent raisonnables mais échouent sur une seule décision. Choisissez celui que vous mettriez devant un comité d'examen côté partenaire.

Le brief Un cabinet juridique de taille moyenne de 180 avocats veut accélérer l'examen des contrats. Les associés seniors passent actuellement une estimation de 12 à 18 heures par semaine à lire les contrats de fournisseur et de partenariat pour signaler les clauses qui entrent en conflit avec le playbook standard du cabinet. La longueur moyenne du contrat est de 35 pages. La sortie actuelle est un PDF avec des marques rouges et des commentaires de marge. Le cabinet utilise iManage pour le stockage de documents, a une passerelle LLM privée approuvée par son CIO et est lié par les exigences de secret professionnel avocat-client qui excluent les outils de qualité consommateur. L'objectif est de réduire le temps d'associé par contrat de 60 % tout en gardant l'associé senior comme examinateur final.

Étape 1 : rédigez votre architecture Avant de lire les quatre options, rédigez votre propre architecture pour le cabinet juridique. En un paragraphe, couvrez les cinq décisions : le point d'entrée de plateforme, le modèle, comment le travail est divisé entre Claude et les systèmes existants, la stratégie de modèle et de contexte et la posture humain dans la boucle. Cliquez pour révéler une réponse à comparer avec votre réponse ; sentez-vous libre de demander à Claude de comparer ce que vous avez écrit avec la réponse fournie.

Votre architecture

Révélez la réponse du modèle Construisez sur l'API directe ou le SDK, intégré dans une application Web interne mince qui s'authentifie via le SSO du cabinet et achemine via la passerelle LLM approuvée. Un flux de travail parallélisé examine le contrat section par section, avec une passe d'évaluateur appliquant un schéma strict sur la sortie de clauses signalées. Claude gère l'extraction, la classification par rapport au playbook et les brouillons de marques rouges. Le playbook reste dans les systèmes du cabinet comme une source de vérité versionnée, récupérée par clause au moment de l'appel. iManage gère la récupération de document. Sonnet est le défaut avec le contexte progressif, la réflexion étendue activée par clause uniquement où un ensemble d'éval le justifie. L'associé senior signe chaque sortie, et les clauses à faible confiance sont signalées pour attention.

Étape 2 : laquelle des quatre options correspond le plus à votre conception ?

Option A. Construisez sur Claude. ai, avec les associés téléchargeant chaque contrat dans un projet qui détient le playbook comme fichiers de référence. Un flux de travail parallélisé examine le contrat section par section et agrège les clauses signalées. Sonnet est le modèle par défaut avec le contexte progressif. L'associé senior examine chaque sortie avant que quoi que ce soit n'aille à un client. Option B. Construisez sur l'API directe ou le SDK, intégré dans une application Web interne mince qui s'authentifie via le SSO du cabinet et achemine via la passerelle LLM approuvée. Le playbook est chargé dans le prompt système en intégralité sur chaque appel pour que le modèle ait toujours la norme du cabinet en contexte. Un flux de travail parallélisé examine le contrat par section et agrège les résultats. Sonnet est le défaut. L'associé senior examine chaque sortie. Option C. Construisez sur l'API directe ou le SDK, intégré dans une application Web interne derrière SSO et la passerelle approuvée. Un agent ouvert est donné le contrat et les outils iManage et laissé à décider par lui-même comment travailler à travers le document. Le playbook est récupéré par clause au moment de l'appel. Opus s'exécute sur chaque appel pour la précision maximale. L'associé senior examine chaque sortie. Option D. Construisez sur l'API directe ou le SDK, intégré dans une application Web interne qui s'authentifie via SSO et achemine via la passerelle approuvée. Un flux de travail parallélisé examine le contrat section par section, avec une passe d'évaluateur appliquant un schéma strict sur la sortie de clauses signalées. Claude gère l'extraction, la classification par rapport au playbook et les brouillons de marques rouges. Le playbook reste dans les systèmes du cabinet comme une source de vérité versionnée, récupérée par clause au moment de l'appel. iManage gère la récupération de document. Sonnet est le défaut avec le contexte progressif, la réflexion étendue activée par clause uniquement où un ensemble d'éval le justifie. L'associé senior signe chaque sortie, et les clauses à faible confiance sont signalées pour attention.

Soumettre Passer pour l'instant

Écran 32 : Glossaire

Référence·Assemblage et récapitulatif

Glossaire Les termes clés utilisés dans ce module, dans l'ordre alphabétique. Cliquez sur un terme pour développer sa définition.

Réflexion adaptativeLa réflexion étendue où le modèle lui-même, plutôt que vous, décide s'il faut penser et combien, en fonction de la complexité de chaque demande. Il peut raisonner longuement sur un problème difficile et ignorer complètement la réflexion sur un trivial. Vous le dirigez avec un niveau d'effort plutôt que de configurer un budget de token. Sur les modèles Claude actuels, c'est le contrôle recommandé, et sur les modèles les plus récents, c'est le seul. APIInterface de programmation d'application. La façon directe d'envoyer des demandes à Claude à partir de votre propre code, avec le contrôle total sur l'invitation, le modèle, les paramètres et la façon dont la réponse est gérée. Utiliser l'API signifie que vous construisez l'application environnante vous-même : l'interface utilisateur, l'historique de conversation, la gestion des erreurs, la journalisation. Le compromis est la flexibilité maximale en échange de posséder l'infrastructure autour. FaisantAutoritaire signifie la source que vous avez accepté de traiter comme correcte : le système d'enregistrement du partenaire, la table de politique en direct, la liste de prix actuelle. Quand une réponse est faisant autorité, elle provient de cette source de confiance plutôt que de la récollection du modèle, pour que vous puissiez vous tenir derrière. Claude Agent SDKUn runtime d'agent géré distribué comme le paquet @anthropic-ai/claude-agent-sdk pour TypeScript et Python. Il donne à un partenaire un accès programmatique à la même boucle d'agent qui alimente Claude Code : itération, exécution d'outils, observation, résiliation, pour que le partenaire puisse intégrer un agent à l'intérieur de son propre produit au lieu d'exécuter Claude Code dans un terminal. Distinct du SDK Anthropic, qui est un wrapper mince de commodité sur l'API et n'exécute pas une boucle d'agent. Claude CodeUn outil de codage agentic qui lit les fichiers, édite le code, exécute les commandes et exécute les tâches d'ingénierie multi-étapes sous des limites de permission configurables. Distribué comme un CLI, des plugins IDE (VS Code, JetBrains et autres), une application de bureau et un produit Web à claude. ai/code. Claude Code est le point d'entrée que les ingénieurs utilisent pour faire du vrai travail de développement, et il est personnalisable via CLAUDE. md, les compétences, les sous-agents, les hooks, les serveurs MCP et les paramètres de permission. Claude. aiLe produit de chat pour utilisateur final hébergé par Anthropic. Atteint via les applications Web, mobile et Claude Desktop. Les utilisateurs se connectent, ouvrent des conversations, téléchargent des fichiers, partagent le contexte via des projets et connectent les services externes via des connecteurs intégrés. Aucun code n'est écrit. Claude. ai est le point d'entrée pour les utilisateurs, pas les constructeurs, c'est pourquoi l'équipe d'ingénierie d'un partenaire ne consomme généralement pas Claude. ai quand intégrant Claude dans son propre produit. CorpusLe corps de documents qu'un système de récupération recherche. Un corpus pourrait être une base de connaissances, un ensemble de documents de politique, un manuel de produit ou une collection de tickets passés. Le corpus est chargé et indexé à l'avance, c'est pourquoi il fonctionne pour le matériel de référence stable et pas pour l'état en direct. Route de livraison CSPRoute de livraison du fournisseur de services cloud : le chemin que le trafic API prend pour atteindre Claude. Anthropic offre une route directe à api. anthropic. com, et les mêmes modèles Claude sont aussi disponibles via AWS Bedrock, GCP Vertex AI et Microsoft Foundry sur Azure. La route que vous choisissez détermine où la dépense est facturée, comment l'appel est authentifié, quelle région le trafic se termine et quel contrat la couvre. Cela n'affecte pas comment le modèle se comporte. Règle déterministeUne règle déterministe est une règle qui produit toujours la même sortie pour la même entrée. Même entrée, même sortie, à chaque fois, sans variation. ÉvalÉval court pour les évaluations est un ensemble de test structuré utilisé pour mesurer si un modèle fonctionne assez bien sur une tâche définie. Une éval associe les entrées aux sorties attendues ou aux critères de qualité, les exécute par rapport au modèle et produit un score que vous pouvez comparer entre les versions de modèle, les invitations ou les configurations. Les évals sont comment les équipes décident si un changement est une amélioration ou une régression avant qu'il n'atteigne la production. Réflexion étendueLa capacité où le modèle travaille à travers un problème dans un bloc de réflexion séparé avant de s'engager à une réponse finale, plutôt que de répondre en une passe. Cela aide sur les tâches où une réponse unique passerait les étapes. Les tokens de réflexion sont facturés comme des tokens de sortie et ajoutent de la latence. La quantité de réflexion qui se produit dépend du mode de contrôle : un budget de token de réflexion que vous configurez vous-même sur les modèles plus anciens, ou la réflexion adaptative (voir Réflexion adaptative) sur les modèles actuels. IDEEnvironnement de développement intégré. Une application logicielle qui regroupe un éditeur de code, un débogueur et d'autres outils en un seul endroit pour écrire et exécuter du code (par exemple, VS Code, PyCharm, Xcode). État en directLes données qui changent pendant la durée de vie d'une conversation ou d'un processus : un statut de commande, un compte d'inventaire, un prix, un créneau de calendrier, la session actuelle d'un utilisateur. L'état en direct est distinct du matériel de référence statique parce que la réponse correcte à 10h00 peut être fausse à 10h05. Les systèmes qui ont besoin de l'état en direct nécessitent une recherche directe par rapport à la source de vérité, pas un instantané stocké. MCPProtocole de contexte de modèle. Une norme ouverte qui permet à Claude de se connecter aux outils et sources de données externes via un serveur dédié, au lieu de nécessiter une intégration personnalisée pour chacun. Un serveur MCP expose les outils, les invitations et les ressources que tout client compatible MCP peut utiliser, ce qui signifie qu'une seule intégration écrite une fois peut être réutilisée entre les applications. MCP déplace le travail de construction et de maintenance des définitions d'outils hors de votre code d'application et dans les serveurs réutilisables. MonolithiqueLe contraire de progressif : tout ce que le modèle pourrait avoir besoin est chargé dans le contexte à l'avance, dans un bloc. Le contexte monolithique est plus simple à configurer et bien pour les tâches courtes et contenues, mais il grandit au fil du temps, pousse contre la fenêtre de contexte et force le modèle à assister au matériel qui peut ne pas être pertinent pour l'étape actuelle. Les déploiements de longue durée construits de manière monolithique ont tendance à se dégrader à mesure que la conversation s'accumule. ObservabilitéCapacité à voir ce que votre système fait, reconstruire pourquoi il s'est comporté d'une certaine manière et détecter quand quelque chose ne va pas. Connaissance paramétriqueLa connaissance paramétrique signifie tout ce que le modèle a appris pendant l'entraînement et porte dans ses poids (ses paramètres). C'est le modèle répondant de mémoire, sans recherche externe. Le contraire est la connaissance que le modèle tire au moment de la demande, comme un document que vous lui remettez ou un résultat de recherche Web. ProgressifUne approche où le contexte, les instructions ou les capacités sont chargés par étapes à mesure que le travail l'exige, plutôt que tout à la fois au démarrage. Le contexte progressif donne au modèle uniquement ce dont il a besoin à chaque étape, ce qui garde l'ensemble de travail concentré et le coût de chaque appel plus bas. Le modèle apparaît dans les compétences qui chargent les fichiers de référence à la demande et dans les agents qui rassemblent les informations via les appels d'outils au lieu de recevoir tout dans l'invitation initiale. Mise en cache d'invitationLa mise en cache d'invitation est une fonctionnalité qui vous permet de stocker les parties fréquemment utilisées d'une invitation, généralement une longue invitation système ou un grand document, pour que le modèle n'ait pas à les retraiter à partir de zéro sur chaque demande. La partie mise en cache est calculée une fois et réutilisée sur plusieurs appels. RécupérationRécupérer les informations pertinentes d'une source externe au moment de la demande et les remettre au modèle aux côtés de la question. Au lieu de vous fier à ce que le modèle a appris pendant l'entraînement, vous tirez le document, l'enregistrement ou le passage actuel et le mettez devant le modèle pour que la réponse soit ancrée dans cette source. SDKKit de développement logiciel. Une bibliothèque spécifique à la langue (Python, TypeScript et autres) qui enveloppe l'API dans le code idiomatique pour cette langue. Le SDK gère le formatage des demandes, l'authentification, les tentatives et l'analyse des réponses pour que vous puissiez appeler Claude avec quelques lignes de code au lieu de construire les demandes HTTP à la main. Le SDK est construit sur l'API, donc tout ce que l'API peut faire, le SDK peut le faire, avec moins de boilerplate. Quand un ingénieur dit « SDK », il peut signifier ce SDK Anthropic (un wrapper sur l'API) ou l'Agent SDK (un runtime d'agent géré) ; cependant, ce sont deux choses différentes. ExpédiablePrêt pour l'utilisation en production, pas seulement une démo fonctionnelle. La sortie expédiable répond à la barre pour la précision, la latence, le coût et la fiabilité que le déploiement exige réellement, et elle a passé les portes d'éval et d'examen que l'équipe utilise pour les changements de version. La distinction compte parce qu'un prototype qui gère le chemin heureux n'est pas la même chose qu'un système qui gère la longue traîne des entrées utilisateur réelles. TerminalUne interface basée sur le texte pour interagir avec le système d'exploitation de votre ordinateur en tapant des commandes. Aussi appelé une ligne de commande ou un shell (par exemple, Terminal sur Mac, Invite de commandes sur Windows). Utilisation d'outilsLa capacité qui permet à Claude d'appeler les fonctions, API ou services externes pendant une réponse au lieu de générer uniquement du texte. Le modèle décide quand invoquer un outil, quels arguments passer et comment utiliser le résultat dans son étape suivante. L'utilisation d'outils est ce qui transforme Claude d'un générateur de texte en un système qui peut lire les fichiers, interroger les bases de données, rechercher le Web ou prendre des mesures dans d'autres logiciels. WrapperCode qui entoure ou encapsule un autre morceau de code, une bibliothèque ou une API pour le rendre plus facile à utiliser, ajouter des fonctionnalités ou traduire entre les interfaces. Par exemple, un wrapper Python autour d'une bibliothèque C vous permet d'appeler les fonctions C comme si elles étaient natives de Python.

Écran 33 : Points clés à retenir

Récapitulatif 3 min · Assemblage et récapitulatif

Points clés à retenir

01

La décomposition est le mouvement qui vient avant l'architecture. Avant de pouvoir choisir un modèle, vous devez diviser le travail en trois seaux : ce que Claude gère, ce que vos systèmes existants gèrent et ce que les humains gèrent. La division est entraînée par comment le modèle se comporte sur chaque pièce, ce qui vous dit si une tâche appartient à Claude du tout ou quelque part ailleurs dans la pile. Les conceptions qui ignorent cette étape finissent par forcer Claude dans un travail qu'un autre système ferait à un coût inférieur ou lui demander d'opérer sans le contexte qu'un humain aurait donné à un collègue.

02

Choisir un modèle, c'est choisir combien d'autonomie accorder. L'LLM augmenté, le flux de travail et l'agent sont des points sur un spectre de « Claude assiste une étape » à « Claude planifie la séquence entière », avec quatre sous-modèles de flux de travail en dessous. La décision dépend de cinq facteurs : la prévisibilité (comment prévisible est la tâche), le coût d'erreur (combien coûterait une mauvaise réponse), l'observabilité (comment visible est le travail pendant qu'il s'exécute), la latence (combien de temps vous pouvez attendre) et le coût (combien vous pouvez dépenser par exécution). Quand le coût d'erreur est la contrainte contraignante, le coût d'erreur choisit le modèle. La contrainte la plus serrée est le facteur qui décide.

03

Atteindre les architectures de référence testées avant d'inventer les vôtres. Les cinq architectures de référence : agent, RAG, pipeline de traitement de documents (évaluateur-optimiseur), routage et agent de codage sont documentées parce que d'autres équipes ont déjà appris ce qui se casse dans chacune. Combinez-les quand différentes parties de votre système se cassent différemment et choisissez-en une quand vous êtes toujours incertain de ce que le système devra gérer. L'erreur la plus courante est d'utiliser la récupération comme substitut à l'état en direct. La récupération est construite pour les documents statiques et les instantanés obsolètes, donc ne les utilisez pas pendant une conversation qui a besoin de données en direct.

04

Choisir un modèle : commencez par Sonnet et traitez chaque échange comme une version. Sonnet est le niveau par défaut parce qu'il équilibre l'intelligence, la vitesse et le coût pour la plupart des charges de travail de production. Passer à Opus ou Haiku est une décision délibérée qui a besoin de la même porte que tout autre version : un ensemble d'éval qui définit ce que « mieux » signifie, et un critère de restauration fixé avant l'échange, pas après. Le même principe s'applique au contexte. Le contexte progressif, où le modèle reçoit uniquement ce dont il a besoin à chaque étape, tient mieux sur un déploiement de longue durée que le contexte monolithique qui charge tout à l'avance et grandit jusqu'à ce qu'il se casse.

05

Choisissez le point d'entrée par le travail qu'il doit faire, pas par ce qui est déjà sur l'étagère. Claude. ai, l'API directe, le SDK, Claude Code et MCP portent chacun un compromis central différent : la vitesse de configuration par rapport à la profondeur du contrôle, l'interface utilisateur pré-construite par rapport à l'intégration personnalisée, la largeur des outils par rapport à la concentration. La bonne recommandation est celle où vous pouvez nommer le compromis à haute voix au moment où vous le faites. Nommer le compromis à haute voix quand vous recommandez le point d'entrée est ce qui vous dit, plus tard, quand changer.

Sources

Anthropic Skilljar, Claude 101 : famille de modèles (Opus, Sonnet, Haiku), points d'entrée Claude. ai et API. Anthropic Skilljar, Claude Code 101 en action : pile de personnalisation Claude Code, CLAUDE. md, sous-agents, MCP, compétences. Anthropic Skilljar, Fondations de fluidité IA : cadre des quatre propriétés, Next Token Prediction, Knowledge, Working Memory, Steerability. Anthropic Skilljar, Construire avec l'API Claude : RAG, chunking, récupération hybride, utilisation d'outils, réflexion étendue, évaluation.

Écran 34 : Félicitations ! Vous avez complété ce module avec succès.

Module complet · Architecte · 2 min Félicitations ! Vous avez complété ce module avec succès. Le module 1 établit les décisions de plateforme sur lesquelles chaque choix d'architecte en aval dépend. Vous avez travaillé à travers la sélection de modèle, l'architecture d'invitation, la conception d'outils et les compromis qui connectent chaque couche au cas commercial. Les décisions que vous prenez à la couche de plateforme définissent le plafond pour tout ce qui est construit au-dessus.

0 de 0 points de contrôle réussis

M1

Plateforme Claude et conception de solutions Sélection de modèle, architecture d'invitation, conception d'outils et compromis de couche de plateforme.

Vous êtes ici

M2

Intégration d'entreprise et production Modèles de déploiement, architecture d'intégration et fiabilité de production.

Suivant

M3

IA responsable, sécurité et risque Cadres de sécurité, identification des risques et pratiques de gouvernance.

M4

Engagement des parties prenantes, cycle de vie et mise sur le marché Communication des parties prenantes, gestion du cycle de vie et stratégie de mise sur le marché.

M5

Habilitation des équipes et productivité opérationnelle Configuration des outils d'équipe et pratiques de support opérationnel.

Examiner le module Recommencer