AingDesk : une interface Electron pour modèles locaux et API distantes

Le problème visé : éviter d'écrire une interface autour de chaque modèle

Le README résume la promesse en une phrase : un logiciel d'assistant IA qui prend en charge les modèles locaux, les API et la mise en place d'une base de connaissances. Le public visé est nommé explicitement dans les points forts du produit : les débutants en IA. Concrètement, AingDesk s'adresse à quelqu'un qui a installé Ollama ou qui possède une clé d'API, et qui ne veut pas construire lui-même une interface de conversation, un chargeur de documents et un sélecteur de modèle. Le dépôt liste aussi les thèmes deepseek, ollama et localai, ce qui situe le projet dans l'écosystème des modèles exécutés en local plutôt que dans celui des plateformes d'inférence managées. La fonction de partage en ligne et le client MCP élargissent la cible au-delà de l'usage individuel, mais le README ne détaille ni le mécanisme de partage ni la portée des permissions accordées aux outils MCP.

Electron côté poste, Node côté serveur : deux formes pour un même dépôt

Le dépôt est en TypeScript et le thème electron figure dans les topics. La section d'installation confirme cette double nature : une version client pour macOS et Windows, distribuée par téléchargement, et une version serveur lancée dans un conteneur. Le README ne décrit pas l'architecture interne, donc tout ce qu'on peut affirmer sur le flux de données doit rester prudent. Ce qui est visible, c'est la séparation des volumes Docker : data, uploads, logs, bin et sys_data. Cette nomenclature indique au minimum que les conversations ou la configuration vivent dans data, que les fichiers importés dans une base de connaissances atterrissent dans uploads, et que bin contient des exécutables, ce qui correspond à l'idée de déploiement de modèles locaux en un clic annoncée dans les fonctionnalités. La frontière exacte entre ces répertoires n'est pas documentée dans le matériel fourni. C'est une lacune réelle pour quiconque prévoit une sauvegarde ou une migration.

Installation : deux commandes Docker et un build en deux étapes

La version serveur se lance avec une commande Docker unique qui monte cinq volumes et expose le port 7071 : docker run -d --name node -v $(pwd)/data:/data -v $(pwd)/uploads:/uploads -v $(pwd)/logs:/logs -v $(pwd)/bin:/aingdesk/bin -v $(pwd)/sys_data:/sys_data -p 7071:7071 -w /aingdesk aingdesk/aingdesk. Le README propose aussi une variante Compose : créer un dossier, récupérer docker-compose.yml depuis l'hébergement CNB, puis lancer docker compose up -d ou docker-compose up -d. Pour compiler depuis les sources, la procédure est en deux temps : cloner le dépôt, puis exécuter yarn dans frontend, revenir à la racine, exécuter yarn de nouveau, et enfin yarn dev. Une note concerne spécifiquement macOS : il faut retirer la dépendance @rollup/rollup-win32-x64-msvc de package.json avant de construire. Cette instruction signale une dépendance de plateforme mal isolée dans le manifeste, ce qui est un détail d'empaquetage à corriger plutôt qu'un choix délibéré.

Base de connaissances, MCP et recherche web : ce que le README ne tranche pas

Les fonctionnalités annoncées incluent une base de connaissances locale, la création d'agents intelligents, la recherche web et un client MCP. Les captures d'écran sont référencées dans le dépôt mais aucune spécification n'accompagne ces listes. On ignore quel format d'indexation est utilisé, si les embeddings sont calculés localement ou délégués à une API, et comment le client MCP découvre les serveurs. La conversation simultanée avec plusieurs modèles est marquée comme à venir, donc absente. Le partage en ligne soulève une question que le README laisse ouverte : qui héberge la conversation partagée, et selon quelles règles d'accès. Pour un projet qui se présente comme adapté aux débutants, l'absence de documentation sur le stockage des clés d'API dans la version serveur est le point le plus gênant. Rien dans le matériel fourni ne permet de dire si ces clés sont chiffrées au repos dans le volume data.

Le rythme des versions comme signal de maturité

Les trois dernières versions publiées sont v1.2.2 le 16 avril 2025, v1.2.3 le 18 avril 2025, puis v1.2.4 le 27 mai 2025. Deux publications à deux jours d'intervalle, suivies de plus d'un mois de silence, dessinent un rythme irrégulier. Le README précise d'ailleurs que le projet grandit vite, ce qui est cohérent avec cette cadence mais implique aussi que les interfaces et les formats de stockage peuvent changer entre deux versions mineures. Un déploiement en production avec des données utilisateurs dans le volume data doit donc prévoir une procédure de sauvegarde avant chaque mise à jour, parce que rien n'indique qu'une migration automatique du schéma soit fournie. La licence MIT lève les restrictions d'usage et de redistribution, y compris pour un déploiement commercial interne. Elle n'impose aucune obligation de publication des modifications, et elle n'offre évidemment aucune garantie. Pour un usage en entreprise, la question du support reste entière : le projet est sponsorisé pour son infrastructure CDN par Tencent EdgeOne, mais aucun contrat de support n'est mentionné.

Ce qui distingue AingDesk d'une interface comme Open WebUI

L'alternative la plus directe dans le même espace est Open WebUI, une interface web auto-hébergée pour modèles locaux et API compatibles OpenAI. La différence d'approche tient au point d'entrée : Open WebUI se déploie comme un service web auquel on accède par navigateur, tandis qu'AingDesk propose en priorité une application de bureau Electron, avec une version serveur en complément. Cela change la donne pour l'accès aux fichiers locaux, puisque l'application de bureau peut lire le disque de l'utilisateur sans configuration de volume, alors qu'un service web doit recevoir les documents par téléversement. En contrepartie, Open WebUI bénéficie d'une documentation publique plus fournie et d'un écosystème de déploiements documentés. AingDesk mise sur l'intégration d'un client MCP et sur le partage en ligne, deux éléments que le README ne détaille pas assez pour qu'on puisse les comparer sérieusement. Le choix se joue donc sur la forme de distribution, pas sur des capacités vérifiables dans le matériel fourni.

Pour qui, et quoi vérifier avant de s'engager

Adoptez AingDesk si vous voulez une application de bureau qui parle à Ollama ou à une API distante, avec une base de connaissances locale et une licence MIT permissive, et si vous acceptez de lire le code pour comprendre le stockage. Écartez-le si vous avez besoin d'une architecture documentée, d'un support éditeur ou d'une garantie de compatibilité entre versions. Avant tout déploiement serveur, inspectez le contenu des volumes /data et /sys_data après une première conversation, pour savoir ce qui est persisté et sous quelle forme. Vérifiez aussi que le fichier docker-compose.yml récupéré depuis cnb.cool correspond bien à la version que vous ciblez, puisque le README pointe vers une branche server distincte de main. Enfin, si vous construisez depuis les sources sur macOS, confirmez la suppression de @rollup/rollup-win32-x64-msvc dans package.json avant de lancer yarn, sans quoi la compilation échouera dès la première étape.

Conclusion éditoriale

AingDesk convient aux développeurs qui veulent une interface de bureau pour brancher Ollama, une API distante et une base de connaissances locale sans écrire d'interface. Il ne convient pas aux équipes qui ont besoin d'une architecture documentée, d'un versionnage sémantique clair ou d'un support commercial. Avant d'adopter, vérifiez ce que contiennent réellement les volumes /data, /uploads et /sys_data, et lisez le code de la version serveur publiée sur la branche server plutôt que de vous fier au README.

Sources officielles

1. aingdesk/AingDesk on GitHub
2. License: MIT
3. Project website
4. README
5. Releases