D7 · Troubleshooting and Optimization

Ce domaine représente environ 6 items sur 60. Il évalue votre capacité à diagnostiquer et corriger un résultat décevant méthodiquement plutôt qu’à tâtonner — trouver la vraie cause (ambiguïté, contexte manquant, instructions conflictuelles, mauvais format, prompt surchargé), exécuter une boucle de débogage disciplinée, gérer les refus et les limites de longueur, réinitialiser les conversations surchargées ou dérivantes, et optimiser coût et vitesse sans sacrifier la qualité qui compte.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

Diagnostiquer les causes fréquentes d’un prompt sous-performant.
Exécuter une boucle de débogage de prompt systématique.
Ajuster d’après le retour avec des changements ciblés.
Gérer les refus et l’excès de prudence de façon appropriée.
Gérer la troncature et les limites de longueur.
Reconnaître la surcharge de contexte et savoir quand réinitialiser.
Détecter et corriger la dérive de sortie dans les longs chats.
Optimiser coût et vitesse et mesurer l’amélioration.

7.1 Diagnosing an underperforming prompt

La plupart des mauvaises sorties se ramènent à l’une de cinq causes. Nommez la cause avant de changer quoi que ce soit.

Cause	Symptôme	Correction
Ambiguïté	Hors sujet, générique, mauvaise interprétation	Clarifier le public, le périmètre, la définition du succès
Contexte manquant	Vague, prudent à l’excès, détails inventés	Fournir le document/les données ; y ancrer la tâche
Instructions conflictuelles	Sortie confuse, ignore une partie de la demande	Retirer les contradictions ; énoncer une seule priorité claire
Mauvaise demande de format	Bon contenu, forme inexploitable	Spécifier format, longueur, schéma exacts
Prompt surchargé	Abandonne des exigences ; qualité inégale	Décomposer en étapes (D1)

Signal d’examen

La bonne correction est presque toujours de changer le prompt/le contexte, pas de « changer de modèle », « augmenter un paramètre » ou « régénérer à l’aveugle ». Faites correspondre le symptôme de l’énoncé à l’une de ces cinq causes.

7.2 The systematic debugging loop

Déboguer un prompt, c’est comme déboguer n’importe quoi : changez une variable à la fois et observez.

Reproduire — confirmez que le problème est constant, pas ponctuel.
Isoler la cause — faites correspondre le symptôme à l’une des cinq causes ci-dessus. Lisez le prompt comme Claude le ferait.
Changer UNE seule chose — ajouter le contexte manquant, retirer une contradiction ou corriger la demande de format.
Réexécuter et comparer — ce changement précis a-t-il aidé ? Sinon, annulez-le et essayez l’hypothèse suivante.
Verrouiller l’amélioration (dans un Project ou une Skill) une fois qu’elle fonctionne, pour ne pas la re-résoudre plus tard.

7.3 Adjusting based on feedback

Quand vous savez ce qui ne va pas, faites des retouches ciblées (c’est l’itération de D1 appliquée à la correction de défauts) :

Retour	Ajustement ciblé
« Trop vague »	Ajouter des précisions : public, critères, exemples
« A manqué une partie de la tâche »	Découper en étapes ; vérifier chaque partie
« Mauvais ton/longueur »	Énoncer le ton et un nombre explicite de mots/phrases
« A halluciné un chiffre »	Fournir la source ; ajouter « si non précisé, dis-le »
« Format incohérent »	Fournir un exemple résolu (few-shot)

7.4 Handling refusals and over-caution

Claude peut refuser ou surpondérer la prudence. Diagnostiquez le pourquoi avant de réagir.

Situation	Bonne réponse
Refus parce que la demande est réellement contraire à la politique/nuisible	Respectez-le ; ne cherchez pas de contournement — reconsidérez la tâche (D6)
Excès de prudence sur une tâche légitime par manque de contexte	Ajouter du contexte et clarifier la légitimité (« c’est notre propre document interne, pour usage interne »)
Formulation ambiguë qui paraît risquée	Reformuler clairement et précisément, en énonçant l’objectif légitime
Demande réellement limite	Escalader vers la conformité plutôt que fabriquer un contournement

