ArtCraft : comment Brandon Thomas a construit 13 clones de logiciels avec Claude Code

En quelques jours, Brandon Thomas a fait apparaître sur GitHub une série d’applications open source qui reprennent les grands codes de Photoshop, Illustrator, Premiere Pro, Lightroom, Acrobat, InDesign, Word, Excel, PowerPoint, AutoCAD ou encore des stations audionumériques. Le réflexe est de regarder les applications et de demander si elles peuvent remplacer Adobe ou Microsoft. Ce n’est pourtant pas le point le plus intéressant.

Le véritable sujet est la méthode de développement. ArtCraft constitue l’un des exemples les plus spectaculaires à ce jour d’un développeur expérimenté utilisant Claude Code et plusieurs agents IA pour compresser en quelques heures ou quelques jours un travail qui, jusque-là, aurait demandé une équipe entière pendant des mois. Le code public permet même de reconstituer assez précisément comment il s’y est pris : architecture pensée pour les agents, développement « clean-room », Rust natif, catalogue de commandes, agents parallèles, tests automatisés, corpus de vrais fichiers et boucle de validation visuelle.

L’exploit ArtCraft n’est pas d’avoir « remplacé Photoshop »

Il faut commencer par écarter le raccourci le plus spectaculaire. Non, un seul développeur n’a pas remplacé en quelques jours des produits qui cumulent plusieurs décennies d’ingénierie, des millions d’utilisateurs, des équipes spécialisées, une compatibilité de fichiers extrêmement large et un écosystème de plugins énorme.

Les dépôts ArtCraft eux-mêmes décrivent plusieurs applications comme early alpha ou in development. Des tests indépendants ont trouvé des fonctionnalités manquantes, des problèmes de fidélité ou des performances encore irrégulières. Le projet a d’ailleurs progressivement remplacé les premières déclarations très agressives de « parité » par des mesures plus honnêtes de profondeur fonctionnelle et d’aptitude au travail réel.

Mais c’est précisément ce qui rend l’expérience intéressante. Ce que Brandon Thomas a réussi à réduire de façon spectaculaire, ce n’est pas le temps nécessaire pour arriver à un produit aussi mûr que Photoshop. C’est le temps nécessaire pour passer d’une feuille blanche à une base logicielle immense, cohérente, compilable, testable et déjà utilisable.

Le 30 septembre 2026, le dépôt PhotoCraft enregistre ainsi un commit intitulé one-shot qui ajoute 42 241 lignes en une seule fois. Quelques jours plus tard, les dépôts se multiplient et le même schéma architectural est appliqué à la retouche photo, au vectoriel, à la vidéo, au PDF, à la bureautique, à la CAO et à l’audio. C’est cette capacité à produire très vite une première « surface » fonctionnelle gigantesque qui change réellement la donne.

Qui est Brandon Thomas ? Un développeur expérimenté, pas un débutant qui « vibe code »

Le contexte compte beaucoup. Brandon Thomas, qui utilise aussi le pseudonyme echelon sur GitHub et Hacker News, est un ingénieur logiciel expérimenté. Il indique avoir environ quinze ans d’expérience dans le développement et près d’une décennie sur de gros projets Rust. Plusieurs articles consacrés à ArtCraft rappellent également son passage par des environnements logiciels exigeants, notamment dans le paiement et la robotique.

Cette précision est essentielle, car l’histoire devient beaucoup moins mystérieuse : Claude ne remplace pas ici la connaissance de l’architecture logicielle. Il amplifie un développeur qui sait déjà comment découper un système, poser des invariants, écrire des tests, mesurer une régression, isoler des modules et organiser plusieurs flux de travail en parallèle.

Autrement dit, ArtCraft ressemble beaucoup moins à « j’ai demandé à une IA de me faire Photoshop » qu’à « j’ai construit une usine logicielle dans laquelle des agents IA peuvent travailler efficacement ».

L’outil central : Claude Code avec Claude Opus 5.5

Le cœur du dispositif est Claude Code, l’agent de développement d’Anthropic exécuté directement dans le terminal. Le modèle le plus souvent crédité dans les dépôts initiaux et dans les fichiers de contribution est Claude Opus 5.5. Les commits publics contiennent de nombreuses lignes de co-auteur attribuées à Claude, et les fichiers contributors.json des différents projets identifient explicitement le modèle.

