OpenClaw est une passerelle multicanal auto-hébergée pour les agents d’IA. Vous exécutez un processus Gateway qui devient le plan de contrôle des sessions, des plugins de canaux et des outils. Vous pouvez lui écrire depuis Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo et d’autres plugins de canaux, puis recevoir les réponses de l’agent sans confier votre quotidien à un chatbot SaaS hébergé.
Documentation : docs.openclaw.ai. Site : openclaw.ai. Licence : MIT ; développement ouvert avec l’OpenClaw Foundation, une organisation à but non lucratif.
Cet article met en service une passerelle personnelle. Les articles suivants couvrent les listes d’autorisation et l’appairage, puis les skills, le heartbeat et les approbations. Pour savoir quand choisir OpenClaw ou Hermes, consultez le choix selon la tâche.
Une passerelle fraîchement installée avec des outils activés est puissante. Les capacités liées au shell, aux fichiers et au navigateur permettent à une personne qui peut envoyer un message au bot de tenter de provoquer des actions dangereuses. Terminez l’installation, puis appliquez les listes d’autorisation et l’appairage avant de connecter un canal accessible au public ou d’activer des outils élevés. Consultez le guide de sécurité d’OpenClaw.
Comprendre la Gateway (modèle mental)
Applications de messagerie + plugins → Gateway → session de l’agent / outils
↘ Control UI (navigateur)
↘ CLI
La Gateway est la source de vérité unique pour les sessions, le routage et les connexions aux canaux. Le Control UI dans le navigateur sert à discuter, à configurer la passerelle et à examiner les sessions. La configuration se trouve par défaut dans ~/.openclaw/openclaw.json.
OpenClaw ne constitue pas une frontière de sécurité multilocataire pour des utilisateurs mutuellement hostiles partageant le même agent. Le modèle de confiance documenté définit une frontière d’opérateur de confiance par passerelle. Hébergez les différentes frontières de confiance dans des passerelles distinctes, idéalement sous des comptes de système d’exploitation ou sur des hôtes distincts.
Versions de Node requises
La documentation actuelle d’installation de Node exige Node 22.22.3+, 24.15+ ou 25.9+, ce qui inclut Node 26. Node 26 est l’environnement d’exécution documenté comme recommandé et utilisé par défaut ; Node 23 n’est pas pris en charge. Les versions minimales évoluent. Vérifiez à nouveau Getting Started et la page Node le jour de l’installation au lieu de recopier un ancien instantané.
Installer et effectuer la configuration initiale
Suivez le parcours actuel de Getting Started :
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
onboard --install-daemon lance une configuration guidée et installe la Gateway comme daemon afin qu’elle survive à la déconnexion ou au redémarrage, selon le modèle de service de votre plateforme.
Vous aurez besoin d’une clé API, ou de la configuration d’un modèle local, pour le fournisseur choisi. Préférez un modèle puissant de dernière génération pour tout bot qui utilisera des outils. Les modèles plus faibles sont plus faciles à manipuler par ingénierie sociale afin de provoquer un usage dangereux des outils, comme l’indique le guide de sécurité.
Après la configuration initiale, exécutez
openclaw security audit, puis--deeplorsque vous êtes prêt à effectuer un test actif. Corrigez les constats relatifs aux accès entrants et à l’exposition réseau avant de considérer l’installation comme prête pour un usage personnel réel.
Ouvrir le Control UI
Tableau de bord local par défaut :
Ou :
openclaw dashboard
Utilisez l’interface pour envoyer un premier message, examiner les sessions et confirmer que la Gateway fonctionne. Gardez le Control UI sur l’interface de bouclage, sauf si vous avez volontairement configuré un accès distant authentifié. Tailscale et les approches apparentées sont documentés dans le guide d’accès distant d’OpenClaw. N’exposez pas :18789 au WAN sans authentification.
La configuration de base renforcée proposée dans la documentation de sécurité comprend gateway.mode: "local", bind: "loopback" et une authentification par jeton de la passerelle. Commencez avec une configuration fermée et n’ouvrez que ce qui est nécessaire.
Emplacement et sauvegarde de la configuration
Configuration par défaut : ~/.openclaw/openclaw.json. Les identifiants et l’état de l’appairage se trouvent également sous ~/.openclaw/. Avant toute expérimentation :
- Copiez le fichier de configuration dans une sauvegarde datée, hors du dossier synchronisé que vous partagez avec une équipe.
- Notez votre version de Node (
node -v) à côté de la sauvegarde. - Après une modification défectueuse de l’accès distant, restaurez la sauvegarde et redémarrez le daemon au lieu de déboguer l’installation active alors que les canaux restent ouverts.
Ne versionnez jamais de vrais jetons dans git. Si plusieurs opérateurs doivent connaître la structure, conservez un exemple de configuration caviardé dans votre guide d’exploitation.
Problèmes d’installation courants
| Symptôme | Cause probable |
|---|---|
openclaw introuvable | Le dossier global des binaires npm n’est pas dans PATH ; corrigez PATH ou utilisez le chemin complet |
| Échec de la configuration initiale avec Node | La version installée ne respecte pas le minimum officiel actuel ; vérifiez Getting Started et effectuez une mise à niveau |
| Tableau de bord vide ou connexion refusée | La Gateway ne fonctionne pas ; le daemon a échoué ; l’hôte ou le port est incorrect |
| Fonctionne sur l’ordinateur, mais pas dans une session SSH | Le processus n’était attaché qu’au premier plan ; relancez la configuration initiale en installant le daemon |
| Le canal se connecte, mais le bot vous ignore | L’appairage est en attente ou votre identifiant manque dans la liste d’autorisation |
| Des inconnus peuvent utiliser les outils | La politique des messages privés est ouverte ou la liste d’autorisation est trop large ; arrêtez le service et consultez l’article sur la sécurité |
En cas de doute, préférez les pages officielles Getting Started et Troubleshooting aux conseils non vérifiés des forums.
Configuration du fournisseur et du modèle
Pendant la configuration initiale, vous orienterez l’agent vers la clé API d’un fournisseur cloud ou vers une URL de base locale compatible avec OpenAI. Règles pratiques :
- Utilisez le modèle actuel le plus puissant que vous acceptez de payer ou d’héberger lorsque les outils sont activés. La documentation de sécurité d’OpenClaw recommande explicitement des modèles modernes, renforcés pour suivre les instructions, pour les bots qui utilisent des outils.
- Si vous utilisez un point de terminaison local, appliquez la même discipline de réseau privé et d’authentification que pour les points de terminaison locaux compatibles avec OpenAI depuis n8n.
- Ne placez aucune clé dans les journaux de discussion ni dans des exemples de configuration versionnés.
Vous pourrez affiner le choix du modèle plus tard. Ne retardez pas l’appairage et les listes d’autorisation pendant vos essais de modèles.
Daemon, mises à jour et diagnostic
--install-daemon est important, car une Gateway attachée à un terminal s’arrête lorsque ce terminal ou la session SSH prend fin. Le gestionnaire de services de la plateforme peut, lui, démarrer ou redémarrer la Gateway après une connexion ou un redémarrage. Un ordinateur portable en veille ne peut toujours pas traiter les messages. Suivez la procédure de mise à jour correspondant à votre méthode d’installation ; ne mélangez pas à la légère les états des gestionnaires de paquets. Après une mise à niveau, exécutez les diagnostics pris en charge :
openclaw doctor --fix # when docs recommend it for config/monitor drift
openclaw security audit
Lisez les notes de version lors d’un changement majeur de version de Node ou d’OpenClaw. Vérifiez à nouveau le port et l’authentification du Control UI après toute expérimentation sur l’accès distant.
Premier canal, sans difficulté inutile
Telegram est souvent le canal le plus rapide à connecter pour un premier test personnel. Procédez ainsi :
- Créez le jeton du bot en suivant les instructions OpenClaw actuelles pour Telegram.
- Pour un bot à propriétaire unique, préférez
dmPolicy: "allowlist"et placez explicitement votre identifiant utilisateur Telegram numérique dansallowFrom. - Le parcours
pairingpar défaut reste valable pour la configuration initiale. Si vous l’utilisez, approuvez votre propre compte avecopenclaw pairing list telegram, puisopenclaw pairing approve telegram <code>. - Interprétez l’appairage de façon restrictive : il accorde seulement l’accès aux messages privés. Si aucun propriétaire de commandes n’existe, le premier appairage approuvé peut aussi initialiser
commands.ownerAllowFrom; l’autorisation des groupes provient toujours de listes d’autorisation explicites dans la configuration. - Bloquez les groupes pendant le premier test. Lorsque vous en activez un, placez son identifiant de discussion stable sous
channels.telegram.groups, conservez les identifiants des expéditeurs dansallowFromougroupAllowFromet maintenezrequireMention: true.
Configuration Telegram initiale renforcée, qui combine les recommandations actuelles sur le canal et la politique d’exécution actuelle. Remplacez l’identifiant d’expéditeur d’exemple et gardez la documentation active ouverte :
{
channels: {
telegram: {
enabled: true,
dmPolicy: 'allowlist',
allowFrom: ['123456789'],
groupPolicy: 'allowlist',
groups: {},
},
},
session: { dmScope: 'per-channel-peer' },
gateway: {
mode: 'local',
bind: 'loopback',
auth: { mode: 'token', token: 'replace-with-a-secret-reference' },
},
tools: {
profile: 'messaging',
deny: [
'group:automation',
'group:runtime',
'group:fs',
'sessions_spawn',
'sessions_send',
],
fs: { workspaceOnly: true },
exec: { mode: 'deny' },
elevated: { enabled: false },
},
}
Les détails et les modes d’échec sont présentés dans l’article sur les listes d’autorisation et l’appairage.
Scénario de test rapide
- Ouvrez
http://127.0.0.1:18789/et envoyez-vous « ping » dans le Control UI. - Confirmez qu’une session apparaît et que le modèle répond.
- Connectez un canal de messages privés et confirmez que votre identité principale explicitement autorisée peut communiquer avec l’agent. Si vous testez volontairement l’appairage, approuvez d’abord cette identité principale.
- Envoyez un message depuis une deuxième identité que vous contrôlez. Avec
dmPolicy: "allowlist", confirmez qu’elle est bloquée ; si vous testezpairing, laissez sa demande sans approbation et confirmez qu’elle ne peut pas déclencher un tour doté d’outils. - Exécutez
openclaw security auditet corrigez tout constat signalant des outils ouverts ou une adresse d’écoute publique.
Si l’étape 4 échoue en mode ouvert, c’est-à-dire si l’expéditeur inconnu obtient un tour complet de l’agent avec des outils, arrêtez-vous et corrigez la politique de messages privés avant de poursuivre l’intégration.
Place d’OpenClaw par rapport à n8n et Hermes
| Composant | Rôle |
|---|---|
| OpenClaw | Interface de discussion et plan de contrôle de passerelle pour plusieurs applications de messagerie |
| Hermes | Environnement d’exécution d’agent avec des interfaces distinctes pour le serveur API et l’intégration webhook |
| n8n | Plomberie SaaS déterministe, validation et validations humaines |
Ces composants peuvent coexister. Une architecture d’évaluation peut confier les contrôles planifiés à n8n, le jugement à Hermes et les conversations d’astreinte à OpenClaw, avec une liste d’autorisation stricte. Hermes expose un serveur API compatible avec OpenAI et un adaptateur webhook distinct pour les événements signés. Choisissez et documentez un seul contrat au lieu de les traiter comme interchangeables.
La matrice de prise en charge des plateformes NemoClaw de NVIDIA décrit une version alpha préliminaire distincte, fondée sur OpenShell. Elle indique actuellement que les chemins OpenClaw et Hermes agent ont été testés, tandis que les lignes concernant les plateformes, l’inférence et le déploiement comportent leurs propres limites. NemoClaw n’est pas nécessaire pour cette configuration sur ordinateur portable et NVIDIA ne fournit aucun SLA de production.
Liste de contrôle de configuration personnelle
- Une version de Node prise en charge est installée
- L’installateur officiel, ou une autre méthode d’installation documentée, a réussi
-
openclaw onboard --install-daemonest terminé - Le Control UI s’ouvre sur
127.0.0.1:18789 - Les résultats de
openclaw security auditont été examinés - Le premier canal utilise une liste d’autorisation explicite pour les messages privés ou un appairage volontairement approuvé ; l’autorisation des groupes reste distincte
- Aucune liaison WAN sur la Gateway ni sur les ports de modèles
- Les clés des fournisseurs sont stockées comme secrets, pas dans l’historique de discussion
- La deuxième identité de test ne peut pas atteindre les outils avant approbation
L’historique des canaux, les pièces jointes et les sorties des outils peuvent être enregistrés dans l’état de la Gateway sous
~/.openclaw. Traitez ce dossier comme une boîte aux lettres et un magasin d’identifiants : chiffrement du disque, permissions de fichiers strictes et aucune synchronisation du dossier d’état vers un espace cloud partagé sans décision explicite.
Ce que « terminé » signifie le premier jour
Vous pouvez ouvrir le tableau de bord, mener une conversation privée avec vous-même et voir une session. La configuration n’est toutefois pas terminée tant que l’appairage ou les listes d’autorisation ne sont pas en place et que vous ne comprenez pas quels outils l’agent peut invoquer. Une installation sans vérification de sécurité reste une démonstration.
Étape suivante : verrouillez les identités et les groupes, puis ajoutez les skills et le heartbeat avec une politique restrictive pour les actions du shell et du navigateur.
