TL;DR

• XML a domine le web des annees 2000, avec SOAP, WS-*, et tout l'ecosysteme enterprise Java.
• JSON est arrive en 2001 grace a Douglas Crockford, qui l'a "decouvert" (pas invente) dans la spec JavaScript.
• JSON a gagne parce qu'il est natif a JavaScript, plus lisible, moins verbeux, et trivial a parser.
• XML garde des avantages reels : schemas, namespaces, contenu mixte, signatures.
• YAML, TOML, Protocol Buffers et MessagePack sont les candidats suivants, mais aucun ne menace JSON.
• L'ironie : un format concu pour les navigateurs des annees 2000 est devenu le standard universel des APIs.

Il y a vingt ans, XML etait roi

Si tu as commence a coder apres 2015, tu n'as probablement jamais ecrit de SOAP request a la main. Tu n'as jamais configure un WSDL. Tu n'as jamais debogue un namespace XML mal reference a 23h un vendredi soir en production.

Laisse-moi te raconter.

Au debut des annees 2000, XML etait partout. Les APIs etaient en SOAP (Simple Object Access Protocol -- le nom etait deja un mensonge). Les configurations etaient en XML. Les fichiers de build etaient en XML (coucou Ant, coucou Maven). Les bases de donnees stockaient du XML. Microsoft avait invente XAML. Java avait invente un ecosysteme entier autour de XML : JAXB, JAXP, SAX, DOM, StAX, XPath, XSLT, XQuery.

Pour envoyer un "bonjour" a un web service, tu ecrivais ca :

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:msg="http://example.com/messaging">
  <soap:Header>
    <msg:Authentication>
      <msg:Token>abc123</msg:Token>
    </msg:Authentication>
  </soap:Header>
  <soap:Body>
    <msg:SendMessage>
      <msg:To>utilisateur@example.com</msg:To>
      <msg:Content>Bonjour</msg:Content>
    </msg:SendMessage>
  </soap:Body>
</soap:Envelope>

28 lignes pour dire "bonjour". Avec des namespaces, une enveloppe, un header d'authentification, et un body. Le tout envoye en POST avec un header SOAPAction. C'etait le quotidien.

Et les gens trouvaient ca normal.

L'arrivee de JSON : une decouverte, pas une invention

Douglas Crockford et le "sous-ensemble de JavaScript"

En 2001, Douglas Crockford -- un ingenieur qui travaillait chez State Software -- a realise quelque chose de simple. La syntaxe des objets litteraux JavaScript pouvait servir de format d'echange de donnees. Pas besoin d'inventer un nouveau format. Il suffisait de formaliser ce qui existait deja dans le langage.

{
  "to": "utilisateur@example.com",
  "content": "Bonjour"
}

Deux lignes. Pas de namespace, pas d'enveloppe, pas de declaration de version. Les memes donnees que le monstre SOAP ci-dessus.

Crockford a toujours insiste : il n'a pas invente JSON, il l'a decouvert. La syntaxe existait dans JavaScript depuis ECMAScript 3 (1999). Il a simplement dit : "ca pourrait servir a autre chose que definir des objets dans un script".

La standardisation minimaliste

JSON a ete formalise en 2002 sur le site json.org. La spec tient sur une carte de visite. Six types de donnees : string, number, boolean, null, array, object. Pas de commentaires, pas de types personnalises, pas d'extensions. La simplicite etait le feature, pas un defaut.

La RFC 4627 est arrivee en 2006. Puis la RFC 8259 en 2017 pour clarifier l'encodage (UTF-8 obligatoire). En quinze ans, la spec a a peine change. Compare ca aux centaines de pages de specifications WS-* que le monde SOAP a produit.

Pourquoi JSON a gagne : les cinq raisons

1. Natif a JavaScript

C'est la raison fondamentale. En 2005, quand Ajax a explose (merci Gmail, merci Google Maps), les devs frontend avaient besoin d'echanger des donnees avec le serveur. JSON etait deja du JavaScript. Pas besoin de parser, pas besoin de bibliotheque, pas besoin de mapping.

// XML : il faut parser, traverser le DOM, extraire les valeurs
const parser = new DOMParser();
const doc = parser.parseFromString(xmlString, "text/xml");
const name = doc.querySelector("Name").textContent;

// JSON : c'est deja un objet
const data = JSON.parse(jsonString);
const name = data.name;

Quand ton format est natif au langage qui domine le web, c'est un avantage insurmontable.

2. La lisibilite humaine

XML est lisible, mais verbeux. Chaque donnee est enveloppee dans une balise ouvrante et fermante. Pour un objet avec 10 champs, tu as 20 balises supplementaires. JSON utilise des accolades et des deux-points. C'est plus compact, plus scannable, plus facile a deboguer a l'oeil.

<user>
  <name>Marie</name>
  <age>32</age>
  <active>true</active>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

{
  "name": "Marie",
  "age": 32,
  "active": true,
  "roles": ["admin", "editor"]
}

Meme donnees. JSON : 6 lignes. XML : 10 lignes. Sur un payload de 500 champs, la difference est massive.

3. Le parsing trivial

Parser du XML correctement, c'est complique. Tu as deux approches : DOM (charge tout en memoire, lent pour les gros documents) et SAX/StAX (evenementiel, rapide mais complexe a coder). Les deux necessitent des bibliotheques specialisees.

