LLMs de décision : quand un modèle doit décider — et quand il ne le doit pas

Demandez aux praticiens ce qui casse dans les systèmes d’agents, et la réponse est rarement la capacité. L’échec est plus discret : le modèle décide, et personne ne peut distinguer le son du fluide.

La sortie d’un modèle est un échantillon. Une décision possède des propriétés qu’un échantillon n’a pas — la détermination pour une entrée fixe, des invariants qu’elle doit satisfaire, une piste d’audit qui explique pourquoi cette option et non pas l’autre. Quand ces propriétés sont absentes, la « décision » n’est qu’une supposition de haute confiance qui porte les habits d’une vraie décision.

Cet article donne un traitement mécanique à cet écart : une taxonomie de cinq rôles de décision, une règle pour acheminer chaque décision vers le plus petit modèle compétent pour la traiter, et le mécanisme de vérification qui transforme « l’agent a décidé X » en quelque chose que l’on pourra prouver a posteriori comme étant sain. Il se conclut par une grille d’évaluation que vous pouvez appliquer à toute action de votre propre système.

« Pour les agents locaux, l’écart que je rencontre constamment n’est pas la capacité, c’est la vérification. L’agent affirme qu’il a lu un fichier, appelé un outil ou pris une décision… » — r/LocalLLaMA, « Meilleurs Agents Locaux — Juin 2026 »

« Quand un agent LLM échoue, c’est une boîte noire et personne ne sait pourquoi. Le vrai goulot d’étranglement pour l’adoption n’est pas de passer un modèle d’une précision de 92 % à 96 % — [c’est de savoir pourquoi il a décidé X]. » — r/AI_Agents, « L’écart entre la décision et l’exécution »

La communauté s’est accordée sur trois intuitions : ne pas faire confiance au modèle pour le verdict final, acheminer la décision vers le plus petit modèle compétent, et rendre la décision explicable. Ce qui a manqué, c’est le cadre qui rend les trois actions simultanément applicables.

Pourquoi « ça répond, mais ça décide-t-il ? »

La sortie d’un modèle est une distribution de jetons réduite à une séquence, et la même invite exécutée deux fois peut produire deux séquences qui divergent exactement sur le jeton qui compte. Une décision, en revanche, est déterministe pour une entrée fixe, satisfait des invariants explicites et laisse une piste d’audit enregistrant quelle branche a été prise et pourquoi.

Quand un modèle « décide » sans mécanisme autour de lui, aucune de ces propriétés n’existe. Il n’y a pas d’invariant que la sortie soit obligée de respecter, pas de registre de la branche prise, pas de moyen de rejouer la décision et de vérifier qu’elle a tenu. L’écart n’est pas l’intelligence — c’est qu’une sortie probabiliste a été placée dans un emplacement conçu pour une sortie déterministe.

L’intuition du praticien est de tenir le modèle hors de la décision entièrement :

« Le LLM ne prend jamais de décisions finales dans le système. Son rôle est purement : raffinement de logique, tests de résistance, génération de scénarios, explication. » — r/AI_Agents, « Utiliser un LLM comme “agent de raisonnement” pour valider les prix… »

C’est la bonne posture énoncée sous forme de maxime. Pour l’appliquer, vous avez besoin d’un moyen de classifier quel rôle le modèle doit tenir pour une action donnée — c’est ce que la taxonomie ci-dessous fournit.

Cinq rôles de décision

Chaque décision qu’un système prend peut être attribuée à l’un des cinq rôles. Le rôle détermine dans quelle mesure la sortie du modèle peut être trustée, comment elle est audité, comment elle échoue, et si un humain doit être dans la boucle.

