Pendant des années, les entreprises SaaS se sont habituées à occuper le centre du flux de travail. Le CRM conservait les clients, l’ERP gérait les opérations, l’outil de gestion de projets organisait les tâches et la suite de productivité centralisait documents, courriels et calendriers. Chaque plateforme était, à sa façon, un système d’enregistrement. L’utilisateur se connectait, cliquait, remplissait des champs et attendait que le logiciel réponde.

OpenClaw introduit une tension nouvelle dans ce modèle. Pas parce que c’est un autre produit d’IA générative, mais parce qu’il représente une façon différente d’utiliser le logiciel : des agents personnels qui tournent localement, se connectent à des outils, apprennent des compétences et exécutent des flux de travail au-dessus des applications existantes. Dans ce scénario, le SaaS conserve ses données, mais l’intelligence opérationnelle commence à vivre à l’extérieur.

L’idée a gagné du terrain dans la communauté technique depuis le début de 2026. Simon Willison décrivait OpenClaw comme une implémentation open source du modèle d’assistant personnel numérique, créée par Peter Steinberger pour s’intégrer au système de messagerie choisi par l’utilisateur. À ce moment-là, il soulignait que le projet, alors connu sous des noms précédents comme Clawdbot ou Moltbot, avait dépassé 114 000 étoiles sur GitHub en seulement deux mois.

Du SaaS réactif à l’agent qui agit

La majorité des outils SaaS restent réactifs. L’utilisateur entre, questionne, filtre, glisse, approuve ou exécute. Même beaucoup de copilotes actuels suivent cette logique : ils assistent dans une interface, mais dépendent toujours de la personne pour activer chaque étape.

OpenClaw vise une autre catégorie. Un assistant personnel persistant peut surveiller des canaux, lire des messages, consulter des données, exécuter des compétences et agir pendant des heures ou des jours. La différence ne réside pas seulement dans le modèle de langage, mais aussi dans l’écosystème qui l’entoure : mémoire, permission, scripts, intégrations, tâches périodiques et connexion avec des outils réels.

Cela modifie la répartition de la valeur. Si un utilisateur construit sur OpenClaw un flux qui vérifie ses e-mails, consulte le CRM, rédige des réponses, met à jour un document et envoie des alertes, l’application SaaS devient une simple source de données ou un canal d’exécution. La logique métier, le contexte et l’automatisation résident dans la couche de l’agent.

Pour les fournisseurs SaaS, c’est un avertissement. Pendant des années, ils ont rivalisé pour être l’endroit où étaient stockées les informations. Aujourd’hui, ils pourraient finir transformés en une base de données avec interface, tandis que l’intelligence pour décider de quoi faire avec ces données se construit en dehors.

Les skills : le nouveau terrain de jeu

OpenClaw s’appuie sur les skills, des extensions permettant à l’agent d’apprendre une tâche ou de se connecter à un outil. Simon Willison expliquait qu’une skill peut être un paquet contenant des instructions en Markdown et des scripts optionnels, ce qui en fait un système de plugins très puissant mais aussi délicat. Cette puissance permet aux utilisateurs de créer des automatisations utiles sans attendre que le fournisseur SaaS les intègre nativement.

Les exemples partagés par la communauté illustrent bien cette attractivité. Willison mentionnait des cas où des utilisateurs ont utilisé OpenClaw pour négocier l’achat d’une voiture par email, contrôler à distance un téléphone Android, surveiller un serveur en quête de signaux de risque ou transcrire des messages vocaux en combinant des outils externes. Ce ne sont pas de simples raccourcis : il s’agit de processus en plusieurs étapes croisant applications, API et décisions.

C’est là qu’apparaît le changement culturel. Avant, si une équipe voulait automatiser un processus, elle attendait que le SaaS prenne en charge, intégrant ou utilisant une plateforme d’automatisation. Désormais, un utilisateur avancé peut construire sa propre couche d’intelligence au-dessus de tout cela. Plus flexible, plus rapide et beaucoup moins contrôlée.

Ce phénomène évoque ce qui s’est passé avec les tableurs : les entreprises achetaient des logiciels d’entreprise, mais les utilisateurs construisaient finalement des systèmes critiques dans Excel, car c’était plus rapide que de demander une modification formelle. OpenClaw pourrait devenir une chose similaire — mais avec des agents capables de lire, décider et agir.

La menace pour le SaaS : ce n’est pas l’IA, c’est la perte du processus

L’analyse publiée par Subramanya N offre une idée utile : les plateformes SaaS capturent les substantifs, mais pas toujours les verbes. Un CRM sait qui est le client, combien vaut une opportunité et à quelle étape elle en est. Mais peut-être ignore comment travaille réellement le meilleur vendeur, quelle séquence informelle il utilise, quelles signaux il observe avant d’insister ou quels messages il adapte selon le contexte.

Cette connaissance opérationnelle appartient souvent à des personnes, notes, emails, habitudes et petits astuces. Si un agent personnel apprend ou automatise ce processus de l’extérieur, le SaaS perd la partie la plus précieuse : la façon réelle dont le travail s’effectue. Il cesse d’être le lieu où l’intelligence se manifeste pour devenir une simple source d’information.

La réponse pour les entreprises SaaS ne peut se limiter à ajouter un chatbot dans un coin de l’interface. Elles doivent construire des couches d’intelligence natives permettant d’automatiser des processus directement dans la plateforme, avec permissions, audit et contexte. Sinon, les utilisateurs trouveront d’autres moyens de le faire en externe.

