Mistral propose une Responses API en préversion publique. Cette interface reprend le format Responses utilisé pour construire des applications avec des modèles d’IA : elle distingue les réponses, les éléments de raisonnement disponibles et les demandes d’appel à des fonctions. Pour une équipe qui développe un assistant, l’intérêt est de mieux traiter chaque étape au lieu de recevoir uniquement un texte final.
L’assistant peut demander une action, votre application doit l’exécuter
L’annonce a été publiée le 28 octobre et la documentation officielle de Mistral détaille déjà les possibilités de la préversion. Les résultats sont renvoyés sous la forme d’un tableau d’éléments, appelé output. L’application peut y distinguer un message destiné à l’utilisateur d’une demande d’exécution.
Prenons un assistant chargé de suivre une commande. Le modèle peut demander l’appel d’une fonction qui consulte le statut de livraison. L’application exécute cette fonction, puis transmet son résultat au modèle pour qu’il formule la réponse. L’API n’exécute pas à elle seule toutes les actions du logiciel. La validation des paramètres et les autorisations restent du côté de l’application.
Documents, images et réponses structurées sont pris en charge
La préversion accepte du texte, mais aussi des fichiers et des images avec les modèles compatibles. Elle peut produire des sorties structurées en JSON et diffuser la réponse au fil de sa génération. Ce dernier point permet d’afficher progressivement le résultat dans une interface.
Pour une application qui utilise déjà le format Responses, cette compatibilité constitue un point de départ pour essayer les modèles Mistral, dont Mistral Large 4 présenté dans les exemples officiels. Elle ne dispense pas de tester les fonctions réellement employées : modèles, capacités visuelles, raisonnement et paramètres acceptés ne deviennent pas identiques par le seul choix d’un format commun.
L’historique reste à gérer dans votre application
La documentation qualifie cette API de stateless. À chaque tour, l’application doit donc transmettre les éléments utiles de la conversation, y compris les sorties précédentes. Un échange qui fonctionne avec une seule question ne valide pas encore le comportement sur une discussion de vingt messages.
Tester aussi les erreurs, pas seulement une réponse réussie
Avant une mise en production, un essai utile consiste à vérifier trois cas : un document correctement lu, un outil qui renvoie une erreur et une conversation reprise après plusieurs échanges. Il faut aussi prévoir les réponses interrompues ou incomplètes, documentées parmi les événements de streaming.
La fonction demeure en préversion. Elle donne une nouvelle voie d’intégration aux développeurs ; elle ne correspond pas à un nouveau bouton activé automatiquement dans Le Chat.
Eric Thomas suit l’actualité de Windows, des logiciels, de la cybersécurité grand public et des outils web. Il s’intéresse aux mises à jour système, aux nouveautés informatiques et aux solutions pratiques qui améliorent l’expérience numérique au quotidien.
