Agents IA : choisir son LLM sur des mesures

Le modèle d'IA, une décision d'architecture

Dans beaucoup d'entreprises, le choix du grand modèle de langage (LLM) qui pilote un agent IA se fait encore sur la réputation : un classement en ligne, un avis enthousiaste, une démonstration convaincante. Le modèle reçoit des instructions, appelle des outils, met à jour un CRM, classe des e-mails ou extrait des données de factures. S'il se trompe, c'est un processus métier qui s'arrête.

Cet article s'appuie sur un banc d'essai publié par une agence spécialisée dans l'automatisation des workflows, intitulé en anglais « AI Agent Development: LLM Benchmark [Tested by Us] » (aucun auteur individuel n'est mentionné). Ses auteurs y dénoncent ce qu'ils appellent l'architecture IA « au ressenti » et proposent une méthode reproductible pour évaluer les modèles à l'intérieur d'un agent. Nous n'allons pas le résumer : nous partons des problèmes qu'il soulève pour expliquer comment comm.it transforme ces enjeux en solutions concrètes pour ses clients, TPE et PME.

Pourquoi un agent IA échoue en production

Un LLM interrogé seul dans une fenêtre de discussion ne se comporte pas comme un LLM intégré à une chaîne d'automatisation. Dans un workflow, il est contraint par un format, des outils et une mémoire. Le banc d'essai met en évidence plusieurs points de rupture que nous retrouvons sur le terrain.

Le respect des schémas JSON

Lorsqu'un agent dispose d'un outil (interroger une base de données, appeler une API, déclencher un sous-processus), la plateforme d'automatisation décrit les paramètres de cet outil sous forme de schéma JSON. Le modèle doit renvoyer un objet parfaitement conforme : champs obligatoires présents, structure imbriquée respectée, caractères correctement échappés. Une seule erreur et l'appel échoue.

Les sorties non exploitables

Les étapes suivantes d'un workflow attendent une réponse dans un format prévisible. Certains modèles ajoutent pourtant des formules de politesse ou encadrent leur réponse de balises de mise en forme, même quand on le leur interdit. Le parseur de sortie structurée ne parvient alors plus à lire la réponse et le processus s'interrompt.

La mémoire qui sature

Au fil des échanges, la fenêtre de contexte se remplit de messages et de résultats d'outils. Certains modèles « oublient » alors les consignes initiales ou des données obtenues plusieurs étapes plus tôt : c'est le phénomène dit du « lost in the middle ».

La latence

Pour un agent conversationnel face à un client, le délai avant le premier mot compte. Pour un traitement en arrière-plan, seule la durée totale importe. Les modèles ne sont pas optimisés de la même manière pour ces deux usages.

La lecture d'images

Extraire les lignes d'un ticket de caisse photographié ou classer un document scanné repose sur les capacités multimodales du modèle, qui varient sensiblement d'un fournisseur à l'autre.

La reprise sur erreur

Quand une API renvoie une erreur, un bon agent lit le message, corrige ses paramètres et réessaie. Un modèle moins capable répète la même requête erronée jusqu'à atteindre la limite d'itérations : on paie des appels sans aucun résultat.

Mesurer plutôt que deviner

L'apport le plus intéressant de ce banc d'essai est méthodologique. Ses auteurs ont construit une suite de 20 tâches fixes, réparties en cinq familles :

• extraction structurée d'informations depuis des e-mails désordonnés ;
• classification et routage de tickets de support selon des nuances d'intention ;
• planification en plusieurs étapes (rechercher, calculer, mettre en forme) ;
• reprise sur erreur, avec un outil volontairement configuré pour échouer au premier essai ;
• rappel en contexte long, après injection d'un grand volume de données en mémoire.

Chaque tâche est exécutée trois fois par modèle, avec des consignes et des outils identiques, et notée en réussite ou échec, sans demi-mesure.

Le bon indicateur : le coût par tâche réussie

