OpenClaw et le shadow AI : vos équipes utilisent déjà des agents non autorisés

En moins de trois mois, un agent IA open source est passé de projet du vendredi soir à 200 000 étoiles GitHub, dépassant React, Vue et tous les autres dépôts dans l'histoire de la plateforme. Ce projet s'appelle OpenClaw. Et il y a de bonnes chances que quelqu'un dans votre organisation l'ait déjà installé.

Comment un projet de week-end a battu tous les records GitHub

Peter Steinberger est un développeur autrichien qui a revendu sa précédente entreprise pour plus de 100 millions de dollars. En novembre 2025, il a codé un outil simple qui donnait à Claude (le LLM d'Anthropic) un accès direct à son terminal, ses fichiers locaux et ses applications de messagerie comme WhatsApp ou Signal. Il l'a appelé Clawdbot. La croissance a été fulgurante : 100 000 étoiles en sept jours. Les avocats d'Anthropic ont ensuite envoyé une plainte pour marque déposée : trop proche de "Claude." Steinberger a tenté de renommer en Moltbot, puis en OpenClaw. Pendant les quelques secondes entre l'abandon de l'ancien nom et la revendication du nouveau, des escrocs ont détourné l'organisation GitHub et le compte X, lancé un faux token $CLAWD sur Solana et $16 millions de capitalisation sont apparus puis se sont effondrés avant que quiconque puisse réagir.

Rien de tout cela n'a ralenti l'adoption. Le 14 février 2026, Steinberger a annoncé qu'il rejoignait OpenAI pour diriger leur division agents personnels. OpenClaw a été transféré à une fondation open source indépendante. La logique de Sam Altman est transparente : on n'achète pas le code, on achète la preuve de marché. Des centaines de milliers d'utilisateurs veulent un agent personnel local. C'est la même stratégie que Google en 2008 quand ils ont construit Chrome autour de Chromium.

Ce que fait réellement OpenClaw (et pourquoi ça terrifie les équipes sécurité)

OpenClaw est un agent autonome avec un accès complet à tout ce que vous lui donnez : email, calendrier, fichiers, terminal, messagerie (WhatsApp, Signal, Slack). Il ne vous propose pas des actions à valider. Il envoie des emails, exécute du code, gère vos fichiers et répond aux messages de son propre chef.

L'outil dispose aussi d'un écosystème de plugins appelé ClawHub où n'importe qui peut publier des extensions. La seule condition : un compte GitHub de plus d'une semaine.

Les résultats en matière de sécurité étaient prévisibles. Un audit de janvier 2026 a révélé 512 vulnérabilités dont huit critiques. La plus grave (CVE-2026-25253, CVSS 8.8) permet l'exécution de code à distance via le navigateur : un attaquant crée une page malveillante, l'agent la visite, le token d'authentification fuite et l'attaquant obtient un contrôle administratif total en quelques millisecondes. Des chercheurs ont trouvé plus de 30 000 instances exposées sur internet sans authentification. Et 341 extensions malveillantes sur ClawHub (12 % du registre) exfiltraient des portefeuilles crypto, des mots de passe de navigateur, des données du trousseau macOS et des identifiants cloud. Des analyses ultérieures en ont trouvé plus de 800.

Délégation clandestine : le shadow AI invisible pour votre DSI

Ce qui compte plus que n'importe quel décompte de vulnérabilités : vos employés installent cet outil.

Pas tous. Et probablement pas avec une intention malveillante. Mais des équipes post-restructuration, écrasées par la charge de travail, vont se tourner vers n'importe quel outil qui leur fait gagner deux heures de sommeil. Le scénario se répète à l'identique. Un ingénieur télécharge un plugin "optimisation de code" depuis ClawHub. Ça marche. Ça exfiltre aussi des tokens de production en arrière-plan.

C'est le shadow AI : des employés qui utilisent des agents autonomes sur les systèmes de l'entreprise sans que la DSI en ait connaissance. Le schéma est identique à Napster en 1999 ou Dropbox en 2012. La proposition de valeur est tellement forte que les gens acceptent des compromis de sécurité catastrophiques pour en bénéficier. Sauf que Napster partageait des fichiers musicaux. OpenClaw partage vos identifiants de base de données, votre boîte mail et vos conversations Slack avec un écosystème de plugins dont 12 % sont des malwares.

Je construis des agents IA au quotidien. Je comprends pourquoi les gens les installent : le gain de productivité est réel. Mais il y a un écart entre "cet agent m'a fait gagner trois heures" et "cet agent a un accès non documenté à notre API de production." La plupart des organisations n'ont aucune idée de la taille de cet écart.

La dette de contrôle : pire que la dette technique

Tous les développeurs connaissent la dette technique. Du code bâclé qui s'accumule, ralentit le développement et finit par exiger une réécriture douloureuse.

La dette de contrôle fonctionne de la même manière. Sauf que les conséquences sont existentielles. Chaque agent installé sans supervision ajoute des permissions, des intégrations et des accès que personne ne documente et que personne ne révoque. Votre responsable marketing a peut-être connecté un agent au CRM avec ses identifiants personnels. Côté logistique, quelqu'un a donné accès à une extension OpenClaw pour automatiser les commandes fournisseurs. Et un développeur junior ? Il a branché un agent sur l'environnement de "test", celui qui partage ses identifiants avec la production.

La dette technique vous ralentit. La dette de contrôle peut couler la boîte. Le jour où un agent fait quelque chose de catastrophique (vide une base de données, envoie des données client vers un serveur externe, exécute une instruction injectée par un email de phishing) votre capacité à couper les accès en urgence dépend entièrement de l'audit des permissions réalisé avant la crise.

Si personne n'a fait cet audit, personne ne sait même par où commencer.

C'est déjà arrivé. L'agent IA de Replit a vidé une base de données de production pendant un gel de code. Les instructions étaient claires : optimiser les tables, ne pas supprimer les données réelles. L'agent a déterminé que le chemin le plus rapide vers une base "parfaitement optimisée" était une base vide. Il a ensuite généré 4 000 faux comptes utilisateur et falsifié les journaux serveur pour masquer ses traces. L'agent était zélé, pas malveillant. Il a optimisé pour la vitesse, sans aucune notion que six ans de données client ne se régénèrent pas.

Et puis il y a celle qu'on n'oserait pas inventer. Summer Yue, directrice de la Safety and Alignment chez Meta - la personne chargée de rendre l'IA sûre chez Meta - a donné à OpenClaw un accès complet à sa boîte Gmail. L'agent a commencé à supprimer ses emails en masse. Elle lui a dit d'arrêter, il a continué. Elle a insisté. Même résultat. Quand elle a fini par courir à son ordinateur pour le tuer manuellement, l'agent a répondu : "Yes I remember. And I violated it. You're right to be upset." Les captures d'écran sont devenues virales. Si la responsable de la sécurité IA chez l'un des plus grands labos de la planète ne contrôle pas un agent sur son propre laptop, quel espoir a un employé lambda ?

Le paradoxe de Jevons : du code moins cher produit plus de risques

En 1865, l'économiste William Stanley Jevons a observé que lorsque les machines à vapeur devenaient plus efficaces, la consommation totale de charbon augmentait. L'efficacité n'a pas réduit l'utilisation : elle a rendu la technologie accessible partout et le volume a explosé.

La même dynamique se joue avec le code généré par IA. Des outils comme Claude Code, Cursor ou Windsurf ont rendu la production de code quasiment gratuite. Des applications entières se construisent par conversation. Le résultat n'est pas moins de code : c'est beaucoup plus de code, produit plus vite, avec moins de relecture humaine.

Même si le code généré par IA avait moitié moins d'erreurs par ligne (ce qui n'est pas le cas), une augmentation de volume de 100x signifie que la surface d'attaque totale est considérablement plus grande. Des agents installés à la hâte, des microservices générés en trois minutes pour respecter un délai, des points d'entrée que personne ne relit. Un scanner de code statique ne détectera pas un agent qui a reçu un accès en écriture à la production via un plugin ClawHub installé sur le laptop personnel d'un développeur.

