Habilitation d'équipe et productivité opérationnelle — Claude Certified Architect Professional Prep Course

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

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

Les quatre premiers modules vous ont transformé en Architect capable de mener un déploiement de la première phrase d'un stakeholder à travers la conception, l'intégration, la gouvernance et la transmission. Ce module concerne l'équipe autour de ce déploiement : rendre les gens productifs avec Claude et les maintenir productifs une fois que le système est en direct.

À la fin de ce module, vous serez capable de : 1 Configurer les outils Claude et les environnements pour une équipe, y compris la configuration partagée, le modèle de déploiement, la stratégie de distribution des compétences et les contrôles de dépenses qui appartiennent à la configuration d'équipe. 2 Améliorer les flux de travail des développeurs avec les outils d'IA et définir la discipline d'examen qui maintient le travail généré par l'IA fiable avant qu'il ne soit mis en production. 3 Soutenir le débogage et la résolution des problèmes opérationnels en connectant les symptômes aux causes architecturales et en guidant l'équipe vers l'autosuffisance. Ce module concerne l'habilitation

Chaque module précédent vous a enseigné comment construire et configurer Claude. Celui-ci suppose que le système est construit et pose la question : comment une équipe l'adopte-t-elle bien, et comment reste-t-il sain sans vous impliquer dans chaque problème ? La configuration d'équipe aide l'équipe à obtenir l'environnement, les actifs réutilisables et la posture de dépenses correcte avant que quiconque ne se connecte. Les flux de travail des développeurs élèvent la barre sur la façon dont l'équipe travaille au quotidien sans abaisser la barre sur la qualité, et le support opérationnel est ce que vous faites quand l'équipe rencontre quelque chose d'inattendu dans le système.

Ces sujets se construisent les uns sur les autres. Les compétences que vous distribuez dans la configuration sont les mêmes actifs sur lesquels s'appuie un flux de travail de développeur ; la discipline d'examen que vous établissez pour ces flux de travail est ce qu'un problème opérationnel teste sous pression. Les trois se déroulent dans l'ordre : configurer l'environnement, élever le flux de travail quotidien et maintenir le système sain.

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

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

Screen 2: Configuration des outils Claude et des environnements pour les équipes

Configuration d'équipe Configuration des outils Claude et des environnements pour les équipes Vous pouvez configurer Claude pour vous-même en quelques minutes ; cependant, le configurer pour une équipe est différent. Lors de la configuration pour une équipe, il y a des valeurs par défaut partagées pour que tout le monde commence à partir de la même base, des actifs réutilisables qui peuvent être mis à jour et révoqués de manière centralisée, et des dépenses qui restent limitées à mesure que l'utilisation s'étend sur des dizaines de personnes. Cet écran couvre les quatre décisions de configuration d'équipe qu'un Architect possède : environnement, déploiement, distribution des compétences et dépenses, et l'échec qui se produit si l'une de ces étapes est ignorée.

Déployer l'environnement comme une configuration partagée Un environnement d'équipe est une configuration partagée : une base de référence à partir de laquelle chaque développeur commence plutôt qu'un ensemble de configurations personnelles. Pour Claude Code, cela signifie que l'équipe s'accorde sur une base de référence au niveau du projet : un CLAUDE. md partagé, un ensemble convenu d'outils et de serveurs MCP, et une posture de permissions, pour que les gens commencent au même endroit plutôt que de découvrir des paramètres ad hoc et de s'éloigner. Cette base de référence est quelque chose que vous pouvez examiner, versionner et améliorer une fois pour tout le monde.

Déployer par le biais de champions, puis par lots L'adoption en équipe réussit rarement comme un simple basculement all-hands. Le modèle qui fonctionne le mieux consiste à identifier un champion par département ou équipe qui reçoit d'abord l'accès, prouve le flux de travail en pratique, puis amorce l'adoption lot par lot. Le champion absorbe les premiers frottements, construit les exemples locaux et devient la première ligne de support pour que l'Architect ne soit pas la seule personne qui peut répondre aux questions de l'équipe.

