Comment choisir le bon modèle pour son agent IA ?

Le modèle est le moteur d’un agent IA. Il comprend les instructions, analyse les informations, choisit éventuellement un outil et produit une réponse ou une action. Il influence donc la qualité du résultat, le temps de traitement et le coût de chaque exécution.

Pourtant, choisir le modèle qui obtient le meilleur score général est rarement une bonne méthode. Un agent qui résume des demandes clients, prépare un document ou recherche une information n’a pas les mêmes exigences qu’un agent chargé de modifier du code. Le meilleur choix dépend d’abord de la tâche.

Je recommande d’utiliser les classements publics pour présélectionner quelques candidats, puis de les comparer sur vos propres cas d’usage. Les benchmarks orientent la recherche. Votre évaluation métier prend la décision.

Pourquoi le modèle le plus intelligent n’est pas toujours le meilleur

Un score d’intelligence agrège plusieurs capacités. Il permet de situer un modèle, mais il ne dit pas à lui seul s’il répondra à votre besoin, dans le délai attendu et à un coût acceptable.

Quelques points peuvent nécessiter davantage de raisonnement, produire plus de tokens et ralentir l’exécution. Cette différence reste parfois justifiée : une erreur dans une analyse financière ou dans la modification d’un document sensible peut coûter plus cher que l’appel au modèle. Pour une tâche simple, répétitive et contrôlable, le même niveau de performance peut au contraire être inutile.

Le volume amplifie cet arbitrage. Une différence de quelques centimes semble négligeable sur un test. Elle devient importante lorsqu’un agent traite des milliers de demandes, appelle plusieurs fois le modèle pendant une exécution ou recommence après l’échec d’un outil.

Le bon modèle n’est donc pas le plus puissant dans l’absolu. C’est celui qui atteint le niveau de qualité nécessaire avec un coût, une vitesse et un niveau de risque compatibles avec votre activité.

Partir de la tâche confiée à l’agent

Avant d’ouvrir un comparateur, décrivez ce que l’agent doit accomplir. Une formulation comme « répondre aux clients » est trop générale pour sélectionner un modèle. Il faut préciser les entrées, les actions autorisées et le résultat attendu.

Je commence par les questions suivantes :

• quelles informations l’agent reçoit-il et dans quelles langues ?
• doit-il seulement rédiger, ou aussi rechercher des données et utiliser des outils ?
• quel résultat permet de considérer la tâche comme réussie ?
• quelles erreurs sont acceptables et lesquelles sont bloquantes ?
• une personne valide-t-elle la réponse avant son utilisation ?
• combien de tâches seront traitées et dans quel délai ?
• les données sont-elles personnelles, confidentielles ou soumises à une politique interne ?

Ces réponses transforment une préférence abstraite pour un modèle en critères observables. Un agent utilisé en arrière-plan peut accepter plusieurs minutes de traitement. Une assistance en direct exige une première réponse rapide. Une tâche à faible risque peut privilégier le coût. Une décision sensible peut imposer une validation humaine et un niveau de qualité plus élevé.

Présélectionner les modèles grâce aux benchmarks

Artificial Analysis permet de comparer des modèles selon leur intelligence, leur coût et leurs performances. La version 4.1 de son Intelligence Index rassemble neuf évaluations couvrant notamment le travail agentique avec livrables, l’utilisation d’outils, le code, le raisonnement scientifique, les connaissances, les hallucinations et le long contexte.

L’index accorde une place importante aux tâches agentiques, ce qui le rend intéressant pour une première sélection. Sa méthodologie précise toutefois deux limites essentielles : la suite est en anglais et porte sur des tâches textuelles. Elle ne représente pas automatiquement votre langue, vos documents, vos outils ou vos règles métier.

Il est donc préférable d’observer les évaluations les plus proches de votre besoin plutôt que le seul score global. Pour un agent qui produit des fichiers, une évaluation de livrables sera plus informative qu’un test scientifique. Pour un agent qui exécute des commandes ou appelle des outils, les performances agentiques et de code méritent davantage de poids.

Comparer la qualité, le coût et la vitesse

Le prix par million de tokens est utile pour comprendre la tarification d’une API, mais il ne suffit pas pour estimer le coût réel d’un agent. Deux modèles peuvent recevoir la même consigne et utiliser des quantités de raisonnement ou de réponse très différentes.

La métrique Cost per Task d’Artificial Analysis rapproche le coût de l’unité qui nous intéresse : une tâche évaluée. Elle tient compte des tokens d’entrée, de réponse, de raisonnement et de cache utilisés dans les évaluations, puis applique la pondération de l’index.