Lisez le tableau comme une contrainte, non comme un menu. La plupart des systèmes cassés partagent un défaut commun : un seul modèle remplit les cinq rôles à la fois, donc un rôle qui exige la détermination (décideur) est servi par un composant optimisé pour la fluidité (générateur). Là où le modèle agit comme générateur, aucun des mécanismes de décision n’est nécessaire — c’est la révision du contenu qui l’est. L’échec à éviter est de confondre ceux-ci : « l’agent a décidé de supprimer l’environnement » est généralement une porte d’approbation manquante, pas un problème de qualité de décision.

Acheminer la décision vers le plus petit modèle compétent

Une fois le rôle fixé, la question du routage est quel niveau de modèle le sert. Les praticiens rapportent directement le rendement :

« Routage des modèles : Haiku pour les décisions de classification/routage, Sonnet pour l’exécution, Opus uniquement pour la conception/planification. Le coût a baissé d’environ 60 % une fois que j’ai cessé d’utiliser Opus pour tout. » — r/AI_Agents, « Quelle est votre pile complète d’Agents IA en 2026 ? »

Ce chiffre provient du traitement de la sélection de modèle comme une décision par rôle plutôt que par système. Un appel de routage — « est-ce un tri de courriel ou une approbation de remboursement ? » — est une classification, et la classification n’a pas besoin d’un modèle de pointe ; elle a besoin d’un petit modèle, rapide, à basse température, parce qu’elle s’exécute des milliers de fois. La mécanique des niveaux — sélection basée sur la capacité, consciente des coûts et de la latence, plus les chaînes de repli — est couverte dans Routage des modèles : Cesser d’utiliser un seul modèle pour tout ; les motifs d’orchestration autour de plusieurs modèles sont dans Conception de systèmes multi-modèles.

L’ajout que le cadre décisionnel apporte est l’escalade basée sur la confiance, qui rend « le plus petit compétent » mesuré plutôt que supposé. Commencez au niveau le plus petit. Si le modèle émet une confiance calibrée — ou une auto-évaluation structurée — et qu’elle franchit un seuil, arrêtez-vous. Sinon, escaladez d’un niveau et enregistrez l’escalade. La compétence est alors une propriété vérifiée par appel, non une propriété supposée par modèle.

Une contrainte reste absolue quel que soit le niveau : le rôle de routeur lui-même ne doit pas être un appel libre de modèle de langage. Une épine dorsale déterministe — règles sur le type de tâche, la taille de la charge utile, le budget de coût — sélectionne la branche, et le modèle ne remplit que les décisions feuilles à l’intérieur de celle-ci. L’épine dorsale est auditable et testable en unités ; le modèle est contenu dans ce qu’il sait réellement faire.

Rendre la décision vérifiable

C’est là que l’écart de « l’agent dit qu’il a fait X » se ferme. La correction est de rendre la décision un artefact structuré de premier plan plutôt qu’un effet secondaire d’un tour de discussion :

1. Un magasin de décisions structuré. Chaque décision que le modèle est autorisé à prendre est écrite dans une table, pas dans une ligne de journal : l’entrée, le rôle, le modèle et le niveau, la confiance, les alternatives envisagées, l’horodatage. Une décision est quelque chose que l’on peut SELECT plus tard. Si elle n’existe que dans une transcription de conversation, c’est une supposition.
2. Un journal de décisions, séparé du journal d’exécution. Le journal d’exécution dit ce qui s’est passé ; le journal de décisions dit ce qui a été décidé et sur quelle base. La séparation est importante parce que l’échec est généralement dans la décision, non dans l’exécution — l’agent a exécuté la suppression parfaitement ; le bug était de décider de supprimer. La mécanique de la journalisation structurée et en ajout uniquement est la même utilisée pour les pistes d’audit de conformité dans Les Garde-fous LLM en Pratique.
3. Invariants et assertions. Pour les rôles de décideur et d’évaluateur, la décision doit satisfaire des invariants vérifiés après l’émission par le modèle, dans du code déterministe. Un recommandeur de prix peut émettre n’importe quoi ; l’invariant « le prix recommandé doit être dans [plancher, plafond] » est appliqué par le code. Le modèle propose ; l’invariant dispose.
4. Portes d’approbation humaine à la frontière de l’irréversibilité. La porte est une propriété de la portée de l’action, non de la confiance du modèle. Un remboursement sous un seuil est auto-approuvable ; un au-dessus ne l’est pas. Un modèle à 99 % de confiance ne peut toujours pas approuver une action irréversible pour laquelle il n’a pas d’enregistrement d’audit.

