J'ai installé REA avec Codex et Ghidra sous Windows : ce que l'outil viral fait vraiment

Le dépôt viral, vérifié au-delà du slogan

REA, pour Reverse Engineer Anything, a été créé sur GitHub le 14 avril 2026. Le 23 octobre, l'API officielle du dépôt indiquait 372 963 étoiles. Cette progression explique les formules spectaculaires comme « le logiciel est mort ». Le dépôt officiel formule une promesse plus précise : permettre à un agent d'inspecter une application, des formats JavaScript ou Electron jusqu'aux binaires natifs, puis de présenter ses conclusions avec des éléments observables. Comprendre une fonction n'est pas recevoir une copie prête à vendre.

• REA orchestre des outils existants et spécialisés, notamment Ghidra, Hopper ou IDA selon l'environnement disponible.
• L'agent peut questionner les résultats, suivre une piste et synthétiser les éléments utiles sans que l'utilisateur maîtrise chaque interface d'analyse dès le départ.
• Le résultat reste une investigation : il contient des observations, des limites et des inconnues qui doivent être relues avant toute décision.

Ce que j'ai réellement validé avec Codex

Dans TestCodex, j'ai traité l'installation comme un petit projet technique avec versions, vérifications et diagnostic final. Sur Windows, le paquet JavaScript dépend d'un artefact natif précis et Ghidra exige un environnement Java compatible.

1. 1

   Installer REA 6.7.0 dans un espace de travail isolé avec Node.js 24.22.1, puis restaurer l'artefact natif Windows correspondant exactement à cette version.

2. 2

   Exécuter les contrôles du projet : la vérification de l'artefact Windows et la construction mise en cache ont toutes deux réussi.

3. 3

   Prévisualiser la configuration, enregistrer REA pour le client Codex et conserver la sauvegarde du fichier de configuration avant modification.

4. 4

   Installer Ghidra 12.1.4 avec JDK 21, déclarer Ghidra comme moteur d'analyse et vérifier les chemins plutôt que de supposer qu'ils sont détectés.

5. 5

   Lancer le diagnostic REA pour Codex et le skill : le résultat final était sain, avec l'enregistrement de l'agent, les instructions et le moteur d'analyse alignés.

La preuve s'arrête là où le test s'arrête

Cette installation prouve que l'environnement est prêt à recevoir une investigation. Elle ne prouve pas encore qu'une application payante a été reproduite, que toutes ses fonctions ont été comprises ou qu'une version peut être commercialisée. J'ai étudié le scénario d'une application de dictée et les fonctions qu'une alternative devrait proposer, mais aucune reconstruction complète n'a été développée ni testée dans cette session. Afficher cette limite ne diminue pas le résultat : cela évite de transformer une préparation technique réussie en promesse produit prématurée.

Ce que mon installation permet réellement de vérifier

Mon expérience ne prouve pas qu'un agent peut reproduire n'importe quel logiciel à l'identique. Elle apporte une preuve plus précise : REA peut fournir à Codex un environnement d'analyse structuré, avec Ghidra pour examiner certains binaires et un diagnostic qui rend les dépendances visibles. La valeur vient des observations traçables, pas d'une promesse de copie automatique. Une fonction locale peut parfois être étudiée parce que son comportement se trouve sur l'appareil, tandis qu'une capacité dépendante d'un service privé reste hors de portée. REA augmente donc la quantité de preuves accessibles à l'agent, mais ne remplace ni le cadrage, ni les tests, ni les droits d'utilisation.

• Le meilleur candidat n'est pas nécessairement l'application la plus célèbre. C'est une fonction observable, exécutée localement et suffisamment petite pour être testée sans ambiguïté.
• Une reconstruction crédible ne se juge pas à une capture d'écran ressemblante. Elle doit reproduire un comportement défini, documenter les écarts et distinguer ce qui a été observé de ce qui a été conçu à nouveau.
• Lorsque le produit repose sur un serveur, un modèle propriétaire, une base de données privée ou une API non documentée, REA peut révéler des appels et des interfaces, mais pas récupérer l'infrastructure qui se trouve derrière.

