Intégration Entreprise & Production

Screen 1: Orientation: ce que vous serez capable de faire à la fin

MODULE SHELL 2 MIN Orientation: ce que vous serez capable de faire à la fin

Le Module 1 a introduit les concepts architecturaux. Ce module approfondit les spécificités.

Ce module vous donne les outils spécifiques qui distinguent un prototype d'un système de production : une porte de qualité avant de construire, un modèle de coût et de fiabilité avant de déployer, un cadre de faisabilité avant de s'engager, une architecture d'intégration qui survit à l'examen de sécurité, et une méthode d'expérimentation qui vous dit si les changements fonctionnent réellement.

À la fin de ce module, vous serez capable de :

1 Définir les critères de succès et construire une suite d'evals avant d'écrire la première ligne de code de production, en distinguant les evals basées sur le modèle des evals basées sur le code, en sélectionnant les étapes du flux de travail des evals, et en utilisant les evals comme mécanisme de contrôle pour tout changement apporté à un système de production. 2 Parcourir la liste de contrôle POC-to-production, en mappant le coût et la latence à un budget, en spécifiant les modèles de fiabilité (retries, fallbacks, circuit breakers), en nommant les modes de défaillance pour l'architecture choisie, et en articulant l'atténuation pour chacun, y compris comment rendre les agents (systèmes qui utilisent des outils, raisonnent sur plusieurs tours, et prennent des actions multi-étapes) fiables en production. 3 Créer un cas d'usage en estimant le volume d'appels, la consommation de tokens, et le coût, évaluer la faisabilité technique par rapport aux quatre propriétés IA du module Capacités et Limitations de l'IA, et traduire un problème métier en une architecture de solution délimitée avec des conditions limites explicites. 4 Architecturer un déploiement Claude prêt pour l'entreprise en spécifiant les modèles d'intégration pour la conformité (contraintes des secteurs réglementés, couverture BAA, résidence des données), l'identité (SSO/OAuth), l'autorisation, la gestion des données, et l'instrumentation d'observabilité. Placer le bon point d'intégration (API, SDK, MCP, Claude Code) à chaque point d'intégration. 5 Planifier et interpréter un test A/B ou une expérience structurée sur un système Claude en direct, en définissant l'hypothèse, en sélectionnant les métriques, en estimant la taille d'échantillon requise, et en lisant un résultat sans surestimer.

Ce module suppose une solide expérience des systèmes et s'appuie directement sur le Module 1. Il ignore les concepts fondamentaux et approfondit les décisions qui distinguent un prototype d'un système de production.

DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

We built this Architect course Module 2: Enterprise Integration & Production to help you get real work done with Claude. Treat it as educational content. It doesn't constitute legal, financial, or other professional advice, so adapt what you learn to your own situation. Our products and services evolve quickly, so certain content may contain errors or be outdated; remember to verify on Anthropic's website or docs. Examples and scenarios used in the course are illustrative and often fictitious. If the course material mentions a company or product, it doesn't mean Anthropic endorses them, they endorse Anthropic, or that we're affiliated. Also note your use of Anthropic products and services is covered by our terms, policies and documentation; if anything in this course conflicts with them, they control.

Screen 2: Evals as acceptance criteria: building quality into the build process

TeachingEvals17 min Evals as acceptance criteria: building quality into the build process Dans le premier module, vous avez pris des décisions architecturales : les modèles, les points d'intégration, et comment votre système devrait répondre à différentes entrées. Ce que vous n'avez pas encore, c'est la confiance que ces décisions tiennent quand les entrées sont réelles et les utilisateurs imprévisibles. C'est là que les evals entrent en jeu. Evals est l'abréviation d'évaluations, et elles vous permettent de tester le comportement de votre système avant qu'il ne soit mis en production ou après les mises à jour du modèle, afin que vous découvriez les problèmes avant qu'ils ne se produisent. Cette section explique ce que sont les evals, pourquoi elles sont importantes, et comment les utiliser pour devancer les problèmes avant que vos utilisateurs ne les trouvent pour vous.

Evals avant le code : pourquoi l'ordre est important Une eval, ou évaluation, est un test structuré qui vérifie si votre système retourne la sortie attendue et exacte. Bien que cela semble simple, le moment est extrêmement important. L'approche standard est de construire le système, de voir s'il semble correct, et de mener des tests plus tard. Ce n'est pas toujours la meilleure approche. Écrire votre suite d'evals avant d'écrire le code de production force trois choses à se produire qui sont autrement faciles à repousser :

Premièrement, énoncez ce que le succès signifie en termes mesurables Deuxièmement, exposez les hypothèses de conception tôt, quand les changer est encore bon marché Troisièmement, donnez-vous une porte qui peut déterminer si un échange de modèle, un changement de prompt, ou une nouvelle stratégie de récupération a mesurément amélioré le système

Une suite d'evals appartient au début de votre construction, définie avant que le code de production ne soit écrit, plutôt qu'à la fin comme étape d'assurance qualité. En fait, si vous ne pouvez pas écrire une eval pour un comportement, alors vous n'avez aucun moyen fiable de mesurer si ce comportement est présent. Cela signifie que chaque changement que vous apportez au système n'est pas vérifiable. L'ajout d'une suite d'evals au début vous permet de vérifier tout au long de la construction entière.

Comment le flux de travail des evals s'exécute : de la définition de la tâche au résultat Un flux de travail d'eval bien construit s'exécute séquentiellement à travers les étapes ci-dessous. Chaque étape produit un artefact qui alimente l'étape suivante :

ÉtapeQue se passe-tSortie

• Définir la tâcheÉnoncez le comportement que vous évaluez en termes spécifiques et mesurables, et écrivez le prompt que vous utiliserez pour le tester. Une définition vague produit une eval vague. Le niveau de concrétude de la spécification comportementale et du prompt est ce qui rend le résultat significatif. Spécification de tâche avec prompt à tester et critères de réussite
• Construire l'ensemble de données dorésAssemblez les entrées que votre système rencontrera, y compris les cas limites et les contre-exemples. Cet ensemble de données est ce contre quoi votre eval s'exécute. Si l'ensemble de données n'est pas représentatif, alors les scores ne sont pas significatifs. Ensemble de données étiqueté avec résultats attendus
• Exécuter les vérifications automatiséesPassez chaque prompt à travers le système et comparez la sortie par rapport à votre résultat attendu. Les vérifications automatisées sont rapides et bon marché. Utilisez-les pour les comportements qui sont sans ambiguïté : conformité de format, validation de schéma, et recherches factuelles par rapport à des données faisant autorité. Enregistrement de réussite/échec par élément
• Évaluer avec un jugesPour les comportements qui nécessitent une interprétation, tels que le ton, l'exactitude du raisonnement, et l'appropriatesse des réponses aux cas limites, un juge basé sur un modèle peut évaluer les sorties à l'échelle. Score par élément avec raisonnement
• Interpréter et agirLes scores agrégés vous disent où se trouve le système et si un changement l'a déplacé dans la bonne direction. Un changement qui augmente le score moyen tout en dégradant silencieusement les performances sur les cas limites ou les entrées adversariales ne rend pas le système meilleur. Score global, ventilation par catégorie

Evals basées sur le modèle vs. evals basées sur le code : quand utiliser chacune Tous les comportements que vous devez évaluer ne peuvent pas être vérifiés de la même manière. Certains comportements ont une seule bonne réponse : la sortie est soit un JSON valide, soit elle ne l'est pas. Une deuxième catégorie est de savoir si la sortie correspond au ton ou au style de langage attendu. Ces deux catégories de comportement ont besoin d'outils d'évaluation différents, et choisir le bon pour un comportement donné est important pour assurer l'exactitude et économiser les coûts. Les trois types d'evals ont des compromis différents entre vitesse et flexibilité :

Les evals basées sur le code exécutent des vérifications déterministes en millisecondes et coûtent presque rien. Les evals basées sur le modèle utilisent un juge modèle pour évaluer les sorties qui nécessitent une interprétation et coûtent à peu près autant que l'appel du modèle lui-même. Les evals d'examen humain s'appuient sur le jugement humain pour les comportements à enjeux élevés ou nouveaux où ni le code ni un juge modèle ne peuvent être fiables pour évaluer de manière fiable. Les evals d'examen humain sont l'option la plus lente et la plus coûteuse.

Type d'evalComment ça marchQuand l'utiliserCoûtLimitation

Eval basée sur le codeUne fonction vérifie la sortie par programmation : validation de schéma, correspondance regex, analyse JSON, vérification de longueur, assertion par rapport à des données faisant autorité. Tout comportement qui est sans ambiguïté. Conformité de format, correction de schéma, exactitude de recherche, contraintes de longueur. Très bas : millisecondes par vérification, pas d'appel API. Ne peut pas évaluer les comportements qui nécessitent une interprétation. Le ton, l'utilité, la qualité du raisonnement, et l'appropriatesse des cas limites nécessitent tous un jugement qu'une fonction ne peut pas fournir. Eval basée sur le modèleUn juge modèle reçoit le prompt original, la sortie du système, et une rubrique de notation. Le juge retourne un score et un raisonnement. Le prompt du juge est lui-même un prompt qui doit être ingéniérisé et testé. Tout comportement qui nécessite une interprétation : qualité de réponse, suivi des instructions, exactitude du raisonnement, sécurité, et gestion des entrées ambiguës. Moyen à élevé : un appel API par élément évalué, au taux par token du juge modèle à l'échelle, cela s'accumule. Les juges modèles peuvent être incohérents dans les cas limites. Sans forcer le juge à produire un raisonnement aux côtés du score, cette incohérence est difficile à détecter Examen humainUn évaluateur humain lit la sortie et la note par rapport à une rubrique ou un ensemble de critères. Cela peut être structuré (une feuille de notation) ou non structuré (annotations ouvertes et retours d'information). Comportements à enjeux élevés ou nouveaux où ni une fonction ni un juge modèle ne peuvent être fiables : cas limites critiques pour la sécurité, nouvelles zones de capacité sans rubriques établies, ou toute sortie où une mauvaise évaluation porte un risque significatif. Aussi utile pour calibrer et valider les evals basées sur le modèle. Élevé : le temps humain est la ressource la plus coûteuse, et le débit est limité. Pas viable à l'échelle sans échantillonnage. Lent, coûteux, et non évolutif au-delà des sous-ensembles échantillonnés. Les évaluateurs humains introduisent également leur propre incohérence.

L'échelle de notation : choisir comment noter Tous les comportements ne doivent pas être notés de la même manière, et le choix de la méthode de notation suit une échelle délibérée. Cherchez d'abord la méthode la moins chère et fiable et montez seulement quand le comportement l'exige.

Notation basée sur le code, partout où le comportement le permet. Les vérifications déterministes, y compris la validation de schéma, la correspondance exacte, la longueur, et la présence, s'exécutent en millisecondes, coûtent presque rien, et ne dérivent jamais. Si un comportement peut être vérifié en code, alors il devrait l'être. LLM-as-judge, quand le comportement a besoin d'interprétation. Utilisez un juge modèle pour les sorties qui nécessitent un jugement. Rendez le jugement rigoureux en utilisant des rubriques détaillées, des verdicts contraints (un petit ensemble fixe d'étiquettes plutôt que des scores en forme libre), l'étalonnage par rapport à des exemples étiquetés par l'homme, et la notation avec un modèle différent de celui dont vous évaluez les sorties, pour éviter l'auto-préférence. Notation humaine, en dernier recours. Réservez l'examen humain aux comportements à enjeux élevés ou nouveaux où ni le code ni un juge étalonné n'est fiable pour le moment. C'est l'option la plus coûteuse et la moins évolutive.

Étalonnage du juge : l'étape que de nombreuses équipes ignorent Un juge LLM est lui-même un système qui peut se tromper. Avant de faire confiance à ses verdicts, assurez-vous de l'étalonner. Pour ce faire, exécutez-le par rapport à un ensemble de sorties étiquetées par l'homme et confirmez que sa similarité avec le jugement humain est suffisamment élevée pour s'y fier. Un juge non étalonné produit des scores confiants qui peuvent ne pas être de haute qualité du tout. C'est pire que pas de notation automatisée, car cela semble fiable.

Favorisez le volume par rapport à la perfection. De nombreux cas automatiquement notables battent une poignée de cas notés manuellement : une couverture large et bon marché détecte plus de régressions qu'un petit ensemble laborieux, et elle peut s'exécuter sur chaque changement.

Définir les critères de succès : transformer une exigence métier en un seuil mesurable Une exigence métier comme « résumer les réclamations avec exactitude » ne vous dit pas vraiment ce qu'il faut mesurer. Le processus de transformation en critère d'eval a les étapes suivantes :

Identifiez le comportement spécifiquement : « Résumer les réclamations avec exactitude » devrait être mis à jour en « extraire le nom du déclarant, le numéro de réclamation, la date de l'incident, et le montant réclamé de chaque document ». Définissez le seuil : Décidez ce qui compte comme réussite. Si, par exemple, vos seuils sont 100% de précision sur les champs structurés, un taux d'hallucination inférieur à 2%, et une réponse dans le schéma 99,5% du temps, ces chiffres devraient provenir de l'exigence métier. Ne choisissez pas simplement ce que votre premier prototype se trouve à réaliser ; trouvez des conseils sur la définition des seuils d'eval sur platform. claude. com/docs/en/test-and-evaluate/develop-tests. Identifiez les modes de défaillance : Continuant avec le même exemple, une sortie qui pourrait ne pas être acceptable peut inclure un faux numéro de réclamation, une date d'incident manquante, ou une valeur de la mauvaise réclamation. Chaque mode de défaillance est une catégorie dans votre ensemble de données d'eval. Incluez les entrées adversariales : Il devrait inclure des documents avec des champs manquants, des sections manuscrites, un formatage inhabituel, et des mises en page non standard. Si votre ensemble de données doré ne contient que des entrées propres, alors vos scores d'eval ne prédisent pas les performances de production.

Evals comme mécanisme de contrôle pour le changement Chaque changement apporté à un système Claude de production, qu'il s'agisse d'un échange de modèle, d'une révision de prompt, d'un changement de stratégie de contexte, ou d'une mise à jour de configuration de récupération, devrait s'exécuter à travers la suite d'evals pendant le développement avant de passer à la production. C'est le seul moyen fiable de savoir si un changement a amélioré le système. Un ensemble d'eval à tour unique ne vous dira pas comment le système se maintient dans une conversation. Les evals multi-tours sont une catégorie séparée qui note le système sur une séquence d'échanges plutôt que sur un seul prompt et réponse. Une eval multi-tours vérifie quelques critères : si le système garde le contexte antérieur droit sur les tours, si elle répond à un prompt de suivi sans inventer des détails qui n'ont jamais été dits plus tôt dans la conversation, et si la qualité de sortie se maintient à mesure que la conversation s'allonge. Parce que l'unité notée est une conversation entière, cette catégorie a besoin de son propre ensemble de données doré. Cela consiste en des transcriptions de conversation complètes avec des réponses de haute qualité connues à chaque tour, couvrant les suivis, les changements de sujet, et les longueurs de conversation que le système verra en production. Considérez une équipe construisant un flux de travail de résumé de document qui a révisé son prompt de résumé mais n'a pas mis à jour sa suite d'evals pour correspondre. La suite d'evals a réussi tous les contrôles requis. Deux jours après le passage en production, les rapports de terrain ont montré que les phrases juridiques multi-clauses étaient tronquées en résumés. La cause première était que l'ensemble d'eval prédatait le changement de prompt et ne correspondait pas au comportement qui avait changé. En bref, vous devriez exécuter les evals avant chaque changement pour garder l'ensemble d'eval actuel avec le système qu'il mesure.