Exemple travaillé Une organisation d'ingénierie de 200 personnes souhaite Claude Code dans quatre départements. Au lieu d'activer les quatre à la fois, l'Architect active un champion dans chaque département, lui donne deux semaines pour convertir un flux de travail réel (par exemple, une assistance d'examen de code, une étape de génération de tests), et chaque champion exécute une session de 45 minutes pour son premier lot qui comprend cinq de ses pairs. Au moment du déploiement large, chaque département a un exemple fonctionnant, un expert local et un CLAUDE. md partagé que le champion a déjà ajusté. Le même déploiement tenté comme un simple email de masse aurait produit un pic de prompts confus de première utilisation et peut-être même un retrait silencieux aux anciennes habitudes.

Distribution des compétences : la version à l'échelle de l'équipe de la réutilisation Nous avons appris que les packages de compétences sont des procédures répétables qui apparaissent comme des unités versionnées et réutilisables. À l'échelle de l'équipe, la question architecturale est : comment devriez-vous distribuer une compétence à toute votre équipe ? Considérez comment vous pourriez la créer, la versionner et la publier pour que l'équipe puisse y accéder, comment l'octroi et la révocation d'accès pourraient fonctionner, et comment vous pourriez la restaurer si une compétence se comporte mal. Il y a quatre façons principales de distribuer les compétences d'équipe, et le mécanisme que vous choisissez tient compte de ce qu'est l'outil, qui l'utilise et qui a accès pour le gouverner. Il y a quatre façons de déployer une compétence à une équipe, et elles diffèrent par qui peut y accéder et le contrôle que vous conservez. Une compétence fournie par le propriétaire, téléchargée sous Paramètres de l'organisation > Compétences, devient disponible pour tous les membres de l'organisation à la fois. C'est le chemin le plus simple quand une capacité devrait vraiment atteindre tous les membres. Quand une compétence devrait atteindre seulement des membres sélectionnés, vous regroupez une ou plusieurs compétences dans un plugin et assignez ce plugin à un groupe. Seuls les membres du groupe peuvent accéder à ces compétences. Les plugins sont aussi où vit la distribution gouvernée : installer des préférences telles que requis, installé par défaut, disponible ou non disponible, ciblage de groupe et mises à jour contrôlées en version à partir d'un référentiel connecté. Le troisième mécanisme est les compétences de projet Claude Code : des artefacts du système de fichiers qui vivent dans le référentiel du projet (. claude/skills/), pour qu'ils se versionnent avec le référentiel lui-même et soient limités aux projets qui les portent. Le quatrième est les compétences API, appelées par programmation par les propres produits du partenaire. La configuration centralisée de Claude Code est un canal entièrement séparé : les paramètres gérés par le serveur sont livrés depuis les serveurs d'Anthropic quand les utilisateurs s'authentifient et s'actualisent sur un cycle d'interrogation horaire - un mécanisme de paramètres, pas un chemin de distribution de compétences.

Mécanismes de distribution des compétences Mécanisme de distributionMeilleur quandGouvernance et restauration

Compétence fournie par l'organisation (Paramètres de l'organisation › Compétences)Une capacité devrait atteindre tous les membres de l'organisation. Disponibilité gérée par le propriétaire et suppression dans toute l'organisation ; les utilisateurs peuvent désactiver les compétences individuelles mais ne peuvent pas les supprimer. Pas de pinning de version ou de restauration native ; les mises à jour nécessitent un re-téléchargement manuel. Plugin assigné à un groupe / organisationUne procédure ou un ensemble d'outils devrait atteindre des équipes spécifiques, ou qui a besoin d'un déploiement gouverné. Ciblage de groupe, préférences d'installation contrôlant si un plugin est requis, installé par défaut ou disponible pour les utilisateurs (étiquettes exactes selon l'interface utilisateur d'administration actuelle, article de support 13837433), et mises à jour contrôlées en version à partir d'un référentiel connecté. Option de gouvernance la plus forte pour la distribution limitée au groupe. Ce n'est pas le seul mécanisme avec un chemin vers une version antérieure : les compétences API supportent le pinning de version explicite, et les compétences de projet Claude Code se restaurent avec le référentiel qui les porte. Compétence de projet Claude CodeUn outil ou une convention qu'une équipe partage sur tous ses propres projets. Un artefact du système de fichiers dans le référentiel du projet (. claude/skills/), se versionnant avec le référentiel et limité aux projets qui le portent. Compétence API (conteneur Messages API)Une capacité appelée par programmation par les propres produits du partenaire. Gouvernée dans le système appelant ; supporte le pinning de version explicite ; la réutilisation est machine-à-machine plutôt que face à l'utilisateur.

