Comment utiliser les API LLM : tokens, coûts, clés et votre première fonctionnalité IA

Une API LLM est un service web qui permet à votre application d'envoyer du texte à un grand modèle de langage, comme les modèles GPT d'OpenAI, Claude d'Anthropic ou Gemini de Google, et de récupérer sa réponse dans votre code. Vous vous inscrivez auprès du fournisseur, vous créez une clé d'API, et le serveur de votre application envoie des requêtes avec cette clé ; vous êtes facturé pour chaque requête selon le nombre de tokens (fragments de texte) en entrée et en sortie. Ajouter de l'IA à une application revient généralement à ça : une requête bien rédigée adressée au modèle d'un tiers, envoyée en toute sécurité depuis votre serveur.

Pourquoi c'est important quand on construit avec l'IA

Une application créée par IA contient deux IA différentes, et il est facile de les confondre :

1. L'IA qui construit votre application : l'agent du générateur, qui écrit le code.
2. L'IA à l'intérieur de votre application : une fonctionnalité utilisée par vos utilisateurs, comme un assistant de discussion, un bouton « résumer » ou un étiquetage automatique.

La seconde appelle une API LLM avec votre clé et facture votre compte chez le fournisseur. Comprendre les tokens, le contexte et la tarification vous permet de concevoir une fonctionnalité qui marche, qui ne divulgue pas votre clé et qui ne vous réserve pas de mauvaise surprise sur la facture.

Une analogie du quotidien : un excellent pigiste payé au mot

Imaginez une API LLM comme un rédacteur indépendant très compétent, que vous contactez par e-mail et que vous payez au mot, à la fois pour les mots que vous lui envoyez et pour ceux qu'il vous renvoie (et les mots de sortie coûtent plus cher).

• Il n'a aucune mémoire d'un e-mail à l'autre. Si vous voulez qu'il poursuive une conversation, vous recopiez les messages précédents dans chaque nouvel e-mail.
• Il ne peut lire qu'une quantité limitée à la fois. Cette limite est la fenêtre de contexte.
• Plus votre consigne est claire, meilleure et plus courte est la réponse, ce qui la rend aussi moins chère.

Les concepts essentiels

Tokens

Les modèles lisent et écrivent du texte en tokens. La documentation tarifaire d'Anthropic estime qu'un token représente environ 4 caractères, soit environ 0,75 mot anglais, en septembre 2026. Les différents modèles et langues ne découpent pas le texte de la même façon : prenez ce chiffre comme une indication approximative. Tout compte : vos instructions, le message de l'utilisateur, les documents que vous joignez, l'historique de la conversation et la réponse.

Entrée et sortie

Les tokens d'entrée sont ce que vous envoyez. Les tokens de sortie sont ce que le modèle écrit. Sur les pages tarifaires d'OpenAI, d'Anthropic et de Google, en septembre 2026, les tokens de sortie coûtent plusieurs fois plus cher que les tokens d'entrée pour un même modèle. La tarification de Gemini de Google précise également que le « raisonnement » interne d'un modèle compte comme sortie.

Fenêtre de contexte

Le nombre maximal de tokens qu'un modèle peut recevoir dans une seule requête, réponse comprise. Les modèles récents acceptent des entrées très longues : certains modèles actuels d'Anthropic, par exemple, acceptent jusqu'à un million de tokens. Mais les entrées longues coûtent plus cher et prennent plus de temps, alors n'envoyez que ce dont la tâche a besoin.

Requêtes sans état

Avec la plupart des API de type chat, chaque requête est indépendante par défaut. Pour qu'un chat « se souvienne », votre application renvoie les messages précédents à chaque nouveau message. C'est pourquoi une longue conversation coûte plus cher par message qu'une courte.

Le prompt système

Les instructions qui définissent le rôle et les règles du modèle pour chaque requête : « Tu résumes des tickets de support en trois puces. N'inclus jamais les adresses e-mail des clients. » Les utilisateurs ne le voient pas, mais il conditionne chaque réponse.

Streaming

Au lieu d'attendre la réponse complète, l'API peut envoyer le texte au fur et à mesure de sa génération, afin que les utilisateurs voient les mots apparaître immédiatement. Cela rend les interfaces de chat beaucoup plus rapides.

Comment fonctionne la tarification

En septembre 2026, vérifié sur les pages tarifaires des fournisseurs :

Certains fournisseurs proposent aussi de tester avant de payer : Anthropic offre aux nouveaux utilisateurs un petit crédit gratuit, et l'API Gemini de Google dispose d'un palier gratuit sur certains modèles, avec la réserve que les contenus envoyés dans ce palier peuvent servir à améliorer les produits de Google.

Les prix diffèrent beaucoup entre les modèles petits et rapides d'un fournisseur et ses plus grands modèles, et ils changent souvent. C'est pourquoi nous n'indiquons pas de tarifs ici. Une estimation simple pour n'importe quelle fonctionnalité est : (tokens d'entrée × prix d'entrée + tokens de sortie × prix de sortie) × nombre de requêtes par mois. Ajoutez ensuite une marge, et définissez une limite de dépense mensuelle dans le tableau de bord du fournisseur.

Exemple concret : un bouton « résumer ce ticket »

Une petite équipe de support souhaite un bouton qui transforme un long fil d'e-mails client en trois puces et une réponse suggérée.

