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.
On parle de l’IA comme d’une révolution de productivité, et elle l’est. Mais pour nous, professionnels de l’IT, c’est aussi une nouvelle surface d’attaque qu’on a déployée en production avant d’avoir réfléchi à qui la surveille. 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. Alors posons les choses à plat : 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.
Le confort d’aller vite, et ce qu’il coûte
Pourquoi tant de déploiements IA tournent-ils sans garde-fou réel ? Ce n’est pas par insouciance. C’est parce que le modèle marche, vite, et qu’il impressionne. On le met en production parce qu’il crée de la valeur tout de suite, et 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.
Et quand une surveillance existe, elle bute sur le même mur que tout le reste de notre dépendance numérique :
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.
Et le marché 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, l’AI Act et NIS2. Le besoin grandit pendant que les options se raréfient. C’est exactement le piège déjà connu ailleurs dans notre infrastructure : on découvre qu’on est locataire d’une fonction critique le jour où le loyer change, ou le jour où le propriétaire ferme la porte.
Ce que nous essayons de construire avec ATLAS-AI
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 partis pris structurent ATLAS-AI dès sa conception, et ils répondent directement au mur décrit plus haut. 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.
Entre le confort d’une IA qu’on déploie sans la surveiller et l’effort d’une vigilance qu’on garde sous la main, la question n’est plus technique, elle est stratégique :
Sommes-nous prêts à garder la main sur ce qui, désormais, décide à notre place ?
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.