11 octobre 2026 IA et automatisation 42 min de lecture

J’ai testé OpenClaw pendant deux semaines : voici ce que j’en retiens

Retour détaillé après deux semaines avec OpenClaw : fonctionnement interne, installation isolée, vraie consommation de tokens, abonnements, agent de code Telegram, voix, rédaction et limites.

Auteur: Jeremy Kraft
Publication: 11 octobre 2026
Dernière vérification: 11 octobre 2026
Environnement: OpenClaw · VM Ubuntu isolée · Telegram · GitLab · modèles général et code

Ce qu’OpenClaw ajoute réellement à un LLM

Un grand modèle de langage reçoit du texte et renvoie du texte. Toute la magie apparente part de là. Un agent ajoute une boucle : avec le message, il transmet au modèle la description des outils disponibles. Le modèle ne répond alors pas seulement par une phrase ; il peut demander, sous une forme structurée, d’exécuter une action.

Cette idée reste pour moi un petit choc intellectuel. Nous parlons de modèles qui écrivent du code, analysent une image ou donnent l’impression de raisonner ; pourtant, au cœur du dispositif, il y a toujours une transformation de texte en texte. Dans un chat classique, j’écris une question et je reçois une réponse. Avec un agent, on ajoute simplement — « simplement » avec beaucoup de guillemets — une liste de choses que le système autour du modèle sait exécuter.

Si je lui dis « rappelle-moi d’appeler un client dans une heure », le modèle identifie l’intention, OpenClaw crée la tâche, puis le résultat repart au modèle afin qu’il formule la confirmation. Pour envoyer un e-mail, consulter un dépôt ou piloter un navigateur, le principe reste le même : le modèle conseille, la passerelle exécute, le résultat revient au modèle.

Concrètement, ma phrase devient quelque chose qui ressemble à un appel JSON : nom de l’outil, heure, texte du rappel, éventuellement identifiant de la conversation. La passerelle reçoit cet ordre, crée le rappel et renvoie au modèle un résultat avec son identifiant. Le modèle peut enfin me répondre : « c’est fait ». Même cette dernière phrase est une nouvelle étape. L’agent ne célèbre pas tout seul son succès : il demande au LLM comment me l’annoncer proprement.

Ce détail est important, car il retire une bonne partie du mystère. OpenClaw n’est pas une conscience numérique cachée dans mon serveur. Sans modèle, il ne « pense » pas. C’est une couche d’orchestration qui transporte du contexte, expose des outils, exécute leurs appels et renvoie les résultats. À chaque étape un peu ambiguë, il retourne demander conseil au LLM. Cela explique à la fois sa souplesse et sa consommation.

Les premiers agents fonctionnaient déjà ainsi, mais leur boîte à outils était figée. Pour ajouter l’envoi d’e-mails, un développeur écrivait une fonction SMTP, la déclarait comme outil — éventuellement via MCP — puis redéployait l’application. Le modèle recevait ensuite la description de cette nouvelle fonction avec chaque requête. C’était efficace, mais l’évolution de l’agent restait un travail de développement classique.

On avait donc déjà des agents avant OpenClaw. Quand il leur manquait une fonction, je pouvais ouvrir mon IDE, demander à un assistant de code d’écrire l’intégration, l’enregistrer dans l’application puis redéployer. C’était devenu beaucoup plus rapide qu’avant, certes, mais il restait toujours un humain au milieu pour prendre le code généré et le brancher au bon endroit. L’idée qui traînait dans ma tête était évidente : puisque l’agent sait déjà écrire ce composant, pourquoi ne pourrait-il pas aussi l’installer lui-même ?

Là où OpenClaw devient vraiment intéressant, c’est qu’il sait étendre son propre environnement. Je peux lui demander d’accepter mes messages vocaux : il lit la documentation, inspecte la machine, installe ou configure un composant, ajoute un hook, puis redémarre ce qui doit l’être. Le catalogue d’outils n’est plus figé. L’agent participe lui-même à la création de ses capacités.

La séquence est presque troublante la première fois : je formule le besoin, il va chercher la documentation de sa propre plateforme, repère le fichier de configuration et le type de hook attendu, prépare la modification puis se redémarre. En théorie, je n’ai plus à supplier le développeur de l’agent d’ajouter une fonction dans une prochaine version. En pratique, je deviens précisément la personne qui doit vérifier que l’agent n’a pas raté une virgule avant de se couper lui-même la parole.

C’est grisant. C’est aussi exactement le moment où il faut se méfier : un système capable de modifier sa configuration peut oublier une virgule, produire un JSON invalide et refuser ensuite de redémarrer. Cela m’est arrivé, évidemment.

Pourquoi tout Internet s’est emballé

L’idée d’un agent capable de se compléter lui-même traînait depuis quelque temps dans l’air. Avec les assistants de code, écrire un nouvel outil était déjà devenu beaucoup plus rapide. OpenClaw a supprimé l’étape où je devais prendre le code généré, l’installer, l’enregistrer et relancer le système. L’agent peut lire sa propre documentation, comprendre quel fichier doit changer, préparer le composant et relancer son service.

Forcément, les démonstrations ont circulé très vite. On a vu des assistants trier des boîtes mail, réserver des billets, remplir des formulaires, surveiller des tableaux de bord et coordonner d’autres agents. Puis sont arrivées les promesses habituelles : plus besoin d’équipe, plus besoin de bureau, tout travaille tout seul pendant la nuit. C’est le moment où mon réflexe de vieux technicien se déclenche.

J’ai regardé beaucoup de ces démonstrations. Certaines m’ont donné de très bonnes idées ; d’autres m’ont fait penser : « mon Dieu, il ne faut surtout pas faire cela ». Je ne mets pas tous les auteurs dans le même sac — je ne peux d’ailleurs pas vérifier chaque installation — mais le mécanisme de la ruée est évident. Une vidéo où l’agent réserve un voyage et répond aux clients attire davantage qu’un récit où il crée correctement une branche Git. Pourtant, dans mon travail, c’est la seconde scène qui a le plus de valeur.

