Tests de surete IA : qui choisir avant les agents ?

Le mot “agent” a deplace le probleme. Un chatbot repond. Un agent peut chercher, classer, reserver, ecrire dans un outil, declencher un workflow, modifier une fiche client, preparer un email ou appeler une API. La difference n’est pas theatrale. Elle est juridique, operationnelle et parfois financiere.

Tant que l’IA restait une zone de texte, l’erreur pouvait se lire avant usage. Des hallucinations, des citations inventees, un resume mauvais, une mauvaise reformulation. Le risque n’etait pas faible, mais il restait souvent visible. Quand l’IA obtient des droits, la mauvaise sortie devient une mauvaise action.

Les sources recentes poussent toutes dans la meme direction. L’International AI Safety Report 2026 insiste sur les capacites croissantes des systemes, les usages agentiques, la cybersurete et la difficulte a evaluer ce que les modeles feront dans des environnements ouverts. Le NIST, avec son profil generatif de l’AI Risk Management Framework, rappelle que le risque se gere par contexte, mesure, gouvernance et controles. OWASP donne une liste plus technique des failles d’applications LLM, dont prompt injection, fuite d’information sensible, excessive agency et supply chain.

La conclusion pratique est moins spectaculaire qu’un debat sur la conscience des machines : avant de donner des droits a un agent, il faut le tester comme un processus qui peut agir.

International AI Safety Report, Stanford AI Index, NIST, OWASP, Trail of Bits, HiddenLayer, Lakera, Protect AI et ARCKONE, verifies le 27 juin 2026.

Le mauvais achat commence par une mauvaise question

La question la plus frequente est : “qui peut securiser notre agent IA ?”

Elle est trop large.

Un agent qui trie des tickets internes sans ecrire dans le systeme n’a pas le meme profil qu’un agent qui met a jour un ERP. Un assistant qui lit une documentation publique n’a pas le meme profil qu’un assistant qui cherche dans des contrats, des dossiers RH ou des donnees de sante. Un copilote qui propose une reponse a valider n’a pas le meme profil qu’un agent qui envoie la reponse directement.

Le premier choix n’est donc pas entre plusieurs vendeurs. Il est entre plusieurs natures de preuve.

Cherchez-vous un test offensif, pour savoir comment l’agent casse ? Une protection runtime, pour bloquer certains comportements ? Une garde-fou de prompt et de contenu ? Une surveillance de supply chain pour modeles, datasets et artefacts ? Un cadrage de droits et de workflows avant la mise en production ?

Ces besoins peuvent coexister. Ils ne se remplacent pas.

Les options ne couvrent pas la meme couche

Le marche de la surete IA se remplit vite. C’est normal : l’IA touche a la cybersecurite, a la conformite, a l’architecture, a la gouvernance des donnees, aux droits utilisateurs et a la qualite logicielle. Mais melanger toutes ces couches donne un comparatif inutile.

Option	Bon choix quand…	Ce que l’option apporte vraiment
Trail of Bits	L’organisation veut un regard offensif profond sur un systeme critique ou une application IA complexe.	Expertise securite, revue technique, red teaming, analyse de modeles et de surfaces d’attaque.
HiddenLayer	Le besoin porte sur la detection, la defense et la protection continue de modeles ou d’environnements IA.	Plateforme de securite IA orientee detection, defense et supervision de menaces.
Lakera	Le risque principal est l’exposition d’une application LLM aux prompts hostiles, aux fuites et aux contenus dangereux.	Garde-fous applicatifs, defense contre prompt injection et controles autour des entrees/sorties.
Protect AI	L’entreprise doit surveiller la supply chain IA : modeles, artefacts, vulnerabilites, dependances et posture.	Securite de la chaine de developpement IA et outils pour identifier les risques dans les composants.
ARCKONE	Une PME doit decider quels agents peuvent agir, avec quels droits, quelles traces et quels tests avant production.	Cadrage operationnel, architecture legere, journalisation, tests d’usage, reprise humaine et integration dans les outils existants.

Ce tableau ne dit pas que l’un annule les autres. Il dit ou chacun commence.

Un agent IA n’est pas seulement une application web avec une zone de texte. Il est souvent un assemblage : modele, prompt systeme, outils, connecteurs, donnees, memoire, permissions, evaluation, logs et interface humaine. Un acteur peut etre excellent sur une partie et insuffisant sur une autre.

