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 même modèle auquel on fournit toute la procédure en contexte peut réellement surpasser une orchestration explicite type LangGraph : une étude publiée en 2026 le mesure noir sur blanc.

• Mais cette amélioration porte sur la qualité moyenne d'exécution, pas sur la garantie qu'un cas précis, déjà rencontré une fois en production, ne se reproduira jamais.

• Dans notre propre historique d'ingénierie, chaque garde qui compte aujourd'hui (anti-répétition, respect d'un refus exprimé, cohérence des règles métier, consentement RGPD) a été ajoutée en code, après un incident réel, précisément parce qu'une instruction de prompt seule s'était montrée contournable.

• Le fossé n'est donc pas la capacité du modèle. C'est l'accumulation de gardes déterministes, individuellement triviales, collectivement impossibles à reconstituer instantanément.

• Pour un agent de qualification commerciale, un cas limite non couvert n'est pas un simple accroc : c'est un prospect qualifié perdu ou une exposition RGPD, pas juste une réponse maladroite.

Le pari du modèle plus fort

L'idée a un charme évident : si le modèle sous-jacent devient assez bon, pourquoi maintenir une machine à états, des centaines de lignes de garde-fous et un moteur d'orchestration fait main ? Il suffirait de mettre toute la procédure dans le prompt système, de brancher quelques serveurs MCP pour l'accès aux données, et de laisser le modèle s'auto-diriger d'un tour à l'autre.

Ce pari n'est pas une intuition en l'air. Une étude publiée en mai 2026 par Dennis, Diamond, Patil, Shabahang et Guo compare, sur le même modèle placé dans les deux configurations, l'exécution en contexte face à des frameworks d'orchestration explicites comme LangGraph, sur des tâches procédurales (réservation de voyage, support technique, traitement de sinistre) [1]. Résultat mesuré : le pilotage en contexte obtient des scores de qualité de 4,53 à 5,00 sur 5, contre 4,17 à 4,84 pour l'orchestration explicite, avec un taux d'échec nettement inférieur (0,5 à 11,5 % contre 9 à 24 %) : l'écart le plus net porte sur le support technique, où l'approche en contexte tombe à 0,5 % d'échec contre 9 % pour l'orchestrateur. Les auteurs sont explicites sur le périmètre : leur conclusion vaut pour des tâches procédurales bien définies, pas au-delà.

C'est un résultat sérieux. Le papier mesure d'ailleurs plus qu'une moyenne : il rapporte aussi, domaine par domaine, des taux d'échec complets. Mais ce qu'il ne mesure pas est plus précis que « la moyenne » : la non-récidive garantie d'une classe d'incident déjà identifiée et explicitement interdite par un garde-fou. C'est cette propriété-là qu'un agent de qualification métier doit prouver.

Ce qu'une moyenne ne garantit pas

Un score de qualité moyen dit ceci : sur un grand nombre de conversations, le modèle suit correctement la procédure la plupart du temps. Il ne dit rien sur un sous-ensemble particulier de conversations, celles où un utilisateur répète une question de façon inattendue, où deux règles métier se contredisent selon la ville visée, où un prospect refuse explicitement de laisser ses coordonnées. Ces cas ne sont pas hypothétiques : ce sont, dans notre propre historique, des incidents réels, chacun découvert en production puis corrigé par une contrainte dédiée.

C'est là que la distinction entre workflow et agent, proposée par Anthropic fin 2024, devient opérante plutôt que théorique : un workflow fait transiter les tâches par des chemins de code prédéfinis, un agent laisse le modèle diriger dynamiquement son propre processus [2]. Un agent au sens plein s'améliore quand le modèle s'améliore. Un workflow, lui, encode une contrainte spécifique, et une contrainte spécifique ne se déduit pas d'un score moyen, aussi élevé soit-il.

Une précision s'impose ici, pour rester fair-play envers Dennis et al. : leur protocole oppose une procédure complète en contexte à un graphe LangGraph qui fragmente tout en nœuds routés. Ce n'est pas exactement l'architecture défendue ici. Il ne s'agit pas de forcer chaque conversation à progresser dans un graphe externe : le modèle garde l'autonomie sur ce qui peut rester probabiliste, et seuls certains invariants, ceux dont la violation a déjà montré un coût réel, sont durcis en code. Le papier remet en cause l'orchestration généralisée ; l'historique de Gamaro plaide pour une orchestration sélective.

Une contrainte de code prime sur une instruction de prompt

Le premier enseignement de l'historique d'ingénierie de Gamaro tient en une phrase : quand une instruction de prompt seule contrôle un comportement, le modèle peut la contourner à nouveau, y compris un modèle qui, par ailleurs, respecte cette même instruction dans l'immense majorité des cas. Nous avons mesuré ce contournement directement, avec une métrique dédiée (crush_rate, le taux auquel l'orchestrateur laisse passer une digression hors-sujet malgré un objectif de conversation en cours). Une désactivation par instruction seule (forceToolUse: false) restait contournable : le modèle réinvoquait malgré tout l'outil. Le correctif qui a tenu a été un levier dur : retirer littéralement l'outil du catalogue de fonctions disponibles pour ce tour, une contrainte que le modèle ne peut pas outrepasser puisqu'elle n'existe simplement plus dans son espace de choix.

