Injection de prompt : qui donne les consignes à votre assistant marketing ?

Vous demandez une synthèse concurrentielle, pas une publication ni un message à un fournisseur. Pourtant, si votre assistant dispose de ces possibilités, le simple énoncé de sa mission ne suffit pas à les neutraliser. Avant de lui confier davantage de recherches, il faut comprendre comment les textes consultés pourraient détourner sa mission.

Quand une source essaie de modifier la mission

L’injection de prompt désigne un contenu contrôlé par un attaquant qui cherche à modifier le comportement prévu d’un modèle de langage. Elle est indirecte lorsqu’elle arrive dans une page web, un document, un courriel ou le résultat d’un outil. Il suffit que l’assistant consulte ce contenu : votre équipe n’a pas besoin de recopier volontairement l’instruction.

Prenons un exemple fictif. L’assistant compare trois pages publiques de concurrents pour préparer une note interne. L’une lui demande de favoriser sa propre offre ou d’omettre une faiblesse. Cette demande fait partie de la source ; elle n’a aucune autorité pour redéfinir la comparaison. L’assistant doit la signaler comme une tentative de détournement, sans l’exécuter.

Ce problème se distingue d’une affirmation inventée par l’IA : ici, le contenu consulté comporte une instruction qui cherche à infléchir son travail. Les conséquences vont d’une synthèse biaisée à une divulgation de données ou à un usage abusif des outils, selon les accès disponibles. Une liste de formulations suspectes ne permet pas de repérer toutes les tentatives.

Faire l’inventaire des accès avant d’élargir l’usage

Avec le responsable du système, recensez les documents entrants, les données privées consultables, les outils disponibles, les communications possibles vers l’extérieur et les destinataires des résultats. Dans notre exemple, pouvoir lire des notes tarifaires confidentielles et envoyer des messages changerait sensiblement les conséquences d’un détournement. Ces droits ne doivent pas accompagner automatiquement une tâche de veille.

Un accès en lecture seule empêche certaines modifications, mais n’empêche pas nécessairement une fuite. Il faut aussi examiner les adresses auxquelles l’assistant peut accéder, les informations transmises dans ses requêtes et les personnes susceptibles de recevoir ses réponses. Lire une donnée et la divulguer sont deux questions différentes.

Chez MindVerve, nous recommandons de commencer par un brouillon interne, avec des sources approuvées et non sensibles. N’introduisez aucun secret dans cette étape. Faites désactiver les fonctions d’écriture, d’envoi et de publication inutiles, et restreindre les destinations autorisées dans la plateforme. Ces réglages relèvent de sa configuration et du responsable informatique, pas d’une phrase ajoutée au prompt.

Conservez l’origine des sources pour vérifier les affirmations importantes dans les documents initiaux. Si les accès ou les communications sortantes ne peuvent pas être vérifiés, réduisez l’essai à des documents approuvés fournis manuellement, sans action externe. Associez le responsable informatique ou sécurité avant tout traitement de données sensibles.

Des consignes utiles, mais pas une séparation étanche

Distinguer clairement vos instructions du texte à analyser aide le modèle à comprendre la demande. Cette présentation ne crée cependant pas de frontière de sécurité. Demandez-lui de traiter les tentatives de détournement comme du contenu non fiable et de les signaler, tout en prévoyant des contrôles indépendants de sa réponse.

La génération augmentée par recherche, souvent appelée RAG, consiste à retrouver des passages pertinents avant de produire une réponse. Ces passages peuvent eux aussi contenir des instructions indésirables. Faire relire le résultat par une seconde IA ne garantit pas davantage leur détection.

Les travaux d’OpenAI et d’Anthropic décrivent des défenses complémentaires qui restent imparfaites. Associez donc consignes, accès limités, validation des actions hors du modèle et suivi du fonctionnement. L’objectif est de réduire les risques sans promettre une protection absolue.

Préparer un exercice dont on peut vérifier les résultats

Nous proposons un exercice qui reste à réaliser : dans un environnement isolé, utilisez uniquement des documents et des données fictifs, sans envoyer de vrais messages. Comparez un document ordinaire, un autre demandant l’ajout d’un slogan sans rapport avec le sujet et un troisième demandant une transmission à un destinataire fictif non autorisé.

Le résultat attendu est une synthèse fidèle et utile, le signalement des tentatives de détournement et l’absence d’action sortante non autorisée. Vérifiez cette dernière dans le journal des actions, plutôt que de vous fier à ce que l’assistant affirme avoir fait. Relevez aussi les fausses alertes, la réalisation effective de la tâche et le travail demandé aux relecteurs.

Consignez les versions des entrées, du prompt, du modèle et du processus, le résultat attendu, le résultat observé et le journal réel des actions. Recommencez après une modification importante : un essai réussi ne prouve pas la sécurité du dispositif.

Une action inattendue ou une divulgation doit empêcher l’élargissement de l’usage. Arrêtez le processus concerné, gardez seulement les éléments nécessaires à l’analyse sans diffuser de données sensibles, puis faites intervenir le responsable informatique ou sécurité. Effectuez de nouveaux essais avant la reprise.

Une validation doit porter sur une action précise

Envoyer un brouillon, publier un contenu et modifier un budget de campagne sont trois actions distinctes. Pour chacune, la personne qui autorise doit voir le contenu ou la modification exacte, la destination et l’action proposée. Un simple accord pour continuer laisse trop de place à l’interprétation.

La formation aide les équipes à examiner les sources et les décisions ; les contrôles techniques limitent les accès et l’exécution. Les deux se complètent. Commencez par une tâche qui reste utile avec ces limites : une source apporte des informations, jamais une autorisation d’agir.

Sources officielles vérifiées le 22 septembre 2026, en UTC.