Routeur de tâches IA : confidentialité et coût

Une extraction de facture, un résumé commercial urgent et une analyse contractuelle sensible ne devraient pas suivre le même chemin. Pourtant, un prototype envoie souvent toutes ces missions au modèle le plus avancé, avec le même contexte et les mêmes outils.

Un routeur de tâches IA est la couche de contrôle placée avant l’exécution. Il qualifie la mission, applique les règles de confidentialité, puis choisit une règle déterministe, un environnement autorisé, un niveau de modèle ou une vérification humaine.

Son objectif n’est donc pas de trouver « le meilleur modèle » dans l’absolu. Il distribue chaque tâche selon la confidentialité des données, la puissance réellement nécessaire, le coût acceptable, la vitesse attendue et le risque d’erreur.

Le routeur ne prend pas une décision commerciale à la place de l’équipe. Il prépare le traitement, bloque les chemins interdits et soumet les cas sensibles à une validation humaine traçable.

Ce que l’entreprise paie réellement

Les modèles de langage traitent du texte sous forme de tokens. Un token correspond à un fragment de mot, un signe de ponctuation ou une petite unité de texte. Le nombre obtenu varie selon la langue, le contenu et le tokenizer du modèle. Les documentations de comptage OpenAI et Anthropic recommandent de compter la requête avec le modèle réellement visé, notamment lorsqu’elle contient des outils, des images ou des fichiers.

La facture ne dépend pas seulement du message écrit par l’utilisateur. L’entrée peut aussi contenir :

les instructions permanentes de l’agent ;
l’historique de la conversation ;
les descriptions des outils disponibles ;
des extraits de CRM, documents, emails ou bases de connaissances ;
des images ou des PDF selon le service utilisé.

Il faut ensuite ajouter les tokens générés en sortie, les éventuels appels d’outils, les recherches externes et les nouvelles tentatives lorsque la première réponse échoue.

On peut résumer le coût d’une mission ainsi :

coût de la mission = entrée non cachée × tarif + lecture du cache × tarif de lecture + écriture du cache × tarif d’écriture, si applicable + sortie facturée × tarif de sortie + frais d’outils + coût des reprises

Chaque élément peut avoir son propre tarif. La sortie facturée peut aussi inclure des tokens de structure ou de raisonnement qui ne figurent pas mot pour mot dans le texte affiché. Le suivi doit donc utiliser les champs usage retournés par l’API, pas une estimation fondée uniquement sur les caractères visibles.

Les pages de prix montrent aussi un écart important entre les modèles légers et les modèles les plus avancés. Utiliser le niveau maximal partout peut donc multiplier le budget sans créer de valeur supplémentaire.

Pourquoi les consommations dérivent

Les dépassements ne viennent pas toujours d’un grand volume d’utilisateurs. Ils viennent souvent d’une architecture qui ne limite rien.

Un agent peut recevoir à chaque requête les mêmes longues instructions, la liste complète de ses outils et un historique devenu inutile. Une synthèse de dix lignes peut être produite à partir de cinquante pages alors que trois extraits ciblés auraient suffi. Un workflow peut aussi relancer automatiquement le modèle après une erreur sans plafond clair.

Les systèmes multi-agents aggravent parfois le problème. Un premier agent analyse, un deuxième reformule, un troisième vérifie et un quatrième rédige la réponse finale. Cette chaîne paraît rigoureuse, mais elle peut traiter plusieurs fois les mêmes données. Si chaque étape utilise un modèle avancé, le coût réel du résultat devient difficile à prévoir.

Le gaspillage le plus discret vient du contexte. Comme l’utilisateur ne voit pas toujours les instructions système, les schémas d’outils ou les documents injectés, il peut croire qu’une demande est courte alors que l’API reçoit des milliers de tokens.

Ce que le routeur peut choisir : trois niveaux à tester

Une organisation peut tester trois niveaux simples. Les noms exacts changent selon les fournisseurs, mais la logique reste la même. « Léger », « intermédiaire » et « avancé » décrivent une capacité relative à une tâche, pas une qualité absolue.

Le mot « puissance » est ici un raccourci. Les modèles ne se distinguent pas uniquement par leur capacité de raisonnement. La fiabilité, la latence, la longueur de contexte, les modalités acceptées et la qualité de l’utilisation des outils comptent aussi. Le bon niveau dépend donc du travail à accomplir, pas d’un classement général.

La méthode recommandée consiste à définir un seuil d’acceptation sur un jeu de cas réels, à établir une référence de qualité, puis à tester des modèles plus rapides et moins chers. L’entreprise retient le modèle le moins coûteux qui atteint le seuil fixé. Cette logique suit le guide officiel Model selection, qui place l’exactitude avant l’optimisation du coût et de la latence.

Niveau léger : traiter les tâches prévisibles

