Qu'est-ce qu'une API de LLM ?

Une API de LLM est un endpoint HTTP vers un modèle de langage hébergé : envoyez un prompt, recevez du texte généré, facturé au token. C’est une API ordinaire dotée de trois propriétés inhabituelles — elle est stateless (vous renvoyez toute la conversation à chaque appel), mesurée en tokens (entrée et sortie tarifées séparément) et non déterministe (le même prompt peut renvoyer des textes différents). Maîtrisez ces trois points, et le reste est la discipline opérationnelle que les pages les mieux classées escamotent : où l’appel a sa place, ce qu’il coûte et comment il échoue.

Points clés

Un vrai appel, côté serveur

// JavaScript — Cloud Code (cloud/main.js)
// The LLM call belongs server-side — the key never reaches the client
Parse.Cloud.define('summarize', async (req) => {
  const res = await Parse.Cloud.httpRequest({
    method: 'POST',
    url: 'https://api.llm-provider.example/v1/chat/completions',
    headers: {
      Authorization: `Bearer ${process.env.LLM_KEY}`, // server-side secret
      'Content-Type': 'application/json',
    },
    body: {
      model: 'default-chat',
      messages: [
        { role: 'system', content: 'Summarize in one sentence.' },
        { role: 'user', content: req.params.text },
      ],
      max_tokens: 80, // cost + latency guardrail, enforced by YOU
    },
  });
  return res.data.choices[0].message.content;
});

// Flutter / Dart — Back4app Flutter SDK
// The client calls YOUR function, never the LLM API directly
final summary = await ParseCloudFunction('summarize')
    .execute(parameters: {'text': longArticle});
print(summary.result);
// The model key stays on the server. If this app called the LLM API
// itself, the key would ship in the binary — one decompile from theft.

// iOS / Swift — Back4app Swift SDK
// The client calls YOUR function, never the LLM API directly
let summary: String = try await Cloud.run(
    name: "summarize", parameters: ["text": longArticle])
print(summary)
// The model key stays on the server. If this app called the LLM API
// itself, the key would ship in the IPA — one decompile from theft.

// Android / Kotlin — Back4app Android SDK
// The client calls YOUR function, never the LLM API directly
val summary = ParseCloud.callFunction<String>(
    "summarize", mapOf("text" to longArticle))
println(summary)
// The model key stays on the server. If this app called the LLM API
// itself, the key would ship in the APK — one decompile from theft.

Le format est portable — la plupart des fournisseurs acceptent le même format chat-completions, si bien que la requête et la réponse ci-dessous se lisent de la même façon quel que soit le modèle visé :

POST /v1/chat/completions            Authorization: Bearer <key>
{ "model": "default-chat",
  "messages": [
    { "role": "system", "content": "You are concise." },   ← définit le comportement
    { "role": "user",   "content": "Explain tokens." } ],   ← l'instruction
  "max_tokens": 200, "temperature": 0.7, "stream": false }

→ { "choices": [ { "message": { "role": "assistant",
                                "content": "A token is…" },
                   "finish_reason": "stop" } ],
    "usage": { "prompt_tokens": 24, "completion_tokens": 118,
               "total_tokens": 142 } }        ← ce qui vous est facturé

Les tokens sont la monnaie

Un token est un fragment de texte — environ quatre caractères, ou les trois quarts d’un mot anglais. Tout le coût d’une API de LLM se ramène à les compter, et deux faits surprennent. La sortie coûte plus cher que l’entrée — souvent plusieurs fois plus — parce que lire votre prompt est bon marché, alors que générer chaque token de la réponse est gourmand en calcul, une prédiction à la fois sur tout le vocabulaire. Et le contexte se paie à chaque appel : le modèle est stateless, donc la « mémoire », c’est vous qui renvoyez les tours précédents, et un long historique ou un gros passage récupéré est facturé à nouveau à chaque requête. La formule mensuelle approximative à intérioriser :

coût mensuel ≈ ( requêtes/jour
                 × (avg_input_tokens  × input_price_per_M  / 1_000_000
                  + avg_output_tokens × output_price_per_M / 1_000_000) )
               × 30

Les leviers qui la font bouger : plafonner max_tokens, réduire le contexte renvoyé,
choisir un modèle plus petit pour les tâches simples, et mettre en cache les préfixes de prompt réutilisés.

Les paramètres qui comptent

Streaming : pourquoi les interfaces de chat semblent rapides

Activez un flag stream et la réponse arrive de façon incrémentale sous forme de Server-Sent Events — des lignes data:, un fragment de tokens à la fois, terminées par un marqueur [DONE] — au lieu d’un bloc unique après plusieurs secondes. La raison tient à la perception : le délai jusqu’au premier token n’est qu’une fraction du délai jusqu’à la réponse complète, donc l’utilisateur voit les mots apparaître plutôt qu’un spinner tourner. C’est du texte unidirectionnel du serveur vers le client sur du HTTP simple, ce qui correspond exactement à la forme de SSE et explique précisément pourquoi le streaming de LLM l’utilise plutôt que les WebSockets. La conséquence côté backend : votre proxy doit laisser passer le flux de bout en bout — lire le flux d’événements du fournisseur et le relayer — plutôt que de mettre toute la réponse en tampon, ce qui ruinerait l’intérêt.

Tool calling et sortie structurée

