Je vais être honnête avec vous. Quand j'ai installé OpenClaw pour la première fois, j'ai fait exactement ce que tout le monde fait. J'ai déployé le système sur un serveur, j'ai configuré une voix très sympa dans Eleven Lab, je lui ai dit "salut" dans le chat, ça m'a répondu et j'ai été impressionné pendant environ 45 minutes. Et puis... rien. L'agent était là, il tournait, il brûlait des tokens, et il ne faisait strictement rien d'utile pour mon business.
Le problème, ce n'est pas OpenClaw. C'est que personne ne prend le temps de le configurer correctement. Les gens installent, ils testent et puis ils passent à autre chose. Résultat : un agent inerte qui occupe un serveur pour rien.
J'ai passé ces derniers jours à transformer cet outil pour qu'il travaille réellement — 24 heures sur 24, 7 jours sur 7, 365 jours par an. Et la différence, c'est pas le prompt. Ce sont cinq décisions de configuration que j'aurais aimé connaître dès le premier jour.
Je sais que c'est tentant. Le Mac Mini est beau, il tient sur un bureau, on a l'impression de "posséder" quelque chose de tangible. J'ai des confrères qui ont dépensé 20K dans des Mac Studios pour faire tourner leurs agents IA dessus. C'est un investissement difficile à justifier.
Votre agent peut tourner sur un serveur distant à quelques euros par mois — ou, si vous avez un profil technique, vous pouvez l'installer sur votre machine principale en virtualisant. Je peux y accéder depuis n'importe où. Toute mon équipe peut y accéder. Si je suis en déplacement à Londres et que quelqu'un a besoin de l'agent, il est là. Essayez ça avec un Mac Mini branché dans votre salon.
Et puis il y a un aspect auquel les gens ne pensent pas : la résilience. Si votre Mac Mini plante — et les disques finissent toujours par lâcher — vous perdez tout. Un serveur distant, vous en déployez un deuxième sur un autre continent et vous avez un backup. J'en ai un en Europe, j'en veux un en Asie. C'est de la décentralisation pure. Le jour où un data center a un problème, le business continue de tourner.
Mon premier réflexe a été de mettre le modèle le plus puissant possible. Opus 4.6. Le meilleur cerveau disponible, vraiment humain. Sauf que dans la pratique, c'était une catastrophe économique.
Le fait est qu'Opus est assez lent. Quand votre agent doit répondre à des gens sur Slack, aller chercher des infos sur le web, analyser des fichiers, le tout en boucle toute la journée — chaque seconde de latence se cumule. Et la facture, n'en parlons même pas. Un heartbeat toutes les 15 minutes avec Opus, c'est absurde. Vous consumez du budget pour rien.
J'ai basculé sur Sonnet 4.5, la différence de qualité est quasi imperceptible pour un usage agentique. Sur le benchmark Computer Use — celui qui mesure si le modèle sait utiliser un navigateur, ce qui est le cœur du travail d'un agent OpenClaw — Sonnet est au coude-à-coude avec Opus. Mais il est tellement plus rapide et moins cher que le retour sur investissement est immédiat.
Le plus beau dans tout ça ? Vous dites littéralement à l'agent : "Passe sur Sonnet 4.5 comme modèle par défaut et redémarre." Il le fait tout seul. Pas de terminal, pas de fichier config à aller chercher. L'agent se reconfigure lui-même. C'est assez bluffant la première fois.
Un mot sur Mistral. Je teste de plus en plus Mistral Large via Open Router, et je suis surpris. Pour les tâches en français, c'est natif — pas de couche de traduction implicite comme avec les modèles américains. Et pour les boîtes européennes qui se soucient de la souveraineté des données, les serveurs sont en Europe. Je l'utilise pas encore comme défaut, mais c'est mon modèle alternatif pour tout ce qui est francophone. OpenClaw gère le multi-modèle nativement, autant en profiter.
Bon, ça c'est le réglage qui a vraiment changé la donne pour moi. Par défaut, OpenClaw utilise Brave comme moteur de recherche. Ce n'est pas mauvais. C'est juste... moyen.
J'ai switché sur Perplexity via Open Router et la qualité des recherches a fait un bond. Mais — et c'est important — il faut comprendre qu'il y a trois produits complètement différents chez Perplexity et la confusion est massive :
Sonar (perplexity/sonar) : c'est le modèle de base. Recherche rapide, résultats corrects, environ un demi-centime la requête. Suffisant si vous voulez juste vérifier un fait.
Sonar Pro (perplexity/sonar-pro) : un cran au-dessus. Meilleur raisonnement, meilleures sources. Environ 2 centimes. Bien pour de l'analyse.
Sonar Pro Search (perplexity/sonar-pro-search) : c'est celui-là que vous voulez. Recherche web profonde avec synthèse multi-sources en temps réel. Environ 5 centimes la requête. C'est le tier agentique.
L'erreur que j'ai faite au début ? J'ai configuré "sonar-pro" au lieu de "sonar-pro-search". Les noms se ressemblent. J'ai mis trois jours à réaliser pourquoi les résultats de recherche de mon agent étaient bons mais pas exceptionnels. Vérifiez dans vos logs Open Router que c'est bien sonar-pro-search qui est appelé. Pas sonar-pro. Pas sonar. C'est un détail qui change tout.
Il y a aussi le Deep Research de Perplexity qui est encore au-dessus, mais chaque requête prend une à deux minutes. Pour un agent qui doit chercher en continu, c'est trop lent. Sonar Pro Search est le compromis idéal.
Le workflow de configuration en deux minutes : créez un compte Open Router, générez une API key avec un plafond à 20$, donnez-la à votre agent, dites-lui de remplacer Brave par Sonar Pro Search et de redémarrer. Testez avec une question d'actu pour confirmer.
Petit détail que j'ai découvert sur le terrain : l'ordre de configuration compte énormément. D'abord le modèle (Sonnet), ensuite la recherche (Sonar Pro Search). Pourquoi ? Parce que quand j'ai voulu configurer le heartbeat juste après, l'agent ne savait pas comment faire. Il a utilisé Sonar Pro Search pour aller chercher la documentation tout seul, l'a implémenté, a redémarré le gateway. Sans intervention de ma part. Si j'avais encore Brave comme moteur de recherche, la qualité des résultats n'aurait probablement pas suffi pour qu'il résolve le problème seul.
Si vous ne retenez qu'une section de cet article, c'est celle-ci.
OpenClaw a un fichier appelé heartbeat.md qui s'exécute automatiquement à intervalles réguliers. Par défaut, c'est toutes les 30 minutes. Et par défaut, il est vide. Donc votre agent se réveille toutes les demi-heures... pour ne rien faire. C'est comme un employé qui met son réveil et se rendort à chaque sonnerie.
J'ai passé le mien à 15 minutes et j'ai mis une instruction dedans :
"Vérifie s'il existe une nouvelle mise à jour officielle d'OpenClaw. Si oui, applique-la, envoie un résumé de ce qui a changé sur Slack, et redémarre le gateway."
Le résultat a été immédiat. Quand Anthropic a sorti Sonnet 4.5, la mise à jour OpenClaw compatible est arrivée quelques heures plus tard. Mon agent l'a détectée à 3h du matin, l'a appliquée, a basculé sur le nouveau modèle et m'a envoyé un message Slack avec le résumé. Au réveil, on tournait déjà sur le meilleur modèle disponible. Personne n'a rien fait. C'est ça, un agent proactif.
Le piège du coût : si vous laissez Sonnet tourner le heartbeat toutes les 15 minutes, vous allez le sentir sur la facture. C'est payer un neurochirurgien pour prendre la tension. Utilisez un modèle économique pour ça — Gemini Flash est gratuit et rapide, MiniMax M2.5 est puissant et très bon marché, ou Mistral Small qui a l'avantage d'être rapide et francophone natif. Préfixez avec openrouter/ dans la config.
Le principe que j'applique maintenant partout : le bon modèle pour la bonne tâche. Sonnet pour les interactions complexes avec l'équipe. Mistral Large pour les tâches en français. Un modèle économique pour les heartbeats. Sonar Pro Search pour la recherche. Un agent bien configuré, c'est pas un soliste — c'est un orchestre.
Un agent qui vit dans l'interface web d'OpenClaw, c'est un outil personnel. Pour que toute l'équipe s'en serve, il faut le mettre dans Slack. J'ai passé un bon moment à résoudre les problèmes, alors je vais vous faire gagner du temps.
Le paramétrage en lui-même n'est pas sorcier :
Allez sur api.slack.com/apps, créez une app from scratch (moi c'est OC1), activez Socket Mode dans la sidebar gauche, générez un App-Level Token avec le scope connections:write. Dans OAuth & Permissions, ajoutez les scopes — les indispensables c'est chat:write, channels:read, et surtout files:read et files:write (sans eux, l'agent comprend pas les images et peut pas attacher de fichiers, c'est un classique). Dans Event Subscriptions, abonnez-vous à app_mention, message.channels, message.groups, message.im, message.mpim. Installez dans le workspace. Donnez les deux tokens à l'agent dans le chat et dites-lui de configurer le gateway et de redémarrer. Créez un channel privé #team-openclaw et invitez le bot.
Jusque-là, ça roule. Sauf que...
Premier piège : le streaming. Les dernières versions d'OpenClaw ont activé le streaming dans Slack — le texte s'affiche token par token, comme dans ChatGPT. Sur le papier, c'est séduisant. En pratique, c'est instable et ça a fait planter mon agent pendant deux heures avant que je comprenne. Si votre agent ne répond pas dans Slack, désactivez le streaming en premier. Vous perdez rien d'important.
Deuxième piège : l'allow list. J'ai voulu restreindre l'agent au channel #team-openclaw via la group policy. Mauvaise idée. Le format attendu par Slack (un objet) ne match pas ce qu'OpenClaw envoie (un array). Le résultat ? Le serveur a crashé. Laissez la policy sur "open" et gérez la sécurité via les permissions du channel privé.
Troisième piège : le debugging. Quand rien ne marche — et ça va arriver — ne paniquez pas. Retournez dans le chat OpenClaw et demandez à l'agent de lire ses propres logs. Il peut diagnostiquer un token manquant, un team ID absent, un scope oublié. J'ai envoyé des captures d'écran de l'erreur Slack directement dans le chat, et l'agent a trouvé le problème en deux itérations. La capacité d'auto-diagnostic d'OpenClaw est la fonctionnalité la plus sous-estimée du produit. Deux ou trois allers-retours et ça marche. L'erreur, c'est d'abandonner au premier essai.
L'infrastructure est posée. Maintenant il faut alimenter le système.
Je vais pas revenir sur la structure des dossiers et le nommage des fichiers, j'en ai parlé ailleurs. Ce qui manque à tout le monde, c'est de savoir quoi mettre dedans. Parce que créer un dossier playbooks/ et le laisser vide, ça sert à rien.
Le journal. C'est l'élément qui m'a le plus surpris. Cinq minutes par jour, je note dans un fichier : qu'est-ce qui a posé problème aujourd'hui, qu'est-ce qu'on a décidé, qu'est-ce qui reste en suspens. Au début je me suis dit que c'était anecdotique. Au bout d'un mois, l'agent avait un contexte temporel que je n'avais jamais vu dans aucun outil. Il savait que le churn avait grimpé début février. Que j'avais pivoté le positionnement le 10. Que le dev senior était parti le 15. Sans ça, l'agent connaît vos process mais il connaît pas votre réalité du moment. Et ça fait toute la différence entre une réponse générique et une réponse pertinente.
Les playbooks. J'ai refait tous les miens. L'ancienne version disait des choses comme "on accueille le nouveau, on lui montre les outils, on fait un point après une semaine". L'agent pouvait rien en faire — c'est trop vague, trop "humain" dans le mauvais sens du terme. La version actuelle, c'est des séquences : Jour 1, créer le compte Slack, l'ajouter à tel et tel channel. Jour 2, call de 30 minutes avec le lead technique. Jour 7, point de suivi avec trois questions précises. L'agent peut tracker ça. Il peut relancer si une étape manque. Mais faut que ce soit écrit comme un programme, pas comme un résumé PowerPoint.
Le fichier des erreurs. "Ne pas refaire la campagne Facebook" — inutile. "Campagne du 12 janvier, CPA à 47€ au lieu de 12€, le ciblage incluait les mineurs et le créatif avait pas de CTA clair" — ça, l'agent peut s'en servir. Le contexte fait la valeur. Sans contexte, une leçon c'est un slogan sur un mug.
La couche opinion. Honnêtement, c'est le plus dur à écrire et le plus puissant. Les principes que vous avez dans la tête et que personne d'autre sait. "Jamais de réduction sur le produit principal — si un prospect négocie, on offre un bonus." "Pas de stock photos, que des captures réelles." "Le ton, c'est direct et technique, zéro bullshit corporate, pas de 'n'hésitez pas', pas de 'solutions innovantes'." Si c'est dans un fichier Markdown, l'agent respecte ces règles dans chaque interaction. Si c'est dans votre tête, c'est perdu — il va écrire du contenu générique.
C'est ça, la vraie compétence des prochaines années. Pas le prompt engineering. La capacité à verbaliser. À sortir ce qui est dans la tête du fondateur et à le transformer en fichiers que l'agent peut lire. J'appelle ça de la traduction cognitive. Et j'y passe entre une et trois heures par jour.
Les premiers jours, j'avais l'impression de perdre mon temps. Au bout de deux semaines, les réponses de l'agent étaient d'un autre niveau. Au bout d'un mois, il anticipait des besoins avant que je les demande. Et ça s'accumule. Chaque fichier ajouté rend l'agent un peu plus intelligent. Contrairement à un doc Google Drive que personne va jamais relire, un Markdown sur le serveur est indexé par le moteur d'embeddings et remonté à chaque interaction pertinente.
Sonnet comme cerveau principal. Mistral Large en renfort pour le français. Sonar Pro Search — pas Sonar, pas Sonar Pro, le Pro Search — pour la recherche. Un heartbeat à 15 minutes sur un modèle économique. Slack pour que toute l'équipe en profite. Et le carburant : des fichiers vivants, pleins d'opinions, de workflows concrets, de contexte quotidien et de leçons durement acquises.
Deux heures de setup. Un serveur. Et commencez à écrire dedans.
La configuration complète prend deux heures. L'écriture des fichiers, c'est un investissement quotidien. Mais c'est là que la magie opère.
Nous accompagnons les entreprises dans le déploiement et la configuration d'agents autonomes OpenClaw.