Thomas a par ailleurs indiqué utiliser essentiellement une configuration « vanilla Claude Code » : l’originalité du projet ne vient donc pas d’un framework propriétaire caché qui ferait tout le travail. La différence se trouve surtout dans la manière dont le dépôt a été préparé pour que Claude puisse travailler longtemps sans se perdre.

Outil ou technologie	Rôle dans la méthode ArtCraft
Claude Code	Agent principal de développement : lecture du dépôt, planification, écriture de code, tests, corrections et délégation à des sous-agents.
Claude Opus 5.5	Modèle principal utilisé pour les grosses tâches d’implémentation et d’analyse.
Rust	Langage commun à la suite, choisi pour les performances, la sûreté mémoire et la compilation native multiplateforme.
Cargo	Build, dépendances, tests et organisation du workspace en dizaines de crates.
egui / eframe	Interface graphique native et volontairement fine, afin que la logique métier reste hors de l’UI.
wgpu	Rendu GPU portable sur Metal, Vulkan, DirectX 12 et WebGPU.
Rayon	Parallélisation CPU des traitements lourds, notamment par tuiles.
WebAssembly	Une partie des mêmes bases Rust est compilée pour le navigateur via wasm-bindgen et Trunk.
Git / GitHub	Historique, pull requests, issues, revue communautaire et coordination des changements.
GitHub Actions	CI multiplateforme, tests, Clippy, vérifications de couches et builds WebAssembly.
cargo xtask	Automatisation maison pour la parité, les corpus, les performances, les scorecards et les contrôles d’architecture.
JSON control channel / MCP	Permet aux agents de piloter l’application elle-même, exécuter des commandes, inspecter l’état et prendre des captures sans passer par des clics fragiles.

Étape 1 : partir d’une « clean-room », pas du code d’Adobe ou de Microsoft

La première règle technique est aussi une règle juridique : ArtCraft se présente comme une réimplémentation clean-room. Le principe est de reproduire un comportement observable sans copier le code source, les shaders, les profils ou les assets propriétaires.

Dans le fichier AGENTS.md de PhotoCraft, les règles sont très explicites : les agents peuvent étudier Photoshop et d’autres logiciels propriétaires pour leur comportement et leur apparence, mais ils doivent implémenter à partir de spécifications publiques, de standards ouverts et d’observations externes. Pour PSD, par exemple, le projet s’appuie sur la documentation publique Adobe, des corpus ouverts et des fichiers de test.

CADCraft documente la même logique pour AutoCAD : catalogues de commandes et de menus, documentation Autodesk publique, captures de référence locales et observation « boîte noire ». Le document indique même que, pour certains audits, les agents se sont limités à lister les noms de modules ou les entrées de menus sans lire le contenu des fichiers de l’application cible.

Cette approche ne supprime pas tous les risques juridiques : une interface peut aussi soulever des questions de marque, de design, de brevet ou de trade dress. Mais sur le plan du développement, le point important est que Claude reçoit une spécification de comportement, pas le code du concurrent à transformer.

Étape 2 : transformer un logiciel immense en catalogue mesurable

Pour qu’un agent puisse progresser rapidement, « faire Photoshop » est une consigne inutilisable. Il faut convertir ce problème flou en milliers de petites unités mesurables.

ArtCraft construit donc des fichiers de parité : listes de menus, commandes, raccourcis, outils, formats, comportements attendus et fonctions manquantes. Un outil maison, cargo xtask parity, compare ce catalogue avec le registre de commandes réellement implémentées.

Cette distinction est fondamentale. Une commande peut être présente sans être profonde. Un menu « Courbes » peut exister et déclencher une fonction, tout en manquant des cas particuliers d’Adobe. Les premières versions d’ArtCraft ont parfois été critiquées pour avoir assimilé couverture des menus et véritable parité. Les documents récents séparent donc explicitement :

• la largeur fonctionnelle : combien de commandes ou de menus existent ;
• la profondeur : jusqu’où les options et comportements sont réellement reproduits ;
• la compatibilité de fichiers ;
• la stabilité ;
• la capacité à faire du travail réel sans rencontrer de blocage.

Cette méthode transforme un objectif gigantesque en une fonction d’optimisation : l’agent sait en permanence ce qui manque et quelle tâche permet de faire monter un indicateur sans régression.

Étape 3 : construire une architecture « agent-ready » dès le premier jour

C’est probablement la décision la plus importante de toute l’expérience. Dans PhotoCraft, la règle numéro un du dépôt est : « Everything is a command ».

