Compositor : l’IA réduit le coût du clean-room

Compositor n’est pas Photoshop, mais le signal est sérieux

Je ne qualifierais pas Compositor de clone avéré de Photoshop : les éléments disponibles ne démontrent ni une telle exhaustivité ni ce niveau de compatibilité. La page du projet Compositor de Robbie Tilton a relancé le débat sur la réalisation rapide, avec l’IA, d’un éditeur graphique en clean-room. En septembre 2026, le signal principal n’est pas que « Photoshop est prêt en quelques jours », mais que le passage d’une spécification au code est devenu nettement moins coûteux.

L’appui quantitatif le plus solide de cette thèse ne vient pas de Compositor, mais de la publication MirrorCode. Un modèle de frontière y a réimplémenté un outillage Go d’environ 16 000 lignes en 14 heures pour 251 dollars ; Epoch AI a estimé le travail humain comparable entre deux et 17 semaines. Ces chiffres sont frappants, mais un outillage limité et une suite graphique mature ne jouent pas dans la même catégorie.

Un système de la classe de Photoshop exige bien plus que la reproduction de fonctions. Il faut reconstruire l’architecture, le comportement de l’interface, la gestion des ressources, les performances et une multitude de cas limites non documentés. C’est pourquoi ProjDevBench et Vibe Code Bench évaluent la livraison de projets entiers, et non la seule correction de tâches isolées. Ils ne démontrent toutefois pas qu’un système autonome puisse produire un remplaçant complet d’un logiciel mature.

Le clean-room n’est pas non plus une formule magique. Le développement doit reposer sur une spécification indépendante, et non sur le code original, tout en préservant une séparation démontrable. Si le modèle a vu une implémentation protégée, ou si la demande revient à reproduire des choix distinctifs, la salle juridiquement propre devient vite une salle avec des empreintes digitales.

La valeur passe de l’écriture du code à la connaissance du produit

L’ingénierie ne disparaît pas, mais ses couches les moins coûteuses se compressent. L’IA accélère l’ossature d’un projet, le code répétitif, les tests, le refactoring et les corrections successives. Ce qui devient cher, c’est une spécification exacte du comportement, la validation de compatibilité, le réglage des performances et la décision de ce qui est techniquement nécessaire ou juridiquement risqué.

Pour l’open source, le changement est réel : une petite équipe peut tester plus vite une alternative de niche et obtenir plus tôt un prototype fonctionnel. Pour les propriétaires de logiciels matures, la protection dépend moins du volume de code écrit que de la qualité du produit, de l’écosystème et des détails de comportement accumulés. Un prototype ne reste pourtant pas un outil fiable pour le travail quotidien.

Le code devient la partie peu coûteuse d’une copie. Deux éléments restent chers : une spécification précise du comportement et une frontière démontrable entre compatibilité et appropriation.

Les dernières mises à jour d’Obsidian montrent comment un logiciel extensible peut rapidement intégrer des fonctions avancées via des CLI, des plugins et des flux de travail locaux. Cette même dynamique aide à comprendre pourquoi les projets open source concurrencent de plus en plus les outils créatifs établis.