Coût · Complexité · Risque Coût : Chaque eval basée sur le modèle est un appel API. Bien que le coût soit à garder à l'esprit, ne le laissez pas vous pousser vers un ensemble d'eval plus petit que votre cas d'usage ne le justifie. Le plus grand risque est la sous-évaluation : un changement qui casse la production qui glisse à travers une suite d'eval sous-dimensionnée coûte beaucoup plus que quelques appels API supplémentaires. Dimensionnez votre ensemble de données par rapport à ce qui vous donne confiance dans vos résultats et traitez le coût comme une contrainte secondaire. Complexité : L'infrastructure d'eval ajoute un système parallèle à maintenir. L'ensemble de données doré doit être tenu à jour, les prompts de juge doivent être ingéniérisés et testés, et les seuils de réussite doivent être revisités quand les exigences du système changent. Où aller ensuite : Pour les modèles d'implémentation fonctionnels, y compris une procédure pas à pas des conceptions de notation et de comparaison de réponses dorées, voir les Claude Cookbooks sur github. com/anthropics/claude-cookbooks/blob/main/misc/building_evals. ipynb. Risque : Une suite d'evals obsolète fournit une fausse confiance. Elle crée l'impression trompeuse qu'un changement est sûr quand les vérifications mesurent un comportement qui n'existe plus dans le système. Le moment de plus grand risque pour une régression est quand les evals sont présentes et obsolètes.

Screen 3: The eval suite that measured the wrong thing

Watch OutEvals5 min La suite d'evals qui a mesuré la mauvaise chose

Pourquoi cette erreur se produit Quand une démo fonctionne, la déclarer « assez bonne » semble être un appel raisonnable. Les vérifications manuelles prennent du temps, et le système semble répondre correctement à chaque entrée testée. Ce qui rend cela problématique est que les équipes ne peuvent tester que les entrées auxquelles elles ont pensé, tandis que la production expose le reste.

Un post-mortem de partenaire qui doit être reconstruit Ce qui suit est un composite d'un post-mortem représentant un modèle qui apparaît à plusieurs reprises dans les déploiements sur le terrain. L'équipe a construit un assistant d'examen de contrats pour un cabinet de services professionnels. Ils ont testé manuellement l'assistant par rapport à dix contrats que leur équipe connaissait bien, ont déclaré le système prêt, et ont ensuite passé à la production. La régression est arrivée deux semaines plus tard.

Ce que le post-mortem a trouvé Le système échouait sur une classe de contrats sur laquelle il n'avait jamais été testé, à savoir ceux avec des structures d'obligations non standard. Le modèle extrayait les obligations de la mauvaise section. La suite d'evals existait. Elle avait été construite au début du projet et avait été construite à partir des dix contrats que l'équipe utilisait pendant le développement. Ce n'était pas un échantillon représentatif de la population complète de contrats. Quand le prompt a changé, la suite d'evals a continué à réussir, mais seulement parce que l'ensemble de données doré reflétait toujours les résultats attendus du vieux prompt. Il n'avait jamais été mis à jour pour tenir compte du nouveau comportement.

Les décisions qui nous ont menés ici

L'ensemble de données d'eval a été construit à partir d'entrées pratiques plutôt qu'un échantillon représentatif. Une suite d'evals qui ne couvre pas la distribution d'entrée qu'elle affrontera en production mesure un système différent de celui que vous expédiez. L'ensemble d'entrée d'eval n'a pas été mis à jour après le changement de prompt. L'eval réussissait toujours à chaque fois parce qu'elle évaluait un comportement que le prompt ne produisait plus. Les scores semblaient stables parce que rien ne testait ce qui avait changé. Les vérifications manuelles ont été traitées comme un substitut d'eval. Les vérifications ponctuelles peuvent confirmer qu'une entrée spécifique produit une sortie spécifique, mais elles ne peuvent pas vous dire si le système se comporte correctement sur des entrées inconnues.

Ce qu'il faut surveiller La suite d'evals était présente mais mal configurée de deux façons : l'ensemble de données n'était pas représentatif, et il n'était pas tenu à jour. Les deux problèmes sont invisibles jusqu'à ce que la production expose l'écart. Le système semblait sain en développement parce qu'il n'était testé que sur des entrées pour lesquelles il était déjà optimisé.

Screen 4: Sort the eval types

CheckpointEvals5 min Trier les types d'evals Huit tâches d'évaluation sont énumérées ci-dessous. Faites glisser chacune dans le compartiment auquel elle appartient : eval basée sur le modèle ou eval basée sur le code. Le bon placement suit si le comportement vérifié nécessite une interprétation ou est simple.

• Vérifier que chaque réponse est un JSON valide correspondant au schéma de sortie défini.
• Évaluer si le raisonnement du modèle dans une analyse complexe est solide et complet.
• Vérifier que la longueur de la réponse est inférieure à 500 tokens.
• Noter comment le système gère de manière appropriée une réclamation client chargée émotionnellement.
• Confirmer que le numéro de réclamation extrait correspond à la valeur quantitative dans le document source.
• Évaluer si le résumé capture les points les plus importants d'un long document d'information.
• Vérifier que toutes les sections requises (résumé exécutif, méthodologie, résultats, recommandations) sont présentes dans la sortie.
• Évaluer si le ton d'un message destiné aux clients est approprié professionnel pour la marque.

Eval basée sur le code

Eval basée sur le modèle

Vérifier les réponses Ignorer pour l'instant

Screen 5: From POC to production: cost, latency, and reliability

TeachingPOC to Prod16 min Du POC à la production : coût, latence et fiabilité Votre suite d'evals vous dit si le système se comporte correctement, mais rien sur la question de savoir s'il peut se permettre de se comporter correctement au volume que votre partenaire attend. Cet écart est l'écart POC-to-production, et il a quatre dimensions : coût, latence, fiabilité, et modes de défaillance. Les quatre sont invisibles dans une démo. Un POC vous donne également le premier signal sur la question de savoir si le système déplace la métrique métier qu'il a été conçu pour améliorer. Ce signal vaut la peine d'être capturé délibérément : mesurez le résultat que le partenaire se soucie sur votre échantillon POC, même avant de modéliser le coût de production. Un profil de coût qui s'adapte au budget sur un système qui ne produit pas une amélioration mesurable dans la métrique qui compte est toujours un déploiement échoué.

Où un Proof of Concept (POC) et un système de production diffèrent Un POC est conçu pour démontrer la capacité. Il s'exécute à faible volume, sur des entrées propres, et avec un utilisateur patient. Un système de production s'exécute au volume que l'entreprise de votre partenaire génère, sur des entrées réelles, et avec des utilisateurs qui n'ont aucune tolérance pour les réponses lentes ou incorrectes. Les quatre dimensions où un POC vous induit en erreur sont le coût, la latence, la fiabilité, et les modes de défaillance.

DimensionPourquoi c'est invisible dans une démoComment ça ressemble quand ça échoue

CoûtUn POC exécutant 10–50 requêtes par jour produit une facture négligeable. Les projections de coût mensuel au volume de production sont un calcul différent. Le tableau de bord de facturation montre un coût qui dépasse le budget approuvé à l'approbation du projet. L'architecture doit être renégociée après le déploiement. LatenceUne démo s'exécute généralement une requête à la fois. La latence p95 sous charge concurrente est un nombre différent de la latence médiane sous une seule requête. Les violations d'accord de niveau de service et l'abandon des utilisateurs. La latence qui est acceptable pour une démo peut être inacceptable pour un flux de travail orienté utilisateur en temps réel. FiabilitéUn POC n'a pas de logique de retry, pas de fallback, et pas de circuit breaker. Quand il échoue, le développeur actualise et réessaie. Il n'y a pas d'utilisateurs qui attendent. Sans logique de retry ou gestion de fallback, toute défaillance API transitoire fait tomber le flux de travail orienté utilisateur entier plutôt que de se dégrader gracieusement. Modes de défaillanceUne démo est testée sur des entrées que le développeur attend. La production soulève des entrées que le développeur n'attendait pas. Les modes de défaillance sont spécifiques au type d'architecture. Dégradation silencieuse, sorties inventées sur les entrées de cas limites, ou défaillance complète sur une classe d'entrée qui n'a jamais été testée.

