Dépannage et optimisation

Écran 1 : Diagnostiquer les invites et les résultats peu performants

EnseignementDiagnostiquer la sous-performance·10 min

Quand un résultat déçoit, la plupart des gens font l'une de deux choses improductives : abandonner et conclure « Claude ne peut pas faire ça », ou s'agiter, en changeant des choses au hasard jusqu'à ce que quelque chose fonctionne. La compétence diagnostique remplace les deux par une séquence. La sous-performance a des causes racines trouvables, et l'exécution de la séquence transforme généralement une impasse en une correction de cinq minutes.

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

• 1Diagnostiquer pourquoi une invite ou un résultat est peu performant et le retracer jusqu'à sa cause racine : sous-spécification, surcharge de contexte, la mauvaise fonctionnalité ou le mauvais modèle, ou configuration obsolète.

• 2Ajuster votre approche en fonction du résultat que vous obtenez, en transformant les corrections récurrentes en corrections qui persistent au lieu de répéter le même travail manuel.

• 3Optimiser un flux de travail pour l'efficacité en promouvant le contexte partagé, le format et les étapes de vérification dans les Projects, les Skills et les instructions permanentes.

Modèles d'échec courants et leurs causes racines

Les quatre produisent des résultats similaires peu performants, alors lisez le timing des symptômes pour déterminer lequel vous êtes. Retournez chaque carte.

Sous-spécification

Sous-spécification. L'invite a omis le contexte, les contraintes ou le format. La cause la plus courante, et la moins chère à corriger : ajouter ce qui manquait.

Surcharge de contexte

Surcharge de contexte. Une longue conversation s'est rapprochée de la limite de contexte, et le contenu antérieur a été automatiquement résumé pour faire de la place ; les détails peuvent se compresser, donc les instructions précoces perdent de leur force. La correction est un redémarrage ou un résumé, pas une meilleure invite.

Mauvaise fonctionnalité ou mauvais modèle

Mauvaise fonctionnalité ou mauvais modèle. Demander un calcul en prose au lieu d'une exécution de code, ou une analyse approfondie d'un niveau de modèle choisi pour la vitesse. La correction est le bon outil, pas plus de prompting.

Configuration obsolète

Configuration obsolète. Une instruction permanente, une source de connaissances ou une Skill a dérivé et dégrade silencieusement le résultat. La correction est la maintenance, couverte dans le Module 5.

Les quatre modèles produisent des résultats similaires peu performants, donc la compétence est de lire le symptôme pour déterminer lequel vous êtes. La sous-spécification apparaît dès la première réponse : le résultat n'a jamais été correct, car l'invite n'a jamais porté ce dont elle avait besoin. La surcharge de contexte apparaît à mi-parcours d'une bonne session : elle a bien commencé et s'est dégradée à mesure que la conversation s'est allongée. Les mauvaises fonctionnalités apparaissent comme des types d'erreurs spécifiques et répétables : des nombres légèrement décalés (nécessite l'exécution de code) ou une analyse superficielle sur une tâche qui nécessite de la profondeur (mauvais niveau de modèle). La configuration obsolète apparaît comme « ça fonctionnait avant » : la même configuration qui produisait de bons résultats le mois dernier ne fonctionne plus, car quelque chose dont elle dépend a dérivé. Le timing et le modèle : première réponse-mauvaise, dégradée-au-fil-du-temps, type-d'erreur-spécifique, ou fonctionnait-avant. Chacun pointe vers une correction différente.

Isoler la cause