Depuis le début de ma carrière, j’ai déjà vu plusieurs technologies présentées comme un changement irréversible des règles du jeu. Les mondes virtuels devaient remplacer les bureaux, la réalité virtuelle devait devenir notre écran principal, et chaque nouvelle vague devait rendre la précédente obsolète. Certaines briques survivent et deviennent utiles. Le grand récit, lui, disparaît généralement beaucoup plus vite.

Je travaille dans l’informatique depuis 2008. J’ai entendu au moins cinq ou sept fois que les règles venaient définitivement de changer. Elles évoluent, bien sûr, mais rarement de la façon annoncée dans la semaine de l’emballement. Ce scepticisme ne m’empêche pas d’utiliser OpenClaw : au contraire, je l’utilise assez pour voir chaque jour de nouveaux cas possibles. Il m’empêche seulement de confondre l’utilité réelle avec la bande-annonce de cette utilité.

Je ne dis pas qu’OpenClaw est un gadget. Je l’utilise réellement plusieurs fois par jour, ce qui est déjà davantage que beaucoup d’outils prétendument révolutionnaires testés puis oubliés. Mais je voulais vérifier une chose plus modeste : où est la valeur quand on retire la démonstration, le montage vidéo et le vocabulaire de science-fiction ?

Pourquoi je n’ai pas installé l’agent sur mon poste principal

Le chemin le plus court serait de lancer le script d’installation sur mon ordinateur de travail, puis de laisser OpenClaw accéder aux fichiers, au navigateur et aux applications. En démonstration, c’est brillant : l’agent retrouve un contrat, en modifie les dates, compare des billets entre Bruxelles et Amsterdam, remplit un formulaire ou réutilise une session déjà ouverte.

La documentation propose effectivement une commande d’installation très courte pour macOS, Linux, WSL ou PowerShell. Elle télécharge les dépendances, installe le service et le place en arrière-plan. C’est confortable, et c’est justement pourquoi je déconseille de la lancer machinalement sur la machine où se trouvent toute votre vie numérique et votre travail. Une commande d’une ligne ne réduit pas le périmètre de confiance : elle le masque.

Sur le papier, le côté positif est formidable. Je peux dire : « retrouve le contrat de ce client, mets à jour la date et les coordonnées, puis renvoie-moi le document ». Je peux lui demander d’ouvrir le navigateur, d’examiner les horaires d’un trajet Bruxelles–Amsterdam et de préparer une réservation avec les informations déjà enregistrées. C’est le fantasme de Jarvis, non plus dans un film, mais assis à côté de mes vrais fichiers et de ma vraie carte bancaire.

Le problème tient dans cette même démonstration : il voit les fichiers, le navigateur et les sessions. Une partie de ce contexte peut partir chez le fournisseur du modèle. Ensuite, il suffit d’une hallucination, d’une consigne mal comprise ou d’une injection cachée dans une page Web pour qu’une vraie action soit déclenchée. Je n’ai aucune envie de confier à un outil encore expérimental les documents de mes clients, mes clés et mon navigateur quotidien.

On peut construire un scénario de film dans lequel le fournisseur du modèle chercherait délibérément mes secrets. Je n’y crois pas beaucoup. Je ne me trouve pas assez intéressant pour qu’une grande entreprise mobilise une opération spéciale contre mon disque. Mais techniquement, la chaîne de confiance existe bien : OpenClaw décrit ses outils et une partie de mon contexte à un LLM distant ; ce LLM propose des appels d’outils ; ma machine les exécute. Donner à ce circuit la possibilité de chercher sur le disque ou d’installer un service mérite autre chose qu’un clic enthousiaste sur « suivant ».

Il n’est même pas nécessaire d’imaginer un fournisseur malveillant. Le scénario le plus crédible est beaucoup plus banal : une page contient une instruction que l’agent prend pour une consigne, un outil reçoit un chemin trop large, ou le modèle comprend « nettoie ce dossier » un peu trop littéralement. Le danger n’est pas seulement que quelqu’un vole mes données. Le danger est aussi qu’un assistant bien intentionné fasse exactement la mauvaise chose avec beaucoup d’enthousiasme.

Les modèles hallucinent. Les meilleurs se trompent moins souvent sur les additions élémentaires, mais ils se trompent encore sur des situations complexes, précisément celles pour lesquelles on leur donne un terminal et un navigateur. Ce n’est donc pas une peur abstraite de l’IA. J’ai vu des personnes demander à OpenClaw de « tout gérer lui-même », puis venir chercher de l’aide quand le service ne démarrait plus. Le modèle n’avait aucune intention malveillante : il avait simplement écrit un mauvais fichier.

Le navigateur augmente encore le rayon d’action. Une session ouverte contient parfois l’accès à des factures, une console d’administration, des moyens de paiement ou des outils internes. Si l’agent sait cliquer à ma place, il peut me faire gagner dix minutes. Il peut aussi transformer une erreur de raisonnement en achat, en message envoyé ou en réglage de production. La commodité et le risque viennent du même privilège.

Je l’ai donc installé sur une petite machine virtuelle séparée. La prochaine étape sera probablement un ancien portable sous Ubuntu, avec son propre utilisateur et son propre navigateur. Pas besoin d’une bête de course : le calcul du modèle se fait chez le fournisseur. Ce qui compte ici, c’est l’isolement. Si l’agent décide de tout casser, je préfère qu’il casse son bac à sable plutôt que mon poste de travail.

Le portable dédié a aussi un avantage très banal : je peux m’y connecter à distance, ouvrir moi-même une page et dire à l’agent « regarde ici » au lieu de lui donner un accès permanent à mon navigateur quotidien. Son utilisateur, son historique et ses sessions lui appartiennent. Il peut au pire abîmer son propre atelier. C’est exactement le genre de frontière un peu ennuyeuse que les démonstrations coupent au montage.

