D3 · Product and Model Selection

Ce domaine représente environ 7 items sur 60. Il évalue votre capacité à choisir le bon outil pour la tâche selon trois dimensions : la surface produit (chat, Projects, artifacts, research, connectors, Claude Code, etc.), le niveau de plan (de Free à Enterprise) et le modèle (Haiku, Sonnet, Opus, Fable). Le jugement récurrent est de faire correspondre la capacité et le coût aux enjeux de la tâche — sans surdimensionner ni sous-dimensionner.

Objectifs d’apprentissage

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

Identifier la bonne surface produit pour une tâche donnée.
Distinguer conceptuellement les niveaux de plan et ce que chacun débloque.
Choisir parmi Haiku 4.5, Sonnet 5, Opus 5 et Fable 5.1 selon le coût, la vitesse et la qualité.
Aligner le choix du modèle sur les enjeux d’une tâche.
Raisonner sur les limites de la fenêtre de contexte et la mémoire : quand démarrer un nouveau chat, résumer ou persister dans un Project.
Décider quand la réflexion étendue / adaptative aide.

3.1 The product surfaces

Claude n’est pas une seule chose — c’est une famille de surfaces. L’examen attend de vous que vous fassiez correspondre un besoin à la bonne.

Surface	Ce que c’est	À utiliser quand…
claude.ai chat	L’interface conversationnelle centrale	Questions ponctuelles, rédaction, analyse dans un seul fil
Projects	Un espace de travail avec instructions personnalisées + fichiers de knowledge + memory partagés entre chats	Le même contexte (docs, ton, règles) revient à travers de nombreux chats
Artifacts	Un panneau latéral pour des livrables autonomes sur lesquels vous itérez	Documents, tableaux, graphiques, maquettes, scripts que vous réviserez
Research mode / web search	Recherche web multi-étapes avec citations	Vous avez besoin d’une synthèse actuelle et sourcée au-delà des connaissances du modèle
Memory	Rappel inter-sessions de faits vous concernant / concernant votre travail	Vous voulez que Claude retienne des préférences et un contexte dans le temps
Skills	Procédures empaquetées et réutilisables que Claude peut invoquer	Une tâche multi-étapes reproductible que vous ou votre équipe exécutez souvent
Code execution / analysis tool	Exécute du code pour calculer, analyser des données, faire des graphiques	Arithmétique fiable, traitement de données, génération de graphiques
Claude Desktop	Application de bureau, prend en charge les connectors locaux	Flux de travail de bureau, accès aux fichiers/connectors locaux
Claude for Chrome	Extension de navigateur qui agit dans le navigateur	Aide en contexte sur des pages web (avec permission)
Applications mobiles	iOS/Android	Chat en déplacement, capture, voix
Claude Code	Agent terminal/IDE pour développeurs	Tâches d’ingénierie logicielle — escaladez vers les Developers
Connectors	Relie Claude à Drive, Gmail, Calendar, Slack, GitHub, etc.	Amener les données de vos propres outils dans un chat

Signal d’examen

« Le même contexte s’applique à chaque chat » → Project. « Itérer sur un livrable » → Artifact. « A besoin de faits actuels et sourcés » → research mode. « Arithmétique fiable sur un jeu de données » → analysis/code tool. « Construire une intégration / écrire un logiciel » → escaladez vers Claude Code / Developers.

3.2 Projects vs. a plain chat

Un Project regroupe un contexte réutilisable pour ne pas le recoller à chaque fois :

Instructions personnalisées — un brief persistant de niveau système (rôle, ton, formats par défaut, à faire/ne pas faire).
Fichiers de knowledge — des documents que chaque chat du Project peut exploiter.
Project memory — un contexte accumulé à travers les chats du Project.

Utilisez un chat simple pour les tâches ponctuelles. Utilisez un Project quand les mêmes instructions ou documents reviennent, quand une équipe a besoin d’une configuration partagée, ou quand vous voulez de la cohérence sur de nombreuses conversations. (Le détail de configuration relève de D5.)

3.3 Plan tiers (conceptual)

Vous n’avez pas besoin de mémoriser les prix, mais vous devez savoir à quoi sert chaque niveau.

