Faire fonctionner Claude dans un prototype est relativement simple. Construire une application Claude capable de fonctionner de manière fiable en production est un tout autre problème.

Un prompt qui fonctionne pendant les tests peut échouer avec des entrées inattendues. Un agent peut sélectionner le mauvais outil. Une session longue peut saturer sa context window. Une réponse en streaming peut être interrompue au milieu d’un tool_use. Une action automatisée peut également avoir des conséquences irréversibles si aucun contrôle humain n’a été prévu.

Le passage à la production consiste donc à construire un système fiable, contrôlable, mesurable et robuste, et pas simplement à écrire un meilleur prompt.

Ce chapitre présente les principales briques nécessaires pour construire une intégration Claude adaptée à la production.

Ce que nous allons apprendre

À travers cette série, nous allons étudier comment :

construire des prompts fiables avec system prompts, XML, few-shot examples et output constraints ;
utiliser extended thinking lorsqu’un problème nécessite davantage de raisonnement ;
définir des tools que Claude sélectionne correctement ;
implémenter la boucle tool_use → tool_result ;
gérer correctement les réponses en streaming ;
maîtriser la context window et le coût des longues sessions ;
choisir entre un workflow déterministe et un agent ;
construire une boucle agentique robuste ;
ajouter des contrôles Human-in-the-Loop (HITL) ;
gérer la mémoire d’un agent entre plusieurs sessions ;
utiliser Skills et MCP pour étendre les capacités d’un système ;
envoyer des images et PDF à Claude ;
traiter de gros volumes avec la Message Batches API.

Sommaire

1. Production-Grade Prompting : construire des prompts fiables

Un prompt qui fonctionne une fois n’est pas nécessairement un prompt adapté à la production.

Nous verrons comment diagnostiquer les principaux problèmes :

Wrong output shape → output constraint

Scope drift → system prompt

Structure inventée → few-shot examples

Confusion instructions/données → structuration XML

Nous verrons également pourquoi il est souvent préférable de diagnostiquer la cause d’un mauvais résultat plutôt que d’allonger continuellement le prompt.

Enfin, nous étudierons les structured outputs, qui permettent de déplacer certaines contraintes de sortie du prompt vers l’API grâce à un JSON Schema.

→ Lire : Production-Grade Prompting avec Claude

2. Extended Thinking : donner plus de raisonnement à Claude

Toutes les tâches ne nécessitent pas le même niveau de raisonnement.

Une classification ou une extraction simple n’a généralement pas besoin d’extended thinking. À l’inverse, une planification complexe ou un problème nécessitant plusieurs étapes de raisonnement peut en bénéficier.

Nous étudierons :

adaptive thinking ;
le paramètre effort ;
le coût des thinking tokens ;
les thinking blocks ;
leur utilisation avec les tools.

Une règle importante apparaît notamment dans les boucles utilisant des tools :

Les thinking blocks reçus doivent être renvoyés à l’API sans modification lorsqu’ils doivent être conservés dans la conversation.

→ Lire : Extended Thinking avec Claude

3. Tool Use : permettre à Claude d’utiliser des outils

Claude n’exécute pas directement vos fonctions.

Il demande à votre application d’utiliser un outil.

Le cycle fondamental est :

Application → Claude → tool_use → Application exécute le tool → tool_result → Claude → réponse

Nous étudierons :

name ;
description ;
input_schema ;
paramètres required et optional ;
sélection du bon tool ;
appels séquentiels ;
appels parallèles ;
gestion des erreurs.

Une attention particulière sera portée à la description des tools, car elle joue un rôle essentiel dans leur sélection.

→ Lire : Tool Use avec Claude — schemas, tool_use et tool_result

4. Streaming : gérer les réponses partielles

Le streaming permet d’afficher une réponse au fur et à mesure de sa génération.

Mais une réponse streamée est constituée d’événements :

message_start

→ content_block_start

→ content_block_delta

→ content_block_stop

→ message_delta

→ message_stop

L’application doit reconstruire correctement le message.

Une règle de production essentielle :

La fin du flux réseau ne signifie pas nécessairement que le message Claude est terminé.

Il faut attendre message_stop avant de considérer le tour comme complet et de l’enregistrer définitivement dans l’historique.

→ Lire : Streaming avec Claude — reconstruire et sécuriser les réponses

5. Context Engineering : maîtriser la context window

Chaque élément envoyé à Claude consomme des tokens :

system prompt ;
conversation ;
tools ;
résultats des tools ;
documents ;
réponses précédentes.

Dans une application agentique, les résultats des tools peuvent rapidement occuper une part importante de la context window.

Nous étudierons quatre stratégies principales :

Pruning

Supprimer les éléments devenus inutiles.

Compaction

Résumer une partie de l’historique afin d’en réduire le coût.

Clearing

Démarrer une nouvelle session lorsqu’un nouveau travail n’a plus besoin du contexte précédent.

Subagent handoffs

Déléguer une tâche isolée à un autre agent possédant sa propre context window.

Nous aborderons également :

prompt caching ;
token counting ;
gestion des gros résultats de tools ;
RAG et récupération de contexte.

→ Lire : Context Engineering avec Claude

6. Construire un agent Claude en production

Avant de construire un agent, il faut se poser une question fondamentale :

Avons-nous réellement besoin d’un agent ?

Un workflow est préférable lorsque les étapes peuvent être déterminées à l’avance.

Un agent devient pertinent lorsque nous connaissons :

l’objectif ;
les tools disponibles ;

mais que nous ne pouvons pas déterminer à l’avance le chemin exact permettant d’atteindre cet objectif.

Une boucle agentique comporte notamment :

les tools disponibles ;
un objectif ;
un contexte ;
une décision de Claude ;
l’exécution d’un tool ;
l’observation du résultat ;
une nouvelle décision ;
une condition d’arrêt.

