Pourquoi Mistral Small bat Medium et Large sur un chatbot agentique

Quand un client revient avec "le bot ignore une partie des instructions", le réflexe le plus tentant est de se dire : "Mistral Small est sous-dimensionné, on passe Medium ou Large." Erreur. Sur un agent narrow-scope avec tools custom, c'est probablement le pire ordre des choses à essayer.

On a piloté un chatbot multilingue en production avec Mistral Small, Mistral Medium 3.5 et Mistral Large 3, sur exactement le même prompt et les mêmes tools. Verdict chiffré : Small gagne. Pas marginalement. Largement. Voici ce qu'on a appris, et pourquoi ça ne contredit pas les benchmarks académiques (mais les complète).

Le contexte : un chatbot multilingue avec 5 tools custom

L'agent étudié ici est l'assistant conversationnel d'une plateforme régionale qui aide des jeunes français et espagnols à trouver des opportunités d'échange transfrontalier : stages, jobs, mobilité européenne, bourses. Il parle 7 langues, dont 4 langues régionales (catalan, basque, aragonais, occitan), et il s'appuie sur 5 outils custom :

• geocode : conversion adresse vers coordonnées via Nominatim (OpenStreetMap).
• searchOpportunities : recherche dans une base Postgres avec embeddings vectoriels (pgvector) et filtrage géographique (PostGIS).
• getContacts : liste les organismes ressources par proximité PostGIS.
• searchOpportunityDirectories : annuaires d'offres spécialisés.
• searchResourcesAndTestimonials : témoignages et ressources éditoriales.

Stack technique côté serveur : Next.js 16, Vercel AI SDK v6 (le pattern ToolLoopAgent), @ai-sdk/mistral pour brancher Mistral. C'est un agent narrow-scope par construction : il ne doit JAMAIS inventer de site, JAMAIS proposer une offre hors base, JAMAIS répondre depuis sa connaissance interne sur le marché des stages en Espagne. Tout passe par les tools.

flowchart LR
    U[Utilisateur 7 langues] --> A[Vercel AI SDK ToolLoopAgent]
    A -->|tool call| G[geocode<br/>Nominatim OSM]
    A -->|tool call| S[searchOpportunities<br/>Postgres pgvector PostGIS]
    A -->|tool call| C[getContacts<br/>PostGIS proximity]
    A -->|tool call| D[searchOpportunityDirectories]
    A -->|tool call| R[searchResourcesAndTestimonials]
    G --> A
    S --> A
    C --> A
    D --> A
    R --> A
    A <-->|prompt + tool calls| M[Mistral Small / Medium / Large]
    A --> U

Premier feedback après quelques semaines de production : "le bot ignore une partie des instructions, il propose parfois des sites externes alors qu'on lui demande de ne pas le faire." Le réflexe d'agence par défaut serait : "Small ne suit pas les règles fines, passons sur Medium." Ce serait un mauvais réflexe, et la suite explique pourquoi.

Prérequis avant de tester votre propre dimensionnement

Avant d'attaquer ce genre de chantier, voici la checklist minimale qu'on recommande pour le reproduire chez vous :

• Un agent déjà fonctionnel avec un set de tools clair (function calling, schemas typés).
• Un accès aux trois tiers Mistral sur la même clé API (Small, Medium, Large) pour comparer à iso-prompt.
• Un script REPL terminal qui boucle sur l'agent (estimation : 100 à 200 lignes de TypeScript avec Vercel AI SDK).
• Deux à trois scénarios de test reproductibles : un multistep "vrai user" et un one-shot riche en information.
• Une compétence prompt engineering de base : ordre des règles, few-shot examples, reformulation positive.
• Un budget de 30 minutes par tour de boucle. Plus si vous voulez itérer plusieurs prompts.

Pas besoin de fine-tuning, pas besoin de GPU dédié, pas besoin de pipeline d'évaluation industriel. La méthode tient sur un poste de dev avec une connexion internet correcte.

Le réflexe à éviter : passer Mistral Small à Medium

Pourquoi monter en gamme est instinctif mais souvent contre-productif sur un agent narrow-scope, c'est ce que nous allons disséquer. Trois raisons :

1. Vous n'avez pas testé si le prompt actuel est saturé. Si Mistral Small ne respecte pas une règle, il y a souvent une raison structurelle dans le prompt (ordre, redondance, formulation négative). Changer de modèle masque ce signal au lieu de le résoudre.
2. Vous multipliez le coût output par 9 à 25. Mistral Medium 3.5 facture 7,50 $ par million de tokens output, contre 0,60 $ pour Small. Sur un chatbot verbeux, c'est un facteur de 10 à 25 sur la facture mensuelle.
3. Vous achetez de la latence dont vous n'avez pas besoin. Small fait 80 à 140 tokens par seconde. Medium tombe à 46 tokens par seconde. Sur une chaîne de tool calls, la différence cumulée devient sensible côté UX.