Ne traitez pas les refus légitimes comme des bugs

Si le refus vient du fait que la tâche est réellement non autorisée, la correction est de changer la tâche, pas de jailbreaker le modèle. Essayer des reformulations pour forcer une sortie interdite est une violation de gouvernance (D6), pas du dépannage.

7.5 Handling truncation and length limits

Les sorties peuvent être coupées (troncature) quand la réponse est très longue, ou l’entrée peut dépasser les limites.

Problème	Correction
Sortie coupée en cours de route	Demander à Claude de « continuer », ou demander la sortie en parties/sections étiquetées
Trop demander d’un coup	Découper le livrable en sections et les assembler
Entrée trop grande	Résumer ou fournir uniquement la portion pertinente ; utiliser un Project pour de gros documents récurrents
Atteindre les limites de façon répétée	Décomposer la tâche ; ne pas juste réessayer la même demande surdimensionnée

7.6 Context bloat and when to reset

Une longue conversation accumule de l’historique. Passé un certain point, cet historique nuit plus qu’il n’aide : les réponses ralentissent, les détails antérieurs se perdent, et les fils se confondent.

Réinitialisez (démarrez un nouveau chat) quand :

Claude oublie ou contredit des décisions antérieures.
La conversation a couvert plusieurs sujets sans rapport.
Les réponses ont dérivé de l’objectif initial.
Vous éteignez des incendies dans un contexte pollué avec des corrections sans fin.

Comment bien réinitialiser : demandez à Claude de résumer les décisions/l’état, puis démarrez un nouveau chat avec ce résumé comme brief propre (D3). Pour le contexte récurrent, persistez-le dans un Project plutôt que de le porter dans l’historique du chat.

7.7 Output drift in long chats

La dérive de sortie (output drift) est l’écart progressif par rapport aux instructions/au format d’origine au fil d’une longue conversation — le ton dérive, le format change, les contraintes antérieures s’estompent.

Détecter	Corriger
Le format a changé par rapport à la forme convenue	Réénoncer le format explicitement ; donner un exemple
Le ton s’est éloigné du brief	Réancrer : « revenez au ton formel de conseil que nous avons fixé »
Contraintes antérieures ignorées	Réénoncer la contrainte ; si cela persiste, réinitialiser avec un brief propre
Confusion de plusieurs fils	Réinitialiser et séparer les sujets dans des chats différents

Signal d’examen

« Longue conversation », « les réponses étaient bonnes mais se sont dégradées », « a commencé à ignorer le format » → surcharge de contexte / dérive de sortie → réancrer ou réinitialiser (résumer → nouveau chat), pas « changer de modèle ».

7.8 Optimising cost and speed

Une fois la qualité acceptable, optimisez la façon la moins chère/la plus rapide de l’obtenir.

Levier	Quand l’utiliser	Compromis
Descendre le modèle (p. ex. Opus → Sonnet → Haiku)	Tâches routinières, à fort volume, sensibles à la latence	Surveillez la qualité sur les items difficiles ; ne descendez pas le travail à enjeux élevés
Désactiver la réflexion étendue	Tâches simples	Plus rapide/moins cher ; gardez-la pour le raisonnement difficile
Réutiliser via Projects/Skills	Tâches récurrentes	Évite de reprompt ; nécessite de la maintenance (D5)
Resserrer les prompts	Échanges verbeux et sinueux	Contexte plus court = plus rapide/moins cher
Dimensionner la sortie	Réponses trop longues	Demandez la longueur dont vous avez réellement besoin

N’optimisez pas au détriment de la qualité qui compte

Descendre le modèle ou supprimer la revue pour une tâche à enjeux élevés afin d’économiser est le mauvais compromis — cela réintroduit l’erreur de D3 de sous-dimensionner la qualité. Optimisez le travail routinier ; protégez le travail à enjeux élevés.

7.9 Measuring improvement

Prouvez que la correction a fonctionné ; ne vous fiez pas à l’impression.