Modélisation du coût et de la latence : connaître les chiffres avant de construire Le modèle de coût et de latence est construit avant de finaliser l'architecture. Les trois entrées dont vous avez besoin sont le volume d'appels (requêtes par jour ou par mois), le budget de tokens par requête (tokens d'entrée plus tokens de sortie attendus), et le niveau de modèle. À partir de ces trois, vous pouvez estimer le coût mensuel et le vérifier par rapport à votre plafond budgétaire avant que du code ne soit écrit. Le budget de tokens par requête est l'endroit où la plupart des modèles de coût se trompent. Les équipes calculent le nombre de tokens moyen sur les entrées qu'elles ont et supposent que c'est la distribution. En pratique, les distributions de tokens sont souvent asymétriques : la plupart des requêtes sont courtes, mais une queue de requêtes longues consomme une part disproportionnée du coût total. Un modèle de coût basé sur l'utilisation moyenne peut considérablement sous-estimer l'impact de coût de ces requêtes plus longues, souvent d'un facteur de deux ou trois. La latence suit un modèle similaire. La latence médiane reflète le milieu du peloton, mais les violations d'accord de niveau de service sont généralement causées par des requêtes plus lentes à l'extrémité supérieure. C'est pourquoi p95 est une cible de conception plus utile que la médiane. P95 est la valeur de latence en dessous de laquelle 95% des requêtes se terminent. Seulement les 5% les plus lents tombent au-dessus. La mise en cache est le levier de coût et de latence le plus efficace quand le prompt système est long et stable. La mise en cache des prompts préserve le préfixe de prompt traité pour les tokens mis en cache, de sorte que l'API ne les retraite pas sur les requêtes suivantes. Les économies s'échellent à la fois avec la longueur du préfixe mis en cache et la fréquence de sa réutilisation. Si, par exemple, les lectures de cache sont facturées à 10% du taux de token d'entrée standard, un long préfixe réutilisé sur de nombreuses requêtes produit les plus grandes économies effectives. Trouvez le taux de lecture de cache le plus actuel sur platform. claude. com/docs/en/about-claude/pricing. Le risque est la cohérence : si le contenu mis en cache doit refléter l'état en direct, la mise en cache crée une fenêtre de cohérence qui peut violer les exigences du cas d'usage. Ce qui est stocké est le préfixe de prompt.

Contrôles de fiabilité : ce qu'il faut construire dans chaque appel de modèle Les contrôles de fiabilité qui appartiennent au système Claude de production adressent différents scénarios de défaillance et se situent à différentes couches de la pile d'appels.

Récupération d'erreur transitoire avec backoff exponentiel. Quand un modèle retourne une erreur transitoire, telle qu'une limite de débit 429, un délai d'attente, ou un 5xx, le système devrait réessayer avec des délais progressivement plus longs entre les tentatives. Cela empêche une inondation de retries de transformer un bref hoquet en une panne prolongée. Définissez le nombre maximum de tentatives et le temps d'attente total en fonction de la durée que votre cas d'usage peut tolérer. Chaînes de fallback. Si le modèle primaire ou le point de terminaison est indisponible, le système devrait automatiquement acheminer la requête vers une alternative telle qu'un niveau de modèle différent ou une réponse mise en cache. Il ne devrait pas lever une erreur à l'utilisateur. Le comportement de fallback devrait être testé dans le cadre de votre suite d'evals. Circuit breakers. Un circuit breaker mesure le taux d'erreur sur une dépendance en aval et se déclenche quand les erreurs dépassent un seuil établi. Une fois déclenché, les requêtes échouent immédiatement plutôt que d'attendre un délai d'attente. Cela empêche une dépendance dégradée de faire tomber le système plus large.

Les contrôles de fiabilité doivent se situer à la bonne étape pour être efficaces : les nouvelles tentatives appartiennent près de l'appel API, les circuit breakers à la limite du service, et les chaînes de fallback dans la couche d'orchestration. Les placer dans la mauvaise couche signifie protéger la mauvaise partie du système et laisser la bonne partie exposée.

Modes de défaillance par type d'architecture Les agents gèrent les tâches qui ne peuvent pas être complétées en un seul appel de modèle : ils peuvent utiliser des outils, observer les résultats, ajuster les plans en cours d'exécution, et compléter les processus multi-étapes qui nécessitent un raisonnement dynamique à chaque étape. Claude Code est un exemple de production, et il navigue dans les bases de code, exécute les tests, applique les correctifs, et itère sur un flux de travail qui est impossible dans une architecture à tour unique. Les contrôles ci-dessous régissent comment construire ces systèmes de manière fiable.

ArchitectureQue casse en premierAtténuation

AgentUtilisation d'outils illimitée et contexte croissant. Un agent qui peut appeler des outils sans contraintes budgétaires ou limites de tours exécutera le coût et la latence de manière invisible jusqu'à ce qu'une seule requête dépasse le plafond budgétaire. Définissez les budgets de tokens par tour, les nombres d'appels d'outils maximums, et les critères d'arrêt explicites. Limitez l'ensemble d'outils au minimum requis. Évaluez le comportement d'arrêt de l'agent, pas seulement la qualité de sa sortie. RAG (retrieval-augmented generation)Dérive de la qualité de récupération. La couche de récupération se dégrade quand les documents sont ajoutés ou supprimés de l'index sans réindexation, quand la requête et la représentation du document se désalignent, ou quand l'index est actualisé selon un calendrier qui crée une obsolescence pour les requêtes d'état en direct. Gardez la qualité de récupération dans la boucle d'eval. Surveillez la précision et le rappel de récupération comme métriques système, pas seulement la qualité de sortie. Séparez les requêtes d'état en direct des requêtes de connaissance statique. Pipeline de traitement de documents (Evaluator-optimizer)Pas de chemin d'exception pour les extractions de faible confiance. Un pipeline qui achemine tous les documents à travers le même flux indépendamment de la confiance d'extraction produira des sorties incorrectes sur les cas limites au même taux qu'il produit des sorties correctes sur les documents propres. Ajoutez la notation de confiance à l'étape d'extraction. Acheminez les extractions de faible confiance vers une file d'attente d'examen humain plutôt que vers le traitement en aval. Incluez les cas limites et les documents difficiles dans votre ensemble d'eval. Orchestrator-workersLes limites de défaillance entre les orchestrateurs et les sous-agents s'estompent, les traces se fragmentent, et un sous-agent supprimé peut échouer silencieusement à la synthèse. Définissez les limites récupérables (sous-agent : retry ou flag) par rapport aux limites irrécupérables (orchestrateur). Créez un ID de trace partagé sur tous les agents. Réconciliez la couverture à la synthèse afin que les résultats égalent les unités soumises.

Coût · Complexité · Risque Coût : Ne supposez pas que vos coûts de preuve de concept correspondront à la production. Modélisez les coûts avant de vous engager dans une architecture, plutôt qu'après le premier cycle de facturation. Complexité : Les retries, les chaînes de fallback, et les circuit breakers sont beaucoup plus difficiles à ajouter à un système qui n'a pas été conçu pour eux. Construisez la fiabilité dès le départ plutôt que de vous précipiter pour la corriger après le premier incident de production. Risque : Un système sans fallback et sans circuit breaker a un point de défaillance : le point de terminaison du modèle primaire. Quand ce point de terminaison tombe en charge de pointe, il n'y a pas de chemin de récupération, le flux de travail orienté utilisateur entier échoue au lieu de se dégrader gracieusement.

Épinglage de version de modèle Remarque : L'épinglage de version de modèle s'applique à chaque architecture du tableau ci-dessus de manière égale. C'est une discipline opérationnelle, pas un choix d'architecture. Épinglez les versions de modèle dans votre configuration, surveillez la page de dépréciation du modèle Anthropic sur platform. claude. com/docs/en/about-claude/model-deprecations, et maintenez un runbook de mise à jour de version.

Screen 6: The demo cost profile that became the production bill

Watch OutPOC to Prod5 min Le profil de coût de démo qui est devenu la facture de production

Pourquoi cette erreur est facile à faire Un POC est construit pour prouver la capacité. Il n'est pas conçu pour modéliser le coût. L'équipe construit sur un petit ensemble de données, exécute quelques centaines de requêtes, et la facture est négligeable. Une facture POC à faible volume est un échantillon, et elle ne reflète pas les dépenses de production.

Trois citations de l'examen post-lancement Les citations ci-dessous proviennent de l'examen post-déploiement d'une seule équipe, 60 jours après le passage d'un système de triage de documents à la production. Chaque citation identifie un aspect différent de la même erreur.

Citation 1 « Un POC exécutant 10–50 requêtes par jour peut toujours informer une estimation de coût de production, mais seulement si les chiffres sont mis à l'échelle au volume de production attendu avec des marges d'erreur appropriées. Présenter les coûts de démo bruts à un client sans cette extrapolation est l'endroit où le risque réside. »

Citation 2 « Nous avons supposé que la distribution de tokens serait uniforme. Ce n'était pas le cas. Les longs documents dans la queue consommaient 80% des dépenses totales de tokens. »

Citation 3 « Quand le point de terminaison a retourné une erreur 529 au pic le jour trois, le flux de travail entier s'est arrêté. Nous n'avions pas de fallback parce que nous n'avions jamais testé ce qui se passait quand l'appel échouait. »

Ce qui a cassé et pourquoi Chaque citation nomme une défaillance distincte, mais elles se composent dans l'ordre. Le modèle de coût était faux parce qu'il a été construit au volume incorrect. L'hypothèse de distribution de tokens était fausse parce qu'elle a été construite sur les entrées incorrectes. La défaillance de fiabilité était invisible en développement parce que les cas de défaillance n'ont jamais été testés. Les trois défaillances partagent la même cause première : le POC a été traité comme un modèle de coût et de fiabilité, pas seulement une démonstration de capacité. Un POC répond à la question « le système peut-il faire cela », mais il ne répond pas à « combien ça coûte de faire cela à l'échelle » ou « que se passe-t-il quand une dépendance échoue ».

Ce qu'il faut surveiller Le POC a été traité comme un modèle de production dans trois dimensions simultanément : coût, distribution d'entrée, et fiabilité. Les trois sont des propriétés de système de production qui doivent être conçues séparément, et un POC n'en établit aucune.

Screen 7: Cost & reliability calculator

CheckpointPOC to Prod5 min Calculatrice de coût et de fiabilité Utilisez la calculatrice pour explorer les configurations. Ajustez le niveau de modèle, la mise en cache des prompts, le plafond max_tokens, et le multiplicateur de volume d'appels ; les lectures affichent le coût mensuel et la latence p95 pour chaque paramètre. Votre objectif : trouver une configuration qui répond à la fois au plafond de coût et à la cible de latence en même temps. La calculatrice affiche uniquement les valeurs ; elle ne note pas votre exploration. (Les chiffres sont représentatifs pour la modélisation ; confirmez les taux actuels au moment de la publication. )

Scénario Un agent de service client traite 50 000 requêtes par mois. Le prompt système est de 5 000 tokens et stable sur les requêtes. L'entrée utilisateur moyenne est de 300 tokens, la sortie moyenne est de 400 tokens. Le plafond de coût est de 800 $/mois. La cible de latence p95 est de 3 secondes.

Niveau de modèle

Haiku Sonnet Opus

Mise en cache des prompts

Activée

Plafond max_tokens : 512

Multiplicateur de volume d'appels : 1,0×

Coût mensuel estimé 720 $ Plafond de coût : 800 $/mois

Latence p95 2,5 s Cible de latence : ≤3 s

Décision : Une fois que vous avez une configuration qui répond aux deux cibles, quel levier a fait le plus de travail pour y arriver ?

A. Passer à Opus, parce que le modèle le plus capable est toujours le plus sûr. B. Activer la mise en cache des prompts, parce que le prompt système de 5 000 tokens est stable sur les 50 000 requêtes, donc le mettre en cache réduit le principal moteur de coût d'entrée. C. Augmenter le plafond max_tokens, parce que plus d'espace améliore la qualité.

Soumettre Ignorer pour l'instant

Screen 8: Use-case sizing and feasibility

TeachingSizing18 min Dimensionnement et faisabilité du cas d'usage La liste de contrôle de préparation à la production vous dit ce qu'un système doit réaliser pour être viable. Elle couvre à la fois la qualité des sorties du modèle et la fiabilité du système autour. La qualité de sortie est validée par les evals, et la fiabilité du système est validée par les contrôles d'architecture comme les retries, les fallbacks, et les circuit breakers. Respecter les deux barres est ce que la préparation à la production signifie. Le dimensionnement vous dit si un problème métier spécifique peut respecter cette barre, et quelles contraintes régissent la conception. La faisabilité s'adapte à l'un des trois états : faisable tel que délimité, faisable avec des contraintes, et non faisable. Identifier l'état correctement est ce qui rend un document de délimitation utile.

Comment dimensionner un cas d'usage Dimensionner un cas d'usage signifie produire un modèle de coût avant que du code ne soit écrit. Le modèle n'a pas besoin d'être précis, mais il doit être assez exact pour valider l'architecture par rapport au budget et exposer les hypothèses de distribution de tokens avant qu'elles ne soient formalisées. Quatre entrées conduisent le modèle : volume d'appels, budget de tokens par requête, niveau de modèle, et paramètres de sensibilité.

Étape 1 : Estimez le volume d'appels. Combien de requêtes sont faites par jour ou par mois ? Ce chiffre provient de l'exigence métier, pas de l'intuition du développeur. Un agent de service client qui gère 1 000 conversations par jour produit 1 000 appels Claude par jour, plus tous les appels de continuation multi-tours. Obtenez ce chiffre du propriétaire métier. Un ensemble de données d'échantillon ne vous donnera pas un chiffre exact. Étape 2 : Définissez le budget de tokens par requête. Le budget de tokens a deux composants : tokens d'entrée (prompt système, contexte récupéré, et message utilisateur) et tokens de sortie (longueur de réponse attendue). Modélisez la distribution plutôt que juste la moyenne. Si les longueurs de document varient largement, le modèle de coût devrait tenir compte des cas typiques ainsi que des extrêmes. Si le prompt système est long et stable, la mise en cache des prompts peut réduire considérablement les coûts d'entrée. La mise en cache nécessite des marqueurs cache_control explicites dans la requête. Les écritures de cache entraînent un coût par token plus élevé que l'entrée standard, de sorte que le modèle de coût doit tenir compte du coût d'écriture à la première utilisation. Le TTL de cache par défaut est de 5 minutes ; les charges de travail avec une fréquence de requête inférieure au TTL ne réaliseront pas des économies de mise en cache cohérentes. Étape 3 : Projetez le coût mensuel. Multipliez le volume d'appels par le nombre de tokens d'entrée au taux de token d'entrée. Séparément, multipliez le nombre de tokens de sortie au taux de token de sortie. Ensuite, ajoutez les deux chiffres. Les tokens d'entrée et de sortie sont facturés à des taux différents sur tous les niveaux de modèle. Si la mise en cache des prompts s'applique, utilisez le taux de lecture de cache pour les tokens d'entrée mis en cache, pas le taux d'entrée standard. Vérifiez les taux actuels sur platform. claude. com/docs/en/about-claude/pricing avant de finaliser le modèle. Ajoutez les économies de mise en cache si applicable. Comparez le résultat au plafond de coût de la liste de contrôle de préparation à la production. Si la projection dépasse le plafond, l'architecture doit changer avant qu'une ligne de code ne soit écrite. Si, par exemple, l'API Batch fournit une réduction de prix de 50% par rapport aux tarifs de l'API standard et supporte jusqu'à 100 000 requêtes par lot, modélisez-la comme une alternative de coût pour toute charge de travail où l'accord de niveau de service permet le traitement asynchrone. Pour les charges de travail réglementées, vérifiez si le traitement par lot est couvert par la BAA et la configuration de conformité du partenaire avant d'acheminer les PHI ou les données similaires gouvernées à travers lui. Trouvez le taux de réduction de l'API Batch le plus actuel et la limite de taille de lot sur platform. claude. com/docs/en/about-claude/pricing. Étape 4 : Exécutez l'analyse de sensibilité. Que se passe-t-il au coût si le volume d'appels double ? Que se passe-t-il si la distribution de tokens se déplace vers la queue ? L'analyse de sensibilité vous dit à quel point le modèle de coût est fragile et où les hypothèses doivent être vérifiées avec le propriétaire métier avant de s'engager dans la conception.

Comment délimiter un cas d'usage La séquence de découverte pour transformer une exigence métier en une architecture délimitée s'exécute en quatre étapes. Ignorer une étape produit un engagement qui ne survivra pas à la prochaine conversation avec le propriétaire métier.

Étape 1 : Exigence métier à liste de capacités. Que doit faire le système ? Nommez chaque capacité séparément. « Traiter les réclamations d'assurance » est un objectif. Les capacités pourraient inclure l'extraction de champs structurés du document de réclamation, la recherche de couverture de politique dans la base de données de politique, l'acheminement de la réclamation vers la file d'attente d'ajusteur appropriée en fonction du type et de la valeur de la réclamation, et la rédaction de la notification d'ajusteur. Identifiez-les séparément afin que vous puissiez assigner chacun au propriétaire approprié. Étape 2 : Liste de capacités à esquisse d'architecture. Pour chaque capacité, décidez où elle appartient. Quelles capacités Claude possède-t-il ? Lesquelles appartiennent aux systèmes existants ? Lesquelles nécessitent un humain dans la boucle ? C'est l'étape de décomposition du Module 1, appliquée à un cas d'usage spécifique. Étape 3 : Esquisse d'architecture à conditions limites. Énoncez les conditions sous lesquelles l'architecture fonctionne et les conditions sous lesquelles elle ne fonctionne pas. La faisabilité est un verdict plus les contraintes qui rendent le verdict vrai. Une architecture qui fonctionne pour les documents jusqu'à 20 pages mais échoue pour les documents plus longs a une condition limite qui doit être documentée. Étape 4 : Conditions limites à délimitation dans le SOW. La déclaration de travail contient les conditions limites. Cela garantit que l'équipe de développement et le propriétaire métier comprennent tous les deux ce que le système est conçu pour gérer et ce qui est explicitement hors de portée.

Comment mener une évaluation de faisabilité technique Une évaluation de faisabilité qui demande seulement « Claude peut-il faire cela » est une vérification de capacité. Les quatre propriétés IA vous donnent un moyen structuré d'identifier où la conception nécessitera des contrôles compensatoires, et quels devraient être ces contrôles. Sélectionnez chaque propriété pour voir la question de faisabilité qu'elle soulève et où la conception compense.

Next Token Prediction Knowledge Working Memory Steerability

La question de faisabilité à poser : Cette tâche nécessite-t-elle une génération probabiliste, ou nécessite-t-elle de la précision sur des valeurs spécifiques ? La classification, la résumé, et la rédaction sont des tâches probabilistes où le modèle excelle. L'extraction de valeurs faisant autorité spécifiques (numéros de compte, dates de politique, montants de réclamation) nécessite une vérification par rapport à la source de vérité. Où la conception compense : Boucles générateur-vérificateur ; evals basées sur le code sur les valeurs extraites ; appels d'outils pour récupérer les données quantitatives.

La question de faisabilité à poser : Cette tâche dépend-elle d'informations qui sont rares, contestées, récentes, ou spécifiques au domaine de manière à ne pas être représentées dans les données d'entraînement ? Si oui, la conception doit apporter la connaissance dans la fenêtre de contexte. Ne comptez pas sur le modèle pour la fournir. Où la conception compense : Génération augmentée par récupération pour la connaissance stable ; appels d'outils pour les données d'état en direct ; signalisation de l'incertitude sur les réclamations contestées.

La question de faisabilité à poser : Les entrées s'adaptent-elles confortablement dans la fenêtre de contexte, ou la tâche nécessite-t-elle de traiter les entrées qui, en agrégat, dépassent la fenêtre ? Les longs documents, les tâches multi-documents, et les conversations étendues frappent tous cette contrainte. Où la conception compense : Stratégies de chunking ; chargement de contexte progressif ; résumé sur les tours ; architecture de pipeline pour les entrées dépassant la limite de contexte.

La question de faisabilité à poser : Les instructions sont-elles spécifiques, concrètes, et vérifiables ? Les instructions abstraites ou ambiguës, les longues chaînes de raisonnement, et les tâches qui nécessitent un calcul numérique ou logique précis sont tous des endroits où le modèle peut dériver de l'intention. Où la conception compense : Prompts système avec schémas de sortie explicites ; sorties structurées ; exécution de code pour la précision numérique ; boucles d'évaluateur-optimiseur.

Verdicts de faisabilité Une fois que la séquence de délimitation et l'évaluation technique sont complètes, l'architecture est prête pour une évaluation de faisabilité. Il y a trois résultats possibles.

VerdictCe que cela signifieQuoi documenter

Faisable tel que déliméLes arguments sur les quatre propriétés IA favorisent Claude pour chaque capacité. Le modèle de coût est dans le plafond. La latence p95 est dans l'accord de niveau de service. Aucune capacité ne nécessite un contrôle compensatoire qui change l'architecture. Énoncez les hypothèses clairement. Les verdicts faisables-tel-que-délimité deviennent faisables-avec-contraintes quand les hypothèses changent. Faisable avec contraintesLa conception fonctionne sous des conditions spécifiques qui doivent être appliquées. La longueur du document doit rester sous un seuil. L'index de récupération doit être actualisé selon un calendrier défini. Une porte d'examen humain doit exister pour les sorties au-dessus d'un seuil de confiance. Les contraintes font partie de l'architecture. Documentez chaque contrainte explicitement. Pour chaque contrainte violée, identifiez le mode de défaillance. L'équipe de développement doit savoir ce qu'elle conçoit, pas seulement ce qu'elle construit. Non faisableAu moins une capacité fait face à une limitation de propriété IA qui ne peut pas être compensée dans la portée et le budget. Le modèle de coût dépasse le plafond d'une marge qui ne peut pas être fermée par le niveau de modèle, la mise en cache, ou les changements d'architecture. Un verdict non faisable est une évaluation correcte qui sauve l'engagement d'une défaillance plus coûteuse plus tard. Énoncez quelle contrainte est disqualifiante et pourquoi. Où une réduction de portée changerait le verdict, nommez-la et présentez au propriétaire métier un choix.

Mappage de la valeur métier et du ROI : transformer une conception faisable en un investissement justifié Un verdict de faisabilité dit au propriétaire métier que le système peut être construit dans le budget et les contraintes. Il ne lui dit pas si la construction en vaut la peine. Déterminer la valeur métier et le mappage du ROI sont les étapes qui répondent à cette deuxième question. Ils connectent l'architecture délimitée aux résultats financiers et opérationnels que l'entreprise attend, exprimés en termes que le propriétaire métier utilise déjà : heures économisées, taux d'erreur réduit, cycle de temps raccourci, ou revenu protégé. Le mappage transforme une conception technique en une décision qu'un détenteur de budget peut défendre.

Le cas métier repose sur cinq piliers principaux, et les identifier garde la conversation du ROI dans le langage que le plan et le propriétaire métier utilisent tous les deux : efficacité (le même travail fait plus rapidement ou moins cher), transformation (le travail qui n'était pas faisable avant devient possible), productivité (plus de sortie des mêmes personnes), coût de solution (le coût d'exécution du système lui-même), et accords de niveau de service de performance (les niveaux de service que le déploiement doit maintenir). Mappez chaque réclamation de ROI au pilier qu'elle avance afin que la déclaration de valeur capture à la fois le chiffre et le type de valeur qu'il représente. Le mécanisme est une comparaison entre deux états. L'état de base est comment le travail est fait aujourd'hui, mesuré dans l'unité que l'entreprise se soucie. L'état projeté est comment le travail est fait une fois que Claude est dans le flux de travail, mesuré dans la même unité. La valeur est la différence entre les deux états, moins le coût d'exécution du système. Le chiffre de coût provient directement du modèle de dimensionnement produit plus tôt dans ce cluster, de sorte que le calcul du ROI réutilise le travail que vous avez déjà fait plutôt que de recommencer.

Le mappage est construit en quatre étapes, et chaque étape doit être ancrée dans un chiffre que le propriétaire métier reconnaîtra :

Étape 1 : Nommez la base de référence dans une unité métier. Commencez par comment la tâche est effectuée aujourd'hui et mesurez-la dans l'unité que l'entreprise suit déjà. Pour un flux de travail d'examen de réclamations, c'est les heures d'analyste par réclamation ou les jours moyens pour résoudre. La base de référence doit provenir des données opérationnelles propres du propriétaire métier, parce que chaque chiffre ultérieur est comparé à celui-ci. Une base de référence tirée de l'intuition produit un chiffre de ROI qu'aucune équipe de finance n'acceptera. Étape 2 : Prédisez l'état post-déploiement dans la même unité. Estimez comment la même tâche fonctionne une fois que Claude est dans le flux de travail, mesuré dans l'unité identique que la base de référence. Où le verdict de faisabilité nécessite un examen humain, la projection doit inclure ce coût. L'acheminement de la sortie de faible confiance vers un examinateur réduit la main-d'œuvre, mais ne l'élimine pas entièrement. Quand la conception spécifie un examen humain dans la boucle, projeter l'automatisation complète surestime la valeur et produit un chiffre que les opérations rejetteront. Étape 3 : Soustrayez le coût d'exécution du modèle de dimensionnement. Prenez le coût mensuel projeté produit pendant le dimensionnement et traitez-le comme le coût récurrent du nouvel état. La valeur du déploiement est le gain opérationnel de l'étape 2 moins ce coût d'exécution. Cette étape isole le coût d'exécution récurrent uniquement. Le coût de construction est traité séparément et est comptabilisé dans le calcul de la période de récupération à l'étape 4. L'inclusion de la sortie de dimensionnement dans le calcul du ROI garde les deux analyses cohérentes. Un changement au budget de tokens ou au niveau de modèle met alors à jour à la fois le plafond de coût et le cas de valeur ensemble. Étape 4 : Énoncez la période de récupération et la sensibilité. Exprimez le résultat comme une période de récupération, qui est le temps qu'il faut pour que le gain opérationnel accumulé couvre le coût de construction et le coût d'exécution. Ensuite, énoncez comment cette période se déplace si les hypothèses de volume ou les hypothèses de gain par tâche sont fausses. Citer une période de récupération sans analyse de sensibilité invite les décisions basées sur un seul scénario optimiste, celui qui échoue souvent quand le cas métier rencontre les volumes réels après le lancement.

La sortie du mappage est une brève déclaration de valeur que l'Architecte remet au propriétaire métier aux côtés du verdict de faisabilité. Elle lie les réponses à « Pouvons-nous construire cela ? » et « Vaut-il la peine de construire cela ? » aux chiffres que l'entreprise possède déjà. Les deux artefacts voyagent ensemble dans la déclaration de travail. Ce sont les erreurs de mappage du ROI les plus courantes, ce qui les cause, et où elles ont tendance à apparaître.

RisqueePourquoi cela se produit et où cela apparaît

La base de référence est estimée plutôt que mesurée. Quand le propriétaire métier n'a pas de données opérationnelles propres, la base de référence est remplie à partir de l'intuition. Cela rend le gain apparent trompeur. L'erreur reste cachée jusqu'à ce que l'équipe de finance demande la source du chiffre de base de référence lors de l'examen du cas métier. À ce stade, le cas entier doit être reconstruit. La projection suppose l'automatisation complète quand la conception nécessite un examen humain. Un verdict de faisabilité qui nécessite une porte d'examen humain signifie que la main-d'œuvre est réduite, pas complètement éliminée. Le cas de valeur modélise souvent de manière trompeuse comme éliminé. L'écart apparaît dans la première période opérationnelle après le lancement, quand les heures d'analyste réelles ne baissent pas aussi loin que le cas métier l'a promis. Le coût d'exécution est tiré d'une moyenne plutôt que de la distribution de dimensionnement. Réutiliser un coût de token moyen au lieu de la distribution du modèle de dimensionnement sous-estime le coût récurrent, ce qui surestime la valeur nette. Cela se concentre sur les flux de travail avec des entrées à queue lourde, où une petite fraction de grandes requêtes conduit la plupart du coût.

Coût · Complexité · Risque Coût : Le dimensionnement basé sur les nombres de tokens moyens sous-estimera le coût quand certaines requêtes sont beaucoup plus grandes que d'autres. Se tromper signifie renégocier l'architecture après que le contrat soit déjà signé. Complexité : Une évaluation de faisabilité qui ignore l'une des quatre propriétés IA risque de manquer une contrainte qui change la conception. La mémoire de travail est la plus négligée, car elle apparaît rarement pendant le développement sur des entrées petites et propres, mais elle apparaîtra en production. Risque : Un verdict faisable-avec-contraintes qui n'est pas documenté devient un système non faisable quand les contraintes sont violées en production. Les contraintes font partie de la conception et portent le même poids que l'architecture qu'elles qualifient.

Screen 9: The scoping call that skipped the constraints

Watch OutSizing5 min L'appel de délimitation qui a ignoré les contraintes

Le piège de la démo Quand un propriétaire métier est enthousiaste à propos d'un cas d'usage et que la démo initiale fonctionne, confirmer la faisabilité avant de rassembler les contraintes de volume et d'accord de niveau de service semble être le chemin efficace. La capacité est là, le prototype fonctionne, et ralentir pour poser des questions sur les contraintes peut sembler chercher des raisons de dire non. Le problème est que « techniquement faisable » est sans sens si les contraintes ne sont pas appliquées à l'échelle attendue.

Une conversation de délimitation : Engagement pris trop tôt Ce qui suit est un extrait d'un modèle qui apparaît dans les appels de découverte quand la question de capacité est répondue avant que les questions de contrainte ne soient posées.

Partenaire : « Nous avons besoin d'un assistant d'examen de documents qui peut traiter nos contrats juridiques et signaler les clauses non standard. » Architecte : « Nous pouvons faire cela. Le modèle est bon pour lire les contrats et identifier les modèles de clauses. Laissez-moi préparer une note de faisabilité. » Partenaire : « Super, combien de temps prendra la construction ? » Architecte : « Six semaines pour la version initiale. » [Deux semaines dans la construction] Partenaire : « Je devrais mentionner : nous traitons environ 800 contrats par jour. Certains d'entre eux sont des accords-cadres qui s'étendent à 300 pages. Et nous avons besoin de résultats en moins de 30 secondes. »

Ce qui s'est mal passé Le verdict de faisabilité a été émis avant que trois contraintes essentielles ne soient rassemblées : volume d'appels (800 par jour), taille d'entrée (jusqu'à 300 pages), et exigence de latence (30 secondes). Si un contrat long s'adapte dans la fenêtre de contexte dépend du niveau de modèle sélectionné. Les modèles avec une fenêtre de contexte de 1 million de tokens peuvent gérer un contrat de 300 pages sans chunking ; un modèle avec une fenêtre de 200k peut nécessiter une stratégie de chunking pour les documents les plus longs. La capacité de la fenêtre de contexte fait donc partie de la décision du niveau de modèle, pas une hypothèse réglée. À 800 requêtes par jour, l'exigence de latence de 30 secondes n'est pas aussi limitante qu'elle le semble. Cela fait la moyenne d'une requête toutes les 108 secondes. Le traitement séquentiel est viable à ce volume sans exécuter les requêtes en parallèle. À ce taux de requête, le volume exerce une pression sur le coût, pas la latence. La latence est conduite par la complexité de la tâche, la taille du modèle, et la longueur de sortie. Ce sont les variables autour desquelles la décision du niveau de modèle doit être construite. L'architecte a confirmé la capacité comme une première étape nécessaire, mais c'était aussi la dernière étape, ce qui signifie que l'engagement a été pris avant que la conception ne soit possible.

