Treize clones d'Adobe et d'Office écrits avec Claude : nous les avons tous compilés et lancés

Publié sur le blog TEN INVENT · Octobre 2026

Durant les deux premières semaines d'octobre 2026, une organisation GitHub appelée storytold est passée de quelques vieux plugins Unreal Engine au projet open source dont on a le plus parlé ce mois-là. Brandon Thomas, fondateur du studio ArtCraft, a publié des réécritures en Rust de Photoshop, Illustrator, Premiere Pro, Lightroom, After Effects, InDesign et Acrobat, puis, une semaine plus tard, de Word, Excel, PowerPoint, d'un outil de CAO et d'un éditeur audio. Presque tout le code a été écrit avec Claude Opus 5.5. PhotoCraft, la version Photoshop, a dépassé 59 000 étoiles en quatorze jours.

Les titres de presse allaient dans deux directions : « Adobe est mort » d'un côté, « c'est un tas de captures d'écran générées par IA » de l'autre. Aucun des deux n'est vraiment utile si vous devez décider de les utiliser, de construire quelque chose de similaire ou de l'expliquer à un client. Nous avons donc fait le travail ingrat. Nous avons cloné les treize applications, compilé chacune depuis les sources sur un Mac, lancé le tout, soumis à PhotoCraft quelques centaines de vrais fichiers PSD, mesuré la mémoire et nous sommes connectés aux serveurs MCP. Voici ce que nous avons trouvé.

Ce qui s'est passé, dans l'ordre

• 30 septembre : les premiers dépôts apparaissent : PhotoCraft, VectorCraft (Illustrator), FilmCraft (Premiere), LightCraft (Lightroom) et PdfCraft (Acrobat). EffectCraft (After Effects) et DesignCraft (InDesign) suivent le 1er octobre. Tous sont sous double licence MIT / Apache-2.0.
• 2–3 octobre : l'annonce est publiée sur Reddit. Le message sur r/SaaS recueille quelques milliers de votes. Thomas y promet une parité fonctionnelle de 100 % avec Adobe en un mois.
• 6 octobre : Hacker News. Thomas explique ses raisons : il en avait assez de se faire piéger par les « frais d'annulation en dark pattern » d'Adobe. Il révise aussi sa promesse : 99 %, en quelques mois plutôt qu'en quelques années. Le contexte compte ici. En mars 2026, Adobe a accepté un règlement de 150 millions de dollars avec le ministère de la Justice américain, dont 75 millions de dollars de sanctions civiles et 75 millions de dollars de services gratuits, au sujet de frais de résiliation anticipée cachés et d'un abonnement difficile à annuler. L'affaire avait été déposée en juin 2024. Adobe a nié toute faute.
• 7–9 octobre : WordCraft, GridCraft et DeckCraft (Word, Excel, PowerPoint), CadCraft, SoundCraft et FigCraft (Figma) apparaissent.
• 9–13 octobre : l'histoire passe dans les médias grand public. Yahoo Tech, Gizmodo, TweakTown, t3n et d'autres s'en emparent, avec des titres allant de l'admiratif au sceptique. Fabio Akita publie le 13 octobre une longue analyse dont la conclusion tient en peu de mots : Adobe n'est pas mort.

À ce jour, le 14 octobre, Adobe n'a rien dit publiquement sur le projet, et aucune plainte ni mise en demeure n'est connue. Le « scandale » est donc un phénomène viral, pas un litige juridique. Du moins pour l'instant.

Ce qu'il y a réellement dans les dépôts

Les étoiles disent peu de choses, alors nous avons regardé ce qu'il y a dans Git. Les chiffres ci-dessous viennent de nos clones du 14 octobre.

Cela représente environ 3,5 millions de lignes de Rust en deux semaines, avec environ 40 000 fonctions de test. Sur les 13 dépôts, on compte 15 840 commits, dont 7 985 portent un trailer Co-Authored-By: Claude, surtout Opus 5.5. C'est un minimum plutôt qu'un chiffre exact, car les fusions en squash de contributeurs externes ne conservent pas toujours le trailer. PhotoCraft à lui seul compte environ 1 990 pull requests fusionnées et 620 ouvertes. Ce n'est pas une personne qui tape au clavier. C'est une personne, une poignée de contributeurs réguliers et de nombreuses sessions d'agents en parallèle, avec Git comme couche de coordination.

