SDK Python officiels : Anthropic, Mistral, Google

Les éditeurs de modèles publient un kit de développement (SDK) officiel. Pour un projet Python, ces SDK suffisent souvent à appeler un modèle, recevoir une réponse en flux continu et déclarer des outils, sans bibliothèque tierce. Ce comparatif reprend les trois SDK les plus demandés, d'après leurs dépôts et leurs documentations lus le 15/11/2026. Il ne compare ni la qualité des réponses ni les prix.

Le tableau d'ensemble

Anthropic

Le paquet anthropic s'installe avec pip install anthropic. Le dépôt anthropics/anthropic-sdk-python est sous Apache-2.0 ; sa page indique que les versions antérieures au passage à cette licence restent sous MIT. Le README lu ne décrit ni le streaming ni les outils : ces points sont dans la documentation de la plateforme.

Streaming. La documentation de streaming indique que, pour recevoir la réponse au fil de l'eau, on met "stream": true dans la requête, et que la réponse arrive par événements envoyés par le serveur. Le SDK Python offre plusieurs façons de streamer, en mode synchrone comme asynchrone.

Appel d'outils. Un outil est déclaré avec un name, une description et un input_schema, qui est un schéma JSON. Quand le modèle veut utiliser un outil, la réponse contient un bloc tool_use et une raison d'arrêt tool_use. L'application exécute l'outil et renvoie le résultat dans un bloc tool_result. La documentation décrit aussi un « tool runner » qui fait ces allers-retours à la place du développeur.

Mistral AI

Le paquet mistralai s'installe avec pip install mistralai. Le dépôt mistralai/client-python est sous Apache-2.0. Son README présente le SDK comme une bibliothèque cliente pour la plateforme Mistral AI.

Streaming. Le README donne l'exemple mistral.beta.conversations.start_stream(...), parcouru par une boucle for dans un bloc with. Il cite aussi les méthodes chat.stream, agents.stream et fim.stream.

Appel d'outils. La documentation de l'appel de fonctions, qui fait partie des outils (« Tool Calling ») de Mistral, décrit l'appel avec client.chat.complete(...), auquel on passe model, messages, tools et tool_choice. Chaque outil est un objet dont type vaut "function", avec sous function un name, une description et des parameters au format d'un schéma JSON de type objet.

Google (Gemini)

Le paquet google-genai s'installe avec pip install google-genai. Le dépôt googleapis/python-genai est sous Apache-2.0. Le SDK permet d'utiliser l'API Gemini Developer et la plateforme Gemini Enterprise Agent Platform.

Streaming. On appelle client.models.generate_content_stream(), qui renvoie des fragments à afficher au fur et à mesure. La version asynchrone est client.aio.models.generate_content_stream().

Appel de fonctions. Deux modes sont décrits. En mode automatique, une fonction Python est passée dans types.GenerateContentConfig(tools=[...]) à client.models.generate_content(), et le SDK l'appelle lui-même ; on peut désactiver ce comportement avec types.AutomaticFunctionCallingConfig(disable=True). En mode manuel, on déclare la fonction avec types.FunctionDeclaration, on l'encapsule dans types.Tool(function_declarations=[...]), on lit response.function_calls, puis on renvoie le résultat avec types.Part.from_function_response().

Ce que ces différences changent

Les trois SDK couvrent les mêmes besoins de base, mais chacun a sa forme. Trois conséquences pratiques :

1. Le schéma d'un outil n'a pas la même enveloppe : input_schema chez Anthropic, function.parameters chez Mistral, types.FunctionDeclaration chez Google. Un changement de fournisseur oblige à réécrire la description des outils.
2. Le streaming se consomme avec des objets différents, à traiter côté application.
3. La boucle d'outils est soit fournie par le SDK (Google en mode automatique, « tool runner » chez Anthropic), soit écrite par le développeur.

Pour limiter ces écarts, la solution la plus simple est une couche de votre code qui porte ces formats. Voir éviter le verrouillage fournisseur. Une autre voie existe : passer par une interface compatible OpenAI, décrite sur l'hôte API, changer de modèle sans réécrire son code ; elle a des limites qu'il faut lire avant de l'adopter.

Quel SDK prendre ?

Si le projet n'utilise qu'un fournisseur, son SDK officiel est le choix le plus direct : il suit ses fonctions et sa documentation fait foi. Si le projet doit comparer plusieurs modèles, une couche maison ou une bibliothèque comme celles du comparatif évite de tripler le code d'appel.

Pour la validation de la sortie, voir sorties structurées avec Pydantic. Pour décider s'il faut une bibliothèque du tout, lire framework ou appel direct à l'API.