PhotoCraft et le prix du logiciel gratuit à l'ère de l'IA
Une réimplémentation indépendante de Photoshop soulève une question plus vaste : si l'IA facilite la création de logiciels, qui paie pour leur fiabilité, leur maintenance et la prochaine avancée ?
Illustration éditoriale originale de Telli.sh. Il s'agit d'un schéma conceptuel, pas d'une capture d'écran de PhotoCraft ni d'une prévision économique mesurée.
Une application créative familière, reconstruite publiquement et disponible sans abonnement : difficile de ne pas s'enthousiasmer à cette idée. Pour les étudiants, les créateurs occasionnels et les personnes que le prix des outils professionnels exclut, l'accès gratuit peut faire la différence entre avoir une idée et la concrétiser. Mais l'enthousiasme n'est que le début de l'histoire. Si l'IA réduit sensiblement le coût de la reproduction d'un logiciel, elle nous oblige aussi à demander qui continuera à développer les capacités qui méritent d'être reproduites.
PhotoCraft rend cette question particulièrement concrète. Des articles sur les projets ArtCraft décrivent une initiative assistée par l'IA visant à reconstruire des outils créatifs établis, dont un éditeur semblable à Photoshop. Ce qui compte n'est pas simplement l'apparition d'une nouvelle alternative sur une page de téléchargement. C'est la possibilité que le chemin entre l'observation d'un flux de travail utile et la production d'une implémentation exploitable se raccourcisse. Cette possibilité mérite attention sans transformer un projet ambitieux encore à ses débuts en remplacement professionnel achevé. Phoronix, 7 octobre 2026
PhotoCraft reprend les flux de retouche familiers
PhotoCraft est un projet indépendant, pas une publication d'Adobe. Son dépôt annonce des calques, des masques, des calques de réglage, du texte modifiable, des vecteurs ainsi que des flux de travail PSD et PSB. Selon l'évaluation de parité du projet du 10 octobre 2026, il reste en version alpha : les mainteneurs estiment sa préparation à un usage professionnel à environ 45 % et jugent les échanges PSD avec Photoshop pas encore assez fiables pour une bêta. Ce sont les mesures et estimations du projet, pas une évaluation indépendante. Dépôt PhotoCraft, évaluation de parité, 10 octobre 2026
Dire « une version open source de Photoshop » est un raccourci commode, mais cela peut effacer des distinctions importantes. Réimplémenter un comportement n'est pas publier le code source original d'Adobe. La description par un développeur d'un processus de conception indépendante (clean room) ne constitue pas un audit indépendant de ce processus. Et une interface familière ne prouve pas la compatibilité avec tous les documents, plug-ins, polices ou pipelines de production professionnels. Pour cet article, nous n'avons ni audité la provenance de l'implémentation, ni installé l'application, ni réalisé de tests comparatifs indépendants.
Le code source est proposé sous licence MIT ou Apache-2.0, tandis que les mentions, les ressources intégrées et les marques exigent un examen distinct. Une licence de code permissive ne donne pas le droit de réutiliser toute marque ou œuvre associée à un dépôt. Les lecteurs qui envisagent une redistribution devraient consulter les fichiers de licence et d'attribution eux-mêmes, plutôt que de considérer « gratuit » comme une autorisation générale. Cet article ne tranche pas le statut juridique de la rétro-ingénierie dans quelque juridiction que ce soit. Licence et crédits, fichier d'attribution
La compatibilité est un flux de travail, pas un nombre de menus
L'étendue fonctionnelle n'est qu'un aspect de la compatibilité. Dans son évaluation du 10 octobre, le projet indique que 133 des 256 fichiers PSD de référence créés avec Photoshop ont réussi son contrôle actuel de fidélité. Il signale aussi des lacunes persistantes en matière de performances, de stabilité, d'interaction et de prise en charge de l'écosystème. Ces chiffres témoignent de tests actifs, mais ne constituent pas des évaluations indépendantes de chaque flux de travail. Évaluation de parité de PhotoCraft
Imaginons une designer qui teste une alternative avec une affiche simple. Elle s'ouvre, un calque de texte reste modifiable et l'export semble correct. C'est un progrès réel. Imaginons maintenant que cette même designer reçoive le document d'un client avec des profils colorimétriques inhabituels, des ressources liées, des effets de plug-ins et une typographie soigneusement réglée. La deuxième tâche pose une autre question : les attentes accumulées pendant des années résistent-elles aux échanges entre personnes, machines et versions ?
Une évaluation raisonnable commence donc par des copies de fichiers et un flux de travail limité. Peut-on modifier un document importé, l'enregistrer, le rouvrir dans l'application d'origine et le transmettre à un collègue sans changement inattendu ? L'application récupère-t-elle après un plantage ? Les opérations non prises en charge sont-elles expliquées avant qu'elles ne fassent perdre des informations ? Une démonstration spectaculaire prouve qu'une démonstration a fonctionné ; elle ne prouve pas que tous ces engagements sont tenus.
Cette distinction n'est pas un argument contre le projet. Elle sépare la reconnaissance d'une réussite du fait de faire une promesse en son nom. Les alternatives naissantes doivent pouvoir progresser, et les utilisateurs ont besoin d'assez d'informations pour décider quand l'expérimentation est appropriée. Remplacer cette relation par le mot « terminé » ne rendrait service à personne.
L'accès gratuit crée de vraies possibilités
Le meilleur argument en faveur de l'open source commence par les personnes qui ne pouvaient pas participer auparavant. Un abonnement récurrent peut être raisonnable pour un studio, mais difficile à assumer pour quelqu'un qui réalise un projet scolaire, une lettre d'information associative ou des illustrations occasionnelles. Un éditeur accessible permet à ces personnes de s'exercer, de se tromper et de développer leurs compétences sans transformer chaque mois d'apprentissage en décision financière. Cela compte même si l'outil ne couvre au départ qu'une partie des besoins professionnels.
La disponibilité du code source apporte une autre forme d'accès. Une communauté locale peut améliorer la prise en charge linguistique. Un spécialiste de l'accessibilité peut examiner une interaction qui exclut certains utilisateurs. Une institution peut préserver une version utile au lieu de dépendre entièrement de la feuille de route commerciale d'un fournisseur. Ce sont des avantages possibles d'une base de code ouverte, pas des réussites automatiques de chaque projet. Ils ne deviennent réels que si quelqu'un fait le travail et si le projet peut l'accepter et le maintenir.
La concurrence change aussi les questions auxquelles les fournisseurs établis doivent répondre. Si une alternative gère bien les tâches quotidiennes, les clients peuvent demander plus clairement ce qu'apporte un produit premium : des capacités plus poussées, un meilleur support, une collaboration fiable ou un écosystème exceptionnel. Un abonnement ne se justifie plus par la seule absence d'alternatives. Il doit expliquer la valeur de la relation dans la durée.
Inutile de prétendre que tous les utilisateurs recherchent la même formule. Certaines personnes apprécient un outil hors ligne qu'elles peuvent conserver indéfiniment. D'autres veulent des mises à jour gérées et du support. Une petite organisation peut associer les deux. L'open source est notamment précieux parce qu'il élargit le choix au lieu d'imposer à tout le monde une théorie unique du financement et de la distribution des logiciels.
Une copie moins coûteuse ne rend pas l'innovation gratuite
Ce qui m'inquiète, ce n'est pas que les utilisateurs puissent obtenir gratuitement des logiciels utiles. C'est un avantage à préserver. La préoccupation concerne la différence entre reproduire un flux de travail existant et découvrir le prochain flux de travail précieux. Une réplique peut s'appuyer sur un produit qui a déjà résolu de nombreux problèmes de conception difficiles. Il faut toujours que quelqu'un identifie de nouveaux problèmes, prenne des paris incertains et assume le coût des expériences infructueuses.
La même distinction s'applique après la première version. Maintenir la compatibilité avec un système d'exploitation qui évolue n'est pas une tâche ponctuelle. Il en va de même pour l'analyse d'un rare signalement de perte de données, la réaction à une dépendance vulnérable ou la vérification d'un format d'importation peu courant. L'IA peut aider dans ces tâches, mais l'assistance ne fait pas disparaître la responsabilité. Quelqu'un doit décider de ce qui est correct, le vérifier et en répondre si une correction crée un autre problème.
Un écosystème peut sembler sain tout en reposant sur une petite quantité de travail invisible. Les utilisateurs voient les nouvelles fonctionnalités, pas nécessairement le mainteneur épuisé qui trie des centaines de signalements. Une organisation peut dépendre volontiers de code gratuit sans jamais financer son entretien. Si la reproduction moins chère réduit les revenus sans remplacer les mécanismes qui soutiennent la maintenance, on pourrait se retrouver avec davantage d'applications disponibles et moins d'applications fiables.
C'est un risque, pas une prédiction selon laquelle l'open source détruirait inévitablement l'innovation. Les projets ouverts peuvent donner naissance à des entreprises, recevoir des subventions, attirer des sponsors et répartir le développement entre organisations. Les projets commerciaux peuvent eux aussi négliger la maintenance ou enfermer les utilisateurs dans un service médiocre. La question pertinente n'est pas l'étiquette qui garantirait la vertu. C'est de savoir si le modèle de financement récompense, dans la durée, le travail dont les utilisateurs ont besoin.
Que devraient payer les utilisateurs quand le code abonde ?
Cadre éditorial original. Les trois responsabilités peuvent relever d'une équipe ou de plusieurs ; aucune n'est automatiquement assumée par la génération de code.
Une réponse consiste à dissocier l'accès à une capacité des garanties qui l'entourent. Un éditeur local gratuit peut offrir une réelle valeur. Une distribution bénéficiant de support pourrait facturer des versions signées, des mises à niveau testées et de l'aide pour les fichiers difficiles. Un service collaboratif pourrait facturer le stockage, les autorisations, la synchronisation et la récupération. Ce sont des exemples de modèles économiques possibles, pas des services que nous avons confirmé que PhotoCraft vend actuellement.
La couche d'infrastructure me paraît particulièrement importante. Une fonctionnalité peut être impressionnante isolément et fragile dans le travail quotidien. Un service fiable exige des sauvegardes réellement restaurables, des règles d'accès claires, des défaillances visibles et un plan de gestion des incidents. Quand plusieurs personnes dépendent des mêmes informations, le coût d'un système indisponible ou incohérent peut dépasser celui de la fonctionnalité elle-même.
Mais « infrastructure » ne devrait pas devenir une excuse vague pour imposer un abonnement supplémentaire. Un fournisseur devrait pouvoir expliquer ce qu'il exploite, ce qui se passe en cas de panne et comment un client peut partir. Un stockage sans export peut devenir un piège. Une promesse de sauvegarde sans procédure de récupération est incomplète. La confiance s'acquiert par des engagements concrets et une exécution répétée, pas en accolant le mot « géré » à du code open source.
Service et propriété peuvent coexister. Les utilisateurs peuvent conserver des fichiers aux formats standard et des copies locales tout en payant pour une collaboration fiable. Les entreprises peuvent contribuer en amont aux améliorations tout en gagnant de l'argent grâce à l'exploitation du logiciel. La formule la plus saine pourrait rendre le code source disponible et le service facultatif, avec des coûts de changement liés à un réel confort plutôt qu'à la privation d'accès au travail de chacun.
Les logiciels personnels pourraient devenir plus pratiques
Si l'implémentation devient moins coûteuse, de plus petits problèmes valent la peine d'être résolus. Une photographe pourrait vouloir une interface organisée autour d'une tâche d'export récurrente plutôt qu'une palette d'outils universelle. Un enseignant aurait besoin d'un écran de révision adapté à une classe. Un groupe de recherche pourrait préférer un flux de travail qui garde visible une étape de validation particulière. Ce sont des pistes plausibles, pas l'affirmation qu'un agent personnel peut déjà créer toute application en toute sécurité.
Jusqu'ici, un besoin aussi précis devenait souvent un tableur, une macro ou un compromis au sein d'un produit plus vaste. Le développement assisté par l'IA pourrait faciliter la transformation de ces compromis en interfaces conçues pour un usage précis. Le rôle de la personnalisation changerait alors. Au lieu de choisir parmi les paramètres anticipés par quelqu'un d'autre, un utilisateur pourrait décrire un flux de travail et contribuer à façonner un petit logiciel autour de celui-ci.
La difficulté consiste à préserver les qualités qui rendent les logiciels partagés utiles. Une modification personnelle peut devenir incompatible avec les mises à jour futures. Un assistant généré pourrait gérer le cas normal mais mal traiter la suppression ou la récupération. Un flux de travail évident pour son auteur pourrait être incompréhensible pour un collègue. La personnalisation a donc besoin de limites, de documentation et de modifications réversibles, pas seulement d'une boucle de génération enthousiaste.
Il faut aussi tenir compte de la répartition de l'expertise. Un utilisateur à l'aise avec la technique peut examiner une modification ; une autre personne peut être incapable de distinguer un simple changement d'interface d'un programme qui lit des fichiers ou envoie des données ailleurs. Si les logiciels personnels se répandent, des modèles d'autorisation compréhensibles deviendront plus importants, pas moins. Simplifier la création ne doit pas transférer discrètement toute la charge de maintenance et de sécurité à la personne qui a demandé l'outil.
Claude Code Mods offre un petit aperçu de cette orientation
Claude Code Mods est un exemple concret d'outil qui devient un environnement personnalisable. La documentation d'Anthropic décrit des gestionnaires JavaScript ou TypeScript capables de modifier des éléments d'interface et le comportement dans Claude Code. C'est davantage que demander au modèle de répondre sur un autre ton : de petits fragments de code peuvent remodeler une partie de l'environnement de travail. Présentation officielle de Mods, consultée le 12 octobre 2026
La même documentation avertit que les mods ne sont pas isolés dans un bac à sable et s'exécutent avec les autorisations de l'utilisateur. L'exemple est donc utile à deux titres. Il annonce des logiciels de plus en plus personnels et montre pourquoi ceux-ci ont toujours besoin d'une base fiable. Une modification pratique n'est pas automatiquement sûre simplement parce qu'une IA a aidé à l'écrire.
À mes yeux, PhotoCraft est moins intéressant comme verdict sur un acteur établi que comme question sur la prochaine économie du logiciel. L'open source peut mettre des capacités puissantes entre davantage de mains. En parallèle, il reste nécessaire de financer la découverte, la maintenance et une exploitation fiable. À mesure que l'IA facilite la reproduction et la personnalisation des interfaces, je m'attends à des logiciels plus personnels et à une infrastructure partagée encore plus importante. Claude Code Mods offre un aperçu modeste mais révélateur de cet avenir : l'outil peut s'adapter à son utilisateur, mais il faut toujours que quelqu'un rende le socle fiable.
Garder une trace vérifiable de vos recherches sur l'IA
Pour les lecteurs qui rassemblent leurs propres notes de recherche, Telli.sh est un endroit facultatif où organiser les ressources et les résumés qui en sont dérivés. Créer un espace de notes.