• Le Top des failles
• L’isolation, une solution ?
  • Le concept de base : LLM vs SLM
  • La solution simple pour les particuliers : le VPS
  • Pour aller plus loin : du VPS au modèles en local
  • L’offre Cloud pour les entreprises : le VPC
  • L’IA « on premise » avec l’AI Factory
• Risques résiduels à l’isolation
• Références

Jusqu’à présent, nous avons vu les grands principes de l’utilisation de l’IA, et toutes les merveilles qu’elle peut accomplir. Mais il faut être conscient que l’IA n’est pas non plus miraculeuse.

Nous avons déjà évoqué les risques des hallucinations, qui peuvent introduire des erreurs dans les réponses et traitements de l’IA. Lorsque nous commençons à travailler avec des agents IA, puis à industrialiser l’IA dans ses projets et entreprises, nous augmentons de facto la surface d’attaque à laquelle nous nous exposons.

§Le Top des failles

Ainsi, l’OWASP (Open Worldwide Application Security Project, une communauté d’experts reconnus) a sorti en décembre 2025 un top 10 des plus grosses vulnérabilités que nous pouvons rencontrer à l’usage des agents IA. Nous pouvons les résumer en 4 points majeurs.

• L’injection de contexte ou de prompt via manipulation des données à disposition de l’agent, directement dans son contexte ou via le RAG.
• La mauvaise utilisation des outils mis à disposition de l’agent, ou bien des outils piratés, induisant l’agent en erreur.
• Une mauvaise isolation entre les agents, ce qui peut entraîner des abus d’identité ou de privilège. Par exemple, un agent va réutiliser des identifiants restés dans le contexte et normalement réservés à un autre agent. La mauvaise isolation peut aussi conduire à l’interception des communications entre les agents,…
• L’agent devient dangereux, volontairement ou non : exécution abusive de scripts ou commandes non anticipés, exfiltration, ou sabotage du système, etc.

En fait, un cinquième point émerge indirectement : le cas des erreurs en cascade, lorsque tout ou partie des points précédents s’enchaînent…

Les conséquences ne se font bien évidemment pas attendre :

• Des fuites massives de données, pernicieuses et difficiles à tracer (imaginez un agent qui décide de publier vos données de santé sur un réseau social, pensant qu’il s’agit du compte Doctolib de votre médecin ?).
• Des agents prenant des décisions lourdes de conséquences (comme la suppression de tout votre environnement de travail).
• Des atteintes à la disponibilité, avec des pannes en chaîne, des interruptions de service, des pertes de données, etc.

Quand on y regarde bien, un point commun à beaucoup de vulnérabilités vient de l’interaction avec le monde extérieur : que ce soit pour utiliser un LLM grand public, pour scraper des données d’un site web, ou utiliser un service accessible par MCP,… À chaque fois, l’agent va s’exposer, créant le risque de manipulation ou de détournement, ou exposer des données à l’extérieur, créant des fuites.

Et ça ne concerne pas que les particuliers, en plus : d’après index.dev, au moins 40% des entreprises s’appuient encore sur des LLM accessibles via internet. Elles sont alors exposées à des pannes massives d’OpenAI ou de services clouds car leurs systèmes opérationnels (support client, supply chain, chatbots, sécurité) reposent directement sur ces services en ligne.

§L’isolation, une solution ?

§Le concept de base : LLM vs SLM

