Sidekick : un agent local macOS bâti sur llama.cpp, encore en release candidate

Le problème concret : un LLM local qui voit vos fichiers sans rien installer d'autre

La plupart des interfaces de chat avec un modèle local vous demandent de monter une pile : un serveur d'inférence, un moteur d'indexation, un connecteur vers le système de fichiers, puis un client. Sidekick part d'un constat inverse. Le README annonce une application macOS native qui contient son propre moteur d'inférence et se passe de toute installation supplémentaire. Le public visé est identifiable : un étudiant qui prépare un devoir d'histoire, un développeur qui veut interroger sa documentation hors ligne, un utilisateur qui refuse d'envoyer ses documents à un service distant. Le README illustre ce cas avec un exemple d'histoire sur les Aztèques et les troupes espagnoles, où l'utilisateur demande si les Aztèques ont utilisé des armes espagnoles capturées et reçoit des citations avec numéros de page. Le projet se positionne comme local first, ce qui signifie que le chemin par défaut ne fait sortir aucune donnée de la machine. C'est l'argument central, et il tient à une contrainte technique : le moteur llama.cpp est embarqué dans le binaire plutôt que délégué à un service externe.

Comment l'application relie un modèle GGUF à vos dossiers : les experts comme unité de contexte

Sidekick organise les sources autour d'une notion appelée expert. Un expert est un ensemble configurable de fichiers, dossiers et sites web rattachés à un domaine. Activer un expert autorise l'application à récupérer et citer les documents qu'il contient. Le README donne l'exemple d'un étudiant qui crée cinq experts (English Literature, Mathematics, Geography, Computer Science, Physics) et active celui de Computer Science pour une question donnée. Le mécanisme sous-jacent est du RAG : plutôt que de tout injecter dans la fenêtre de contexte, l'application récupère les passages pertinents au moment de la requête. C'est ce qui permet, selon le README, de mettre un nombre théoriquement illimité de ressources dans un expert sans saturer le modèle. Il existe aussi un chemin plus léger : glisser un fichier directement dans le champ de saisie pour l'utiliser comme ressource temporaire, sans passer par un expert. Cette séparation entre contexte permanent (les experts) et contexte ponctuel (le glisser-déposer) est le vrai choix d'architecture visible dans la documentation. Elle a un coût : chaque expert doit être configuré, et rien n'indique dans le matériel fourni comment l'indexation se comporte quand un dossier change après coup.

Function calling, Deep Research et mémoire : trois couches d'agent au-dessus du chat

Le chat simple n'est qu'une partie du produit. Le README décrit un système de function calling où les fonctions sont appelées séquentiellement en boucle jusqu'à obtention d'un résultat. L'exemple cité porte sur le calcul de métriques financières pour Nvidia au troisième trimestre 2025, avec 27 appels d'outils, l'enregistrement d'un fichier CSV et la présentation des résultats. Un second exemple montre la rédaction d'un brouillon d'e-mail d'invitation, où l'application va chercher la date d'anniversaire dans le carnet de contacts et l'adresse du destinataire avant de créer le brouillon dans le client de messagerie par défaut. Deep Research est présenté comme un agent distinct, conçu pour des tâches longues et multi-étapes, qui lit entre 50 et 80 pages web avant de synthétiser un rapport. La mémoire, enfin, conserve des informations entre les conversations. Le README donne l'exemple d'un utilisateur qui se déclare débutant en Python et construit sa version de Tetris, information réutilisée plus tard quand il demande des alternatives à pygame. Ces trois couches partagent un point commun : elles augmentent le nombre d'appels au modèle, donc le temps de réponse. Sur un modèle local de taille moyenne, la boucle d'appels d'outils peut devenir longue.

Mise en route : ce que la documentation permet réellement de reconstituer

Le matériel fourni ne contient pas de procédure d'installation détaillée. Le README renvoie vers une page de documentation externe pour les fonctionnalités et leur usage, et les releases publiées portent des étiquettes comme 1.0.0-rc.18. On peut donc raisonner sur ce qui est confirmé : l'application est native macOS, le moteur d'inférence est llama.cpp, les modèles attendus sont au format GGUF, et le README cite Qwen3.5 comme exemple de modèle supporté nativement. Pour le volet distant, Sidekick propose des presets pour OpenAI, Anthropic, Google AI Studio, DeepSeek, Groq, MiniMax, Mistral et xAI. La marche à suivre annoncée est simple : sélectionner un fournisseur, saisir une clé API. Aucune clé de configuration, aucun chemin de fichier ni aucun nom de variable d'environnement n'apparaît dans le matériel transmis. Toute description plus précise de la configuration relèverait de l'invention. Le lecteur qui veut des commandes exactes doit consulter la page du projet, pas cet article.

