Modèles de raisonnement : ce que ça change dans une architecture

Les modèles qui produisent une phase de raisonnement avant de répondre ont réglé des problèmes que l'ajustement de prompt ne réglait pas : les tâches à plusieurs étapes, les arbitrages entre contraintes contradictoires, la vérification d'un calcul.

Mais ils introduisent une contrainte que les équipes découvrent en production : le temps de réponse et le coût deviennent variables, et cette variabilité dépend de la difficulté perçue de la question, donc de l'utilisateur.

Une interface conçue pour une réponse en une seconde supporte mal une réponse qui prend parfois trente secondes.

Ce n'est pas seulement une question de patience. C'est une question de conception : un utilisateur qui ne sait pas si le système travaille ou s'il est bloqué relance, ce qui double le coût et dégrade encore la latence. Les dispositifs qui fonctionnent affichent explicitement l'étape en cours, ou basculent en traitement différé avec notification.

La règle que j'applique : si la tâche est interactive, le raisonnement long ne doit pas être sur le chemin critique.

Un point sur lequel j'insiste en formation, parce qu'il induit en erreur : la trace de raisonnement produite par le modèle est une sortie du modèle, pas une explication de son fonctionnement.

Elle est utile, pour repérer où une chaîne dérape, pour donner du contexte à un relecteur. Elle n'a pas valeur de justification opposable. Confondre les deux conduit à considérer une réponse comme vérifiée parce qu'elle est accompagnée d'un raisonnement plausible, ce qui est exactement le piège que l'IA générative tend depuis le début.

Rien de ce qui précède ne modifie les fondamentaux : il faut toujours des données propres, une mesure, une intégration au bon endroit et une supervision réelle.

Un modèle qui raisonne mieux sur un corpus mal tenu produit simplement des erreurs mieux argumentées. C'est une aggravation, pas une amélioration.

La réflexion est devenue un réglage par requête plutôt qu'un choix de modèle, ce qui change la nature de l'arbitrage. Il se règle par famille de tâches, jamais globalement.

Le régime doit être fixé dans le code, par type d'appel. Faire évaluer la difficulté par un modèle ajoute un appel, de la latence, et une imprévisibilité qui rend les incidents irreproductibles.

Une recherche documentaire part toujours en régime direct ; un contrôle croisant plusieurs textes part toujours en régime réfléchi. Le raisonnement complet figure dans raisonnement hybride : un modèle, deux régimes.

Activer la réflexion pour compenser une mauvaise récupération triple la facture et ne corrige rien. C'est le schéma que je rencontre le plus souvent.

La vérification qui l'évite prend dix minutes : sur cinq mauvaises réponses réelles, l'information correcte figurait-elle dans le contexte fourni au modèle ? Si elle n'y était pas, aucun raisonnement ne la fera apparaître.

Dans la quasi-totalité des cas examinés, elle n'y était pas, et le travail était en amont, dans la recherche, le découpage ou le corpus. La méthode de diagnostic est détaillée dans reprendre un système d'IA construit par quelqu'un d'autre.

Une question difficile peut consommer dix fois plus qu'une question simple de longueur identique, ce qui rend la moyenne inutilisable comme prédicteur. La prévision budgétaire change de nature.

Deux réglages suffisent. Un plafond de jetons de réflexion par requête, appliqué par le système et non par une consigne. Et une surveillance au quantile élevé, pour repérer la dispersion avant qu'elle n'apparaisse sur la facture.

Ces deux réglages coûtent une heure et évitent l'incident classique : une poignée de requêtes pathologiques qui consomment l'essentiel du budget mensuel. La mesure correspondante est décrite dans mesurer le coût par fonctionnalité.