Vos LLM, vos agents IA et vos serveurs MCP prennent déjà des décisions à votre place. La vraie question n’est plus s’ils sont attaqués, mais qui surveille ces attaques, et où vivent les outils qui les surveillent.
L’intelligence artificielle s’est installée partout en quelques mois, bien plus vite que les garde-fous censés l’encadrer. Un développeur colle un secret dans un assistant pour gagner cinq minutes. Une application lit un document fournisseur et exécute, sans le savoir, une instruction qu’on y avait dissimulée. Un agent enchaîne des appels d’outils et touche, en passant, une base qu’il n’aurait jamais dû atteindre.
Chacun de ces gestes paraît anodin. Chacun ouvre une porte. Et la plupart de ces portes sont aujourd’hui surveillées, quand elles le sont, par des briques conçues, hébergées et arbitrées ailleurs. La dépendance reste silencieuse, jusqu’au jour où elle cesse de l’être. L’enjeu n’est plus seulement technique : il s’agit de garder la main sur ce qui, désormais, décide à notre place.
L’IA en production est une surface d’attaque, pas un gadget
Un modèle de langage en production fait trois choses : il reçoit des prompts, produit des réponses, appelle des outils. Trois points de contact, trois surfaces d’attaque. Ce constat ne concerne pas qu’un secteur : éditeurs SaaS, industriels, banques, établissements de santé, collectivités, administrations. Dès qu’une organisation déploie un LLM, un agent ou un serveur MCP, elle hérite de ces surfaces.
L’OWASP Top 10 LLM 2025 (le référentiel ouvert qui recense les dix risques majeurs des applications à base de modèles de langage) les nomme noir sur blanc. Parmi les plus structurants :
- Prompt injection, directe et indirecte : une instruction malveillante glissée dans un message — ou dissimulée dans un document, une page web, un ticket — détourne le comportement du modèle.
- Sensitive information disclosure : le modèle restitue des secrets, des données personnelles ou des éléments de configuration qu’il n’aurait jamais dû exposer.
- Data et model poisoning : on corrompt en amont les données ou le modèle pour fausser durablement ses décisions.
- Excessive agency : un agent doté de trop d’outils et de trop d’autonomie agit au-delà de ce qu’on attendait — le périmètre d’impact (blast radius) explose.
- Insecure output handling : une sortie du modèle est consommée sans contrôle par un système en aval, et devient le vecteur d’une attaque classique.
À cela s’ajoute une surface neuve et mal cartographiée : les serveurs MCP, qui relient les modèles à des outils et à des données. Plus un agent gagne en capacités, plus il devient un point de pivot intéressant pour un attaquant. Et le premier maillon n’est pas en production : c’est le poste du développeur, là où le « shadow AI » (l’usage d’assistants IA hors de tout cadre) s’installe sans bruit.
Pourquoi les réponses actuelles ne tiennent pas
La plupart des déploiements IA tournent sans garde-fou réel. Le modèle est mis en production parce qu’il marche, vite, et qu’il impressionne. La sécurité, elle, arrive après, quand elle arrive. Le poste développeur reste l’angle mort total : c’est là que les secrets fuitent, que les instructions piégées entrent, et c’est précisément là que rien ne regarde.
Quand une surveillance existe, elle repose souvent sur des briques arbitrées ailleurs. La détection est déléguée à des plateformes conçues, hébergées et gouvernées hors d’Europe. Vous ne maîtrisez ni leurs règles, ni leur disponibilité, ni l’usage qui est fait de ce qu’elles observent de vos flux. Vous sous-traitez la vigilance sur ce que votre IA décide, à un tiers que vous n’arbitrez pas.
Le marché de la détection s’est refermé. En 2025, presque tous les acteurs spécialisés ont été absorbés par des plateformes extra-européennes. Le mouvement est rapide, et il laisse un vide : il ne reste quasiment aucune alternative souveraine, déployable chez soi, alignée sur les exigences de l’État français, le RGPD, l’AI Act et NIS2. Le besoin grandit pendant que les options se raréfient.
L’approche ATLAS-AI : des garanties, pas une boîte noire
ATLAS-AI, Automatisation des Traitements et Lutte Avancée pour la Sécurité IA, répond à ce vide. Sa promesse : détecter les attaques sur vos LLM, agents IA et serveurs MCP, du poste développeur jusqu’à la production. Deux portes d’entrée pour un même moteur de détection : Nova Guard couvre le premier front, celui du poste développeur, là où le risque naît au quotidien ; un simple branchement par API protège le second, l’application exposée en production.
Nous ne publions pas le détail de notre détection. En revanche, nous nous engageons sur des propriétés vérifiables :
- 9 risques sur 10 de l’OWASP Top 10 LLM 2025 couverts — une couverture pensée pour les classes d’attaque qui comptent vraiment, du prompt injection à l’excessive agency.
- 100 % déployable on-premise — la détection vit chez vous, dans votre infrastructure, sous votre contrôle.
- Zéro dépendance SaaS au runtime — aucun appel sortant obligatoire vers un service tiers pour fonctionner. Ce que votre IA traite ne transite pas par une plateforme que vous n’arbitrez pas.
- Continuité du poste développeur à la production — le même moteur, deux points d’entrée, pour fermer l’angle mort du « shadow AI » comme celui de l’application exposée.
Deux principes structurent ATLAS-AI dès sa conception. Security by design : la détection n’est pas un module ajouté à la fin, elle est pensée comme le socle, du poste développeur à la production. User-centric : parce qu’un garde-fou qui gêne le développeur finit désactivé, ATLAS-AI vise à protéger sans casser le flux de travail : surveiller l’IA sans ralentir ceux qui la construisent. La sécurité qui s’intègre au quotidien est celle qu’on garde active.
Ce qu’ATLAS-AI n’expose pas
Nous décrivons ce que la solution garantit, jamais comment elle l’obtient. Le moteur de détection, ses règles, son architecture interne et sa logique restent fermés, par choix, pas par négligence. Un outil de sécurité dont on publie le fonctionnement est un outil dont on publie aussi le contournement. L’opacité, ici, n’est pas une zone d’ombre : c’est une garantie. Elle protège votre détection de ceux qu’elle est censée arrêter. Vous obtenez des propriétés mesurables et une frontière nette autour de ce qui décide à votre place, sans céder la carte qui permettrait de la franchir.
Pourquoi maintenant
Le calendrier réglementaire n’attend pas. NIS2 demande déjà aux organisations concernées de cartographier leurs systèmes, l’IA comprise, et de maîtriser les risques qui en découlent. L’AI Act arrive derrière, avec ses obligations propres pour les systèmes à risque. Pendant que le droit se met en place, les LLM, les agents IA et les serveurs MCP se multiplient en production, le plus souvent sans surveillance dédiée.
À cette pression réglementaire s’ajoute la fermeture du marché. Les acteurs de la détection rachetés, les alternatives souveraines qui disparaissent : la fenêtre pour disposer d’une solution maîtrisée, hébergée chez soi et alignée sur les exigences européennes se referme. Attendre, c’est accepter que la vigilance sur ce que décide votre IA reste arbitrée ailleurs.
On construit ça en France
ATLAS-AI est en construction, conçu en France, pour les organisations qui refusent de déléguer à un tiers la surveillance de ce que leur IA décide. Une détection qui vous appartient, qui reste chez vous, et qui vous laisse échanger, déployer et innover sans renoncer au contrôle.
Garder la main sur ce qui décide à notre place : c’est tout l’objet d’ATLAS-AI.
Et si vous déployez déjà des LLM, des agents ou des serveurs MCP sans savoir qui surveille leurs portes, c’est sans doute le bon moment pour en parler.