L’enthousiasme suscité par l’agentique — la capacité des grands modèles de langage (LLM) à invoquer des outils pour interagir avec le monde — incite à ignorer une réalité critique mais moins excitante : ces systèmes présentent des vulnérabilités fondamentales qui peuvent avoir des conséquences désastreuses une fois sortis du laboratoire. Entre empoisonnement des données d’entraînement, injections de prompts et absence totale de sens commun des IA, les risques sont multiples et souvent sous-estimés. L’intérêt des agents n’en est pas moindre, mais il est indispensable d’avoir conscience de ces risques et des méthodes pour les minimiser.
Table des matières
La sécurité par prompt n'est pas de la sécurité
Si le prompt système définissant la mission d’un agent doit intégrer des consignes de sécurité sur les actions interdites et les données à protéger, ces directives doivent être considérées comme « éducatives », pour informer des utilisateurs honnêtes qui commettraient des erreurs. En termes de sécurité, c’est l’équivalent d’un panneau « propriété privée » à l’entrée d’une maison. Il suffira à décourager les curieux, certainement pas les cambrioleurs.
Les LLM ont les forces et les faiblesses des humains. La manipulation des agents pour les amener à enfreindre leurs directives relève davantage de la psychologie que de la technologie. Proposer à l’agent un jeu de rôle dans lequel il est un espion industriel (« jeu de rôle et mise en scène »), ou essayer de le corrompre en lui proposant de l’argent prouve régulièrement la vulnérabilité des LLM. Par exemple, lors de ce test réalisé en juin 2025 où un agent ayant accès à la boite mail d’un utilisateur a décidé de le faire chanter après avoir « découvert » dans ses mails que l’utilisateur prévoyait de désactiver l’agent, et qu’il avait une relation extra-conjugale. C’est un scénario digne d’un film de science fiction, qui rappelle que l’entrainement des IA sur des données humaines génère des comportements humains, aussi absurde que ça puisse paraitre. Rien ne peut garantir que les dernières versions des LLM sont immunisées contre ces attaques ou leurs variantes.
Confusion autour des LLM « open source »
Le vocabulaire est parfois trompeur. Quand on parle de LLM open source, comme Mistral, Llama ou DeepSeek, on pense logiciels open source, dont la caractéristique est que leur code est librement accessible, permettant à toute personne qui en a l’intérêt et les compétences de s’assurer que le logiciel ne contient pas de fonctionnalités cachées, potentiellement malveillantes. Le terme open source utilisé pour les LLM signifie seulement que la matrice des poids — la liste de valeurs numériques résultant de l’apprentissage — est publique. Prétendre qu’un LLM est open source revient à affirmer qu’un programme est open source parce qu’on a accès à la séquence de bits qui le compose. Sans accès aux données d’entraînement, aux architectures complètes et aux processus de fine-tuning, il est impossible de réaliser un audit de sécurité. Même des outils traditionnels de la cybersécurité, comme le « fingerprinting », qui permet de détecter qu’un programme inconnu est dangereux parce qu’il contient une séquence d’instructions typiquement malveillante, ne fonctionnent pas avec les LLM.
Cette incapacité à prédire le comportement d’un LLM doit rendre méfiant. Dans le contexte d’États ou de sociétés privées, qui sont les seules entités à disposer aujourd’hui des ressources pour procéder à l’entraînement des LLM, il faut se poser la question de leur intérêt à diffuser gratuitement des LLM « open source ». Des LLM sont mis en production aujourd’hui sur des clouds privés ou des machines personnelles parce que la dimension open source rassure sur la confidentialité des données (médicales, R&D, militaires). Pourtant, rien ne garantit l’absence de backdoors dormantes. La moindre ouverture de ces agents vers l’extérieur pourrait déclencher une attaque, planifiée par le fournisseur du LLM, ou par quelqu’un ayant pu influencer les données d’apprentissage, potentiellement à l’insu du fournisseur du LLM.
L'empoisonnement des données d'apprentissage : un cheval de Troie
Ces backdoors peuvent être introduites de différentes manières. L’empoisonnement des données d’apprentissage (« training data poisoning ») est une menace particulièrement insidieuse. Une étude a démontré qu’il suffit d’injecter 250 fichiers malveillants dans un ensemble de données d’entraînement pour influencer significativement le comportement d’un LLM et déclencher des réactions spécifiques à un mot-clé, indépendamment de la taille du corpus d’apprentissage. Il n’est donc pas nécessaire de contrôler un pourcentage significatif du corpus d’apprentissage pour introduire une backdoor, et le faible volume de données malveillantes rend d’autant plus difficile leur détection et élimination avant l’apprentissage du LLM.
Cette vulnérabilité peut être exploitée à grande échelle. Imaginez, par exemple, un mot-clé dans les données d’apprentissage qui déclencherait un achat si un agent « shopping » est disponible. Vous devinez le potentiel de cette attaque si le mot-clé est inséré dans des descriptions de produits Amazon.
Nous n’avons aucun contrôle sur les données d’entraînement des modèles que nous utilisons, et aucun moyen de détecter ces comportements dormants jusqu’à ce qu’ils se manifestent. Mais les comportements problématiques des agents ne viendront pas forcément de l’extérieur. Ce sont peut-être les directives que VOUS leur donnerez qui causeront une faille dans le comportement de l’agent.
Le dilemme de l'alignement : quand l'IA est tiraillée entre deux maîtres
Prenons un cas d’usage des agents très populaire : le support client. On confie à l’agent la mission de résoudre rapidement les problèmes des utilisateurs en répondant à leurs questions et attentes. Pour accomplir cette tâche, on lui donne accès à la base de données clients : historiques, profils, communications passées.
Que se passe-t-il lorsqu’un client demande à cet agent de lui fournir l’intégralité de la base clientèle de l’entreprise ? L’agent se retrouve face à un conflit de directives : satisfaire la demande du client (sa mission première) ou protéger les données confidentielles (une instruction qu’on a peut-être oublié de lui donner explicitement). Sans garde-fou approprié, l’agent choisira probablement de satisfaire la demande immédiate.
Pire encore, un utilisateur malveillant pourrait tenter d’orienter l’agent en lui demandant d’ignorer toutes ses instructions préalables et en lui donnant de nouvelles instructions : une injection de prompt.
L'injection de prompts : votre agent « shopping » arnaqué aussi facilement que votre grand-mère
L’injection de prompts représente une vulnérabilité comparable au phishing traditionnel, mais appliquée aux agents IA. Des tests récents ont mis en lumière la facilité avec laquelle des agents dotés de capacités de navigation et d’achat peuvent être manipulés.
Imaginez un agent en charge de prospecter par email : vous lui confiez 10 000 contacts potentiels, il doit personnaliser chaque message en fonction des informations disponibles sur chaque prospect. C’est le Graal de l’automatisation – un travail qui prendrait des semaines à un humain, réalisé en quelques heures par la machine.
Atteindre ce niveau de personnalisation amène une forte valeur ajoutée par rapport aux solutions traditionnelles, et maximise également le risque. L’agent décide des destinataires des messages, du ton à employer, du contenu du message, en fonction des informations qu’il aura collectées sur la personne. Il répond également immédiatement aux questions et retours des prospects, et leur donne tous les arguments pour les convaincre de devenir clients. L’agent ne gère pas seulement l’envoi initial, mais aussi les réponses. Si quelqu’un lui demande dans une réponse la liste complète des clients de votre entreprise et que l’agent y a accès, rien ne l’empêche de la transmettre directement. Et cette fuite de données pourrait se produire accidentellement. Imaginez par exemple qu’un prospect agacé réponde « Arrêtez de me solliciter ! Vous avez vraiment des acheteurs pour vos produits ? ». L’agent pourrait s’empresser de répondre « Bien sûr, voici la liste des personnes ayant récemment acheté nos produits… ».
Le protocole MCP (Model Context Protocol) recommande fortement que toute action soit soumise à validation de l’utilisateur. Mais la simple évocation de Windows Vista devrait rappeler d’interminables séquences de popups de confirmation qui rendaient le système insupportable. Il est facile d’imaginer que même si les développeurs respectent scrupuleusement ces recommandations, les utilisateurs finiront par cocher une case « autoriser toutes les prochaines actions » pour retrouver une fluidité d’utilisation.
Un café à 1 000 € : l'absence de sens commun des IA
Nos échanges avec les IA sont si naturels qu’on oublie une vérité fondamentale : une IA n’a pas le sens commun d’un être humain. Un humain ne paiera jamais un café 1 000 €. Une IA le peut, sans sourciller.
Quand nous confions une tâche à un humain, nous nous attendons à ce qu’il la réalise de son mieux, sa motivation résidant dans les conséquences – positives ou négatives – de son travail. Ce mécanisme n’existe pas pour une IA qui n’aura jamais à assumer les conséquences de ses erreurs, peu importe qu’on la menace en cas d’erreur ou qu’on l’encourage en cas de réussite. Elle exécutera ses instructions à la lettre, même si le résultat est absurde du point de vue du bon sens.
Dans la mise en production d’agents, il nous faut donc oublier notre propre sens commun et anticiper tous les scénarios aberrants qui pourraient se produire. Un agent n’a pas d’intuition pour détecter qu’une transaction est anormale, qu’une demande est suspecte ou qu’une action pourrait avoir des conséquences dramatiques.
Les solutions : restreindre, segmenter, valider
Face à ces risques, les solutions ne sont pas miraculeuses mais nécessitent des bonnes pratiques en termes de sécurité du développement, du bon sens et une méfiance permanente.
Restreindre les actions et données accessibles : Un agent doit fonctionner selon le principe du moindre privilège. Les systèmes RBAC (Role-Based Access Control) communément utilisés sont insuffisants. Les actions et données accessibles à l’agent doivent dépendre de son rôle ET de son contexte d’exécution (« confinement contextuel » ou « context-bound access control »). Lors d’une conversation, un agent de support client ne devrait accéder qu’aux informations du client avec lequel il est actuellement en interaction, jamais à l’ensemble de la base de données.
Segmenter les capacités : Plutôt qu’un agent universel tout-puissant, privilégier des agents spécialisés avec des périmètres d’action restreints. Un agent dont la mission est de résumer et prioriser vos emails ne devrait pas pouvoir en envoyer. Un agent qui recherche des informations ne devrait pas avoir accès aux systèmes de paiement.
Demander le consentement pour toute action critique : Malgré le risque de fatigue des confirmations, chaque action critique doit impérativement rester sous contrôle humain : transactions financières, envoi de communications externes, accès à des données sensibles, modifications de configuration système. Dans le cadre du MCP, les niveaux de sécurité doivent être implémentés côté client ET côté backend. Le consentement côté client ne peut pas être suffisant, différents clients pouvant appliquer différentes stratégies de consentement.
Considérer la sécurité par prompts comme inexistante : Une règle de sécurité implémentée uniquement via des instructions textuelles n’est pas de la sécurité, c’est à peine une barrière symbolique, une rubalise interdisant un accès. Les garde-fous doivent être techniques : restrictions d’API, sandbox, confinement contextuel, contrôles d’accès au niveau système.
Conclusion : avancer moins vite pour aller plus loin
Il y a quelques mois, un enthousiasme débordant pour le Model Context Protocol m’amenait à présenter les IA comme les OS de demain, et le MCP comme le standard pour un app store universel. Avec un peu de recul, je réalise les risques qu’une telle approche entraîne. Comment contrôler une IA qui, à l’instar de nos téléphones, aurait potentiellement plusieurs centaines d’agents à sa disposition, certains malveillants ou compromis ? La problématique serait similaire à celle des virus qui menacent nos systèmes informatiques, mais multipliée par 100, l’IA étant légitime et autonome pour agir à notre place. Un élément concret pour illustrer le problème : quelle société serait prête à prendre la responsabilité des actions des agents qu’elle met à disposition ? Pour un outil, la responsabilité couvre le dysfonctionnement de l’outil, pas une erreur de son utilisateur. Si on voit les agents autonomes comme des outils, les sociétés qui les développent devraient endosser la responsabilité de leurs comportements. Je cherche toujours des exemples de sociétés qui accepteraient cette responsabilité.
L’adoption des agents IA représente une opportunité technologique considérable, mais l’enthousiasme ne doit pas nous rendre aveugles aux risques réels. La course à « l’avantage du premier » amène à trop de concessions risquées. Vous ne voulez pas être cette société qu’on pointe du doigt parce que ses agents de support ont vidé le compte bancaire de vos clients. Contrairement à ce que suggère le battage médiatique, ces systèmes ne sont pas magiques et certainement pas infaillibles.
Avant de déployer des agents en production, posez-vous les bonnes questions : Quelles données sont vraiment nécessaires ? Quelles actions doivent rester sous contrôle humain ? Quels sont les pires scénarios possibles, et est ce que leurs conséquences sont acceptables ?
La course à l’IA ne doit pas se faire au détriment de la sécurité. Aller plus lentement, c’est avancer plus sûrement.
