Un outil OpenAI que Mistral refusait : le « strict: null » du SDK

En bref : Function.from_openai de mistral-common rejetait toute définition d'outil contenant "strict": null. C'est pourtant ce que le SDK OpenAI produit par défaut quand on sérialise un outil. Mon correctif (PR #396) a été fusionné par les mainteneurs de Mistral AI le 21 octobre 2026. Il sera dans la prochaine version publiée après la 1.12.0. En attendant, il existe un contournement d'une ligne, décrit plus bas.

Le symptôme

Vous migrez des agents d’OpenAI vers Mistral, ou vous exposez une passerelle compatible OpenAI devant des modèles Mistral. Vos outils sont décrits avec les types du SDK OpenAI, puis convertis par mistral-common :

from openai.types.shared import FunctionDefinition
from mistral_common.protocol.instruct.tool_calls import Function

outil = FunctionDefinition(name="get_weather", parameters={"type": "object"})
Function.from_openai(outil.model_dump())

Résultat sur mistral-common 1.12.0 :

pydantic_core._pydantic_core.ValidationError: 1 validation error for Function
strict
  Input should be a valid boolean [type=bool_type, input_value=None, input_type=NoneType]

L’outil est pourtant valide. Le problème touche aussi Tool.from_openai et ChatCompletionRequest.from_openai(tools=...), qui passent par la même fonction.

La cause

Dans le schéma OpenAI, strict est optionnel et nullable. Le SDK OpenAI le sérialise donc à None quand on ne le renseigne pas :

{'name': 'get_weather', 'description': None, 'parameters': {'type': 'object'}, 'strict': None}

Function.from_openai remplaçait déjà les None de parameters et de description par des valeurs par défaut, mais pas celui de strict. Côté Mistral, strict est un booléen qui vaut False par défaut. Pydantic refusait donc None.

C’est un bug silencieux d’intégration : chaque bibliothèque a raison prise isolément, et l’erreur n’apparaît qu’à la jonction des deux.

Le correctif

Deux lignes dans Function.from_openai : si strict vaut None, on retire le champ, et le modèle reprend sa valeur par défaut (False).

if filtered.get("strict") is None:
    filtered.pop("strict", None)

Aucun changement pour True ou False. Deux tests couvrent Function.from_openai et Tool.from_openai avec "strict": None. La suite complète passe (1 294 tests), ainsi que ruff et mypy.

Chronologie :

issue #393 le 20 octobre (reproduction minimale) ;
PR #396 le même jour ;
fusion par les mainteneurs le 21 octobre.

Si vous êtes sur la 1.12.0 aujourd’hui

Tant que la nouvelle version n’est pas publiée, sérialisez vos outils sans les champs nuls :

Function.from_openai(outil.model_dump(exclude_none=True))

Si vos outils arrivent en JSON brut (par exemple dans une passerelle), retirez strict quand il vaut null avant la conversion.

Un deuxième signalement, corrigé autrement par Mistral

Le même jour, j’ai signalé une incohérence dans les tokenizers (issue #395). Tekkenizer.decode acceptait encore les anciennes politiques de jetons spéciaux en entier (0, 1, 2), mais id_to_byte_piece les rejetait.

J’avais proposé d’aligner id_to_byte_piece sur decode. Les mainteneurs ont reconnu le bug et choisi l'inverse : ils ont supprimé la compatibilité avec les entiers partout (PR #402, 21 octobre). C'est leur décision de conception, et elle est cohérente.

Conséquence pratique : si votre code appelle decode(..., special_token_policy=1), il échouera à la prochaine version. Passez dès maintenant à l'énumération, ou à sa valeur texte :

from mistral_common.tokens.tokenizers.base import SpecialTokenPolicy
tokenizer.decode(tokens, special_token_policy=SpecialTokenPolicy.KEEP)  # ou "keep"

À retenir

Un outil sérialisé par le SDK OpenAI contient "strict": None. mistral-common 1.12.0 le rejette, la prochaine version l'acceptera.
Contournement immédiat : model_dump(exclude_none=True).
Les politiques de jetons spéciaux en entier (0, 1, 2) disparaissent : utilisez SpecialTokenPolicy.
Dans une migration OpenAI → Mistral, testez la conversion de vos outils tels que votre code les produit réellement, pas seulement des dictionnaires écrits à la main.

Pour aller plus loin

C’est la deuxième contribution que Mistral AI intègre après la PR #349 sur les tokenizers hors ligne (article). D’autres correctifs sont en attente de revue : 3 bugs silencieux dans les bibliothèques Python de Mistral AI.

Zakaria Khchiche, Tech Lead Data & IA freelance : plus de 200 agents IA en production (Copilot Studio, Azure AI Foundry, Azure OpenAI), contributeur à Microsoft Agent Framework et à Mistral AI. LinkedIn · Site

Vous voulez que vos équipes construisent des agents comme ceux-ci ? Je propose une formation pratique Copilot Studio (avec Spar-x, organisme certifié Qualiopi, finançable par votre OPCO) et un kit gratuit sur l’article 4 de l’AI Act.