Ce que le projet ne dit pas : release candidate, périmètre macOS et opacité de l'indexation

Trois limites ressortent du matériel disponible, et elles sont de nature différente. La première est le statut. La dernière version publiée est une release candidate, la dix-huitième du cycle 1.0.0. Une rc signifie par définition que l'API et le comportement peuvent encore bouger. Le dernier push sur le dépôt date de mai 2026, ce qui indique une activité, mais aussi un projet qui n'a pas encore figé sa première version stable. La deuxième limite est le périmètre : c'est une application macOS native, écrite en Swift et SwiftUI. Sur Linux ou Windows, elle n'est pas une option, et il n'existe pas de version serveur décrite dans le matériel. La troisième concerne le RAG lui-même. Le README affirme qu'on peut mettre un nombre théoriquement illimité de ressources dans un expert et que l'application trouvera l'information pertinente. Cette affirmation n'est accompagnée d'aucun détail sur la stratégie de découpage, le modèle d'embedding utilisé ou la façon dont les scores de pertinence sont calculés. Pour un usage personnel, cela peut suffire. Pour un usage où la traçabilité de la récupération compte, c'est un point aveugle. Un dernier point mérite attention : la génération d'images. Le README explique qu'il n'y a ni bouton ni mode dédié, qu'un modèle CoreML intégré détecte automatiquement les prompts de génération d'image. Une détection automatique de l'intention est pratique, mais elle implique qu'une requête ambiguë peut déclencher une génération non souhaitée.

Face à quoi : Ollama plus une interface, ou une pile RAG assemblée à la main

L'alternative la plus directe n'est pas un autre agent intégré, c'est une combinaison. Ollama expose un serveur local qui charge des modèles GGUF et répond sur une API HTTP ; on y branche ensuite une interface de chat, et l'on ajoute soi-même un moteur de récupération pour interroger des fichiers. La différence d'approche est nette. Sidekick livre l'inférence, l'indexation, les experts, le function calling et la mémoire dans un seul binaire macOS, avec une interface graphique. La pile Ollama vous laisse choisir chaque composant et inspecter chaque étape, au prix de l'assemblage. Autrement dit : Sidekick optimise le temps de mise en route, la pile assemblée optimise le contrôle. Il existe une troisième voie, celle d'un client de chat graphique connecté à une API distante, mais elle abandonne précisément ce que Sidekick met en avant, à savoir le traitement local des documents. Le choix se joue donc sur une question simple : acceptez-vous de déléguer les décisions de découpage et de récupération à une application dont la documentation ne détaille pas ces mécanismes.

Coût de maintenance et implications de la licence MIT

Le coût de maintenance dépend de deux facteurs que le matériel permet d'identifier. D'abord le rythme des versions : trois release candidates publiées entre novembre 2025 et avril 2026, avec des écarts de plusieurs semaines. Suivre le projet implique de mettre à jour régulièrement, et une rc peut introduire des changements de comportement entre deux versions. Ensuite le modèle lui-même : llama.cpp évolue, les formats GGUF évoluent, et une application qui embarque ce moteur doit suivre. La licence est MIT, ce qui est permissif : usage commercial, modification et redistribution sont autorisés, avec conservation du texte de licence et de l'avis de copyright. Cela dit, la licence couvre le code de Sidekick, pas les modèles que vous chargez. Un modèle GGUF conserve sa propre licence, qui peut restreindre l'usage commercial indépendamment de la licence du logiciel hôte. Ce point est sans rapport avec le droit d'auteur de Sidekick et mérite une vérification séparée pour chaque modèle. Rien dans le matériel fourni n'indique de politique de support, de canal de discussion ou d'engagement de compatibilité.

Conclusion éditoriale

Sidekick convient à ceux qui travaillent déjà sur macOS, veulent un chat LLM hors ligne adossé à des dossiers locaux, et acceptent de suivre une release candidate. Ceux qui ont besoin d'une version stable, d'un support Linux ou Windows, ou d'une chaîne RAG auditable ligne par ligne doivent passer leur chemin. Avant d'adopter, vérifier trois choses concrètes : le format GGUF du modèle que vous voulez charger, le comportement de l'indexation quand vous ajoutez un dossier volumineux à un expert, et la façon dont l'application gère vos clés API si vous activez un fournisseur distant.

Sources officielles

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