Pourquoi Ghidra change la qualité de l'analyse

Un agent de code sait lire un dépôt source qui lui est donné. Une application distribuée arrive souvent sous une autre forme : exécutable, bibliothèque, paquet Electron, assembly .NET ou application Android. Ghidra apporte les outils d'analyse statique nécessaires pour examiner ces artefacts, identifier des fonctions, suivre des références et produire une représentation exploitable. REA sert alors de couche d'orchestration : Codex peut demander une observation ciblée, recevoir une réponse structurée et conserver les preuves et les limites. Cela ne recrée pas le code source original. Une décompilation produit une interprétation, avec des noms perdus, des optimisations et parfois des protections qui réduisent la précision.

• REA doit être vu comme une interface entre l'agent et plusieurs moteurs d'analyse, pas comme un nouveau décompilateur magique.
• Ghidra améliore surtout les questions qui dépendent d'un binaire natif : où commence une fonction, quelles bibliothèques elle appelle et quelles données locales elle manipule.
• La conclusion doit toujours citer l'artefact observé, le moteur utilisé et les zones inconnues. Sans cette trace, une explication convaincante reste difficile à vérifier.

Le cas d'une application de dictée : ce qu'il faudrait reconstruire

Une application de dictée comme Wispr Flow constitue un bon exercice de cadrage, mais pas une preuve automatique de clonage. Il faut d'abord séparer l'expérience visible de l'infrastructure. Côté local, on peut observer un raccourci clavier, l'ouverture du microphone, un indicateur d'écoute, l'insertion du texte et le comportement de l'interface. Côté distant, la transcription, la correction et la personnalisation peuvent dépendre de modèles et de services privés. Une alternative propre doit donc reconstruire son propre pipeline : capture audio autorisée, moteur de transcription choisi légalement, traitement du texte, gestion des erreurs, interface originale et tests de latence. Mon expérimentation a validé l'environnement REA, Codex et Ghidra qui permettrait cette investigation. Elle n'a pas encore produit ni validé une copie commercialisable de Wispr Flow.

• Définir un seul comportement mesurable, par exemple déclencher la dictée avec un raccourci et insérer le résultat dans un champ de test.
• Observer uniquement ce qui est nécessaire et autorisé : événements locaux, fichiers créés, processus lancés et appels réseau indispensables à la compréhension du flux.
• Concevoir une implémentation indépendante avec ses propres composants, ses propres textes, son identité visuelle et un moteur de transcription dont la licence permet l'usage prévu.
• Comparer la nouvelle version à une spécification de comportement, pas au code interne supposé du produit étudié.

La frontière décisive entre logique locale et service cloud

Le discours viral mélange souvent deux réalités. Une application locale peut contenir une grande partie de sa logique dans les fichiers installés : interface, calculs, règles, stockage et intégrations système. Une application connectée peut n'embarquer qu'une interface et quelques appels vers un service distant. Dans le second cas, comprendre la requête ne révèle ni le modèle, ni les données, ni les règles exécutées sur le serveur. REA peut aider à cartographier cette frontière. Il ne la supprime pas. Cette distinction protège aussi le projet : elle évite de promettre une reconstruction complète alors que l'on ne possède qu'une vue du client.

• Local et observable : comportement d'interface, raccourcis, formats de fichiers, logique embarquée et interactions avec le système.
• Observable mais non récupérable : adresse d'un service, structure d'une requête, codes de réponse et séquence d'appels visibles pendant un test autorisé.
• Non observable depuis le client : code du serveur, données privées, entraînement d'un modèle, règles internes et infrastructure d'exploitation.

Le cadre propre : autorisation, licence et reconstruction indépendante