Niveau	Pour qui	Débloque conceptuellement
Free	Usage individuel occasionnel	Chat de base, usage limité, accès à des modèles plus petits
Pro	Utilisateurs individuels avancés	Usage supérieur, Projects, plus d’accès aux modèles, research
Max	Utilisateurs individuels intensifs	Limites d’usage bien plus élevées, accès prioritaire
Team	Petites et moyennes organisations	Facturation centralisée, collaboration, espace partagé, contrôles admin
Enterprise	Grandes organisations	SSO, journaux d’audit, contrôles de rétention des données, contexte plus grand, gouvernance d’entreprise

La gouvernance suit le niveau

Les plans Enterprise et Team sont là où résident les contrôles organisationnels — SSO, journaux d’audit, paramètres de rétention, et la garantie commerciale que vos données ne sont pas utilisées pour entraîner les modèles. Cela se relie directement à D6.

3.4 The model lineup

Quatre modèles actuels, choisis selon le compromis coût / vitesse / qualité.

Modèle	Coût relatif	Vitesse relative	Idéal pour
Haiku 4.5	Le plus bas	La plus rapide	Tâches à fort volume, routinières, sensibles à la latence ; classification simple, brouillons rapides
Sonnet 5	Modéré	Rapide	Le choix par défaut au quotidien — meilleur équilibre vitesse/intelligence pour la plupart du travail métier
Opus 5	Élevé	Plus lent	Raisonnement complexe, analyse à enjeux élevés, travail agentique/de code le plus difficile
Fable 5.1	Le plus élevé	La plus lente	Le niveau le plus performant, pour les tâches les plus exigeantes (réflexion toujours active)

Règles empiriques :

Par défaut Sonnet pour le travail du savoir général.
Descendez à Haiku pour les tâches routinières, répétitives, à fort volume ou critiques en vitesse, afin d’économiser coût et temps.
Montez à Opus/Fable uniquement quand la tâche est réellement difficile ou à enjeux élevés et que la qualité supplémentaire vaut le coût et la latence.

Deux erreurs symétriques

Utiliser le modèle le plus cher pour tout gaspille argent et temps ; utiliser le modèle le moins cher pour un travail à enjeux élevés risque la qualité là où elle compte le plus. Les deux sont de mauvaises réponses d’examen. Faites correspondre le modèle aux enjeux.

3.5 Aligning model choice with stakes

Posez deux questions : Quelle est la difficulté du raisonnement ? et Quel est le coût d’une erreur ? Si les deux sont faibles, allez vers l’économique et le rapide. Si l’un des deux est élevé, montez d’un cran.

3.6 Context windows and memory

Une fenêtre de contexte est la quantité de texte (conversation + documents) que le modèle peut considérer à la fois. Les modèles actuels ont de très grandes fenêtres, mais elles ne sont pas infinies, et de très longs chats peuvent tout de même dériver ou perdre les détails antérieurs.

Trois outils pour gérer un contexte de longue durée :

Situation	Meilleur geste
Un chat s’est allongé et Claude perd les détails antérieurs ou dérive	Démarrez un nouveau chat avec un brief propre et consolidé
Vous ne voulez reporter que les conclusions	Demandez à Claude de résumer le fil, puis collez le résumé dans un nouveau chat
Le même contexte doit s’appliquer à de nombreux chats futurs	Persistez-le dans un Project (instructions personnalisées + knowledge)
Vous voulez que Claude retienne des préférences dans le temps	Utilisez Memory

Signal d’examen

« La conversation est très longue et les réponses dérivent / oublient » → démarrez un nouveau chat (éventuellement après avoir résumé). « Ce contexte revient dans de nombreux chats » → Project. Distinguez un report ponctuel (résumer → nouveau chat) d’un besoin permanent (Project / Memory).

3.7 Extended / adaptive thinking

Les modèles actuels peuvent réfléchir avant de répondre — travailler un problème en interne avant de produire la réponse finale. Sur les modèles d’aujourd’hui, c’est adaptatif : le modèle décide de la quantité de réflexion nécessaire, et vous pouvez activer la réflexion étendue pour les problèmes plus difficiles.

Pour le raisonnement multi-étapes, l’analyse complexe, la planification difficile, les compromis délicats — les tâches où une chaîne de raisonnement soignée améliore la réponse. Elle coûte plus de temps (et de tokens) mais améliore la qualité sur les problèmes réellement difficiles.