1. Obtenez une clé. Créez un compte chez un fournisseur et générez une clé d'API. Définissez une limite de dépense mensuelle basse.
2. Stockez la clé comme secret sur votre serveur, sous un nom comme ANTHROPIC_API_KEY ou OPENAI_API_KEY, jamais dans le code de la page. Voir variables d'environnement et secrets.
3. Ajoutez une route serveur, POST /api/summarise, qui :
   • vérifie que la personne est connectée et qu'elle fait partie de l'équipe de support ;
   • charge le ticket depuis la base de données ;
   • envoie au fournisseur un prompt système (« Résume en trois puces, puis rédige une réponse polie ; n'invente pas de numéros de commande ») accompagné du texte du ticket ;
   • limite la longueur de la réponse avec un paramètre de nombre maximal de tokens de sortie ;
   • renvoie le résultat et enregistre le nombre de tokens utilisés.
4. Le bouton appelle votre route, et non le fournisseur, et affiche le résumé au fur et à mesure qu'il arrive.
5. Gérez les échecs. Si le fournisseur est lent ou renvoie une erreur, affichez « Impossible de résumer pour le moment » et laissez le ticket utilisable.
6. Mesurez. Après une semaine, regardez les journaux de tokens. Si l'essentiel du coût vient des longs fils d'e-mails, retirez l'historique cité avant l'envoi.

Remarquez ce qui manque : aucun entraînement de modèle, aucune infrastructure particulière. Une clé, une route serveur, un prompt bien écrit.

Termes clés

• Clé d'API : le secret qui identifie votre compte auprès du fournisseur. Quiconque la possède peut dépenser votre argent.
• Modèle : le LLM précis que vous appelez. Les fournisseurs proposent plusieurs tailles, à des prix et des vitesses différents.
• Température : un réglage qui détermine la variété des réponses. Plus elle est basse, plus les réponses sont prévisibles.
• Max tokens : une limite de longueur de réponse, qui limite aussi le coût.
• Limite de débit (rate limit) : le nombre de requêtes ou de tokens que votre compte peut utiliser par minute.
• Embeddings : des nombres qui représentent le sens d'un texte, utilisés pour la recherche dans vos propres documents.
• RAG (génération augmentée par récupération) : rechercher des passages pertinents dans vos données et les inclure dans le prompt, pour que le modèle réponde à partir de votre contenu.
• Utilisation d'outils / appel de fonctions : permettre au modèle de demander à votre application d'exécuter une fonction précise, comme « consulter le statut d'une commande ».

Erreurs courantes et idées reçues

• Mettre la clé dans le code frontend. L'erreur la plus coûteuse. Le code du navigateur est public. Appelez toujours depuis votre serveur. La liste de contrôle de sécurité pour les applications créées par IA couvre ce point avec les autres vérifications avant mise en ligne.
• Aucune limite de dépense ni limite par utilisateur. Un bug, une boucle ou un utilisateur abusif peut faire exploser les coûts en peu de temps. Définissez une limite chez le fournisseur et limitez les requêtes par utilisateur dans votre application.
• Tout envoyer à chaque fois. Les documents entiers et les historiques complets de discussion multiplient les tokens d'entrée. Coupez, résumez les anciens messages ou ne récupérez que les parties pertinentes.
• Faire aveuglément confiance à la sortie. Les modèles peuvent affirmer avec aplomb des choses fausses. Pour les faits, les prix, ou tout ce qui touche au juridique ou au médical, appuyez les réponses sur vos propres données et affichez les sources, ou faites vérifier par une personne.
• Laisser la saisie de l'utilisateur contourner vos règles. Les utilisateurs peuvent taper « ignore tes instructions ». Gardez les autorisations et les actions sensibles dans le code de votre serveur, et pas seulement dans le prompt.
• Commencer par le plus gros modèle. Essayez d'abord un modèle plus petit et moins cher ; ne passez à un modèle supérieur que si la qualité l'exige.
• Envoyer des données personnelles sans réfléchir. Vérifiez les conditions d'utilisation des données du fournisseur, en particulier sur les offres gratuites, et n'envoyez que ce dont la fonctionnalité a besoin.

Ce qu'il faut demander à votre générateur d'apps IA

Ajoute un bouton « Résumer » sur la page du ticket. Il appelle une route serveur qui utilise le secret OPENAI_API_KEY (jamais exposé au navigateur), vérifie que l'utilisateur est connecté, envoie le texte du ticket avec ce prompt système : […], limite la réponse à 300 tokens, affiche la réponse en streaming dans la page, et montre un message d'erreur convivial si l'appel échoue. Enregistre les tokens utilisés pour chaque requête, et limite chaque utilisateur à 30 résumés par heure.

Pour une expérience de chat complète, voir comment créer une application de chatbot IA ; pour d'autres idées, comment ajouter des fonctionnalités IA à votre application. Si les API en général vous sont nouvelles, commencez par qu'est-ce qu'une API.

Les API LLM dans les applications construites avec Mythex

Avec Mythex, l'IA intégrée à votre application utilise votre propre clé de fournisseur. Vous l'ajoutez comme secret de projet, ou via la carte de secrets que Mythex affiche dans le chat quand elle en a besoin, puis vous demandez à l'agent d'effectuer l'appel côté serveur. L'usage du fournisseur est facturé sur votre compte chez le fournisseur, et non sur vos crédits de construction Mythex. Mythex n'inclut pas de tokens pour les utilisateurs de votre application ni de produit de base de connaissances intégré ; les limites de débit et les contrôles de coût vous appartiennent et sont à concevoir et tester de votre côté. La recette de la documentation ajouter des fonctionnalités IA avec vos propres clés d'API propose un prompt de départ, et la page générateur d'apps IA indique par où commencer.

Questions