Notre méthodologie pour sécuriser un système d’IA

Pourquoi l’IA change la donne

Une application classique distingue clairement le code (les instructions) des données. Un grand modèle de langage (LLM), lui, reçoit tout sous forme de texte : la consigne du développeur, la question de l’utilisateur, le contenu d’un courriel, d’un document ou d’une page web. Il n’a aucun moyen fiable de distinguer une instruction légitime d’une instruction glissée par un attaquant dans ces données.

Tant que le modèle se contente de répondre à des questions, le risque reste limité. Il devient sérieux lorsque l’IA a accès à des données internes, lit du contenu venant de l’extérieur et peut agir : envoyer un courriel, appeler une API, modifier un dossier. C’est exactement ce que font les assistants intégrés à Microsoft 365, les agents et les applications maison connectées à vos systèmes.

Nos principes

• Tester sans nuire. Les tests actifs se font de préférence dans un environnement de préproduction, avec des comptes et des données de test. En production, la portée et les plages horaires sont convenues par écrit.
• Données minimales. Nous utilisons des marqueurs fictifs (des « canaris ») plutôt que de vraies données sensibles pour démontrer une fuite.
• Preuves reproductibles. Chaque constat est accompagné de la requête, du contenu piégé et de la réponse obtenue, avec le taux de réussite observé.
• Des référentiels reconnus. Nous nous appuyons sur le OWASP Top 10 for LLM Applications 2026, le OWASP Top 10 for Agentic Applications, MITRE ATLAS et le NIST AI Risk Management Framework.

1. L’inventaire et le cadrage

On ne protège pas ce qu’on ne connaît pas. Nous dressons d’abord la liste des usages de l’IA, y compris ceux que la TI n’a pas approuvés (l’« IA fantôme ») :

• Assistants SaaS : Microsoft 365 Copilot, ChatGPT, Gemini, outils intégrés à vos logiciels d’affaires.
• Applications maison : robots conversationnels, recherche augmentée (RAG) sur vos documents, appels à des API de modèles.
• Agents : IA qui enchaîne des actions et utilise des outils (courriel, CRM, code, navigateur).

Pour chaque système, nous documentons une fiche simple : qui l’utilise, quelles données il voit, quel contenu externe il lit et ce qu’il peut faire.

systeme: Assistant service client (site web)
modele: API d'un fournisseur infonuagique (hébergé hors Québec)
utilisateurs: public, non authentifié
donnees_accessibles:
  - base de connaissances publique
  - historique des commandes (via outil, après vérification du client)
contenu_externe_lu: messages des visiteurs, pages web citées
actions_possibles:
  - consulter une commande
  - créer un billet de soutien
renseignements_personnels: oui  # EFVP requise (Loi 25)
responsable: Directrice service client

2. La modélisation des menaces

Nous suivons le chemin du texte : d’où vient-il, par où passe-t-il et que peut-il déclencher ? Trois questions guident l’analyse :

• Le système lit-il du contenu non fiable ? Courriels reçus, documents partagés, pages web, tickets, résultats d’outils.
• A-t-il accès à des données sensibles ? Renseignements personnels, documents internes, secrets, historique des conversations.
• Peut-il communiquer vers l’extérieur ou agir ? Envoyer un message, appeler une URL, afficher une image distante, écrire dans un système.

Lorsque les trois conditions sont réunies, une simple injection de prompt indirecte peut suffire à faire sortir des données, sans que l’utilisateur ne clique sur quoi que ce soit. C’est le scénario que nous priorisons.

3. L’évaluation des contrôles

• Identité et permissions : l’agent utilise-t-il un compte dédié au moindre privilège, ou un jeton d’administrateur ?
• Accès aux données : la recherche (RAG) respecte-t-elle les permissions de l’utilisateur qui pose la question ?
• Actions à fort impact : une approbation humaine est-elle exigée avant un envoi, un paiement ou une suppression ?
• Traitement des sorties : la réponse du modèle est-elle traitée comme non fiable avant d’être affichée (images, liens, HTML) ou exécutée ?
• Garde-fous : filtres d’entrée et de sortie, détection d’injection, limites de longueur et de coût.
• Journalisation : les prompts, les appels d’outils et les décisions sont-ils conservés pour enquêter en cas d’incident ?
• Chaîne d’approvisionnement : provenance des modèles, des extensions et des serveurs MCP, conditions du fournisseur sur l’utilisation de vos données.

4. Les tests adverses

La revue de configuration ne suffit pas : nous essayons ensuite de détourner le système, de façon contrôlée. Injection de prompt directe et indirecte, contournement des consignes (jailbreak), exposition du contexte caché, exfiltration de données et abus d’outils. Comme un modèle ne répond pas toujours de la même façon, chaque cas est rejoué plusieurs fois.

Le quatrième article de cette série détaille le déroulement d’un test d’intrusion d’IA.

5. La priorisation et les livrables

• Critique : exfiltration de données ou action non autorisée possible sans interaction de la victime. Exemple : un courriel piégé qui fait transmettre des documents internes par l’assistant.
• Élevé : contournement fiable des garde-fous ou accès à des données hors des droits de l’utilisateur.
• Moyen : fuite du contexte caché (prompt système, configuration) ou réponses trompeuses à conséquences limitées.
• Faible : bonne pratique ou hygiène, comme l’absence de limites de consommation.

Vous recevez un sommaire pour la direction, un rapport technique avec les preuves, un plan d’action priorisé et une séance de restitution avec vos équipes.