TOON : tout savoir sur le format qui pourrait remplacer le JSON

Le problème est simple : appeler des LLMs, ça utilise des Tokens. Un token, c'est un "morceau de mot". Quand on envoie des données à un LLM, on utilise en général un format particulier, le JSON, qui est ultra-répandu, notamment dans le monde des APIs. Ce JSON, comme tout le reste, consomme des tokens. La promesse de Token-Oriented Object Notation, c'est de réduire drastiquement le nombre de tokens nécessaires pour faire passer une information, et donc de réduire directement le coût d'utilisation des LLMs, tout en améliorant la fiabilité de leurs réponses.

En trois mots

Le format Toon est une bonne idée, mais vous en faites trop. On économise des tokens, donc c'est une bonne chose, mais ça ne change pas fondamentalement le travail.

Et comme à chaque fois qu'une nouveauté, même mineure, apparaît dans l'écosystème LLM, on voit fleurir les posts LinkedIn qui parlent de "game changer" et de "révolution". Ce n'est ni une révolution, ni même une avancée vraiment majeure.

Comment ça marche ?

Voici un exemple de JSON :

{
  employees: 
  [
    {
      id: 1,
      name: "Didier Sampaolo",
      gender: "m",
      company: "LVLUP",
      height: 182
    },
    {
      id: 2,
      name: "Carole Colombier",
      gender: "f"
      company: "LVLUP"
      height: 174,
    }
  ]
}

et la même chose en Toon :

employees[2]{id,name,gender,company,height}: 
  1,Didier Sampaolo,m,LVLUP,182
  2,Carole Colombier,f,LVLUP,174

Ça saute aux yeux : le JSON est beaucoup plus verbeux, et consommera donc plus de tokens, notamment parce qu'il répète le label des champs pour chaque objet.

Et face au CSV ?

Au départ, je pensais que Toon était un CSV, mais il y a quelques features supplémentaires qui font que, d'après Johann Schopplich (l'inventeur du format) on ne peut pas comparer. Notamment, le CSV ne peut pas contenir de données imbriquées (dans notre exemple, les dossiers client, ou les dates de congés prévues, etc).

