Rétro-ingénierie logicielle

De quoi on parle

La rétro-ingénierie logicielle consiste à comprendre ce que fait un programme sans disposer de son code source. Trois gestes la composent. Observer : lancer le logiciel, regarder ses fichiers, ses appels réseau, ses écrans, ses journaux. Décompiler : passer du binaire au pseudocode (code natif via Ghidra, Hopper ou IDA), des classes Java compilées aux méthodes (JADX pour Android), des assemblies .NET aux métadonnées et aux instructions CIL. Tracer : suivre l'exécution, les canaux IPC d'une application Electron, les requêtes d'une capture HAR. Le résultat est toujours une reconstruction : du pseudocode et des graphes, jamais le code source d'origine, et le fichier DISCLAIMER de REA rappelle que « decompilation, reconstruction, heuristics, and AI-assisted analysis may be incomplete or incorrect ».

Les usages que ce même fichier liste sont ceux que l'on retrouve en entreprise : recherche en sécurité, analyse de malwares et d'incidents, recherche de vulnérabilités et divulgation coordonnée, CTF et formation, interopérabilité, préservation logicielle, et « debugging or auditing software you own or are authorized to examine ». Une DSI y ajoute deux cas qui lui sont propres : vérifier ce que fait un binaire fourni par un éditeur avant de le déployer, et retrouver les règles métier d'une application dont le code source a disparu avec son auteur ou son éditeur.

Ces éléments sont des points d'attention, pas un conseil juridique : faites-les valider par votre propre juriste.

Le cadre européen

La directive 2009/24/CE sur la protection juridique des programmes d'ordinateur fixe les règles, transposées en France à l'article L122-6-1 du Code de la propriété intellectuelle. Son article 5 autorise la personne ayant le droit d'utiliser le programme à en observer, étudier et tester le fonctionnement pour en déterminer les idées et principes, au cours d'opérations auxquelles elle est autorisée (L122-6-1, III). Son article 6 autorise la décompilation quand elle est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un programme créé de façon indépendante, sous trois conditions et avec trois interdits, dont celui d'utiliser les informations pour « la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire » (L122-6-1, IV). Le dernier alinéa de l'article tranche les contrats : « Toute stipulation contraire aux dispositions prévues aux II, III et IV du présent article est nulle et non avenue. » La correction d'erreurs par l'acquéreur légitime (I) reste, elle, réservable par contrat.

La Cour de justice de l'Union européenne a précisé deux points. Le 2 mai 2012, dans SAS Institute (C-406/10), elle a jugé que ni la fonctionnalité d'un programme, ni le langage de programmation, ni le format des fichiers de données ne sont une forme d'expression protégée par le droit d'auteur, et que le titulaire d'une licence peut observer, étudier et tester le programme pour en déterminer les idées et principes. Le 6 octobre 2021, dans Top System (C-13/20), elle a jugé que l'acquéreur légitime peut décompiler tout ou partie d'un programme pour corriger des erreurs affectant son fonctionnement, y compris en désactivant une fonction qui le perturbe, dans la mesure nécessaire et dans le respect des conditions contractuelles, sans que les conditions de l'article 6 s'appliquent.

Le secret des affaires n'y fait pas obstacle en soi. La directive (UE) 2016/943, article 3, paragraphe 1, point b), transposée à l'article L151-3 du Code de commerce, range parmi les modes d'obtention licites « l'observation, l'étude, le démontage ou le test d'un produit ou d'un objet qui a été mis à la disposition du public ou qui est de façon licite en possession de la personne qui obtient l'information », sauf obligation juridiquement valide de limiter cette obtention. La licence du logiciel et le contrat avec l'éditeur restent donc à lire avant d'ouvrir le binaire ; la fiche clean-room traite du cas où l'on veut ensuite réécrire.

Ce que les agents changent

Jusqu'en 2026, la rétro-ingénierie restait un métier de spécialistes, et son coût tenait la curiosité à distance. Un serveur MCP comme REA, qui met Ghidra, JADX ou l'analyse d'une archive Electron à portée d'un agent de code, change ce coût. Connor Turland a reconstitué en une dizaine de minutes la logique du mode « Ne pas déranger » de Slack 4.52.171 (20 octobre 2026) et conclut que ce qui a changé, c'est « how much curiosity costs ». Aayush Tyagi a retrouvé les cinq pénalités du quick switcher d'Obsidian en 7 min 8 s de travail actif, pour 1,83 $ (18 octobre 2026). Ce qu'un spécialiste faisait en jours, un agent outillé le fait en minutes, et vos fournisseurs, vos concurrents et vos auditeurs disposent du même outil que vous.

La contrepartie est une sortie à relire. Sur Slack, l'agent a marqué 43 004 éléments comme inconnus ; sur une application Electron de 100 Mo, Ishank Choudhary a compté 744 limitations déclarées et deux scripts preload manqués, chargés à travers un helper que l'analyse statique n'a pas résolu. Tyagi retient que l'ordre compte plus que l'outil : écrire sa prédiction avant de lancer l'agent, vérifier que la classe minifiée trouvée est bien celle qui s'exécute, confronter la trace à une table de cas relevés à la main. Deux risques s'ajoutent : un binaire peut contenir des chaînes d'injection de prompt qui trompent l'agent sur ce que fait le programme (Crawford et McClure, arXiv, mai 2026), et les résultats d'outils partent dans le contexte du modèle, dont le fournisseur « has its own data policy » selon le README de REA. SFEIR traite ces deux points, confinement et choix du modèle, dans l'offre AI Cyber.