En tant qu’utilisateur métier, vous vivez la réflexion comme une option/un bouton dans l’interface, non comme un paramètre d’API. Faites-la correspondre à la difficulté de la tâche de la même manière que vous choisissez le modèle.

3.8 A selection workflow

Quel type de sortie ? Livrable à itérer → artifact. Données machine → sortie structurée. Faits actuels → research mode.
Le contexte revient-il ? Oui → Project. Non → chat simple.
Quelle difficulté / quels enjeux ? Routez le modèle : Haiku → Sonnet → Opus/Fable.
Raisonnement multi-étapes ? Activez la réflexion étendue.
Est-ce un logiciel / une intégration / un agent autonome ? → escaladez vers les Developers/Architects ; ce n’est pas une tâche de chat pour utilisateur métier.

3.9 Feature-to-need decision table

L’examen adore les énoncés qui décrivent un besoin en langage métier simple et demandent quelle fonctionnalité convient. Mémorisez la correspondance et son déclencheur en une ligne.

Le besoin dans l’énoncé…	Bonne fonctionnalité	Pourquoi (et le mauvais choix tentant)
« Le même contexte/ton/docs s’appliquent à de nombreux chats »	Project	Contexte partagé. Faux : coller à chaque fois ; Memory (personnelle, non curée).
« Exécuter cette procédure standard multi-étapes de façon répétée »	Skill	Procédure réutilisable. Faux : un Project (contient du contexte, pas des étapes).
« Itérer sur un document/livrable et garder les versions »	Artifact	Livrable persistant et versionné. Faux : chat en ligne.
« Besoin de faits actuels et sourcés au-delà des connaissances du modèle »	Research mode / web search	Synthèse sourcée. Faux : chat simple sur connaissances intégrées.
« Arithmétique fiable / graphiques sur un jeu de données »	Code / analysis tool	Exécute, n’estime pas. Faux : research mode ; chat simple.
« Retenir mes préférences entre les sessions »	Memory	Rappel personnel inter-sessions. Faux : un fichier de knowledge.
« Amener mes données Drive/Gmail/Slack dans le chat »	Connector	Atteint les données de vos outils. Faux : coller des exports à la main.
« Travailler avec des fichiers locaux / applications de bureau »	Claude Desktop	Accès aux connectors locaux. Faux : application mobile.
« M’aider sur la page web que je consulte »	Claude for Chrome	Assistant navigateur en page. Faux : Desktop.
« Capturer une idée / chat rapide en déplacement »	Application mobile	Surface nomade. Faux : Desktop.
« Construire un logiciel / une intégration non supervisée »	Escalader vers Claude Code / Developers	Au-delà du plafond de l’utilisateur métier.

Signal d’examen

Deux paires de fonctionnalités sont les confusions les plus testées : Project vs Skill (contexte vs procédure) et research mode vs code/analysis tool (faits web sourcés vs travail de données exécuté). Lisez l’énoncé pour « contexte récurrent » vs « étapes reproductibles », et « faits actuels sourcés » vs « nombres fiables sur un jeu de données ».

3.10 Surface selection across devices and clients

Les utilisateurs métier atteignent Claude via plusieurs clients ; le bon dépend de où vivent le travail et les données.

Client	Idéal pour	Note données / accès
claude.ai (web)	Chat général, Projects, artifacts, research	Données régies par votre niveau de plan
Claude Desktop	Fichiers locaux, connectors locaux, flux de bureau	Peut atteindre les ressources locales que vous accordez
Claude for Chrome	Agir sur la page web courante, aide en contexte	Agit dans le navigateur avec permission par site
Mobile (iOS/Android)	Capture, questions rapides, voix, en déplacement	Même gouvernance de compte/plan
Claude Code (terminal/IDE)	Ingénierie logicielle	Territoire développeur — escaladez

Même gouvernance, surface différente

Changer de client ne change pas la gouvernance de votre plan. Les règles sur les données confidentielles (D6) et la garantie de non-entraînement suivent le compte/plan, pas l’application que vous ouvrez.

3.11 Common misconceptions