Il y a un deuxième argument : le TOON déclare explicitement le nombre d'éléments qu'on trouvera dans un tableau (c'est le [2] de notre exemple), ce qui pose un garde-fou supplémentaire pour éviter que le LLM ne se perde dans les data.

...et Protobuf ?

Si on parle d'optimisation de la transmission de données, impossible de ne pas mentionner Protocol Buffers (Protobuf), le format binaire développé par Google. Protobuf est beaucoup plus compact que JSON, plus rapide à parser, et utilisé en production par des millions de systèmes depuis des années. Sauf que voilà : les LLMs ne comprennent pas le binaire. Ils ont besoin de texte lisible pour parser et générer des données. Protobuf est imbattable pour la communication machine-to-machine, mais inutilisable pour la communication human/machine-to-LLM.

Toon se positionne donc dans un créneau spécifique : un format texte optimisé pour les LLMs, qui reste lisible par un humain (contrairement à Protobuf) tout en étant plus compact que JSON. C'est un compromis, pas une révolution. Si vous cherchez vraiment la performance maximale pour des échanges entre vos serveurs, vous utilisez déjà Protobuf ou gRPC. Si vous voulez gratter 40% de tokens sur vos prompts LLM, Toon peut avoir du sens. Mais ce sont deux problèmes différents, et Toon ne remplace pas Protobuf, il joue dans une autre catégorie.

Performances comparées

Sur le Github officiel du projet, l'auteur détaille le bechmark qu'il a fait subir à son Toon et à JSON en parallèle (et à CSV, quand les données s'y prêtaient).

Sur la plupart des tâches, on constate une très légère augmentation de la fiabilité (quasiment négligeable, de l'ordre d'un point de pourcentage), mais surtout une nette diminution des tokens utilisés, souvent de l'ordre de 40 %.

Concrètement, si vous faites 1000 requêtes/jour avec 2000 tokens de contexte, vous passez de 8 € à 5 €/jour chez OpenAI. Ça fait 100 € par mois d'économies.

Où est-ce que ça peut être utile ?

Chaque fois qu'on fait transiter des données entre un LLM et un autre système. Ça peut être dans un MCP, quand on fournit le résultat d'une analyse (ou d'une lecture de base de données) à un LLM.

Les plus gros bénéfices se feront surtout sentir dans le cadre d'un RAG par exemple, où l'utilisation en tokens est généralement assez intensive. Quand le RAG récupère des informations (le "Retrieval"), il ne récupère généralement pas un seul gros bloc de texte. Il peut récupérer plusieurs "chunks" (morceaux) de documents, chacun avec ses propres métadonnées (source, URL, numéro de page, etc.). C'est sur ce type de requêtes que les 40% d'économies de tokens se feront beaucoup ressentir.

Le contexte (les documents récupérés) est beaucoup plus compact. On peut donc soit en mettre plus dans la même fenêtre de contexte, soit simplement faire baisser le coût par requête.

Pourquoi ce n'est pas révolutionnaire

Toon est une bonne idée d'optimisation,. C'est le genre d'amélioration incrémentale qu'on doit saluer, sans en faire des caisses. Si vous avez un RAG qui tourne H24 avec des milliers de requêtes, oui, regardez-y. Si vous faites 10 appels par jour à Claude, économiser 40% de tokens ne changera rien à votre vie.

Ce n'est qu'une optimisation d'encodage, pas un nouveau paradigme
Ça ne résout aucun problème structurel des LLMs (hallucinations, limites de contexte réelles)
L'écosystème est déjà saturé de formats (JSON, YAML, XML, CSV, Parquet...)
Le gain de 40% est réel mais ne change pas l'ordre de grandeur des coûts
Ça ajoute une couche de complexité : il faut maintenant gérer un parser de plus, former les devs, etc.

La vraie révolution, ce sera quand on arrêtera de prendre chaque micro-optimisation pour une rupture technologique.

Un format artisanal dans un monde industriel

Il faut aussi noter que Toon n'est pas backé par OpenAI, Anthropic, Google ou n'importe quel acteur majeur de l'écosystème LLM. C'est un projet solo, d'un développeur indépendant. Loin de moi l'idée de cracher sur un confrère, c'est même tout à son honneur d'avoir documenté, benchmarké et packagé proprement son idée. Le premier commit du projet date de début octobre 2025 : on parle d'un format qui a tout juste un mois d'existence.

Mais ça veut aussi dire quelque chose sur l'adoption : sans intégration native dans les SDKs officiels, sans mention dans les docs d'Anthropic ou OpenAI, sans librairies maintenues par des équipes dédiées, vous allez devoir gérer vous-même le parsing, la maintenance, et expliquer à vos collègues pourquoi vous avez ajouté une dépendance exotique au projet.

Et c'est là que ça devient risqué. Ajouter une dépendance pendant la hype, c'est exactement le genre de décision qu'on regrette 18 mois plus tard quand le projet n'a pas décollé, que le repo GitHub est à l'abandon, et qu'on doit maintenant soit porter le code nous-mêmes, soit refactoriser pour revenir au bon vieux JSON. On l'a vu 100 fois : GraphQL qui allait "tuer REST", JAMstack qui allait "révolutionner le web", et combien d'autres tendances qui ont laissé des projets dans l'embarras ? Pendant ce temps, PHP est mort, et ce, depuis 1994, même s'il motorise encore 70% du web.

JSON a gagné parce qu'il était partout, supporté nativement, avec des parsers ultra-optimisés dans tous les langages. Toon, pour l'instant, c'est un repo GitHub avec quelques stars. Peut-être que ça décollera si un gros acteur s'y intéresse, peut-être que ça restera une curiosité de niche, peut-être que dans 6 mois personne n'en parlera plus.

Et franchement, si ça ne prend pas, on sera bien contents de ne pas avoir ajouté cette charge mentale supplémentaire pour les mainteneurs de nos projets clients. Parce que choisir une techno parce qu'elle fait le buzz, c'est du resume-driven development, et ça finit toujours de la même façon : par un projet enlisé qu'il faudra démêler.