Le code n'est pas non plus un tas de captures d'écran. PhotoCraft est découpé en 24 crates, avec une organisation en couches imposée à la compilation : géométrie et couleur en bas, puis le modèle de document, les algorithmes, les compositeurs, les formats de fichiers, le moteur, et l'interface utilisateur au sommet. Les règles de AGENTS.md sont plus strictes que dans bien des projets humains : pas de unwrap ni de panic hors des tests, pas de unsafe sauf dans une crate isolée pour les tablettes graphiques, chaque correction de crash s'accompagne d'un test de non-régression, et le code de traitement des pixels est testé en 8, 16 et 32 bits.

Nous les avons compilées sur un Mac

La machine de test était un Mac Studio avec un M3 Ultra et 96 GB de RAM, sous Rust 1.99. Nous avons compilé le binaire de bureau et la CLI de chaque application en mode release, sans modifier le code.

Les 13 ont compilé du premier coup, sans modification. Un build release prend entre 30 secondes et 3,5 minutes par application sur cette machine. Ensuite, nous avons donné à chacune une vraie tâche en ligne de commande, avec nos propres fichiers quand nous en avions :

Ce sont des smoke tests, pas une évaluation de chaque application. Ils montrent que les applications existent, démarrent, lisent de vrais fichiers et écrivent des fichiers que d'autres logiciels ouvrent. Ils ne montrent pas comment elles se comportent au fil d'une journée de travail, question à laquelle le document de parité du projet répond plus bas.

Pour PhotoCraft, nous sommes allés plus loin.

Fichiers PSD. PhotoCraft fournit un script qui télécharge des corpus de test publics à des commits fixes : les fichiers de test de psd-tools (une bibliothèque Python) et d'ag-psd (une bibliothèque JavaScript), PngSuite et un ensemble de fichiers Affinity. Nous avons ouvert chaque PSD avec photocraft-cli, l'avons aplati en PNG, réenregistré en PSD et rouvert le résultat. 308 des 309 fichiers de psd-tools et les 51 fichiers d'ag-psd (360 au total) s'ouvrent, s'enregistrent et se rouvrent sans erreur. Celui qui échoue est un séparateur de groupe avec un mode de fusion inhabituel. Ouvrir sans erreur n'est pas la même chose que rendre exactement comme Photoshop, et nous n'avons pas comparé les pixels à ceux de Photoshop. Le README indique « le rendu est conservé pour 307 fichiers sur 309 », ce qui est cohérent avec ce que nous avons vu.

L'interface. L'application s'ouvre avec Metal, le canevas GPU fonctionne, et les effets de calque (biseautage, lueur, ombres, incrustations, contour) se rendent sur des calques de texte actifs. Les menus, panneaux, barre d'outils et raccourcis clavier sont clairement calqués sur Photoshop. Un détail qui montre jusqu'où va l'imitation : Photoshop utilise ⌘H et ⌘M pour ses propres commandes, alors que macOS les réserve normalement à Masquer et Réduire. PhotoCraft garde donc le comportement de Photoshop et déplace Masquer et Réduire vers ⌃⌘H et ⌃⌘M. L'application l'indique elle-même dans son journal au démarrage.

Mémoire. Nous avons créé un document de 12 000 × 8 000 pixels (96 MP), ajouté du bruit, un flou gaussien de 20 px et un calque de réglage Courbes, puis l'avons enregistré en PSD, le tout depuis la CLI. Cela a pris 3 secondes avec un pic à 4,5 GB de RAM. À 4 000 × 3 000, c'était 0,5 seconde et 866 MB. Ça fonctionne, mais au prix d'environ 47 octets par pixel pour un seul calque, ce qui concorde avec les issues ouvertes sur la consommation mémoire des gros fichiers. Pour situer l'ordre de grandeur, les pixels bruts d'un calque RGBA 8 bits de 96 MP font environ 384 MB.

La partie intéressante : chaque action est une commande

Si vous ne regardez que les captures d'écran, vous passez à côté de l'architecture, qui est l'idée la plus réutilisable du projet. Dans PhotoCraft, chaque élément de menu, outil et boîte de dialogue exécute une commande issue d'un registre unique. Notre build compte 909 commandes. L'interface les appelle, et la CLI, un canal de contrôle JSON et un serveur MCP aussi.

