Piloter OpenClaw en ligne de commande : Gateway et sessions

La messagerie est l’interface quotidienne d’OpenClaw, mais la ligne de commande reste l’outil de l’administrateur : pour diagnostiquer, scripter, envoyer un message proactif ou contrôler finement une conversation. Ce tutoriel fait le tour des commandes essentielles et des commandes intégrées (slash) qui vous rendent maître de votre agent depuis le terminal.

🎯 Ce que vous allez apprendre

• Piloter la passerelle : démarrer, vérifier l’état, arrêter.
• Interroger l’agent et envoyer un message proactif en une commande.
• Gérer le contexte d’une conversation avec les commandes intégrées.
• Régler la verbosité et tracer les échanges pour déboguer.
• Suivre la consommation de jetons et tenir l’agent à jour.

🛠️ Ce que vous allez construire

Vous allez constituer votre trousse de commandes : un petit ensemble de réflexes pour démarrer, diagnostiquer et piloter l’assistant sans dépendre de la messagerie. C’est ce qui transforme un utilisateur en administrateur de son propre agent.

Prérequis

• OpenClaw installé, un modèle configuré, la passerelle fonctionnelle.
• Un accès terminal sur la machine de l’agent.
• Niveau : débutant à intermédiaire. ⏱️ Temps estimé : ~25 minutes.

Étape 1 — Maîtriser la passerelle

Tout commence par la passerelle, le processus central qui doit tourner pour que l’agent vive. Trois commandes couvrent l’essentiel de son cycle de vie. Gardez-les en mémoire : ce sont vos premiers gestes à chaque diagnostic.

openclaw gateway          # demarrer au premier plan (logs en direct)
openclaw gateway status   # verifier qu'elle tourne
openclaw gateway stop     # arreter proprement

Le démarrage au premier plan affiche les journaux en temps réel : c’est le mode idéal pour comprendre une panne, car vous voyez exactement où le chargement échoue. En usage normal, la passerelle tourne en service système ; status est alors votre commande de contrôle, et stop sert avant une maintenance.

✅ Point d’étape — openclaw gateway status rapporte une passerelle active. Si elle ne l’est pas, lancez-la au premier plan et lisez les journaux pour identifier la cause.

Étape 2 — Interroger l’agent directement

Pour tester une réponse sans passer par la messagerie, la commande agent envoie un message et affiche la réponse dans le terminal. C’est parfait pour vérifier qu’un changement de modèle ou de compétence produit l’effet voulu, en isolant l’agent de la couche Telegram.

openclaw agent --message "Donne-moi la date et l'heure du serveur."
# Pour une analyse plus poussee, augmenter l'effort de raisonnement :
openclaw agent --message "Analyse ce log et propose une cause." --thinking high

La réponse s’affiche directement. Le drapeau --thinking high demande au modèle de réfléchir davantage : à réserver aux tâches complexes, car il consomme plus de jetons et de temps. Pour les questions simples, laissez l’effort par défaut.

Étape 3 — Envoyer un message proactif

Un agent ne fait pas que répondre : il peut vous écrire en premier. La commande message send pousse un message vers une cible (un numéro, un identifiant de discussion). C’est la brique des notifications : couplée à une tâche planifiée, elle permet à l’agent de vous prévenir d’un événement.

openclaw message send --target +221770000000 --message "Sauvegarde nocturne terminee avec succes."

La cible dépend du canal configuré ; pour Telegram, ce sera l’identifiant de la discussion. Imaginez l’usage : un script de sauvegarde qui se termine appelle cette commande, et vous recevez la confirmation sur votre téléphone. L’agent devient un canal d’alerte, pas seulement un répondeur.

Étape 4 — Gérer le contexte d’une conversation

OpenClaw garde le contexte d’un échange : il se souvient des messages précédents pour rester cohérent. Mais un contexte trop long coûte des jetons et peut « polluer » les réponses. Les commandes intégrées (slash), tapées directement dans la conversation, gèrent cela. Les principales :