La capacité technique n'accorde pas un droit automatique. Avant toute analyse, il faut vérifier la licence, les conditions d'utilisation, les règles applicables et l'autorisation sur la cible. Le chemin le plus sûr pour apprendre est d'utiliser son propre logiciel, un projet open source dont la licence est comprise, un exemple explicitement autorisé ou un binaire conçu pour la formation. Pour une reconstruction, la méthode dite clean-room sépare les observations fonctionnelles de l'implémentation nouvelle : une spécification décrit le comportement permis, puis le nouveau produit est construit sans reprendre le code, les actifs, les textes ou la marque du logiciel étudié.

• Ne jamais contourner une protection, un contrôle d'accès ou une restriction technique pour accélérer une démonstration.
• Conserver la source de l'autorisation, la version de l'artefact, les commandes exécutées et les résultats obtenus afin de pouvoir auditer le travail.
• Faire vérifier le projet par un professionnel compétent lorsque la redistribution, la vente, les données personnelles ou une licence propriétaire créent un risque juridique.

Une méthode en cinq étapes pour un vrai cas d'usage

La méthode utile consiste à réduire l'ambition jusqu'à obtenir une question testable. REA devient pertinent lorsque l'équipe sait ce qu'elle cherche, possède le droit d'observer la cible et peut vérifier le résultat. Voici le processus que j'utiliserais pour passer de l'installation validée à une expérimentation produit reproductible.

1. 1

   Choisir une fonction et écrire son contrat de comportement : entrée, action, sortie attendue, délai acceptable et cas d'échec. Écarter les objectifs vagues comme copier toute l'application.

2. 2

   Qualifier la cible avant l'analyse : format de l'application, système, dépendance au cloud, licence, autorisation et données potentiellement sensibles. Arrêter le projet si le périmètre n'est pas légitime.

3. 3

   Demander à Codex et REA une investigation limitée. Chaque conclusion doit être reliée à une observation, un fichier, une fonction, un événement ou un appel, avec les incertitudes explicitement marquées.

4. 4

   Écrire une spécification indépendante, puis reconstruire uniquement le comportement utile avec des composants autorisés. L'interface, la marque, les textes et l'architecture de la nouvelle solution doivent rester originaux.

5. 5

   Tester sur un jeu de cas préparé avant le développement. Mesurer la conformité, la latence, les erreurs et les écarts. Documenter ce qui fonctionne, ce qui manque et ce qui exige encore une validation humaine ou juridique.

Où REA peut créer de la valeur en entreprise

Le cas d'usage professionnel le plus solide n'est pas la copie d'un concurrent. REA peut aider une équipe à comprendre un ancien logiciel sans documentation, préparer une migration, vérifier un comportement de sécurité autorisé, analyser une dépendance abandonnée ou documenter une intégration dont le code source n'est plus disponible. Dans ces scénarios, la valeur vient de la réduction de l'incertitude. L'agent accélère la collecte et l'explication, tandis que les spécialistes décident du changement et vérifient les risques.

• Maintenance : retrouver le rôle d'un composant ancien avant une mise à jour ou un remplacement.
• Migration : cartographier les entrées, sorties et formats réellement utilisés par une application métier.
• Sécurité autorisée : produire des observations reproductibles sur un binaire appartenant à l'organisation ou inclus dans un périmètre de test approuvé.
• Interopérabilité : comprendre un comportement local nécessaire pour construire une intégration indépendante, sans reprendre des éléments protégés.

Mon verdict après l'installation

REA ne signifie pas que le logiciel est mort. Il signifie que l'écart entre un expert équipé d'outils spécialisés et une équipe capable de poser de bonnes questions commence à se réduire. Mon test apporte une preuve précise : sous Windows, j'ai obtenu une installation REA 6.7.0 vérifiée, une intégration Codex cohérente et un moteur Ghidra 12.1.4 déclaré sain. La prochaine preuve devra être plus exigeante : analyser une fonction autorisée, produire un dossier d'observations, reconstruire une version indépendante et faire passer des tests préparés à l'avance. C'est à ce moment seulement qu'une démonstration devient un retour d'expérience produit.