Cherry Studio : un client de bureau IA open source multiplateforme fondé sur les adaptateurs multi-fournisseurs, l'inférence locale et les outils MCP
Cherry Studio est un client de bureau IA open source et multiplateforme de CherryHQ, pour Windows, macOS et Linux. Une seule interface relie les modèles cloud d'OpenAI, Gemini et Anthropic à des moteurs locaux comme Ollama et LM Studio. Il propose plus de 300 assistants prédéfinis, le dialogue parallèle avec plusieurs modèles, le traitement de documents, le rendu Mermaid et la prise en charge des outils MCP. Ce rapport étudie l'architecture des adaptateurs, l'intérêt de l'inférence hybride, les compromis de coût et la feuille de route, avec les fonctions pas encore livrées et les défis de maintenance.
Ce qu'est Cherry Studio
Cherry Studio est un client de bureau open source développé par CherryHQ. Il fonctionne sous Windows, macOS et Linux. Son idée centrale est simple : l'utilisateur ne doit pas rester enfermé chez un seul fournisseur de modèles. Dans une même fenêtre, on peut connecter des services cloud comme OpenAI, Gemini et Anthropic. On peut aussi utiliser des moteurs locaux comme Ollama et LM Studio. Des services d'IA accessibles par le web, comme Claude, Perplexity et Poe, rejoignent le même espace de travail. Le README annonce plus de 300 assistants préconfigurés, la création d'assistants personnalisés et des conversations simultanées avec plusieurs modèles.
Sur le plan technique, le projet s'attaque à la fragmentation des modèles. Les API se ressemblent en surface. En profondeur, elles diffèrent par l'authentification, le protocole de streaming, le nom des paramètres et le format des entrées multimodales. Un bon client place une abstraction de session commune au-dessus de ces différences. L'utilisateur se demande alors « quel modèle choisir ? » et plus jamais « comment l'appeler ? ».
Architecture et principes de fonctionnement
Le dépôt contient une application de bureau multiplateforme. Les notes de développement se trouvent dans docs/contrib. Le README insiste sur le fait que l'outil est prêt à l'emploi, sans configuration d'environnement. Cela indique que l'environnement d'exécution est livré avec le paquet. L'utilisateur n'a pas besoin d'installer Python ni Node. C'est l'avantage principal d'un client de bureau face à un panneau web auto-hébergé.
On peut diviser les fonctions en cinq sous-systèmes :
1. **Couche d'adaptation des fournisseurs.** Chaque fournisseur a son adaptateur. Celui-ci convertit une structure de message commune en requête propre au fournisseur, puis retransforme la réponse en flux d'événements communs. Ajouter un fournisseur revient surtout à écrire un nouvel adaptateur.
2. **Couche des assistants et des conversations.** Un assistant est un préréglage : un prompt système, un modèle par défaut et des paramètres. Les conversations s'organisent en sujets, avec gestion des sujets, tri par glisser-déposer et recherche globale. Pour le dialogue multi-modèles, une même entrée est envoyée en parallèle à plusieurs adaptateurs. Les réponses s'affichent côte à côte, ce qui permet de comparer tout de suite.
3. **Couche des documents et des données.** L'application accepte le texte, les images, les fichiers Office, les PDF et d'autres formats. Elle ajoute la gestion de fichiers et la sauvegarde par WebDAV. En sortie, elle propose un rendu Markdown complet, la coloration syntaxique du code et la visualisation de graphiques Mermaid.
4. **Couche des outils et des protocoles.** Le client prend en charge MCP, le Model Context Protocol. Un modèle peut ainsi appeler des outils et des sources de données externes. On trouve aussi la traduction par IA et la prise en charge des mini-programmes.
5. **Couche d'expérience et de thèmes.** Thèmes clair et sombre, fenêtre transparente, galerie cherrycss.com et thèmes communautaires comme Aero et PaperMaterial.
Points techniques marquants
MCP dans un produit réel. MCP est l'un des protocoles ouverts les plus importants de l'écosystème d'appel d'outils. Un client compatible permet d'utiliser le même jeu de serveurs d'outils avec des modèles différents. Il n'est pas nécessaire de réécrire un plugin pour chaque modèle. La feuille de route mentionne une « place de marché MCP », ce qui montre la volonté de rendre les outils faciles à trouver et à installer.
Local et cloud ensemble. Avec Ollama et LM Studio, les données sensibles peuvent rester sur la machine. Pour les tâches qui demandent plus de qualité, on passe à un modèle cloud. Ce mélange convient aux particuliers et aux petites équipes attentifs à la confidentialité.
Comparaison directe des modèles. Envoyer une question à plusieurs modèles est le moyen le plus direct de voir leurs différences. On apprend plus sur ses propres tâches qu'avec un classement public.
Performance, coût et compromis
Le README ne publie aucun résultat de benchmark, et ce rapport n'en invente pas. On peut tout de même discuter des compromis structurels. Le client ajoute peu de latence : elle vient du rendu de l'interface et des allers-retours réseau.
La vitesse d'inférence et le prix dépendent entièrement du modèle choisi. L'utilisateur apporte ses propres clés d'API et paie directement le fournisseur. Il n'y a pas de marge d'intermédiaire, mais il faut suivre soi-même les dépenses. Le dialogue multi-modèles multiplie la consommation de jetons, et il faut y prêter attention.
Écosystème et impact sur l'adoption
Le projet a été présenté par HelloGitHub, affiché sur Trendshift et publié sur Product Hunt. Ses canaux communautaires sont Telegram, Discord et un groupe QQ, ce qui indique un public à la fois sinophone et anglophone.
Pour les développeurs, le code est un outil prêt à l'emploi et aussi une référence : comment organiser de nombreux adaptateurs, le stockage des sessions et un protocole d'outils dans une application de bureau. Pour les entreprises, le README affiche un badge de licence commerciale, de sorte que les équipes soumises à des exigences de conformité peuvent étudier une option commerciale.
Limites et défis
Premièrement, la surface fonctionnelle est large, donc la maintenance est coûteuse. Chaque changement d'API chez un fournisseur exige une mise à jour de l'adaptateur. Deuxièmement, une application de bureau dépend de la machine de l'utilisateur pour les mises à jour, la sécurité et le stockage des clés.
Les clés d'API restent sur le disque local, et c'est à l'utilisateur de les protéger. Troisièmement, plusieurs éléments de la feuille de route ne sont que des plans : Deep Research, le système de plugins, la reconnaissance vocale et les applications mobiles. Il ne faut pas les compter comme des fonctions livrées. Quatrièmement, la qualité des plus de 300 assistants est inégale, et un prompt prédéfini peut ne pas convenir à une tâche donnée : il faut le tester.
Évolution à venir
La feuille de route cite : assistant de sélection, Deep Research, prétraitement des documents, place de marché MCP, notes et collections, canevas dynamique, OCR, synthèse vocale, reconnaissance vocale, système de plugins, HarmonyOS, Android, iOS et multi-fenêtres. Le système de plugins et la place de marché MCP comptent le plus.
S'ils arrivent, Cherry Studio passera d'un client de discussion à un poste de travail IA extensible. Le test à long terme sera de garder une interface simple alors que la liste des fonctions s'allonge.
Conclusion
La valeur de Cherry Studio ne tient pas à un algorithme nouveau.
Elle tient à l'intégration de l'accès multi-modèles, de l'inférence locale, du traitement de documents et des outils MCP dans un produit de bureau utilisable tout de suite. Pour les particuliers et les équipes qui veulent échapper à un fournisseur unique sans construire une plateforme complexe, il mérite un examen attentif.