Idée reçue	Réalité	Pourquoi cela compte à l’examen
« Utiliser le modèle le plus performant pour tout, par sécurité. »	Surdimensionne coût et latence sur le travail routinier.	Distracteur surdimensionné ; adaptez le modèle aux enjeux.
« Utiliser le modèle le moins cher pour économiser partout. »	Sous-dimensionne la qualité sur le travail difficile/à enjeux élevés.	Distracteur aveugle aux contraintes.
« Un Project et une Skill sont interchangeables. »	Project = contexte partagé ; Skill = procédure réutilisable.	La confusion de fonctionnalités la plus testée.
« Research mode sert à toute question factuelle. »	Il sert aux faits actuels et sourcés ; utilisez l’analysis tool pour données/maths.	Distracteur research vs analysis.
« Un modèle plus gros retient des conversations plus longues. »	Les longs chats dérivent quel que soit le niveau ; réinitialisez/résumez.	Distracteur du modèle-comme-correction-de-contexte.
« Memory et le knowledge d’un Project sont pareils. »	Memory = rappel personnel ; knowledge = docs partagés curés.	Item de périmètre personnel vs partagé.
« La réflexion étendue améliore toujours la réponse. »	Elle ajoute latence/coût pour peu de gain sur les tâches triviales.	Distracteur du paramètre-comme-correction.
« Un utilisateur métier peut construire l’intégration non supervisée dans le chat. »	L’automatisation sans humain par exécution s’escalade aux Developers.	Item de frontière d’escalade.

3.12 Scenario walkthrough – choosing tools for a market-entry study

Scénario. Une chargée de stratégie doit produire une recommandation d’entrée sur un marché. Le travail comporte trois parties : (1) une vue actuelle et sourcée d’un changement réglementaire de ce trimestre ; (2) un modèle financier fiable additionnant et comparant cinq scénarios d’un tableur ; (3) un brief soigné de 2 pages que l’équipe révisera plusieurs fois. La chargée exécute aussi cette étude pour un nouveau marché chaque mois. Un collègue suggère « utilise juste Opus pour tout dans un seul long chat ».

Trace de raisonnement d’expert.

Découper par besoin, pas par modèle. Trois besoins différents correspondent à trois surfaces différentes ; un seul long chat sur un modèle les confond et invite à la dérive. Rejet de « Opus pour tout dans un chat ».
Partie 1 – faits actuels sourcés → research mode avec vérification des citations (D2). Les connaissances intégrées peuvent être périmées, le chat simple est donc rejeté ici.
Partie 2 – arithmétique fiable sur un tableur → le code/analysis tool, qui exécute plutôt que d’estimer. Le research mode (faux : il sert aux faits web) et le chat simple (faux : l’arithmétique des LLM n’est pas fiable) sont rejetés.
Partie 3 – brief de 2 pages itéré → un artifact, qui persiste et versionne le livrable. Le chat en ligne est rejeté pour un document révisé de façon répétée.
Choix du modèle selon les enjeux. La synthèse/recommandation est à enjeux élevés et exigeante en raisonnement → montez à Opus (ou Fable) avec réflexion étendue pour cette étape, puis vérifiez les chiffres. Les parties routinières n’ont pas besoin du niveau supérieur.
Récurrent chaque mois → persistez les instructions, les critères et les emplacements des documents dans un Project pour que chaque mois démarre configuré ; si le rapport suit une procédure fixe, capturez-la en Skill.
Hygiène de contexte. Gardez les parties dans des chats focalisés ; si un chat de synthèse s’allonge et dérive, résumez et réinitialisez plutôt que de monter en gamme le modèle.

Décision correcte à l’examen : research mode pour la vue réglementaire sourcée, l’analysis tool pour le modèle financier, un artifact pour le brief itéré, un modèle de niveau supérieur + réflexion étendue uniquement pour la synthèse difficile, et un Project (plus une Skill) pour la configuration mensuelle récurrente. Pas un seul long chat Opus pour tout.

Pièges de l’examen dans ce domaine