Avant/après sur la même tâche — comparez au cas d’échec d’origine.
Retouches nécessaires du relecteur — moins de retouches = meilleure sortie.
Cohérence — la correction tient-elle sur plusieurs exécutions, pas seulement une fois ?
Coût/temps — une optimisation a-t-elle réellement réduit coût/latence sans nuire à la qualité ?
Par type de tâche — confirmez que la correction n’a pas discrètement cassé une autre catégorie (évitez les métriques uniquement agrégées).

7.10 A troubleshooting decision tree

L’examen récompense le diagnostic avant l’action. Routez tout résultat décevant par cet arbre, qui fait correspondre un symptôme à sa vraie cause et à la bonne première correction.

Signal d’examen

Presque chaque bonne réponse de D7 est « identifier la cause et corriger le prompt/le contexte/la conversation ». Les options qui recourent à un modèle plus gros, un paramètre ou une régénération aveugle comme premier geste sont des distracteurs — elles traitent le symptôme, pas la cause.

7.11 Optimisation trade-offs and guardrails

Optimiser coût et vitesse est légitime une fois la qualité acceptable — mais seulement sur le bon travail. L’examen teste si vous protégez la qualité qui compte.

Optimisation	Sûre sur…	Dangereuse sur…
Descendre le modèle	Tâches routinières, à fort volume, à faibles enjeux	Analyse à enjeux élevés, contenu réglementé
Désactiver la réflexion étendue	Recherches/réécritures simples	Raisonnement multi-étapes complexe
Supprimer/assouplir un point de contrôle de revue	(jamais pour les enjeux élevés)	Sorties irréversibles, réglementées, externes
Élaguer le prompt/le contexte	Échanges verbeux et sinueux	Là où le détail élagué était porteur
Dimensionner la sortie	Réponses trop longues	Là où la complétude est requise

Avant/après — une optimisation qui a mal tourné, puis corrigée :

Optimisez le travail routinier, protégez le travail à enjeux élevés

Les économies qui suppriment la qualité ou un point de contrôle de revue de tâches à enjeux élevés sont le mauvais compromis — toujours. Redirigez l’optimisation vers le travail routinier, à fort volume et à faibles enjeux, où la barre de qualité est plus basse.

7.12 Common misconceptions

Idée reçue	Réalité	Pourquoi cela compte à l’examen
« Un modèle plus gros corrige un mauvais résultat. »	Si la cause est l’ambiguïté/le format/le contexte, le modèle n’est pas le problème.	Distracteur du modèle-comme-correction.
« Régénérer, c’est du dépannage. »	Cela fait varier la formulation, pas la cause sous-jacente.	Distracteur de régénération aveugle.
« Changer plusieurs choses à la fois pour corriger vite. »	Vous ne pouvez pas dire ce qui a marché ni le reproduire.	Item une-variable-à-la-fois.
« Un refus légitime est un bug à jailbreaker. »	Si la tâche est non autorisée, changez la tâche, pas le comportement du modèle.	Item de frontière de gouvernance.
« Réessayer la même demande surdimensionnée après troncature. »	Cela répète la limite ; continuez ou sectionnez.	Item de gestion de troncature.
« Continuer à corriger le chat géant dérivant. »	Réinitialisez : résumer → nouveau chat ; persister le contexte récurrent.	Item de surcharge de contexte.
« Moins cher est toujours mieux. »	Pas sur le travail à enjeux élevés ; protégez la qualité et les points de contrôle.	Item de garde-fou d’optimisation.
« Une seule bonne exécution prouve que la correction a marché. »	Vérifiez avant/après, sur plusieurs exécutions, par type de tâche.	Item de mesure.

7.13 Scenario walkthrough – a status report that got worse over a long session

Scénario. Une chargée a passé deux heures dans un seul chat à construire un rapport de statut d’exploitation hebdomadaire. Au début, il était excellent. Maintenant, Claude contredit une décision antérieure sur les métriques à inclure, a discrètement fait passer le tableau de quatre colonnes à trois, inventé un chiffre de livraison, et abandonné entièrement la section « risques ». Sous pression de temps, la chargée s’apprête à passer au modèle le plus cher et à y coller toute la transcription de deux heures.