Cette même distinction s'est confirmée à nouveau quelques semaines plus tard, à l'occasion de l'évaluation d'un modèle candidat dans le cadre d'un changement de fournisseur. Sous ce modèle précis, crush_rate s'est figé à 1,00 : preuve que l'arbitrage au prompt seul échouait systématiquement, de façon reproductible sur plusieurs séries d'exécutions et températures. Le correctif, cette fois, n'a pas été un nouveau levier dur (il existait déjà) : c'est le classifieur en amont, chargé de déclencher ce levier, qui manquait de rappel, mesuré à 5/8 sur le corpus de diagnostic. Une fois ses libellés enrichis et son rappel porté à 8/8, la métrique est retombée à son niveau attendu. Les deux épisodes racontent la même leçon sous deux angles : l'arbitrage confié uniquement au jugement du modèle est, par construction, dépendant du modèle. Un comportement qui tient avec un LLM donné peut cesser de tenir avec le suivant, silencieusement, sans aucun changement de code.

Une garde par incident, jamais générique à l'avance

Le deuxième enseignement est plus dérangeant pour quiconque espère un jour finir la liste des gardes : les gardes déterministes qui comptent le plus aujourd'hui dans notre historique ont été ajoutées après un incident précis, rarement anticipées de manière abstraite.

Une session de diagnostic a par exemple révélé un agent répétant une question déjà posée deux tours plus tôt, mot pour mot, malgré une réponse différente de l'utilisateur : un motif borné, pas une boucle infinie, mais un motif de répétition bien réel, dont le correctif définitif est passé par une refonte architecturale de l'orchestrateur plutôt que par un simple patch local. Un autre incident, en apparence sans rapport, a immobilisé un parcours multi-villes pendant plusieurs heures : zéro résultat affiché malgré des dizaines d'appels internes, un véritable interblocage entre deux conditions d'activation d'outils qui s'excluaient mutuellement dans une configuration précise, résolu non par un correctif ponctuel mais par une refonte du modèle de données de localisation. Un troisième cas a révélé des libellés de prompt qui ne correspondaient plus aux valeurs réellement acceptées par un outil, corrigé à la fois dans le prompt et par une règle de lint dédiée pour empêcher la récidive automatiquement.

Aucun de ces trois correctifs n'était devinable à l'avance depuis une spécification générale de « bon agent conversationnel ». Chacun encode une leçon tirée d'un cas réel et particulier. Un concurrent qui démarre aujourd'hui avec le meilleur modèle disponible et un jeu de serveurs MCP standard n'hérite d'aucune de ces trois leçons : il devra vraisemblablement faire l'expérience de la plupart de ces incidents à ses dépens, dans son propre système de production, avec ses propres utilisateurs comme détecteurs.

Le refus explicite comme cas limite