Ce choix évite aussi un malentendu fréquent. Un mini-ordinateur haut de gamme n’est pas indispensable pour faire tourner la passerelle. Au repos, OpenClaw consomme peu ; la partie lourde, l’inférence, s’exécute ailleurs lorsque j’utilise un modèle distant. Un vieux portable, une VM ou un petit serveur suffisent souvent. Je préfère investir dans une séparation propre des comptes et des secrets plutôt que dans une machine impressionnante posée sur le bureau.

À moins de vouloir faire tourner le modèle localement, acheter une machine puissante uniquement pour OpenClaw relève donc davantage du plaisir que de la nécessité. La passerelle n’est pas le moteur : elle tient le volant et appelle le moteur distant. Mon investissement prioritaire reste un environnement que je peux réinstaller, des sauvegardes et des droits que je peux révoquer.

machine ou VM dédiée, sans montage automatique de mes dossiers personnels ;
compte système et profil de navigateur propres à l’agent ;
accès accordés un par un, pour un usage et une durée identifiables ;
secrets séparés, révocables et limités au strict nécessaire ;
configuration versionnée afin de voir exactement ce que l’agent modifie ;
aucun déploiement, achat ou envoi sensible sans validation humaine.

La documentation actuelle fournit des politiques d’outils, des listes d’autorisation, un audit de sécurité et plusieurs modes de sandbox. Il faut les utiliser consciemment : le sandbox d’exécution n’est pas une frontière parfaite et il n’est pas activé automatiquement pour tous les outils d’une installation classique.

La panne la plus bête reste une vraie panne

J’ai vu revenir un problème très simple chez plusieurs personnes : l’agent modifie son fichier JSON, oublie une virgule ou une accolade, puis ne démarre plus. Avec un excellent modèle, cela arrive moins souvent. Avec un modèle moins cher choisi pour économiser des tokens, les erreurs de schéma deviennent rapidement visibles.

Pour un développeur, la réparation prend parfois deux minutes. Je valide le JSON, je regarde le dernier diff et je corrige la faute. Pour une personne qui a installé l’agent justement parce qu’elle ne veut pas toucher à la configuration, l’expérience s’arrête sur un service silencieux. Le même système qui devait se réparer seul ne peut plus démarrer pour lire le message « répare-toi ».

Je garde donc le répertoire de configuration sous Git. Avant une modification importante, je veux savoir ce qui va changer. Après, je regarde le diff. Pour les réglages de démarrage, les permissions et les liaisons de messagerie, je préfère encore éditer moi-même le JSON. Ce n’est pas très futuriste, mais c’est une excellente manière de retrouver un mardi soir tranquille.

Le coût caché : chaque « bonjour » transporte une valise

OpenClaw lui-même est léger. La facture, elle, peut vite prendre du poids. Chaque décision demande une inférence et mon simple « bonjour » ne voyage jamais seul : le modèle reçoit aussi le prompt système, les règles de l’agent, ses outils, ses compétences, une partie de la mémoire et l’historique jugé utile.

Pendant mon test, avec la configuration et les tarifs du moment, une session fraîche commençait autour de 10 000 tokens d’entrée. Réinitialiser la session et recevoir le message d’accueil coûtait environ deux centimes. Créer un rappel simple montait à environ 45 000 tokens et neuf centimes. Demander l’ajout de deux pages dans un projet a consommé environ 263 000 tokens d’entrée, 6 000 de sortie, dont 168 000 servis depuis le cache : autour de quelques dizaines de centimes pour une modification assez modeste.

Pourquoi 10 000 tokens avant même d’avoir commencé ? Parce que « bonjour » arrive accompagné d’une petite valise administrative : qui est l’agent, comment doit-il répondre, quels outils possède-t-il, quelles compétences sont installées, quelles règles s’appliquent, quelle mémoire est pertinente et quelle partie de la conversation doit être conservée. Dans un chat ordinaire, mon mot pèse quelques tokens. Dans un agent, il réveille tout un environnement.

Le rappel à 45 000 tokens paraît encore plus absurde jusqu’à ce qu’on regarde le trajet. Le modèle comprend la demande, choisit l’outil, consulte éventuellement la manière correcte de l’appeler, reçoit le résultat, vérifie que la tâche existe puis prépare une réponse lisible. OpenClaw n’effectue pas tout cela avec un petit moteur déterministe : il sollicite le modèle à plusieurs moments.

Je le formule volontairement de façon un peu brutale : sans LLM, OpenClaw est une machine sans cerveau ni volonté. À chaque embranchement, il retourne voir son conseiller : « qu’est-ce que je dois faire pour que l’utilisateur soit content ? » Puis, une fois l’action terminée : « comment dois-je lui dire que j’ai bien travaillé ? » Cette souplesse est le produit. C’est aussi la ligne de facture.

Tâche observée	Ordre de grandeur	Ce qui gonfle le contexte
Nouvelle session	≈ 10 000 tokens · ≈ 0,02 $	Identité, règles, outils et compétences
Rappel « appeler dans une heure »	≈ 45 000 tokens · ≈ 0,09 $	Choix de l’outil, création, vérification et réponse
Deux pages dans un projet	263 000 entrée · 6 000 sortie	Règles du dépôt, lecture du code, modifications et MR
Tâche de développement longue	Jusqu’à ≈ 1 million en entrée lors de mes essais	Itérations, sorties d’outils, tests et contexte accumulé

Ne prenez pas ces chiffres pour un tarif universel. Le modèle, le cache, le fournisseur et les prix changent. Ils montrent simplement ce qui se passe sous le capot. Avec un paiement à l’usage, une boucle malheureuse devient une facture. Avec un abonnement plafonné, l’agent finit par heurter la limite et s’arrête. C’est agaçant, mais au moins le fusible saute.