Le serveur MCP est la partie astucieuse. Il n'expose pas 909 outils. Il en expose 25 : command_list, command_run, command_batch, doc_open, doc_save, doc_render_preview, ui_screenshot et quelques autres. Le schéma complet des outils pèse environ 25 KB de JSON. L'agent demande la liste des commandes quand il en a besoin, et exécute les commandes par leur ID. À titre de comparaison, Akita a mesuré le catalogue d'outils d'un autre serveur MCP populaire, REA (pour la rétro-ingénierie), à environ 2,3 MB de JSON, que l'agent paie en tokens à chaque session.

La même idée se retrouve dans les autres applications : VectorCraft, LightCraft et les autres ont chacune leur propre sous-commande mcp. L'accès aux fichiers est fermé par défaut : le serveur MCP sans interface ne peut lire et écrire que dans les dossiers que vous lui indiquez avec --automation-read-root et --automation-write-root. Le canal de contrôle de l'application de bureau n'écoute que sur l'interface loopback et exige un jeton.

C'est la partie que nous reprendrions dans un projet client, quel que soit le sort des clones. Si une application dispose d'une seule couche de commandes, que l'interface appelle elle aussi, un agent IA peut faire tout ce que fait l'utilisateur, sans « intégration IA » séparée qui s'éloigne peu à peu du produit. Et vous pouvez tester chaque fonctionnalité sans interface.

Les chiffres de parité, lus avec attention

PhotoCraft dispose d'un document plus honnête que les titres de presse : docs/target-app-parity.md. Il mesure l'application par rapport à Photoshop 2026 et est mis à jour tous les quelques jours. La version du 10 au 13 octobre indique ceci :

Deux chiffres comptent. L'étendue fonctionnelle est d'environ 76 % : les trois quarts des menus, outils, panneaux et formats de Photoshop existent sous une forme ou une autre. « Prêt pour le travail réel » est à environ 45 % : c'est la mesure de savoir si un professionnel pourrait remplacer Photoshop par cet outil dès aujourd'hui. C'est dans l'écart entre les deux que se trouve tout le travail difficile d'un éditeur : gestion des couleurs, fichiers PSD écrits par Photoshop qui doivent y retourner intacts, performances sur les gros fichiers, stabilité sur de vraies machines, plugins.

Le document est aussi honnête sur son propre historique. Le 3 octobre, il estimait 82 % et 140–220 heures-agent pour atteindre 95 %. Une semaine plus tard, il qualifiait cette estimation de « beaucoup trop optimiste » : environ 1 230 issues avaient été ouvertes depuis la première version, la plupart concernant des fonctionnalités déjà comptées comme terminées. La nouvelle estimation est de 2 300–4 100 heures-agent jusqu'à la parité complète. C'est environ 15 fois l'estimation initiale, après une semaine avec de vrais utilisateurs.

C'est la leçon la plus utile pour quiconque estime un logiciel construit par IA. Un agent vous amène très vite à « la fonctionnalité existe ». « La fonctionnalité marche sur les fichiers des utilisateurs » est une autre courbe, et vous ne découvrez sa pente que quand les utilisateurs arrivent.

Clean room ou pas ?

Thomas présente les applications comme une réimplémentation en clean room. Au sens classique, une clean room suppose deux équipes distinctes : l'une étudie l'original et rédige une spécification, l'autre écrit le code à partir de la spécification sans jamais avoir vu l'original. Ici, il y a un seul développeur et un modèle entraîné sur d'énormes quantités de code et de documentation publics, donc la définition classique ne convient pas.

Ce que contient réellement le dépôt est plus nuancé. Les règles de contribution interdisent de copier du code, des shaders, des icônes, des profils ICC ou d'autres ressources issus de logiciels propriétaires, et exigent de reproduire le comportement « par observation et à partir de spécifications publiques ». Le format PSD a une spécification qu'Adobe a lui-même publiée. En revanche, le document de parité indique que la cible a été mesurée en inspectant une installation de Photoshop 2026 sans la lancer : les types de documents dans Info.plist, le fichier des raccourcis clavier par défaut, les indicateurs de lecture/écriture des plugins et des chaînes dans le binaire principal. Ce n'est pas du code source, mais c'est plus que des « spécifications publiques », et les conditions de licence d'Adobe restreignent la rétro-ingénierie au-delà de ce que la loi autorise.