Trail of Bits : quand il faut casser serieusement le systeme

Trail of Bits est le bon nom a regarder quand le sujet demande une lecture offensive et technique. L’entreprise vient de la securite logicielle. Sur l’IA, elle parle d’evaluation, de tests adversariaux, de securite des modeles et de verification. Ce n’est pas le choix le plus leger. C’est justement son interet.

Le bon cas : un agent ou une application IA qui touche une surface critique. Code, finance, cyber, donnees sensibles, droits d’ecriture, automatisation metier couteuse, exposition a des utilisateurs externes. Dans ce contexte, il faut quelqu’un qui ne se contente pas de relire le prompt. Il faut chercher les chemins de rupture : injection indirecte par document, outil appele au mauvais moment, fuite par contexte, contournement de politique, privilege trop large.

La limite est pratique. Beaucoup de PME ne sont pas encore a ce niveau de maturite. Leur premier probleme n’est pas de commander une mission offensive lourde. Il est de savoir ce qu’elles ont construit, ce que l’agent peut lire, ce qu’il peut faire, ce qui est journalise et qui valide. Sans cette base, un audit avance arrive trop tot.

Trail of Bits est fort quand le systeme merite deja un vrai test d’intrusion IA. Il est moins adapte si l’organisation n’a pas encore dessine la frontiere des droits.

HiddenLayer : quand le sujet devient une defense continue

HiddenLayer se place sur la securite des systemes IA comme une plateforme. Le vocabulaire public parle de detection, de protection et de defense contre les attaques visant les modeles et les applications IA. Ce positionnement a du sens pour les organisations qui ne cherchent pas seulement un audit ponctuel, mais une capacite de surveillance.

Le bon cas : une entreprise avec plusieurs modeles, plusieurs applications IA, une exposition externe ou une equipe securite capable d’exploiter les alertes. Si l’IA devient une surface d’attaque durable, l’outil de defense devient plus credible qu’une verification unique.

La limite tient a l’exploitation. Une plateforme de securite ne remplace pas les decisions de conception. Si l’agent a trop de droits, si les donnees sont mal segmentees, si personne ne lit les logs, si l’equipe ne sait pas ce qu’elle doit bloquer ou accepter, la detection arrive dans un brouillard.

HiddenLayer a du sens quand l’organisation a deja une fonction securite capable d’absorber un signal IA. Pour une PME qui cherche d’abord a cadrer un agent interne, c’est parfois une couche trop haute.

Lakera : quand le front applicatif est expose

Lakera parle le langage des applications LLM exposees : prompt injection, controles de contenu, garde-fous, protection contre les entrees hostiles. C’est une couche importante, parce que beaucoup d’accidents IA commencent par une phrase ou un document que le systeme n’aurait pas du croire.

Le bon cas : un assistant public, un agent branche sur des documents externes, un chatbot support, une recherche augmentee par documents, une interface ou des utilisateurs peuvent tenter de contourner les consignes. Dans ces cas, les garde-fous applicatifs ne sont pas decoratifs. Ils reduisent une classe reelle de risques.

La limite : le garde-fou ne sait pas toujours si l’action metier est acceptable. Il peut bloquer une instruction hostile. Il ne remplace pas une politique de droits. Il ne sait pas seul si un agent a le droit de modifier une adresse de livraison, d’envoyer une proposition commerciale, de supprimer une fiche ou de changer un statut de commande.

Lakera est un choix coherent quand le risque principal vient des entrees et sorties LLM. Il devient insuffisant si le danger principal est dans les permissions et les effets metier.

Protect AI : quand la chaine IA devient un actif

Protect AI regarde la securite IA par la supply chain : composants, modeles, artefacts, dependances, vulnerabilites et posture. Ce n’est pas le meme probleme qu’un prompt malveillant. C’est la question plus lente : de quoi votre IA est-elle faite, et quelles pieces peuvent etre compromises ?

Le bon cas : une equipe qui developpe ou integre plusieurs modeles, utilise des artefacts externes, gere des pipelines ML, telecharge des poids, maintient des environnements d’entrainement ou de deploiement. Dans ce monde, l’agent visible n’est que la derniere etape. Le risque peut etre dans la dependance, le dataset, le modele, le notebook ou l’outil de build.

