En pied d’article, un projet WinDev POC à télécharger pour tester le gain apporté par TOON.
![]() | ![]() | ![]() |
JSON, l’hégémonie d’un standard devenu incontournable
Depuis plus d’une décennie, JSON s’est imposé comme le format d’échange de données dominant. Léger, lisible, simple à manipuler, il a remplacé XML dans la quasi-totalité des usages liés aux API Web, aux microservices et aux communications entre applications.
Qu’il s’agisse d’un backend en WinDev ou NodeJS, d’un front en JavaScript, d’un microservice Kubernetes ou d’une fonction serverless, JSON est devenu la lingua franca des Web Services. Les bibliothèques existent dans tous les langages, les outils savent le parser nativement, et les développeurs ont désormais le réflexe JSON pour structurer les données.
Mais à force d’être utilisé partout, un défaut majeur est devenu de plus en plus visible…
Le défaut principal de JSON : le volume des données
Si JSON est simple et universel, il n’est pas optimisé pour la compacité. Plusieurs raisons expliquent son surpoids :
-
- Structures verbeuses : chaque clé est répétée dans chaque objet, parfois des centaines de fois.
- Usage systématique des guillemets autour des clés et des chaînes de caractères.
- Pas de typage natif compact : tout est texte, même ce qui pourrait être encodé de manière plus dense.
- Indentation et espaces qui, même facultatifs, augmentent souvent encore la taille.
- Dans des systèmes modernes à forte volumétrie — IoT, logs, temps réel, API intensives, transferts inter-microservices — la taille des messages JSON devient un frein :
- plus de bande passante consommée,
- plus de temps de traitement,
- plus de CPU pour la sérialisation/désérialisation,
- plus de coûts d’infrastructure.
Il devenait nécessaire d’innover… d’où l’apparition de TOON.
Introduction à TOON : un format structuré, lisible et ultra-compact
TOON (Token Object-Oriented Notation) est un format de données textuel, hiérarchique et humainement lisible, conçu pour être drastiquement plus léger que JSON, tout en restant simple à parser et à générer.
Le principe est inspiré des structures indentées (YAML, Python), mais avec une philosophie différente :
chaque niveau d’imbrication est représenté par une indentation contrôlée (2 espaces), suivie de champs clé/valeur sans guillemets inutiles.
Exemple JSON :
{
"societes": [
{
"nom": "CODE LINE",
"url": "https://codeline.fr",
"effectifs": 28
},
{
"nom": "SILICO",
"url": "https://silico.fr",
"effectifs": 18
},
{
"nom": "TOKAMAX",
"url": null,
"effectifs": 5
}
]
}
Le même objet en TOON :
societes[3]{nom,url,effectifs}:
CODE LINE,"https://codeline.fr",28
SILICO,"https://silico.fr",18
TOKAMAX,null,5
Pas d’accolades, pas de virgules, pas de duplication inutile (les chaînes ne sont mises entre guillemets que lorsque cela est strictement nécessaire pour éviter toute ambiguïté (espaces de début ou de fin, caractères de contrôle, valeurs qui pourraient être confondues avec des booléens ou des nombres).
La hiérarchie est naturelle, la lecture est immédiate, et la taille chute.
Les avantages de TOON sur JSON
✔ Format beaucoup plus compact
-
-
- TOON supprime :
- les guillemets,
- les accolades et virgules,
- les répétitions lourdes,
- une partie du bruit syntaxique.
- Résultat : 20 à 60 % de réduction de taille selon les structures.
-
✔ Lisibilité humaine accrue
TOON se lit comme un fichier de configuration propre.
Même un non-développeur peut comprendre un document TOON.
✔ Parsing plus simple
L’indentation est stricte (multiples de 2 espaces), ce qui :
-
-
- élimine les ambiguïtés,
- facilite l’écriture de parseurs très rapides,
-
permet une conversion directe JSON ↔ TOON.
✔ Adapté aux systèmes API, IoT, logs et microservices
Partout où la performance et la compacité comptent, TOON apporte un vrai gain :
-
-
- Web services,
- messages MQTT,
- échanges interservices,
- fichiers de configuration,
- transferts de données compressés.
-
✔ Format textuel → compatible avec les outils DevOps
Contrairement à des formats binaires (protobuf, msgpack), TOON reste :
-
-
- diffable,
- versionnable dans Git,
- éditable à la main,
- lisible même en ligne de commande.
-
Les contraintes et règles strictes du format TOON
Comme tout format structuré et optimisé, TOON impose plusieurs contraintes, nécessaires pour garantir un parsing rapide, robuste et non ambigu. Contrairement à JSON, qui tolère plus de flexibilité structurelle, TOON suit un ensemble de règles précises :
- Indentation stricte à 2 espaces
- L’imbrication structurelle repose entièrement sur l’indentation.
Chaque niveau doit utiliser exactement 2 espaces. - Pas de tabulation
- Pas de 3 ou 4 espaces
- Une seule unité valide : 2 espaces par niveau
- Toute déviation entraîne une erreur de parsing.
- L’imbrication structurelle repose entièrement sur l’indentation.
- Pas de clés optionnelles dans les tableaux
C’est une particularité importante :
dans un tableau d’objets, tous les éléments doivent utiliser les mêmes clés, dans le même ordre.
Exemple valide :
items:
- name: Item A
qty: 10
- name: Item B
qty: 20
Exemple invalide :
items:
- name: Item A
qty: 10
- name: Item B
# manque qty → erreur
Cela permet au parseur TOON :
-
- d’optimiser l’allocation mémoire,
- de détecter instantanément les incohérences,
- d’augmenter la vitesse de décodage.
- Valeurs typées mais sans décorations
Les valeurs numériques, booléennes ou nulles s’écrivent telles quelles, sans guillemets.
Seules les chaînes complexes doivent parfois être explicitement marquées.
age: 42
active: true
Pour inclure des caractères spéciaux (saut de ligne, : dans la chaîne, etc.), TOON peut exiger un encapsulage dans une notation étendue (selon les implémentations).
- Impossible de mélanger objets et valeurs au même niveau
Une clé ne peut pas être à la fois :
-
- un objet sur une ligne
- et une valeur sur une autre
Exemple interdit :
config: yes
config:
mode: auto
- Pas de références circulaires ou dynamiques
TOON est un format statique :
-
-
- pas de symboles $ref,
- pas de pointeurs internes,
- pas de liens dynamiques
-
Ce qui garantit un parsing prévisible et linéaire.
- Ordre des clés significatif
Contrairement à JSON où l’ordre n’a aucune importance, TOON considère l’ordre comme faisant partie de la structure. Cela permet :
-
-
- des diffs Git plus propres,
- un encodage plus compact,
- une cohérence stricte entre versions.
-
Conclusion
JSON reste un excellent standard… mais il montre ses limites.
Avec TOON, vous disposez d’un format plus compact, plus lisible et plus performant, tout en conservant la simplicité et l’universalité d’un format textuel.
TOON n’est pas destiné à supplanter systématiquement JSON. Il s’avère néanmoins très intéressant pour transmettre des tableaux de données structurées (par exemple pour remplir une datagrid sur un frontal Web), les clés étant identiques pour toutes les itérations. Dans ce genre de situation, TOON présente un avantage indéniable sur JSON du point de vue volume.
Pour les projets modernes nécessitant des échanges rapides, économiques et propres, TOON est une alternative sérieuse — légère, efficace et élégante.
Toujours à l’affût de techniques ou de stratégies pour améliorer les performances de ses applications (en l’occurrence le volume des données transférées), CODE LINE a développé une bibliothèque pour permettre aux WinDeveloppeurs de tester et évaluer TOON. Et c’est avec plaisir que nous la mettons à votre disposition (en attendant une probable implémentation native dans en WLangage par notre éditeur préféré ;-))
Le projet a été réalisé en WinDev 25 (pour permettre au plus grand nombre de l’utiliser, mais est migrable dans les versions postérieures), et utilise une DLL que nous avons réalisée en GO et dont le source est également fourni. Il s’agit d’un prototype, qui n’a pas encore été testé en production réelle.
Téléchargement ICI : https://www.codeline.fr/wp-content/uploads/2025/11/WDToon.zip
N’hésitez pas à nous faire part de vos remarques et suggestions.



