Article mis à jour
Kimi Claw et OpenClaw : distinguer service hébergé et installation personnelle
Kimi Claw et une installation OpenClaw personnelle répondent à une question commune : où l’agent fonctionne-t-il, avec quels outils et sous quel contrôle ? Les noms se ressemblent, mais le choix change la façon de gérer l’hébergement, les accès et les coûts.
Mise à jour du 14 septembre 2026. Cette brève, publiée le 2 mars 2026, évoquait Kimi et OpenClaw de manière trop imprécise. Je l’ai recentrée sur leurs modes de déploiement. Les informations ci-dessous proviennent des documentations des éditeurs ; ce n’est pas un test personnel de Kimi Claw.
Kimi Claw : un OpenClaw hébergé par Kimi
Kimi présente Kimi Claw comme un service permettant de déployer OpenClaw dans son environnement cloud et de l’utiliser depuis le navigateur. L’éditeur annonce notamment des tâches planifiées, de la mémoire et l’accès à des skills. Il s’agit de fonctions annoncées, pas de résultats dont cet article aurait mesuré la fiabilité. Présentation officielle de Kimi Claw.
L’intérêt de cette formule est d’éviter de gérer soi-même toute l’installation de l’agent. Cela ne supprime pas les décisions sur les données confiées, les services connectés et les opérations autorisées.
L’accès au déploiement hébergé dépend de l’offre Kimi. Il faut vérifier les fonctionnalités et quotas du compte concerné ; l’absence de serveur à louer séparément ne signifie pas que le service est gratuit ou toujours moins cher. Offres et conditions d’accès Kimi.
OpenClaw administré soi-même : plus de configuration à maîtriser
Dans une installation personnelle, l’agent fonctionne sur la machine ou le serveur que l’on administre. Il faut configurer le modèle, les outils, les connexions et les restrictions adaptées au projet. Une machine locale doit rester disponible pour que les tâches qui s’y exécutent puissent continuer.
Ce mode permet de choisir son environnement, mais demande aussi de suivre les mises à jour et de contrôler les accès. Et « installé en local » ne signifie pas « toutes les données restent en local » : si le modèle ou un outil utilise un service distant, les données nécessaires à son appel peuvent quitter la machine. La documentation d’OpenClaw décrit les limites de confiance de ce type d’installation.
| Point à examiner | Kimi Claw hébergé | OpenClaw administré soi-même |
|---|---|---|
| Environnement | Déploiement dans l’offre Kimi. | Machine ou serveur choisi et administré par l’utilisateur. |
| Configuration | Parcours et fonctions disponibles dans le service. | Configuration de l’installation, des fournisseurs et des outils. |
| Disponibilité | Dépend du service et du compte. | Dépend notamment de l’hôte et des services connectés. |
| Coût | Offre, quotas et conditions Kimi à vérifier. | Hébergement éventuel, appels aux modèles et autres services utilisés. |
| Accès et données | Connexions accordées au service à examiner. | Droits locaux, réseau et services distants à maîtriser. |
Cette comparaison décrit l’organisation des deux options. Elle ne constitue ni un benchmark ni une garantie de sécurité de l’une par rapport à l’autre.
Kimi Claw, API Moonshot et Kimi Coding : trois notions à séparer
Utiliser un modèle Kimi depuis OpenClaw ne revient pas automatiquement à utiliser le service hébergé Kimi Claw.
La documentation OpenClaw distingue l’API Moonshot et Kimi Coding. Ces intégrations utilisent des préfixes de fournisseur et des clés différents ; leurs points d’accès ne sont pas interchangeables. Il faut suivre le parcours correspondant au service réellement souscrit, sans supposer qu’un abonnement ou une clé donne accès à toutes les offres. Intégrations Moonshot et Kimi Coding dans OpenClaw.
Cette distinction évite une confusion dans les guides trop rapides : confondre le logiciel qui organise l’agent, le modèle qui produit ses réponses et le service qui héberge l’ensemble.
Un premier usage possible : préparer une veille WordPress
Voici un scénario à évaluer, pas une automatisation que j’aurais testée avec Kimi Claw : demander à l’agent de préparer une synthèse à partir de quelques documentations officielles WordPress, avec les liens, les dates et les points incertains.
Le résultat attendu serait un document à relire. Avant de passer à une publication ou à une action sur un site, il faudrait vérifier les sources citées, l’exactitude des versions et les permissions nécessaires. Pour un premier essai, des pages publiques suffisent ; aucun identifiant d’administration WordPress n’est nécessaire à la préparation de cette synthèse.
C’est à cette échelle que la comparaison devient utile : la tâche aboutit-elle, les sources sont-elles vérifiables, les erreurs sont-elles visibles et le coût est-il compréhensible ?
Le choix dépend du travail à réaliser
Un service hébergé peut convenir à une tâche dont les outils et les conditions sont bien couverts par l’offre. Une installation administrée soi-même demande davantage de configuration, mais permet d’organiser l’environnement autour d’un projet précis.
Mon intérêt pour OpenClaw s’inscrit dans cette seconde démarche, décrite dans mon retour sur la construction d’un agent WordPress personnel. Ce retour reste distinct de la présente note documentaire sur Kimi Claw.
Pour choisir, je regarderais d’abord le périmètre de la tâche et les accès qu’elle exige. La facilité de lancement compte ; la capacité à comprendre et contrôler ce qui se passe ensuite compte tout autant.