Deux fonctionnalités transforment « du texte en entrée, du texte en sortie » en quelque chose de programmable. Le tool calling (appel d’outils) : vous décrivez les fonctions disponibles (nom + schéma JSON) dans la requête, et le modèle — au lieu de prose — renvoie un appel JSON structuré qui nomme un outil et ses arguments ; votre code l’exécute et renvoie le résultat (le pas-à-pas de Fowler est la référence claire). Le modèle n’exécute jamais la fonction ; il se contente de la demander. La sortie structurée, distincte du tool calling et souvent confondue avec lui, recouvre trois choses qu’il vaut la peine de distinguer :

Le tool calling est le mécanisme qui rend possible un agent IA — la même requête/réponse, exécutée en boucle jusqu’à ce que le modèle cesse de demander des outils.

API de LLM vs. auto-hébergement d’un modèle ouvert

La lecture honnête : une API l’emporte pour presque tout le monde, presque tout le temps — zéro infrastructure, démarrage instantané, et moins cher tant que le volume n’est pas réellement important et régulier. Auto-héberger un modèle ouvert (avec Ollama, vLLM ou llama.cpp) ne rentabilise son coût d’exploitation qu’au-delà d’un seuil élevé, ou quand la résidence des données est une exigence ferme. La plupart des produits démarrent sur l’API et ne réexaminent la question que si l’échelle l’impose un jour.

Fiabilité : les endpoints de LLM sont capricieux

Traitez l’API de LLM comme une dépendance distante lente, soumise à des limites de débit et qui échoue de temps en temps, parce que c’en est une. Les limites s’expriment en requêtes par minute et tokens par minute ; dépassez l’une ou l’autre et vous recevez un 429. La discipline est la même que celle qu’exige toute API soumise au rate limiting : sur un 429 ou un 5xx, réessayez avec un backoff exponentiel plus du jitter et respectez Retry-After ; sur un 4xx — authentification invalide, requête malformée, refus de politique de contenu — ne réessayez pas, car l’appel échouera à l’identique. Ajoutez des timeouts par requête (la génération peut se bloquer), et souvenez-vous qu’un appel non idempotent retenté coûte ses tokens deux fois. Rien de tout cela n’est propre aux LLM ; tout cela est ignoré par les tutoriels qui s’arrêtent au curl du cas nominal.

La règle que les tutoriels enterrent : ne l’appelez jamais depuis le client

Le fait opérationnel le plus important, et celui que les pages de glossaire omettent : l’appel à l’API de LLM a sa place sur votre serveur, jamais dans le navigateur ni dans l’app. Une clé d’API de modèle livrée au client peut être volée d’un simple coup d’œil sur l’onglet réseau ou en décompilant le binaire — et contrairement à une clé publiable qui fuit, une clé de modèle volée, c’est un inconnu avec votre budget de tokens et aucune autre limite que votre facture. Le pattern est la même discipline de proxy qu’exige tout service protégé par une clé secrète : le client appelle votre endpoint, votre backend garde la clé dans la configuration côté serveur et appelle le modèle, et la réponse revient par vous. Ce proxy est aussi l’endroit où vivent tous les autres contrôles de cet article — plafonds de coût, nouvelles tentatives, streaming, réduction des prompts — et c’est pourquoi la question « où va l’appel ? » n’a qu’une seule réponse.

Cas d’usage courants

• Résumé et extraction — transformer un long texte en données courtes et structurées, temperature: 0.
• Chat et assistants — des réponses en streaming sur un historique de conversation renvoyé.
• Classification et étiquetage — des Structured Outputs qui imposent votre schéma d’étiquettes.
• Réponses RAG — une génération ancrée dans un contexte récupéré, dont le coût se maîtrise en réduisant ce contexte.
• Actions agentiques — du tool calling en boucle, chaque outil étant une fonction backend soumise aux permissions.

Devriez-vous utiliser une API de LLM ? Matrice de décision

Limites et trade-offs

• Le non-déterminisme est la règle par défaut. Le même prompt varie d’une exécution à l’autre ; tout ce qui exige une répétabilité exacte nécessite temperature: 0 et, souvent, une validation de la sortie.
• Le coût grimpe avec les tokens, en silence. Un contexte généreux ou un max_tokens non borné rend coûteuse à grande échelle une feature bon marché — mesurez la consommation, ne la supposez pas.
• La latence se compte en secondes, pas en millisecondes. Les appels de LLM sont lents selon les standards du web ; concevez en conséquence avec du streaming, des patterns asynchrones et des états de chargement honnêtes.
• La dépendance est externe et soumise à des limites de débit. Les pannes et le throttling du fournisseur sont vos pannes ; nouvelles tentatives, solutions de repli et cache relèvent de la résilience, pas de la finition.
• Les sorties peuvent être fausses et assurées. L’API renvoie un texte fluide indépendamment de la vérité ; l’ancrage (RAG) et la validation sont ce qui vous permet de lui faire confiance.

Les API de LLM sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La question « où l’appel a-t-il sa place ? » se règle d’elle-même ici : dans une Cloud Function, exactement comme le montrent les onglets de code — le client appelle votre summarize, la fonction garde la clé du modèle dans la configuration côté serveur et appelle l’API de LLM, et la clé ne touche jamais l’appareil. Ce seul emplacement comble d’un coup toute la liste des lacunes : plafonds de coût (la fonction fixe max_tokens et choisit le modèle), nouvelles tentatives et backoff (dans la fonction, face à l’endpoint capricieux), et livraison de deux manières — renvoyez la réponse de façon synchrone pour une réponse unique, ou écrivez-la en base de données et laissez les clients la voir se remplir via Live Queries, ce qui revient à du streaming sans socket à construire vous-même. L’API de LLM cesse d’être un risque d’intégration et devient un appel côté serveur de plus, que votre backend sait déjà passer en toute sécurité.