Trace de raisonnement d’expert.

Diagnostiquer, ne pas monter en gamme le modèle. « Était bon, dérive maintenant/oublie/change de format » est la signature d’une surcharge de contexte / dérive de sortie, pas d’un manque de capacité du modèle. Un modèle plus gros avec le même contexte surchargé dérivera aussi, donc changer de modèle (et coller toute la transcription) est rejeté.
Séparer les sous-problèmes. Il y en a quatre : une décision contredite (dérive), un changement de format (dérive), un chiffre inventé (fabrication) et une section abandonnée (complétude). Chacun a une correction ciblée, mais la racine commune est la conversation polluée.
Réinitialiser correctement. Demandez à Claude de résumer les décisions confirmées et l’état actuel, puis démarrez un nouveau chat avec ce résumé comme brief propre — cela efface la surcharge tout en gardant les conclusions.
Réancrer le format explicitement. Dans le chat propre, réénoncez la mise en page exacte à quatre colonnes et, si nécessaire, donnez un exemple résolu pour que le format tienne.
Tuer la fabrication à la source. Ancrez le rapport aux données sources : « utilisez uniquement les métriques jointes ; si un chiffre n’est pas précisé, écrivez « non précisé ». » Vérifiez le chiffre de livraison par rapport à la source (D2).
Restaurer la complétude. Incluez la section « risques » dans le brief et vérifiez-la par rapport à la structure requise.
Prévenir la récurrence. Comme ce rapport est hebdomadaire et récurrent, persistez les instructions, le format et l’emplacement des données dans un Project (ou capturez les étapes en Skill) pour que la semaine prochaine démarre d’une configuration propre et correcte (D5).

Décision correcte à l’examen : résumer → démarrer un nouveau chat avec un brief propre, réancrer le format exact, ancrer les chiffres à la source, restaurer la section manquante et persister la configuration dans un Project. Pas un modèle plus gros, pas coller toute la transcription, pas des corrections en place sans fin.

Pièges de l’examen dans ce domaine

Piège	Pourquoi c’est faux
« Passer à un modèle plus gros pour corriger un prompt vague »	Le prompt est la cause ; un modèle plus gros manque toujours du contexte/format
« Changer plusieurs choses à la fois jusqu’à ce que ça marche »	Vous n’apprenez rien ; changez une variable à la fois
« Régénérer de façon répétée en espérant un meilleur résultat »	La régénération aveugle n’est pas du débogage ; corrigez la cause identifiée
« Jailbreaker autour d’un refus légitime »	Si la tâche est non autorisée, changez la tâche, pas le comportement du modèle
« Garder un chat géant et continuer à le corriger »	Surcharge/dérive de contexte ; résumez et réinitialisez vers un brief propre
« Réessayer la même demande surdimensionnée après troncature »	Décomposez en parties ou demandez de continuer ; réessayer répète la limite
« Descendre le modèle sur un travail à enjeux élevés pour économiser »	Sous-dimensionne la qualité là où les erreurs coûtent cher
« Faire confiance qu’une correction a marché sans mesurer »	Vérifiez avant/après et sur plusieurs exécutions, par type de tâche
« Coller toute la longue transcription dans un modèle plus gros »	Reporte la surcharge ; résumez l’état et démarrez un chat propre à la place
« Un format qui change sans cesse a besoin de plus de description »	Fournissez un exemple résolu (few-shot) ; réancrez ou réinitialisez si la dérive persiste
« Des chiffres inventés dans un long chat signifient qu’il faut monter le modèle »	Ancrez à la source et vérifiez ; la cause est l’ancrage/la dérive, pas le niveau
« Moins cher est toujours la meilleure optimisation »	Protégez la qualité et les points de contrôle de revue sur le travail à enjeux élevés ; optimisez le travail routinier

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Tentez avant de révéler.

Q1 · Un prompt renvoie une réponse générique et hors sujet. Avant toute chose, que doit faire l’utilisateur ? (Sélectionnez une réponse)