Empaqueter un flux de travail d'équipe comme une compétence distribuable est comment une bonne pratique locale devient une norme d'équipe. La procédure se déplace comme un artefact gouverné unique au lieu de comme du savoir-faire non documenté, et les mises à jour se propagent par le versioning plutôt que par la ré-explication.

Définir la posture de dépenses avant la première facture La configuration d'équipe inclut également les garde-fous de coûts. Les administrateurs devraient les définir intentionnellement plutôt que d'hériter des valeurs par défaut : les valeurs par défaut du modèle (quel modèle une session commence), les listes blanches et restrictions de modèles (quels modèles l'équipe peut basculer), les conseils d'effort (à quel point le modèle travaille dur sur une tâche), et les dépenses, taux et plafonds par utilisateur qui maintiennent la consommation dans les limites. Le Module 2 a montré que laisser le choix du modèle non géré peut tranquillement acheminer le travail vers un niveau plus capable et plus cher que la tâche ne l'exige. À l'échelle de l'équipe, ce choix se multiplie sur chaque membre et chaque demande.

Attention à La compétence qui a été expédiée sans moyen de revenir. Une équipe de plateforme a empaqueté sa procédure de notes de version comme une compétence, l'a regroupée dans un plugin et l'a assignée à son groupe de quarante ingénieurs. Une semaine plus tard, une modification bien intentionnée a changé l'invite et la compétence a commencé à produire des notes dans le mauvais format dans toutes les équipes qui l'utilisaient. Les compétences ont été poussées comme un lot plat sans les mises à jour contrôlées en version et la restauration qu'un plugin fournit, donc la correction a nécessité une ré-édition manuelle tandis que la mauvaise sortie continuait à être expédiée. La compétence était une bonne idée distribuée sans la gouvernance qu'elle exigeait. Un actif partagé sans version et sans moyen de revenir est un passif à partir du moment où plus d'une personne en dépend. Quand un actif partagé a besoin de versioning, de ciblage de groupe ou de restauration, distribuez-le à l'intérieur d'un plugin géré par l'organisation et identifiez un propriétaire.

Coût · Complexité · Risque

Coût La mise en place d'un environnement d'équipe coûte du temps de configuration : configuration partagée, un plan de déploiement et empaquetage des compétences à l'avance, mais c'est bien moins cher que de réconcilier plus tard quarante configurations qui se sont éloignées. Complexité La partie difficile est la gouvernance de la distribution : qui peut atteindre, mettre à jour et révoquer chaque actif partagé. Décidez-le sur une base par actif. Risque Le plus grand mode d'échec est un actif partagé (par exemple, une compétence, une configuration) sans versioning ou restauration, donc un mauvais changement se propage à toute l'équipe avant que quiconque puisse l'arrêter.

Screen 3: Point de contrôle : concevoir la stratégie de distribution d'équipe

Configuration d'équipe · Point de contrôle Point de contrôle : concevoir la stratégie de distribution d'équipe

Essayez maintenant. Pour chaque scénario ci-dessous, choisissez comment l'équipe devrait recevoir l'actif réutilisable et identifiez le facteur qui rend ce mécanisme le bon. Un mécanisme correct associé à la mauvaise raison ne passe pas.

A Une procédure d'examen de conformité que chaque département doit exécuter de manière identique, qui doit être mise à jour de manière centralisée et restaurable.

Sélectionner le mécanisme... Compétence fournie par l'organisation (Paramètres de l'organisation › Compétences) Compétence de projet Claude Code Plugin distribué à l'échelle de l'organisation (ou à tous les groupes pertinents) Compétence API (conteneur Messages API)

B Une capacité qui devrait vraiment être disponible pour chaque membre, sans besoin de versioning ou de restauration.

Sélectionner le mécanisme... Compétence API (conteneur Messages API) Compétence fournie par l'organisation (Paramètres de l'organisation › Compétences) Plugin distribué à l'échelle de l'organisation Compétence de projet Claude Code