Le fil conducteur : la poussée pour passer de 92 % à 96 % de précision n’est pas le goulot d’étranglement — l’explicabilité l’est. Un système à 92 % où chaque décision est journalisée, vérifiée par invariants et contrôlée à la frontière est livré en toute sécurité, parce que les 8 % de décisions erronées sont trouvables avant de causer des dégâts. Un système à 99 % avec un processus de décision boîte noire ne l’est pas, parce que les 1 % sont un incident en cours sans enregistrement forensique. Le fait que la porte elle-même réside dans un assistant — quel composant détient l’autorité d’approbation et comment les requêtes l’atteignent — est détaillé dans Architecture de l’Assistant IA : LLM, Mémoire, Outils, Routage, Observabilité.

Exemples détaillés

Trois systèmes, une attribution de rôle chacun.

Validation des prix — le modèle comme recommandeur, jamais décideur. Un agent examine une modification de prix d’un fournisseur et produit une liste classée : accepter, négocier à X, rejeter. Le verdict final est un emplacement de décideur rempli par des règles déterministes : sous le plancher de coût, acceptation automatique ; au-dessus du plafond, route vers un humain ; en entre, appliquer l’invariant « le prix négocié doit battre le dernier accepté de Y %. » Le modèle n’approuve jamais sa propre recommandation, et la recommandation réside dans le magasin de décisions avec sa trace de grille si elle se trompe.

Routage des tâches d’agent — l’épine dorsale comme décideur, le modèle aux feuilles. Une requête entrante (courriel, ticket, commande) est assignée un chemin par forme de charge utile et catégorie d’intention — déterministe, testable en unités. Un petit modèle remplit uniquement la décision feuille à l’intérieur de la branche. Un mal-routage est un événement de portée, ce qui est exactement pourquoi la sélection de la branche doit être déterministe.

LLM-comme-juge — le modèle comme évaluateur, la grille comme contrainte. Un modèle note la sortie d’un autre par rapport à une grille versionnée, et la note plus la trace de la grille sont stockées, pas seulement le nombre. Le mode d’échec connu est le biais d’auto-préférence — un modèle note plus haut son propre style de génération — et la mitigation est structurelle : versionner la grille pour qu’un modèle ne note jamais silencieusement selon des critères qu’il a façonnés.

La limite honnête

Il y a une classe de décision qu’un LLM ne doit pas prendre, et ce n’est pas une question d’échelle : les actions qui sont irréversibles, à fort enjeu et n’ont aucun repli — suppression de données, mouvement de fonds, engagements externes. La vérification est impossible pour une action que l’on ne peut pas annuler, c’est pourquoi « agent autonome » heurte constamment le même mur indépendamment de la qualité du modèle.

L’humain dans la boucle qui n’est pas du théâtre se situe exactement à cette frontière et nulle part ailleurs. Un humain examinant chaque décision à faible enjeu ajoute de la friction et aucune sécurité ; un humain absent de chaque décision à fort enjeu est l’incident. Le même principe apparaît sous une forme plus étroite dans la mémoire des agents : les boucles de mémoire auto-renforçantes mettent les écritures de mémoire candidates derrière une approbation humaine explicite avant que quoi que ce soit n’atteigne l’état durable — la porte dimensionnée selon ce que l’écriture peut casser. Pour les systèmes multi-agents, la question correspondante est qui peut agir au nom de qui, et la mécanique d’identité, de délégation et de piste d’audit pour cela est dans Sécurité des Agents A2A et MCP.

La grille d’évaluation des décisions