Un modèle léger convient aux opérations dont le format est stable et dont la réponse peut être vérifiée facilement : classification, extraction de champs, détection de doublons, normalisation d’une date, choix d’une catégorie ou contrôle de présence d’une pièce.

Une partie de ces tâches ne nécessite même pas de modèle. Une règle métier, une expression régulière ou une requête classique peut être plus fiable et moins chère.

Niveau intermédiaire : produire le travail courant

Un modèle intermédiaire peut résumer un appel, préparer un email, structurer un brief commercial ou comparer quelques sources. Il peut offrir un compromis utile entre qualité, vitesse et coût, mais ce résultat doit être confirmé sur les cas de l’entreprise.

L’équipe garde un format de sortie précis et une validation humaine lorsque le contenu doit être envoyé ou enregistré dans un outil métier.

Niveau avancé : traiter l’ambiguïté et les enjeux élevés

Le modèle avancé intervient lorsque plusieurs sources se contredisent, que le raisonnement comporte de nombreuses étapes ou que l’erreur aurait un impact important. C’est le cas d’une analyse contractuelle complexe, d’un arbitrage entre commerce, marketing et facturation ou d’une anomalie financière difficile à expliquer.

Le modèle avancé devient alors une ressource d’escalade. Il ne reçoit pas tout le trafic par défaut et ne remplace pas un contrôle déterministe ou humain. Un modèle plus capable peut encore produire une réponse erronée.

Le routeur de tâches décide avant l’appel au modèle

Le nombre de tokens ou la longueur du document ne suffisent pas pour choisir un traitement. Une demande de trois lignes peut contenir des données sensibles. À l’inverse, un long fichier peut nécessiter une extraction simple et vérifiable.

Le routeur applique une politique dans un ordre explicite :

Confidentialité — quelles données sont présentes, dans quel environnement peuvent-elles être traitées et quels fournisseurs ou régions sont autorisés ?
Résultat attendu — faut-il classer, extraire, rédiger, comparer plusieurs sources ou préparer une décision ?
Puissance nécessaire — quel niveau de raisonnement, quelle longueur de contexte, quelles modalités et quels outils sont indispensables ?
Coût et vitesse — quels plafonds de budget et de latence le workflow doit-il respecter ?
Risque et supervision — l’erreur est-elle détectable, réversible et acceptable sans validation humaine ?

L’ordre compte. Un modèle moins cher ou plus rapide reste exclu si son fournisseur, sa région de traitement ou ses conditions contractuelles ne correspondent pas aux données manipulées. Les contrôles de résidence des données d’Anthropic illustrent cette distinction entre le lieu d’inférence, le stockage et les contraintes de disponibilité ou de prix. L’entreprise doit traduire ces options techniques en règles internes, pas les décider au cas par cas dans un prompt.

Une fois le filtre de confidentialité franchi, le routeur peut choisir entre quatre chemins :

une règle déterministe lorsqu’elle suffit ;
un environnement privé ou un fournisseur explicitement autorisé ;
un modèle léger, intermédiaire ou avancé selon le seuil de qualité attendu ;
un blocage ou une escalade humaine lorsqu’une règle manque, qu’une source se contredit ou qu’une action aurait une conséquence sensible.

La documentation officielle Model selection d’OpenAI recommande d’atteindre d’abord le niveau d’exactitude requis, puis d’optimiser le coût et la latence. Un routeur opérationnel ajoute à cette comparaison les permissions, la confidentialité, la modalité et la possibilité de revenir en arrière.

Une adresse extraite d’un formulaire peut ainsi passer par une règle ou un modèle léger. Un email commercial standard peut être préparé par un niveau intermédiaire. Une clause sensible, des montants incompatibles ou une action irréversible déclenchent un contrôle supplémentaire ou une revue humaine.

Chaque routage reste traçable. L’entreprise journalise la version de la politique, l’environnement, le modèle, la règle appliquée et un motif explicite comme region_not_allowed, conflicting_amounts ou human_review_required. Une note de confiance déclarée par le modèle ne suffit pas pour choisir le chemin.

Exemple : un parcours commercial supervisé

Prenons un flux qui traite les comptes rendus d’appels commerciaux.

Le premier niveau identifie le nom du client, la date, les participants et les champs explicitement mentionnés. Le niveau intermédiaire prépare le résumé, les objections, la prochaine étape et un brouillon d’email. Une escalade intervient si le décideur manque, si deux dates se contredisent, si le montant ne correspond pas au CRM ou si l’email proposé engage l’entreprise au-delà d’une règle autorisée.

Le commercial ne perd pas la main. Il relit les champs proposés et valide l’email avant tout envoi. Le système économise les appels coûteux sur les cas ordinaires et réserve davantage de puissance aux situations qui le justifient.