La grille tarifaire d'un fournisseur indique le prix d'un token, pas celui d'un résultat. Un modèle bon marché qui a besoin de trois tentatives pour produire un JSON valide peut finalement coûter plus cher qu'un modèle premium qui réussit du premier coup. D'où l'indicateur central retenu : le coût par tâche réussie, qui divise la dépense totale (essais ratés et relances compris) par le nombre de tâches effectivement accomplies.

Le banc d'essai suit aussi :

• la latence médiane (p50) et la latence de queue (p95) ;
• le taux de sorties malformées ;
• le taux d'erreurs d'appel d'outil (paramètres manquants, outils inventés) ;
• la fréquence des relances avant d'obtenir la réponse finale.

Ce que montrent les résultats

Les mesures datent d'août 2024 et portent sur des versions précises de modèles, aujourd'hui en partie remplacées. Les chiffres valent donc surtout comme illustration de la méthode :

• Claude 3.5 Sonnet obtient le meilleur taux de réussite global (96,6 %), pour un coût par tâche réussie de 0,0142 dollar, et aucune sortie malformée. Face à une erreur 400, il a corrigé sa requête dans 98 % des cas.
• GPT-4o offre la latence médiane la plus basse parmi les modèles premium (2,8 secondes pour une exécution complète en plusieurs étapes) et se montre plus précis sur l'extraction visuelle. Il lui arrive en revanche de boucler en répétant la même requête erronée.
• GPT-4o-mini ne réussit que 78,3 % des tâches complexes, mais atteint 98 % sur la classification et l'extraction isolées, pour un coût par tâche réussie de 0,0011 dollar.

La leçon est claire : il n'existe pas de meilleur modèle dans l'absolu, seulement un modèle adapté à une tâche donnée.

Le routage entre modèles : payer le premium seulement quand c'est utile

Les architectures les plus efficaces ne reposent pas sur un modèle unique. Le banc d'essai décrit deux schémas que nous appliquons dans nos projets d'automatisation des processus métier.

Commencer petit, escalader si nécessaire