Ce qu'il faut surveiller La question de capacité a été répondue avant que les questions ne soient même posées. Le volume, la latence, et les contraintes de taille d'entrée sont des entrées au verdict de faisabilité. Le verdict n'est aussi solide que les contraintes rassemblées avant lui.

Screen 10: Justify the feasibility call

CheckpointSizing5 min Justifier l'appel de faisabilité Pour chaque scénario, choisissez l'option qui nomme à la fois le verdict de faisabilité correct et la contrainte unique porteuse de charge derrière lui. Le verdict seul ne suffit pas, la contrainte est ce qui rend le verdict défendable.

SCÉNARIO 1 SUR 3 Un cabinet de services professionnels veut un assistant de recherche qui résume les rapports d'industrie de 10–40 pages et rédige les briefings des clients. 50 rapports par semaine, briefings dans les 24 heures, plafond de 500 $/mois.

A. Non faisable, les rapports sont trop longs pour la fenêtre de contexte. B. Faisable tel que délimité, la taille d'entrée s'adapte à la fenêtre de contexte, et le volume, la latence, et le coût sont tous dans la plage au niveau Sonnet ; aucune propriété IA ne présente une contrainte disqualifiante. C. Faisable avec contraintes, a besoin d'une porte d'examen humain sur chaque briefing.

SCÉNARIO 2 SUR 3 Une entreprise de logistique veut un prédicteur de retard qui lit les e-mails de transporteur non structurés, extrait les raisons de retard et les nouveaux ETA, et les écrit dans le système de gestion des commandes. 5 000 e-mails/jour, moins de 10 secondes, 1 000 $/mois.

A. Faisable tel que délimité, Haiku avec mise en cache gère le volume et la latence. B. Non faisable, le volume est trop élevé. C. Faisable avec contraintes, la contrainte porteuse de charge est la précision d'extraction sur une écriture transactionnelle, donc elle nécessite une eval basée sur le code sur la précision d'extraction plus une porte d'examen humain sur les extractions de faible confiance avant d'écrire au système d'enregistrement.

SCÉNARIO 3 SUR 3 Un cabinet de services financiers veut des recommandations de trading en temps réel à partir des conditions de marché actuelles plus son modèle propriétaire, livrées en moins de 2 secondes.

A. Non faisable tel que décrit, la contrainte porteuse de charge est l'écart de connaissance d'état en direct : les données de marché en temps réel nécessitent un appel d'outil à un flux en direct, et si ce aller-retour s'adapte dans le budget de 2 secondes doit être validé avant que tout verdict de faisabilité puisse être émis. B. Faisable tel que délimité, Claude connaît déjà les conditions de marché actuelles. C. Faisable avec contraintes, ajoutez juste une porte humaine.

Ignorer pour l'instant

Screen 11: Enterprise integration patterns: identity, auth, data, and observability

TeachingIntegration14 min Modèles d'intégration d'entreprise : identité, authentification, données, et observabilité Les contraintes de conformité éliminent les options de point d'entrée avant toute autre décision, de sorte que la sélection du point d'entrée vient en premier. Les cinq couches restantes régissent comment l'intégration est construite à partir de là. Le dimensionnement vous dit ce que le système doit faire et s'il peut le faire dans les contraintes. Les modèles d'intégration vous disent comment il se connecte à la pile d'entreprise. Cette connexion a cinq couches, et chaque couche a une décision architecturale qui appartient à l'Architecte, par opposition à l'équipe d'implémentation.

Sélection du point d'entrée : quelle intégration utiliser et quand La première décision dans toute intégration est le point d'entrée par lequel le système se connectera. Les contraintes de conformité éliminent les options à ce premier stade, avant toute autre décision architecturale. Le tableau couvre les cinq points d'entrée disponibles, quand chacun s'applique, et ce que chacun coûte en flexibilité ou maintenance. Points d'entrée : quelle intégration utiliser et quand Point d'entréeL'utiliser quandCe que vous échangez

API directeVous avez besoin d'un contrôle complet sur la façon dont les requêtes sont construites, comment les réponses sont gérées, et comment les erreurs sont gérées. Chaque partie du système est votre propre code. Vous êtes responsable de la construction et de la maintenance de la logique de retry, du streaming, de l'orchestration d'outils, et de la gestion des erreurs. L'effort d'implémentation est plus élevé que le chemin SDK. SDK (Python/TypeScript)Vous voulez une couche de commodité qui gère les bases sans renoncer au contrôle sur la façon dont le système est conçu. Le SDK gère la couche HTTP et vous donne des interfaces typées tout en laissant l'orchestration à votre code. Moins de contrôle granulaire que l'API brute. Les mises à niveau de version du SDK peuvent occasionnellement changer le comportement de manière à nécessiter un examen du code avant le déploiement. Claude CodeL'utilisateur principal est un développeur, et la tâche implique l'écriture, l'examen, ou la navigation du code. Pas approprié comme backend pour un produit intégré. Non conçu pour les produits avec plusieurs utilisateurs ou les déploiements orientés clients. Claude Code est conçu pour les flux de travail des développeurs, pas comme backend pour les produits multi-locataires ; les intégrations de produits devraient utiliser l'API Claude, le SDK client, ou l'Agent SDK. Agent SDKVous avez besoin que Claude agisse sur plusieurs tours à l'intérieur de votre propre produit, avec votre application contrôlant le flux de travail environnant. L'Agent SDK exécute une boucle gérée, gérant l'itération, l'exécution d'outils, et la terminaison, de sorte que votre équipe n'a pas à construire cette infrastructure. Disponible en Python et TypeScript. Pas le bon choix quand une seule requête et réponse suffit, ou quand la tâche ne nécessite pas de raisonnement multi-tours sur les outils. La boucle gérée renonce au contrôle fin-grained sur chaque étape d'itération. Si votre cas d'usage nécessite une logique personnalisée entre les tours, une boucle API brute vous donne ce contrôle au coût de construire et de maintenir la boucle vous-même. MCP (Model Context Protocol)Vous connectez Claude aux outils existants ou aux services internes et voulez un moyen standard de gérer ces connexions sans les mélanger dans votre logique d'orchestration. MCP fournit un protocole pour l'intégration d'outils qui garde la couche d'intégration séparée de la couche d'orchestration. MCP ajoute une couche de protocole entre Claude et vos outils, ce qui rend le débogage des appels d'outils plus complexe que les appels de fonction directs.