La même logique fonctionne en finance. Des contrôles déterministes rapprochent d’abord les montants et les références. Un modèle léger classe l’écart. Un modèle plus capable formule l’explication lorsque plusieurs documents se contredisent. Le responsable financier décide ensuite de la suite.

Corriger une dérive observée

Optimiser ne signifie pas couper arbitrairement le contexte. Le système retire ce qui n’aide pas la décision et conserve les preuves nécessaires.

Dérive observée	Correction possible
Dossier complet envoyé pour une question ciblée	Sélectionner les extraits pertinents et conserver leurs références
Historique de conversation qui grossit sans limite	Résumer les échanges anciens et fixer une fenêtre utile
Tous les outils disponibles à chaque appel	Charger uniquement les outils autorisés pour la mission
Réponse beaucoup plus longue que le besoin	Utiliser un schéma de sortie et une longueur maximale
Relances automatiques après chaque échec	Plafonner les tentatives et créer un état d’échec explicite

Le prompt caching aide lorsque plusieurs requêtes partagent un préfixe stable. Les documentations OpenAI et Anthropic décrivent des mécanismes différents, avec leurs longueurs minimales, points de cache, durées de vie et tarifs. Une première écriture peut coûter plus cher, et un préfixe identique ne garantit pas à lui seul une lecture depuis le cache. Le tableau de bord doit séparer les lectures, les écritures et le taux de cache réellement observé.

Le cache ne remplace pas le nettoyage du contexte. Mettre en cache un prompt inutilement long réduit parfois son prix unitaire, mais ne corrige pas une mauvaise architecture.

Mesurer le coût par résultat validé

Le prix d’un million de tokens ne dit pas si un workflow est rentable. Un modèle léger peut coûter peu à chaque appel mais produire davantage d’erreurs, de reprises ou de corrections humaines. Un modèle plus cher peut être préférable sur une tâche complexe s’il fournit un résultat exploitable dès le premier passage.

La mesure utile est le coût par résultat validé.

Un tableau de suivi devrait enregistrer, pour chaque mission :

le workflow, la version du prompt, la règle du routeur et le modèle utilisés ;
les tokens d’entrée, mis en cache et de sortie ;
le nombre de tentatives, les frais d’outils et les appels externes ;
la latence et le temps de relecture humaine ;
le tarif utilisé, le coût estimé et le coût facturé ;
le taux d’acceptation au premier passage et après correction ;
le résultat final : accepté, corrigé, rejeté ou escaladé.

Ces données permettent de comparer les modèles sur un jeu de cas réels. L’entreprise peut alors réduire la puissance sur une tâche stable ou renforcer le modèle lorsqu’un taux de correction devient trop élevé.

Mettre un budget dans le workflow

Le suivi mensuel ne suffit pas. Les limites doivent exister au moment de l’exécution.

Chaque mission peut recevoir un plafond de tokens, un nombre maximal de tentatives et une règle d’escalade. Une alerte se déclenche lorsque la consommation dépasse la normale. Le système peut aussi refuser une boucle supplémentaire et demander une décision humaine.

Lorsque le fournisseur propose un endpoint de comptage, le workflow peut estimer les tokens avant l’envoi. Cette vérification est particulièrement utile pour les PDF, les images, les outils nombreux et les historiques longs. Elle permet de résumer ou de sélectionner les sources avant de déclencher un appel coûteux.

Pour un client ou un service interne, le budget peut être décliné par dossier, par utilisateur ou par type de mission. Cette granularité évite de découvrir une dérive à la fin du mois sans pouvoir l’expliquer.

Les tarifs ne doivent pas être codés en dur dans chaque workflow. Une table de coûts centralisée, mise à jour par fournisseur et par version de modèle, permet de recalculer les estimations sans modifier toute l’application. Le contrôle final doit aussi comparer l’estimation à la consommation réellement facturée.

Le budget doit faire partie du produit

Adapter la puissance du modèle améliore le budget, mais aussi la lisibilité du système. Les tâches simples suivent un parcours stable. Les cas complexes deviennent visibles. Les décisions sensibles restent supervisées.

Chez Pulse, cette logique permet de coordonner plusieurs employés IA sans faire tourner le modèle le plus coûteux à chaque étape. Les règles traitent ce qui est déterministe, les modèles légers gèrent le volume, les modèles intermédiaires préparent le travail courant et les modèles avancés prennent en charge les exceptions documentées.

L’objectif consiste à dépenser au bon endroit pour obtenir un résultat fiable, vérifiable et utile à l’équipe. Une consommation plus faible n’a de valeur que si la qualité opérationnelle reste suffisante.

Sources

Sources vérifiées le 22 septembre 2026. Les tarifs, les capacités et les options de résidence évoluent ; vérifier les pages officielles avant tout chiffrage.