Toutes les tâches confiées à Claude ne nécessitent pas le même niveau de raisonnement.
Classifier un ticket parmi trois catégories est très différent de planifier la refactorisation d’une application, analyser plusieurs contraintes contradictoires ou résoudre un problème nécessitant plusieurs étapes.
Claude propose des mécanismes permettant d’accorder davantage de capacité au raisonnement lorsque la tâche le justifie.
Mais en production, la question n’est pas simplement :
Comment activer Extended Thinking ?
La véritable question est :
Quand le raisonnement supplémentaire améliore-t-il suffisamment le résultat pour justifier son coût et sa latence ?
C’est un arbitrage important pour la certification comme pour la conception d’applications Claude.
1. Qu’est-ce que l’Extended Thinking ?
L’extended thinking permet à Claude de consacrer davantage de raisonnement à un problème avant de produire sa réponse finale.
Conceptuellement, on peut représenter le traitement ainsi :
Prompt
↓
Claude
↓
Reasoning / Thinking
↓
Réponse
Sur une tâche simple, cette étape supplémentaire peut être inutile.
Sur une tâche complexe, elle peut permettre à Claude d’explorer davantage le problème avant de répondre.
L’objectif n’est donc pas d’utiliser le maximum de raisonnement possible.
L’objectif est d’utiliser le niveau de raisonnement adapté à la difficulté réelle de la tâche.
2. Toutes les tâches ne nécessitent pas Extended Thinking
Prenons trois exemples.
Cas 1 — Classification simple
Classify this support ticket as:
BILLING
TECHNICAL
ESCALATION
Le problème est :
- court ;
- bien défini ;
- peu ambigu ;
- doté d’un espace de sortie très limité.
Ajouter davantage de raisonnement apporte généralement peu de valeur.
Cas 2 — Extraction structurée
Extract from this invoice:
- invoice_number
- date
- total
- currency
Ici encore, la tâche est essentiellement mécanique.
Claude doit identifier et retourner des informations.
Le besoin principal concerne plutôt :
- la qualité des instructions ;
- la structure des données ;
- les
structured outputs.
Pas nécessairement davantage de raisonnement.
Cas 3 — Refactorisation complexe
Supposons maintenant que l’on demande :
Analyze this service and propose a migration plan that:
- preserves backward compatibility,
- removes the legacy authentication layer,
- introduces the new API,
- minimizes downtime,
- identifies affected dependencies,
- includes a rollback strategy.
Claude doit :
- comprendre l’architecture existante ;
- identifier les dépendances ;
- comparer plusieurs stratégies ;
- anticiper les risques ;
- ordonner les changements ;
- prévoir un rollback.
Le problème nécessite réellement plusieurs étapes de raisonnement.
C’est un bien meilleur candidat pour extended thinking.
3. La règle fondamentale : adapter le raisonnement à la tâche
On peut retenir cette heuristique :
| Tâche | Extended Thinking |
|---|---|
| Classification simple | Généralement inutile |
| Extraction | Généralement inutile |
| Reformattage | Généralement inutile |
| Lookup mécanique | Généralement inutile |
| Analyse complexe | Potentiellement utile |
| Planification multi-étapes | Utile |
| Architecture | Potentiellement utile |
| Refactorisation complexe | Utile |
| Problème nécessitant plusieurs contraintes | Utile |
Ce tableau n’est pas une règle absolue.
Il exprime surtout un principe :
Ne payez pas pour du raisonnement dont la tâche n’a pas besoin.
4. Pourquoi ne pas toujours utiliser le maximum de raisonnement ?
Parce qu’une application de production doit arbitrer entre plusieurs dimensions :
Qualité
↕
Coût
↕
Latence
Davantage de raisonnement peut améliorer certaines tâches complexes.
Mais il peut également :
- augmenter les tokens utilisés ;
- augmenter le coût ;
- augmenter le temps avant la réponse.
Pour une application traitant quelques problèmes complexes, ce compromis peut être acceptable.
Pour un pipeline classifiant des dizaines de milliers de tickets simples, il peut être inutilement coûteux.
5. Exemple : 50 000 classifications
Supposons un traitement nocturne de :
50 000 tickets support.
Chaque ticket doit être classifié dans :
BILLING
TECHNICAL
ESCALATION
La tentation pourrait être d’activer davantage de raisonnement afin d’obtenir « la meilleure qualité possible ».
Mais le problème est principalement un problème de classification.
Une meilleure approche consiste d’abord à travailler sur :
- le
system prompt; - les exemples ;
- les contraintes de sortie ;
- les
evals.
Puis à mesurer les résultats.
Si la classification atteint déjà le niveau de qualité requis, ajouter du raisonnement augmente principalement le coût et la latence.
6. Exemple inverse : planifier une refactorisation
Considérons maintenant une tâche de développement.
Analyze this repository.
We need to migrate the authentication system from the legacy API
to the new identity service.
Constraints:
- existing clients must continue working,
- deployment must remain zero-downtime,
- database migrations must be reversible,
- authentication failures must be observable,
- provide a rollback strategy.
Produce an implementation plan before modifying any code.
Cette fois, Claude doit raisonner sur plusieurs dimensions simultanément.
Il doit notamment :
- explorer les dépendances ;
- comprendre l’architecture ;
- identifier les risques ;
- ordonner les changements ;
- anticiper les migrations ;
- construire un plan de rollback.
C’est précisément le type de problème pour lequel davantage de raisonnement peut être pertinent.
7. Adaptive Thinking
Le module introduit également la notion d’adaptive thinking.
Avec les modèles concernés, Claude peut adapter son raisonnement à la complexité de la tâche.
Au lieu de définir systématiquement un budget de raisonnement rigide, l’idée est de laisser davantage de flexibilité au modèle.
Le développeur conserve néanmoins un levier permettant d’influencer la quantité de raisonnement :
effort.
8. Le paramètre effort
effort permet de contrôler le compromis entre profondeur de raisonnement, coût et latence.
Conceptuellement :
Effort faible
→ moins de raisonnement
→ coût/latence réduits
Effort élevé
→ davantage de raisonnement potentiel
→ coût/latence potentiellement supérieurs
Il ne faut donc pas penser :
« Quel est le meilleur niveau d’effort ? »
mais plutôt :
« Quel est le niveau d’effort minimum qui atteint mon objectif de qualité ? »
Cette nuance est essentielle.
9. Le rôle des evals
Comment déterminer le bon niveau ?
Pas par intuition.
Par des evals.
Supposons que vous compariez trois configurations :
Configuration A
Reasoning minimal
Configuration B
Reasoning intermédiaire
Configuration C
Reasoning élevé
Vous mesurez ensuite :
| Configuration | Qualité | Coût | Latence |
|---|---|---|---|
| A | 91 % | faible | faible |
| B | 96 % | moyen | moyen |
| C | 96,4 % | élevé | élevé |
Si votre objectif est de dépasser 95 %, la configuration B peut être préférable.
La configuration C est légèrement meilleure, mais son gain peut être insuffisant pour justifier son coût.
La bonne architecture n’est donc pas :
Maximum intelligence
mais :
Minimum capability
qui satisfait les evals
10. Model choice et reasoning sont deux leviers différents
Il faut également distinguer deux décisions.
Choix du modèle
Quel modèle utiliser ?
Niveau de raisonnement
Combien de raisonnement lui permettre ?
Ces deux dimensions peuvent être ajustées séparément.
Conceptuellement :
Model
+
Reasoning configuration
+
Prompt
=
System behavior
Il ne faut donc pas automatiquement changer de modèle lorsqu’une tâche échoue.
L’échec peut venir :
- du prompt ;
- du contexte ;
- du niveau de raisonnement ;
- des tools ;
- de l’architecture ;
- du modèle.
Les evals permettent de déterminer quel levier doit réellement être modifié.
11. Extended Thinking et Tool Use
La situation devient particulièrement importante lorsque Claude utilise des tools.
Rappelons la boucle fondamentale :
Application
↓
Claude
↓
tool_use
↓
Application exécute le tool
↓
tool_result
↓
Claude
↓
Réponse
Avec extended thinking, la réponse de Claude peut également contenir des blocs associés au raisonnement.
L’application doit alors préserver correctement les différents content blocks.
12. Les Thinking Blocks
Conceptuellement, un tour assistant peut contenir plusieurs types de blocs :
Assistant
├── thinking
├── text
└── tool_use
Il ne faut donc pas considérer une réponse Claude comme une simple chaîne de caractères.
La réponse est composée de content blocks typés.
Cette distinction devient essentielle dès que l’on implémente soi-même la boucle de tool use.
13. La règle critique : préserver les Thinking Blocks
Supposons que Claude produise :
Assistant turn[thinking block]
[tool_use] get_customer customer_id = 123
L’application exécute le tool :
get_customer(123)
puis retourne :
tool_result
Pour poursuivre correctement la conversation, l’application doit conserver les blocs nécessaires du tour assistant précédent.
Le module insiste sur une règle importante :
Les thinking blocks concernés doivent être renvoyés sans modification lors des tours de tool use.
Il ne faut donc pas :
- modifier leur contenu ;
- les reconstruire ;
- les résumer ;
- les filtrer arbitrairement.
14. Exemple d’une mauvaise implémentation
Imaginons ce code conceptuel :
assistant_blocks = response.content
clean_blocks = [
block
for block in assistant_blocks
if block.type != "thinking"
]
messages.append({
"role": "assistant",
"content": clean_blocks
})
Le développeur pense :
« Je n’ai pas besoin du thinking, donc je vais économiser du contexte. »
Mais il vient de modifier le tour assistant.
Dans une boucle de tool use nécessitant la conservation de ces blocs, cette optimisation casse le protocole attendu.
15. La bonne approche
Il faut préserver le contenu assistant requis tel qu’il a été retourné.
Conceptuellement :
messages.append({
"role": "assistant",
"content": response.content
})
Puis ajouter le tool_result correspondant :
messages.append({
"role": "user",
"content": [
{
"type": "tool_result",
"tool_use_id": tool_use_id,
"content": result
}
]
})
La conversation conserve ainsi correctement la structure du tour précédent.
16. Pourquoi cette règle existe-t-elle ?
Parce qu’une boucle utilisant des tools n’est pas constituée de requêtes indépendantes.
Claude raisonne, décide d’appeler un tool, reçoit l’observation produite par ce tool, puis poursuit.
Conceptuellement :
Reasoning
↓
Tool decision
↓
tool_use
↓
Observation
↓
tool_result
↓
Reasoning continues
Le tool_result fait donc partie de la continuité du raisonnement.
Modifier arbitrairement le tour précédent peut casser cette continuité.
17. Une autre règle : l’application reste responsable des tools
Extended thinking ne modifie pas la responsabilité de l’application.
Claude peut décider :
Je souhaite appeler delete_file.
Mais cela ne signifie pas que le fichier doit être supprimé.
La chaîne réelle reste :
Claude demande un tool
↓
Application examine la demande
↓
Validation / permissions / HITL
↓
Application décide d'exécuter ou non
↓
tool_result
C’est particulièrement important pour les actions sensibles.
Davantage de raisonnement ne signifie jamais davantage d’autorité.
18. Extended Thinking n’est pas une solution universelle
Supposons qu’un classifier retourne :
This appears to be a billing issue.
alors que l’application attend :
BILLING
Faut-il activer extended thinking ?
Non.
Le problème concerne la forme de sortie.
La bonne correction est plutôt :
output constraint
ou éventuellement :
structured output
Autre exemple :
Claude sélectionne régulièrement le mauvais tool entre :
search_knowledge_base
et :
get_cached_result
Faut-il augmenter le raisonnement ?
Pas nécessairement.
Le problème peut venir des descriptions des tools.
Il faut d’abord examiner le tool schema.
19. Diagnostiquer avant d’augmenter le raisonnement
Lorsque Claude échoue, posez-vous successivement ces questions :
Le prompt est-il suffisamment précis ?
↓
La sortie est-elle suffisamment contrainte ?
↓
Le contexte contient-il les bonnes informations ?
↓
Les tools sont-ils correctement décrits ?
↓
La tâche nécessite-t-elle réellement plus de raisonnement ?
↓
Le modèle choisi est-il suffisant ?
Cette logique évite une erreur coûteuse :
compenser un problème d’architecture avec davantage de tokens de raisonnement.
20. Reasoning et architecture agentique
Le raisonnement devient particulièrement utile lorsqu’un agent doit décider quoi faire ensuite.
Par exemple :
Objectif :
Diagnostiquer pourquoi le déploiement échoue.
Tools :
- read_logs
- inspect_deployment
- search_repository
- run_tests
Le chemin n’est pas nécessairement connu à l’avance.
Claude peut décider :
read_logs
↓
observe authentication error
↓
search_repository
↓
identify config
↓
inspect_deployment
↓
compare environment
↓
run_tests
Cette situation nécessite davantage de planification qu’une simple extraction.
Mais même ici, il faut se demander si un agent est réellement nécessaire.
Si le chemin est toujours :
read_logs
→ inspect_deployment
→ run_tests
→ generate_report
un workflow déterministe peut être préférable.
21. Le principe d’architecture à retenir
On retrouve une règle importante pour toute cette série :
Simple API call
↓
Workflow
↓
Agent
↓
Agent + deeper reasoning
Ne montez pas automatiquement au niveau supérieur.
Choisissez l’architecture la plus simple qui satisfait vos evals.
C’est généralement :
- moins coûteux ;
- plus facile à tester ;
- plus facile à sécuriser ;
- plus facile à observer ;
- plus facile à maintenir.
22. Ce qu’il faut retenir pour la certification
Principe 1 — Adapter le raisonnement à la tâche
Extended thinking est particulièrement pertinent pour les tâches complexes nécessitant plusieurs étapes de raisonnement ou de planification.
Il est souvent inutile pour les tâches mécaniques simples.
Principe 2 — Reasoning et model choice sont deux leviers distincts
Ne confondez pas :
Choisir un modèle
et :
Choisir le niveau de raisonnement
Ces décisions doivent être évaluées séparément.
Principe 3 — Mesurer avec des evals
La bonne configuration est celle qui satisfait vos objectifs mesurés de qualité, coût et latence.
Pas nécessairement celle qui utilise le maximum de capacité.
Principe 4 — Préserver les thinking blocks
Dans les boucles de tool use, les thinking blocks devant être conservés doivent être renvoyés sans modification.
C’est un point technique important.
Principe 5 — Reasoning ne donne aucune permission supplémentaire
Même si Claude raisonne correctement et demande un tool, l’application reste responsable de son exécution.
Claude propose
≠
Application autorise
Pièges fréquents à l’examen
Piège 1
« Plus la tâche est importante, plus il faut automatiquement augmenter le reasoning. »
Non.
La question est la complexité du raisonnement nécessaire, pas simplement l’importance métier de la tâche.
Piège 2
« Une classification instable doit être corrigée avec davantage de thinking. »
Pas nécessairement.
Il faut d’abord examiner :
- le prompt ;
- les exemples ;
- les contraintes de sortie ;
- les
evals.
Piège 3
« Je peux supprimer les thinking blocks de l’historique pendant une boucle tool use puisqu’ils ne sont pas utiles à mon application. »
Non lorsque le protocole exige leur conservation.
Ils doivent être préservés correctement.
Piège 4
« Si Claude décide qu’un tool doit être exécuté, l’application doit l’exécuter. »
Faux.
Claude demande l’appel.
L’application :
- valide ;
- contrôle les permissions ;
- applique éventuellement un
Human-in-the-Loop; - puis décide de l’exécution.
Piège 5
« Le maximum de reasoning donne toujours la meilleure architecture. »
Non.
En production, il faut arbitrer :
Qualité ↔ Coût ↔ Latence
et choisir le niveau suffisant pour atteindre les objectifs mesurés.
La règle à mémoriser
Pour la certification, retenez cette chaîne de décision :
La tâche échoue
↓
Diagnostiquer pourquoi
↓
Prompt ?
Output constraint ?
Context ?
Tool schema ?
↓
La tâche nécessite réellement
plus de raisonnement ?
↓
Oui
↓
Adapter le reasoning
↓
Mesurer avec des evals
L’extended thinking est donc un levier de raisonnement, et non une solution universelle à tous les problèmes rencontrés avec Claude.
Le bon système n’est pas celui qui fait toujours réfléchir Claude davantage.
C’est celui qui lui donne exactement les capacités nécessaires pour atteindre le niveau de qualité attendu, tout en maîtrisant le coût, la latence et la sécurité.
Article suivant
Tool Use avec Claude : schemas, tool_use, tool_result et boucle d’exécution
Nous entrerons dans l’une des parties les plus importantes de la certification : comment Claude demande l’utilisation d’un outil, comment l’application l’exécute, comment retourner correctement le tool_result, comment gérer plusieurs appels et pourquoi une mauvaise description de tool peut conduire Claude à sélectionner le mauvais outil.