Sur des tâches de développement plus longues, j’ai vu le compteur approcher le million de tokens d’entrée, avec des dizaines de milliers en sortie et une partie du contexte servie depuis le cache. Ce n’est pas forcément un million de tokens « nouveaux » au sens humain : les règles, les fichiers et les retours d’outils circulent plusieurs fois. Mais la facturation, elle, additionne bien les passages.

Le plus trompeur est la vitesse. Une modification peut durer cinq minutes et donner l’impression d’un petit service presque gratuit. Pendant ces cinq minutes, l’agent a peut-être lu le dépôt, interrogé le modèle, lancé un outil, relu sa sortie, corrigé son code, exécuté les tests et résumé le résultat. Mon chronomètre n’indique pas la quantité de contexte qui a circulé.

C’est aussi pour cela que je me méfie de la formule « l’agent remplace un salarié ». Il peut absorber une fonction précise, par exemple préparer un résumé, ouvrir une MR ou vérifier une boîte. Si on le laisse raisonner et agir sans arrêt pendant des heures avec un modèle coûteux, l’économie devient nettement moins séduisante. L’agent n’est pas gratuit parce qu’aucune personne ne touche le clavier.

Et quel salarié remplace-t-on exactement ? Celui qui ne fait qu’ouvrir la boîte mail une fois par heure et fabriquer un digest ? Si toute la fonction d’une personne peut être reproduite par une boucle aussi étroite, le vrai problème était peut-être déjà l’organisation du travail. Dans mon équipe, les assistants de code augmentent la production, mais je n’ai licencié aucun développeur. Il est possible que je recrute moins vite pendant un temps ; ce n’est pas la même affirmation que « les agents ont remplacé l’équipe ».

Paiement à l’usage ou abonnement ?

Avec une API facturée au token, je conserve une grande liberté, mais je porte tout le risque d’une boucle ou d’un contexte qui gonfle. Un abonnement limite mieux la catastrophe : quand le quota est atteint, le travail s’arrête jusqu’au prochain renouvellement. Pour expérimenter, ce plafond me rassure davantage qu’une carte bancaire laissée ouverte derrière une automatisation nocturne.

Les abonnements ne rendent pas l’inférence infinie. Les offres abordables ont des fenêtres et des plafonds ; les formules supérieures coûtent vite plusieurs centaines de dollars par mois. Pour une personne, cela peut rester acceptable. Pour une équipe entière, multiplier les comptes et les forfaits change sérieusement le calcul. Il faut comparer le coût avec le temps réellement économisé, pas avec une promesse abstraite d’autonomie.

Au moment de mon test, une formule personnelle d’entrée de gamme permettait surtout d’essayer. Avec un usage agentique soutenu, le quota de quelques heures tombait vite, puis le plafond hebdomadaire arrivait derrière. Les offres beaucoup plus chères donnaient davantage d’air sans devenir illimitées. C’est un point que les tableaux marketing rendent mal : une conversation humaine « active » et un agent qui multiplie les appels d’outils ne consomment pas du tout au même rythme.

À l’échelle d’une entreprise, acheter une grosse formule personnelle pour chaque développeur n’est pas automatiquement la solution optimale, et les contrats professionnels changent encore le calcul. Nous avons fini par centraliser plusieurs modèles derrière notre propre passerelle afin de maîtriser les accès et la dépense. Je ne présente pas cela comme une recette universelle : c’est simplement la conséquence d’un usage collectif où les limites personnelles devenaient trop difficiles à prévoir.

Ma recommandation pour commencer reste donc prosaïque : utilisez d’abord une enveloppe plafonnée. Une limite qui interrompt l’agent pendant cinq heures est frustrante, mais elle vaut mieux qu’une boucle nocturne reliée directement à une facturation sans plafond. Une fois la consommation comprise, on peut décider consciemment d’ouvrir davantage le robinet.

Cron et heartbeat : l’automatisation consomme même quand il ne se passe rien

Mes messages ne sont pas les seuls à consommer. Une tâche planifiée peut réveiller l’agent chaque heure, lui faire vérifier la boîte mail, demander au modèle quoi faire, constater qu’il ne se passe rien, puis se rendormir. Même ce magnifique « rien à signaler » a demandé du contexte, une décision et quelques tokens.

Je réserve donc les automations récurrentes aux contrôles qui justifient vraiment une interprétation par modèle. Une vérification déterministe, une requête API ou quelques lignes de script coûtent moins cher et sont souvent plus fiables. Le LLM intervient seulement lorsque le résultat exige du langage, un classement ambigu ou une décision contextuelle.

Pour reprendre l’exemple de la messagerie : un script peut d’abord demander au serveur s’il existe de nouveaux e-mails. S’il n’y en a aucun, il s’arrête sans appeler le modèle. S’il y en a dix, il transmet uniquement ces dix messages pour classement et résumé. Réveiller l’agent complet toutes les heures pour découvrir une boîte vide est techniquement possible, mais c’est une façon très chère d’apprendre qu’il ne s’est rien passé.

J’ai vu des configurations qui voulaient tout automatiser, tout le temps. Au bout d’un ou deux jours, le quota avait disparu ou la facture avait pris une forme beaucoup moins amusante. Le problème n’était pas une tâche extraordinaire : c’était l’accumulation de petits réveils, chacun accompagné du prompt système, des outils, de la mémoire et d’une demande au modèle. Le coût agentique se cache souvent dans la répétition, pas dans le grand bouton rouge.

Premier usage utile : les rappels qui ne me lâchent pas

Mon usage le plus fréquent est presque banal. Je lui dis : « Rappelle-moi d’appeler ce client dans une heure, puis relance-moi toutes les dix minutes jusqu’à ce que je confirme. » Un calendrier classique sait afficher une alerte. OpenClaw, lui, garde l’intention en tête et continue jusqu’à ma confirmation. C’est parfois pénible. C’est précisément pour cela que ça marche.

