Clean-room ou reverse engineering : méthode et risque juridique à l'ère des agents

Le README de REA, l'outil de rétro-ingénierie par agents publié sous licence MIT, s'ouvre sur une promesse : repérer une fonctionnalité dans une application, la faire examiner par un agent sans le code source, puis « build a version for your project »¹. Voir une fonctionnalité chez un autre et la reconstruire chez soi tient désormais dans une session d'agent. La réponse juridique dépend d'une distinction que beaucoup confondent : la rétro-ingénierie d'un côté, la méthode clean-room de l'autre. Cette page sert de point d'entrée à toutes les questions de droit du dossier.

Deux pratiques distinctes

La rétro-ingénierie consiste à observer, tracer ou décompiler un logiciel pour comprendre son fonctionnement. Elle produit de la connaissance : pseudocode, schémas d'appels, description d'un format.

La méthode clean-room, ou salle blanche, organise une réécriture. Une première équipe étudie le logiciel et rédige une spécification débarrassée de tout code protégé. Une seconde équipe réimplémente à partir de cette seule spécification, sans jamais avoir vu le code d'origine. La barrière entre les deux équipes, et la trace écrite qui la prouve, fait la valeur juridique de la méthode : le nouveau code ne peut pas être une copie de ce que ses auteurs n'ont jamais lu. La méthode ne rend pas licite pour autant l'étude initiale : si la première équipe a décompilé le logiciel hors des cas que la loi prévoit, la salle blanche ne couvre pas cette étape.

Ce que le droit européen et français autorisent

La directive 2009/24/CE sur la protection juridique des programmes d'ordinateur ménage deux exceptions au monopole de l'auteur², transposées à l'article L122-6-1 du Code de la propriété intellectuelle³.

