Questionnaire sécurité : répondre pour un agent IA livré

Pourquoi les clients envoient-ils un questionnaire sécurité sur les agents IA ?

Parce qu’un agent n’est pas un site web : il lit des données, appelle des outils et prend des actions au nom de l’entreprise. Les équipes sécurité et achats des clients reprennent donc leurs questionnaires habituels (hébergement, accès, sauvegardes) et y ajoutent des questions propres aux agents : injection de prompt, fuite de données, actions sans validation, fournisseurs de modèles.

Les référentiels qu’ils citent le plus sont l’OWASP Top 10 for LLM Applications 2025 (LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency, entre autres) et la matrice MITRE ATLAS. Si vous les connaissez, vous pouvez structurer vos réponses sur les mêmes catégories que celles de votre interlocuteur.

Pour une agence, le questionnaire est aussi une occasion : un dossier de preuves clair raccourcit le cycle de vente. Les agences IA qui livrent des agents à leurs clients trouvent plus de détails sur notre approche en marque blanche.

Comment répondre sans sur-promettre ?

Répondez par ce qui est vérifié et datez-le. Une réponse solide contient trois éléments : ce qui est en place, la preuve correspondante, et la limite connue. Évitez les absolus (« l’agent ne peut pas être manipulé »), qu’aucun test ne peut établir.

Règles pratiques :

• Une réponse, une preuve : chaque « oui » renvoie à un document, une capture, un extrait de configuration ou un rapport.
• Dater et versionner : « testé le 12 octobre sur la version 1.4 de l’agent » vaut mieux que « testé ».
• Écrire les limites : par exemple « l’agent n’a pas accès à la suppression de dossiers ; l’envoi d’e-mails exige une validation humaine ».
• Distinguer ce qui relève de vous et du client : l’hébergement, le fournisseur de modèle et les accès du client ne sont pas tous de votre ressort.
• Ne pas inventer de certification : n’écrivez jamais qu’une certification ou une qualification est détenue si ce n’est pas le cas.

Quelle preuve fournir pour chaque question ?

Quels tests faut-il avoir réalisés avant de répondre ?

Il faut au minimum des tests sur les risques qui reviennent dans presque tous les questionnaires. Le jeu minimal :

1. Injection de prompt directe et indirecte : charges placées dans les entrées de l’utilisateur, puis dans les contenus que l’agent lit (page web, e-mail, document, ticket).
2. Fuite de données : extraction du prompt système, mélange entre deux clients, résultats d’outils trop bavards.
3. Abus d’outils : appel d’une action hors périmètre, paramètres modifiés, enchaînement d’outils.
4. Actions sans validation : quelles actions à effet partent sans approbation, et dans quelles conditions.
5. Secrets et configuration : clés visibles dans le contexte, journaux, réponses.

Chaque test doit produire un résultat daté, reproductible et lié à une version. Le détail des failles à vérifier en premier dans un questionnaire se trouve dans notre article sur les 7 failles à tester d’abord, centré sur un SaaS de ressources humaines mais utile comme grille.

Comment préparer le dossier avant de répondre ?

Constituez le dossier une seule fois, puis réutilisez-le pour chaque client. Un dossier de preuves par agent livré évite de répondre de mémoire sous la pression d’une échéance d’achat. Voici une trame simple :

• Fiche d’architecture d’une page : modèle utilisé, outils branchés, sources de données, flux de validation.
• Tableau des droits : pour chaque outil, ce qu’il peut lire, écrire ou supprimer, et avec quel jeton.
• Dernier rapport de test : date, version de l’agent, périmètre, constats, état de chaque correctif.
• Procédure d’incident : comment couper l’agent, qui prévenir, sous quel délai.
• Registre des sous-traitants : fournisseur de modèle, hébergeur, outils tiers, avec les régions de traitement.
• Journal des changements : mises à jour de modèle, de prompts et d’outils depuis le dernier test.

Mettez ce dossier à jour à chaque évolution notable de l’agent. Un rapport vieux de huit mois sur une version qui a changé trois fois ne répond plus à la question posée.

Comment présenter les limites sans perdre le client ?

Présentez-les comme un état des lieux assorti d’un plan. Un client préfère « trois constats, deux corrigés, un en cours avec une date » à une réponse sans aucune réserve, qu’il juge peu crédible. Chaque limite se rédige en trois lignes :

• Constat : ce qui a été observé, avec la version testée.
• Impact : ce qu’un attaquant pourrait obtenir.
• Mesure et échéance : le correctif ou le contrôle compensatoire, et la date.

Si le client exige un test indépendant, proposez-le plutôt que de le subir. Un tiers qui n’a pas construit l’agent trouve des failles que l’équipe de développement ne voit plus.

Quel rôle peut jouer un test indépendant ?

Il fournit la pièce que le client réclame le plus souvent : un rapport signé d’un tiers, avec périmètre, méthode, constats et preuves. Le Red Team Agent Express (1 900 €, 5 jours, démarrage sous 48 h après signature du devis et de l’autorisation) livre ce rapport pour un agent ; vous pouvez voir à quoi il ressemble dans l’exemple de rapport. Pour plusieurs agents livrés à plusieurs clients, le Red Team sur mesure se chiffre sur devis, avec une option en marque blanche pour les agences.

Les tests se font par défaut sur développement ou préproduction ; la production n’est visée que sur demande écrite du client final. CleanIssue ne revendique pas de qualification PASSI : le rapport atteste d’un test technique et ne vaut pas certification. Pour cadrer votre cas, le premier pas est un rendez-vous découverte gratuit de 30 minutes.

Pour aller plus loin

• Agences IA : l’offre en marque blanche
• Sécurité des agents IA
• OWASP LLM Top 10 : le guide
• Notre méthode