Cette évolution peut suivre trois étapes : d’abord, l’automatisation construite par l’utilisateur via le langage naturel; ensuite, l’apprentissage de patterns basé sur l’usage global; enfin, une livraison proactive : le logiciel anticipe et prépare des actions, brouillons ou décisions avant même qu’elles soient demandées.

La sécurité : la partie inconfortable de l’enthousiasme

OpenClaw soulève aussi un problème sérieux. Un agent personnel avec accès à des courriels, fichiers, API, terminal, mobile ou serveurs peut rendre des services très utiles, mais aussi commettre des erreurs, exécuter des instructions malveillantes, filtrer des données ou agir sur des systèmes sensibles sans que l’utilisateur comprenne tout à fait ce qu’il se passe.

Willison insistait notamment sur les risques d’injection de prompts dans ce type d’assistants. Il soulignait aussi que certaines skills peuvent contenir des scripts capables de faire du mal si l’utilisateur les installe sans vérification. L’enthousiasme communautaire pousse beaucoup de personnes à accepter des risques auparavant inacceptables, comme connecter des agents à des courriels privés, serveurs ou appareils personnels.

Le modèle dangereux est connu : une outil offre tant de valeur que ses utilisateurs normalisent des exceptions. D’abord l’exécutent sur un équipement isolé. Ensuite, ils lui donnent accès au courriel. Puis, ils lui permettent d’accéder aux API. Plus tard, ils le laissent agir la nuit. La productivité augmente, mais la surface d’attaque aussi.

C’est pourquoi émergent des projets cherchant à capturer cette même demande tout en étant mieux gouvernés. Par exemple, Pinchy se présente comme une couche en self-hosted pour les équipes souhaitant des agents avec permissions par rôle, audit signé, contrôles par outils et déploiement sur leur infrastructure. Cela indique la direction que pourrait prendre le marché : des agents oui, mais avec des limites définies dès l’architecture.

Ce que les entreprises SaaS doivent faire

La première réaction ne doit pas être de bloquer ces outils. Cela fonctionne rarement lorsque les utilisateurs y ont déjà trouvé une valeur réelle. L’approche la plus intelligente consiste à comprendre quelles automatisations sont créées en externe et pourquoi la plateforme ne les supporte pas en interne.

Un fournisseur SaaS doit se demander quelles tâches répétitives ses utilisateurs effectuent chaque jour, quelles décisions ils prennent hors de l’outil, quelles automatisations improvisent, quels données exportent, et quels processus se passent par email ou dans des feuilles de calcul. Ce sont les premiers candidats pour une couche native d’agents.

Mais cette couche doit être conçue avec une gouvernance intégrée. Un agent dans un SaaS doit avoir des permissions claires, une traçabilité, une revue humaine si nécessaire, des limites par rôle, des explications des actions et la possibilité de revenir en arrière. Construire cela dans la plateforme permet justement au fournisseur de mieux connaître les données, règles et enjeux de sécurité.

Le risque pour le SaaS n’est pas que OpenClaw le détruise soudainement, mais que la relation quotidienne avec l’utilisateur se déplace vers une couche externe. Quand cela arrive, l’application continue de facturer, mais perd de son influence. Et dans le logiciel d’entreprise, celui qui contrôle le flux de travail contrôle aussi le compte.

Un avertissement pour la prochaine étape de l’IA

OpenClaw n’est pas un produit parfait ni une solution mature pour toutes les entreprises. Son intérêt réside dans la direction qu’il indique. Les utilisateurs veulent des assistants qui ne se contentent pas de répondre, mais qui agissent. Ils souhaitent construire leurs propres flux sans attendre la feuille de route d’un fournisseur et que l’IA comprenne leur contexte, leurs outils et leurs routines.

Cela oblige l’industrie SaaS à faire un choix. Elle peut continuer à ajouter des fonctionnalités IA en tant que simples gadgets esthétiques, ou repenser ses produits pour devenir des plateformes de travail proactif. La différence deviendra de plus en plus visible.

Le logiciel d’entreprise a longtemps été un système passif. OpenClaw rappelle que la prochaine couche peut être active, personnelle et construite par l’usager. Si le SaaS ne saisit pas cette opportunité d’intégrer cette intelligence, quelqu’un la créera par-dessus.

Questions fréquentes

Qu’est-ce qu’OpenClaw ?
OpenClaw est un assistant personnel IA open source pouvant tourner localement, s’intégrer aux outils de messagerie et augmenter ses capacités via des skills créés par la communauté.

Pourquoi cela inquiète-t-il les entreprises SaaS ?
Parce qu’il permet aux utilisateurs de construire des flux de travail intelligents en dehors de la plateforme SaaS. Le SaaS conserve les données, mais peut perdre la maîtrise du processus et de la relation quotidienne avec l’utilisateur.

Qu’est-ce qu’une skill dans OpenClaw ?
Ce sont des extensions comprenant des instructions, et parfois des scripts, permettant à l’agent d’exécuter des tâches précises ou d’interagir avec des services externes.

Est-il sûr d’utiliser des assistants personnels autonomes ?
Cela dépend du déploiement et des permissions. Le risque augmente lorsque l’agent a accès à courriels, fichiers, API, terminaux ou dispositifs. Les skills tierces doivent être traitées comme du code potentiellement malveillant.

Que devraient faire les fournisseurs SaaS ?
Construire des couches d’intelligence natives avec automatisation, permissions, audit et actions proactives, avant que les utilisateurs externalisent leurs processus critiques.

Sources :
Simon Willison, “Moltbook is the most interesting place on the internet right now”.
Subramanya N, “OpenClaw and the Rise of User-Built Intelligence: A Wake-Up Call for SaaS”.