JSON
JSON est un format texte composé d’objets, de tableaux et de valeurs, utilisé pour les API, les annotations et les sorties de modèles. Découvre les règles de syntaxe, les usages en apprentissage automatique, JSON Lines et le code.
JSON, abréviation de JavaScript Object Notation, est un format léger, textuel, destiné au stockage et à l’échange de données structurées. Douglas Crockford l’a spécifié au début des années 2000, en s’appuyant sur la syntaxe des littéraux d’objet de JavaScript. Il est désormais normalisé par l’IETF sous la référence RFC 8259 et par ECMA-404. JSON est indépendant du langage, lisible par les personnes et analysable avec la bibliothèque standard de presque tous les langages de programmation, ce qui en fait le format par défaut des API web. En apprentissage automatique (ML), il transporte les prédictions depuis les moteurs d’inférence, stocke les annotations des jeux de données, consigne les métadonnées des expériences et définit les sorties structurées des grands modèles de langage (LLMs).
Syntaxe JSON#
Un document JSON est constitué de deux conteneurs et de quatre types de valeurs :
- Objets : ensembles non ordonnés de paires clé-valeur entre accolades, comme
{"name": "bus", "confidence": 0.94}. Les clés doivent être des chaînes entre guillemets doubles. - Tableaux : listes ordonnées entre crochets, comme
[48.5, 398.0, 245.3, 902.1]. - Valeurs : chaînes, nombres, littéraux
true,falseetnull, ou objets et tableaux imbriqués.
Le format est strict. Les commentaires, les virgules finales, les chaînes entre apostrophes et les valeurs NaN et Infinity ne sont pas autorisés, même si le module Python json écrit NaN par défaut, sauf si allow_nan=False est défini, ce qui produit des fichiers rejetés par les analyseurs stricts. La RFC 8259 avertit également que les nombres ne sont échangés de manière fiable que dans la limite de la précision double IEEE 754 ; c’est pourquoi les entiers supérieurs à 2⁵³ − 1, comme certains identifiants de base de données, sont souvent transmis sous forme de chaînes.
JSON dans les workflows d’apprentissage automatique#
Quand une caméra d’un système de sécurité envoie une image à un service de détection d’objets, la couche de mise à disposition du modèle répond généralement en JSON : un enregistrement par objet détecté, avec sa classe, son score de confiance et les coordonnées de sa boîte englobante, prêt à être utilisé dans des tableaux de bord, des applications mobiles et des bases de données documentaires comme MongoDB.
Les formats d’annotation reposent aussi sur JSON. Le jeu de données COCO stocke toutes les étiquettes d’une partition dans un seul fichier JSON contenant trois listes principales : images avec les noms et tailles des fichiers, categories avec les identifiants et noms des classes, et annotations, où chaque entrée référence une image et une catégorie par identifiant et stocke une boîte sous forme de [x, y, width, height] en pixels à partir du coin supérieur gauche. Le format YOLO utilise plutôt un fichier texte par image avec des coordonnées centrales normalisées, et la conversion entre les deux est une étape courante des pipelines d’annotation des données, même si une classe de jeu de données personnalisée peut aussi entraîner YOLO directement à partir du JSON COCO.
JSON Lines, également appelé NDJSON, place un objet JSON complet sur chaque ligne. On peut alors ajouter des données aux fichiers, les diffuser et les fractionner sans analyser tout le document, ce qui convient aux journaux d’entraînement, aux flux de prédictions et aux jeux de données d’instructions utilisés pour le réglage fin des LLMs. Pour les LLMs, le schéma JSON décrit précisément les champs attendus par une application, tandis que les sorties structurées et l’appel de fonctions contraignent un modèle à produire un JSON qui respecte ce schéma. GeoJSON, normalisé sous la référence RFC 7946, applique ce format aux entités géographiques, ce qui permet à l’analyse d’images satellite de situer les détections sur une carte.
Convertir les prédictions en JSON#
Les objets Results d’Ultralytics YOLO sérialisent leurs prédictions avec to_json(), en écrivant un enregistrement par détection avec le nom de classe, l’identifiant de classe, la confiance et les coins de la boîte x1, y1, x2, y2, ainsi que les coordonnées du masque ou des points clés pour les modèles de segmentation d’instances et d’estimation de pose. L’exemple suivant exécute YOLO26 sur une image d’exemple et analyse à nouveau le JSON avec la bibliothèque standard de Python :
import json
from ultralytics import YOLO
# Charger un modèle YOLO26 de détection préentraîné et exécuter l’inférence
model = YOLO("yolo26n.pt")
results = model("https://ultralytics.com/images/bus.jpg")
result = results[0]
# Sérialiser chaque détection en chaîne JSON (normalize=True mettrait les boîtes à l’échelle de 0 à 1)
json_string = result.to_json()
# N’importe quel analyseur JSON peut le lire à nouveau, ici dans une liste de dictionnaires Python
detections = json.loads(json_string)
print(json.dumps(detections[0], indent=2))L’enregistrement affiché est un objet JSON avec les clés name, class et confidence, ainsi qu’un objet imbriqué box contenant les coordonnées des coins en pixels.
JSON et formats apparentés#
- YAML : un format plus lisible qui autorise les commentaires et les imbrications fondées sur l’indentation, couramment utilisé pour les configurations d’entraînement et les définitions de jeux de données. YAML 1.2 est conçu comme un sur-ensemble de JSON : la plupart des documents JSON sont donc des documents YAML valides.
- XML : un format à balises, utilisé pour les annotations Pascal VOC, plus verbeux que JSON et qui prend en charge les attributs, les espaces de noms et les schémas.
- CSV : un format de tableau plat, compact pour les données tabulaires, mais qui ne peut pas imbriquer des objets ou des listes.
- Formats binaires : Protocol Buffers et MessagePack sont plus compacts et plus rapides à analyser que JSON, mais ne sont pas lisibles par une personne. Les fichiers de modèle ONNX sont stockés sous forme de messages Protocol Buffers.










