OpenClaw, c'est quoi ? Fonctionnement, limites et usage en entreprise

OpenClaw est un assistant IA open source qui fonctionne sur votre propre ordinateur ou serveur. Il reçoit des demandes depuis des messageries comme WhatsApp, Teams ou Slack, puis utilise des outils pour lire des fichiers, consulter le web ou agir dans des logiciels. Ce n'est ni un produit Meridiem, ni un employé autonome prêt à diriger une entreprise : c'est un moteur d'exécution qu'il faut configurer, limiter et superviser.

Cette distinction compte. Une démonstration d'OpenClaw peut donner l'impression qu'il suffit de l'installer pour automatiser une PME. En production, le logiciel n'est qu'une partie du système. Il faut encore décider à quelles données il accède, quelles actions il peut exécuter seul et comment une personne reprend la main quand le contexte sort du cadre.

OpenClaw, c'est quoi exactement ?

OpenClaw se présente comme un assistant IA open source qui tourne sur la machine de son utilisateur. Il relie trois éléments : un canal de conversation, un modèle d'intelligence artificielle et des outils capables d'agir.

Le canal peut être WhatsApp, Telegram, Slack, Teams, Signal, iMessage ou une autre messagerie. Le modèle comprend la demande et choisit une suite d'actions. Les outils lui permettent ensuite, selon les droits accordés, de consulter un agenda, parcourir un dossier, lancer une commande ou appeler l'API d'un logiciel.

Un exemple simple : vous lui demandez de préparer la réunion de demain. OpenClaw peut lire le calendrier, retrouver les derniers documents liés aux participants, rechercher les échanges utiles et produire une synthèse. S'il dispose aussi d'un accès en écriture, il pourrait créer un document ou envoyer un message. C'est précisément à cet endroit que la configuration devient plus importante que la démonstration.

OpenClaw n'est donc pas un nouveau modèle concurrent de ChatGPT, Claude ou Gemini. C'est une couche qui orchestre un modèle et des outils. Le modèle peut être remplacé sans reconstruire tout le dispositif. Le dépôt officiel parle d'ailleurs de modèles et de moteurs d'agents interchangeables.

Qui a créé OpenClaw ?

OpenClaw a été lancé par le développeur autrichien Peter Steinberger avec une communauté de contributeurs. Le projet a changé plusieurs fois de nom au début de son histoire, avant d'adopter OpenClaw.

Aujourd'hui, le code est développé publiquement sous l'égide de l'OpenClaw Foundation, une organisation américaine indépendante reconnue comme 501(c)(3). Le projet n'appartient ni à Meridiem, ni à OpenAI. La fondation précise qu'OpenAI figure parmi ses donateurs, sans posséder ni diriger le projet.

La licence du dépôt est la licence MIT. Elle permet d'utiliser, modifier et redistribuer le logiciel sous ses conditions. Open source ne veut toutefois pas dire sans responsabilité, sans coût ou automatiquement sécurisé.

Au 19 septembre 2026, le dépôt openclaw/openclaw comptait environ 390 000 étoiles sur GitHub. Ce chiffre est daté parce qu'il évolue rapidement. Il mesure surtout l'attention de la communauté, pas le nombre d'entreprises qui exploitent OpenClaw de manière fiable.

Pourquoi OpenClaw est devenu aussi visible

La plupart des assistants IA attendent une question dans une page web. OpenClaw se place dans les canaux où l'utilisateur travaille déjà et conserve son état sur sa propre machine. La promesse est concrète : écrire un message depuis son téléphone et demander à son assistant d'agir sur un ordinateur resté au bureau.

Le projet est aussi facile à montrer. Une vidéo où un agent retrouve un fichier, pilote un navigateur ou répond dans WhatsApp rend l'idée d'agent autonome immédiatement compréhensible. On voit la différence avec un chatbot qui se contente de produire du texte.

Enfin, son architecture est extensible. Des compétences et des plugins ajoutent des outils sans modifier le coeur du logiciel. Une communauté peut donc connecter de nouveaux services plus vite qu'une équipe fermée.

Cette souplesse explique l'engouement. Elle crée aussi le principal risque : plus un assistant reçoit d'outils et d'accès, plus une mauvaise interprétation peut produire des conséquences réelles.

Ce qu'OpenClaw peut faire concrètement

OpenClaw devient utile quand une demande exige plusieurs étapes et un peu d'interprétation.

Travailler depuis une messagerie

L'assistant peut recevoir une instruction dans un canal déjà utilisé par l'équipe. Il garde le fil de la conversation et peut revenir avec un résultat, une question ou une demande de validation.

Cette interface réduit la friction, mais elle ne change pas les droits réels. Un message envoyé dans WhatsApp ne donne pas magiquement accès au CRM. Chaque connexion doit être installée et autorisée.