Contraintes de sécurité et de conformité au niveau de l'intégration Le Module 1 a établi que les contraintes réglementaires et politiques, les lois comme HIPAA, GDPR, et FedRAMP, le privilège avocat-client, et les exigences de résidence des données éliminent les options de point d'entrée avant toute autre décision. Cette section applique la même logique un niveau plus profond : quel modèle d'intégration sur ce point d'entrée peut, avec les choix architecturaux appropriés, les politiques internes, les termes contractuels, et d'autres éléments, aider à satisfaire ou autrement atténuer les préoccupations concernant la contrainte. Le tableau ci-dessous étend cette analyse de la sélection du point d'entrée à la conception d'intégration complète. Remarque : Ceci ne doit pas être considéré comme des conseils juridiques - travaillez avec votre propre équipe juridique et de conformité pour mettre en œuvre les contrôles qui répondent aux besoins de votre organisation. Matrice de contrainte à intégration ContrainteOù il s'exécute (Route)Comment il se connecte (Modèle d'intégration)Qui il fait confiance (Identité)Ce qu'il gère (Gestion des données)Ce qu'il enregistre (Observabilité)

Privilège avocat-client*L'API s'exécute derrière l'application propre du cabinet, à travers une passerelle approuvée par le cabinet qui enregistre chaque requête. La passerelle se situe entre l'utilisateur et Claude. Elle détient la clé API, applique qui peut accéder à quoi, et produit un journal d'audit que le cabinet possède. Les utilisateurs se connectent via SSO. L'identité de l'utilisateur et les permissions sont assignées par le serveur et ne peuvent pas être revendiquées par l'utilisateur. Tout contenu privilégié circule à travers la passerelle, qui sert de dossier officiel. Chaque requête et réponse est enregistrée à la passerelle et conservée selon la politique du cabinet. HIPAA (gestion PHI)L'API s'exécute sur une configuration couverte par un Business Associate Agreement (BAA). Les chemins éligibles à HIPAA incluent l'API Claude directement (avec une BAA signée d'Anthropic), AWS Bedrock, et Google Vertex AI. La BAA doit couvrir la configuration spécifique en usage, pas seulement le fournisseur en général. Le fournisseur de cloud médiatise l'intégration. La BAA doit couvrir la configuration spécifique en usage, pas seulement le fournisseur en général. Les utilisateurs sont vérifiés par le système d'authentification du partenaire. L'accès à PHI est limité au minimum nécessaire selon HIPAA. PHI est réduit à seulement ce que la tâche nécessite avant l'appel API. Où possible, les ID de référence sont utilisés à la place des champs de données complets. Les journaux capturent la requête, la version du modèle, l'identité de l'utilisateur, et la portée des données, et sont conservés selon les exigences HIPAA. GDPR et résidence des donnéesL'exécution du modèle est confinée à une région approuvée. Cela peut être réalisé par une route cloud (AWS Bedrock ou Google Vertex AI) ou directement par l'API Claude en utilisant le paramètre inference_geo, qui supporte actuellement « us » et « global » comme valeurs. Notez que inference_geo ne supporte pas le pinning EU directement – bien que la conformité GDPR ne nécessite pas la résidence EU, car les transferts transfrontaliers sont légaux avec un mécanisme de transfert valide, où un déploiement a une exigence de résidence des données EU, une route cloud plutôt que l'API directe devrait être utilisée. Où l'API Claude est utilisée, la DPA est avec Anthropic directement. Où une route cloud est utilisée, les termes DPA sont hérités du contrat cloud. Remarque : Microsoft Foundry EU data residency est listé comme À venir 2026 sans calendrier confirmé à la publication. Si le déploiement référence Foundry et nécessite le pinning des données EU, vérifiez la disponibilité actuelle avant de s'engager dans cette route. L'exécution région est verrouillée au niveau de l'intégration et vérifiée à chaque requête. Les données ne quittent pas la région approuvée. Les utilisateurs sont vérifiés dans la région de données approuvée et gérés selon les exigences GDPR. Les données personnelles ne sont traitées que dans la région épinglée. Déplacer les données à travers les frontières nécessite une base légale documentée et n'est construit que quand explicitement justifié. Les journaux enregistrent qui a accédé à quelles données, la base légale du traitement, et quand elles seront supprimées. FedRAMP et gouvernementL'intégration s'exécute sur une configuration cloud qui détient l'autorisation FedRAMP requise au niveau d'impact correct. Les chemins éligibles à FedRAMP sont Claude for Government, AWS Bedrock GovCloud, et Google Vertex Assured Workloads. Claude Enterprise sur l'API directe n'est pas autorisé FedRAMP et ne peut pas être utilisé comme substitut à ces chemins. L'architecture est limitée au cloud spécifique et à la configuration qui porte l'autorisation. Rien en dehors de cette limite n'est autorisé. Les utilisateurs s'authentifient par le fournisseur d'identité approuvé de l'agence. L'accès est contrôlé par la couche de rôle et de politique de l'agence. Les données sont gérées selon les règles de classification de l'agence. Les informations non classifiées contrôlées restent dans la limite autorisée. Les journaux répondent aux exigences de surveillance continue de l'agence. Politique de résidence des données interneL'intégration s'exécute sur le fournisseur de cloud que l'organisation du partenaire a déjà approuvé. La bonne route est celle que le CIO a approuvée, indépendamment de la commodité. L'architecture est contrainte par ce que l'approvisionnement a approuvé, indépendamment de la préférence d'ingénierie. Les utilisateurs se connectent via le SSO standard du partenaire. Les rôles sont assignés selon la politique existante du partenaire. Gestion des données selon le schéma de classification existant du partenaire. La couche Claude hérite des contrôles existants et n'en introduit pas de nouveaux. Les journaux s'alimentent dans l'infrastructure de journalisation existante du partenaire plutôt qu'un système séparé.

• La préservation du privilège dépend des termes contractuels appropriés, des paramètres de conservation, des politiques internes, et d'autres éléments. Les informations de ce tableau sont destinées à aider à atténuer les préoccupations concernant la renonciation au privilège.

Avant que toute conception d'intégration ne commence, travaillez à travers les contraintes dans l'ordre : identifiez la réglementation ou la politique gouvernante, déterminez quels points d'entrée et routes sont toujours disponibles, choisissez le modèle d'intégration qui s'adapte, et documentez les exigences d'identité, de gestion des données, et d'observabilité qui suivent. Ignorer une étape risque de construire quelque chose qui fonctionne techniquement mais échoue un examen juridique ou de sécurité.

Chaque intégration Claude d'entreprise nécessite des décisions aux couches définies dans le tableau ci-dessous. La conformité vient en premier, les contraintes des réglementations comme HIPAA, GDPR, et FedRAMP, et les politiques comme la résidence des données et le privilège avocat-client, éliminent les routes et les points d'entrée avant toute autre décision. Les quatre couches restantes opèrent dans les options qui survivent à ce filtre. Notez que ces sections ne traitent pas les cas d'usage ZDR.

CoucheeLa décision architecturaleQuoi casse quand c'est faux

Conformité et contraintes des secteurs réglementésQuels chemins de livraison et points d'entrée survivent à la contrainte gouvernante ? La couverture BAA, l'autorisation FedRAMP, le pinning de résidence des données, et les listes de fournisseurs approuvés éliminent chacun les options avant que le reste de la conception ne commence. L'intégration est construite sur une route qui échoue le prochain examen juridique ou de sécurité. Le coût de la reconception à ce stade est le temps déjà investi plus une nouvelle architecture à partir de zéro. Identité et SSOOù se situe la limite d'identité de l'utilisateur par rapport au point d'intégration Claude ? Qui est l'utilisateur dans le contexte d'un appel Claude, et comment cette identité est-elle passée dans le prompt de manière sûre ? Quand l'identité de l'utilisateur n'est pas passée dans le prompt correctement, Claude ne peut pas délimiter ses réponses à ce que cet utilisateur est autorisé à voir. L'identité passée comme un champ brut dans le message utilisateur est manipulable. L'injection côté serveur supprime ce risque. Autorisation et politiqueQuelles capacités cet utilisateur ou ce rôle a-t-il ? Quelles données peuvent-ils accéder ? Le modèle d'autorisation qui régit vos systèmes existants doit régir la couche Claude aussi. Une intégration Claude qui contourne le modèle d'autorisation du système sous-jacent donne aux utilisateurs l'accès aux données qu'ils ne sont pas autorisés à voir, par un chemin qui n'a pas été conçu pour appliquer la politique d'accès. Gestion des données et PIIQuelles données vont dans la fenêtre de contexte ? Les champs sensibles passés directement dans le message utilisateur ou le prompt système deviennent partie de la requête API. Anthropic ne conserve pas le contenu de conversation par défaut ; seulement ce qui est techniquement nécessaire pour que l'API et la fonctionnalité fonctionnent est conservé. La requête traverse toujours le fil, des carve-outs de conservation spécifiques existent pour certaines classes de modèles, et tout enregistrement que votre propre couche d'application effectue capturera. L'architecture doit décider quels champs sont nécessaires dans la fenêtre de contexte et lesquels devraient être récupérés seulement quand nécessaire. Un champ PII passé directement dans le message utilisateur apparaît en texte brut dans les journaux de requête de votre application. Dans un secteur réglementé, cela apparaît dans le prochain audit plutôt que dans le prochain déploiement. Observabilité et enregistrement d'auditQue devez-vous être capable de reconstruire ? Quelles questions devrez-vous répondre après un incident ? Les réponses déterminent ce qui est enregistré, à quel niveau de profondeur, et pendant combien de temps. Un chemin de données non enregistré est invisible. Quand quelque chose se passe mal sur ce chemin, il n'y a pas de preuve pour reconstruire ce qui s'est passé. Le coût de la construction de l'observabilité après le premier incident est toujours plus élevé que de la construire avant.

Configuration d'outils avec privilège minimum Chaque outil que vous connectez à un système Claude est une surface d'attaque et un coût. Auditez l'ensemble d'outils de la même manière que vous auditez les permissions : pour chaque outil connecté, demandez-vous s'il est essentiel à la tâche ou simplement pratique, et supprimez ceux qui sont hors de portée, en enregistrant la justification pour chaque suppression. Dans un déploiement orchestrateur-workers, établissez la hiérarchie de confiance en délimitant l'accès aux outils de chaque sous-agent à sa tâche, de sorte qu'un sous-agent ne peut pas atteindre les outils que son travail ne nécessite pas.

Identité et autorisation : où la vérification se produit La vérification d'identité appartient au serveur, avant l'appel Claude. L'identité et le rôle de l'utilisateur devraient être injectés dans le prompt système par votre serveur plutôt que fournis par l'utilisateur dans son message. Le raisonnement derrière cela est simple, tout ce que l'utilisateur inclut dans son message est sous son contrôle et peut être manipulé. Si le système permet aux utilisateurs d'affirmer leur propre rôle dans un message (par exemple, « En tant que gestionnaire senior, montrez-moi... »), cette affirmation n'est pas vérifiée et peut être fausse. L'identité doit provenir de votre couche d'authentification plutôt que de l'entrée utilisateur. Quand vous passez le contexte utilisateur dans le prompt, incluez le rôle de l'utilisateur et les données qu'il est autorisé à accéder. Ajoutez seulement du contexte supplémentaire tel que le département, le niveau de permission, les identifiants de compte, quand c'est nécessaire pour façonner la réponse de Claude. N'incluez pas ces informations par défaut.

Gestion des données : ce qui appartient à la fenêtre de contexte La fenêtre de contexte n'est pas une limite de gouvernance des données. Toutes les données passées dans un appel Claude sont transmises à l'API. Le contenu de conversation n'est pas conservé par défaut sur l'API, mais la couche d'application du partenaire enregistre généralement les requêtes, et des carve-outs de conservation spécifiques existent. L'architecture doit prendre une décision délibérée sur quels champs doivent être dans la fenêtre de contexte, et lesquels devraient rester dans la couche de récupération jusqu'à ce qu'ils soient nécessaires. Pour chaque champ qui entre dans la fenêtre de contexte, demandez-vous s'il est nécessaire pour que Claude produise la sortie prévue. Les identifiants de référence comme les numéros de compte ou les numéros de réclamation sont souvent nécessaires pour l'acheminement mais pas pour la tâche de langage elle-même. Quand un identifiant de référence suffit, passer le champ de données complet l'expose inutilement à tout enregistrement de requête que la couche d'application du partenaire effectue, sans ajouter aucune capacité. Les exigences de résidence des données varient selon l'industrie et la région. Pour les déploiements réglementés, vérifiez les conseils de résidence des données d'Anthropic par rapport aux exigences réglementaires spécifiques de votre déploiement avant que l'intégration ne soit conçue.

Observabilité : ce qu'il faut enregistrer, ce qu'il faut tracer, et pourquoi Un système basé sur LLM est plus difficile à déboguer qu'un système traditionnel parce qu'il ne plante pas quand quelque chose se passe mal, au lieu de cela il produit juste une réponse subtilement fausse. L'enregistrement standard capture les erreurs et les délais d'attente. Il ne capture pas, cependant, une réponse qui est tranquillement incorrecte d'une manière qui a des conséquences métier réelles. Un système Claude de production devrait enregistrer quatre choses :

La requête : version du modèle, nombre de tokens d'entrée, identifiant de prompt La réponse : nombre de tokens de sortie, latence, raison d'arrêt Le contexte : rôle utilisateur, ID de session, si la mise en cache a été appliquée Le résultat : si le système en aval a accepté la sortie et tous les signaux de rejet

Les organisations de sécurité traitent de plus en plus l'observabilité comme la précondition pour activer les agents du tout, car sans une piste d'audit fiable, un système autonome n'est pas approuvé pour agir. Concevez pour cette norme. Comme élément de liste de contrôle d'examen de conception, vérifiez quelles actions agentic sont enregistrées dans les journaux d'audit sur vos surfaces choisies. La couverture varie selon la surface, et une action qui est prise mais non enregistrée est, pour un examinateur de sécurité, une action qui ne peut pas être autorisée.

Coût · Complexité · Risque Coût : Une intégration sans redaction PII avant l'appel API expose les champs sensibles à l'enregistrement de requête de la couche d'application du partenaire à chaque requête. Le coût de la redaction rétroactive sur un historique de journal qui n'a jamais été conçu pour la supporter est le correctif de gestion des données le plus coûteux dans un système Claude de production. Complexité : Une couche d'observabilité ajoutée après le premier incident de production signifie que la cause première doit être reconstruite à partir d'un système qui n'a pas été configuré pour répondre à la question que l'incident a soulevée. La complexité supplémentaire de construire l'instrumentation correctement la première fois est inférieure à la complexité de la reconstruction de journal rétroactive. Risque : Un système multi-locataire s'exécutant sur une clé API partagée n'a aucun moyen d'attribuer une violation de limite de débit au locataire qui l'a causée. Quand la limite au niveau de l'organisation se déclenche en charge de pointe, le pic est visible mais la source ne l'est pas, et chaque locataire absorbe l'impact. Les clés API séparées par locataire sont nécessaires pour l'attribution et l'isolation dans tout déploiement multi-locataire de production.

Screen 12: The PII field that went straight into the prompt

Watch OutIntegration5 min Le champ PII qui est allé directement dans le prompt

