OpenClaw Gateway

Salut, c'est Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 1 sur 11. Tu es loin de ton bureau, mais tu as besoin d'une code review rapide. Tu envoies un message depuis ton téléphone et, quelques secondes plus tard, une analyse détaillée te parvient, générée intégralement par un serveur privé qui tourne sur ta machine locale. C'est l'architecture Personal AI Gateway qui rend possible ce setup entièrement self-hosted. La plupart des chatbots IA font transiter tes données personnelles par une couche d'orchestration tierce. Si tu veux connecter une app de messagerie à un modèle de langage, tu utilises généralement un service cloud pour faire le lien entre les API. Ça expose tes requêtes privées et ça introduit de la latence. L'architecture OpenClaw Gateway supprime ce service intermédiaire en faisant tout tourner dans un seul process self-hosted. Ce process sert de pont dédié. Il se place directement entre tes interfaces de messagerie habituelles et le runtime IA de ton choix. Traçons le parcours exact d'un message pour voir comment le flux logique se déroule. Tu envoies un snippet de code depuis ton téléphone via WhatsApp. Sur ta machine locale, le process de la gateway tourne déjà. Il maintient des connexions persistantes vers tes apps de messagerie en utilisant des librairies spécifiques. Pour WhatsApp, la gateway utilise la librairie Baileys pour gérer la connexion socket directe. Pour Telegram, elle s'appuie sur le framework grammY. Quand ton message arrive sur le serveur local, il est wrappé dans une structure de données spécifique au protocole. Un event WhatsApp a une structure de payload totalement différente d'un event Telegram. La gateway parse immédiatement ces messages entrants. Elle retire les wrappers spécifiques à la plateforme, extrait le raw text et l'identifiant de l'expéditeur, puis les regroupe dans un objet interne standardisé. Voici le point clé. Au moment où ton message atteint le runtime IA, le moteur ne sait pas d'où vient le texte. Le runtime fonctionne de manière totalement indépendante de Baileys ou grammY. Il voit uniquement une requête propre et uniforme. L'IA traite ton snippet de code, génère la review, et renvoie une réponse en plain text à la gateway. La gateway inverse ensuite le flux. Elle vérifie le marqueur d'origine attaché à la requête initiale. Si tu as posé la question via WhatsApp, la gateway formate la réponse de l'IA dans une structure compatible avec Baileys et la push sur le socket directement vers ton téléphone. Si la requête vient de Telegram, elle utilise grammY pour dispatch la réponse. Garder tout ça dans un seul process self-hosted réduit considérablement la complexité opérationnelle. Tu n'as pas besoin de deploy plusieurs microservices, de configurer des message queues, ou d'exposer des endpoints locaux à des webhooks externes juste pour router un texte. Une seule application isolée gère les sockets réseau, exécute la logique de normalisation et invoque le moteur d'IA. Comme la gateway unifie plusieurs canaux en interne, le contexte de ta conversation reste centralisé. Tu peux commencer à débugger sur Telegram en marchant, et poser une question de suivi plus tard sur WhatsApp. La gateway s'assure que le runtime IA conserve l'historique complet, peu importe l'app mobile que tu ouvres. Le plus gros avantage de cette architecture, c'est le contrôle absolu sur tes inputs et tes outputs à travers n'importe quelle interface de messagerie, entièrement sur ton propre hardware. Si tu aimes le podcast et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et keep building !

