Décompiler pour interopérer : l'article 6 de la directive expliqué à une DSI
Le 23 avril 2009, l'Union européenne a codifié dans la directive 2009/24/CE un droit que peu de DSI utilisent : décompiler un programme sans l'accord de son auteur quand c'est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante1. En France, la règle figure au IV de l'article L122-6-1 du Code de la propriété intellectuelle2. Avec les outils de rétro-ingénierie pilotés par agents comme REA, la décompilation ne demande plus des semaines d'expert. Le cadre juridique, lui, n'a pas bougé.
Le principe
L'article 6 de la directive autorise la reproduction du code et la traduction de sa forme, autrement dit la décompilation, quand ces actes sont indispensables pour obtenir les informations nécessaires à l'interopérabilité d'un programme créé de façon indépendante avec d'autres programmes. Il s'agit d'une exception au monopole de l'auteur. Les juges l'interprètent donc strictement.
Le cas typique d'une DSI : une application métier achetée il y a quinze ans échange des fichiers ou des messages selon un protocole jamais documenté, l'éditeur ne répond plus, et vous devez la faire dialoguer avec un nouveau système. Comprendre ce protocole en lisant le programme peut entrer dans le champ de l'article 6, si les trois conditions qui suivent sont réunies.
Les trois conditions
Le texte pose trois conditions cumulatives. La personne qui décompile a le droit d'utiliser une copie du programme, ou agit pour le compte d'une telle personne. Les informations nécessaires à l'interopérabilité ne lui sont pas déjà facilement et rapidement accessibles. Les actes se limitent aux parties du programme nécessaires à cette interopérabilité.
La deuxième condition se traite en premier. Avant de décompiler, demandez la documentation à l'éditeur, cherchez une spécification publique, un SDK, une API documentée. Gardez la trace de ces démarches : elle montre que l'information n'était pas facilement accessible. La troisième condition impose de rester ciblé. Un outil comme Ghidra importe souvent tout le binaire avant qu'on cible une fonction : ce qui compte, c'est de limiter l'étude et l'usage aux parties nécessaires à l'interopérabilité, et de le documenter.
Les trois interdits
Les informations obtenues ne peuvent pas être utilisées à d'autres fins que l'interopérabilité du programme créé de façon indépendante. Elles ne peuvent pas être communiquées à des tiers, sauf si c'est nécessaire à cette interopérabilité. Elles ne peuvent pas servir à la mise au point, à la production ou à la commercialisation d'un programme « dont l'expression est substantiellement similaire », ni à tout autre acte portant atteinte au droit d'auteur12.
Le troisième interdit est le piège des projets de réécriture. Décompiler pour comprendre un protocole, puis réécrire à l'identique la fonction qui le produit, sort de l'exception. La méthode clean-room, qui sépare l'analyse de la réécriture, existe précisément pour éviter ce glissement ; notre page sur le clean-room et la rétro-ingénierie l'explique.
Interopérabilité ou correction d'erreurs : deux régimes
Un autre régime existe, à ne pas confondre. L'article 5 de la directive vise les actes nécessaires à l'utilisation du programme par l'acquéreur légitime, dont la correction d'erreurs. Le 6 octobre 2021, dans l'arrêt Top System (C-13/20), la Cour de justice de l'Union européenne a jugé que l'acquéreur légitime peut décompiler tout ou partie d'un programme pour corriger des erreurs qui en affectent le fonctionnement, dans la mesure nécessaire et dans le respect des conditions contractuelles. La Cour précise que cette décompilation ne relève pas des conditions de l'article 63.
En droit français, le I de l'article L122-6-1 permet à l'auteur de se réserver par contrat le droit de corriger les erreurs2. Le contrat de licence pèse donc lourd sur ce second régime.
Enfin, l'arrêt SAS Institute du 2 mai 2012 (C-406/10) rappelle que la fonctionnalité d'un programme, son langage et le format de ses fichiers de données ne constituent pas une forme d'expression protégée du programme4. La Cour réserve toutefois qu'un langage ou un format puisse être protégé comme œuvre, au titre de la directive 2001/29/CE, s'il est original. Comprendre un format d'échange pour le relire ailleurs part donc d'un terrain favorable, à vérifier au cas par cas avec votre juriste.
Ce que ça implique côté outillage
Un agent équipé de REA peut piloter Ghidra sur un exécutable natif et rendre pseudocode, chaînes et références, avec les preuves et les limites de chaque conclusion5. Pour rester dans l'article 6, cadrez la session : une question précise (le format d'un message, la séquence d'un échange), un périmètre de fonctions limité, et la conservation des preuves produites, qui aident à démontrer la proportionnalité. Évitez la demande « reconstruis l'application » : elle dépasse le nécessaire et prépare un clone.
Le README de REA renvoie lui-même à ce cadre : l'outil vise l'analyse légale, dont l'interopérabilité, et sa clause de non-responsabilité rappelle que la rétro-ingénierie peut être restreinte par le droit applicable ou par la licence du logiciel analysé6. Un cas réel montre la limite inverse : les clones d'Adobe d'ArtCraft, réimplémentés à partir du comportement observé selon leur développeur, ne relèvent pas de l'interopérabilité mais du principe selon lequel le droit d'auteur ne protège pas les fonctionnalités.
Questions fréquentes
Puis-je décompiler pour faire communiquer deux logiciels ?
Oui, si vous avez le droit d'utiliser le programme, si l'information n'est pas facilement accessible ailleurs et si vous vous limitez aux parties nécessaires. Gardez la trace de chaque étape.
Puis-je réutiliser ce que j'ai trouvé pour un clone ?
Non. La directive et l'article L122-6-1 interdisent d'utiliser ces informations pour un programme dont l'expression est substantiellement similaire.
La correction d'erreurs est-elle couverte ?
Par un autre régime : l'article 5, interprété par l'arrêt Top System (C-13/20), dans la mesure nécessaire à la correction d'erreurs affectant le fonctionnement et dans le respect des conditions contractuelles, l'éditeur pouvant se réserver la correction par contrat (I de l'article L122-6-1).
Une clause de licence peut-elle interdire cette décompilation ?
En droit français, une stipulation contraire au IV de l'article L122-6-1 est nulle. Le reste du contrat continue de s'appliquer.
Pour faire dialoguer une application ancienne avec le reste du SI, ou préparer son remplacement, la Software Factory SFEIR part de la rétro-documentation des échanges et des règles métier, dans le cadre validé avec votre juriste.
Sources
- Directive 2009/24/CE du Parlement européen et du Conseil du 23 avril 2009 concernant la protection juridique des programmes d'ordinateur, article 6 — eur-lex.europa.eu.
- Code de la propriété intellectuelle, article L122-6-1 — legifrance.gouv.fr.
- CJUE, 6 octobre 2021, Top System SA contre État belge, C-13/20 — curia.europa.eu.
- CJUE, 2 mai 2012, SAS Institute Inc. contre World Programming Ltd, C-406/10 — curia.europa.eu.
- morluto/rea, README (cibles et retour de preuves) — github.com/morluto/rea, consulté le 12 octobre 2026.
- morluto/rea, DISCLAIMER.md — github.com/morluto/rea, consulté le 12 octobre 2026.
Faire dialoguer une application legacy avec le reste du SI
Découvrir la Software FactoryArticles similaires
Clean-room ou reverse engineering : méthode et risque juridique à l'ère des agents
Rétro-ingénierie et clean-room ne se confondent pas en droit. Ce que la directive 2009/24/CE, le Code de la propriété intellectuelle et la CJUE autorisent, et pourquoi un agent qui lit le décompilé puis réécrit fragilise la défense.
ArtCraft : des clones d'Adobe en clean-room revendiqué, ce que vaut l'argument
Depuis le 30 septembre 2026, ArtCraft publie des réécritures en Rust de Photoshop, Premiere ou Lightroom, écrites avec Claude et présentées comme clean-room. Ce que la revendication couvre en droit européen, et ce qu'elle laisse ouvert.