C Une convention de codage et un ensemble d'outils que l'équipe d'ingénierie devrait partager sur chaque projet.

Sélectionner le mécanisme... Compétence de projet Claude Code Compétence API (conteneur Messages API) Compétence fournie par l'organisation Plugin distribué au groupe d'ingénierie

D Une capacité réutilisable que plusieurs des propres produits du partenaire doivent appeler par programmation.

Sélectionner le mécanisme... Plugin distribué à l'échelle de l'organisation Compétence de projet Claude Code Compétence API (conteneur Messages API) Compétence fournie par l'organisation

Vérifier les sélections Ignorer pour l'instant

Screen 4: Amélioration des flux de travail des développeurs avec les outils d'IA

Flux de travail des développeurs Amélioration des flux de travail des développeurs avec les outils d'IA Une équipe peut avoir Claude configuré parfaitement et en tirer peu. La différence est leur flux de travail : comment l'assistance IA est tissée dans la façon dont les développeurs travaillent, et la discipline qui maintient sa sortie fiable. Cet écran concerne l'élévation de la barre du flux de travail sans abaisser la barre de qualité, et l'échec qui se produit quand la deuxième moitié est ignorée.

Intégrer l'assistance dans le flux de travail qui existe déjà L'assistance IA paie quand elle vit à l'intérieur du flux de travail existant : l'éditeur, le processus d'examen et la boucle de test, plutôt que dans une fenêtre de chat séparée que le développeur visite occasionnellement. Le travail de l'Architect est de trouver où l'assistance IA a l'opportunité de supprimer les vrais frottements et d'améliorer le processus global. Claude devrait être intégré dans le flux de travail actuel de l'équipe. L'intégration est aussi comment les connaissances et les façons de travailler d'une équipe sont codifiées. Les conventions, les normes d'examen et les procédures répétées qui vivent habituellement dans la tête des gens deviennent des compétences et une configuration de projet que Claude applique de manière cohérente, pour que la bonne pratique voyage avec les outils plutôt que de dépendre de qui se trouve dans la pièce.

Où Claude aide à chaque étape du flux de travail, et la discipline d'examen qu'il a toujours besoin Étape du flux de travailOù Claude peut aiderDiscipline d'examen qu'il a toujours besoin

Écrire du codeBrouillon de code passe-partout, tests et implémentations de première passe à partir d'une spécification claire. Examen de la correction et de la sécurité ; l'auteur doit comprendre ce qui a été généré. Examiner du codeRésumé d'une diff, signalisation des problèmes probables, explication du code non familier. Jugement humain sur l'appel ; les drapeaux IA sont une entrée, pas un verdict. DéboguageProposition d'hypothèses à partir d'un symptôme et d'une trace. Vérifier l'hypothèse par rapport aux preuves avant d'agir en fonction de celle-ci.

Deux modes d'échec apparaissent encore et encore

1Adoption inégale : Cela se produit quand quelques développeurs utilisent les outils d'IA intensément et le reste les touche à peine, donc l'équipe ne réalise jamais le vrai gain de l'outil et la pratique ne se standardise jamais. Le déploiement champion-et-lot du sujet précédent est un excellent moyen d'éviter cela : il propage l'utilisation délibérément au lieu de la laisser à tous les premiers utilisateurs. 2Stagnation au chat basique : L'équipe utilise Claude comme une boîte de questions-réponses et n'avance jamais vers les flux de travail de plus grande valeur tels que l'utilisation d'outils, l'assistance consciente du référentiel, les compétences empaquetées parce que personne ne les a activées au-delà de la première étape. Fournir à une équipe l'accès n'est pas l'adoption ; vous devez configurer pour une véritable habilitation dans les flux de travail actuels.

