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

Un agent IA open source est passé de projet du vendredi soir à 200 000 étoiles GitHub en moins de trois mois, dépassant React, Vue et tous les autres dépôts de l'histoire de la plateforme. Ce projet s'appelle OpenClaw. Et il y a de bonnes chances que quelqu'un dans ton 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. 100 000 étoiles en sept jours. Les avocats d'Anthropic ont 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. 16 millions de dollars 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. Même stratégie que Google en 2008, quand ils ont construit Chrome autour de Chromium.

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

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

L'outil a aussi 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 côté 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. 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. 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 ta DSI

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

Pas tous. 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 tes identifiants de base de données, ta boîte mail et tes 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 pareil. 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. Ton 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. Un développeur junior a branché un agent sur l'environnement de "test", celui qui partage ses identifiants avec la production.

La dette technique te ralentit. La dette de contrôle peut couler la boîte. Le jour où un agent fait quelque chose de catastrophique (il 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), ta 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 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 : assez d'autonomie à l'IA pour multiplier le débit par dix mais 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

Tes employés ont déjà tranché la question "des agents ou pas d'agents" à ta place. Ce qui reste, c'est de savoir si ces agents tournent sur une infrastructure que tu contrôles, avec des permissions que tu peux révoquer et des traces d'audit que tu peux lire. Ou sur le laptop personnel de quelqu'un, branché à ton email et ton CRM avec des identifiants dont tu ignorais 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 te 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 :

Commence par cartographier ce qui tourne déjà. Audite les agents installés, leurs permissions, intégrations et identifiants. On ne gouverne pas ce qu'on ne voit pas. Isole ensuite l'exécution des agents dans des environnements cloisonnés sans accès direct à la production. Construis un kill switch unique qui révoque tous les accès agents instantanément et teste-le avant d'en avoir besoin. Trace 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 fais tourner tout ça sur ta 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.