Accélérateurs et contribution IP — Claude Certified Developer Foundations Prep Course

Écran 1 : Ce que vous serez capable de faire à la fin

ORIENTATION MODULE DÉVELOPPEUR 5 · 2 MIN Ce que vous serez capable de faire à la fin

Documentez bien la build et que l'engagement suivant s'en serve plutôt que de repartir de zéro.

Au cours des trois derniers modules, vous avez construit un agent de production, l'avez intégré à Claude Code avec les bons contrôles de permission et de contexte, et configuré les connexions MCP qui passent un audit de sécurité. Chacune de ces étapes était une build fonctionnelle.

Ce module couvre ce qui se passe après qu'une build fonctionne. Soit vous la reconstruisez de zéro lors de l'engagement suivant, soit vous l'emballez une fois, et l'équipe suivante la configure simplement. Le deuxième chemin est celui qui libère votre temps pour de nouveaux travaux au lieu de reconstructions répétées.

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

1 Empaqueter une solution fonctionnelle en tant qu'accélérateur réutilisable, qu'il s'agisse d'un modèle d'agent paramétré, d'un serveur MCP configurable ou d'une suite d'eval portable, afin que l'engagement suivant configure un actif plutôt que de le reconstruire entièrement. 2 Contribuer un outil, un motif ou une correction via les canaux documentés et le préparer pour qu'un responsable puisse l'accepter, transformant un actif privé en infrastructure partagée. 3 Choisir où une charge de travail Claude s'exécute parmi l'API propriétaire, Amazon Bedrock, Google Vertex AI et les plateformes tierces, et versionnez ce qui est livré afin qu'un changement de modèle ou de prompt ne casse pas silencieusement la production. 4 Comparer ces plateformes sur la latence, la conformité et le coût afin que le choix soit celui qu'une équipe d'approvisionnement et de sécurité peut approuver, plutôt qu'un défaut que votre équipe a choisi par défaut. 5 Construire une application qui coordonne plusieurs déploiements Claude en un seul flux de travail et le délimiter afin que les limites de données et d'identité soient maintenues lors d'un audit de sécurité ou de conformité.

Ce module s'adresse au Développeur qui a une build fonctionnelle et qui doit maintenant la rendre durable. Vous êtes pragmatique, orienté code et orienté motifs, et les modules précédents l'ont supposé et construit dessus. À ce stade, vous pouvez écrire un agent de production, le configurer dans Claude Code, câbler les connexions MCP qui passent un audit de sécurité et le prouver avec des evals. Ce module ne réenseigne rien de tout cela. Il reprend au moment où votre code s'exécute correctement et pose la question plus difficile : quelqu'un d'autre peut-il le réutiliser, un responsable peut-il l'accepter, peut-il survivre à une mise à jour de modèle, et une équipe de sécurité ou d'approvisionnement peut-elle approuver où il s'exécute. Le travail ici porte moins sur l'écriture de code et plus sur les décisions qui rendent le code fini réutilisable, déployable et défendable pour les personnes qui ne l'ont pas écrit.

« LA BUILD » DANS CE MODULE

Tout dans ce module repose sur une lacune récurrente : une build qui fonctionne n'est pas encore une build qui survit à la réutilisation, à l'examen ou au déploiement. En développement, le modèle s'exécutait, la contribution résolvait votre problème, le modèle répondait, la plateforme était facile à construire, et chaque plateforme passait ses propres tests. Rien de cela n'est l'état final. Le même modèle doit être configuré pour une équipe qui ne vous a jamais parlé. La même contribution doit être vérifiable par un responsable qui ne doit rien reconstruire. Le même modèle doit être épinglé afin qu'un changement en amont soit une décision plutôt qu'une surprise. La même plateforme doit passer l'examen de résidence et de conformité d'un client. Les mêmes plateformes connectées doivent maintenir leurs limites de confiance lors d'un audit. Chaque sujet dans ce module est une version différente de la même leçon : le point où le code commence à fonctionner est où le travail de ce module commence. Plus de ces décisions que vous pourriez l'imaginer sont pilotées par le cloud existant du client, sa posture de conformité et son processus d'examen.

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

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

Écran 2 : Empaqueter une build fonctionnelle pour que l'engagement suivant commence par un actif

EnseignementEmballage pour réutilisation·16 min Empaqueter une build fonctionnelle pour que l'engagement suivant commence par un actif Vous avez terminé les modules précédents avec une build qui s'exécute : une boucle d'agent, un serveur MCP configuré, un eval qui prouve que le prompt fonctionne. La chose la plus chronophage et coûteuse pour une équipe est le temps d'ingénierie dépensé pour reconstruire la même chose pour le client suivant. Ce qu'un accélérateur fait : conserver les parties réutilisables et séparer le reste Un accélérateur est une solution emballée afin que les engagements futurs commencent par une base fonctionnelle plutôt que par un référentiel vierge. En termes de plan, c'est l'emballage pour réutilisation : séparer le code spécifique à l'engagement du noyau réutilisable et paramétrer le reste. Prenez une build fonctionnelle, séparez les parties spécifiques au client, et exposez-les en tant que paramètres avec des valeurs par défaut documentées. L'actif se configure alors plutôt que d'être entièrement réécrit. L'emballage pour réutilisation pendant que la build est fraîche est moins cher que de reconstruire l'intention des mois plus tard, quand la personne qui savait pourquoi une valeur était codée en dur a quitté. La plupart du travail réutilisable se divise en différents types d'actifs, et chacun s'emballe différemment La plupart du travail réutilisable se divise en trois catégories utilisées tout au long de ce module : un modèle, un serveur configurable ou un eval portable. Chaque type contient un type de travail différent et doit être emballé de sa propre manière. Choisir le mauvais type peut faire qu'un actif semble réutilisable tout en le rendant difficile à appliquer.

Type d'actifCe qu'il regroupeCe que l'emballage correct exige Modèle d'agentLe prompt système, les schémas d'outils et la structure de boucle d'un agent fonctionnel. Tirez les valeurs spécifiques au domaine dans la configuration avec des valeurs par défaut documentées, afin qu'une nouvelle équipe définisse les valeurs plutôt que de modifier la boucle. Paquet serveur MCPLes outils que le serveur expose, avec leurs entrées et la portée que l'équipe d'installation contrôle. Documentez chaque entrée d'outil et laissez l'équipe d'installation définir la portée, afin que le serveur s'installe dans un nouvel environnement sans modifications de code. Suite d'evalL'ensemble de tests notés et la rubrique du juge qui prouvent que l'actif fonctionne. Livrez l'ensemble de données et la rubrique ensemble afin qu'une nouvelle équipe puisse les exécuter dans son propre contexte et confirmer que l'actif fonctionne toujours là. La même suite d'eval agit également comme la porte au déploiement. Quand vous promouvez une nouvelle version de modèle en production, exécutez-la par rapport à un score de base épinglé avant que la version ne soit mise en ligne.

Livrer un agent en tant qu'ensemble de scripts libres au lieu d'un modèle est la version la plus courante de la mauvaise approche. Les scripts s'exécutent, donc ils semblent réutilisables, mais chaque valeur spécifique au client est enterrée dans un fichier différent, et l'équipe suivante les copie et les diverge au lieu de configurer un actif. Documentez à la fois le code et les hypothèses Le code décrit le comportement. La documentation couvre ce qu'un futur constructeur ne peut pas déduire de manière fiable en lisant la source : les hypothèses que l'actif fait sur son environnement, les entrées qu'il attend, les modes de défaillance qu'il gère déjà, et l'eval qui définit s'il fonctionne toujours. Sans cela, l'équipe suivante traite l'actif comme une boîte noire et le reconstruit. Regroupez le journal d'audit dans le paquet Un examinateur d'un client réglementé demande quelles données l'actif touche, sous quelle identité il agit et quel journal il laisse. Un accélérateur sans ceux-ci passe une démo et s'arrête au premier examen de sécurité. Traitez le journal d'audit comme faisant partie du paquet. La liste de contrôle d'emballage Gardez cette liste de contrôle à côté de la build pendant que vous l'emballez. Chaque colonne est une décision que vous prenez une fois par actif.

