Reverse Engineer Anything (REA) : toutes les applis sont-elles devenues open source ?

Non, Reverse Engineer Anything n’a pas rendu toutes les applis open source. REA, le dépôt GitHub viral pour Claude Code et Codex, branche ton agent de code sur des outils de rétro-ingénierie comme Ghidra ou IDA. Il lui permet d’expliquer, preuves à l’appui, comment marche une fonctionnalité d’une appli qui tourne sur ta machine. Il ne te donne ni le code source, ni le serveur d’un SaaS, ni le droit de recopier quoi que ce soit, et son propre avertissement refuse d’aider à « copier un logiciel propriétaire ». Cette page détaille ce qu’une IA peut sortir d’une appli selon son type, la seule preuve mesurée, mon prompt pour le faire sans REA, les liens officiels des applis gratuites qui copient Adobe et ce que dit la loi en France.

Vérifié le 18 octobre 2026 : dépôt morluto/rea (README, avertissement, skill version 42, version 6.5.0), cas DX-Ball sur rea.tools, page officielle des Crafting Apps et leurs dépôts GitHub, directive 2009/24/CE, article L122-6-1 du Code de la propriété intellectuelle et arrêt SAS Institute. Je ne suis pas avocat : la partie loi est de la vulgarisation, pas un conseil juridique.

La vidéo en chapitres : site web · Electron, natif, iPhone · comment marche REA · la preuve DX-Ball · avec ou sans REA · le prompt · le clone d’Adobe · ce que dit la loi · Samba, Mario 64 · open source ou pas ?

Sommaire : ce qu’une IA voit selon le type d’appli · mon prompt (prompt de la 2e session, version pour apprendre, avec REA, d’où il vient) · comment marche REA (installer REA dans Claude Code) · la preuve DX-Ball · avec ou sans REA (les outils sans REA) · ArtCraft et les clones d’Adobe · la loi · ce que REA ne peut pas faire · rien de nouveau · verdict

La phrase « toutes les applis du monde sont maintenant open source » vient du titre d’une vidéo de Fireship, vue plus de 5 millions de fois au 17 octobre. Elle mélange deux histoires sans lien : REA, un outil d’analyse, et ArtCraft, une suite de clones d’Adobe écrite sans REA. Les deux sont traités ici, séparément.

Rétro-ingénierie : ce qu’une IA peut sortir d’une appli selon son type

Plus une appli tourne chez toi, plus une IA peut l’étudier ; plus elle tourne chez l’éditeur, moins on en voit. Tout dépend de ce que ton ordinateur reçoit vraiment quand tu installes ou ouvres l’appli.

Quelques mots pour suivre la suite. Le code source, c’est ce qu’écrivent les développeurs. Le compilateur le traduit en instructions pour le processeur : ce fichier traduit, le binaire, est ce que tu installes. Pendant la traduction, les noms de fonctions et les commentaires disparaissent. Un décompilateur refait le chemin à l’envers et sort du pseudo-code : du code qui ressemble à du C, reconstruit à partir des instructions, sans les vrais noms et parfois faux.

Une chose survit à la compilation : les textes. Le libellé d’un bouton ou un message d’erreur restent lisibles dans le binaire. Toute enquête commence par là : on cherche le texte, puis on remonte à la fonction qui l’affiche. Côté web, c’est encore plus simple : dans le JavaScript du jeu du dinosaure de Chrome, on retrouve la vitesse de départ et l’accélération. Mais pour un SaaS, le cœur tourne sur la machine de l’éditeur et n’en sort jamais. Ni toi, ni une IA, ni REA ne le verrez.

Mon prompt de rétro-ingénierie pour Claude Code, sans REA

Ce prompt fait suivre à Claude Code ou à Codex la méthode de REA sans l’installer : une seule fonctionnalité, des preuves classées, un garde-fou juridique et deux sessions séparées. Je l’ai écrit à partir de la méthode officielle de REA (son skill, publié sous licence MIT). Remplace les crochets, puis colle-le dans une session neuve de ton agent ; il fonctionne aussi avec un agent de code gratuit.

Je veux comprendre puis reproduire UNE fonctionnalité : [fonction] de [appli].
Cible : [chemin de l'appli installée ou URL]. Mon droit : [elle m'appartient / elle est open source / j'ai une licence d'utilisation]. But : [comprendre et refaire à ma façon / la faire fonctionner avec un autre programme, par exemple lire son format pour récupérer mes données / corriger un bug].