/new        # demarrer une nouvelle conversation, repartir de zero
/reset      # reinitialiser le contexte courant
/compact    # compacter l'historique pour economiser des jetons
/status     # afficher l'etat de la session

Utilisez /new quand vous changez complètement de sujet, /compact quand une longue conversation devient coûteuse mais que vous voulez garder l’essentiel, et /reset pour repartir propre sans changer de fil. Ces commandes s’envoient comme un message normal à l’agent.

✅ Point d’étape — après un /new, l’agent ne fait plus référence aux messages précédents. Vous contrôlez ce qu’il « se rappelle ».

Étape 5 — Régler la verbosité et tracer

Quand un comportement vous surprend, augmentez ce que l’agent vous montre. Les commandes intégrées de verbosité et de trace exposent ce qui se passe en coulisse : quels outils l’agent appelle, combien de jetons il consomme. C’est l’outil de débogage numéro un.

/verbose on        # afficher plus de details sur les actions de l'agent
/trace on          # tracer les appels d'outils
/usage full        # detailler la consommation de jetons

Avec /trace on, vous voyez l’agent décomposer son raisonnement et appeler ses outils, ce qui révèle pourquoi une compétence ne s’active pas ou pourquoi une réponse part de travers. Pensez à repasser en /verbose off une fois le diagnostic terminé, pour retrouver des échanges lisibles.

Étape 6 — Suivre la consommation et mettre à jour

Deux gestes d’hygiène ferment la boucle. Suivre la consommation de jetons vous évite les mauvaises surprises de facturation ; mettre à jour applique les correctifs, y compris de sécurité.

/usage tokens                     # consommation de la session courante
openclaw update --channel stable  # appliquer la derniere version stable

Prenez l’habitude de vérifier /usage après une session intensive : c’est là que vous repérez une compétence trop bavarde ou un modèle trop gourmand. Et lancez la mise à jour régulièrement — un agent à jour est un agent plus sûr.

Étape 7 — Vérification finale

Constituez votre routine en l’exécutant une fois de bout en bout : gateway status pour confirmer que l’agent tourne, openclaw agent --message pour une réponse, /usage pour la consommation, et un /new pour repartir propre. Si ces gestes vous sont familiers, vous pilotez désormais votre assistant sans dépendre de quoi que ce soit d’autre que le terminal.

🐞 Pièges fréquents

Comprendre les sessions et la mémoire de l’agent

Pour bien piloter le contexte, il faut comprendre ce qu’OpenClaw appelle une session. Chaque interlocuteur et chaque fil de discussion correspond à un espace isolé : la passerelle route les messages entrants vers la bonne session, de sorte que votre conversation privée ne se mélange pas avec celle d’un groupe, ni avec celle d’un autre utilisateur autorisé. C’est ce cloisonnement qui permet à un même agent de servir plusieurs canaux sans tout confondre.

À l’intérieur d’une session, l’agent conserve un historique : les messages échangés, les actions menées, les résultats obtenus. Cette mémoire de court terme est ce qui rend la conversation naturelle — vous pouvez dire « refais-le pour l’autre fichier » sans tout réexpliquer. Mais elle a un coût : chaque message renvoyé au modèle inclut une partie de cet historique, facturée en jetons. Les commandes /compact et /new sont donc autant des outils d’économie que de clarté. /compact résume l’historique pour en garder l’essentiel à moindre coût ; /new ouvre une session vierge quand le sujet n’a plus rien à voir. Savoir quand couper, c’est savoir maîtriser à la fois la pertinence des réponses et la facture.

Service système ou premier plan : deux usages

La passerelle peut tourner de deux manières, et chacune a son moment. Au premier plan, lancée par openclaw gateway, elle occupe votre terminal et y déverse ses journaux en direct : c’est le mode du débogage, quand vous voulez voir exactement ce qui se passe au démarrage ou pendant un échange qui pose problème. En service système, installée par l’onboarding, elle tourne en arrière-plan et redémarre toute seule après un reboot : c’est le mode de production.

Pour inspecter les journaux d’un service en arrière-plan sous Linux, on passe par journalctl, ce qui revient à voir ce que le mode premier plan afficherait, mais a posteriori.

