OpenClaw peut transformer ton agent IA en cauchemar de partage de mots de passe

À quel point fais-tu confiance à ton équipe ? Lui donnerais-tu le mot de passe de ta banque ? Si tu ne fais pas attention avec l’IA agentique, c’est en gros ce que tu fais. Sauf que ce « membre de l’équipe » est un logiciel qui peut agir plus vite que tu ne penses, et commettre des erreurs à la vitesse d’une machine.

J’adore la promesse des agents. Je construis Notis parce que je crois sincèrement qu’on va vers un monde où le logiciel ne se contente pas de te dire des choses : il les fait pour toi. Mais dès qu’un agent peut faire du vrai travail, la sécurité cesse d’être une note de bas de page et devient le produit.

La vérité qui dérange sur l’IA agentique

Le logiciel classique est déterministe : tu cliques sur un bouton, il exécute le même chemin de code à chaque fois. Les agents, c’est différent. Ils raisonnent sur des entrées désordonnées, interprètent une intention et décident de la suite. C’est ça, la magie. C’est aussi ça, le risque.

En pratique, beaucoup de configurations d’agents finissent avec un même schéma dangereux : un endroit unique où tu « lui donnes juste l’accès » pour qu’il puisse se rendre utile. Un token ici. Une clé API là. Un plugin qui peut exécuter du code. Un navigateur qui peut cliquer sur des boutons. Un système de fichiers qui peut tout lire. Ça paraît progressif, jusqu’au moment où tu lèves la tête et réalises que tu as créé un super-utilisateur qui a des problèmes de mémoire.

Pourquoi OpenClaw est puissant, et pourquoi cette puissance est à double tranchant

OpenClaw est enthousiasmant parce qu’il transforme un LLM en quelque chose de plus proche d’un vrai opérateur. Il peut se connecter à des outils, récupérer du contexte et agir. C’est le rêve : ton assistant n’est pas juste une fenêtre de chat, c’est un exécutant.

Mais pas d’exécution sans capacités, et pas de capacités sans identifiants. Dès que tu branches un agent sur ta boîte mail, ton agenda, tes documents, ton CRM, tes paiements, tes serveurs, tu passes de « l’IA écrit du texte » à « l’IA détient les clés ».

Si tu configures tout parfaitement, isoles l’environnement d’exécution, réduis les permissions au minimum et audites chaque action, tu peux faire tourner ce genre d’outil en sécurité. Le problème, c’est ce qui se passe en pratique. La plupart des gens ne traitent pas un projet d’automatisation du week-end comme une infrastructure de production. Et les agents ne s’arrêtent pas poliment à la limite du raisonnable : ils utilisent tout ce qu’ils peuvent pour faire le travail.

L’analogie du mot de passe partagé n’est pas une métaphore, c’est un modèle de menace

Quand tu confies des identifiants larges à un agent, tu acceptes implicitement au moins trois types de risque :

Premièrement : la fuite accidentelle. Les agents travaillent avec du texte. Le texte est journalisé, copié, collé, résumé, transféré, stocké. Si des éléments sensibles entrent un jour dans le contexte de travail de l’agent, il est étonnamment facile qu’ils réapparaissent là où tu ne le voulais pas, surtout quand tu ajoutes des plugins, des appels d’outils et des intégrations tierces.

Deuxièmement : les entrées malveillantes. Internet est un endroit hostile. L’e-mail est hostile. Les documents publics sont hostiles. Même des fils Slack internes peuvent devenir hostiles si quelqu’un publie un contenu qui contient des instructions destinées à détourner le comportement d’un agent. Si ton agent ingère du contenu non fiable et a le pouvoir d’agir, tu as construit le pont parfait entre « quelqu’un peut t’envoyer du texte » et « quelqu’un peut déclencher des actions dans tes outils ».

Troisièmement : le risque lié à l’écosystème. Dès que tu installes des Skills ou des extensions tierces, tu exécutes en réalité le code de quelqu’un d’autre dans un contexte qui a accès à tes identifiants. Même si toi, tu es prudent, tu dépends désormais de l’hygiène de toute la chaîne : mainteneurs, dépôts, mises à jour et intérêts de parfaits inconnus.

Ce qu’on a appris en construisant Notis pendant un an (pour t’éviter de l’apprendre à tes dépens)

L’un des avantages sous-estimés de travailler avec une équipe qui vit dans l’IA agentique depuis un moment, c’est qu’on s’est déjà cogné à tous les angles vifs. Pas en théorie : en production. Avec de vrais utilisateurs. De vraies données. De vraies conséquences.

Un agent sécurisé n’est pas une fonctionnalité unique. C’est un empilement de décisions ennuyeuses qui finissent par compter :

Comment les permissions sont demandées. Comment les tokens sont stockés. Comment l’accès est délimité. Comment les données sont séparées entre utilisateurs. Comment les actions sont journalisées. Comment tu empêches le contexte d’un utilisateur de déborder sur celui d’un autre. Comment tu fais du chemin sûr le chemin par défaut, parce que les réglages par défaut sont ce que la plupart des gens utilisent vraiment.

C’est la partie qu’on sous-estime facilement quand on est tout excité de « faire tourner un agent ». La sécurité n’est pas ce qu’on ajoute quand la démo marche. C’est ce qui décide si la démo mérite d’être livrée tout court.

Si tu veux quand même faire tourner OpenClaw, fais ça (sérieusement)

Je ne suis pas là pour jouer les oiseaux de mauvais augure. Je suis là pour rendre les compromis explicites. Si tu veux quand même faire tourner OpenClaw, le chemin le plus sûr ressemble bien plus à de l’exploitation qu’à un projet perso.

Commence par l’isolation. Fais-le tourner dans un environnement dédié (une machine séparée, une VM ou une configuration en conteneur) qui n’a pas accès à tes fichiers personnels par défaut. Traite-le comme du code non fiable capable de passer des appels réseau.

Ensuite, applique le moindre privilège. Ne donne pas un passe-partout à l’agent quand une clé de voiturier suffirait. Utilise des OAuth à périmètre limité quand c’est possible. Évite les clés API à longue durée de vie. Crée des comptes de service séparés, avec des permissions restreintes. Segmente les comptes : l’agent qui rédige des e-mails ne doit pas avoir la même identité que celui qui peut déplacer de l’argent ou accéder aux systèmes de production.

Rends les accès révocables et de courte durée. Plus un identifiant est « éternel », plus il devient un passif. Privilégie des tokens que tu peux faire tourner rapidement et révoquer instantanément.

Enfin, audite pour de vrai. Garde des journaux de ce que l’agent a lu et de ce qu’il a fait. Relis les actions. Mets en place des alertes pour tout ce qui semble anormal. Si tu ne sais pas dire ce que ton agent a fait hier, tu ne sauras pas ce qu’il a fait pendant les cinq minutes où il a déraillé.

Le critère que j’applique : est-ce que je le confierais à un collègue ?

Je reviens sans cesse à un test simple : si je ne confierais pas à un collègue le mot de passe de ma banque, mes identifiants root ou mes clés de production, pourquoi les confierais-je à un agent ?

Les agents vont être partout. Les gagnants ne seront pas seulement ceux qui ont les meilleurs modèles de raisonnement. Ce seront ceux qui rendent les agents sûrs dans le monde réel, là où les gens sont débordés, où les configurations sont bancales et où les erreurs arrivent.

C’est ce qu’on construit chez Notis : un assistant qui fait vraiment le travail, sans transformer par accident les identifiants de ton entreprise en secret partagé. Parce que peu importe la qualité de ton équipe et la confiance que tu lui accordes, il y a des choses qu’on ne partage pas.