Le piège de la démo pour ignorer la sécurité Quand l'objectif est de faire fonctionner une démo rapidement, le chemin le plus rapide vers une intégration Claude fonctionnelle est de passer les données que vous avez directement dans le prompt. L'ajout d'une couche de redaction PII, la construction d'une injection d'identité côté serveur, et l'instrumentation de la pile d'observabilité ajoutent tous du temps. Ils n'ajoutent également aucune capacité visible, car le système fonctionne sans eux. Le coût de les ignorer n'apparaît pas jusqu'au premier audit.

Un extrait de trace d'un déploiement du secteur réglementé La trace ci-dessous est un composite d'un modèle de champ dans un déploiement adjacent aux soins de santé. L'équipe a construit un outil de résumé d'admission de patient. Le résumé a fonctionné correctement. La gestion des données n'a pas.

Requête API : capturée dans les journaux de requête de la couche d'application Modèle : claude-sonnet-4-6 Système : « Vous êtes un résumeur d'admission clinique. Extrayez les préoccupations principales, les médicaments, et les allergies du formulaire d'admission. » Utilisateur : « Patient : Jane Doe, DOB : 1978-04-12, SSN : 123-45-6789, ID d'assurance : BCB-88712. Plainte principale : douleur thoracique, début il y a 3 jours... »

Le SSN et l'ID d'assurance sont dans le message utilisateur et voyagent donc avec la requête API, exposés à tout enregistrement de requête de la couche d'application, malgré ne pas être nécessaires pour produire le résumé. Le prompt système demande les préoccupations principales, les médicaments, et les allergies. Aucun de ceux-ci ne nécessite que le SSN ou l'ID d'assurance du patient soient dans la fenêtre de contexte.

Ce qui a cassé L'outil a fonctionné comme conçu, mais la gestion des données était fausse. Plusieurs champs qui se qualifient comme Informations de Santé Protégées (PHI) selon HIPAA, le nom du patient, la date de naissance, le SSN, l'ID d'assurance, la plainte principale, les médicaments, et les allergies, ont été passés dans l'appel API et capturés en texte brut dans les journaux de requête de la couche d'application. Ceux-ci n'étaient pas nécessaires pour la tâche de langage. Quand le déploiement a été examiné avant la certification de production, les journaux de requête de la couche d'application contenaient des milliers d'entrées avec les SSN des patients dans le champ de message utilisateur. Le correctif était un changement d'architecture de données : une étape de redaction côté serveur qui supprime les champs PII non essentiels avant l'appel Claude, et une fonction de récupération qui fournit seulement les champs que la tâche de langage nécessite. Les deux auraient dû être dans la conception originale.

Ce qu'il faut surveiller L'architecture de gestion des données a été conçue autour de ce qui était pratique à passer, pas autour de ce qui était nécessaire à passer. La nécessité est le bon filtre : si le champ n'est pas requis pour la tâche de langage que Claude effectue, il ne devrait pas être dans la fenêtre de contexte.

Screen 13: Critique the integration diagram

CheckpointIntegration5 min Critiquer le diagramme d'intégration Le diagramme ci-dessous montre un déploiement Claude pour un agent de service client dans une entreprise SaaS multi-locataire. Examinez les composants et connexions étiquetés, et sélectionnez chacun qui représente un problème d'intégration. Sélectionnez tous les problèmes. Laissez les composants sains non sélectionnés.

✓ ProblèmeClaude Code utilisé comme backend pour le produit de chat orienté client

↓↓↓

✓ ProblèmeClé API partagée utilisée pour tous les locataires

✓ ProblèmeVérification de capacité basée sur « Je suis un client premium » dans le message utilisateur

✓ ProblèmeNuméro de compte et e-mail passés dans le message utilisateur et apparaissant dans les journaux de requête

↓↓↓

✓ SainCouche d'authentification côté serveur en face de l'API

↓

✓ SainDonnées de locataire isolées par locataire au niveau du stockage

↓

✓ ProblèmeRéponse Claude passée au CRM en aval sans enregistrement au niveau de l'intégration

Vérifier les réponses Ignorer pour l'instant

Screen 14: A/B testing and observability at scale

TeachingA/B & Obs17 min Tests A/B et observabilité à l'échelle Les modèles d'intégration mettent Claude dans la pile d'entreprise. La question qui suit est de savoir s'il fonctionne comme il devrait une fois qu'il y est. L'observabilité répond à la question de surveillance. Les tests A/B structurés répondent à la question d'amélioration. Sans les deux, vous volez à l'aveugle ou vous faites des changements que vous ne pouvez pas mesurer.

Tests A/B structurés pour les systèmes Claude en direct Un test A/B pour un système Claude suit la même structure que toute expérience : une hypothèse, un groupe de traitement, un groupe de contrôle, une métrique, et une taille d'échantillon suffisamment grande pour rendre le résultat statistiquement significatif. La différence par rapport aux tests A/B logiciels traditionnels est que les sorties LLM sont probabilistes, ce qui rend les résultats plus bruyants et les effets d'interaction plus difficiles à contrôler. L'hypothèse doit être spécifique et testable. « Le nouveau prompt est meilleur » échoue sur les deux points : il ne nomme aucun traitement, aucune métrique, et aucun seuil. Une hypothèse utilisable se lit comme ceci : « Remplacer l'instruction de résumer par une instruction d'extraire les trois éléments d'action les plus importants augmentera le taux de succès de la tâche d'au moins 5% sans dégrader la latence p95 de la réponse. » Elle nomme le traitement, la métrique, le seuil de succès, et la contrainte.

ComposantCe qu'il nécessiteCe qui se passe mal quand il manque

HypothèseUne déclaration spécifique et réfutable nommant le traitement, la direction attendue de la métrique primaire, et toute contrainte sur les métriques secondaires. Sans une hypothèse, tout résultat peut être interprété comme une victoire. Vous pouvez toujours trouver une métrique qui s'est déplacée dans la bonne direction si vous regardez assez de métriques après le fait. Assignation de traitement et de contrôleAssignation aléatoire des requêtes au traitement (nouvelle version) ou au contrôle (version actuelle). L'assignation doit être cohérente pour un utilisateur ou une session donné pour éviter la contamination. L'assignation non aléatoire signifie que les groupes ne sont pas comparables. Si le groupe de traitement reçoit par hasard des requêtes plus complexes, une victoire apparente peut être un artefact de la distribution d'entrée. Métrique primaireLa métrique unique définie avant l'expérience s'exécute. Taux de succès de la tâche, coût par achèvement, latence p95, ou proxy de satisfaction utilisateur. Choisir la métrique après avoir vu les résultats est du shopping de résultats. Une métrique primaire non spécifiée transforme une expérience en une corrélation rétroactive, qui est une base beaucoup plus faible pour une décision. Taille d'échantillonCalculée à partir de l'effet minimum détectable, de la valeur de métrique de base, et du niveau de confiance requis. Pour les systèmes LLM, la variance dans les sorties est plus élevée que pour les systèmes déterministes, ce qui signifie que la taille d'échantillon requise est plus grande. Une expérience sous-alimentée produit des résultats qui ne peuvent pas distinguer un effet réel du bruit. Une équipe qui s'exécute jusqu'à ce qu'elle voie ce qu'elle veut trouvera ce qu'elle cherchait, que ce soit réel ou non.

Lire les résultats sans surestimer La signification statistique signifie que le résultat est peu probable d'avoir occurred par hasard compte tenu de la taille d'échantillon. Que ce soit assez grand pour compter est une question séparée. Un changement peut être statistiquement significatif mais toujours trop petit pour justifier le coût opérationnel de l'expédition et de la maintenance de la nouvelle version. Les deux questions à poser avant de déclarer un gagnant sont : l'effet est-il assez grand pour justifier les frais généraux opérationnels de maintenir la nouvelle version ? Et une métrique secondaire s'est-elle dégradée ? Un changement de prompt qui améliore le taux de succès de la tâche tout en augmentant le coût de 30% peut ne pas être une victoire nette, selon les contraintes budgétaires du déploiement. Les expériences LLM ont un mode de défaillance supplémentaire que les tests A/B classiques n'ont pas : les effets d'interaction entre le traitement et les types d'entrée spécifiques. Un changement de prompt qui améliore les performances sur les entrées typiques peut dégrader les performances sur les entrées de cas limites qui apparaissent rarement pendant la période de test mais fréquemment dans un pic saisonnier futur. L'alignement de la période de test et de la distribution d'entrée compte plus dans les expériences LLM que dans la plupart des autres contextes logiciels.

Tests d'ombre : valider un changement avant que tout utilisateur ne le voie Un test A/B en direct envoie les utilisateurs réels à la nouvelle version, ce qui signifie qu'une régression atteint une fraction d'entre eux avant que l'expérience ne se ferme. Il y a un moyen de tester par rapport au trafic réel sans prendre cette exposition. Vous exécutez la nouvelle version en parallèle avec la version actuelle, lui envoyez une copie des requêtes en direct, et servez à chaque utilisateur la réponse de la version actuelle. Les sorties de la nouvelle version sont enregistrées plutôt que retournées, et vous les notez hors ligne après le fait. La décision de déploiement est prise avant qu'un seul utilisateur n'ait vu la nouvelle version. Ce modèle s'appelle les tests d'ombre. Le choix entre les deux modèles dépend de la quantité de risque que le déploiement peut supporter et de la quantité de trafic qu'il voit.

Utilisez un test A/B en direct quand le déploiement peut absorber une petite quantité bornée d'exposition à une version pire et le volume de trafic est assez élevé pour atteindre un échantillon statistiquement significatif dans une fenêtre raisonnable. Le bénéfice est que vous mesurez la nouvelle version par rapport au comportement utilisateur réel, y compris les signaux en aval qu'une réponse en direct produit, tels que si l'utilisateur a accepté la réponse ou a suivi. Utilisez les tests d'ombre quand une seule mauvaise sortie porte trop de risque, ou quand le trafic est trop bas pour supporter une division en direct avant que le changement ne soit nécessaire. Le coût des tests d'ombre est la perte de signal en aval : sans utilisateurs recevant la sortie d'ombre, la notation s'appuie sur une rubrique hors ligne ou des réponses dorées plutôt que sur le comportement utilisateur réel. Pour un déploiement du secteur réglementé, où exposer les utilisateurs à un changement de modèle non validé peut ne pas être permis du tout, les tests d'ombre sont souvent le seul moyen acceptable de valider le changement.

Observabilité à l'échelle : conception d'instrumentation, tableaux de bord, détection d'anomalies L'observabilité de production pour un système Claude doit répondre à quatre questions : que fait le système, comment fonctionne-t-il bien, quand a-t-il changé, et pourquoi a-t-il changé ? Chaque question nécessite une couche d'instrumentation différente.

Traçage au niveau de la requête. Chaque requête devrait produire une trace qui inclut le modèle, la version du modèle, le nombre de tokens d'entrée, le nombre de tokens de sortie, la latence, la raison d'arrêt, et tous les appels d'outils effectués. C'est la matière première pour tout le reste. Agrégation de métriques. Agrégez les données au niveau de la requête dans les métriques que le tableau de bord affiche : coût par requête, latence p50 et p95, taux de succès de la tâche (si le système en aval fournit un signal d'acceptation), et taux d'erreur par type d'erreur. La décomposition par requête est critique : les métriques agrégées peuvent sembler saines tandis qu'une petite fraction de requêtes consomme la plupart du budget. Détection d'anomalies. Définissez des alertes de seuil sur les métriques qui comptent pour le déploiement. Un pic de coût qui dépasse 150% de la moyenne de 7 jours mérite une alerte. Une latence p95 qui franchit le seuil d'accord de niveau de service mérite une alerte. La dérive du modèle (changement graduel dans la distribution des sorties du modèle au fil du temps) est plus difficile à détecter avec les alertes de seuil et bénéficie de la comparaison de distribution périodique. Attribution de changement. Quand une métrique se déplace, l'instrumentation devrait être capable de distinguer la dérive du modèle (le comportement du modèle sur les entrées stables a changé), la dérive des données (la distribution d'entrée a changé), et les effets de mise à jour du modèle (la version du modèle a changé et la nouvelle version se comporte différemment sur les entrées existantes). Ces trois causes ont des atténuations différentes et les mélanger produit le mauvais correctif.

Une taxonomie de défaillance : classer ce que vous regardez L'instrumentation vous dit qu'une métrique s'est déplacée ; le diagnostic vous dit quel type de défaillance l'a déplacée. Avant d'attribuer un changement, classifiez la défaillance. Les classes courantes sont distinctes et appellent des correctifs différents :

Défaillance de prompt. L'instruction était ambiguë ou sous-spécifiée et le modèle a rempli l'écart. Le correctif est dans le prompt, pas le modèle. Hallucination. Le modèle a produit du contenu confiant et fluide qui n'est pas ancré dans l'entrée ou une source fiable. Le correctif est l'ancrage par la récupération, l'utilisation d'outils, ou la vérification. Une instruction plus forte ne la résoudra pas. Inadéquation du modèle. Le niveau choisi est faux pour la tâche ou a été échangé sans réévaluation. Le correctif est la sélection du modèle, contrôlée par une eval. Défaillance d'orchestrateur-workers. Dans les systèmes multi-agents, tracez à travers l'orchestrateur et ses sous-agents : une défaillance de sous-agent récupérable (retry ou flag) ressemble différemment d'une défaillance d'orchestrateur irrécupérable. L'attribution nécessite une trace qui s'étend sur les deux.

Discernement : juger la sortie Le discernement est l'une des quatre compétences de fluidité IA, défini comme la discipline de juger la qualité de ce que le modèle a produit plutôt que de l'accepter au pied de la lettre. Appliqué à un système de production, le discernement est l'habitude de classer chaque sortie comme acceptable, nécessite une révision, ou nécessite un remplacement, et de nourrir ce jugement dans les evals et la surveillance. Une équipe sans discernement regarde les métriques se déplacer et ne demande jamais si les sorties sous-jacentes étaient réellement bonnes.

Connexion des données d'observabilité à la valeur métier Les personnes qui ont financé le déploiement Claude ne lisent pas la trace au niveau de la requête. Ils lisent un tableau de bord KPI qui mesure le résultat que le déploiement a été conçu pour améliorer. La pile d'observabilité a besoin d'une couche de traduction qui connecte les métriques techniques aux métriques métier qu'elles conduisent. Pour un agent de service client, la métrique métier pourrait être le temps de traitement moyen, le taux de résolution au premier contact, ou le score de satisfaction client. La pile d'observabilité mesure la latence, le taux de succès de la tâche, et le taux d'erreur. La couche de traduction mappe le taux de succès de la tâche à la résolution au premier contact et la latence au temps de traitement, de sorte que le propriétaire métier peut voir si le système déplace les chiffres qu'il se soucie. Construisez cette couche de traduction quand le système est conçu, pas après le premier examen métier. Si les métriques techniques et métier ne sont pas mappées au moment de la construction, le premier examen métier soulèvera une question sur ce qui conduit le changement du temps de traitement. Sans ce mappage, y répondre nécessite une reconstruction rétroactive plutôt que d'exécuter une requête en direct.

