Le problème
Sur une instance LIA, des dizaines de tâches font appel à un modèle de langage : comprendre ta demande, planifier, répondre, résumer une réunion, écrire ton journal, préparer une notification. Un administrateur doit pouvoir changer le modèle de l'une d'elles, parce qu'un fournisseur augmente ses prix, qu'un modèle plus récent sort ou qu'une tâche répond mal.
Si ce changement passe par un fichier de configuration et un redémarrage, on hésite à le faire. S'il passe par un formulaire qui accepte n'importe quoi, on finit par enregistrer une combinaison que le fournisseur refusera à chaque appel. Et si rien ne borne la dépense, une instance ouverte à plusieurs comptes peut coûter bien plus que prévu.
Ce que je voulais
Je voulais un seul endroit pour ces réglages, un effet immédiat et un écran qui ne propose que ce qui marchera. Je voulais aussi que la dépense ait deux plafonds clairs : celui de chaque compte et celui de l'instance entière.
Comment ça marche
Chaque tâche a des valeurs par défaut écrites dans le code et éprouvées. Dans Administration › Configuration LLM, l'administrateur peut les remplacer, tâche par tâche : fournisseur, modèle, température, budget de réponse, délai, profondeur de réflexion. Ce remplacement est enregistré en base et s'applique aux opérations suivantes, sans redémarrage. Le bouton « Réinitialiser » l'efface et revient au défaut du code. Il n'existe pas de troisième source cachée : un ancien réglage de modèle resté dans un fichier d'environnement est ignoré.
L'écran sert aussi de garde-fou :
- Il ne propose que les niveaux de réflexion que le modèle choisi accepte, et masque les réglages que ce modèle ne sait pas recevoir.
- Un budget de réponse est tenu au plafond de sortie connu du modèle. Si tu passes à un modèle plus limité, LIA envoie le plus petit des deux chiffres et le signale.
- Une réflexion profonde avec un budget de réponse trop petit est refusée à l'enregistrement : la réflexion occuperait toute la place et la réponse arriverait vide.
Ce que chaque modèle sait faire (outils, images, sortie structurée, plafonds) vient d'un catalogue tenu à partir de registres publics, et chaque ligne dit d'où viennent ses valeurs : un défaut que personne n'a vérifié, une valeur importée ou une valeur confirmée par un humain. Un modèle n'est désactivé que si la date d'arrêt annoncée par son fournisseur est passée et qu'aucune tâche ne l'utilise encore.
Le coût, tâche par tâche
Ce découpage permet d'optimiser finement. Par exemple, le tri des demandes tourne sur un petit modèle économique, le planificateur sur un modèle plus cher mais plus fiable, l'extraction des souvenirs sur un modèle local gratuit. Les prix vivent dans un catalogue de tarifs qui connaît aussi les heures creuses des fournisseurs qui en proposent : chaque appel est compté au tarif de son instant. Chaque appel garde le modèle réellement utilisé et les paramètres envoyés, et les tableaux de bord permettent de comparer les tâches entre elles.
Deux plafonds pour la dépense
Chaque compte peut avoir ses limites, en jetons, en messages et en coût, par cycle mensuel ou au total. Mais additionner des comptes ne borne pas une instance. L'opérateur peut donc fixer un budget journalier de l'instance, que l'administrateur peut resserrer depuis l'interface sans pouvoir l'élargir : c'est la plus petite des deux valeurs qui s'applique.
Les deux plafonds ne réagissent pas de la même façon à une panne. Si la base ne répond pas, une limite de compte laisse passer un message de trop. Une dépense d'instance inconnue, elle, bloque, parce que le pire cas de ce côté est le budget entier. Le refus dit ce qui se passe : une pause de l'instance, avec l'heure à laquelle elle se lève. Tu ne crois donc pas avoir épuisé ton propre quota. En arrière-plan, une tâche refusée est notée comme sautée, ce qui évite de chercher une panne qui n'existe pas.
Les limites
- Un changement s'applique aux opérations suivantes : une opération déjà commencée peut garder la configuration avec laquelle elle a démarré.
- Un prix du catalogue est une référence. La facture réelle reste celle du fournisseur, qui applique parfois des règles que LIA ne sait pas exprimer, comme un tarif plus élevé au-delà d'une certaine taille de requête.
- Certaines petites décisions, comme classer un e-mail, peuvent être confiées à un modèle de décision spécialisé. Chaque usage a son interrupteur, éteint par défaut. En cas de doute, LIA reprend son parcours habituel, et une telle décision n'autorise aucune action à elle seule.
Pour approfondir : Un modèle pour chaque tâche, chez le fournisseur de ton choix ; Modifier tout le catalogue de modèles dans un tableur, sans risque.