Points clés à retenir (TL;DR)
Synthèse exécutive- Le risque principal de l'IA en PME vient moins de l'IA elle-même que de son usage non encadré : outils non approuvés (shadow AI), données sensibles copiées dans des services externes, faux sites d'outils IA qui distribuent des maliciels.
- Trois vecteurs sont à surveiller en priorité : les faux installateurs « IA » (souvent des voleurs d'identifiants), les applications IA qui obtiennent un consentement OAuth sur la messagerie ou les fichiers, et les agents IA vulnérables à l'injection de prompt.
- La détection repose sur la corrélation : nouveau domaine lié à l'IA, puis téléchargement, puis exécutable non signé, puis connexion inhabituelle au compte infonuagique ; ou encore un consentement OAuth à privilèges élevés suivi d'un accès massif aux données.
- Les contrôles les plus rentables sont simples : un catalogue d'outils IA approuvés, la restriction du consentement OAuth par les utilisateurs, une liste blanche d'extensions de navigateur et une politique de prévention des pertes de données (DLP) sur les services IA.
- Au Québec, la Loi 25 s'applique pleinement : un projet IA qui traite des renseignements personnels peut exiger une évaluation des facteurs relatifs à la vie privée (EFVP), et une fuite constitue un incident de confidentialité.
Contexte
Dans la plupart des PME, l’IA générative n’arrive pas par un projet piloté par les TI. Elle arrive par les employés : un adjoint administratif qui résume des courriels avec un assistant conversationnel, un vendeur qui installe une extension « IA » pour rédiger ses offres, un comptable qui téléverse un fichier Excel pour en tirer une analyse. Ces usages sont légitimes et souvent productifs. Le problème, c’est qu’ils se font hors de toute visibilité.
Cette adoption informelle crée trois expositions. D’abord une exposition des données : des contrats, des listes de clients ou des renseignements personnels peuvent se retrouver dans des services dont les conditions d’utilisation permettent la conservation ou l’entraînement sur les données soumises. Ensuite une exposition aux menaces : la popularité de l’IA est exploitée par des acteurs malveillants qui imitent des outils connus pour distribuer des maliciels. Enfin une exposition d’identité : les applications IA demandent souvent un accès délégué à la messagerie, au calendrier ou aux fichiers, ce qui leur donne une porte d’entrée persistante dans l’environnement Microsoft 365 ou Google Workspace.
Pour une PME québécoise, l’enjeu dépasse la technique. En vertu de la Loi 25, l’entreprise demeure responsable des renseignements personnels qu’elle détient, y compris lorsqu’un employé les transmet à un service tiers. Interdire l’IA ne règle rien : l’usage se déplace vers les appareils personnels. La bonne approche est d’encadrer.
Comment ça fonctionne
Le scénario suivant est illustratif. Il combine des techniques documentées publiquement pour montrer comment une adoption non encadrée de l’IA pourrait mener à une compromission.
Étape 1 : la recherche d’un outil IA
Une employée chercherait un générateur de vidéos par IA. Parmi les premiers résultats figurerait une annonce commanditée ou un site bien référencé imitant un service connu. Les attaquants enregistrent des domaines ressemblants (T1583.001) et utilisent la publicité malveillante (T1583.008) ou l’empoisonnement SEO (T1608.006) pour se placer en tête des résultats.
Étape 2 : le téléchargement et l’exécution
Le site proposerait de « générer » la vidéo puis de télécharger le résultat, en fait un exécutable ou une archive contenant un installateur. L’employée l’ouvrirait elle-même (T1204.002, exécution par l’utilisateur d’un fichier malveillant), l’accès initial passant par un téléchargement furtif ou incité (T1189).
Étape 3 : le vol d’identifiants et de sessions
La charge serait un voleur d’informations (infostealer). Il collecterait les mots de passe enregistrés dans le navigateur (T1555.003) et, surtout, les cookies de session (T1539). Ces cookies permettent de rejouer une session déjà authentifiée, ce qui contourne souvent l’authentification multifacteur classique (T1550.004). Les données seraient exfiltrées par le canal de commande et contrôle (T1041).
Étape 4 : la variante OAuth
Un second chemin ne demande aucun maliciel. Une application « assistant IA pour courriels » demanderait à l’utilisateur de consentir à des permissions comme la lecture de la messagerie et des fichiers, avec un accès hors connexion. Une fois le consentement accordé, l’application dispose d’un jeton d’accès valide (T1528, T1550.001) qui survit à un changement de mot de passe. Si l’éditeur est malveillant ou compromis, les données peuvent être aspirées vers un service web (T1567).
Étape 5 : l’agent IA détourné
Enfin, si l’entreprise déploie un agent IA connecté à la messagerie ou à un SharePoint, un courriel ou un document piégé pourrait contenir des instructions cachées. C’est l’injection de prompt indirecte, répertoriée dans MITRE ATLAS (AML.T0051) et en tête du Top 10 OWASP pour les applications LLM. L’agent pourrait alors résumer des données sensibles dans une réponse ou déclencher une action non souhaitée s’il en a les permissions.
Pourquoi ça passe / signaux
- La légitimité perçue : la marque « IA » inspire curiosité et urgence. Un employé qui veut gagner du temps baisse sa garde, et le site frauduleux reproduit fidèlement l’interface d’un outil réel.
- L’absence de catalogue approuvé : sans outil officiel, chacun cherche le sien. Les TI ne savent pas quels services sont utilisés ni quelles données y transitent.
- Le consentement OAuth par défaut : dans de nombreux locataires Microsoft 365, les utilisateurs peuvent encore consentir eux-mêmes à des applications tierces. L’écran de consentement est souvent accepté sans lecture.
- Le trafic se fond dans la masse : les échanges avec des services IA passent en HTTPS vers des domaines infonuagiques réputés. Un filtrage par réputation ne suffit pas à distinguer un usage légitime d’une fuite.
- Les agents ont trop de droits : un agent IA configuré avec un compte de service large hérite de tous ses accès. Le modèle ne fait pas de différence fiable entre une instruction de l’utilisateur et un texte contenu dans un document.
Détection
Aucun signal isolé n’est concluant. La valeur vient de la corrélation dans le SIEM ou la plateforme XDR, sur une fenêtre de temps courte et pour un même utilisateur ou poste.
Chaîne poste de travail
- Navigation vers un domaine récemment enregistré ou catégorisé « IA » ou « non classé », suivie d’un téléchargement d’exécutable, d’archive ou de fichier MSI.
- Exécution d’un binaire non signé ou signé par un éditeur inconnu depuis le dossier Téléchargements ou un répertoire temporaire, dans les minutes qui suivent.
- Accès par un processus autre que le navigateur aux fichiers de profil du navigateur (bases d’identifiants et de cookies) : c’est un comportement typique des infostealers.
- Connexion sortante de ce processus vers une adresse IP ou un domaine jamais vu dans l’environnement.
Chaîne identité
- Dans les journaux d’audit Entra ID, événement de consentement à une application (« Consent to application ») avec des permissions comme Mail.Read, Files.Read.All ou offline_access, surtout si l’éditeur n’est pas vérifié.
- Pic d’appels Microsoft Graph par cette application dans les heures suivantes : lecture massive de courriels ou de fichiers.
- Réutilisation d’une session depuis une adresse IP, un pays ou un fournisseur réseau inhabituels, sans nouvel événement d’authentification multifacteur : indice de rejeu de cookie.
Chaîne données et agents
- Alertes DLP sur des téléversements ou copier-coller vers des domaines IA non approuvés, notamment pour des numéros d’assurance sociale, des données de carte ou des documents étiquetés confidentiels.
- Pour les agents IA internes : journaliser les prompts, les sources consultées et les actions déclenchées. Une action d’envoi ou de partage externe initiée juste après la lecture d’un document externe mérite une revue.
Mitigation
| Domaine | Mesure concrète | Priorité |
|---|---|---|
| Gouvernance | Adopter une politique d’usage de l’IA courte et claire : outils permis, types de données interdits, processus de demande d’un nouvel outil. S’inspirer du NIST AI RMF ou d’ISO/IEC 42001. | Élevée |
| Outils approuvés | Fournir au moins un assistant IA sous licence entreprise, avec engagement contractuel de non-entraînement sur les données et durée de conservation définie. C’est le meilleur antidote au shadow AI. | Élevée |
| Identité | Restreindre le consentement des utilisateurs aux applications d’éditeurs vérifiés et à faibles permissions ; activer le flux de demande de consentement administrateur ; revoir trimestriellement les applications d’entreprise autorisées. | Élevée |
| Authentification | Déployer une authentification multifacteur résistante à l’hameçonnage (FIDO2, passkeys) et des politiques d’accès conditionnel liant la session à un appareil conforme, afin de limiter le rejeu de jetons. | Élevée |
| Postes de travail | Contrôle applicatif (WDAC ou AppLocker), retrait des droits d’administrateur local, EDR avec surveillance de l’accès aux profils de navigateur. | Élevée |
| Navigateur | Liste blanche d’extensions via Intune ou GPO ; désactiver l’enregistrement des mots de passe dans le navigateur au profit d’un gestionnaire d’entreprise. | Moyenne |
| Données | Classifier les documents sensibles et appliquer des règles DLP ou CASB sur les domaines IA : bloquer, avertir ou autoriser selon la sensibilité. | Moyenne |
| Agents IA | Moindre privilège pour les comptes des agents, validation humaine avant toute action externe (envoi, partage, paiement), traitement de tout contenu externe comme non fiable. | Moyenne |
| Conformité Loi 25 | Réaliser une EFVP pour tout projet IA traitant des renseignements personnels ; informer les personnes concernées en cas de décision fondée exclusivement sur un traitement automatisé ; intégrer les fuites liées à l’IA au registre des incidents de confidentialité. | Élevée |
| Sensibilisation | Former les employés à reconnaître les faux sites d’outils IA et les écrans de consentement abusifs, avec des exemples concrets. | Moyenne |
Indicateurs (exemples illustratifs)
Les valeurs ci-dessous sont entièrement fictives et servent uniquement à illustrer le type d’indicateurs à rechercher. Elles ne correspondent à aucune campagne réelle et ne doivent pas être importées dans un outil de blocage.
| Type | Exemple fictif | Ce qu’il illustre |
|---|---|---|
| Domaine | ai-video-studio.test | Site imitant un outil IA populaire |
| URL de téléchargement | https://download.example.com/AI_Video_Result.zip | Archive présentée comme un résultat généré |
| Adresse IP | 192.0.2.45 | Serveur de commande et contrôle d’un infostealer |
| Application OAuth | « Smart AI Mail Assistant (exemple) », éditeur non vérifié | Consentement demandant Mail.Read et offline_access |
| Comportement | Exécutable non signé lancé depuis Téléchargements, accédant aux fichiers de cookies du navigateur | Vol de session typique d’un infostealer |
| Connexion | Session réutilisée depuis 192.0.2.200 sans nouvelle demande MFA | Rejeu de cookie de session |
À retenir
Adopter l’IA sans risque ne veut pas dire l’interdire. Il s’agit de reprendre la main sur trois choses : les outils utilisés, les données qui y circulent et les accès qui leur sont délégués. Une PME qui fournit un outil IA approuvé, verrouille le consentement OAuth, contrôle les exécutables et les extensions, et corrèle les signaux poste, identité et données réduit fortement son exposition. Elle reste en même temps conforme à la Loi 25 et profite des gains de productivité.
Commencez par un inventaire : quels services IA sont déjà utilisés chez vous, et quelles applications ont accès à votre messagerie ? Si vous souhaitez être accompagnés pour cet inventaire, la rédaction d’une politique d’usage ou la mise en place des détections décrites ici, l’équipe WeITSM peut vous aider à bâtir un cadre adapté à votre réalité.