Chaque action visible par l’utilisateur — ouvrir un fichier, créer un calque, appliquer une courbe, modifier l’opacité, exporter — est d’abord une commande de moteur avec un identifiant, des paramètres, une condition d’activation et des tests. Ensuite seulement, l’interface graphique appelle cette commande.

Résultat : le même moteur peut être piloté de quatre façons :

• par l’interface graphique ;
• par la ligne de commande ;
• par un canal JSON de contrôle ;
• par un serveur MCP pour Claude Code, Cursor ou un autre agent.

Cela change totalement la boucle de développement. L’IA n’est pas obligée de déplacer la souris dans l’application pour vérifier son travail. Elle peut exécuter précisément layer.opacity.set, ouvrir un fichier, appliquer une opération, récupérer l’état du document, lancer un export ou demander une capture de l’interface.

Le projet devient donc à la fois un logiciel pour humains et une API pour agents. Et comme les tests utilisent eux aussi les mêmes commandes, l’agent peut vérifier automatiquement ce qu’il vient d’ajouter.

Étape 4 : séparer le moteur, les formats, le GPU et l’interface

Le workspace PhotoCraft est organisé en couches strictes. Les crates de fondation gèrent la géométrie, les couleurs et les pixels ; d’autres le format PSD ; le modèle de document contient les calques, masques et réglages ; les opérations et algorithmes vivent au-dessus ; le compositeur CPU sert de référence ; le GPU accélère le rendu ; les entrées/sorties convertissent les documents ; le moteur expose les commandes ; et l’interface egui reste tout en haut.

Un outil automatique vérifie que les dépendances ne remontent pas les couches. L’UI n’est donc pas autorisée à avaler progressivement la logique métier, un travers classique des gros logiciels de bureau.

Cette architecture est particulièrement adaptée aux agents : plusieurs Claude peuvent modifier des zones différentes sans tous toucher aux mêmes fichiers centraux.

Étape 5 : lancer plusieurs agents en parallèle sans transformer le dépôt en chaos

ArtCraft ne repose pas seulement sur un Claude travaillant très vite. Les documents publics décrivent explicitement l’usage de sous-agents parallèles.

Le fichier AGENTS.md indique comment éviter les collisions : chaque agent doit avoir son propre répertoire de compilation Cargo, éditer uniquement les fichiers dont il est responsable, créer de nouveaux modules plutôt que grossir des fichiers partagés et faire des modifications minimales lorsqu’un fichier central doit vraiment être touché.

Il existe même des consignes très concrètes pour éviter qu’un agent casse le travail des autres : si la modification en cours d’un autre agent provoque temporairement un échec de compilation, il faut attendre plutôt que « réparer » ses fichiers ; les fichiers Cargo.toml doivent être remplacés de façon atomique afin qu’un manifeste à moitié écrit ne bloque pas tout le workspace.

C’est beaucoup plus proche d’une équipe d’ingénieurs coordonnée que d’une simple conversation avec un chatbot.

Le chiffre le plus parlant : 51 000 lignes, 290 commandes, 11,5 heures-agent

Le dépôt CADCraft contient une donnée rare : une estimation basée sur les transcriptions Claude Code de la session de construction initiale.

Selon le document de parité, la première version de CADCraft représentait environ 51 000 lignes de code, 290 commandes et 47 % de couverture des menus. Le tout a demandé environ 11,5 heures-agent de Claude Opus 5.5 :

• environ 6,9 heures pour l’agent principal ;
• environ 4,6 heures cumulées pour huit sous-agents ;
• une partie de ces sous-agents travaillait en parallèle.

Le dépôt calcule donc environ 25 commandes ajoutées par heure-agent lors de cette phase initiale.

Mais la documentation ajoute immédiatement la nuance la plus importante : cette vitesse correspond à de la « presence quality ». Autrement dit, le premier passage est excellent pour faire exister beaucoup de fonctionnalités, beaucoup moins pour reproduire chaque option, chaque cas limite et chaque interaction subtile.

Le même document estime ensuite qu’atteindre une vraie profondeur AutoCAD demanderait encore des centaines ou des milliers d’heures-agent. L’exploit consiste donc à écraser le coût du premier 30 à 50 %, pas à faire disparaître les derniers 50 %.

Le « one-shot » PhotoCraft : ce que montre réellement le commit de 42 241 lignes