Utiliser des fichiers et des outils

Selon sa configuration, OpenClaw peut parcourir des fichiers, exécuter des commandes, consulter des pages web et appeler des services externes. Il peut par exemple réunir les informations nécessaires à un compte rendu, classer des documents ou préparer une réponse à partir d'un dossier.

Il faut distinguer préparer et exécuter. Préparer un brouillon est réversible. Envoyer l'e-mail, modifier une fiche client ou supprimer un fichier ne l'est pas toujours. Un système sérieux donne ces permissions séparément.

Enchaîner plusieurs actions

Un agent classique ne suit pas seulement une séquence figée. Il peut observer le résultat d'une étape et adapter la suivante. Si un document manque, il peut le signaler au lieu de continuer. Si deux dossiers correspondent à la demande, il peut demander lequel utiliser.

C'est ce qui sépare un agent d'une automatisation purement déterministe. Notre guide sur la différence entre chatbot, agent IA et automatisation détaille cette frontière et aide à choisir l'outil adapté au problème.

Fonctionner à intervalles réguliers

OpenClaw peut aussi servir de moteur à des tâches programmées : préparer une veille, vérifier une boîte de réception ou produire un état périodique. Le résultat n'est fiable que si chaque passage laisse une trace et si l'échec est visible. Une tâche silencieuse qui ne s'est pas lancée reste une tâche non faite.

Ce qu'OpenClaw ne fait pas tout seul

L'installation ne transforme pas un processus flou en organisation autonome. Elle donne un moteur à un cadre qui doit encore être écrit.

Il ne connaît pas vos règles métier

OpenClaw ignore par défaut qui peut approuver une remise, quels clients doivent être traités avec prudence ou à quel moment un dossier doit être transmis à un responsable. Ces règles vivent souvent dans la tête des collaborateurs.

Les écrire est le vrai travail. Il faut définir les critères, les exceptions, les sources qui font foi et les situations dans lesquelles l'agent s'arrête. Sans ce cadre, un agent peut produire une réponse plausible mais contraire à la manière réelle de travailler.

Il ne garantit pas qu'une action est correcte

Un modèle de langage peut mal interpréter une demande, choisir le mauvais fichier ou affirmer qu'une action a réussi alors qu'un outil a renvoyé une erreur. La phrase « c'est fait » n'est pas une preuve.

La preuve doit venir du système concerné : l'e-mail apparaît dans les éléments envoyés, la ligne existe dans la base, le document est présent au bon emplacement. Pour les actions importantes, un second contrôle automatique ou humain doit vérifier l'artefact réel.

Il ne rend pas les données automatiquement privées

Le projet conserve son état, sa mémoire et ses identifiants sur l'infrastructure choisie. Cela apporte du contrôle, mais ne signifie pas que toutes les données restent sur la machine.

Les demandes peuvent partir vers le fournisseur du modèle, et les outils connectés communiquent avec leurs propres services. Les plateformes de messagerie voient aussi les messages qui transitent chez elles. Il faut donc cartographier les flux réels, choisir les fournisseurs et limiter les données envoyées. Le mot « local » ne remplace ni un accord de traitement, ni une analyse de sécurité.

Il ne remplace pas une équipe ou une organisation

Un agent peut accomplir une tâche délimitée. Il ne porte pas spontanément les priorités, les responsabilités et les arbitrages d'une entreprise.

Dans une PME, la bonne cible n'est généralement pas « remplacer un poste ». C'est retirer une suite de gestes répétitifs tout en gardant une personne responsable du résultat. L'agent prépare, classe, recherche ou propose. L'humain tranche les exceptions et les actions engageantes.

Les risques à comprendre avant une mise en production

Le guide de sécurité officiel rappelle que les outils de la session principale peuvent agir directement sur la machine hôte si aucun bac à sable n'est configuré. Ce n'est pas un détail technique. C'est la frontière entre un assistant qui suggère une commande et un système capable de l'exécuter sur vos fichiers.

Des permissions trop larges

Donner accès à toute une boîte mail pour traiter un seul type de message augmente inutilement le risque. Même problème pour un disque partagé, un CRM complet ou un compte administrateur.

Le principe utile est celui du moindre privilège : l'agent reçoit uniquement les lectures et les actions nécessaires à sa mission. Les comptes de service, dossiers et outils sont séparés lorsque cela crée une vraie frontière.

Une instruction cachée dans les données

Un agent lit des contenus qui n'ont pas été écrits pour lui obéir : e-mails, pages web, documents ou pièces jointes. Un de ces contenus peut contenir une instruction trompeuse. Le modèle peut alors la confondre avec la demande de l'utilisateur.

