La tendance actuelle à privilégier une inférence ultra-efficace, la compression des jetons et des méthodes d’encodage ingénieuses nous incite à rechercher la performance et la réduction des coûts, comme si la disponibilité allait naturellement suivre. Ce ne sera pas le cas. La disponibilité se moque bien de l’ingéniosité de votre encodage sur une diapositive présentant des résultats de benchmark.
Récemment, la tendance à l’optimisation des tokens a enflammé les réseaux sociaux, suscitant un vif enthousiasme autour de Token-Oriented Object Notation (TOON), un format conçu pour réduire le nombre de tokens utilisés lors de l’inférence, puisque la tarification repose sur leur quantité. Puis les parodies ont commencé à circuler. Prises pour de véritables innovations, elles se sont propagées sous le slogan de « la mort de JSON », prouvant une fois de plus que le sarcasme passe mal à l’écrit et que l’emballement médiatique devance toujours la nuance.
Le véritable enjeu ici n’est pas la guerre des formats. Il s’agit du même défi opérationnel auquel nous sommes confrontés depuis des décennies : trouver le juste équilibre entre les performances, la disponibilité et la fiabilité, d’une part, et les coûts, d’autre part. Les coûts directs se mesurent en ressources de calcul et de réseau. Les coûts indirects se traduisent par une perte de confiance des utilisateurs, une atteinte à l’image de marque, une charge de travail accrue pour les équipes d’exploitation et une hausse du taux d’attrition. Quiconque a déjà planifié les capacités nécessaires pour un week-end de fêtes sait que cet exercice d’équilibriste n’a rien de nouveau.
Cependant, avec l’inférence de l’IA, la disponibilité englobe désormais aussi la justesse. Un système qui fournit des réponses rapidement, mais de manière inexacte, n’est pas « disponible » : il fonctionne mal. Demandez à n’importe quel opérateur ayant déjà annulé une modification à 3 heures du matin, une tasse de café tiède à la main, tout en remettant en question ses choix de carrière.
Il n’existe pas de solution universelle
C’est pourquoi TOON mérite d’être envisagé de manière réaliste, et non idéalisée, comme toute technique de compression. Certains se souviendront peut-être que, si la compression HTTP fonctionnait très bien sur les contenus textuels, elle n’avait aucun effet sur les images telles que les fichiers JPG, déjà compressées par défaut. Aujourd’hui, la distinction reste la même : les données structurées ne sont pas des instructions.
TOON est conçu pour optimiser les données structurées et affirme permettre d’importantes économies de jetons tout en améliorant légèrement la précision de la récupération. Cela peut être utile dans certains cas. Mais la structure ne fait pas tout. Les systèmes d’inférence et pilotés par des agents ne se limitent pas aux enregistrements de bases de données et aux réponses d’API. Ils traitent des instructions, des intentions et des cheminements de raisonnement. Économiser des jetons sur les données ne revient pas à améliorer la prise de décision.
Prenons une instruction JSON simple destinée à un agent :
{
"action": "create_ticket",
"priority": "high",
"summary": "L’utilisateur ne peut pas accéder à son compte",
"user_id": 84713
}
Dans TOON, cela se résume à :
action: create_ticket
priority: high
summary: L’utilisateur ne peut pas accéder à son compte
user_id: 84713
C’est concis et bien présenté. Malheureusement, l’avantage s’arrête là. L’agent doit toujours interpréter ce que signifie l’action dans son contexte. « Créer un ticket » nécessite-t-il une confirmation, une localisation, une attribution, une catégorisation, un routage ou une mise en corrélation ? TOON permet de gagner de la place, mais n’améliore pas la clarté du raisonnement.
Un article publié sur arXiv en 2025 (2510.14453) propose une approche différente : produire les résultats des outils en langage naturel. Les résultats obtenus montrent une amélioration de la précision de plus de 18 %, tout en réduisant le nombre de tokens de plus de 30 %. Pourquoi ? Parce que les modèles sont principalement entraînés sur du langage naturel, et non sur des mini-langages de données personnalisés.
En suivant leur approche, nous envoyons :
Créez un ticket d’assistance prioritaire pour l’utilisateur 84713. Problème : l’utilisateur ne peut pas accéder à son compte.
Moins de jetons que JSON, plus de clarté que TOON et une formulation conforme à la manière dont les modèles raisonnent déjà. Il ne s’agit pas d’une rédaction créative libre, mais d’une instruction encadrée par un modèle et formulée en langage naturel. Cela présente en outre l’avantage d’utiliser moins de jetons et de faciliter la détection des manipulations, ce qui apporte des bénéfices inattendus en matière de sécurité.
La leçon est simple : toutes les entrées ne se valent pas, et aucun format ne peut répondre à tous les cas d’usage. Les formats de compression comme TOON peuvent exceller pour transmettre de grands jeux de données structurées. Les modèles en langage naturel peuvent être plus efficaces pour donner des instructions aux modèles de raisonnement. C’est en prétendant qu’une solution unique convient à tout que l’on provoque des pannes.
Le nombre de jetons est important, mais ce n’est pas un indicateur clé de réussite
Le nombre de tokens n’est pas un indicateur clé de réussite pour l’IA. Ce n’est qu’une variable parmi plusieurs dans un compromis qui englobe les performances, la fiabilité et la disponibilité. De plus en plus, nous devons également tenir compte des coûts. Il est possible d’optimiser l’une de ces variables sans améliorer le système dans son ensemble, voire parfois de le dégrader. L’histoire regorge d’ingénieurs qui ont privilégié l’indicateur le plus visible au détriment du résultat le plus important.
La fourniture de services d’inférence doit trouver un équilibre entre les dimensions opérationnelle et commerciale :
- Performances: rapidité avec laquelle le système répond
- Disponibilité: indique si le système répond correctement
- Fiabilité: s’il répond de manière cohérente
- Coût: indique si l’entreprise peut le supporter à grande échelle
Réduisez le nombre de jetons, mais pas au détriment de la clarté. Améliorez la rapidité, mais pas au détriment du raisonnement. Optimisez les coûts, mais pas en les reportant sur des tentatives répétées, des escalades ou des vérifications manuelles.
Le secteur finira presque certainement par adopter plusieurs formats selon les situations. TOON pour les données structurées. Des modèles en langage naturel pour les instructions. JSON pour la compatibilité. Et probablement d’autres formats pour les charges de travail spécialisées.
Nous n’en sommes encore qu’aux débuts, et quiconque prétend avoir définitivement gagné cherche à attirer l’attention, pas à faire de l’ingénierie. L’objectif n’est pas de choisir le format le plus compact ou le plus récent, mais celui qui fournit des résultats fiables.
Si les économies réalisées réduisent la confiance, vous n’améliorez pas le système ; vous ne faites que reporter la défaillance en aval.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
Les paquets empoisonnés sont en train de tuer notre industrie
L’open source ne dispose pas d’un registre central recensant les paquets malveillants, alors même que l’IA et l’automatisation accélèrent les attaques contre la chaîne d’approvisionnement. L’écosystème a besoin d’un moyen fiable de signaler et de suivre les compromissions.
Top 10 des risques liés à la mise en production d’applications d’IA : manque de sécurité et de conformité réglementaire
L’IA étend la conformité au-delà de la sécurisation des chemins d’accès et des espaces de stockage pour englober la gouvernance du comportement à l’exécution — accès aux modèles, contexte de récupération, résultats et actions des agents —, de sorte que les contrôles doivent être rapprochés de l’inférence.
Top 10 de la livraison d’applications d’IA : politiques de livraison incompatibles
Les divergences de politiques deviennent des sources de pannes pour l’IA : des mécanismes de basculement, des délais d’expiration, des limites et des contrôles de sécurité incohérents entraînent des défaillances silencieuses, des résultats partiels et des résultats différents selon le point de terminaison.
Top 10 de la mise à disposition d’applications d’IA : orientation du trafic non optimisée
L’IA remet en cause les principes traditionnels de répartition du trafic : les backends ne sont pas interchangeables, les coûts varient et les agents multiplient les requêtes de manière imprévisible. Le routage doit donc tenir compte du modèle, de l’état des GPU et de la localisation des données.
Top 10 de la livraison d’applications d’IA : contrôles du trafic insuffisants
Les limites de débit et les mécanismes de régulation traditionnels ne tiennent pas compte de l’étendue réelle des répercussions. Les charges de travail d’IA se répartissent entre les modèles, les bases de données vectorielles et les services, provoquant des pics de latence, des défaillances en cascade et des nouvelles tentatives.
La gestion des fenêtres de contexte en IA n’a rien de magique. C’est une question d’architecture.
Découvrez pourquoi les créateurs d’applications d’IA doivent gérer le contexte, la mémoire et l’infrastructure, tout en faisant évoluer les processus de livraison et la sécurité afin d’éviter la dérive, la latence et les attaques par injection de prompts.