Premier Appel API en Python — API Mistral — Démarrage Rapide

Votre premier échange avec un modèle Mistral

Le SDK est installé, la clé API est en place : il est temps d’envoyer une vraie requête et, surtout, de comprendre ce qui revient. Beaucoup de développeurs s’arrêtent à la première ligne de la réponse et ignorent le reste de l’objet retourné ; c’est dommage, car c’est précisément dans ce reste que se trouvent le suivi des coûts et le diagnostic des réponses tronquées. Nous allons donc partir du code minimal et remonter jusqu’à la structure complète.

Initialiser le client

Le client est le point d’entrée de toutes vos interactions avec l’API :

import os
from mistralai import Mistral

client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])

Il prend en charge les connexions HTTP, les retries en cas d’erreur réseau et la sérialisation des requêtes. Instanciez-le une seule fois dans votre application, au démarrage : recréer un client à chaque appel vous ferait payer inutilement l’établissement de la connexion, et c’est une des causes les plus discrètes de latence excessive.

Envoyer une requête avec chat.complete()

La méthode chat.complete() est celle que vous emploierez le plus souvent. Elle transmet vos messages et attend la réponse complète du modèle avant de rendre la main :

response = client.chat.complete(
    model="mistral-small-latest",
    messages=[
        {
            "role": "user",
            "content": "Expliquez-moi le concept de tokenisation en trois phrases."
        }
    ]
)

print(response.choices[0].message.content)

Deux paramètres suffisent ici. model désigne l’identifiant du modèle appelé : mistral-small-latest pointe toujours vers la dernière version de Mistral Small, ce qui en fait le choix naturel pour débuter puisqu’il est rapide et économique. messages attend une liste de messages structurés, chacun composé d’un role — system, user ou assistant — et d’un content qui porte le texte. Cette structure paraît lourde pour une question unique ; elle prend tout son sens dès la leçon sur les conversations multi-tour.

Lire l’objet retourné

L’objet response contient bien davantage que le texte généré :

# Le texte de la réponse
texte = response.choices[0].message.content

# Le rôle (toujours "assistant" pour une réponse)
role = response.choices[0].message.role

# La raison d'arrêt
fin = response.choices[0].finish_reason  # "stop", "length", etc.

# Les statistiques de tokens
tokens_entree = response.usage.prompt_tokens
tokens_sortie = response.usage.completion_tokens
tokens_total = response.usage.total_tokens

print(f"Réponse ({tokens_sortie} tokens) : {texte}")
print(f"Tokens totaux consommés : {tokens_total}")

Le champ usage mérite votre attention dès le premier jour : en le journalisant à chaque appel, vous saurez exactement quelle fonctionnalité de votre application consomme votre budget, sans avoir à faire de la rétro-ingénierie sur la facture en fin de mois.

Quant à finish_reason, il indique pourquoi le modèle s’est arrêté et prend l’une de ces valeurs :

stop : le modèle a terminé naturellement sa réponse
length : la réponse a été coupée car elle a atteint max_tokens
model_length : le contexte total (entrée + sortie) a atteint la limite du modèle

Une réponse qui se termine au milieu d’une phrase n’est donc pas un bug du modèle : c’est un finish_reason à length que personne n’a lu. Vérifiez-le systématiquement avant de conclure à un problème de qualité.

Ajuster le comportement du modèle

Trois paramètres supplémentaires permettent d’orienter la génération :

response = client.chat.complete(
    model="mistral-large-latest",
    messages=[
        {
            "role": "user",
            "content": "Proposez trois noms pour une startup d'IA éducative."
        }
    ],
    temperature=0.7,
    max_tokens=500,
    top_p=0.95,
)

La temperature règle le degré de liberté du modèle. À 0.0, les réponses sont déterministes : le même prompt produit toujours le même texte, ce que vous voulez pour de l’extraction ou de la classification. Entre 0.3 et 0.5, vous obtenez un bon équilibre pour des tâches factuelles. Entre 0.7 et 1.0, les réponses deviennent plus créatives et variées — c’est la plage retenue dans l’exemple ci-dessus, puisqu’on demande des propositions de noms et que trois fois la même idée n’aurait aucun intérêt. Au-delà de 1.0, la génération devient très aléatoire et n’a que rarement une utilité pratique.

max_tokens plafonne la longueur de la réponse, ce qui sert autant à contrôler les coûts qu’à garder des sorties exploitables ; souvenez-vous simplement que si le modèle est coupé, finish_reason vaudra "length". top_p agit sur la diversité par un autre mécanisme : il filtre les tokens les moins probables. Une valeur de 0.95 signifie que le modèle ne considère que les tokens représentant 95 % de la probabilité cumulée.

Un appel prêt pour la production

En conditions réelles, le réseau tombe, la clé expire, le quota se remplit. Encadrez donc systématiquement vos appels :

import os
from mistralai import Mistral

client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])

try:
    response = client.chat.complete(
        model="mistral-small-latest",
        messages=[
            {"role": "user", "content": "Quelle est la capitale de la France ?"}
        ],
        max_tokens=100,
    )

    texte = response.choices[0].message.content
    print(f"Réponse : {texte}")
    print(f"Tokens utilisés : {response.usage.total_tokens}")

except Exception as e:
    print(f"Erreur lors de l'appel API : {e}")

Reprenez ce squelette pour vos propres essais en remplaçant simplement le contenu du message : c’est le point de départ de tout ce qui suit dans ce cours.

Points clés à retenir

client.chat.complete() est la méthode principale pour interagir avec les modèles
La réponse se trouve dans response.choices[0].message.content
response.usage vous indique le nombre de tokens consommés (utile pour le suivi des coûts)
temperature contrôle la créativité, max_tokens limite la longueur
Utilisez mistral-small-latest pour commencer : rapide, économique, et performant