TOON : encoder du JSON pour les prompts LLM sans payer la structure

Le problème : la structure JSON se paie en tokens

Chaque accolade, chaque guillemet et chaque répétition de nom de champ dans un tableau d'objets identiques consomme des tokens facturés. Le README de TOON pose le constat sans détour : les tokens coûtent de l'argent, et JSON en dépense une part importante en structure plutôt qu'en contenu. L'exemple fourni est parlant : une prévision météo sur trois jours coûte environ 117 tokens en JSON contre environ 66 en TOON, soit une économie annoncée de 43,6 % sur ce cas précis. Le projet cible donc un public précis : les équipes qui injectent des données structurées dans des prompts, et qui paient ces prompts au token. Le format se présente comme une couche de traduction : on manipule du JSON dans le code, on l'encode en TOON au moment de l'envoyer au modèle. La conversion est décrite comme sans perte, ce qui signifie que le décodage doit restituer exactement l'objet de départ. Cette promesse de réversibilité est le point à vérifier en premier dans la suite de tests de conformité, car c'est elle qui rend le format utilisable sans changer le reste de la chaîne de traitement.

Quatre formes de rendu, choisies selon la forme des données

TOON n'est pas une syntaxe unique mais un jeu de quatre représentations, sélectionnées automatiquement d'après la structure de la valeur. La forme inline place un tableau de primitives sur la ligne d'en-tête : `alerts[2]: frost,wind`. La forme tabulaire déclare la liste des champs une seule fois puis écrit une ligne par élément : `forecast[3]{day,temp{min,max},condition,rainChance}:` suivi des trois lignes de valeurs. La forme tabulaire indexée s'applique aux objets dont les valeurs sont elles-mêmes des objets uniformes, comme une table d'environnements ou de feature flags ; le deux-points après la longueur (`[2:]`) la signale, et chaque ligne porte sa propre clé, par exemple `production: eu-central-1,6,false`. Enfin, tout ce qui ne rentre dans aucune de ces formes retombe en forme liste, un tiret par élément, un tiret nu pour un objet vide. La structure imbriquée repose sur l'indentation, comme YAML, tandis que les lignes tabulaires empruntent la compacité du CSV. Un détail mérite attention : `temp{min,max}` à l'intérieur d'un en-tête est un groupe de champs imbriqués, qui replie des objets internes uniformes dans l'en-tête tout en gardant les lignes plates. C'est ce repli qui permet de gagner des tokens sans aplatir la donnée de façon destructrice.

Les garde-fous de parsing, argument plus solide que l'économie de tokens

Le README met en avant un point qui n'est pas seulement comptable : `[N]` déclare le nombre de lignes attendues et `{fields}` déclare la largeur du tableau. Une sortie tronquée ou malformée du modèle devient donc détectable, parce que le compte annoncé ne correspond plus au nombre de lignes reçues. Dans un pipeline qui demande au modèle de produire des données structurées, cette redondance volontaire change la nature du contrôle qualité : on ne compare plus une chaîne à un schéma après coup, on vérifie une invariante inscrite dans le format lui-même. Le projet revendique aussi une précision de récupération comparable à celle de JSON, avec 42,6 % de tokens en moins, sur la base de ses propres benchmarks. Ce chiffre vient du dépôt et n'a pas été reproduit ici. Il faut le lire comme une revendication de l'auteur, mesurée sur des jeux de données qu'il a choisis, répartis en deux pistes : une piste à structures mixtes, où TOON est comparé à JSON, YAML et XML, et une piste purement tabulaire, où CSV entre en comparaison. Cette séparation est méthodologiquement correcte : CSV ne peut pas représenter des structures imbriquées sans aplatissement destructeur, donc le comparer sur la piste mixte n'aurait pas de sens.

Mise en route : CLI et SDK

L'essai ne demande aucune installation. Le README donne cette commande : `cat data.json | npx @toon-format/cli --stats`. Elle affiche le TOON produit à côté de l'économie estimée, sous une forme du type `Token estimates: ~117 (JSON) → ~66 (TOON)` puis `Saved ~51 tokens (-43.6%)`. L'option `--stats` est donc le point d'entrée pour évaluer le format sur vos propres données avant d'écrire la moindre ligne de code. Le paquet npm s'appelle `@toon-format/toon`, publié en version 4.1.1, et le dépôt contient un SDK TypeScript ainsi qu'une CLI. Le format est versionné séparément : le badge du README indique SPEC v4.1, et la spécification vit dans un dépôt distinct, toon-format/spec. Cette séparation entre l'implémentation et la spécification est un choix d'architecture qui compte pour la maintenance, car elle permet à des ports communautaires dans d'autres langages de viser le même document normatif et de partager une suite de tests de conformité. Le type MIME et l'extension de fichier sont documentés, mais le README tronqué ne permet pas de les citer ici avec certitude.

Quand TOON perd, et pourquoi le projet le dit

