Analyser des assemblies .NET avec REA

Dans le tableau des cibles de REA, la ligne « .NET assemblies » porte une seule exigence : « None (static only) ». Aucun moteur à installer, aucun runtime à lancer. Pour une DSI qui porte des dizaines d'applications .NET Framework dont plus personne ne maîtrise le source, la promesse mérite d'être lue de près.

Ce que REA lit dans une assembly

Le README liste ce que REA renvoie pour une assembly .NET : métadonnées, instructions CIL, dépendances natives déclarées et comparaisons de builds¹. Sa documentation sur le code managé précise la méthode : REA décode le format PE/CLI avec son propre parseur, et aucune assembly n'est chargée ni exécutée². Le CLR ne démarre jamais, ce qui compte quand l'assembly vient d'un fournisseur inconnu.

Le CIL d'une assembly .NET garde beaucoup d'information après compilation : noms de types, de méthodes, signatures, références entre assemblies. L'intérêt de REA tient moins à cette lisibilité, connue depuis vingt ans, qu'à la possibilité de la parcourir à l'échelle d'un parc, avec des résultats structurés que l'agent peut interroger et recouper.

Ce qu'il ne fait pas

REA ne reconstruit pas de C#. Ses outils managés renvoient des métadonnées et du CIL ; la documentation ne décrit aucune émission de code source. Elle liste aussi ses angles morts : REA n'extrait pas le contenu des exécutables .NET single-file, n'infère pas une identité NativeAOT à partir d'un PE natif ordinaire et ne décode pas IL2CPP, confié à un outil séparé de lecture des métadonnées Unity².

NativeAOT relève de l'analyse native. REA embarque un parseur en lecture seule pour les cibles x64 PE avec des métadonnées RTR 9.1 (.NET 8) ; les autres versions et architectures sont signalées comme non prises en charge ou partielles, et l'analyse des corps de méthode passe par Ghidra³.

Le DISCLAIMER du projet rappelle la limite de fond : la décompilation, la reconstruction et l'analyse assistée par IA peuvent être incomplètes ou fausses, et les conclusions qui comptent se vérifient sur les preuves⁴.

Ce que ça apporte sur un patrimoine .NET Framework

Le cas typique : une application métier écrite en .NET Framework il y a quinze ans, maintenue par un prestataire parti, dont le dépôt ne correspond plus aux binaires en production. Avant de décider de la réécrire, l'équipe veut savoir quelles assemblies dépendent de quoi, quelles bibliothèques natives sont appelées, et ce qui a changé entre deux livraisons.

REA répond à ces trois questions sans exécuter le code. La comparaison de builds sert à vérifier que le binaire en production correspond bien au dernier source connu, ou à repérer ce qu'un correctif livré sans commit a modifié. Les dépendances natives déclarées dessinent la surface à reprendre lors d'une migration. Le tout alimente une rétro-documentation, la première étape décrite dans notre hub applications legacy sans code source.

Sur trois assemblies, un décompilateur .NET ouvert à la main suffit. REA devient intéressant sur un parc mixte, quand la même session doit passer d'une assembly .NET à une bibliothèque native ou à une application JavaScript : le README range ces cibles derrière un seul serveur MCP¹.

Lire la sortie, puis la vérifier

Une sortie REA sur du .NET reste une hypothèse documentée. Les noms de méthodes et les appels sont des faits du binaire ; l'intention métier qu'un agent en déduit ne l'est pas. Gardez la distinction visible, comme le décrit notre méthode pour lire une sortie REA, et transformez les règles déduites en tests de non-régression avant toute réécriture.

Côté droit, décompiler une assembly obéit au même cadre que tout logiciel. Observer et tester son fonctionnement est permis à l'utilisateur légitime, mais ne permet pas de la décompiler : la décompilation relève de l'interopérabilité, de la correction d'erreurs par l'acquéreur légitime (arrêt Top System) ou d'une autorisation de l'éditeur. Les conditions sont détaillées dans décompiler pour interopérer et dans notre hub clean-room ou reverse engineering.

Pour l'architecture de l'outil et son installation, voir REA expliqué en trois schémas.

Questions fréquentes

REA décompile-t-il le .NET en C# ?

Non. Il renvoie métadonnées et instructions CIL. Un décompilateur .NET dédié reste l'outil pour obtenir du C# lisible.

Faut-il un moteur de décompilation pour le .NET ?

Pas pour le code managé, lu statiquement. Ghidra intervient pour les corps de méthode NativeAOT.

Est-ce utile sur du .NET Framework ancien ?

Oui, pour cartographier un parc : dépendances, appels natifs, écarts entre builds. La décision de réécrire vient ensuite.

Préparer la modernisation

La Software Factory de SFEIR part de cette rétro-documentation pour réécrire les applications .NET sur une stack maintenue, sous tests de non-régression (golden master).

Sources

1. morluto/rea, README (tableau « What you can analyze »), github.com/morluto/rea, consulté le 17 octobre 2026.
2. morluto/rea, Managed code analysis (docs/managed-code-analysis.md), github.com, consulté le 17 octobre 2026.
3. morluto/rea, Optional NativeAOT metadata recovery (docs/ghidra-nativeaot.md), github.com, consulté le 17 octobre 2026.
4. morluto/rea, DISCLAIMER.md, github.com, consulté le 17 octobre 2026.