PhotoSuite, quasi-clone de Photopea, illustre le risque des dérivés open source sans provenance
La lettre selfh.st du 9 octobre 2026 relate la controverse autour de PhotoSuite et PhotoCraft, deux prétendus clones auto-hébergés de Photopea dont l’historique de code est contesté. Avant d’adopter un fork communautaire, vérifiez sa provenance, son historique de commits et sa licence.
9 octobre 2026. La lettre Self-Host Weekly d’Ethan Sholly consacre son édito à une controverse qui agite la communauté auto-hébergée. Une suite. Deux alternatives open source à Adobe, PhotoSuite puis PhotoCraft, apparaissent coup sur coup. Une accusation. Le développeur de Photopea y voit des copies et signale le dépôt à GitHub. Pourquoi c’est important : dans l’auto-hébergement, la confiance se gagne par la provenance du code, et ce genre d’épisode montre à quel point elle est fragile.
Deux projets qui se ressemblent un peu trop
PhotoSuite est décrit par selfh.st comme un quasi-clone de Photopea, l’éditeur d’images en ligne devenu une référence de la communauté. La sortie ne passe pas inaperçue : Ivan Kutskir, le créateur de Photopea, est parmi les premiers à tirer la sonnette d’alarme. Il signale le projet à GitHub, après quoi le dépôt est temporairement fermé et nettoyé de l’accusation.
La chronologie se complique ensuite. PhotoCraft est publié à son tour. Le dépôt PhotoSuite rouvre, en créditant PhotoCraft comme la « fondation » de l’application. Sauf que la nouvelle revendication est immédiatement scrutée : les horodatages du dépôt PhotoSuite sont antérieurs à l’existence de PhotoCraft. Autrement dit, la filiation affichée ne tient pas, et l’ordre réel des événements devient difficile à reconstituer, y compris pour les lecteurs qui suivent les fils Reddit et Hacker News consacrés à l’affaire.
La recommandation d’Ethan Sholly est sans détour : « éviter les nouvelles alternatives tant qu’elles n’auront pas prouvé être davantage que des dérivés vibe-codés du travail de quelqu’un d’autre ». Le terme n’est pas anodin : il désigne du code généré à la va-vite, souvent par IA, sans la rigueur d’un vrai projet maintenu.
Photopea, une cible récurrente de la communauté
Ce n’est pas la première friction entre Photopea et la foule de l’auto-hébergement. Quelques années plus tôt, l’éditeur de Noted.lol s’était publiquement moqué de la tarification de la version auto-hébergée de Photopea. Le créateur, comme le note selfh.st, « ne peut tout simplement pas avoir de répit ». Cette histoire de fond compte : elle explique pourquoi un clone suscite autant d’émotion, et pourquoi la question de la légitimité d’un fork se pose de façon aiguë.
Photopea occupe une place particulière dans l’écosystème. C’est un logiciel très apprécié, développé pour l’essentiel par une seule personne, et dont le modèle économique repose en partie sur la publicité et des options payantes. Pour la communauté auto-hébergée, qui cherche des alternatives à Adobe qu’on peut installer chez soi, Photopea est à la fois une référence technique et un point de tension économique. Un clone qui arrive sans crier gare touche donc à la fois à la propriété du code et à la sensibilité d’un public.
C’est exactement le terreau où prospèrent les dérivés douteux : une forte demande, un modèle économique tendu, et une barrière technique réelle pour reconstruire l’outil. Le clone promet de résoudre les trois d’un coup, en réutilisant ce qui a déjà été construit.
Ce que la provenance révèle, et ce qu’elle ne révèle pas
L’affaire PhotoSuite-PhotoCraft illustre un point de méthode pour quiconque installe un logiciel auto-hébergé : la provenance n’est pas un détail juridique, c’est un critère de sécurité opérationnelle. Un fork dont on ne peut pas reconstituer l’historique est un fork dont on ne peut pas évaluer ni la qualité ni les intentions. Les trois questions à poser sont simples : d’où vient le code, qui le maintient, et sous quelle licence.
Un historique de commits incohérent — des horodatages qui ne concordent pas, un crédit de « fondation » vers un projet plus jeune — est un signal d’alarme immédiat. Il ne prouve pas une malveillance, mais il indique que le projet n’a pas été mené comme une vraie base de code maintenue. Or, pour un service qu’on va exposer sur son NAS ou son VPS, et auquel on va confier ses fichiers, l’exigence minimale est de comprendre ce que l’on fait tourner.
La licence complète le tableau. Un clone qui réutilise du code Photopea (ou de tout autre projet) doit respecter la licence de ce code. Si la filiation est floue, la conformité de licence l’est tout autant, et l’utilisateur final hérite d’un risque juridique en plus d’un risque technique. Le self-hébergement repose sur la confiance que l’on peut lire le code ; quand cette lecture devient impossible, la confiance n’a plus de socle.
Le vibe coding, carburant des clones à bas coût
Le qualificatif vibe-codé employé par selfh.st mérite qu’on s’y arrête. Il désigne une pratique devenue banale : générer une application entière en dictant des intentions à un modèle, sans relire ni comprendre le code produit. Le résultat peut être impressionnant en démonstration et fragile en production — c’est exactement le profil des clones qui apparaissent en quelques jours autour d’un outil populaire comme Photopea.
Pour la communauté auto-hébergée, le risque est double. D’abord, un risque de sécurité : du code généré sans relecture peut embarquer des dépendances douteuses, des portes dérobées ou des failles que personne n’a jamais auditées. Ensuite, un risque de pérennité : un projet né d’un coup de générateur n’a souvent ni mainteneur durable ni feuille de route, et disparaît dès que l’engouement retombe. Installer un tel logiciel sur son NAS, c’est parier sa stabilité sur un dépôt dont on ne connaît ni l’auteur ni l’avenir.
La controverse PhotoSuite-PhotoCraft a justement ceci d’instructif : elle montre que même la filiation — qui a copié qui — devient impossible à établir quand l’historique est fabriqué après coup. Les horodatages contradictoires ne sont pas un détail d’archive, ce sont des indices de provenance qui ne mentent pas. Quand ils ne concordent pas, c’est toute la chaîne de confiance qui se casse.
Le réflexe à adopter avant d’installer un fork
L’épisode n’appelle pas au repli sur les grands éditeurs. La communauté auto-hébergée produit chaque semaine des projets remarquables, souvent plus transparents que bien des logiciels propriétaires. Il appelle en revanche à un réflexe de vérification systématique, le même que l’on appliquerait à une dépendance logicielle critique.
Avant d’adopter un fork ou un clone : lire l’historique des commits et vérifier sa cohérence, identifier le ou les mainteneurs et leur historique, confirmer la licence et sa compatibilité avec le code source d’origine, et attendre que le projet fasse ses preuves plutôt que d’installer la première version. Ce délai n’est pas de la frilosité : dans l’auto-hébergement, la stabilité et la sécurité valent toujours mieux que la nouveauté.
La controverse PhotoSuite-PhotoCraft a au moins un mérite : elle rappelle que le label « open source » ne garantit rien à lui seul. Un dépôt public peut être un projet sincère, un dérivé bâclé ou une copie déguisée. La différence ne se lit pas dans la vitrine, elle se lit dans l’historique.
Verdict
Si vous cherchez une alternative auto-hébergée à Photopea, tenez-vous-en au projet d’origine ou à des forks dont la filiation est documentée et la licence claire, et laissez PhotoSuite et PhotoCraft faire leurs preuves avant de les installer — leur historique de commits ne permet pas, aujourd’hui, de lever le doute. Si vous maintenez un annuaire ou une liste de logiciels auto-hébergés, exigez une provenance vérifiable avant d’y référencer un projet : la confiance de vos lecteurs est votre seul capital. Et quel que soit le logiciel que vous installez chez vous, appliquez le même réflexe qu’à une dépendance critique : lire l’historique, identifier les mainteneurs, confirmer la licence, puis seulement déployer.