Piège	Pourquoi c’est faux
« Utiliser Opus pour tout, par sécurité »	Surdimensionne coût et latence sur le travail routinier ; adaptez le modèle aux enjeux
« Utiliser Haiku pour l’analyse financière au niveau du conseil, pour économiser »	Sous-dimensionne la qualité là où les erreurs coûtent cher
« Recoller le même contexte dans chaque chat »	Le contexte récurrent appartient à un Project
« Garder un seul chat géant pour toujours »	Les longs chats dérivent et perdent des détails ; démarrez un nouveau chat, en résumant au besoin
« Utiliser research mode pour de l’arithmétique sur un jeu de données »	Traitement de données → analysis/code tool ; research mode sert à la synthèse web sourcée
« Construire soi-même l’intégration API en tant qu’utilisateur métier »	Intégrations/agents s’escaladent aux Developers/Architects
« Activer la réflexion étendue pour une réécriture d’une ligne »	Ajoute latence/coût sans bénéfice sur les tâches triviales
« Le plan Free convient aux besoins de gouvernance d’entreprise »	SSO, journaux d’audit et garanties de non-entraînement résident dans Team/Enterprise
« Un Project convient quand on a besoin d’une procédure reproductible »	Les procédures reproductibles sont des Skills ; les Projects contiennent du contexte partagé
« Research mode pour une arithmétique fiable sur un jeu de données »	Données/maths → analysis/code tool ; research mode sert aux faits web sourcés
« Passer à Claude Desktop change la gouvernance des données »	La gouvernance suit le compte/plan, pas l’application cliente
« Memory remplace les fichiers de knowledge curés d’un Project »	Memory est un rappel personnel ; les docs curés partagés appartiennent à un Project

Questions d’entraînement

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

Q1 · Une équipe marketing fait passer le même contexte de voix de marque et de produit dans des dizaines de chats chaque semaine. Quelle est la MEILLEURE façon de gérer cela ? (Sélectionnez une réponse)

A. Coller le contexte en tête de chaque nouveau chat. B. Créer un Project avec des instructions personnalisées et des fichiers de knowledge pour que chaque chat qu’il contient utilise le contexte automatiquement. C. Utiliser Memory pour le stocker et espérer qu’il soit rappelé. D. Utiliser le modèle le plus cher pour qu’il « retienne » mieux.

Réponse : B. Un contexte récurrent et partagé est exactement ce à quoi servent les Projects. Coller à chaque fois (A) est source d’erreurs et incohérent. Memory (C) sert aux préférences personnelles, pas à une base de knowledge partagée et curée. Le niveau de modèle (D) n’a rien à voir avec la persistance.

Q2 · Un utilisateur doit classer 5 000 courts messages de support en trois catégories aussi vite et aussi économiquement que possible. Quel modèle est le PLUS approprié ? (Sélectionnez une réponse)

A. Fable 5.1 B. Opus 5 C. Sonnet 5 D. Haiku 4.5

Réponse : D. Une classification à fort volume, de faible complexité et sensible à la latence est la tâche archétypale de Haiku — le plus rapide et le moins cher. Les niveaux supérieurs surdimensionnent coût et vitesse pour un travail simple et répétitif.

Q3 · Un CFO a besoin d’une analyse de scénarios financiers complexe et multi-étapes qui éclairera une décision du conseil. Quel choix convient le MIEUX ? (Sélectionnez une réponse)

A. Haiku 4.5 pour économiser, puisque ce ne sont que des chiffres. B. Opus 5 (ou Fable 5.1) avec réflexion étendue, puis vérification humaine des chiffres. C. Sonnet 5 avec réflexion étendue désactivée. D. Research mode seul.

Réponse : B. Un raisonnement difficile + des enjeux élevés justifient le niveau de modèle supérieur et la réflexion étendue, suivis d’une vérification humaine (D2). Haiku (A) sous-dimensionne la qualité sur un travail à enjeux élevés. Research mode seul (D) ne fait pas le raisonnement/l’analyse.

Q4 · Une conversation dure depuis deux heures ; Claude oublie maintenant les décisions antérieures et se contredit. Quelle est la MEILLEURE action ? (Sélectionnez une réponse)

A. Continuer ; la fenêtre de contexte est grande. B. Demander à Claude de résumer les décisions clés, puis démarrer un nouveau chat avec ce résumé comme brief. C. Passer à un modèle moins cher. D. Activer la réflexion étendue.

Réponse : B. Les longs chats qui dérivent gagnent à être réinitialisés : capturez les conclusions dans un résumé et continuez dans un contexte propre. Continuer (A) aggrave la dérive. Le niveau de modèle (C) et la réflexion (D) ne corrigent pas un contexte surchargé.

Q5 · Une équipe a besoin de SSO, de journaux d’audit et de la garantie que ses données ne sont pas utilisées pour l’entraînement des modèles. Quel niveau est requis ? (Sélectionnez une réponse)

A. Free B. Pro C. Max D. Team ou Enterprise