Avant de blâmer l'outil, localisez l'échec. Est-ce l'invite (spécification), le contexte (fenêtre pleine ou mauvais matériel chargé), le choix de fonctionnalité (mauvais point d'entrée, modèle ou pas d'exécution de code), ou une inadéquation d'attentes (la tâche n'a jamais été celle que Claude pouvait bien faire) ? Nommer lequel des quatre c'est pointe directement vers la correction.

Une séquence diagnostique

Exécutez-les dans l'ordre avant de conclure que Claude ne peut pas faire la tâche :

• Relisez l'invite par rapport aux cinq composants : quelque chose est-il sous-spécifié ?

• Vérifiez la longueur de la conversation : le contexte est-il surchargé et a-t-il besoin d'un redémarrage ou d'un résumé ?

• Vérifiez la fonctionnalité et le modèle : s'agit-il d'un calcul qui nécessite l'exécution de code, ou d'une tâche complexe sur un modèle de niveau vitesse ?

• Vérifiez la configuration : les instructions, les connaissances et les Skills sont-elles à jour ?

• Seulement ensuite, questionnez-vous si la tâche est un bon ajustement du tout.

La séquence s'exécute à correction-la-moins-chère-d'abord exprès. Relire l'invite coûte des secondes et résout l'échec le plus courant, donc elle va en premier. Redémarrer à partir d'un résumé coûte un peu plus d'effort, donc elle vient en deuxième. Changer de fonctionnalités ou de modèle et vérifier la configuration coûtent encore plus. Questionner si la tâche s'ajuste du tout est dernier car c'est la conclusion la plus chère, elle termine la tentative et vous ne devriez la atteindre qu'après que les causes moins chères soient exclues. La plupart des gens inversent ceci : ils sautent à « passer au modèle le plus capable » ou « cette tâche est impossible » en premier, ce qui est le mouvement coûteux qui généralement n'était pas nécessaire. La discipline ici est de résister à l'envie de sauter à l'étape 5.

Exemple travaillé : une galerie d'échecs

« Le résumé continue de manquer les points clés. » Diagnostic : sous-spécification. L'invite n'a jamais dit quels points importent. Correction : nommez les critères de « clé ».

« Il a arrêté de suivre mon format à mi-parcours. » Diagnostic : surcharge de contexte dans une longue session. Correction : redémarrez à partir d'un résumé, ou persistez le format dans une instruction permanente.

« Les nombres sont légèrement décalés. » Diagnostic : mauvaise fonctionnalité. Correction : déplacez le calcul vers l'exécution de code.

« Ça fonctionnait le mois dernier, maintenant c'est décalé. » Diagnostic : configuration obsolète. Correction : exécutez la liste de contrôle de maintenance du Module 5.

« Je lui ai demandé de prédire les ventes exactes du prochain trimestre et le nombre était faux. » Diagnostic : inadéquation d'attentes. C'est le cas étape-5 pour lequel la séquence est construite pour atteindre seulement après les autres. Aucun changement d'invite, redémarrage, fonctionnalité ou configuration ne le corrige, car la tâche demande quelque chose que l'outil ne peut pas faire, c'est-à-dire prédire un nombre futur avec précision. La correction est de remodeler la tâche en une qui s'ajuste : demandez une plage avec des hypothèses énoncées, ou un modèle des facteurs que vous pouvez ajuster. Reconnaître une véritable inadéquation est autant une compétence que de corriger un échec corrigible, cela vous empêche de brûler du temps en accordant une invite pour un résultat qui n'a jamais été disponible.

Exécutée de bout en bout, la séquence prend généralement une ou deux minutes et se termine à l'un de deux endroits : une correction spécifique et bon marché (la plupart du temps), ou un « cette tâche a besoin d'être remodelée » confiant et raisonné (occasionnellement). L'un ou l'autre est une victoire, car les deux remplacent les deux mauvaises valeurs par défaut par une décision que vous pouvez expliquer. L'habitude de la construction est d'atteindre la séquence automatiquement au moment où un résultat déçoit, avant de former une opinion sur la faute de qui c'est.

Nous avons construit ce cours Associate Module 7 : Dépannage et optimisation pour vous aider à faire du vrai travail avec Claude. Traitez-le comme du contenu éducatif. Il ne constitue pas un conseil juridique, financier ou autre conseil professionnel, alors adaptez ce que vous apprenez à votre propre situation. Nos produits et services évoluent rapidement, donc certains contenus peuvent contenir des erreurs ou être obsolètes ; n'oubliez pas de vérifier sur le site web ou la documentation d'Anthropic. Les exemples et scénarios utilisés dans le cours sont illustratifs et souvent fictifs. Si le matériel du cours mentionne une entreprise ou un produit, cela ne signifie pas qu'Anthropic 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 : Ajuster l'approche en fonction des commentaires et des résultats

EnseignementAjuster en fonction des commentaires·7 min

Chaque résultat décevant est une donnée diagnostique. Laisser ces données s'évaporer, corriger le même problème à la main chaque fois qu'il se reproduit, représente une opportunité manquée. La compétence est de traduire la critique de résultat en un ajustement spécifique, puis de capturer la correction pour qu'elle persiste.

Intégrer des boucles de rétroaction dans le travail récurrent

Pour le travail que vous faites régulièrement, traitez le résultat de chaque cycle comme un signal sur la configuration. Un rapport récurrent qui nécessite la même correction manuelle chaque semaine vous dit que l'invite, le contexte ou la configuration manque quelque chose. Construisez une habitude rapide de demander, après chaque cycle, ce que le résultat a révélé sur le système qui l'a produit.

Traduire la critique en un ajustement spécifique

Un vague « ce n'est pas tout à fait correct » n'améliore rien. Convertissez-le en le changement précis : quel composant, quel contexte, quel paramètre de configuration. « Trop générique » devient « ajouter l'audience au contexte. » « Mauvais ton » devient « ajouter une contrainte de ton à l'instruction permanente. » L'ajustement est assez spécifique pour agir et vérifier.

La compétence ici est de transformer une réaction en une instruction. Une réaction nomme comment le résultat se sent (« trop générique, » « pas tout à fait correct, » « a manqué le point »), tandis qu'une instruction nomme ce qu'il faut changer pour que le prochain résultat soit différent. La façon fiable de faire le saut est de demander : qu'est-ce qui devrait spécifiquement être présent pour que ce soit correct, et quelle partie de la configuration contrôle cela ? « Trop générique » devient « nommez l'audience et l'une action que je veux qu'elle prenne. » « A manqué le point » devient « énoncez la question unique à laquelle le résultat doit répondre d'emblée. » Chaque traduction pointe vers un levier spécifique, l'invite, le contexte chargé, ou un paramètre de configuration et ce levier est où la correction va. Si vous ne pouvez pas nommer le levier, la critique est toujours une réaction, et la prochaine tentative sera une supposition.

Capturer ce qui a fonctionné

Quand une correction fonctionne, ne la laissez pas dans une conversation ponctuelle où elle sera perdue. Promouvez-la : une formulation qui produit de manière fiable le bon résultat devient une instruction permanente ; une correction multi-étapes devient une Skill. Capturer la correction est ce qui transforme une chance en une amélioration permanente.

Le mode d'échec coûteux est de trouver la correction et puis de la perdre. Une correction découverte dans la session de lundi et non capturée sera redécouverte lundi prochain et par quiconque exécute la tâche. Chaque redécouverte coûte le même temps que la première, multiplié par chaque personne et chaque cycle. Capturer la correction une fois, comme une instruction permanente dans le Project ou comme une Skill, convertit un coût répété en un coût unique. Le test pour savoir si une correction vaut la peine d'être promue est simple : cette même correction sera-t-elle nécessaire à nouveau, par moi ou quelqu'un d'autre ? Si oui, elle appartient à la configuration. La Memory de Claude peut capter les modèles que vous répétez, mais elle est par utilisateur et au mieux ; la configuration est la maison délibérée, partagée et fiable pour une correction.

Exemple travaillé : une correction récurrente promue

Basculez pour comparer la même correction capturée par rapport à laissée dans une conversation ponctuelle.

Une spécialiste en marketing remarque que chaque brouillon de brief de campagne a besoin des deux mêmes corrections : il omet le segment cible et enterre l'appel à l'action. Au lieu de corriger les deux à la main chaque semaine, elle ajoute deux instructions permanentes au Project des briefs : « Énoncez toujours le segment cible dans la première ligne » et « Placez l'appel à l'action dans sa propre section de fermeture. » Le prochain brouillon arrive correct. Un cycle de rétroaction, capturé dans la configuration, supprime une correction hebdomadaire récurrente.

Contrastez cela avec l'analyste qui, chaque mois, rappelle manuellement à Claude que le rapport devrait exclure les comptes de test internes. Ils ont trouvé les bonnes instructions au mois un mais les ont gardées en conversation. Six mois plus tard, ils les tapent toujours, et quand un collègue les remplace, le collègue ne sait pas le faire, donc un rapport est expédié avec des données de test dedans. La correction existait tout le temps ; l'échec était de la laisser non capturée.

---

Écran 3 : Optimiser les flux de travail pour l'efficacité et l'efficacité

EnseignementOptimiser les flux de travail·8 min

L'optimisation est délibérée, pas accidentelle. Vous instrumentez le flux de travail, trouvez la friction, et promouvez la correction dans la configuration. Bien fait, cela se compose : chaque redondance supprimée et chaque modèle promu rend le flux de travail plus rapide et plus cohérent pour tous ceux qui l'utilisent.

Trouver la redondance et la friction

Regardez un flux de travail récurrent assisté par l'IA pour les étapes qui se répètent inutilement : le même contexte collé chaque session, la même correction faite chaque cycle, le même reformatage manuel à la fin. Chacun est une friction que la configuration peut supprimer. La friction est facile à vivre et difficile à voir, car vous l'absorbez une session à la fois. La façon d'identifier cela est de regarder un cycle complet du flux de travail et de noter chaque étape que vous faites à la main que vous avez aussi faite la dernière fois. Trois signaux pointent vers une friction supprimable. Retournez chacun pour voir la correction. Si vous ne pouvez pas voir la friction, exécutez le flux de travail une fois avec le travail explicite d'écrire chaque étape manuelle. Cette liste est votre backlog d'optimisation.

Répétition

Vous collez ou tapez la même chose à chaque exécution.

Correction : contexte sauvegardé ou une instruction permanente.

Correction

Vous corrigez le même défaut dans chaque résultat.

Correction : un changement de configuration pour que le défaut cesse d'apparaître.

Variance

Différentes personnes exécutant la même tâche obtiennent des résultats différents.

Correction : une Skill partagée ou une base de connaissances pour que tout le monde exécute la même configuration.

Consolider et promouvoir

Deux mouvements font la plupart du travail. Consolidez les étapes qui peuvent s'exécuter ensemble plutôt que comme des invites séparées. Et promouvez les modèles répétés dans les Projects et les Skills : le contexte que vous collez à chaque fois appartient à la base de connaissances ou aux instructions permanentes ; une procédure que vous exécutez à chaque fois appartient à une Skill. La promotion est comment une solution de contournement personnelle devient une efficacité à l'échelle de l'équipe.

La promotion n'aide que si la correction atterrit au bon endroit. Une instruction permanente est pour une règle qui devrait toujours s'appliquer dans un Project (« toujours inclure le segment cible »). La base de connaissances du Project est pour le matériel de référence que chaque exécution a besoin (« notre guide de voix de marque, » « la liste de produits actuelle »). Une Skill est pour une procédure répétable avec des étapes (« générer le rapport hebdomadaire dans cet ordre et ce format exact »). Le test rapide : est-ce une règle, une référence ou une procédure ? Les règles vont aux instructions, les références vont aux connaissances, les procédures vont aux Skills. Mettre une correction au mauvais endroit est pourquoi certaines « optimisations » ne collent pas. Une procédure collée comme une instruction d'une ligne perd ses étapes, et le matériel de référence entassé dans une instruction gonfle chaque invite.

Pas chaque changement est une amélioration, alors promouvez avec un peu de prudence. Quand vous déplacez une correction dans la configuration, exécutez le flux de travail quelques cycles avec l'ancienne approche toujours disponible avant de vous fier complètement à la nouvelle configuration. Si la version optimisée produit des résultats pires ou moins prévisibles, vous voulez le capturer avant qu'il n'ait expédié plusieurs fois. Le bénéfice composé de l'optimisation est réel, mais aussi le coût composé d'un mauvais changement intégré dans un flux de travail que tout le monde utilise. Prouvez le gain sur quelques exécutions, puis engagez-vous à cela.

Mesurer l'amélioration

L'optimisation que vous ne pouvez pas mesurer est difficile à justifier ou à maintenir. Suivez les gains concrets : temps économisé par cycle, cycles de révision réduits, cohérence améliorée entre les personnes faisant la même tâche. Un flux de travail qui est passé de 40 minutes à 25, ou de trois cycles de révision à un, est une amélioration sur laquelle vous pouvez pointer.

Le temps économisé est la métrique la plus facile, mais ce n'est pas toujours celle qui importe le plus. Pour certains flux de travail, le vrai gain est la cohérence (chaque résultat suit maintenant le même format et capture les mêmes problèmes, indépendamment de qui l'exécute) ou la qualité (moins d'erreurs atteignent le produit final). Choisissez la métrique qui correspond à la raison pour laquelle le flux de travail importait : un rapport orienté client optimise la cohérence et la précision plus que la vitesse brute ; un brouillon interne optimise pour le temps. Identifier la bonne métrique d'avance vous dit aussi quand arrêter, l'optimisation a des rendements décroissants, et une fois que la métrique qui vous importe est assez bonne, un réglage supplémentaire est sa propre sorte de friction.

Exemple travaillé : un audit d'efficacité du flux de travail

Le flux de travail de rapport hebdomadaire d'une équipe prend environ 45 minutes par analyste, et les résultats varient selon qui l'exécute. L'audit trouve trois frictions : chaque analyste recolle le même contexte, chaque reformate le résultat à la main, et chacun capture des choses différentes.

L'optimisation : déplacez le contexte dans une base de connaissances partagée du Project, ajoutez une Skill pour le format du rapport, et définissez une instruction permanente pour l'étape de vérification. Résultat : environ 25 minutes par analyste, format cohérent dans l'équipe, et un cycle de révision de moins. La friction a été trouvée en instrumentant le flux de travail ; le gain est venu de la promotion des corrections dans la configuration.

Remarquez comment l'exemple se mappe proprement sur les trois maisons de promotion : le contexte répété (une référence) est allé à la base de connaissances, le format du rapport (une procédure) est allé à une Skill, et l'étape de vérification (une règle) est allée à une instruction permanente. C'est le test règle-référence-procédure appliqué. Quand vous exécutez votre propre audit, trier chaque friction dans l'une de ces trois maisons est ce qui transform