OpenClaw : de l'assistant IA au réseau d'agents — retour terrain

OpenClaw n'est pas un ChatGPT. Ce n'est pas un chatbot qu'on interroge à la console. C'est autre chose — et cette différence mérite qu'on s'y attarde.

Depuis plusieurs mois, BOTUM fait tourner OpenClaw en production pour automatiser ses opérations internes. Ce billet ouvre une série de 7 articles sur ce retour terrain : comment on est passé d'un agent unique à un réseau d'agents spécialisés, ce que ça change concrètement, et pourquoi le self-hosted redevient pertinent en 2026.

1. Ce que tout le monde croit d'OpenClaw — et pourquoi c'est faux

La première réaction quand on présente OpenClaw à un CTO : Ah, comme ChatGPT mais en local ? Non. Pas vraiment.

ChatGPT (et ses équivalents) sont des interfaces conversationnelles. Vous posez une question, vous obtenez une réponse. Vous copiez-collez. Vous retournez dans votre workflow. Le modèle n'a pas de mémoire persistante, pas d'accès à vos fichiers, pas de capacité d'action autonome dans votre environnement.

OpenClaw fonctionne différemment. L'agent a un workspace local — un répertoire sur votre machine ou votre serveur qui est son espace de travail persistant. Il peut lire et écrire des fichiers, exécuter des commandes shell, interagir avec des APIs, piloter un navigateur. Il reçoit des instructions via une interface de messagerie et il agit dans votre infrastructure.

La distinction est fondamentale : on ne consulte pas OpenClaw, on lui confie des tâches.

2. Le concept en 5 minutes

OpenClaw est un runtime d'agent IA self-hosted. Voici ce que ça signifie concrètement :

• Self-hosted : tourne sur votre infra (VM, serveur, laptop). Vos données ne quittent pas votre réseau, sauf les prompts envoyés au LLM de votre choix.
• Multi-LLM : compatible Anthropic Claude, OpenAI GPT-4, Google Gemini, et modèles locaux via Ollama. Vous choisissez — et vous changez sans refactoring.
• Workspace persistant : un répertoire Git versionné. L'agent y lit ses instructions, y écrit ses sorties, y maintient sa mémoire entre les sessions.
• Skills : des modules spécialisés (email, calendrier, navigateur, Docker, GitHub...) que vous activez à la carte. Chaque skill donne à l'agent de nouvelles capacités.
• Interface messagerie : vous interagissez avec l'agent via votre messagerie habituelle — pas besoin d'ouvrir une console ou une interface web dédiée.

Le modèle mental : pensez à un développeur junior très capable, qui a accès à votre terminal, à vos fichiers, à vos APIs — et qui attend vos instructions dans votre messagerie. Sauf que lui ne dort pas, ne prend pas de vacances, et traite 50 tâches en parallèle.

3. Pourquoi self-hosted en 2026 ?

La question revient souvent : pourquoi s'embêter à héberger quand SaaS existe ?

Pour les usages personnels ou les tests rapides, le SaaS a du sens. Mais dès qu'on parle d'automatisation d'opérations réelles — là où l'agent a accès à vos emails, votre calendrier, votre CRM, vos serveurs — le self-hosted devient non-négociable pour plusieurs raisons :

Privacy et souveraineté des données

Un agent qui lit vos emails de clients, accède à vos factures, consulte vos logs serveurs — vous ne voulez pas que ces données transitent par l'infrastructure d'un tiers. Avec OpenClaw self-hosted, seuls les prompts (la question + le contexte minimal) partent vers le fournisseur LLM. Vos données restent chez vous.

Contrôle total de l'environnement

Vous décidez quels tools l'agent peut utiliser, à quels réseaux il a accès, quels scripts il peut exécuter. Pas de feature flag que le vendor active ou désactive. Pas de changement de comportement au prochain update SaaS. Votre agent se comporte exactement comme vous l'avez configuré.

Pas de vendor lock-in

OpenClaw est agnostique au LLM. Si Anthropic augmente ses tarifs, vous switchez vers un modèle local ou un autre fournisseur. Si un nouveau modèle surpasse les autres sur votre cas d'usage, vous l'activez sans changer votre infrastructure. Le runtime reste stable, le modèle est interchangeable.

Coût maîtrisé à l'échelle