Ce n’est pas révolutionnaire, mais c’est une petite friction supprimée. La règle reste la même : le rappel ne doit pas avoir accès à ma messagerie complète, à mon disque et à mon dépôt de production simplement parce qu’il sait relancer une tâche.

Le carnaval des usages possibles

Une fois l’agent connecté au navigateur, à la messagerie, au terminal et aux API, les idées viennent toutes seules. Il peut lire les e-mails, envoyer un rapport, récupérer des métriques, remplir un formulaire, chercher un restaurant, comparer des billets ou superviser d’autres agents. Certaines démonstrations ressemblent presque à un jeu de stratégie : plusieurs personnages numériques se répartissent le code, le déploiement et la surveillance.

Je trouve cela fascinant à regarder. Je ne suis pas certain d’avoir envie de travailler ainsi. Une interface spectaculaire n’est pas forcément un bon processus. Ce que je cherche est plus sobre : prolonger ce que je sais déjà faire, dans les moments où mon clavier n’est pas disponible, tout en gardant un point de contrôle clair.

Dans une communauté privée, j’ai même vu une installation transformée en jeu de stratégie : plusieurs agents se déplaçaient comme des unités, l’un construisait le site, un autre préparait le déploiement, un troisième surveillait le résultat. J’aurais pu regarder la démonstration longtemps. Mais je ne me suis pas imaginé travailler ainsi une seule seconde. C’était une très bonne interface de spectacle, pas nécessairement une bonne journée de travail.

Mon critère est plus pauvre en effets spéciaux : est-ce que l’agent allonge réellement mes bras ? Est-ce qu’il exécute, sous mon contrôle, une action que je sais déjà faire mais que je ne peux pas faire confortablement à cet instant ? C’est sur ce terrain qu’OpenClaw a commencé à gagner sa place chez moi.

Mon vrai cas d’usage : un agent de code dans Telegram

L’idée m’est venue après un incident très banal — le genre qui arrive toujours quand on n’est pas devant son ordinateur. Une erreur d’affichage avait multiplié les prix d’un service. Deux minutes au clavier auraient suffi. Depuis mon téléphone, j’ai voulu modifier le gros composant dans le monorepo, j’ai cassé le déploiement et j’ai dû revenir en arrière pour remettre le service debout.

J’étais en congé, sur les pistes, quand un développeur m’a envoyé la capture. L’accès à ce projet n’était alors configuré que pour moi. J’ai ouvert l’interface Git depuis le téléphone, essayé de diviser les valeurs fautives et réussi surtout à faire tomber l’ensemble du fournisseur, rangé dans le même monorepo. J’ai déclenché le rollback, l’équipe a pu reprendre son travail, et je me suis retrouvé avec cette pensée agaçante : devant mon ordinateur, la correction et le déploiement auraient pris deux ou trois minutes.

J’ai donc construit mon « canot de sauvetage » : un agent de développement joignable dans un sujet Telegram dédié. Il n’a pas le droit de déployer et ne touche jamais directement à la branche principale. Son espace de travail contient un clone du projet. Il crée une branche, modifie le code, lance les contrôles, pousse la branche et ouvre une merge request. Ensuite, je reprends la main : je lis le diff, je teste et je décide du merge.

Le mot « canot » est volontaire. Ce n’est pas mon environnement de développement principal. Devant mon ordinateur, l’IDE et mon assistant de code habituel restent plus rapides, plus confortables et surtout plus transparents. Je veux cet agent pour les moments où je suis en déplacement, où une correction simple devient pénible depuis un téléphone et où attendre plusieurs heures n’est pas raisonnable.

Dans ma configuration, l’assistant général et l’agent de code sont séparés. Le premier utilise le modèle général par défaut. Le second est lié uniquement au sujet du projet et utilise un modèle orienté code. Les liaisons Telegram déterminent quel compte, quel groupe et quel sujet activent quel agent. Les messages privés inconnus sont refusés, l’agent doit être mentionné dans les groupes ordinaires et il répond automatiquement seulement dans son sujet de travail.

Au début, je lui ai écrit dans le nouveau groupe : « tu es là ? ping ». Silence complet. En privé, l’agent m’assurait pourtant que tout devait fonctionner et me proposait des explications de plus en plus imaginatives. La réalité était moins intelligente : dans ce groupe il fallait le mentionner, et le bot devait disposer des droits nécessaires pour lire les messages. Dès que je l’ai tagué, une réaction est apparue et la conversation a commencé.

Cette séparation paraît administrative, mais elle évite que tout le contexte se mélange. Un échange sur un rappel n’a pas besoin des règles du monorepo. Une tâche de code n’a pas besoin de la mémoire de mon assistant général. Le routage par compte, groupe et sujet me permet de choisir le modèle et le workspace avant même que le message soit traité.

Le principe de configuration, débarrassé de mes identifiants, ressemble à ceci :

{
  "agents": {
    "default": { "workspace": "/srv/openclaw/general", "model": "general" },
    "provider-code": { "workspace": "/srv/openclaw/provider", "model": "coding" }
  },
  "bindings": [
    {
      "channel": "telegram",
      "chatId": "<groupe-code>",
      "topicId": "<sujet-projet>",
      "agent": "provider-code"
    }
  ]
}

Ce n’est pas un fichier prêt à copier : les noms exacts dépendent de la version et de l’installation. Il montre la logique qui compte. Le compte Telegram arrive dans un groupe, le groupe contient un sujet, et ce sujet pointe vers un agent précis, un modèle précis et un workspace précis. Le routage est décidé avant que le modèle ne commence à improviser.

