--- term: 'API de LLM' seoTitle: 'API de LLM : tokens, streaming, tool calling, clés côté serveur' headline: "Qu'est-ce qu'une API de LLM ?" slug: api-de-llm category: ai-modern-stack shortDefinition: '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.' relatedTerms: - api - api-key-security - cloud-code-serverless-functions - retrieval-augmented-generation-rag contrastsWith: - ai-agent aboutTerms: - 'Tokens' - 'Chat Completions' - 'Streaming (SSE)' - 'Tool Calling' faq: - question: "Qu'est-ce qu'une API de LLM ?" answer: "Un endpoint HTTP qui permet à votre code d'envoyer un prompt à un grand modèle de langage hébergé et de recevoir du texte généré en retour — sans faire tourner vous-même le modèle, les GPU ni l'infrastructure d'inférence. Vous envoyez un corps JSON en POST, vous recevez un message de l'assistant accompagné du décompte des tokens consommés, et vous payez au token." - question: "Qu'est-ce qu'un token, et comment le pricing est-il calculé ?" answer: "Un token est un fragment de texte — environ quatre caractères, ou les trois quarts d'un mot en anglais. Vous payez par million de tokens, avec des tarifs distincts pour l'entrée (votre prompt) et la sortie (la réponse générée). La sortie coûte généralement plusieurs fois plus cher que l'entrée, car générer chaque token demande plus de calcul que d'en lire un." - question: "Qu'est-ce que la fenêtre de contexte ?" answer: "Le nombre maximal de tokens — entrée plus sortie — qu'un modèle peut prendre en compte dans une requête. Elle plafonne la quantité d'historique de conversation ou de document que vous pouvez inclure, et c'est un facteur de coût direct : chaque appel paie pour tout le contexte envoyé, si bien qu'un long historique ou un gros passage récupéré représente de l'argent dépensé à chaque requête." - question: "Qu'est-ce que le streaming, et pourquoi les interfaces de chat l'utilisent-elles ?" answer: "Activer un flag stream renvoie la réponse de façon incrémentale sous forme de Server-Sent Events plutôt qu'en un bloc final unique, si bien que l'interface affiche les tokens au fil de leur génération. Il existe pour la latence perçue : 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 des mots immédiatement au lieu d'un spinner pendant plusieurs secondes." - question: "Qu'est-ce que le function calling ou tool calling ?" answer: "Vous décrivez les outils disponibles — un nom et un schéma JSON — dans la requête ; le modèle, au lieu de répondre en prose, renvoie un appel JSON structuré qui nomme un outil et ses arguments. Votre code l'exécute et renvoie le résultat. Le modèle n'exécute jamais la fonction ; il se contente de la demander. C'est le mécanisme qui transforme une API de LLM en agent." - question: "Faut-il appeler une API de LLM depuis le client ou depuis le serveur ?" answer: "Depuis le serveur, toujours. Une clé d'API livrée dans un bundle navigateur ou un binaire mobile peut être volée après une simple inspection de l'onglet réseau ou une décompilation — et une clé de modèle volée, c'est un inconnu qui dépense votre budget de tokens. Chaque appel de LLM passe par votre backend, avec la clé dans la configuration côté serveur." - question: 'API de LLM ou auto-héberger un modèle ouvert ?' answer: "Une API, c'est zéro infrastructure, une facturation à l'appel et une mise en production dès aujourd'hui ; auto-héberger un modèle ouvert (avec des outils comme Ollama, vLLM ou llama.cpp) achète le contrôle total et la résidence des données, mais ne l'emporte sur le coût qu'à un volume très élevé et soutenu, une fois les GPU et l'exploitation comptés. La plupart des produits démarrent avec l'API et réexaminent la question à l'échelle." - question: 'Comment gérer les rate limits et les pannes ?' answer: "Les limites s'expriment en requêtes par minute et en tokens par minute ; sur un 429 ou un 5xx, réessayez avec un backoff exponentiel plus du jitter et respectez le header Retry-After s'il est présent. Ne réessayez pas les erreurs 4xx — une authentification invalide, une requête malformée ou un refus de politique de contenu échoueront à l'identique la seconde fois." codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Server-Sent Events — WHATWG HTML Living Standard' url: 'https://html.spec.whatwg.org/multipage/server-sent-events.html' - name: 'How to call an LLM API with function calling — Martin Fowler' url: 'https://martinfowler.com/articles/function-call-LLM.html' - name: 'RFC 8259 — JSON' url: 'https://datatracker.ietf.org/doc/html/rfc8259' - name: 'Ollama — run open models locally' url: 'https://github.com/ollama/ollama' - name: 'Large language model — Wikipedia' url: 'https://en.wikipedia.org/wiki/Large_language_model' cta: title: "Là où l'appel de LLM a sa place" text: "Placez l'appel au modèle dans une Cloud Function Back4app : clé côté serveur, plafonds de coût appliqués, résultat écrit en base de données et diffusé aux clients via Live Queries — jamais aucune clé sur l'appareil." linkText: 'Commencez gratuitement' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-14' translationKey: llm-api --- **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](/glossary/fr/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 | Question | Réponse | | --- | --- | | Ce que c'est | Un POST d'un tableau `messages` → une réponse de l'assistant + le décompte des tokens | | La facturation | Au token, entrée et sortie tarifées séparément ; la sortie coûte plus cher | | Le piège du stateless | La mémoire, c'est vous qui renvoyez les tours précédents — à chaque appel, chaque token payé | | La règle d'or | Ne l'appelez jamais depuis le client — la clé fuit ; passez par un proxy dans le backend | | La passerelle vers les agents | Le tool calling — le modèle demande une fonction, votre code l'exécute | ## Un vrai appel, côté serveur **JavaScript:** ```javascript // 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 // 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. ``` **Swift:** ```swift // 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. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The client calls YOUR function, never the LLM API directly val summary = ParseCloud.callFunction( "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é : ```text POST /v1/chat/completions Authorization: Bearer { "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é](/glossary/fr/rag/) est facturé *à nouveau* à chaque requête. La formule mensuelle approximative à intérioriser : ```text 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 | Paramètre | Contrôle | Conseil pratique | | --- | --- | --- | | `temperature` | Le caractère aléatoire (0–2) | 0 pour l'extraction/la classification ; ~0,7 pour la prose | | `top_p` | Nucleus sampling | Réglez celui-ci *ou* temperature — pas les deux | | `max_tokens` | Plafond de longueur de sortie | Définissez-le presque toujours — il borne le coût et la latence | | `stop` | Séquences d'arrêt | Terminez la génération sur un délimiteur que vous contrôlez | ## 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](https://html.spec.whatwg.org/multipage/server-sent-events.html) — 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](/glossary/fr/sse-vs-websockets-vs-polling/) 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](https://martinfowler.com/articles/function-call-LLM.html) 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 : | Mécanisme | Garantie | À utiliser pour | | --- | --- | --- | | Mode JSON | Du JSON valide — mais de n'importe quelle forme | Les besoins lâches du type « donne-moi du JSON » | | Structured Outputs | Correspond exactement à *votre* schéma | Extraction, classification, données typées | | Tool calling | Un appel à *votre* fonction | Faire des choses, pas seulement formater | Le tool calling est le mécanisme qui rend possible un [agent IA](/glossary/fr/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 | | API de LLM hébergée | Modèle ouvert auto-hébergé | | --- | --- | --- | | Infrastructure | Aucune — le fournisseur la fait tourner | GPU, stack de serving, exploitation | | Facturation | Au token, à l'usage | Capacité fixe, à vous de la remplir | | Délai de mise en production | Des minutes | Des jours à des semaines | | Résidence des données | Les conditions du fournisseur | Entièrement à vous | | Coût à volume faible/irrégulier | Le moins cher | Des GPU inactifs qui brûlent de l'argent | | Coût à volume extrême et soutenu | Peut dépasser l'auto-hébergement | Gagnant au-delà du seuil de rentabilité | 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](https://github.com/ollama/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](/glossary/fr/rate-limiting-api/) : 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](/glossary/fr/securite-des-cles-d-api/) 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](/glossary/fr/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 | Situation | Choisissez | | --- | --- | | Livrer une feature d'IA maintenant | Une API de LLM — zéro infrastructure | | Toute app exposée aux clients | L'API, appelée **côté serveur** — jamais depuis l'appareil | | Volume extrême et soutenu | Évaluez l'auto-hébergement (Ollama, vLLM) au-delà du seuil de rentabilité | | Résidence des données stricte | Auto-hébergez, ou choisissez un fournisseur offrant les bonnes garanties | | Tâche déterministe, fondée sur des règles | Peut-être aucun LLM — du code simple est moins cher et fiable | | Le modèle doit *faire* des choses | Tool calling → un [agent](/glossary/fr/agent-ia/) | ## 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](/glossary/fr/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](/glossary/fr/cloud-code-fonctions-serverless/), 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](/glossary/fr/securite-des-cles-d-api/) 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](/glossary/fr/live-queries-temps-reel/), 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é.