L'industrie commence à documenter ce contre-intuitif. Nvidia a publié en 2025 un papier de position (Small Language Models are the Future of Agentic AI) qui défend exactement la même thèse : pour un agent, un SLM bien aligné est 10 à 30 fois moins cher qu'un LLM pour un résultat équivalent ou meilleur. Une équipe AWS a montré dans un papier paru sur arXiv qu'un OPT-350M fine-tuné atteint 77,55 % de pass rate sur ToolBench, contre 26 % pour ChatGPT-CoT (175 milliards de paramètres). Cinq cents fois plus petit, trois fois meilleur.

Notre méthode : un REPL CLI pour piloter l'agent en 5 secondes par boucle

La première chose qu'on a faite n'est pas de modifier le prompt. C'est de construire un meilleur outil de test.

Tester un chatbot via l'UI de production, c'est une boucle de feedback de 30 secondes : recharger la page, taper un message, attendre, screenshot, lire les logs. Inutilisable pour itérer rapidement. On a écrit un REPL CLI d'environ 150 lignes en TypeScript qui utilise directement ToolLoopAgent.stream() du Vercel AI SDK et logue, en temps réel :

• chaque tool call avec ses arguments JSON,
• chaque tool result (ou erreur),
• la latence par étape,
• le nombre de tokens input et output,
• la réponse finale streamée.

Boucle de feedback : 5 secondes. On peut tester 50 variantes de prompt en une heure. Et surtout on voit ce que le modèle fait, pas seulement ce qu'il dit. Construire ce genre d'outillage avant d'optimiser le prompt est le levier le plus sous-estimé en LLM engineering. Tant que vous itérez via l'UI de prod, vous travaillez dans le noir.

Le piège qu'on a vraiment vécu : l'hallucination masquait un bug Drizzle

Pendant les tests REPL, searchOpportunities a planté avec une GraphQLError: Something went wrong. Investigation côté Sentry : deux issues silencieuses depuis cinq jours, dont une avec 4 events sur de vrais utilisateurs en production. Le bot avait continué à répondre sans alerte.

