Le code n’a jamais été le produit

Toutes les deux ou trois semaines, un réseau social ou un autre annonce la mort d’un pan entier de l’industrie logicielle. Le scénario ne varie guère : un développeur, un modèle d’IA, une consigne qui tient en une phrase (« je veux une copie de tel logiciel »), puis un fil triomphal. Le dernier en date, relayé par Pirat Nation, présente sept applications libres, écrites en Rust avec l’aide de Claude Opus 5.5, comme des alternatives « clean-room » aux principaux outils d’Adobe.

Je prends cette suite pour exemple, pas pour cible. Elle est simplement la plus aboutie de ces annonces, et donc celle qui montre le mieux ce que toutes oublient. Je ne jugerai pas la qualité de son code : je n’en ai ni le temps ni la prétention, et ce n’est pas mon propos. Mon propos est ailleurs. Le code est une partie très importante d’un logiciel, mais une partie très importante ne fait pas un tout, et encore moins la rencontre entre un produit et un client.

Ce qui a été publié

Derrière le projet se trouve Brandon Thomas, présenté comme un vétéran de quinze ans du secteur, qui dirige ArtCraft. La méthode : huit agents lancés en parallèle, qui ont produit sept logiciels imitant Photoshop, Illustrator, Premiere Pro, Lightroom, After Effects, InDesign et Acrobat Pro, sous licences MIT ou Apache.

Les chiffres impressionnent. En huit jours, les sept dépôts ont cumulé plus de 42 000 étoiles sur GitHub, dont plus de 23 000 pour le seul PhotoCraft. Le même article dénombre 24 crates et plus de 1 700 tests pour PhotoCraft, 35 crates et plus de 1 600 tests pour FilmCraft. Rien à redire sur le volume : c’est un travail considérable, abattu en un temps qui aurait été inimaginable il y a trois ans.

L’auteur, il faut le reconnaître, ne cache rien du stade atteint : les badges affichent « early alpha » ou « in development », et il compte sur les retours de bugs et les contributions de la communauté pour stabiliser l’ensemble. Le problème n’est pas l’honnêteté du projet. C’est le récit qu’on en tire.

Le prompt n’est pas un cahier des charges

« Fais-moi un Photoshop » est une consigne d’une précision redoutable sur tout ce qui se voit, et d’une pauvreté totale sur tout ce qui ne se voit pas. Un modèle peut reproduire des menus, des panneaux, des calques, des masques et des raccourcis, parce que tout cela est documenté, montré dans des milliers de tutoriels, photographié sous tous les angles. Ce qu’il ne peut pas deviner, c’est ce qui n’a jamais été écrit nulle part : pourquoi tel comportement existe, à quel client il a répondu, quel fichier corrompu de 2009 il permet encore d’ouvrir.

C’est toute la différence entre le vibe codeur qui maîtrise une consigne et l’ingénieur qui maîtrise les tenants et les aboutissants. Le premier réinvente la roue en la regardant tourner ; le second sait sur quelle route elle roule, quelles charges elle porte, et ce qui casse quand on la change. J’écrivais il y a quelques mois que plus personne ne lit le code qu’il déploie. Ces annonces vont un cran plus loin : on ne lit plus non plus le logiciel qu’on prétend remplacer.

Le chiffre qui trahit la thèse

Un détail de la communication d’ArtCraft dit tout. Selon l’équipe, il faudrait encore 140 à 220 heures-agents, soit 25 à 40 heures réelles, pour atteindre 95 % de parité fonctionnelle avec les outils d’Adobe. Quarante heures pour rattraper trente-cinq ans. Le chiffre est séduisant, et il est surtout optimiste au regard des propres documents du projet.

Ces documents, il faut leur rendre cette justice, sont d’une franchise rare. Pour PhotoCraft, ils affichent 625 éléments de menu câblés sur 625, une parité fonctionnelle globale d’environ 86 %, mais seulement 115 fichiers PSD sur 170 rendus au pixel près, et une aptitude au travail professionnel quotidien estimée à 25 à 35 %. Tout est là : 100 % des menus répondent, un tiers à peine du travail réel est possible. L’écart entre « menus câblés » et « prêt pour le travail réel » n’est pas une critique extérieure, c’est l’équipe elle-même qui le mesure.

La parité fonctionnelle mesure une liste de fonctions cochées. Elle ne mesure pas un logiciel. Ce qui manque n’est pas une poignée de fonctions oubliées : ce sont les fichiers réels, les cas tordus, les comportements limites, c’est-à-dire précisément ce qui fait qu’un professionnel confie sa journée de travail à un outil. Le suivi des bugs le montre déjà : parmi les 447 issues ouvertes sur PhotoCraft figurent un plantage à l’ouverture d’un PSD de 32 calques et des PSD qui refusent tout bonnement de s’ouvrir.

