Pourquoi un LLM plus puissant ne suffit pas à orchestrer un agent conversationnel fiable

L'essentiel

• Sur des tâches procédurales bien définies, un modèle à qui l'on donne toute la procédure dans son prompt fait mieux qu'une orchestration LangGraph. Une étude d'avril 2026 le mesure [1].

• Ce gain porte sur la qualité moyenne. Il ne promet pas qu'une anomalie déjà repérée ne reviendra pas.

• Chez Gamaro, un harnais de code entoure le modèle. Un orchestrateur y porte la progression de la qualification. Les gardes qui comptent le plus (anti-répétition, refus en texte libre, cohérence des règles métier, demande de consentement) viennent d'une méthode empirique : les anomalies repérées en construisant le produit sont devenues des contraintes en code.

• L'avantage ne vient donc pas du modèle, que tout le monde peut appeler. Il vient de ce harnais et des gardes accumulées dedans, chacune née d'un cas précis, impossibles à reconstituer d'un coup.

• Pour un agent de qualification, un cas limite non couvert peut coûter un prospect qualifié ou ouvrir une exposition RGPD.

Le pari du modèle plus fort

Maintenir un orchestrateur et des centaines de lignes de garde-fous coûte cher à chaque évolution du produit. D'où une tentation légitime : mettre toute la procédure dans le prompt système, brancher quelques serveurs MCP pour l'accès aux données, et laisser le modèle mener la conversation seul.

Ce pari a désormais une base mesurée. Dennis, Diamond, Patil, Shabahang et Guo ont placé le même modèle dans deux configurations [1]. Dans l'une, il reçoit la procédure complète en contexte. Dans l'autre, un orchestrateur LangGraph route la conversation de nœud en nœud. Sur trois tâches procédurales, avec 200 conversations par condition notées par un LLM juge, le pilotage en contexte obtient de 4,53 à 5,00 sur 5. L'orchestrateur obtient de 4,17 à 4,84.

Les échecs complets baissent aussi, dans les trois domaines testés [1] :

Les auteurs bornent eux-mêmes leur conclusion aux tâches procédurales bien définies. Sur ce terrain, le résultat est sérieux. Il mesure des taux sur un grand nombre de conversations. Il ne dit rien de la question qu'un agent métier doit trancher : une anomalie précise, déjà repérée et interdite, peut-elle revenir ?

Ce qu'une moyenne ne garantit pas

Un prospect répète sa question d'une façon inattendue. Deux règles métier se contredisent selon la ville visée. Un visiteur refuse de laisser ses coordonnées, avec ses propres mots. Un score moyen de 4,8 sur 5 ne dit rien de ces conversations-là. Chez Gamaro, chacune a d'abord été une anomalie repérée pendant la construction du produit, puis une contrainte dédiée.

Anthropic distingue deux architectures [2]. Un workflow fait passer les tâches par des chemins de code prédéfinis. Un agent laisse le modèle diriger son propre processus. Un agent progresse quand le modèle progresse. Un workflow encode une contrainte précise, qu'aucun score moyen ne remplace.

Le protocole de Dennis et al. compare deux extrêmes : toute la procédure confiée au modèle, ou toute la conversation routée de nœud en nœud par LangGraph. Gamaro se situe entre les deux. Un orchestrateur codé porte la progression de la qualification : quel champ demander ensuite, quand l'objectif est atteint, quand passer au contact puis au consentement. Le modèle formule les questions, interprète la plupart des réponses libres et répond aux digressions du visiteur, quand le code l'autorise à les servir.

Sur la progression, Gamaro fait donc ce que l'étude met en cause : un orchestrateur externe choisit l'étape suivante. Nous le gardons pour une raison que l'étude ne mesure pas. « Objectif atteint » n'est pas seulement un moment de la conversation. C'est un fait que d'autres briques lisent : le suivi de l'entonnoir, l'affichage de l'appel à l'action, la demande de consentement. Il doit être calculé par le code, pas estimé par le modèle.

Une contrainte de code tient là où une instruction cède

Les exemples qui suivent viennent de notre historique d'ingénierie et de corpus de test internes, pas d'une mesure sur du trafic réel : le produit est encore en construction.

Un modèle peut respecter une instruction de prompt dans l'immense majorité des cas et la contourner quand même. Nous l'avons mesuré avec une métrique dédiée, crush_rate : le taux auquel l'orchestrateur écrase la question hors sujet d'un visiteur pour reposer la sienne. Lever l'obligation d'appeler l'outil d'orchestration (forceToolUse: false) ne suffisait pas : le modèle l'appelait quand même. Le correctif qui a tenu retire l'outil du catalogue proposé au modèle pour ce tour. Ce qui n'existe plus dans son espace de choix ne peut pas être choisi.

Quelques semaines plus tard, l'évaluation d'un modèle candidat, lors d'un changement de fournisseur, a fait remonter le problème. Sous ce modèle, crush_rate restait figé à 1,00, sur plusieurs séries d'exécution et plusieurs températures. Le levier dur existait déjà. C'est le classifieur chargé de le déclencher qui ratait des cas : 5 sur 8 détectés sur le corpus de diagnostic. Avec des libellés enrichis, il en détecte 8 sur 8, et la métrique est revenue à son niveau attendu.