1. Avant tout outil, identifie le type de cible : site web, appli Electron (fichier .asar), binaire natif (Mach-O, EXE, ELF), Android, .NET. Dis-moi ce qu'on peut voir pour ce type, et ce qu'on ne verra jamais (par exemple le serveur d'un SaaS).
2. Choisis les outils selon ce type, ceux déjà installés d'abord : navigateur et onglet Réseau pour le web ; extraction du .asar et lecture du JavaScript pour Electron ; strings et objdump, puis Ghidra en mode headless pour un natif. Règle de droit (UE, directive 2009/24) : si l'appli ne m'appartient pas et n'est pas open source, n'ouvre son binaire (désassemblage, décompilation) que si le but est l'interopérabilité ou la correction d'un bug ; sinon reste en observation : la faire tourner, regarder ses entrées, ses sorties, ses fichiers et ses échanges réseau, ses textes affichés. Demande-moi avant d'installer quoi que ce soit. N'exécute l'appli que si l'analyse statique ne suffit pas. Si je te joins une vidéo, extrais-en des images avec ffmpeg.
3. Commence par une vue d'ensemble courte, puis suis la fonctionnalité depuis son point d'entrée (bouton, route, texte affiché) jusqu'à son résultat. Ne relance jamais deux fois la même analyse.
4. Classe chaque conclusion : OBSERVÉ (avec sa preuve : fichier, adresse, requête, capture), DÉDUIT (ton raisonnement), INCONNU (ce qu'il faudrait pour trancher). Ne présente jamais une déduction comme un fait.
5. Écris dans SPEC.md une description du comportement (entrées, sorties, cas limites, tests à passer) sans copier de code, de texte, d'icône ni d'image de l'original. Puis arrête-toi.
6. Je lance ensuite une nouvelle session qui ne reçoit que SPEC.md : elle construit ma version avec mon nom et mon design, écrit les tests, et compare son comportement à l'original sur les mêmes entrées jusqu'à ce qu'ils passent.
7. Termine chaque session par la liste des questions résolues, à moitié résolues et non résolues.

Pourquoi chaque règle

• Le type d’appli et ce qu’il ne verra jamais (règle 1). L’agent commence par dire ce qui est visible pour cette cible. Il ne va pas te promettre le serveur de Trello, ni chercher un décompilateur pour une appli web.
• Les outils déjà installés, ton accord avant d’installer, et le garde-fou de droit (règle 2). Pas de logiciel ajouté dans ton dos. Et l’agent n’ouvre le binaire d’une appli qui ne t’appartient pas que dans les deux cas que la loi européenne autorise ; sinon, il observe l’appli en marche, ce qui reste permis (détails plus bas). Une précision que le prompt ne dit pas : pour une appli Electron ou Android qui ne t’appartient pas, extraire son .asar ou décompiler son APK revient aussi à reproduire son code. Remplis alors « Mon droit » honnêtement et considère que la même règle s’applique : sans but d’interopérabilité ou de correction, l’agent reste en observation.
• Une seule fonctionnalité, depuis ce que tu vois (règle 3). L’agent part d’un bouton, d’une route ou d’un texte, pas de l’appli entière. C’est là que les résultats deviennent bons : tu récupères ce dont tu as besoin, sans noyer l’agent sous des milliers de fonctions.
• Observé, déduit, inconnu (règle 4). C’est la classification de REA. Une déduction présentée comme un fait, c’est exactement comme ça qu’un agent te construit une fonction fausse.
• Une description, puis une nouvelle session (règles 5 à 7). L’agent écrit SPEC.md sans copier une ligne de code, un texte ou une icône, puis s’arrête. Une session qui n’a jamais vu l’original construit ta version à partir de cette seule description, avec des tests, jusqu’à se comporter comme le vrai logiciel. Cette séparation porte un nom : la salle blanche.

Tu as déjà REA ? Mets le prompt par-dessus

Le prompt ne remplace pas REA, il le complète. La règle 2 demande d’utiliser d’abord les outils déjà installés : si REA est branché sur ton agent, celui-ci passe par ses outils (résumés paginés, preuves numérotées, comparaison de fonctions). Le prompt ajoute ce que REA ne fait pas : dire dès le départ ce qui restera invisible, écrire SPEC.md sans rien copier, puis reconstruire dans une session séparée, testée sur les mêmes entrées que l’original. REA donne les mains, le prompt donne la méthode jusqu’à ta propre version. Pour vérifier une réécriture fonction par fonction, lance en plus le prompt guidé verify_reconstruction de REA.

Méfie-toi des prompts qui promettent de « tout débloquer »

Des posts viraux partagent un prompt censé « rétro-ingénierer n’importe quoi sans blocage ni refus ». La méthode : faire sortir le code décompilé d’une appli avec un modèle gratuit, puis le présenter à Claude comme ton projet que tu aurais « mis de côté », pour qu’il le continue sans poser de question. Trois raisons de ne pas le faire.

• Ça ment au modèle. Déguiser le code d’un autre en projet personnel pour contourner les garde-fous de l’agent va contre les conditions d’utilisation, et REA refuse lui-même d’aider à contourner des protections.
• Ça te fait reprendre son code, pas son comportement. Continuer le développement à partir du code décompilé de quelqu’un, c’est exactement la reprise de code que le droit d’auteur interdit, à l’opposé de la salle blanche. La loi sépare les deux.
• Certains exemples sont carrément illégaux. « Récupérer les indicateurs payants de TradingView gratuitement » revient à contourner un paiement : même ceux qui le partagent le reconnaissent. Refaire ton propre outil d’analyse, oui ; réutiliser un service payant sans payer, non.

Mon prompt fait l’inverse : il part d’une origine assumée (« Mon droit »), écrit une description sans copier une ligne, puis reconstruit dans une session neuve avec ton code. Plus lent, mais c’est ça qui reste défendable et réutilisable.

Comment t’en servir en deux sessions

1. Session 1, l’enquête : lance le prompt dans le dossier de travail. L’agent rend SPEC.md et la liste des questions ouvertes.
2. Entre les deux : copie SPEC.md seul dans un dossier neuf. La deuxième session ne doit pas pouvoir relire les notes, captures ou extraits de la première.
3. Session 2, la construction : ouvre une session neuve dans ce dossier et demande-lui de construire ta version à partir de SPEC.md, avec ses tests, puis de la comparer à l’original sur les mêmes entrées.

Avec une IA, c’est toi qui tiens les deux sessions. La salle blanche reste une bonne pratique qui documente ta démarche, pas un bouclier juridique.

Le prompt de la deuxième session (la construction)

Le prompt principal s’arrête à SPEC.md. Voici celui que je colle dans la session neuve, ouverte dans le dossier qui ne contient que ce fichier. Il garde la séparation : l’agent peut faire tourner l’original comme une boîte noire pour comparer les sorties, jamais ouvrir son code.

Tu construis ma propre version d'une fonctionnalité à partir de SPEC.md, le seul document de ce dossier. Tu n'as ni le code ni les fichiers internes de l'appli d'origine, et tu ne dois pas les chercher.
Mon projet : [nom de ton projet, langage, contraintes].

1. Lis SPEC.md. Liste les comportements à reproduire, les cas limites et les tests demandés. Signale ce qui est ambigu avant de coder.
2. Écris d'abord les tests tirés de SPEC.md, puis le code, avec mon nom, mon design et mes propres textes.
3. Pour chaque comportement, distingue ce qui vient de SPEC.md de tes choix de conception.
4. Si l'original est installé, tu peux le lancer comme une boîte noire : mêmes entrées, puis comparaison des sorties avec ta version. N'ouvre jamais son code, ses ressources ni ses fichiers internes. Corrige jusqu'à ce que les tests passent.
5. Termine par la liste des questions résolues, à moitié résolues et non résolues.

Exemple : le prompt rempli

Deux lignes changent selon ton cas. Le reste du prompt ne bouge pas.

Je veux comprendre puis reproduire UNE fonctionnalité : l'export de mes notes de [ton ancien logiciel de notes].
Cible : [chemin de l'appli installée]. Mon droit : j'ai une licence d'utilisation. But : la faire fonctionner avec un autre programme, par exemple lire son format pour récupérer mes données.

Le but choisi change ce que l’agent a le droit de faire. Ici, c’est l’interopérabilité : il peut ouvrir le binaire pour comprendre le format de fichier. Si tu écris « comprendre et refaire à ma façon » pour une appli qui ne t’appartient pas, il reste en observation : il lance l’appli, exporte, compare les fichiers produits.

Pour apprendre : la version sans garde-fou juridique

Tu veux t’entraîner à la rétro-ingénierie, décompilation comprise ? Choisis une cible faite pour ça, puis retire le garde-fou :

1. Dans la règle 2, supprime la phrase qui commence par « Règle de droit (UE, directive 2009/24) » et se termine par « ses textes affichés. ».
2. Dans « Mon droit », écris par exemple : « c’est un exercice dont l’auteur autorise l’analyse (crackme, CTF) » ou « c’est mon propre programme ».

Les bonnes cibles pour apprendre :

• Ton propre programme : compile un petit utilitaire, puis demande à l’agent de le retrouver dans le binaire. Korben a fait ses tests ainsi, avec un faux système de licence.
• Les crackmes : de petits programmes publiés pour être cassés, sur crackmes.one.
• Les épreuves de CTF : par exemple picoCTF, de l’université Carnegie Mellon, qui a une catégorie dédiée à la rétro-ingénierie.
• Le cours officiel de Ghidra : la NSA publie ses supports et exercices dans le dépôt de Ghidra (GhidraClass).
• Un logiciel open source : tu peux comparer ce que sort le décompilateur avec le vrai code source.

Pour ta propre appli ou un logiciel open source, tu n’as même pas besoin de retirer la phrase : le garde-fou ne bloque rien dans ces cas-là. Le but éducatif, lui, n’est pas une exception prévue par la loi européenne : décompiler l’appli propriétaire de quelqu’un d’autre « pour apprendre » reste hors des deux cas autorisés (interopérabilité, correction d’un bug). Pour ces applis, garde la version complète du prompt.

Le squelette de SPEC.md

Si l’agent hésite sur la forme, donne-lui ce plan. Chaque règle est rattachée à une preuve, et rien de l’original n’est recopié.

# SPEC : [fonctionnalité]
## Ce que fait la fonctionnalité (une phrase)
## Entrées (formats, valeurs possibles)
## Sorties (formats, exemples écrits avec mes propres données)
## Règles observées (OBSERVÉ, avec la preuve : requête, fichier, capture)
## Hypothèses (DÉDUIT, avec le raisonnement)
## Inconnues (INCONNU, avec ce qu'il faudrait pour trancher)
## Cas limites
## Tests à passer (entrée → sortie attendue)
## Ce qui n'est pas repris (code, textes, icônes, nom)

Trois lignes pour un prompt encore meilleur

Ces ajouts viennent des leçons que l’équipe de REA a tirées de la reconstruction d’un jeu entier (série Touhou, 697 fonctions, 696 identiques en 12 jours). Colle-les à la fin du prompt principal quand le projet est gros.

8. Fixe d'abord les critères de réussite : quels tests doivent passer et quel comportement veut dire « fini ». Montre-les-moi avant de coder.
9. Teste tes tests : vérifie que ta comparaison échoue bien sur une version volontairement fausse. Une comparaison trop laxiste laisse passer une fonction fausse.
10. Garde tes notes, tes preuves et tes points de contrôle dans git, pour qu'une nouvelle session puisse reprendre où tu t'es arrêté.

La règle 9 corrige le piège le plus courant : dans la reconstruction de Touhou, une fonction est passée alors qu’elle comparait une valeur à 0.0 là où l’original utilisait 128.0 ; le test ne vérifiait jamais cette constante. Une réécriture qui « passe les tests » ne vaut que si les tests sont eux-mêmes vérifiés.

D’où vient ce prompt

Je l’ai construit à partir du skill officiel de REA (SKILL.md, version 42, licence MIT), dont j’ai gardé la méthode sans les outils, puis j’ai ajouté ce que le skill ne couvre pas : la loi européenne et la salle blanche.

Le garde-fou juridique est arrivé en relisant la première version : elle laissait l’agent décompiler n’importe quelle appli sous licence, ce que la loi européenne n’autorise pas pour « comprendre et refaire ». La version publiée ici est la version corrigée, la même que dans la vidéo.

Comment marche Reverse Engineer Anything (REA) : MCP, skill et tuyauterie

REA rassemble deux choses : un serveur MCP qui pilote une vingtaine de logiciels d’analyse, et un skill, un fichier texte qui explique à l’agent comment mener l’enquête. Le MCP (Model Context Protocol) est le standard ouvert publié par Anthropic le 25 novembre 2024 : il permet à un agent comme Claude Code ou Codex de piloter d’autres logiciels.

Les décompilateurs ne sont pas nouveaux : IDA existe depuis les années 90, la NSA a rendu Ghidra public en 2019, Hopper tourne sur Mac. Leur problème, c’est ce qu’ils sortent : des milliers de fonctions sans nom, que peu de spécialistes savent lire. Depuis 2025, des ponts MCP comme GhidraMCP les relient déjà à une IA. REA les rassemble en une seule installation.

• Le serveur MCP se branche sur les logiciels déjà présents sur ta machine : Hopper, Ghidra, IDA, Rizin et objdump pour les programmes ; JADX, JEB, Apktool et adb pour Android ; Frida, LLDB et GDB pour observer un programme en marche ; Chrome, mitmproxy et TShark pour le réseau ; Binwalk et Unblob pour les firmwares ; WABT pour le WebAssembly. Il lit le JavaScript, Electron et .NET sans décompilateur. Il n’installe aucun de ces outils, sauf Hopper avec ton accord. IDA, Hopper et JEB sont payants.
• Le skill donne la méthode : identifier la cible, commencer par un résumé, suivre une fonctionnalité, classer chaque conclusion. Installé seul, il ne donne à l’agent aucun outil : il apporte la méthode, pas les mains. Le copier sans le serveur ne sert à rien, il appellerait des outils que ton agent n’a pas.
• La tuyauterie fait la différence. Sur une grosse appli, une analyse brute peut dépasser le gigaoctet de texte (Nate Herk l’a constaté sur Loom), bien plus qu’une IA ne peut en lire. REA lui donne d’abord un résumé, puis seulement les morceaux qu’elle demande. Chaque résultat porte un numéro de preuve revérifiable, et des outils comparent ta version à l’original, instruction par instruction.

Au 18 octobre 2026, le dépôt morluto/rea compte 308 105 étoiles et 77 961 forks. Il a été créé le 14 avril 2026, est publié sous licence MIT, et sa version 6.5.0 date du 14 octobre.

Son avertissement liste les usages pour lesquels il est fait : recherche en sécurité, analyse de logiciels malveillants, recherche de vulnérabilités, CTF et enseignement, interopérabilité, préservation de logiciels, débogage ou audit de logiciels que tu possèdes ou que tu as le droit d’examiner. Retrouver la logique d’un de tes vieux programmes dont le code source est perdu entre dans ce dernier cas.

Installer REA dans Claude Code, pas à pas

1. Prérequis : Node.js 22.19 ou plus récent (24.11 et plus, ou 26), avec npm. Pour un programme natif, il faut aussi un moteur : Ghidra (gratuit, demande Java), IDA ou Hopper. Pour Android, JADX et un JDK. Une appli Electron ou un site ne demandent aucun moteur.
2. Voir avant d’écrire : npx -y rea-agents@latest setup --client claude_code --dry-run --json affiche les fichiers que l’installation modifierait, sans rien toucher.
3. Installer : npx rea-agents setup, choisis Claude Code (ou Codex, Cursor, Gemini CLI, Grok Build…) et valide. L’installation enregistre le serveur MCP et le skill ; elle ne propose d’installer Hopper qu’avec ton accord.
4. Redémarrer et vérifier : relance Claude Code, puis npx -y rea-agents@latest doctor --client claude_code --json contrôle l’enregistrement et les moteurs trouvés. Les outils de REA doivent apparaître dans la session.
5. Premier essai sans décompilateur : sur une appli Electron open source, npx -y rea-agents@latest analyze-javascript-application /chemin/absolu/vers/appli --json sort la carte des modules sans passer par l’agent.

Une fois branché, REA propose six prompts guidés dans le client MCP : investigate_feature (suivre une fonctionnalité), compare_application_versions (comparer deux versions d’une appli), verify_reconstruction (vérifier une réécriture), trace_crash (remonter un plantage), audit_residual_unknowns (lister ce qui reste inconnu) et prepare_bounded_process_capture (préparer une observation limitée d’un programme en marche).

Pour un premier essai guidé, REA fournit une petite appli d’entraînement officielle : une appli de notes avec un bouton « Export ». Demande à ton agent de télécharger https://rea.tools/examples/notes-example.zip, de l’ouvrir, et de retrouver ce qui se passe au clic sur « Export notes ». Tu dois obtenir le chemin complet d’un clic : le bouton (renderer.js) envoie un message notes:export via le pont (preload.js), que le processus principal (main.js) traite en écrivant un fichier notes.csv avec les colonnes id et title. C’est de la rétro-ingénierie, sur un exemple fait pour ça.

Ce qui reste sur ta machine, ce qui part chez Anthropic ou OpenAI

L’analyse tourne en local : REA lit le fichier sur ton ordinateur. Mais tout ce que l’agent reçoit part chez le fournisseur du modèle, Anthropic pour Claude, OpenAI pour Codex. Le README le dit en une phrase : ton agent reçoit les résultats, et le fournisseur du modèle « a sa propre politique de données ». Si tu veux analyser le logiciel de ta boîte, demande l’accord avant. Pour un programme suspect, travaille dans une machine virtuelle : Korben rappelle qu’un binaire piégé peut glisser de fausses instructions au modèle qui l’analyse, à travers ses textes.

REA GitHub : n’installe que le dépôt officiel

Un outil aussi viral attire les copies. Le README désigne trois sources officielles : le dépôt github.com/morluto/rea, le site rea.tools et le paquet npm rea-agents. Il ajoute qu’un nom de dépôt proche ou un README recopié ne prouve pas qu’un téléchargement est officiel. Le 17 octobre, les moteurs de recherche affichaient en bonne place des dépôts copiés, un miroir SourceForge et plusieurs sites au nom proche de « REA ». Aucun ne figure parmi les sources officielles.

La vraie preuve : DX-Ball, 3 205 cas et 63 octets

La démonstration la plus solide de REA porte sur une seule fonction d’un casse-briques de 1996, réécrite en C et prouvée identique à l’original. Sa page d’accueil montre surtout le dinosaure de Chrome et la Calculatrice de Windows. Leur code est déjà public (le dinosaure sous licence BSD, la Calculatrice publiée par Microsoft en 2019) : pratique pour vérifier, mais ça ne prouve pas grand-chose.

Le cas DX-Ball sur rea.tools est d’un autre niveau. Dans DX-Ball 1.07 (Windows, 1996), quand une brique casse, le son part à gauche ou à droite selon sa position à l’écran. L’agent retrouve dans le binaire la fonction qui fait ce calcul :

1. Premier piège : le décompilateur l’affiche comme FUN_00406400(void), une fonction sans entrée. C’est en lisant les instructions que l’agent retrouve la position de la brique, passée à l’adresse [EBP+8].
2. Réécriture : la fonction est réécrite en C (position × 1,5625 − 500, multipliée par un réglage de panoramique).
3. Test exhaustif : l’original et la copie tournent sur chaque position de 0 à 640, avec cinq réglages (0 ; 0,5 ; 1 ; 20 ; −1). Soit 3 205 cas, tous identiques.
4. Preuve au niveau des octets : recompilée avec le compilateur de l’époque (Visual C++ 4.0), la fonction redonne les mêmes 63 octets que l’original, après application des relocations vérifiées.

La limite est écrite sur la même page. Au 7 octobre 2026, le projet maintient 55 fonctions en C, dont 33 aux octets identiques, après 45 380 comparaisons avec le code original. Le jeu n’est pas encore jouable : il reste la physique de la balle et de la raquette, les bonus et l’intégration à Windows. C’est le vrai niveau de REA aujourd’hui : précis, prouvé, fonction par fonction. Pas une appli entière en un clic. Cette méthode de comparaison octet par octet est celle de la décompilation « matching », que j’explique avec le cas de GTA 5 et des jeux dans le navigateur.

Une deuxième preuve, sur une appli cette fois : REA a analysé Aegis, l’application d’authentification Android (open source, licence GPL-3.0, 3 077 classes). Il a retrouvé comment elle fabrique ses codes à 6 chiffres (le temps découpé en tranches de 30 secondes, combiné à ta clé par HMAC-SHA1), et la réécriture a reproduit les 133 cas de test. Deux cas mesurés, deux domaines : un calcul dans un vieux jeu, un algorithme de sécurité dans une appli récente.

Claude Code avec ou sans REA : ce que montrent les tests

Pour refaire ce que tu vois à l’écran, Claude Code seul suffit et va souvent plus vite. REA devient utile pour un calcul, un format de fichier ou un comportement caché dans une appli installée, quand il faut prouver le résultat. Plusieurs créateurs ont fait la course en octobre 2026. Chacun a fait un essai, pas un banc d’essai complet.

Ce que j’en retiens :

• Pour une interface, un site ou un outil web, l’agent seul et le prompt suffisent. Des captures d’écran ou une vidéo de l’appli l’aident davantage qu’un décompilateur.
• Pour un calcul, un format de fichier ou un comportement caché dans une appli installée, REA vaut le coup, ou au minimum Ghidra en mode headless piloté par l’agent. La tuyauterie (résumés, preuves, comparaison) est ce qu’un agent seul n’a pas.
• Pour un usage régulier sur tes propres cibles, prends REA tel quel, avec ton propre petit skill par-dessus pour tes outils, tes cibles et tes garde-fous. Réécrire REA n’a pas de sens : sa valeur est dans ses milliers de fichiers de tuyauterie.

Faire sans REA : les outils par type d’appli

Le prompt demande à l’agent d’utiliser ce qui est déjà sur ta machine. Voici ce que ça recouvre, du plus simple au plus technique. Les étapes sur Electron, Android et natif valent pour tes applis, l’open source ou l’interopérabilité (voir la loi plus bas).

Dans tous les cas, une condition passe avant l’outil : avoir le droit de regarder dedans. Pour choisir l’agent lui-même, mon comparatif des meilleures IA pour coder départage Claude, Codex, Cursor et les autres.

ArtCraft : les applis gratuites qui copient Adobe

Brandon Thomas, ingénieur logiciel à Atlanta, a publié à partir du 30 septembre 2026 sept applis gratuites et open source qui reprennent les logiciels d’Adobe, écrites en Rust avec Claude Opus 5.5. Il n’a pas utilisé REA, et ses applis sont en alpha. Son projet s’appelle ArtCraft, et l’ensemble des applis porte le nom de Crafting Apps.

Son point de départ, il l’a raconté sur Reddit, repris par PetaPixel : Adobe lui a facturé « les frais de résiliation à plusieurs reprises ». Ces frais ont valu à Adobe une plainte du ministère américain de la Justice, saisi par la FTC, en juin 2024 (TechRadar) : résilier un abonnement annuel payé au mois coûtait la moitié des mensualités restantes. Adobe a conclu en mars 2026 un accord de 150 millions de dollars, 75 versés et 75 en services gratuits pour certains clients (KTVU).

La méthode revendiquée est celle de la salle blanche. Celui qui observe n’écrit pas le code, et celui qui écrit le code n’a jamais vu l’original. Le README de PhotoCraft annonce une appli « implémentée à partir des spécifications publiques et du comportement observé uniquement », sans code, shaders ni éléments graphiques d’Adobe. Son support des fichiers PSD part de la spécification qu’Adobe publie lui-même, et FilmCraft code ses formats vidéo à partir des normes publiques ITU, ISO et IETF. Selon IT-Connect, huit agents ont travaillé en parallèle.

Le résultat reste jeune. Fireship a testé FilmCraft, le clone de Premiere : l’interface est presque identique, mais ça rame et les effets sont loin du compte. La feuille de route du 7 octobre, citée par IT-Connect, estime la parité réelle avec Photoshop « bien inférieure à 50 % ». Brandon Thomas visait « 100 % de parité » en un mois ; PetaPixel rappelle qu’une parité de fonctions n’est ni une parité de stabilité ni une parité de performances. Les applis sont gratuites ; ArtCraft vend en parallèle des crédits pour ses outils d’IA générative. Pour un usage professionnel aujourd’hui, mon guide des IA de retouche photo liste des outils éprouvés.

Les 7 applis ArtCraft (PhotoCraft, FilmCraft, LightCraft…) et leurs liens officiels

⚠️ Logiciels en alpha, vérifiés le 18 octobre 2026. Sauvegarde tes fichiers avant de les ouvrir et travaille sur des copies. Télécharge uniquement depuis la page officielle getartcraft.com/apps ou l’organisation GitHub storytold. Le site getartcraft.org, enregistré le 12 octobre 2026, se présente comme un « hub indépendant » : ce n’est pas le site de l’équipe.

Les sept dépôts sont publiés sous double licence MIT et Apache 2.0. Toutes tournent sur macOS, Windows et Linux ; toutes sauf FilmCraft fonctionnent aussi dans un onglet de navigateur. Le lanceur ArtCraft installe les applis et les tient à jour. Depuis la vidéo, la liste s’est allongée : la page officielle en compte 13 au 18 octobre, avec FigCraft (Figma), WordCraft (Word), SoundCraft (Pro Tools), DeckCraft (PowerPoint), CADCraft (AutoCAD) et GridCraft (Excel).

Rétro-ingénierie et décompilation : ce que dit la loi en France et dans l’UE

Si tu as le droit d’utiliser un logiciel, tu peux l’observer, l’étudier et le tester, et aucun contrat ne peut te l’interdire. Ses fonctionnalités, ses formats de fichiers et ses algorithmes ne sont pas protégés. Décompiler n’est permis que pour l’interopérabilité ou pour corriger un bug. Reprendre son code, son nom ou son apparence, c’est de la contrefaçon. Tout part de la directive 2009/24/CE, reprise en France à l’article L122-6-1 du Code de la propriété intellectuelle.

Pour « comprendre puis refaire », la voie légale est l’observation : tu fais tourner le logiciel, tu regardes ce qui entre et ce qui sort, tu écris une description, et tu construis ta version avec ton code, ton nom et ton design. C’est ce que fait le prompt. Un tableau avec des colonnes et des cartes, tout le monde peut en faire un ; le logo et le nom de Trello, non.

Trois nuances qui changent la décision :

• La salle blanche n’est pas un bouclier. Elle documente ta démarche. Avec une IA, la même personne tient les deux sessions, et un résultat trop proche de l’original reste une copie.
• Un usage interne ne change pas la limite légale. Dans la vidéo, je dis « pour de l’interne, amusez-vous » : c’est mon avis sur le risque pratique. La règle sur la décompilation et la reprise du code est la même, que l’outil reste dans ta boîte ou non.
• Publier ou vendre un clone ressemblant demande un avis juridique. Brevets, marques et interface : PetaPixel note qu’Adobe détient des milliers de brevets. Avant de déployer pour le grand public, fais relire par un avocat.

Ce que REA ne peut pas faire

Pour que tu saches où est la limite, voici ce que l’outil ne fait pas, quoi qu’en disent les posts viraux.

• Il ne touche pas au serveur. Il lit ce qui est sur ta machine. Le code qui tourne sur les serveurs d’une entreprise ne t’a jamais été livré : REA ne pirate pas une banque et ne déplace pas d’argent.
• Le code décompilé n’est pas le code source. C’est une reconstruction, parfois fausse. C’est pour ça que l’étape de vérification compte.
• Les cibles difficiles le restent. Un binaire C++ dépouillé de ses symboles est bien plus dur à lire qu’un jeu Unity en .NET. REA ne rend pas tout facile.
• Ton agent peut refuser. Certains firmwares ou cibles de console déclenchent les garde-fous du modèle, et la demande s’arrête là.
• Les outils commerciaux demandent une vraie licence. REA ne te donne ni IDA, ni Hopper, ni JEB, et les copies piratées sont exclues.

La rétro-ingénierie n’a rien de nouveau : BIOS IBM, Samba, Super Mario 64

Ce que REA fait sur une fonction, d’autres l’ont fait sur des systèmes entiers, à la main ; ce qui change, c’est le coût.

• Dans les années 80, des concurrents d’IBM ont recréé en salle blanche le programme qui démarre ses PC : une première équipe décrivait son comportement, une seconde, qui n’avait jamais vu le code d’IBM, l’écrivait à partir de cette seule description. Compaq y a mis environ un million de dollars ; Phoenix Technologies a vendu son BIOS aux autres fabricants, et les PC « compatibles IBM » sont nés. Les tribunaux américains ont confirmé plus tard que démonter un logiciel pour comprendre son fonctionnement pouvait être licite (Sega contre Accolade, 1992 ; Sony contre Connectix, 2000), mais ces décisions valent aux États-Unis, pas en France.
• Dans les années 90, Samba est né de l’observation. Si Linux et la plupart des NAS partagent des fichiers avec Windows, c’est grâce à lui : son auteur, Andrew Tridgell, l’a construit en écoutant ce que Windows envoyait sur le réseau, une méthode qu’il appelle la « technique du café français » (récit sur samba.org).
• En 2019, des bénévoles ont fini de réécrire Super Mario 64 en C, jusqu’à ce que le code recompilé redonne la cartouche d’origine octet par octet (dépôt n64decomp/sm64).

Il fallait des semaines à des spécialistes. Low Level a cassé le chiffrement d’un firmware en 15 minutes avec une IA branchée sur Ghidra, pour un travail qu’il estimait à une semaine.

Comment j’ai préparé cet article

Pour préparer la vidéo, j’ai lu le code et la documentation de REA, son cas DX-Ball et les textes de loi européens et français. Le prompt de cette page vient de la méthode officielle de REA, adaptée pour un agent sans REA et pour le droit européen. Le principe de la description puis de la construction séparée, je l’utilise déjà pour mes propres outils internes.

Alors, toutes les applis sont-elles devenues open source ?

Non. Open source, c’est une licence : le droit de lire, de modifier et de reprendre un code. Ce que l’IA rend accessible, c’est autre chose : comprendre comment marche une fonctionnalité qui tourne sur ta machine, pour t’en inspirer ou bâtir ta propre version avec ton code. On a désormais tout pour construire, même sans être spécialiste. Si tu comptes déployer une appli pour le grand public, vérifie la loi avant ; pour un outil interne, mon prompt suffit pour commencer. La vidéo complète montre la jauge, le cas DX-Ball et les deux portes de la loi en animation.

Pour recevoir la prochaine enquête de ce genre, inscris-toi à la newsletter : chaque jeudi, la synthèse des actus IA de la semaine, et en option un mail à chaque nouvelle vidéo.

Sources (consultées les 17 et 18 octobre 2026)

• REA, dépôt officiel morluto/rea : README, licence MIT, version 6.5.0 du 14 octobre 2026, 308 105 étoiles au 18 octobre ; skill officiel (SKILL.md, version 42) ; prompts MCP guidés ; avertissement (DISCLAIMER.md).
• rea.tools, cas DX-Ball : point d’étape du projet au 7 octobre 2026.
• Anthropic, annonce du Model Context Protocol (25 novembre 2024) ; Ghidra (NSA).
• ArtCraft, page officielle des Crafting Apps et organisation GitHub storytold ; README de PhotoCraft (méthode, spécification PSD).
• Adobe, spécification du format Photoshop.
• PetaPixel (7 octobre 2026), IT-Connect (8 octobre 2026), ProPakistani (9 octobre 2026), Creative Bloq, Phoronix.
• TechRadar, plainte contre Adobe (19 juin 2024) ; KTVU, accord de 150 millions de dollars (13 mars 2026).
• Tests vidéo d’octobre 2026 : Fireship, Nick Saraev, Nate Herk, Better Stack, Low Level ; Korben (14 octobre 2026).
• Directive 2009/24/CE ; CPI, article L122-6-1 ; CJUE, SAS Institute (C-406/10) ; CJUE, Top System (C-13/20) ; CJUE, BSA (C-393/09) ; directive 2016/943.
• Super Mario 64 décompilé (n64decomp/sm64) ; Andrew Tridgell, « How Samba was written » (2003) ; Clean-room design (Wikipédia).