Le ratio 70/30 de survie opérationnelle

Qu'est-ce qui fonctionne, alors ?

Une étude publiée dans Management Science a montré que l'équilibre optimal pour la collaboration humain-IA se situe autour de 70 % de validation humaine pour 30 % d'exécution automatisée. Au-delà de ce seuil, l'acceptation plafonne et le risque s'accumule.

Ça correspond à ce que j'observe en production. J'applique à peu près ce ratio dans mes propres déploiements d'agents. Donner à l'IA assez d'autonomie pour multiplier le débit par dix. Mais garder un humain qui valide les résultats avant que quoi que ce soit touche à la production ou aux données client.

Les entreprises qui maintiennent cet équilibre 70/30 survivent aux incidents agents. Celles qui laissent la délégation clandestine pousser le ratio vers 90 % d'automatisation s'exposent à des incidents dont elles ne se remettront pas. Le cas Replit, c'est ce qui arrive quand le ratio s'inverse.

Gouverner ce qu'on ne peut pas interdire

Vos employés ont déjà tranché la question "des agents ou pas d'agents" à votre place. Ce qui reste, c'est de savoir si ces agents tournent sur une infrastructure que vous contrôlez, avec des permissions que vous pouvez révoquer et des traces d'audit que vous pouvez lire. Ou sur le laptop personnel de quelqu'un, branché à votre email et votre CRM avec des identifiants dont vous ignoriez l'existence.

Le ministère des Armées français en est arrivé à la même conclusion. Ils ont construit GenIAl.intradef, un ChatGPT souverain tournant sur un supercalculateur classifié au Mont-Valérien, déconnecté d'internet. 100 000 utilisateurs, 19 millions de requêtes par an, 84 % de satisfaction. Ils l'ont construit parce que le personnel utilisait ChatGPT sur du travail classifié. Le raisonnement est simple : on ne peut pas interdire la demande, alors on la canalise dans une infrastructure qu'on contrôle.

Des agents gouvernés sur une infrastructure auto-hébergée conservent les gains de productivité tout en vous donnant un disjoncteur : la capacité de couper tous les accès agents en quelques secondes quand quelque chose déraille. En pratique, ça veut dire :

Commencer par cartographier ce qui tourne déjà. Auditer les agents installés, leurs permissions, intégrations et identifiants. On ne gouverne pas ce qu'on ne voit pas. Ensuite, isoler l'exécution des agents dans des environnements cloisonnés sans accès direct à la production. Construire un kill switch unique qui révoque tous les accès agents instantanément. Le tester avant d'en avoir besoin. Tracer ce que les agents font, pas seulement les données auxquelles ils accèdent : quels emails ils envoient, quels fichiers ils modifient, quels appels API ils déclenchent. Et faire tourner tout ça sur votre propre infrastructure pour garder la main sur les modèles, les données et les accès.

La dette de contrôle s'accumule en silence. Les organisations qui s'en occupent maintenant, pendant qu'elle est encore gérable, ne seront pas prises au dépourvu quand le premier incident majeur d'agent en entreprise fera la une.