Les deux épisodes donnent la même leçon. Un arbitrage confié au seul jugement du modèle dépend du modèle. Il peut cesser de tenir au changement de LLM, sans une ligne de code modifiée.

Une garde par anomalie, rarement anticipée

Les trois gardes suivantes n'ont pas été déduites d'avance. Chacune est venue d'une anomalie précise, repérée en testant le produit.

Une session de test a montré un agent qui reposait mot pour mot la même question deux tours de suite, alors que l'utilisateur avait donné deux réponses différentes. La répétition était bornée, mais réelle. Son correctif a demandé une refonte de l'orchestrateur, pas un patch local.

Sur l'application de démonstration immobilière, une autre anomalie a bloqué un parcours multi-villes : zéro résultat affiché malgré 28 appels à l'orchestrateur. Deux conditions d'activation d'outils s'excluaient mutuellement dans une configuration précise. Il a fallu revoir le modèle de données de localisation.

Un troisième cas tenait à des libellés de prompt qui ne correspondaient plus aux valeurs acceptées par un outil. Le prompt a été corrigé, et une règle de lint, doublée de tests, détecte désormais ce type de décalage.

Aucun de ces correctifs ne se déduisait d'une spécification générale de « bon agent conversationnel ». Un concurrent qui démarre aujourd'hui avec le meilleur modèle et des serveurs MCP standard n'en hérite d'aucun. Nous les avons repérées en construisant le produit. Lui les découvrira probablement en production, avec ses propres utilisateurs comme détecteurs.

Le refus exprimé en texte libre

Un visiteur qui refusait en toutes lettres de laisser ses coordonnées, au lieu de cliquer sur le bouton prévu, n'était pas toujours entendu. La détection par correspondance exacte ratait le refus dès qu'il était formulé autrement. Pour un agent de qualification, c'est un problème de conformité autant que de conversation.

Le correctif est un classifieur dédié, appelé en repli quand l'analyse déterministe de la réponse échoue alors que des coordonnées sont attendues. Son seuil de confiance est volontairement haut : 0,85, contre 0,70 pour un classifieur voisin moins critique. Le refus mène à un état terminal, donc un faux positif ferait perdre en silence un prospect valide.

Dans ce corpus, deux refus sur cinq échappent donc au classifieur. Le seuil reste un point de vigilance, pas une preuve de conformité du dispositif entier.

Le consentement comme état, pas comme jugement

En production, un prospect a été converti sans que l'agent lui propose jamais l'e-mail de confirmation de sa demande. L'envoi de cet e-mail exige un accord explicite du visiteur, et la demande d'accord était entièrement confiée à une instruction de prompt. Le modèle ne l'a pas posée, alors que l'outil correspondant restait disponible à chaque tour.

Le correctif n'a pas consisté à durcir la formulation de l'instruction. Quand l'option est activée, l'orchestrateur transforme la fin de conversation en un état dédié de l'orchestrateur : email collecté, objectif atteint, accord pas encore demandé. Deux réponses rapides fixes (accepter, refuser) s'affichent alors, et une relance déterministe prend le relais si le modèle laisse son tour vide.

Le modèle formule encore la question, et l'enregistrement de la réponse passe par un appel d'outil qu'il déclenche au tour suivant. Mais ce tour ne porte plus sur une interprétation libre : le clic ne prend que deux valeurs, et l'accord n'est jamais déduit d'une phrase. Cela ne prouve pas la conformité réglementaire de bout en bout. Cela retire une étape où le jugement du modèle avait déjà failli.

Ce qu'un concurrent ne copie pas en changeant de modèle

Rien de cela ne réfute l'étude de Dennis et al. Sur des procédures connues et bornées, un modèle capable piloté en direct peut battre une orchestration mal conçue. Mais un agent de qualification n'est pas jugé sur sa qualité moyenne. Il est jugé sur le pire cas qu'un visiteur réel finira par déclencher, d'une façon que personne n'avait prévue. Sur cet axe, un harnais qui accumule des gardes déterministes, anomalie après anomalie, prend une avance qu'un changement de modèle ne rattrape pas d'un coup.

Le modèle n'est pas le fossé : n'importe qui peut appeler la même API demain. Le fossé, c'est le harnais : l'orchestrateur qui porte la qualification, enrichi de chaque anomalie déjà repérée et corrigée. Chaque garde y est écrite dans le code, donc relisible et testable. Souveraineté et modèles localisés défend la même thèse côté infrastructure et coût d'inférence [3]. Cet article en est le pendant côté orchestration.

[1] Dennis, S., Diamond, M., Patil, R., Shabahang, K., Guo, H. (2026). In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks. arXiv:2604.27891.

[2] Anthropic (décembre 2024). Building Effective Agents.

[3] Gamaro (août 2026). Souveraineté et modèles localisés : le coût caché de l'inférence à l'échelle Leboncoin.