Réponse : D. Les contrôles de gouvernance organisationnelle — SSO, journaux d’audit, paramètres de rétention et garantie commerciale de non-entraînement — résident dans les plans Team/Enterprise. Les niveaux individuels (A–C) ne fournissent pas d’administration au niveau de l’organisation.

Q6 · Un utilisateur a besoin d’un résumé actuel et sourcé des changements réglementaires de ce trimestre dans son secteur. Quelle surface est la PLUS appropriée ? (Sélectionnez une réponse)

A. Un chat simple s’appuyant sur les connaissances intégrées du modèle. B. Research mode / web search, puis vérifier chaque citation. C. L’outil d’exécution de code. D. Un artifact.

Réponse : B. Des faits actuels et sourcés au-delà des connaissances du modèle appellent le research mode avec citations, que vous vérifiez ensuite (D2). Les connaissances intégrées (A) peuvent être périmées ou non ancrées. Le code tool (C) calcule, et les artifacts (D) sont un conteneur, pas une capacité de recherche.

Q7 · Quelles DEUX tâches sont le mieux servies par le code execution / analysis tool plutôt que par un chat simple ? (Sélectionnez deux réponses)

A. Additionner et croiser avec exactitude un tableur de 2 000 lignes. B. Générer un graphique à partir d’un jeu de données. C. Rédiger un e-mail d’excuses chaleureux. D. Faire un brainstorming de noms de campagne. E. Traduire un paragraphe.

Réponse : A et B. L’arithmétique fiable sur de nombreuses lignes et la génération de graphiques sont exactement ce que l’analysis/code tool fait bien — il exécute plutôt qu’il n’estime. Les e-mails, le brainstorming et la traduction sont des tâches de langage ordinaires qui n’ont pas besoin d’exécution de code.

Q8 · Un utilisateur métier veut construire un pipeline automatisé qui lit les e-mails entrants, en extrait des champs et met à jour une base de données sans humain dans la boucle. Quelle est la réponse CORRECTE ? (Sélectionnez une réponse)

A. Le faire lui-même dans claude.ai chat. B. Reconnaître qu’il s’agit d’une intégration API/agent et escalader vers les Developers/Architects. C. Utiliser un Project. D. Utiliser research mode.

Réponse : B. Une intégration autonome, de système à système, est une solution de développeur/architecte, pas une tâche de chat pour utilisateur métier — le rôle de l’Associate est de le reconnaître et d’escalader. Un Project (C) ou research mode (D) ne construit pas d’automatisation, et le faire dans le chat (A) n’est pas une vraie intégration.

Q9 · Pour une réécriture rapide d’une phrase en une ligne, quel réglage est le PLUS approprié ? (Sélectionnez une réponse)

A. Opus 5 avec réflexion étendue activée. B. Sonnet 5 (ou Haiku) avec réflexion étendue désactivée. C. Fable 5.1. D. Research mode.

Réponse : B. Une réécriture triviale n’a besoin ni d’un modèle de niveau supérieur ni de réflexion étendue ; un modèle rapide et modéré avec réflexion désactivée convient. Les options plus lourdes ajoutent coût et latence sans gain.

Q10 · Un utilisateur veut que Claude retienne son style d’écriture préféré et le contexte de projet en cours sur les sessions futures. Quelle fonctionnalité est conçue pour cela ? (Sélectionnez une réponse)

A. Artifacts B. Research mode C. Memory (et/ou un Project pour le contexte partagé) D. Le code tool

Réponse : C. Memory est faite pour le rappel inter-sessions de préférences et de contexte ; pour un contexte d’équipe partagé et curé, un Project est le pendant. Les artifacts (A), research (B) et le code tool (D) ne persistent pas de contexte personnel.

Q11 · Un utilisateur itère sur une proposition de cinq pages, la révisant de façon répétée. Quelle surface de sortie est la PLUS appropriée ? (Sélectionnez une réponse)

A. Des messages de chat en ligne. B. Un artifact, qui persiste et versionne le livrable à côté du chat. C. Un blob JSON. D. Research mode.

Réponse : B. Un livrable révisé de façon répétée appartient à un artifact, qui persiste et est facile à itérer, copier et télécharger. Le texte en ligne (A) est difficile à gérer sur plusieurs révisions ; le JSON (C) et research (D) ne conviennent pas à une proposition en prose.