J’ai déjà raconté comment, sur un tout autre sujet, une métrique en hausse peut sortir d’un dispositif de mesure cassé et ressembler trait pour trait à un vrai progrès. Un pourcentage de parité, c’est exactement cela : un chiffre qui monte, et qui ne dit rien de ce qui compte.

Un format est un territoire, pas une spécification

Le README de PhotoCraft précise que le support du PSD repose sur la spécification publiée par Adobe. C’est rigoureux, et c’est insuffisant. Une spécification décrit un format idéal. Elle ne décrit pas trente-cinq ans de fichiers produits par des dizaines de versions successives, des plugins tiers, des exports approximatifs et des bugs devenus des normes de fait. Le vrai format PSD, c’est le stock mondial de fichiers PSD, pas le document qui le définit.

Même chose pour la mise en page. Un imprimeur n’attend pas « un PDF » : il attend un PDF/X conforme, avec des profils colorimétriques maîtrisés, des fonds perdus corrects et des polices incorporées. Un graphiste ne choisit pas InDesign pour ses menus, mais parce que son imprimeur, son agence et ses clients savent tous lire ce qui en sort.

Le réel a une manière bien à lui de répondre aux refontes parfaites. Je l’avais décrit avec IPv6, l’Esperanto des réseaux : une solution techniquement supérieure, née en 1998, que le monde refuse obstinément d’adopter. Dans le logiciel, on ne gagne pas contre l’existant en ayant raison, on gagne en étant compatible avec lui.

Les codecs, ou le droit avant le code

FilmCraft a fait un choix audacieux : se passer de FFmpeg et embarquer ses propres codecs H.264, HEVC, ProRes et AAC. Sur le papier, c’est la pureté Rust jusqu’au bout. En pratique, c’est s’attaquer à deux montagnes à la fois.

La première est juridique : ces formats sont couverts par des brevets, regroupés pour certains dans des pools de licences, et la question n’est pas de savoir si l’on sait les écrire, mais si l’on a le droit de les distribuer. La seconde est technique : FFmpeg et les encodeurs matériels représentent deux décennies d’optimisation, de corrections de cas limites et de compatibilité avec des millions de fichiers mal formés. Quiconque a passé du temps à régler un encodage en qualité constante sait qu’un codec ne se juge pas à ce qu’il produit sur une vidéo de démonstration, mais sur ce qu’il fait de la pire source qu’on lui donne.

GIMP, Inkscape et Scribus ont déjà répondu

Voici l’argument qui, à mes yeux, tranche le débat. Si le code était la barrière qui protège Adobe, elle serait tombée depuis longtemps. GIMP existe depuis le milieu des années 1990, Inkscape et Scribus depuis 2003. Ce sont des logiciels libres, gratuits, écrits par de vraies équipes, sur des décennies, avec des contributeurs qui connaissaient intimement leur sujet. Ils sont respectables, souvent excellents sur leur terrain, et ils restent marginaux dans les studios professionnels.

Ce n’est pas faute de code. C’est que le client d’Adobe n’achète pas du code. Les seules alternatives qui ont réellement grignoté le terrain, comme Affinity ou DaVinci Resolve, l’ont fait avec des entreprises derrière, des années d’investissement et une stratégie de compatibilité patiente. J’avais d’ailleurs détaillé, à propos de la politique tarifaire d’Adobe, combien le géant poussait lui-même ses clients vers la sortie. La porte est ouverte depuis des années : ce n’est pas un prompt qui la franchira.

L’habitude est l’actif

ArtCraft revendique un choix révélateur : l’interface reprend volontairement les menus, les panneaux et les raccourcis d’Adobe, pour qu’un utilisateur de Photoshop se sente immédiatement chez lui. C’est un aveu. Si la copie de l’apparence est l’argument commercial principal, c’est que l’actif véritable d’Adobe n’est pas son code, mais l’habitude de dizaines de millions de personnes.

Cette habitude s’est construite avec des écoles qui enseignent Photoshop, des offres d’emploi qui exigent sa maîtrise, des milliers de presets, de pinceaux, de scripts et de plugins, des tutoriels dans toutes les langues, des forums où chaque problème a déjà sa réponse. C’est un effet réseau, et je sais d’expérience ce qu’il pèse. J’ai administré des serveurs FreeBSD en production avant de me rendre à l’évidence : l’écosystème de Linux a écrasé l’élégance des BSD, non par supériorité technique, mais par la force du nombre. On ne copie pas un effet réseau en copiant des menus.