A. Passer au modèle le plus cher. B. Identifier la cause — probablement l’ambiguïté ou un contexte manquant — et corriger ce problème précis dans le prompt. C. Régénérer cinq fois. D. Activer la réflexion étendue.

Réponse : B. Le diagnostic précède l’action : faites correspondre le symptôme (générique/hors sujet) à sa cause (ambiguïté/contexte manquant) et corrigez-la. Un modèle plus gros (A) n’ajoute pas le contexte manquant ; régénérer (C) fait varier la formulation, pas la pertinence ; la réflexion (D) ne corrige pas une demande vague.

Q2 · Un utilisateur change le modèle, réécrit le prompt, augmente la longueur et régénère tout à la fois — et la sortie s’améliore. Quel est le PROBLÈME de cette approche ? (Sélectionnez une réponse)

A. Aucun ; ça a marché. B. Changer plusieurs variables à la fois signifie que l’utilisateur ne peut pas dire ce qui a réellement corrigé ni le reproduire fiablement. C. Elle a utilisé trop peu de calcul. D. Elle aurait dû utiliser un modèle moins cher.

Réponse : B. Le débogage systématique change une variable à la fois pour que la correction efficace soit identifiable et reproductible. « Ça a marché » (A) ignore la reproductibilité ; le calcul (C) et le coût du modèle (D) ne sont pas le problème.

Q3 · La sortie de Claude est coupée de façon répétée avant qu’il ne termine un long rapport. Quelles sont les DEUX MEILLEURES réponses ? (Sélectionnez deux réponses)

A. Demander à Claude de continuer là où il s’est arrêté. B. Demander le rapport en sections étiquetées et les assembler. C. Continuer à réessayer la même demande unique surdimensionnée. D. Passer à un modèle moins cher. E. Désactiver la réflexion étendue.

Réponse : A et B. La troncature se gère en continuant ou en découpant le livrable en sections. Réessayer la même demande surdimensionnée (C) répète la limite ; le niveau de modèle (D) et la réflexion (E) ne traitent pas la longueur de sortie.

Q4 · Un chat de deux heures a couvert plusieurs sujets et Claude contredit maintenant des décisions antérieures et ignore le format convenu. Quelle est la MEILLEURE correction ? (Sélectionnez une réponse)

A. Continuer à le corriger dans le même chat. B. Demander à Claude de résumer les décisions, puis démarrer un nouveau chat avec ce résumé comme brief propre. C. Passer à un modèle plus gros. D. Activer la réflexion étendue.

Réponse : B. C’est de la surcharge de contexte/dérive de sortie ; le remède est de capturer l’état et de réinitialiser vers un contexte propre. Continuer à corriger (A) combat la surcharge ; le niveau de modèle (C) et la réflexion (D) n’effacent pas un contexte pollué.

Q5 · Claude refuse par excès de prudence d’aider à éditer le PROPRE document interne de l’entreprise, apparemment incertain qu’il soit légitime. Quelle est la MEILLEURE réponse ? (Sélectionnez une réponse)

A. Essayer de nombreuses reformulations pour forcer l’obéissance. B. Clarifier le contexte légitime — qu’il s’agit du propre document interne de l’utilisateur pour usage interne — et réénoncer la tâche clairement. C. Escalader vers la conformité immédiatement. D. Abandonner.

Réponse : B. L’excès de prudence sur une tâche légitime se corrige généralement en ajoutant du contexte qui établit la légitimité. Forcer l’obéissance par des reformulations (A) est inapproprié pour des tâches réellement non autorisées et inutile ici ; l’escalade (C) est prématurée ; abandonner (D) est du gaspillage.

Q6 · Une équipe exécute une tâche de classification simple et à fort volume sur Opus 5 et veut réduire les coûts. Quelle est la MEILLEURE optimisation ? (Sélectionnez une réponse)

A. Garder Opus 5 ; c’est le plus sûr. B. Descendre à Haiku (ou Sonnet), en vérifiant que la qualité tient pour cette tâche routinière. C. Activer la réflexion étendue pour être rigoureux. D. Ajouter plus d’instructions.