J’héberge aussi plusieurs agents sur le même serveur. Chacun possède son identité, son workspace et ses liaisons. Créer une VM par assistant serait inutilement coûteux, mais partager le processus ne signifie pas partager toutes les permissions. Le point essentiel est de pouvoir dire : ce sujet Telegram parle à cet agent, avec ce modèle, dans ce dépôt, et nulle part ailleurs.

Dans mon vrai fichier, le bot principal reste le défaut pour les conversations générales. Le sujet du projet possède une liaison plus spécifique vers l’agent de code. J’ai récupéré l’identifiant du sujet en demandant au système où se trouvait le message courant, puis je l’ai reporté manuellement dans le JSON. J’avais préparé pour la démonstration une copie nettoyée du fichier : afficher un exemple de sécurité avec les vrais tokens à l’écran aurait été une assez mauvaise plaisanterie.

Le dépôt contient aussi un fichier de règles : architecture du monorepo, commandes de test, conventions, création obligatoire d’une branche et d’une MR, interdiction de déployer. Pour une tâche complexe, je lui demande d’abord un plan texte. Le token GitLab est dédié et révocable ; la clé SSH appartient à cet environnement, pas à mon compte principal.

J’ai créé pour lui un compte GitLab séparé, une adresse dédiée, une clé SSH propre et un access token limité. L’agent a généré sa clé et installé le token dans son environnement, mais c’est moi qui ai décidé des droits. Son fichier de règles lui ordonne de créer une branche, de pousser et d’ouvrir une MR. Pour les demandes complexes, il doit déposer un plan avant d’écrire le code afin que je puisse vérifier qu’il a compris le bon problème.

J’ai commencé par un test volontairement ridicule : remplacer un numéro de version par un autre. L’agent a modifié le fichier, créé la branche et ouvert la MR. J’ai lu le diff, fusionné, puis vérifié le déploiement automatique. Ce n’est qu’après cette répétition générale que je lui ai confié les deux nouvelles pages. Un agent ne mérite pas les droits d’un grand projet parce qu’il a réussi une belle phrase dans Telegram.

Ce premier test ne prouvait presque rien sur sa capacité à coder. Il prouvait quelque chose de plus important pour moi : toute la chaîne fonctionnait. Le message atteignait le bon agent, le dépôt était le bon, la branche apparaissait, la MR était visible et le pipeline partait seulement après mon merge. Avant de demander de l’intelligence, je voulais vérifier la plomberie.

Ce qui a fonctionné

Je lui ai demandé de créer une page d’offre et une page de confidentialité provisoire sur le modèle d’une page de conditions existante. Deux minutes plus tard, la MR contenait les deux routes, les textes temporaires et même le sélecteur de thème cohérent avec le reste du site. J’ai ensuite laissé un commentaire demandant de retirer un bloc « brouillon » : l’agent a lu le commentaire, modifié la branche et mis la MR à jour.

Dans Telegram, l’indicateur « écrit… » s’est affiché pendant qu’il travaillait. Sous le capot, il lisait le commentaire, retrouvait la branche, modifiait le fichier et poussait la nouvelle révision. Quand la réponse est arrivée, j’ai contrôlé le diff au lieu de prendre son « terminé » pour une preuve. Le bouton merge est resté sous mon doigt, pas sous le sien.

Ce dernier aller-retour compte davantage que la génération initiale. Une première version de code est facile à montrer dans une démo. Lire un commentaire de revue, retrouver la bonne branche, appliquer une modification limitée puis actualiser la MR ressemble déjà à un vrai morceau de workflow. Je pouvais suivre le résultat dans GitLab au lieu de croire le message « c’est fait ».

C’est exactement le niveau d’autonomie que je recherche. Lorsque je suis devant mon IDE, mon outil de code habituel reste plus rapide et plus transparent. OpenClaw devient intéressant quand je suis dehors, que je peux expliquer la correction par message vocal et que la modification m’attend sous la forme d’un diff vérifiable.

J’insiste sur ce point parce qu’il change complètement la promesse. Je ne vais pas m’asseoir devant mes sept écrans pour dicter du code dans Telegram. À mon bureau, j’ouvre l’IDE, je vois les fichiers et je contrôle la boucle beaucoup plus vite. Cet agent est un canot de sauvetage pour le moment où je suis dans une voiture, dans un train ou loin de mon poste — pas le remplacement théâtral de mon environnement quotidien.

Ce qui n’a pas fonctionné du premier coup

La configuration « automatique » a vite perdu son côté magique. Dans un nouveau groupe, l’agent restait parfaitement silencieux tout en m’assurant que tout devait fonctionner. La cause était toute bête : il fallait le mentionner et lui donner le droit de lire les messages. J’ai fini par corriger le JSON moi-même. Laisser un modèle réécrire sans contrôle son propre fichier de démarrage me semblait être une assez mauvaise façon de terminer la soirée.

La mise en route réelle a demandé plusieurs étapes : créer le groupe et ses sujets, récupérer les identifiants, déclarer les bindings, associer le sujet du projet à l’agent de code, régler les mentions, préparer le workspace, installer la clé SSH et fournir un token GitLab limité. OpenClaw m’a aidé pour une partie de ce travail, mais il ne l’a pas transformé en bouton unique.

Dans les groupes ordinaires, je lui impose une mention explicite. Sans elle, il écoute mais ne répond pas. Dans le sujet réservé au code, la mention n’est pas nécessaire : tout message lui est destiné. Les messages privés provenant d’identités inconnues sont refusés. Ce sont de petits réglages, mais ce sont eux qui font la différence entre un assistant utile et un bot qui intervient partout.

Ce détail résume bien OpenClaw : il peut effectuer une modification de code convaincante, puis halluciner à propos de sa propre configuration. L’intelligence n’est pas uniforme. Je vérifie donc les permissions, les fichiers modifiés et le résultat réel, pas seulement la réponse rassurante du bot.

Les messages vocaux : l’extension qui change l’usage mobile