Dans mes articles précédents sur l’IA Générative, j’ai beaucoup parlé des modèles et de leur fonctionnement, mais sans rentrer dans la nuance entre LLM (« Large Language Model » et SLM (« Small Language Model »).

Les LLM sont ce qu’on utilise en général, lorsqu’on utilise Gemini, Grok, Chat GPT, etc. Ce sont des modèles modèles capables de traiter, lors de l’inférence, plusieurs centaines de milliers à plusieurs millions de tokens en contexte (prompt + historique de conversation, tel que vu sur Local AI Zone). Par contre, ils consomment tellement de ressource qu’il faut un datacenter à disposition, pour les faire tourner : plusieurs cartes graphiques de dernière génération, et il faut compter plusieurs centaines de Go de RAM. En contrepartie, ils s’appuient sur un savoir encyclopédique et peuvent mener des raisonnements très complexes.

Les SLM sont spécialement conçus pour l’exécution en local, ce qu’on appelle le « edge computing » : la carte graphique d’un ordinateur portable peut suffire (à condition qu’elle soit assez récente), et certains modèles peuvent fonctionner avec à peine 1Go de RAM (quoique les plus performants demandent au moins 6 à 10 Go de RAM). Ces modèles seront entraînés sur des jeux de données pré-sélectionnés et seront particulièrement pertinents pour des tâches très spécifiques, comme résumer un texte, répondre à des emails, ou servir de moteur de recherche local. En comparaison des LLM, les SLM peuvent traiter en inférence d’une dizaine de milliers à quelques centaines de milliers de tokens maximum.

§La solution simple pour les particuliers : le VPS

Un VPS (pour Virtual Private Server) est un serveur virtuel privé : C’est une machine virtuelle hébergée dans le Cloud, donnant l’accès aux ressources nécessaires pour faire tourner nos applications, y compris IA : CPU, GPU, RAM, Stockage, bande passante. Contrairement à un hébergement partagé, tout est isolé : nous aurons l’impression d’avoir notre propre serveur, mais à un prix bien plus bas qu’un serveur dédié physique.

Suivant l’hébergeur choisi (OVH, Scaleway, Hetzner, etc.), nous disposerons de GPU dédiés à l’IA, puis nous pourrons choisir le reste de la configuration (8 à 16 vCPU, ou CPU virtuels, 32 à 64 Go de RAM pour l’exécution des modèles, etc.). Nous pourrons ensuite contrôler les entrées/sorties réseau, utiliser des modèles locaux,… La plupart des fournisseurs Cloud proposent également des outils d’IA clés en main, des APIs, voire des images machines (à partir desquels installer une machine virtuelle) permettant d’utiliser rapidement des modèles comme ceux de Mistral, par exemple (par contre, ces solutions sont généralement coûteuses).

Une solution clé en main va également voir le jour fin mars : Spawnr.dev. Dans sa présentation sur le Café Viennois, Nicolas, créateur de Spawnr, explique que le plus gros frein aujourd’hui n’est ni l’idée, ni le code, mais la configuration complexe des environnements. En effet, nous avons vu que vous pouvez configurer votre machine virtuelle dans le Cloud, mais nous avons seulement évoqué la partie visible de l’iceberg.

• Le contrôle du réseau nécessite une configuration fine avec des outils en ligne de commande.
• Pour éviter que votre IA ne mène des actions au-delà de ses permissions, vous devrez lui configurer un compte (« utilisateur » et « groupe » sous Linux), utiliser Docker (un environnement isolé dans lequel votre agent sera « enfermé », et dont vous pourrez contrôler strictement les entrées et sorties).
• etc.

Spawnr est un outil qui s’inscrit dans une vision de souveraineté numérique, permettant aux individus de créer du contenu en ligne avec l’IA, tout en réduisant drastiquement le temps perdu sur la technique pure : l’environnement est déjà entièrement configuré, avec des outils IA prêts à l’emploi, (notamment n8n pour l’automatisation, Open Claude, Codex, etc.) et accessible en quelques clics.

§Pour aller plus loin : du VPS au modèles en local

Cependant, le serveur dédié qu’offre le VPS n’est bien qu’une impression d’avoir notre propre serveur : le matériel est en réalité partagé avec d’autres utilisateurs du Cloud. Si vous souhaitez une véritable isolation, vous devrez opter pour un hébergement en local.

Pour cela, la principale contrainte est la performance : comme nous l’avons vu plus haut, si certains SLM sont vraiment peu gourmands, de bons SLM demandent quand même un minimum de 6 à 10 Go de RAM. En creusant un peu sur SLM Bench, nous trouvons des modèles certes plus performants encore, mais pouvant réclamer plusieurs dizaines de Go de RAM.

Sans forcément devoir prévoir une bête de course, il vaudra mieux se procurer une machine dédiée, par exemple une tour dans le salon, avec une bonne carte graphique et au moins 32 Go de RAM pour pouvoir s’estimer souverain.

§L’offre Cloud pour les entreprises : le VPC

Pour une entreprise, l’équivalent du VPS, qui correspond à une machine virtuelle est le VPC : concrètement, il s’agit d’un réseau privé, virtuel, et dans lequel peuvent s’exécuter plusieurs machines virtuelles dédiées à des tâches spécifiques. Ce que le particulier fait avec des containers (à l’intérieur d’une seule machine virtuelle), l’entreprise le fait avec des machines virtuelles (à l’intérieur d’un réseau privé).

En tant que réseau « privé », le VPC se pose comme une garantie de sécurité : les communications à l’intérieur du VPC restent à l’intérieur, seuls les points d’accès explicitement exposés sont accessibles (et nous pouvons les restreindre à des utilisateurs donnés, avec des droits bien précis). Cela permet également d’ouvrir des canaux bien spécifiques et bien sécurisés (par exemple avec un VPN) directement avec les outils de l’entreprise (comme le CRM qui sert à gérer les clients, ou l’ERP qui sert à gérer l’ensemble des ressources de l’entreprise).

Dans un VPC, nous pourrons donc créer des machines virtuelles de la même façon que dans l’exemple du VPS tout à l’heure (juste qu’une entreprise aura généralement plus de moyens qu’un particulier), les connecter aux outils de l’entreprise, et proposer des interfaces qui ne peuvent être utilisées que depuis l’intérieur de l’entreprise, ou du moins via un réseau parfaitement sécurisé.

Pour des solutions d’IA agentique, nous pourrons reprendre l’idée des containers, mais à l’échelle d’entreprise, comme avec Kubernetes (un orchestrateur de containers). Enfin, nous pourrons également déployer une base de données vectorielle dédiée à nos agents pour leur faciliter la manipulation des données (comme vu précédemment).

§L’IA « on premise » avec l’AI Factory

L’AI Factory est la solution qui permet d’industrialiser ses services IA. L’objectif est avant tout le Time-to-Market, mais la sécurité est aussi un enjeu majeur. Le public cible est l’organisation elle-même : comment permettre à 50 équipes de créer des apps IA sans réinventer la roue, et comment déployer, monitorer le coût des tokens, tester la régression des modèles et assurer la sécurité des données (Gouvernance) ?

Une équipe dédiée au sein de l’entreprise se charge

• de la gestion des données mises à disposition de l’IA,
• des composants de l’IA (RAG, agents, LLM, base de données vectorielle, etc.),
• du monitoring et des garde-fous de sécurité.

La plateforme est alors déployée, opérée, et exploitée au sein même de l’entreprise, « on premise » : c’est en quelques sortes une IA Cloud auto-hébergée.

L’IA devient un processus reproductible, sécurisé et rentable, comme une chaîne de production complète.

§Risques résiduels à l’isolation

Que ce soit en tant que particulier, ou en tant qu’entreprise, nous aurons beau mettre en place toute l’isolation et tous les garde-fous que nous voulons, il reste néanmoins des risques et des failles non-couvertes.

Par exemple, il reste des risques entre les agents (erreurs subtiles dans les prompts), ou au sein même de l’agent (erreur ou déviance). De plus, nous travaillons dans des environnements évoluant constamment, avec des briques de la chaîne de valeur chargées et mis à jour à chaud. D’autre part, les dérives du système peuvent être subtiles à déceler, ou bien découler sur des phénomènes en cascade qui se propagent très vite.

Dans ces cas-là, il ne reste que l’intervention humaine : formation, contrôles de sécurité réguliers, etc.

Et même là, comme dirait Daisuke Aramaki, dans Ghost in the Shell : « Bien sûr, ceux qui effectuent ces contrôles ne sont que des humains. » ou « errare humanum est » comme disent les latinistes.

§Références

• 50+ Min Blowing LLM Enterprise Adoption
• Cloud-based LLMs risk enterprise stability
• OWASP Top 10 for Agentic Applications for 2026
• SLM Bench de août 2025 sur arXiv
• Context Length Guide 2025 de Local AI Zone
• Le catalogue des modèles d’Hugging Face
• Mon article précédent sur la dissection de l’IA générative