Q12 · Quand la montée de Sonnet 5 à Opus 5 est-elle le PLUS justifiée ? (Sélectionnez une réponse)

A. Dès que l’utilisateur peut se le permettre. B. Quand la tâche implique un raisonnement réellement complexe ou que le coût d’une erreur est élevé. C. Pour tous les e-mails clients. D. Uniquement pour la traduction.

Réponse : B. Montez d’un cran quand la difficulté du raisonnement ou le coût d’une erreur est élevé — c’est là que la qualité supplémentaire mérite son coût et sa latence. La seule capacité à payer (A), les e-mails routiniers (C) et la traduction (D) ne justifient pas à eux seuls le niveau supérieur.

Q13 · Un utilisateur ne veut reporter que les conclusions finales d’un long chat dans une nouvelle conversation focalisée. Quelle est la MEILLEURE approche ? (Sélectionnez une réponse)

A. Copier toute la transcription de deux heures dans le nouveau chat. B. Demander à Claude de produire un résumé concis des conclusions, puis démarrer le nouveau chat avec ce résumé. C. Créer un Project juste pour ce cas ponctuel. D. Continuer à utiliser l’ancien chat pour toujours.

Réponse : B. Un report ponctuel se gère au mieux en résumant les conclusions et en repartant de zéro, gardant le nouveau contexte léger. Coller toute la transcription (A) réintroduit la surcharge. Un Project (C) sert au contexte récurrent, pas ponctuel ; garder l’ancien chat (D) prolonge la dérive.

Q14 · Une équipe a besoin À LA FOIS du même ton de marque et des mêmes docs de référence sur de nombreux chats ET d’une procédure fixe de rapport hebdomadaire exécutée de la même façon à chaque fois. Quelle combinaison est la MEILLEURE ? (Sélectionnez une réponse)

A. Un seul très long prompt réutilisé chaque semaine. B. Un Project pour le ton/docs partagés et une Skill pour la procédure de rapport reproductible. C. Memory seulement. D. Un compte distinct par tâche.

Réponse : B. Le contexte partagé est le rôle d’un Project ; une procédure multi-étapes reproductible est le rôle d’une Skill — les deux sont complémentaires. Un long prompt (A) et Memory (C) ne couvrent bien ni l’un ni l’autre ; des comptes distincts (D) fragmentent la configuration et la gouvernance.

Q15 · Une chargée doit additionner et croiser avec exactitude un tableur de ventes de 4 000 lignes ET obtenir une vue actuelle et sourcée d’une nouvelle réglementation. Quelles DEUX surfaces sont correctes, respectivement ? (Sélectionnez deux réponses)

A. Le code / analysis tool pour les maths du tableur. B. Research mode / web search pour la réglementation actuelle sourcée. C. Chat simple sur connaissances intégrées pour la réglementation. D. Research mode pour les totaux du tableur. E. Un artifact pour les maths du tableur.

Réponse : A et B. L’arithmétique fiable sur de nombreuses lignes est exécutée par l’analysis tool ; les faits actuels sourcés viennent du research mode avec vérification des citations. Les connaissances intégrées (C) peuvent être périmées ; research mode ne fait pas d’arithmétique (D) ; un artifact (E) est un conteneur, pas un moteur de calcul.

Q16 · Un utilisateur veut que Claude agisse sur la page web qu’il consulte actuellement pour l’aider à remplir un long formulaire. Quel client est le PLUS approprié ? (Sélectionnez une réponse)

A. L’application mobile. B. Claude for Chrome, qui peut agir sur la page courante avec permission par site. C. Claude Code. D. Research mode dans l’application web.

Réponse : B. L’aide en page sur le site courant est exactement ce que fournit l’extension Chrome, avec permission. L’application mobile (A) sert à la capture en déplacement ; Claude Code (C) est un outillage développeur ; research mode (D) fait de la synthèse web, pas de l’action sur la page ouverte.

Q17 · Un manager soutient que passer de l’application web à Claude Desktop leur permettra d’utiliser en toute sécurité des données confidentielles que la politique interdit actuellement. Qu’est-ce qui est CORRECT ? (Sélectionnez une réponse)

A. Correct ; Desktop est intrinsèquement plus sécurisé. B. Incorrect ; la gouvernance des données suit le compte/plan, pas l’application cliente, la politique s’applique donc toujours. C. Correct ; les applications locales contournent la politique. D. Correct s’ils suppriment les fichiers ensuite.