Coût · Complexité · Risque Coût : Exécuter un test A/B sans pré-spécifier la métrique primaire signifie que vous pouvez toujours trouver un résultat que vous voulez. Les expériences sous-alimentées produisent des faux positifs. Un changement qui ressemble à une amélioration est déployé, et l'équipe finit par maintenir une version pas meilleure que ce qu'elle a remplacé tout en absorbant les frais généraux opérationnels complets. Complexité : L'instrumentation d'observabilité ajoutée après le premier incident de production signifie que la question de cause première ne peut pas être répondue à partir des données de journal existantes. La complexité supplémentaire de construire l'instrumentation correctement la première fois est inférieure à la complexité de la reconstruction de journal rétroactive. Risque : Un système LLM avec des métriques d'observabilité agrégées uniquement peut sembler sain tandis qu'une petite fraction de requêtes consomme la plupart du budget et produit des sorties incorrectes. Les métriques agrégées protègent contre les défaillances évidentes. La décomposition par requête protège contre les défaillances non évidentes.

Screen 15: The 50-session winner that wasn't

Watch OutA/B & Obs5 min Le gagnant de 50 sessions qui n'était pas

Pourquoi cette erreur est facile à faire Exécuter un test A/B approprié prend du temps, nécessite un calcul de taille d'échantillon, et peut prendre des jours ou des semaines pour atteindre la signification. Comparer 50 sessions de la nouvelle version à 50 sessions de l'ancienne version prend un après-midi. Une comparaison de 50 sessions qui ressemble à positive est une vérification de confirmation plutôt qu'un test significatif. L'échantillon est trop petit pour distinguer le signal du bruit.

Le changement de prompt qui ressemblait à une victoire Ce qui suit est un composite représentant un modèle qui apparaît dans les équipes qui ont un système fonctionnant et veulent l'améliorer mais n'ont pas de processus d'expérimentation formel. Une équipe exécutant un agent de service client voulait tester une instruction révisée dans le prompt système. Ils ont exécuté la nouvelle version par rapport à 50 sessions client et l'ancienne version par rapport à 50 sessions. Le taux de succès de la tâche était de 68% sur la nouvelle version et de 62% sur l'ancienne version. Ils ont déclaré la nouvelle version gagnante et l'ont déployée. Deux semaines plus tard, le taux de succès de la tâche sur la nouvelle version s'était stabilisé à 61%. Le gain apparent de 6 points avait disparu.

Ce qui a cassé La comparaison avait trois problèmes, dont n'importe lequel était suffisant pour invalider le résultat.

La taille d'échantillon était trop petite. Une différence de 6 points sur une métrique avec une variance élevée nécessite une taille d'échantillon dans les centaines pour atteindre la signification statistique. À 50 sessions par groupe, la différence observée était dans le plancher de bruit. La distribution d'entrée n'était pas contrôlée. Les 50 sessions du groupe de traitement se sont trouvées contenir moins d'entrées de cas limites que les 50 sessions du groupe de contrôle. L'amélioration apparente était en partie un artefact de quelles entrées ont été acheminées vers quel groupe. La métrique primaire n'était pas pré-spécifiée. L'équipe a comparé le taux de succès de la tâche parce qu'il s'est déplacé dans la bonne direction. S'il s'était déplacé dans la mauvaise direction, ils auraient regardé une autre métrique. Sélectionner la métrique après avoir vu le résultat transforme un test en une recherche de quelle métrique s'est déplacée.

Ce qu'il faut surveiller Une expérience sous-alimentée avec sélection de métrique après le fait produit une confirmation plutôt que des preuves, car le résultat reflète l'hypothèse avec laquelle vous avez commencé. Le résultat était du bruit, et le bruit ressemblait à un signal parce que l'échantillon était trop petit pour faire la différence.

Screen 16: Place on the experiment-design plane

CheckpointA/B & Obs5 min Placer sur le plan de conception d'expérience Le plan ci-dessous a deux axes : la taille d'effet attendue (quelle grande différence vous vous attendez à voir) et l'exigence de confiance (à quel point vous devez être certain avant d'agir sur le résultat). Placez chaque scénario dans la zone correcte. Le placement correct détermine la bonne posture expérimentale, qui à son tour détermine la taille d'échantillon minimale.

A. Un changement mineur de formulation dans un message de clarification dans un chatbot FAQ à faible enjeu. B. Un changement d'architecture de prompt pour un résumeur d'admission médicale où une erreur pourrait retarder le traitement. C. Ajouter une nouvelle catégorie de classification à un modèle de routage censé capturer 30% du volume entrant. D. Tester si passer de Sonnet à Haiku sur une tâche de formatage simple économise du coût sans dégrader la qualité. E. Un petit changement au prompt de récupération dans un système RAG traitant 200 requêtes par jour.

← Petit effet Grand effet →

↑ La confiance augmente

Confiance élevée

Petit effet · Confiance élevée

Grand effet · Confiance élevée

Confiance modérée

Petit effet · Confiance modérée

Grand effet · Confiance modérée

Confiance basse

Petit effet · Confiance basse

Non utilisé dans cet exercice

Vérifier les réponses Ignorer pour l'instant

Screen 17: Exercise: define the evaluation framework

ExerciseEvals8 min Exercice : définir le cadre d'évaluation Le briefUn assureur régional déploie un système Claude qui lit une réclamation soumise, extrait les champs structurés (déclarant, numéro de police, montant de la perte, date de la perte), résume la narration pour un ajusteur, et signale les réclamations qui peuvent justifier un examen de fraude. Le système doit répondre en quelques secondes, rester dans un coût défini par réclamation, ne jamais fuir les données d'un déclarant dans le résumé d'un autre, et ne jamais auto-refuser une réclamation. Rédigez le cadre d'évaluation pour ce système. Pour chacune des cinq dimensions ci-dessous, écrivez la métrique, la méthode de notation (eval basée sur le code, juge LLM, ou examen humain), et une phrase expliquant votre choix. Écrivez votre cadre, puis révélez la réponse modèle ci-dessous pour comparer avec votre réponse. [Cliquez pour révéler une réponse à comparer avec votre réponse ; n'hésitez pas à demander à Claude de comparer ce que vous avez écrit avec la réponse fournie. ]

• Exactitude : extraction de champs

• Latence : temps de réponse

• Sécurité : fidélité du résumé et pas d'auto-refus

• Sécurité : pas de fuite de données entre déclarants

• Coût : dépense par réclamation

Révéler la réponse modèle Ignorer pour l'instant

Réponse modèle

• Exactitude, extraction de champs : Eval basée sur le code. Les valeurs attendues (nom du déclarant, numéro de police, montant de la perte, date de la perte) sont connues et vérifiables par correspondance exacte ou de schéma. Aucune interprétation requise ; une fonction vérifie la sortie par rapport à la vérité de terrain.
• Latence, temps de réponse : Eval basée sur le code. La latence p95 est un nombre. La vérification est de savoir si elle tombe en dessous de la cible. Aucun jugement impliqué.
• Sécurité, fidélité du résumé et pas d'auto-refus : Deux méthodes requises. Eval basée sur le code pour l'action de refus (binaire, soit un refus a été émis, soit il ne l'a pas été). Juge LLM pour la fidélité du résumé (si la narration représente avec exactitude la réclamation source sans fabrication est une tâche interprétative qu'une fonction ne peut pas encoder).
• Sécurité, pas de fuite de données entre déclarants : Eval basée sur le code. La fuite entre déclarants peut être vérifiée en scannant chaque résumé pour les identifiants qui apparaissent dans toute réclamation d'entrée autre que celle en cours de traitement. Vérification déterministe, aucune interprétation nécessaire.
• Coût, dépense par réclamation : Eval basée sur le code. Le coût est une valeur numérique dérivée des tokens d'entrée, des tokens de sortie, du niveau de modèle, et de si la mise en cache des prompts s'applique. La vérification est de savoir si elle dépasse le plafond.

Correct : Vous avez appliqué l'échelle de notation correctement sur les cinq dimensions. Les mouvements distinctifs : diviser la dimension 3 en code pour l'action et juge pour la fidélité, et garder la sécurité en code parce que la vérification est déterministe malgré les enjeux élevés. Partiellement correct : Au moins une dimension est mal appariée. Les erreurs les plus courantes : utiliser un juge pour l'extraction de champs (c'est déterministe, le code le gère), et traiter la vérification d'auto-refus comme interprétative (c'est binaire, le code le gère). Relisez le tableau des evals basées sur le modèle par rapport aux evals basées sur le code et révisez. Incorrect : Relisez l'échelle de notation : utilisez le code où le comportement est sans ambiguïté (valeur connue, vérification binaire, seuil numérique) ; utilisez un juge où la correction nécessite une interprétation. Appliquez cette question à chaque dimension et refaites. Ignorer : Passez si vous avez besoin, mais la tâche cumulative vous demande de concevoir une stratégie d'eval à partir de zéro. Revenez avant cela. Marquer comme complet quand vous êtes satisfait de votre auto-évaluation.

Marquer comme complet

Screen 18: Production readiness builder

CumulativeModule13 min Constructeur de préparation à la production Le briefUn cabinet de conseil de 600 personnes veut déployer un assistant de connaissance interne. L'assistant devrait aider les consultants à récupérer les extraits pertinents des rapports d'engagement passés, répondre aux questions sur les méthodologies du cabinet, et générer les premières versions des réponses aux RFP des clients en utilisant le travail passé comme source. Le corpus de connaissance est de 12 000 documents, allant de 5 à 80 pages chacun. Les consultants utilisent l'assistant pendant les engagements actifs, avec un pic d'utilisation de 800 requêtes par jour. Le cabinet a un plafond de coût de 3 000 $/mois. Le temps de réponse doit être inférieur à 8 secondes à p95. Le cabinet a un système SSO existant (par exemple, Okta ou autres) et un système de gestion de documents (par exemple, SharePoint ou autres). Plusieurs documents contiennent des informations confidentielles des clients soumises à un NDA. Cliquez pour révéler les réponses à comparer avec vos réponses ; n'hésitez pas à demander à Claude de comparer ce que vous avez écrit avec la réponse fournie.

Décision 1, Stratégie d'eval. Avant que la construction ne commence, vous devez définir ce que le succès ressemble pour ce système. Quelle est votre tâche d'eval primaire ? Comment allez-vous mesurer la pertinence de récupération et la qualité du brouillon RFP ? Quel type d'eval utilisez-vous pour chacun ? Nommez un comportement adapté à une eval basée sur le code et un adapté à un juge modèle. Quelle est votre stratégie d'ensemble de données doré ? Comment allez-vous gérer la contrainte de confidentialité des clients ?

Décision 2, Liste de contrôle POC-to-production. Vous avez un prototype fonctionnant. Que devez-vous vérifier avant que le cabinet ne s'engage au déploiement ? Construisez un modèle de coût pour le scénario. La projection de coût tombe-t-elle dans le plafond de 3 000 $/mois ? Quel modèle de fiabilité est le plus critique pour ce déploiement et pourquoi ? Nommez le mode de défaillance spécifique à ce type d'architecture dont vous êtes le plus préoccupé.

Décision 3, Dimensionnement et faisabilité du cas d'usage. Exécutez le cas d'usage à travers les quatre propriétés IA. Est-ce faisable tel que délimité ? Appliquez l'axe de mémoire de travail. Les documents de 80 pages présentent-ils une contrainte ? Appliquez l'axe de connaissance. Les méthodologies propriétaires du cabinet ne sont pas dans les données d'entraînement. Quelle est l'atténuation ? Énoncez le verdict de faisabilité et nommez la condition limite porteuse de charge.

Décision 4, Sélection du modèle d'intégration. Le cabinet a Okta SSO et SharePoint. Où se situe la limite d'identité Okta par rapport à l'appel Claude ? Les documents dans SharePoint incluent des fichiers confidentiels des clients, comment gérez-vous la contrainte de gestion des données ? Que instrumentez-vous pour l'observabilité ?

Décision 5, Posture de test A/B. Le cabinet veut tester une nouvelle configuration de récupération qu'il croit améliorera la qualité du brouillon RFP. Encadrez l'hypothèse. Quel est le traitement, la métrique primaire, et la contrainte sur les métriques secondaires ? Estimez la taille d'échantillon requise. La base de taux de succès de la tâche est de 70% et vous voulez détecter une amélioration de 5 points. Que signifie cela pour la durée de l'expérience à 800 requêtes par jour ? Quel contrôle de distribution d'entrée avez-vous besoin compte tenu de la structure du corpus ?

Révéler la réponse modèle Ignorer pour l'instant