PhotoCraft fournit un autre exemple spectaculaire. Son commit 16941f7, intitulé simplement one-shot, ajoute 42 241 lignes. On y trouve déjà une architecture en crates, une CI GitHub Actions, un guide AGENTS.md, une séparation du moteur et de l’interface, des tests, un support WebAssembly et les premières briques du contrôle automatisé.

C’est important : le « one-shot » ne correspond pas seulement à une maquette visuelle. Claude a produit en une passe une quantité impressionnante de structure logicielle.

Mais là encore, la suite de l’historique Git raconte le reste de l’histoire. Après ce premier jet, des centaines de corrections détaillées apparaissent : fidélité des courbes de luminosité, comportement de Levels, fichiers RAW de vrais appareils, gestion des valeurs NaN, outils de recadrage, règles typographiques, compatibilité PSD, erreurs de sauvegarde, etc.

La vitesse initiale ne supprime donc pas la phase d’ingénierie. Elle permet de l’attaquer depuis une base déjà énorme.

Étape 6 : utiliser le logiciel cible comme oracle de comportement

Pour reproduire un outil complexe, les agents ont besoin de réponses précises à des questions du type : « que fait exactement Photoshop avec un gamma supérieur à 1 ? », « que contient ce bloc PSD ? », « où se trouve le zéro des règles lorsque l’image est tournée ? ».

Les commits publics montrent une méthode récurrente : observer le comportement du logiciel de référence sur des entrées contrôlées, enregistrer le résultat attendu, puis faire converger l’implémentation Rust.

Un commit sur Brightness/Contrast explique par exemple qu’un gradient 0–255 a été envoyé dans Photoshop 2026 pour reconstruire la forme de ses courbes. Un autre compare des résultats de niveaux. D’autres utilisent de vrais fichiers PSD produits par Photoshop et vérifient le rendu au pixel près.

Cette méthode transforme le logiciel propriétaire en oracle de sortie sans avoir besoin de son code source.

Étape 7 : construire des corpus de vrais fichiers, pas seulement des tests unitaires

Les tests unitaires ne suffisent pas pour un logiciel qui doit ouvrir des PSD, des RAW, des PDF ou des documents bureautiques réels.

PhotoCraft maintient donc plusieurs corpus de fichiers : fichiers PSD créés dans Photoshop, corpus publics psd-tools et ag-psd, PngSuite, ainsi que des fichiers RAW provenant de jeux publics. Les archives sont épinglées à des versions précises et vérifiées par SHA-256 avant les tests.

Le système peut ensuite répondre à des questions beaucoup plus solides : combien de fichiers s’ouvrent ? combien se réenregistrent sans altération ? quelle différence de pixels reste-t-il ? tel changement a-t-il cassé un format qui fonctionnait hier ?

La README de PhotoCraft indique par exemple que la réécriture conserve actuellement le rendu de 307 fichiers PSD sur 309 dans son corpus de test. Ce type de métrique est beaucoup plus utile que « l’application ressemble à Photoshop ».

Étape 8 : faire vérifier l’interface visuellement par l’agent

Les règles du dépôt imposent également une validation visuelle. L’application peut être rendue hors écran, ou lancée avec son canal de contrôle, puis produire une capture via une commande dédiée.

L’agent peut donc :

1. modifier l’interface ;
2. compiler ;
3. lancer l’application ;
4. ouvrir un document de référence ;
5. prendre une capture ;
6. inspecter le PNG ;
7. corriger son travail.

Cette boucle est capitale pour un logiciel graphique. Elle donne à Claude une forme de feedback visuel sans que le développeur soit obligé d’ouvrir manuellement chaque dialogue après chaque commit.

Étape 9 : imposer des garde-fous extrêmement stricts aux agents

Un dépôt de dizaines ou centaines de milliers de lignes généré très vite devient dangereux si les agents ont le droit de prendre tous les raccourcis.

ArtCraft compense avec des règles inhabituelles par leur précision. Dans PhotoCraft, le code hors tests ne doit pas paniquer ; unwrap(), expect(), panic!, todo! et plusieurs constructions risquées sont bloqués par Clippy. Les entrées externes sont considérées comme hostiles, les tailles doivent être bornées et chaque correction de crash doit ajouter un test de régression.

Une suite panic_hunt injecte même des paramètres adverses dans les commandes pour vérifier qu’elles renvoient une erreur au lieu de planter.

Les changements passent aussi par :

• cargo test ;
• cargo clippy avec avertissements transformés en erreurs ;
• contrôle des couches de dépendances ;
• build WebAssembly ;
• tests de corpus ;
• benchmarks de performance ;
• fuzzing sur les parseurs de formats ;
• CI Linux, macOS et Windows.

