AWS Bedrock et Autres Providers Cloud

L’écosystème cloud de Mistral

Au-delà d’Azure et de Google Cloud, les modèles Mistral sont distribués sur plusieurs autres plateformes. Cette leçon traite AWS Bedrock en détail, parce que c’est le cas le plus fréquent et celui qui s’écarte le plus de ce que vous avez appris jusqu’ici, puis présente les intégrations avec Snowflake Cortex, IBM watsonx et Outscale.

AWS Bedrock

Amazon Bedrock est le service managé d’AWS pour les modèles de fondation. Il expose une API unifiée devant plusieurs fournisseurs — Anthropic, Meta, Mistral et d’autres — avec la facturation, la sécurité et la conformité AWS. Pour une équipe déjà outillée sur AWS, cela signifie que les modèles Mistral entrent dans le même périmètre IAM, les mêmes logs CloudWatch et la même facture que le reste de l’infrastructure.

Côté catalogue, Bedrock donne notamment accès aux modèles suivants. La liste exacte dépend de votre région et évolue au fil des mises à disposition : la page Model Access de la console fait foi.

Préparer l’accès

Quatre conditions doivent être réunies avant le premier appel :

1. Un compte AWS avec accès à une région supportant Bedrock
2. Un principal IAM avec les permissions bedrock:InvokeModel et bedrock:InvokeModelWithResponseStream
3. AWS CLI configuré et boto3 installé
4. Activer les modèles Mistral dans la console Bedrock (Model Access)

pip install boto3>=1.34.131
aws configure  # Renseignez vos identifiants

La deuxième permission est celle qu’on oublie : un principal qui ne dispose que de bedrock:InvokeModel fonctionnera en mode synchrone puis échouera dès le premier appel en streaming. Quant à l’étape 4, elle est de même nature que l’activation dans le Model Garden de Google : tant que le modèle n’est pas débloqué dans Model Access, aucun droit IAM ne suffira.

Appeler un modèle avec boto3

Voici la différence majeure avec Azure et Vertex : sur Bedrock, vous n’utilisez pas le SDK Mistral. Tout passe par le SDK AWS natif, boto3, via l’API converse() commune à tous les fournisseurs présents sur la plateforme.

import boto3
import json

client = boto3.client('bedrock-runtime', region_name='us-west-2')

response = client.converse(
    modelId="mistral.mistral-large-2512-v1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Quels sont les avantages d'une architecture serverless sur AWS ?"}]
        }
    ],
    inferenceConfig={
        "temperature": 0.3,
        "maxTokens": 1024
    }
)

texte = response["output"]["message"]["content"][0]["text"]
print(texte)

Le streaming suit la même logique, avec converse_stream() et une boucle sur les événements du flux. Notez qu’il faut tester la présence de la clé contentBlockDelta : le flux Bedrock transporte aussi des événements de début et de fin de bloc, qui ne contiennent aucun texte.

response = client.converse_stream(
    modelId="mistral.mistral-large-2512-v1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Décrivez l'architecture Lambda + API Gateway."}]
        }
    ],
    inferenceConfig={"temperature": 0.3, "maxTokens": 1024}
)

for event in response["stream"]:
    if "contentBlockDelta" in event:
        texte = event["contentBlockDelta"]["delta"].get("text", "")
        print(texte, end="", flush=True)

Si vous transposez un code écrit pour l’API Mistral directe, quatre écarts vous attendent. Le content n’est plus une chaîne mais un tableau d’objets {"text": "..."}. Le modelId suit le format AWS mistral.{modele}-v{version}:{numero} : contrairement aux alias -latest de l’API directe, vous pointez une version figée qu’il vous appartient de faire évoluer. Les paramètres d’inférence sont regroupés dans un objet inferenceConfig séparé au lieu d’être passés à plat. Enfin, aucun SDK Mistral n’intervient : les réponses sont des dictionnaires boto3, pas des modèles typés, d’où les accès par clés ci-dessus.

Snowflake Cortex

Snowflake intègre les modèles Mistral, dont Mistral Large, directement dans sa plateforme de données via Cortex AI. L’avantage principal tient en une phrase : vos données ne quittent jamais Snowflake. L’appel au modèle devient une fonction SQL, invoquée au milieu d’une requête, au plus près de la table à enrichir.

-- Utilisation directe dans une requête SQL
SELECT SNOWFLAKE.CORTEX.COMPLETE(
  'mistral-large',
  'Résumez ce rapport financier en trois points clés.'
) AS resume;

Imaginez une table de milliers de rapports : plutôt que d’exporter les contenus vers un script Python, d’appeler l’API puis de réinjecter les résultats, vous écrivez une requête qui produit directement la colonne de résumés. C’est l’option évidente lorsque votre pipeline de données vit déjà dans Snowflake et que la gouvernance interdit toute sortie de données.

IBM watsonx

IBM watsonx.ai propose les modèles Mistral, dont Mistral Large, dans son catalogue. L’accès se fait via l’API watsonx avec les identifiants IBM Cloud : vous instanciez un objet ModelInference en lui passant l’identifiant du modèle, vos identifiants et le projet cible. Remarquez l’URL régionale dans l’exemple — elle détermine où s’exécute l’inférence, un point à vérifier si vous êtes soumis à des exigences de localisation.

from ibm_watsonx_ai import Credentials
from ibm_watsonx_ai.foundation_models import ModelInference

model = ModelInference(
    model_id="mistralai/mistral-large",
    credentials=Credentials(url="https://eu-de.ml.cloud.ibm.com", api_key="..."),
    project_id="votre-projet-id"
)

response = model.generate_text("Expliquez le concept de data mesh.")

Outscale, le cloud souverain français

Outscale, cloud souverain français qualifié SecNumCloud, propose également les modèles Mistral. Pour une organisation du secteur public, de la défense ou de la santé, soumise à des contraintes réglementaires strictes, cette option garantit que les données comme le traitement restent en France. C’est le seul critère qui compte dans ces contextes : la qualification prime sur les considérations d’intégration ou de confort de développement.

Choisir le bon provider

Le choix ne se joue presque jamais sur les modèles eux-mêmes, puisqu’on retrouve largement les mêmes d’une plateforme à l’autre. Il se joue sur l’endroit où vivent vos données, votre contrat et vos obligations.

Un réflexe utile pour trancher : commencez sur l’API directe le temps de valider que le modèle répond à votre besoin, puis migrez vers le provider de votre écosystème quand le projet passe en production. Le code applicatif change peu, l’essentiel du travail portant sur l’authentification et le nommage des modèles.

À vérifier avant tout déploiement

Les identifiants de modèles des providers cloud sont versionnés et changent à chaque génération (mistral.mistral-large-2512-v1:0 sur Bedrock, par exemple). Avant de câbler un déploiement, vérifiez la valeur exacte dans la console du provider : c’est la source qui fait foi, et un identifiant périmé produit une erreur d’accès difficile à diagnostiquer.

Points clés à retenir

• AWS Bedrock utilise boto3 et l’API converse() — pas le SDK Mistral
• Le format des messages Bedrock diffère légèrement (contenu en tableau d’objets)
• Snowflake Cortex intègre Mistral directement dans les requêtes SQL
• IBM watsonx et Outscale offrent des alternatives pour des besoins spécifiques
• Choisissez votre provider en fonction de votre écosystème cloud existant et de vos contraintes réglementaires