Type d'actifQuoi paramétrerQuoi documenterQuoi regrouper pour l'audit Modèle d'agentChaque valeur qui change par client : prompts, chemins, portées, identifiants de credentials par référence, et seuils. Hypothèses d'environnement, entrées attendues, modes de défaillance gérés, et l'eval qui définit le fonctionnement. Les données touchées, l'identité agissant, et le journal de ce que l'actif a fait. Serveur MCPPortées, identifiants de credentials par référence, et chemins par client. Entrées attendues par outil, limites de portée, et modes de défaillance gérés. Les données touchées, l'identité agissant, et le journal de ce que l'actif a fait. Suite d'evalSeuils et chemins d'ensemble de données qui changent par client ou environnement. La logique de la rubrique, ce que les scores signifient, et la base à laquelle l'actif est épinglé. Les données touchées, l'identité agissant, et le journal de ce que l'actif a fait.

Fonctionne bien Paramétrer pendant que la build est fraîche transforme une livraison en un actif que l'engagement suivant configure en heures.

Ajoute du coût ou de la complexité Séparer les parties généralisables des parties spécifiques au client et documenter les hypothèses ajoute du temps réel à la première build.

Utilisez une approche différente Pour un one-off qu'un client ne réutilisera jamais, les frais généraux d'emballage ne valent pas la peine : livrez la build et passez à autre chose.

Écran 3 : Le modèle qui s'est livré rapidement et ne pouvait pas être réutilisé

Attention ! Emballage pour réutilisation·2 min Le modèle qui s'est livré rapidement et ne pouvait pas être réutilisé

Configuration Le codage en dur se livre plus rapidement et vous travailliez sous une date limite, donc vous avez codé en dur les valeurs qui ont fait la démo. Le modèle a fonctionné. C'est exactement pourquoi personne ne l'a regardé à nouveau jusqu'à ce que l'équipe suivante essaie de le réutiliser.

Ceci est une autopsie, écrite de la manière qu'une équipe l'écrit après l'échec d'une tentative de réutilisation, afin que vous puissiez voir l'échec se former avant que quelqu'un ne l'étiquette comme une erreur. Ce qui s'est passé Une équipe a construit un modèle d'agent pour un engagement client et l'a livré à temps. Pour respecter la date limite, les valeurs spécifiques au client sont allées directement dans le code : le chemin du référentiel, le nom du modèle, les seuils d'examen et quelques fragments de prompt spécifiques au domaine de ce client. Le modèle s'exécutait, l'engagement s'est fermé, et la build a été mise dans le référentiel partagé étiqueté comme réutilisable.

Des mois plus tard, une deuxième équipe l'a repris pour un engagement similaire. Ils ne pouvaient pas le configurer, car il n'y avait rien à configurer. Chaque valeur qui devait changer était intégrée dans la boucle où la deuxième équipe ne pouvait pas la voir sans lire le fichier entier. Il n'y avait aucun document disant quelles valeurs étaient spécifiques au client et lesquelles étaient critiques. Il n'y avait pas non plus d'eval regroupé, donc même après avoir deviné les modifications, rien ne confirmait que le modèle fonctionnait toujours dans le nouveau contexte. Ils ont dû le réécrire de zéro.

Pourquoi ça a échoué La build a été traitée comme terminée au moment où elle s'exécutait plutôt qu'au moment où elle pouvait être réutilisée. Le codage en dur était l'appel raisonnable sous une date limite, et il n'a jamais été revisité. Un modèle fonctionnel n'annonce pas qu'il ne peut pas être réutilisé. Le coût n'a apparaître que quand une deuxième équipe a payé pour la reconstruction que l'emballage était censé prévenir, ainsi que le temps qu'elle a perdu en découvrant que le modèle était une impasse.

À quoi faire attention Un modèle qui s'exécute n'a pas été emballé pour réutilisation. Ce sont des états de fin différents. Les signes d'avertissement sont l'absence de trois choses : pas de paramètres où les valeurs spécifiques au client appartiennent, pas de documentation décrivant les hypothèses, et pas d'eval regroupé prouvant que l'actif fonctionne toujours dans un contexte différent. Emballez l'actif pendant que la build est fraîche. La connaissance de ce qui est spécifique au client est la plus chère à reconstruire après que les personnes qui l'avaient ont quitté.

Écran 4 : Point de contrôle 1 : Corriger le modèle d'accélérateur cassé

Point de contrôleEmballage d'un accélérateur réutilisable·4 min Point de contrôle 1 : Corriger le modèle d'accélérateur cassé Essayez maintenant. Ci-dessous se trouve un modèle d'agent qu'une autre équipe est censée réutiliser. Il a un défaut : une valeur spécifique au client est codée en dur où un paramètre appartient. Le modèle tel que livré

