Clean-room

Deux équipes et une barrière documentée

La méthode clean-room, ou salle blanche, sépare ceux qui étudient un logiciel existant de ceux qui en écrivent une nouvelle version. La première équipe observe, teste ou décompile le logiciel d'origine et rédige une spécification fonctionnelle qui décrit ce qu'il fait sans en reproduire le code. La seconde équipe, qui n'a jamais vu ce code ni ce pseudocode, implémente à partir de cette seule spécification. Entre les deux, une barrière documentée : qui a eu accès à quoi, quand, et par quel canal la spécification a circulé. Cette traçabilité sert à démontrer, en cas de contestation, que la nouvelle implémentation est une création indépendante.

Le droit européen donne à cette précaution sa raison d'être. L'article L122-6-1 du Code de la propriété intellectuelle autorise l'observation et l'étude d'un logiciel, et sa décompilation pour l'interopérabilité, mais interdit d'utiliser les informations obtenues pour « la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ». La Cour de justice a jugé en 2012 (C-406/10) que la fonctionnalité, le langage et le format des fichiers ne sont pas protégés : reproduire ce que fait un logiciel est possible, reproduire la façon dont il est écrit ne l'est pas. La clean-room matérialise cette frontière entre fonction et expression. La fiche rétro-ingénierie logicielle détaille le cadre.

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

Pourquoi un agent unique fragilise la méthode

Un agent de code équipé de REA peut, dans la même session, lire le pseudocode décompilé d'une application et écrire le code d'une autre. La barrière disparaît alors de fait : un seul contexte contient le décompilé et le code cible, et aucune trace ne permet de montrer que l'un n'a pas été dérivé de l'autre. Connor Turland, après avoir fait reconstituer par REA la logique interne de Slack en une dizaine de minutes (20 octobre 2026), conclut que cette facilité « makes any clean-room argument pretty hard to defend ». La citation vise un cas où l'on se contenterait du résultat ; elle décrit le risque que court toute organisation qui laisse un agent unique tout faire.

La documentation d'installation de REA fait la même analyse et propose la parade. Restreindre REA à un profil d'agent (CLAUDE_CONFIG_DIR pour Claude Code) contrôle seulement quelles sessions découvrent le serveur MCP : « They leave shell commands, filesystem access and network access available. An agent under the same OS account can run rea from PATH or npx and read other profiles and REA output. » Pour une séparation clean-room, les mainteneurs demandent un environnement d'implémentation avec des restrictions de fichiers et de réseau qui empêchent de lire ou de télécharger REA, la cible et les sorties d'analyse, y compris par les installations partagées et les registres de paquets : « A separate account or container must enforce those restrictions. »

La clean-room avec agents se construit comme avant, avec des machines à la place des personnes. Un premier environnement, confiné, héberge REA, le binaire et l'agent lecteur, qui produit une spécification en langage métier : règles, formats, cas limites, sans extrait de pseudocode. Cette spécification est relue par un humain, qui vérifie qu'elle décrit des fonctions et non une expression, puis transmise. Un second environnement, sans accès au premier ni au réseau qui y mène, héberge l'agent rédacteur, qui n'a que la spécification. Le journal des deux environnements et la spécification relue constituent la barrière documentée.

Le cas ArtCraft

Entre le 30 septembre et le 9 octobre 2026, l'organisation GitHub storytold a publié treize dépôts baptisés ArtCraft : PhotoCraft, PDFCraft, FilmCraft, VectorCraft, LightCraft, DesignCraft, EffectCraft, GridCraft, CADCraft, DeckCraft, SoundCraft, WordCraft et FigCraft, sous licence Apache 2.0. Le README de PhotoCraft le présente comme « an open-source, clean-room reimplementation of Adobe Photoshop, rebuilt in pure Rust », avec les menus, raccourcis et panneaux « where your hands expect them, from ⌘J to ⇧⌘D », un support PSD « written from Adobe's public specification » et un rendu identique à Photoshop pour 307 des 309 fichiers du jeu de test psd-tools. Le dépôt comptait 71 629 étoiles le 23 octobre 2026. D'après la presse, le fondateur Brandon Thomas, ex-CEO de Storyteller.ai, dit avoir utilisé Claude Opus 5.5 et promet la parité en mois plutôt qu'en années.

La revendication clean-room n'a fait l'objet d'aucune vérification indépendante au 23 octobre 2026, et aucune réaction publique d'Adobe n'a été trouvée à cette date. Le cas illustre les deux lectures possibles de la méthode : une spécification publique (le format PSD) et une interface reproduite de mémoire d'utilisateur relèvent de la fonction, que le droit ne protège pas ; ce qui compte pour la qualification, c'est que personne n'ait écrit le code cible avec le décompilé d'Adobe sous les yeux, et seule une barrière documentée peut le montrer. L'analyse complète est dans clean-room contre rétro-ingénierie.

Ce que SFEIR en fait

Sur une modernisation du legacy sans code source, SFEIR applique la séparation à deux environnements décrite ci-dessus : l'agent lecteur produit une rétro-spécification validée par le métier, l'agent rédacteur reconstruit à partir d'elle, et un golden master inversé (l'application d'origine produit les sorties de référence) prouve l'équivalence fonctionnelle sans qu'aucun extrait du code d'origine n'ait traversé la barrière. En sécurité, l'offre AI Cyber part du code source que l'organisation possède, ce qui ne pose pas la question de la clean-room.