Diligence : la discipline qui maintient le travail généré par l'IA fiable La diligence est l'une des quatre compétences de fluidité IA. Anthropic la définit comme prendre la responsabilité de ce que nous faisons avec l'IA et comment nous le faisons. La diligence de déploiement spécifiquement signifie prendre la responsabilité de vérifier et de cautionner les résultats que nous utilisons ou partageons. Appliquée aux flux de travail des développeurs, cette responsabilité se manifeste comme une habitude concrète : tenir le code généré par l'IA aux mêmes normes que tout autre code, ce qui signifie correction, sécurité et maintenabilité, et surveiller l'échec subtil où les ingénieurs acceptent une sortie qu'ils ne comprennent plus complètement parce qu'elle semble juste et passe une vérification. Le livrable concret que la diligence produit est une liste de vérification de vérification : l'ensemble explicite des vérifications qu'une sortie générée par l'IA doit passer avant d'atteindre la production. Cette liste de vérification de vérification est quelque chose qu'une équipe produit en interne en fonction de ses besoins spécifiques. La liste de contrôle devrait inclure des questions qui abordent les quatre dimensions de la vérification : correction, sécurité, maintenabilité et compréhension humaine. Partout où une vérification peut être automatisée, elle devrait l'être. Une suite de tests de régression et un ensemble d'évals transforment la vérification de la correction et du comportement du jugement d'un examinateur en une porte qui s'exécute sur chaque changement. La liste de contrôle définit ce qui doit être vrai. Les évals et les tests sont comment une équipe le prouve de manière répétée plutôt que de le re-dériver à la main à chaque fois. Une équipe avec cette liste de contrôle a transformé une bonne intention en une porte répétable ; une équipe sans elle fait confiance à la sortie IA par défaut et espère que l'examinateur attrape ce qui compte.

Attention à La fusion que personne ne pouvait expliquer. Une équipe a adopté le codage assisté par l'IA et a expédié notablement plus rapidement. Trois semaines plus tard, un changement généré a passé l'examen du code et les tests et est allé en production, où il a fui des données par une entrée qu'il n'a jamais validée. Dans l'examen post-incident, l'auteur ne pouvait pas expliquer pourquoi le code gérait cette entrée de la façon dont il le faisait ; cela semblait plausible, les tests étaient verts et personne n'a posé la question que la liste de contrôle aurait forcée : la personne qui fusionne cela peut-elle expliquer ce qu'elle fait et pourquoi ? La vitesse avait tranquillement remplacé la compréhension, ce qui est exactement l'érosion du jugement que la diligence existe pour attraper.

Coût · Complexité · Risque

Coût L'assistance IA abaisse le coût de production de code, ce qui élève le volume qui atteint l'examen ; la liste de vérification de vérification est ce qui maintient ce volume de ne pas submerger la barre de qualité. Complexité La partie difficile est culturelle, pas technique : tenir le code généré par l'IA à la même norme d'examen que le code écrit à la main, surtout quand il s'expédie plus rapidement et semble juste. Risque Le plus grand mode d'échec est l'érosion du jugement : une équipe qui expédie une sortie qu'elle ne comprend plus parce qu'elle a passé des vérifications superficielles, jusqu'à ce qu'une entrée que personne n'a raisonnée atteigne la production.

Screen 5: Exercice : définir la liste de vérification de vérification

Flux de travail des développeurs · Exercice Exercice : définir la liste de vérification de vérification

Essayez maintenant. Écrivez la liste de vérification de vérification que le code généré par l'IA doit passer avant la production. Pour chacune des quatre dimensions ci-dessous, écrivez une vérification concrète avec vos propres mots. Écrivez votre liste de contrôle, puis révélez la réponse modèle ci-dessous.

Correction

Sécurité

Maintenabilité

Compréhension humaine

Révéler la réponse modèle

Correction : Les tests existent et passent, et le comportement correspond à l'exigence énoncée, y compris les cas limites. Sécurité : Pas de secrets dans le code ; les entrées sont validées ; tous les outils ou appels externes utilisent l'accès du moindre privilège. Maintenabilité : Le code se lit clairement, suit les conventions de l'équipe et ne contient pas de complexité inexpliquée. Compréhension humaine : Le développeur soumettant le changement peut expliquer ce que le code fait et pourquoi, y compris comment il gère les entrées contre lesquelles il n'a pas été explicitement testé.

Marquer la liste de contrôle comme complète Ignorer pour l'instant

Screen 6: Soutien au débogage et à la résolution des problèmes opérationnels