Sur les questions qui comptent généralement devant un tribunal, la jurisprudence penche en faveur des clones. Aux États-Unis, Lotus v. Borland (1995) a jugé que la hiérarchie des commandes de menu d'un programme est une méthode d'utilisation, et non une expression protégée, et Google v. Oracle (2021) a considéré la réimplémentation d'une API comme un usage loyal (fair use). Dans l'UE, la CJUE a jugé dans SAS Institute v. World Programming (2012) que la fonctionnalité d'un programme, son langage de programmation et ses formats de fichiers ne sont pas protégés par le droit d'auteur. Le vrai risque est ailleurs : l'apparence générale (look and feel), des icônes trop ressemblantes, et les marques. Les applications n'utilisent ni les noms ni les logos d'Adobe ou de Microsoft, ce qui réduit ce risque. Ce n'est pas un avis juridique, et la réponse dépend de la juridiction, mais « Adobe attaque et gagne facilement » est loin d'être évident.

Sécurité : ce que nous ferions avant de les utiliser

Trois choses nous inquiètent plus que la question du droit d'auteur.

1. Le rythme des changements. PhotoCraft a fusionné environ 2 000 pull requests en deux semaines, beaucoup venant de nouveaux contributeurs, avec des agents impliqués des deux côtés. Personne ne lit autant de code avec soin. Si vous utilisez les applications, épinglez un commit ou une release, ne lancez pas main.
2. Les fichiers non fiables. Un éditeur d'images ou de PDF analyse des formats complexes provenant de sources inconnues. Rust supprime toute une classe de bugs mémoire, et les projets interdisent unsafe presque partout, ce qui aide. Mais les bugs de logique, les bombes de décompression et les allocations non bornées subsistent. Notre test à 96 MP montre à quelle vitesse la mémoire grimpe. Ne les utilisez pas sur un serveur qui traite des fichiers envoyés par des utilisateurs.
3. Les agents avec accès aux fichiers. Les serveurs MCP adoptent les bons réglages par défaut (pas d'accès aux fichiers sans dossiers explicites, canal de contrôle limité à loopback avec jeton). Gardez ce comportement : donnez à l'agent un dossier de travail, pas votre répertoire personnel.

Les releases macOS sont signées et notarisées par Apple, ce qui confirme qui les a compilées, pas ce qu'elles contiennent. Nous avons compilé depuis les sources, à un commit que nous avons noté, et conservé une copie privée des dépôts au cas où ils disparaîtraient.

Ce que cela signifie

Cela ne veut pas dire qu'Adobe est mort. L'essentiel de la valeur de Creative Cloud ne se trouve pas dans un binaire que l'on peut copier : science des couleurs, profils d'appareils photo, palettes et polices sous licence, fonctionnalités génératives dans le cloud, intégration avec les imprimeurs et les agences, et vingt ans de fichiers PSD qui doivent s'ouvrir exactement de la même façon. Akita le souligne longuement.

Mais trois choses ont changé, et sans retour possible :

• Le coût d'une première version crédible s'est effondré. 3,5 millions de lignes de Rust structuré et testé en deux semaines, c'est un fait, pas une démo. Pour les outils internes et les produits de niche, « il nous faudrait une équipe pendant un an » n'est plus automatiquement vrai.
• Les 50 % restants n'ont pas vu leur coût baisser au même rythme. Les chiffres du projet le montrent : de 76 % d'étendue à 45 % de disponibilité, et une estimation multipliée par 15 après une semaine d'utilisateurs. C'est là que se concentrent encore l'ingénierie, les tests sur de vrais fichiers et les décisions de produit.
• « Prêt pour les agents » devient une exigence d'architecture. Une couche de commandes unique, utilisée par l'interface, la CLI et un serveur MCP avec un nombre réduit d'outils, c'est le modèle que nous recommanderions aujourd'hui pour toute nouvelle application destinée à être utilisée par des agents.

Si vous souhaitez un deuxième avis sur ce que l'IA peut réalistement construire pour votre produit, et sur ce qui restera le travail de votre équipe, contactez-nous.