Les modèles de raisonnement : quand ils changent la donne

Depuis quelque temps, une nouvelle famille de modèles occupe le devant de la scène : les modèles de raisonnement. Leur particularité est de ne pas répondre immédiatement, mais de dérouler d’abord un raisonnement interne, parfois long, avant de produire la réponse. La série o d’OpenAI (o1, o3), DeepSeek-R1, le mode de réflexion étendue de Claude, les versions « thinking » de Gemini ou Magistral chez Mistral en sont les représentants. Ce comportement améliore nettement la justesse sur certaines tâches, au prix d’une latence et d’un coût sensiblement plus élevés.

La réalité est plus nuancée que la promesse : ces modèles ne sont pas meilleurs partout, ils sont meilleurs sur une classe précise de problèmes, et ce surcroît de justesse se paie cher. Les utiliser à mauvais escient, c’est payer plus pour rien.

Voici les critères pour choisir, cas par cas, entre un modèle de raisonnement et un modèle classique.

Ce qui distingue un modèle de raisonnement

Un modèle de raisonnement se reconnaît à un comportement : il produit une chaîne de raisonnement avant la réponse, et ce raisonnement lui-même est le produit du travail. Il décompose le problème, explore des hypothèses, revient sur ses pas, puis conclut. Cette étape intermédiaire, invisible ou partiellement visible selon les cas, est ce qui lui permet de résoudre des problèmes qu’un modèle classique rate en répondant d’un coup.

La contrepartie est double : la latence et le coût. Le raisonnement consomme des tokens, parfois en très grande quantité, et ces tokens sont facturés comme les autres. Un problème qui demande plusieurs minutes de raisonnement coûte plusieurs fois le prix d’une réponse immédiate. La latence, elle, peut rendre le modèle inutilisable pour une interaction où l’utilisateur attend une réponse rapide.

Il faut donc comprendre ces modèles comme un outil spécialisé, pas comme une version supérieure du modèle classique. Ils sont supérieurs sur ce qu’ils savent faire, et simplement plus chers ailleurs. Le choix se joue sur la nature de la tâche, pas sur une hiérarchie générale.

Où ils changent réellement la donne

Les modèles de raisonnement excellent sur les problèmes qui demandent plusieurs étapes enchaînées : la résolution de problèmes mathématiques ou logiques, le débogage d’un code complexe, l’analyse d’un texte juridique ou réglementaire où il faut croiser plusieurs clauses. Dans ces cas, la différence de justesse est réelle et souvent décisive, et elle justifie largement le surcoût.

Ils sont aussi précieux là où une erreur coûte cher. Quand un agent doit prendre une décision dont on ne peut pas se permettre qu’elle soit fausse, confier le raisonnement à un modèle qui prend le temps de vérifier est un investissement rationnel. Le surcoût se compare alors au coût d’une erreur, et l’arbitrage devient évident.

Enfin, ils servent à améliorer d’autres systèmes, en amont ou en aval : générer des données d’entraînement, vérifier le raisonnement d’un modèle plus léger, évaluer la justesse de réponses produites ailleurs. Dans ces rôles, le coût s’amortit sur un volume important, et la latence n’est pas un problème puisque personne n’attend en direct.

Où ils n’apportent rien de plus

À l’inverse, il y a toute une classe de tâches pour lesquelles les modèles de raisonnement n’apportent rien, et où les utiliser est du gaspillage. La génération de texte simple, le résumé, la reformulation, la réponse à une question dont la réponse est dans un document fourni : toutes ces tâches sont déjà bien traitées par des modèles classiques, plus rapides et moins chers.

Le cas du RAG est parlant. La recherche fournit au modèle le passage qui contient la réponse, et le modèle n’a qu’à la reformuler. Ajouter une longue phase de raisonnement ne rend pas la réponse plus juste, elle la rend plus lente et plus chère. Beaucoup d’équipes adoptent un modèle de raisonnement pour leur RAG par mimétisme, et paient ce mimétisme sur chaque requête. Sur un assistant RAG, la justesse se joue d’abord sur la qualité des sources et de la recherche, comme on l’explique dans pourquoi la qualité des sources prime sur le modèle.

La règle simple est la suivante : si la réponse est dans les données fournies, un modèle classique suffit. Si la réponse demande de raisonner sur ces données, de croiser, de déduire, alors un modèle de raisonnement peut se justifier. C’est la frontière entre retrouver et résoudre qui départage les deux familles.

Le coût réel : le mesurer avant de choisir

Le surcoût des modèles de raisonnement ne se lit pas sur le prix affiché au token, il se lit sur le coût par réponse correcte. Un modèle de raisonnement peut coûter dix fois plus cher par requête, mais si sa justesse passe de quatre-vingts à quatre-vingt-quinze pour cent sur une tâche critique, ce surcoût peut être parfaitement rationnel. L’inverse est vrai aussi : un surcoût sans gain de justesse est une perte sèche.

Pour trancher, il faut mesurer les deux choses sur votre cas réel : la justesse, avec un jeu de cas de référence (le principe des evals, expliqué ici), et le coût, avec les tokens réellement consommés. Promptfoo permet de lancer le même jeu de cas sur plusieurs modèles et de comparer justesse et coût côte à côte ; Langfuse suit ensuite ce coût en production. Le rapport entre les deux, le coût par réponse correcte, est la métrique qui décide. C’est elle qui dit si le raisonnement vaut son prix, ou s’il faut revenir à un modèle plus simple.

Cette mesure a un second bénéfice : plutôt que d’opposer des intuitions sur « quel modèle est le meilleur », on compare des chiffres.

La stratégie pragmatique : router selon la tâche

La conclusion pratique n’est pas de choisir entre les deux familles, mais de les utiliser chacune là où elle excelle. C’est ce qu’on appelle le routage : selon la nature de la requête, on l’envoie à un modèle classique ou à un modèle de raisonnement. Cette approche combine le meilleur des deux : la rapidité et le faible coût du classique pour le courant, la justesse du raisonnement pour le difficile.

Le routage peut être simple, fondé sur une règle, ou plus fin, fondé sur un premier modèle léger qui décide de la complexité. Une passerelle comme LiteLLM ou OpenRouter, ou un nœud conditionnel dans LangGraph, permet de changer de modèle sans réécrire l’application. Dans tous les cas, l’idée est la même : ne payer le raisonnement que lorsqu’il apporte quelque chose.

Le résultat est un système au coût maîtrisé et à la justesse élevée, où chaque requête est traitée par le modèle le moins cher capable de bien la traiter. C’est une stratégie d’ingénierie simple, mais elle suppose d’avoir mesuré la frontière entre ce qui demande du raisonnement et ce qui n’en demande pas.

Le premier pas pour choisir le bon modèle

Choisir entre modèle classique et modèle de raisonnement, et surtout mettre en place le routage qui combine les deux, demande de la mesure et de l’ingénierie. Si vous utilisez déjà un modèle de raisonnement, un premier contrôle est facile : prenez une centaine de requêtes réelles, faites-les traiter aussi par un modèle classique, et comparez la justesse et le coût par réponse correcte. Si l’écart de justesse est nul sur la majorité des cas, vous tenez votre règle de routage.

C’est ce type d’arbitrage qu’on intègre dès la conception quand on développe un agent IA : caractériser les tâches, mesurer les options sur vos cas, puis router chaque requête vers le modèle le moins cher capable de bien la traiter, avec le suivi de coût qui permet de vérifier que le choix tient dans la durée.