Un dernier cas illustre bien pourquoi ce n'est pas seulement une question de qualité de conversation, mais aussi de conformité. Un refus explicite de laisser ses coordonnées, exprimé en langage naturel plutôt qu'en cliquant un bouton dédié, n'était pas toujours honoré de façon fiable : la correspondance exacte utilisée jusque-là ne détectait plus le refus dès qu'il était formulé autrement.

La correction a pris la forme d'un classifieur dédié, activé en repli lorsque la réponse rapide déterministe n'a pas été utilisée. Son seuil de confiance a été fixé volontairement haut (0,85, contre 0,70 pour un classifieur voisin moins critique), sur un arbitrage business assumé : l'état qu'il déclenche est terminal, donc un faux positif coûte un prospect valide perdu silencieusement. Mesuré sur un petit corpus d'évaluation interne dédié (12 cas, dont 5 refus) : précision de 1,00, rappel de 0,60, sans aucun faux positif observé. La contrepartie honnête de ce choix : une partie des refus formulés en texte libre échappe à ce filtre précis, un point de vigilance continue, pas une conclusion acquise sur la conformité du dispositif dans son ensemble.

Le consentement comme état, pas comme jugement

Le même principe s'applique à la conformité RGPD, avec une nuance qui mérite d'être posée avec précision plutôt qu'affirmée en gros. Rien ne rend une conversation pilotée par un LLM automatiquement conforme au seul motif qu'elle contient les bons mots : un modèle peut très bien dire qu'il a noté un consentement sans que ce fait soit structurellement vérifiable après coup.

Là encore, l'histoire commence par un incident précis : la demande de consentement était entièrement déléguée à une instruction de prompt, et un jour, le modèle a clos la conversation sans jamais la poser, alors même que l'outil correspondant restait disponible. Le correctif n'a pas été de réécrire l'instruction plus fermement : c'est devenu une réécriture serveur systématique, qui transforme toute sortie de conversation en une proposition explicite dès qu'un état dédié de la machine à états conversationnelle s'ouvre (email collecté, objectif de conversation atteint, consentement pas encore demandé). Concrètement, deux réponses rapides déterministes s'affichent toujours à ce moment-là, que le modèle les évoque ou non dans sa réponse.

Une nuance honnête s'impose ici : l'affichage de la question est, lui, déterministe et garanti, mais l'enregistrement de la réponse continue de passer par un appel d'outil que le modèle déclenche au tour suivant. La différence avec un simple jugement de modèle est que ce tour-là ne porte plus sur une interprétation libre : le clic ne peut prendre que deux valeurs fixes, pas une phrase libre à interpréter. Ce n'est pas une preuve de conformité réglementaire complète, ce serait une affirmation que rien ici ne permet de soutenir. C'est un argument plus modeste : rendre la question elle-même impossible à sauter silencieusement réduit déjà, de façon vérifiable, le nombre d'étapes où l'interprétation du modèle peut faire défaut.

La capitalisation logicielle comme seule barrière défendable

Rien de tout cela ne réfute l'étude citée plus haut. Elle a raison sur son terrain : pour des procédures connues, bien bornées, un modèle suffisamment capable en pilotage direct peut surpasser une orchestration explicite mal conçue. Mais un agent de qualification métier n'est pas évalué sur sa qualité moyenne : il est évalué sur le pire cas qu'un utilisateur réel va finir par déclencher, un jour, d'une façon que personne n'avait anticipée. C'est précisément l'axe que la moyenne ne mesure pas, et c'est précisément l'axe sur lequel une architecture qui accumule des gardes déterministes, incident après incident, prend une avance qu'aucun changement de modèle ne rattrape d'un coup.

Le fossé concurrentiel n'est donc pas le modèle : n'importe qui peut appeler la même API demain. C'est l'historique d'incidents déjà traversés et déjà encodés en code, plus la structure qui rend chaque garde inspectable après coup plutôt que simplement espérée. Une thèse déjà défendue côté infrastructure et coût d'inférence dans Souveraineté et inférence : modèles locaux [3] ; celle-ci en est le pendant côté orchestration conversationnelle.

[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 (2026). Souveraineté et inférence : modèles locaux.