Symptôme côté utilisateur : le chatbot proposait des plateformes externes (sites d'offres connus, groupes Facebook spécialisés) qui n'avaient rien à faire là. Côté équipe : "le bot semble bizarre."

Quatre events sur cinq jours, c'est invisible dans les métriques produit standards. Mais c'est exactement le genre de dégradation silencieuse qui érode la confiance utilisateur sans laisser de trace. Et tant que le modèle "comble" avec ses propres connaissances, vous ne saurez jamais que l'erreur vient de votre backend.

Cinq leviers de prompt engineering qui ont tout changé

Pas de changement de modèle. Pas de changement de tools. Pas de fine-tuning. Juste cinq modifications du system prompt :

1. Identité et trois règles non-négociables en tête. Les small models pondèrent fortement les premiers tokens du prompt. La règle anti-hallucination existait dans l'ancien prompt, mais perdue en douzième position après onze autres règles en MAJUSCULES. Déplacée tout en haut, formulée en trois lignes : "Réponds en français. Toutes les infos viennent des outils, sinon admets-le et propose un contact réseau. Pas de questions en rafale."

2. Critère d'action explicite et concret. L'ancien prompt disait "commence à chercher dès que tu as assez d'éléments". Trop vague. Nouvelle version : "3 éléments essentiels acquis (lieu, type d'opportunité, destination) ? Lance les outils sur le champ. Ne paraphrase pas pour confirmer."

3. Few-shot example pair (good vs bad). Deux lignes de prose normative ne suffisent pas. Ajouter un exemple positif ET un exemple négatif explicite a été le levier décisif. Un mauvais ("User: 'BTS hôtellerie à Toulouse, stage 6 mois à Barcelone, septembre.' Toi: 'Tu es bien à Toulouse, c'est ça ?' ❌") et un bon ("User: '...' Toi: (lance immédiatement les tools) ✅"). Ce pattern good/bad pair vaut souvent dix lignes d'instructions abstraites, et il est généralisable bien au-delà des chatbots.

4. Suppression de la duplication des tool descriptions. Les descriptions de tools sont déjà transmises au modèle via le protocole function-calling. Les redécrire en prose dans le system prompt revient à doubler l'information : bruit, risque d'incohérence entre les deux versions, budget d'attention gaspillé.

5. Reformulation positive des règles négatives. "NE DIS JAMAIS X" devient "DANS LE CAS Y, FAIS Z". Les négations sont des règles de suppression, plus difficiles à respecter pour un modèle que les règles d'action. Plus le modèle est gros, plus c'est vrai (on y revient juste après).

Résultat : prompt 6 % plus court (2962 à 2786 tokens en input first turn), et zéro hallucination observée sur les deux scénarios après itération.

Le résultat chiffré : Small bat Medium et Large

Avec le nouveau prompt, comparaison à iso-input sur un scénario one-shot riche ("Je suis étudiante en BTS hôtellerie à Toulouse, je cherche un stage de 6 mois à Barcelone en cuisine pour septembre, je parle espagnol") :

Sur ce scénario, Mistral Large a généré l'adresse hugo.rosier@ut-capitole.fr. Format pro, domaine universitaire vraisemblable, prénom français banal. Crédible. Sauf que ni Hugo Rosier ni cette adresse n'existent. C'est exactement le type d'hallucination dangereuse : elle passe inaperçue. Small, quand il hallucine, hallucine des trucs plus génériques et plus repérables. Paradoxe à retenir : pour les usages où la véracité absolue compte, vous voulez le modèle qui ment moins bien.

Pourquoi les gros modèles hallucinent plus (la mécanique interne)

C'est la partie qui intrigue. Cinq mécanismes empilés expliquent le phénomène :

1. Plus de monde stocké, plus à supprimer. Les sites de jobs spécialisés Espagne, les universités françaises, les acronymes de l'enseignement supérieur apparaissent des milliers de fois dans le training data web. Plus le modèle est gros, plus le pattern "Barcelone + stage cuisine = [site connu]" est ancré profondément. La règle "n'utilise que les outils" devient une règle de suppression active : éteindre un réflexe puissant.

2. Le RLHF "be helpful" tire dans l'autre sens. Plus un modèle est aligné sur "aide complètement, suggère des alternatives, sois exhaustif", plus son réflexe "et puis aussi tu pourrais essayer X" se déclenche quand un tool retourne peu de résultats. C'est une voie d'évasion à la règle d'interdiction.

3. Suivre une instruction positive est plus facile que supprimer un comportement. Les gros modèles sont meilleurs sur "structure ta réponse en trois sections". Ils sont moins bons sur "ne mentionne JAMAIS de sites externes". La règle de suppression doit gagner un arbitrage interne face à plus de candidats compétents.

4. Plus de capacité, plus de fluence dans le mensonge. Quand Small hallucine, il invente "des plateformes connues comme ..." : générique, repérable. Quand Large hallucine, il fabrique un email d'enseignant universitaire avec format institutionnel cohérent et nom plausible. La fluence rend l'erreur indétectable.

5. Compétition d'attention dans le prompt. Plus le modèle a de capacité, plus il y a de candidats neuronaux qui s'affrontent à chaque prochain token. La règle "no external sites" doit emporter plus d'arbitrages internes pour gagner.

Le ton du leak est observable cliniquement. Small répond : "Voici ce que j'ai trouvé." Medium ajoute : "et en plus tu pourrais aussi essayer [site externe]." Large empile : "et l'Université, et le rectorat, et voici un email type, et voici des conseils CV..." La cascade "et puis aussi" est la signature du leak de helpfulness.

Une analogie utile : un débutant à qui on dit "tu ne sers que les boissons de la carte" l'applique facilement, il ne connaît pas les autres. Un barista expert à qui on donne la même consigne lutte en permanence : il connaît cent alternatives qui régaleraient ce client. L'expert est plus compétent. Mais la règle crée une friction précisément à cause de sa compétence. Pour un agent narrow-scope, vous voulez le débutant discipliné, pas l'expert créatif.

Pourquoi on ne migrera pas vers Medium ou Large sur ce projet

Sur ce job précis (agent narrow-scope avec tools, contrainte d'anti-hallucination forte, latence importante), Small domine sur trois axes simultanément : qualité (zéro hallucination), latence (3 fois plus rapide que Large), coût (6 à 25 fois moins cher). Aucun argument technique ne justifierait de monter en gamme.

Il y a même un argument économique fort : pour 10 sessions par jour, 5 turns par session, 365 jours dans l'année, on parle de 18 250 turns annuels. Small revient à environ 12 $ par an. Large à 27 $. Medium dépasse les 100 $. Sur un budget association, collectivité ou TPE, le multiplicateur a un sens concret.

Cette approche fait partie de notre standard quand nous concevons des agents IA souverains. Sur Jef, l'assistant IA du Barreau de Bruxelles, où l'inacceptabilité de l'hallucination est encore plus forte (contraintes déontologiques juridiques), le même principe s'applique : modèle juste assez gros, discipline absolue sur les sources, et un prompt design qui privilégie les règles d'action sur les règles d'interdiction.

Quand monter en gamme reste pertinent

Le message n'est pas "Small partout". Mistral Medium et Large ne sont pas "mauvais", ils sont sous-optimaux pour ce job précis. Ils brillent ailleurs :

• Rédaction éditoriale longue : la world knowledge devient un atout pour étoffer un sujet.
• Synthèse de documents longs : meilleure capacité de contexte effective.
• Code generation complexe : raisonnement multi-fichier, plus de patterns mémorisés.
• Q&A généraliste sans tools : tâche où la dérive "and you could also try" est une fonctionnalité, pas un bug.

Si votre cas d'usage tombe dans une de ces catégories, montez en gamme. Si votre cas est un agent narrow-scope avec tools custom, ne montez pas par défaut. Les benchmarks académiques (MMLU, MATH, HumanEval, GPQA) mesurent la capacité brute et favorisent systématiquement les gros modèles. Pour un agent, ce qui compte est la discipline, pas la capacité. C'est pourquoi des labos comme Artificial Analysis publient désormais des benchmarks dédiés au tool calling et au prompt following, où le ranking peut s'inverser.

La méthode pour démarrer un agent LLM en 2026

Pour synthétiser, voici l'ordre d'investigation que nous appliquons systématiquement sur ce type de projet :

1. Commencez par Mistral Small (ou un équivalent SLM souverain) avec un prompt initial décent.
2. Bâtissez une boucle d'évaluation rapide : REPL terminal, DevTools, ou un dataset de scénarios joués automatiquement.
3. Avant de monter en gamme, exhaustez le prompt engineering : règles en tête, few-shot good/bad, suppression du bruit, reformulation positive.
4. Si après prompt exhaustif vous avez toujours des problèmes structurels, regardez le modèle. Souvent ce ne sera pas la solution.
5. Ne fine-tunez pas avant d'avoir épuisé le prompt et bâti un dataset d'évaluation objectif. Le fine-tuning a sa place, mais après les leviers gratuits.

Sur la stack souveraineté, Mistral coche les cases : modèle français, infrastructure européenne, conformité RGPD native. C'est un argument qui compte sur les projets publics et parapublics, où la souveraineté des données utilisateurs n'est pas négociable.

Questions fréquentes

Quel modèle Mistral choisir pour un chatbot agentique ?

Sur un agent narrow-scope avec tools (function calling, RAG ciblé), Mistral Small bat généralement Medium et Large en discipline, latence et coût, à condition d'avoir un prompt soigné. Les benchmarks académiques classiques (MMLU, MATH, HumanEval) mesurent la capacité brute et favorisent les gros modèles, mais pour un agent ce qui compte est la discipline : suivre des règles de suppression, appeler les bons tools dans le bon ordre, ne pas déborder.

Pourquoi un petit modèle peut-il battre un gros modèle sur un agent ?

Trois raisons principales : (1) moins de monde stocké donc moins de réflexes parasites à éteindre, (2) RLHF "be helpful" moins poussé donc moins de "et puis aussi" parasites, (3) compétition d'attention moins forte donc règles de suppression mieux respectées. Des recherches récentes (Nvidia, AWS) documentent ce phénomène : un SLM bien aligné peut surpasser un LLM 500 fois plus gros sur ToolBench.

Faut-il fine-tuner avant d'optimiser le prompt ?

Non. Le fine-tuning ajoute une dépendance lourde (dataset à maintenir, pipeline de réentraînement, perte de portabilité). Épuisez le prompt engineering et bâtissez un eval set objectif avant. Le ROI du prompt est immédiat, celui du fine-tuning se mesure sur plusieurs mois.

Comment tester un agent LLM en boucle rapide ?

Construisez un REPL terminal qui pilote directement votre agent SDK (Vercel AI SDK, Anthropic SDK, Mistral SDK) en bypassant l'UI de prod. Logguez en temps réel : tool calls, arguments, results, latence, tokens. Vous passez d'une boucle de feedback de 30 secondes à 5 secondes, soit 6 fois plus de tentatives à l'heure.

Conclusion

Sur un agent LLM avec tools, le bon dimensionnement de modèle est le plus petit modèle qui sait appeler les bons outils dans le bon ordre. Pas plus gros. Ce qui est au-dessus est du poids mort, parfois de la pollution. L'industrie commence à converger sur ce point, des labos de recherche aux fournisseurs européens qui dimensionnent leurs gammes pour les usages agentiques.

L'agence Platane (https://platane.io) accompagne des PME et collectivités françaises sur la conception d'agents IA souverains : choix de modèle, prompt engineering, intégration de tools custom, hébergement Scaleway en France. Si vous démarrez un projet de chatbot agentique et que vous hésitez sur le dimensionnement, un échange de 30 minutes suffit souvent à débloquer la décision.