La protection ne repose pas sur une phrase disant à l'agent d'être prudent. Elle repose sur les permissions. Un agent qui ne peut pas envoyer, supprimer ou divulguer une donnée ne pourra pas franchir ces limites, même s'il interprète mal un document.

L'absence de reprise

Une automatisation finit toujours par rencontrer un cas non prévu. Il faut savoir qui reçoit l'alerte, quelles informations lui sont transmises et comment reprendre le dossier sans recommencer depuis le début.

Le système doit aussi savoir revenir en arrière. Une proposition peut être rejetée. Un fichier déplacé peut être restauré. Une opération financière ou un message externe exige un plancher plus strict, car le retour arrière est incomplet.

Ce qu'une entreprise doit préparer avant d'installer OpenClaw

La première étape n'est pas de choisir un serveur. C'est de choisir une tâche.

1. Décrire un résultat observable

« Gérer les e-mails » est trop large. « Classer les demandes entrantes dans cinq catégories et préparer un brouillon pour deux d'entre elles » peut être testé.

Le résultat doit être observable dans l'outil final. On mesure ce qui a été classé correctement, les brouillons acceptés, les exceptions et le temps réellement retiré à l'équipe.

2. Écrire les décisions et les exceptions

Pour chaque cas, il faut préciser la source qui fait foi, l'action autorisée et le comportement attendu en cas de doute. Une liste courte de règles réelles vaut mieux qu'un manuel théorique que personne ne suit.

3. Séparer lecture, proposition et action

Un déploiement prudent commence en lecture seule. L'agent observe et propose. Il gagne ensuite le droit de préparer des changements, puis éventuellement d'exécuter les actions réversibles qui ont été validées sur un volume suffisant.

Les envois externes, les paiements, les engagements contractuels et les données sensibles gardent une validation humaine explicite.

4. Prévoir les traces et le contrôle

Chaque action importante doit laisser une trace compréhensible : ce qui a été demandé, les sources consultées, la décision prise, l'outil appelé et son résultat. Le journal ne remplace pas la vérification, mais il rend l'incident explicable.

5. Nommer la personne responsable

Un agent ne devient pas responsable parce qu'il travaille seul. Une personne doit posséder le processus, arbitrer les exceptions et décider quand les permissions peuvent évoluer.

Sans propriétaire, la première erreur sérieuse transforme rapidement l'outil en démonstration abandonnée.

OpenClaw est-il adapté à une PME ?

Oui, dans un périmètre précis. Non, comme raccourci vers une entreprise entièrement autonome.

OpenClaw est pertinent si la tâche comporte du langage naturel, plusieurs outils et des décisions encadrables. Il l'est moins si une règle classique suffit, si les données ne sont pas accessibles proprement ou si personne ne peut superviser les exceptions.

Pour un prototype personnel, l'installation peut être rapide. Pour la production, il faut ajouter l'identité des utilisateurs, les permissions, la journalisation, les sauvegardes, la surveillance et un processus de validation. Le coût principal n'est pas nécessairement l'hébergement. C'est la conception du cadre opérationnel.

Il existe aussi des alternatives. Une automatisation classique reste préférable pour une règle stable. Un développement sur mesure peut mieux convenir quand l'interface, les droits ou le volume sont très spécifiques. Les assistants proposés directement dans Microsoft 365, Google Workspace ou un logiciel métier réduisent parfois le nombre d'intégrations à maintenir. Le bon choix dépend du processus, pas de la popularité du dépôt.

Ce que Meridiem utilise réellement

Meridiem n'a pas créé OpenClaw. Nous utilisons le projet comme moteur d'exécution dans certains environnements de Speyy, notre agent IA d'action.

La valeur ajoutée n'est pas de rebaptiser le logiciel. Elle se trouve dans le travail autour : décrire le métier, connecter les bons outils, isoler les accès, poser les validations, conserver les preuves et exploiter le système dans la durée. OpenClaw fournit une partie du moteur. Speyy et la configuration propre à chaque entreprise fournissent le cadre dans lequel ce moteur peut travailler.

Cette manière de l'utiliser évite deux erreurs opposées. La première consiste à présenter un projet open source tiers comme un produit propriétaire. La seconde consiste à croire qu'un dépôt open source suffit, à lui seul, à faire fonctionner un processus d'entreprise.

Une PME qui veut tester ce type d'agent devrait donc commencer par une mission étroite, réversible et mesurable. Si le système réussit, ses droits peuvent grandir. S'il échoue, l'entreprise doit pouvoir expliquer pourquoi, corriger la règle et reprendre la main sans perdre le dossier.

Pour voir des exemples de périmètres adaptés, la page solutions IA de Meridiem présente les fonctions où un agent peut être utile. Le choix décisif reste le même dans tous les cas : définir d'abord le travail, puis choisir la technologie.