Appliquez ceci à toute action de votre système :

1. Classifier le rôle. Décideur, recommandeur, évaluateur, générateur ou routeur ? Un rôle sans nom est un bug — un modèle dans un emplacement de décideur portant la confiance d’un générateur.
2. Choisir le niveau pour ce rôle. Le plus petit compétent, avec une escalade basée sur la confiance pour que la compétence soit mesurée par appel.
3. Définir la vérification. Quels invariants doivent tenir ? Qu’est-ce qui va dans le magasin de décisions ? Quelle est la trace d’audit ? Un rôle sans chemin de vérification est un décideur par défaut.
4. Fixer la porte humaine selon la portée, non la confiance. Irréversible ou à fort enjeu → contrôlé. Sinon → auto, avec la décision journalisée pour qu’elle soit trouvable.

La même discipline, appliquée aux choix d’ingénierie plutôt qu’aux actions d’exécution, est ce que font les enregistrements de décision — les Enregistrements de décision pour le développement piloté par IA capturent pourquoi un choix a été fait pour qu’il puisse être révisé plus tard ; la grille ci-dessus fait de même pour les décisions que prend un système en fonctionnement.

À venir : le décideur comme produit

Le cadre prédit sa propre commoditisation : une fois que « router la décision vers le plus petit modèle compétent » est devenu un motif, l’étape suivante était une classe de modèle qui ne fait que décider. Cette étape est maintenant arrivée.

Jusqu’en octobre 2026, plusieurs éditeurs ont publié des modèles construits sur une recette partagée — un squelette Qwen figé, un adaptateur LoRA de rang 256, et une tête de schéma conjointe — qui émettent des décisions typées en un seul passage avant : un choix à partir d’un ensemble énuméré, un oui/non, ou une note, avec des probabilités calibrées et aucun texte libre. Il n’y a pas de chaîne de pensée à attendre, parce qu’il n’y a pas de génération. La latence rapportée par les éditeurs se situe entre environ 8 et 210 ms à travers la classe — de la variante la plus petite (d1-3B, environ 8 ms) jusqu’à la plus grande (d3, environ 209 ms) — et les empreintes sont dans le territoire des petits GPU : d1-3B à environ 1,67 Go, d3-flash à environ 6,6 Go en Q4_K_M. Le support a également avancé vite : llama.cpp a fusionné le support natif de l’architecture pour plusieurs de ces modèles en à peine deux semaines de la publication.

Deux conséquences pour le cadre ci-dessus. Premièrement, la règle de routage obtient une expression matérielle qu’elle n’avait pas avant : le rôle de décideur peut être servi par un petit modèle dédié plutôt que par un mode d’invite d’un modèle général, ce qui rend la décision du niveau le plus petit compétent en partie automatique — le niveau existe pour votre type de décision ou il n’existe pas. Deuxièmement, rien ne change concernant la vérification. Une décision typée en 8 ms a toujours besoin du magasin de décisions, des invariants et de la porte à la frontière d’irréversibilité ; ce que la classe de modèle supprime est le coût de génération et la non-détermination, non la charge d’audit. Des décisions plus rapides multiplient le nombre d’enregistrements de décisions à auditer — le goulot d’étranglement n’était jamais la vitesse du modèle, et ce n’est pas non plus l’intelligence du modèle.

Les autres directions à surveiller sont plus discrètes. La fiabilité de l’appel d’outils pour les petits modèles approche de la saturation — l’entraînement postérieur sur l’utilisation d’outils est l’étape à fort impact la moins chère dans la pile, ce qui déplace l’attention vers les lignes ci-dessus. Les horizons de planification fiables s’étendent continuellement, ce qui rend le rôle de décideur atteignable pour des tâches plus longues et fait croître la charge de vérification avec l’horizon. Les deux alimentent la même conclusion : la ressource rare dans les systèmes d’agents est les décisions que l’on pourra prouver a posteriori comme saines, et tout le reste rattrape cela.