Mistral sur Azure AI
Sur cette page
Corrigé le 3 novembre 2026 : l’exemple TypeScript passait
process.env.AZUREAI_API_KEYetprocess.env.AZUREAI_ENDPOINTdirectement àMistralAzure, dont les deux options sont obligatoires ; en mode strict, TypeScript 7 refusait de compiler (vérifié avec@mistralai/mistralai-azure2.1.0). Les variables sont désormais vérifiées avant la construction du client. Source : SDK@mistralai/mistralai-azure.
Pourquoi utiliser Mistral via Azure ?
La question se pose rarement pour des raisons techniques : l’API Mistral directe fonctionne parfaitement. Elle se pose pour des raisons contractuelles et organisationnelles. Une entreprise déjà ancrée dans l’écosystème Microsoft consomme un engagement Azure négocié, dispose de processus d’achat rodés, et n’a aucune envie d’ouvrir un nouveau contrat fournisseur pour quelques milliers d’euros de tokens.
Passer par Azure AI apporte donc une facturation consolidée sur votre contrat Azure existant, la conformité RGPD grâce aux régions européennes, l’intégration native avec les autres services Azure — Azure Functions, Cosmos DB, Azure ML — et le support entreprise Microsoft, avec les engagements de niveau de service qui l’accompagnent. Autrement dit : le même modèle, dans le périmètre de gouvernance que votre DSI a déjà validé.
Choisir entre serverless et GPU dédié
Azure propose deux approches, et le choix se joue sur la régularité de votre charge. Le mode pay-as-you-go, aussi appelé MaaS pour Model as a Service, expose une API serverless : aucun GPU à provisionner, vous payez uniquement les tokens consommés, et Azure gère seul la mise à l’échelle. C’est le mode recommandé pour la plupart des cas d’usage, en particulier tant que votre trafic est irrégulier ou encore imprévisible.
Les real-time endpoints répondent au besoin inverse. Vous choisissez le type et le nombre de GPU, l’infrastructure vous est dédiée, et la facturation se fait par heure de calcul — que le modèle travaille ou reste inactif. Une API interne sollicitée en continu par plusieurs milliers d’utilisateurs y trouve son compte ; un prototype consulté trois fois par jour y perdra beaucoup d’argent. Retenez la règle : ce mode est recommandé pour les charges de travail prévisibles et à haut débit.
Modèles disponibles sur Azure
La documentation Mistral cite notamment les modèles suivants sur Azure (liste relevée le 2 novembre 2026). Le catalogue évolue régulièrement : consultez la page officielle pour la liste à jour.
| Modèle | Positionnement |
|---|---|
| Mistral Medium 3.5 | Bon équilibre performance/coût |
| Mistral Large 3 (25.12) | Le modèle phare pour les tâches complexes |
| Mistral Small (25.06) | Rapide et économique |
| Codestral (25.01) | Spécialisé dans la génération de code |
| Ministral 3B (24.10) | Modèle compact pour les tâches légères |
| Document AI (OCR 4) | Extraction de texte et de structure dans les documents |
Obtenir vos identifiants
La récupération des identifiants passe par l’interface Azure et prend quelques minutes :
- Rendez-vous sur Microsoft Foundry
- Créez un projet ou sélectionnez un projet existant
- Déployez un modèle Mistral depuis le catalogue de modèles
- Récupérez votre endpoint et votre clé API depuis la page du déploiement
Ces deux valeurs se placent ensuite en variables d’environnement, exactement comme la clé Mistral directe. La différence tient à l’endpoint : chaque déploiement Azure possède le sien, il n’existe pas d’URL commune.
export AZUREAI_ENDPOINT="https://votre-endpoint.inference.ai.azure.com"
export AZUREAI_API_KEY="votre-cle-secrete-azure"
Appeler le modèle en Python
Le SDK Mistral fournit un client dédié à Azure, MistralAzure, inclus dans le package mistralai : vous lui passez l’URL de votre déploiement et sa clé, et le reste du code est identique à ce que vous écrivez sur l’API directe. Depuis la version 2.0 du SDK (mars 2026), il s’importe depuis mistralai.azure.client.
import os
from mistralai.azure.client import MistralAzure
client = MistralAzure(
server_url=os.environ["AZUREAI_ENDPOINT"],
api_key=os.environ["AZUREAI_API_KEY"],
)
response = client.chat.complete(
model="azureai", # Identifiant attendu par les endpoints Azure
messages=[
{"role": "user", "content": "Quels sont les avantages du cloud souverain en Europe ?"}
]
)
print(response.choices[0].message.content)
Le point le plus déroutant se trouve dans le paramètre model. On s’attend à y écrire mistral-large-latest ; il faut y mettre azureai. La raison est simple : le modèle est déjà déterminé par le déploiement que vous avez créé côté Azure, l’endpoint pointe vers lui et vers lui seul. Changer de modèle signifie donc changer d’endpoint, pas changer de chaîne dans le code.
Le streaming, lui, ne change pas d’un iota par rapport à l’API directe — même méthode, même niveau .data pour atteindre le contenu du chunk. C’est tout l’intérêt d’un SDK unifié : le code que vous avez écrit dans les leçons précédentes fonctionne tel quel.
stream = client.chat.stream(
model="azureai",
messages=[
{"role": "user", "content": "Décrivez l'architecture d'un data lake sur Azure."}
]
)
for chunk in stream:
content = chunk.data.choices[0].delta.content
if content:
print(content, end="", flush=True)
Le même appel en TypeScript
Côté TypeScript, le client Azure est publié dans un paquet à part, @mistralai/mistralai-azure, à installer avec npm add @mistralai/mistralai-azure. Ses options suivent la casse JavaScript : apiKey et endpoint, toutes deux obligatoires. D’où la vérification des variables d’environnement, sans laquelle le mode strict refuse de compiler, puisqu’une variable d’environnement peut être absente :
import { MistralAzure } from '@mistralai/mistralai-azure';
const apiKey = process.env.AZUREAI_API_KEY;
const endpoint = process.env.AZUREAI_ENDPOINT;
if (!apiKey || !endpoint) {
throw new Error('Définissez AZUREAI_API_KEY et AZUREAI_ENDPOINT.');
}
const client = new MistralAzure({ apiKey, endpoint });
const response = await client.chat.complete({
model: 'azureai',
messages: [
{ role: 'user', content: 'Comment sécuriser un Azure Key Vault ?' },
],
});
console.log(response.choices[0]?.message?.content);
Sources : Mistral sur Azure (documentation Mistral) · SDK TypeScript
@mistralai/mistralai-azure
Exploiter le reste de la plateforme
Une fois l’appel fonctionnel, tirez parti des services que vous payez déjà. Stockez vos clés dans Azure Key Vault plutôt que dans des variables d’environnement : la rotation devient une opération d’administration, et non un redéploiement. Activez les logs de diagnostic sur votre endpoint pour surveiller la latence et les erreurs, seule façon de distinguer une lenteur du modèle d’une lenteur de votre code. Choisissez une région européenne, West Europe ou France Central, pour rester conforme au RGPD — c’est souvent la raison même pour laquelle on passe par Azure. Enfin, configurez des alertes Azure Monitor sur la consommation de tokens : une boucle mal fermée dans un job nocturne se voit sur la facture bien plus tard que sur une alerte.
Points clés à retenir
- Azure AI propose Mistral en mode serverless (MaaS) ou GPU dédié
- Le modèle est identifié par
"azureai"dans les appels API - Le client
MistralAzureprend l’endpoint viaserver_url(Python,mistralai.azure.client) ouendpoint(TypeScript,@mistralai/mistralai-azure) - L’intégration avec l’écosystème Azure (Key Vault, Monitor, Functions) est un atout majeur pour les entreprises
- Choisissez une région européenne pour rester conforme au RGPD