def build_review_agent(): return Agent( model="claude-opus-4-8", system_prompt=SYSTEM_PROMPT, tools=[read_file, run_linter], repo_path="/home/acme/checkout-service", # référentiel client ) (Confirmez l'ID de modèle actuel sur platform. claude. com/docs/en/about-claude/models au moment de la build. ) Identifiez la valeur codée en dur, puis écrivez la signature de fonction corrigée et la ligne paramétrée qui la remplace.

Comparer avec la réponse modèle Ignorer pour l'instant

IgnoréPassez si vous devez, mais revenez avant la tâche cumulative. Un point de contrôle ultérieur plante une version de ce même défaut de codage en dur parmi deux autres et est plus difficile à repérer sous une charge multi-couche.

Écran 5 : Déplacer un actif de la réutilisation privée vers l'infrastructure partagée qu'un responsable accepte

EnseignementContribution en retour·12 min Déplacer un actif de la réutilisation privée vers l'infrastructure partagée qu'un responsable accepte Vous avez déjà fait la plupart du travail qui rend un actif partageable. Quand vous l'avez emballé pour que votre propre équipe le réutilise, vous avez extrait les paramètres, écrit les hypothèses et regroupé l'eval. Les paramètres montrent que l'actif peut être configuré plutôt que réécrit. Les hypothèses documentées disent au responsable quel environnement l'actif attend. L'eval regroupé leur donne un moyen de confirmer qu'il fonctionne toujours. Un actif emballé pour réutilisation interne est déjà proche de ce qu'un responsable doit accepter. Le canal de contribution est conçu pour recevoir cet actif emballé. Il porte la version, les étapes d'installation et les composants en tant qu'unité unique, afin qu'une équipe qui ne vous a jamais parlé puisse l'installer et obtenir la même configuration fonctionnelle. Faites correspondre la contribution au canal construit pour elle Contribuer en retour signifie déplacer un actif de la réutilisation privée vers l'infrastructure partagée via un canal documenté. Chaque canal est construit pour un type spécifique de contribution. Le Claude Cookbook est un référentiel GitHub d'implémentations de référence focalisées. Il est conçu pour les implémentations autonomes de motifs simples ou multiples démontrées clairement et fonctionnant de bout en bout. Les serveurs MCP open-source et les outils vivent chacun dans leur propre référentiel avec leurs propres conventions de contribution. Envoyer une application multi-composants complète au Cookbook est une inadéquation. Le référentiel est configuré pour examiner un motif focalisé plutôt qu'une application entière, donc une soumission de cette taille ne correspond pas à ce que les examinateurs recherchent et s'arrêtera. La première étape est de faire correspondre la contribution au canal construit pour elle. Mettre une application complète où un exemple focalisé appartient est l'une des raisons les plus courantes pour lesquelles une contribution n'est jamais examinée. Ce qui rend la vérification d'une contribution possible Un responsable accepte une contribution qu'il peut vérifier. La barre est définie par ce qu'il doit vérifier, pas par la façon dont le code est intelligent. Quatre choses rendent cette vérification possible :

1Le code fait une chose. Une contribution étendue force un examinateur à reconstruire votre intention avant de l'évaluer. 2Un exemple le montre en cours d'exécution. Un examinateur ne devrait pas avoir à construire un harnais pour voir le comportement. 3Un test prouve qu'il fonctionne. Un test permet à un responsable de vérifier le résultat sans reproduire le raisonnement lui-même. 4Une courte déclaration nomme les hypothèses. Sinon, le premier échec devient le problème du responsable.

Les droits et l'attribution viennent avant l'examen technique La licence et l'attribution décident si une contribution peut être acceptée du tout, c'est pourquoi elles viennent avant l'examen technique. Le code apporté d'un engagement client peut avoir des contraintes sur où il peut aller. Confirmer que vous avez le droit de le contribuer et attribuer tout ce sur quoi vous avez construit est une porte que la contribution doit d'abord franchir. Ignorer cela transforme une contribution en problème que l'équipe juridique doit démêler plus tard. L'exemple travaillé ici est le cas de l'agent de service client. Un motif de gestion de conversation réutilisable, construit lors d'un engagement, est dépouillé des spécificités du client et préparé comme un exemple général pour le Cookbook. Le mouvement de contribution en retour est partagé entre les trois rôles de ce curriculum. Votre travail en tant que Développeur est la préparation technique : le code focalisé, l'exemple, le test, les hypothèses et la vérification des droits. Le contexte d'engagement provient de l'équipe plus large. La référence de préparation à la contribution

CanalCe qu'un responsable vérifieLicence et attributionLa barre d'exemple et de test à franchir Cookbook pour un exemple focalisé, ou le référentiel propre de l'outil ou du serveur pour un outil ou une correction. Que le code fasse une chose et qu'ils puissent le lire en entier. Confirmez que vous avez le droit de contribuer du code d'un engagement, avec les travaux antérieurs attribués. Un exemple exécutable plus un test qui prouve le comportement, pas seulement une description de celui-ci.

Fonctionne bien Un actif emballé n'a besoin que de l'exemple, du test et de la vérification des droits pour devenir une infrastructure partagée sur laquelle d'autres construisent.

Ajoute du coût ou de la complexité Franchir la barre du responsable et la porte de licence est du vrai travail en plus de faire fonctionner le code pour vous.

Utilisez une approche différente Quand le code porte une contrainte de licence d'engagement que vous ne pouvez pas franchir, ne le contribuez pas : escaladez vers le propriétaire à la place.

Écran 6 : La demande de tirage qu'un responsable ne pouvait pas vérifier

Attention ! Contribution en retour·2 min La demande de tirage qu'un responsable ne pouvait pas vérifier

Configuration Vous avez ouvert la contribution avec le code exact qui a résolu votre problème. C'était le choix naturel car il fonctionnait dans votre cas et il était accessible. Il a fonctionné pour vous, mais c'est précisément pourquoi il manquait tout ce dont un étranger a besoin pour lui faire confiance.

Ceci est un échange d'un canal interne afin que vous puissiez entendre comment un responsable explique le silence sur une demande de tirage. L'échange Développeur : Ma PR est ouverte depuis trois semaines sans examen. Le code fonctionne, je l'utilise tous les jours. Quel est le problème ? Responsable : Ça fonctionne probablement pour vous. Le problème est que je ne peux pas le dire. Il n'y a pas de test que je peux exécuter, pas d'exemple qui prouve le comportement, et rien ne dit ce qu'il suppose sur l'environnement. Développeur : Donc, vous voulez que j'ajoute un test et un exemple ? Responsable : Oui. Une contribution qu'un examinateur ne peut pas vérifier s'assoit à l'arrière de la file d'attente jusqu'à ce que quelqu'un ait le temps de reconstruire ce qu'elle fait. Une PR focalisée avec un test et un exemple est examinée rapidement car il n'y a rien à laisser pour que je fasse de l'ingénierie inverse.

Pourquoi ça a échoué Le code était correct. La contribution s'est arrêtée car le responsable ne pouvait pas la vérifier sans reconstruire le travail du développeur. Cet écart est facile à négliger car l'auteur a déjà le contexte manquant. L'exemple, le test et la déclaration d'hypothèses semblent tous évidents à la personne qui a créé le code. Pour le responsable, cependant, ils ne le sont pas, et un examinateur qui doit reconstruire l'intention le fera toujours en dernier.

À quoi faire attention Une demande de tirage s'arrête sur ce que l'examinateur ne peut pas vérifier. Avant d'ouvrir une contribution, ajoutez l'exemple qui le montre en cours d'exécution, le test qui prouve le comportement et la courte déclaration nommant ce qu'il suppose. Ces trois caractéristiques sont ce qui déplace une contribution de l'arrière de la file d'attente vers un examen rapide, car elles laissent au responsable rien à faire de l'ingénierie inverse.

Écran 7 : Point de contrôle 2 : Choisir le canal de contribution et la correction de préparation

Point de contrôleContribution en retour à l'écosystème·3 min Point de contrôle 2 : Choisir le canal de contribution et la correction de préparation Essayez maintenant. Lisez les trois cas ci-dessous. Faites correspondre chaque cas au canal construit pour lui et faites correspondre chaque cas à l'élément de préparation unique que l'extrait manque.

Cas A : Un outil focalisé qui enveloppe une seule API dans une fonction propre. L'extrait est la fonction et rien d'autre. Cas B : Une application de service client complète qu'un développeur veut partager entièrement, y compris son interface utilisateur et ses scripts de déploiement. Cas C : Une correction d'une ligne à un exemple Cookbook existant. L'extrait est la ligne corrigée, apportée d'un engagement client.

Correspondance 1 : cas au canal Cas A : Un outil focalisé qui enveloppe une seule API dans une fonction propre. L'extrait est la fonction et rien d'autre. Le référentiel propre de l'outilLe Cookbook, mais seulement après que le motif réutilisable soit extrait en tant qu'exemple focalisé. Le référentiel propre de l'exemple Cookbook Cas B : Une application de service client complète qu'un développeur veut partager entièrement, y compris son interface utilisateur et ses scripts de déploiement. Le référentiel propre de l'outilLe Cookbook, mais seulement après que le motif réutilisable soit extrait en tant qu'exemple focalisé. Le référentiel propre de l'exemple Cookbook Cas C : Une correction d'une ligne à un exemple Cookbook existant. L'extrait est la ligne corrigée, apportée d'un engagement client. Le référentiel propre de l'outilLe Cookbook, mais seulement après que le motif réutilisable soit extrait en tant qu'exemple focalisé. Le référentiel propre de l'exemple Cookbook Correspondance 2 : cas à l'élément de préparation manquant Cas A : Un outil focalisé qui enveloppe une seule API dans une fonction propre. L'extrait est la fonction et rien d'autre. Un test qui prouve le comportement de l'enveloppeRéduction à un motif focalisé unique, car une application entière ne correspond pas à un examen construit pour un motifLa vérification des droits, car le code d'engagement peut porter une contrainte de licence qui bloque la fusion avant tout examen technique Cas B : Une application de service client complète qu'un développeur veut partager entièrement, y compris son interface utilisateur et ses scripts de déploiement. Un test qui prouve le comportement de l'enveloppeRéduction à un motif focalisé unique, car une application entière ne correspond pas à un examen construit pour un motifLa vérification des droits, car le code d'engagement peut porter une contrainte de licence qui bloque la fusion avant tout examen technique Cas C : Une correction d'une ligne à un exemple Cookbook existant. L'extrait est la ligne corrigée, apportée d'un engagement client. Un test qui prouve le comportement de l'enveloppeRéduction à un motif focalisé unique, car une application entière ne correspond pas à un examen construit pour un motifLa vérification des droits, car le code d'engagement peut porter une contrainte de licence qui bloque la fusion avant tout examen technique

Soumettre Ignorer pour l'instant

Écran 8 : Des exigences métier aux exigences fonctionnelles et d'infrastructure

EnseignementExigences et cycle de vie·8 min Des exigences métier aux exigences fonctionnelles et d'infrastructure Les décisions de plateforme de déploiement qui suivent supposent toutes que les exigences existent déjà : la règle de résidence, l'objectif de latence, le modèle d'identité. Cet écran est d'où proviennent ces exigences : transformer un problème métier en exigences fonctionnelles et d'infrastructure qu'une décision de déploiement peut être défendue contre. Capturer les exigences fonctionnelles à partir d'un problème métier Une exigence fonctionnelle nomme ce que le système doit faire, énoncé avec assez de détail pour vérifier. Un problème métier (par exemple « aider les agents d'assistance à répondre plus rapidement ») n'est pas encore une exigence ; les exigences fonctionnelles en découlent (par exemple « classer chaque ticket dans l'une des quatre files d'attente ; rédiger une réponse citant la politique pertinente ; ne jamais envoyer automatiquement sans approbation humaine »). La discipline consiste à écrire chacun en tant que déclaration vérifiable du comportement. Un objectif vague ne peut pas être conçu ou vérifié, tandis qu'un objectif spécifique devient une ligne dans un eval et un critère lors de l'examen. Dériver les exigences d'infrastructure Les exigences d'infrastructure sont les contraintes non fonctionnelles que le déploiement doit satisfaire. La plupart d'entre elles ne sont pas énoncées dans le problème métier ; au lieu de cela, vous les dérivez en posant les questions que le problème métier implique. Latence : à quelle vitesse une réponse doit-elle être, mesurée où l'utilisateur est ? Échelle : combien de demandes, et à quel pic ? Résidence : où les données doivent-elles être traitées, et selon quelle réglementation ? Identité : qui agit, sous quelles identifiants, et qu'est-ce qui doit être auditable ? La latence, l'échelle, la résidence et l'identité sont les exigences d'infrastructure qui décident le plus souvent de la plateforme de déploiement, et elles sont les plus faciles à capturer au départ, avant qu'une plateforme ne soit choisie pour d'autres raisons. Documenter les exigences pour qu'une décision puisse être défendue Les exigences sont écrites car la décision de déploiement sera examinée par des personnes qui ne les ont pas rassemblées. Un court dossier d'exigences couvrant les comportements fonctionnels, les contraintes d'infrastructure et la réglementation que chaque contrainte provient vous permet de défendre un choix de plateforme comme suivant des exigences plutôt que de la familiarité. Ce dossier est l'entrée que la décision de déploiement de l'écran suivant lit.

