OCPP 1.6 JSON vs SOAP - Pourquoi JSON a gagné
Pourquoi OCPP 1.6J (JSON sur WebSocket) domine les déploiements, où SOAP apparaît encore, et que faire si vous héritez d'une flotte SOAP.
OCPP 1.6 JSON vs SOAP. Pourquoi JSON a gagné
OCPP 1.6 existe en deux variantes : 1.6J (JSON sur WebSocket) et 1.6S (SOAP sur HTTP). Si vous démarrez quoi que ce soit de nouveau en 2026, vous utiliserez JSON. Mais SOAP n'a pas complètement disparu du terrain, et si vous héritez d'un déploiement ancien, vous devez comprendre pourquoi la différence compte.
Côte à côte
| OCPP 1.6J (JSON) | OCPP 1.6S (SOAP) | |
|---|---|---|
| Transport | WebSocket | HTTP |
| Format des données | JSON | XML |
| Connexion | Persistante, bidirectionnelle | Requête-réponse |
| Serveur → Borne | Natif via WebSocket | La borne doit exposer un endpoint HTTP |
| Overhead par message | ~100-200 octets | ~2-5 Ko (enveloppe XML + namespaces) |
| Outillage | Parsez avec JSON.parse() | Parsing XML, génération WSDL nécessaires |
| Support moderne | Universel | En déclin |
Pourquoi JSON domine
WebSocket est bidirectionnel. Avec SOAP sur HTTP, le backend ne peut pas pousser de messages vers la borne sans que celle-ci expose un endpoint HTTP entrant. Ça veut dire que la borne a besoin d'une IP publique ou d'un port forwarding. La traversée NAT devient un casse-tête, les pare-feux bloquent les connexions entrantes.
Avec JSON/WebSocket, la borne ouvre une connexion sortante et les deux côtés communiquent librement. Aucun problème de pare-feu.
Rendering diagram...
Les messages sont petits. Un StartTransaction typique en JSON fait environ 140 octets. Le même message en SOAP, avec les namespaces XML et l'enveloppe, fait 2-3 Ko. Sur du matériel contraint avec un lien cellulaire lent, cette différence s'accumule.
Expérience développeur. JSON est natif dans chaque langage utilisé en backend moderne. JSON.parse() et c'est fait. SOAP nécessite du parsing XML, de la génération WSDL, du traitement de namespaces, et généralement une bibliothèque spécialisée. C'est pas impossible, c'est juste de la friction que personne ne veut.
Où SOAP apparaît encore
Bornes anciennes. Beaucoup d'unités fabriquées avant 2018-2019 ne supportent que OCPP 1.6S. Si un opérateur en a des centaines sur le terrain, il ne va pas les remplacer pour une variante de protocole.
Réseaux gouvernementaux et énergétiques. Certains anciens cahiers des charges imposaient SOAP explicitement. Les protocoles basés sur XML étaient considérés comme "enterprise-grade" à l'époque.
Régions spécifiques. Des poches de déploiements SOAP-only existent dans certaines parties d'Europe, d'Asie et d'Amérique du Sud, issues de programmes d'infrastructure VE précoces.
Migration de SOAP vers JSON
Si vous êtes bloqué sur SOAP et voulez migrer :
Rendering diagram...
Beaucoup de bornes supportent en fait les deux variantes mais ont été configurées en SOAP au déploiement parce que c'est ce que le CSMS original demandait. Souvent, une mise à jour firmware ajoute le support JSON, ou il est déjà là. il suffit de changer l'URL de l'endpoint.
Faites tourner les deux protocoles en parallèle pendant la migration. Votre backend peut accepter les deux. Basculez les bornes une par une, testez, puis passez au lot suivant.
OCPP 2.0.1 est JSON uniquement
Il n'y a pas de variante SOAP dans OCPP 2.0.1. Si votre feuille de route inclut une montée vers 2.0.1, le support JSON est de toute façon obligatoire.
Rendering diagram...
La direction est claire. JSON a gagné. Planifiez en conséquence.