Support opérationnel Soutien au débogage et à la résolution des problèmes opérationnels Il y a toujours un moment où un déploiement en direct surprend son équipe. Quand c'est le cas, l'Architect est la personne qui connecte ce que l'équipe voit à la raison pour laquelle c'est arrivé. L'Architect est aussi responsable de l'amélioration des compétences de l'équipe, pour que la prochaine fois, ils se sentent habilités à résoudre le problème eux-mêmes. Cet écran concerne le rôle de support, le raisonnement symptôme-à-cause qui le définit, et la construction de l'équipe vers l'autosuffisance.

Le rôle de support est la traduction, pas l'extinction d'incendie Quand un problème opérationnel arrive, l'équipe identifie généralement un symptôme, pas une cause. Par exemple, ils noteront que la latence a augmenté, la qualité des résultats s'est dégradée ou un outil a commencé à échouer. L'équipe tire alors l'Architect, dont la valeur est de connecter le symptôme opérationnel à sa cause architecturale : la même discipline de diagnostic que le Module 2 a construite pour les systèmes de production, maintenant appliquée au soutien d'une équipe qui possède le déploiement. Résoudre un incident vous-même est l'extinction d'incendie ; enseigner à l'équipe le chemin symptôme-à-cause qu'ils peuvent suivre à nouveau à l'avenir est un support qui dure.

Connecter les symptômes aux causes architecturales De nombreux symptômes opérationnels remontent à un petit ensemble de causes architecturales. Les identifier permet à l'équipe de raisonner clairement à partir de ce qu'elle voit vers où regarder. Symptôme → cause architecturale probable → première action SymptômeProblable cause architecturalePremiére action

La qualité des résultats s'est dégradée graduellement, mais il n'y a eu aucun changement de codeUn changement de modèle ou d'invite, ou une dérive de récupération à mesure que le corpus a grandi. Comparer par rapport à un ensemble d'évals ; vérifier ce qui a changé dans le modèle, l'invite ou le corpus. La latence a augmentéLa taille du contexte a grandi, un outil est devenu lent ou un cache a arrêté de frapper. Utiliser la télémétrie et les traces de demande pour trouver l'intervalle le plus lent : vérifier les nombres de tokens par demande et l'appel d'outil le plus lent, et confirmer le comportement du cache. Défaillances intermittentes d'outilsAutorisation, limites de taux ou un chemin d'erreur non géré. Inspecter l'autorisation et les limites de l'outil défaillant ; tracer un appel échoué de bout en bout. Le coût a augmenté sans changement d'utilisationLe niveau du modèle a augmenté, ou la mise en cache a régressé. Vérifier le niveau du modèle par demande et le taux de succès du cache par rapport au modèle budgétaire.

Construire l'autosuffisance : runbooks et chemins d'escalade L'autosuffisance est intégrée dans les équipes fonctionnelles. Un runbook capture les chemins symptôme-à-cause-à-action connus pour que l'équipe puisse résoudre les problèmes récurrents sans l'Architect. Le tableau ci-dessus est la fondation d'un bon runbook. Un chemin d'escalade identifie qui gère quoi et quand un problème quitte l'équipe, pour que les gens connaissent la limite de ce qu'ils peuvent résoudre et ce qui doit être escaladé. Encouragez toujours une équipe à maintenir un runbook pour son déploiement et à définir un chemin d'escalade clair. L'objectif est une équipe qui vous a besoin seulement quand de nouveaux problèmes surgissent, pas pour ceux que vous leur avez déjà appris à affronter.

Attention à La dérive qui attendait un examen trimestriel. Une équipe de support a regardé les tableaux de bord d'un déploiement rester verts pendant un trimestre entier tandis que la qualité des réponses glissait tranquillement. Personne n'a connecté le déclin lent à sa cause : un corpus de récupération croissant que l'index n'avait pas suivi. Les symptômes étaient visibles tout le temps, mais l'entrée du runbook qui dit le déclin graduel de la qualité sans changement de code pointe vers le modèle, l'invite ou la dérive de récupération était manquante. Avec ce chemin écrit, un ingénieur de première ligne aurait pu résoudre le problème en un après-midi ; mais sans lui, il attend un examen.

Coût · Complexité · Risque