Fonctionne bien Transformer un problème métier en exigences fonctionnelles et d'infrastructure vérifiables avant qu'une plateforme ne soit choisie.

Ajoute du coût ou de la complexité L'élicitation des contraintes d'infrastructure en amont prend une conversation de scoping que l'équipe est tentée de sauter.

Utilisez une approche différente Pour un prototype jetable sans examen et sans données réglementées, des notes légères suffisent.

Écran 9 : Point de contrôle 3 : extraire les exigences

Point de contrôleExigences et cycle de vie·2 min Point de contrôle 3 : extraire les exigences Essayez maintenant. Une banque réglementée de l'UE veut un agent qui résume les transcriptions d'appels clients pour son équipe d'assistance, avec des résumés examinés avant d'être stockés dans l'UE. Question 1Une banque réglementée de l'UE veut un agent qui résume les transcriptions d'appels clients pour son équipe d'assistance. Laquelle des affirmations suivantes est une exigence fonctionnelle valide ? AL'agent devrait être rapide et précis. BL'agent produit un résumé qu'un humain approuve avant qu'il ne soit stocké. CLe système doit être construit en utilisant un fournisseur de cloud approuvé. DLes données de transcription ne doivent pas quitter l'UE. Question 2Du même scénario, laquelle des affirmations suivantes est une exigence d'infrastructure valide ? AL'agent doit produire des résumés assez rapidement pour que le personnel d'assistance puisse agir dessus. BL'agent résume les transcriptions en utilisant un modèle de prompt pré-approuvé. CLes données de transcription sont traitées dans l'UE. DUn humain examine chaque résumé avant qu'il ne soit stocké.

Soumettre Ignorer pour l'instant

Écran 10 : Cycle de vie des systèmes pour les applications Claude

EnseignementExigences et cycle de vie·8 min Cycle de vie des systèmes pour les applications Claude Les exigences que vous venez de capturer sont la première phase d'un arc plus long. Cet écran nomme cet arc comme le cycle de vie des systèmes, afin que le déploiement, le versioning et le travail de limite dans le reste de ce module s'assoient dans la bonne phase plutôt que d'arriver en tant que tâches non liées. Les phases du cycle de vie appliquées à une application Claude Une application Claude passe par le même cycle de vie que tout système d'ingénierie, avec le travail du modèle mappé dessus :

1Exigences : capturer les besoins fonctionnels et d'infrastructure 2Conception : choisir la plateforme, le modèle et les limites de confiance 3Build : écrire l'agent, les outils et les prompts 4Test : evals, unité, intégration et vérifications de bout en bout 5Déploiement : épingler la version, gater la promotion sur l'eval 6Exploitation : instrumenter le coût, la latence et les erreurs ; appliquer les garde-fous 7Itération : réinjecter les résultats de production dans les exigences

Les phases sont les mêmes que celles que les modules précédents ont enseignées une à la fois. Les identifier comme un cycle de vie montre comment elles se connectent. Gater entre les phases Une porte est une décision de passer d'une phase à la suivante, et c'est où un engagement réglementé garde le contrôle. Vous ne passez pas de la conception à la build jusqu'à ce que la plateforme satisfasse l'exigence de résidence ; vous ne passez pas du déploiement vers la production complète jusqu'à ce que la nouvelle version franchisse l'eval par rapport à la base épinglée. Placer le travail d'ingénierie dans la bonne phase et refuser de sauter une porte est ce qui garde une application Claude vérifiable.

Fonctionne bien Placer chaque morceau de travail d'ingénierie dans la phase du cycle de vie à laquelle il appartient, avec un artefact défini et une porte.

Ajoute du coût ou de la complexité Gater entre les phases ajoute des points de contrôle qu'une équipe sous date limite est tentée de sauter.

Utilisez une approche différente Une expérience unique peut réduire les phases, mais un déploiement réglementé ne peut pas.

Écran 11 : Point de contrôle 4 : placer le travail dans la bonne phase

Point de contrôleCycle de vie des systèmes·2 min Point de contrôle 4 : placer le travail dans la bonne phase Essayez maintenant. Placez chaque activité dans la phase du cycle de vie à laquelle elle appartient : exigences, conception, test, déploiement, exploitation. (a) épingler l'ID de modèle complet et conserver la version antérieureexigeancesconceptiontestdéploiementexploitation(b) gater la promotion sur le résultat eval avant qu'une version ne soit mise en productionexigeancesconceptiontestdéploiementexploitation(c) décider que les données doivent être traitées dans une région spécifiqueexigeancesconceptiontestdéploiementexploitation(d) instrumenter le coût des tokens et la latence par appel en productionexigeancesconceptiontestdéploiementexploitation(e) choisir Amazon Bedrock car le client y détient sa posture de conformitéexigeancesconceptiontestdéploiementexploitation

Soumettre Ignorer pour l'instant

Écran 12 : Choisir où une charge de travail Claude s'exécute et versionnez ce qui est livré