Bonjour, ici Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 2 sur 11. Ton bot de travail et ton bot assistant personnel ne devraient jamais partager les mêmes mémoires, pourtant lancer une instance de serveur séparée pour chaque nouveau persona de bot est un cauchemar opérationnel. C'est exactement cette tension que résout le Multi-Agent Routing. Les auditeurs confondent souvent ce setup avec une architecture SaaS multi-tenant. Clarifions ça tout de suite. Le Multi-Agent Routing n'est pas conçu pour héberger des bots disparates pour des milliers de clients externes. Il sert plutôt à organiser les différents personas d'un même propriétaire, ou à lier des group chats spécifiques à des bots dédiés, le tout tournant efficacement sous le même toit. Pour que ça marche, le système sépare strictement deux concepts. Tu dois comprendre la différence entre un account ID et un agent ID. L'account ID, c'est l'humain. C'est l'identifiant de la personne qui envoie le texte. L'agent ID, c'est le bot. Il définit le persona, le modèle et les instructions spécifiques auxquels l'humain s'adresse. Un seul humain avec un seul account ID va régulièrement parler à plusieurs agent IDs différents tout au long de la journée. Sur l'OpenClaw Gateway, plusieurs agents isolés tournent côte à côte. Tu ne partages pas les memory states entre eux. Chaque agent ID a son propre workspace dédié et son propre session store distinct. Quand un message entrant arrive sur la Gateway, le système doit déterminer exactement quel workspace isolé doit le recevoir. Il fait ça en utilisant des règles de routing appelées bindings. Les bindings sont des mappings déterministes. Ils regardent les metadata exactes attachées à un message entrant et le routent en conséquence. Chaque message entrant transporte un payload de données de connexion. Ça inclut le channel, comme WhatsApp ou Telegram. Ça inclut l'account ID de l'expéditeur. Ça peut aussi inclure un peer identifier, qui pourrait dicter une room de group chat spécifique. Tu configures les bindings pour évaluer ces metadata. Par exemple, tu peux créer un binding qui dicte que tout message arrivant sur le channel WhatsApp est routé directement vers un agent ID rapide pour le quotidien. Cet agent gère les tâches rapides, les listes de courses ou les simples recherches web. Dans la même configuration, tu définis un autre binding indiquant que tout message arrivant via Telegram est routé vers un agent ID robuste qui fait tourner un plus gros modèle comme Opus pour du travail de code approfondi. Le flow logique est simple. La Gateway reçoit un message Telegram. Elle lit les metadata du channel et ton account ID. Elle vérifie les bindings, trouve la règle qui correspond à Telegram, et transfère le payload à l'agent ID Opus. L'agent Opus se réveille dans son workspace isolé. Il requête son propre session store dédié pour récupérer l'historique de la conversation. Il n'a absolument aucun accès à la liste de courses que tu viens d'envoyer à l'agent WhatsApp. Voici l'idée clé. Le Multi-Agent Routing transforme une seule Gateway en un standard téléphonique déterministe, en utilisant les metadata du channel et de l'utilisateur pour garantir que le bon persona traite toujours la bonne requête sans jamais faire de cross-contamination entre leurs mémoires. Comme toujours, merci pour ton écoute. On se retrouve dans le prochain épisode.

Salut, ici Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 3 sur 11. Tu as toujours rêvé de pouvoir littéralement écrire une âme pour ton IA, peut-être pour qu'elle réponde exclusivement comme un homard de l'espace grognon ? Dans OpenClaw, atteindre ce niveau de contrôle sur le personnage ne nécessite aucun code. Tout se passe entièrement via du texte brut, ce qui nous amène à l'Agent Workspace et aux System Prompts. Un agent dans OpenClaw est défini par son workspace. Ce workspace est simplement un répertoire de fichiers contenant un ensemble spécifique de fichiers de bootstrap Markdown. Au lieu d'enterrer ton system prompt dans la logique de l'application ou dans des champs de base de données complexes, OpenClaw expose les instructions principales sous forme de documents lisibles et versionnables. Quand l'application tourne, OpenClaw lit ces fichiers pour construire le system prompt monolithique qui guide le Large Language Model. La construction repose sur quatre documents principaux. Le premier est le fichier Markdown agents. Ce document établit l'identité de base, les objectifs principaux et les limites opérationnelles strictes de l'agent. Vois ça comme sa fiche de poste fondatrice. Il indique au modèle ce qu'il est censé accomplir et les sujets qu'il doit absolument éviter. Le deuxième document est le fichier Markdown soul. C'est là que vivent la personnalité, le ton et le style conversationnel. C'est exactement ici que tu indiques au modèle d'agir comme un homard de l'espace grognon. Tu rédiges des directions explicites pour dire à l'agent de se plaindre du vide glacial de l'espace, d'utiliser des métaphores de crustacés et de se montrer généralement agacé par les questions humaines. En isolant la personnalité de la logique principale, tu peux changer le ton de ton agent sans risquer sa fiabilité fonctionnelle. Le troisième composant est le fichier Markdown tools. Ce texte explique les capacités externes disponibles pour l'agent. Il décrit quelles fonctions le modèle peut déclencher, les paramètres requis pour ces fonctions, et comment interpréter logiquement les résultats. Il fait le pont entre le raisonnement interne du modèle et ton codebase réel. Le dernier document est le fichier Markdown user. Ce fichier injecte du contexte sur la personne qui interagit avec l'agent. Il peut contenir les préférences de l'utilisateur, son niveau de compétence technique ou les contraintes de son compte. Ça garantit que l'agent adapte ses réponses à l'humain spécifique à l'autre bout du chat, plutôt que d'offrir des conseils génériques. Voici l'idée clé. OpenClaw prend le contenu de ces quatre fichiers et les concatène. Cette string combinée devient le system prompt final. Le détail crucial, c'est que ce prompt est injecté dans la context window à chaque tour de conversation. Le modèle ne lit pas ces fichiers une seule fois au startup pour les garder dans une banque de mémoire séparée. Il lit l'intégralité du bloc concaténé à chaque fois que l'utilisateur envoie un nouveau message. Ce choix architectural dicte la façon dont tu dois écrire tes fichiers de workspace. Parce que le texte complet du workspace est placé en prepend à chaque interaction, ton token count va grimper agressivement. Si tu écris une backstory de trois pages dans le fichier soul, tu paies le coût de traitement pour ces trois pages à chaque fois que l'utilisateur dit simplement bonjour. Plus important encore, les gros system prompts consomment les limites disponibles de la context window. Un workspace surchargé étouffe l'historique réel de la conversation, ce qui fait que le modèle oublie les premières parties du chat beaucoup plus vite. Tu dois être impitoyable quand tu édites tes documents de workspace. Supprime les instructions redondantes. Utilise un langage précis. Si une règle dans le fichier agents n'est jamais déclenchée, supprime-la. Le system prompt n'est pas une étape de configuration unique. C'est une taxe récurrente sur ta context window et ton budget API, payée à chaque tour de la conversation. Garde-le léger, et ton agent restera concentré. Merci d'avoir écouté. Prenez soin de vous, tout le monde.