Coût Enseigner le chemin symptôme-à-cause coûte plus de temps de l'Architect à l'avance que de résoudre l'incident directement, mais c'est la seule version du support qui réduit la charge future au lieu de la répéter. Complexité La partie difficile est de résister à l'envie d'éteindre les incendies : le correctif rapide est de le résoudre vous-même, mais le correctif durable est d'aider l'équipe à créer une entrée de runbook et à identifier le chemin d'escalade qui permet à l'équipe de résoudre le prochain problème sans votre aide. Risque Le plus grand mode d'échec est une dégradation lente que personne ne connecte à une cause, donc elle s'exécute jusqu'à ce qu'un examen programmé la détecte plutôt que l'équipe la détecte le jour où elle commence.

Screen 7: Quiz du module

Module · Quiz Quiz du module

Cinq questions de scénario sur les trois sujets. Choisissez la meilleure réponse ; les commentaires nomment le principe.

Question 1 · Configuration d'équipe Une équipe déploie Claude à quatre départements à la fois et l'adoption est inégale. Quel est le meilleur prochain pas ?

AMandat des objectifs d'utilisation quotidienne pour tout le monde. BActiver un champion dans chaque département d'abord, prouver le flux de travail, puis amorcer l'adoption par lots. CAttendre que chaque département demande de l'aide. DFournir le modèle le plus fort à tout le monde pour encourager l'utilisation.

Question 2 · Distribution des compétences Une procédure doit être exécutée de manière identique par chaque département et être révocable d'un seul endroit. Comment devrait-elle être distribuée ?

ACollée dans le chat de chaque équipe comme une invite. BRegroupée dans un plugin géré par l'organisation distribué à tous les départements, avec ciblage de groupe/organisation, mises à jour contrôlées en version et restauration. CUne configuration de projet Claude Code dans le référentiel d'une équipe. DEnvoyée par email comme un document pour que les gens suivent.

Question 3 · Flux de travail des développeurs Une équipe expédie du code généré par l'IA plus rapidement mais un problème de sécurité s'échappe. Qu'est-ce qui manquait très probablement ?

AUn SLA d'examen du code qui exemptait les petits changements générés par l'IA de l'examen de sécurité. BUn linter configuré pour signaler les modèles de vulnérabilité connus avant la fusion. CUne liste de vérification de vérification que le code généré par l'IA doit passer avant la production, y compris une dimension de sécurité. DPlus de mises à jour fréquentes du modèle pour incorporer les modèles de sécurité récents.

Question 4 · Jugement À l'examen, un développeur ne peut pas expliquer pourquoi un changement généré par l'IA gère une entrée de la façon dont il le fait, mais les tests passent. Que devrait-il se passer ?

AFusionner ; les tests sont verts. BLe maintenir jusqu'à ce que l'auteur puisse expliquer le comportement et sa justification, la vérification de la compréhension humaine. CSupprimez les tests et réécrivez à la main. DEscalader à l'Architect pour chaque fusion.

Question 5 · Support opérationnel La qualité des résultats sur un déploiement en direct s'est dégradée sur deux mois sans changements de code. Où l'Architect regarde-t-il d'abord ?

AAugmenter le niveau du modèle ; un modèle plus capable compensera les lacunes de récupération. BUn changement de modèle ou d'invite, ou une dérive de récupération à mesure que le corpus a grandi, connecter le symptôme à une cause architecturale. CDésactiver la mise en cache pour s'assurer que chaque appel tire du contenu frais. DRétrograder le dernier déploiement de code et ré-exécuter les tests d'intégration.

Soumettre le quiz Ignorer pour l'instant

Screen 8: Glossaire

Conclusion · 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.

