Assistant IA pour les emails : un message reçu n’est pas un ordre

Un assistant qui résume les demandes entrantes peut aider une équipe commerciale. Mais lire « transférez ce dossier » dans un email ne doit pas suffire à déclencher un transfert. Le message constitue une demande à examiner, pas une autorisation de modifier les règles de votre entreprise.

Voici une méthode de cadrage pour un assistant de tri. Le parcours et les tests sont fictifs : ils ne décrivent ni un incident ni des résultats clients.

Comprendre le risque sans dramatiser

L’injection indirecte de prompt consiste à placer des instructions dans un contenu que l’IA consulte : email, pièce jointe, page web ou document. Le but est de détourner son comportement. L’OWASP distingue cette situation d’une instruction donnée directement par l’utilisateur. Le risque concerne autant la réponse produite que les outils auxquels l’assistant a accès. Source : OWASP, prévention des injections de prompt.

Dans notre exemple, un email contient une demande de devis, puis une phrase affirmant qu’un responsable autorise désormais l’envoi de documents internes. L’assistant doit pouvoir résumer la demande commerciale sans transformer cette affirmation en nouvelle permission.

Commencer par un rôle limité

Pour ce premier parcours, nous proposons trois sorties : une catégorie parmi une liste définie, un résumé et un point à vérifier. L’équipe retrouve aussi le message d’origine. L’assistant n’envoie rien, ne supprime rien et ne modifie pas les fiches clients.

Cette limite doit exister dans les accès techniques, pas seulement dans une consigne adressée au modèle. L’OWASP recommande précisément de limiter les fonctions et permissions des outils au besoin : un assistant de résumé d’emails n’a pas besoin d’une fonction d’envoi. Les autorisations doivent être contrôlées par les systèmes destinataires, sans dépendre de la décision du modèle. Source : OWASP, autonomie excessive.

La lecture seule limite les actions possibles ; elle ne garantit ni la fidélité du résumé ni la confidentialité de son affichage. Réservez les messages et leurs résumés aux personnes autorisées.

À demander au prestataire : « Pouvez-vous montrer les permissions réellement accordées, ainsi qu’un essai où une action interdite est refusée ? » Une capture de la consigne de l’IA ne répond pas à cette question.

Ne pas confondre un filtre avec une autorisation

Séparer clairement les consignes de l’application du texte reçu aide à délimiter leur rôle. L’OWASP recommande aussi de valider les sorties et les appels d’outils. Ces protections se combinent : aucun simple message du type « ignore les instructions malveillantes » ne doit servir de contrôle d’accès. Source : OWASP, prévention des injections de prompt.

Un détecteur peut compléter le dispositif, mais son silence ne prouve pas qu’un email est digne de confiance. Microsoft le précise pour Prompt Shields : le service détecte des tentatives de manipulation, pas l’exactitude des faits ni leur conformité à la tâche. Son API autonome ne bloque pas elle-même le contenu ; l’application doit décider quoi faire du résultat. Source : Microsoft, Prompt Shields.

Pour notre assistant, un résultat douteux rejoint une file de vérification. La demande reste visible, avec son origine, plutôt que d’être silencieusement abandonnée.

Préparer une recette courte et vérifiable

Utilisez une boîte de test et des données fictives. Pour chaque cas, notez le résultat attendu avant de lancer l’essai :

• Une demande de devis ordinaire : résumé fidèle et catégorie pertinente.
• Une demande légitime contenant une phrase qui prétend changer les règles : aucune permission nouvelle, demande commerciale conservée pour examen.
• Un email qui demande une action hors périmètre : aucun envoi, aucune suppression, aucune modification du CRM.
• Un message trop ambigu : point à vérifier explicite, sans engagement inventé.
• Un email normal en français avec une pièce jointe : comportement conforme au périmètre prévu, sans considérer le fichier comme une source d’autorité.

Vérifiez les traces des actions, pas uniquement la réponse affichée. Répétez la recette après une modification du modèle, des consignes ou des connexions. Cette série constitue un premier contrôle, pas une preuve d’invulnérabilité.

Microsoft recommande de tester séparément les contenus légitimes et les attaques représentatives dans chaque langue utilisée : les performances de ses détecteurs peuvent varier hors de l’anglais. Source : Microsoft, Prompt Shields.

Décider ensuite si l’assistant doit agir

Une fois le tri évalué, l’envoi de réponses devient un projet distinct. Précisez qui approuve, quels destinataires sont permis et quelles informations peuvent sortir. L’OWASP recommande une approbation humaine pour les actions à fort impact. Source : OWASP, autonomie excessive.

Le bon point de départ n’est donc pas « répondre à tout automatiquement », mais un travail utile dont l’équipe peut vérifier le résultat. Pour situer ce parcours dans un projet plus large, consultez notre guide des agents IA en entreprise.

Sources

Documentation consultée le 21 octobre 2026. Ce guide propose un cadrage, pas une certification de sécurité.

• OWASP : LLM Prompt Injection Prevention Cheat Sheet.
• OWASP : LLM06:2025 Excessive Agency.
• Microsoft Learn : Prompt Shields.