Un premier modèle, économique, traite la demande et renvoie, en plus de sa réponse, un score de confiance. Une condition dans le workflow vérifie ce score : s'il est élevé, le traitement continue ; s'il est trop bas (le banc d'essai retient un seuil de 85 sur 100), la demande est transmise à un modèle plus puissant. Les cas simples, souvent majoritaires, ne mobilisent jamais le modèle coûteux.

La branche de secours

Si le modèle principal échoue (JSON invalide, boucle d'itérations), une branche de gestion d'erreur récupère l'ensemble du contexte et le confie à un agent de secours plus capable. Le processus aboutit, même quand le premier niveau trébuche.

Les leviers de maîtrise des coûts

Le choix du modèle ne suffit pas. Un agent mal configuré peut consommer un budget d'API considérable en peu de temps. Le banc d'essai insiste sur plusieurs leviers.

• La mise en cache des prompts. Les principaux fournisseurs la proposent, à condition de regrouper les parties statiques du prompt. Un horodatage injecté en tête de consigne invalide le cache à chaque exécution et annule l'économie.
• L'élimination des appels en double. Un agent mal guidé peut appeler plusieurs fois le même outil de récupération de données au cours d'une exécution. Une consigne explicite lui demande d'utiliser d'abord ce qui figure déjà dans son contexte.
• Le plafonnement des itérations. Trois ou quatre itérations suffisent, selon le banc d'essai, pour savoir si un agent va réussir ; au-delà, on consomme sans changer l'issue.
• La limitation des tokens de sortie. Quand seule une réponse JSON est attendue, inutile de laisser le modèle produire de longs raisonnements.

Changer de modèle sans casser la production

Les modèles évoluent vite et un changement de fournisseur peut devenir nécessaire. Ce n'est pas qu'une question d'identifiants : chaque modèle réagit différemment aux mêmes consignes. Le banc d'essai note par exemple que les modèles d'Anthropic répondent mieux à des balises de structure de type XML, tandis que ceux d'OpenAI préfèrent une mise en forme Markdown. La démarche recommandée :

1. dupliquer le workflow et ne jamais tester en production ;
2. réécrire les consignes dans la syntaxe préférée du nouveau modèle ;
3. mener un test fantôme sur des données historiques pour comparer les résultats ;
4. procéder à un déploiement progressif, sur une fraction du trafic, avant de retirer l'ancien modèle.

Selon ses auteurs, une telle migration prend généralement une à deux semaines, selon la complexité des outils de l'agent.

Comment comm.it crée de la valeur à partir de ces enjeux

Ces principes concernent aussi bien les grands groupes que les TPE et PME : ce sont même ces dernières qui ont le moins de marge pour absorber un agent défaillant ou une facture d'API qui dérape. Voici comment nous les mettons en œuvre.

Partir du processus, pas du modèle

Nous commençons par cartographier le processus métier à automatiser : traitement des demandes entrantes, qualification de prospects, mise à jour du CRM ou de l'ERP, rapprochement de documents. Nous identifiant ensuite les étapes où l'IA apporte réellement quelque chose et celles où une règle simple suffit. Toutes les tâches n'ont pas besoin d'un agent : une chaîne d'appels déterministe est souvent plus fiable et moins coûteuse.

Construire votre propre jeu de tests

Les résultats publiés ailleurs ne remplacent pas un test sur vos données. Comme le recommande le banc d'essai, nous constituons un jeu de cas représentatifs de votre activité, avec la réponse attendue pour chacun. Un workflow d'évaluation les soumet en boucle à l'agent, fait juger les réponses par un modèle évaluateur et consigne pour chaque cas la réussite, la durée et la consommation de tokens. Vous disposez alors d'une base objective pour choisir un modèle, puis pour vérifier qu'une mise à jour ne dégrade rien.

Concevoir des architectures robustes

Nous intégrons dès la conception :

• le routage entre modèles selon la difficulté de la tâche ;
• des branches de secours pour garantir que le processus aboutit ;
• la validation systématique des sorties avant toute écriture dans vos outils métier ;
• des plafonds d'itérations et de tokens adaptés à chaque étape.

L'objectif : qu'une réponse mal formée ne vienne jamais corrompre votre base clients ou votre comptabilité.

Relier l'IA à votre infrastructure

Un agent IA dépend des systèmes qu'il interroge. Notre expertise en réseau, en messagerie et en développement de logiciels cœur de métier nous permet de traiter l'ensemble de la chaîne : accès sécurisé aux API internes, gestion des droits, connexion aux boîtes mail, intégration aux CRM et ERP existants ou développés sur mesure. Nous privilégions, lorsque c'est pertinent, des briques open source auto-hébergées, qui vous laissent la maîtrise de vos données et de vos coûts.

Suivre et faire évoluer

Une automatisation IA n'est jamais figée. Nous mettons en place un suivi des indicateurs (taux de réussite, latence, coût par tâche réussie) et accompagnons les migrations de modèles selon la démarche progressive décrite plus haut : duplication, adaptation des consignes, test sur données historiques, bascule par étapes.

En résumé

• Le choix d'un LLM pour un agent IA est une décision d'architecture, qui doit reposer sur des mesures.
• Le bon indicateur n'est pas le prix du token mais le coût par tâche réussie.
• Chaque modèle a ses points forts : fiabilité des appels d'outils, rapidité, lecture d'images ou faible coût sur les tâches simples.
• Le routage entre modèles, les branches de secours et les plafonds d'exécution permettent de concilier fiabilité et budget.
• Changer de modèle se prépare : tests, adaptation des consignes et déploiement progressif.

Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

Source : n8n AI Agent Development: LLM Benchmark Tested by Us