→ Lire : Construire un agent Claude robuste

7. Human-in-the-Loop : garder le contrôle des actions sensibles

Un agent capable d’agir sur un système réel peut provoquer des effets importants.

Par exemple :

modifier un fichier de production ;
supprimer une donnée ;
envoyer un message ;
modifier un compte ;
déclencher une opération externe.

Pour certaines actions, l’agent ne doit donc pas disposer d’une autonomie totale.

On introduit alors un checkpoint :

Claude propose l’action

→ Human approval

→ Application exécute l’action

Le principe est particulièrement important pour les actions destructives ou difficilement réversibles.

→ Lire : Human-in-the-Loop et sécurité des agents Claude

8. Mémoire et état des agents

La context window ne doit pas être confondue avec une mémoire permanente.

Plusieurs architectures sont possibles :

Mémoire	Utilisation
In-context	Session courte
External storage	État persistant entre sessions
Summarized memory	Conversations longues
Stateless	Jobs indépendants

Le bon choix dépend surtout de la durée de vie de l’état dont l’agent a besoin.

Nous verrons également comment éviter d’injecter systématiquement l’intégralité des anciennes conversations dans chaque nouvelle requête.

→ Lire : Mémoire et persistance des agents Claude

9. Skills, CLAUDE.md et instructions réutilisables

Toutes les instructions ne doivent pas nécessairement vivre dans le system prompt.

Les Skills permettent de créer des ensembles d’instructions réutilisables chargés lorsqu’ils deviennent pertinents pour une tâche.

Nous comparerons notamment :

Skill (SKILL.md)

vs.

CLAUDE.md

vs.

instructions présentes directement dans le contexte

Cette distinction devient importante lorsque les systèmes Claude deviennent plus complexes.

→ Lire : Skills et instructions réutilisables avec Claude

10. MCP : connecter Claude à des systèmes externes

Lorsqu’un service possède déjà un MCP server, il n’est pas toujours nécessaire de développer manuellement toute l’intégration.

MCP fournit une couche standardisée permettant notamment de découvrir les tools proposés par un serveur.

Le principe reste compatible avec la logique du tool use :

MCP server expose des tools

→ MCP client les découvre

→ Claude sélectionne un tool

→ le tool est exécuté

→ le résultat revient à Claude

Nous verrons pourquoi MCP peut réduire le coût de développement d’intégrations, mais également pourquoi il faut contrôler les tools exposés et leur impact sur le contexte.

→ Lire : MCP — connecter Claude aux outils et systèmes externes

11. Images, PDF et multimodal

Claude peut également recevoir des contenus multimodaux.

Les images peuvent notamment être transmises :

inline en base64 ;
par référence ;
via la Files API.

Les PDF utilisent des blocs de type document.

Mais ces contenus consomment eux aussi la context window.

La conception d’une application multimodale doit donc tenir compte du poids des documents et images envoyés au modèle.

→ Lire : Images, PDF et Files API avec Claude

12. Message Batches API : traiter de gros volumes

Pour traiter plusieurs milliers d’éléments hors ligne, effectuer des milliers d’appels synchrones successifs n’est généralement pas le bon modèle.

La Message Batches API permet de soumettre un ensemble de requêtes pour un traitement asynchrone.

Elle est particulièrement adaptée à :

des traitements nocturnes ;
des classifications massives ;
des pipelines de données ;
des campagnes d’evals.

En revanche, elle n’est pas destinée à une interaction où un utilisateur attend immédiatement la réponse.

→ Lire : Message Batches API — traiter Claude à grande échelle

Les 8 principes à retenir

1. Diagnostiquer avant de modifier le prompt

Un mauvais résultat ne signifie pas automatiquement qu’il faut ajouter davantage d’instructions.

2. Adapter le raisonnement à la difficulté

L’extended thinking doit être utilisé lorsqu’il apporte réellement quelque chose à la tâche.

3. Un stream terminé n’est pas forcément un message terminé

Attendre message_stop avant de valider définitivement un tour.

4. La qualité d’un tool commence par son schema

Le nom, la description et l’input_schema déterminent la manière dont Claude comprend et sélectionne les tools.

5. La context window est un budget

Les messages, tools, documents et résultats de tools consomment tous ce budget.

6. Utiliser l’architecture la plus simple suffisante

API call → workflow → agent

Ne passer au niveau suivant que lorsque le précédent ne permet plus de résoudre correctement le problème.

7. Choisir explicitement la stratégie de mémoire

Tout conserver dans le contexte n’est pas une stratégie viable pour tous les systèmes.

8. Adapter le mode d’appel au workload

Temps réel, multimodal, assets réutilisés et traitement massif nécessitent des stratégies différentes.

De prototype Claude à système de production

Le point central de cette série est finalement simple :

une bonne application Claude n’est pas seulement un bon prompt.

C’est un système complet dans lequel le développeur contrôle :

Prompt → Model → Tools → Context → State → Validation → Human approval → Observability

Le modèle produit des décisions et des contenus, mais l’application reste responsable de l’exécution des tools, de la validation des données, de la gestion du contexte, de la mémoire et des actions ayant un impact sur le système réel.

C’est cette différence qui sépare une démonstration fonctionnelle d’une véritable intégration Claude adaptée à la production.

Explorer le phare info

📌 Contexte

📊 Les stratégies de greenwashing

1. Techniques utilisées par les multinationales

2. Exemples concrets de greenwashing

3. Les conséquences pour les consommateurs et l’environnement

⚠️ Décryptage des biais

🚀 Quelles solutions pour lutter contre le greenwashing ?

📝 Conclusion

Production-Grade Prompting, Agents & Tool Use avec Claude