La leçon est presque paradoxale : plus le code est produit vite par l’IA, plus les barrières automatiques doivent être fortes.

Pourquoi Rust est un choix particulièrement malin pour ce type d’expérience

Rust apporte plusieurs avantages simultanés. Le langage produit des binaires natifs, sans Electron ni navigateur embarqué. Son système de types et de propriétés mémoire élimine une grande classe de bugs. Cargo rend simple la création de dizaines de modules indépendants. Et la même base peut être compilée vers WebAssembly pour le navigateur.

Avec wgpu, ArtCraft dispose d’une abstraction GPU unique capable de viser Metal sur macOS, Vulkan, DirectX 12 et WebGPU. Avec Rayon, des traitements d’image peuvent être parallélisés sur tous les cœurs sans écrire manuellement une infrastructure de threads.

Rust a aussi un coût : le compilateur est exigeant et la compilation peut être longue. C’est justement pour cela que les règles multi-agents imposent des répertoires target séparés : sans cela, plusieurs Claude lancés en même temps se battraient sur le verrou de compilation Cargo.

Pourquoi MCP est important, même si MCP n’a pas servi à écrire tout le code

Le Model Context Protocol n’est pas le moteur qui a créé ArtCraft. En revanche, l’avoir prévu dans chaque application rend le développement et l’usage par agents beaucoup plus puissants.

Chaque Craft App expose progressivement son moteur sous forme d’outils structurés. Un agent peut donc demander à PhotoCraft d’ouvrir un PSD, modifier un calque, lancer un filtre, exporter un PNG puis vérifier le résultat. Il ne « pilote » pas seulement l’IDE : il pilote également le logiciel qu’il vient de développer.

Cette boucle — agent qui écrit le logiciel, puis agent qui utilise le logiciel pour le tester — est probablement l’une des idées les plus importantes de toute l’expérience ArtCraft.

Le rôle de l’humain reste énorme

L’histoire ArtCraft est parfois résumée comme « Claude a cloné Photoshop ». C’est séduisant, mais incomplet.

Le développeur humain reste celui qui :

• choisit l’architecture ;
• définit les règles de clean-room ;
• écrit les invariants que les agents ne doivent pas violer ;
• choisit les corpus et les oracles ;
• organise le travail parallèle ;
• arbitre les compromis entre présence fonctionnelle et profondeur ;
• analyse les retours utilisateurs ;
• accepte, corrige ou rejette les contributions ;
• maintient une vision produit cohérente.

Le gain de productivité vient justement de ce découplage : l’humain investit davantage dans la spécification, l’architecture et le contrôle, tandis que Claude absorbe une énorme quantité de travail d’implémentation.

La communauté devient la deuxième moitié de la machine

Thomas a expliqué sur Hacker News qu’il avait volontairement cherché à amorcer une communauté capable de fournir des rapports de bugs et des pull requests. Une fois les dépôts publics et massivement visibles, les issues ont explosé.

Ce mécanisme est important : les agents construisent très vite une grande surface de logiciel, puis des milliers d’utilisateurs essaient des chemins impossibles à prévoir, signalent les erreurs et fournissent parfois directement des correctifs. Chaque problème concret redevient alors une tâche très bien définie pour Claude Code.

On obtient une boucle extrêmement rapide :

génération de couverture → utilisateurs → bugs précis → agents → tests de régression → nouvelle release.

C’est peut-être ce modèle collectif, plus encore que le premier « one-shot », qui permettra à certains de ces projets d’atteindre un niveau réellement utilisable.

Ce qu’ArtCraft révèle sur la nouvelle économie du développement logiciel

Le message « Software is over » lancé par Brandon Thomas est volontairement provocateur. Le logiciel n’est évidemment pas terminé. Au contraire, on pourrait assister à une explosion du nombre de logiciels.

Ce qui semble réellement changer, c’est le coût marginal de reproduction d’une fonctionnalité connue et bien spécifiée. Si une interface, un format de fichier et un comportement sont documentés ou facilement observables, un agent peut désormais générer très vite une première implémentation.

Les avantages concurrentiels se déplacent alors vers ce qui est plus difficile à copier :

• la qualité accumulée sur des millions de cas limites ;
• l’écosystème et les plugins ;
• la compatibilité parfaite des fichiers ;
• les données propriétaires ;
• les services cloud ;
• la confiance, le support et la responsabilité ;
• le design réellement original ;
• la communauté.