Parser du JSON, c'est JSON.parse(). Une ligne. Et ca fonctionne dans tous les langages modernes, avec des performances excellentes. La simplicite de la spec rend l'implementation triviale -- un parser JSON correct tient en 200 lignes de code.

4. Les types de donnees natifs

XML ne connait que du texte. <age>32</age> est une chaine de caracteres, pas un nombre. Pour savoir que c'est un entier, tu as besoin d'un schema XML (XSD) ou d'une convention documentee.

JSON a des types natifs : strings, numbers, booleans, null, arrays, objects. "age": 32 est un nombre. "active": true est un boolean. Le parser le sait sans documentation supplementaire.

5. L'ecosysteme REST

Quand Roy Fielding a formalise REST et que les APIs web ont commence a migrer de SOAP vers REST, JSON est devenu le format par defaut. Pas par decree technique, mais par usage. Les devs choisissaient JSON parce que c'etait plus simple. Les frameworks supportaient JSON en premier. Les tutoriels utilisaient JSON. Un cercle vertueux s'est installe.

Twitter, Facebook, Google Maps, GitHub -- les APIs qui ont defini le web moderne utilisaient toutes JSON. Une fois que les geants adoptent un format, le reste suit.

Ce que XML fait encore mieux

Attention, JSON n'est pas superieur en tout. XML garde des avantages techniques reels.

Schemas et validation. XSD permet de definir exactement la structure attendue d'un document, avec des contraintes complexes (intervalles, patterns, types derives). JSON Schema existe, mais il est moins mature et moins puissant.

Namespaces. Quand tu combines des donnees de sources differentes, les namespaces XML evitent les collisions de noms. JSON n'a pas d'equivalent -- tu te debrouilles avec des conventions de nommage.

Contenu mixte. XML gere naturellement le texte melange a des elements structures : <p>Le <b>gras</b> est utile</p>. JSON ne peut pas representer ca sans conventions artificielles.

Signatures et chiffrement. XML Signature et XML Encryption sont des standards matures pour signer et chiffrer des parties specifiques d'un document. C'est pourquoi SAML (authentification enterprise) est toujours en XML.

Transformations. XSLT permet de transformer un document XML en un autre format (HTML, texte, autre XML) de maniere declarative. Il n'y a pas d'equivalent JSON aussi puissant.

Les pretendants au trone

JSON n'est pas le dernier chapitre. D'autres formats grappillent des parts de marche dans des niches specifiques.

YAML. Populaire pour les fichiers de configuration (Docker Compose, Kubernetes, GitHub Actions). Plus lisible que JSON grace a l'indentation et aux commentaires. Mais le parsing est un cauchemar -- la spec YAML fait 86 pages, et les regles d'indentation sont un nid a bugs. "The Norway problem" : country: NO est parse comme false, pas comme la chaine "NO".

TOML. Le format de configuration de Rust (Cargo.toml) et Python (pyproject.toml). Plus simple que YAML, avec des types explicites. Mais limite a la configuration -- pas adapte a l'echange de donnees.

Protocol Buffers. Le format binaire de Google. Plus compact et plus rapide que JSON, avec un schema fort et la generation de code. Utilise pour les communications inter-services (gRPC). Mais pas lisible par un humain et necessitant une etape de compilation.

MessagePack. Du JSON binaire, essentiellement. Memes types, meme structure, mais encode en binaire pour des payloads plus petits et un parsing plus rapide. Utilise par Redis, Fluentd, et certaines APIs high-performance.

Aucun de ces formats ne menace JSON sur son terrain principal : les APIs web publiques. JSON est "good enough" pour 95% des cas, et l'ecosysteme autour est trop massif pour etre deplace.

L'ironie historique

Douglas Crockford a formalise JSON en 2001 pour resoudre un probleme simple : permettre a des navigateurs web de communiquer avec des serveurs sans la complexite de XML. Un format concu pour les browsers Internet Explorer et Netscape des annees 2000.

Vingt-cinq ans plus tard, JSON est le format d'echange de donnees le plus utilise au monde. Il est partout : APIs REST, configurations, bases de donnees (MongoDB, PostgreSQL JSONB), messages (Kafka, RabbitMQ), logs (structured logging), et meme l'IA (les reponses structurees des LLM sont en JSON).

Un format qui n'a meme pas de commentaires est devenu le standard universel. C'est un rappel utile : en ingenierie, la simplicite gagne presque toujours. Pas la simplicite naive qui ignore les vrais problemes, mais la simplicite disciplinee qui refuse d'ajouter de la complexite sans raison.

XML avait raison sur beaucoup de choses. Mais il avait tort sur la plus importante : il surestimait la complexite dont les developpeurs avaient besoin. JSON a parie sur "moins, c'est mieux", et l'histoire lui a donne raison.

Ressources

• JSON.org -- la specification originale de Douglas Crockford
• RFC 8259 -- la specification JSON actuelle
• The JSON Saga -- Douglas Crockford raconte l'histoire de JSON
• XML vs JSON : A Comprehensive Comparison -- comparaison technique
• Protocol Buffers Documentation -- l'alternative binaire de Google
• The Norway Problem -- pourquoi le typage implicite de YAML est problematique