Le bon modèle pour la bonne tâche : arbitrer la puissance sans surdimensionner

Dans la plupart des projets d'agents que nous reprenons, le diagnostic technique tient en une phrase : tout passe par le même modèle. Le plus puissant disponible, appelé pour extraire une date de facture comme pour arbitrer un litige client. C'est confortable à construire, coûteux à exploiter, et surtout impossible à optimiser ensuite — parce que personne n'a jamais documenté pourquoi ce choix avait été fait.

L'arbitrage de puissance n'est pas un sujet de coût. C'est un sujet d'architecture. Et comme tout choix d'architecture, il doit être explicite, justifié et révisable.

Un agent n'est pas une tâche, c'est une chaîne de tâches

Quand un dirigeant décrit un agent — « il traite les demandes clients entrantes » —, il décrit un résultat. L'ingénieur, lui, voit une séquence : lire le message, identifier l'intention, extraire les données utiles, chercher l'information dans le système métier, décider de la réponse, la rédiger, la router vers le bon interlocuteur.

Sept étapes. Sept besoins cognitifs différents :

• Extraction structurée (numéro de commande, date, montant) : tâche déterministe, tolérance à l'erreur quasi nulle, aucun raisonnement requis. Un petit modèle, correctement contraint par un schéma de sortie, fait le travail.
• Classification (réclamation, demande d'information, résiliation) : quelques dizaines de catégories, des exemples de référence. Un modèle intermédiaire suffit, parfois même un classifieur classique.
• Reformulation : transformer une information brute en réponse lisible dans le ton de l'entreprise. Ni complexe ni risqué, à condition que le contenu soit déjà validé en amont.
• Arbitrage : cas ambigu, informations contradictoires, exception au processus. Là, on a besoin de raisonnement, de capacité à peser, à dire « je ne sais pas ». C'est ici que le modèle haut de gamme se justifie.

Appeler le modèle le plus puissant pour les sept étapes, c'est payer un raisonnement de niveau expert pour lire une date. Mais le problème n'est pas que financier : un modèle très capable est aussi plus créatif, donc plus susceptible d'interpréter là où on attendait une extraction littérale. Le surdimensionnement introduit de la variance là où on voulait de la fiabilité.

Router, c'est décider — et documenter la décision

Le routage par tâche n'est pas un réglage fin de fin de projet. C'est une décision de conception, prise au moment où l'on découpe l'agent en étapes. Pour chaque nœud de la chaîne, trois questions :

• Quelle est la tolérance à l'erreur ? Une extraction fausse qui alimente un ERP n'a pas le même coût qu'une reformulation maladroite relue par un humain.
• Quelle est la variabilité de l'entrée ? Un formulaire structuré et un email libre n'exigent pas la même robustesse.
• Y a-t-il un jugement à rendre ? Si l'étape se résume à appliquer une règle, la règle doit être dans le code, pas dans le prompt.

Ce troisième point mérite insistance. Une partie significative de ce qu'on confie aux modèles relève de logique métier explicite : seuils, conditions, tables de correspondance. Le meilleur modèle pour ces tâches, c'est souvent pas de modèle du tout. Une fonction déterministe est plus rapide, moins chère, testable unitairement et auditable. L'arbitrage de puissance commence par se demander si l'IA est nécessaire à cette étape.

Le vrai risque : le choix implicite

Le paysage des modèles bouge tous les trimestres. Ce qui exigeait un modèle de pointe il y a dix-huit mois tourne aujourd'hui sur un modèle intermédiaire, souvent hébergeable en Europe. Ce qui coûtait cher devient marginal.

Une architecture qui a figé ses choix sans les documenter ne peut pas profiter de ces évolutions. Personne ne sait plus pourquoi tel appel utilise tel modèle, donc personne n'ose y toucher. Le système se sédimente.

C'est pourquoi le plan d'architecture que nous remettons à nos clients comporte, pour chaque étape d'agent, une ligne d'arbitrage écrite : le niveau de modèle retenu, le critère qui a motivé ce choix, les alternatives évaluées, et le seuil à partir duquel il faudrait reconsidérer. Ce document appartient au client. Il lui permet de challenger nos choix, de les faire réviser par un tiers, ou de reprendre la main intégralement.

Techniquement, cela suppose une couche d'abstraction : le code métier appelle une fonction « extraire les champs », pas « appeler tel modèle de tel fournisseur ». Changer de modèle devient une modification de configuration, pas une réécriture. La réversibilité n'est pas une clause contractuelle, c'est une propriété du code.

Un cas concret

Une ETI industrielle de 340 personnes, traitement des demandes de prix entrantes. Volume : environ 180 demandes par jour, arrivant par email, formulaire web et EDI client.

Architecture initiale héritée d'un prototype : un appel unique au modèle le plus puissant disponible, qui lisait le message et produisait un devis. Résultat : temps de réponse moyen de 14 secondes, et surtout des références produit inventées dans environ 4 % des cas — assez rare pour passer les tests, assez fréquent pour générer des litiges.

Après découpage : extraction des références et quantités par un petit modèle contraint par schéma, avec vérification systématique contre le référentiel produit (fonction déterministe, zéro modèle). Calcul de prix par les règles tarifaires existantes de l'ERP. Modèle intermédiaire pour la mise en forme commerciale. Modèle haut de gamme réservé aux demandes non résolues à l'étape 1 — environ 11 % du volume — avec escalade humaine si le niveau de confiance reste bas.

Références inventées : zéro, par construction, puisque toute référence non présente au référentiel déclenche une escalade. Temps de réponse médian : 3 secondes. Coût d'inférence mensuel divisé par environ six. Et surtout : un document qui explique pourquoi chaque étape est configurée ainsi, relu par le DSI, révisé une fois depuis.

Ce que cela change pour un dirigeant

Vous n'avez pas à arbitrer entre des modèles. Vous avez à exiger que l'arbitrage existe, qu'il soit écrit, et qu'il vous appartienne. Une infrastructure agentique dont vous ne pouvez pas changer les composants n'est pas une infrastructure, c'est une dépendance.