Réponse : B. Le travail routinier à fort volume devrait s’exécuter sur le modèle le moins cher qui maintient la qualité ; descendez et vérifiez. Garder Opus (A) surdimensionne ; la réflexion étendue (C) ajoute du coût sans bénéfice ici ; plus d’instructions (D) ne réduit pas le coût.

Q7 · Un Associate veut réduire le coût d’une analyse juridique à ENJEUX ÉLEVÉS en la passant à Haiku et en supprimant la revue humaine. Qu’est-ce qui ne va pas ? (Sélectionnez une réponse)

A. Rien ; les économies sont toujours bonnes. B. Cela sous-dimensionne la qualité et supprime un point de contrôle de revue requis sur un travail à enjeux élevés — le mauvais compromis. C. Haiku est trop cher. D. La réflexion étendue devrait être désactivée.

Réponse : B. L’optimisation ne doit pas sacrifier la qualité/la revue là où les enjeux sont élevés ; cela réintroduit le sous-dimensionnement et supprime un point de contrôle nécessaire. Les économies ne sont pas toujours bonnes (A) ; Haiku est l’option économique, pas chère (C) ; les réglages de réflexion (D) ne sont pas le problème central.

Q8 · Un prompt contient deux instructions contradictoires (« sois extrêmement détaillé » et « réponds en une phrase »). Quel est le symptôme et la correction ? (Sélectionnez une réponse)

A. Contexte manquant ; ajouter un document. B. Instructions conflictuelles ; retirer la contradiction et énoncer une seule priorité claire. C. Mauvais modèle ; monter en gamme. D. Troncature ; demander de continuer.

Réponse : B. Des instructions contradictoires embrouillent la sortie ; résolvez le conflit et fixez une priorité. Ce n’est pas un contexte manquant (A), un problème de modèle (C) ni une troncature (D).

Q9 · Comment un utilisateur peut-il le MIEUX confirmer qu’une correction de prompt a réellement amélioré les résultats ? (Sélectionnez une réponse)

A. Faire confiance à l’impression que c’est mieux. B. Comparer avant/après sur la même tâche et vérifier que la correction tient sur plusieurs exécutions et types de tâches. C. Supposer qu’une seule bonne exécution le prouve. D. Ne vérifier que le score de satisfaction global.

Réponse : B. Mesurer l’amélioration signifie comparaison avant/après, cohérence sur plusieurs exécutions et vérifications par type de tâche. L’impression (A), une seule exécution (C) et la satisfaction uniquement agrégée (D) peuvent induire en erreur.

Q10 · Claude dérive sans cesse du format de tableau convenu à mi-parcours d’une longue session de travail. Quelles sont les DEUX MEILLEURES actions correctives ? (Sélectionnez deux réponses)

A. Réénoncer le format exact et fournir un exemple résolu. B. Si la dérive persiste, réinitialiser avec un brief propre et consolidé. C. Passer à un modèle moins cher. D. L’ignorer ; le format n’a pas d’importance. E. Activer la réflexion étendue.

Réponse : A et B. Réancrer avec un format explicite et un exemple corrige la dérive ; une réinitialisation la corrige quand le contexte est trop pollué. Le niveau de modèle (C) et la réflexion (E) ne traitent pas la dérive ; ignorer le format (D) accepte le défaut.

Q11 · Un prompt regroupe cinq livrables et en abandonne systématiquement deux. Quelle est la cause et la correction ? (Sélectionnez une réponse)

A. Troncature ; augmenter la longueur. B. Prompt surchargé ; décomposer en étapes ordonnées et vérifier chacune. C. Refus ; ajouter du contexte. D. Mauvais modèle ; monter en gamme.

Réponse : B. Abandonner des parties d’une demande regroupée est le motif du prompt surchargé ; la décomposition le corrige. Ce n’est pas la troncature d’une sortie unique (A), un refus (C) ni un problème de modèle (D).

Q12 · Un utilisateur atteint la limite de taille d’entrée en collant un très grand document de façon répétée. Quelle est la MEILLEURE correction durable ? (Sélectionnez une réponse)

