PromptHub : centraliser prompts, skills et agents dans une application Electron locale

Le problème concret : un même SKILL.md recopié dans dix dossiers

Un développeur qui utilise Claude Code, Cursor, Codex, Windsurf, Antigravity et Cline en parallèle ne gère pas un seul emplacement de configuration. Chaque outil attend ses fichiers à un endroit qui lui est propre, et un prompt corrigé dans l'un ne se propage pas dans les autres. La conséquence est mécanique : des copies divergentes, dont on ne sait plus laquelle est la bonne. Le README de PromptHub présente le projet comme un « 本地优先的 Prompt、Skill 与 AI 编程资产工作台 », autrement dit un espace de travail local d'abord. La cible est donc l'utilisateur individuel qui accumule des assets de codage IA sur son poste, pas l'équipe qui cherche un service central. Le projet se présente aussi comme une boîte à outils « 一站式 » couvrant prompts, skills et agents : trois objets distincts rangés dans un même endroit. Cette promesse a un corollaire que le README n'aborde pas, à savoir ce qui se passe quand les trois catégories ne sont pas synchronisées au même rythme.

Architecture : Electron, React, SQLite, et un stockage qui reste sur votre disque

La pile est lisible dans les badges du README : TypeScript, Electron, React, TailwindCSS et SQLite. Le choix d'Electron explique la distribution en application de bureau pour macOS, Windows et Linux, et il explique aussi le poids d'installation, qu'un outil en ligne de commande n'aurait pas. SQLite implique une base locale, donc pas de serveur à interroger pour consulter un prompt. Le dépôt expose par ailleurs un répertoire docs et un README traduit en plusieurs langues, dont le français, ce qui indique une documentation structurée plutôt qu'une page unique. Le README mentionne une commande CLI et une structure de dépôt documentée, mais le contenu fourni ici s'arrête avant de détailler les sous-commandes : je ne peux donc pas décrire la syntaxe exacte de la CLI sans la reproduire de travers. Ce qui est confirmé, c'est la double nature du projet : une application graphique et une interface en ligne de commande, avec la base SQLite comme point commun probable. La distribution des skills vers Claude Code, Cursor, Codex, Windsurf, Antigravity ou Cline est décrite comme un « 一键安装 », une installation en une action. Le README ne précise pas si cette action écrit dans les fichiers de configuration de chaque outil ou passe par un répertoire intermédiaire ; c'est un point à vérifier avant de laisser l'outil toucher à une configuration existante.

Mise en route : téléchargement depuis les Releases, puis WebDAV

Le chemin d'installation décrit dans le README passe par GitHub Releases. La version stable annoncée est v0.5.9, et la section de téléchargement indique deux entrées : un lien direct vers l'asset stable de la dernière release, et la page GitHub Releases pour l'historique et les notes de version. Le README signale que le lien direct bascule vers un CDN à nom de fichier fixe une fois la synchronisation du miroir terminée, ce qui évite un 404 quand le miroir n'est pas prêt. C'est un détail d'infrastructure, mais il indique que les binaires ne sont pas servis depuis un seul endroit. Pour la synchronisation entre appareils, le mécanisme annoncé est WebDAV, avec en complément une sauvegarde de snapshot complet vers un Web auto-hébergé. Le README ne donne pas d'exemple de bloc de configuration WebDAV ni de clé de configuration précise dans l'extrait fourni, donc je ne peux pas citer d'URL ni de paramètre exact. Le dépôt documente aussi une exécution depuis les sources, sous l'intitulé « 从源码运行 », ce qui suppose Node.js et un gestionnaire de paquets, mais le README ne détaille pas les commandes dans la partie reproduite ici. Si vous voulez évaluer le projet sans installer un binaire, c'est cette section qu'il faut ouvrir en premier.

La version stable et les bêtas ne racontent pas la même histoire

Les releases récentes montrent une chronologie qui mérite attention. v0.5.9 est datée du 14 juillet 2026 et présentée comme la version stable dans le README. v0.6.0-beta.1 sort le 19 août 2026, puis v0.6.0-beta.2 le 3 septembre 2026. Le dernier push sur la branche main est daté du 5 septembre 2026, soit deux jours après la dernière bêta. Autrement dit, la branche principale est en avance sur la version que le README recommande de télécharger. Pour un utilisateur qui veut la stabilité, la ligne à suivre est v0.5.9. Pour celui qui veut les fonctions de la 0.6, il n'existe pas de version stable correspondante dans les données fournies. Ce décalage est courant dans un projet jeune, mais il a une conséquence pratique : un bug corrigé sur main peut ne pas être présent dans le binaire que vous installez. Le dépôt n'étant pas archivé, le projet est actif, ce qui est un point positif pour la maintenance, sans garantir la fréquence des futures versions stables.

WebDAV comme colonne vertébrale, et ce que cela impose

