OpenClaw : quand la popularité masque les failles IA

150 000 étoiles GitHub. Plus de 135 000 instances déployées en production. Et un score de sécurité entreprise de 1.2 sur 5. OpenClaw est devenu le cas d’école d’un phénomène que nous observons encore et encore dans l’écosystème IA : la popularité virale d’un outil n’a strictement rien à voir avec sa fiabilité.

Selon Onyx, l’évaluation CLAW-10 — un cadre d’analyse composite couvrant 10 dimensions de sécurité — révèle 8 écarts critiques sur 10 pour OpenClaw. Le seuil minimum pour un déploiement en entreprise est fixé à 4.0. OpenClaw obtient 1.2.

La question n’est plus de savoir si OpenClaw est dangereux. C’est de comprendre pourquoi tant d’organisations continuent de déployer des outils IA sur la seule base du nombre d’étoiles.

Un outil banni par ceux qui s’y connaissent

Meta, Google, Microsoft et Amazon ont tous banni OpenClaw de leurs environnements internes. Ces entreprises disposent d’équipes de sécurité parmi les plus avancées au monde. Quand quatre géants technologiques arrivent indépendamment à la même conclusion, le signal est difficile à ignorer.

Pourtant, des milliers de PME et de startups continuent de déployer OpenClaw sans audit préalable. Le raisonnement est souvent le même : « C’est open source, c’est populaire, donc c’est fiable. » Ce raccourci est exactement celui qui a conduit à la crise Log4j en 2021 — une bibliothèque utilisée par des millions de systèmes, maintenue par deux bénévoles, et dont une faille critique a exposé la moitié d’internet.

L’histoire se répète. La communauté open source produit des outils remarquables, mais la popularité d’un dépôt GitHub mesure l’intérêt, pas la sécurité. Ce sont deux dimensions complètement distinctes. Et les confondre expose votre entreprise à des conséquences concrètes.

Ce que CLAW-10 révèle : huit dimensions en échec

Le cadre CLAW-10 d’Onyx évalue un agent IA sur dix dimensions de sécurité entreprise, chacune notée de 1 à 5. Pour OpenClaw, huit dimensions obtiennent la note minimale de 1 sur 5.

Authentification : 1/5. Aucun mécanisme robuste pour vérifier l’identité des utilisateurs accédant à l’agent.

Autorisation : 1/5. Pas de gestion granulaire des permissions — tout utilisateur connecté a potentiellement accès à tout.

Isolation des données : 1/5. Les données de différents utilisateurs ou projets ne sont pas séparées de manière fiable.

Sandboxing d’exécution : 1/5. Le code exécuté par l’agent n’est pas confiné dans un environnement isolé, ce qui ouvre la porte à des compromissions système.

Conformité : 1/5. Aucune prise en compte de l’AI Act, du RGPD ou de toute autre exigence réglementaire.

Chaîne d’approvisionnement : 1/5. La campagne ClawHavoc a démontré l’ampleur du problème : 1 184 paquets malveillants ont été insérés dans la marketplace d’OpenClaw. Sur les 135 000 instances publiquement accessibles, 63 % présentent au moins une vulnérabilité connue.

Modèle de privilèges : 1/5. L’agent fonctionne avec des permissions excessives par défaut, sans principe de moindre privilège.

Ce n’est pas un outil qui a quelques lacunes à corriger. C’est un outil qui n’a pas été conçu pour un usage professionnel — et que des professionnels déploient quand même.

Le pattern récurrent : adoption virale, puis panique

OpenClaw n’est pas un incident isolé. C’est la manifestation d’un schéma que nous voyons se répéter dans l’écosystème IA. Un outil émerge, génère de l’enthousiasme, accumule des étoiles et des forks, puis des milliers d’organisations l’adoptent sans évaluation. Quelques mois plus tard, un audit révèle des failles structurelles. La panique s’installe.

Ce cycle a un nom : le FOMO technologique. La peur de rater la vague IA pousse des décideurs à déployer des outils avant même d’avoir posé les questions de base. Qui a audité ce code ? Quelles données cet agent peut-il lire ? Quelles permissions lui avons-nous accordées ? Quelle est notre stratégie de sortie si une faille est découverte ?

Ce phénomène touche particulièrement les PME, qui n’ont souvent ni équipe de sécurité dédiée ni processus formalisé pour évaluer la gouvernance de leurs agents IA. Le résultat : des outils déployés en production avec les paramètres par défaut, connectés à des systèmes critiques, sans que personne n’ait vérifié les fondamentaux.

Adopter oui, déployer sans évaluer non

Notre position chez LeCollectif est claire : l’open source IA est une force formidable. Nous l’utilisons nous-mêmes. Nous le recommandons à nos clients. Mais l’adoption d’un outil IA en entreprise ne peut pas se faire sur la base d’un compteur d’étoiles GitHub.

Avant de déployer un agent IA dans votre environnement professionnel, trois vérifications minimales s’imposent.

Exigez une évaluation structurée. Un cadre comme CLAW-10 couvre les dimensions essentielles : authentification, autorisation, isolation, conformité. Si l’éditeur ou la communauté ne fournit pas ces informations, c’est un signal d’alerte.

Vérifiez les permissions par défaut. Un agent IA ne devrait jamais avoir un accès illimité à votre infrastructure. Appliquez le principe du moindre privilège : donnez accès uniquement aux données et aux systèmes strictement nécessaires.

Anticipez la conformité. L’AI Act entre en vigueur en août 2026. Déployer un outil IA sans documentation, sans traçabilité et sans politique de protection des données n’est plus seulement imprudent — c’est un facteur d’exposition réglementaire.

La popularité d’un outil open source est un indicateur d’intérêt. L’évaluation de sécurité est un indicateur de maturité. Ce sont deux choses différentes, et votre entreprise mérite que vous fassiez la distinction.

Vous souhaitez évaluer la sécurité de vos outils IA avant de les déployer en production ? LeCollectif vous accompagne dans l’audit, la gouvernance et la mise en conformité de vos solutions.