EnseignementDéploiement et versioning·15 min Choisir où une charge de travail Claude s'exécute et versionnez ce qui est livré Un actif emballé et un actif contribué ne sont que du code jusqu'à ce que quelque chose les exécute. L'actif fait maintenant face à une question différente : où il s'exécute et comment verrouiller sa version, afin qu'un changement en amont ne devienne pas un changement non suivi en production. Cette décision de plateforme est rarement basée sur le mérite technique seul. En pratique, elle est généralement façonnée par l'endroit où le client a déjà une infrastructure cloud, une gestion d'identité et des accords de conformité en place. La première question porte généralement sur la plateforme que le client fait déjà confiance et exploite. Le cloud du client détermine généralement la plateforme La plateforme de déploiement est l'environnement où la charge de travail Claude s'exécute. Le même modèle peut s'exécuter dans plusieurs environnements de déploiement, et le cloud existant du client détermine généralement lequel. L'API Claude propriétaire est l'environnement propre d'Anthropic et reçoit généralement les nouvelles fonctionnalités en premier. Claude Platform sur AWS est accessible via le compte AWS du client en utilisant les ID de modèle propres d'Anthropic et le cycle de vie ; l'inférence est exploitée par Anthropic, en dehors de la limite AWS. Amazon Bedrock offre deux intégrations : Claude in Amazon Bedrock utilise l'API Messages à /anthropic/v1/messages avec une large parité de fonctionnalités ; confirmez les exigences spécifiques aux fonctionnalités par rapport à la documentation Bedrock, car une liste de fonctionnalités non prises en charge existe, tandis que Claude on Amazon Bedrock (hérité) utilise les APIs InvokeModel/Converse avec des identifiants versionnés par ARN. Google Vertex AI fait la même chose à l'intérieur de Google Cloud. Les plateformes tierces, telles que Microsoft Foundry, intègrent Claude dans un produit que le client utilise déjà. Microsoft Foundry offre Claude sous deux formes d'hébergement : Hébergé sur Azure (actuellement Claude Opus 4. 8, Claude Sonnet 5 et Claude Haiku 4. 5, avec l'inférence s'exécutant de bout en bout sur l'infrastructure Azure, généralement disponible) et Hébergé sur Anthropic (tous les autres modèles Claude Foundry, avec l'inférence sur l'infrastructure exploitée par Anthropic). Les hypothèses de résidence pour les clients réglementés dépendent de la forme d'hébergement du modèle spécifique. Confirmez la forme d'hébergement et la répartition actuelle des modèles avec Microsoft au moment de la build. L'identité et la résidence des données sont importantes pour la sécurité L'identité et l'emplacement des données sont répondus par la plateforme, pas par votre code. Bedrock utilise l'identité AWS et garde les données à l'intérieur de la limite AWS du client ; Vertex utilise l'identité et la limite Google Cloud. Les deux offrent un routage régional quand la résidence est une contrainte. Faire correspondre la plateforme à l'accord de conformité existant du client évite un examen de résidence des données de zéro. Épinglez la version afin qu'un changement de modèle en amont ne soit pas un changement silencieux en production Le versioning est ce qui empêche un changement de modèle ou de prompt de devenir un changement silencieux en production. Chaque ID de modèle Claude pointe vers un snapshot de modèle spécifique. Les alias tels que Opus et Sonnet sont pratiques, mais ils évoluent au fil du temps et peuvent se résoudre en différentes versions sur les plateformes de déploiement. Un ID de modèle complet épinglé se résout en un snapshot fixe. Épinglez la version de modèle spécifique plutôt que l'alias, afin qu'une mise à jour de modèle en amont soit un choix délibéré plutôt qu'un changement silencieux en production. Ensuite, versionnez le prompt et l'actif aux côtés du code. Enfin, gardez la version antérieure disponible afin que la régression puisse être annulée. Un déploiement non épinglé rend chaque mise à jour de modèle en amont un changement non suivi de votre sortie. La première ligne suit un alias mobile. La deuxième épingle le snapshot.

model = "claude-haiku-4-5"

model = "claude-haiku-4-5-20251001" Pour Claude 4. 6 et versions ultérieures, l'ID de modèle seul épingle un snapshot spécifique ; pour les modèles antérieurs, l'ID plus un suffixe de date est requis. Vérifiez la convention actuelle sur platform. claude. com au moment de la build. Promouvoir une version via l'eval Gater la promotion sur la suite d'eval. Envoyez une nouvelle version à une portion du trafic, comparez par rapport à la base épinglée et promouvez ou annulez en fonction du résultat. C'est là que l'eval cesse d'être un test unique et devient la porte de déploiement. Tableau de décision de plateforme de déploiement

PlateformeModèle d'identité et de donnéesQuand la choisirComment le versioning est épinglé API Claude propriétaireIdentité Anthropic et conditions. Le client n'a pas de contrainte cloud ou de résidence contraignante et veut les capacités les plus récentes. Épinglez l'ID de modèle complet et gardez le snapshot antérieur. Claude Platform sur AWSIdentité Anthropic et conditions, accessible via le compte AWS du client ; l'inférence est exploitée par Anthropic en dehors de la limite AWS. Le cycle de vie du modèle suit le calendrier de dépréciation d'Anthropic. Le client est sur AWS mais veut les ID de modèle Anthropic, le cycle de vie et la parité de fonctionnalités avec l'API propriétaire. Épinglez en utilisant le même format d'ID de modèle que l'API Claude (par exemple, claude-opus-4-8). Le cycle de vie suit le calendrier d'Anthropic. (Confirmez au moment de la publication. ) Claude in Amazon BedrockAPI Messages à /anthropic/v1/messages, large parité de fonctionnalités avec l'API propriétaire ; confirmez les exigences spécifiques aux fonctionnalités par rapport à la documentation Bedrock. Les données restent à l'intérieur de la limite AWS configurée du client. Le client est sur AWS, veut une large parité de fonctionnalités avec l'API propriétaire (confirmez les exigences spécifiques aux fonctionnalités) et détient une posture de conformité là. Épinglez l'ID de modèle complet en utilisant le format de préfixe anthropic. Les dates de retrait des partenaires diffèrent du calendrier d'Anthropic. Confirmez au moment de la publication. Claude on Amazon Bedrock (hérité)Identité et facturation AWS, APIs InvokeModel/Converse avec identifiants de modèle versionnés par ARN. Le client est sur une intégration Bedrock existante utilisant InvokeModel ou Converse et n'a pas migré vers l'API Messages. Épinglez via des identifiants de modèle versionnés par ARN selon les contrôles de versioning de Bedrock. Google Vertex AIIdentité Google Cloud, Identity and Access Management (IAM) et facturation, avec des points de terminaison régionaux ou globaux pour la résidence. Le client est sur Google Cloud et détient une posture de conformité là. Épinglez l'ID de modèle complet avant le déploiement en utilisant le format d'ID de modèle de Vertex. Les dates de retrait des partenaires diffèrent du calendrier d'Anthropic. Plateforme tierceLe modèle d'identité et de facturation du produit d'enveloppe. Remarque : Claude in Microsoft Foundry offre deux formes d'hébergement : Hébergé sur Azure (actuellement Opus 4. 8, Sonnet 5 et Haiku 4. 5 ; inférence de bout en bout sur Azure) et Hébergé sur Anthropic (tous les autres modèles Claude Foundry). Confirmez la résidence et les conditions de conformité avec Microsoft avant de sélectionner ce chemin pour un client réglementé. Le client exécute déjà la plateforme qui intègre Claude. Épinglez selon les contrôles de versioning de la plateforme.

Fonctionne bien Faire correspondre la plateforme au cloud du client et épingler la version garde une migration vérifiable et un rollback possible.

Ajoute du coût ou de la complexité L'épinglage, la rétention des versions antérieures et la gation de la promotion sur l'eval ajoutent des frais généraux de processus de libération à chaque déploiement.

Utilisez une approche différente Pour un prototype jetable qui ne touche jamais la production, un alias mobile est bien : l'épinglage est pour ce qui est livré.

Écran 13 : Le déploiement qui s'est cassé quand l'alias de modèle s'est déplacé

Attention ! Déploiement et versioning·3 min Le déploiement qui s'est cassé quand l'alias de modèle s'est déplacé

Configuration Vous avez livré par rapport à l'alias qui pointait vers la version recommandée, car c'était le défaut pratique et cela vous a donné le dernier modèle gratuitement. Ça a marché. Ensuite, l'alias a avancé, et ce qui était gratuit s'est avéré avoir un prix.

Ceci est un extrait de trace d'un journal de production, le genre que vous feriez défiler après un incident. Il montre le jour où la forme de sortie a changé et pourquoi il n'y avait rien à annuler. Le journal --: deploy: model="opus" status=ok --: alias advanced -> new opus version (no app change) --: parser: KeyError "summary" in response payload --: Error: output shape changed; downstream parse failed --: rollback attempted -> no pinned prior version retained --: incident: hotfix parser; root cause = unpinned deployment

Pourquoi ça a échoué L'application n'a jamais changé, mais l'alias l'a fait. Aucune version antérieure épinglée n'avait été conservée, donc il n'y avait rien à annuler. Le correctif à chaud a réparé l'analyseur mais a laissé le déploiement non épinglé en place.

À quoi faire attention Un alias se résout en une cible mobile ; un ID de modèle complet épinglé est un snapshot fixe. Épinglez l'ID de modèle complet afin qu'une mise à jour en amont soit quelque chose que vous adoptez à dessein. Gardez la version antérieure épinglée disponible afin qu'une régression soit une annulation plutôt qu'un correctif à chaud. Gater la nouvelle version via votre eval avant de la promouvoir, afin que le changement de forme de sortie s'affiche dans une exécution de test au lieu de la production.

Écran 14 : Point de contrôle 5 : Faire correspondre la plateforme de déploiement et l'épinglage de version à chaque scénario

Point de contrôlePlateforme de déploiement et versioning·4 min Point de contrôle 5 : Faire correspondre la plateforme de déploiement et l'épinglage de version à chaque scénario Essayez maintenant. Un client exécute AWS avec une exigence de résidence des données et doit pouvoir annuler une mise à jour de modèle. Sélectionnez la pièce correcte dans chaque groupe ci-dessous pour assembler la configuration de déploiement minimale qui satisfait les deux. Laissez de côté ce qui n'appartient pas. Groupe de plateformeAPI propriétaireAmazon BedrockGoogle Vertex AI Groupe d'identitéRéférence d'identité AWSClé API Anthropic Groupe de référence de modèleUn ID de modèle complet épingléUn alias mobile Groupe de rollbackConserver la version antérieure épingléePas de rétention

Soumettre Ignorer pour l'instant

Écran 15 : Comparer les plateformes sur la latence, la conformité et le coût pour que le choix survive à l'examen

EnseignementComparaison de plateformes·12 min Comparer les plateformes sur la latence, la conformité et le coût pour que le choix survive à l'examen Au cours des deux derniers écrans, vous avez choisi une plateforme et épinglé sa version. Ce choix était correct pour le cloud du client, mais « correct pour leur cloud » n'est pas encore un argument qu'une équipe d'approvisionnement et de sécurité approuvera. Mesurer la latence à partir de la région du client La latence dépend de l'endroit où la plateforme s'exécute par rapport au client et de la façon dont l'accès aux nouvelles fonctionnalités est acheminé. Une plateforme s'exécutant dans la propre région cloud du client peut réduire le temps d'aller-retour par rapport à un point de terminaison propriétaire situé plus loin. Le compromis est le moment de l'accès : l'API propriétaire reçoit généralement les nouvelles capacités avant qu'elles n'atteignent d'autres plateformes. Le nombre n'est exact que lorsque vous le mesurez à partir de la région réelle du client par rapport à sa charge utile réelle. Une mesure à partir de votre ordinateur portable cache la pénalité d'aller-retour qui apparaît une fois que la charge de travail s'exécute où le client est. Dans Bedrock spécifiquement, le choix entre les points de terminaison globaux et régionaux est également le contrôle de résidence principal et peut affecter le coût. Vous devez mesurer à partir de la région réelle du client par rapport aux deux options avant de vous engager. La conformité détermine souvent la plateforme La conformité est souvent la dimension qui termine le débat. Un client qui détient déjà une certification sur un cloud est peu susceptible de se recertifier sur un autre. La résidence des données est une règle selon laquelle les données d'un client doivent être traitées dans un pays ou une région spécifique. Les certifications de conformité disponibles et qui peut auditer l'accès diffèrent selon la plateforme, et un client réglementé dans le secteur financier ou de la santé les traite comme des critères de réussite ou d'échec plutôt que comme des compromis à équilibrer. L'API Claude propriétaire peut ne pas offrir de résidence des données de l'UE ; confirmez la couverture régionale actuelle sur platform. claude. com, car la résidence uniquement pour l'UE nécessite généralement Bedrock ou Vertex AI ; sur les plateformes tierces telles que Microsoft Foundry, l'hébergement est par modèle : les modèles Foundry hébergés sur Azure exécutent l'inférence de bout en bout sur l'infrastructure Azure, tandis que les modèles Foundry hébergés sur Anthropic ne satisfont pas aux exigences de résidence régionale de l'UE. La résidence doit être confirmée par modèle et déploiement avec Microsoft. Soulevez la contrainte de conformité lors du scoping, ou elle apparaît à l'examen du contrat après que le travail soit fait. Ce qui détermine le coût total au-delà du taux par token Les taux par token sont largement alignés sur les plateformes ; le coût total se déplace sur la sortie, les frais de plateforme et l'effort d'intégration. Un prix de token inférieur peut coûter plus cher au total une fois que le transfert de données et l'intégration sont pris en compte. Instrumentez le coût par appel pour chaque plateforme. Confirmez les pages de tarification actuelles lors du scoping. La référence de comparaison inter-plateformes

DimensionComment elle diffère selon la plateformeComment la mesurer Où chaque plateforme gagne LatenceUne plateforme dans la région du client raccourcit l'aller-retour, tandis que l'API propriétaire peut atteindre les nouvelles fonctionnalités en premier. À partir de la région réelle du client par rapport à leur charge utile réelle. Une plateforme cloud dans la région gagne sur la latence d'aller-retour, tandis que l'API propriétaire est avantagée sur l'accès aux fonctionnalités les plus récentes. ConformitéLa résidence des données, les certifications et les contrôles d'audit sont déterminés par la plateforme de déploiement. Par rapport aux exigences de certification et de résidence existantes du client lors du scoping. La plateforme cloud que le client a déjà certifiée gagne, car elle n'a besoin d'aucune recertification. CoûtLe prix du token, la sortie des données, les frais de plateforme et l'effort d'intégration varient tous. Coût total par appel par plateforme, y compris la sortie et l'intégration, plutôt que le prix du token seul. La plateforme avec le coût total le plus bas pour la charge de travail réelle gagne, ce qui n'est pas toujours le token le moins cher.

Fonctionne bien Mesurer les trois dimensions par plateforme transforme un placement en un que l'équipe d'approvisionnement approuvera.

Ajoute du coût ou de la complexité L'instrumentation de la latence, de la conformité et du coût sur les plateformes nécessite du vrai travail de mesure avant que du code ne soit livré.

Utilisez une approche différente Quand l'exigence de conformité du client est déjà un critère de réussite ou d'échec, ignorez la comparaison complète. Cette contrainte détermine le placement à elle seule.

Écran 16 : La plateforme choisie sur la familiarité qui a échoué la résidence

Attention ! Comparaison de plateformes·2 min La plateforme choisie sur la familiarité qui a échoué la résidence

Configuration Vous avez choisi la plateforme sur laquelle votre équipe avait déjà livré, car la migration semblait facile et la date limite approchait rapidement. Elle s'est construite très bien ; le problème était que facile à construire et autorisé à livrer sont des critères différents.

L'anecdote suivante est le genre qu'un développeur raconte à un coéquipier après qu'un examen s'est mal déroulé. Elle vous permet de voir le piège de la plateforme familière avant que quelqu'un ne l'appelle une erreur. Ce qui s'est passé Un développeur construisant pour un client réglementé a choisi la plateforme sur laquelle l'équipe avait déjà livré. L'intégration s'est mise en place rapidement car l'équipe connaissait les outils et les ressources. La build a passé ses tests fonctionnels. À l'examen de sécurité du client, l'examinateur a demandé où les données étaient traitées. La plateforme sélectionnée ne satisfaisait pas aux exigences de résidence du client. Une plateforme différente, celle que l'équipe connaissait moins bien, aurait satisfait l'exigence via des options de déploiement régional que le client avait déjà approuvées. Le placement a été rejeté et l'intégration a dû être reconstruite sur la plateforme qui satisfaisait la contrainte de résidence.

Pourquoi ça a échoué La familiarité a optimisé pour le mauvais test. La migration facile a répondu à la question de savoir si l'équipe pouvait construire rapidement. Elle n'a jamais répondu à la question de savoir si le déploiement passerait l'examen de résidence du client, qui était le test qui déterminait s'il pouvait être livré. Parce que l'exigence de conformité n'a pas été satisfaite lors du scoping, elle est arrivée à l'examen go-no-go à la place. C'est l'endroit le plus cher pour la découvrir, car la build était déjà complète.

À quoi faire attention Une plateforme qui est facile pour votre équipe de construire n'est pas nécessairement une plateforme que le client est autorisé à exécuter. Quand le client est réglementé, la contrainte de résidence et de conformité est souvent un critère de réussite ou d'échec, plutôt que des compromis. Identifiez-les tôt lors du scoping et laissez-les influencer le placement avant la familiarité. Vérifier tôt coûte une conversation de scoping, tandis que vérifier tard coûte une reconstruction entière.

Écran 17 : Point de contrôle 6 : Diagnostiquer l'inadéquation de plateforme à partir d'une trace de comparaison

Point de contrôleComparaison de plateformes sur la latence, la conformité et le coût·3 min Point de contrôle 6 : Diagnostiquer l'inadéquation de plateforme à partir d'une trace de comparaison Essayez maintenant. La trace de comparaison ci-dessous montre une plateforme de déploiement sélectionnée sur la familiarité échouant une exigence client. Identifiez le mécanisme, puis choisissez le correctif ciblé parmi les trois options. La trace platform_selected = "team_default" # chosen on familiarity latency_test: measured from dev laptop -> 180ms (looked fine) customer_region: eu-west, payload 12 KB compliance_check: data residency = EU-only required result: REJECTED reason="data processed outside EU on selected platform" AOption 1 : Optimiser l'analyseur pour réduire la latence de 180 ms mesurée sur l'ordinateur portable. BOption 2 : Remesurer la latence à partir d'eu-west et sélectionner la plateforme dont la région satisfait la résidence uniquement pour l'UE. COption 3 : Ajouter une couche de mise en cache pour réduire le coût par appel sur la plateforme sélectionnée.

Soumettre Ignorer pour l'instant

Écran 18 : Coordonner plusieurs déploiements Claude avec les limites de confiance maintenues lors de l'examen

EnseignementLimites de confiance·14 min Coordonner plusieurs déploiements Claude avec les limites de confiance maintenues lors de l'examen Les accélérateurs, les déploiements et les compromis se réunissent maintenant dans une seule application. Connecter les composants multiplie les endroits où l'identité, les secrets et l'entrée non fiable peuvent traverser. La discipline consiste à identifier chaque limite avant de connecter quoi que ce soit. Cartographiez quel composant fait quoi avant de les connecter Une application multi-composants coordonne plus d'une capacité Claude en un seul flux de travail. Une demande API pourrait déclencher une tâche Claude Code, qui atteint ensuite un système client via un serveur MCP. Chaque composant contribue une capacité que les autres n'ont pas. Le défi est que chaque connexion entre eux crée un endroit où l'identité, les secrets et l'entrée non fiable peuvent traverser. Cartographiez quel composant fait quoi avant de connecter quoi que ce soit. La limite de confiance est où les données se déplacent La limite de confiance est le point où les données ou les instructions se déplacent d'un environnement de déploiement à un autre. C'est exactement où les contrôles d'injection et d'accès du module précédent s'appliquent. Le contenu récupéré par une tâche Claude Code n'est pas fiable quand il atteint le composant suivant. Le composant récepteur devrait le traiter comme des données, plutôt que comme des instructions, suivant le même principe utilisé tout au long du module de sécurité. La discipline centrale ici est d'identifier chaque couture comme une limite. Ne supposez pas qu'un composant est fiable simplement parce qu'il a fonctionné correctement seul. Le moindre privilège s'applique à l'application entière L'identité et le moindre privilège, ce qui signifie donner à chaque composant uniquement l'accès dont sa tâche a besoin et rien de plus, s'appliquent à l'application entière. Chaque composant fonctionne sous une identité. L'application n'est aussi contenue que sa couture la plus privilégiée, ce qui signifie qu'un composant délimité trop largement devient le point faible même quand chaque autre composant est correctement délimité. Vous délimitez chaque composant au moindre privilège que son rôle dans le flux de travail exige. C'est ce qui empêche un composant piloté de dépasser sa tâche prévue. La délimitation pour un examen réglementé rassemble le module Un examen réglementé exige de justifier la journalisation d'audit, les décisions de résidence des données et les contrôles de permission sur l'application complète. Pour les déploiements réglementés, Bedrock et Vertex AI sont généralement les plateformes qui satisfont les contraintes de résidence régionale. Confirmez l'admissibilité ZDR et HIPAA BAA pour chaque composant par rapport au Centre de confiance Anthropic et platform. claude. com avant la délimitation. La carte d'intégration multi-composants

ComposantCe qu'il contribueLa limite de confiance à sa coutureLe contrôle qui l'applique API propriétaireOrchestre le flux de travail et détient le point d'entrée. La demande entrant dans l'application de l'extérieur. La validation d'entrée et l'identité sous laquelle l'appel s'exécute. Tâche Claude CodeExécute le travail agentic et peut récupérer du contenu externe. Le contenu qu'il a récupéré, qui n'est pas fiable en aval. Traitez le contenu récupéré comme des données à la couture suivante. Serveur MCPAtteint un système client pour lire ou agir. L'accès au système qu'il détient au nom de l'application. Délimitez le serveur au moindre privilège et enregistrez l'accès.

Fonctionne bien Nommer chaque couture comme une limite et délimiter chaque composant au moindre privilège rend une application multi-composants déployable sous examen.

Ajoute du coût ou de la complexité Cartographier les coutures, appliquer les contrôles à chacune et enregistrer les traversées de limite ajoute du travail de conception et d'audit à chaque intégration.

Utilisez une approche différente Quand une couture ne peut pas être sécurisée, ne la livrez pas : escaladez vers un propriétaire humain.

Écran 19 : La couture que personne n'a marquée comme une limite

Attention ! Limites de confiance·2 min La couture que personne n'a marquée comme une limite

Configuration Vous avez connecté les composants qui ont chacun passé leurs propres tests. Les pièces ont déjà été vérifiées et connecter des pièces vérifiées semble sûr. Chacun était fiable en isolation. L'écart était qu'une couture entre deux pièces fiables ne peut pas automatiquement être fiable elle-même.

Ceci est une courte transcription d'une session d'appairage, le genre d'allers-retours qui se termine au moment où la couture non marquée est identifiée. La session Dev A : Les trois composants passent leurs propres tests. Je viens de les câbler. Dev B : Où la tâche Claude Code envoie-t-elle ce qu'elle a récupéré ? Dev A : Directement dans l'appel suivant dans le cadre du prompt. C'est juste le contenu que nous avons tiré de la page client. Dev B : Ce contenu n'est pas fiable. S'il porte des instructions, le composant suivant les exécute, car nous ne marquons jamais cette couture comme une limite. Dev A : Mais chaque composant était fiable seul. Dev B : C'est vrai, et la couture entre eux ne l'était pas. C'est celle que personne n'a traitée comme une limite, donc le contenu récupéré traverse comme des instructions.

Pourquoi ça a échoué Chaque composant ayant passé ses propres tests ne disait rien sur la couture entre eux. Le contenu récupéré n'était pas fiable au moment où il quittait la tâche Claude Code. Il est arrivé d'un composant qui a fonctionné en isolation et a été passé dans l'appel suivant comme s'il était des instructions fiables. La limite existait dans le flux de données. Elle n'a juste pas été marquée, donc aucun contrôle ne l'a vérifiée. Un composant qui passe ses propres tests n'a pas de contrôles au niveau de la couture. Chaque point où les données traversent entre les environnements de déploiement exige un contrôle de limite explicite indépendamment de la façon dont chaque composant se comporte indépendamment.

À quoi faire attention Un composant qui est fiable en isolation ne rend pas automatiquement la couture qui le quitte digne de confiance. Marquez chaque endroit où les données ou les instructions traversent d'un environnement de déploiement à un autre comme une limite. Mettez un contrôle là qui traite le contenu récupéré comme des données plutôt que comme des instructions, exactement comme le travail de sécurité l'a enseigné. La couture que personne n'identifie est celle qu'une action pilotée traverse.

Écran 20 : Point de contrôle 7 : Compléter la configuration de limite multi-composants

Point de contrôleApplication multi-composants et limites de confiance·3 min Point de contrôle 7 : Compléter la configuration de limite multi-composants Essayez maintenant. L'application multi-composants ci-dessous est câblée, avec deux blancs laissés. Faites glisser le contrôle correct sur la couture qui reçoit du contenu récupéré non fiable et faites glisser la portée d'identité correcte sur le composant le plus privilégié. L'application partielle

fetched = code_task. run(fetch_url=customer_page)

next_call(input=drop here(fetched))

mcp_server = MCPServer( system=customer_db, scope=drop here, # BLANC 2: identity scope ) Jetons à faire glisser (banque partagée, deux sont des distracteurs) treat_as_dataleast_privilege_read_onlyrun_as_instructionsfull_access

Soumettre Ignorer pour l'instant

Écran 21 : Tâche cumulative : Trouvez les trois, expliquez chacun, écrivez la correction

CumulatifTous les sujets·6 min Tâche cumulative : Trouvez les trois, expliquez chacun, écrivez la correction Ci-dessous se trouve un accélérateur emballé et exécutable déployé sur les plateformes. Il y a trois défauts plantés : un dans la couche d'emballage, un dans la couche de déploiement et versioning, et un dans la couche de limite multi-composants. Votre tâche est de trouver les trois. Le déploiement tel que livré

def build_agent(): return Agent( model="opus", system_prompt=SYSTEM_PROMPT, repo_path="/home/acme/checkout", tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn)

fetched = code_task. run(fetch_url=customer_page) next_call(input=fetched) Portez vos trois lignes corrigées à l'écran suivant, où vous assemblez et vérifiez le déploiement corrigé. En vos propres termes, identifiez les trois défauts.

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

Écran 22 : Tâche cumulative : assembler et vérifier le déploiement corrigé

CumulatifTous les sujets·6 min Tâche cumulative : assembler et vérifier le déploiement corrigé Vous avez identifié trois défauts dans ce module. Maintenant assemblez la correction : en vos propres termes, décrivez ce que chaque défaut était, ce que vous avez changé et pourquoi la version corrigée est déployable. Ensuite, examinez le code corrigé ci-dessous et confirmez que votre raisonnement tient. Quand vous êtes prêt, révélez la réponse modèle.

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

Le déploiement corrigé def build_agent(repo_path): # parameterized for reuse return Agent( model="us. anthropic. claude-opus-4-8", # pinned full Bedrock model ID system_prompt=SYSTEM_PROMPT, repo_path=repo_path, # set per engagement tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn, retain_previous_pinned_version=True) # rollback target kept

fetched = code_task. run(fetch_url=customer_page) next_call(input=treat_as_data(fetched)) # untrusted -> data, not instructions

assert eval_suite. run(model="us. anthropic. claude-opus-4-8") >= baseline_score Réponse modèle : Le premier défaut était un chemin de référentiel codé en dur. Le paramétrer restaure la réutilisation : un engagement suivant définit la valeur plutôt que de modifier la boucle. Le deuxième défaut était un alias de modèle mobile. Épingler l'ID de modèle Bedrock complet (avec le préfixe anthropic. ) avec une version antérieure conservée restaure le déploiement contrôlé et donne une cible d'annulation si la nouvelle version régresse. Le troisième défaut était le contenu récupéré passé directement comme des instructions. L'envelopper dans treat_as_data() ferme la limite de confiance : le contenu d'une source non fiable est traité comme des données, pas comme quelque chose sur lequel l'agent devrait agir. L'assertion eval gâte la promotion sur un score de base prouvé avant que la version ne soit livrée.

Les trois défauts ont atterri · réussi J'en ai manqué un ou plus · réessayer

Écran 23 : Points clés à retenir

RécapitulationTous les sujets·3 min Points clés à retenir

01 Emballez pendant que la build est fraîche. Un accélérateur conserve la logique réutilisable, expose les parties spécifiques au client en tant que paramètres documentés et regroupe l'eval et le journal d'audit aux côtés de l'actif. L'emballage correct produit un actif que les équipes configurent. La connaissance de ce qui est spécifique au client est la plus chère à reconstruire après que les personnes qui l'avaient ont quitté.

02 Un responsable accepte ce qu'il peut vérifier. Déplacer un actif vers l'infrastructure partagée signifie le faire correspondre au canal construit pour sa forme, puis franchir la barre d'examen : code focalisé, un exemple exécutable, un test et une déclaration d'hypothèses, avec les droits de licence confirmés avant l'examen technique. Une contribution qu'un examinateur ne peut pas vérifier s'assoit à l'arrière de la file d'attente. La préparation déplace un actif privé vers l'infrastructure partagée sur laquelle d'autres construisent.

03 Épinglez ce qui est livré. Choisissez la plateforme de déploiement en fonction du cloud et de la posture de conformité du client, puis épinglez la version de modèle spécifique plutôt que l'alias mobile et gardez la version antérieure disponible. Un alias est comme demander l'édition actuelle d'un livre : pratique, mais le texte peut changer. Épingler cite une édition fixe, afin qu'un changement de modèle en amont soit quelque chose que vous adoptez délibérément plutôt que quelque chose qui arrive du jour au lendemain sans chemin d'annulation.

04 Mesurez la dimension qui détermine le placement. Un choix de plateforme n'est défendable que quand la latence, la conformité et le coût sont mesurés : latence à partir de la région du client, conformité par rapport à leur certification existante, et coût comme le total par appel plutôt que le prix du token seul. Pour les clients réglementés, la conformité est généralement un critère de réussite ou d'échec. Soulever la conformité comme une contrainte lors du scoping l'empêche de rejeter la build plus tard à l'examen du contrat.

05 Marquez chaque couture comme une limite. Une application multi-composants n'est aussi contenue que sa couture la plus privilégiée. Délimitez chaque composant à l'accès minimum que son rôle exige et traitez chaque point où les données traversent comme une limite de confiance. Le contenu récupéré est traité comme des données, pas comme des instructions. La confiance à une limite de composant doit être explicitement établie. Elle ne se transporte pas du composant qui a envoyé les données. Quand une couture ne peut pas être sécurisée, elle va à un propriétaire humain plutôt que d'être livrée.

Ce qui vient ensuite Vous pouvez maintenant empaqueter une build en un actif réutilisable, le contribuer en retour, le placer et le versioner sur la bonne plateforme, défendre ce placement et connecter les composants ensemble afin que les limites tiennent. Cela complète l'arc de build-à-déploiement pour ce persona : de l'écriture de code de production dans les modules précédents à la livraison d'actifs qu'un client réglementé peut auditer et qu'une équipe peut réutiliser.

Références publiques Anthropic (sensibles au temps)

IDSourceTypeUtilisé pour S1platform. claude. com (Claude in Amazon Bedrock, Claude on Vertex AI)Documentation de produitPlateformes de déploiement, modèles d'identité et de données, routage de résidence, points de terminaison régionaux et globaux. S2platform. claude. com (Model IDs and versioning, Model deprecations)Documentation de produitIDs de modèle épinglés, résolution d'alias, cycle de vie et retrait, calendriers définis par les partenaires. S3anthropic. com and the Anthropic GitHub organization (Cookbook)Produit et référentielCanaux de contribution, le Cookbook comme maison pour les exemples focalisés, conventions de contribution. S4Building with the Claude API (Skilljar)Source de coursEnsembles de données d'eval, évaluateurs et le pipeline d'évaluation utilisé comme la porte de déploiement. S5Claude Code 101 In Action (Skilljar)Source de coursTâches agentic Claude Code et rôles de serveur MCP dans un flux de travail multi-composants.

Vous pouvez maintenant prendre une build fonctionnelle jusqu'à un actif déployable et auditable. Emballez-la, contribuez-la, placez-la et versionnez-la, défendez ce placement et maintenez les limites ensemble lors de l'examen.

Écran 24 : Termes clés de ce module

GlossaireTermes clés·3 min Termes clés de ce module Alphabétique. Cliquez sur un terme pour développer sa définition.

AccélérateurUne solution fonctionnelle emballée afin que l'engagement suivant la configure plutôt que de la reconstruire. Les parties spécifiques au client sont exposées en tant que paramètres documentés, les hypothèses sont écrites et un eval est regroupé pour prouver que l'actif fonctionne toujours dans un nouveau contexte. Préparation à la contributionCe qu'un responsable doit vérifier une contribution : code focalisé, un exemple exécutable, un test qui prouve le comportement, une déclaration d'hypothèses d'environnement et des droits confirmés de contribuer le code. Plateforme de déploiementOù une charge de travail Claude s'exécute. Les six sont : l'API Claude propriétaire, Claude Platform sur AWS, Claude in Amazon Bedrock, Claude on Amazon Bedrock (hérité), Google Vertex AI et les plateformes tierces. Le même modèle peut différer selon la plateforme sur l'identité, la résidence des données, la latence et le coût. Alias de modèle par rapport à l'ID épingléUn alias tel que opus ou sonnet se résout en une version recommandée qui se met à jour au fil du temps et peut différer selon la plateforme. Un ID de modèle complet épinglé est un snapshot fixe. L'épinglage est ce qui empêche un changement de modèle en amont de devenir un changement silencieux en production. Limite de confianceLa couture où les données ou les instructions se déplacent d'un environnement de déploiement à un autre dans une application multi-composants. Le contenu récupéré par un composant n'est pas fiable quand il atteint le suivant, donc le composant récepteur le traite comme des données, pas comme des instructions.

Écran 25 : Félicitations ! Vous avez terminé ce module avec succès.

Module terminéChemin développeur·2 min Félicitations ! Vous avez terminé ce module avec succès. Vous pouvez maintenant prendre une build fonctionnelle jusqu'à un actif déployable et auditable : un accélérateur réutilisable, une contribution qu'un responsable peut vérifier, une plateforme de déploiement choisie et versionnée à dessein, et chaque couture dans une application multi-composants marquée comme une limite de confiance. Le fil conducteur : le point où le code commence à fonctionner est où le travail de ce module commence.

4 des 9 points de contrôle réussis

Fondations MSO Tokens, fenêtres de contexte, échantillonnage, niveaux de modèle, modes de prompt et la mécanique de transport de l'API.

Prompting de qualité production, agents et utilisation d'outils Prompts prêts pour la production, boucles d'utilisation d'outils, streaming, gestion du contexte et de la mémoire, et boucles d'agent avec points de contrôle.

Claude Code, MCP et intégration Modes de permission, contexte de projet durable, emballage de plugin et intégration MCP sans fuite de credentials.

Ingénierie de production, evals et sécurité Prouvez que le système tient sous le trafic de production et survit à un audit de sécurité.

Accélérateurs et contribution IP Emballez les accélérateurs, préparez les contributions vérifiables, choisissez les plateformes de déploiement et marquez les limites de confiance.

Vous êtes ici

Examiner le module Recommencer

Fin du module enregistrée.