Le choix de WebDAV pour la synchronisation est un choix d'infrastructure, pas un détail. WebDAV est un protocole standard, ce qui signifie que vous pouvez pointer PromptHub vers un Nextcloud, un serveur Apache configuré pour WebDAV ou un espace auto-hébergé, sans dépendre d'un service propriétaire. Le revers est que la qualité de la synchronisation dépend entièrement du serveur en face : gestion des conflits, verrous, versions de fichiers. Le README mentionne une gestion de versions pour les prompts, mais il ne décrit pas la stratégie de résolution en cas de modification simultanée sur deux appareils. C'est la question à poser avant de s'appuyer dessus à deux. La sauvegarde vers un Web auto-hébergé est présentée comme un snapshot complet, ce qui est plus simple à raisonner qu'une synchronisation différentielle : on sait ce qui a été sauvegardé, et quand. En contrepartie, un snapshot complet prend de la place et ne permet pas de restaurer un seul prompt sans restaurer l'ensemble. Le README ne tranche pas entre les deux usages, et c'est au lecteur de décider lequel il veut.

Le test multi-modèles et l'écosystème des fournisseurs

PromptHub propose de tester un prompt sur plusieurs modèles, et le README affiche deux partenaires de services de modèles, APIMart et Infistar, avec des liens d'affiliation et des offres de crédits. Cette partie du README est un emplacement sponsorisé, pas une documentation technique. Elle indique en revanche que la configuration passe par des « Provider » et des modèles compatibles avec l'interface standard OpenAI, ce qui laisse penser qu'un point de terminaison compatible suffit pour brancher un fournisseur. Le README ne publie pas de tableau de latence, de coût par appel ni de résultat de comparaison entre modèles, et je n'en avancerai aucun. La fonction de test sert donc à comparer des sorties, pas à produire des métriques de performance. Si votre besoin est de mesurer la qualité d'un prompt à grande échelle avec des statistiques, ce n'est pas ce que le dépôt décrit.

Alternatives : un dépôt Git de fichiers Markdown

L'alternative la plus directe est un dépôt Git contenant vos prompts et vos fichiers SKILL.md, avec des liens symboliques vers les répertoires attendus par chaque outil. La différence d'approche est nette. Git gère les versions, les branches et les conflits depuis des décennies, et vous gardez le contrôle total du format. PromptHub apporte une interface graphique, une base SQLite et une distribution en une action vers une dizaine d'outils, ce qu'un script de liens symboliques ne fait pas sans travail. En échange, vous dépendez d'un format interne stocké dans SQLite, et l'export vers du texte brut n'est pas décrit dans le README. Autre différence : Git suppose une certaine discipline et ne convient pas à quelqu'un qui veut cliquer plutôt que commiter. PromptHub vise précisément ce profil. Pour un utilisateur à l'aise avec la ligne de commande et qui veut que ses assets restent des fichiers lisibles, Git reste plus simple à auditer. Pour celui qui jongle entre six éditeurs et veut installer un skill sans chercher le bon dossier, PromptHub résout un problème réel.

Licence AGPL-3.0 et coût de maintenance

Le projet est publié sous AGPL-3.0. Concrètement, si vous modifiez PromptHub et que vous l'exposez en réseau à des utilisateurs, l'AGPL impose de mettre à disposition le code source correspondant. Pour un usage personnel sur votre poste, la question ne se pose pas de la même façon. Pour une entreprise qui voudrait intégrer le code dans un service interne accessible à ses salariés, il faut lire le texte de la licence et, le cas échéant, demander un avis juridique : je ne donne ici aucune interprétation qui vaudrait conseil. Sur la maintenance, le dépôt n'est pas archivé et la branche main a reçu un push en septembre 2026, ce qui indique une activité. Le coût réel pour l'utilisateur tient à trois choses : suivre l'écart entre v0.5.9 et les bêtas 0.6, maintenir un serveur WebDAV ou un Web auto-hébergé si vous voulez la synchronisation, et accepter qu'une application Electron se mette à jour indépendamment de vos outils de codage. Aucun de ces points n'est rédhibitoire, mais aucun n'est gratuit non plus.

Conclusion éditoriale

PromptHub convient à un développeur qui travaille déjà avec plusieurs assistants de codage et veut une source unique pour ses prompts et ses fichiers SKILL.md, sur sa propre machine. Il ne convient pas à une équipe qui a besoin d'un registre partagé avec contrôle d'accès : le dépôt décrit une synchronisation WebDAV et une sauvegarde vers un Web auto-hébergé, pas une gestion multi-utilisateurs. Avant d'adopter, vérifiez deux points précis : la licence AGPL-3.0 si vous comptez exposer une version modifiée en réseau, et l'écart entre la version stable v0.5.9 et les versions v0.6.0-beta publiées en septembre 2026.

Sources officielles

1. legeling/PromptHub on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases