Il existe dans le yoga un principe discret qui s’applique étonnamment bien à la technologie : fournir exactement l’effort que le moment exige — ni plus, ni moins. La plupart des équipes qui utilisent l’IA aujourd’hui font l’inverse. Elles consacrent un effort maximal à chaque tâche, qu’elle en ait besoin ou non, et paient ce privilège un token à la fois.
Parlons de pourquoi vos coûts IA continuent d’augmenter — et de comment les ramener à quelque chose de plus intentionnel.
Les modèles de pointe sont conçus pour consommer des tokens
Les modèles de pointe d’Anthropic et d’OpenAI sont réellement remarquables, et une grande partie du pourquoi tient au fait que la génération la plus récente fait tout simplement davantage de travail par requête. Ils raisonnent étape par étape. Ils « réfléchissent » avant de répondre. Ils exécutent des boucles agentiques plus longues et à plusieurs étapes. Ils fournissent des réponses détaillées, nuancées et riches en contexte.
C’est un vrai gain d’expérience utilisateur. Les réponses sont meilleures, plus prudentes et plus capables que les modèles laconiques d’il y a quelques années. Mais cela s’accompagne d’un effet structurel qu’il vaut la peine de nommer clairement :
Ces modèles sont facturés au token, et ils sont conçus pour utiliser plus de tokens.
Plus de raisonnement, plus de sortie, plus d’allers-retours — tout cela améliore l’expérience et augmente la consommation. Les incitations de ceux qui vous vendent des tokens et les vôtres, en tant qu’acheteur, ne vont pas dans la même direction. Vous finissez par payer une réflexion approfondie pour des tâches qui n’exigeaient qu’une réponse en une ligne.
Ce que cela coûte réellement à une entreprise
Sur une seule conversation, le coût est invisible — une fraction de centime. Le problème, c’est l’échelle.
- Un flux de service client qui traite 50,000 messages par jour.
- Un pipeline de contenu qui génère des centaines de brouillons.
- Un agent interne qui boucle cinq ou six fois par tâche pour « y réfléchir ».
Multipliez l’usage de tokens par appel par la surcharge de raisonnement, puis par le volume, puis par 30 days. Un flux de travail qui semblait ridiculement peu coûteux dans la démonstration devient une dépense d’exploitation sérieuse et récurrente — et une dépense qui augmente à chaque fois que vous ajoutez une fonctionnalité ou un client. Pire encore, c’est imprévisible : un modèle qui décide de réfléchir davantage ce mois-ci augmente discrètement votre facture sans qu’aucune ligne de nouveau code ne soit livrée.
Pour une petite ou moyenne entreprise, cette imprévisibilité est la vraie taxe.
L’alternative locale : Ollama
Voici le changement de perspective. Toutes les tâches n’ont pas besoin d’un modèle de pointe. En réalité, la plupart n’en ont pas besoin.
Ollama vous permet d’exécuter des modèles open-source performants — Llama, Mistral, Qwen, et bien d’autres — directement sur votre propre matériel ou sur un serveur modeste. Une fois en fonctionnement, le coût marginal d’une requête tombe à peu près à zéro. Vous avez déjà payé le calcul ; il n’y a pas de compteur de tokens qui tourne.
Le compromis, c’est qu’un modèle local de 7B–30B n’est pas aussi brillant dans tous les domaines qu’un modèle de pointe. Mais pour un travail bien défini et répétable — classification, extraction, synthèse, routage, rédaction à partir d’un modèle — un modèle local plus petit est amplement suffisant. L’art consiste à savoir quelles tâches garder en local et lesquelles faire remonter.
Les compétences personnalisées d’AnythingLLM : le vrai levier
C’est là que se cachent la plupart des économies.
AnythingLLM est une application open-source qui encapsule des modèles locaux (via Ollama) dans un espace de travail propre avec prise en charge des documents/RAG — et, surtout, un système de compétences personnalisées. Au lieu de demander à un modèle de raisonner à nouveau depuis zéro pour la même tâche à chaque fois, vous encodez la partie répétable du travail sous forme de compétence déterministe : du vrai code qui s’exécute de manière prévisible, appelle vos API, met en forme votre sortie et ne renvoie au modèle que les décisions réellement ambiguës.
Le résultat est hybride :
- Le code déterministe effectue le gros du travail répétitif — gratuitement, à chaque fois, de façon identique.
- Le modèle n’est invoqué que pour la petite partie de la tâche qui exige réellement un jugement.
Vous obtenez le même résultat final, avec une fraction de la consommation de tokens — parce que vous avez cessé de payer un modèle de langage pour redériver un processus que vous connaissez déjà.
Où s’insèrent les serveurs MCP
Un petit modèle local n’est utile que dans la mesure où il peut atteindre quelque chose. C’est le rôle des serveurs MCP (Model Context Protocol).
MCP est un standard ouvert pour connecter des modèles IA à des outils, des données et des systèmes en direct — bases de données, espaces de stockage de fichiers, API internes, systèmes de ticketing, votre CRM. AnythingLLM prend en charge les serveurs MCP, ce qui signifie que votre pile locale n’est pas un chatbot fermé ; c’est un agent capable de lire des données réelles et d’effectuer de vraies actions via une interface propre et standardisée.
C’est ce qui rend l’approche locale viable pour un travail sérieux. Les fournisseurs de pointe veulent que vous fassiez tout à l’intérieur de leur fenêtre de contexte mesurée au token. MCP vous permet de garder les données, les outils et la logique déterministe de votre côté — et de ne dépenser des tokens que pour la réflexion elle-même.
Conseils pratiques : réécrire une compétence standard en compétence personnalisée optimisée
Voici comment prendre une tâche que vous confiez actuellement à un modèle de pointe et la reconstruire pour l’exécuter à une fraction du coût.
Commencez par profiler votre consommation de tokens. Identifiez les 3–5 flux de travail qui s’exécutent le plus souvent. C’est là que les économies se cumulent. N’optimisez pas ce que vous lancez deux fois par semaine.
Séparez le déterministe de l’ambigu. Relisez ce que le modèle fait réellement à chaque appel. Les parties identiques à chaque fois — récupération de données, application d’un format, validation de champs, routage — n’ont pas besoin d’un modèle de langage.
Déplacez les parties déterministes dans du code. Dans une compétence personnalisée AnythingLLM, cette logique devient une fonction gestionnaire. Elle s’exécute de manière identique à chaque fois, sans coût en tokens.
Réduisez le prompt à la décision. Donnez au modèle uniquement la question réellement ambiguë, avec juste assez de contexte pour y répondre. Pas de répétition de tout le processus à chaque appel. Entrée plus petite, sortie plus petite, facture plus légère.
Récupérez les données en direct via MCP, pas via le prompt. N’insérez pas un document de 4,000 tokens dans le contexte lorsqu’un outil MCP peut aller chercher exactement le champ dont vous avez besoin à la demande.
Orientez selon la difficulté. Exécutez la version courante sur un modèle local Ollama. Réservez le modèle de pointe aux 5% vraiment difficiles — et laissez votre compétence décider quand faire remonter.
Mesurez avant et après. Suivez les tokens par tâche avant et après. Les équipes qui font cela constatent régulièrement des réductions de 80–95% sur leurs flux de travail les plus volumineux.
La conclusion intentionnelle
L’IA de pointe mérite qu’on la paie — quand la tâche l’exige réellement. L’erreur consiste à l’utiliser par défaut pour tout, tout en finançant discrètement un compteur par token conçu pour continuer à augmenter.
Faites fonctionner les tâches courantes en local. Encodez ce qui est répétable sous forme de compétences personnalisées. Connectez le tout au monde réel avec MCP. Réservez les modèles de pointe aux moments qui en ont vraiment besoin.
Ce n’est pas rogner sur la qualité. C’est simplement fournir le bon effort au bon moment — ce qui, comme il se trouve, est une bonne pratique sur le tapis comme dans le cloud.