Déploiement champion par départementUn modèle d'adoption qui active un champion par équipe d'abord pour prouver le flux de travail, puis amorce l'adoption lot par lot. Chemin d'escaladeUne définition nommée de qui gère quoi et quand un problème opérationnel quitte l'équipe. RunbookUn ensemble capturé de chemins symptôme-à-cause-à-action connus qui permet à une équipe de résoudre les problèmes opérationnels récurrents sans l'Architect. Configuration partagéeUne seule base de référence d'équipe (par exemple un CLAUDE. md de projet, des outils convenus et une posture de permissions) à partir de laquelle chaque membre commence, au lieu de configurations individuelles qui s'éloignent. Distribution des compétencesMettre une compétence devant les bonnes personnes par l'un des quatre mécanismes, chacun avec un accès, un versioning et un comportement de restauration différents : les compétences fournies par l'organisation (Paramètres de l'organisation > Compétences) pour la disponibilité à l'échelle de l'organisation ; les plugins assignés à un groupe ou une organisation pour la distribution limitée au groupe avec des préférences d'installation, des mises à jour contrôlées en version et une restauration ; les compétences de projet Claude Code versionnées avec le référentiel et limitées à une équipe ; et les compétences API appelées par programmation avec le pinning de version explicite. Posture de dépensesLes valeurs par défaut du modèle, les listes blanches et restrictions de modèles, les conseils d'effort et les dépenses, taux et plafonds par utilisateur définis dans le cadre de la configuration d'équipe maintiennent la consommation dans les limites. Liste de vérification de vérificationL'ensemble explicite des vérifications de correction, sécurité, maintenabilité et compréhension humaine que la sortie générée par l'IA doit passer avant la production.

Screen 9: Récapitulatif : quatre choses qui tiennent partout ici

Module · Récapitulatif Récapitulatif : quatre choses qui tiennent partout ici

La configuration d'équipe est une configuration partagée, une distribution et une posture de dépenses décidées à l'avance Un environnement d'équipe est une base de référence partagée plus une approche de distribution des compétences : fournie par l'organisation pour tout le monde, plugins pour le ciblage de groupe et d'organisation avec des mises à jour versionnées et une restauration, compétences de projet pour une équipe et compétences API pour la réutilisation programmatique, le tout limité par les garde-fous de modèle et de budget.

L'adoption est intégrée par le biais de champions et de lots Un champion par équipe prouve le flux de travail et amorce l'adoption ; l'accès sans habilitation stagne au chat basique, et l'adoption inégale ne standardise jamais le gain.

La diligence maintient le travail assisté par l'IA fiable Tenir le code généré par l'IA aux normes de correction, sécurité et maintenabilité, et exiger que l'auteur puisse expliquer ce qui a été expédié, capturé comme une liste de vérification de vérification qui porte avant la production.

Le support opérationnel est la traduction plus l'autosuffisance Connecter les symptômes aux causes architecturales et laisser derrière des runbooks et des chemins d'escalade pour que l'équipe vous ait besoin pour le nouveau problème, pas le problème familier.

Cela complète la piste Architect. Vous pouvez mener un déploiement de la première phrase d'un stakeholder à travers la conception, l'intégration, la gouvernance, la transmission et le livrer à l'équipe qui l'adopte et l'exécute.

Sources

Skilljar Anthropic, Building with the Claude API : utilisation d'outils, mécanique d'intégration API et concepts de compétences de base portés dans la distribution d'équipe. Documentation de configuration Claude Code (code. claude. com) : instructions CLAUDE. md par rapport aux paramètres applicables, permissions, hooks, MCP et paramètres gérés. Documentation de provisioning des compétences Claude Code et de l'organisation : structure du package de compétences, compétences de projet, distribution basée sur les plugins et disponibilité à l'échelle de l'organisation fournie par le propriétaire. Gestion des plugins de l'organisation (support. code. com) : places de marché de plugins, assignation de groupe, préférences d'installation, installation requise/par défaut, comportement de masquage/dépréciation, téléchargement manuel, synchronisation Github, mise à jour et mécanique de suppression.

Screen 10: Félicitations ! Vous avez complété ce module avec succès.

Module Complété · Architect · 2 min Félicitations ! Vous avez complété ce module avec succès. Le Module 5 couvre la configuration des outils d'équipe, la conception des flux de travail des développeurs et les pratiques de support opérationnel qui soutiennent la productivité IA une fois qu'un déploiement est en direct. Un déploiement que l'équipe ne peut pas exploiter, déboguer et améliorer ne restera pas productif ; vous avez maintenant les modèles pour le maintenir en fonctionnement.

0 de 0 points de contrôle réussis

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

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

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

Engagement des stakeholders, cycle de vie et go-to-market Communication avec les stakeholders, gestion du cycle de vie et stratégie go-to-market.

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

Vous êtes ici

Examiner le module Recommencer