Réponse modèle Décision 1, Stratégie d'eval : Eval basée sur le code : conformité de schéma sur les citations extraites (nom du document, numéro de page, section). Eval basée sur le modèle : pertinence et appropriatesse de la réponse au brouillon RFP. Ensemble de données doré : construit à partir des RFP passés avec les noms des clients redactés, provenant des engagements historiques du cabinet. Les documents confidentiels des clients sont exclus de l'ensemble d'eval sauf si le client a donné une approbation explicite. Décision 2, Liste de contrôle POC-to-production : Modèle de coût : 800 requêtes/jour × 30 jours = 24 000 requêtes/mois. Prompt système ~2 000 tokens (aperçu de méthodologie + instructions) + contexte récupéré ~3 000 tokens + requête ~200 tokens = ~5 200 tokens d'entrée. Sortie ~600 tokens. Au niveau Sonnet avec mise en cache sur le prompt système stable, le coût projeté est dans la plage. Ce sont des moyennes plates, et la réponse devrait le clarifier : la projection suppose que les requêtes se regroupent près de la moyenne sans queue lourde. Le corpus s'étend de 5 à 80 pages, donc la taille du contexte récupéré est probablement bimodale, et une queue de grandes requêtes d'extrait sous-estime le coût d'entrée sur un modèle de moyenne plate. Le verdict dans le plafond tient sous la distribution supposée et devrait être vérifié avec l'analyse de sensibilité du cluster de dimensionnement avant d'être fiable. Fiabilité : chaîne de fallback de Sonnet à Haiku pour les pics de latence. Mode de défaillance le plus critique : dérive de la qualité de récupération à mesure que les documents sont ajoutés au corpus. Si les nouveaux documents sont indexés de manière incohérente, la précision de récupération se dégrade et la qualité du brouillon se dégrade avec elle. Décision 3, Dimensionnement et faisabilité du cas d'usage : Mémoire de travail : Aucun document individuel dans ce corpus (jusqu'à 80 pages, environ 29 000 tokens) ne dépasse la fenêtre de contexte Claude actuelle de 1 million de tokens sur la plupart des niveaux de modèle actuels. La contrainte de mémoire de travail porteuse de charge est l'échelle du corpus : 12 000 documents ne peuvent pas être chargés dans le contexte simultanément. C'est ce qui conduit l'architecture RAG. À ~29 000 tokens par document de 80 pages, un seul document à la longueur maximale s'adapte bien dans la fenêtre de contexte et ne présente pas une contrainte de mémoire de travail en soi. Sur l'ensemble du corpus de 12 000 documents, la longueur moyenne du document sur la plage de 5–80 pages est d'environ 14 600 tokens. Le corpus total représente environ 175 millions de tokens. Cela dépasse de loin toute fenêtre de contexte. Pour les documents individuels dans cette plage de taille, les stratégies de chunking sont disponibles mais ne sont pas la contrainte porteuse de charge ici. L'architecture nécessite une couche de récupération pour faire surface les extraits pertinents au moment de la requête. Connaissance : Les méthodologies propriétaires du cabinet ne sont pas dans les données d'entraînement de Claude, ce qui signifie que le modèle ne peut pas les fournir de la mémoire. L'atténuation est la récupération : les documents de méthodologie sont indexés dans la même couche RAG que les rapports d'engagement et sont mis en surface dans la fenêtre de contexte au moment de la requête quand une question est pertinente pour eux. C'est le contrôle compensatoire standard pour les lacunes de connaissance sur le contenu spécifique au domaine. Le système n'a pas besoin que Claude connaisse les méthodologies ; il a besoin que Claude raisonne sur les extraits de méthodologie que la couche de récupération met devant lui. La contrainte est que la qualité de récupération doit être suffisamment élevée pour faire surface le contenu de méthodologie correct pour une requête donnée. Si la récupération manque la section pertinente, la réponse sera incomplète indépendamment de la qualité du raisonnement du modèle sur ce qu'il reçoit. La précision de récupération sur les requêtes de méthodologie devrait être suivie comme une métrique séparée dans la suite d'eval et dans l'observabilité de production. Verdict de faisabilité : Faisable avec contraintes. Les quatre axes de propriété IA sont adressables dans l'architecture délimitée. Les contraintes de mémoire de travail sont résolues par la couche RAG. Les lacunes de connaissance sur les méthodologies propriétaires sont résolues par l'indexation de ces documents dans le même corpus de récupération. L'exigence de steerability est satisfaite par la structure du prompt système et le schéma de sortie pour les brouillons RFP. La condition limite porteuse de charge est la couverture et la fraîcheur de l'index de récupération. Le système fonctionne tant que l'index de récupération contient les documents de méthodologie et d'engagement pertinents et est tenu à jour à mesure que le corpus change. Si l'index est incomplet, si les documents sont ajoutés sans être indexés, ou si l'index se désynchronise avec le système de gestion de documents, l'atténuation de l'axe de connaissance échoue et le système produira des réponses qui omettent ou mal représentent la méthodologie du cabinet. Cette condition doit être documentée comme une contrainte opérationnelle explicite dans la déclaration de travail. Décision 4, Sélection du modèle d'intégration : Identité : Le token Okta est vérifié côté serveur. Le rôle utilisateur et les ensembles de documents autorisés sont injectés dans le prompt système par le serveur, pas fournis par l'utilisateur. Gestion des données confidentielles : les documents marqués comme confidentiels dans SharePoint ne sont récupérables que par les consultants dont le rôle inclut l'engagement client pertinent. La couche de récupération applique ce contrôle d'accès avant de passer le contenu à Claude. PII : les noms des clients dans les documents sont remplacés par des identifiants anonymisés avant que le document n'entre dans la fenêtre de contexte. Observabilité : enregistrez la version du modèle, le nombre de tokens d'entrée (avec hit/miss de mise en cache), la précision de récupération par requête (mesurée par rapport aux documents de base), et le nombre de tokens de sortie. Enregistrez le rôle utilisateur et l'ID de session au niveau du contexte. Capturez l'acceptation ou la révision du brouillon RFP par le consultant comme le signal de résultat. Alertez si la latence p95 franchit 8 secondes et si la précision de récupération tombe en dessous du seuil. Décision 5, Posture de test A/B : Hypothèse : La nouvelle configuration de récupération augmentera le taux de succès du brouillon RFP (mesuré par l'acceptation du consultant du brouillon sans révision majeure) de 70% à au moins 75%, sans augmenter la latence p95 au-dessus de 8 secondes ou le coût par requête de plus de 10%. Taille d'échantillon : détecter une amélioration de 5 points à une base de 70% avec une puissance de 80% et une signification de 5% nécessite environ 1 500 sessions par groupe. À 800 requêtes par jour divisées uniformément, cela prend environ 4 jours, ce qui est faisable. Contrôle de distribution d'entrée : assurez-vous que les groupes de traitement et de contrôle ont des distributions similaires de complexité RFP (proxy : longueur du document et nombre de documents source récupérés). Segmentez par type RFP si possible.

Comparez vos réponses sur les cinq décisions. Les réponses fortes nomment des chiffres spécifiques (modèle de coût, corpus de ~175M-token, 1 500 sessions/groupe, ~4 jours) et lient chaque décision à la suivante : le modèle de dimensionnement alimente le plafond de coût, la condition limite de faisabilité (couverture et fraîcheur de récupération) alimente l'observabilité, et l'eval alimente la métrique primaire A/B.

Marquer comme complet

Screen 19: Glossary

ReferenceWrap-up 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.

Erreurs 5xxLa classe des codes de statut HTTP (500–599) indiquant une défaillance côté serveur pour remplir une requête autrement valide. Les exemples courants incluent 500 (Erreur interne du serveur), 503 (Service indisponible) et 529 (Erreur de surcharge). Généralement transitoires et résolubles avec retry et backoff, distincts des codes 4xx qui indiquent un problème côté client. BAA (Business Associate Agreement)Un contrat requis selon HIPAA entre une entité couverte (ou associé commercial) et un fournisseur qui gère les informations de santé protégées en son nom. La BAA spécifie les garanties que le fournisseur appliquera à PHI. Pour les déploiements Claude, la couverture BAA est spécifique à la configuration : la même surface peut être couverte par BAA sur une route de livraison et pas sur une autre. Vérifiez la couverture par configuration, pas par produit. Mise en cacheLa mise en cache stocke le contenu de prompt réutilisable de sorte que le système n'a pas besoin de le retraiter à chaque requête. Elle est plus efficace quand le prompt système est long et stable, réduisant à la fois le coût de token et la latence de réponse ; la réponse que vous recevez est identique à ce que vous obtiendriez sans mise en cache. Circuit breakerUn contrôle de fiabilité qui surveille le taux d'erreur sur une dépendance en aval et, quand les erreurs dépassent un seuil défini, bloque les requêtes supplémentaires à cette dépendance pendant une fenêtre de refroidissement de sorte qu'un composant dégradé ne consomme pas la capacité du système appelant. Se situe à la limite du service, distinct des retries (près de l'appel API) et des chaînes de fallback (dans la couche d'orchestration). Pinning de résidence des donnéesConfigurer l'intégration de sorte que l'exécution du modèle se produit dans une région géographique spécifiée, généralement pour satisfaire les réglementations sectorielles, ou la politique de résidence des données interne. Le pinning est implémenté au niveau de la route de livraison sur les intégrations médiées par CSP. Le pin doit être défini au niveau de l'intégration et vérifié à chaque requête, pas supposé par le choix du point d'entrée seul. DPA (Data Processing Agreement)Un contrat entre un contrôleur de données et un processeur de données définissant comment les données personnelles peuvent être gérées au nom du contrôleur, y compris la portée du traitement, les obligations de sécurité, les termes des sous-processeurs, et la notification de violation. EvalUn ensemble de test structuré utilisé pour mesurer si un modèle fonctionne suffisamment bien sur une tâche définie. Une eval apparie les entrées avec les sorties attendues ou les critères de qualité, les exécute par rapport au modèle, et produit un score que vous pouvez comparer sur les versions de modèle, les prompts, ou les configurations. Les evals sont comment les équipes décident si un changement est une amélioration ou une régression avant qu'il n'atteigne la production. Backoff exponentielleLe backoff exponentiel est une stratégie de retry où, après une requête échouée, le système attend avant de réessayer et chaque attente successive est plus longue que la dernière, généralement en doublant à chaque fois. GDPR (Règlement général sur la protection des données)La réglementation de l'Union européenne (UE) régissant le traitement des données personnelles des individus dans l'UE et l'Espace économique européen (EEE). Établit les exigences de base légale, les droits des sujets de données, les obligations des contrôleurs et des processeurs, et les amendes jusqu'à 4% du chiffre d'affaires annuel mondial. Boucle générateur-vérificateurUn modèle à deux étapes dans lequel une sortie générée par un modèle est vérifiée par une deuxième passe avant d'être utilisée en aval. Le vérificateur peut être une vérification déterministe basée sur le code (validation de schéma, comparaison par rapport à une valeur faisant autorité) ou un deuxième appel de modèle délimité à l'évaluation. Utilisé comme contrôle compensatoire où la tâche sous-jacente nécessite plus de précision que la génération à passe unique fournit de manière fiable. Taux d'hallucination Le pourcentage de réponses dans lesquelles le modèle a inventé, déduit, ou énoncé des informations qui n'étaient pas soutenues par l'entrée, les données source, ou la logique autorisée. É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 nombre 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 bonne réponse à 10h00 peut être fausse à 10h05. Les systèmes qui ont besoin d'état en direct nécessitent une recherche directe par rapport à la source de vérité, pas un snapshot stocké. Latence médianeLa latence médiane est le temps qu'il faut pour compléter la requête du milieu dans la distribution, ce qui signifie que 50% des requêtes sont plus rapides et 50% sont plus lentes. Elle est aussi appelée latence p50. p95 (latence du 95e percentile)La valeur de latence en dessous de laquelle 95% des requêtes se terminent, avec les 5% les plus lents tombant au-dessus. Utilisée comme cible de conception de production parce que les violations d'accord de niveau de service et l'abandon des utilisateurs sont conduits par la queue lente de la distribution plutôt que par la médiane. PHI (Informations de santé protégées)Les informations de santé individuellement identifiables détenues ou transmises par une entité couverte ou un associé commercial selon la Loi américaine sur la portabilité et la responsabilité de l'assurance maladie (HIPAA). Le traitement de PHI nécessite un Business Associate Agreement avec tout tiers qui le gère. RAG (retrieval-augmented generation)Un modèle dans lequel un corpus de connaissance est chunké et indexé dans une étape de prétraitement, et au moment de la requête les chunks les plus pertinents à l'entrée utilisateur sont récupérés et passés dans le contexte du modèle. Adapté à la connaissance statique ou à mouvement lent telle que les manuels, la documentation interne, et le texte réglementaire. Pas adapté à l'état transactionnel en direct, où la récupération retourne un snapshot qui peut déjà être obsolète et un appel d'outil au système d'enregistrement est le mécanisme correct. Limite de débitUn plafond appliqué par le serveur sur le nombre de requêtes qu'un client peut faire dans une fenêtre de temps définie. Quand le plafond est dépassé, le serveur rejette les requêtes supplémentaires (généralement avec HTTP 429) jusqu'à ce que la fenêtre se réinitialise. Une réponse de limite de débit indique la limitation plutôt que la défaillance et est une condition transitoire qui se résout avec le backoff. RegexRegex signifie expression régulière. C'est une règle basée sur un modèle utilisée pour trouver ou valider du texte qui correspond à un format spécifique, tels que les adresses e-mail, les numéros de téléphone, les numéros de sécurité sociale, ou les modèles de numéro de carte de crédit. SchémaLa structure, le format, et les règles requis pour la sortie. Cela définit quels champs doivent apparaître, leurs types de données, les valeurs autorisées, et comment la réponse devrait être organisée. SSO (single sign-on)Un arrangement d'authentification dans lequel un utilisateur se connecte une fois à un fournisseur d'identité central et gagne l'accès à plusieurs applications en aval sans se réauthentifier. Champs structurésCes champs qui nécessitent des sorties spécifiques qui doivent être remplies dans un format défini, tels que le nom du client, le numéro de facture, la date, le montant, ou l'ID de police. Ce sont des éléments de données discrets, pas du texte narratif en forme libre. TimeoutUn mode de défaillance dans lequel une requête ne reçoit pas de réponse dans la période d'attente configurée du client ou du serveur et est terminée. Généralement causée par la charge transitoire du serveur, la latence du réseau, ou une dépendance en aval sous stress, plutôt qu'une défaillance permanente. Utilisation d'outilsLa capacité qui permet à Claude d'appeler des fonctions externes, des API, ou des services pendant une réponse au lieu de générer seulement 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 des fichiers, interroger des bases de données, rechercher le web, ou prendre des mesures dans d'autres logiciels. Erreur transitoireUne erreur transitoire est une défaillance temporaire qui devrait se résoudre d'elle-même sans aucun correctif permanent, ce qui signifie que si vous réessayez la même requête après une courte attente, elle réussira probablement.

Screen 20: Five takeaways

RecapModule3 min Cinq points clés

Points clés :

01

Evals comme critères d'acceptation Écrivez la suite d'evals avant le code de production. Gardez l'ensemble de données doré à jour avec chaque changement système. Utilisez l'eval comme porte pour chaque échange de modèle ou révision de prompt.

02

POC à production Estimez le coût et la latence au volume de production avant de vous engager dans l'architecture. Construisez les retries, les chaînes de fallback, et les circuit breakers dans la conception initiale. Nommez le mode de défaillance spécifique à votre type d'architecture et documentez l'atténuation.

03

Dimensionnement et faisabilité du cas d'usage Exécutez chaque nouveau cas d'usage à travers les quatre propriétés IA avant d'émettre un verdict de faisabilité. Énoncez le verdict dans l'une des trois formes : faisable tel que délimité, faisable avec contraintes, ou non faisable. Documentez la condition limite porteuse de charge pour chaque verdict contraint.

04

Modèles d'intégration d'entreprise Appliquez l'identité au côté serveur. Passez seulement les données minimales nécessaires dans la fenêtre de contexte. Construisez l'instrumentation d'observabilité au moment de la conception, pas après le premier incident.

05

Tests A/B et observabilité Identifiez la métrique primaire et la taille d'échantillon avant d'exécuter une expérience. À l'échelle, séparez l'observabilité par requête des tableaux de bord agrégés. Construisez une couche de traduction qui mappe les métriques techniques aux métriques métier que le stakeholder se soucie.

Le Module 3 couvre l'IA responsable, la sécurité, et le risque pour les Architectes : conception de garde-fous, considérations du secteur réglementé, et stratégies de validation humaine dans la boucle.

Sources

Anthropic Skilljar, Building with the Claude API: étapes du flux de travail d'eval, evals basées sur le modèle par rapport aux evals basées sur le code, modélisation du coût et de la latence, mise en cache, utilisation d'outils, streaming. Anthropic Skilljar, Claude 101: aperçu de la famille de modèles, fenêtres de contexte, capacités générales de Claude. Anthropic Skilljar, Claude Code in Action: Claude Code comme point d'entrée d'intégration, modèles agentic en pratique. Anthropic Skilljar, AI Capabilities and Limitations: cadre des quatre propriétés IA, concepts fondamentaux. platform. claude. com/docs: page d'aperçu des modèles (chiffres de capacité et de fenêtre de contexte), page de tarification (points de prix par token pour la modélisation des coûts), et page de mise en cache des prompts (mécanique de mise en cache et conseils de risque de cohérence). Anthropic, Building Effective Agents: modèles de conception de flux de travail et d'agent ; quand utiliser les agents par rapport aux architectures plus simples. Anthropic Cookbook: candidats de mode de défaillance et modèles travaillés.

Screen 21: Congratulations! You have successfully completed this module.

Module Complete · Architect · 2 min Félicitations ! Vous avez réussi à compléter ce module. Le Module 2 couvre les modèles d'intégration, l'infrastructure de production, et les décisions opérationnelles qui prennent un déploiement Claude du prototype à l'échelle d'entreprise. La fiabilité de production est une décision d'architecture, pas une décision opérationnelle ; vous avez maintenant les modèles pour la prendre au moment de la conception.

0 de 0 points de contrôle réussis

M1

Plateforme Claude et conception de solution Sélection de modèle, architecture de prompt, conception d'outils, et compromis au niveau de la plateforme.

M2

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

Vous êtes ici

M3

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

Suivant

M4

Engagement des parties prenantes, cycle de vie et go-to-market Communication des parties prenantes, gestion du cycle de vie, et stratégie go-to-market.

M5

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

Examiner le module Recommencer