Bonjour, ici Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 4 sur 11. Tu déploies un nouveau chatbot dans le workspace de ton entreprise. Alice lui demande de résumer ses notes de réunion privées, et cinq minutes plus tard, il les cite par erreur à Bob. Ton agent vient de leak des données parce qu'il traite tout le monde dans le workspace comme une seule et même personne. Pour corriger ça, tu dois comprendre le Session Management et la DM Isolation. Avant de corriger cet overlap, on doit parler d'une idée reçue courante. Les ingénieurs confondent souvent les session keys avec les tokens d'authentification. Ce n'est pas du tout la même chose. Les session keys ne sont pas des barrières de sécurité. Ce sont simplement des sélecteurs de routing. Elles disent au système OpenClaw quel bloc d'historique de conversation récupérer dans la base de données pour l'injecter dans le prompt. Si tu as besoin de restreindre qui peut parler à ton agent, tu utilises une vraie authentification. Les session keys servent juste à garder le texte séparé. Chaque interaction avec un agent OpenClaw se passe à l'intérieur d'une session. La session contient l'historique de la conversation et le contexte actif à court terme. Par défaut, OpenClaw route tout le trafic à travers une seule session key partagée qui s'appelle main. Si tu fais tourner un script dans ton terminal en local ou un assistant personnel juste pour toi, ce comportement par défaut marche parfaitement. Tout ton contexte reste dans un seul thread continu. Mais si tu connectes exactement le même agent à une plateforme multi-utilisateurs, ce paramètre par défaut pose problème. Chaque utilisateur qui parle au bot écrit exactement dans le même historique main. L'agent lit le prompt d'Alice, génère une réponse, et la sauvegarde. Quand Bob envoie un message dix secondes plus tard, l'agent lit l'input de Bob en même temps que l'input précédent d'Alice. C'est là que ça devient intéressant. Tu empêches cet overlap en utilisant les paramètres de DM Isolation. Quand tu configures ton intégration de plateforme, tu changes la stratégie de routing de session pour passer du mode par défaut à per-channel-peer. Quand tu actives per-channel-peer, OpenClaw arrête de router le trafic vers la session main. À la place, il génère dynamiquement une session key unique pour chaque message entrant. Il fait ça en combinant l'identifiant de channel de la plateforme avec l'identifiant de l'utilisateur. Maintenant, quand Alice envoie un message au bot dans un channel spécifique, OpenClaw construit une session key unique pour elle et ce channel. Quand Bob envoie un message au bot, son identifiant utilisateur génère une session key complètement différente. Le système charge un state propre et vide pour Bob. Leurs contextes sont entièrement isolés. Si Alice parle au bot dans un channel complètement différent, elle obtient une nouvelle session là-bas aussi. Ces sessions ne gardent pas leur state pour toujours. OpenClaw gère le nettoyage des sessions via deux événements de lifecycle spécifiques. Le premier est un idle reset. Si une session particulière ne reçoit aucun nouveau message pendant une durée configurée, le système drop le contexte. La prochaine fois que l'utilisateur envoie un message, il repart de zéro. Le deuxième mécanisme de nettoyage est un hard reset quotidien. Peu importe l'activité d'une conversation, OpenClaw purge de force tous les contextes de session à exactement 4 heures du matin, heure du serveur. Ce reset quotidien agit comme une étape de garbage collection automatisée. Ça garantit que la mémoire est libérée et que les conversations très longues ne consomment pas silencieusement des quantités massives de tokens de contexte sur plusieurs semaines d'utilisation. Quand tu déploies des agents dans des environnements de groupe, ne pars jamais du principe que la plateforme gère la séparation des utilisateurs pour toi. Mapper explicitement tes session keys sur la bonne user boundary est le seul moyen d'empêcher les leaks de contexte accidentels. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 5 sur 11. Les context windows d'une IA ne sont pas infinies, mais ta conversation a souvent besoin de l'être. Quand une session qui dure depuis un moment heurte un mur, la solution classique c'est de supprimer complètement les anciens messages, ce qui fait que l'agent oublie soudainement des étapes de setup cruciales. Gérer les limites de contexte avec le compactage résout ce problème en transformant proprement les anciens chats en résumés denses avant même que la limite ne soit atteinte. Avant de regarder comment ça marche, ne confonds pas ça avec le session pruning. Le session pruning est une opération distincte qui nettoie uniquement les tool results en excès. Le compactage agit directement sur l'historique principal de la conversation. Imagine une longue session de code. L'agent génère du boilerplate, lit des fichiers locaux et debug des erreurs de logique depuis une heure. Chaque interaction fait grimper le nombre de tokens. Si le système atteint la hard limit du modèle de langage sous-jacent, l'API rejette la requête et la session crash. Tu as besoin d'un moyen de récupérer de l'espace sans casser la logique de l'assistant. OpenClaw gère ça via le Context Engine. Le Context Engine gère tout le flux de messages entre l'utilisateur et le modèle. À l'intérieur de ce moteur, il y a un lifecycle point spécifique appelé compact. Cette phase agit comme une soupape de sécurité automatique pour le context overflow. Le moteur surveille activement l'utilisation des tokens de la conversation en cours. Tu définis un seuil maximum de tokens dans ta configuration. Tant que la conversation reste en dessous de ce seuil, les messages passent normalement. Quand le nombre de tokens approche de la limite, le moteur déclenche automatiquement un memory flush via le lifecycle point compact. Quand le flush se déclenche, le système divise l'historique des messages en deux sections. Il sépare les messages les plus récents des messages plus anciens et historiques. Les messages récents restent complètement intacts. Le moteur préserve les mots exacts de l'échange immédiat pour que l'agent ne perde pas le fil de sa pensée ou la syntaxe exacte de la fonction sur laquelle tu travailles activement. Voici le point clé. Les anciens messages ne sont pas jetés. À la place, ils sont redirigés vers un processus de résumé secondaire. Ce processus lit le gros de la conversation du début et le condense en un court texte de résumé. Ce texte capture les objectifs de départ, les décisions d'architecture prises au début, et toutes les règles établies, tout en supprimant le remplissage conversationnel et les itérations obsolètes du code. Le moteur restructure ensuite la mémoire active. Il remplace le gros bloc d'anciens messages bruts par cet unique bloc de résumé. Le prompt nouvellement structuré contient d'abord le bloc de résumé, suivi des messages récents verbatim. Le nombre total de tokens chute drastiquement. L'agent comprend toujours le contexte historique en lisant le résumé, et il peut continuer d'exécuter la tâche active en lisant les messages récents. La conversation continue fluidement sans aucune intervention manuelle. Une gestion efficace du contexte, ce n'est pas de retenir chaque mot exact que tu as tapé, mais de compresser systématiquement le passé pour que l'agent ait un maximum de place pour raisonner sur le présent. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 6 sur 11. Mettre une IA dans un workspace Slack partagé avec un accès terminal, ça ressemble à un incident de sécurité garanti, à moins que tu définisses strictement qui a le droit de lui dire quoi faire. Aujourd'hui, on parle de sécurité et de trust boundaries. La règle fondamentale d'OpenClaw Gateway, c'est qu'il fonctionne sur un modèle de confiance de type assistant personnel. Beaucoup de développeurs pensent que les gateways IA intègrent d'office une autorisation complexe au niveau user. Ce n'est pas le cas d'OpenClaw. OpenClaw n'est pas conçu pour de l'isolation multi-tenant hostile. Il n'essaie pas de séparer de manière safe les users malveillants les uns des autres sur une seule instance partagée. Au lieu de ça, toute la gateway agit comme une seule boundary qui représente un opérateur de confiance. Le système part du principe que quiconque peut communiquer avec la gateway est autorisé à agir au nom du propriétaire. Vois ça comme une workstation non verrouillée. Si ton instance OpenClaw est configurée avec un tool qui modifie l'infrastructure, n'importe qui capable de parler à cette instance peut déclencher cette modification. Le modèle d'IA lui-même n'a aucune notion de rôles user ou d'access tokens. Il ne voit qu'un flux de texte entrant. Ce qui nous amène au risque sérieux des channels partagés. Si tu connectes ta gateway à un groupe Telegram public ou à un grand channel Slack d'équipe, chaque user de ce channel est maintenant à l'intérieur de ta trust boundary. L'IA traite chaque message qu'elle lit comme une instruction valide. Si un user externe tape une attaque par prompt injection dans le chat, il pirate l'autorité déléguée des tools de ton bot. La gateway ne peut pas faire la différence entre toi qui demandes un statut système et un attaquant qui piège le modèle pour lancer un shell script destructeur. L'autorité appartient au bot, mais le contrôle appartient à celui qui fournit le prompt. Si tu as une connexion exposée, comme un bot Telegram, tu dois la verrouiller. D'abord, désactive les tools à privilèges élevés pour ce profil de gateway spécifique. Ne donne pas à un bot accessible publiquement l'accès à ton file system local ou à tes APIs internes sensibles. Garde son toolset limité à des actions en read-only ou inoffensives. Ensuite, restreins la couche de communication. Configure la connexion pour qu'elle n'accepte que les messages directs de users spécifiques appairés, en ignorant complètement les chats de groupe et les inconnus. En limitant qui peut entrer du texte et quels tools le bot peut exécuter, tu sécurises la boundary. Pour vérifier que tu n'as pas laissé une porte ouverte, utilise l'utilitaire en ligne de commande intégré. Lance la commande openclaw security audit. Ce tool scanne la configuration active de ta gateway et vérifie deux risques principaux. Premièrement, il vérifie ton exposition réseau. Il t'avertira si ton instance écoute sur des interfaces publiques plutôt que d'être bindée de façon safe sur localhost. Deuxièmement, il signale les tools permissifs. L'audit t'alertera si tu as des capacités à haut risque, comme de l'arbitrary code execution, activées en même temps que des intégrations de chat public. Voici le point clé. La boundary de la sécurité de ton système, c'est exactement la boundary de qui peut soumettre du texte à tes modèles. Si tu ne peux pas limiter l'audience, tu dois limiter les tools. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 7 sur 11. Donner à un modèle d'IA un accès raw à la ligne de commande, ça ressemble à un aller simple pour ruiner un système. Mais et si l'agent pouvait exécuter automatiquement des commandes de data-parsing inoffensives, tout en te demandant explicitement ta permission avant de toucher à quoi que ce soit de destructeur ? L'Exec Tool et les Runtime Approvals gèrent exactement cet équilibre. L'Exec Tool permet à un agent OpenClaw d'exécuter des commandes shell pour interagir avec le système. Quand l'agent décide qu'il a besoin d'exécuter une commande, il cible soit directement la machine host, soit un container sandbox dédié. Utiliser un container sandbox limite le blast radius pour l'exécution générale. Cependant, parfois l'agent a vraiment besoin d'interagir avec ton file system local, de lire tes logs locaux ou de lancer des process locaux. Exécuter des commandes sur le host, c'est puissant, et c'est exactement pour ça que le modèle d'autorisation existe. OpenClaw utilise un système d'autorisation à deux niveaux pour te permettre de garder le contrôle sans ralentir l'agent inutilement. Le premier niveau repose sur les safe bins. Ce sont des binaires spécifiques que tu whitelist explicitement comme inoffensifs, comme jq pour parser du JSON ou grep pour chercher du texte. Si l'agent appelle une commande qui utilise uniquement ces safe bins, la Gateway l'exécute immédiatement. Il n'y a pas de prompt, et l'agent garde son élan. Le second niveau attrape tout le reste. Si l'agent tente une exécution shell complète ou essaie d'utiliser un binaire qui n'est pas sur la safe list, la Gateway intercepte la requête. Elle met l'agent en pause et déclenche le système de runtime approvals. Un prompt apparaît dans l'UI de ta Gateway ou dans ton app compagnon. Tu peux revoir la command string exacte que l'agent veut exécuter. Si tu approuves, la Gateway exécute la commande et renvoie l'output à l'agent. Si tu rejettes, la commande ne s'exécute jamais. À la place, l'agent reçoit une erreur execution denied, et il doit trouver un autre moyen de continuer ou te demander des précisions. Voici comment ça se passe concrètement en pratique. Disons que l'agent a besoin d'analyser un énorme fichier de log. Il appelle grep pour extraire les erreurs. Ça s'exécute instantanément. Ensuite, il a besoin de compiler le projet, donc il tente de lancer npm run build comme un background process. La Gateway stoppe l'agent et ping ton app compagnon. Tu lis la commande, tu te rends compte que c'est logique, et tu cliques sur approve. Le build démarre en background. Plus tard, l'agent décide de faire du nettoyage en tentant de supprimer un fichier source. La Gateway te ping à nouveau. Tu refuses la requête. Ton fichier reste intact, et l'agent apprend qu'il n'a pas la permission pour cette action. Il y a une contrainte de sécurité stricte que tu dois connaître lors de l'exécution sur le host. La Gateway rejette explicitement toute tentative d'override de la variable d'environnement path. Ça empêche le hijacking. Sans ce blocage, un prompt malveillant pourrait piéger l'agent pour qu'il redéfinisse le path, ce qui ferait qu'un nom de safe bin comme grep exécuterait un script destructeur caché dans un autre dossier. Parce que le path est verrouillé, la liste des safe bins reste absolue. La vraie puissance de l'Exec Tool, ce n'est pas juste que l'IA peut exécuter des commandes, c'est que le modèle de sécurité à plusieurs niveaux force un humain dans la boucle uniquement quand les enjeux sont élevés, laissant l'agent complètement autonome pour le travail de routine. Si tu veux aider à faire vivre l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 8 sur 11. Tu veux que ton agent manipule des images en utilisant un outil en ligne de commande. D'habitude, ça implique d'écrire des wrappers Python, de définir des schemas, et d'espérer que le modèle de langage comprenne les paramètres. Mais tu n'as pas vraiment besoin de code pour apprendre une nouvelle capacité à une IA. Tu as juste besoin d'un fichier texte. Aujourd'hui, on se concentre sur comment apprendre des Skills aux agents dans OpenClaw. Un Skill dans OpenClaw, c'est essentiellement un manuel d'instructions. C'est un simple fichier texte nommé SKILL point md, formaté avec le standard AgentSkills. Ce n'est pas un binaire compilé et ce n'est pas un script Python. C'est un document Markdown qui dit exactement à l'agent comment orchestrer les outils existants. Dans ce fichier, tu écris des instructions étape par étape. Tu définis le but du skill, les outils qu'il utilise, et la séquence d'actions que l'agent doit faire. Si tu crées un skill de traitement d'image appelé image-lab, ton fichier SKILL point md expliquera comment formater les arguments de la ligne de commande pour redimensionner ou recadrer une image. L'agent lit ce fichier et traduit tes instructions en anglais en exécutions précises en ligne de commande. Un skill est inutile si l'outil sous-jacent est absent du système. OpenClaw évite les erreurs ici en utilisant un load-time gating. Ça te permet de définir des prérequis pour que ton agent n'essaie jamais d'utiliser un logiciel qui n'est pas installé. Tu gères ça en déclarant des requirements dans la configuration du skill. Pour le skill image-lab, tu pourrais avoir besoin d'un package manager spécifique pour lancer les commandes. Tu spécifies ça en utilisant la propriété requires point bins, en listant le nom de l'exécutable, comme uv. Tu peux aussi exiger des variables d'environnement spécifiques avec la propriété requires point env, ce qui garantit qu'une clé API ou un chemin de configuration est présent avant que le skill s'active. Quand OpenClaw démarre, il évalue ces gates. Il vérifie l'environnement local pour trouver le binaire uv et toutes les variables demandées. S'ils manquent, OpenClaw ignore silencieusement le skill. Le système ne va pas crasher et l'agent ne va pas halluciner des commandes non supportées. Il fonctionne simplement sans les capacités de image-lab. Voici le point clé. OpenClaw doit fournir ces skills valides au modèle de langage de manière efficace. Il prend tous les skills qui ont passé les checks au load-time et les compile dans une liste XML compacte. Ce bloc XML est injecté directement dans le system prompt de l'agent. Les modèles de langage sont très optimisés pour parser les tags XML. En formatant le manuel d'instructions de cette façon, l'agent sépare proprement son persona principal de la logique stricte, étape par étape, définie dans tes skills. Tu n'as pas besoin d'écrire chaque skill toi-même. OpenClaw s'intègre avec ClawHub, le registry officiel pour les skills créés par la communauté. Si tu as besoin que ton agent utilise une base de données spécifique ou un utilitaire cloud, tu peux chercher sur ClawHub et installer un skill existant. Il se télécharge dans ton environnement, passe par les mêmes checks au load-time, et s'injecte automatiquement dans le system prompt. L'aspect le plus précieux de l'architecture Skills, c'est le découplage de la capacité et du code. Tu peux complètement recâbler la façon dont ton agent résout des problèmes complexes en plusieurs étapes juste en éditant un fichier Markdown, sans jamais modifier la logique de ton application ou compiler un nouveau build. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 9 sur 11. Ton agent essaie d'extraire des données d'une page web, mais il ne fait pas juste du parsing de HTML brut. Il doit faire le render d'un dashboard React dynamique, cliquer sur un bouton et attendre qu'un chart charge. Tu dois fournir à l'agent une interface web complètement fonctionnelle, mais tu ne veux absolument pas qu'il vienne mettre le bazar dans tes propres onglets ouverts ou qu'il pirate ta souris. Le Managed Browser Tool gère exactement ça. Cet outil donne à ton agent la capacité de cliquer, de taper du texte, de naviguer et de capturer visuellement exactement ce qu'un humain verrait. Il fait tourner un vrai environnement de browser pour interagir avec des applications client-side rendered, en contournant les limites des simples requêtes HTTP. Pour garder ton espace de travail sécurisé, le Managed Browser Tool utilise différents profils opérationnels. Le profil par défaut est le profil openclaw isolé. Quand l'agent utilise ce profil, l'outil lance une instance Chromium complètement séparée et dédiée. Elle a ses propres cookies, son propre local storage et son propre historique vierge. L'agent navigue dans son propre browser dédié. Il peut remplir des formulaires et cliquer dans les menus sans jamais toucher à ta session Chrome personnelle. Cependant, il y a des moments où un agent a besoin d'accéder à des outils internes où tu es déjà authentifié. Pour ça, l'outil fournit le profil user. Au lieu de démarrer de zéro, le profil user s'attache à ta session Chrome existante et connectée. Il se connecte via le DevTools Protocol à travers le Model Context Protocol. Ça permet à l'agent d'utiliser tes login tokens actifs pour cette tâche spécifique sans t'obliger à passer tes credentials directement à l'IA. Voici le point clé. Donner un browser automatisé à un agent IA dans ton environnement introduit des risques de sécurité immédiats. Pour limiter ça, le contrôle du Managed Browser Tool est strictement loopback-only. L'agent communique avec le browser entièrement via l'interface loopback locale. Plus important encore, chaque requête de navigation est protégée par la policy Server-Side Request Forgery. Cette policy garantit que l'agent ne peut pas utiliser son instance de browser comme proxy pour scanner silencieusement les ports de ton réseau local ou taper sur des services internes non autorisés. Pense au scénario du dashboard React. D'abord, l'agent envoie une commande pour lancer le browser en utilisant le profil isolé par défaut. Il navigue vers l'URL du dashboard et attend activement que les composants JavaScript soient mount et que le DOM se stabilise. Ensuite, il localise l'élément chart spécifique en utilisant un sélecteur CSS et déclenche un event click pour agrandir la vue. Enfin, il envoie une commande screenshot. Le browser capture la frame rendue et renvoie le buffer d'image directement à la gateway. Donner un browser à un agent ne devrait jamais signifier lui filer les clés de ton réseau interne ou de ta session Chrome personnelle. Le Managed Browser Tool garde l'agent ultra-capable, mais strictement contenu. C'est tout pour cette fois. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 10 sur 11. Tu demandes à ton IA de scraper un site web complexe ou de traiter des milliers de lignes de logs, et ensuite, tu restes planté là. Tu fixes un indicateur qui tourne pendant dix minutes, incapable de poser une autre question tant que la tâche n'est pas terminée. Pour résoudre ce problème bloquant, tu utilises des sous-agents éphémères. Un sous-agent éphémère, c'est un background worker temporaire et isolé. Au lieu de faire les gros calculs lui-même, ton agent de chat principal délègue le travail. Il fait ça en utilisant un system tool spécifique appelé sessions spawn. Quand l'agent principal rencontre une tâche massive, il déclenche ce tool. Il lui transmet un prompt clair, tous les fichiers de contexte requis, et les instructions spécifiques pour le job. Cette action crée une toute nouvelle session de chat invisible, qui tourne entièrement en background. Comme cette session est isolée, ton agent principal est immédiatement libéré. Tu peux continuer à parler à ton assistant principal, poser des questions qui n'ont rien à voir, ou assigner d'autres tâches pendant que le sous-agent mouline sur les données lourdes à l'abri des regards. Prenons un scénario concret. Tu balances un énorme log d'erreurs serveur dans ton chat principal et tu demandes un audit de sécurité. Traiter ce log ligne par ligne avec ton gros LLM principal prend beaucoup de temps et brûle beaucoup de tokens coûteux. Au lieu de ça, ton agent principal délègue le job. Voici le point clé. En appelant sessions spawn, l'agent principal peut spécifier un modèle complètement différent pour la tâche en background. Il peut assigner un LLM moins cher et plus rapide au sous-agent. Ce background worker utilise le modèle plus rapide pour abattre l'analyse répétitive des logs. L'agent principal reste réactif en utilisant le modèle intelligent, pendant que le sous-agent fait le sale boulot avec le modèle rapide. Quand le sous-agent a enfin fini de parser ces logs, il lui faut un moyen de renvoyer les données. Il fait ça en annonçant son résultat final en remontant la chain. Le sous-agent prend son résumé compilé et injecte un message directement en retour dans le chat du demandeur initial. Tu vois juste un nouveau message poper de la part du sous-agent avec ton analyse de logs terminée, prête à être discutée entre toi et l'agent principal. Cette architecture est connue sous le nom de pattern orchestrator, et elle repose sur des règles autour de la nesting depth. Le scénario qu'on vient de voir, c'est une nesting depth de un. L'utilisateur parle à l'agent principal, et l'agent principal spawn un sous-agent. OpenClaw supporte aussi une nesting depth de deux. Dans un scénario de depth deux, ton sous-agent qui parse les logs pourrait rencontrer un payload lourdement encodé dans les logs. Il peut alors spawner son propre sous-agent juste pour décoder ce payload spécifique. Cet agent de second niveau décode le texte, le repasse au premier sous-agent, qui termine ensuite l'analyse des logs et fait remonter son rapport dans ton chat principal. Le système limite ça strictement à une depth de deux. Cette hard limit empêche les boucles récursives incontrôlables où les agents spawnent continuellement d'autres agents à l'infini, siphonnant tes ressources de compute. Les sous-agents éphémères changent fondamentalement ta façon d'interagir avec une interface de prompt. Tu arrêtes de traiter ton LLM comme un thread unique bloqué, et tu commences à le traiter comme un gestionnaire de tâches asynchrone. C'est tout pour cette fois. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. OpenClaw Gateway, épisode 11 sur 11. Un vrai assistant ne reste pas inactif à attendre que tu tapes une commande. Il vérifie proactivement tes systèmes et t'alerte quand quelque chose a vraiment besoin de ton attention. Passer d'une boucle réactive de prompt et de réponse à un agent autonome nécessite des mécanismes de scheduling et d'exécution spécifiques. C'est là qu'interviennent les workflows d'automatisation proactive. OpenClaw gère l'automatisation basée sur le temps avec deux mécanismes distincts. Le premier est le Heartbeat. Le deuxième est Cron. Les ingénieurs les confondent souvent parce qu'ils déclenchent tous les deux des actions automatiquement en fonction du temps, mais ils ont des rôles architecturaux complètement différents en ce qui concerne le state et l'isolation de session. Le Heartbeat est une boucle périodique qui tourne en continu dans ta session principale active. Il est conçu pour les vérifications de routine en continu, où ton contexte actuel est important. Voici le point clé. Parce que le Heartbeat tourne à l'intérieur de ta session actuelle, il a un accès direct à ton interface active. Imagine un scénario où tu veux monitorer ta boîte de réception pour des messages urgents. Tu configures un Heartbeat pour exécuter une vérification toutes les trente minutes. S'il détecte un e-mail critique, le Heartbeat peut immédiatement pousser une alerte en langage naturel directement dans ton flux de conversation actif. Il agit comme un thread en background continu attaché à ton user state actuel, ce qui permet des interruptions immédiates et contextuelles. Cron fonctionne de manière totalement différente. Il est conçu pour des jobs planifiés et précis qui nécessitent une isolation complète. Si tu veux que le système compile un briefing matinal quotidien complet à partir de différentes sources de données à exactement six heures du matin, tu utilises Cron. Quand un schedule Cron se déclenche, OpenClaw n'utilise pas ton chat actif. À la place, il lance une session en background complètement isolée. Il pull les données nécessaires, traite le gros de l'analyse silencieusement, et track tout le job en interne comme une Background Task. Ça veut dire que le traitement lourd ne pollue pas la context window de ton chat desktop actif. Une fois le job terminé, le briefing finalisé est stocké et prêt à être récupéré quand tu te loggues. Le Heartbeat partage le state avec toi, alors que Cron tourne en headless et de manière isolée. Les triggers basés sur le temps ne sont qu'une partie du workflow. OpenClaw s'appuie sur les Hooks et les Standing Orders comme outils complémentaires pour compléter la boucle d'automatisation. Alors que Heartbeat et Cron dictent quand une action se produit en fonction d'une horloge, les Hooks gèrent les triggers externes, event-driven. Un Hook expose un endpoint d'écoute que les systèmes extérieurs peuvent appeler. Si un log serveur critique indique une erreur, un système externe peut appeler un Hook OpenClaw, ce qui réveille l'assistant pour analyser l'erreur immédiatement sans attendre la prochaine impulsion planifiée du Heartbeat. Les Standing Orders fournissent les règles opérationnelles persistantes pour tous ces runs autonomes. Quand ce job Cron isolé se réveille à six heures du matin, il n'y a pas de user présent pour guider son output. Les Standing Orders définissent le format exact, la profondeur d'analyse et les règles de priorité que l'assistant doit respecter pendant qu'il travaille de manière complètement indépendante. En combinant des Heartbeats périodiques pour du monitoring actif, des jobs Cron isolés pour les tâches planifiées lourdes, et des Standing Orders persistants pour gouverner le comportement non guidé, tu changes fondamentalement la nature de l'application. Tu arrêtes de construire une simple interface de chat et tu commences à déployer un vrai assistant autonome. Comme c'est le dernier épisode de notre série OpenClaw, je t'encourage vivement à explorer la documentation officielle, à essayer de configurer ces background tasks toi-même, ou à visiter devstories dot eu pour suggérer des sujets pour notre prochaine série. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.