Comment enchaîner des appels à l’API de Claude en un workflow
3 min de lecture
Quand tu construis quelque chose d’automatisé avec l’API de Claude, tu commences probablement par écrire un gros prompt qui tente d’accomplir toute la tâche en un seul appel, puis tu es frustré parce qu’une partie de la sortie n’est pas fiable.
Un workflow qui fait une chose par appel est plus facile à croire qu’un seul prompt qui essaie de tout faire à la fois.
Une tâche par appel, puis on compose
Découpe le travail comme tu le ferais dans du code ordinaire : un appel extrait ou classe, un deuxième agit sur ce résultat. Chaque appel est plus simple à réussir, et tu peux inspecter la sortie entre les étapes au lieu de déboguer un long prompt enchevêtré.
- 1
Identifie la sortie unique du premier appel
Décide exactement quel résultat structuré le premier appel doit produire, et rien de plus. Un travail plus étroit est plus facile à réussir de façon fiable.
- 2
Passe ce résultat en entrée du deuxième appel
Le prompt du deuxième appel doit s’appuyer sur la sortie réelle du premier, pas répéter depuis zéro l’entrée brute d’origine.
- 3
Donne à chaque appel ses propres critères de réussite clairs
Si la première étape échoue ou renvoie quelque chose d’inattendu, tu veux savoir quelle étape a cassé, sans avoir à démêler une seule réponse géante.
Conçois un workflow en deux étapes : le premier appel lit un ticket de support collé et extrait la vraie demande du client en un résumé d’une phrase plus une catégorie (facturation, bug, demande de fonctionnalité). Le deuxième appel prend ce résumé et cette catégorie et rédige une première réponse dans notre ton : direct, sans excuses sauf si nous étions réellement en tort. Montre-moi la forme de la requête pour chaque étape.
”
Dans Claude Tutorial
Découper le travail en petites étapes est une compétence Claude parmi d’autres
Découper une grande tâche en étapes à usage unique qui s’appuient les unes sur les autres se retrouve aussi dans les leçons de l’appli, pas seulement dans les workflows construits sur l’API.
Là où cela tourne souvent mal
L’erreur la plus courante est de sauter complètement la frontière entre les appels, en laissant le texte brut et non structuré du premier alimenter directement le deuxième. Demande au premier appel une forme précise et structurée (un court résumé, une catégorie, un petit ensemble de champs) plutôt que de la prose libre, pour que le deuxième ait quelque chose de fiable sur quoi s’appuyer.
Attention
Si tu ne peux pas énoncer clairement ce que le premier appel doit produire avant d’écrire son prompt, le workflow n’est probablement pas encore bien découpé. Corrige la frontière avant d’ajouter un deuxième appel.
Pour aller plus loin
- Connecter Claude à tes propres données et outils avec MCP pour ancrer une étape du workflow dans des données en direct plutôt que seulement dans ce qui est collé.
- Qu’est-ce que les artefacts de Claude ? Une introduction pratique pour appeler l’API de Claude depuis un prototype en cours d’exécution plutôt que depuis ton propre code backend.
- Faire une modification multi-fichiers avec Claude Code plutôt qu’un fichier à la fois pour la même habitude « décrire le résultat, vérifier le résultat » appliquée à l’édition de code plutôt qu’à la composition d’appels d’API.