--- title: "J'ai mis un assistant 24/7 sur un Raspberry Pi" description: "Un build-log sur OpenClaw sur un Raspberry Pi 5 : Slack comme interface, GPT-5.5 comme modèle, et le Pi comme couche agent always-on à côté du DGX Spark." canonical: "https://djangodevreng.nl/fr/blog/openclaw-sur-raspberry-pi/" pubDate: "2026-05-01T00:00:00.000Z" updatedDate: "2026-05-05T00:00:00.000Z" category: "on-prem" --- Je ne voulais pas un meilleur chatbot. Je voulais un agent qui prend du travail tout seul : aller sur internet, lire des tickets, plonger dans un repo, faire une première proposition de modifications de code et ensuite rendre compte là où mon équipe travaille déjà de toute façon. L'entrée devait être Slack. C'est là que vivent les questions, les threads, les fichiers et les idées à moitié finies. L'agent devait pouvoir utiliser des tools, lire des fichiers, préparer des branches et continuer à tourner quand mon laptop se ferme. Du coup il y a maintenant un Raspberry Pi 5 avec 4 GB RAM dans mon réseau. Dessus tourne [OpenClaw](https://openclaw.ai/). Slack devant, GPT-5.5 derrière, [Tailscale](https://tailscale.com/) comme porte d'accès quand je ne suis pas chez moi. Ça sonne plus gros que ce que c'est. Le Pi ne fait pas tourner de modèle de langage local. OpenClaw utilise le Pi comme Gateway always-on : la couche qui reçoit les messages Slack, gère les sessions et le contexte du workspace, lance un agent-run, met des tools à disposition et renvoie la réponse dans le même thread. Dans cette config, le modèle tourne via OpenAI. Cette distinction est importante. Pour de l'inference entièrement locale j'utilise [le DGX Spark](/fr/dgx-spark/), et j'en ai parlé plus tôt dans [le post sur la quantization](/fr/blog/quantization-llms-locaux/). Ce Pi est la couche agent à côté : toujours allumé, joignable dans Slack, proche de mes fichiers et de mes workflows. ## Le truc qui me manquait J'utilise déjà assez d'outils AI. Claude Code pour construire. ChatGPT pour des questions isolées. Pour les projets clients je travaille avec des API de modèles ou des modèles locaux, selon ce que les données et l'infrastructure permettent. La couche manquante se trouvait entre ces outils : un agent qui voit le travail arriver et commence déjà. Dans Slack ça peut démarrer petit. Je tape une instruction brouillonne, l'agent lit le repo, va chercher les bonnes règles de tone-of-voice et revient avec quelque chose que je peux évaluer. Publier reste du travail manuel. La confiance aussi. Le premier travail préparatoire a le droit de se faire automatiquement. La direction est plus grande que d'écrire des drafts. À terme je veux pouvoir désigner un ticket et dire : trouve ce qu'il faut ici. L'agent lit le contexte, vérifie la documentation, regarde dans la codebase, propose une approche et prépare éventuellement déjà une branche. Ce travail-là reste souvent en plan parce qu'il ne rentre nulle part proprement. Trop petit pour un sprint. Trop gros pour le faire "vite fait". Avant que tu t'en rendes compte, ce ticket est encore ouvert une semaine plus tard avec les trois mêmes remarques vagues en dessous. ## Ce qui tourne sur le Pi La base est petite : - Raspberry Pi 5, 4 GB RAM - OpenClaw Gateway en local sur le Pi - OpenAI GPT-5.5 comme modèle dans cette config - Slack comme interface - Tailscale pour l'accès distant Le Pi est surtout disponible ici. C'est son talent. OpenClaw relie les couches entre elles : channel, session, agent-runtime, model-provider et tools. Un message Slack arrive par la couche channel. OpenClaw en prépare un agent-turn, avec le bon contexte et les bons tools. Le runtime exécute ce turn avec le modèle choisi. Ensuite OpenClaw renvoie la réponse via Slack. De cette manière, le même agent peut lire des fichiers, lancer des shell-commands, récupérer des pages web, regarder le git-status ou préparer une PR, selon les tools que tu autorises. Le Pi n'est donc pas un mini-GPU. C'est la couche de contrôle locale. Tailscale garde ça pratique. Je peux atteindre le Pi quand je suis en déplacement. Ouvrir un port public pour un build-log serait un peu trop d'honneur. ## Slack comme atelier Slack était le choix le plus facile parce que j'y suis déjà toute la journée. Mes entreprises ont des workspaces, des channels, des threads, des fichiers et des notifications. Un dashboard en plus ne ferait surtout que ramasser de la poussière d'onglet en plus. Pour moi c'est ça le cœur : l'agent doit être disponible là où l'équipe travaille. S'il trouve quelque chose à partir d'un ticket, je veux la réponse de retour dans le même flux. L'analyse a sa place à côté de la question, dans le même thread. OpenClaw supporte plus d'entrées que Slack. Il fonctionne aussi via, entre autres, Telegram, Microsoft Teams, Google Chat, WhatsApp, Discord et iMessage. Slack est mon entrée. L'idée plus large, ce sont des agents sur les canaux de communication existants, avec des tools et de la mémoire derrière. ## L'installation était moins palpitante qu'espéré L'installation était moins dramatique que ce que j'avais prévu. C'est agréable pour moi et mauvais pour le genre "build-log avec du feu". Le plus gros du temps est parti dans la lecture. OpenClaw a beaucoup de documentation, et tu dois trouver quelle partie correspond à ta config. Slack, Gateway, agents, runtimes, channels, tools : ce sont des couches séparées qui forment au final un seul assistant ensemble. Configurer Slack a demandé de l'attention aussi. Tu décides quels utilisateurs peuvent DM le bot, dans quels channels il peut parler et s'il réagit à chaque message dans les channels de groupe ou seulement sur un @mention. Ce ne sont pas des détails pour plus tard. Tu dois choisir ces règles à l'avance et les partager avec ton équipe, sinon personne ne comprend quand l'agent participe ou non. Après environ deux heures, ça marchait. Je tapais dans Slack, le Pi attrapait le message, OpenClaw lançait un run, GPT-5.5 réfléchissait avec moi et la réponse revenait dans le même thread. Beaucoup de plumbing pour un message texte. Sauf que ce message texte peut maintenant utiliser des tools. ## Premier test : ce site Le premier endroit où j'utilise ça, c'est djangodevreng.nl. Le contenu doit venir de vrai travail : ce qu'on a construit, ce qui a cassé, quels choix sont restés, où un outil avait l'air bien jusqu'à ce qu'il commence à transpirer sous la charge. L'agent a le droit d'aider avec la forme et l'exécution. Dès que cet input brut est là, il peut faire beaucoup. Structurer un dump. Faire un premier outline. Réécrire un draft dans mon ton. Enlever le langage marketing. Vérifier si un post sonne comme s'il était tombé d'un carrousel LinkedIn générique. Le workflow pour ce site commence en général en bazar. Je balance dans Slack ce que je veux dire : quelques observations, une demi-idée, parfois juste du feedback sur un post existant. L'agent va ensuite chercher le bon repo, lit les fichiers pertinents et prend le guide d'écriture du workspace. Ensuite je lui demande une modification concrète : "réécris l'intro", "enlève le langage marketing" ou "rends cette explication technique plus précise". Plus l'instruction est nette, plus le diff est utilisable. Il modifie le markdown sur une branche, lance les checks et pousse la modification vers une PR. C'est là que ma partie recommence. Je lis le diff, je donne du feedback dans Slack et je le laisse traiter le tour suivant. Ce n'est que quand le post est juste que je merge moi-même. L'agent fait le travail préparatoire. Je reste responsable de ce qui passe en live. Un agent qui publie sans que je regarde, ce n'est pas un workflow. C'est une machine à sous avec des droits de commit. ## Pourquoi ça ressent différent du chat Beaucoup d'outils AI donnent l'impression que tu dois amener ton travail vers une fenêtre de chat. Tu copies du contexte, tu colles des logs, tu expliques pour la troisième fois où se trouve le chemin du repo et tu espères que le modèle fasse comme s'il était là. Cette config tourne plus près du contexte. L'agent peut commencer tout seul parce qu'il voit le workspace, connaît la branche, peut lire les règles du site et sait quels checks doivent être lancés. Ça n'en fait pas encore un développeur autonome. Il pousse surtout le premier bout ennuyeux vers l'avant. Pour moi c'est ça la couche agent intéressante : lire en amont, faire une première version, montrer où ça coince. Un collègue junior avec une patience infinie, sans agenda et parfois une confiance inquiétante dans ses propres phrases. Je vais écrire un post séparé là-dessus, parce qu'OpenClaw mérite en fait plus d'explications que ce qui rentre dans ce build-log. Quels canaux il supporte. Quels tools tu lui accroches. Et surtout : pourquoi ça devient intéressant. On glisse lentement de l'AI comme partenaire de sparring vers l'AI comme couche d'exécution. Ces dernières années on parlait surtout aux modèles : brainstormer, résumer, réécrire, réfléchir avec. Ça reste utile, mais la vraie différence est dans les agents qui peuvent exécuter du travail dans des systèmes existants. Les agents ne reprennent pas le travail des gens un pour un. Ce n'est pas aussi simple, heureusement. Le glissement est dans les workflows : trouver des tickets, rassembler du contexte, préparer des drafts, proposer des modifications de code, lancer des checks, rendre compte. Du travail pour lequel tu demandes normalement quelqu'un parce que ça prend du temps, alors que ça demande peu de jugement humain profond. ## Étape suivante : tickets et MCP L'étape suivante, c'est [MCP](https://modelcontextprotocol.io/). Je veux accrocher des tools proprement à ce workflow, en commençant par Linear. Le scénario est simple : un ticket arrive, l'agent lit le contexte pertinent du repo, cherche les fichiers probables, écrit une courte analyse et revient avec une proposition ou une liste de questions. Le merge autonome, je le saute. D'abord je veux savoir où se trouve la limite entre une préparation utile et un zèle d'action dangereux. Après ça viennent GitHub, le contexte du repo et peut-être une knowledge base locale. Certains contextes devraient simplement être disponibles, sans que je les recolle dans un prompt à chaque fois. ## Workflow après workflow Cette config Pi est petite. C'est exactement pour ça que je l'aime bien. Assez petite pour la comprendre. Assez réelle pour en apprendre quelque chose. Assez bon marché pour la laisser allumée tout le temps. Assez locale pour rester proche de mon travail, sans faire comme si le modèle tournait lui-même en local. Pour de l'AI en production chez des clients, c'est au mieux une couche dans l'architecture. Pour mon propre workflow ça marche déjà très bien : Slack comme entrée, OpenClaw comme Gateway, OpenAI comme model-provider, GitHub comme endroit où le travail se retrouve prêt. Dans les temps qui viennent je vais bien bricoler avec ça. D'abord ce site. Ensuite les tickets. Ensuite les tools MCP. Ensuite probablement un truc dont je pense encore maintenant qu'il est trop spécifique pour être automatisé. C'est ça la route intéressante : remplacer workflow après workflow par un agent qui fait le travail préparatoire, rassemble du contexte et prépare des propositions. Étape par étape je développe ma config OpenClaw. Juste comme un assistant pratique qui me retire un peu plus de travail des mains à chaque fois. Et si ça déraille, il est assez proche pour tirer la prise.