Un agent SaaS facture souvent à l'usage ou en abonnement mensuel croissant. Avec le self-hosted, votre coût principal c'est les tokens LLM — et vous optimisez finement : modèles légers pour les tâches mécaniques, modèles puissants pour les tâches complexes. À l'échelle d'un réseau de 15 agents, cette granularité fait une différence réelle sur la facture.

4. De l'agent unique au réseau d'agents

La vraie rupture de paradigme ne vient pas d'OpenClaw en soi — elle vient du moment où vous passez d'un agent généraliste à un réseau d'agents spécialisés.

L'agent généraliste, c'est le couteau suisse. Utile, mais limité : un contexte unique, une session à la fois, des instructions qui finissent par se contredire quand les domaines s'accumulent.

Le réseau d'agents, c'est une équipe. Chaque agent a un périmètre défini, une identité, des règles qui lui sont propres. Ils partagent un workspace commun, se passent des artefacts (fichiers, rapports, états), et opèrent de façon autonome sur leur domaine.

Concrètement sur notre infra BOTUM, ça ressemble à ça :

• Un agent système — surveille la santé de l'infra, gère les commits Git, maintient la mémoire long terme, déclenche les compactions de contexte.
• Un agent email — lit les emails entrants, les classe, génère des digests quotidiens, applique des règles de filtrage métier.
• Un agent calendrier — consulte et met à jour le calendrier, génère des briefings matinaux, coordonne les rappels avec les autres agents.
• Un agent rédaction — rédige les billets de blog, les emails professionnels, les posts LinkedIn — avec le ton maison.
• Un agent facturation — suit les timesheets, génère les factures, rapproche les paiements.

Ces agents ne s'ignorent pas. Ils communiquent via des fichiers partagés dans le workspace, via des files de tâches JSON, via des triggers définis. L'agent système peut demander à l'agent email d'envoyer un rapport. L'agent calendrier peut notifier l'agent rédaction d'une deadline de publication.

Le résultat : une automatisation qui ressemble davantage à une organisation qu'à un script.

5. Ce que ça change dans les opérations

Le bénéfice le plus visible n'est pas la vitesse — c'est la continuité.

Un humain a des heures de bureau, des jours off, des moments où l'attention flanche. Un réseau d'agents opère en continu : le rapport quotidien arrive à 8h15 même si personne ne l'a demandé, le digest email est prêt avant que la journée commence, le monitoring tourne pendant le weekend.

Le deuxième bénéfice : la traçabilité native. Chaque action de chaque agent est loggée dans le workspace (Git versionné). On peut auditer ce qui s'est passé, reproduire une décision, comprendre pourquoi un email a été envoyé ou non. Pas de boîte noire.

Le troisième : la composabilité. Une fois les agents en place, ajouter une nouvelle automatisation revient souvent à configurer un nouveau skill ou à ajouter une règle dans un fichier de configuration — pas à coder un nouveau système from scratch.

Ce n'est pas une transformation instantanée. Les premières semaines, on calibre, on ajuste les périmètres, on découvre les cas limites. Mais passé ce rodage, le gain opérationnel est réel et durable.

6. Ce que cette série va couvrir

Cette série de 7 billets documente notre déploiement OpenClaw chez BOTUM, du plus conceptuel au plus technique :

1. Billet 1 (celui-ci) — Le concept, le self-hosted, et la logique des réseaux d'agents
2. Billet 2 — Installation et configuration initiale d'OpenClaw (workspace, skills, premier agent)
3. Billet 3 — Déployer un réseau d'agents : identités, rôles, workspace partagé, protocoles
4. Billet 4 — Automatiser les opérations : crons, triggers, files de tâches, escalades
5. Billet 5 — Intégrations avancées : email, calendrier, GitHub, Docker, navigateur
6. Billet 6 — Sécurité et coûts : sandboxing, gestion des credentials, optimisation tokens
7. Billet 7 — Retour terrain complet : métriques, erreurs, leçons apprises

On ne vend pas OpenClaw (on n'a aucune affiliation). On documente ce qu'on a construit, ce qui fonctionne, ce qui a planté, et ce qu'on ferait différemment. Pour les architectes et CTOs qui evaluent si ça vaut le coup d'investir dans ce type d'infrastructure — cette série est pour vous.

→ Billet 2 à venir : Installation et premier agent opérationnel en moins de 30 minutes.