Choisir un LLM pour un agent IA : une décision d’architecture, pas de classement

Le choix d’un modèle détermine une partie de la qualité, du coût et du délai de réponse de votre application IA. Pourtant, commencer par comparer les modèles les plus visibles conduit souvent à poser le problème trop tôt : vous ne savez pas encore précisément ce que vous leur demanderez.

Ma méthode commence par les tâches. Extraire une référence produit, sélectionner un outil et analyser des documents contradictoires ne présentent pas les mêmes difficultés. Je cherche à identifier le modèle et la configuration qui atteignent le niveau attendu sur chacune de ces opérations, puis à vérifier que l’ensemble reste cohérent en production.

Décomposer le travail avant de choisir

Prenons un exemple illustratif : un assistant destiné à une entreprise de services reçoit une demande, identifie le dossier concerné, consulte son statut et prépare une réponse. Cette demande apparemment simple contient plusieurs décisions distinctes.

L’extraction d’une référence demande de respecter un format et de signaler une information manquante. L’appel d’outil exige de choisir la bonne fonction avec les bons arguments. La rédaction doit restituer les faits sans transformer une estimation en engagement. Les cas litigieux peuvent nécessiter une analyse plus approfondie ou un passage à un collaborateur.

Je formalise ces opérations avec leurs entrées, leurs sorties attendues et leurs conditions d’échec. Le premier livrable utile est donc un contrat de tâche. Il permet d’éviter qu’un excellent résultat rédactionnel masque une mauvaise sélection de dossier.

Comparer des capacités observables

Un benchmark pertinent porte sur ce que votre application attend effectivement du modèle. Je distingue notamment la compréhension de consignes, la sélection d’outils, la précision des arguments et le traitement des informations absentes ou contradictoires.

Pour les sorties structurées, deux contrôles sont nécessaires. Le premier vérifie le format : champs présents, types corrects, valeurs appartenant aux listes autorisées. Le second vérifie le sens. Une date parfaitement conforme au schéma peut être fausse ; une référence bien formée peut désigner le mauvais dossier.

Dans notre exemple, un résultat contenant un identifiant et une catégorie de demande n’est accepté que si l’identifiant est présent dans les éléments autorisés et si la catégorie correspond au message. Lorsque l’information manque, une valeur explicitement absente est préférable à une référence plausible.

Si des pièces jointes entrent dans le périmètre, j’ajoute des documents représentatifs : scans peu lisibles, tableaux, pages multiples et annotations. Je compare alors la chaîne complète de lecture et de traitement. Tester uniquement du texte propre ne permet pas de conclure sur la fiabilité du parcours documentaire.

Construire un jeu d’essai qui permet de décider

Je recommande un ensemble de cas issus de vos usages, anonymisés si nécessaire, avec des résultats attendus validés par une personne compétente du métier. Il doit inclure les demandes courantes, les exceptions et les situations dans lesquelles l’application doit s’abstenir.

Les cas servant à ajuster les instructions sont séparés de ceux utilisés pour la décision finale. Sinon, on risque de sélectionner la configuration la mieux adaptée aux exemples déjà travaillés. Pour les scénarios sensibles, plusieurs exécutions permettent d’observer la variabilité au lieu de retenir une réponse particulièrement réussie.

Chaque essai conserve la version du modèle, les instructions, les outils disponibles et leurs résultats. Sans ces éléments, une comparaison devient difficile à reproduire. J’approfondis cette démarche dans mon article sur l’évaluation d’un agent en production.

Mesurer le coût par tâche réussie

Le prix affiché pour un volume de tokens donne une indication, mais ne représente pas le coût du service. Je prends en compte les appels supplémentaires, les reprises après erreur, les outils externes, l’hébergement éventuel et le temps de traitement humain.

Le calcul utile consiste à rapporter ce coût complet au nombre de tâches correctement terminées. Un modèle économique à l’appel peut perdre son avantage s’il multiplie les tentatives. Un modèle plus coûteux peut être justifié sur une étape difficile, tout en étant superflu sur les autres.

La latence se mesure également sur le parcours complet. Je regarde la médiane, mais aussi un percentile élevé comme le p95, qui représente le délai sous lequel se terminent 95 % des exécutions mesurées. Une bonne moyenne peut masquer des attentes pénibles sur les demandes les plus complexes.

Un budget de raisonnement plus important peut augmenter le travail de génération. Son intérêt dépend du gain de qualité obtenu dans votre configuration ; je le traite comme un paramètre à tester, plutôt que comme une propriété systématiquement souhaitable.

Quand utiliser plusieurs modèles

Une architecture peut réserver les tâches simples à un modèle compact et orienter les cas difficiles vers un modèle plus capable. Le routage entre catégories de demandes est un pattern documenté, avec un arbitrage entre qualité et coût. Guide d’architecture d’Anthropic.

Ce routage apporte toutefois ses propres erreurs. Je préfère commencer avec une configuration de référence, puis introduire une spécialisation quand les mesures la justifient. Une mauvaise classification initiale peut annuler le bénéfice attendu.

Le papier Small Language Models are the Future of Agentic AI, publié par des chercheurs notamment affiliés à NVIDIA, défend la pertinence des petits modèles pour de nombreuses tâches spécialisées. C’est une position argumentée, pas une garantie de performance ou d’économie applicable à tout projet. Article de recherche.

Intégrer l’hébergement à la décision

Un modèle aux poids disponibles peut ouvrir la possibilité d’un hébergement maîtrisé, sous réserve de sa licence et de vos moyens techniques. Cette disponibilité ne garantit à elle seule ni la souveraineté, ni un coût inférieur. L’exploitation, les mises à jour, la capacité matérielle et les compétences nécessaires font partie du calcul.

Avec un service distant, je vérifie les contraintes du projet : localisation des traitements, politique de conservation, disponibilité, limites de débit et conditions de changement de version. Ce sont des critères de sélection à documenter avec les fournisseurs, au même titre que la qualité des réponses.

Chez LeoWeb, je propose de transformer ce choix en décision vérifiable : tâches définies, jeu d’essai métier, comparaison des configurations et recommandation chiffrée sur votre volume. Si vous hésitez entre plusieurs modèles ou si votre facture augmente sans amélioration nette, échangeons sur les mesures à mettre en place.