Les créateurs d'agents IA promettent la confidentialité : Muse de Meta et Dots d'OpenAI tiendront-ils parole ?

Le 10 octobre, Hayden Field, journaliste senior IA de The Verge, a décrit une scène pleine d'ironie. Lors du DevDay d'OpenAI cette année, le PDG Sam Altman a présenté le nouvel agent de l'entreprise, Dots, et affirmé devant le public qu'OpenAI veut « fixer une nouvelle norme de confidentialité pour l'IA de pointe ». Selon l'article, OpenAI a passé la journée à lancer des piques voilées à son principal concurrent, Muse de Meta, accusé de ne pas protéger les données des utilisateurs. Or, quelques mois plus tôt, Muse s'était lancé comme une alternative soi-disant plus sûre à son prédécesseur OpenClaw, et Mark Zuckerberg avait promis qu'il était « conçu dès le départ pour la confidentialité et la sécurité ». Une chaîne de promesses apparaît : Muse se positionne contre OpenClaw, Dots contre Muse, et chaque génération se présente comme le correctif de sécurité de la précédente. Un mot de méthode. Cette analyse repose sur la partie publique de l'article. Tout ce qui est dit ci-dessous sur le fonctionnement interne des agents relève de l'inférence et ne prétend pas qu'une entreprise ait divulgué des détails techniques. Cela posé, la contradiction centrale saute aux yeux. L'article plante le décor sans détour : les entreprises accumulent les données personnelles de leurs clients, les cyberattaques sont monnaie courante, et pourtant les laboratoires d'IA cherchent à convaincre les utilisateurs de partager encore davantage d'informations avec leurs agents. Le secteur réclame une confiance plus profonde en utilisant le slogan « nous sommes plus sûrs que les autres » comme clé pour l'obtenir. La confidentialité n'est plus une note de bas de page pour les juristes. Elle est devenue un argument phare du produit et, au DevDay, un élément de langage dirigé contre un rival nommé.

Pourquoi un agent aiguise-t-il le problème ? Le raisonnement découle de la forme même du produit. Un chatbot ordinaire traite ce que l'utilisateur choisit d'y coller. Un agent tire sa valeur de l'action : lire les courriels, organiser l'agenda, fouiller les fichiers, manipuler des comptes. Pour cela, il lui faut un accès durable, large et souvent transversal aux applications. Plus la surface de données est vaste, plus une erreur coûte cher. Plus la permission est grande, plus l'agent attire les attaquants. Quand un même produit peut lire et agir, une faille peut passer de la fuite d'informations à des actions menées au nom de l'utilisateur. Pour un agent, la promesse de confidentialité n'est donc pas un bonus, mais la condition préalable à toute délégation. Voilà pourquoi trois produits surenchérissent sur la sécurité. Entre la promesse et sa réalisation se trouve la vérifiabilité. Une formule comme « conçu pour la confidentialité » ne peut pas être testée lorsqu'aucun mécanisme ne la soutient. Une ingénierie sérieuse de la vie privée se manifeste par des pratiques que des tiers peuvent contrôler. Les données de l'utilisateur ne servent pas à entraîner les modèles par défaut, ou au moins une option de refus claire existe. Les permissions sont limitées tâche par tâche au lieu d'être accordées d'un bloc. Les données sensibles sont traitées au plus près de l'utilisateur. Un journal d'accès exportable indique ce que l'agent a lu et fait. Des auditeurs indépendants examinent la sécurité, et les incidents sont divulgués vite et complètement. Cette liste est un cadre d'évaluation, non une description de ce que font réellement Dots ou Muse. Le test équitable pour les deux entreprises est de savoir si elles inscriront de tels mécanismes dans la documentation produit, et pas seulement dans les phrases d'une keynote.

Le récit « chaque génération est plus sûre que la précédente » comporte aussi un risque structurel. Quand la confidentialité devient une publicité comparative, l'étalon de la sécurité est fixé par les échecs du rival. Une entreprise paraît fiable dès que l'autre trébuche, et l'incitation glisse vers « ne pas être pire que les autres » plutôt que « être réellement assez bon ». Si l'un des trois subit une fuite grave, le dommage ne restera pas chez lui : il touchera la crédibilité de toute la catégorie des agents, et les utilisateurs réfléchiront à deux fois avant de confier leur messagerie et leurs fichiers. Muse s'est posé en successeur sûr d'OpenClaw et se voit aujourd'hui critiqué par le créateur de Dots. Cela montre à quelle vitesse une telle position peut être renversée par le prochain entrant. Plus la promesse est forte, plus les utilisateurs ont de raisons d'exiger des preuves, et plus les régulateurs ont de raisons de poser des questions.

Pour les particuliers comme pour les entreprises, la démarche pratique consiste à transformer la promesse en questions vérifiables une à une. Les données servent-elles à l'entraînement par défaut ? Peut-on les supprimer en une étape ? Les permissions sont-elles divisibles finement ? Existe-t-il un journal d'audit ? Qui doit prévenir les utilisateurs après un incident ? Tant que ces questions restent sans réponse claire, il est raisonnable de cantonner les agents à des tâches peu sensibles et d'élargir leur autorité par étapes. Pour le secteur, une vraie nouvelle norme ne naîtra pas sur la scène d'une keynote, mais d'une ingénierie et d'une transparence que des tiers peuvent vérifier. Dots fixe-t-il la norme décrite par Altman, et la prétention de Muse d'avoir été conçu dès l'origine pour la confidentialité tient-elle ? Seuls le temps et un examen indépendant le diront. D'ici là, un point mérite d'être retenu : plus un agent devient capable, plus il exige de confiance, et la confiance se construit sur des preuves. Elle ne s'emprunte pas d'avance à un slogan.