La section « When Not to Use TOON » est la plus utile du README, parce qu'elle borne le format au lieu de le vendre partout. Quatre cas de rejet y sont listés. Premier cas : les structures profondément imbriquées ou non uniformes, avec un taux d'éligibilité tabulaire proche de zéro, où JSON compact gagne franchement. Deuxième cas : les tableaux semi-uniformes, autour de 40 à 60 % d'éligibilité, où l'économie fond et où rester sur JSON se défend si le pipeline le parle déjà. Troisième cas : la donnée purement tabulaire, où CSV est plus petit ; l'overhead de 5 à 10 % de TOON achète les longueurs déclarées, les listes de champs et le cadrage des délimiteurs, ce qui est un arbitrage de fiabilité et non de taille. Quatrième cas, le plus important en pratique : quand la latence domine. Le README indique que certains déploiements, notamment des modèles locaux ou quantifiés, traitent du JSON compact plus vite malgré un nombre de tokens supérieur. Aucune mesure de latence n'est fournie, et le texte renvoie explicitement à une mesure sur votre propre installation, en surveillant le TTFT et le temps total. C'est un aveu honnête : le gain en tokens n'implique pas un gain en temps de réponse.

Face à CSV et à JSON compact : ce que le format ajoute vraiment

L'alternative la plus directe pour un tableau uniforme est CSV, et le README ne l'esquive pas : sur de la donnée purement tabulaire, CSV est plus petit. La différence d'approche tient dans ce que TOON conserve et que CSV abandonne. CSV ne porte ni longueur déclarée, ni liste de champs typée, ni délimiteur cadré, ni imbrication. TOON ajoute ces éléments en échange de 5 à 10 % de tokens, et il accepte de représenter des objets imbriqués et des tableaux de types mixtes, ce que CSV ne fait pas sans aplatissement. Face à JSON, la différence n'est pas dans le modèle de données, qui est identique, mais dans le rendu : indentation au lieu d'accolades, listes de champs déclarées une fois au lieu d'être répétées à chaque élément, citation minimisée. Le point de bascule est donc mesurable et dépend entièrement de la forme de vos données. Un tableau de mille enregistrements à champs constants est le cas favorable. Un arbre de configuration à profondeur variable est le cas défavorable, et la documentation le reconnaît sans détour.

Maintenance, stabilité et licence

Le dépôt n'est pas archivé, la dernière poussée date du 3 septembre 2026, et trois versions sont sorties entre juillet et août 2026, dont une version majeure 4.0.0. Ce rythme indique un projet actif, mais il indique aussi une certaine instabilité d'API : passer de 4.0.0 à 4.1.1 en un mois signifie que les épinglages de version ont leur importance dans un pipeline de production. Le README qualifie lui-même le format de stable tout en le présentant comme une idée en cours, avec une spec ouverte aux contributions. Cette formulation est un avertissement utile : la stabilité annoncée porte sur le format tel que documenté, pas sur une garantie de compatibilité future entre versions majeures. Le projet est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, sous réserve de conserver la mention de copyright et le texte de la licence. Ce n'est pas un avis juridique : si vous redistribuez le SDK dans un produit, faites vérifier le fichier LICENSE et les licences des dépendances par votre service compétent. La séparation entre le SDK et la spécification signifie aussi que suivre la spec ne suffit pas à suivre le SDK, et inversement.

Ce qu'il faut vérifier avant d'adopter

Le format a un profil d'adoption clair. Il convient aux équipes qui envoient au modèle des tableaux d'objets à champs constants, des dictionnaires indexés par identifiant, des listes de primitives, et qui paient ces tokens. Il convient aussi à celles qui veulent une détection native de troncature via les en-têtes `[N]` et `{fields}`. Il ne convient pas aux structures profondément imbriquées, aux tableaux semi-uniformes, ni aux déploiements où la latence prime sur le coût, notamment certains modèles locaux ou quantifiés. La première vérification est concrète et tient en une commande : faire passer un échantillon représentatif de vos données réelles dans `npx @toon-format/cli --stats` et lire le taux d'éligibilité tabulaire. Si ce taux est faible, la section « When Not to Use TOON » s'applique et le reste de l'évaluation est inutile. Si le taux est élevé, la seconde vérification porte sur la latence, que le projet laisse explicitement à votre charge. Le gain de tokens est documenté par l'auteur ; le gain de temps de réponse, non. La licence MIT et la séparation avec toon-format/spec sont deux points favorables pour un usage en production, à condition d'épingler la version du paquet et de suivre les notes de version lors des passages de version majeure.

Conclusion éditoriale

Adoptez TOON si vos prompts transportent des tableaux d'objets uniformes ou des dictionnaires indexés par identifiant, et si vous pouvez mesurer vous-même la latence sur votre modèle. Ne l'adoptez pas si vos structures sont profondément imbriquées, si votre pipeline parle déjà JSON de bout en bout, ou si votre modèle local traite plus vite du JSON compact. Avant de généraliser, convertissez un échantillon réel avec `npx @toon-format/cli --stats` et vérifiez le taux d'éligibilité tabulaire annoncé dans la sortie.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. toon-format/toon on GitHub