Kelivo : un client de chat LLM en Flutter qui vise six plateformes

Le problème visé : un client, plusieurs fournisseurs, plusieurs systèmes

Les interfaces officielles des fournisseurs de modèles restent cloisonnées. Une conversation commencée avec un modèle hébergé chez un fournisseur ne se transporte pas facilement vers un autre, et les clients de bureau ou mobiles disponibles couvrent rarement l'ensemble des plateformes d'un même utilisateur. Kelivo se place exactement sur ce créneau. Le README annonce le support d'OpenAI, Google Gemini et Anthropic, la création d'assistants personnalisés, et une couverture Android, iOS, Harmony, Windows, macOS et Linux. Le public visé n'est donc pas une équipe qui construit un produit, mais une personne qui veut la même application sur son téléphone et sur son ordinateur, avec ses propres clés d'API. Kelivo est distribué sur l'App Store et via les releases GitHub, avec un canal TestFlight pour les versions bêta. La version publiée la plus récente au moment de la rédaction est v1.2.6, datée du 6 septembre 2026, précédée de v1.2.5 le 31 août et de v1.2.4 le 25 août.

Ce que le dépôt laisse voir de l'architecture

Le README ne décrit pas d'architecture interne, et il faut le dire clairement : tout ce qui suit vient des fonctionnalités listées et de la nature du projet, pas d'une lecture du code. Kelivo est une application Flutter, donc un client lourd qui parle directement aux API des fournisseurs depuis l'appareil. Les clés d'API restent sur la machine, ce qui est cohérent avec l'absence de service central mentionné. Deux éléments structurent l'ensemble. D'abord le Model Context Protocol, avec un outil MCP Fetch intégré : le client agit comme hôte MCP et expose des outils au modèle. Ensuite la recherche web, branchée sur une liste longue de moteurs : Bing, DuckDuckGo, Exa, Tavily, Zhipu, LinkUp, Brave, Metaso, SearXNG, Ollama, Jina, Perplexity, Bocha, Serper et Grok. Le partage de configuration par QR code et la sauvegarde de l'historique suggèrent que l'état vit localement, sans synchronisation serveur. Le README cite aussi une génération en arrière-plan sur Android, en option.

Mise en route : ce que la documentation donne réellement

Le README n'expose aucune commande d'installation depuis les sources. Il renvoie vers l'App Store, vers la page des releases GitHub et vers TestFlight. Pour un build local, il faut donc se référer au dépôt lui-même, et je ne peux pas affirmer ici quelles commandes Flutter précises fonctionneront : je ne les ai pas exécutées et le README ne les fournit pas. La procédure de contribution, elle, est explicite : fork du dépôt, puis git checkout -b feature/AmazingFeature, git commit -m 'Add some AmazingFeature', git push origin feature/AmazingFeature, et enfin une pull request. C'est une procédure de contribution, pas une procédure d'installation, et la distinction compte. Côté configuration, les éléments confirmés sont des clés d'API de fournisseurs, des assistants personnalisés, des en-têtes et corps HTTP personnalisés pour les requêtes, des variables de prompt (nom du modèle, heure), des polices système ou Google Fonts téléchargées à la demande, et l'import ou l'export de configurations de fournisseurs par QR code. Pour Harmony, le README pointe vers un dépôt séparé, Chevey339/kelivo-ohos.

MCP et recherche web : la partie qui distingue Kelivo d'un simple client

Beaucoup de clients de chat se contentent d'envoyer des messages et d'afficher la réponse. Kelivo ajoute deux couches. Le support MCP signifie que le modèle peut appeler des outils, et le README mentionne un outil MCP Fetch fourni avec l'application. La recherche web, ensuite, est intégrée avec quinze moteurs listés, ce qui laisse supposer une abstraction commune avec un choix par configuration plutôt qu'un couplage à un seul fournisseur. Cette liste est aussi le principal point d'interrogation : le README ne dit rien sur la manière dont les résultats sont fusionnés, tronqués ou cités dans la réponse. Un utilisateur qui compte sur la recherche pour des faits vérifiables doit tester ce comportement lui-même, parce que la documentation ne le décrit pas. Le support multimodal, lui, est annoncé pour les images, les documents texte, les PDF et les fichiers Word, avec un rendu Markdown couvrant coloration syntaxique, formules LaTeX et tableaux.

Les limites que le README ne masque pas, et celles qu'il tait

La limite la plus concrète est la licence. Kelivo est publié sous AGPL-3.0. Pour un usage personnel, cela ne change rien. Pour quiconque veut intégrer le code dans un produit distribué ou exposer une version modifiée comme service réseau, l'AGPL impose des obligations de publication du code source. Un client de chat fermé construit sur cette base n'est pas une option, et je ne peux que renvoyer au fichier LICENSE pour le détail, sans donner de conseil juridique. La deuxième limite est la couverture. Harmony passe par un dépôt distinct, kelivo-ohos, ce qui veut dire deux bases à suivre pour qui vise cette plateforme. La troisième est l'absence de synchronisation : la sauvegarde et la restauration de l'historique sont annoncées, mais rien n'indique un mécanisme multi-appareils automatique. Enfin, le README est un document de présentation, pas une documentation technique. Il ne dit rien des versions minimales de systèmes, de la consommation mémoire, ni de la gestion des erreurs de fournisseurs.

Face à RikkaHub et aux clients web auto-hébergés

Le README remercie explicitement le projet RikkaHub pour l'inspiration de l'interface, et précise que le design de Kelivo s'en inspire fortement. La comparaison la plus honnête est donc celle-là : deux clients Flutter aux interfaces proches. Ce qui distingue Kelivo dans le matériel fourni, c'est l'étendue de la liste de moteurs de recherche et la présence d'un outil MCP Fetch intégré, plus une cible Harmony. Un client web auto-hébergé comme Open WebUI répond à un autre besoin : il centralise les conversations sur un serveur, ce qui permet de reprendre une discussion depuis n'importe quel navigateur, au prix d'une infrastructure à maintenir et de clés d'API stockées côté serveur. Kelivo prend le chemin inverse : pas de serveur, des clés locales, mais pas de reprise de conversation entre appareils sans passer par la sauvegarde manuelle. Le choix se fait donc sur une question simple : voulez-vous vos clés chez vous sur chaque appareil, ou sur une machine que vous administrez ?

Coût de maintenance et rythme de publication

Trois releases en trois semaines, v1.2.4 le 25 août, v1.2.5 le 31 août et v1.2.6 le 6 septembre 2026, indiquent un projet actif, avec un dernier push sur master au 9 septembre 2026. Ce rythme a un revers : suivre chaque version sur six plateformes demande du temps, surtout si vous compilez vous-même. Le dépôt n'est pas archivé, et le README ouvre les pull requests et les issues. La structure du projet, avec un dépôt séparé pour Harmony, ajoute une dépendance à surveiller. Sur le plan de la licence, AGPL-3.0 signifie que toute redistribution ou mise à disposition en réseau d'une version modifiée doit respecter les termes du fichier LICENSE ; pour un usage strictement personnel, la question ne se pose pas.

Conclusion éditoriale

Kelivo convient à un utilisateur qui veut un client de chat multi-fournisseurs sur plusieurs systèmes, avec MCP et recherche web, et qui accepte l'AGPL-3.0. Il ne convient pas à une équipe qui doit redistribuer un client fermé, ni à quelqu'un qui cherche un back-end partagé. Avant d'adopter, vérifiez le fichier LICENSE, le rythme des releases et le dépôt kelivo-ohos pour Harmony.

Sources officielles

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