A. Continuer à réessayer le collage. B. Fournir uniquement la portion pertinente, ou stocker le document dans le knowledge d’un Project pour que les chats puissent l’exploiter sans le recoller. C. Passer à la réflexion étendue. D. Utiliser un modèle moins cher.

Réponse : B. Une entrée surdimensionnée récurrente se gère au mieux en utilisant uniquement la partie pertinente ou en persistant le document dans un Project. Réessayer (A) répète la limite ; la réflexion (C) et le niveau de modèle (D) ne résolvent pas la taille d’entrée.

Q13 · Quelle séquence reflète une boucle de débogage de prompt SYSTÉMATIQUE ? (Sélectionnez une réponse)

A. Tout changer, l’expédier, passer à autre chose. B. Reproduire le problème, isoler la cause, changer une seule chose, réexécuter et comparer, puis verrouiller la correction. C. Régénérer jusqu’à ce que ça ait l’air bon. D. Escalader vers les Developers immédiatement.

Réponse : B. La boucle disciplinée est reproduire → isoler → changer une variable → comparer → verrouiller. Tout changer (A) et régénérer à l’aveugle (C) ne sont pas systématiques ; l’escalade immédiate (D) saute le diagnostic.

Q14 · Un chat de rapport hebdomadaire, excellent il y a deux heures, contredit maintenant une décision antérieure, a changé le format du tableau, inventé un chiffre et abandonné une section. Quelle est la MEILLEURE PREMIÈRE action ? (Sélectionnez une réponse)

A. Passer au modèle le plus cher et y coller toute la transcription. B. Demander à Claude de résumer les décisions confirmées et l’état, puis démarrer un nouveau chat avec ce résumé comme brief propre. C. Continuer à corriger chaque problème dans le même chat. D. Activer la réflexion étendue.

Réponse : B. Ce sont des symptômes de surcharge de contexte/dérive ; le remède est de capturer l’état et de réinitialiser vers un contexte propre. Un modèle plus gros avec la transcription collée (A) reporte la surcharge ; la correction en place (C) combat la surcharge ; la réflexion (D) ne l’efface pas.

Q15 · Pour réduire les coûts, un collègue propose de passer la revue de contrat juridique à Haiku ET de supprimer la validation de l’avocat, tout en laissant l’étiquetage de tickets à fort volume sur Opus. Quelle est la MEILLEURE correction ? (Sélectionnez une réponse)

A. L’approuver ; moins cher est toujours mieux. B. Garder le modèle supérieur et la validation de l’avocat pour les contrats (enjeux élevés), et plutôt passer l’étiquetage de tickets routinier à Haiku, en vérifiant que la qualité tient. C. Passer les deux à Haiku. D. Passer les deux à Opus.

Réponse : B. Protégez la qualité et le point de contrôle de revue sur le travail de contrat à enjeux élevés ; redirigez l’optimisation vers l’étiquetage routinier à fort volume. « Moins cher est toujours mieux » (A, C) sous-dimensionne et supprime un point de contrôle sur un travail à enjeux élevés ; Opus pour l’étiquetage (D) surdimensionne.

Q16 · Le long rapport de Claude est tronqué de façon répétée. Quelles DEUX réponses sont les MEILLEURES ? (Sélectionnez deux réponses)

A. Demander à Claude de continuer là où il s’est arrêté. B. Demander le rapport en sections étiquetées et les assembler. C. Réessayer la même demande unique surdimensionnée. D. Passer à un modèle moins cher. E. Désactiver la réflexion étendue.

Réponse : A et B. La troncature se gère en continuant ou en sectionnant le livrable. Réessayer la même demande surdimensionnée (C) répète la limite ; le niveau de modèle (D) et la réflexion (E) ne traitent pas la longueur de sortie.

Q17 · Un prompt contient deux instructions contradictoires (« inclus chaque détail » et « réponds en une phrase ») et la sortie est confuse. Quelle est la cause et la correction ? (Sélectionnez une réponse)

