Class, JAR, WAR, PYC, BEAM : le bytecode compilé selon l'écosystème (JVM, Python, Erlang/Elixir)

Ces cinq formats n’ont pas vocation à être comparés pour un choix (chacun est imposé par le langage utilisé) mais partagent un même principe : aucun ne contient le code source original, seulement une forme intermédiaire compilée qu’une machine virtuelle ou un interpréteur spécifique sait exécuter. Comprendre ce point commun aide à saisir pourquoi ces fichiers ne s’ouvrent jamais par double-clic ordinaire, et dans quelle mesure ils peuvent être décompilés.

Format	Écosystème	Runtime requis	Contenu	Décompilation
Class	JVM (Java, Kotlin, Scala...)	JVM	Bytecode d'une seule classe	Approximative (outils comme CFR, JD-GUI)
JAR	JVM	JVM	Archive ZIP de .class + manifeste	Idem, classe par classe
WAR	Jakarta EE (ex-Java EE)	Serveur d'applications (Tomcat, WildFly)	Application web complète (JAR + web.xml)	Idem, via ses JAR internes
PYC	Python	Interpréteur Python (version précise)	Bytecode d'un module	Relativement aisée
BEAM	Erlang / Elixir	Machine virtuelle BEAM	Bytecode d'un module	Peu répandue en pratique

Le Class est le bytecode d’une seule classe Java, produit par javac et interprété (ou compilé à la volée) par la JVM, le pilier du « écrit une fois, exécuté partout » de la plateforme. D’autres langages de la JVM (Kotlin, Scala, Groovy) compilent vers ce même format, ce qui leur permet d’interopérer nativement avec du code Java existant. Sa décompilation vers un code source lisible reste possible mais approximative : les noms de variables et certains commentaires d’origine sont généralement perdus.

Le JAR regroupe des fichiers .class compilés, des ressources et un manifeste dans une archive ZIP standard, distribuable et exécutable via java -jar. Il a été introduit avec le JDK 1.1 en 1997 pour éviter de multiplier les requêtes HTTP par fichier .class lors du chargement d’une applet. Le WAR est une variante spécialisée du JAR pour une application web Jakarta EE complète : classes compilées, bibliothèques dépendantes, pages JSP et un descripteur web.xml (facultatif depuis Servlet 3.0), le tout nécessitant un serveur d’applications compatible (Apache Tomcat, WildFly) pour s’exécuter : un serveur web générique ne sait servir que des fichiers statiques, pas interpréter ce bytecode packagé.

Le PYC diffère des deux précédents par sa nature : c’est avant tout un cache de performance, généré automatiquement par l’interpréteur Python (souvent dans un dossier __pycache__) pour éviter de recompiler le code source à chaque exécution, plutôt qu’un format de distribution à proprement parler. Son en-tête change à chaque version mineure de Python, ce qui le rend généralement incompatible d’une version à l’autre, et sa décompilation reste nettement plus aisée que celle d’un binaire natif, offrant une protection limitée à qui chercherait à distribuer du code Python sans révéler sa logique interne.

Le BEAM est le bytecode compilé exécuté par la machine virtuelle du même nom, partagée par Erlang et Elixir, deux langages de syntaxe différente qui compilent néanmoins vers exactement le même format binaire intermédiaire, à l’image de la relation entre Kotlin et le bytecode Java. Un module BEAM compilé depuis Elixir interopère directement avec un module compilé depuis Erlang, sans couche de conversion, ce qui permet à l’écosystème Elixir de réutiliser directement l’immense bibliothèque OTP d’Erlang.

Ces cinq formats ne sont donc interchangeables ni entre eux ni avec leur code source : chacun exige le runtime précis de son écosystème (JVM, serveur Jakarta EE, interpréteur Python d’une version donnée, machine virtuelle BEAM) pour s’exécuter, et aucun ne protège efficacement contre une décompilation à des degrés de fidélité variables selon le format.