L'article 5 vise les actes nécessaires à l'utilisation du programme par l'acquéreur légitime. Il couvre l'observation, l'étude et le test du fonctionnement lors d'opérations autorisées, et la correction d'erreurs. Le 6 octobre 2021, dans l'arrêt Top System (C-13/20), la Cour de justice 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 du contrat, l'éditeur pouvant se réserver la correction d'erreurs (I de l'article L122-6-1)⁴.

L'article 6 autorise la décompilation à seule fin d'interopérabilité, sous trois conditions et avec trois interdits. Le plus important pour un projet de réécriture : les informations obtenues ne peuvent pas servir à produire un logiciel « dont l'expression est substantiellement similaire ». Le détail figure dans notre page sur la décompilation pour interopérer.

Le 2 mai 2012, l'arrêt SAS Institute (C-406/10) a fixé la frontière de la protection : ni la fonctionnalité d'un programme, ni son langage de programmation, ni le format de ses fichiers de données ne sont des formes d'expression protégées⁵. Dans cette affaire, l'acquéreur avait observé, étudié et testé le programme sous licence, et lu ses manuels, sans accéder au code source ni le décompiler : c'est ce qui fondait la solution. Réimplémenter un comportement est donc possible au regard du droit d'auteur, à cette condition ; copier du code ou des ressources ne l'est pas. D'autres protections peuvent jouer sur une fonctionnalité : brevet, secret des affaires, contrat, concurrence déloyale.

Le secret des affaires ajoute une pièce. La directive (UE) 2016/943 range parmi les obtentions licites l'observation, l'étude, le démontage ou le test d'un produit mis à la disposition du public ou détenu de façon licite, sauf obligation juridiquement valide de limiter cette obtention⁶. En France, la règle figure à l'article L151-3 du Code de commerce⁷. Le contrat redevient alors central, et notre page sur les clauses de licence nulles en France dit ce qu'il peut et ne peut pas interdire.

Où un agent unique casse l'argument clean-room

Le problème apparaît dès qu'un même agent lit le pseudocode décompilé puis écrit la réimplémentation. Les deux rôles que la salle blanche doit séparer fusionnent dans une seule session. Connor Turland, qui a passé Slack au crible de REA le 20 octobre 2026, le formule ainsi : le fait que l'agent ait lu le code décompilé « makes any clean-room argument pretty hard to defend »⁸.

La documentation d'installation de REA va dans le même sens. Elle explique comment limiter l'outil à un projet ou à un profil d'agent, puis précise que ces réglages laissent le shell, le système de fichiers et le réseau accessibles : un agent tournant sous le même compte peut relancer REA et lire ses sorties. Pour une séparation clean-room, elle demande un environnement de réécriture dont les restrictions empêchent de lire ou de récupérer REA, la cible et les résultats d'analyse, et ajoute qu'« A separate account or container must enforce those restrictions »⁹.

L'étude de cas ArtCraft illustre la difficulté : des clones d'applications Adobe écrits avec Claude, présentés comme clean-room, sans audit indépendant de la méthode.

Le réflexe de preuve

La traçabilité protège : qui a vu quoi, quand, sur quelle base. Concrètement, une équipe d'analyse produit une spécification relue et expurgée de tout extrait de code ; une équipe de réécriture, sur d'autres comptes et d'autres machines, n'a accès ni à l'outil d'analyse ni à ses sorties ; chaque passage de document entre les deux est journalisé. La sortie de REA, qui accompagne chaque conclusion de ses preuves et de ses limites, aide à documenter l'analyse (voir comment lire une sortie REA). Elle ne remplace pas la séparation organisationnelle.

Le même raisonnement vaut pour la modernisation d'un patrimoine applicatif : notre page sur la modernisation d'une application WinDev avec des agents l'applique à un cas fréquent dans les DSI françaises, et le hub legacy élargit aux applications dont le source est perdu.

Les autres points d'attention du dossier

Plusieurs pages approfondissent un cas précis : la conformité au Cyber Resilience Act quand un composant arrive sans inventaire, la vérification de ce qu'une application envoie au regard du RGPD, et l'audit d'un logiciel extra-européen pour un acheteur public. Notre tribune sur la fin de l'avantage du code fermé tire les conséquences côté éditeur.

Questions fréquentes

Clean-room et reverse engineering, est-ce la même chose ?

Non. La rétro-ingénierie produit de la connaissance sur un logiciel. Le clean-room organise une réécriture en séparant, de façon documentée, ceux qui analysent et ceux qui écrivent le nouveau code.

Peut-on réimplémenter une fonctionnalité ?

La fonctionnalité en elle-même n'est pas protégée par le droit d'auteur selon l'arrêt SAS Institute. Le code, les ressources graphiques et, le cas échéant, une interface originale le sont. Un brevet, un secret des affaires ou les règles de la concurrence déloyale peuvent aussi jouer, et les clauses du contrat de licence s'appliquent, dans les limites de l'article L122-6-1.

Un agent qui lit le décompilé puis réécrit, est-ce un risque ?

Oui : la séparation des rôles disparaît. La documentation de REA elle-même demande un compte ou un conteneur distinct, qui interdit l'accès à l'outil et à ses résultats, pour une séparation clean-room.

Faut-il faire valider le projet par un juriste ?

Oui, avant de commencer. Les points ci-dessus sont des repères pour préparer cet échange, pas une analyse de votre cas.

L'offre AI Cyber de SFEIR travaille en boîte blanche sur le code dont ses clients disposent ; pour un projet de réécriture, elle aide à organiser la séparation des équipes et la trace qui la prouve, en lien avec votre conseil juridique.

Sources

1. morluto/rea, README — github.com/morluto/rea, consulté le 11 octobre 2026.
2. Directive 2009/24/CE du Parlement européen et du Conseil du 23 avril 2009 concernant la protection juridique des programmes d'ordinateur, articles 5 et 6 — eur-lex.europa.eu.
3. Code de la propriété intellectuelle, article L122-6-1 — legifrance.gouv.fr.
4. CJUE, 6 octobre 2021, Top System SA contre État belge, C-13/20 — curia.europa.eu.
5. CJUE, 2 mai 2012, SAS Institute Inc. contre World Programming Ltd, C-406/10 — curia.europa.eu.
6. Directive (UE) 2016/943 du 8 juin 2016 sur la protection des savoir-faire et des informations commerciales non divulgués, article 3 — eur-lex.europa.eu.
7. Code de commerce, article L151-3 — legifrance.gouv.fr.
8. Connor Turland, What is REA (Reverse Engineer Anything)? I ran it on Slack to find out — atcyrus.com, 20 octobre 2026.
9. morluto/rea, docs/installation.md, section « Limit REA to one project or agent profile » — github.com/morluto/rea, consulté le 23 octobre 2026.