Dans cette capture, GPT-5.6 Sol (effort maximal) obtient un score de 59 pour 1,86 dollar par tâche, tandis que Claude Fable 5 (Adaptive Reasoning, Max Effort, avec Opus 4.8 en repli) atteint 60 pour 3,15 dollars. Un point sépare leurs scores globaux, mais le second coûte environ 1,7 fois plus cher sur cette mesure. Ce résultat n’établit pas que l’un est toujours préférable : il montre pourquoi qualité et coût doivent être lus ensemble, à une date donnée.

La vitesse constitue un troisième axe. Artificial Analysis publie un temps de génération moyen par tâche, calculé à partir du nombre de tokens produits et de la vitesse de sortie. D’après sa définition, cette mesure exclut le temps avant le premier token et les autres surcoûts de bout en bout. Un agent ajoute aussi les appels d’outils, les recherches, les validations et le réseau.

Dans la capture, le temps allait d’environ 0,6 à 11,8 minutes selon les modèles en tête de l’analyse, soit un écart proche de vingt. Cette différence peut être invisible dans un traitement nocturne, mais rédhibitoire dans une conversation avec un client.

Vérifier l’hébergement et les contraintes de données

La performance ne décide pas seule en entreprise. Il faut aussi vérifier qui traite les données, dans quelle région, avec quels sous-traitants, pendant combien de temps et pour quels usages.

L’Openness Index d’Artificial Analysis mesure la disponibilité des poids, les licences et la transparence sur les données ou la méthode d’entraînement. Il ne mesure pas la souveraineté et ne garantit pas la localisation des requêtes. Un modèle ouvert peut être appelé chez un fournisseur situé hors d’Europe ; un modèle propriétaire peut être proposé dans une région européenne.

Pour des données personnelles, la Commission européenne rappelle que les transferts hors de l’Espace économique européen doivent reposer sur les mécanismes et garanties prévus. Le guide du Comité européen de la protection des données insiste également sur le choix du sous-traitant, le contrat, la sécurité, les sous-traitants ultérieurs et les transferts internationaux.

Une région européenne ou un hébergement interne peut faciliter certains choix, mais ne suffit donc pas à garantir la conformité au RGPD. Il faut examiner le traitement complet et, si nécessaire, faire valider l’analyse par la personne responsable de la protection des données ou par un conseil compétent.

Tester les modèles sur vos propres cas d’usage

Après la présélection, construisez un jeu d’évaluation représentatif. Il doit contenir des cas courants, des cas difficiles et des situations dans lesquelles l’agent doit refuser ou demander une validation.

Pour chaque exemple, définissez ce qui sera mesuré : exactitude des informations, respect du format, choix du bon outil, qualité du livrable, absence d’action interdite, coût total et temps de traitement. Utilisez les mêmes instructions, données et outils pour tous les candidats afin que la comparaison reste utile.

Une évaluation réaliste ne s’arrête pas au texte final. Elle vérifie le déroulement complet : l’agent a-t-il appelé la bonne fonction, transmis les bons paramètres, interprété correctement le résultat et réagi proprement à une erreur ? Les échecs les plus coûteux se cachent souvent dans cette chaîne.

Commencez avec quelques dizaines de cas bien choisis plutôt qu’avec une grande collection mal définie. Ajoutez ensuite les incidents rencontrés en production. Le jeu de tests devient ainsi une mémoire de vos exigences et permet de réévaluer rapidement un nouveau modèle ou une nouvelle version.

Construire une grille de décision

Une grille permet de rendre l’arbitrage explicite. Les poids doivent refléter votre activité, pas les préférences de l’équipe technique.

Éliminez d’abord les modèles qui ne respectent pas les contraintes incontournables. Comparez ensuite les candidats restants selon leur rapport qualité, coût et vitesse. Il est également possible d’utiliser plusieurs modèles : un modèle économique pour les tâches simples et un modèle plus capable uniquement lorsque la difficulté ou le risque le justifie.

Le meilleur modèle est celui qui réussit votre tâche

Les classements publics permettent de comprendre le marché et d’éviter de tester des centaines de possibilités. Ils restent une photographie construite à partir de tâches, d’une méthode et d’une date précises.

Pour choisir un modèle d’agent IA, partez de votre tâche, présélectionnez quelques candidats, vérifiez les contraintes de données, puis mesurez le résultat complet sur vos propres exemples. Le choix devient une décision documentée et révisable, plutôt qu’un pari sur le modèle le plus connu ou le score le plus élevé.

Sources

• Artificial Analysis Intelligence Index v4.1
• Méthodologie de l’Intelligence Index
• Comparateur de modèles et métriques par tâche
• Méthodologie de l’Openness Index
• Commission européenne — transferts de données hors de l’Union européenne
• Comité européen de la protection des données — responsable et sous-traitant
• Thread à l’origine de cet Article