ArtCraft ne prouve donc pas qu’Adobe est mort. Il prouve quelque chose de plus concret : le coût pour construire un concurrent crédible à 20, 30 ou 40 % d’un logiciel mature vient de s’effondrer.

Peut-on reproduire la méthode ArtCraft sur son propre projet ?

Oui, mais certainement pas en copiant un unique prompt. La méthode publique d’ArtCraft peut être résumée en dix étapes :

1. Choisir un périmètre observable : une application, un workflow ou un protocole dont le comportement peut être testé.
2. Écrire une matrice de fonctionnalités : menus, commandes, formats, raccourcis, scénarios et cas limites.
3. Poser une architecture modulaire avant le volume : moteur métier séparé de l’UI, dépendances orientées, modules étroits.
4. Créer un fichier AGENTS.md extrêmement prescriptif : conventions, erreurs interdites, tests requis, manière de terminer une tâche.
5. Tout rendre pilotable par commandes : les agents doivent pouvoir appeler les fonctions sans GUI.
6. Automatiser les métriques : couverture de commandes, scorecards, performances, régressions.
7. Paralléliser uniquement les tâches réellement indépendantes et attribuer des fichiers ou modules précis à chaque agent.
8. Construire des corpus réels et des oracles de comparaison avec le comportement attendu.
9. Forcer l’agent à tester ce qu’il écrit, y compris visuellement lorsque le produit a une interface.
10. Faire entrer les retours utilisateurs dans la boucle pour transformer les bugs de terrain en tests permanents.

La leçon la plus importante est probablement la quatrième : un agent puissant amplifie la qualité de l’environnement dans lequel on le place. Un dépôt mal structuré donne du code IA difficile à maintenir. Un dépôt avec des règles, des métriques et des tests permet à l’agent de produire à une échelle beaucoup plus grande sans perdre immédiatement le contrôle.

Ce que l’on ne sait pas exactement

Il reste des zones d’ombre, et il faut les signaler pour ne pas transformer l’exploit en légende. Les prompts initiaux complets de PhotoCraft ne sont pas publiés. Le coût total en tokens de l’ensemble des treize applications n’est pas documenté publiquement. Certaines règles communes sont stockées dans un dépôt interne craftrules auquel les contributeurs externes n’ont pas accès.

Nous pouvons donc reconstruire très précisément l’architecture, les outils, les règles de travail, la parallélisation et les boucles de test, mais pas reproduire mot pour mot la session qui a généré chaque application.

C’est aussi pour cela que les chiffres de CADCraft sont intéressants : ils constituent l’un des rares endroits où le projet publie une calibration fondée sur les transcriptions de la session Claude Code elle-même.

Où télécharger les applications ArtCraft ?

Si vous voulez essayer le résultat plutôt que simplement étudier la méthode, la page officielle est getartcraft.com/apps. ArtCraft recommande d’utiliser son Launcher, qui permet d’installer les différentes applications et de les maintenir à jour. Chaque application dispose également de sa propre page et de ses installateurs.

Au moment de la rédaction, la suite regroupe treize projets : PhotoCraft, VectorCraft, FilmCraft, LightCraft, PdfCraft, EffectCraft, DesignCraft, FigCraft, WordCraft, SoundCraft, DeckCraft, CADCraft et GridCraft.

Les sources sont disponibles dans l’organisation GitHub storytold. C’est aussi l’endroit à privilégier pour consulter les releases, le code, les issues et les checksums. Des versions macOS, Windows et Linux sont proposées selon les applications ; la majorité compile également vers WebAssembly pour fonctionner directement dans un navigateur.

Attention toutefois : plusieurs logiciels sont encore classés en alpha ou en développement. Pour des fichiers professionnels importants, conservez les originaux, testez les exports et évitez de considérer ces versions comme des remplaçants garantis des outils Adobe, Microsoft ou Autodesk.

Sources

• ArtCraft — Crafting Apps
• PhotoCraft — AGENTS.md : architecture, règles de contribution, agents parallèles et tests
• CADCraft — Target-app parity : calibration des heures-agent Claude Code
• PhotoCraft — commit « one-shot » de 42 241 lignes
• Hacker News — discussion ArtCraft avec Brandon Thomas
• Ars Technica — « Software is over » : contexte, Claude Opus 5.5 et limites
• Tom’s Hardware — profil de Brandon Thomas et lancement initial