Engagement des parties prenantes, Cycle de vie et GTM

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

MODULE · ORIENTATION Orientation : ce que vous serez capable de faire à la fin

Les trois derniers modules vous ont menés d'un problème commercial à un déploiement Claude conçu, intégré et gouverné. Vous pouvez décomposer une demande, choisir un modèle, dimensionner un cas d'usage, construire des évaluations comme critères d'acceptation, instrumenter l'observabilité et mettre en place un ensemble de contrôles auditables pour une charge de travail réglementée. Ce que tout cela n'a pas résolu, c'est la partie du travail qui se déroule dans les salles avec les parties prenantes : la conversation de découverte où les véritables exigences sont établies, la réunion d'approbation où un compromis est remporté ou perdu, la transmission où votre conception survit à votre absence ou se dégrade silencieusement.

Ce module couvre ce travail. À la fin, vous serez capable de : 1 Mener une conversation de découverte structurée avec une partie prenante non technique et traduire ce que vous apprenez en exigences architecturales et hypothèses documentées, afin que la conception soit tracée jusqu'au cas commercial plutôt qu'à votre propre préférence technique. 2 Présenter un compromis architectural en termes qu'une partie prenante commerciale peut actionner en associant chaque choix à un coût, un risque et ce qu'une inversion nécessiterait, afin que les examens exécutifs et d'approvisionnement aboutissent à une décision au lieu de stagner. 3 Construire et exploiter une boucle de rétroaction des parties prenantes sur le cycle de vie du déploiement en nommant ce qui déclenche un examen, ce qu'une violation de SLA exige, et quand itérer par rapport à réarchitecturer, avec des points de contrôle de gouvernance intégrés à la même boucle. 4 PISTE PARTENAIRE[Pertinent pour la piste partenaire, non testé par l'examen Architecte ; conservé pour les apprenants de la piste partenaire] Diriger le rôle de l'Architecte dans un mouvement de mise sur le marché partenaire à travers la découverte, une démonstration basée sur des scénarios, la gestion des objections techniques et la portée conjointe avec l'équipe Applied AI d'Anthropic, afin qu'une opportunité d'entreprise ne stagne pas sur des questions auxquelles seul vous pouvez répondre. 5 Sélectionner le point d'entrée du déploiement et la stratégie multi-plateforme pour un système de production multi-plateforme en comparant les routes API directe, Bedrock, Vertex et tierces sur la latence, la conformité et le coût, puis produire un document de résultat qui rend la valeur lisible pour un sponsor non technique et réutilisable comme IP partenaire. Le travail correspond aux sections qui suivent :

La découverte est l'endroit où vous transformez la préférence d'une partie prenante en une contrainte documentée contre laquelle l'architecture peut être conçue. Le mouvement est la traduction : une préférence signale que d'autres questions sont nécessaires plutôt que de fonctionner comme une exigence directe. Une exigence utile est testable et délimitée. L'échec coûteux est un appel de découverte qui se termine par un croquis de conception avant que la traduction ne soit terminée. Le croquis plausible est ce qui le rend dangereux : une partie prenante qui voit une architecture confiante suppose que les questions ont été répondues.

La présentation des compromis et la mise sur le marché est l'endroit où vous présentez une décision architecturale en termes qu'une partie prenante peut actionner, et où vous concevez une démonstration contre le scénario réel de l'acheteur plutôt que contre les capacités propres de l'équipe. Trois éléments appartiennent à chaque présentation de compromis : ce que le choix gagne, ce qu'il abandonne, et ce que l'inversion coûte une fois que le système est construit autour de lui. Le troisième élément est celui qui change la réunion, et c'est celui que la plupart des présentations manquent.

La boucle de rétroaction est l'endroit où vous construisez la couche de décision qui se situe au-dessus de la pile d'observabilité et détermine quels signaux changent le comportement et de qui. Une boucle de rétroaction est un tableau de gouvernance qui mappe chaque signal à un déclencheur, un propriétaire et une action. Dans les déploiements réglementés, certains examens se déclenchent selon un calendrier plutôt qu'à un seuil. Ces lignes de gouvernance doivent être en place avant le lancement. S'il n'y a pas de déclencheur défini, un point de contrôle de conformité ne fera surface que lorsqu'un examinateur viendra chercher l'enregistrement.

La documentation pour la transmission et l'audit est l'endroit où vous enregistrez non seulement les décisions qui ont été prises mais aussi les alternatives qui ont été rejetées et le compromis que chacune a résolu. Le test de complétude est de savoir si un Architecte compétent qui n'était pas dans la salle peut apporter une modification sûre au système après avoir lu le document. Un diagramme porte ce que le système est. Sans la justification des décisions, le diagramme ne peut pas dire au successeur quels choix sont porteurs de charge et lesquels sont simplement des préférences. Le moment où vous quittez l'engagement est le moment où ce raisonnement disparaît s'il n'a jamais été documenté.

La sélection du point d'entrée et le document de résultat est l'endroit où vous confirmez la bonne route de déploiement pour un système de production en direct et transformez les résultats du déploiement en un artefact qui survit à l'engagement. Le document de résultat établit le cas commercial pour un lecteur qui n'a pas participé à la construction. Le volume, la latence et le taux d'erreur indiquent à un sponsor que le système fonctionne. Un avant et après sur la métrique commerciale que le cas d'usage ciblait, soutenu par un contrôle auditable, indique à un CFO ce qu'il vaut la peine d'étendre.

Ces cinq sujets ne sont pas indépendants, en fait, chacun s'étend à partir du dernier. L'ensemble de contraintes de la découverte est ce que la présentation du compromis défend. Le tableau de gouvernance de la boucle de rétroaction garde les contrôles de conformité capturés dans le registre à jour au fur et à mesure que le déploiement s'exécute. La justification de la documentation garde les décisions que le registre contient d'être silencieusement inversées par un successeur. Le document de résultat s'appuie sur chaque couche au-dessus de lui pour rendre la valeur compréhensible à un lecteur qui n'a jamais vu le travail. La tâche cumulative à la fin vous demande de prendre un déploiement multi-plateforme réglementé de la première phrase d'une partie prenante à un document de résultat qui justifie l'expansion. En fait, c'est exactement ce que ce module vous équipe pour faire avant de transmettre.

Sur ces cinq sujets s'étend le cycle de vie du projet lui-même : découverte → conception → transmission → surveillance → itération. La découverte et la présentation des compromis font le travail de découverte et de conception ; la boucle de rétroaction est la phase de surveillance et d'itération ; la documentation est la phase de transmission ; et la sélection du point d'entrée avec le document de résultat ferme la boucle. Identifier la phase à laquelle une décision appartient est ce qui vous permet de juger quand une phase est prête à passer à la suivante.

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

Nous avons construit ce cours Architecte Module 4 : Engagement des parties prenantes, Cycle de vie et Mise sur le marché pour vous aider à accomplir un 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 contrôlent.

Écran 2 : Un appel de découverte est une élicitation structurée, pas une conversation

Découverte Un appel de découverte est une élicitation structurée, pas une conversation Vous savez comment évaluer le modèle, la plateforme de déploiement et la posture de contrôle. La découverte révèle si vous résolvez le bon problème. Une partie prenante décrira généralement le problème en termes commerciaux. Votre travail est d'écouter ce que l'entreprise essaie d'accomplir, d'identifier les contraintes cachées dans cette description, et de quitter l'appel avec un enregistrement que la conception peut suivre.

La découverte établit les artefacts sur lesquels la conception dépend Une conversation de découverte fonctionne comme un filtre à trois étapes : écouter, traduire et écrire.

1D'abord, écoutez l'objectif commercial en langage clair et prêtez attention au sens derrière le mot. Les parties prenantes décrivent généralement le résultat qu'elles veulent mais pas la contrainte dont vous avez besoin pour concevoir. 2Deuxièmement, traduisez cela en exigences, hypothèses et contraintes non résolues. Cela vous permet de voir ce que la conception doit supporter, ce qui doit encore être confirmé, et ce qui pourrait bloquer la solution plus tard. 3Troisièmement, écrivez ces éléments avant que la conversation ne progresse. La conception a besoin d'un enregistrement clair à suivre. Sans ce filtre, la conception hérite de vos hypothèses. L'inadéquation peut ne pas être révélée que beaucoup plus tard, quand changer de trajectoire est plus lent, plus difficile et plus coûteux.

Le mouvement central est la traduction : une préférence énoncée cache presque toujours une contrainte La compétence la plus importante en découverte est la traduction. Les parties prenantes parlent généralement en préférences, mais les décisions de conception sont prises contre des contraintes. Imaginez qu'une partie prenante dit : « Nous voulons que ce soit transparent ». Si vous écrivez « transparent » comme exigence, vous n'avez pas appris assez pour concevoir quoi que ce soit. Vous n'avez que le résumé de la partie prenante de l'expérience qu'elle veut. Le vrai travail commence avec la question suivante : qu'est-ce qui le rendrait non transparent ? C'est là que les contraintes cachées commencent à apparaître. Peut-être que l'utilisateur ne devrait jamais attendre plus d'une ou deux secondes pour l'étape suivante. Peut-être qu'il ne devrait pas avoir à réentrer des informations qui existent déjà en amont. Peut-être que les exceptions devraient se déplacer silencieusement vers un examinateur humain au lieu d'exposer une erreur technique. Peut-être que le flux de travail doit rester dans une seule application, afin que l'utilisateur n'ait jamais à sauter entre les outils. Chaque réponse affine la conception. Cet échange transforme « transparent » en exigences que l'architecture doit supporter : une cible de latence, une exigence d'intégration, une règle de transmission et un chemin d'échec sûr. La partie prenante nomme le résultat en langage commercial. Vous le transformez en quelque chose que le système peut construire et mesurer. La préférence se situe au niveau supérieur, et la contrainte se situe en dessous. Quand une partie prenante vous donne un mot d'expérience comme transparent, facile, rapide, simple ou intuitif, traitez-le comme un signal que plus de découverte est nécessaire. Demandez ce qui briserait cette expérience, ce que l'utilisateur ne doit jamais remarquer, ce qui doit se passer en arrière-plan, et ce qui doit rester vrai quand quelque chose se passe mal. Ces réponses sont ce qui appartient au dossier de conception. Une contrainte testable et délimitée est ce contre quoi la conception peut être construite. Une préférence de partie prenante vous indique où enquêter, tandis que les questions de suivi produisent la contrainte elle-même.

Quatre questions transforment la découverte en exigences La découverte fonctionne mieux quand vous forcez une déclaration vague de partie prenante dans les quatre catégories ci-dessous. Une déclaration comme « nous voulons que ce soit transparent » n'est pas encore quelque chose contre quoi vous pouvez concevoir. Elle cache généralement une ou plusieurs réponses spécifiques. Enquêtez sur les points suivants :

1Ce que le système doit faire. Ce sont les capacités que le déploiement doit fournir, exprimées comme des résultats commerciaux plutôt que comme des fonctionnalités. C'est là que vous séparez le travail que Claude possède du travail qui reste avec un système existant ou un humain. 2Ce que le système ne doit pas faire. Ce sont les limites, les actions interdites et les cas qui doivent être acheminés vers un humain. Les parties prenantes offrent rarement ces informations, vous devez donc les demander explicitement. 3Ce que le système doit coûter. C'est la contrainte budgétaire, exprimée en termes que la partie prenante contrôle. Une cible de latence, un plafond de coût par interaction ou une prévision de volume doivent tous être pris en compte ici. Ceux-ci deviennent des contraintes de conception cruciales. 4Ce que le système doit prouver. C'est la preuve que le déploiement doit être capable de produire quelque chose de valeur. Dans les flux de travail réglementés, les obligations de preuve font partie de l'ensemble des exigences. Les identifier en découverte est beaucoup moins cher que lors d'un examen juridique des semaines plus tard.

« Transparent » peut vraiment signifier un budget de latence que l'utilisateur ne devrait pas remarquer, une transmission qui ne devrait pas interrompre le flux, ou un état d'échec qui ne doit pas exposer les éléments internes du système. Une fois que vous découvrez ces réponses, vous avez des exigences que l'équipe peut concevoir, tester et défendre.

La sortie de la découverte est un tableau de traduction Chaque élément trouvé en découverte devient une ligne dans un tableau de traduction. La ligne capture la déclaration de la partie prenante telle qu'elle a été dite, la contrainte qu'elle implique, la décision architecturale que cette contrainte force, et toute hypothèse que vous documentez quand la contrainte n'a pas encore été confirmée. Une ligne par élément garde le raisonnement intact au fur et à mesure que le travail passe de la découverte à la conception, et cela garde les hypothèses à l'esprit.

Déclaration de la partie prenantContrainte impliqueeDécision architecturale requiseHypothèse du document

« Nous voulons que ce soit transparent. »L'expérience doit rester dans un budget de latence convenu. Les défaillances ne doivent pas exposer les éléments internes du système ou briser le flux. Définir une cible de latence p95 comme contrainte de conception, puis concevoir un état d'échec gracieux et sûr en interne. Suppose que « transparent » fait référence à la réactivité perçue et à la continuité du flux. Confirmez la compréhension. « Il suffit juste de lire le formulaire et de l'acheminer. »L'acheminement peut être une règle commerciale déterministe. Gardez la décision d'acheminement dans le moteur de règles. Claude extrait, et le système achemine. Suppose que la logique d'acheminement est possédée et maintenue en dehors du modèle. Confirmez le propriétaire. « Les cliniciens examineront de toute façon la sortie. »Un humain autorisé doit autoriser la sortie avant qu'elle ne devienne partie d'un enregistrement avec des conséquences juridiques, financières ou cliniques. Construire une étape d'autorisation humaine dans la boucle comme point de contrôle obligatoire. Suppose que l'examen est une porte architecturale. Confirmez l'autorité et le calendrier. « Nous sommes dans le secteur de la santé, alors soyez prudent avec les données. »Le flux de travail porte probablement une obligation de preuve en vertu d'un régime de confidentialité de la santé. Traitez la piste d'audit et la preuve de manipulation des données comme une exigence centrale dès le départ. Suppose un flux de travail couvert avec une obligation formelle. Confirmez la portée avec la conformité.

Coût · Complexité · Risque

Coût : Un appel de découverte qui dure assez longtemps pour identifier les véritables contraintes est beaucoup moins cher que de reconcevoir la solution après qu'une contrainte cachée émerge lors d'un examen juridique ou de conformité. Complexité : Travailler à travers les quatre catégories de questions ajoute une structure nécessaire, et traduire les préférences en contraintes en temps réel nécessite une pratique délibérée. Risque : L'échec coûteux est la contrainte non énoncée qui survit au test et devient un bloqueur d'examen de production, quand le coût de changer la conception est à son plus haut.

Écran 3 : L'appel de découverte qui s'est transformé en session de conception

Attention à laDiscoverte5 min L'appel de découverte qui s'est transformé en session de conception

ConfigurationLa découverte est l'endroit où le travail commence. La conception est l'endroit où il s'accélère. Un bon Architecte commence à former une solution à mi-chemin de l'appel. Esquisser et visualiser cela semble productif, et la partie prenante semble heureuse de voir des progrès. C'est exactement le moment où les questions s'arrêtent.

Un appel de découverte reconstruit, où les questions se sont arrêtées tôt Dans l'échange ci-dessous, l'Architecte entend deux déclarations de parties prenantes et commence à proposer une solution. La partie prenante confirme la proposition initiale parce qu'elle semble compétente. Les contraintes qui auraient exclu cette architecture ne sont jamais identifiées. Elles émergent deux semaines plus tard lors d'un examen de conformité. Cette section montre exactement où la question qui aurait attrapé chaque contrainte appartenait. Utilisez cet exemple pour apprendre à reconnaître le modèle dans vos propres appels.

Échange reconstruit

Partie prenante : « Nous gérons un réseau hospitalier régional. Les infirmières passent une éternité à rédiger les interactions avec les patients. Nous voulons que Claude rédige la note clinique à partir de leur dictée. » Architecte : « D'accord, c'est juste un modèle augmenté propre. Claude prend la dictée, rédige la note structurée, puis la réécrit. Nous pouvons avoir un prototype la semaine prochaine. » Partie prenante : « Cela semble juste. Il y a une étape d'examen quelque part, mais c'est juste une vérification rapide. » Architecte : « Bien sûr, nous ajouterons une étape d'examen. Laissez-moi commencer par la conception. »

Diverses contraintes identifiées trop tard pour être une correction facile La « vérification rapide » n'était pas une fonctionnalité de commodité. Le flux de travail infirmier exigeait qu'un clinicien autorisé autorise toute sortie de modèle avant qu'elle n'atteigne le dossier du patient. Cela a rendu l'autorisation humaine une porte architecturale requise plutôt qu'un ajout optionnel. La dictée contenait des informations de santé protégées. Les informations de santé protégées se sont déplacées dans la fenêtre de contexte sans la manipulation que le flux de travail exigeait. Le réseau s'étendait sur deux États avec des règles de rétention d'enregistrements différentes, et la conception à région unique n'a jamais tenu compte de l'une ou l'autre. Aucune de ces exigences n'était inhabituelle ou difficile à trouver. Chacune aurait émergé d'une question directe dans les catégories doit-prouver et ne-doit-pas-faire, si l'appel n'avait pas passé à l'esquisse avant que ces questions ne soient posées.

Pourquoi cela a échoué : une proposition d'esquisse compétente a mis fin aux questions qu'un appel de découverte existe pour poser L'esquisse était plausible, et la plausibilité est ce qui rend cela dangereux. Une partie prenante qui entend une architecture confiante suppose que l'Architecte a les informations pour la construire. Le mouvement qui vous protège est ennuyeux : terminez l'ensemble de questions à quatre catégories avant de proposer quoi que ce soit et traitez chaque « c'est juste un examen » comme une contrainte à poursuivre.

Écran 4 : Point de contrôle : trouvez l'hypothèse non documentée

Découverte · Point de contrôle Point de contrôle : trouvez l'hypothèse non documentée

Essayez maintenant. Ci-dessous se trouve un résumé d'appel de découverte et le document d'exigences qu'un Architecte a produit à partir de celui-ci. Trois éléments tracent quelque chose que la partie prenante a dit ; un est une hypothèse que l'Architecte a faite sans faire surface la contrainte en dessous. Choisissez l'élément qui est l'hypothèse non documentée, puis confirmez qu'aucune déclaration de partie prenante ne le soutient.

Document d'exigences

• Claude rédige l'e-mail client, mais une personne l'envoie réellement.
• Les réponses doivent revenir dans un budget perçu de deux secondes.
• Les remboursements au-dessus du seuil sont acheminés vers un approbateur humain.
• Les transcriptions de conversation sont conservées pendant soixante jours à des fins d'analyse.

Ce que la partie prenante a dit

« Tout ce qui est important nécessite l'approbation d'une personne. » « Rédigez la réponse, mais nous l'envoyons nous-mêmes. » « Cela doit sembler instantané pour l'utilisateur. »

Partie 1 : Quel élément est l'hypothèse non documentée ?

AÉlément 1, rédaction d'e-mail avec envoi humain BÉlément 2, budget de latence de deux secondes CÉlément 3, acheminement des remboursements vers un approbateur humain DÉlément 4, conservation des transcriptions pendant soixante jours

Partie 2 : Quelle déclaration de partie prenante devrait l'élément 4 tracer ?

A« Rédigez la réponse, mais nous l'envoyons nous-mêmes. » B« Cela doit sembler instantané pour l'utilisateur. » C« Tout ce qui est important nécessite l'approbation d'une personne. » DAucune déclaration de partie prenante ne soutient cet élément.

Vérifier la réponse Ignorer

Écran 5 : Présentez un compromis pour que la partie prenante puisse agir dessus, et concevez une démonstration qui avance

Compromis et GTM Présentez un compromis pour que la partie prenante puisse agir dessus, et concevez une démonstration qui avance l'opportunité La découverte vous a dit ce que l'acheteur a besoin. Transformer ces exigences en une décision qu'une partie prenante peut prendre est le travail suivant. L'Architecte aide maintenant la partie prenante à comprendre le compromis, à voir les conséquences commerciales et à approuver un chemin à suivre avec confiance.

Votre travail n'est pas de résoudre le compromis avant la réunion. Votre travail est de rendre les décisions possibles. Votre travail est de décrire les options assez clairement pour que la partie prenante puisse faire un choix éclairé. Chaque décision de conception significative a un compromis. Une option peut réduire le coût ou la complexité mais augmenter la latence, le risque ou la charge de conformité. Une autre peut améliorer l'expérience utilisateur ou s'adapter mieux mais nécessiter plus d'efforts en amont. Si vous présentez uniquement la conclusion, la décision peut sembler claire, mais elle est faible. Quand l'inconvénient apparaît plus tard, la partie prenante peut sentir qu'elle a approuvé une recommandation sans comprendre ce qui venait avec. Donc, utilisez un cadre de décision simple :

1Qu'est-ce que nous gagnons ? 2Qu'est-ce que nous abandonnons ? 3Que se passe-t-il si nous choisissons cela maintenant mais devons l'inverser plus tard ? 4Dans les environnements réglementés, qu'est-ce que cela fait à notre posture de conformité ?

Cette troisième question est celle que la plupart des gens sautent, et c'est souvent celle qui change la réunion. Elle transforme la discussion de « quelle est la meilleure réponse technique ? » en « quel est le meilleur choix commercial ? » La précision technique est nécessaire, mais elle n'est pas suffisante. Dans les examens architecturaux, la recommandation est souvent techniquement correcte mais toujours incompréhensible pour la personne qui doit l'approuver. L'Architecte peut expliquer les options en vocabulaire technique (c. -à-d. latence, profondeur de journalisation, taille du contexte, modèle de récupération, route de déploiement) mais l'exécutif pose une question plus simple : « Qu'arrive-t-il à l'entreprise si nous faisons le mauvais choix ? » À ce moment, la salle n'a pas besoin de plus de détails, ce dont elle a besoin est une traduction en quelque chose qu'une personne peut comprendre. Quand vous le faites bien, la partie prenante n'entend pas seulement votre recommandation. Elle prend une décision éclairée qu'elle peut défendre plus tard.

Encadrez la décision comme un paquet, plutôt que comme un verdict Présentez la décision comme un paquet que la partie prenante peut actionner : les options que vous avez considérées, les critères que vous avez pesés, votre recommandation et les risques qui restent. La partie prenante n'adopte pas votre architecture ; elle accepte une décision qu'elle devra défendre auprès de sa propre direction.

La description est la compétence qui fait atterrir le paquet La description est l'une des quatre compétences de fluidité IA : communiquer efficacement avec l'IA. Étendue au côté des parties prenantes du travail, la même discipline signifie dire à l'audience exactement ce dont elle a besoin, en termes qu'elle peut comprendre. Appliquée à la communication avec les parties prenantes, la description signifie encadrer le comportement du système, ses limites et la surveillance autour de lui en termes d'objectif de la partie prenante. L'encadrement doit correspondre à leur familiarité avec l'IA sans sacrifier la précision. Trois règles s'appliquent en pratique : commencez par le résultat commercial plutôt que par l'architecture ; encadrez les limitations honnêtement, car une partie prenante en sécurité fait confiance à un système dont les limites sont clairement énoncées ; et anticipez la demande de preuve par les pairs, car la partie prenante devra justifier le choix auprès d'autres et devrait quitter la conversation avec cette justification en main.

Utilisez la carte de traduction des compromis pour passer du cadrage architectural au langage de décision des parties prenantes.

Décision architecturaleQuoi vous gagnezQuoi vous abandonnezCe qu'un mauvais choix inversé coûte

Fenêtre de contexte plus grande par appel par rapport à la récupération sur des morceauxConception initiale plus simple, le document complet en vue, et moins de pièces mobiles à gérer au début. Coûts par appel plus élevés et temps de réponse plus lents à mesure que le volume de production augmente. La mise en cache des prompts peut récupérer une partie importante du coût d'entrée pour le contenu statique comme les documents de politique tenus en contexte sur l'appel, donc évaluez la mise en cache avant de traiter le coût par appel comme fixe. Remanier l'architecture après que les coûts augmentent en production, plus le coup à la crédibilité d'expliquer une dépense surprise évitable. Échanger les détails de journalisation pour une latence plus bassePour une réponse perçue plus rapide et une expérience utilisateur plus fluide. Visibilité réduite sur ce qui s'est passé dans chaque interaction. Dans une charge de travail réglementée, une lacune de conformité potentielle nécessitant une correction. Route de livraison unique par rapport à multi-plateformeMoins de complexité de construction et un profil d'authentification et de journalisation cohérent. Moins de flexibilité pour répondre à différents besoins régionaux, de conformité ou d'approvisionnement. Un lancement de production retardé ou bloqué si la route choisie ne peut pas satisfaire une exigence de résidence des données ou de déploiement émergente tardivement.

La carte existe pour aider la partie prenante à voir la conséquence de son choix assez clairement pour décider.

La conception de démonstration est une compétence distincte, et une démonstration faible peut annuler ce que la découverte a gagné Imaginez la réunion de l'acheteur où la découverte s'est bien déroulée. L'équipe s'est alignée sur le problème, le cas d'usage et la valeur en jeu. Puis la démonstration commence. Au lieu de montrer le monde de l'acheteur, elle montre un ensemble de fonctionnalités poli mais générique. La réaction est généralement polie, que la démonstration était intéressante, mais pas tout à fait ce qu'ils envisageaient. Une démonstration faible peut faire douter l'acheteur que l'équipe a compris le problème central. Cela se produit quand les équipes confondent deux travaux différents. Une démonstration de capacités répond à « Qu'est-ce que ce système peut faire ? » Une démonstration spécifique au scénario répond à « Qu'est-ce que ce système fait avec mon problème, mon flux de travail et mes contraintes ? » Le premier crée de l'intérêt ; seul le second crée de la confiance. Concevoir une preuve que la solution s'adapte au contexte de l'acheteur fait partie du travail de la démonstration. Une démonstration bien conçue fait avancer l'opportunité tandis qu'une faible peut annuler la confiance que la découverte a construite.

Piste partenairNon testé par l'examen Architecte Avant de construire des écrans, prenez quatre décisions de conception. Ces décisions déterminent si la démonstration semble adaptée et crédible ou générique et facile à rejeter.

Décision de conceptionCe que l'Architecte décidePourquoi cela détermine le résultat

Sélection du scénarioChoisissez un flux de travail que l'acheteur reconnaîtra immédiatement de ses propres opérations, y compris les formes de données familières, les étapes d'approbation et les cas limites. Évitez une tâche de document générique ou un flux de requête abstrait. Les acheteurs font confiance à ce qui semble familier. Quand ils voient leur propre vocabulaire et points d'échec sur l'écran, la démonstration semble pertinente et crédible. La reconnaissance est souvent plus persuasive qu'une visite de fonctionnalités poli mais générique. Placement des limitesDecidez à l'avance laquelle une ou deux limitations la démonstration identifiera, et encadrez-les comme des limites de portée intentionnelles. Déclarez ce que le système ne fait pas et pourquoi. Si un acheteur découvre une limitation à mi-chemin de la démonstration, la confiance baisse. Si vous nommez la limitation tôt, cela se lit comme de la discipline et de l'honnêteté. Dans les paramètres réglementés, la divulgation préalable des limites est souvent un signal positif. Collaboration de l'équipe de ventesFormez le récit de démonstration avec l'équipe de ventes avant de construire quoi que ce soit. Ils savent ce que l'acheteur a soulevé dans les conversations antérieures, et vous savez ce que le système peut réaliste montrer dans les conditions de production. Une démonstration construite sans ventes peut répondre à des questions que l'acheteur n'a jamais posées. Une démonstration construite sans l'Architecte peut surpromesse. De toute façon, la démonstration perd en crédibilité et ralentit l'opportunité. Préparation des donnéesUtilisez des informations qui ressemblent aux données de l'acheteur en structure et en volume. Pour les acheteurs réglementés, utilisez des données anonymisées qui reflètent toujours les mêmes contraintes structurelles que l'environnement réel. Les acheteurs jugent la démonstration par les données qu'elle contient. Les noms de champs réalistes et les modèles de données rendent le scénario réel. Quand les données ressemblent aux leurs, la démonstration se défend d'elle-même.

Le placement des limites mérite une attention délibérée Des quatre décisions de conception de démonstration, le placement des limites est celui qui va le plus souvent à l'encontre de l'instinct. En pratique, nommer une faiblesse peut sembler risqué, donc la tentation est de la cacher ou de l'adoucir. Cela échoue généralement. Imaginez le moment où l'acheteur demande : « Qu'est-ce que cela ne gère pas bien ? » Si la réponse est vague, la confiance baisse. Si la réponse est claire et délimitée, l'acheteur voit de la discipline au lieu de la défensive. C'est pourquoi vous devriez décider à l'avance laquelle une ou deux contraintes vous nommerez et comment vous les encadrerez. Montrez que la limite est délibérée, que c'est ce que la solution est construite pour faire, et c'est ce qu'elle n'est pas construite pour faire. Cela importe encore plus dans les industries réglementées comme la santé, les services financiers et le secteur public. Dans ces paramètres, une limite claire signale souvent la rigueur, tandis qu'une déflexion signale le risque. Un moyen simple de se préparer est de demander :

Quelle est la limite ? Pourquoi existe-t-elle ? Que se passe-t-il si le cas d'usage doit aller au-delà ?

La portée conjointe réussie commence avant la session Piste partenairNon testé par l'examen Architecte Cette même discipline se porte directement dans la portée conjointe avec l'équipe Applied AI. Une bonne session de portée n'est pas un endroit pour comprendre les bases pour la première fois. C'est un endroit pour affiner les choix, tester les hypothèses et résoudre les questions qui ont besoin d'une contribution spécialisée. Si la démonstration prouve que vous comprenez le problème de l'acheteur, la session de portée prouve que vous êtes prêt à façonner une solution crédible autour de lui. Cela ne fonctionne que si vous arrivez avec trois choses préparées :

Une vue documentée des exigences et contraintes du client. Cela capture ce qui est sorti de la découverte : le cas d'usage, le flux de travail, les parties prenantes, les conditions de données, l'environnement technique, les préoccupations de conformité et les critères de succès. Cela donne à la session un point de départ partagé. Un modèle proposé ou un petit ensemble de modèles candidats, avec des compromis déjà nommés. Entrez avec un point de vue. Montrez les options probables, ce que chacun vous donne, ce que chacun abandonne, et où les risques se situent. Une courte liste de questions ouvertes que l'équipe Applied AI est la mieux placée pour répondre. Ce sont les questions qui valent la peine de passer la session : comportement du modèle, implications architecturales, contraintes de mise à l'échelle, approche d'évaluation, considérations de sécurité ou ajustement du modèle.

Dans la démonstration, vous gagnez la confiance en identifiant clairement les limitations. Dans la portée conjointe, vous gardez cette confiance en apportant une vue structurée du problème, des options et des questions sans réponse.

Les objections se divisent en différentes catégories, et chacune nécessite une réponse différente Les objections techniques dans un cycle de vente se divisent généralement en trois catégories. Les objections de capacité demandent si le système peut faire la chose du tout. Les objections de gouvernance et de conformité demandent si le déploiement peut être approuvé, contrôlé et prouvé d'une manière que l'acheteur peut défendre. Les objections de choix de conception demandent pourquoi vous avez fait ce choix au lieu d'un autre. Celles-ci nécessitent plus que juste une justification. Vous devez expliquer le compromis que le choix fait et ce que l'alternative aurait coûté, en utilisant la même structure de traduction que vous avez utilisée quand vous avez présenté le compromis en premier lieu.

Piste partenairNon testé par l'examen Architecte La carte d'engagement de mise sur le marché devrait traiter la conception de démonstration comme un flux de travail suivi. C'est pourquoi elle inclut une colonne de conception de démonstration avec scénario, limitations identifiées, source de données confirmée et approbation de l'équipe de ventes comme livrables explicites. Cela importe le plus quand un partenaire exécute des opportunités parallèles ou quand les Architectes se transmettent à mi-cycle, car la continuité dépend cruciale de ce qui est documenté.

Coût · Complexité · Risque

Coût : Préparer une présentation de compromis et une démonstration spécifique au scénario prend du vrai temps d'Architecte, mais c'est beaucoup moins cher qu'une opportunité stagnante ou une approbation qu'une partie prenante retire plus tard. Complexité : Trois compétences distinctes se situent sous ce travail, et deux d'entre elles vont souvent à l'encontre de l'instinct : nommer le coût d'inversion et placer clairement les limites. Les deux nécessitent une pratique délibérée pour s'améliorer. Risque : L'échec coûteux est un faux alignement. Quand une décision semble approuvée dans la salle, mais le coût d'inversion n'a jamais été rendu explicite, et la conséquence surgit plus tard.

Écran 6 : L'approbation qui n'était pas un choix éclairé

Attention auxCompromi et GTM5 min L'approbation qui n'était pas un choix éclairé

ConfigurationUne partie prenante qui dit oui à la fin d'une présentation de compromis semble avoir compris le compromis. La présentation était complète et techniquement exacte, et la salle semblait alignée. Ce sentiment est le piège.

Un examen de pré-production reconstruit, du point de vue du CTO L'Architecte a présenté un compromis de stratégie de contexte en termes techniques. Le CTO a posé une question sur le coût, l'Architecte l'a répondue avec précision, et le CTO a approuvé. Six semaines plus tard, le coût par appel plus élevé est apparu sur la facture de production. Ceci est l'échange, et puis la note que le CTO a écrite quand la facture a été reçue. Cela montre où la présentation a répondu à la mauvaise version de la question.

Échange reconstruit + suivi

Architecte : « Nous recommandons la fenêtre de contexte plus grande, afin que le document de politique complet reste en vue à chaque appel. Cela garde la conception plus simple et évite une couche de récupération. » CTO : « À quoi ressemble le coût par appel ? » Architecte : « Environ quatre cents par interaction au niveau de modèle que nous utilisons. Si le document de politique est statique sur les appels, la mise en cache des prompts pourrait réduire considérablement la portion d'entrée de cela. » CTO : « D'accord, approuvé. Gardons-le simple. » [Six semaines plus tard, sur la facture de production] Note du CTO à l'équipe de compte : « J'ai approuvé une direction, pas un nombre. Personne ne m'a dit que quatre cents fois notre volume d'appels était une ligne mensuelle à cinq chiffres. Si le document était statique, pourquoi n'utilisions-nous pas la mise en cache ? Et si nous allions construire autour du contexte complet de toute façon, j'avais besoin de savoir ce que défaire cela coûterait une fois que le système en dépendait. »

Le problème : le coût d'inversion n'a jamais entré la conversation La présentation a nommé ce que la conception a gagné, la simplicité, et elle a répondu au coût par appel comme demandé. Ce qu'elle n'a jamais identifié était le troisième élément : qu'arrive-t-il à l'entreprise quand ce choix rencontre le volume de production et doit être inversé après que le système soit construit autour de lui. Le CTO a approuvé un nombre par appel, pas une facture mensuelle, et pas le coût de défaire une décision plus tard. Deux parties du compromis ont été clairement communiquées et comprises. La troisième ne l'était pas, et il s'est avéré être celle qui porte la charge.

Pourquoi cela a échoué : une présentation exacte peut toujours répondre à la mauvaise question Une partie prenante qui a approuvé une recommandation sans comprendre le coût d'inversion n'a pas fait un choix éclairé. Le CTO a entendu un chiffre par appel et un argument de simplicité et a raisonnablement dit oui. L'élément du coût d'inversion était le seul facteur qui aurait changé la décision. Nommez les trois éléments à chaque fois et nommez le coût d'inversion surtout quand la conception semble évidemment plus simple.

Écran 7 : Point de contrôle : recommandez l'option et nommez l'élément manquant

Compromis et GTM · Point de contrôle Point de contrôle : recommandez l'option et nommez l'élément manquant

Essayez maintenant. Lisez le résumé d'une phrase de la partie prenante et les trois présentations d'options écrites en langage clair. Une option est techniquement exacte et présentée de manière complète. Une est techniquement exacte, mais sa présentation manque d'un élément. Une est inappropriée pour les contraintes énoncées. Recommandez l'option à présenter, puis nommez l'élément unique manquant de la présentation de la deuxième option.

Résumé Un assureur de taille moyenne veut que Claude rédige les réponses des experts en sinistres aux demandes des assurés. Le flux de travail est couvert par la réglementation d'assurance d'État avec une obligation de piste d'audit. Le volume est élevé et stable. Le sponsor se soucie de la qualité des réponses et de maintenir un enregistrement défendable de chaque interaction automatisée.

OptionPrésentation telle que présentée

AModèle de flux de travail avec journalisation par interaction intégrée. Gagne : piste d'audit complète, porte de qualité avant envoi. Abandonne : un petit coût de latence de l'étape de journalisation. Inversion : mineure, la journalisation peut être ajustée sans reconception. BModèle de flux de travail qui échange l'étape de journalisation pour une latence plus basse. Gagne : réponses plus rapides. Abandonne : détail d'audit par interaction. CAppel augmenté unique sans journalisation et sans porte humaine, choisi pour le coût de construction le plus bas.

Partie 1 : Quelle option devriez-vous recommander ?

AOption A, journalisation intégrée, piste d'audit complète BOption B, échange la journalisation pour une latence plus basse COption C, pas de journalisation, pas de porte humaine

Partie 2 : Quel élément unique manque de la présentation de l'option B ?

ACe que l'option B gagne (les réponses plus rapides ne sont pas nommées assez clairement) BCe que l'option B abandonne (la perte de détail d'audit n'est pas expliquée) CLe coût d'inversion, ce qu'il coûte de restaurer la journalisation après que la conception dépend du gain de latence DLa posture de conformité que cette option crée

Vérifier la réponse Ignorer

Écran 8 : La boucle de rétroaction décide quels signaux atteignent une partie prenante, et l'SLA nomme ce que vous devez

Boucles de rétroaction La boucle de rétroaction décide quels signaux atteignent une partie prenante, et l'SLA nomme ce que vous devez quand un se brise L'observabilité de production et la piste d'audit enregistrent ce qu'un déploiement en direct fait. Ce sujet couvre le filtrage de ces signaux, la décision d'escalader au-delà de l'équipe, et la définition de ce que l'SLA exige quand les performances tombent en dessous de la norme. Le système est en direct ; le garder digne de confiance au fil du temps ce qui prend de l'effort. En termes de cycle de vie, la boucle de rétroaction est l'étape de surveillance et d'itération du cycle de vie du déploiement.

Un déploiement en direct dérive sans surveillance active Imaginez un assistant de support client qui est lancé en bon état. Il répond rapidement, reste dans un ton, et gère bien les questions les plus courantes. D'abord, tout semble stable. Mais au fil du temps, les modèles d'utilisation changent, de nouveaux styles d'invite apparaissent, et les problèmes des clients deviennent plus complexes. Certaines réponses ralentissent simplement, et certaines réponses commencent à manquer la cible entièrement. Rien ne se casse dramatiquement, ce qui rend la dérive difficile à attraper. La qualité s'érode graduellement plutôt que tout à la fois. Une équipe sans boucle de rétroaction peut ne pas voir le déclin jusqu'à ce que les utilisateurs le ressentent déjà.

La boucle de rétroaction est une couche de décision qui se situe au-dessus de la pile d'observabilité L'observabilité vous donne la matière première : latence, taux d'erreur, scores d'évaluation, modèles d'utilisation et autres signaux du système. Mais un signal en soi n'est pas encore une décision. Un pic peut être du bruit. Un autre peut pointer vers un vrai problème. Un troisième peut être important seulement s'il continue à se produire. La boucle de rétroaction se situe au-dessus de l'observabilité pour répondre à cinq questions : Signaux → Triage → Décider → Agir → Examiner

1Signaux : Qu'est-ce que le système nous montre ? 2Triage : Qu'a besoin d'attention maintenant, et qu'est-ce qui peut attendre ? 3Décider : Le problème a-t-il besoin d'une correction d'équipe, d'un examen de partie prenante ou d'aucune action ? 4Agir : Quelle correction, mise à jour de garde-fou ou escalade est requise ? 5Examiner : La réponse a-t-elle fonctionné et la règle a-t-elle besoin de changer ?

Pensez-y comme une salle de contrôle dans une gare. Les capteurs peuvent vous dire où les trains sont en retard, mais quelqu'un doit toujours décider si un retard est mineur, si les passagers doivent être informés, et si l'horaire doit changer. Cette couche de jugement est ce qui rend le système gérable au lieu de juste mesurable.

Un SLA nomme trois choses, et les seuils viennent de quelque part de tangible. Une fois que la boucle de rétroaction décide que quelque chose importe, l'SLA définit ce qui se passe quand il franchit la ligne. Un SLA est un engagement qui rend trois choses claires :

1Qu'est-ce que nous mesurons ? 2Qu'est-ce qui compte comme une violation ? 3Que se passe-t-il quand une violation se produit ?

Le seuil ne devrait jamais être arbitraire. Il devrait tracer jusqu'à quelque chose de tangible :

1La latence devrait refléter l'attente d'expérience utilisateur identifiée plus tôt 2La disponibilité devrait refléter la criticité du déploiement pour l'entreprise 3La qualité devrait refléter les résultats d'évaluation et les critères d'acceptation déjà établis

Cette traçabilité importe parce qu'elle garde l'SLA défendable. Si le nombre ne peut pas être lié à l'une de ces sources, c'est probablement juste une cible que quelqu'un a choisie parce qu'elle semblait raisonnable. Le coût est l'attente qui se brise le plus souvent après le lancement. Le volume de production dépasse régulièrement la preuve de concept d'un à deux ordres de grandeur, donc un coût qui semblait trivial dans la preuve de concept devient une ligne mensuelle à cinq chiffres à l'échelle. Prévenez-le : donnez à la partie prenante une prévision de consommation au volume de production attendu, nommez la posture de contrôle des dépenses (mise en cache, nivellement de modèle, alertes budgétaires), et encadrez la narration de nivellement de modèle avant la première facture plutôt qu'après.

Les déploiements réglementés ajoutent des points de contrôle d'examen qui s'exécutent selon un calendrier L'observabilité enregistre ce qui s'est passé ; la boucle de rétroaction détermine quoi faire à ce sujet. Dans les déploiements réglementés, certains examens doivent se produire même quand rien n'a mal tourné. Un flux de travail de santé avec une obligation de documentation peut nécessiter des audits de sortie périodiques selon un calendrier défini. Un déploiement de résidence des données peut avoir besoin d'une confirmation programmée que l'environnement satisfait toujours les règles de résidence. Ce sont des obligations de temps de conception plutôt que des tâches à ajouter plus tard. S'ils ne sont pas construits tôt, ils deviennent beaucoup plus chers à établir quand quelqu'un demande une preuve. Construisez un tableau de gouvernance qui mappe chaque signal à son déclencheur, la réponse de l'Architecte et tout point de contrôle réglementaire. Le tableau devrait exister avant le lancement. C'est le mécanisme qui transforme la politique en une routine d'exploitation. Tableau de gouvernance des signaux de production Type de signalDéclencheur d'examenAction de l'ArchitectePoint de contrôle de l'industrie réglementée

Qualité de sortie (score d'évaluation)Le score franchit le seuil tiré de la suite d'évaluation. Diagnostiquer si la cause est une dérive d'invite, de données ou de modèle, puis décider d'itérer par rapport à réarchitecturer. Audit de sortie périodique par rapport à la norme de documentation, selon un calendrier établi, indépendamment du score. Latence p95Franchit le budget défini à partir des exigences d'expérience utilisateur. Enquêter sur le goulot d'étranglement, puis ajuster ou escalader vers un examen de partie prenante si le budget lui-même est incorrect. Généralement aucun, sauf si la latence masque une lacune de journalisation ou de traçabilité. Coût par interactionFranchit l'enveloppe budgétaire convenue en découverte. Identifier le moteur, puis apporter un compromis à la partie prenante si le budget doit être revisité. Généralement aucun, sauf si les contrôles de coûts font partie d'une contrainte d'exploitation réglementée. Configuration de résidence des donnéesConfirmation programmée. Confirmer et enregistrer la posture de résidence et signaler immédiatement toute dérive. Confirmation de résidence selon le calendrier établi.

Coût · Complexité · Risque

Coût : La boucle crée un effort d'architecte continu. Notez que c'est moins cher que de découvrir le déclin lors d'un examen trimestriel après que chaque tableau de bord semblait bon. Complexité : La partie la plus difficile est de décider quels signaux méritent l'attention, et lesquels sont du bruit, car l'outillage d'observabilité ne peut pas faire ce jugement pour vous. Risque : Le plus grand mode d'échec est un point de contrôle de conformité qui n'a jamais été câblé à un déclencheur, permettant à une violation de norme documentée de s'exécuter pendant des semaines avant qu'un examen de routine ne l'attrape.

Écran 9 : La pile d'observabilité qui a remplacé la boucle de rétroaction

Attention auxBoucles de rétroaction5 min La pile d'observabilité qui a remplacé la boucle de rétroaction

ConfigurationUn Architecte qui a construit une pile d'observabilité rigoureuse a fait le travail technique plus difficile. Les tableaux de bord sont en direct, les alertes sont configurées, et les données circulent. Il est facile, et raisonnable, de conclure que la rétroaction des parties prenantes est couverte.

Une trace reconstruite : quatre-vingt-dix jours de journal d'alerte par rapport au calendrier d'examen des parties prenantes L'extrait ci-dessous place un journal d'alerte de déploiement à côté de son calendrier d'examen des parties prenantes sur une fenêtre de quatre-vingt-dix jours. Le journal d'alerte montre une dérive soutenue de la qualité de sortie sur les semaines quatre à sept. Le calendrier d'examen montre aucun examen qui s'est produit dans cette fenêtre. Une seule ligne dans un tableau de gouvernance de boucle de rétroaction aurait connecté les deux. Cela montre à quoi ressemble l'écart dans l'enregistrement.

FenêtreEnregistrement de la pile d'observabilitéCalendrier d'examen des parties prenantesQuoi la boucle aurait dû faire

Semaines 1-3Le score d'évaluation est stable à la ligne de base, avec latence et coût nominaux. Examen de lancement tenu en semaine 1. Nominal. Aucune escalade nécessaire. Semaines 4-7Le score d'évaluation dérive vers le bas semaine après semaine, avec taux d'erreur plat, donc aucune alerte difficile n'est déclenchée. Aucun examen programmé ou tenu. Un déclencheur de dérive de qualité aurait dû escalader vers un examen d'Architecte en semaine 5, et en avant vers un examen de partie prenante une fois que le diagnostic a confirmé la dérive. Semaines 8-12Le score est toujours en déclin, et la partie prenante rapporte que la sortie est « moins utile dernièrement ». L'examen trimestriel le fait enfin surface en semaine 12. Par conception, la boucle aurait attrapé cela sept semaines plus tôt.

Le problème : les signaux existaient, mais rien n'a décidé qu'ils importaient Chaque métrique que le déploiement avait besoin était déjà collectée. Le score d'évaluation dérivait visiblement vers le bas depuis la semaine quatre. Ce qui manquait était la couche de décision : aucune règle de gouvernance ne mappait une dérive de qualité lente à un déclencheur d'examen. La dérive n'a jamais franchi un seuil de taux d'erreur, donc aucune alerte n'a été déclenchée. Une dérive sans déclencheur est invisible jusqu'à ce qu'un humain la remarque par hasard. La pile mesurait la bonne chose et disait à personne que cela importait.

Pourquoi cela a échoué : la surveillance n'est pas une boucle de rétroaction Un tableau de bord collecte et affiche les signaux. Une boucle de rétroaction mappe chaque signal à un déclencheur, un propriétaire et une action requise. La pile d'observabilité a collecté les signaux mais n'avait aucune règle de gouvernance mappant un signal à un déclencheur ou propriétaire. Construisez le tableau de gouvernance qui mappe chaque signal à un déclencheur, une action et un propriétaire. Incluez à la fois les dérives lentes et les défaillances difficiles.

Écran 10 : Point de contrôle : triez les signaux de production

Boucles de rétroaction · Point de contrôle Point de contrôle : triez les signaux de production

Essayez maintenant. Voici neuf signaux d'un déploiement de production. Faites glisser chacun dans le compartiment où il appartient : Surveillance interne, Examen d'Architecte, Examen de partie prenante ou Bruit.

1 · La latence p99 a augmenté de 40 ms, toujours dans le budget. 2 · Le score d'évaluation est en baisse depuis trois semaines, la tendance est claire. 3 · La confirmation programmée de résidence des données est due. 4 · Une demande malformée d'un client connu mauvais. 5 · Le coût par interaction a franchi le seuil budgétaire convenu. 6 · Un travail par lot à 2 h du matin a enregistré une nouvelle tentative qui a ensuite réussi. 7 · L'audit de sortie trimestriel par rapport à la norme de documentation est dû. 8 · L'utilisation de token a augmenté avec une augmentation de trafic saisonnière connue. 9 · Un nouveau modèle d'invite a été expédié, et le taux d'erreur est plat.

Surveillance interne

Examen d'Architecte

Examen de partie prenante

Bruit

Vérifier les placements Ignorer

Écran 11 : La documentation qui survit à votre absence sert le destinataire de la transmission, l'auditeur

Documentation La documentation qui survit à votre absence sert le destinataire de la transmission, l'auditeur et l'Architecte qui revient La boucle de rétroaction garde le système sain pendant que vous le gérez. La documentation est ce qui le garde fonctionnant après votre départ. Ce sujet transforme la conception complète en documentation qui survit à une transmission et satisfait un examinateur de conformité. Soit la conception porte son propre raisonnement dans cette transmission, soit ce raisonnement disparaît le moment où vous partez. En termes de cycle de vie, la documentation est l'étape de transmission du cycle de vie du déploiement.

Un document sert trois lecteurs, et servir seulement un d'eux le rend incomplet La documentation architecturale sert trois lecteurs. L'ingénieur héritier reprend un déploiement auquel il n'a pas participé. L'auditeur arrive plus tard, cherchant une preuve qu'un contrôle spécifique est en direct et comptabilisé. L'architecte qui revient, souvent vous, revient des mois plus tard sans mémoire des sessions de conception. Un document construit pour l'un de ces lecteurs et pas les autres est incomplet même quand il est détaillé.

Pour le destinataire de la transmission : les alternatives rejetées importent tout autant que les décisions prises Pour celui qui hérite du système, le document doit porter les décisions qui ont été prises, les alternatives qui ont été rejetées, et la raison de chaque rejet. Une conception livrée sans ses alternatives rejetées ne peut pas être comprise par quelqu'un qui n'était pas dans la salle. Ils inverseront la bonne décision pour la mauvaise raison ou défendront la mauvaise décision parce qu'ils ne peuvent pas dire quel compromis elle résolvait. Les options rejetées expliquent pourquoi la conception est façonnée comme elle l'est.

Pour l'examinateur de conformité : la preuve importe plus que les assertions Pour l'examinateur de conformité, le document doit porter chaque obligation réglementaire, le contrôle technique qui la satisfait, le propriétaire de ce contrôle, et l'artefact de preuve qui démontre que le contrôle fonctionne. C'est le registre de contrôle de déploiement réglementé, porté en avant dans le document vivant qui gouverne la vie de production du déploiement. L'examinateur n'accepte pas de simples assertions. Il exige une preuve, ce qui signifie qu'une déclaration qu'un contrôle existe n'est pas suffisante en soi.

Pour l'Architecte qui revient : navigable sans un briefing Pour l'Architecte qui revient des mois plus tard, le document doit se tenir seul. Les décisions sont datées. Les hypothèses sont explicitement étiquetées comme des hypothèses plutôt qu'intégrées comme des faits. Les éléments ouverts ont des propriétaires et des critères de résolution. Le test est pratique : après avoir lu le document, un Architecte compétent qui n'était pas présent aux sessions de conception peut-il apporter une modification sûre au système ? Si la réponse est non, le document n'est pas complet.

La liste de contrôle de complétude de la documentation : Liste de contrôle de complétude de la documentation ChampCe qu'il captureeLecteur qu'il sert principalement

DécisionLe choix architectural qui a été fait, y compris la date. Les trois lecteurs. Alternatives rejetéesLes options qui ont été considérées mais non choisies. Destinataire de la transmission. Compromis nomméLe compromis que la décision a résolu, exprimé en termes de gains, de coûts et d'implications d'inversionDestinataire de la transmission et Architecte qui revient. PropriétaireLa personne ou l'équipe responsable de la décision ou du contrôle à l'avenir. Examinateur de conformité et destinataire de la transmission. Artefact de preuveL'artefact qui démontre qu'un contrôle fonctionne réellement. Examinateur de conformité. Statut prêt pour l'auditSi la preuve disponible est actuelle et suffisante pour l'examen. Examinateur de conformité.

Coût · Complexité · Risque

Coût : Écrire la justification et la preuve au moment de la conception prend du temps. La reconstruire plus tard à partir de fils d'e-mail, ou ne pas le faire, coûte une inversion incorrecte en production. Complexité : La discipline est d'enregistrer le pourquoi, pas seulement le quoi, et d'étiqueter les hypothèses comme des hypothèses, ce qui est facile à sauter quand le raisonnement semble évident pour la personne qui l'a vécu. Risque : L'échec coûteux est un successeur qui inverse une décision porteuse de charge parce que la justification n'a jamais été documentée, réintroduisant une violation de contrainte que la conception originale avait résolue.

Écran 12 : La justification de conception qui vivait dans la tête de l'Architecte

Attention àDocumentation5 min La justification de conception qui vivait dans la tête de l'Architecte

ConfigurationUn Architecte qui était présent à chaque décision de conception détient la justification pour toutes. L'écrire semble redondant quand vous le savez déjà, et il y a toujours quelque chose de plus urgent que la documentation. C'est exactement comment la justification part avec la personne.

Une autopsie : une transmission de services financiers où la justification n'a jamais atteint la page Dans ce cas, l'Architecte original a quitté un engagement de services financiers de taille moyenne douze semaines après le lancement. Son remplaçant a hérité d'un diagramme d'architecture approfondi sans justification attachée. Un problème de performance a incité une proposition de changer les stratégies de contexte, le remplaçant a fait le changement, et il a réintroduit un modèle de manipulation de données qui violait la contrainte de résidence des données du déploiement. L'autopsie trace l'échec à la seule ligne qui manquait. Voici à quoi cela ressemble dans l'enregistrement.

ÉtapeQuoi s'est passéCe que le document portait

LancementL'Architecte original conçoit une stratégie de contexte spécifiquement pour garder les données réglementées en région. Un diagramme d'architecture montrant la conception finale. TransmissionL'Architecte original part en semaine douze. Aucune session de conception n'est enregistrée. Le diagramme, sans alternatives rejetées et sans justification. ChangementLe remplaçant frappe un problème de performance et change les stratégies de contexte pour le corriger. Rien n'explique pourquoi la stratégie originale a été choisie. ÉchecLe changement réintroduit un modèle de manipulation de données qui casse la règle de résidence des données. La raison pour laquelle la conception originale a évité ce modèle existait seulement dans la tête de l'Architecte parti.

Ce qui a échoué : le diagramme a montré le quoi et a perdu le pourquoi Le remplaçant était compétent et a agi raisonnablement sur les informations qu'il avait. Le diagramme lui a dit ce que le système était, pas pourquoi il était comme ça. La stratégie de contexte originale était un choix délibéré pour satisfaire une contrainte de résidence, et ce raisonnement n'a jamais été écrit comme une décision avec un compromis nommé et une alternative rejetée. Sans justification documentée, le remplaçant ne pouvait pas dire que la stratégie qu'il changeait était porteuse de charge pour la conformité, donc il a inversé la bonne décision pour une mauvaise raison compréhensible.

Pourquoi cela a échoué : une conception sans sa justification est une conception qui ne peut pas être changée en toute sécurité Le test de complétude est de savoir si un Architecte compétent qui n'était pas dans la salle peut apporter une modification sûre après avoir lu le document. Ici la réponse était non, et personne ne le savait jusqu'à ce que la production se casse. Enregistrez la décision, les alternatives rejetées, et le compromis que chacune a résolu. Rappelez-vous si cela n'est jamais écrit, alors cela part avec vous.

Écran 13 : Point de contrôle : placez les artefacts de documentation

Documentation · Point de contrôle Point de contrôle : placez les artefacts de documentation

Essayez maintenant. Le plan a deux axes : l'un va de « sert le destinataire de la transmission » à « sert l'examinateur de conformité », l'autre de « documente l'intention » à « documente la preuve ». Faites glisser chacune des six cartes d'artefact dans la zone qui décrit le mieux sa fonction principale.

Diagramme d'architecture Journal de décision avec justification Registre de contrôle avec liens de preuve Runbook de déploiement Résumé des résultats de test Registre d'hypothèse

← Destinataire de la transmissionExaminateur de conformité →

Transmission · Intention

Conformité · Intention

Transmission · Preuve

Conformité · Preuve

↑ Documente l'intention / Documente la preuve ↓

Vérifier les placements Ignorer

Écran 14 : La sélection du point d'entrée revient avec l'image de production complète, et le document de résultat

Point d'entrée et résultats La sélection du point d'entrée revient avec l'image de production complète, et le document de résultat transforme le travail en IP réutilisable Ce sujet couvre comment le déploiement a été acheminé et ce qu'il a produit, transformant le travail en IP partenaire qui survit à l'engagement. La sélection du point d'entrée revient ici avec le contexte de production complet en vue.

La question du point d'entrée change une fois que le déploiement est en direct sur plus d'une plateforme Le module antérieur a introduit la sélection de route comme un pré-filtre de point d'entrée et de conformité : l'API Anthropic directe, AWS Bedrock, GCP Vertex AI et Microsoft Foundry servent chacun différentes postures d'approvisionnement partenaire et exigences de conformité régionale. Ce sujet revient à cette décision avec le contexte de production complet. La question n'est plus quelle route survit au pré-filtre de conformité. C'est quelle route fonctionne le mieux sur les dimensions de latence, de coût et de conformité d'un déploiement multi-plateforme en direct. Parce que les capacités du point d'entrée changent, chaque affirmation spécifique dans cette section est re-vérifiée par rapport à platform. claude. com/docs et anthropic. com au moment de la construction.

Les déploiements multi-plateforme exposent des problèmes qu'un système à point d'entrée unique ne montre jamais Un déploiement qui s'étend sur plus d'un point d'entrée expose une classe de problèmes qu'un système à point d'entrée unique ne montre pas. Les chaînes d'identification de modèle diffèrent sur les routes. La disponibilité des fonctionnalités peut être en retard sur une route médiatisée par un fournisseur de services cloud par rapport à l'API directe. La disponibilité régionale sur Bedrock et Vertex nécessite une configuration explicite, et la valeur par défaut sur un point de terminaison global est le modèle courant qui casse une exigence de résidence des données. Un Architecte concevant sur plusieurs points d'entrée a besoin d'une carte de responsabilité du point d'entrée documentée avant d'écrire la première ligne de code d'intégration.

Une application multi-point d'entrée doit dire quel point d'entrée possède quelle tâche, et pourquoi Une application qui intègre plusieurs points d'entrée Claude dans un flux de travail nécessite que vous spécifiiez quel point d'entrée gère quelle tâche et la raison. Un flux de travail qui utilise l'API pour l'inférence back-end, Claude Code pour une sous-tâche d'ingénierie, et un point de terminaison Bedrock pour un chemin de données réglementé n'est pas inhabituel à l'échelle d'entreprise. Chaque limite de point d'entrée est un point d'intégration avec son propre profil d'authentification, de journalisation et de mode d'échec. La carte de responsabilité du point d'entrée rend ces limites explicites et prévient l'échec multi-point d'entrée le plus courant : un point d'entrée choisi pour une tâche prenant graduellement une autre parce que la logique d'acheminement n'a jamais été documentée.

Le document de résultat rend la valeur lisible au-delà de l'équipe qui l'a construite La documentation de résultat client est l'artefact qui rend la valeur du déploiement compréhensible aux personnes qui n'étaient pas sur la construction. Un document de résultat bien structuré couvre six champs : le cas d'usage et sa limite de portée, la métrique avant le déploiement, la métrique après le déploiement, le contrôle qui rend le résultat auditable, le propriétaire responsable de la mesure continue, et le potentiel de réutiliser le modèle pour d'autres clients ou engagements. Les métriques techniques seules ne font pas ce document. Les résultats commerciaux avant et après et les notes de réutilisation sont ce qui le transforment en un actif réutilisable.

La matrice de décision du point d'entrée de déploiement : Matrice de décision du point d'entrée de déploiement PlateformeProfilProfil de conformitéQuand la choisir

API Anthropic directeLes nouvelles fonctionnalités en premier, avec le moins de sauts supplémentaires. Défaut fort mais confirmez la couverture par configuration. Utilisez par défaut sauf si une règle d'approvisionnement ou de résidence pointe ailleurs. AWS BedrockConfigurable par région, avec possible retard de fonctionnalité par rapport à direct. S'adapte aux règles d'approvisionnement et de région centrées sur AWS quand configurées explicitement. Partenaire standardisé sur AWS et a besoin d'une exécution en région. GCP Vertex AIConfigurable par région, avec possible retard de fonctionnalité par rapport à direct. S'adapte aux règles d'approvisionnement et de région centrées sur GCP quand configurées explicitement. Partenaire standardisé sur GCP avec un chemin d'approvisionnement Vertex. Route Microsoft Foundry (Azure)Varie selon la forme d'hébergement : les modèles hébergés sur Azure exécutent l'inférence dans l'environnement Azure du partenaire (GA) ; les modèles hébergés sur Anthropic acheminent vers l'infrastructure Anthropic. Vérifiez la résidence et la couverture par route, et ne supposez pas à partir du nom de la plateforme. L'approvisionnement partenaire ou la posture de résidence exige cette route spécifique.

Piste partenaireLe cadrage « réutiliser le modèle pour d'autres clients ou engagements » et le champ Potentiel de réutilisation dans le modèle ci-dessous sont du contenu pertinent pour la piste partenaire ; le reste du document de résultat est sur le plan (6. 4). Le modèle de documentation de résultat client : Modèle de documentation de résultat client ChampCe qu'il enregistre

Cas d'usage avec limite de portéeCe que le déploiement fait et ce qu'il ne fait pas. Métrique avantLa métrique commerciale telle qu'elle se tenait avant le déploiement. Métrique aprèsLa même métrique après le déploiement, mesurée en utilisant la même définition. Contrôle en placeQuoi rend la comparaison avant et après auditable plutôt que simplement affirmée. Propriétaire de la mesureQui possède la mesure continue après la fermeture de l'engagement. Potentiel de réutilisationComment le modèle se transfère à d'autres clients ou engagements en tant qu'IP.

Coût · Complexité · Risque

Coût : Choisir la mauvaise plateforme de déploiement ou produire un document de résultat mince est bon marché à faire et cher à défaire : l'inadéquation de résidence peut bloquer le lancement, et un document basé sur les métriques ne peut pas justifier l'expansion. Complexité : L'acheminement multi-plateforme multiplie les points d'intégration, chacun avec son propre profil d'authentification, de journalisation et d'échec. La carte de responsabilité du point d'entrée est la seule chose qui les garde compréhensibles au fil du temps. Risque : L'échec coûteux est une configuration par défaut qui casse silencieusement la résidence des données, ou un document de résultat qu'un sponsor ne peut pas apporter à un CFO parce qu'il n'a jamais capturé la valeur commerciale.

Écran 15 : Le document de résultat qui a mesuré la mauvaise chose

Attention auPoint d'entrée et résultats5 min Le document de résultat qui a mesuré la mauvaise chose

ConfigurationUn déploiement qui a bien fonctionné lors d'un lancement contrôlé a des données derrière lui. Un Architecte fermant l'engagement a tout ce dont il a besoin pour écrire le document de résultat. L'écrire rapidement à partir des métriques déjà à portée de main semble être le bon mouvement, et l'engagement est terminé avant que quelqu'un remarque ce que le document ne peut pas répondre.

Une anecdote : le document de résultat qui ne pouvait pas survivre à la première question d'un CFO Un Architecte a produit un document de résultat client en utilisant les métriques les plus faciles à exporter de la pile d'observabilité : volume de demandes, latence moyenne et taux d'erreur. Le sponsor client l'a apporté à son CFO pour justifier l'expansion du déploiement. La première question du CFO était ce que le déploiement avait économisé ou produit en termes commerciaux, et le document ne pouvait pas y répondre. Les deux champs qui l'auraient rendu utilisable n'ont jamais été remplis. Voici comment cela s'est déroulé.

Le sponsor a ouvert avec le document tel qu'écrit : « Voici le déploiement. Quarante mille demandes par mois, latence moyenne inférieure à deux secondes, taux d'erreur inférieur à un demi pour cent. » Le CFO : « Cela me dit qu'il fonctionne. Qu'a-t-il fait pour nous ? Quels étaient les délais de traitement des réclamations avant cela, et quels sont-ils maintenant ? Parce que c'est le nombre qui justifie de dépenser plus. » Le sponsor n'avait aucune preuve à pointer. Le document mesurait que le système fonctionnait, mais il ne mesurait pas ce qu'il changeait.

Ce qui a échoué : le document a capturé les métriques techniques sans les résultats commerciaux Le volume, la latence et le taux d'erreur sont réels et valent la peine d'être suivis, mais aucun d'eux n'est un résultat commercial. Les champs qui auraient rendu le document utilisable pour la conversation du CFO étaient le avant et après sur la métrique commerciale que le cas d'usage ciblait, le délai de traitement des réclamations, et le contrôle qui rendait cette comparaison auditable. Sans le nombre avant, il n'y a pas d'histoire. Sans contrôle, le nombre après est une affirmation. Le document était complet en tant qu'enregistrement technique et inutile en tant que cas pour l'expansion.

Pourquoi cela a échoué : les métriques faciles à exporter sont rarement celles qui justifient le coût La pile d'observabilité collecte vos métriques techniques gratuitement mais sans les ancrer dans les données, vous vous retrouvez avec des tableaux de bord qui semblent informatifs et ne signifient rien. Cependant, le document de résultat existe pour un lecteur différent, le sponsor qui doit justifier le déploiement vers le haut. Capturez la métrique avant au démarrage, nommez le contrôle qui rend la comparaison auditable, et ajoutez la note de réutilisation, afin que le document puisse faire le travail qu'un tableau de bord technique ne peut pas.

Écran 16 : Point de contrôle : choisissez la plateforme et les champs de résultat requis

Point d'entrée et résultats · Point de contrôle Point de contrôle : choisissez la plateforme et les champs de résultat requis

Essayez maintenant. Vous recevez un scénario de déploiement avec trois variables : la plateforme cloud principale du partenaire, le niveau d'obligation réglementaire du déploiement et la contrainte de performance principale. Définissez les trois variables. Un modèle de décision mappe la combinaison à une plateforme principale recommandée, une plateforme secondaire le cas échéant, et les deux champs de document de résultat que la combinaison doit être réutilisable.

Plateforme cloud principale

Sélectionner... AWS GCP Microsoft Foundry Direct (pas de cloud)

Niveau d'obligation réglementaire

Sélectionner... Aucun Modéré Strict

Contrainte de performance principale

Sélectionner... Sensible à la latence Sensible au coût Sensible à la conformité

Votre réponse : plateforme principale

Sélectionner... AWS Bedrock GCP Vertex AI Microsoft Foundry API Anthropic directe

Votre réponse : plateforme secondaire

Sélectionner... API Anthropic directe Aucune requise

Votre réponse : champs de résultat requis

Sélectionner... Contrôle en place (auditable) + Propriétaire de la mesure Métrique avant + Métrique après Métrique avant + Métrique après + Potentiel de réutilisation

Plateforme principale recommandée : Plateforme secondaire : Champs de résultat requis pour la réutilisation :

Vérifier la réponse Ignorer

Écran 17 : Cumulatif : architectez un déploiement multi-plateforme réglementé de bout en bout

Module · Cumulatif Cumulatif : architectez un déploiement multi-plateforme réglementé de bout en bout

Voici un résumé autonome. Un réseau de santé régional avec une obligation de confidentialité de la santé déploie un assistant de documentation clinique sur deux plateformes cloud. L'Architecte original se retire, et le CFO du client demande une preuve de la valeur commerciale. Travaillez à travers les sept décisions dans l'ordre. Chacune s'appuie sur la dernière.

Le résumé Le réseau s'étend sur deux États. Les infirmières dictent les interactions avec les patients, et l'assistant rédige la note clinique structurée. Un clinicien autorisé doit autoriser chaque note avant qu'elle n'atteigne le dossier du patient. Le déploiement porte une obligation de confidentialité de la santé avec une exigence de piste d'audit et une règle de résidence des données. Le partenaire est standardisé sur AWS mais exécute certains travaux back-end non réglementés sur l'API directe. Vous êtes quatre semaines dans le déploiement, et le CFO veut savoir ce que le déploiement vaut.

Décision 1 · Découverte : À partir du résumé, nommez la contrainte doit-prouver qui façonne le plus l'architecture, et écrivez la ligne d'exigence unique qu'elle force. (Applique le cadre de traduction de découverte. )

Révéler la réponse du modèle Contrainte doit-prouver : L'obligation de confidentialité de la santé avec exigence de piste d'audit. Ligne d'exigence : Le déploiement doit produire un enregistrement auditable de chaque note générée par le modèle examinée par un clinicien autorisé, traçable à l'interaction spécifique, parce que le flux de travail porte une obligation de preuve formelle en vertu d'un régime de confidentialité de la santé. Hypothèse à documenter : portée confirmée avec la conformité avant la conception.

Décision 2 · Présentation des compromis : Le réseau demande la conception avec la latence la plus basse. Encadrez le compromis entre réduire la journalisation pour la latence et garder la piste d'audit, en trois éléments y compris le coût d'inversion. (Applique la carte de traduction des compromis. )

Révéler la réponse du modèle Gain (réduire la journalisation) : Réponse perçue plus rapide ; flux de travail clinicien plus fluide. Abandonne : Détail d'audit par interaction requis pour satisfaire l'obligation de confidentialité de la santé. Coût d'inversion : Une fois que le système est construit autour du gain de latence, restaurer la journalisation nécessite une reconception de la couche d'interaction, et toute période d'écart crée une exposition de conformité qui doit être divulguée et corrigée.

Décision 3 · Boucle de rétroaction : Définissez une ligne de tableau de gouvernance qui mappe l'audit de sortie requis à un déclencheur d'examen de partie prenante selon un calendrier, indépendamment de toute métrique. (Applique le tableau de gouvernance de la boucle de rétroaction. )

Révéler la réponse du modèle Signal : Audit de sortie périodique par rapport à la norme de documentation de confidentialité de la santé. Déclencheur : Basé sur le calendrier (trimestriel, par obligation réglementaire), se déclenche indépendamment des scores d'évaluation ou des taux d'erreur. Propriétaire : Responsable de la conformité. Action : Examen de partie prenante avec enregistrement d'audit soumis à l'officier de conformité.

Décision 4 · Documentation : Nommez la ligne de journal de décision unique dont l'absence permettrait à votre successeur d'inverser un choix porteur de charge de conformité et énoncez l'alternative rejetée qu'elle doit porter. (S'applique à la liste de contrôle de complétude de la documentation. )

Révéler la réponse du modèle Ligne de décision : Stratégie de contexte, exécution explicite en région via Bedrock, pas un point de terminaison global. Alternative rejetée : Point de terminaison Bedrock global pour une configuration plus simple. Compromis nommé : Configuration plus simple par rapport à la conformité de résidence des données. Pourquoi porteur de charge : Un successeur qui ne voit pas cette justification inversera la configuration globale pour résoudre un problème de performance et cassera la résidence, exactement comme dans l'autopsie des services financiers.

Décision 5 · Sélection du point d'entrée : Choisissez les points d'entrée principal et secondaire compte tenu de la standardisation AWS, d'une obligation stricte et d'une règle de résidence, et nommez l'étape de configuration qui prévient l'échec de résidence courant. (Applique la matrice de décision du point d'entrée. )

Révéler la réponse du modèle Principal : AWS Bedrock, configuré pour l'exécution explicite en région (pas de point de terminaison global), parce que le partenaire est standardisé sur AWS et la règle de résidence gouverne. Vérifiez que l'exigence de conformité spécifique (BAA HIPAA ou souveraineté des données) est satisfaite par la configuration Bedrock en usage. Secondaire : API directe pour les tâches back-end non réglementées où les nouvelles fonctionnalités importent et aucune règle de résidence ne s'applique. Étape de configuration : Définissez le paramètre de région explicitement dans le client Bedrock, ne vous fiez pas à la résolution de point de terminaison par défaut.

Décision 6 · Document de résultat : Nommez la métrique commerciale avant et après et le contrôle auditable qui rend le document utilisable pour le cas d'expansion du CFO. (Applique le modèle de documentation de résultat client. )

Révéler la réponse du modèle Métrique avant : Temps moyen de la dictée infirmière à la note clinique complète et autorisée par le clinicien (ligne de base mesurée avant le déploiement). Métrique après : Même métrique après le déploiement, en utilisant la même définition de mesure. Contrôle auditable : Le journal d'autorisation du clinicien, chaque note a un enregistrement d'autorisation horodaté liant le clinicien, la note et l'interaction, rendant la comparaison avant et après auditable plutôt qu'affirmée.

Décision 7 · Transition de phase : Nommez l'artefact qui porte la transition de phase suivante pour ce résumé et jugez si cette porte est satisfaite. (Applique le portage de phase du cycle de vie. )

Révéler la réponse du modèle Artefact de porte : Le document de résultat avec métrique avant et après, contrôle auditable et propriétaire de la mesure nommés, cela porte la transition de la phase de déploiement actuelle à la décision d'expansion que le CFO est invité à prendre. Jugement : La porte n'est pas encore satisfaite à la semaine quatre, la métrique avant existe à partir de la ligne de base, mais la métrique après nécessite suffisamment de temps d'exécution post-déploiement pour mesurer. Le document de résultat ne peut pas être complété jusqu'à ce que suffisamment de données se soient accumulées. L'action correcte : nommez le propriétaire de la mesure, confirmez que le contrôle enregistre, et programmez la fin du document de résultat à un jalon défini après le lancement.

Marquer toutes les décisions comme complètes

Écran 18 : Glossaire

Enveloppe · Référence 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.

Registre de contrôleTableau porté en avant du travail de déploiement réglementé qui mappe chaque obligation réglementaire à un contrôle technique, un propriétaire responsable et un artefact de preuve qu'un examinateur peut inspecter. En documentation, il devient l'enregistrement vivant qui gouverne la vie de production du déploiement. Journal de décision (avec justification)Enregistrement de chaque choix architectural qui capture non seulement la décision mais aussi les alternatives rejetées et le compromis que chacune a résolu, afin qu'un successeur n'inverse pas un choix porteur de charge pour une mauvaise raison compréhensible. Cycle de vie du déploiementLes phases qu'un déploiement traverse : découverte → conception → transmission → surveillance → itération. La découverte et la présentation des compromis font le travail de découverte et de conception, la boucle de rétroaction est surveillance et itération, la documentation est transmission, et la sélection du point d'entrée avec le document de résultat ferme la boucle. Identifier la phase à laquelle une décision appartient est ce qui vous permet de juger quand une phase est prête à passer à la suivante. DécouvertteÉlicitation structurée, pas une conversation : un filtre à trois étapes d'écoute, traduction et écriture qui transforme l'objectif commercial d'une partie prenante en exigences, hypothèses et contraintes contre lesquelles la conception peut être construite et mesurée. Complétude de la documentationLe test de savoir si un Architecte compétent qui n'était pas dans la salle peut apporter une modification sûre après avoir lu le document. Elle nécessite la décision, les alternatives rejetées, le compromis que chacune a résolu, le propriétaire et l'artefact de preuve, et les hypothèses étiquetées comme des hypothèses. Carte de responsabilité du point d'entréeEnregistrement documenté de quel point d'entrée Claude (API directe, Claude Code, Bedrock, Vertex, Microsoft Foundry) possède quelle tâche et pourquoi, écrit avant que l'intégration ne commence. Il prévient l'échec multi-plateforme courant d'un point d'entrée choisi pour une tâche prenant tranquillement une autre parce que l'acheminement n'a jamais été documenté. Artefact de preuvePreuve concrète qu'un contrôle fonctionne, un accord signé, un écran de configuration, un enregistrement d'autorisation ou une requête de journal retournée. Un contrôle affirmé dans un document de conception sans artefact est une affirmation, pas une preuve. Boucle de rétroactionLa couche de décision qui se situe au-dessus de la pile d'observabilité et répond à Signaux → Triage → Décider → Agir → Examiner, mappant chaque signal à un déclencheur, un propriétaire et une action. La surveillance collecte les signaux ; la boucle de rétroaction décide lesquels changent le comportement et de qui. Tableau de gouvernanceLe tableau de pré-lancement qui mappe chaque signal de production à son déclencheur d'examen, l'action de l'Architecte et tout point de contrôle réglementé programmé. C'est le mécanisme qui transforme la politique en une routine d'exploitation et doit exister avant le lancement. Portée conjointe Séance de travail avec l'équipe Applied AI d'Anthropic pour affiner les choix et résoudre les questions spécialisées. Vous arrivez avec une vue documentée des exigences et contraintes, un modèle proposé ou un ensemble candidat avec compromis nommés, et une courte liste de questions ouvertes que seule l'équipe Applied AI peut répondre. Placement des limitesDecider à l'avance laquelle une ou deux limitations une démonstration nommera, et les encadrer comme des limites de portée intentionnelles. Dans les paramètres réglementés, une limite clairement délimitée en amont signale la rigueur, tandis qu'une limitation découverte ou déviée érode la confiance. Document de résultatL'artefact qui rend la valeur d'un déploiement lisible pour un sponsor qui n'était pas sur la construction. Six champs : le cas d'usage avec limite de portée, la métrique avant, la métrique après, le contrôle auditable, le propriétaire de la mesure et le potentiel de réutilisation. Le résultat commercial avant et après et les notes de réutilisation sont ce qui le rend réutilisable en tant qu'IP plutôt qu'un enregistrement technique. Exigence par rapport à hypothèseUne exigence trace jusqu'à quelque chose que la partie prenante a réellement dit ; une hypothèse est quelque chose que la conception tient pour acquis qui n'a jamais été énoncé. Une hypothèse non sourcée est la plus dangereuse, parce que personne ne se souvient de l'avoir décidée. Coût d'inversionCe qu'il coûte d'annuler une décision après que le système a été construit autour de lui, le troisième élément d'une présentation de compromis. C'est l'élément que la plupart des présentations omettent et celui qui change le plus souvent la réunion, transformant « quelle est la meilleure réponse technique ? » en « quel est le meilleur choix commercial ? » Démonstration spécifique au scénarioUne démonstration construite contre le flux de travail propre de l'acheteur, les formes de données et les contraintes, elle répond à « qu'est-ce que cela fait avec mon problème ? » plutôt que la démonstration de capacités « qu'est-ce que ce système peut faire ? » Seule la démonstration spécifique au scénario crée la confiance plutôt que le simple intérêt. SLA (Accord de niveau de service)Un engagement qui nomme ce qui est mesuré, ce qui compte comme une violation et ce qui se passe quand une violation se produit. Les seuils tracent jusqu'à une source tangible, l'attente d'expérience utilisateur, la criticité commerciale du déploiement ou les critères d'acceptation d'évaluation, plutôt qu'une cible arbitraire. Encadrement des compromissPrésenter une décision architecturale en termes qu'une partie prenante peut actionner : ce que le choix gagne, ce qu'il abandonne, et ce qu'une inversion coûte une fois que le système est construit autour de lui (plus, dans les paramètres réglementés, ce qu'il fait à la posture de conformité). L'objectif est de rendre une décision éclairée possible, pas de livrer un verdict. Traduction (découverte)Le mouvement de découverte central : convertir une préférence de partie prenante (« transparent », « rapide », « simple ») en une contrainte testable et délimitée en demandant ce qui briserait l'expérience, ce que l'utilisateur ne doit jamais remarquer, et ce qui doit rester vrai quand quelque chose se passe mal. Tableau de traductionLa sortie de la découverte : une ligne par élément capturant la déclaration de la partie prenante telle que dite, la contrainte impliquée, la décision architecturale requise et toute hypothèse documentée jusqu'à ce qu'elle soit confirmée. Une ligne par élément garde le raisonnement intact au fur et à mesure que le travail passe de la découverte à la conception.

Écran 19 : Récapitulatif : cinq choses qui tiennent partout ici

Module · Récapitulatif · 3 min Récapitulatif : cinq choses qui tiennent partout ici

Points clés à retenir

01

Découverte structurée Menez la découverte comme un processus à quatre catégories, traduisez chaque préférence en une contrainte, et écrivez chaque élément comme une ligne d'exigence avec son hypothèse étiquetée, afin que la conception trace jusqu'au cas commercial.

02

Communication des compromis et GTM Présentez chaque compromis en trois éléments y compris le coût d'inversion. Piste partenaire[Pertinent pour la piste partenaire, non testé par l'examen Architecte] Concevez la démonstration contre le scénario réel de l'acheteur avec les limitations identifiées en premier, et entrez dans la portée conjointe avec les exigences, les modèles candidats et les questions ouvertes en main.

03

Boucles de rétroaction et gestion des SLA Construisez la couche de décision qui mappe les signaux aux actions de déclenchement aux propriétaires, définissez les seuils d'SLA à partir de leurs vraies sources, et câblez les points de contrôle réglementés pour s'exécuter selon un calendrier.

04

Documentation pour la transmission et l'audit Écrivez la décision, les alternatives rejetées et le compromis que chacune a résolu pendant que vous tenez toujours le raisonnement, et portez le registre de contrôle en avant comme preuve qu'un examinateur acceptera.

05

Sélection du point d'entrée et résultats Choisissez la route sur la latence, la conformité et le coût avec une carte de responsabilité du point d'entrée pour les conceptions multi-points d'entrée, et capturez la métrique avant, le contrôle auditable et la note de réutilisation afin que le document de résultat justifie l'expansion.

Le module suivant couvre l'habilitation des équipes et la productivité opérationnelle : configurer les outils Claude pour une équipe, construire des flux de travail de développeur qui gardent le travail assisté par l'IA digne de confiance, et soutenir la santé opérationnelle d'un déploiement en direct. Vous pouvez maintenant prendre un déploiement de la première phrase d'une partie prenante à un document de résultat qui survit à l'engagement. Le module suivant couvre ce qui se passe après que vous transmettiez ce déploiement à l'équipe qui le gère.

Sources

Building with the Claude API (Skilljar) : cycle de vie des demandes sans état, invites système, évaluations et évaluateurs, utilisation d'outils, RAG, mise en cache des prompts, exécution de code. Claude 101 (Skilljar) : capacités générales de Claude et cadrage d'utilisation quotidienne. (Claude 101 ne porte pas l'enseignement de la famille de modèles ou de la fenêtre de contexte selon le catalogue en direct ; ces concepts tracent à la documentation de la plateforme ; vérifiez la gamme de modèles actuelle au moment de la publication. ) Capacités et limitations de l'IA (Skilljar) : la lentille de décision à quatre propriétés portée en avant des modules antérieurs. platform. claude. com/docs : noms de modèles, capacités de plateforme, disponibilité des routes, configuration de résidence. Re-vérifiez au moment de la construction. Documentation du programme partenaire anthropic. com : définitions des étapes GTM partenaire, protocoles de contribution d'IP. Documentation de l'équipe Applied AI d'Anthropic : structure d'engagement de portée conjointe et entrées de préparation.

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

Module terminé · Architecte · 2 min Félicitations ! Vous avez complété ce module avec succès. Le module 4 couvre la communication avec les parties prenantes, la gouvernance du cycle de vie et les décisions de mise sur le marché qui transforment un déploiement d'IA fonctionnant en un actif commercial défendable et évolutif. Le déploiement n'est aussi durable que la documentation, la gouvernance et la preuve de résultat qui l'entourent.

0 de 0 points de contrôle réussis

M1

Plateforme Claude et conception de solutions Sélection de modèles, architecture d'invite, conception d'outils et compromis au niveau de la plateforme.

M2

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

M3

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

M4

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

Vous êtes ici

M5

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

Suivant