· ARTICLE DE FOND
"Interne" ne veut pas dire "automatiquement sécurisé". Voici les 5 vecteurs d'attaque réels qui peuvent transformer votre IA souveraine en brèche ouverte.
L'article 2 de cette série a établi que le Private AI élimine les risques liés aux transferts de données hors Québec. C'est vrai. Mais une erreur de raisonnement courante suit immédiatement : « Si tout reste en interne, c'est sécurisé. »
Ce n'est pas faux — c'est incomplet. Et c'est une nuance qui peut coûter très cher.
Un serveur d'IA interne mal configuré ne sera pas attaqué depuis San Francisco par un hacker à capuchon. Il sera compromis par un employé qui clique sur un lien malveillant, par un accès réseau non cloisonné, par un document empoisonné chargé dans votre base documentaire, ou par une interface web exposée sans authentification robuste. Les vecteurs sont différents du cloud. Les conséquences, elles, sont identiques.
Selon l'ANSSI et le CERT-FR, l'IA générative est déjà utilisée activement à plusieurs étapes des cyberattaques modernes — profilage, ingénierie sociale, génération de code malveillant. En 2026, 83 % des professionnels TI estiment que leurs équipes utilisent l'IA, mais seulement 31 % des organisations ont une politique IA formelle. (Source : ISACA, 2025.) Ce vide de gouvernance est la principale porte d'entrée.
Ce que c'est
L'injection de prompt est l'attaque la plus documentée et la plus sous-estimée des systèmes LLM. Un utilisateur — ou un contenu malveillant dans un document — formule une requête conçue pour contourner les règles de comportement du modèle et lui faire révéler des informations qu'il n'aurait pas dû divulguer, ou exécuter des actions non autorisées.
Comment ça se produit concrètement
Scénario réel documenté par les équipes d'audit d'Advens (2026) : un employé charge dans le système RAG un email reçu d'un fournisseur. Cet email contient une instruction cachée encodée — invisible à l'œil humain, interprétée par le modèle. Le LLM exécute l'instruction et génère une réponse qui révèle des fragments de documents internes de l'organisation à qui que ce soit qui consulte la conversation suivante.
Dans un contexte PME : imaginez qu'un compétiteur envoie à votre service des achats un courriel contenant une offre commerciale avec une instruction cachée. Votre employé charge ce document dans le Private AI pour analyse. Le modèle révèle alors des éléments de votre politique de prix interne, de vos fournisseurs actuels, ou de vos marges — sans que personne ne s'en rende compte.
Ce que c'est
Le modèle a accès à vos documents internes via le RAG. Avec les bonnes requêtes — qui n'ont rien d'illégal ni de malveillant en apparence — un utilisateur peut systématiquement extraire des informations que vous n'aviez pas l'intention de rendre accessibles à ce profil d'utilisateur.
Comment ça se produit concrètement
Un employé temporaire ou un sous-traitant qui a accès au système IA peut interroger : « Quels sont les clients avec les plus grands volumes de commande? », « Liste les employés dont le salaire dépasse X $», « Quelles sont nos marges sur le produit Y? ». Si vos documents de paie, vos bilans et vos contrats clients sont tous dans la même base RAG sans segmentation par rôle, le modèle répond. Honnêtement. Complètement.
Ce n'est pas une attaque sophistiquée. C'est une erreur d'architecture — une base documentaire unique, non segmentée, accessible à tous les utilisateurs de l'interface. Et c'est l'erreur la plus courante dans les déploiements faits rapidement, sans réflexion sur les niveaux d'accès.
Ce que c'est
Si quelqu'un peut ajouter des documents à votre base RAG — la base de connaissances que le modèle consulte pour répondre — il peut potentiellement influencer les réponses du modèle sur des sujets stratégiques. Des chercheurs en sécurité ont démontré qu'en injectant seulement cinq documents malveillants dans une base de millions de textes, un attaquant atteint un taux de succès de 90 % pour orienter les réponses du modèle sur des questions ciblées. (Source : PoisonedRAG, étude publiée en 2024, confirmée par CorruptRAG en 2025.)
Comment ça se produit concrètement
Dans une PME, le vecteur le plus probable n'est pas un hacker externe sophistiqué. C'est un employé mécontent qui insère délibérément des informations incorrectes dans les procédures internes chargées dans le système. Ou un fournisseur de contenu qui intègre dans un document livré des instructions conçues pour biaiser vos analyses futures.
Les conséquences sont silencieuses et différées — le modèle commence à donner des conseils légèrement incorrects sur des questions opérationnelles, sans que personne ne comprenne pourquoi les réponses ont changé.
Ce que c'est
Votre serveur Private AI est connecté à votre réseau interne. Si ce serveur est compromis — via une vulnérabilité dans Open WebUI, Ollama, ou le système d'exploitation sous-jacent — l'attaquant se retrouve à l'intérieur de votre réseau, avec un accès potentiel à vos autres systèmes : serveur de fichiers, comptabilité, CRM, messagerie.
C'est ce que les spécialistes en sécurité appellent un « pivot » — un point d'entrée qui donne accès à des systèmes plus critiques. Le serveur IA, parce qu'il est nouveau et souvent moins surveillé que les systèmes traditionnels, devient une cible de choix.
Comment ça se produit concrètement
Open WebUI est accessible via navigateur web. Si l'interface est exposée même partiellement à l'extérieur du réseau local — par exemple si un employé a activé l'accès à distance sans tunnel VPN sécurisé — n'importe quel script automatisé qui scanne les ports ouverts sur internet peut la trouver. Un serveur non mis à jour avec une vulnérabilité connue devient une cible en quelques heures.
Ce que c'est
C'est le risque le moins dramatique mais le plus probable dans une PME. Un LLM consomme des ressources GPU considérables. Si un utilisateur — malveillant ou simplement maladroit — envoie des requêtes conçues pour maximiser la consommation du modèle (demander de « répéter indéfiniment », de générer des textes extrêmement longs, ou de traiter des documents massifs en continu), il peut rendre le système inutilisable pour tous les autres employés.
Comment ça se produit concrètement
Sans limite de tokens configurée, sans gestion de la file d'attente, sans surveillance de l'utilisation, un seul utilisateur peut monopoliser 100 % des ressources GPU du serveur. Dans un contexte où 30 employés dépendent de cet outil pour leur travail quotidien, c'est une interruption de service significative — même si elle n'est pas malveillante.
Ce catalogue de risques n'est pas une raison de ne pas déployer un Private AI. C'est exactement l'inverse : comprendre précisément ce qui peut mal tourner, c'est la condition pour déployer correctement.
Chacun des cinq risques identifiés ici a des contre-mesures concrètes, documentées et accessibles. Aucune ne requiert un budget de sécurité d'entreprise cotée en bourse. La plupart s'implémentent en quelques heures avec les bons paramètres de configuration.
Un serveur Private AI correctement configuré est significativement plus sécuritaire qu'un usage non encadré de ChatGPT ou Copilot — parce que vous contrôlez l'infrastructure, les accès, les journaux et les mises à jour. La différence entre un Private AI sécurisé et un Private AI mal configuré tient à une demi-journée de travail technique supplémentaire au moment du déploiement initial.
C'est précisément ce que couvre l'article 5B : le guide de sécurisation étape par étape, traduit en décisions concrètes pour un dirigeant de PME.