journalctl --user -u openclaw -f      # suivre les logs du service en direct
# ou, si le service est au niveau systeme :
sudo journalctl -u openclaw -f

Le nom exact du service (openclaw ici) est celui affiché lors de l’onboarding ; adaptez-le si besoin. Le drapeau -f suit les journaux en continu, comme le mode premier plan. C’est l’outil à dégainer quand l’agent se comporte mal alors qu’il tourne en service : vous gardez la production active tout en observant ce qui se passe. Coupez l’affichage avec Ctrl+C sans arrêter le service.

Le tableau de bord local

Au-delà du terminal pur, OpenClaw propose une interface locale qui rassemble l’état de l’agent, les canaux et les sessions dans une vue unique. On l’ouvre par une commande dédiée.

openclaw dashboard

Le tableau de bord est pratique pour visualiser d’un coup d’œil ce que la ligne de commande montre morceau par morceau. Une réserve de sécurité, déjà évoquée dans le tutoriel de durcissement : ne l’exposez jamais directement sur Internet. S’il faut y accéder à distance, faites-le à travers un tunnel SSH plutôt qu’en ouvrant un port, afin de ne pas transformer cette commodité en porte d’entrée.

🌍 Scripter pour automatiser à moindre coût

La vraie puissance de la ligne de commande, c’est l’automatisation. Comme openclaw message send et openclaw agent s’appellent depuis un script, vous pouvez brancher l’agent sur les événements de votre infrastructure sans aucun outil payant : une tâche planifiée (cron) qui vérifie chaque matin qu’un site répond et vous écrit le verdict, un script de sauvegarde qui confirme sa réussite, une alerte quand l’espace disque baisse. Sur un VPS modeste, cet usage « notifications intelligentes » coûte une poignée d’appels d’API par jour, soit quelques centimes, tout en vous tenant informé où que vous soyez. C’est souvent là que l’assistant personnel devient indispensable au quotidien.

✅ Récapitulatif

Vous savez piloter la passerelle (démarrer, vérifier, arrêter), interroger l’agent et lui faire envoyer un message proactif, gérer le contexte d’une conversation avec /new, /reset et /compact, déboguer avec /trace et /verbose, et surveiller la consommation avec /usage. Votre trousse de commandes est complète, et l’automatisation par script vous ouvre la porte d’un assistant proactif.

🧾 Aide-mémoire

💪 À vous de jouer

Défi : faites en sorte que l’agent vous envoie automatiquement, chaque matin, un message confirmant que la passerelle tourne.

#!/bin/bash
if openclaw gateway status | grep -qi running; then
  openclaw message send --target VOTRE_ID --message "Agent operationnel ce matin."
fi

Tutoriels frères

• Configurer un modèle LLM dans OpenClaw — l’effort de raisonnement piloté par --thinking.
• Sécuriser un agent OpenClaw — surveiller l’activité via les commandes de trace et d’usage.

Pour aller plus loin

• 🔝 Retour au guide principal : OpenClaw, panorama et mise en route.
• Documentation officielle : docs.openclaw.ai et github.com/openclaw/openclaw.

FAQ

Dois-je connaître la ligne de commande pour utiliser OpenClaw ?
Pour l’usage quotidien via messagerie, non. Mais pour installer, diagnostiquer et automatiser, la ligne de commande est incontournable — d’où ce tutoriel.

Les commandes slash fonctionnent-elles aussi sur Telegram ?
Oui. Les commandes intégrées comme /new ou /compact s’envoient comme des messages dans n’importe quel canal connecté, pas seulement en CLI.

Puis-je automatiser l’agent avec cron ?
Tout à fait. Comme openclaw message send et openclaw agent sont des commandes, un script planifié peut faire agir l’agent ou vous notifier d’un événement, sans intervention humaine.

Comment savoir combien je dépense ?
La commande intégrée /usage détaille la consommation de jetons de la session. Pour le coût réel, croisez-la avec la grille tarifaire de votre fournisseur de modèle et fixez un plafond de dépense chez lui.