Claude Code n'est pas l'API Claude : ce que MissionPilot m'a appris en les combinant

Claude Code est l'outil avec lequel j'écris ce blog. L'API Claude est ce que MissionPilot, l'outil qui score mes opportunités freelance repérées sur LinkedIn, Malt et Comet, appelle en production, à chaque fois qu'un utilisateur charge une nouvelle offre. Les deux utilisent le même modèle, mais résolvent deux problèmes complètement différents, et les confondre au moment de concevoir un produit mène à de mauvaises décisions d'architecture.

Deux contextes d'exécution, pas une nuance#

Claude Code tourne dans mon terminal, avec accès à mon système de fichiers, mes outils, ma configuration personnelle. L'API Claude tourne côté serveur de MissionPilot, appelée par du code que j'ai écrit, sans accès à rien d'autre que ce que ce code lui transmet explicitement dans la requête. La différence n'est pas de degré, elle est de nature : l'un est un environnement de développement augmenté par un agent, l'autre est un service qu'un produit consomme comme il consommerait n'importe quelle API tierce.

Ce que ça change pour le design du prompt#

	Claude Code	API dans MissionPilot
Qui écrit le prompt	Moi, au moment voulu, itérativement	Le code, à chaque requête, de façon identique
Contexte disponible	Fichiers du repo, historique de session	Uniquement ce que le code transmet explicitement
Tolérance à la variabilité	Élevée, je peux reformuler si le résultat ne convient pas	Faible, la sortie doit être exploitable automatiquement
Format de sortie attendu	Texte libre, code, discussion	Structuré, généralement du JSON validé par un schéma

La ligne la plus importante est la dernière. Un score de mission mal formaté casse silencieusement l'affichage si rien ne le détecte : demander une sortie structurée, avec un schéma explicite, n'est pas une option de confort côté API, c'est ce qui rend le résultat exploitable par du code sans supervision humaine à chaque appel.

Un appel API typique#

typescript

const response = await anthropic.messages.create({
  model: "claude-sonnet-4-5",
  max_tokens: 1024,
  system: "Tu scores une offre de mission freelance de 0 à 100 par rapport "
    + "à la stack de l'utilisateur. Réponds uniquement en JSON valide.",
  messages: [
    {
      role: "user",
      content: `Stack : ${userStack}\n\nOffre : ${missionDescription}`,
    },
  ],
});

Rien d'exotique dans cet appel. Ce qui fait la différence entre un prototype et un composant fiable de MissionPilot se joue ailleurs : dans la validation de la sortie, la gestion des erreurs de format, et le comportement du produit quand l'appel échoue ou renvoie quelque chose d'inattendu.

La sortie structurée n'est pas un détail#

Astuce

Ne jamais faire confiance à un JSON généré par un LLM sans le valider contre un schéma explicite avant de l'utiliser. Un modèle peut produire un JSON syntaxiquement correct mais sémantiquement incomplet (un champ manquant, un type inattendu), et ce n'est presque jamais un problème de prompt, c'est un problème d'absence de validation côté code.

Sur MissionPilot, chaque réponse passe par une validation de schéma avant d'atteindre l'interface. Un score hors des bornes attendues, un champ manquant, et la réponse est rejetée plutôt qu'affichée telle quelle. Ce n'est pas de la paranoïa, c'est la différence entre un appel API qui tourne une fois en test et un appel qui tourne tous les jours sans supervision.

Le coût, une contrainte de design dès le départ#

Une session Claude Code, je la paie une fois, en tokens d'usage personnel. Un appel API dans MissionPilot se répète à chaque offre scannée, pour chaque utilisateur. Le coût par appel devient une contrainte de conception dès le départ : limiter la taille du contexte transmis à ce qui est vraiment nécessaire au scoring, plutôt que d'envoyer l'intégralité d'une fiche de poste brute par confort d'implémentation.

Ce que ça généralise#

Attention

Construire un produit en supposant que l'API se comportera comme Claude Code en session interactive, avec possibilité de reformuler et d'itérer, mène à sous-estimer systématiquement le travail de validation et de gestion d'erreurs nécessaire côté serveur.

Le point commun entre Claude Code et l'API Claude s'arrête au modèle sous- jacent. Tout le reste, la gestion de l'incertitude, le format de sortie, le coût, la tolérance à l'erreur, dépend entièrement du contexte d'exécution. Concevoir un produit qui appelle l'API sans avoir pensé ces contraintes en amont, c'est traiter un service de production comme un terminal interactif, et ça se paie en bugs qui n'apparaissent qu'en production, jamais en test manuel.