A. Contexte manquant ; joindre un document. B. Instructions conflictuelles ; retirer la contradiction et énoncer une seule priorité claire. C. Troncature ; demander de continuer. D. Mauvais modèle ; monter en gamme.

Réponse : B. Des instructions contradictoires embrouillent la sortie ; résolvez le conflit et fixez une priorité. Ce n’est pas un contexte manquant (A), une troncature (C) ni un problème de modèle (D).

Q18 · Claude refuse par excès de prudence d’aider à éditer le propre document interne d’accueil de l’entreprise, incertain qu’il soit légitime. Quelle est la MEILLEURE réponse ? (Sélectionnez une réponse)

A. Essayer de nombreuses reformulations pour forcer l’obéissance. B. Clarifier le contexte légitime — le propre document interne de l’utilisateur pour usage interne — et réénoncer la tâche clairement. C. Escalader vers la conformité immédiatement. D. Abandonner la tâche.

Réponse : B. L’excès de prudence sur une tâche légitime se corrige généralement en ajoutant du contexte qui établit la légitimité. Forcer l’obéissance par des reformulations (A) est inapproprié et inutile ici ; l’escalade (C) est prématurée ; abandonner (D) est du gaspillage.

Q19 · Claude dérive sans cesse du format de tableau convenu à quatre colonnes à mi-parcours d’une longue session de travail. Quelles DEUX actions correctives sont les MEILLEURES ? (Sélectionnez deux réponses)

A. Réénoncer le format exact à quatre colonnes et fournir un exemple résolu. B. Si la dérive persiste, réinitialiser avec un brief propre et consolidé. C. Passer à un modèle moins cher. D. L’ignorer ; le format n’a pas d’importance. E. Activer la réflexion étendue.

Q20 · Une chargée a appliqué une correction de prompt et une exécution a semblé excellente, elle a donc déclaré la réussite. Quelle est la FAILLE et la meilleure pratique ? (Sélectionnez une réponse)

A. Aucune faille ; une bonne exécution suffit. B. Une seule exécution n’est pas une preuve ; comparez avant/après sur la même tâche et confirmez que la correction tient sur plusieurs exécutions et types de tâches. C. Elle ne devrait suivre que la satisfaction globale. D. Elle devrait changer de modèle pour être sûre.

Réponse : B. Mesurer l’amélioration signifie comparaison avant/après, cohérence sur plusieurs exécutions et vérifications par type de tâche — pas une seule exécution chanceuse. Une exécution (A) peut induire en erreur ; la satisfaction uniquement agrégée (C) cache les échecs par segment ; changer de modèle (D) ne valide pas la correction.

À retenir

Diagnostiquez avant de changer : la plupart des mauvaises sorties sont de l’ambiguïté, un contexte manquant, des instructions conflictuelles, un mauvais format ou un prompt surchargé.
Déboguez systématiquement — reproduire, isoler, changer une variable, comparer, verrouiller.
Corrigez les défauts par des ajustements ciblés, pas par une régénération aveugle ou un changement de modèle.
Respectez les refus légitimes ; corrigez l’excès de prudence en ajoutant du contexte légitime — ne jailbreakez jamais une tâche non autorisée.
Gérez la troncature en continuant ou en sectionnant ; gérez une entrée surdimensionnée en élaguant ou via un Project.
Réinitialisez les chats surchargés et dérivants : résumez, puis repartez de zéro ; persistez le contexte récurrent dans un Project.
Optimisez coût/vitesse sur le travail routinier (descendre le modèle, resserrer les prompts, réutiliser via Projects/Skills) mais protégez la qualité et la revue à enjeux élevés.
Vérifiez les améliorations par une mesure avant/après et par type de tâche.
Routez les symptômes par l’arbre de dépannage ; un modèle plus gros/un paramètre/une régénération aveugle n’est jamais le bon premier geste.
Ne collez jamais toute une transcription surchargée dans un modèle plus gros — résumez l’état et réinitialisez à la place.
L’optimisation ne doit jamais dépouiller la qualité ou un point de contrôle de revue d’un travail à enjeux élevés ; redirigez-la vers les tâches routinières.