Réponse : B. Le plan/compte détermine la gouvernance et la garantie de non-entraînement ; changer de client ne change pas quelles données sont autorisées. Desktop n’est pas intrinsèquement plus conforme (A, C), et la suppression (D) ne change pas les permissions de la politique.

Q18 · Une réécriture d’une ligne d’objet est nécessaire des milliers de fois par jour au coût et à la latence les plus bas. Quel modèle ET quel réglage de réflexion est le PLUS cost-effective ? (Sélectionnez une réponse)

A. Opus 5 avec réflexion étendue activée. B. Haiku 4.5 avec réflexion étendue désactivée. C. Fable 5.1 avec réflexion activée. D. Sonnet 5 avec réflexion étendue activée.

Réponse : B. Une tâche triviale, à fort volume et sensible à la latence veut le modèle rapide le moins cher sans réflexion supplémentaire. Opus/Fable (A, C) surdimensionnent ; la réflexion étendue sur Sonnet (D) ajoute coût et latence sans gain de qualité ici.

Q19 · Un utilisateur veut que Claude retienne ses préférences personnelles de ton sur les sessions futures, tandis que son équipe veut un ensemble partagé et curé de docs de politique disponible pour tous. Quel appariement est CORRECT ? (Sélectionnez une réponse)

A. Memory pour les préférences personnelles ; les fichiers de knowledge d’un Project pour les docs partagés curés. B. Un Project pour les préférences personnelles ; Memory pour les docs partagés. C. Les deux dans Memory. D. Les deux dans un seul Project personnel.

Réponse : A. Memory gère le rappel personnel inter-sessions ; les documents partagés curés appartiennent au knowledge d’un Project. Les intervertir (B), mettre les docs partagés dans Memory personnelle (C) ou cacher des docs partagés dans un Project personnel (D) attribue mal le périmètre du besoin.

Q20 · Une analyse de scénarios au niveau du conseil est complexe et à enjeux élevés, mais un lot routinier de 5 000 étiquettes de tickets doit aussi être produit à bas coût. Quelle est la MEILLEURE stratégie de modèles ? (Sélectionnez une réponse)

A. Utiliser un seul modèle pour les deux, pour rester simple. B. Utiliser Opus/Fable avec réflexion étendue pour l’analyse du conseil, et Haiku pour l’étiquetage des tickets. C. Utiliser Haiku pour les deux pour économiser le plus. D. Utiliser Opus pour les deux, par sécurité.

Réponse : B. Faites correspondre chaque tâche à ses enjeux : niveau supérieur plus réflexion pour le raisonnement difficile à enjeux élevés, modèle rapide le moins cher pour l’étiquetage routinier à fort volume. Un seul modèle pour les deux (A) désadapte au moins une tâche ; Haiku pour l’analyse du conseil (C) sous-dimensionne ; Opus pour l’étiquetage (D) surdimensionne.

À retenir

Faites correspondre le besoin à la surface : Project (contexte récurrent), artifact (livrable itérable), research mode (faits sourcés), analysis/code tool (données & arithmétique), connectors (données de vos outils).
Escaladez logiciels, intégrations et agents autonomes vers les Developers/Architects.
Par défaut Sonnet ; descendez à Haiku pour le travail routinier/à fort volume/rapide ; montez à Opus/Fable pour le travail difficile ou à enjeux élevés.
Faites correspondre à la fois le modèle et la réflexion étendue à la difficulté de la tâche et aux enjeux — évitez de surdimensionner et de sous-dimensionner.
Gérez le contexte long : démarrez un nouveau chat (en résumant d’abord) quand un fil dérive ; persistez le contexte récurrent dans un Project ; utilisez Memory pour les préférences personnelles.
Les niveaux Enterprise/Team sont là où résident SSO, journaux d’audit, contrôles de rétention et garantie de non-entraînement.
Project vs Skill = contexte partagé vs procédure reproductible ; research mode vs analysis tool = faits web sourcés vs travail de données exécuté.
Choisissez le client selon où vivent le travail/les données (web, Desktop, Chrome, mobile) ; la gouvernance suit le compte/plan, pas l’application.
Memory est un rappel personnel ; les fichiers de knowledge d’un Project sont des documents partagés curés — ne confondez pas les deux.