Je voulais parler à l’agent plutôt que taper un cahier des charges sur mon téléphone. OpenClaw peut examiner les ressources disponibles et proposer Whisper en local. Ma petite VM n’était pas adaptée à cette transcription, alors je lui ai fourni la documentation de notre service de transcription existant.

Dans notre infrastructure, ce service n’est pas un simple appel direct à un modèle. Nous avons une passerelle interne pour plusieurs fonctions d’IA : transcription, LLM et génération d’images. Pour la voix, elle essaie d’abord une ressource interne, bascule vers un autre moteur si celui-ci échoue, puis seulement vers un service payant. Certains traitements sont asynchrones : on crée une tâche, on attend, puis on récupère le résultat. Il fallait expliquer toute cette plomberie sans laisser OpenClaw en inventer la moitié.

L’agent a posé quelques questions, ajouté un hook et modifié sa configuration. Désormais, un vocal Telegram passe d’abord par le transcripteur ; le texte revient dans la boucle normale et devient une instruction comme une autre. Les changements restent versionnés, ce qui me permet de contrôler précisément les hooks ajoutés.

Notre transcripteur fonctionne de manière asynchrone : il reçoit le média, crée une tâche, attend le résultat puis renvoie le texte. Au lieu d’expliquer oralement ce protocole à l’agent, j’ai demandé à mon assistant de code d’en produire une documentation d’intégration détaillée à partir d’un projet existant. J’ai donné ce document à OpenClaw, répondu à ses questions, puis je l’ai laissé préparer le branchement.

J’avais déjà un petit bot interne qui utilisait cette passerelle : on lui envoyait un vocal, il le transcrivait et remettait légèrement les idées en ordre. J’ai donné le code de ce bot à mon assistant de développement avec une consigne très précise : rédige un document d’intégration, décris l’authentification, le format des tokens, la création de tâche, l’attente du résultat et les cas d’erreur. Ce fichier Markdown est devenu le contrat entre notre service et OpenClaw.

Le pipeline final est simple à lire : un message arrive de Telegram ; s’il contient un vocal, le hook l’envoie au service de transcription ; le texte obtenu remplace le média dans la boucle normale. À partir de là, l’agent traite ma voix comme n’importe quelle instruction écrite. C’est exactement le genre d’extension qui justifie le projet : elle change concrètement mon usage lorsque je suis loin du bureau.

Je pouvais observer les requêtes arriver chez nous, la tâche de transcription se terminer, puis le texte revenir dans OpenClaw. Le résultat n’était donc pas seulement « le bot affirme qu’il comprend les vocaux ». Je voyais le trajet réel. Et comme la configuration d’OpenClaw est versionnée, j’ai pu lire le hook ajouté et la règle qui l’insère dans le pipeline avant le traitement normal du message.

Tout n’est pas resté parfait. La veille de l’enregistrement, j’expérimentais encore avec les hooks et j’ai momentanément cassé le traitement des vocaux. C’est presque une démonstration idéale du produit : très puissant, réellement pratique, et suffisamment modifiable pour que je puisse moi-même le rendre inutilisable avant d’aller dormir.

Ce fut le meilleur exemple de sa capacité à s’étendre : je n’ai pas écrit l’intégration à la main, mais je n’ai pas non plus donné une permission aveugle. J’ai fourni une interface documentée, un token limité et un dépôt sous contrôle de version.

Deuxième usage utile : préparer mes publications sans perdre ma voix

J’écris depuis longtemps pour mon canal. J’ai exporté mes anciennes publications en JSON, puis demandé à un modèle d’en extraire un guide de style détaillé : rythme, tournures, structure, transitions et défauts à éviter. J’ai placé ce guide dans le prompt d’un agent réservé à la rédaction.

À une époque, je publiais pratiquement tous les jours. Puis le coût de la première version — ouvrir la page, mettre les idées dans l’ordre, trouver l’angle — a fini par ralentir le rythme. C’est ce problème très ordinaire que je voulais résoudre. Pas créer une machine qui aurait mes opinions à ma place, mais raccourcir le chemin entre une idée enregistrée en marchant et un brouillon que j’ai envie de corriger.

L’export compte beaucoup. Je ne lui ai pas demandé d’imiter trois publications choisies parce qu’elles me plaisaient. Je lui ai donné des années de textes, avec mes habitudes, mes répétitions et mes défauts. Le modèle a transformé cette matière en consignes exploitables. Ensuite seulement, j’ai créé un sujet séparé pour la rédaction, comme je l’avais fait pour le code.

Je ne lui dis pas seulement « écris sur OpenClaw ». Je lui envoie un brouillon, des points clés ou un long message vocal. Il produit une structure et une première version proches de mon ton. Je reprends ensuite le texte, je remplace certains passages et je décide seul de publier.

Pour la démonstration, j’aurais pu lui demander un vague « écris un post sur les dangers d’OpenClaw ». Dans la vraie vie, ce n’est pas ainsi que je travaille. Je lui donne des fragments, des objections, une anecdote et parfois une conclusion encore confuse. Il fait surtout le travail de montage. Si je n’apporte ni faits, ni position, ni aspérités, il me rend exactement ce que je mérite : un texte lisse que n’importe qui aurait pu signer.

Je ne prétends pas qu’il écrit à ma place. Il fait disparaître la page blanche et me livre un squelette suffisamment bon pour commencer. Après, je coupe, je réécris et je remets mes propres aspérités. Le contenu, le jugement et la responsabilité restent chez moi ; la machine m’évite surtout la première heure pénible.

Le gain s’est vu immédiatement : j’ai recommencé à produire des brouillons régulièrement. Ce n’est pas parce que l’agent serait devenu auteur. C’est parce que le moment le plus coûteux pour moi — transformer un tas de notes en structure — est devenu plus court. Ensuite, je peux consacrer mon énergie à ce que l’agent ne possède pas : mon expérience, mon niveau de doute et la décision d’assumer publiquement chaque phrase.