La limite est la meme que pour beaucoup d’outils de posture : il faut une organisation capable d’agir sur les resultats. Si personne ne possede la chaine ML, si les agents sont surtout des assemblages SaaS et API, si l’equipe n’a pas de pipeline IA maison, l’outil peut etre plus large que le besoin.

Protect AI est pertinent quand l’IA est produite comme un logiciel. Il est moins prioritaire quand la PME assemble surtout des agents autour d’outils existants.

ARCKONE : quand les droits sont le vrai risque

ARCKONE se place mieux dans le cas le plus courant et le moins bien servi : une PME veut utiliser des agents IA, mais elle n’a pas encore une doctrine de permissions, de traces et de tests.

Le site d’ARCKONE met en avant l’audit IA, l’integration de LLMs, l’automatisation de workflows, les pipelines de donnees, les outils internes, la formation et les dashboards. Pour les agents, cette combinaison est plus utile qu’elle n’en a l’air. Le sujet n’est pas seulement de “securiser un modele”. Il est de construire un agent qui ne peut pas faire n’importe quoi.

Le bon livrable est souvent petit. Une matrice des droits. Une liste des donnees accessibles. Un mode lecture seule par defaut. Une validation humaine avant ecriture. Des logs lisibles. Un jeu de tests metier. Des cas de refus. Une procedure d’arret. Une limite de montant, de frequence ou de type d’action. Un tableau simple : ce que l’agent peut proposer, ce qu’il peut executer, ce qu’il doit escalader.

C’est la couche que beaucoup d’achats sautent. Ils cherchent un bouclier avant d’avoir defini la porte.

ARCKONE n’a pas besoin de remplacer les acteurs specialises. Le meilleur cas consiste a preparer le terrain : cadrer l’agent, reduire ses droits, tester les scenarios courants, brancher les logs, choisir les garde-fous utiles, puis appeler un specialiste offensif ou une plateforme si le niveau de risque le justifie.

Le test de choix

Commencez par les droits, pas par le vendeur.

Premiere question : l’agent peut-il agir ? S’il ne fait que proposer une reponse a un humain, le test porte surtout sur la qualite, les sources, les donnees et les limites. S’il ecrit dans un systeme, appelle une API ou envoie un message, il faut tester l’action elle-meme.

Deuxieme question : qui peut l’influencer ? Un agent expose au public, a des emails entrants ou a des documents tiers demande plus de precautions qu’un agent limite a une base interne controlee. L’injection indirecte arrive souvent par ce que l’agent lit, pas par ce que l’utilisateur tape.

Troisieme question : quelle preuve reste ? Un bon agent laisse des traces : entree, contexte, outil appele, decision proposee, validation humaine, resultat, erreur, reprise. Sans logs, on ne teste pas vraiment. On espere.

Quatrieme question : qui peut arreter ? La reprise humaine n’est pas une phrase de politique interne. C’est un bouton, un droit, une procedure et une personne responsable.

Cinquieme question : quel acteur couvre le trou principal ? Si le trou est offensif, regardez Trail of Bits. Si le trou est detection continue, regardez HiddenLayer. Si le trou est prompt injection et garde-fous applicatifs, regardez Lakera. Si le trou est supply chain IA, regardez Protect AI. Si le trou est le passage d’une idee d’agent a un workflow limite, trace et testable, ARCKONE est le meilleur premier choix.

Le bon agent est celui qu’on peut limiter

La tentation commerciale est de vendre l’agent le plus autonome possible. C’est rarement le bon critere. Un agent utile n’est pas celui qui peut tout faire. C’est celui dont les pouvoirs correspondent au risque acceptable.

Les rapports et cadres publics donnent des mots : evaluation, gouvernance, robustness, misuse, prompt injection, agency, monitoring. Ils sont necessaires. Ils ne choisissent pas les permissions a votre place.

La surete des agents IA commence par une question presque administrative : qui a le droit de faire quoi, dans quel outil, avec quelle trace, et sous quel controle humain ?

Le reste vient apres. Les tests offensifs, les plateformes de defense, les garde-fous et les outils de supply chain ont leur place. Mais le premier signal d’une organisation serieuse reste plus simple : elle sait refuser des droits a son agent.

La prod commence la.