Le savoir qui ne se prompte pas

LightCraft promet une bibliothèque photo et un développeur RAW. C’est sans doute le cas le plus parlant. Un développeur RAW crédible repose sur des milliers de profils de boîtiers et d’objectifs, mesurés un par un, mis à jour à chaque sortie d’appareil, et sur une science des couleurs qui relève davantage du laboratoire que de l’algorithme.

Il ne s’agit pas de lignes de code mais de données accumulées, de mesures physiques et de choix esthétiques assumés. J’ai consacré un billet entier à la colorimétrie de Sony et à l’héritage Minolta : même un géant qui possède les capteurs ne parvient pas toujours à produire des carnations justes. Ce savoir-là ne se trouve dans aucun corpus d’entraînement, parce qu’il n’a jamais été écrit sous une forme qu’un modèle pourrait copier.

Qui paiera la maintenance dans cinq ans ?

Un logiciel professionnel n’est pas un livrable, c’est un engagement dans la durée : corriger, suivre les nouvelles versions des systèmes, des processeurs, des formats, des boîtiers. Sur ce point, le modèle d’ArtCraft mérite d’être lu attentivement. L’équipe prévoit de financer le développement en vendant l’accès à son propre modèle d’IA, proposé dans les applications aux côtés de modèles tiers. Et il ne s’agit pas d’une fondation ou d’un collectif de bénévoles, mais d’une entreprise spécialisée dans l’image générée par IA.

Rien d’illégitime à cela. Mais cela change la nature de l’objet : la suite gratuite devient un canal de distribution pour un service payant. On connaît la mécanique, que je décrivais à propos des boucles d’IA et de la dépendance qu’on vend avec : l’outil est ouvert, le cerveau reste ailleurs. Le jour où la monétisation ne suivra pas, qui maintiendra sept applications, des codecs maison et un moteur PSD ? Un client professionnel ne parie pas son activité sur cette question sans réponse.

Ce que ces projets font vraiment de neuf

Soyons justes, parce que tout n’est pas mirage. Ces applications sont natives, sans Electron ni vue web, et la plupart tournent aussi dans un navigateur. Surtout, PhotoCraft expose plus de 500 commandes en ligne de commande, également accessibles via un serveur MCP, le protocole qui permet à un agent d’IA de piloter une application.

C’est peut-être là le vrai sujet, et il est passionnant : le client visé n’est plus seulement le graphiste, mais l’agent qui travaillera pour lui. Adobe n’a jamais pensé ses outils pour être pilotés par une machine, et ce marché-là est réellement neuf. On retrouve le mouvement que j’observais avec EmDash, le CMS que Cloudflare a d’abord construit pour les agents. Sur ce terrain, partir de zéro est un avantage. Sur celui du graphiste qui doit livrer un catalogue imprimé vendredi, c’est un handicap.

Ce qu’on m’opposera

On m’opposera que Linux a fini par l’emporter contre les Unix propriétaires, et que l’open source gagne toujours à la fin. C’est vrai, mais Linux a gagné par trente ans de communauté, de mainteneurs, d’entreprises qui ont investi et de compatibilité patiemment construite. Pas par un sprint de huit jours.

On pourrait aussi me renvoyer à mes propres écrits : j’ai soutenu que la complexité d’Odoo n’était pas technique mais commerciale. Je le maintiens, et ce n’est pas contradictoire. Je parlais du déploiement, qu’on rend artificiellement intimidant pour vendre de l’intégration. Ici, je parle de ce que vaut le produit une fois déployé. La première complexité est une barrière qu’on dresse ; la seconde est une valeur qu’on accumule.

La rareté a déménagé

Brandon Thomas voit venir un monde où chaque développeur pourra recréer en open source les logiciels payants pour « take back the internet and own tech forever ». Il a raison sur un point essentiel : le code devient abondant. Je l’écrivais dès janvier, le coût marginal de la programmation s’effondre, et ces sept dépôts en sont une démonstration spectaculaire.

Mais quand une ressource devient abondante, la rareté ne disparaît pas, elle déménage. C’est la thèse que je défendais récemment à propos de l’âge de l’abondance promis par Musk, et elle s’applique ici trait pour trait. La rareté s’installe désormais dans la compatibilité avec le stock existant, dans les données mesurées plutôt que générées, dans le droit de distribuer, dans la confiance qu’un outil sera encore là et encore maintenu dans cinq ans, dans l’habitude de millions d’utilisateurs.

Rien de tout cela ne se prompte. On peut demander à une IA une copie de Photoshop. On ne peut pas lui demander une copie de trente-cinq ans de clients.