Le flux qui fonctionne le mieux n’est d’ailleurs pas « donne-moi un sujet ». Je lui envoie mes idées dans le désordre, parfois sous forme de bullet points, parfois dans un long vocal enregistré en marchant. Il remet les éléments dans un ordre lisible et propose un texte. Plus mon brouillon contient une opinion et des exemples personnels, moins le résultat ressemble à une soupe générique.

« Il apprend tout seul » mérite une astérisque

OpenClaw peut installer des composants, modifier ses fichiers et enrichir ses compétences. Dire qu’il « apprend tout seul » reste néanmoins un raccourci. Il ne devient pas spontanément plus sage. Il applique une demande avec les outils et le modèle dont je lui ai donné l’accès. Une mauvaise consigne ou un mauvais modèle produit simplement une nouvelle erreur dans un système désormais plus complexe.

Les versions récentes ont justement resserré le comportement par défaut. Pour obtenir le profil le plus permissif, il faut l’activer volontairement dans la configuration. Je trouve ce frein sain. Une installation neuve doit commencer par discuter et observer, pas par disposer immédiatement du terminal, du navigateur, des secrets et de tous les fichiers.

Autrement dit, le raccourci « il se rend lui-même plus intelligent » mélange plusieurs choses. Il peut lire une documentation, installer un paquet, créer un skill, ajouter un hook ou modifier un prompt. C’est une capacité d’extension très puissante. Mais son jugement continue de dépendre du modèle, du contexte et des permissions. Ajouter une nouvelle clé à une boîte à outils ne garantit pas que l’utilisateur saura choisir la bonne serrure.

Ma règle est progressive : d’abord un canal, puis un workspace vide, puis un dépôt de test, ensuite une clé limitée, et seulement enfin un workflow utile. À chaque étape, je regarde les logs et les fichiers modifiés. L’autonomie n’est pas un interrupteur que j’allume ; c’est un périmètre que j’élargis après avoir vu le comportement réel.

C’est peut-être ma déformation professionnelle : je n’aime pas qu’un logiciel, un prestataire ou même une personne dispose d’un contrôle complet sur mes appareils. Je ne prétends pas imposer ce point de vue. Je dis seulement, avec toute la modestie nécessaire, qu’il est absolument correct et que les autres sont faux. Plus sérieusement : si vous choisissez une autre politique de risque, choisissez-la au moins en connaissance de cause.

L’envie d’automatiser tout est un piège

OpenClaw provoque un syndrome très reconnaissable : dès qu’il fonctionne, on veut le brancher partout. Cela me rappelle le jour où j’ai obtenu mon permis : j’avais envie de prendre la voiture même pour le magasin situé de l’autre côté de la rue. C’était plus cher, parfois plus lent et objectivement absurde, mais j’avais envie de conduire.

À pied, le trajet était gratuit, probablement plus rapide après avoir compté le stationnement, et même meilleur pour ma santé. En voiture, je dépensais du carburant, cherchais une place et ajoutais une nouvelle occasion d’accrocher quelque chose. Pourtant je prenais la voiture, simplement parce que j’avais enfin le droit et l’envie de m’en servir. L’enthousiasme OpenClaw produit exactement cette démangeaison technique.

Pour beaucoup de tâches, OpenClaw est exactement cette voiture. On pourrait marcher — ou, ici, écrire quelques lignes de script, poser un webhook, lancer une fonction planifiée. Ce serait moins amusant, mais plus simple, plus prévisible et moins cher. Je garde l’agent pour les demandes qui changent, se décrivent mieux en langage naturel et obligent plusieurs outils à travailler ensemble.

OpenClaw est pertinent	Un script est préférable
La demande change et arrive en langage naturel	Les entrées et les sorties sont fixes
Plusieurs outils doivent être orchestrés	Une API ou une commande suffit
Le résultat peut être relu avant action	L’action doit être parfaitement déterministe
Le gain dépasse le coût des inférences	La tâche tourne souvent sans événement nouveau
Le périmètre est isolé et réversible	L’agent aurait besoin d’un accès global au poste

Ce que je retiens après deux semaines

Après deux semaines, OpenClaw n’a remplacé ni mon équipe ni mon travail. En revanche, il transforme un vocal en MR, insiste quand j’ignore un rappel, assemble le premier brouillon d’un texte et relie un outil documenté à un canal de discussion. Ce n’est pas une révolution quotidienne. C’est déjà suffisamment utile pour que je continue à lui parler.

Je continuerai à l’utiliser et à lui ajouter des capacités. Mais chaque nouvelle capacité devra répondre à trois questions : est-elle réellement plus efficace qu’un script ? Combien peut-elle coûter dans le pire cas ? Quel est le dommage maximal si le modèle se trompe ?

Je vais probablement continuer à casser des hooks, à comparer des modèles et à trouver de nouveaux usages. La différence est que je ne cherche plus une démonstration dans laquelle OpenClaw paraît tout-puissant. Je cherche des automatisations un peu ennuyeuses qui résistent à une vraie semaine de travail. Mes deux réussites actuelles — le canot de sauvetage pour le code et l’assistant de rédaction — sont précisément de cette espèce.

Je ne cherche donc plus « un agent qui peut tout faire ». Je préfère plusieurs petits agents, chacun avec son modèle, son sujet, son dépôt et ses permissions, avec une validation humaine aux endroits où une erreur fait mal. C’est moins magique, nettement moins vendeur — et, à mes yeux, beaucoup plus sérieux.

Références techniques

À propos de l’auteur

Jeremy Kraft administre les infrastructures et les services auto-hébergés de l’IBCSC. Ces guides reprennent des configurations réellement déployées, revérifiées avant publication.

Poser une question Tous les guides

Discussion

Commentaires

Aucun commentaire pour le moment. Vous pouvez ouvrir la discussion avec une question ou un retour d’expérience.